很多人在查看SQL語句等待的時候都是通過sys.dm_exec_requests查看,等待類型也是通過wait_type得出,sys.dm_os_waiting_tasks也可以看到session的等待那麼有什麼區別呢....
廢話不多說直接開整.
測試版本2012
sys.dm_os_waiting_tasks 的字段說明:
waiting_task_address
varbinary(8)
等待任務的地址。
session_id
smallint
與任務關聯的會話的 ID。
exec_context_id
int
與任務關聯的執行上下文的 ID。
wait_duration_ms
int
此等待類型的總等待時間（毫秒）。此時間包含 signal_wait_time。
wait_type
nvarchar(60)
等待類型的名稱。
resource_address
varbinary(8)
任務等待的資源的地址。
blocking_task_address
varbinary(8)
當前持有此資源的任務。
blocking_session_id
smallint
正在阻塞請求的會話的 ID。如果此列為 NULL，則表示請求未被阻塞，或鎖定會話的會話信息不可用（或無法進行標識）。
-2 = 阻塞資源由孤立的分布式事務擁有。
-3 = 阻塞資源由延遲的恢復事務擁有。
-4 = 由於內部闩鎖狀態轉換而無法確定阻塞闩鎖所有者的會話 ID。
blocking_exec_context_id
int
正在阻塞的任務的執行上下文 ID。
做個小例子：
-----開啟事務更新一張表並且不提交。 begin tran update t1 set b = getdate() -----做一個查詢 並且開啟並行 select * from t1 inner join t2 on t1.a = t2.a option (querytraceon 8649)
查詢sys.dm_os_waiting_tasks 的結果，udate ：session 55, select : session 54,如圖開一看到session 中出現了
21條等待（虛機給了雙核4線程），那麼可以看出wait_type 為LCK_M_S的有四條，這個可以理解是開並行起了四個線程要掃描表t1全部等待狀態，從 resource_description 字段信息中我們看一下是否是T1表的等待。
從”ridlock fileid=1 pageid=109 dbid=7 id=lock1f03c7700 mode=X associatedObjectId=72057594038910976“ 這個信息中我們知道ridlock fileid=1 pageid=109 dbid=7
dbcc traceon (3604)
dbcc page(7,1,109,3)
確定了LCK_M_S的四條確實是掃描表所產生的等待，那麼其他的CXPACKET等待是什麼鬼？ 從規律中可以看出CXPACKET等待的分成四組每一組4條 exec_context_id分別是 5，6，7，8（四個等待掃表的線程），還有一個上圖中的第十三行“exchangeEvent id=Port1fe7a2200 WaitType=e_waitPortOpen nodeId=0” 應該是調度的線程。
sys.dm_os_waiting_tasks裡在並行計劃的執行中出現了 CXPACKET 和 LCK_M_S 那麼我們來看一下 sys.dm_exec_requests 裡是如何顯示的（這裡只取出試驗用的字段）
blocking_session_id 竟然是0 ， wait_type 竟然是CXPACKET（並行等待，我們知道主要的等待原因不是這個），另外觀察 發現這裡面抓取的TASK_ADDRESS 是調度線程。經過其他實驗得知 sys.dm_exec_requests 在並行的等待中無法獲得真正的等待類型和資源。如果取消並行，執行一個串行計劃兩個視圖得到的結果是一樣的。
例子中我們看出了sys.dm_exec_requests 和sys.dm_os_waiting_tasks 在實際使用中關於並行的區別，但不單單只有這一個疑問，4線程並行計劃為什麼一下會出現21條等待？並行計劃怎麼執行的？ 我們下篇繼續說....
