一将无能,累死三军啊。别误会,说的不是你,是开发软件的那人。
首先,要彻底解决问题,肯定是要修改软件代码,软件中有造成死锁的代码。
二,死锁可以通过重启数据库暂时解决,
三,通过SQL PROFILE可以监视所有SQL语句的执行,找出死锁最可能的原因,有助于开发员解决问题。
四,如果软件没有源代码,那就只能再想办法了....
能不能把详细的信息贴出来看看?
消息 1205,级别 13,状态 80,第 1 行 事务(进程 ID 76)与另一个进程被死锁在 线程 | 通信缓冲区 资源上,并且已被选作死锁牺牲品。请重新运行该事务。
@美。: 你看看这篇文章对你是否有帮助,http://www.doc88.com/p-700892629581.html,里面有关于排查死锁、解决死锁的思路,很不错。
没有相关经验,只能帮你查资料了:http://blog.csdn.net/zwkandy/article/details/5281581
sp_who active --看看哪个引起的阻塞
sp_lock--看看锁住了那个资源id,objid ,select object_name(objid) 得到
dbcc inputbuffer(@blk)-- 看看是那个语句
停掉数据库,重新打开不就行了?
过段时间又会出现这样,所以不算解决
@美。: 那么说是sql语句或者存储过程等写的有问题了
@阿 牛: 查询少数量是可以执行的,不算存储过程写错
@美。: 当然不是写错呀,写错是压根就不能执行,是有些地方同时执行,然后又是同一资源,如果没有给它加锁的话,肯定是死锁的
@阿 牛: 不是的,应该是存在共享锁了还存在排他锁,存现无限期等待和循环才这样的,
@美。: 额,那不是自绝死路...必须要释放排他锁才吃,不然加了排他锁的是不会给别人访问的...
@阿 牛: 我也知道啊,这不是都试过了,都没能解决嘛,昨天还是月底。。。报表什么的都不能做了
SQL脚本问题,自己监视下sql服务器的执行.
一般情况下,你不加事务的话,是很少会出现这样的情况的。
建议你先把所有加事务的部分找出来,再分析看哪些事务会造成死锁的可能,然后逐个排查试错。
那还不如用SQL PROFILE跟踪吧
@美。: 我提的是解决问题的思路.
你也可以在出问题的时候SQL PROFILE跟踪是查看哪个sql报出来这个错误。
但是造成的死锁的事务肯定是在它之前早就锁住了。所以你还是需要去排查和此报错部分的sql相关的事务.