SQL Server 手把手教你使用profile進行性能監控

介紹

常常會有人問profile工具該怎麼使用？有沒有方法獲取性能差的sql的問題。自從轉mysql我本身也差很少2年沒有使用profile，突然profile變得有點生疏不得不從新熟悉一下。這篇文章主要對profile工具作一個詳細的介紹；包括工具的用途和使用方法等。profile是SQLServer自帶的一個性能分析監控工具，它也能夠生成數據庫引擎優化顧問分析須要的負載數據，好比開發對功能進行調試須要收集執行sql使用profile就是一個很是好的辦法，profile主要用於在線實時監控和收集數據用於後期的分析使用，它能夠將收集的數據保存成文件和插入到表。

 

 

跟蹤屬性

---

1、常規

將跟蹤的記錄保存到指定的文件。

1.最大文件大小

指定最大文件大小的跟蹤在達到最大文件大小時，會中止將跟蹤信息保存到該文件。使用此選項可將事件分組成更小、更容易管理的文件。此外，限制文件大小使得無人蔘與的跟蹤運行起來更加安全，由於跟蹤會在達到最大文件大小後中止。能夠爲經過 Transact-SQL 存儲過程或使用 SQL Server Profiler建立的跟蹤設置最大文件大小。

最大文件大小選項的上限爲 1 GB。默認最大文件大小爲 5 MB

注意：最大文件的大小建議不要設的太大，特別是須要用於數據庫引擎優化顧問使用的文件，太大的跟蹤文件須要很長的分析的時間並且因爲數據庫引擎優化顧問也是把收集的負載文件執行一遍有時候可能會致使負載過大分析失敗，同時對服務器的壓力持續的時間過長對業務影響也會比較大，通常設置幾兆或者幾十兆便可，同時啓動文件滾動更新，屢次分析。

2.啓用文件滾動更新

若是使用文件滾動更新選項，則在達到最大文件大小時，SQL Server 會關閉當前文件並建立一個新文件。新文件與原文件同名，可是文件名後將追加一個整數以表示其序列。例如，若是原始跟蹤文件命名爲 filename_1.trc，則下一跟蹤文件爲 filename_2.trc，依此類推。若是指定給新滾動更新文件的名稱已經被現有文件使用，則將覆蓋現有文件，除非現有文件爲只讀文件。默認狀況下，將跟蹤數據保存到文件時，會啓用文件滾動更新選項。

3.服務器處理跟蹤數據

確保服務器記錄每一個跟蹤事件，若是記錄事件會顯著下降性能，能夠清除服務器處理跟蹤數據，這樣服務器不會再記錄事件。

4.最大行數

指定有最大行數的跟蹤在達到最大行數時，會中止將跟蹤信息保存到表。每一個事件構成一行，所以該參數可設置收集的事件數的範圍。設置最大行數使得無人蔘與的跟蹤運行起來更加方便。例如，若是須要啓動一個將跟蹤數據保存到表的跟蹤，同時但願在該表變得過大時中止跟蹤，則可使其自動中止。

若是已指定而且達到了最大行數，將在運行 SQL Server Profiler的同時繼續運行跟蹤，但再也不記錄跟蹤信息。SQL Server Profiler將繼續顯示跟蹤結果，直到跟蹤中止

5.啓用跟蹤中止時間 

啓用跟蹤中止時間以後，到了指定的時間跟蹤自動中止。每一次跟蹤建議都必須得設置一個跟蹤中止時間防止忘記關閉跟蹤致使服務器空間被佔滿，默認跟蹤1小時。

 

注意：

• 從 SQL Server 2005 開始，服務器以微秒（百萬分之一秒或 10^-6 秒）爲單位報告事件的持續時間，以毫秒（千分之一秒或 10^-3 秒）爲單位報告事件使用的 CPU 時間。
• 在 SQL Server 2000 中，服務器以毫秒爲單位報告持續時間和 CPU 時間。
• 在 SQL Server 2005 及更高版本中，SQL Server Profiler圖形用戶界面默認以毫秒爲單位顯示「持續時間」列，可是當跟蹤保存到文件或數據庫表中以後，將以微秒爲單位在「持續時間」列中寫入值。

2、事件選擇

對於不一樣跟蹤選擇不一樣的跟蹤事件；經過勾選「顯示全部跟蹤事件」能夠看到全部的跟蹤事件，總共有21個事件分類。用得最多的兩個分類就是存儲過程和TSQL這兩個分類主要用來記錄執行的存儲過程和SQL語句，把鼠標移動到具體的事件上面會顯示該事件和事件列的具體說明，接下來就分析幾個經常使用的事件和經常使用的事件列。

1.顯示全部跟蹤事件

勾選以後會將全部的事件都顯示出來

2.顯示全部列

勾選以後會將全部的列顯示出來

3.列篩選

對列增長一些條件，其實能夠將它理解在TSQL語句的WHERE後面添加條件，對於整形列直接輸入數值便可，對於字符串列就至關於like同樣使用不帶引號的%%模糊匹配方法。經過勾選「排除不包含值的行」以後跟蹤結果就會篩選掉不知足條件的記錄。

4.列組織

列組織能夠理解成TSQL語句裏面作GROUP BY操做，能夠將相同的條件放在一塊兒去重。

 

事件

1.SQL:Stmt*******

[SQL:StmtStarting]:啓動TSQL語句時記錄

[SQL:StmtCompleted]:完成TSQL語句時記錄

這兩事件的區別也同單詞的意思同樣，StmtStarting是記錄事件的開始不關注這個事件在接下來會作什麼，StmtCompleted是記錄事件結束以後在開始和結束這個過程當中作的一些操做好比一些經常使用的列"Duration","Cpu","Reads","Writes","EndTime"這些列就會出如今StmtCompleted事件中。因此若是你須要收集的記錄不關心整個事件過程當中的操做只須要收集數量那麼可使用Starting事件好比記錄某個語句或者存儲過程執行的次數等。

2.SQL:Batch******

[SQL:BatchStarting]:啓動TSQL批處理時記錄

[SQL:BatchCompleted]:完成TSQL批處理時記錄

 

此次我把兩個select語句放在一塊兒來執行，能夠從batch事件中能夠看到它記錄的整個批處理的SQL同時還包括相關注釋，同時整個批處理兩個TSQL做爲一條事件記錄，而stmt事件記錄具體的TSQL語句把兩個TSQL語句做爲兩條記錄來記錄。同時還能夠發現兩個TSQL的Duration相加是小於整個批處理的duration的，這也是正常的整個批處理在sql編譯分析執行這塊確定比單個TSQL須要耗費更多的時間，可是相差也是很是的小。

 

batchcompleted事件多用於引擎優化顧問，而stmtcompleted事用於分析單個TSQL語句。一樣Stored分類裏面的starting事件和completed事件和TSQL裏面的是同樣的意思。

事件列

列舉經常使用的事件列

TextData:文本詳細信息，好比詳細的執行SQL語句等等。

ApplicationName:鏈接SQLSever的客戶端應用程序名稱。

NTUserName:windows用戶名

LoginName:SQLServer登入用戶名。

CPU:事件佔用的CPU時間，在圖形化界面可是是毫秒（千分之一秒或 10^-3 秒），在文本文件或者數據庫表中單位是微妙（百萬分之一秒或 10^-6 秒）。

Reads:執行邏輯讀的次數。

Writes:物理磁盤寫入的次數。

Duration:事件的持續時間，也就是統計信息裏面顯示的佔用時間，在圖形化界面可是是毫秒（千分之一秒或 10^-3 秒），在文本文件或者數據庫表中單位是微妙（百萬分之一秒或 10^-6 秒）

ClientProcessID:調用SQLServer的應用程序進程ID。

SPID:SQLServer爲鏈接分配的數據庫進程ID，也就是sys.processes裏面記錄的進程ID。

StartTime:事件的開始時間。

EndTime:事件的結束時間。

DBUserName:客戶端的sqlserver用戶名。

DatabaseID:若是指定了USE database就是指定的數據庫id,不然就是默認的數據庫id(也就是master的數據庫id)。因此該列的做用不是很大。

Error:事件的錯誤號，一般是sysmessage中存儲的錯誤號。

ObjectName:正在引用的對象名稱。

3、自帶跟蹤模板

工具自帶了幾個比較實用的跟蹤模板，通常的跟蹤均可以直接使用自帶的跟蹤模板解決，同時本身也能夠建立自定義的跟蹤事件和跟蹤屬性保存成模板供之後使用。

SP_Counts:計算已運行的存儲過程數，而且按存儲過程的名稱進行分組統計，此模板能夠分析某時間段存儲過程的行爲。

Standard:記錄全部存儲過程和T-SQL語句批處理運行的時間，當你想要監視常規數據庫服務器活動時便可使用該模板，通常的跟蹤須要使用該模板就能夠解決，這也是默認的模板。

TSQL:記錄客戶端提交給sqlserver的全部T-SQL語句的的內容和開始時間，一般使用該模板用於程序調試。

TSQL_Duration:記錄客戶端提交給sqlserver的全部T-SQL語句批處理信息以及執行這些語句所需的時間（毫秒），並按時間進行分組，使用該模板能夠分析執行慢的查詢，此模板的跟蹤記錄能夠用於數據庫引擎優化顧問分析使用。

TSQL_Grouped:按提交客戶端和登入用戶進行分組記錄全部提交給SQLServer的T-SQL批處理語句及其開始時間，此模板用於分析某個客戶或者用戶執行的查詢。

TSQL_Locks：記錄全部開始和完成的存儲過程和T-SQL語句，同時記錄死鎖信息，此模板用於跟蹤死鎖。

TSQL_Replay:記錄有關已發出的T-SQL語句的詳細信息，此模板記錄重播跟蹤所需的信息，此模板可執行跌到優化，例如基準測試。

TSQL_SPs:記錄有關執行的全部存儲過程的詳細信息，此模板能夠分析存儲過程的組成步驟。若是你懷疑正在從新編譯存儲過程，請添加SP:Recomple事件

Tuning:記錄有關存儲和T-SQL語句批處理的信息以及執行這些語句所需的時間（毫秒），使用此模板生產跟蹤輸出可用於數據庫引擎優化顧問工做負載來優化索引、優化性能。此模板和TSQL_Druation類似後者是作了時間分組。

 

數據庫引擎優化顧問

---

1.若是須要用數據庫引擎優化顧問分析跟蹤事件記錄必須捕獲瞭如下跟蹤事件：

• RPC:Completed

• SQL:BatchCompleted

• SP:StmtCompleted

也可使用這些跟蹤事件的 Starting 版本。 例如，SQL:BatchStarting。 可是，這些跟蹤事件的 Completed 版本包括 Duration 列，它能使數據庫引擎優化顧問更有效地優化工做負荷。 數據庫引擎優化顧問不優化其餘類型的跟蹤事件。

2.包含 LoginName列

數據庫引擎優化顧問在優化過程當中提交顯示計劃請求。 當包含 LoginName 數據列的跟蹤表或跟蹤文件被用做工做負荷時，數據庫引擎優化顧問將模擬 LoginName 中指定的用戶。 若是沒有爲此用戶授予 SHOWPLAN 權限（該權限使用戶可以爲跟蹤中包含的語句執行和生成顯示計劃），數據庫引擎優化顧問將不會優化這些語句。 

避免爲跟蹤的 LoginName 列中指定的每一個用戶授予 SHOWPLAN 權限

1. 經過從未優化的事件中刪除 LoginName 列來建立新的工做負荷，而後只將未優化的事件保存到新的跟蹤文件或跟蹤表中。

2. 將不帶 LoginName 列的新工做負荷從新提交到數據庫引擎優化顧問。

數據庫引擎優化顧問將優化新的工做負荷，由於跟蹤中未指定登陸信息。 若是某個語句沒有相應的 LoginName，數據庫引擎優化顧問將經過模擬啓動優化會話的用戶（sysadmin 固定服務器角色或 db_owner 固定數據庫角色的成員）來優化該語句。

3.數據庫引擎優化顧問不能執行下列操做：

• 建議對系統表創建索引。
  
  
• 添加或刪除惟一索引或強制 PRIMARY KEY 或 UNIQUE 約束的索引。
  
  
• 優化單用戶數據庫。

4.數據庫引擎優化顧問具備下列限制：

• 數據庫引擎優化顧問經過數據採樣收集統計信息。所以，在相同的工做負荷上重複運行該工具可能生成不一樣的結果。
  
  
• 數據庫引擎優化顧問不能用於優化 Microsoft SQL Server 7.0 或更早版本的數據庫中的索引。
  
  
• 若是爲優化建議指定的最大磁盤空間超過了可用空間，數據庫引擎優化顧問將使用指定的值。可是，當您執行建議腳原本實施它時，若是未先添加更多磁盤空間，則腳本會失敗。可使用 dta 實用工具的 -B 選項指定最大磁盤空間，也能夠經過在「高級優化選項」對話框中輸入值來指定最大磁盤空間。
  
  
• 爲了安全起見，數據庫引擎優化顧問不能優化駐留在遠程服務器上的跟蹤表中的工做負荷。若要解除此限制，能夠選擇如下選項之一：
  
  
  • 使用跟蹤文件而不使用跟蹤表。
    
    
  • 將跟蹤表複製到遠程服務器。
    
    
• 當強制實施約束時，例如爲優化建議指定最大磁盤空間時強制的約束（經過使用 -B 選項或「高級優化選項」對話框），數據庫引擎優化顧問可能會被迫刪除某些現有的索引。在此狀況下，生成的數據庫引擎優化顧問建議可能生成負的預期提升值。
  
  
• 指定限制優化時間的約束時（經過使用 dta 實用工具的 -A 選項或經過選擇「優化選項」選項卡上的「限制優化時間」），數據庫引擎優化顧問可能超過該時間限制，以便針對到當時爲止已處理的工做負荷，生成精確預期的提升值和分析報告。

5.數據庫引擎優化顧問可能在下列狀況下不提供建議：

• 正在優化的表所包含的數據頁數少於 10。
  
  
• 建議的索引對當前物理數據庫設計的查詢性能預計帶來的提升值不夠。
  
  
• 運行數據庫引擎優化顧問的用戶不是 db_owner 數據庫角色或 sysadmin 固定服務器角色的成員。工做負荷中的查詢在運行數據庫引擎優化顧問的用戶的安全上下文中進行分析。該用戶必須是 db_owner 數據庫角色的成員。

6.數據庫引擎優化顧問可能在下列狀況下不提供分區建議：

• 未啓用 xp_msver 擴展存儲過程。此擴展存儲過程用於提取要優化的數據庫所在服務器上的處理器數目以及可用內存。請注意，安裝 SQL Server 後，默認狀況下，此擴展存儲過程處於打開狀態。有關詳細信息，請參閱瞭解外圍應用配置器和 xp_msver (Transact-SQL)。

7.性能注意事項

在分析過程當中，數據庫引擎優化顧問可能佔用至關多的處理器及內存資源。若要避免下降生產服務器速度，請採用下列策略之一：

• 在服務器空閒時優化數據庫。數據庫引擎優化顧問可能影響維護任務性能。
  
  
• 使用測試服務器/生產服務器功能。有關詳細信息，請參閱減輕生產服務器優化負荷。
  
  
• 指定數據庫引擎優化顧問僅分析物理數據庫設計結構。數據庫引擎優化顧問提供許多選項，可是請僅指定所需選項。

注意：因爲數據庫引擎優化顧問進行性能優化時也是將負載記錄中的語句執行一篇查詢分析執行計劃的操做，因此對服務器一樣存在壓力。特別是對於大的負載分析可能須要分析一個小時甚至更長，這樣可能會持續對服務器形成壓力，因此避免在業務高峯期進行使用引擎優化顧問進行負載分析。

實例 

---

接下來就列舉三個案例，使用數據庫引擎優化顧問來分析跟蹤記錄優化索引的案例、監控死鎖的案例、建立自定義跟蹤模板案例。

案例1：優化索引

1.建立測試數據

--建立測試表
CREATE TABLE [dbo].[book](
    [id] [int] NOT NULL PRIMARY KEY,
    [name] [varchar](50) NULL);


--插入10W條測試數據
DECLARE @id int
SET @id=1
WHILE @id<100000
BEGIN
INSERT INTO book values(@id,CONVERT(varchar(20),@id))

SET @id=@id+1
END;

2.建立跟蹤

這裏使用默認的跟蹤模板「tuning」

1.建立好跟蹤後點擊運行便可，事件選擇這裏保持默認

2.執行SQL

SELECT * FROM book WHERE name='10001';

因爲name字段沒有建索引因此該查詢執行計劃分析事後會返回建立name字段的索引，經過引擎優化顧問分析一樣如此

3.中止跟蹤

在使用數據庫引擎優化顧問分析負載跟蹤以前必須先中止跟蹤。

4.打開數據庫引擎優化顧問

能夠直接在profile的工具欄選擇打開，「文件」選擇剛纔的跟蹤文件，「負載數據庫」選擇須要進行優化的數據庫，「選擇要優化的數據庫和表」也就須要優化的數據庫的相關表。優化選項沒有特別的需求選擇默認便可，而後點擊「開始分析」。

引擎優化顧問會自動生成建立索引的腳步，同時還給出了建立該索引以後預計性能能夠提供的百分比，若是同時存在不少表的索引建議能夠勾選須要保存的建議保存成sql文件在「開始分析」欄旁邊有一個保存建議的按鈕能夠將建議保存成sql文件。

建議：

1.數據庫引擎優化顧問給出的建議不是每個都是對的，本身對比該SQL的執行頻率來判斷是否須要建立該索引，好比我當前這個SQL若是我這個SQL只執行了一次後面就不會再執行了那麼這個索引就不必建立了。

2.修改引擎優化顧問給出的索引名，數據庫引擎優化顧問給出的建立索引的索引名不夠直觀，建議本身手動更改，好比改爲「ix_book_name」,「索引標示_表名_字段描述」的規則。

3.用來分析的文件不要太大不然可能會分析不完成，不要在業務高峯期進行分析。

案例2：監控死鎖

1.建立跟蹤

 

模板選擇自帶的「TSQL_Locks」模板，運行跟蹤。

2.執行SQL

打開兩個會話窗口分表執行以下SQL，先在會話1執行而後在10S內在會話2中執行，兩個會話擁有各自的排他鎖同時又去申請對方擁有的排他鎖形成死鎖。

會話1執行：當前會話1是62

BEGIN TRANSACTION
UPDATE book 
SET name='a'
WHERE ID=10

--延時10s執行
waitfor delay '0:0:10'

UPDATE book 
SET name='a'
WHERE ID=100

會話2執行：當前會話2是

BEGIN TRANSACTION
UPDATE book 
SET name='b'
WHERE ID=100

--延時20執行
waitfor delay '0:0:20'

UPDATE book 
SET name='b'
WHERE ID=10

msms客戶端返回的錯誤消息顯示當前62會話做爲死鎖的犧牲品。

3.跟蹤分析死鎖

 死鎖跟蹤事件使用圖形和直觀的返回了兩個會話的死鎖，其中62會話用了一個×表示當前的會話是死鎖的犧牲品。

案例三：建立自定義跟蹤模板

 標準模板就是一個比較好的參考模板，好比咱們對執行語句進行監控就能夠參考標準模板在其基礎上修改保存成本身的模板。

1.建立TSQL語句跟蹤

2.建立跟蹤模板

中止當前的TSQL跟蹤，選擇「文件」-「另存爲跟蹤模板」就能夠保存成本身的跟蹤模板。

3.列篩選

 

當前是篩選跟蹤的TSQL語句中包含book，這裏的列篩選這執行 where like 的語法相似。

整形列的話就不須要帶模糊條件：

注意：若是要取消列篩選記得把剛纔的篩選條件刪除同時把「排除不包含值的行」 的勾選也去除，記得二者都要去掉不然跟蹤仍是包含篩選的跟蹤。

4.列組織

列組織其實就是按某列進行分組顯示跟蹤，相似select查詢裏面的group by操做。好比我當前按持續時間進行分組跟蹤。

經過對持續時間進行分組，相同的持續時間會放在一個分組裏。

總結

 因爲篇幅有限列舉了一些簡單經常使用的操做，其它的分類監控的方法相似有興趣能夠多去研究，profile是很是實用且界面化很好的監控工具這也是SQLServer獨特的條件，應該熟練運用。