Oracle 12.2 AWR 报告导读片段

Oracle AWR 报告是分析数据库问题的十分有效的报告，我以前也写过不少 AWR 报告导读方面的文章。Oracle 12C 以后，AWR 报告的内容有了较大的变化，增加了很多内容。昨天正好有个网友发来一份做 BENCHMARK 测试时采集的 AWR 报告，以此为例，原本想写一篇导读文章，不过时间有限，“导读”写成“导读片段”了，因此今天只能给大家展示其中的一个问题分析的案例，希望今后有机会多写几篇此类的文章，把我对 AWR 分析的经验传递给大家。

AWR 报告中基本上每个数据都是有意义的，忽略上面头部信息的朋友不少，分析一份 AWR 报告，不了解服务器的配置是不行的，很多负载和性能方面的指标依赖于服务器的配置。另外上面的数据里的 DB TIME 与 Elapsed 的比值也是很关键的。对于应用变更不是很频繁的系统，对比这个值的变化，对于了解系统总体负载和性能十分关键。

Report Summary 是大多数 DBA 都十分关注的，在 12C 的报告中，位于 C 位的是 ADDM FINDINGS BY Avg Active Sessions,根据活跃会话情况分析出的系统主要问题可以给 DBA 一个分析问题的指导性意见。从本案例上看，SQL 问题还是最为主要的问题。另外热块冲突、RAC 集群和行锁等待是三个十分具体的问题。

LOAD PROFILE 和命中率是 DBA 最需要关注的细节性问题，从中可以看出一些 TOP EVENTS 里不一定看得出来的信息。负载永远是分析数据库问题的关键，离开负载谈性能是没有意义的。这里每秒 24M 的 REDO，48.7 万的逻辑读，读写 IO 的吞吐量和流量似乎不高，解析方面也十分合理。每秒 3.9 万的执行也不算太高，回滚事务数量占比似乎有点高了。而从命中率上看，也是基本正常的。

接下来是很多 DBA 作为 C 位的 Top 10 Events，可以看出行锁平均等待 21 毫秒，如果在普通的应用系统中算是不错的，不过在 BENCHMARK压 测场景，这个等待有点高了，可以随后分析。接下来的 DB CPU 是 SQL 执行所消耗的所有 CPU 的统计，随后几个都与集群和热块有关。热块冲突可能是产生这些等待的主因。

接下来是 Wait Class 的统计，集群等待和应用等待占据了大半部分，从中也可以印证了对Top Events 的分析结论。从集群等待 1.23 毫秒的平均值上看，这套系统的 RAC 集群性能还算正常。USER/IO 和 SYSTEM/IO 都是亚毫秒级的，没有太大的问题。

Host 和 Instance CPU 的指标放在这里有点突兀，很容易让人的分析思路被打断或者被忽略掉。如果前面的分析发现系统资源有问题，那么顺便看看这个就很顺，很可能老外的数据库服务器配置都比较节约，经常出现 CPU 资源不足吧。

Host CPU 可以解读为：2 路服务器，CPU 是16核，32 线程的，总共有 64 线程。SNAP 采集时的负载是 1.99 和 6.33，并不算高，不超过 CPUS 的两倍都不算有明显瓶颈，不超过CPUS 的 60%，不会因为 CPU 资源竞争而引起略微的延时增加。其他几个指标大家都看得懂，我就不多说了。

Instance CPU 是说实例使用 CPU 的分解。大家要注意的是最后一个指标，如果这个值很大，说明因为你的资源管理器的配置可能不合理而导致了 CPU 等待。

在 SUMMARY 里最后一部分数据是 IO PROFILE 和一些内存与一些缓冲区的统计数据。IO和 CHACE 放在一起还是有一定参考意义的。因为 VIA BUFFER CACHE 的指标是和 DB CACHE 配置是否合理紧密相关的。要分析 DB CACHE 配置是否合理最好参考主报告中的相关内容。

AWR 中的这部分内容安排得也十分合理，IO STATS 和 Buffer Pool Stats 是挨着的。

IO STATS 里提供了十分丰富的 IO 分类信息，这里我不一一介绍了。

Buffer Pool Stats 的每个数据都十分有价值，我们不能仅仅看看命中率，其中 Free Buffer Waits 指标如果不为零，说明数据库存在无法分配 DB CACHE 的情况出现，DB CACHE 配置过小或者写 IO 太慢就会引发这个问题。而 Write COMP Wait 则说明当分配 DB CACHE 的时候会因为等待 DBWR 写完脏块后，从 LRU-W 链中将 BUFFER 放回主链，要么 DBWR 写得不够快，要么 DB CACHE 不够大，要么脏块太多。这里可以看到 1493 个等待，这样会大幅降低 DB CACHE 的分配效率，从而加剧 BUFFER BUSY WAITS 等待。最后一个数值是 BBW，就不用我解释了吧。

实际上看到这里，我们是可以看 Advisory Stats 章节的，不过本报告因为启用了 AMM，这部分数据没有内容。

看到这里我们还是很有收获的，因为我们看到了一个和 BBW 直接相关的一个问题，那就是DB CACHE 方面存在的写完成等待问题。如何分析这个问题呢？在这份报告中有几个地方可以对这个问题做进一步的分析。

首先我们来看看实例活跃状态的指标，如果你已经构建起了 Oracle 数据库的运行状态的知识模型，那么你可以利用这些指标做十分深入的分析，找到其中的不合理数据，从而依托数据库的内部原理去定位问题。在十多年前，我写了一本《DBA的思想天空》，其主要宗旨是让 DBA 去了解 Oracle 内部运行的一些基本原理，从而能够利用原理性的东西，去分析你获得的监控数据（特别是 AWR 数据），从而找到数据库深层次的问题。

关键指标是 Oracle 认为对于分析问题最为重要的指标，对于大多数比较明显的问题的分析，通过这些指标就可以有相对直观的了解。对于 DBA 来说，你可以把这些指标做成数据库的基线（每个数据库实例可能都有不同的基线），当系统出现问题的时候，用这些指标来评估数据库当前的负载。不过我们今天要分析的问题，这些指标对你分析问题的帮助有限，我们还是需要看完整的数据。

上面这些指标都是和 BBW/WRITE COMP WAIT 等有关的指标，从指标上看，问题可能是多方位的，DB CACH E存在不足，DBWR 写的效率也不算很高，另外索引叶节点分裂过高，一致性度和 CR BLOCK 读的并发量也很高。遇到这样的问题，优化 DB CACHE 的配置，实际上对于 BENCHMARK 测试这样的场景，关闭 AMM，合理地调整共享内存配置，调整 DBWR 的数量，优化分区表的数量，调整索引的 PCTFREEE 和 INITRANS 参数等都可以改善性能，进一步提高并发量。实际上在做出调整 DBWR 相关的结论之前，我们还需要去看看后台写进程的性能，从而确保系统的 IO 子系统还有提升这方面能力的潜力。

后台进程的写 IO 平均延时是我们要十分关注的，从这个案例看，写 IO 的延时很低，还有进一步提升的潜力。

接下来我们可以通过 Top Segments 来分析哪些对象存在较为严重的冲突和等待，BenchMark 测试实际上很清晰，就那么几张表需要调整。可能因为这些表已经 DROP 了，所以显示出来的都是 MISSING。加大 PCTFREE，增加 HASH 分区数量，加大 INITRANS 都可以有效提升。

马上八点了，今天虽然比平时到公司的时间更早，不过也不足以写一份完整的 AWR 报告的导读。不过在今早的这个导读中，我们也发现了系统中存在的一些隐藏比较深的影响 TPCC 的问题。阅读 AWR 报告曾经是我十分喜欢做的一件事情，有几年时间，我每天的主要工作就是帮助客户和公司的同事阅读 AWR 报告，并把其中的发现标注出来，与同事和客户讨论，通过远程的分析，帮助用户解决棘手的问题。现在还真有点怀念那段简单而充实的日子。希望今后大家如果遇到什么疑难问题，不妨把 AWR 报告发给我，我也许能帮你在这些纷繁的数据中找到一些不容易察觉的问题。