由SQLServer应用sys.dm_os_waiting_tasks引起的问题（1）
许多人在等待时查看SQL语句。他们都是通过sys.dm_exec_requests。该类型的等待也是通过wait_type。sys.dm_os_waiting_tasks也可以看到会议之间的差异等。关于直接对外开放的议论不多。
测试版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.
做一个小例子：
----打开一个事务来更新表而不提交它。
事务的开始
更新T1 B = getdate（）
----执行查询和打开并行
从T1内部连接T2中选择*。
期权（querytraceon 8649）
查询的结果sys.dm_os_waiting_tasks，增加产品：55届，54届，选择：如会议
21等待（虚拟机给双核心4线程），所以我们可以看到，wait_type lck_m_s四，这可以理解是打开四个平行线扫描表T1的所有等待的状态，从resource_deｓｃｒｉｐｔion场消息中我们看到是T1表。 U3000 U3000 U3000 U3000 U3000 U3000 U3000 U3000
U3000 U3000 U3000 U3000
从ridlock，为= 1，pageid = 109，= 7 = lock1f03c7700 DBID，ID，模式= x和associatedobjectid = 72057594038910976，我们知道ridlock fileid = 1 = 109 = 7 pageid DBID。
DBCC TRACEON（3604）
DBCC页（71109,3）
U3000 U3000 U3000 U3000
该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显示。
U3000 U3000 U3000 U3000
blocking_session_id竟然是0。wait_type原来是cxpacket（平行的等待，我们知道等待的主要原因不是这个）。此外，据观察，task_address是调度线程。其他的实验发现sys.dm_exec_requests不平行等得到真正的等待类型和资源。如果并行的串行计划取消，两视图的结果都是一样的。
在这个例子中，我们看到，在实践中sys.dm_exec_requests和sys.dm_os_waiting_tasks之间的差异，但不是唯一的这个问题。为什么4个线程并行计划有21个等待时间并行计划的实现是什么我们将继续说下一个…