說到跟蹤，很多人會(huì)想起SQL Profiler。SQL Profiler僅僅是一個(gè)GUI，SQL Trace才是本質(zhì)。SQL Trace是構(gòu)建服務(wù)器跟蹤和Profiler的基礎(chǔ)。如果你了解到這點(diǎn)，那你就會(huì)毫不猶豫的在生產(chǎn)環(huán)境使用服務(wù)器跟蹤。下面分別從跟蹤的代價(jià)、跟蹤架構(gòu)、反跟蹤和跟蹤原則等方面來介紹SQL Trace，并通過一個(gè)實(shí)例使這些介紹更加的通俗易懂。

 一、SQL Trace跟蹤的代價(jià)

必須指出，跟蹤會(huì)影響系統(tǒng)的性能這是不可完全避免的。當(dāng)然可以通過一些方式我們能將這種代價(jià)降到最小。很多人往往以跟蹤會(huì)影響現(xiàn)網(wǎng)性能為理由而拒絕跟蹤。其實(shí)這是不對的，還有一些人平時(shí)也做跟蹤，不過他們喜歡在系統(tǒng)不繁忙的時(shí)候跟蹤。這樣的做法都是有問題的。前者往往會(huì)出現(xiàn)突然間你的系統(tǒng)出現(xiàn)問題，而你完全沒有任何預(yù)兆，后者往往會(huì)出現(xiàn)你錯(cuò)過捕獲問題的***時(shí)機(jī)這樣在不繁忙時(shí)的跟蹤等于白費(fèi)。 那什么時(shí)候?qū)ιa(chǎn)環(huán)境進(jìn)行跟蹤呢？正確的做法應(yīng)該是每時(shí)每刻的收集系統(tǒng)信息，為對系統(tǒng)性能整體分析提供信息來源。

二、SQL Trace架構(gòu)

如果你想理解SQL Trace，那***的方式莫過于用你自己的系統(tǒng)去對比。一般情況下我們都會(huì)在系統(tǒng)中記錄一些日志，根據(jù)我們關(guān)注的點(diǎn)來區(qū)分記錄日志的級別。典型的日志組件就是Log4net之類的日志組件。這樣我們就能夠通過日志來分析系統(tǒng)的運(yùn)行情況。知道這點(diǎn)，那理解SQL Trace就容易了。在SQLServer中，跟蹤信息由一系列的事件組成。既然有事件，那誰觸發(fā)事件呢。數(shù)據(jù)庫引擎中的各個(gè)組件都是事件的生產(chǎn)者。下面看看SQL Trace的架構(gòu)圖：

如上圖所示：整個(gè)SQL  Trace架構(gòu)有三個(gè)部分組成，數(shù)據(jù)庫引擎、跟蹤控制器、跟蹤會(huì)話。數(shù)據(jù)庫引擎是事件生成者，跟蹤控制器負(fù)責(zé)事件的分發(fā)以及事件的過濾，跟蹤會(huì)話負(fù)責(zé)對事件的列過濾以及跟蹤事件的終點(diǎn)。下面簡單描述下整個(gè)過程，跟蹤控制器通過一個(gè)位圖讓數(shù)據(jù)庫引擎的其他組件知道跟蹤器請求了哪些事件，這個(gè)位圖是所有跟蹤的事件集合。一旦數(shù)據(jù)庫引擎生成一個(gè)事件后，就把事件信息保存在跟蹤控制器中的隊(duì)列中。然后跟蹤控制器把完整的事件信息傳遞給每個(gè)要求這個(gè)事件的跟蹤會(huì)話。跟蹤會(huì)話接收到自己關(guān)注的事件信息時(shí)，先經(jīng)過過濾器（主要是過濾掉不感興趣的列與行），過濾掉后發(fā)送給跟蹤的I/O提供者。這里面的隊(duì)列只是起緩沖作用。I/O提供者有很多種，比如Profiler、服務(wù)器跟蹤、SQLServer自己的跟蹤。

三、具體跟蹤例子

這里的例子不想用SQL Profiler進(jìn)行舉例，因?yàn)槲矣X得它僅僅是方便我們跟蹤而已。但是它在跟蹤時(shí)既會(huì)把輸出寫入目標(biāo)文件或者表（然后選擇保存文件中保存表）還有把跟蹤信息寫入運(yùn)行Profiler的客戶端。把跟蹤信息寫入到運(yùn)行Profiler客戶端，這個(gè)比直接寫入文件往往會(huì)慢。大家可以想想為什么？不過倒是可以用Profiler圖形化方式定義跟蹤，然后導(dǎo)出生成的跟蹤SQL。具體如下：

 一旦你開啟了跟蹤后，你可以通過：

select * from sys.traces 查看到你正在跟蹤的會(huì)話。

#p#

四、如何反跟蹤

有時(shí)候，我們不希望自己的sql被人跟蹤。比如，我們不希望別人能看到我們程序中寫的sql。方法有很多，這里介紹一種簡單的方法。思路就是：強(qiáng)迫SQLServer停止跟蹤。具體存儲過程如下：

名稱：[DBO].[Performance_Trace_StopAll]

功能：防止反跟蹤

作者：junling

創(chuàng)建時(shí)間：2011-02-09

項(xiàng)目名稱：XXXX

歷史記錄：

編號    日期        作者    備注

1.0    2011-02-09    junling    創(chuàng)建

代碼的執(zhí)行過程如下：

create  proc [dbo].[Performance_Trace_StopAll]  
 
AS  
 
declare traceCursor cursor for select id from sys.traces where id <> 1  
 
open traceCursor  
 
declare @curid int  
 
fetch next from traceCursor into @curid  
 
while(@@fetch_status=0)  
 
begin           
 
exec  sp_trace_setstatus @curid,0  
 
exec  sp_trace_setstatus @curid,2  
 
fetch next from traceCursor into @curid  
 
end  
 
close traceCursor  
 
deallocate traceCursor 

具體什么時(shí)候調(diào)用，就是看你具體的情況了。

五、SQL Trace跟蹤原則

這里主要列出我們在跟蹤時(shí)應(yīng)該注意的事項(xiàng)，或者說按照下面的原則會(huì)降低跟蹤對生產(chǎn)環(huán)境的影響。

1、不要使用Profiler GUI跟蹤，如果使用了盡量不要運(yùn)行在跟蹤的SQLServer所在服務(wù)器；

2、不要把跟蹤數(shù)據(jù)直接寫入表，我們可以采用系統(tǒng)不是很繁忙時(shí)才把跟蹤信息導(dǎo)入表中（除非你想立刻分析數(shù)據(jù)）；

3、跟蹤會(huì)有大量的I/O操作，盡量把跟蹤文件單獨(dú)放在物理磁盤中；

4、只選擇自己感興趣的事件，多選一個(gè)事件都會(huì)帶來開銷（除非你多選的事件不發(fā)生，那樣也就沒有選擇的必要；

5、過濾你的跟蹤信息，比如你只對某數(shù)據(jù)庫感興趣，你只對某些列感興趣（注意這里僅僅是減少了架構(gòu)圖中的I/O提供者的開銷，想想為什么）；

6、像XXXXXXStarting之類的事件往往沒有太大意義；

7、要注意你跟蹤的sql中是否使用了標(biāo)量函數(shù)，對這些sql的跟蹤會(huì)嚴(yán)重影響性能，每個(gè)標(biāo)量函數(shù)每處理一行都會(huì)觸發(fā)事件（如果表很大，這是件很恐怖的事件)；

8、只給需要跟蹤的用戶指定跟蹤權(quán)限。

本文就介紹到這里，希望會(huì)對讀者有所幫助，謝謝大家！

【編輯推薦】

1. 如何將系統(tǒng)監(jiān)視器數(shù)據(jù)記錄到SQL Server
2. 用FOR XML PATH將查詢結(jié)果以XML輸出
3. 淺述SQL Server的Replication技術(shù)創(chuàng)建技巧
4. 淺析SQL Server數(shù)據(jù)修復(fù)命令DBCC的使用
5. 如何在SQL Server 2005中使用作業(yè)實(shí)現(xiàn)備份和特定刪除