善用 Read80trace 與自訂預存程序，深度剖析 SQL Server Profiler 追蹤檔

前言

當 SQL Server 資料庫系統效能下降時，DBA 往往會想到使用 SQL Server Profiler（SQL 事件探查器）進行追蹤分析。Profiler 確實能捕獲所有送往 SQL Server 的陳述式，以及執行效能相關資料（如讀寫頁數、CPU 使用量、Duration 等）。然而，面對龐大的追蹤檔，傳統分析方法往往力不從心。本文將介紹如何結合 Read80trace 工具與自訂預存程序，從海量 Trace 檔中快速提煉關鍵效能報表，實現「高屋建瓴」的資料庫優化策略。

傳統 Trace 分析方法的困境

資料庫系統的「存取模式」

除了排查死結、阻塞、逾時等問題，Trace 檔最核心的價值在於揭示三大關鍵資訊：

1. 執行頻率最高的陳述式
2. 對系統效能影響最大的關鍵陳述式
3. 各類陳述式群組佔比及相關效能統計

這三大資訊構成了資料庫系統的「存取模式」。在足夠長的採樣時間（建議 2 小時以上）下，這些模式相當穩定。掌握存取模式，優化時便能胸有成竹。

傳統方法的兩大侷限

• 檔案過大難以全局把控： 大型系統下，僅捕獲基本事件，2 小時 Trace 檔即可能達 GB 級。使用 Profiler 內建篩選或匯入資料庫用 T-SQL 分析，極易陷入細節而失去全局視野，錯誤鎖定非關鍵陳述式。
• 無法自動歸類相似陳述式： 大量陳述式僅參數不同，邏輯卻相同。傳統方法缺乏將其歸類統計的機制，導致無法快速識別真正的效能瓶頸模式。

Read80trace：破局利器

工具簡介

Read80trace 是 Microsoft RML Utilities 包含的命令列工具。其核心價值在於 Normalization（標準化/歸一化） 功能：將邏輯相同、參數不同的陳述式自動歸類，並匯入資料庫生成 HTML 效能分析報表。此外，它還能生成 RML 檔供 OSTRESS 多執行緒重放，便於在測試環境複現生產負載。

標準化功能實例

假設 Trace 中包含：

SELECT * FROM authors WHERE au_lname = 'white'
SELECT * FROM authors WHERE au_lname = 'green'
SELECT * FROM authors WHERE au_lname = 'brown'

標準化後將歸類為單一模式：

SELECT * FROM authors WHERE au_lname = @p1

並統計該模式的總執行次數、總 CPU、總 Duration、總 Reads/Writes 等聚合指標，瞬間揭示「高頻且高耗」的核心模式。

進階分析流程：Read80trace + 自訂預存程序

1. 匯入與標準化： 執行 read80trace -I trace.trc -d PerfAnalysisDB -o output.rml，將 Trace 匯入資料庫並生成標準化資料表。
2. 自訂聚合統計： 撰寫預存程序，依「標準化陳述式」分組，計算：
   • 總執行次數
   • 總/平均 CPU、Duration、Reads、Writes
   • 佔總資源比例（CPU%、Duration%、IO%）
   • 執行計畫特徵（是否 Table Scan、Key Lookup 等）
3. 多維度報表輸出： 產出 HTML/Excel 報表，支援按「資源消耗總量」「平均耗資源」「執行頻率」等維度排序，快速鎖定 Top N 待優化模式。

實戰效益

• 分析時間從數小時縮減至數分鐘
• 自動識別「隱形殺手」： 單次耗資源不高、但極高頻執行累積佔用大量資源的模式
• 優化決策有據可依： 明確知道哪類陳述式佔用 80% 資源，優先優化這 20% 的模式

結語

Read80trace 的標準化功能打破了傳統分析「見樹不見林」的瓶頸。配合自訂預存程序的彈性統計，DBA 可在海量 Trace 中快速建立系統存取模式全景圖，實現精準、高效的 SQL Server 效能優化。