以Oracle为例聊聊DBA须要的罕用数据库TRACE

端午假期外加孩子高考正好这几天出效果，因此几天都没有动笔了。这几天确实很焦虑，心比拟乱，所以也没有心理写物品。昨天广东高考分数颁布，一块大石头也落了地。孩子不是学霸型的，所以希冀也没有那么高，总的来说还算是反常施展。接上去的志愿填写上班量还是不小的，只管提早钻研了一些学校，到了要真正报考的时刻，还是有少量的上班要做的。

这两天除了在网上检查电子资料外，“大厚本”也是必需去仔细翻阅的资料。关于如此泛滥的数据须要人工剖析，我都有了一种写个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工具上方多下点工夫，让用户能够从国产数据库的黑盒子里取得一些有用的运维数据。