读写分离,读写分离死锁解决方案,事务发布死锁解决方案,发布订阅死锁解决方案|事务(进程 ID *)与另一个进程被死锁在 锁 资源上,并且已被选作死锁牺牲品。请重新运行该事务
2011-05-11 18:10
621 查看
前言:
由于网站访问压力的问题,综合分析各种因素后结合实际情况,采用数据库读写分离模式来解决当前问题。实际方案中采用“事务发布”模式实现主数据库和只读数据库的同步,其中:
发布服务器1台:sql2005,推送订阅模式
订阅服务器2台:sql2005
问题:
以上方案后实施后,数据同步正常,但从日志中发现了死锁情况。错误提示如:事务(进程 ID *)与另一个进程被死锁在 锁 资源上,并且已被选作死锁牺牲品。请重新运行该事务。
查询一些资料后,确定是数据同步的同时资源被锁,同时用户访问页面请求,导致死锁产生,按照事务优先级,应用程序产生死锁。
解决方法:
找到大致思路后,查询了一些资料,大部分资料显示是死锁如何产生,如果跟踪日志,然后根据日志优化查询等方向,尝试一些方案后死锁减少,但并没有彻底解决,最后转换思路,从项目实际情况来看,主要是资讯信息的查询,对查询结果的安全性要求相对不高,所以可以接受“脏”数据的情况,在某种情况下又能提升查询的性能,于是在一些查询频繁和数据量比较大的几个表的select语句中加入with(nolock),死锁问题彻底解决。
建议:
处理一个数据库死锁的异常时候,其中一个建议就是使用 NOLOCK 或者 READPAST,对于非银行等严格要求事务的行业,搜索记录中出现或者不出现某条记录,都是在可容忍范围内,所以碰到死锁,应该首先考虑,我们业务逻辑是否能容忍出现或者不出现某些记录,而不是寻求对双方都加锁条件下如何解锁的问题。
NOLOCK 和 READPAST 都是处理查询、插入、删除等操作时候,如何应对锁住的数据记录。但是这时候一定要注意NOLOCK 和 READPAST的局限性,确认你的业务逻辑可以容忍这些记录的出现或者不出现:
简单来说:
NOLOCK 可能把没有提交事务的数据也显示出来.
READPAST 会把被锁住的行不显示出来
不使用 NOLOCK 和 READPAST ,在 Select 操作时候则有可能报错误:事务(进程 ID **)与另一个进程被死锁在 锁 资源上,并且已被选作死锁牺牲品。
做此记录,希望给遇到同样的问题的朋友一些帮助。
由于网站访问压力的问题,综合分析各种因素后结合实际情况,采用数据库读写分离模式来解决当前问题。实际方案中采用“事务发布”模式实现主数据库和只读数据库的同步,其中:
发布服务器1台:sql2005,推送订阅模式
订阅服务器2台:sql2005
问题:
以上方案后实施后,数据同步正常,但从日志中发现了死锁情况。错误提示如:事务(进程 ID *)与另一个进程被死锁在 锁 资源上,并且已被选作死锁牺牲品。请重新运行该事务。
查询一些资料后,确定是数据同步的同时资源被锁,同时用户访问页面请求,导致死锁产生,按照事务优先级,应用程序产生死锁。
解决方法:
找到大致思路后,查询了一些资料,大部分资料显示是死锁如何产生,如果跟踪日志,然后根据日志优化查询等方向,尝试一些方案后死锁减少,但并没有彻底解决,最后转换思路,从项目实际情况来看,主要是资讯信息的查询,对查询结果的安全性要求相对不高,所以可以接受“脏”数据的情况,在某种情况下又能提升查询的性能,于是在一些查询频繁和数据量比较大的几个表的select语句中加入with(nolock),死锁问题彻底解决。
建议:
处理一个数据库死锁的异常时候,其中一个建议就是使用 NOLOCK 或者 READPAST,对于非银行等严格要求事务的行业,搜索记录中出现或者不出现某条记录,都是在可容忍范围内,所以碰到死锁,应该首先考虑,我们业务逻辑是否能容忍出现或者不出现某些记录,而不是寻求对双方都加锁条件下如何解锁的问题。
NOLOCK 和 READPAST 都是处理查询、插入、删除等操作时候,如何应对锁住的数据记录。但是这时候一定要注意NOLOCK 和 READPAST的局限性,确认你的业务逻辑可以容忍这些记录的出现或者不出现:
简单来说:
NOLOCK 可能把没有提交事务的数据也显示出来.
READPAST 会把被锁住的行不显示出来
不使用 NOLOCK 和 READPAST ,在 Select 操作时候则有可能报错误:事务(进程 ID **)与另一个进程被死锁在 锁 资源上,并且已被选作死锁牺牲品。
做此记录,希望给遇到同样的问题的朋友一些帮助。
相关文章推荐
- C# 最基本的涉及模式(单例模式) C#种死锁:事务(进程 ID 112)与另一个进程被死锁在 锁 | 通信缓冲区 资源上,并且已被选作死锁牺牲品。请重新运行该事务,解决方案: C#关闭应用程序时如何关闭子线程 C#中 ThreadStart和ParameterizedThreadStart区别
- 事务(进程 ID 66)与另一个进程被死锁在 锁 资源上,并且已被选作死锁牺牲品。请重新运行该事务
- sqlserver.jdbc.SQLServerException: 事务(进程 ID 246)与另一个进程被死锁在 锁 资源上,并且已被选作死锁牺牲品。请重新运行该事务
- 触发器引起"事务(进程 ID 88)与另一个进程被死锁在 锁 资源上,并且已被选作死锁牺牲品。请重新运行该事务。"的错误
- EF 多线程TransactionScope事务异常"事务(进程 ID 58)与另一个进程被死锁在 锁 资源上,并且已被选作死锁牺牲品。请重新运行该事务。"
- 事务(进程 ID %1!)与另一个进程已被死锁在资源 {%2!} 上,且该事务已被选作死锁牺牲品。请重新运行该事务。
- 与另一个进程被死锁在 锁 | 通信缓冲区 资源上,并且已被选作死锁牺牲品。请重新运行该事务。
- 事务(进程 ID )与另一个进程已被死锁在 lock 资源上,且该事务已被选作死锁牺牲品。请重新运行
- EF 多线程TransactionScope事务异常"事务EFTransaction类定义:与另一个进程被死锁在 锁 资源上,并且已被选作死锁牺牲品。请重新运行该事务。"
- 事务(进程 ID )与另一个进程已被死锁在 lock 资源上,且该事务已被选作死锁牺牲品。请重新运行该事务
- 事务(进程 ID )与另一个进程已被死锁在 lock 资源上,且该事务已被选作死锁牺牲品。请重新运行该事务
- 小记:事务(进程 ID 56)与另一个进程被死锁在 锁 | 通信缓冲区 资源上,并且已被选作死锁牺牲品。
- 查询数据的时候 提示事务(进程 ID **)与另一个进程被死锁在 锁 资源上,并且已被选作死锁牺牲品。
- 事务 ( 进程 ID 60) 与另一个进程被死锁在锁资源上,并且已被选作死锁牺牲品
- 事务(进程 ID )与另一个进程已被死锁在 lock 资源上,且该事务已被选作死锁牺牲品
- 事务(进程 ID )与另一个进程已被死锁在 lock 资源上,且该事务已被选作死锁牺牲品
- 读写分离死锁解决方案、事务发布死锁解决方案、发布订阅死锁解决方案
- 读写分离,读写分离死锁解决方案,事务发布死锁解决方案,发布订阅死锁解决方案
- 事务(进程 ID )与另一个进程已被死锁在 lock 资源上
- 读写分离死锁解决方案、事务发布死锁解决方案、发布订阅死锁解决方案