SQL Server 事件探查器對於協助 DBA 優化他們的 T-SQL 代碼而言是真正的不可多得的財富。但是，過度的富有（這讓我想起了《一千零一夜》中的阿拉丁）可能會令人不知所措。最近，在我首次嘗試弄懂客戶端服務器上按跟蹤收集的大量數據時，感到了一種“孤立無助”的感覺。在該特定客戶端上，聯機事務處理系統每小時執行的數據庫事務超過四百萬個。這意味著，實際上捕獲“SQL Batch Completed”事件的 30 分鐘跟蹤將生成長達兩百萬行的表格。當然，不利用一些自動化操作來處理這麼多的記錄是不可行的，即使選擇耗時最長或成本最高的事務也未必會有助於標識瓶頸。畢竟，每分鐘執行數千次耗時短的事務，可能會導致性能有所下降。[訂閱者可能希望重新閱讀 Linchi Shea 於 2002 年 06 月為其 Perl 代碼撰寫的文章“Distill SQL Server Log Files”。Linchi 的 PDF 和 Perl代碼均包含在本文的下載中 — 編者注。]
跟蹤清理規則
我的直覺告訴我使用聚合。但是，由於執行查詢中的輕微變化，不用多長時間我就發現按事務類型分組和聚合跟蹤文件並不湊效。每個存儲過程調用都具有不同的參數，並且查詢都是通過不同的搜索參數和稍許不同的 WHERE 子句條件來執行。某些事務包含注釋或在其他相同的代碼中具有不同數量的空格、制表符或換行符。某些查詢使用關鍵字的同義詞。
為了解決大型跟蹤分析的問題，我開發了一個跟蹤清理進程，以除去所有跟蹤記錄的不太重要的細節，並允許按事務類型進行分組。例如，如果我的跟蹤文件包含 50,000 條有關相同存儲過程執行的記錄（每條都帶有不同的參數），那麼，我的進程會按持續時間、CPU、讀取和寫入（所有的總計和平均數）對它們進行排列。這使我可以快速標識負責大部分整體系統利用的事務類型。
跟蹤清理的實現要求 1) 分析所有按跟蹤記錄的 T-SQL 語句，以及 2) 消除變量參數，如以下示例所示。假設此處所列的三個事務均是按跟蹤捕獲的。
1. Proc_A 123, 'alpha', 0x0a9fff8b 2. EXECUTE [Proc_A] -345, 'beta', null /*comment*/ 3. EXEC dbo.Proc_A 9876543, default -- test
雖然所有三個事務都執行存儲過程 Proc_A，但是執行、參數、換行符、制表符、空格以及注釋中的變化使它們看起來非常不同。我的清理算法會將它們聚合至一個事務類型存儲為“Proc_A%”的報告中。
例如，為了識別這數個事務是否執行同樣的存儲過程，或將 INSERT 插入帶有不同值的相同表格，該清理算法將執行以下操作：
•消除 EXEC 和 EXECUTE 關鍵字。
•將所有的換行符和制表符替換為空格。
•將多個空格視為一個整體。
•消除任何數字常量、十六進制的值、文字字符串以及 NULL 關鍵字。
