某客户应用生产系统是使用两节点Oracle RAC数据库环境，6月19日应用运维人员对其进行数据清理和导数操作后，两个数据库节点的CPU使用率频繁达到90%以上，并持续了近10天，严重影响后续任务的执行。

工程师29日到达现场进行分析排查后，定位了此次性能问题的原因并提出解决方案，实施应对方案后，两个数据库节点的CPU使用率下降到正常标准，得到客户肯定。

一、故障处理

1、基本信息收集

l  数据库环境：Oracle 11.2.0.3 RAC

l  操作系统：ASianux Server 3.4

l  近期CPU趋势：

分析CPU趋势发现：22日之前，1节点CPU使用率峰值偶尔会达到90%以上，22日之后，达到90%以上的频率明显升高；2节点峰值稍高于1节点，趋势类似。

与客户沟通了解到：19日之前，两个数据库节点的CPU使用率已经偏高，偶尔会达到90%以上；但22日之后频率明显升高，CPU的内核态消耗偏高，处于20%-25%左右。

2、初步分析

工程师在收集分析了AWR和ASH等报告以及等待事件后，发现如下问题：

l  分析等待事件发现，等待次数较多的是单块读，往往是由于使用了错误的索引。

l  log file sync 和 gc 相关的等待说明两个节点存在相同业务，并且节点间数据传输频繁。

l  direct path read 等待事件往往意味着出现了并行SQL，或是因为执行计划改变导致SQL使用了错误的访问路径。

l  shared_pool和buffer cache存在抖动现象。

3、深入分析

3.1 工程师首先根据SQL执行情况，对执行耗时和CPU消耗最多的语句进行分析。

可以看出语句7u4g4ab1vkw5a 耗时、消耗CPU以及逻辑读均较多。

应用运维人员在19日对数据库做了rename表和重建索引的操作，语句 7u4g4ab1vkw5a 涉及的表 vnod_info_91 无统计信息。

此表有两个索引，根据谓词可以看出，此查询应使用唯一索引，但由于缺少统计信息，优化器错误的选择了另一个索引进行范围扫描。此语句执行次数较多，引起异常等待，并且占用CPU较高、仅有一个错误的执行计划，buffer cache和shared_pool的内存转换有可能受此语句影响。

显然应该使用唯一索引，但选择了IDX2。

3.2 数据库监控用户执行了一些并行度较高的查询。

工程师在29日上午10:04和11:22出现的CPU报警分析中，直接定位到此用户的并行查询。一个查询开启32个并发，另一查询开启8个并发，等待事件为direct path read。

3.3 其他并行查询

值得注意的是，白天业务时段内，其他应用用户也存在并行查询，虽然并行度不高，但语句较多。

3.4 工程师对数据库表和索引做了检查，发现数据库本身也存在大量带有并行度的索引和表。

3.5 数据库备份的时间为每天0点开始，共持续17个小时左右，运行备份程序的节点CPU需要多消耗15%左右。

3.6 两个节点运行相同业务，且没有关闭DRM，数据在节点间传输过于频繁，可能引起log file sync等待，对内存的分配又会导致系统态消耗CPU。

3.7 这套数据库禁用了每天收集统计信息的任务，并且未开启自主定期收集。

二、处理建议

l  对表vnod_info_91进行统计信息收集，确定是否执行计划改变为唯一索引扫描。

l  建议应用运维人员编写对业务表的统计分析脚本，排除特别大的表，避免优化器选择错误的执行计划。

l  将存在并行度的表和索引重置并行度为1，清理无用的索引。

l  尽量减少其他SQL的并行查询，确定是否可以使用索引进行优化。

l  监控用户在非业务繁忙时段执行并行度较大的查询。

l  RMAN备份时间调整为2天或3天一次，减少对资源的占用，避免业务繁忙期间频繁备份。

l  在业务允许的时间窗口关闭DRM。

l  在压力和负载允许的情况下，相同类型的业务尽量使用单独的RAC节点，避免产生过多的gc等待。

三、经验总结

l  通过本次事件可以发现，这套数据库存在较多问题，CPU使用率的持续增高并非突发事件，而是反映出一段时间以来数据库的运行情况。

l  数据库在此次性能问题出现前，已开启了较多并行查询，CPU使用率一直平均在50%左右，问题并未暴露出来。进入6月后，随着新业务不断增加，日常操作增多，导致CPU使用率较之前已有所增加；19日又新增了业务，表面上看是使用了错误的索引导致CPU使用率持续增加，实际上是多个问题的一次综合爆发。

l  由于停机窗口以及业务需要等问题，本次并未实施全部建议。目前每天运行收集统计信息的脚本，删除无用索引，重置表和索引的并行度为1；语句7u4g4ab1vkw5a使用唯一索引，两个数据库节点的资源使用情况亦得到较大改善。通过CPU趋势图可以看出，29日晚至30日凌晨开始收集统计信息后，两个节点CPU使用率呈下降趋势。至7月3日，CPU使用率趋于稳定。如果后续将其他操作建议落实，CPU使用率将进一步下降。

如欲了解更多，请登录十大靠谱网赌软件官方网站:o8lg.yzmum.com