一、SQL Profiler工具簡介
SQL Profiler是一個圖形界面和一組系統存儲過程，其作用如下：
- 圖形化監視SQL Server查詢；
- 在背景收集查詢資訊；
- 分析性能；
- 診斷像死鎖之類的問題；
- 調試T-SQL語句；
- 模拟重放SQL Server活動；
也可以使用SQL Profiler捕捉在SQL Server執行個體上執行的活動。這樣的活動被稱為Profiler跟蹤。
1、Profiler跟蹤
從開始=》所有程式=》Microsoft SQL Server 2008=》性能工具打開Profiler工具，也可以打開SQL Server Management Studio=》工具=》SQL Server Profiler。
然後選擇檔案=》建立=》跟蹤打開一個連接配接視窗，選擇将要跟蹤的伺服器執行個體然後連接配接。打開如下“跟蹤屬性”對話框。
如果有許多跟蹤，可以提供一個跟蹤名稱來幫助在以後進行分類。不同的跟蹤模闆可幫助建立用于不同目的的跟蹤。
打開跟蹤屬性視窗後，單擊“事件選擇”頁籤，為跟蹤提供更詳細的定義。
2、事件
一個事件表現SQL Server中執行的各種活動。這些活動可以簡單地分類為事件類，遊标事件，鎖事件，存儲過程事件和T-SQL事件是常見的事件類。
對于性能分析，主要對SQL Server上執行的各種活動的資源壓力水準的事件感興趣。資源壓力主要包含如下内容：
- SQL活動涉及哪一類的CPU使用？
- 使用了多少記憶體？
- 涉及多少I/0操作?
- SQL活動執行了多長時間？
- 特定的查詢執行的頻率有多高？
- 查詢面對哪類錯誤和警告？
下面給出跟蹤查詢結束的事件：
| 事件類 | 事件 | 說明 |
| Stored Procedures | RPC:Completed | RPC完成事件 |
| SP:Completed | 存儲過程完成事件 | |
| SP:StmtCompleted | 在存儲過程中一條SQL語句完成事件 | |
| T-SQL | SQL:BatchCompleted | T-SQL批完成事件 |
| SQL:StmtCompleted | 一條T-SQL語句完成事件 |
RPC事件表示存儲過程使用遠端過程調用(RPC)機制通過OLEDB指令執行。如果一個資料庫應用程式使用T-SQL EXECUTE語句執行一個存儲過程，那麼存儲過程将被轉化為一個SQL批而不是一個RPC。RPC請求通常比EXECUTE請求快，因為它繞過了SQL Server中的許多語句解析和參數處理。
T-SQL由一條或多條T-SQL語句組成。語句或T-SQL語句在存儲過程中也是單獨和離散的。用SP:StmtCompleted或SQL:StmtCompleted事件捕捉單獨的語句可能是代價很高的操作，這取決于單獨語句的數量。假設系統中的每個存儲過程包含且隻有一條T-SQL語句。在這種情況下，完成的語句集合相當小。現在假定過程中有多條語句，而且這些過程中有些使用其他語句調用其他過程。收集所有這些額外的資料現在變成系統上非常厲害的負載。在生産機上一定要慎用。
現在回到那個事件選擇面闆，隻有已經被選擇的事件才會被顯示。如果想顯示所有可供選擇的事件，則隻需選中“顯示所有事件”單選框，要添加一個跟蹤事件，在Event列中查找一個事件類下的事件，并單擊其左邊的檢查框；要删除不需要的事件，取消選中的事件選擇框。
光分類就有好多的說：
下面給出其他一些與性能診斷有關的事件:
| 事件類 | 事件 | 說明 |
| Security Audit(安全審計) | Audit Login(登入審計) | 記錄使用者連接配接到SQL Server或斷開連接配接時資料庫的連接配接 |
| Audit Logout(登出審計) | ||
| Sessions(會話) | ExistingConnection(現有連接配接) | 表示所有在跟蹤開始之間連接配接到SQL Server的使用者 |
| Cursors(遊标) | CursorImplicitConversion(遊标隐含轉換) | 表明建立的遊标類型與所請求的類型個不同 |
| Errors and Warnings(錯誤和警告) | Attention(注意) | 表示由于用戶端撤銷查詢或者資料庫連接配接破壞引起請求中斷 |
| Exception(異常) | 表明SQL Server發生了異常 | |
| Execution Warning(執行警告) | 表明在查詢或存儲過程執行期間出現了警告 | |
| Hash Warning(哈希警告) | 表明hash操作發生了錯誤 | |
| Missing Column Statistics(列統計丢失) | 表明優化器要求的确定處理政策用的類統計丢失 | |
| Missing Join Predicate(連接配接斷言丢失) | 表明查詢在兩個表沒有連接配接斷言情況下執行 | |
| Sort Warning(排序警告) | 表明像SELECT這樣的查詢中執行排序操作沒有合适的記憶體 | |
| Locks(鎖) | Lock:Deadlock(死鎖) | 标志着死鎖的出現 |
| Lock:Deadlock Chain(死鎖鍊) | 顯示産生死鎖的查詢鍊條 | |
| lock:Timeout(鎖逾時) | 表示鎖已經超過其逾時參數，該參數由SETLOCK_TIMEOUT timeout_perious(ms)指令設定 | |
| Stored Procedures(存儲過程) | SP:Recompile(重編譯) | 表明用于一個存儲過程的執行計劃必須重編譯，原因是執行計劃不存在，強制的重編譯，或者現有的執行計劃不能重用 |
| SP:Starting(開始) SP:StmtStarting(語句開始) | 分别表示一個SP:StmtStarting存儲過程和存儲過程中的一條SQL語句的開始。他們對于識别開始單因為一個操作導緻Attention事件未能結束的查詢很有用 | |
| Transactions(事物) | SQLTransaction(SQL事務) | 提供資料庫事務的資訊，包括事務開始/結束的時間、事務持續事件等資訊 |
3、事件列
事件以不同的特性(被稱為資料列)來表現。資料清單現一個事件的不通特性，如事件的類、用于該事件的SQL語句、事件的資源開銷以及事件來源。
| 資料列 | 說明 |
| EventClass(事件類) | 事件類型，如SQL:StatementCompleted |
| TextData | 事件所用的SQL語句，如SELECT * FROM Person |
| CPU | 事件的CPU開銷（以ms表示），如對一個SELECT語句，CPU=100表示該語句執行100ms |
| Reads | 為一個事件所執行的邏輯讀操作數量。例如對一個SELECT語句，Reads=800表示該語句需要800次邏輯讀操作 |
| Writes | 為一個事件所執行的邏輯寫操作數量 |
| Duration | 事件的執行時間(ms) |
| SPID | 用于該事件的SQL Server程序辨別符 |
| StartTime | 事件開始的時間 |
以上是常用的資料列，另外還有一些不太常用的資料列：
- BinaryData(二進制資料)
- IntegerData(整數資料)
- EventSubClass(事件子類)
- DatabaseID(資料庫辨別符)
- ObjectID(對象辨別符)
- IndexID(索引辨別符)
- TransactionID(事務辨別符)
- Error(錯誤)
- EndTime(結束時間)
列資料可以重新安排以符合你自己所喜歡的風格，要控制列資料的安放，單擊組織列按鈕，将打開如下對話框。可以單擊Up和Down按鈕修改列的位置，将列移入Groups意味着它将成為一個合計列。
4、列篩選器
除了為一個Profiler跟蹤定義事件和資料列之外，還可以定義各種過濾條件。這些條件幫助縮小跟蹤的輸出，這往往是一個好主意。下面給出常用過濾條件清單。
| 事件 | 過濾條件執行個體 | 用處 |
| ApplicationName(應用程式名稱) | Not like:SQL Profiler | 過濾Profiler生成的事件。這是預設的行為 |
| DatabaseID(資料庫辨別符) | Equals:<ID of the database to monitor> | 過濾特定資料庫生成的事件。資料庫ID:SELECT DB_IC('Northwind') |
| Duration(持續時間) | Greater than or equal:2 | 對于性能分析，經常會為一個大的工作負載捕捉跟蹤，在大的跟蹤中，許多事件日志具有比所感興趣更小的持續周期(Duration)。過濾這個事件日志，因為幾乎沒有可用于優化這些SQL活動的餘地 |
| Reads(讀操作數) | Greater than or equal"2 | 過濾讀操作較小的事件 |
| SPID | Equals:<Database users to monitor> | 定位由特定的資料庫使用者發送的查詢 |
下面給出設定過濾列的方式：
5、跟蹤模闆
SQL Server Profiler可以用自定義事件、資料列和過濾器建立一個跟蹤模闆，然後定義一個新的跟蹤，然後重用跟蹤個模闆來捕捉一個跟蹤。定義新跟蹤模闆的過程類似于定義新跟蹤，步驟如下：
- 建立一個新的跟蹤。
- 和前面一樣定義事件，資料列和過濾器。
- 從檔案=》另存為菜單将跟蹤定義儲存為跟蹤模闆。
SQL Server Profiler将自動将新的模闆加入到其模闆清單中。
建立模闆：
儲存模闆:
檢視：
6、跟蹤資料
定義了跟蹤以後，單擊運作按鈕将開始捕捉事件并将其顯示在螢幕上，可以看到一系列滾動事件，可以在我們稱之為SQL TV的螢幕上看到系統的運作，可以像DVD播放機一樣或多或少地控制跟蹤，可以使用工具欄上的按鈕暫停、開始和停止跟蹤，甚至可以在工作室暫停跟蹤并修改它。
一旦完成了SQL Server活動的捕捉，就可以将跟蹤輸出儲存為一個跟蹤檔案或一個跟蹤表。儲存到跟蹤檔案的跟蹤輸出是一個原生的格式，可以由Profiler打開以分析SQL查詢。将跟蹤的輸出儲存為一個表，也可以使Profiler在跟蹤表上用SELECT語句來分析其中的SQL查詢。
具體的操作為 檔案 =》 另存為 =》 跟蹤表。選擇你希望存入的的資料庫和表，然後你就可以像普通表一樣執行各種SQL查詢。
二、跟蹤的自動化
Profiler GUI簡化了Profiler跟蹤的收集。不幸的是，這種簡易性有其代價。Profiler工具捕捉的事件進入記憶體中的緩沖以便通過網絡回報給GUI。GUI依賴網絡，網絡流量可能降低系統的速度并導緻緩沖被填滿。這将在較小的程度上影響伺服器的性能。進一步地，當緩沖被填滿，伺服器将開始丢棄事件以避免嚴重地影響伺服器性能。
1、使用GUI捕捉跟蹤
可以以兩種方法兩建立一個腳本化跟蹤-手工或者使用GUI。在輕松地滿足腳本的所有要求之間，最簡易的方法就是使用Profiler工具的GUI,需要如下步驟：
- 定義一個跟蹤；
- 單擊檔案=》導出=》腳本跟蹤定義；
- 必須選擇目标伺服器類型， SQL Server2005/2008；
- 未檔案命名，并儲存它；
這些不走将生成所有步驟跟蹤并将其輸出到一個檔案所需的所有腳本指令。
使用Management Studio手工啟動新的跟蹤:
- 打開檔案；
- 使用系統的相關名稱和路徑替換InsertFileNameHere；
- 執行腳本，它将傳回帶有TraceId的單列結果集；
可以通過SQL Agent自動化這個腳本的執行，甚至可以使用sqlcmd.exe使用程式從指令行運作這個腳本。不管使用哪種方法，這個腳本将啟動跟蹤。如果沒有定義跟蹤停止時間，就必須使用TraceId手工停止跟蹤。
2、使用存儲過程捕捉跟蹤
檢視上一節中定義的腳本，會看到以特定順序條用的一系列指令：
- sp_trace_create:建立一個跟蹤定義；
- sp_trace_setevent:添加事件和事件列到跟蹤中；
- sp_trace_setfilter:将過濾器應用到跟蹤；
一旦定義了SQL跟蹤持續到跟蹤被停止。因為SQL跟蹤作為一個後端程序持續運作，Managerment Studio會話不需要保持打開。可以使用SQL Server内建函數fn_trace_getinfo确定正在運作的跟蹤，查詢如下：
SELECT * FROM ::fn_trace_getinfo(default); 輸出圖：
fn_trace_getinfo函數的輸出中，不同的traceid的數量表示SQL Server上活動跟蹤的數量。
第三列(value)表示跟蹤是否正在運作(value=1)或者停止(value=0)。可以通過執行存儲過程sp_trace_setstatus停止特定的跟蹤，如traceid=1，如下所示：
EXEC sp_trace_setstatus 1,0; 在跟蹤停止之後，它的定義必須執行sp_trace_setstatus關閉并且從伺服器中删除，如下所示:
EXEC sp_trace_setstatus 1,2; 為了驗證跟蹤成功地停止，重新執行fn_trace_getinfo函數，并确定該函數的輸出不包含該traceid。
這種技術所建立的跟蹤檔案的格式與Profiler建立的跟蹤檔案相同。是以，這種跟蹤檔案可以與Profiler建立的檔案以相同的方式進行分析。
使用前一小節所概述的存儲過程捕捉SQL跟蹤，避免了與Profiler GUI相關的開銷。而且還比Profiler工具提供了管理SQL跟蹤計劃的更大靈活性。
三、結合跟蹤和性能螢幕輸出
如果自動化了性能螢幕捕捉到檔案，又自動化了Profiler資料捕捉到一個檔案。它們覆寫相同的時間段，那麼就可以在SQL Profiler GUI中一起使用它們。确定跟蹤有StartTime和EndTime資料字段，按照以下步驟進行：
- 打開跟蹤檔案(當然前提是你曾經 另存為=》跟蹤檔案)；
- 單擊 檔案=》 導入性能資料；
- 選擇導入的性能螢幕檔案；
執行上面的操作将打開如下所示對話框，這裡允許選擇包含性能螢幕計數器。
選擇了想要包含的計數器之後，單擊OK按鈕将一起打開Profiler和性能螢幕資料。現在，可以開始一起使用跟蹤資料和性能螢幕資料。如果在頂部視窗選擇一個時間，它将在性能 螢幕中放置一條紅線，顯示資料中事件發生的時間。相反，可以單擊性能螢幕資料，表示那段 時間的事件将被選中。這些性能工作得很好，将可以在調整過程中定時使用它們以确認瓶頸和壓力 點，并确定導緻這些壓力的特定查詢。
四、SQL Profiler使用要點
SQL Profiler使用建議如下：
- 限制事件和資料列的數量；
- 抛棄用于性能分析的啟動事件；
- 限制跟蹤的輸出大小；
- 避免聯機資料列排序；
- 遠端運作Proflier；
1、限制事件和資料列
在跟蹤SQL查詢時，可以通過過濾事件和資料列來決定哪些SQL活動應該被捕捉。選擇更多的事件造成了大量的跟蹤開銷。資料列不會增加太多的開銷，因為它們隻是一個事件類的特性。是以，知道每個所希望跟蹤事件的原因，并根據必要性來選擇事件是很重要的。
最小化捕捉的事件數量避免SQL Server浪費寶貴的資源帶寬去生成所有的事件。捕捉像鎖和執行計劃這樣的事件時應該小心進行，因為這些事件會使跟蹤輸出變得非常大并降低SQL Server的性能。
過濾分兩個階段：預過濾由SQL Server執行，後過濾由使用者執行。預過濾是捕捉SQL Server活動的聯機階段，預過濾提供多種溢出：
- 降低了SQL Server的性能影響，因為生成有限數量的時間；
- 降低跟蹤輸出大小；
- 簡化後過濾操作，首先因為要捕捉的事件更少了；
預過濾的唯一缺點是，可能丢失一些徹底分析中需要的重要資訊。
2、丢棄性能分析所用的啟動事件
所用于性能分析的資訊圍繞一個查詢的資源開銷。想SP:StmtStarting這樣的啟動事件不提供這種資訊，因為隻有在事件完成之後，才能計算I/O量、CPU負載和查詢的持續時間。是以，在跟蹤運作緩慢的查詢以進行性能分析時，不需要捕捉啟動事件。這種資訊由對應的完成事件來提供。
什麼情況下适合捕捉啟動事件呢？應該在預期某些SQL查詢因為錯誤而不能結束執行，或者頻繁發現Attention事件的時候捕捉啟動事件。Attention事件一般表示使用者中途撤銷了查詢或者查詢逾時，可能因為查詢運作了太長時間。
3、限制跟蹤輸出大小
除了預過濾事件和資料列，其他過濾條件也會限制跟蹤輸出的大小。同樣，限制大小可能丢失所關注的總體系統狀态中感興趣的事件。但是，如果關注于開銷較大的查詢，過濾器是有幫助的。
通過過濾器，能夠篩選執行事件》=2或邏輯讀數量》=100的查詢，因為消耗太低的查詢基本上不需要優化。
4、避免線上資料列排序
在性能分析期間，一般在不同的資料列(如Duration、CPU、Reads)上排序以确定相應數字最大的查詢。如果脫機排序，就能降低在與SQL Server互動時必須進行的Profiler活動。排序捕捉到的SQL跟蹤輸出的方法如下：
- 捕捉跟蹤，不做任何排序或分組；
- 另存為跟蹤輸出到一個跟蹤檔案；
- 打開跟蹤檔案并按照需要在特定的資料列上排序或分組跟蹤檔案輸出；
5、遠端運作Profiler
直接在生産伺服器上運作測試工具一般不是一個好辦法。Profiler有一個大型的使用者界面，是以，在其他機器上運作它更好。與系統螢幕相似，Profiler不應該通過終端服務會話來運作，因為這樣工具的主要部分仍然在伺服器上運作。在直接将跟蹤輸出收集到一個檔案時，儲存在Profiler運作的本地檔案上。這仍然是比通過系統存儲過程将Profiler作為伺服器端跟蹤來運作更加資源密集的操作。使用系統存儲過程仍然是最好的選擇。
6、限制使用某些事件
某些事件的開銷比其他的事件大。由于生成的查詢的特性，語句完成事件的開銷可能非常大。需要謹慎地使用，特别是在已經遇到壓力的系統上，必須謹慎使用的事件有：Showplan XML事件，Performance:Showplan XML、Performance:Showplan XML for Query Compile和Performance:Showplan XML sTATISTICS Prifile。雖然這些事件可能有用，但是不要在生産機器上使用它們。
五、沒有Profiler的情況下查詢性能度量
建立一個跟蹤能收集許多資料供以後使用，但是這種收集可能代價很大，必須等待結果。
如果要立即捕捉系統的性能度量，特别是關于查詢性能的度量，那麼動态管理視圖sys.dm_exec_query_stats正式所需要的。如果還需要查詢運作及其單獨開銷的曆史記錄，那麼跟蹤仍然是更好的工具。但是，如果隻需要知道這時候運作時間最長的查詢或者最多的實體讀操作，則可以從sys.dm_exec_query_stats得到這些資訊。
因為sys.dm_exec_query_stats隻是一個視圖，可以簡單地對其進行查詢并獲得伺服器上查詢計劃統計的資訊。
| 列 | 描述 |
| Plan_handle | 引用執行計劃的指針 |
| Creation_time | 計劃建立的時間 |
| Last_execution time | 查詢最後一次使用的計劃時間 |
| Execution_count | 計劃已經使用的次數 |
| Total_worker_time | 從建立起計劃使用的CPU時間 |
| Total_logical_reads | 從建立器計劃使用的讀操作數量 |
| Total_logical_writes | 從建立器計劃使用的寫操作數量 |
| Query_hash | 可用于識别有相似邏輯的查詢的一個二進制hash |
| Query_plan_hash | 可用于識别有相似邏輯的計劃的一個二jinzhihash |
為了過濾從sys.dm_exec_query_stats傳回的資訊，需要将其連接配接到其他動态管理函數上，如sys.dm_exec_sql_text可以顯示與計劃相關的查詢文本，sys.dm_query_plan顯示用于查詢的執行計劃。一旦連接配接到其他DMF，可以限制希望過濾得資料庫或過程。