端午假期外加孩子高考正好这几天出成绩，因此几天都没有动笔了。这几天确实很焦虑，心比较乱，所以也没有心思写东西。昨天广东高考分数发布，一块大石头也落了地。孩子不是学霸型的，所以期望也没有那么高，总的来说还算是正常发挥。接下来的志愿填写工作量还是不小的，虽然提前研究了一些学校，到了要真正报考的时候，还是有大量的工作要做的。

这两天除了在网上查看电子资料外，“大厚本”也是必须去认真翻阅的资料。对于如此众多的数据需要人工分析，我都有了一种写个PYTHON工具来分析这些数据的冲动。后来考虑到只有一个孩子，这几天报考时间，等我写出来黄花菜都凉了，就打消了这个念头。不过我想如果有人把这些数据都收集起来，训练一个大语言模型，用来对外提供咨询服务，也许还真的能赚到钱。

还是回归正题，前两天在谈数据库可观测性中的TRACE，可能有些朋友对TRACE关注不多，甚至对于TRACE和日志这两种数据库可观测性能力也有点模糊。数据库的TRACE很可能在日志中生成，而且TRACE也可能是在数据库出现某种现象时产生的，但是TRACE和日志是数据库可观测性方面的两个不同的领域。

数据库日志是记录数据库的正常行为的，包括数据库遇到BUG，遇到故障时，都是通过记录日志的方式让使用者了解情况。而TRACE往往是记录一些特殊的信息，在数据库正常运行时并不输出这些信息，只有主动要求输出日志，或者在分析某个问题或者调试某种应用时，才主动设置或者主动要求数据库输出这些信息。

从一个DBA的角度，我们需要数据库拥有什么样的TRACE能力呢？实际上Oracle数据库为我们提供了一个十分好的样板。这些年来，处理各种疑难杂症的时候，我经常会用到TRACE，因此在这方面也有些经验，今天我把这些经验总结一下，一方面也为DBA们提供一些分析Oracle数据库的思路，另外一方面也给我们的国产数据库提一些需求。

作为DBA，我们最需要的TRACE能力可能就是知道SQL语句是如何运行的，执行计划是如何产生的。如果我们遇到某条SQL，访问的数据也没啥变化，不过今天突然执行变慢了，我们需要了解慢的原因。这时候我们就需要了解这条SQL的执行的详细情况了。Oracle数据库的10046 trace是二十年前DBA拥有的核武器级别的TRACE工具，哪个DBA掌握了10046 trace，就能够分析与解决一些别的DBA解决不了的问题。

10046 trace可以把SQL执行的黑匣子打开，让DBA知道一条SQL是如何执行的，调用了哪些递归调用，执行过程中扫描了哪些数据块，扫描效率如何，哪些地方产生了等待。另外还可以看到SQL的完整执行计划，了解SQL的执行计划是否出现了问题。

除此之外，在SQL解析的时候，有时候会选择错误的执行计划，因此我们需要去了解某种错误的执行计划是如何产生的，因此我们需要类似Oracle 10053 trace这样的分析能力。Oracle 10053可以让我们知道一条SQL的执行计划产生的细节，通过这些细节，我们可以发现数据库选择错误执行计划的原因，从而让我们找到解决此类问题的方法。

SQL TRACE的功能可以让我们从SQL实际执行情况和SQL产生执行计划的过程来了解数据库SQL执行的详细情况，从而帮我们定位问题。对于国产数据库来说，SQL及SQL优化是十分重要的工作，因此这个功能是国产数据库中急需的功能。目前有些国产数据库已经具有了此类TRACE的能力，比如MogDB中目前已经实现了类似Oracle 10046、10053 trace的功能。

除了SQL TRACE的功能之外，还有一个DBA十分需要的trace工具就是treedump。Treedump是用来DUMP索引的树信息的。与表不同，索引组织的数据结构经常会出现节点分裂，因此很容易出现碎片。当索引碎片严重的时候，索引扫描的性能会受到很大的影响。因此了解索引碎片的情况，从而制定重建计划对于DBA来说十分重要。十年前我曾经和一个银行的IT主管谈到过这个话题，后来他组织了一次核心账务系统的索引重建。重建后效果十分惊人，他们发现核心交易的延时都提高了15%左右。做索引treedump的命令如下：

ALTER SESSION SET EVENTS 'immediate trace name TREEDUMP level '。

我们可以在会话上直接DUMP某个索引的树结构，参数是需要dump的索引的OBJECT ID。今天早上我没时间做实验了，所以直接从网上找了一个数据展示给大家：

从tree dump里，我们可以看到枝节点和叶节点的信息，了解树的高度（level）,从而了解树的倾斜情况。如果Level过大了，那么肯定是存在问题的。一般情况下，索引树的高度顶多也就是3-4层，如果索引很小，层数很高，那么你就可以试试是否能通过rebulid来优化索引了。

除了上面的几个日常经常会用到的TRACE工具外，DBA经常还需要分析数据库中是否存在一些不合理的等待事件链。Hanganalyze是我在运维Oracle数据库的时候最经常使用的TRACE工具。当用户的数据库变慢，出现卡顿，锁死等情况的时候，我都会首先建议用户做一个3级的Hanganalyze，通过做几个Hanganalyze可以看出系统是否真正锁死，还是处于缓慢等待状态。主要的等待是什么，从而找到进一步分析问题的方法。

我贴的这张图已经比较老了，是十多年前的，现在的HANGANALYZE REPORT的可读性要好了很多。不过从老版本的报告中我们也很容易发现系统中出现的一场等待。

除了上面所说的几个TRACE工具外，会话DUMP，内存使用情况DUMP，数据块DUMP等也是运维人员十分常用的数据库诊断分析工具。实际上TRACE工具都是DBA遇到一些复杂问题的时候需要使用的工具。目前国产数据库在一些国产化替代的场景中已经是能用了，不过谈不上能让用户用得很好。要想让用户用得好，除了加强核心的稳定性与能力外，外围工具也十分重要。一个数据库产品想要在短时间内大幅提升核心的水平，难度很大，而把这些外围工具做好实际上是力所能及的。我也十分希望国产数据库厂商能在这些TRACE工具上面多下点工夫，让用户能够从国产数据库的黑盒子里获得一些有用的运维数据。