从生命周期的角度谈谈 Oracle 12c, 18c, 19c 和 20c

转载:
原文链接:从生命周期的角度谈谈 Oracle 12c, 18c, 19c 和 20c
看到的博客链接:从生命周期的角度谈谈 Oracle 12c, 18c, 19c 和 20c

之前的博客我们了解到Oracle 20c即将发布,如下:

Oracle 20c 官方文档正式发布
https://www.cndba.cn/dave/article/4029

在我去年出版的《Oracle 18c 必须掌握的新特性》一书中也有一小节专门讲解了Oracle 的生命周期以及补丁的变化。

《Oracle 18c 必须掌握的新特性》 发售了
https://www.cndba.cn/dave/article/3453

那么对于Oracle 12c,18c,19c, 20c,在学习时,我们如何进行选择,这个也就是写本片博客的目的。 其实要搞清楚这一点,最好的方式就是从数据库生命周期进行了解。

那么对于Oracle 12c,18c,19c, 20c,在学习时,我们如何进行选择,这个也就是写本片博客的目的。 其实要搞清楚这一点,最好的方式就是从数据库生命周期进行了解。
下图是最新的Oracle 发布时间图:
在这里插入图片描述
这个是早期Oracle 的发布路线图:
在这里插入图片描述
其实从这2张图片也可以非常清晰的看出,Oracle 也在不断淡化之前的老版本问题。在早期的路线图中,我们还可以看到新版本号和老版本号之间的对应关系。 如果按旧的版本号规则,18c 等于 12.2.0.2。 19c 等于12.2.0.3。

在新的版本路线图中,有一个非常大的变化,就是提到,Oracle 19c 将是一个长期版本。如果按旧的观点,我们应该等的是12.2.0.4, 类似于11.2.0.4。 但是Oracle 现在直接告诉我们,没有这个版本了。 19c 将是12c 家族的最后一个长期支持版本。
在这里插入图片描述
通过上图,我们可以看到19c 可以支持到2026年。并且这里还有一个重要信息,就是Oracle 将12.2 的三个版本单独规划出来一个12.2 家族。
所以,根据以上的分析,在我们选择和使用Oracle 版本时,应该选择12.2 家族的最新版本19c。 目前从Oracle 官网可以下载到19.3的版本,19c 最新的RU 已经到19.6, 这个需要从MOS上进行下载。也就说,从学习和生产环境使用来说,我们都建议使用19c的版本,并更新到最新的RU, 当前是19.6。 关于补丁RU和RUR的问题,可以参考我在之前18c 书,这里不再描述。 至于20c,将会是一个新的版本家族,根据以往的经验看,20c和21c的生命周期都不会太长。 虽然目前11.2.0.4的生命周期已经结束,但没有大规模的普及到12c和19c。 因此未来很长的一段时间(7-8年),将会是Oracle 19c天下。 所以,从现在开始,好好研究Oracle 19c吧。
在这里插入图片描述

<think>好的,我现在需要帮助用户解决如何降低LoadRunner配置要求或优化其性能的问题。首先,我要回顾一下用户提供的引用内容,看看有没有相关的信息可以利用。 根据引用[1],LoadRunner是一个用于负载测试的工具,可以模拟大量用户并发来测试系统性能。用户现在希望降低它的配置要求,可能意味着他们遇到了硬件资源不足的问题,或者想要在较低配置的机器上运行测试。引用[2]提到了负载测试的流程,包括创建脚本、定义场景和分析结果,这可能涉及到如何优化这些步骤以减少资源消耗。引用[3]讨论了场景中脚本的并发用户数配置,调整这些设置可能有助于减少资源使用。 接下来,我需要考虑用户可能的场景。他们可能在资源有限的环境中使用LoadRunner,或者测试需求超过了当前硬件的处理能力。因此,用户需要在不升级硬件的情况下优化LoadRunner的性能。 首先,我应该从脚本优化开始。减少不必要的操作,比如去除冗余的思考时间(think time)和日志记录,这样可以减轻每个虚拟用户的负载。例如,用户可以在脚本中禁用日志,或者仅在出错时记录,这样可以减少磁盘I/O和CPU的使用。 然后是场景配置优化。调整虚拟用户的数量和启动方式。如果用户同时运行太多虚拟用户,可能会导致系统资源不足,所以可以分阶段逐步增加用户数,而不是一次性启动所有用户。此外,使用IP欺骗可能增加网络负担,如果测试不需要多个IP,可以关闭这个功能以节省资源。 接下来是监控和分析部分。在运行测试时,关闭不必要的监控工具,如资源计数器和实时结果,可以减少内存和CPU的占用。另外,生成的结果数据量过大时,可以调整结果收集的频率,或者只保留关键指标的数据。 系统层面的优化也很重要。调整操作系统的性能选项,比如关闭视觉效果和调整虚拟内存,可以释放更多资源给LoadRunner使用。此外,确保没有其他后台程序占用资源,特别是在测试运行时。 分布式负载测试可能是一个有效的解决方案。通过在多台机器上分布负载生成器,可以分摊资源消耗,降低单台机器的压力。这需要设置多个负载生成器,并在LoadRunner配置它们协同工作。 最后,定期维护脚本和场景配置,清理无用数据,保持环境的高效运行。这些步骤结合起来,应该能够有效降低LoadRunner的系统配置要求并优化性能。 现在需要检查是否有遗漏的方面。比如,是否提到了结果分析阶段的优化?用户可能需要减少结果数据的存储量,或者调整收集的数据类型。此外,网络优化也可能有帮助,比如使用更高效的协议或压缩数据。 总结一下,我需要将这些思路分步骤整理,确保每个建议都有明确的实施方法,并且引用相关的参考资料来支持建议的可行性。同时,生成相关问题时要覆盖用户可能进一步询问的方向,比如具体如何调整脚本,或者分布式测试的具体步骤。</think>### 降低LoadRunner系统配置要求及优化性能的解决方案 #### 一、脚本优化(降低单虚拟用户资源占用) 1. **精简脚本逻辑** - 移除冗余的事务和检查点,仅保留核心业务步骤 - 使用参数化替代硬编码数据,减少内存占用 - 示例优化: ```c web_url("login", "URL=http://test.com/login?user={username}&pass={password}", LAST); // 参数化替代固定值 ``` 2. **禁用非必要组件** - 关闭思考时间(Think Time):运行时设置中设置$ThinkTime = 0$ - 禁用自动事务:`web_set_max_html_param_len("0");` - 关闭调试日志:运行时设置 → 日志 → 仅错误日志[^3] #### 二、场景配置优化(提升整体执行效率) 1. **虚拟用户管理策略** - 采用梯度加压模式(Ramp Up): $$ \text{初始用户数} = \frac{\text{目标并发数}}{3}, \quad \text{加压间隔} \geq 30\text{秒} $$ - 设置合理的退出策略:立即释放完成用户的资源[^2] 2. **网络资源优化** - 关闭IP欺骗(非必要场景) - 调整连接池设置: ```c web_set_sockets_option("SSL_VERSION", "TLS"); // 使用高效加密协议 ``` #### 三、系统级优化(降低硬件需求) 1. **负载生成器配置** | 配置项 | 推荐值 | 说明 | |--------------|-----------------|-----------------------| | Vusers/Generator | ≤50 | 单机最大用户承载量[^3] | | 内存分配 | 512MB-1GB | 通过`mdrv.exe -memory`参数设置 | 2. **分布式部署方案** - 使用多台负载生成器构建集群 - 配置步骤: ``` 1. 安装Load Agent到备用机器 2. 在Controller中添加IP 3. 分配脚本到不同Agent执行 ``` #### 四、监控与分析优化(减少资源消耗) 1. **精简监控指标** - 仅保留关键计数器:CPU利用率、内存可用量、磁盘队列长度 - 关闭图形化实时更新(Tools → Options → Monitoring → Disable Realtime Graphs) 2. **结果存储优化** - 设置自动清理旧结果:`lr_cleanup_result_dir("*.lrr", 7);` - 使用二进制日志格式(.lrr)替代文本格式 #### 五、替代方案建议 对于配置较低的测试环境,可考虑: - 使用云测试平台托管负载生成器 - 采用轻量级工具JMeter进行初步测试 - 实施分段测试:将完整场景拆分为多个子场景执行
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值