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

赞 (0)

相关推荐

  • SqlServer应用之sys.dm_os_waiting_tasks 引发的疑问(中)

    SqlServer应用之sys.dm_os_waiting_tasks 引发的疑问(中)

    通过上篇文章给大家介绍了SqlServer应用之sys.dm_os_waiting_tasks 引发的疑问(上) ,说了一下sys.dm_exec_requests 和 sys.dm_os_waiting_tasks 在获取并行等待的时候得不同结果,这一篇我们谈论下我的第二个疑问:为什么一个并行计划(4线程)却一下出现了那么多等待,SQL的并行到底是怎么执行的!!!! 先贴以下上篇sys.dm_os_waiting_tasks 的结果图: 我们分析一下这个结果的task_address 可以看出

  • SQL Server 2016里的sys.dm_exec_input_buffer的问题

    我们都知道DBCC命令有点尴尬,因为你不能在T-SQL查询里调用它们,你也不能关联它们的输出到其它DMV/DMF.例如你想为每个用户会话返回最后一个执行的SQL语句.... sys.dm_exec_input_buffer 在SQL Server 2016里,事情就变得简单多,因为微软为你提供了一个新DMFsys.dm_exec_input_buffer,它和DBCC INPUTBUFFER一样做同样的工作. 使用sys.dm_exec_input_buffer非常简单:这个DMF需要2个输入参

  • 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_con

  • SqlServer应用之sys.dm_os_waiting_tasks 引发的疑问(下)

    SqlServer应用之sys.dm_os_waiting_tasks 引发的疑问(下)

    sys.dm_os_waiting_tasks 引发的疑问(下) 前面写了两篇了,其实不光是说sys.dm_os_waiting_tasks的应用,研究了挺长时间的并行,自己有了一些理解,所以分享出来希望有什么理解错误的地方大神们及时纠正!! 给出前两篇的连接: SqlServer应用之sys.dm_os_waiting_tasks 引发的疑问(上) SqlServer应用之sys.dm_os_waiting_tasks 引发的疑问(中) 前面两篇的编写有一个疑惑...最初认为的并行比如这个语句

  • 阿里Druid数据连接池引发的线上异常解决

    阿里Druid数据连接池引发的线上异常解决

    目录 前言 过程一:定位工作流 过程二:定位JPA的OpenEntityManagerInViewInterceptor 过程三:定位Druid,真正的罪魁祸首 后记: 前言 事件起因:项目使用了activiti工作流,系统是由老的spring mvc项目改造成的spring boot项目,数据库链接池从dbcp切换到druid,新系统上线后,同事多次系统隔一段时间后数据查询就很慢,基本出不来. 由此开始了线上bug排查之路.这个问题从一开始就模糊定位到数据库层面的问题,因为只有和数据相关的操作

  • java == 引发的线上异常详解

    今天分享遇到的一个线上的 bug,线上代码: class Scratch { public static void main(String[] args) { JSONArray arrays = JSONUtil.parseArray("[{'type':1},{},{'type':2},{'type':2}" + ",{'name':'zhangsan'},{'type':1},{'type':1},{'type':1}]"); List<User>

  • is_uploaded_file函数引发的不能上传文件问题

    起因: 在一个项目中,接到用户反馈说其所有客户不能上传文件,都返回失败.经过排查发现是PHP中的is_uploaded_file函数在捣鬼. 细节分析: 在正常情况下,通过PHP 上传文件 ,需要通过is_uploaded_file函数来判断文件是否是通过 HTTP POST 上传的,这可以用来确保恶意的用户无法欺骗脚本去访问本不能访问的文件,例如 /etc/passwd. 而本次遇到的问题是本来应该是C:/WINDOWS/Temp/php99.tmp这样的tmp_name,却变成了C://WI

  • 启动sqlserver服务的bat脚本分享

    声明下这个脚本不是我写的,忘了是从哪看到的了,在此分享给大家,因为在我的理解中技术就是用来分享的,希望原创作者看到了不要介意. 1.创建个文本,将后缀名改成.bat 2.将下边语句粘贴进去,然后保存即可 复制代码 代码如下: @echo off for /f "skip=3 tokens=4" %%i in ('sc query MSSQLSERVER') do set "zt=%%i" &goto :next :next if /i "%zt%&

  • SqlServer数据库备份与还原的实现步骤

    SqlServer数据库备份与还原的实现步骤

    目录 问题描述 SqlServer数据库备份步骤 SqlServer数据库还原步骤 其它 问题描述   最近需要给程序新增功能,用于将旧格式的数据转换为新格式,同时删除旧格式的数据(新旧格式的数据库表有部分重叠,同一份数据无法同时存在新旧格式的数据),由于测试环境中的测试数据不多,功能调试几次之后就没有旧格式的数据做测试了,因此想到在功能调试前先将测试数据库备份,然后功能调试之后再将测试数据库还原,这样就可以重复的进行功能调试.   数据库备份过程比较顺利,但是还原过程中出现错误,无论是还原数据

  • SQL Server使用游标处理Tempdb究极竞争-DBA问题-程序员必知

    SQL Server使用游标处理Tempdb究极竞争-DBA问题-程序员必知

    SQL Server tempdb分配竞争算是DBA老生常谈的问题了,几乎现在所有的DBA都知道多建几个文件来解决/缓解问题.但是深层次的的竞争依旧不可避免.这里给大家剖析下游标在tempdb中的特点使其在一定场景下替代临时表/表变量对象,解决深层次的tempdb竞争问题. 在抛出这个不可避免的问题之前我们先简要看下什么是tempdb竞争. 我们拿SQL Server创建一个临时表的过程来描述 1 在系统表中创建表的条目(系统数据页中) 2 分配一个IAM页并找到一个混合区在PFS页中标记 3

  • Sql Server中通过sql命令获取cpu占用及产生锁的sql

    获取SQLSERVER中产生锁的SQL语句 SELECT SUBSTRING(st.text, (qs.statement_start_offset/2) + 1,((CASE statement_end_offset WHEN -1 THEN DATALENGTH(st.text) ELSE qs.statement_end_offset END - qs.statement_start_offset)/2) + 1) as statement_text FROM sys.dm_exec_qu

随机推荐