1 0 .2 用於監視的工具和技術

第 3 章從功能的角度介紹了不少可用的工具，而本章將從實現的角度介紹這些工具，
並討論如何使用它們來實際執行一些關鍵的數據庫監視任務。本章還涉及了一些第3 章中
沒有介紹的工具，由於它們雜亂地結合到了 SQL Server Management Studio中。

1 0 .2 .1 日誌文件查看器
日誌文件査看器(Log Hie Viewer)是一個很出色的工具，能夠用它在一個一次性關聯的 視圖中査看SQL Server和操做系統日誌。例如，來自於系統日誌的內存子系統錯誤能夠和 SQL Server錯誤關聯在一塊兒，指示內存不足的狀況，並容許將問題與SQL Server隔離開來。 要打開日誌文件査看器，可 在 SQL Server Management Studio中 展 開 「管理」文件夾，然 後 展 開 「SQL Server日誌」文件夾，右擊想査看的日誌，然 後 選 擇 「查 看 SQL Server日誌」 命令。在日誌文件查看器打開以後，能夠選擇打開其餘SQL Server 0 志和/或操做系統曰志, 方法是展幵並選擇想查看的日誌(如圖10-2所示)。可注意到，還能夠打開SQL Server代理 和數據庫郵件的日誌文件。

每 次 重 啓 SQL Server和 SQL Server代理服務時，會關閉各自的日誌文件並打開一個新 的日誌。在一個生產系統中，這種狀況可能不會常常發生，因而就會造成一個較大的日誌
文件。要想避免出現過於龐大的日誌文件，必須導出日誌文件的內容，而後再循環使用該
文件。要想循環使用SQL Server日誌，可 以 執 行 spjyclejrrodog存儲過程。要想循環使 用代理日誌，可 以 使 用 sp_CyCk_agen t_errOrk>g存儲過程。這些過程能夠清除日誌的內容而 不要求重啓服務。
可 以 右 擊 「SQLServer日誌」文件夾，然 後 選 擇 「配置」命令來配置SQL Server保留 的日誌數量，如 圖 10-3所示。最小的(也是默認的)數量是6 , 但能夠增長到99。日誌數量
不能小於6。

10.2.2活動監視器
Microsoft在 SQL Server 2008的最後一個候選發佈版中包含了一個徹底革新的活動監 視器(Activity Monitor)。這 令 SQL Server社區感到意外，由於活動監視器已經再也不位於其 原來的位置上，許多感到擔優的DBA在支持論壇上發佈了大量的相關帖子。顯然，這也
讓 Microsoft聯機叢書團隊感到意外，由於在編寫本書時，他們仍在引用原來的活動監視器 的文檔。
SQL Server 2008中的活動監視器如今是一個功能豐富的、接近實時的圖形化性能面
板。新的活動監視器的外觀與Windows Vista和 Windows Server 2008系統中的可靠性和性
能監視器相似。有經驗的DBA將注意到的第一件事是活動監視器再也不位於SQL Server Management的 「管理」節點下，而是在SQL Server實例的上下文菜單中。 活動監視器是一個能夠幫助對服務器的總體運行情況和性能有更深刻理解的優秀工
具。與前面的版本相比，它再也不只顯示簡單的進程和鎖定信息。它如今顯示直觀的圖形、
詳細的進程和鎖定信息、文件I/O統計信息和長時間運行的査詢的信息。另外，如今能夠
對全部的網格視圖進行排序和篩選。活動監視器不能取代有經驗的DBA所掌握的一組優
秀的數據管理視圖，但它能夠很好地回答「爲何服務器運行如此緩慢」這個基本問題。
要運行活動監視器，需 要 具 有 view server state權限。要終止任何進程，還須要是
sysadmin或 processadmin服務器角色的成員。新的活動監視器能夠在SQL Server 2005上工
做，但在以前的版本上不能運行。

活動監視器由5 個主要部分構成，分別是：概述、進程、資源等待、數據文件I/O和
磁近耗費大量資源的査詢。
• 概述—— 「概述」部分顯示了 4 個表示關鍵性能度量指標的接近實時的圖形。右
擊圖形將能夠調整刷新率或暫停數據收集。
• 進程一 「進程」部分爲每一個與SQL Server的鏈接列出了一行，並有一些列來描 述該進程(如與該鏈接關聯的用戶、數據庫t 下文、當前運行的命令以及全部的等 待狀態和阻塞信息)。右擊一個進程並選擇「詳細信息」命令將顯示在該鏈接上最
後一個執行的命令，並提供了在必要時終止該進程的功能。右擊一個進程所顯示
的上下文菜單中有一個「SQL Server Profiler中的跟蹤進程」的選項。圖 10-4演示 了這一行爲。另外在圖10-4中可看到，進 程 59是掛起的，由於它在等待被進程
57鎖定的資源，然後者又在等待被進程60鎖定的資源。

資源等待—— 「資源等待」部分妞示一個全部資源等待(CPU、Latch、Memory、
Buffer I/O等)的完整列表。這個列表並不提供任何鑽取功能，但能夠篩選和排序結果。 • 數據文件I/O—— 「數據文件I/O」 部分顯示了數據庫文件的活動總計信息。能夠
對這個列表進行篩選和排序。
• 最近耗費大量資源的查詢—— 這是活動監視器中新添加的-個很是優秀的選項。
「最近耗費大量資源的査詢」部分顯示了全部最近、最耗費資源的査詢，容許在
一個新的查詢窗U中打開某個完整的査詢語句或詳細的執行計劃。圖 10-5顯示了
這個部分以及一個耗費大量資源的査詢的文菜單選項。

默認狀況下，活動監視器將每10秒刷新一次顯示結果。要將活動監視器配置爲另外
一個刷新率，可右擊任意圖形，選擇所需的刷新間隔或選擇「暫停」命令禁用刷新。記住，
頻繁刷新進程信息會致使SQL Server性能降低。
1 0 .2 .3 系 統 存 儲 過 程
雖然就査看進程以及它們使用的資源而言，活動監視器是一個很好的圖形工具，但通
常來講，系統存儲過程的輸出更簡單，更適合用來識別當前進程以及任意資源競爭。
1. sp_who 和 sp_who2
sp_who2存儲過程是一個未歸檔的系統過程，和已歸檔的同類存儲過程sp_who相比， 它有顯著的優點。它們都返回當前SQL Server進程的信息，可是sp_who2過程返回的信息更 加全面。
這些存儲過程本質上等同於活動監視器的「進程」頁。sp_who或 sp_who2的輸出能夠通 過指定一個進程ID做爲輸入參數加以限制。sp_who和 sp_who2過程的語法以下所示：
s p _ w h o [p ro c e s s _ _ I D ] , l o g i n n am e | (A CTIV E]
s p _ w h o 2 [ p r o c e s s _ I D ] I [ACTIV E]
sp who相儲過程返回表10-3中描述的9 列。

sp_who2存儲過程返回了 13列，但它返冋了 spid列兩次，一次在結果集的左邊， 次在結果集的右邊，以使結果集的讀取更加容易。這些列如表10-4所示。

當 把 Active選 項 添 加 到 sp_who或 sp_who2時 ，SQL Server不會返回任何狀態爲
Awaiting Command的會話，該狀態指明會話正在等待一個用戶進程的輸入。
2. sp_lock
spJock存儲過程返回活動數據庫進程所持有的鎖的數目和類型。已鎖定的或將要被鎖 定的對象會和鎖定狀態以及任何標識信息(例如對象的整型標識符)一塊兒返冋，另外還會返
回 索 引 ID(若是有的話)。
3. SQL Server 鎖定
要 解 讀 spjock返回的信息，瞭解可鎖定的資源類型和這些鎖能夠採用的模式是很重 要的。可能的資源類型如表10-5所示。

資源類型上的鎖經過模式請求和授予。spjock存儲過程返回標識鎖模式的信息(例如鎖 是一個共享鎖仍是排他鎖)。表 10-6列出了最多見的模式。

4. KILL命令
雖然KILL命令不是一個存儲過程，但它使數據庫管理員能夠終止一個違反規則的進程,
就像圖10-4所示的「進程屬性」對話框中的「終止進程」按鈕同樣。KILL命令的語法如

下所示:
KILL s p id
KJLL命令頗有用，但使用時須要至關當心。雖然有時候有必要終止一箇中斷的進程,
可是在終止它以前蒐集與它有關的儘量多的信息仍是很重要的。例如，終止一個已更新
了 1000行的事務會致使這1000行冋滾，這會產生一些不但願看到的結果，例如事務日誌
填滿或數據丟失。

試一 試系統存儲過程
如今看系統存儲過程返回了什麼信息，以及如何使用它們隔離有問題的進程。
(1)打開一個查詢窗口。輸入並執行下列代碼：
USE AdventureWorks2008; GO
BEGIN TRAN
UPDATE Person.Person SET LastName =*Gates'
WHERE BusinessEntitylD =1;
(2) 打開另外一個査詢窗口。輸入並執行下列代碼：
USE AdventureWorks2008; GO
SELECT * FROM Person.Person WHERE BusinessEntitylD =1;
在執行此語句時不會看到任何返冋的結果。由於在第一個查詢釋放其鎖定以前，此語
句不會完成執行。
(3) 如今打開第三個査詢窗口，執行下列命令運行sp_who系統存儲過程：
EXEC spwho;
注意，其中一個進程顯示它被另外一個會話阻塞。如圖10-6所示，SPID 59被 SPID 60阻塞。

 

(4) 執 行 sp_who2存儲過程，但將結果集限制爲阻塞會話的服務器進程ID(Server
Process ID, SPID)。在這裏，spid 是 60。
EXEC sp_who2 60;
執 行 sp_who2存儲過程所獲得的更加全面的結果會返回很是有用的信息(例如形成阻 塞的程序和用戶，以及會話執行負責鎖爭用的命令的時間)。
(5) 肯定哪一個對象在被兩個進程競爭。執 行 sp lock存儲過程。和 sp_who及 sp_who2 存儲過程同樣，能夠經過傳遞合適的進程ID限制過程的結果。 _ _
(6) 輸入並執行下列命令以顯示有關被阻塞的SPID的信息。該 SPID在 sp_who2結果 的 BlkBy列中返回了一個值。在本例中這個值是5 9 ,可是您的SHD頗有可能不同：
EXEC sp_lock 59;
結果如圖10-7所示。

在 圖 10-7中能夠注意到，已經請求和授予了一些鎖，但彙集索引鍵010086470766(表
示 Person.Person表 中 BusinessEntitylD爲 1 的聯繫人)上的共享鎖處於WAIT狀態。這是因
爲 spid 60當前正在修改該行，並在該鍵上持有一個排他鎖。
要終止阻塞進程，須要執行KJLL命令並指定合適的SPID,在這裏是60:
KILL 60;
注意：
在終止進程時要當心。SPID 60是個人機器上的進程。您的結果可能和個人不同!
10.2.4 使用 Profiler
第 3 章介紹了 Profiler的基本功能。本節將介紹如何蒐集性能信息來隔離和糾正數據 庫應用程序的問題。對所提供跟蹤的指導原則能夠結合到一個綜合性跟蹤中或者單獨實施。
使用Profiler時另外一個重要的考慮事項是開銷。交互式運行Profiler會致使大量服務器 開銷，以及較大的不肯定因素。Profiler只是一個查看SQL跟蹤的圖形化界面。它是一個 很好的工具，但對於有着繁重事務負荷的大型數據庫來講，可能須要使用sp_trace_setevent,
sp_trace_setfilter、sp_trace_setstatus和 sp」race_create存儲過程，經過文件中搜集的跟蹤數
據建立、配置和運行跟蹤。而後可使用Profiler直接經過蒐集的文件查看這些數據，或 者能夠將它們導入到一個數據庫中以供分析。

 

試一試 使 用 Profiler分 析 死 鎖
如前所述，使用性能監視器檢測死鎖很容易。但要找出死鎖發生的緣由則較爲困難，
須要經過Profiler運行跟蹤和檢査收集的數據。
(1 )打開 SQL Server Management Studio,鏈接到駐留 AdventureWorks2008 數據庫的服
務器。在鏈接後經過「工具」菜單啓動SQL Server Profiler,建立一個基於「空白」模板的 新跟蹤，如 圖 10-8所示。.

 

 

(2 )在 「事件選擇」選項卡上，選擇Deadlock graph和 Lock:Deadlock Chain事件，如
圖 10-9所示。注意，若是選擇了 Deadlock graph事件，則會出現「事件提取設置」選項卡。

(3 )要限制返回給Profiler的數據，單擊「列篩選器」按鈕，而後選擇DatabaseName。在 「不相似於」文本框中，輸入MSDB以免跟蹤SQL代理和計劃的監視活動。單擊「肯定」

按鈕。
圖 10-10顯示了想要使用的配置。篩選數據庫時要當心。您可能認爲最佳篩選器應該
是經過數據庫ID或數據庫名稱指定特定數據庫的篩選器。可是，有不少Profiler事件沒有 一個特定的數據庫上下文，因此若是這樣設置篩選器的話，它們將不會顯示。所以，必須
告訴Profiler不要監視哪些數據庫。deadlock graph就是這樣一個事件。

(4)在 「事件提取設置」選項卡上，選中「分別保存死鎖XML事件」複選框，而後輸
入一個位置來保存文件(如圖10-11所示)。選 中 「不一樣文件中的每一個死鎖XML批」單選按
鈕，而後單擊「運行」按鈕。

(5 )在 SQL Server Management Studio中，打幵兩個新的査詢窗口。
⑹在第一個査詢窗 口 中 (可 能 叫 作 SQLQueryl.sql),輸入以下代碼並執行:
—— Connection 1 USE AdventureWorks2008; GO
BEGIN TRAN
UPDATE Person.Address SET City = * Redmond * WHERE AddressID =1;

(7)在第二個查詢窗口中輸入以下代碼並執行:
—— Connection 2 USE AdventureWorks2008; GO
BEGIN TRAN
UPDATE Person.Person SET LastName =*Gates'
WHERE BusinessEntitylD =1; UPDATE Person.Address SET AddressLinel = * 1 Microsoft Way* WHERE AddressID =1;
此更新將不會完成，因 爲 Connection 1 中的事務在想要更新的Person.Person表的行上 有一個排他鎖。此時發生的是一個阻塞鎖。Connection2中的事務想要更新被Connection 1 阻塞的行。阻塞鎖是容許的，並且除非設置了鎖定超時值、阻塞的事務完成或者管理員終
止了阻塞的事務，不然此鎖就會一直存在。
(8 )在第一個鏈接上，編寫並執行以下代碼以更新Person.Person表：
--Connection 1
UPDATE P erson.P erson
SET FirstName = *Bill'
WHERE BusinessEntitylD =1;
此更新會致使一個死鎖發生，由於兩個鏈接在對立事務完成所需的資源上都持有排他鎖。
死鎖會被檢測到，其中一個死鎖的進程將被終止。留下的進程將成功運行。
(9 )返回到Profiler,中止跟蹤，而後選擇Deadlock graph事件類行。死鎖圖形顯示了
被死鎖的服務器進程ID和已鎖定資源。將鼠標指針懸停在一個進程上面會顯示參與死鎖的
進程，如 圖 10-12所示。

提示：
要將Person.Person表還原至初始狀態，須要在沒有被死鎖終止的事務上執行ROLLBACK 語句。
(10)要捕捉用來運行這個跟蹤的腳本，單擊SQL Profiler中 的 「文件」菜單，而後選 擇 「導出」 | 「編寫跟蹤定義的腳本」丨「用於 SQL Server 2005-2008」 選項，如 圖 10-13所 示。這時 將 出 現 -個 「另存爲」對話框。將該腳本保存爲DeadLockTrace.SQL。

(11)打開使用 SQL Server Management Studio 保存的 DeadLockTrace.SQL 文件。SQL
Server運行此腳原本建立剛纔執行的跟蹤。保存這個腳本以後，能夠在任意時間運行它， 而不須要啓動和運行Profiler。要知道有關每一個存儲過程的更多信息，請 參 閱 SQL Server 聯機叢書，裏面有至關詳細的討論。
在捕捉到跟蹤文件後，可使用SQL Profiler打開它，或者若是跟蹤較大，能夠把它
插入表，以便使用傳統的T-SQL査詢分析。要把數據移動至表中，可使用fh_trace_gettable
表值函數。此表值函數須要兩個值：須要導入的跟蹤文件的名稱和須要蒐集的滾動更新文
件的最大值。默認的文件數目是爲跟蹤設置的最人文件數。下面的例子顯示瞭如何將以前
蒐集的跟蹤添加到AdventureWorks2008數 據 庫 中 的 個 叫 作 DeadLockTraceTable的表裏：
USE AdventureWorks2008; GO
SELECT * INTO DeadLockTraceTable FROM fn_trace_gettable(C:\ProfilerTraces\DeadLocks.trc1, NULL);
使用Profiler檢測和分析長吋間運行的查詢 Profiler是一個很好的工具，能夠用於分析鎖，以及調試存儲過程和數據庫應用程序。

 

試一試
它也可用於檢測和分析影響SQL Server性能的長時間運行的査 詢 。Profiler能夠返回査詢 執行信息，數據庫管理員能夠經過這些信息找出致使冗長査詢的緣由。是代碼寫得很差嗎？
是否沒有索引支持査詢？或者這只是一種奇怪的查詢？
分析查詢
要分析查詢，須要遵循下列步驟：
(1) 啓 動 Profiler,使 用 「空白」模板建立一個叫作QueryTuning的新跟蹤。在 「事件 選擇」選項卡上選擇下列事件：
• Performance： ShowPlan XML • Stored Procedures： SP: Completed
• TSQL： SQL: BatchCompleted
(2) 單擊「列篩選器」按鈕建立一個篩選器，其中數據庫名稱「相似於」AdventureWOrks2008, 而後單擊「肯定」按鈕應用該篩選器。
(3) 單 擊 「組織列」按 鈕 。找 到 Duration列 ，將其移至列列表的頂部，使得易於閱讀 持久數據。
(4) 在 「事件提取設置」選項卡上，選 中 「分別保存XML顯示計劃事件」複選框。選
擇 一 個 保 存 ShowPlan信息的位置，將文件命名爲Query Tuning,然 後 選 擇 「不一樣文件中的 每 個 XML顯示計劃批」選 項 。SQLPlan是 給 予 ShowPlan數據的文件擴展。ShowPlan數據 存 儲 爲 XML格式，而且可使用Management Studio査看(後面將會介紹)。當將査詢計劃 保存在單獨的文件中時，每一個文件都採用在目標位置中定義的名稱，而且名稱後面附加有
數字標識符。
(5) 單 擊 「運行」按鈕運行此跟蹤。
(6) 接下來，在 SQL Server Management Studio中 打 開 一 個 新查詢窗口。輸入並執行下
列代碼：
USE AdventureWorks2008; GO
SELECT P.ProductID, P.name AS Product, TH.TransactionDate, SUM(TH.Quantity), SUM(TH.ActualCost), SUM(P.StandardCost) FROM Production.Product P INNER JOIN Production.TransactionHistory TH ON P.ProductID = TH.ProductID GROUP BY P.ProductID, P.Name, TH.TransactionDate;
GO
EXEC dbo.uspGetManagerEmployees 109;
GO
EXEC dbo.uspGetEmployeeManagers 1;
GO
SELECT P.name AS Product, SUM(SOD.OrderQty) AS SumQty , SUM(SOD.UnitPrice) AS SumPrice, SUM(SOD.LineTotal) AS SumTotal , CONVERT(char(10), SOH•OrderDate,101) AS orderDate , CONVERT(char(10), SOH.ShipDate,101) AS ShipDate , CONVERT(char(10)r SOH.DueDate,101) AS DueDate

FROM Sales.SalesOrderDetail SOD
INNER JOIN Sales.SalesOrderHeader SOH
ON SOH.SalesOrderlD = SOD.SalesOrderlD INNER JOIN Production.Product P ON P.ProductID = SOD.ProductID
GROUP BY P.Name, SOH.OrderDate, SOH.ShipDate, SOH.DueDate;
査詢完成以後，中止跟蹤並檢查結果。可注意到，運行時間最長的進程是最後一個進
程 ，它引用了 Sales.SalesOrderHeader 表、Sales.SalesOrderdetail 和 Production. Product 表 0
(7) 導 航 至 ShowPlan目標文件夾並檢 査 內 容 。應 該 看 到 4 個 文 件 ，分別從
QueryTuning l.SQLPlan 到 QueryTuning_4.SQLPlan 進行命名。 (8) 雙擊 QueryTuning_4.SQLPlan 文件。這將啓動 SQL Server Management Studio，並
把該文件做爲一個圖形 化 &行計劃打開，如圖10-14所示。

在評估數據庫引擎用來優化査詢的實際進程和識別可改進的區域方面，ShowPlan文件 很是有用。對於ShowPlan,應該從右到左閱讀。把鼠標指針懸停在一個圖標上會顯示該圖 標描述的進程的附加信息，這有助於決定如何優化該進程。例如，若是一個進程顯示了一 個沒必要要的隱式轉換，則能夠對傳遞的數據類型執行更嚴格的檢査以免隱式轉換。提示：圖 10-14中顯示的信息實際上被保存爲XML。這對於那些想在用於分析查詢計劃和識別 要改進的區域的分析應用程序(例如數據庫優化顧問）中使用ShowPlan數據的組織來講特別有 吸引力。將名稱 QueryTuning_4.SQLPlan 改成 QueryTuning_4.XML„ 右擊 QueryTuning_4.XML 文件，選擇「打開方式… Internet Explorer」命 令 。顯 示 的 ShowPlan文件經過Internet Explorer 內置的XML分析器呈現，並很容易被標識爲一個XML文件•