22,300
社区成员
发帖
与我相关
我的任务
分享怎样解除数据库锁的问题？
SQL Server2000数据库服务器隔2，3天就会出现锁是怎么回事？
查看锁进程就发现有些事务被锁住了，非要查看或取消该进程才行！
还有出现“该事务已被Lock，请重新启动该事务”的错误报告，
这又怎么解决？
兄弟们帮帮忙啊！
查看锁进程就发现有些事务被锁住了，非要查看或取消该进程才行！
还有出现“该事务已被Lock，请重新启动该事务”的错误报告，
这又怎么解决？
兄弟们帮帮忙啊！
...全文
请发表友善的回复…
发表回复
nicepp 2006-05-18
- 打赏
- 举报
mark
fordyang 2006-03-20
- 打赏
- 举报
谢谢啦！
wuweilue 2006-03-08
- 打赏
- 举报
kill ID
zjcxc 2006-03-08
- 打赏
- 举报
阻塞需要从业务逻辑上去分析并寻找解决方法, 如果要说通用的, 那只有一些原则需要你遵守:
将死锁减至最少
虽然不能完全避免死锁，但可以使死锁的数量减至最少。将死锁减至最少可以增加事务的吞吐量并减少系统开销，因为只有很少的事务：
回滚，而回滚会取消事务执行的所有工作。
由于死锁时回滚而由应用程序重新提交。
下列方法有助于最大限度地降低死锁：
按同一顺序访问对象。
避免事务中的用户交互。
保持事务简短并在一个批处理中。
使用低隔离级别。
使用绑定连接。
按同一顺序访问对象
如果所有并发事务按同一顺序访问对象，则发生死锁的可能性会降低。例如，如果两个并发事务获得 Supplier 表上的锁，然后获得 Part 表上的锁，则在其中一个事务完成之前，另一个事务被阻塞在 Supplier 表上。第一个事务提交或回滚后，第二个事务继续进行。不发生死锁。将存储过程用于所有的数据修改可以标准化访问对象的顺序。
避免事务中的用户交互
避免编写包含用户交互的事务，因为运行没有用户交互的批处理的速度要远远快于用户手动响应查询的速度，例如答复应用程序请求参数的提示。例如，如果事务正在等待用户输入，而用户去吃午餐了或者甚至回家过周末了，则用户将此事务挂起使之不能完成。这样将降低系统的吞吐量，因为事务持有的任何锁只有在事务提交或回滚时才会释放。即使不出现死锁的情况，访问同一资源的其它事务也会被阻塞，等待该事务完成。
保持事务简短并在一个批处理中
在同一数据库中并发执行多个需要长时间运行的事务时通常发生死锁。事务运行时间越长，其持有排它锁或更新锁的时间也就越长，从而堵塞了其它活动并可能导致死锁。
保持事务在一个批处理中，可以最小化事务的网络通信往返量，减少完成事务可能的延迟并释放锁。
使用低隔离级别
确定事务是否能在更低的隔离级别上运行。执行提交读允许事务读取另一个事务已读取（未修改）的数据，而不必等待第一个事务完成。使用较低的隔离级别（例如提交读）而不使用较高的隔离级别（例如可串行读）可以缩短持有共享锁的时间，从而降低了锁定争夺。
使用绑定连接
使用绑定连接使同一应用程序所打开的两个或多个连接可以相互合作。次级连接所获得的任何锁可以象由主连接获得的锁那样持有，反之亦然，因此不会相互阻塞。
将死锁减至最少
虽然不能完全避免死锁，但可以使死锁的数量减至最少。将死锁减至最少可以增加事务的吞吐量并减少系统开销，因为只有很少的事务：
回滚，而回滚会取消事务执行的所有工作。
由于死锁时回滚而由应用程序重新提交。
下列方法有助于最大限度地降低死锁：
按同一顺序访问对象。
避免事务中的用户交互。
保持事务简短并在一个批处理中。
使用低隔离级别。
使用绑定连接。
按同一顺序访问对象
如果所有并发事务按同一顺序访问对象，则发生死锁的可能性会降低。例如，如果两个并发事务获得 Supplier 表上的锁，然后获得 Part 表上的锁，则在其中一个事务完成之前，另一个事务被阻塞在 Supplier 表上。第一个事务提交或回滚后，第二个事务继续进行。不发生死锁。将存储过程用于所有的数据修改可以标准化访问对象的顺序。
避免事务中的用户交互
避免编写包含用户交互的事务，因为运行没有用户交互的批处理的速度要远远快于用户手动响应查询的速度，例如答复应用程序请求参数的提示。例如，如果事务正在等待用户输入，而用户去吃午餐了或者甚至回家过周末了，则用户将此事务挂起使之不能完成。这样将降低系统的吞吐量，因为事务持有的任何锁只有在事务提交或回滚时才会释放。即使不出现死锁的情况，访问同一资源的其它事务也会被阻塞，等待该事务完成。
保持事务简短并在一个批处理中
在同一数据库中并发执行多个需要长时间运行的事务时通常发生死锁。事务运行时间越长，其持有排它锁或更新锁的时间也就越长，从而堵塞了其它活动并可能导致死锁。
保持事务在一个批处理中，可以最小化事务的网络通信往返量，减少完成事务可能的延迟并释放锁。
使用低隔离级别
确定事务是否能在更低的隔离级别上运行。执行提交读允许事务读取另一个事务已读取（未修改）的数据，而不必等待第一个事务完成。使用较低的隔离级别（例如提交读）而不使用较高的隔离级别（例如可串行读）可以缩短持有共享锁的时间，从而降低了锁定争夺。
使用绑定连接
使用绑定连接使同一应用程序所打开的两个或多个连接可以相互合作。次级连接所获得的任何锁可以象由主连接获得的锁那样持有，反之亦然，因此不会相互阻塞。
zjcxc 2006-03-08
- 打赏
- 举报
"查看锁进程就发现有些事务被锁住了，非要查看或取消该进程才行"
这是堵塞, 正常现象, 不正常的是你的业务处理, 锁是为了解决并发冲突而引入的, 只要你把业务处理中会导致并发的分散开来就不会阻塞.
这是堵塞, 正常现象, 不正常的是你的业务处理, 锁是为了解决并发冲突而引入的, 只要你把业务处理中会导致并发的分散开来就不会阻塞.
fordyang 2006-03-08
- 打赏
- 举报
怎么没人来看看嘛？
fordyang 2006-03-07
- 打赏
- 举报
unsigned，意思我是理解了，
但这里涉及到银行端也对库进行操作，那我就不能控制银行端的操作了！
而且对数据库操作的点也比较多！
但这里涉及到银行端也对库进行操作，那我就不能控制银行端的操作了！
而且对数据库操作的点也比较多！
fordyang 2006-03-07
- 打赏
- 举报
刚才在http://blog.csdn.net/netwalking/archive/2006/03/01/613169.aspx上看到
“Sql Server 2000数据库死锁的解决”好像也没有明确说出解决方法，
要把“趋势杀毒”卸载掉吗？
“Sql Server 2000数据库死锁的解决”好像也没有明确说出解决方法，
要把“趋势杀毒”卸载掉吗？
僵哥 2006-03-07
- 打赏
- 举报
关键的问题并不是如何去解除锁定,而是首先从应用级解决掉产生非预期性死锁的问题.
比如有A1应用程序和A2应用程序,两者都要访问T1和T2表
A1先对T1进行更新,从而锁定了T1,而与此同时A2也对T2进行更新并锁定了T2,接下来A1希望更新T2结果由于被A2锁定而无法执行下去,出现死锁,同时A2也希望更新T1,也由于被A1锁定无法执行下去...
对于此类问题,则需要考虑一下,要么在A1当中预期更新T1和T2,则先对T1和T2同时加锁,如果T1和T2需要事务同步的话.A2也一样,若是发现其中有一个表锁定失败则回滚事务,这样就在一定程度上避免了交叉死锁的发生.
比如有A1应用程序和A2应用程序,两者都要访问T1和T2表
A1先对T1进行更新,从而锁定了T1,而与此同时A2也对T2进行更新并锁定了T2,接下来A1希望更新T2结果由于被A2锁定而无法执行下去,出现死锁,同时A2也希望更新T1,也由于被A1锁定无法执行下去...
对于此类问题,则需要考虑一下,要么在A1当中预期更新T1和T2,则先对T1和T2同时加锁,如果T1和T2需要事务同步的话.A2也一样,若是发现其中有一个表锁定失败则回滚事务,这样就在一定程度上避免了交叉死锁的发生.
