27,582
社区成员
发帖
与我相关
我的任务
分享请高手指点:sql2000中如何避免死锁！小弟不胜感激！！！
我看过一个贴子是解决sql7.0的，但没看懂怎么回事！贴子内容：
小妖甲：本人想在sqlserver7.0中用语句"set lock_timeout 3000",以达到死锁出现3秒后自动杀死该进程的目的，但数据库工作一段时间后，该设置会自动还原成-1，请问谁有办法能让该设置永远保持为3000？
小妖乙：set lock_time只能用于本次连接，每次connection时，都是-1,在set后改变直到连接结束,要永远保持.另外，应该在逻辑中控制不产生dead lock，这样来控制才能一劳永益.
这里的语句"set lock_timeout 3000"在哪里写？还有"在逻辑中控制不产生dead lock"具体怎么控制。
我想在sql2000中实现，具体怎么办啊！
哪位高手知道还请赐教啊！小弟将不胜感激！！！另加50分。
小妖甲：本人想在sqlserver7.0中用语句"set lock_timeout 3000",以达到死锁出现3秒后自动杀死该进程的目的，但数据库工作一段时间后，该设置会自动还原成-1，请问谁有办法能让该设置永远保持为3000？
小妖乙：set lock_time只能用于本次连接，每次connection时，都是-1,在set后改变直到连接结束,要永远保持.另外，应该在逻辑中控制不产生dead lock，这样来控制才能一劳永益.
这里的语句"set lock_timeout 3000"在哪里写？还有"在逻辑中控制不产生dead lock"具体怎么控制。
我想在sql2000中实现，具体怎么办啊！
哪位高手知道还请赐教啊！小弟将不胜感激！！！另加50分。
...全文
请发表友善的回复…
发表回复
warren1999 2005-01-28
- 打赏
- 举报
gz
cgsun 2004-12-22
- 打赏
- 举报
了解和避免阻塞
当来自应用程序的第一个连接控制锁而第二个连接需要相冲突的锁类型时，将发生阻塞。其结果是强制第二个连接等待，而在第一个连接上阻塞。不管是来自同一应用程序还是另外一台客户机上单独的应用程序，一个连接都可以阻塞另一个连接。
说明 一些需要锁保护的操作可能不明显，例如系统目录表和索引上的锁。
大多数阻塞问题的发生是因为一个进程控制锁的时间过长，导致阻塞的进程链都在其它进程上等待锁。
常见的阻塞情形包括：
提交执行时间长的查询。
长时间运行的查询会阻塞其它查询。例如，影响很多行的 DELETE 或 UPDATE 操作能获取很多锁，这些锁不论是否升级到表锁都阻塞其它查询。因此，一般不要将长时间运行的决策支持查询和联机事务处理 (OLTP) 查询混在一起。解决方案是想办法优化查询，如更改索引、将大的复杂查询分成简单的查询或在空闲时间或单独的计算机上运行查询。
查询运行时间长并由此导致阻塞的一个原因是这些查询不适当地使用游标。游标可能是在结果集中浏览的便利方法，但使用游标可能比使用面向集合的查询慢。
取消没有提交或回滚的查询。
如果应用程序取消查询（如使用开放式数据库连接 (ODBC) sqlcancel 函数）但没有同时发出所需数目的 ROLLBACK 和 COMMIT 语句，则会发生这种情况。取消查询并不自动回滚或提交事务。取消查询后，所有在事务内获取的锁都将保留。应用程序必须提交或回滚已取消的事务，从而正确地管理事务嵌套级。
应用程序没处理完所有结果。
将查询发送到服务器后，所有应用程序必须立即完成提取所有结果行。如果应用程序没有提取所有结果行，锁可能会留在表上而阻塞其他用户。如果使用的应用程序将 Transact-SQL 语句透明地提交给服务器，则该应用程序必须提取所有结果行。如果应用程序没这样做（如果无法配置它执行此操作），则可能无法解决阻塞问题。为避免此问题，可以将这些应用程序限制在报表或决策支持数据库上。
分布式客户端/服务器死锁。
与常规死锁不同，分布式死锁无法由 Microsoft® SQL Server™ 2000 自动检测到。如果应用程序打开多个与 SQL Server 的连接并异步提交查询，则可能会发生分布式客户端/服务器死锁。
例如，一个客户端应用程序线程有两个开放式连接。该线程异步启动事务并在第一个连接上发出查询。应用程序随后启动其它事务，在另一个连接上发出查询并等待结果。当 SQL Server 返回其中一个连接的结果时，应用程序开始处理这些结果。应用程序就这样处理结果，直到生成结果的查询被另一个连接上执行的查询阻塞而导致再没有可用的结果为止。此时第一个连接阻塞，无限期等待处理更多的结果。第二个连接没有在锁上阻塞，但仍试图将结果返回给应用程序。然而，由于应用程序阻塞而在第一个连接上等待结果，第二个连接的结果将得不到处理。
若要避免此问题，请执行下列任一操作：
对每个查询使用查询超时。
对每个查询使用锁定超时。有关更多信息，请参见自定义锁超时。
使用绑定连接。有关更多信息，请参见使用绑定连接。
SQL Server 本质上是受客户端应用程序操纵的傀儡。客户端应用程序对服务器上获取的锁几乎有完全的控制（并对锁负责）。虽然 SQL Server 锁管理器自动使用锁保护事务，但这受客户端应用程序发出的查询类型和对结果的处理方式的直接鼓动。因此，大多数阻塞问题的解决方案都涉及检查客户端应用程序。
阻塞问题常要求检查应用程序提交的 SQL 语句本身，以及检查与连接管理、所有结果行的处理等有关的应用程序行为本身。如果开发工具不允许显式控制连接管理、查询超时、结果处理等，阻塞问题可能得不到解决。
设计应用程序以避免阻塞的准则包括：
不要使用或设计使用户得以填写编辑框的应用程序，编辑框会生成长时间运行的查询。例如，不要使用或设计提示用户输入的应用程序，允许某些字段保留空白或允许输入通配符。这可能导致应用程序提交运行时间过长的查询，从而导致阻塞问题。
不要使用或设计使用户得以在事务内输入内容的应用程序。
允许取消查询。
使用查询或锁定超时，防止失控查询和避免分布式死锁。
立即完成提取所有结果行。
使事务尽可能简短。
显式控制连接管理。
在所预计的并发用户全负荷下对应用程序进行应力测试。
当来自应用程序的第一个连接控制锁而第二个连接需要相冲突的锁类型时，将发生阻塞。其结果是强制第二个连接等待，而在第一个连接上阻塞。不管是来自同一应用程序还是另外一台客户机上单独的应用程序，一个连接都可以阻塞另一个连接。
说明 一些需要锁保护的操作可能不明显，例如系统目录表和索引上的锁。
大多数阻塞问题的发生是因为一个进程控制锁的时间过长，导致阻塞的进程链都在其它进程上等待锁。
常见的阻塞情形包括：
提交执行时间长的查询。
长时间运行的查询会阻塞其它查询。例如，影响很多行的 DELETE 或 UPDATE 操作能获取很多锁，这些锁不论是否升级到表锁都阻塞其它查询。因此，一般不要将长时间运行的决策支持查询和联机事务处理 (OLTP) 查询混在一起。解决方案是想办法优化查询，如更改索引、将大的复杂查询分成简单的查询或在空闲时间或单独的计算机上运行查询。
查询运行时间长并由此导致阻塞的一个原因是这些查询不适当地使用游标。游标可能是在结果集中浏览的便利方法，但使用游标可能比使用面向集合的查询慢。
取消没有提交或回滚的查询。
如果应用程序取消查询（如使用开放式数据库连接 (ODBC) sqlcancel 函数）但没有同时发出所需数目的 ROLLBACK 和 COMMIT 语句，则会发生这种情况。取消查询并不自动回滚或提交事务。取消查询后，所有在事务内获取的锁都将保留。应用程序必须提交或回滚已取消的事务，从而正确地管理事务嵌套级。
应用程序没处理完所有结果。
将查询发送到服务器后，所有应用程序必须立即完成提取所有结果行。如果应用程序没有提取所有结果行，锁可能会留在表上而阻塞其他用户。如果使用的应用程序将 Transact-SQL 语句透明地提交给服务器，则该应用程序必须提取所有结果行。如果应用程序没这样做（如果无法配置它执行此操作），则可能无法解决阻塞问题。为避免此问题，可以将这些应用程序限制在报表或决策支持数据库上。
分布式客户端/服务器死锁。
与常规死锁不同，分布式死锁无法由 Microsoft® SQL Server™ 2000 自动检测到。如果应用程序打开多个与 SQL Server 的连接并异步提交查询，则可能会发生分布式客户端/服务器死锁。
例如，一个客户端应用程序线程有两个开放式连接。该线程异步启动事务并在第一个连接上发出查询。应用程序随后启动其它事务，在另一个连接上发出查询并等待结果。当 SQL Server 返回其中一个连接的结果时，应用程序开始处理这些结果。应用程序就这样处理结果，直到生成结果的查询被另一个连接上执行的查询阻塞而导致再没有可用的结果为止。此时第一个连接阻塞，无限期等待处理更多的结果。第二个连接没有在锁上阻塞，但仍试图将结果返回给应用程序。然而，由于应用程序阻塞而在第一个连接上等待结果，第二个连接的结果将得不到处理。
若要避免此问题，请执行下列任一操作：
对每个查询使用查询超时。
对每个查询使用锁定超时。有关更多信息，请参见自定义锁超时。
使用绑定连接。有关更多信息，请参见使用绑定连接。
SQL Server 本质上是受客户端应用程序操纵的傀儡。客户端应用程序对服务器上获取的锁几乎有完全的控制（并对锁负责）。虽然 SQL Server 锁管理器自动使用锁保护事务，但这受客户端应用程序发出的查询类型和对结果的处理方式的直接鼓动。因此，大多数阻塞问题的解决方案都涉及检查客户端应用程序。
阻塞问题常要求检查应用程序提交的 SQL 语句本身，以及检查与连接管理、所有结果行的处理等有关的应用程序行为本身。如果开发工具不允许显式控制连接管理、查询超时、结果处理等，阻塞问题可能得不到解决。
设计应用程序以避免阻塞的准则包括：
不要使用或设计使用户得以填写编辑框的应用程序，编辑框会生成长时间运行的查询。例如，不要使用或设计提示用户输入的应用程序，允许某些字段保留空白或允许输入通配符。这可能导致应用程序提交运行时间过长的查询，从而导致阻塞问题。
不要使用或设计使用户得以在事务内输入内容的应用程序。
允许取消查询。
使用查询或锁定超时，防止失控查询和避免分布式死锁。
立即完成提取所有结果行。
使事务尽可能简短。
显式控制连接管理。
在所预计的并发用户全负荷下对应用程序进行应力测试。
cgsun 2004-12-22
- 打赏
- 举报
将死锁减至最少
虽然不能完全避免死锁，但可以使死锁的数量减至最少。将死锁减至最少可以增加事务的吞吐量并减少系统开销，因为只有很少的事务：
回滚，而回滚会取消事务执行的所有工作。
由于死锁时回滚而由应用程序重新提交。
下列方法有助于最大限度地降低死锁：
按同一顺序访问对象。
避免事务中的用户交互。
保持事务简短并在一个批处理中。
使用低隔离级别。
使用绑定连接。
按同一顺序访问对象
如果所有并发事务按同一顺序访问对象，则发生死锁的可能性会降低。例如，如果两个并发事务获得 Supplier 表上的锁，然后获得 Part 表上的锁，则在其中一个事务完成之前，另一个事务被阻塞在 Supplier 表上。第一个事务提交或回滚后，第二个事务继续进行。不发生死锁。将存储过程用于所有的数据修改可以标准化访问对象的顺序。
避免事务中的用户交互
避免编写包含用户交互的事务，因为运行没有用户交互的批处理的速度要远远快于用户手动响应查询的速度，例如答复应用程序请求参数的提示。例如，如果事务正在等待用户输入，而用户去吃午餐了或者甚至回家过周末了，则用户将此事务挂起使之不能完成。这样将降低系统的吞吐量，因为事务持有的任何锁只有在事务提交或回滚时才会释放。即使不出现死锁的情况，访问同一资源的其它事务也会被阻塞，等待该事务完成。
保持事务简短并在一个批处理中
在同一数据库中并发执行多个需要长时间运行的事务时通常发生死锁。事务运行时间越长，其持有排它锁或更新锁的时间也就越长，从而堵塞了其它活动并可能导致死锁。
保持事务在一个批处理中，可以最小化事务的网络通信往返量，减少完成事务可能的延迟并释放锁。
使用低隔离级别
确定事务是否能在更低的隔离级别上运行。执行提交读允许事务读取另一个事务已读取（未修改）的数据，而不必等待第一个事务完成。使用较低的隔离级别（例如提交读）而不使用较高的隔离级别（例如可串行读）可以缩短持有共享锁的时间，从而降低了锁定争夺。
使用绑定连接
使用绑定连接使同一应用程序所打开的两个或多个连接可以相互合作。次级连接所获得的任何锁可以象由主连接获得的锁那样持有，反之亦然，因此不会相互阻塞。
子陌红尘 2004-12-22
- 打赏
- 举报
查联机帮助："死锁：避免"
zjcxc 2004-12-22
- 打赏
- 举报
1.和你的查询语句中写在一齐:
set lock_timeout 3000;select * from 表
2.不产生死锁这个不是通过设置能解决的问题,别人也说得很清楚了"在逻辑中控制不产生dead lock"
这个逻辑控制是根据你的具体情况具体分析的
set lock_timeout 3000;select * from 表
2.不产生死锁这个不是通过设置能解决的问题,别人也说得很清楚了"在逻辑中控制不产生dead lock"
这个逻辑控制是根据你的具体情况具体分析的
