SQL 跟蹤（SQL Trace）介紹

SQL 跟蹤（SQL Trace）介紹

SQL 跟蹤是一個SQL Server資料庫引擎工具，而用戶端性能分析器工具隻不過是伺服器端功能的包裝。當執行跟蹤時，會監視特定的事件，這些事件是資料庫引擎中的各類動作發生時被引發的。例如，一個使用者登入或一個查詢的執行都會觸發事件。每個事件都有一個列的關聯集合，這些關聯集合是包含事件觸發時收集的資料的各類屬性。例如，就一個查詢而言，可以收集的資料有該查詢開始的時間、持續的時間及使用CPU的時間。最後，每個跟蹤都可以規定各自的篩選程式，這樣就可以根據一組規則來限定傳回結果。例如，一個跟蹤可以規定隻有超過50毫秒的事件才應該被傳回。

由于是從大量事件及列中進行選擇，是以能夠收集到的資料點的數量很大，并不是每一列都适用于每個事件。考慮保留這些資料時的記憶體使用情況，以及建立這些資料時所需的處理器時間，SQL Server在生成許多資訊的同時，還能保證高效運作。除非使用者有要求，SQL Server實際上根本不收集任何資料，即這種模式就是選擇性地隻在需要時進行收集。

注意：

後續版本的 Microsoft SQL Server 将删除該功能。請避免在新的開發工作中使用該功能，并着手修改目前還在使用該功能的應用程式。 請改用擴充事件。

SQL 跟蹤（SQL Trace）的優點

Microsoft SQL Server 提供 Transact-SQL 系統存儲過程來建立對 SQL Server 資料庫引擎執行個體的跟蹤。 可以不使用 SQL Server Profiler，而使用這些系統存儲過程從您自己的應用程式中手動建立跟蹤。 這樣，您就可以針對企業的特定需求編寫自定義應用程式。

SQL 跟蹤（SQL Trace）體系結構

事件源可以是生成跟蹤事件（例如 Transact-SQL 批處理）或 SQL Server 事件（例如死鎖）的任何源。有關事件的詳細資訊，請參閱MSDN中有關 SQL Server 事件類的參考。事件發生後，如果該事件類已經包含在跟蹤定義中，則跟蹤将收集該事件資訊。如果已經在跟蹤定義中為該事件類定義篩選器，則将應用這些篩選器并将跟蹤事件資訊傳遞到隊列。從隊列中，跟蹤資訊或者被寫入檔案，或者由應用程式（例如 SQL Server Profiler）中的 SMO 使用。

以下關系圖顯示了在跟蹤期間 SQL 跟蹤如何收集事件。

下面結合上圖，對關鍵的元件和過程進行描述。

内部跟蹤元件

SQL跟蹤體系結構中的中心元件是跟蹤控制器，這是一種共享資源，用于管理使用者建立的所有跟蹤。各種事件發生器遍布整個資料庫引擎，例如，查詢處理器、鎖管理器和高速緩存管理器中都存在。這些發生器負責産生與伺服器活動的某些目錄相關的事件，但是每個發生器都預設設定為不可用，是以就不會産生任何資料。當一個使用者要求開始跟蹤某個事件時，跟蹤控制器中的一個全局位圖就被更新，并告知事件發生器至少有一個跟蹤在監聽，進而使事件開始運作。與該位圖一起管理的是一個次級清單，該次級清單記錄了哪些跟蹤正在監視着哪些事件。

如果一個事件開始運作，它的資料就被發送至一個全局事件接收器，全局事件接收器對各種事件資料進行排隊，以配置設定給每個正在監聽的跟蹤。這個跟蹤控制器根據内部跟蹤清單和監控事件清單，将資料傳遞至每個監聽的跟蹤。除了跟蹤控制器的清單外，每個單獨的跟蹤都保留監視事件的軌迹，以及正被實際使用的列和适當的過濾程式。跟蹤控制器傳回至每個跟蹤的事件資料都經過過濾，而在資料被發送至一個I/O提供者之前，資料列也會根據需要而被裁剪。

跟蹤I/O提供者

跟蹤I/O提供者是實際發送資料至其最終目的地的工具。跟蹤資料的可用輸出格式有兩種，一種是資料庫伺服器（或網絡共享）中的一個檔案，另一種是客戶的一個行集。這兩種提供者都是同内部緩沖區來確定當資料不能被盡快消耗時（即寫入磁盤或從行集讀取時）可以被加入到隊列之中。然而，它們在隊列增長到超過可控制大小時的處理方法卻有很大差別。

檔案提供者在設計上的一個重要保證就是不能遺漏任何事件資料。為了使它在發生I/O降速甚至停止工作時既然能運作，内部緩沖區在無法及時寫磁盤時就開始逐漸填充資料。一旦緩沖區被填滿，傳輸事件資料至跟蹤的線程就開始等待緩沖區被清空。為了避免線程等待跟蹤緩沖區，就必須保證有足夠快的磁盤系統來完成跟蹤。要想監視這些等待，就要了解SQLTRACE_LOCK和IO_COMPLETION等待類型。

另一方面，行集提供者在設計上不能保證不丢失任何資料。如果資料沒有被及時消耗并且内部緩沖區已經填滿，它就會先等待20秒，然後再抛棄事件以清空緩沖區使事件繼續進行。如果事件被丢棄，SQL Server性能分析器客戶工具就會發送一個特殊的錯誤資訊，使用者也可以通過監視SQL Server的跟蹤寫等待類型來檢視自己是否出現這種情況，當線程等待緩沖區清空時SQL Server的跟蹤寫等待也會增加。

無論何時，隻要伺服器上至少有一個跟蹤處于活躍狀态，背景跟蹤管理線程就會運作。除了關閉被視為到期的（如果一個跟蹤已經丢失一個事件超過10分鐘，這種情況就會發生）基于行集的跟蹤之外，這個背景線程還負責重新整理檔案提供者緩沖區（每4秒鐘執行一次）。比起每次收集完一個事件就往磁盤中寫資料，SQL Server更傾向于隻是偶爾重新整理一次檔案提供者緩沖區。這樣，SQL Server就能利用大塊的寫操作，極大降低跟蹤（求其是特别活躍的伺服器上的跟蹤）的開銷。

SQL Server的新資料庫管理者經常會遇到一個問題，為什麼沒有能直接将跟蹤資料寫入一個表中的提供者。之是以會有這個局限，是考慮到所需要的開銷。由于一個表并不支援大塊的寫操作，是以SQL Server就不得不一行一行地寫入事件資料。事件消費所緻的性能下降将引發兩種後果：一種是丢棄大量事件；另一種是強制執行無損保證時引發大量的阻塞。由于這兩種方案都不合适，是以SQL Server幾乎不提供這個功能。無論是在跟蹤期間還是在跟蹤之後，将資料載入表裡都很簡單，是以，這也就算不上是一個局限了。

安全和權限

跟蹤不僅可以顯示大量關于伺服器狀态的資訊，而且還能顯示使用者發送到資料庫引擎及資料庫引擎傳回的資料資訊。監視範圍從單獨的查詢到批處理甚至查詢計劃級别，這種監視能力很強，但同時一會對存儲過程中的輸入參數進行曝光，因而會為攻擊者提供大量有關資料庫中的資料資訊。為了保護SQL跟蹤不被他人看到，之前版本的SQL Server隻允許管理使用者（系統管理者确定的伺服器負責任的成員）通路來啟動跟蹤。對許多開發團隊來說，這是個限制，是以後來就被放寬了。

修改跟蹤（ALTER TRACE）權限

修改跟蹤權限，是一個伺服器級别的權限（授權給一個登入），除了能夠引發使用者自定義事件之外，還允許通路來啟動、停止或修改一個跟蹤。

這個權限是在伺服器級别上授權的，它的通路也是伺服器級别的；如果一個使用者可以啟動一個跟蹤，那麼無論事件在哪個資料庫上引發，都能檢索事件資料。對于開發者可能在産品系統上運作跟蹤以調試應用程式，在SQL Server中加入了該權限，但不能輕易地授予該權限，即使這并不能給他人全部的系統管理者通路權限，但它仍是一個潛在的安全威脅。

要想給一個登入授予修改跟蹤的權限，可以使用下面的GRANT語句：

GRANT ALTER TRACE TO JANE;

保護敏感事務資料

除了加鎖便于允許某些特定使用者使用SQL跟蹤之外，跟蹤引擎自身還有一對内置的安全特性去避開多餘的對私有資訊的的監視--包括那些可以通過通路跟蹤的多餘監視。如果一個事件包含了一個對密碼相關的存儲過程或語句的調用，SQL跟蹤就會自動忽略這些資料。例如，包含WITH PASSWORD選項的CREATE LOGIN的調用會被SQL跟蹤取消。

SQL跟蹤的另一個安全特性是加密子產品的使用。在一個加密的存儲過程、使用者自定義函數或視圖中，SQL跟蹤不會傳回生成的語句文本或查詢計劃。再者，也可以有助于保護特别敏感的資料不被那些原本可以檢視跟蹤的使用者看到。