一、SQL Trace跟蹤的代價(jià)
必須指出,跟蹤會(huì)影響系統(tǒng)的性能這是不可完全避免的。當(dāng)然可以通過(guò)一些方式我們能將這種代價(jià)降到最小。很多人往往以跟蹤會(huì)影響現(xiàn)網(wǎng)性能為理由而拒絕跟蹤。其實(shí)這是不對(duì)的,還有一些人平時(shí)也做跟蹤,不過(guò)他們喜歡在系統(tǒng)不繁忙的時(shí)候跟蹤。這樣的做法都是有問(wèn)題的。前者往往會(huì)出現(xiàn)突然間你的系統(tǒng)出現(xiàn)問(wèn)題,而你完全沒(méi)有任何預(yù)兆,后者往往會(huì)出現(xiàn)你錯(cuò)過(guò)捕獲問(wèn)題的最佳時(shí)機(jī)這樣在不繁忙時(shí)的跟蹤等于白費(fèi)。 那什么時(shí)候?qū)ιa(chǎn)環(huán)境進(jìn)行跟蹤呢?正確的做法應(yīng)該是每時(shí)每刻的收集系統(tǒng)信息,為對(duì)系統(tǒng)性能整體分析提供信息來(lái)源。
二、SQL Trace架構(gòu)
如果你想理解SQL Trace,那最好的方式莫過(guò)于用你自己的系統(tǒng)去對(duì)比。一般情況下我們都會(huì)在系統(tǒng)中記錄一些日志,根據(jù)我們關(guān)注的點(diǎn)來(lái)區(qū)分記錄日志的級(jí)別。典型的日志組件就是
如上圖所示:整個(gè)SQL Trace架構(gòu)有三個(gè)部分組成,數(shù)據(jù)庫(kù)引擎、跟蹤控制器、跟蹤會(huì)話。數(shù)據(jù)庫(kù)引擎是事件生成者,跟蹤控制器負(fù)責(zé)事件的分發(fā)以及事件的過(guò)濾,跟蹤會(huì)話負(fù)責(zé)對(duì)事件的列過(guò)濾以及跟蹤事件的終點(diǎn)。下面簡(jiǎn)單描述下整個(gè)過(guò)程,跟蹤控制器通過(guò)一個(gè)位圖讓數(shù)據(jù)庫(kù)引擎的其他組件知道跟蹤器請(qǐng)求了哪些事件,這個(gè)位圖是所有跟蹤的事件集合。一旦數(shù)據(jù)庫(kù)引擎生成一個(gè)事件后,就把事件信息保存在跟蹤控制器中的隊(duì)列中。然后跟蹤控制器把完整的事件信息傳遞給每個(gè)要求這個(gè)事件的跟蹤會(huì)話。跟蹤會(huì)話接收到自己關(guān)注的事件信息時(shí),先經(jīng)過(guò)過(guò)濾器(主要是過(guò)濾掉不感興趣的列與行),過(guò)濾掉后發(fā)送給跟蹤的I/O提供者。這里面的隊(duì)列只是起緩沖作用。I/O提供者有很多種,比如Profiler、服務(wù)器跟蹤、SQLServer自己的跟蹤。
三、具體跟蹤例子
這里的例子不想用SQL Profiler進(jìn)行舉例,因?yàn)槲矣X(jué)得它僅僅是方便我們跟蹤而已。但是它在跟蹤時(shí)既會(huì)把輸出寫入目標(biāo)文件或者表(然后選擇保存文件中保存表)還有把跟蹤信息寫入運(yùn)行Profiler的客戶端。把跟蹤信息寫入到運(yùn)行Profiler客戶端,這個(gè)比直接寫入文件往往會(huì)慢。大家可以想想為什么?不過(guò)倒是可以用Profiler圖形化方式定義跟蹤,然后導(dǎo)出生成的跟蹤SQL。具體如下:
一旦你開(kāi)啟了跟蹤后,你可以通過(guò):
四、如何反跟蹤
有時(shí)候,我們不希望自己的sql被人跟蹤。比如,我們不希望別人能看到我們程序中寫的sql。方法有很多,這里介紹一種簡(jiǎn)單的方法。思路就是:強(qiáng)迫SQLServer停止跟蹤。具體存儲(chǔ)過(guò)程如下:
exec sp_trace_setstatus @curid,0
具體什么時(shí)候調(diào)用,就是看你具體的情況了。
五、SQL Trace跟蹤原則
這里主要列出我們?cè)诟檿r(shí)應(yīng)該注意的事項(xiàng),或者說(shuō)按照下面的原則會(huì)降低跟蹤對(duì)生產(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ì)帶來(lái)開(kāi)銷(除非你多選的事件不發(fā)生,那樣也就沒(méi)有選擇的必要;
5、過(guò)濾你的跟蹤信息,比如你只對(duì)某數(shù)據(jù)庫(kù)感興趣,你只對(duì)某些列感興趣(注意這里僅僅是減少了架構(gòu)圖中的I/O提供者的開(kāi)銷,想想為什么);
6、像XXXXXXStarting之類的事件往往沒(méi)有太大意義;
7、要注意你跟蹤的sql中是否使用了標(biāo)量函數(shù),對(duì)這些sql的跟蹤會(huì)嚴(yán)重影響性能,每個(gè)標(biāo)量函數(shù)每處理一行都會(huì)觸發(fā)事件(如果表很大,這是件很恐怖的事件);
8、只給需要跟蹤的用戶指定跟蹤權(quán)限。
六、結(jié)尾
今天主要和大家討論了SQLServer的跟蹤方面的知識(shí),其中的知識(shí)還有很多值得我們?nèi)ネ诰?,比如事件的分類、SQL Trace目錄視圖的每個(gè)列的意義、如何把trc格式文件導(dǎo)入表中分析統(tǒng)計(jì)、跟蹤的安全性問(wèn)題、跟蹤的性能優(yōu)化等等。 在這些方面多花點(diǎn)時(shí)間,你會(huì)到SQLServer有更好的理解的。
今天分析就到此結(jié)束,文中如有描述不當(dāng)?shù)牡胤?,歡迎指出。共同進(jìn)步才是硬道理。
聯(lián)系客服