端午假期外加孩子高考正好這幾天出成績，因此幾天都沒有動筆了。這幾天確實很焦慮，心比較亂，所以也沒有心思寫東西。昨天廣東高考分數(shù)發(fā)布，一塊大石頭也落了地。孩子不是學霸型的，所以期望也沒有那么高，總的來說還算是正常發(fā)揮。接下來的志愿填寫工作量還是不小的，雖然提前研究了一些學校，到了要真正報考的時候，還是有大量的工作要做的。

這兩天除了在網(wǎng)上查看電子資料外，“大厚本”也是必須去認真翻閱的資料。對于如此眾多的數(shù)據(jù)需要人工分析，我都有了一種寫個PYTHON工具來分析這些數(shù)據(jù)的沖動。后來考慮到只有一個孩子，這幾天報考時間，等我寫出來黃花菜都涼了，就打消了這個念頭。不過我想如果有人把這些數(shù)據(jù)都收集起來，訓練一個大語言模型，用來對外提供咨詢服務，也許還真的能賺到錢。

還是回歸正題，前兩天在談數(shù)據(jù)庫可觀測性中的TRACE，可能有些朋友對TRACE關注不多，甚至對于TRACE和日志這兩種數(shù)據(jù)庫可觀測性能力也有點模糊。數(shù)據(jù)庫的TRACE很可能在日志中生成，而且TRACE也可能是在數(shù)據(jù)庫出現(xiàn)某種現(xiàn)象時產(chǎn)生的，但是TRACE和日志是數(shù)據(jù)庫可觀測性方面的兩個不同的領域。

數(shù)據(jù)庫日志是記錄數(shù)據(jù)庫的正常行為的，包括數(shù)據(jù)庫遇到BUG，遇到故障時，都是通過記錄日志的方式讓使用者了解情況。而TRACE往往是記錄一些特殊的信息，在數(shù)據(jù)庫正常運行時并不輸出這些信息，只有主動要求輸出日志，或者在分析某個問題或者調試某種應用時，才主動設置或者主動要求數(shù)據(jù)庫輸出這些信息。

從一個DBA的角度，我們需要數(shù)據(jù)庫擁有什么樣的TRACE能力呢？實際上Oracle數(shù)據(jù)庫為我們提供了一個十分好的樣板。這些年來，處理各種疑難雜癥的時候，我經(jīng)常會用到TRACE，因此在這方面也有些經(jīng)驗，今天我把這些經(jīng)驗總結一下，一方面也為DBA們提供一些分析Oracle數(shù)據(jù)庫的思路，另外一方面也給我們的國產(chǎn)數(shù)據(jù)庫提一些需求。

作為DBA，我們最需要的TRACE能力可能就是知道SQL語句是如何運行的，執(zhí)行計劃是如何產(chǎn)生的。如果我們遇到某條SQL，訪問的數(shù)據(jù)也沒啥變化，不過今天突然執(zhí)行變慢了，我們需要了解慢的原因。這時候我們就需要了解這條SQL的執(zhí)行的詳細情況了。Oracle數(shù)據(jù)庫的10046 trace是二十年前DBA擁有的核武器級別的TRACE工具，哪個DBA掌握了10046 trace，就能夠分析與解決一些別的DBA解決不了的問題。

10046 trace可以把SQL執(zhí)行的黑匣子打開，讓DBA知道一條SQL是如何執(zhí)行的，調用了哪些遞歸調用，執(zhí)行過程中掃描了哪些數(shù)據(jù)塊，掃描效率如何，哪些地方產(chǎn)生了等待。另外還可以看到SQL的完整執(zhí)行計劃，了解SQL的執(zhí)行計劃是否出現(xiàn)了問題。

除此之外，在SQL解析的時候，有時候會選擇錯誤的執(zhí)行計劃，因此我們需要去了解某種錯誤的執(zhí)行計劃是如何產(chǎn)生的，因此我們需要類似Oracle 10053 trace這樣的分析能力。Oracle 10053可以讓我們知道一條SQL的執(zhí)行計劃產(chǎn)生的細節(jié)，通過這些細節(jié)，我們可以發(fā)現(xiàn)數(shù)據(jù)庫選擇錯誤執(zhí)行計劃的原因，從而讓我們找到解決此類問題的方法。

SQL TRACE的功能可以讓我們從SQL實際執(zhí)行情況和SQL產(chǎn)生執(zhí)行計劃的過程來了解數(shù)據(jù)庫SQL執(zhí)行的詳細情況，從而幫我們定位問題。對于國產(chǎn)數(shù)據(jù)庫來說，SQL及SQL優(yōu)化是十分重要的工作，因此這個功能是國產(chǎn)數(shù)據(jù)庫中急需的功能。目前有些國產(chǎn)數(shù)據(jù)庫已經(jīng)具有了此類TRACE的能力，比如MogDB中目前已經(jīng)實現(xiàn)了類似Oracle 10046、10053 trace的功能。

除了SQL TRACE的功能之外，還有一個DBA十分需要的trace工具就是treedump。Treedump是用來DUMP索引的樹信息的。與表不同，索引組織的數(shù)據(jù)結構經(jīng)常會出現(xiàn)節(jié)點分裂，因此很容易出現(xiàn)碎片。當索引碎片嚴重的時候，索引掃描的性能會受到很大的影響。因此了解索引碎片的情況，從而制定重建計劃對于DBA來說十分重要。十年前我曾經(jīng)和一個銀行的IT主管談到過這個話題，后來他組織了一次核心賬務系統(tǒng)的索引重建。重建后效果十分驚人，他們發(fā)現(xiàn)核心交易的延時都提高了15%左右。做索引treedump的命令如下：

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

我們可以在會話上直接DUMP某個索引的樹結構，參數(shù)是需要dump的索引的OBJECT ID。今天早上我沒時間做實驗了，所以直接從網(wǎng)上找了一個數(shù)據(jù)展示給大家：

從tree dump里，我們可以看到枝節(jié)點和葉節(jié)點的信息，了解樹的高度（level）,從而了解樹的傾斜情況。如果Level過大了，那么肯定是存在問題的。一般情況下，索引樹的高度頂多也就是3-4層，如果索引很小，層數(shù)很高，那么你就可以試試是否能通過rebulid來優(yōu)化索引了。

除了上面的幾個日常經(jīng)常會用到的TRACE工具外，DBA經(jīng)常還需要分析數(shù)據(jù)庫中是否存在一些不合理的等待事件鏈。Hanganalyze是我在運維Oracle數(shù)據(jù)庫的時候最經(jīng)常使用的TRACE工具。當用戶的數(shù)據(jù)庫變慢，出現(xiàn)卡頓，鎖死等情況的時候，我都會首先建議用戶做一個3級的Hanganalyze，通過做幾個Hanganalyze可以看出系統(tǒng)是否真正鎖死，還是處于緩慢等待狀態(tài)。主要的等待是什么，從而找到進一步分析問題的方法。

我貼的這張圖已經(jīng)比較老了，是十多年前的，現(xiàn)在的HANGANALYZE REPORT的可讀性要好了很多。不過從老版本的報告中我們也很容易發(fā)現(xiàn)系統(tǒng)中出現(xiàn)的一場等待。

除了上面所說的幾個TRACE工具外，會話DUMP，內存使用情況DUMP，數(shù)據(jù)塊DUMP等也是運維人員十分常用的數(shù)據(jù)庫診斷分析工具。實際上TRACE工具都是DBA遇到一些復雜問題的時候需要使用的工具。目前國產(chǎn)數(shù)據(jù)庫在一些國產(chǎn)化替代的場景中已經(jīng)是能用了，不過談不上能讓用戶用得很好。要想讓用戶用得好，除了加強核心的穩(wěn)定性與能力外，外圍工具也十分重要。一個數(shù)據(jù)庫產(chǎn)品想要在短時間內大幅提升核心的水平，難度很大，而把這些外圍工具做好實際上是力所能及的。我也十分希望國產(chǎn)數(shù)據(jù)庫廠商能在這些TRACE工具上面多下點工夫，讓用戶能夠從國產(chǎn)數(shù)據(jù)庫的黑盒子里獲得一些有用的運維數(shù)據(jù)。