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 引发的疑问(中)

前面两篇的编写有一个疑惑...最初认为的并行比如这个语句:    

select * from t1 inner join t2 on t1.a = t2.a OPTION (querytraceon 8649 )

    在我的理解并行是开几个线程去获取T1数据,另外几个线程获取T2 数据,然后关联结果形成最后结果集。可是试验了才发现自己原来想的和看到的结果不太一样呀!!!!

    下面我们用前两篇的例子继续做试验...

    这次我们2张表同时给锁住,看看等待里是什么情况。

begin tran
update t1 set b = getdate()
update t2 set b = getdate()

    查看sys.dm_os_waiting_tasks (3篇文章的语句代码为了方便全都截图的,情景模拟的代码都很简单,就不贴出来了)

    同样是21条...但是要注意,我特意把四个获取数据线程的 resource_description放在了前面:

keylock hobtid=72057594039042048 dbid=7 id=lock1ee280f00 mode=X associatedObjectId=72057594039042048

    这次锁的是T2了 (sys.objects 是分数据库...越着急越添乱哈哈  在MASTER里查partition_id = 72057594039042048 也有值 queue_messages_1067150847 ,INTERNAL_TABLE直接给我整蒙圈了!!细节呀~细节)但是可以看出其实并行不是像我理解那样两张表会同时扫描。执行计划可以看出要先扫描T2表,所以这个例子中只是锁住T2 ,如果和我想的执行方式(同时扫描T1、T2)一样应该出现T1 、T2两张表都有lck_m_s等待。

    语句及执行计划再贴一次:

    

个人猜测所谓并行其实就是每个物理操作符的多线程同时操作,但单单这一个例子是不能说明问题的。SQL 也不会傻到并行只是操作符级别的吧? 这个没有找到明确的答案,继续研究争取有结论!!!

    另一个问题union all 每个union 部分为什么不能同时执行?难道真的是操作符级别的多线程并行?

    希望大神给解答呀!!!!

    本篇内容均为自己的理解,如有错误请大神们及时指出!!谢谢

    篇幅限制,下面给出小段的测试代码,没有整理自己摘吧!

这个是在查询执行的时候 一直获取sys.dm_os_waiting_tasks 等待信息,并以@a 为分组 ,标示一次等待抓取,这样我们可以看到整个语句并行的等待。    

declare @a int set @a = 0 while 1=1 begin insert into waiting_ecec select @a ,* from sys.dm_os_waiting_tasks a where session_id > 50 set @a = @a + 1 end truncate table waiting_ecec select * from waiting_ecec select a.resource_description,a.waiting_task_address,a.session_id,a.exec_context_id,a.wait_type,blocking_task_address,blocking_exec_context_id,blocking_session_id, e.task_address,e.parent_task_address,worker_address from sys.dm_os_waiting_tasks a left join sys.dm_os_tasks e on a.waiting_task_address =e.task_address and a.exec_context_id = e.exec_context_id where a.session_id > 50 SELECT session_id,status,blocking_session_id,wait_type,last_wait_type,scheduler_id,task_address FROM sys.dm_exec_requests where session_id = 53

时间: 2024-09-21 14:02:38

SqlServer应用之sys.dm_os_waiting_tasks 引发的疑问(下)的相关文章

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

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

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

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

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 可以看出

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

很多人在查看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 引发的疑问(上)

很多人在查看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

AMP会引发移动广告下一个革命吗?

搜索业务是Google的核心,面对Facebook InstantArticles.AppleNews等"新兴新闻入口"的挑战,去年秋天,Google宣布启动AMP(Accelerated Mobile Pages)项目.该项目改善了网页的搭建与呈现,以提高移动端的搜索体验. AMP到底是什么? 早在去年10月,谷歌就邀请出版商和开发者将AMP代码整合到他们的网站和应用程序中.现在,已采用AMP代码的公司包括微博网站Twitter.视觉社交网站Pinterest.职业社交网站Linke

SQL Server锁分区特性引发死锁解析

原文:SQL Server锁分区特性引发死锁解析 锁分区技术使得SQL Server可以更好地应对并发情形,但也有可能带来负面影响,这里通过实例为大家介绍,分析由于锁分区造成的死锁情形. 前段时间园友@JentleWang在我的博客锁分区提升并发,以及锁等待实例中问及锁分区的一些特性造成死锁的问题,这类死锁并不常见,我们在这里仔细分析下.不了解锁分区技术的朋友请先看下我的锁分区那篇实例. Code(执行测试脚本时请注意执行顺序,说明) 步骤1 创建测试数据 use tempdb go creat

Session_End引发的性能问题

这是这两天刚刚发现的问题,记下来,希望对被web性能困扰的同仁有所帮助! 下面说说网站的环境和状况吧: 环境:win2003 + asp.net + sqlserver2000, 一个在线读书项目,日PV超500万,独立IP超3万 状况: 1)内存占用218M平稳: 2)cpu约占5%,但是每隔20秒会突然冲到30%,有时甚至50%:(这个很重要) 3)每次重新更新发布程序,cpu会稳定占5%一段时间(约30分钟),之后就会如上面第2条(这个也很重要) 我分析了下,认为应该是有定时器这类的东西每

资源等待类型sys.dm_os_wait_stats

动态管理视图  sys.dm_os_wait_stats  返回执行的线程所遇到的所有等待的相关信息.可以使用该聚合视图来诊断 SQL Server 以及特定查询和批处理的性能问题. 列名 数据类型 说明 wait_type nvarchar(60) 等待类型的名称. waiting_tasks_count bigint 该等待类型的等待数.该计数器在每开始一个等待时便会增加. wait_time_ms bigint 该等待类型的总等待时间(毫秒).该时间包括 signal_wait_time_