SqlServer應(yīng)用之sys.dm_os_waiting_tasks 引發(fā)的疑問(wèn)(上)

更新時(shí)間：2015年12月03日 14:36:51 作者：aiyouheiya

很多人在查看SQL語(yǔ)句等待的時(shí)候都是通過(guò)sys.dm_exec_requests查看,等待類型也是通過(guò)wait_type得出,sys.dm_os_waiting_tasks也可以看到session的等待那么有什么區(qū)別呢....，這篇文章給大家介紹SqlServer應(yīng)用之sys.dm_os_waiting_tasks 引發(fā)的疑問(wèn)(上)，需要的朋友參考下

很多人在查看SQL語(yǔ)句等待的時(shí)候都是通過(guò)sys.dm_exec_requests查看,等待類型也是通過(guò)wait_type得出,sys.dm_os_waiting_tasks也可以看到session的等待那么有什么區(qū)別呢....

　　　　廢話不多說(shuō)直接開(kāi)整.

　　　　測(cè)試版本2012

　　　　sys.dm_os_waiting_tasks 的字段說(shuō)明:

waiting_task_address	varbinary(8)	等待任務(wù)的地址。
session_id	smallint	與任務(wù)關(guān)聯(lián)的會(huì)話的 ID。
exec_context_id	int	與任務(wù)關(guān)聯(lián)的執(zhí)行上下文的 ID。
wait_duration_ms	int	此等待類型的總等待時(shí)間（毫秒）。此時(shí)間包含 signal_wait_time。
wait_type	nvarchar(60)	等待類型的名稱。
resource_address	varbinary(8)	任務(wù)等待的資源的地址。
blocking_task_address	varbinary(8)	當(dāng)前持有此資源的任務(wù)。
blocking_session_id	smallint	正在阻塞請(qǐng)求的會(huì)話的 ID。如果此列為 NULL，則表示請(qǐng)求未被阻塞，或鎖定會(huì)話的會(huì)話信息不可用（或無(wú)法進(jìn)行標(biāo)識(shí)）。 -2 = 阻塞資源由孤立的分布式事務(wù)擁有。 -3 = 阻塞資源由延遲的恢復(fù)事務(wù)擁有。 -4 = 由于內(nèi)部閂鎖狀態(tài)轉(zhuǎn)換而無(wú)法確定阻塞閂鎖所有者的會(huì)話 ID。
blocking_exec_context_id	int	正在阻塞的任務(wù)的執(zhí)行上下文 ID。

做個(gè)小例子：　　

-----開(kāi)啟事務(wù)更新一張表并且不提交。
　　　　begin tran 
　　　　update t1 set b = getdate()
　　　　-----做一個(gè)查詢 并且開(kāi)啟并行
　　　　select * from t1 inner join t2 on t1.a = t2.a
　　　　option (querytraceon 8649)

　　　　查詢sys.dm_os_waiting_tasks 的結(jié)果，udate ：session 55, select : session 54,如圖開(kāi)一看到session 中出現(xiàn)了

21條等待（虛機(jī)給了雙核4線程），那么可以看出wait_type 為L(zhǎng)CK_M_S的有四條，這個(gè)可以理解是開(kāi)并行起了四個(gè)線程要掃描表t1全部等待狀態(tài)，從 resource_description 字段信息中我們看一下是否是T1表的等待。　　　　　　　　

　　　　　從”ridlock fileid=1 pageid=109 dbid=7 id=lock1f03c7700 mode=X associatedObjectId=72057594038910976“ 這個(gè)信息中我們知道ridlock fileid=1 pageid=109 dbid=7 　　

　　　　dbcc traceon (3604)
　　　　dbcc page(7,1,109,3)

確定了LCK_M_S的四條確實(shí)是掃描表所產(chǎn)生的等待，那么其他的CXPACKET等待是什么鬼？從規(guī)律中可以看出CXPACKET等待的分成四組每一組4條 exec_context_id分別是 5，6，7，8（四個(gè)等待掃表的線程），還有一個(gè)上圖中的第十三行“exchangeEvent id=Port1fe7a2200 WaitType=e_waitPortOpen nodeId=0” 應(yīng)該是調(diào)度的線程。

　　　　sys.dm_os_waiting_tasks里在并行計(jì)劃的執(zhí)行中出現(xiàn)了 CXPACKET 和 LCK_M_S 那么我們來(lái)看一下 sys.dm_exec_requests 里是如何顯示的（這里只取出試驗(yàn)用的字段）

　　　　blocking_session_id 竟然是0 ， wait_type 竟然是CXPACKET（并行等待，我們知道主要的等待原因不是這個(gè)），另外觀察發(fā)現(xiàn)這里面抓取的TASK_ADDRESS 是調(diào)度線程。經(jīng)過(guò)其他實(shí)驗(yàn)得知 sys.dm_exec_requests 在并行的等待中無(wú)法獲得真正的等待類型和資源。如果取消并行，執(zhí)行一個(gè)串行計(jì)劃兩個(gè)視圖得到的結(jié)果是一樣的。

　　　　例子中我們看出了sys.dm_exec_requests 和sys.dm_os_waiting_tasks 在實(shí)際使用中關(guān)于并行的區(qū)別，但不單單只有這一個(gè)疑問(wèn)，4線程并行計(jì)劃為什么一下會(huì)出現(xiàn)21條等待？并行計(jì)劃怎么執(zhí)行的？我們下篇繼續(xù)說(shuō)....

您可能感興趣的文章: