问题来自于我的朋友
他管理的服务器出现了堵塞的情况，他有一个存储过程，对一些表进行了插入。
被堵塞session 会去读表A并且加U锁，但是表A 和 存储过程内被插入数据的表没有关系。
表A只有13行数据，小于8页，也就是没有专用的区
他怀疑是否是 因为共享区而产生的问题，所以把表A重建了。问题没有再出现，但是一直不清楚，是什么原因导致了堵塞。
下面是他监控程序获取的堵塞信息：
现在看不出来了，给出的信息太少。不会是共享区的问题。
可能的原因有：
1、被插入的表有触发器，会去读A表。
2、某个表/索引的中间页出了错，导致页的归属关系出了问题。
想不想时已是想，不如不想都不想。
现在看不出来了，给出的信息太少。不会是共享区的问题。 可能的原因有： 1、被插入的表有触发器，会去读A表。 2、某个表/索引的中间页出了错，导致页的归属关系出了问题。 想不想时已是想，不如不想都不想。
触发器，没有。我的第一印象也是触发器，但是没有触发器
第二个，这个不太可能吧。
sp_lock 查看一下锁信息， 找状态为 Waint 的那条， 看在等等什么资源， 再通过这个来分析为什么会锁
邹老大，看我发的那个图，等待表A的RangeS-U 锁。
这个问题已经讨论了好几天了一直没有结果
现在看不出来了，给出的信息太少。不会是共享区的问题。 可能的原因有： 1、被插入的表有触发器，会去读A表。 2、某个表/索引的中间页出了错，导致页的归属关系出了问题。 想不想时已是想，不如不想都不想。 触发器，没有。我的第一印象也是触发器，但是没有触发器 第二个，这个不太可能吧。
sp_lock 查看一下锁信息， 找状态为 Waint 的那条， 看在等等什么资源， 再通过这个来分析为什么会锁 邹老大，看我发的那个图，等待表A的RangeS-U 锁。 这个问题已经讨论了好几天了一直没有结果
那阻塞的时候， 表A上持有什么锁？按照你的描述，存储过程应该不会影响表A？就是不会在表A上下锁？那这表A上的锁是谁下的
表A等待加U锁，这个与你描述中对表A的操作是对的，所以问题是表A被谁下了锁，导致这个被阻塞
Did you friend check what were session 114 and 149 do at that time?
检查了，149 是一个事务对一些表插入数据，但是这些表和 114 操作的表没有关系。
sp_lock 查看一下锁信息， 找状态为 Waint 的那条， 看在等等什么资源， 再通过这个来分析为什么会锁 邹老大，看我发的那个图，等待表A的RangeS-U 锁。 这个问题已经讨论了好几天了一直没有结果 那阻塞的时候， 表A上持有什么锁？按照你的描述，存储过程应该不会影响表A？就是不会在表A上下锁？那这表A上的锁是谁下的 表A等待加U锁，这个与你描述中对表A的操作是对的，所以问题是表A被谁下了锁，导致这个被阻塞
邹老大，这问题其实是我碰到，是这样：
第一个存储过程对B表只有Insert操作，其中包含在事务里。
第二个存储过程只对A表有更新的操作。
捕捉阻塞信息，主要是通过dm_tran_locks视图，发现A表被第一个存储过程频繁阻塞，而且只产生的是RangS-U锁等待，其他。A表只有13条记录，大小8K多。
因为两个存储过程不存在任何交集，所以我推断是否因为A表在混合扩展区分配空间上，与B表公用资源导致了某种阻塞，基于这种判断，我重建了A表聚集索引，让A表重新分配混合扩展区的空间，后来阻塞再也没发生
