使用ttTraceMon進行TimesTen故障分析

1.   TraceMon介紹

TraceMon工具是TimesTen提供的一個底層的Debug工具，可以透過TraceMon跟蹤TimesTen的內部Trace詳細資訊，類似於Oracle的SYSDUMP；對於TimesTen來說，由於其執行在記憶體中的特點，不能像Oracle那樣有詳細的記錄資訊，所有的資訊都是瞬間值，對於能重現的故障或者效能問題，使用TraceMon跟蹤分析，可以說是不二的選擇了。更多介紹可以參考官方文件《TimesTen Troubleshooting Guide》或者Oracle技術論壇。

2.   使用注意事項

   TraceMon是TimesTen提供的一個底層的Debug工具，既然是底層工具，那麼使用自然會存在一定的風險。

   TraceMon最主要的風險在於對效能的消耗，特別是CPU的消耗最為嚴重，所以使用時需要非常小心，不建議對生產系統進行全庫的Trace，全庫Trace不單對效能消耗過大，日誌量也非常太大，不便於問題的分析和定位；在生產系統中使用建議請求Oracle的技術支援。

3.   TraceMon功能介紹

TraceMon支援對大部分元件的跟蹤，具體的元件如下：

其中對SQL/API/LOCK/ERR/AGING/AUTOREFRESH提供相應的使用文件說明。

1)   SQL元件

SQL元件分為2、3、4、5四個等級：

Level 2:輸出為SQL命令的編譯（Preparing）過程。

Level 3:在Level 2的基礎上加上SQL命令執行(Executing)。

Level 4:在Level 3的基礎上加上命令共享池的相關編譯資訊(prepares not being done because the prepared command already exists in the pool)，或者是SQL命令不在共享池內的重新編譯。Level 4 ttTraceMon 同時會輸出opening、fetching和closing.

Level 4:在Level 4的基礎上，同時輸出一些內部資訊，比如命令編號。

2)   lock元件

   Lock元件用於跟蹤應用鎖行為，為觀察死鎖或鎖等待；鎖跟蹤的資訊會產生大量正常鎖的資訊，這可能會使得跟蹤的資訊閱讀起來比較困難。lock元件分為1、2、3、4、6五個等級：

Level 1：輸出Trace期間監控到的死鎖。

Level 2：在Level 1的基礎上加上分配鎖失敗的原因。

Level 3：在Level 2的基礎上加上鎖等待(鎖分配或者未分配)。

Level 4：在Level 3的基礎上加上所有鎖的分配和釋放，鎖呼叫及死鎖檢測器的機制。

Level 6：在Level 4的基礎上加上迴圈遍歷。

3)   API元件

API元件是用於跟蹤一些連線到Data Store、連線屬性變更及事務提交等，API分為1、2、3、4四個等級。

Level 1:所有回滾的事務，有subdaemon恢復異常中斷的應用程式連線。

Level 2:在Level 1的基礎上加上一些低空間條件。

Level 3：在Level 2的基礎上加上操作Data Store的建立、建立連線、斷開連線、checkpoint、backup和空間緊湊；提交或回滾的連線以及一些其他的操作。

    Level 4：在Level 3的基礎上加上其他操作進行TimesTen的內部API級別。它不顯示大量的儲存管理器和索引操作內部完成。

4)   Err元件

    顯示所有直接驅動錯誤資訊，Err元件預設等級為Level 1，這個等級只會輸出一些致命的錯誤資訊。

    Level 1:所有異常引起的錯誤資訊，比如事務超時；Level 2會輸出很多由TimesTen內部處理的錯誤資訊。

5)   AGING元件

AGING元件主要用於跟蹤AGING的開始和結束，AGING期間多少資料被subdaemon刪除。AGING分為1、2、3、4四個等級。

     Level 1:subdaemon啟動最近一次AGING的LRU演算法或time-based演算法；沒有達到閥值時，重複的執行LRU演算法老化；subdaemon停止LRU演算法或time-based演算法。

    Level 2:在Level 1的基礎上加上Aging開始和結束，結束的原因資訊和共刪除的記錄數。

Level 3:在Level 2的基礎上加上每個Aging週期刪除的資料量的詳細資訊。

Level 4:在Level 3的基礎上加上加上aging 每次被subdaemon喚醒的資訊。

6)   Autorefresh元件

   Autorefresh元件用於獲取Cache Group重新整理程式相關操作資訊。Autorefresh分為1、2、3、4四個等級。

Level 1: 自動重新整理間隔彙總，啟動自動重新整理時間；每個間隔重新整理的記錄數；每個重新整理間隔根表重新整理的記錄數；從上次Cache Agent程式啟動至今共重新整理的記錄數；從上次Cache Agent程式啟動至今根表重新整理的記錄數；

 Level 2:在Level 1的基礎上加上每個Cache Group啟動的時間；每個Cache Group重新整理的記錄數；每個Cache Group根表重新整理的記錄數；從上次Cache Agent啟動至今每個Cache Group重新整理的總記錄數；從上次Cache Agent啟動至今每個Cache Group根表重新整理的總記錄數；每個Cache Group重新整理結束時間。

   Level 3:在Level 2的基礎上加上Cache Group重新整理啟動時間，重新整理記錄數；從Cache Agent啟動重新整理記錄數；Cache Group重新整理結束時間。

   Level 4:在Level 3的基礎上加上每個表的重新整理詳細資訊；每個表的自動重新整理啟動時間；自動重新整理的查詢語句；查詢語句在Oracle端執行的時間（單位為milliseconds），包括子表；查詢fetch在Oracle端執行的時間（單位為milliseconds），包括子表；查詢結果在TimesTen的端應用的時間（單位為milliseconds），包括子表；自動重新整理結束時間；自動重新整理到哪個bookmark (logseq) 已經完成。

4.   使用方法

    TraceMon的使用方法很簡單，只需根據需求按照如下方法開啟Trace跟蹤，跟蹤完成後關閉即可；這裡比較複雜的是如何判斷跟蹤的型別及跟蹤的級別，這個需要結合應用故障型別及相關經驗綜合考慮，建議請求Oracle的官方支援。

以上的例子根據connection id進行跟蹤，如果不執行connection all off操作即是全庫跟蹤。

5.   日誌分析

    擷取Trace的輸出日誌如下：

 

日誌輸出可以分為7列：

第一列為時間串: 22:13:34.805

第二列為序列: 269

第三列為元件型別: SQL

第四列為抓取的等級，也就是該日誌屬於哪個級別: 2L

第五列為Connection Id號: 3C

第六列為程式號: ProcessId

第七列為操作(Operation): Preparing: SELECT BILL_SEQ FROM RTA_ONLINE_BILL WHERE USER_ID = :1_acctid AND BILL_MONTH = :2_billmonth ;

 

附：相關TraceMon故障分析的例子可以參考之前編寫的《使用TraceMon分析TimesTen應用超時問題》
Tony.Tang[湯雲]2015.02.02

－－－－－－－－－－－－－－－－End－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－－