SQLSERVER Profiler進行性能調優時經常用到的事件
SQLSERVER的一大優點，是能夠把SQL里發生的很多事件記錄下來，而記錄下的日志通常被稱為SQL Trace文件。
在SQL安裝的管理工具里，有一個叫SQLSERVER Profiler的工具，可以用他來搜集和分析SQL Trace文件。
這個工具比較直觀很多時候都要靠這個工具發揮他的威力呢o(∩_∩)o
開始介紹
開始介紹SQL Trace 開始菜單-》性能工具-》數據庫引擎優化顧問的下面
或者在SSMS里打開
SQL Trace文件的收集方法
首先，SQL Trace里能夠有哪些事件呢？在Profiler里新建一個Trace，在在事件選擇里選擇“顯示所有事件”，就能看到一個清單
里面的事件分類，在SQL2005這個版本的時候已經有21個之多，而每個分類下又有不同數目的事件。
可以說，DBA想要看到的事件，基本上都能覆蓋。
可是事件太多，如果所有的事件都收集，產生的SQL Trace會非常龐大，SQLSERVER就受不了。
這里總結一下，在做不同的問題分析時，經常要用到的事件
Database事件組
當DBA要監視數據文件和日志文件的自動增長與自動收縮的時候，可以選擇收集
Database事件組下面的這些事件，不過如果只是關心文件大小是什么時候變化的，
可以定期運行TSQL腳本，或者使用性能監視器。如果要分析是什么操作觸發了文件
大小變化，可以使用SQL Trace
Errors and Warnings事件組
這些事件會搜集在SQL里發生的所有錯誤和警告信息。如果SQL運行不正常，很
可能這些事件會有反映。所以建議每次收集時，都把還這個事件組的事件全都選上
這個事件組也能從一個角度反映性能問題。例如，attention事件記錄了每一個客戶端
取消的請求。運行超時command timeout就是其中一個類型。如果你發現
一個語句運行了15秒或30秒，然后緊跟着一個attention事件，就說明這里發生了
一個客戶端的command timeout。而hash warning，missing column statistics，
missing join predicate，sort warning很可能伴隨着一個運行速度不理想的語句
Locks事件組
dead lock graph，lock：deadlock，lock：deadlock chain
這三個事件是跟蹤死鎖的。因為死鎖在SQL里發生的頻率不會太高，所以在做
死鎖問題的時候，可以把他們三個都選上。但是要注意，要先選上
“顯示所有列”，再選事件，因為有些重要的字段默認的模板里沒有選上。
Lock:Timeout和Lock：Timeout（timeout>0）
在發生阻塞的時候，會有Lock Timeout事件發生。可是，阻塞是SQL里為了實現
事務隔離所需發生的事件，所以阻塞在SQL里發生得非常普遍。收集這兩個事件
對問題分析的幫助不會太大。還不如用性能監視器里SQLSERVER：Locks-Lock Timeouts/sec
這個計數器看一個總的趨勢。所以在實際使用中，很少選他們
Lock：Acquired 、Lock:Cancel、Lock:Escalation、Lock:Released:
這些事件能夠跟蹤一句語句在運行過程中對鎖資源的申請和釋放過程。
但是在繁忙的生產環境里，SQL會申請大量的鎖資源。所以這些事件會產生大量
記錄。通常情況下，只會在測試環境里，測試單條語句時，才敢把他們加上。
在生產環境上，要盡可能避免使用他們
“Performance”事件組
“Performance”事件組里的事件主要分兩類：Auto Stats能夠記錄SQL里發生的自動
創建或更新統計信息的事件。其他有showplan字樣的，是關於各種形式的執行計划
以及運行信息。他們的相同點和不同點要有目的地選擇，不要重復收集
需要注意的是，執行計划一般都比較大，而每一條語句執行，都會有他的執行計划
所以如果要收集執行計划，結果日志肯定會很大。所以一定要在必要的時候，才加入執行計划事件
“Security Audit”事件組
這一組事件的目的，是監視SQL里各項和安全有關的事件，例如有人加入了一個
DB User、一個Login，有人做了數據庫備份、DBCC動作，有人修改了用戶密碼等
如果要對SQL做安全監控，這些事件都是要考慮的
如果是要一般地監視運行，可能要選擇的只有Audit Login和Audit logout
通過這兩個事件，我們能夠看到一個連接的生命周期。如果有用戶抱怨連接
失敗，也可以跟蹤Audit Login Failed。如果連接請求是被SQL拒絕的，可以
看到拒絕的時間和理由
“Server”事件組
他的下面只有三個事件，Mount Tape、 Server Memory Change 、Trace File Close
這三個事件在SQL里發生的頻率都不會很高，所以加進來也不會有很大影響
尤其是Server Memory Change，如果發生，對SQL性能的影響不會很大。所以
這個事件是可以經常收集的。當然，如果你同時收集了性能監視器日志，那個
日志里也會有包含
“Sessions”事件組
他只有一個事件：ExistingConnection，反映在日志開始收集的時候，SQL里已經有
的連接。這個事件總是要被選上的
“Stored Procedures”事件組
這是一個很重要的事件組，事件的選擇也很有講究。常用的事件分成兩類：
和編譯、重編譯有關的：
SP:CacheHit
SP:CacheInsert
SP:CacheMiss
SP:CacheRemove
SP:Recompile
這些事件的量也會很大。所以只有當懷疑問題和執行計划重用、或者編譯
、重編譯相關的時候，才需要選擇。其他問題不要選擇收集這些事件
關於存儲過程運行的：
RPC:Completed,RPC:Starting:應用程序調用了一個存儲過程。這兩個事件記錄了存儲過程
的開始和結束。一般的SQL應用程序，例如，使用ADO連接運行一個存儲過程，在SQL
里看到的都是RPC事件
在RPC:Completed事件里，不但有結束時間，也包含開始時間。所以如果連接正常
一個RPC:Completed事件就應該包含RPC:Starting里的信息。理論上講，只收
RPC:Completed就可以了。但是如果連接非正常地退出，或者遇到了SQL異常，
可能存儲過程的運行只能看到RPC:Starting事件，看不到RPC:Completed事件，但是這種幾率
是比較小的
SP:Completed,SP:Starting:如果連接是以SQL Batch的方式調用存儲過程，例如
在SSMS里運行sp_who，看到的會是一組SP:Completed,SP:Starting事件。像
RPC一樣，SP:Completed事件也能包含SP:Starting的絕大部分信息
SP:StmtCompleted,SP:StmtStarting:前兩組事件都是以整個存儲過程為單位的
一個復雜的存儲過程，可能最后執行的指令數會達到幾千行，甚至幾萬行，十幾萬行
（如果里面有循環邏輯）。當知道了一個存儲過程慢，就要知道是哪一部分，或者
是哪一句話最慢。這時候就需要SP:StmtCompleted,SP:StmtStarting事件來幫忙
和SP:Completed、RPC:Completed不同的是，如果一個存儲過程在運行過程中
被cancel了（例如，遇到了運行超時），SP:Completed、RPC:Completed都能
被抓到，但是正在運行的語句不會有SP:StmtCompleted，后面沒有運行的語句
都不會有SP:StmtCompleted,SP:StmtStarting事件。所以通過
SP:StmtCompleted,SP:StmtStarting事件可以很好地看出存儲過程在被終止時執行到了哪一步
但是SP:StmtCompleted,SP:StmtStarting事件會產生大量的日志記錄，所以在
問題定位階段，一般不大會加入他們。而且，為了減少事件的數目，常常
只收Completed事件，不收Starting事件。當問題有了方向之后，再加入
更多的事件，有目的地收集和分析
“TSQL”事件組
這個事件組也很重要。他的事件也分兩類
和編譯、重編譯相關的：
Exec PreparedSQL
Prepare SQL
SQL:StmtRecompile
Unprepare SQL
其中，SQL:StmtRecompile比較常用
關於批處理執行的：
SQL:BatchCompleted SQL:BatchStarting RPC:Completed
RPC:Starting類似
SQL:StmtCompleted SQL:StmtStarting
SP:StmtCompleted SP:StmtStarting類似
相似地，在問題定位階段，一般不會加入SQL:StmtCompleted SQL:StmtStarting
而且，為了減少事件的數目，常常只收Completed事件，不收Starting事件
當問題有了方向之后，再加入更多的事件，有目的地收集和分析
“Transactions”事件組
常用的事件有：
DTCTransaction：分布式事務的生命周期。正常來講MSDTC事務在SQL里比較少，而且
容易出問題。所以可以默認就收集他
SQLTransaction：SQL事務的生命周期。SQL事務是SQL非常普通的操作。如果搜集
，會產生大量記錄。所以只會在遇到阻塞和死鎖問題，又搞不清楚這個事務
怎麽被打開時，才會借助這個事務分析問題
TransactionLog：記錄SQL向事務日志文件里寫入日志的動作。這個動作在SQL里非常普遍，建議不要收集
總結
來總結一下，對於一般性問題，作者建議收集的事件有哪些
1、一個普通的Trace
Database：Data File Auto Grow、Data File Auto Shrink、Log File Auto Grow、Log File Auto Shrink
Errors and Warnings：除了Errorlog以外的所有事件
Locks：Deadlock Graph、Lock：Escalation（在論壇里見過）
1 ALTER TABLE dbo.Tmp_testComputeColumn SET (LOCK_ESCALATION = TABLE) 2 GO
Performance：Auto Stats
Progress Report：Online Index Operation
Security Audit：、Audit Logi、Audit Login Failed、Audit Logout、Audit Server Starts and Stops、Audit Backup/Restore Event、Audit DBCC Event
Server：所有事件
Sessions：ExistingConnection
Stored Procedures：RPC:Completed, RPC:Starting
TSQL：SQL:BatchCompleted、SQL:BatchStarting、PrepareSQL、UnprepareSQL、SQL:StmtRecompile
Transactions：DTCTransaction
如果還要縮小日志生成量，可以去掉RPC:Starting和 SQL:BatchStarting
2、一個很詳細的關於性能問題的Trace
Performance：Showplan Statistics Profile
Stored Procedures：RPC:Output Parameter、SP:CacheMiss、SP:CacheRemove、SP:Recompile、
、SP:Completed、SP:Starting、SP:StmtCompleted、SP:StmtStarting
TSQL：SQL:StmtStarting、SQL:StmtCompleted
Transactions：SQLTransaction
如果要縮小日志生成量，可以去掉SP:Starting 、SP:StmtStarting、 SQL:StmtStarting
當然，每個人分析問題的方法都可能不一樣，對這些事件的喜好也不一樣。
上面只是兩種建議的組合。在使用時可以根據實際問題作調整
另外，按照默認的模板，有些事件比較重要的數據字段可能沒有被包含。
例如Performance下的“Showplan Statistics Profile”事件，如果不選Binary字段，可能整個執行計划就看不到了，Trace就白收了。
所以如果要收Trace，建議把所有字段都選上