Oracle数据库性能问题分析的一种常规思路

最新推荐文章于 2024-07-03 22:24:10 发布

数据和云

最新推荐文章于 2024-07-03 22:24:10 发布

阅读量707

点赞数

文章标签：数据库编程语言人工智能 jdbc 大数据

原文链接：https://www.modb.pro/db/43443?sjhy

版权

点击上方"数据和云"

关注我们！

这两天微信群里在讨论一个Oracle数据库性能问题引起业务问题的案例，一位朋友把分析报告发到了群里。正好有空就看了看，感觉这份报告颇有Oracle原厂工程师的味道，从问题到现象到分析到结论一气呵成，十分连贯。不过以老白二十年的经验，不大认可这份报告的结论。因为这份报告还没有充分的分析一些重要的数据，就直接做出结论了，这很容易出现误判。实际上对于一个故障的分析，事实只有一个，所有的报告只是观点而已。对于观点，就没办法说谁的观点一定就对，谁的观点一定就错。判断报告是否准确的最佳方法是是否真的解决了这个问题，而很多数据库故障和这个案例类似，最后是自愈了，因此不存在解决问题的事情，而且这个问题是否再现也很难说。如果按照报告上的做法去调整了参数，或者升级了系统，这个问题就不再出现了，那就说明这个报告的判断就是正确的吗？也不尽然，因为有可能未再次出现故障是这个故障的触发条件没有重现的原因。

幸好这个故障十分典型，所以老白很快就梳理出了问题的脉络。也拜谢这份报告的规范性，把问题描述的已经十分清晰了。

首先我们看故障最严重的时段的TOP EVENT，排在第一位的是row cache objects闩锁，占到等待事件的49.1%。实际上上周五群友发出这个AWR报告的时候我也简单的看了一下，排在第一位的row cache objects闩锁的平均等待时间是5毫秒。row cache objects是SGA中管理row cache的闩锁，主要是用于数据字典的串行化访问，这个闩锁在2000年左右做DBA的人里，十分著名，当时因为SGA比较小，服务器性能也较差，因此一旦这个闩锁出问题，很容易耗尽CPU资源，导致数据库故障。不过从经验上看，目前这个闩锁的平均等待时间并不大，而且其他的共享池相关的等待事件指标都还算不错，还不足以让数据库系统出现特别严重的问题。下面我们来看看系统资源的使用情况：

从Load上看，还不算高，不到50%，CPU也有超过50%的IDLE，IO似乎也还算可以，从IO相关的等待事件来看也还没有出现瓶颈。再来看看LOAD PROFILE：

每秒6800K左右的REDO，916.8万的逻辑读，8900+的执行，408的事务，对这种88个物理核（怀疑是4路至强服务器，CPU可能是E8 GOLD 6238T或者E5-2699）的服务器来说，这点负载不算太高。从命中率看：

LIBRARY HIT比较呆，软解析比例94.57%有点低，不过还可以接受，从no-parse cpu看，PARSE消耗了12%左右的CPU，算是比较高了，不过也不是不可以接受的，因为CPU资源本身并不存在瓶颈。

所以从这份报告上看，似乎这套系统虽然出现了一些row cache objects闩锁的争用，本身并没有出现十分严重的故障。当时也就没有深入去分析了。昨天下午，这位群友把分析报告发出来后，老白看了一眼报告，感到最终定位为Oracle的一个BUG，似乎理由不是很充分。正好这份报告里的附件十分完整，还包含了awr对比报告，因此就稍微分析了一下相关的数据。同时这份报告写的十分规范，报告的背景分析里提到了一个现象引起了我的注意：

统计分析未正常结束往往是引起一些SQL执行计划错误的重要原因。因此马上对比了平均每秒逻辑读的指标，在故障期间，大概是900万+/秒，而正常时段是300万+，差了3倍。这种情况很可能是SQL的执行计划出现了问题，于是直接跳到TOP SQL BUFFER GETS：

从上面可以看出，存在一些SQL，在正常时段没有出现在TOP SQL中，而这份报告中出现了，开销十分大。而在这份对比报告中，正常时段存在而本报告中不存在的SQL比较少。

而从执行时间较长的TOP SQL的对比分析上看，二者执行时间的差异并不大，说明row cache objects虽然对系统有影响，但是对SQL的执行时长的影响还不至于引起如此大的性能问题。

于是我建议那位朋友，对于存在严重性能问题的应用执行的SQL，做一个awrsqlrpt,从而分析一下，是什么因素导致的性能问题。如果不出意料，这些SQL在逻辑读上，对比正常时段，都有较大的差异，从执行计划上来看，有可能会存在多个执行计划，其中一个是错误的（或者只存在一个错误的执行计划）。因为在故障期间的排名TOP 3的一条SQL里，我已经从两份报告中看到了不同的执行开销：

在问题最严重的10分钟里，这条SQL执行了19次，平均每次的buffer gets超过4000万，而同一天稍后的一个40分钟的AWR报告中：

这条SQL的buffer gets是104万期间相差了40倍，这是十分典型的SQL执行计划错误的表现。

实际上这个案例分析的方法一旦掌握了，再分析类似问题就会比较容易。从这个案例可以看出，有很多种方式都可以去解说某个故障，不过很多种解说中最多只可能有一个是正确的，甚至有可能所有的解释都是错误的。而从错综复杂的问题表象中抽丝剥茧，找到正确的问题原因，仅仅依靠数据分析是不够的。因为从数据分析上看那份报告也解释的通。真正定位问题的关键是专家的经验。以老白二十多年的运维经验，清楚CURSOR_SHARING/SESSION_CACHED_CURSORS这些参数在什么场景下能发挥作用，清楚row cache objects闩锁在什么情况下才能对系统造成致命的影响，因此就会把这条诊断路径的优先级设定为较低，因此才能十分精准的找到更加适合的诊断路径，更容易定位问题。这也是“运维知识自动化”体系建设中的关键，除了数据分析，专家经验或者说知识库的水平，才真正决定了自动化分析工具的水平。

END