SQL Server Profiler工具

1、SQL Profiler工具簡介

SQL Profiler是一個圖形界面和一組系統存儲過程，其做用以下：

• 圖形化監視SQL Server查詢；
• 在後臺收集查詢信息；
• 分析性能；
• 診斷像死鎖之類的問題；
• 調試T-SQL語句；
• 模擬重放SQL Server活動；

也可使用SQL Profiler捕捉在SQL Server實例上執行的活動。這樣的活動被稱爲Profiler跟蹤。

　　一、Profiler跟蹤

　　從開始=》全部程序=》Microsoft SQL Server 2008=》性能工具打開Profiler工具，也能夠打開SQL Server Management Studio=》工具=》SQL Server Profiler。

　　而後選擇文件=》新建=》跟蹤打開一個鏈接窗口，選擇將要跟蹤的服務器實例而後鏈接。打開以下「跟蹤屬性」對話框。

　　

　　若是有許多跟蹤，能夠提供一個跟蹤名稱來幫助在之後進行分類。不一樣的跟蹤模板可幫助創建用於不一樣目的的跟蹤。

　　打開跟蹤屬性窗口後，單擊「事件選擇」選項卡，爲跟蹤提供更詳細的定義。

　　

　　二、事件

　　一個事件表現SQL Server中執行的各類活動。這些活動能夠簡單地分類爲事件類，遊標事件，鎖事件，存儲過程事件和T-SQL事件是常見的事件類。

　　對於性能分析，主要對SQL Server上執行的各類活動的資源壓力水平的事件感興趣。資源壓力主要包含以下內容：

1. SQL活動涉及哪一類的CPU使用？
2. 使用了多少內存？
3. 涉及多少I/0操做?
4. SQL活動執行了多長時間？
5. 特定的查詢執行的頻率有多高？
6. 查詢面對哪類錯誤和警告？

　　下面給出跟蹤查詢結束的事件：

事件類	事件	說明
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事務)	提供數據庫事務的信息，包括事務開始/結束的時間、事務持續事件等信息

　　三、事件列

 　　事件以不一樣的特性(被稱爲數據列)來表現。數據列表現一個事件的不通特性，如事件的類、用於該事件的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意味着它將成爲一個合計列。

 　　

　　四、列篩選器

　　除了爲一個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>	定位由特定的數據庫用戶發送的查詢

 　　下面給出設置過濾列的方式：

　　

 　　五、跟蹤模板

　　SQL Server Profiler能夠用自定義事件、數據列和過濾器建立一個跟蹤模板，而後定義一個新的跟蹤，而後重用跟蹤個模板來捕捉一個跟蹤。定義新跟蹤模板的過程相似於定義新跟蹤，步驟以下：

1. 建立一個新的跟蹤。
2. 和前面同樣定義事件，數據列和過濾器。
3. 從文件=》另存爲菜單將跟蹤定義保存爲跟蹤模板。

　　SQL Server Profiler將自動將新的模板加入到其模板列表中。

　　新建模板：

　　

　　保存模板:

　　

　　查看：

　　

　　六、跟蹤數據

　　定義了跟蹤之後，單擊運行按鈕將開始捕捉事件並將其顯示在屏幕上，能夠看到一系列滾動事件，能夠在咱們稱之爲SQL TV的屏幕上看到系統的運行，能夠像DVD播放機同樣或多或少地控制跟蹤，可使用工具欄上的按鈕暫停、開始和中止跟蹤，甚至能夠在工做室暫停跟蹤並修改它。

　　一旦完成了SQL Server活動的捕捉，就能夠將跟蹤輸出保存爲一個跟蹤文件或一個跟蹤表。保存到跟蹤文件的跟蹤輸出是一個原生的格式，能夠由Profiler打開以分析SQL查詢。將跟蹤的輸出保存爲一個表，也可使Profiler在跟蹤表上用SELECT語句來分析其中的SQL查詢。

　　具體的操做爲 文件 =》 另存爲 =》 跟蹤表。選擇你但願存入的的數據庫和表，而後你就能夠像普通表同樣執行各類SQL查詢。

2、跟蹤的自動化

　　Profiler GUI簡化了Profiler跟蹤的收集。不幸的是，這種簡易性有其代價。Profiler工具捕捉的事件進入內存中的緩衝以便經過網絡反饋給GUI。GUI依賴網絡，網絡流量可能下降系統的速度並致使緩衝被填滿。這將在較小的程度上影響服務器的性能。進一步地，當緩衝被填滿，服務器將開始丟棄事件以免嚴重地影響服務器性能。

　　一、使用GUI捕捉跟蹤

　　能夠以兩種方法兩建立一個腳本化跟蹤-手工或者使用GUI。在輕鬆地知足腳本的全部要求之間，最簡易的方法就是使用Profiler工具的GUI,須要以下步驟：

1. 定義一個跟蹤；
2. 單擊文件=》導出=》腳本跟蹤定義；
3. 必須選擇目標服務器類型， SQL Server2005/2008；
4. 未文件命名，並保存它；

　　這些不走將生成全部步驟跟蹤並將其輸出到一個文件所需的全部腳本命令。

　　使用Management Studio手工啓動新的跟蹤:

1. 打開文件；
2. 使用系統的相關名稱和路徑替換InsertFileNameHere；
3. 執行腳本，它將返回帶有TraceId的單列結果集；

　　能夠經過SQL Agent自動化這個腳本的執行，甚至可使用sqlcmd.exe使用程序從命令行運行這個腳本。無論使用哪一種方法，這個腳本將啓動跟蹤。若是沒有定義跟蹤中止時間，就必須使用TraceId手工中止跟蹤。

　　二、使用存儲過程捕捉跟蹤

　　查看上一節中定義的腳本，會看到以特定順序條用的一系列命令：

• 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跟蹤計劃的更大靈活性。

3、結合跟蹤和性能監視器輸出

　　若是自動化了性能監視器捕捉到文件，又自動化了Profiler數據捕捉到一個文件。它們覆蓋相同的時間段，那麼就能夠在SQL Profiler GUI中一塊兒使用它們。肯定跟蹤有StartTime和EndTime數據字段，按照如下步驟進行：

• 打開跟蹤文件(固然前提是你曾經 另存爲=》跟蹤文件)；
• 單擊 文件=》 導入性能數據；
• 選擇導入的性能監視器文件；

　　執行上面的操做將打開以下所示對話框，這裏容許選擇包含性能監視器計數器。

 

　　選擇了想要包含的計數器以後，單擊OK按鈕將一塊兒打開Profiler和性能監視器數據。如今，能夠開始一塊兒使用跟蹤數據和性能監視器數據。若是在頂部窗口選擇一個時間，它將在性能 監視器中放置一條紅線，顯示數據中事件發生的時間。相反，能夠單擊性能監視器數據，表示那段 時間的事件將被選中。這些性能工做得很好，將能夠在調整過程當中定時使用它們以確認瓶頸和壓力 點，並肯定致使這些壓力的特定查詢。

4、SQL Profiler使用要點

　　SQL Profiler使用建議以下：

• 限制事件和數據列的數量；
• 拋棄用於性能分析的啓動事件；
• 限制跟蹤的輸出大小；
• 避免聯機數據列排序；
• 遠程運行Proflier；

　　一、限制事件和數據列

　　在跟蹤SQL查詢時，能夠經過過濾事件和數據列來決定哪些SQL活動應該被捕捉。選擇更多的事件形成了大量的跟蹤開銷。數據列不會增長太多的開銷，由於它們只是一個事件類的特性。所以，知道每一個所但願跟蹤事件的緣由，並根據必要性來選擇事件是很重要的。

　　最小化捕捉的事件數量避免SQL Server浪費寶貴的資源帶寬去生成全部的事件。捕捉像鎖和執行計劃這樣的事件時應該當心進行，由於這些事件會使跟蹤輸出變得很是大並下降SQL Server的性能。

　　過濾分兩個階段：預過濾由SQL Server執行，後過濾由用戶執行。預過濾是捕捉SQL Server活動的聯機階段，預過濾提供多種溢出：

• 下降了SQL Server的性能影響，由於生成有限數量的時間；
• 下降跟蹤輸出大小；
• 簡化後過濾操做，首先由於要捕捉的事件更少了；

　　預過濾的惟一缺點是，可能丟失一些完全分析中須要的重要信息。

　　二、丟棄性能分析所用的啓動事件

　　所用於性能分析的信息圍繞一個查詢的資源開銷。想SP:StmtStarting這樣的啓動事件不提供這種信息，由於只有在事件完成以後，才能計算I/O量、CPU負載和查詢的持續時間。因此，在跟蹤運行緩慢的查詢以進行性能分析時，不須要捕捉啓動事件。這種信息由對應的完成事件來提供。

　　什麼狀況下適合捕捉啓動事件呢？應該在預期某些SQL查詢由於錯誤而不能結束執行，或者頻繁發現Attention事件的時候捕捉啓動事件。Attention事件通常表示用戶中途撤銷了查詢或者查詢超時，可能由於查詢運行了太長時間。

　　三、限制跟蹤輸出大小

　　除了預過濾事件和數據列，其餘過濾條件也會限制跟蹤輸出的大小。一樣，限制大小可能丟失所關注的整體系統狀態中感興趣的事件。可是，若是關注於開銷較大的查詢，過濾器是有幫助的。

　　經過過濾器，可以篩選執行事件》=2或邏輯讀數量》=100的查詢，由於消耗過低的查詢基本上不須要優化。

　　四、避免在線數據列排序

　　在性能分析期間，通常在不一樣的數據列(如Duration、CPU、Reads)上排序以肯定相應數字最大的查詢。若是脫機排序，就能下降在與SQL Server交互時必須進行的Profiler活動。排序捕捉到的SQL跟蹤輸出的方法以下：

• 捕捉跟蹤，不作任何排序或分組；
• 另存爲跟蹤輸出到一個跟蹤文件；
• 打開跟蹤文件並按照須要在特定的數據列上排序或分組跟蹤文件輸出；

　　五、遠程運行Profiler

　　直接在生產服務器上運行測試工具通常不是一個好辦法。Profiler有一個大型的用戶界面，所以，在其餘機器上運行它更好。與系統監視器類似，Profiler不該該經過終端服務會話來運行，由於這樣工具的主要部分仍然在服務器上運行。在直接將跟蹤輸出收集到一個文件時，保存在Profiler運行的本地文件上。這仍然是比經過系統存儲過程將Profiler做爲服務器端跟蹤來運行更加資源密集的操做。使用系統存儲過程仍然是最好的選擇。

　　六、限制使用某些事件

　　某些事件的開銷比其餘的事件大。因爲生成的查詢的特性，語句完成事件的開銷可能很是大。須要謹慎地使用，特別是在已經遇到壓力的系統上，必須謹慎使用的事件有：Showplan XML事件，Performance:Showplan XML、Performance:Showplan XML for Query Compile和Performance:Showplan XML sTATISTICS Prifile。雖然這些事件可能有用，可是不要在生產機器上使用它們。

5、沒有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，能夠限制但願過濾得數據庫或過程。