sys.dm_os_waiting_tasks 引发的疑问(下)

    前面写了两篇了,其实不光是说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-10-11 16:21:23

sys.dm_os_waiting_tasks 引发的疑问(下)的相关文章

Replication的犄角旮旯(七)-- 一个DDL引发的血案(下)(聊聊logreader的延迟)

原文:Replication的犄角旮旯(七)-- 一个DDL引发的血案(下)(聊聊logreader的延迟) <Replication的犄角旮旯>系列导读 Replication的犄角旮旯(一)--变更订阅端表名的应用场景 Replication的犄角旮旯(二)--寻找订阅端丢失的记录 Replication的犄角旮旯(三)--聊聊@bitmap Replication的犄角旮旯(四)--关于事务复制的监控 Replication的犄角旮旯(五)--关于复制identity列 Replicat

通过/proc/sys/net/ipv4/优化Linux下网络性能

通过/proc/sys/net/ipv4/优化Linux下网络性能 /proc/sys/net/ipv4/优化1)      /proc/sys/net/ipv4/ip_forward该文件表示是否打开IP转发.0,禁止1,转发 缺省设置:02)      /proc/sys/net/ipv4/ip_default_ttl   该文件表示一个数据报的生存周期(Time To Live),即最多经过多少路由器.   缺省设置:64 增加该值会降低系统性能. 3)      /proc/sys/ne

Expert 诊断优化系列------------------语句调优

前面三篇通过CPU.内存.磁盘三巨头,讲述了如何透过现在看本质,怎样定位服务器三巨头反映出的问题.为了方便阅读给出链接: Expert 诊断优化系列------------------你的CPU高么? Expert 诊断优化系列------------------内存不够用么? Expert 诊断优化系列------------------冤枉磁盘了 通过三篇文章的基本介绍,可以看出系统的语句如果不优化,可能会导致三巨头都出现异常的表现.所以本篇开始介绍系统中的重头戏--------------

SQL语句调优三板斧

改装有顺序------常开的爱车下手 你的系统中有成千上万的语句,那么优化语句从何入手呢 ? 当然是系统中运行最频繁,最核心的语句了.废话不多说,上例子: 这是一天的语句执行情况,里面柱状图表示的是对应执行时间段内语句的次数,总体看起来长时间语句非常多. 下面看一下具体的语句执行情况: 排位第一的语句执行次数38508次,是一个存储过程(RPC:Completed 表示存储过程结束,不知道这个的请看profiler的使用说明).其中的一条语句(SP:StmtCompleted)也就是排在第二位的

解决一阻塞语句CPU直降15%

原本只是部署作业获取数据库中阻塞语句,中午测试汇集阻塞数据,发现某一服务器写入386行,而其他服务器只写入几行.登录对应服务器查看详细信息,发现有四个时间点分别写入100来行记录对于第一行:会话183被会话221阻塞,阻塞时长1887ms,会话221持有18:1:4311755上的U锁,会话183等待18:1:4311755上的U锁.查看BlockedBatch/BlockingBatch列,此处的阻塞与被阻塞对应的存储过程是相同的,只是传递的参数不同.存储过程定义如下 CREATE PROCE

Expert 诊断优化系列------------------透过等待看系统

上一篇我们简单的介绍了,语句优化的三板斧,大部分语句三板斧过后,就算不成为法拉利也能是个宝马了.为了方便阅读给出系列文章的导读链接: SQL SERVER全面优化-------Expert for SQL Server 诊断系列 本篇主要讲述几个常见的系统等待,透过这些等待,看看系统存在什么问题,怎么样解决这些问题.结合系统三巨头(CPU,内存,磁盘)综合展现系统问题和这些元素的联系. 首先我们举个例子:前文提到了,一个好的SQL语句就好比一辆时速180的好车,好的系统硬件(CPU,内存,磁盘)

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

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

sys.dm_db_wait_stats

sys.dm_db_wait_stats 返回在操作期间执行的线程所遇到的所有等待的相关信息. 可以使用此聚合视图来诊断 Azure SQL Database 以及特定查询和批处理的性能问题. 执行查询期间的特定等待时间类型可以说明查询中存在瓶颈或失效点. 同样,如果服务器级的等待时间较长或等待计数较多,说明服务器实例内交互查询交互中存在瓶颈或热点. 例如,锁等待指示查询争用数据:页 IO 闩锁等待指示 IO 响应时间较慢:页闩锁更新指示表示文件布局不正确. 列名 数据类型 说明 wait_ty

TCP/IP 在 Windows 下的实现

Windows 实现TCP/IP 协议也是建立在上一篇博客的OSI 基础之上的. 用户态是由ws2_32.dll 和一些其他服务提供者的 dll 共同实现,当中ws2_32.dll 是一个框架.能够容纳非常多的服务提供者,这些服务提供者事实上就是各种协议的实现者,如比較常见的有 TCP/IP 协议,IPX 协议.而 TCP/IP 协议的服务实现是由 msafd.dll 和 mswsock.dll 来完毕. HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\S