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

這兩天除了在網上查看電子資料外，“大厚本”也是必須去認真翻閱的資料。對于如此眾多的數據需要人工分析，我都有了一種寫個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工具上面多下點工夫，讓用戶能夠從國產數據庫的黑盒子里獲得一些有用的運維數據。