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表的等待?! ?br />
從”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ō)....
相關(guān)文章
SQL Server實(shí)現(xiàn)查詢每個(gè)分組的前N條記錄
這篇文章介紹了SQL Server實(shí)現(xiàn)查詢每個(gè)分組的前N條記錄,文中通過(guò)示例代碼介紹的非常詳細(xì)。對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2022-06-06SQL Server代理服務(wù)無(wú)法啟動(dòng)的解決方法
錯(cuò)誤MSSQLSERVERSQLServerAgent could not be started (reason: SQLServerAgent 必須能夠以 SysAdmin 身份連接到 SQLServer,但“(未知)”不是 SysAdmin 角色的成員)2013-02-02sql 存儲(chǔ)過(guò)程分頁(yè)代碼 支持億萬(wàn)龐大數(shù)據(jù)量
sql 存儲(chǔ)過(guò)程分頁(yè)代碼 支持億萬(wàn)龐大數(shù)據(jù)量,需要的朋友可以參考下。2011-09-09分享整理的12條sql語(yǔ)句連同數(shù)據(jù)
原本sql寫(xiě)得也不好,近幾年數(shù)據(jù)庫(kù)用得少,sql更是荒廢了,最近復(fù)習(xí)sql,網(wǎng)上例 子很多,但都只是提供sql例子,沒(méi)有配套的數(shù)據(jù)用來(lái)自己練習(xí)和調(diào)試2012-06-06CentOS8安裝SQLServer2019的過(guò)程
這篇文章主要介紹了CentOS8安裝SQLServer2019的步驟,本文通過(guò)命令實(shí)例相結(jié)合給大家介紹的非常詳細(xì),對(duì)大家的學(xué)習(xí)或工作具有一定的參考借鑒價(jià)值,需要的朋友可以參考下2020-04-04Sql?Server?"用戶登錄失敗,錯(cuò)誤編18456"的解決過(guò)程
在我們使用數(shù)據(jù)庫(kù)的時(shí)候,偶爾會(huì)遇到一些登錄上的錯(cuò)誤提示,下面這篇文章主要給大家介紹了關(guān)于Sql?Server?"用戶登錄失敗,錯(cuò)誤編18456"的解決過(guò)程,文中通過(guò)圖文介紹的非常詳細(xì),需要的朋友可以參考下2022-09-09做購(gòu)物車系統(tǒng)時(shí)利用到得幾個(gè)sqlserver 存儲(chǔ)過(guò)程
最近使用asp.net+sql2000開(kāi)始開(kāi)發(fā)一個(gè)小型商城系統(tǒng),其中涉及到得購(gòu)物車功能主要是仿照淘寶實(shí)現(xiàn)的.2009-12-12用非動(dòng)態(tài)SQL Server SQL語(yǔ)句來(lái)對(duì)動(dòng)態(tài)查詢進(jìn)行執(zhí)行
此文章主要向大家講述的是非動(dòng)態(tài)SQL ServerSQL語(yǔ)句執(zhí)行動(dòng)態(tài)查詢,在實(shí)際操作中我嘗試在一個(gè)存儲(chǔ)過(guò)程中,來(lái)進(jìn)行傳遞一系列以逗號(hào)劃定界限的值,來(lái)對(duì)結(jié)果集進(jìn)行限制。但是無(wú)論什么時(shí)候,我在IN子句中使用變量,都會(huì)得到錯(cuò)誤信息2017-06-06