AWR 报告是 Oracle 数据库重要的性能诊断工具，AWR 对一段时间内数据库的核心状态指标进行详细的分类展示，蕴含了十分丰富的信息。如果某个指标异常，可以通过解读 AWR 报告对其追根溯源，寻找解决方案。其他数据库也提供类似的报告，例如达梦提供的 AWR 报告，华为 GaussDB/openGauss 数据库提供的 WDR 报告。然而解读 AWR 报告对 DBA 的要求较高，AWR 报告中有几百个性能指标，每个指标都有对应的含义、阈值和范围值，如果不了解 AWR 报告或者对 AWR 报告中的某些指标不理解，就很难发现问题；即使对于有经验 DBA 来说，分析解读 AWR 报告时也需要从大量指标中查找出异常指标，排查问题的过程需要耗费较多时间，并且人工分析还可能存在数据指标误读的情况。是否有更加直观简便和智能的方式来做溯源分析呢，zCloud 就做了这样的尝试——zCloud 基于更高频度的采样数据进行分析，把类似 AWR 的指标数据分为了操作系统、IO、并发、负载、性能、集群、总体健康等数个维度，建立了一个健康模型，通过健康模型来提醒运维人员系统可能存在隐患，然后针对发现隐患的维度，收集相关的数据进行综合分析和问题溯源。通过这种基于运维经验与基线的自动化的分析手段，提升数据库的可观测性，帮助 DBA 以一种更加可视化、更加简便的方式管理数据库系统，提高运维效率。还是从一个 zCloud 帮助用户快速溯源问题的真实案例看起：某用户环境 DBA 在晚间巡查时，在 zCloud 问题列表中记录了一个“等待/阻塞的活动会话过多或过长”的严重问题，持续半小时后消失（如下图），这类事件可能复现导致业务变慢甚至中断，必须回溯定位问题。如果是人工分析，会用到 AWR 报告、ASH 数据以及 v$ 视图等，较为费时费力，先看 zCloud 的诊断过程，后面再来对比人工诊断过程。在 zCloud 中，通过智能诊断对该事件的记录，问题相关数据很容易就被观测到。通过查看详情记录可以看到 zCloud 给出的问题描述，认为是“主库活动会话数严重超标”引起 。这里记录了具体的引起该问题的数据库实例，业务会话活动数579个，显然该实例的活动会话严重阻塞。接下来继续查询根因，看看是什么原因导致了这个数据库实例的活动会话数过多。继续往下看，智能诊断给出了根因：“会话被非常规（4级）TX行锁堵塞”（如下图），DBA 点击诊断详情进一步查看智能诊断树，以确保诊断路径正确。诊断树在显著位置给出的诊断路径是：“等待/阻塞的活动会话过多”-》“会话被应用TX/TM锁堵塞数量过多”-》“会话被非常规（4级）TX行锁堵塞”。打开根因的详细数据，可以看到当时已经记录的由行锁引发的问题有301个，而且大部分是由“enq：TX-allocate ITL entry” 引起的，这就是引起阻塞的直接诱因了。值得一提的是，zCloud 智能诊断中事件的历史数据是持续记录的，在下图中，任意时间点的数据都可以查询到，只需要拖动鼠标选择需要查看的时间点，就可以看到诊断路径以及下钻的分析过程和历史数据。结论是某个程序或操作占用了行锁，行锁是数据库在修改一条记录产生的，其目的是为了保证数据的一致性，如果行锁长久不能得到释放，当其他进程想要使用的时候，就会产生争用。那么究竟是哪个程序或者哪个操作导致的呢？我们还需要进一步找到引起阻塞的源头，继续查看诊断树，我们会发现一条“SQL 语句等待并发数过多-》会话被Liabrarycache对象锁阻塞-》DDL 语句正在执行”的诊断路径（如下图）。查看详细数据，有 SQL 语句在执行，时长最长的是“ALTER PACKAGE ……COMPILE DEBUG SPECIFICATION”语句，结合 ASH 数据堵塞链的描述，可以判断引起阻塞的罪魁祸首就是它了。至此，通过智能诊断，整个回溯过程快捷直观方便，几分钟之内就定位到了问题。作为对比，我们再回到人工诊断方式：首先 DBA 导出覆盖阻塞持续时间段的 AWR 报告，发现TOP 10的等待事件，排前两位的是“Library cache pin”和“enq：TX-allocate ITL entry” 。再来查看相应的 ASH 数据，找到阻塞链，也是这两个事件，并且占据了阻塞的 80%，有经验的DBA就会知道“enq：TX-allocate ITL entry”等待的会话的阻塞源会话正在经历“Library cache pin”的等待。继续在 AWR 报告中查找“enq：TX-allocate ITL entry”的等待事件相关指标，发现执行“enq：TX –allocate ITL entry 一半都失败了，且等待事件的执行时间大部分都在大于1秒到4秒之间（如下几图）。此时 DBA 意识到引起阻塞的原因很可能是发生了行锁的争用，在等待事件队列中，TX allocate ITL entry 的行锁执行大部分都失败了，所以判断根因为行锁引起的会话阻塞。随后，查找到 TOP 事件的 P1/P2/P3 值（如下图），此时就要借助 AWR 以外的数据，需要在 Oracle 视图中查询锁表，通过 P1/P2/P3 值找到锁名字、模式、事务的回滚段号和 ITL 列表中 slot 的编号等，从而找到引起锁的 SQL。定位到具体的 SQL 语句后，接下来还要继续借助历史数据查找引起行锁的源头是谁，因为行锁的成因复杂，排除法最终定位到 DDL 操作还需要一连串的分析动作。可以看到，DBA 回溯问题时，是通过 DBA 所掌握的基线数据去分析某个指标是否合理，如果某个指标不合理，那么就需要把这个指标相关的历史数据都找出来，进行仔细的分析，验证这个问题，从而更深入的去查找指标异常的原因。这个过程依赖于 DBA 的经验，问题定位、解决的耗时也因 DBA 的经验积累而不同。这个案例人工分析回溯到行锁的问题，耗费时间以小时计算，而通过 zCloud 智能诊断几分钟就完成了回溯和定位，极大的提高了效率。zCloud 将 DBA 从大量的原始数据、代码中释放出来，只需点击几次鼠标，就可以查询到历史数据，事件持续过程中的详细信息也完全展现，并做智能关联分析，问题定位的过程大大简化，更加准确、及时的发现问题。
zCloud 数据库云管平台，身边的“数据库专家”
云和恩墨 zCloud 数据库云管平台，基于 WaaS（Wisdom as a Service，智慧即服务）理念打造知识库与智能诊断功能，将行业最佳实践和专家经验转化为平台能力，让高级“数据库专家”实时在线，有效保障数据库稳定高效运行。WaaS 模型从数据到智慧，持续将专家经验代码化，为平台动态赋能：数据层面利用管理大数据，实现对数据库做精准画像，改变过去基于指标运维的不足；知识层面通过共建共享知识库，解决过去管理经验孤岛、样本不足的问题；智慧层面通过用户贡献个案、专家标注、机器学习三个来源生成知识点、案例、算法，实现经验代码化。