select r.session_id,
status,
command,
r.blocking_session_id,
r.wait_type as[request_wait_type],
r.wait_time as[request_wait_time],
t.wait_type as[task_wait_type],
t.wait_duration_ms as[task_wait_time],
t.blocking_session_id,
t.resource_description
from sys.dm_exec_requests r
LEFT join sys.dm_os_waiting_tasks t
on r.session_id = t.session_id
where r.session_id >=50
and r.session_id <> @@spid;

通过上面的语句我们找到，并行等待正在等待LCK_M_S.说明查询是被其他的操作阻塞了。上面的问题是由于一个写入语句引起的。这个语句是一个很简单的插入动作，为什么写入会这么慢呢。可以查看磁盘响应时间，，磁盘队列

 发现都出奇的高。

建议

看来问题是由于磁盘本身引起的。给出如下的解决建议：

1.更换读写速度更快的磁盘

2.目前数据文件和日志文件在同一物理磁盘，分割开来

3.从业务出发。经过和客户沟通后发现，这个表是操作日志表。每次做业务操作都会记录日志。所以特别的大。

对应这样的表，可以单独建立文件夹组，文件，并把表放在单独的磁盘，缓解IO压力

4. 比如传统机械磁盘IOPS往往是瓶颈，而吞吐量并不是，所以磁盘格式化的簇大小就比较重要，较大的簇可以减少IOPS瓶颈。

5.对于日志表，如果能改程序，在前端程序合并写入，或者在情况允许的情况下开trace flag 610最小化日志写入
6.整理磁盘碎片，另外合并&删除日志表的索引减少写入开销也能起到一定作用

SQL调优日记--并行等待的原理和问题排查

标签：rip   技术   格式化   完成   source   ima   div   磁盘格式   status