程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> 其他數據庫知識 >> 更多數據庫知識 >> SqlServer應用之sys.dm_os_waiting_tasks 引發的疑問(上),

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

編輯:更多數據庫知識

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


很多人在查看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條等待?並行計劃怎麼執行的? 我們下篇繼續說....

您可能感興趣的文章:

  • 使用GruntJS構建Web程序之Tasks(任務)篇
  • SqlServer應用之sys.dm_os_waiting_tasks 引發的疑問(中)
  • SqlServer應用之sys.dm_os_waiting_tasks 引發的疑問(下)

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved