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条等待？并行计划怎么执行的？ 我们下篇继续说....