上接SQL SERVER 查詢性能優化——分析事務與鎖（二）
接下來看看SP_WHO2這個系統存儲過程，如果你查詢這個系統存儲過程的源代碼，就可以發現這個系統存儲過程是整理master.sys.sysprocesses系統視圖中的內容。在此用sp_who2來說明一下。
第一步，在查詢分析器中執行例二，例三代碼。(就是上一篇文章SQL SERVER 查詢性能優化——分析事務與鎖（二）中的示例)--例二
第二步，再打開一個查詢分析器界面，在此界面中輸入exec sp_who2，如下圖，在此界面中你可以很容易的觀察到鎖與被鎖的關聯，看到進程“56”被“53”鎖住。
Use test Go Begin tran update book set Name='MS SQL 2008' where bookid=1 ---切換到另一個查詢界面，執行以下代碼 --例三 Use test Go select * from Book where bookid=1 go
你可以通過dbcc inputbuffer(53)來查看進程“53”所執行的查詢語句。如下圖1、2。
Sql 2008中的 wbk_pde_list表
圖1
Book表
圖2
當然，如果你使用SQL SERVER 2005也可以通過Microsoft SQL Server Management Studio中的“活動監視器--》進程信息”直接以鼠標雙擊某條進程，便可以看到此進程所執行的查詢語句。如下圖3。
圖3
你還可以通過sp_lock系統存儲過程來觀察進程“53”和“56”的結果。執行如下命令
Exec sp_lock 53
Exec sp_lock 56
然后得到如下圖結果：
Book表
圖4
以上語句執行結果，同SQL SERVER 2005中的Microsoft SQL Server Management Studio中的“活動監視器--》按進程分類的鎖”有異曲同工之處。
Sql 2005
圖5
當然在Sql 2008中就只能執行以下的SQL 語句了。
Exec sp_lock 54
Exec sp_lock 55
圖6
如上，圖6中的Type字段如果是PAG，則Resource表示的是該分頁在數據庫的第幾個文件上。以及分頁編號。我們可以通過DBCC PAGE來觀察該分布。
如果indId為1，則表示為聚集索引，則dbcc page查詢出來的是整個分頁的細節，如果IndId大於1，則表示為非聚集索引，則dbcc page查詢出來的是索引鍵值與哈希值。如下圖7。
Dbcc traceon(3604)
dbcc page(28,1,10683,3)
Book
圖7
結合圖5對象ID、說明與圖7中的KeyHashValue字段相比較，就可以進一步看出什么樣的記錄被鎖住了。
也可以結合結合圖6中的RESOURCE與圖7中的KeyHashValue字段相比較，就可以進一步看出什么樣的記錄被鎖住了。
注：此處的圖7不是圖6的明細。
select db_name(28) 數據庫名稱,OBJECT_NAME(117575457) 表名 ,(select name from sys.indexes where OBJECT_ID=117575457 and index_ID=54) 索引名稱
另外可以打開 SQL Profiler觀察多人交互情況。
綜上所述，你可以從以下幾方面來觀察數據庫是否因為鎖與被鎖而造成系統運行出現問題。
1.通過Microsoft SQL Server Management Studio或SP_WHO2系統存儲過程來觀察數據庫中是否有許多進程被鎖。
2.觀察master.sys.sysprocesses系統視圖內，被鎖進程中的waittime字段的值是否異常的大。
3.SQL Profiler工具所錄制的結果中，有許多attention事件，代表SQL語句執行過久沒有響應，前端程序放棄執行。
4.SQL SERVER所在服務器並沒有顯的很忙碌。例如，CPU，內存，硬盤，網絡等硬件資源使用率並不是很高，但系統的效率卻不高，或是正相反，上述資源由於某個操作而持續高度使用，但是該操作一直做不完，導致它持有的資源都無法釋放。
5.通過Microsoft SQL Server Management Studio、性能監視器、SQL PROFILER等結果，進行交叉分析以相互印證。