若想對數(shù)據庫當前連接情況查看，一般可以使用系統(tǒng)自帶的存儲過程sp_who以及sp_who2來查看：

exec sp_who
exec sp_who2

對于像tomcat這樣搭建的java服務器來說，很多時候除了要看數(shù)據庫的所有連接情況外，還經常（本人）要且僅要查看tomcat所在的服務器的java程序通過jdbc創(chuàng)建的數(shù)據庫連接，于是有了以下方式的查詢（簡單的過濾了一下）：

create Table #temppp(
  SPID int,
  Status varchar(100),
  Login varchar(100),
  HostName varchar(100),
  BlkBy varchar(100),
  DBName varchar(100),
  Command varchar(100),
  CPUTime int,
  DiskIO int,
  LastBatch varchar(100),
  ProgramName varchar(100),
  SPID2 int,
  REQUESTID int
)
insert into #temppp exec sp_who2
select * from #temppp
 where HostName = 'PCNAME' and ProgramName = 'Microsoft SQL Server JDBC Driver'
drop table #temppp
 
 
 
SQL SERVER 查詢性能優(yōu)化——分析事務與鎖（三） 
上接SQL SERVER 查詢性能優(yōu)化——分析事務與鎖（二）
 
接下來看看SP_WHO2這個系統(tǒng)存儲過程，如果你查詢這個系統(tǒng)存儲過程的源代碼，就可以發(fā)現(xiàn)這個系統(tǒng)存儲過程是整理master.sys.sysprocesses系統(tǒng)視圖中的內容。在此用sp_who2來說明一下。
第一步，在查詢分析器中執(zhí)行例二，例三代碼。(就是上一篇文章SQL SERVER 查詢性能優(yōu)化——分析事務與鎖（二）中的示例)--例二
第二步，再打開一個查詢分析器界面，在此界面中輸入exec sp_who2，如下圖，在此界面中你可以很容易的觀察到鎖與被鎖的關聯(lián)，看到進程“56”被“53”鎖住。
Use testGoBegin tranupdate book set Name='MS SQL 2008'where bookid=1---切換到另一個查詢界面，執(zhí)行以下代碼--例三Use testGoselect * from Book where bookid=1go 
 
 
 
 
你可以通過dbcc inputbuffer(53)來查看進程“53”所執(zhí)行的查詢語句。如下圖1、2。
 
Sql 2008中的 wbk_pde_list表
 
 
圖1
Book表
 
圖2
 
當然，如果你使用SQL SERVER 2005也可以通過Microsoft SQL Server Management Studio中的“活動監(jiān)視器--》進程信息”直接以鼠標雙擊某條進程，便可以看到此進程所執(zhí)行的查詢語句。如下圖3。
 
 圖3
你還可以通過sp_lock系統(tǒng)存儲過程來觀察進程“53”和“56”的結果。執(zhí)行如下命令
Exec sp_lock 53
Exec sp_lock 56
然后得到如下圖結果：
Book表
 
圖4
 
以上語句執(zhí)行結果，同SQL SERVER 2005中的Microsoft SQL Server Management Studio中的“活動監(jiān)視器--》按進程分類的鎖”有異曲同工之處。
Sql 2005
 
 圖5
當然在Sql 2008中就只能執(zhí)行以下的SQL 語句了。
Exec sp_lock 54
Exec sp_lock 55
 
圖6
 
如上，圖6中的Type字段如果是PAG，則Resource表示的是該分頁在數(shù)據庫的第幾個文件上。以及分頁編號。我們可以通過DBCC PAGE來觀察該分布。
 如果indId為1，則表示為聚集索引，則dbcc page查詢出來的是整個分頁的細節(jié)，如果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) 數(shù)據庫名稱,OBJECT_NAME(117575457) 表名,(select name from sys.indexes where OBJECT_ID=117575457 and index_ID=54) 索引名稱
 
 
 
 
另外可以打開 SQL Profiler觀察多人交互情況。
 
 
綜上所述，你可以從以下幾方面來觀察數(shù)據庫是否因為鎖與被鎖而造成系統(tǒng)運行出現(xiàn)問題。
1.通過Microsoft SQL Server Management Studio或SP_WHO2系統(tǒng)存儲過程來觀察數(shù)據庫中是否有許多進程被鎖。
2.觀察master.sys.sysprocesses系統(tǒng)視圖內，被鎖進程中的waittime字段的值是否異常的大。
3.SQL Profiler工具所錄制的結果中，有許多attention事件，代表SQL語句執(zhí)行過久沒有響應，前端程序放棄執(zhí)行。
4.SQL SERVER所在服務器并沒有顯的很忙碌。例如，CPU，內存，硬盤，網絡等硬件資源使用率并不是很高，但系統(tǒng)的效率卻不高，或是正相反，上述資源由于某個操作而持續(xù)高度使用，但是該操作一直做不完，導致它持有的資源都無法釋放。
5.通過Microsoft SQL Server Management Studio、性能監(jiān)視器、SQL PROFILER等結果，進行交叉分析以相互印證。
分類: 數(shù)據庫
綠色通道： 好文要頂 關注我 收藏該文與我聯(lián)系 
 
DotNet菜園
關注 - 1
粉絲 - 126 
+加關注 
2 
0 
(請您對文章做出評價) 
 上一篇：SQL SERVER 查詢性能優(yōu)化——分析事務與鎖（二）
 下一篇：SQL SERVER 查詢性能優(yōu)化——分析事務與鎖（四）

其中紅色背景的“PCNAME”替換為需要查看的發(fā)起連接的計算機名即可。