关于数据库阻塞的问题!

走你_ 2013-08-25 02:42:49
我用SQL2005 程序经常发生阻塞,
按我的理解 阻塞应该是相互的 ,有阻塞就一定有一个其他的进程是阻塞者
但是每次我按照阻塞排查,总会找到一个进程
这个进程在活动监视器里 是这样显示的,
使用资源 :空着
阻塞者 0
阻塞1
问题是为什么这个进程发生阻塞了 为什么没有阻塞者呢,每次只要我把这个进程结束,他后边的进程就顺利的执行成功了 所谓确定就是这个进程有问题,但是我看他的内容 就是一个查询的存储过程,应该就是加了个共享锁 怎么会阻塞呢
...全文
399 13 打赏 收藏 转发到动态 举报
写回复
用AI写文章
13 条回复
切换为时间正序
请发表友善的回复…
发表回复
KevinLiu 2013-08-27
  • 打赏
  • 举报
回复
如果有阻塞那么一定可以看到BlockID的,不会看不到,所以你说的阻塞是怎么发现的?
走你_ 2013-08-26
  • 打赏
  • 举报
回复
引用 11 楼 wwwwgou 的回复:
[quote=引用 10 楼 beyond789654 的回复:] 70被60阻塞,60的状态是sleep,资源那一列没显示, 70的等待资源是60刚刚执行过的SQL语句用过的资源,但是在60这个进程来看都COMMIT了
70的等待资源类型,是什么?70的等待类型是什么running/runable?[/quote]running/runable没注意看 反正活动监视器前边是个 沙漏的图标 等明天再遇到我去看看, 具体的情况就是60这个进程执行各种SQL语句都会出现这种问题,什么查询啊 ,执行存储过程啊等等 都会把别的进程给阻塞,而且不光是60这台机器 有可能下回是另外一台机器的链接
Shawn 2013-08-26
  • 打赏
  • 举报
回复
引用 10 楼 beyond789654 的回复:
70被60阻塞,60的状态是sleep,资源那一列没显示, 70的等待资源是60刚刚执行过的SQL语句用过的资源,但是在60这个进程来看都COMMIT了
70的等待资源类型,是什么?70的等待类型是什么running/runable?
走你_ 2013-08-26
  • 打赏
  • 举报
回复
引用 9 楼 wwwwgou 的回复:
[quote=引用 7 楼 beyond789654 的回复:] 谢谢你的回答。不过可能我没说清楚, #1 不是被SPID:0阻塞,比如一个进程 状态是sleeping,SPID是60,然后又有一个进程SPID是70,这个70被60阻塞了,但是看SPID为60的的进程状态 ,60的状态显示阻塞者是0.也就是说这个进程没被别的进程阻塞,想知道进程60的这个情况是怎么产生的
70被60阻塞时,70的等待资源是什么?这时60的状态是什么?running or sleeping,还是其它?[/quote]70被60阻塞,60的状态是sleep,资源那一列没显示, 70的等待资源是60刚刚执行过的SQL语句用过的资源,但是在60这个进程来看都COMMIT了
Shawn 2013-08-26
  • 打赏
  • 举报
回复
引用 7 楼 beyond789654 的回复:
谢谢你的回答。不过可能我没说清楚, #1 不是被SPID:0阻塞,比如一个进程 状态是sleeping,SPID是60,然后又有一个进程SPID是70,这个70被60阻塞了,但是看SPID为60的的进程状态 ,60的状态显示阻塞者是0.也就是说这个进程没被别的进程阻塞,想知道进程60的这个情况是怎么产生的
70被60阻塞时,70的等待资源是什么?这时60的状态是什么?running or sleeping,还是其它?
走你_ 2013-08-26
  • 打赏
  • 举报
回复
引用 6 楼 wwwwgou 的回复:
#1.SPID:1被SPID:0所阻塞?<50的SPID一般是系统进程。这个情况,还真少见,得进一步跟踪问题。 #2.C#中启用的事务和存储过程中启用的事务,是一样的。都是显示开启一个数据库事务。 #3.锁,是为了保证事务的一致性,必须产生的。 #4.根据楼主给的说明,给那个查询的存储过程中的SELECT语句加上WITH(NOLOCK),应该就不会阻塞了。示例: select * from tablea A with(nolock) inner join tableB b with(nolock) on a.id = b.id
with(nolock)可不敢用,那数据绝对完蛋了
走你_ 2013-08-26
  • 打赏
  • 举报
回复
引用 6 楼 wwwwgou 的回复:
#1.SPID:1被SPID:0所阻塞?<50的SPID一般是系统进程。这个情况,还真少见,得进一步跟踪问题。 #2.C#中启用的事务和存储过程中启用的事务,是一样的。都是显示开启一个数据库事务。 #3.锁,是为了保证事务的一致性,必须产生的。 #4.根据楼主给的说明,给那个查询的存储过程中的SELECT语句加上WITH(NOLOCK),应该就不会阻塞了。示例: select * from tablea A with(nolock) inner join tableB b with(nolock) on a.id = b.id
谢谢你的回答。不过可能我没说清楚, #1 不是被SPID:0阻塞,比如一个进程 状态是sleeping,SPID是60,然后又有一个进程SPID是70,这个70被60阻塞了,但是看SPID为60的的进程状态 ,60的状态显示阻塞者是0.也就是说这个进程没被别的进程阻塞,想知道进程60的这个情况是怎么产生的
Shawn 2013-08-26
  • 打赏
  • 举报
回复
#1.SPID:1被SPID:0所阻塞?<50的SPID一般是系统进程。这个情况,还真少见,得进一步跟踪问题。 #2.C#中启用的事务和存储过程中启用的事务,是一样的。都是显示开启一个数据库事务。 #3.锁,是为了保证事务的一致性,必须产生的。 #4.根据楼主给的说明,给那个查询的存储过程中的SELECT语句加上WITH(NOLOCK),应该就不会阻塞了。示例: select * from tablea A with(nolock) inner join tableB b with(nolock) on a.id = b.id
走你_ 2013-08-25
  • 打赏
  • 举报
回复
引用 2 楼 tcmakebest 的回复:
从来不用锁的飘过,不懂就别用了。
锁是数据库自动控制的 你用不用都会产生的
走你_ 2013-08-25
  • 打赏
  • 举报
回复
引用 1 楼 rockyljt 的回复:
原因有很多了,包括前台程序使用事务时所犯的低级错误,比如:在事务中用msgbox之类的弹出框,这样一天不点击确定按键事务中所用的表就会锁一天
那我所有的事物都扔到存储过程了,不在C#用事物这样好不
Q315054403 2013-08-25
  • 打赏
  • 举报
回复
共享锁与更新互相产生阻塞,根源还是在于正确设计
tcmakebest 2013-08-25
  • 打赏
  • 举报
回复
从来不用锁的飘过,不懂就别用了。
---涛声依旧--- 2013-08-25
  • 打赏
  • 举报
回复
原因有很多了,包括前台程序使用事务时所犯的低级错误,比如:在事务中用msgbox之类的弹出框,这样一天不点击确定按键事务中所用的表就会锁一天

34,590

社区成员

发帖
与我相关
我的任务
社区描述
MS-SQL Server相关内容讨论专区
社区管理员
  • 基础类社区
  • 二月十六
  • 卖水果的net
加入社区
  • 近7日
  • 近30日
  • 至今
社区公告
暂无公告

试试用AI创作助手写篇文章吧