通过案例学学Oracle等待事件分析

Oracle的等待事件分析我已经研究了二十多年了，从Oracle 7.3.4 OWI刚刚成为标准接口开始，OWI可以改变Oracle数据库运维技术的理念就深深植入了我的脑中。Oracle数据库运维从只能通过SQL优化、到可以缓冲区调整进行整体优化，再到等待事件分析分析，时间模型、自动化驾驶的每个阶段的进步，都离不开等待事件分析这个基础工具。如何分析这些等待事件一直也是DBA不断地在学习的，大家也在不断地积累等待事件相关地知识。

这些年来，我们也一直在梳理和积累这方面的知识，不断地完善对等待事件的解读。不过解读等待事件并不是一件简单的事情，这需要十分丰富的经验。周五我在微信群里也和网友讨论过等待事件分析知识的积累问题，大家都希望我能够多分享一些这方面的知识，今天利用我们实验室中的几个实际的客户系统监控数据来学习一下如何通过等待事件分析来定位系统存在的问题。明天的文章我会和大家一起分享一下Oracle锁等待的根因分析的完整表格，供大家参考。

经验丰富的DBA可以通过这些等待事件的组合关系发现系统中可能存在的问题，然后再根据一些相关的指标进行根因收敛，最终定位问题。而很多DBA可能只知道一些主要的等待事件代表什么含义，遇到不明白的问题，只能到METALINK上去搜索相关的文章。运气好的话，他能找到适当的NOTES，从而定位和解决问题。运气不好的时候，很可能会被类似的场景给误导了，得出错误的结论，或者被折腾的没了脾气。

实际上等待事件反映出的数据库的问题也不是那么清晰和简单的。比如说上面的这个例子是一个系统中的等待事件的列表，排在前面的大多数是后台进程的等待事件以及一些IDLE的等待事件，实际上和数据库系统存在的问题关联不是很大的。我们可以看到其中排在比较靠前USER的等待事件是read by other session等待。有点经验的DBA很快就会识别出来，这是系统存在热块冲突。再加上排在更靠前的gc buffer busy acquire的存在，就会更加强化这个观点了，系统存在比较严重的热块冲突。

实际上真的是这样吗？有可能并不是如此的，智能诊断工具并不认为BUFFER BUSY WAITS存在问题。RAC方面确实存在一定的争用问题，不过read by other session等待的根因并不是BUFFER BUSY WAITS，而是IO延时较大的问题。

是不是比较意外呢？实际上read by other session的根因也不一定就是buffer busy waits，正是因为这个原因，这个等待事件才会从buffer busy waits拆分出来。而这个等待事件的可能根因也十分广泛。如果我们掌握知识的时候不准确或者不全面，就会用这些不全面的知识去做出不准确的判断。

实际上，这个系统在这个分析事件段里，buffer busy waits的平均等待时间最大也不过1毫秒，是不存在明显的问题的。

其总的等待次数上，也没有出现明显的暴增。

而操作系统的IO延时确实是存在问题的，最高的IO延时达到144毫秒。

智能化诊断工具发现的另外一个问题，SQL解析的问题，也确实是存在的，在分析的这段时间里，硬解析的梳理维持在一个比较高的范围，高峰时居然达到了700+/秒。这显然会影响系统的性能。

从对这个例子的一些具体的指标的详细分析之后，我们发现智能诊断工具的判断是正确的。数据库中我们观察到了存在的等待事件，都可能是正常的，也都可能是不正常的，如何判断某个等待事件是否正常是需要我们不断地通过实际案例积累才能逐渐提升地能力。因此首先我们不能看到某个等待事件就认为数据库存在某方面的问题，我们必须去进一步的验证这个问题。下面我们再来看一个案例：

不看后面的结论部分，我们能不能自己分析一下，上面的等待事件中可以看出系统中存在哪些问题？也许我们都看到了下面的一些问题，就是我在上面标黄的部分：

• 并行查询比较多
• CURSOR存在一定的争用
• 表/索引扫描比较多
• RAC性能存在一定的问题

如果你自己也已经识别出了这些问题，那么说明你对等待事件的认知已经达到了实战的基本需要了。不过识别出这些问题还只是第一步。下一步我们需要从这些疑点作为起点来做两件事情，第一件事是分析系统到底哪里存在问题，第二件事是确定系统的风险等级（或者说判断系统是否存在风险）。

这是一个ODS系统，存在大量的并行查询是正常的，PX相关的这几个等待事件都不说明PX存在问题，我们完全可以忽略。实际上通过对PX是否降级的指标分析，也可以了解到PX SERVER是否配置不足。

从这些指标可以看出，并不存在比较严重的PX查询降级的问题，本月出现的最多的平均每秒PX查询降级到串行的最高值是每秒0.03次，是可以接受的。不过如果系统的资源还充足的话，还是可以加大PX SERVER的数量的。

Cursor：Pin S的平均等待时间1毫秒出头，也没有太大的问题，这个疑点也可以排除。那么我们下面就可以再来看看db file scattered read的问题了。

偶尔有点高，不过还是可以接受的，在这个时间段里最高接近10毫秒，平均2.42毫秒。因此我们看了一圈发现，从系统的整体情况来看，风险不大。接下来我们来看看智能诊断工具对这段时间里系统存在问题的分析结论：

IO延时过大？网络故障？怎么回事？这一点似乎我们是没有看到的，为什么智能诊断工具会发现这些问题，而我们没有直接发现呢？首先我们先看看这些问题是否存在吧。

好像IO延时偶然会出现一些高点。我们来看看OS层面的磁盘IO延时

还真的存在问题。我们再来看看网络的问题。

网络延时还真的存在一些问题，看样子gc current grant 2-way这些等待时间有可能和这个有关，不过从当前地情况来看，还不算太高。为什么我们没能找到这些问题呢？这是因为等待事件分析不仅仅要靠表面现象，还要根据自己地知识积累去发散分析，找到关联问题并进行分析。在这方面，智能化分析工具通过服务器的算力可以快速的计算，因此比人工分析具有更高的效率。而通过智能诊断算法，我们也可以学习到一些原本不掌握的算法。

实际上，通过这个案例，我们可以学到一些分析问题的方法，首先，某个等待事件是否意味着某个问题，需要找到相关的指标去进行分析，而不能马上就下结论。其次，我们对等待事件知识掌握的准确程度决定了我们的分析的效果。如果我们的知识掌握的是有偏差的，甚至是错误的，那么就很可能会导致错误的分析。再其次，根据当前现象，通过自己掌握地知识进行发散分析也十分关键。