熟悉Oracle数据库的DBA肯定用过AWR报告和ASH报告。AWR报告是很多DBA分析Oracle数据库性能问题的利器。而对于ASH报告的使用则稍微陌生一点。事实上ASH报告包含的技术细节也是不够的，ASH的明细数据更有分析价值。

Oracle的AWR的 LOAD PROFILE 可以十分明确地反映出数据库的负载情况，目前绝大多数国产数据库都提供类似Oracle AWR这样的负载报告，数据库负载情况是分析数据库性能问题的关键。很多问题从历史负载的比对就可以得到结论。命中率指标也是反映出数据库性能的十分明确的指标，一些因为数据库配置有问题导致的性能问题，很可能会反映在命中率上。幸运的是，国产数据库的AWR报告里这方面的数据也比较完善。

等待事件是分析Oracle问题的最有价值的数据，如果发现明显某种等待事件影响了性能，那么在MOS上丰富的资料库中搜索一番，可能就能找到答案了。不幸的是，国产数据库缺少MOS这样的知识库，因此分析等待事件的能力偏弱一些，不过有经验的DBA还是可以从中分析出一些问题。比如上面的等待事件中，WAL写入锁占了大部分等待时间，优化WAL子系统性能应该能够改善性能。

上图是电科金仓数据库的时间模型。时间模型是分析数据库总体性能问题中十分有价值的数据，不过这些数据的解读因为需要比较专业的数据库知识而往往被忽视了。通过时间模型，我们可以看出数据库在哪些地方消耗了更多的时间，一般与做总体优化。如果某数据库的时间模型数据是准确的，那么可以做很多有价值的分析，定期采集数据库的时间模型，并保存起来，当某些故障发生时进行标注，积累多了，就可以构建分析与预测模型了。

“AWR”报告比较适合于宏观分析，那么ASH数据在微观分析方面很有价值。比如我们从“AWR”报告中看出行锁等待是引发性能问题的关键。那么我们就需要去定位为什么行锁等待会那么严重。这时候AWR报告不一定能发挥作用了。有可能行锁等待只持续了几分钟，而AWR报告是1小时采样的，无法通过细微的分析最终定位问题的根因。另外锁等待或阻塞类的问题，在ASH数据里是能够明确查到阻塞者的。找出阻塞者，分析阻塞者在做什么，在等待什么，往往是定位问题根因的关键。

ASH数据还可以用来分析某些SQL语句并发执行的情况，会话的变化情况(会话数量、会话分布情况、活跃会话数量、异常会话数量、阻塞会话数量等的变化)，结合服务器资源变化的趋势，可以获得十分有价值的分析结果。一般的分析方法如下：

今天因为时间关系，我就不展开这张图的解释了，明天我会写一个最近遇到的这方面的案例，到时候再来分析这种图吧。ASH数据要能够定位根因就必须是十分丰富的。数据甚至比会话视图里的数据还要丰富。Oracle的ASH数据就是如此的，在数据中还包含了会话两次被采样之间的各种统计数据的变化，比如物理读的次数、总量等。这些数据对于定位根因十分关键。

幸运的是越来越多的国产数据库目前已经开始支持活跃会话数据的采样与保存，让我们获得了这个分析微观问题的关键数据。AWR做宏观分析，找出大体的分析方向;然后使用ASH数据做微观分析，通过阻塞链分析，执行SQL情况的分析等实现更为精准的定位，这样的组合分析是定位性能问题根因的有效手段。

不过国产数据库的ASH数据与Oracle相比还有很大的差距，上图是电科金仓的ASH数据，其丰富程度与Oracle还有一定的差距。实际上Oracle是把SESSION STATE OBJECT中的所有数据都做了合并，形成了比v$session更为丰富的数据。国产数据库厂商也应该学习一下，ASH不应该是个摆设，而应该成为分析阻塞类根因的利器。