SQL server阻塞

　　阻塞定义

　　当来自应用程式的第一个连接控制锁而第二个连接需要相冲突的锁类型时，将发生阻塞。其结果是强制第二个连接等待，而在第一个连接上阻塞。不管是来自同一应用程式还是另外一台客户机上单独的应用程式，一个连接都能够阻塞另一个连接。

　　说明 一些需要锁保护的操作可能不明显，例如系统目录表和索引上的锁。

　　大多数阻塞问题的发生是因为一个进程控制锁的时间过长，导致阻塞的进程链都在其他进程上等待锁。

　　常见的阻塞情形包括

　　1 .提交执行时间长的查询。

　　长时间运行的查询会阻塞其他查询。例如，影响很多行的 DELETE 或 UPDATE

　　操作能获取很多锁，这些锁不论是否升级到表锁都阻塞其他查询。因此，一般不要将长时间运行的决策支持查询和联机事务处理 (OLTP)

　　查询混在一起。解决方案是想办法优化查询，如更改索引、将大的复杂查询分成简单的查询或在空闲时间或单独的电脑上运行查询。

　　2 .查询不适当地使用游标。游标可能是在结果集中浏览的便利方法，但使用游标可能比使用面向集合的查询慢。

　　3 .取消没有提交或回滚的查询。

　　假如应用程式取消查询(如使用开放式数据库连接 (ODBC) sqlcancel 函数)但没有同时发出所需数目的 ROLLBACK 和 COMMIT

　　语句，则会发生这种情况。取消查询并不自动回滚或提交事务。取消查询后，任何在事务内获取的锁都将保留。应用程式必须提交或回滚已取消的事务，从而正确地管理事务嵌套级。

　　4 .应用程式没处理完任何结果。

　　将查询发送到服务器后，任何应用程式必须立即完成提取任何结果行。假如应用程式没有提取任何结果行，锁可能会留在表上而阻塞其他用户。假如使用的应用程式将

　　Transact-SQL 语句透明地提交给服务器，则该应用程式必须提取任何结果行。假如应用程式没这样做(假如无法配置他执行此操作)，则可能无法解决阻塞问题。为避免此问题，能够将这些应用程式限制在报表或决策支持数据库上。

　　5 .分布式客户端/服务器死锁。

　　和常规死锁不同，分布式死锁无法由 Microsoft SQL Server^® 2000 自动检测到。假如应用程式打开多个和 SQL Server 的连接并异步提交查询，则可能会发生分布式客户端/服务器死锁。

　　例如，一个客户端应用程式线程有两个开放式连接。该线程异步启动事务并在第一个连接上发出查询。应用程式随后启动其他事务，在另一个连接上发出查询并等待结果。当 SQL Server 返回其中一个连接的结果时，应用程式开始处理这些结果。应用程式就这样处理结果，直到生成结果的查询被另一个连接上执行的查询阻塞而导致再没有可用的结果为止。此时第一个连接阻塞，无限期等待处理更多的结果。第二个连接没有在锁上阻塞，但仍试图将结果返回给应用程式。然而，由于应用程式阻塞而在第一个连接上等待结果，第二个连接的结果将得不到处理。

　　避免阻塞方法

　　1 .对每个查询使用查询超时。

　　2 .对每个查询使用锁定超时。有关更多信息，请参见自定义锁超时。

　　3 .使用绑定连接。有关更多信息，请参见使用绑定连接。

　　4 .SQL Server 本质上是受客户端应用程式操纵的傀儡。客户端应用程式对服务器上获取的锁几乎有完全的控制(并对锁负责)。虽然 SQL Server 锁管理器自动使用锁保护事务，但这受客户端应用程式发出的查询类型和对结果的处理方式的直接鼓动。因此，大多数阻塞问题的解决方案都涉及检查客户端应用程式。

　　5 .阻塞问题常需要检查应用程式提交的 SQL 语句本身，连同检查和连接管理、任何结果行的处理等有关的应用程式行为本身。假如研发工具不允许显式控制连接管理、查询超时、结果处理等，阻塞问题可能得不到解决。

标签：

版权申明：本站文章部分自网络，如有侵权，请联系：west999com@outlook.com
特别注意：本站所有转载文章言论不代表本站观点，本站所提供的摄影照片，插画，设计作品，如需使用，请与原作者联系，版权归原作者所有