欧美bbbwbbbw肥妇,免费乱码人妻系列日韩,一级黄片

SqlServer應用之sys.dm_os_waiting_tasks 引發(fā)的疑問(上)

 更新時間:2015年12月03日 14:36:51   作者:aiyouheiya  
很多人在查看SQL語句等待的時候都是通過sys.dm_exec_requests查看,等待類型也是通過wait_type得出,sys.dm_os_waiting_tasks也可以看到session的等待那么有什么區(qū)別呢....,這篇文章給大家介紹SqlServer應用之sys.dm_os_waiting_tasks 引發(fā)的疑問(上),需要的朋友參考下

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

    廢話不多說直接開整.

    測試版本2012

    sys.dm_os_waiting_tasks 的字段說明:

waiting_task_address

varbinary(8)

等待任務的地址。

session_id

smallint

與任務關聯(lián)的會話的 ID。

exec_context_id

int

與任務關聯(lián)的執(zhí)行上下文的 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 = 由于內部閂鎖狀態(tài)轉換而無法確定阻塞閂鎖所有者的會話 ID。

blocking_exec_context_id

int

正在阻塞的任務的執(zhí)行上下文 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 中出現(xiàn)了

21條等待(虛機給了雙核4線程),那么可以看出wait_type 為LCK_M_S的有四條,這個可以理解是開并行起了四個線程要掃描表t1全部等待狀態(tài),從 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的四條確實是掃描表所產(chǎn)生的等待,那么其他的CXPACKET等待是什么鬼? 從規(guī)律中可以看出CXPACKET等待的分成四組每一組4條 exec_context_id分別是 5,6,7,8(四個等待掃表的線程),還有一個上圖中的第十三行“exchangeEvent id=Port1fe7a2200 WaitType=e_waitPortOpen nodeId=0”  應該是調度的線程。

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

    

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

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

相關文章

最新評論