Wenn das Anwendungsprogramm aus der ersten Verbindung die Kontrolle Schloss und die zweite Verbindung erfordert eine widersprüchliche Art Sperre, Sperrung wird auftreten. Das Ergebnis ist gezwungen, für die zweite Verbindung, eine Verbindung in den ersten Block warten. Ob aus der gleichen Anwendung oder ein anderer Kunde über eine separate Anwendung, kann eine Verbindung eine andere Verbindung blockieren.
Beschreiben Sie einige der Notwendigkeit, den Betrieb der Schleuse zu schützen möglicherweise nicht offensichtlich, wie z. B. System-Katalog Tabellen und Indizes auf das Schloss.
Die meisten Probleme, weil Sperrung eines Prozessleitsystems Sperre zu lange geschehen, was bei der Blockierung der Prozesskette sind für andere Prozesse Sperren warten.
Gemeinsame Sperren Situationen gehören:
◆ Anfragen, die an das Direktorium eine lange Zeit.
Lang laufende Abfrage kann andere Abfragen blockieren. Zum Beispiel, viele Datensätze betreffen DELETE oder UPDATE-Operation kann eine Menge von Sperren zu bekommen, diese Sperren, ob oder nicht zu Tabellensperren Upgrade blockieren andere Abfragen. Daher sollte nicht der allgemeinen Dauerbrenner Entscheidung Support-Anfragen und Online Transaction Processing (OLTP)-Abfragen werden gemischt. Die Lösung besteht darin, Wege zu finden, Abfragen zu optimieren, wie z. B. Änderung der Index, der große, komplexe Abfragen in einfache Abfragen oder Freizeit oder einem separaten Rechner laufen Abfragen.
Query und der daraus resultierenden langfristigen Sperrung einer der Gründe ist die unsachgemäße Verwendung dieser Abfragen wird ein Cursor. Cursor kann ein bequemer Weg, um die Ergebnismenge durchsuchen, sondern die Verwendung der Cursor als die Verwendung von Set-orientierten Abfragen langsamer.
◆ Abbrechen der Abfrage nicht Commit oder Rollback.
Wenn die Anwendung Abbrechen der Abfrage (wie z. B. die Verwendung von Open Database Connectivity (ODBC) sqlcancel Funktion), aber auch nicht die erforderliche Anzahl der ROLLBACK und COMMIT-Anweisungen wird passieren ausgestellt. Abbrechen der Abfrage nicht automatisch ein Rollback oder Commit der Transaktion. Abgebrochene überprüfen, alle Sperren innerhalb der Transaktion erworben werden beibehalten. Die Anträge müssen oder Rollback der Transaktion wurde, so ordnungsgemäße Verwaltung der Transaktions-Schachtelungsebene abgesagt.
◆ die Anwendung nicht verarbeiten alle Ergebnisse.
Abfrage an den Server gesendet, müssen alle Anwendungen beendet sofort holen alle Ergebniszeilen werden. Wenn die Anwendung nicht zu holen nicht alle Ergebniszeilen, können Sperren auf dem Tisch gelassen werden, während andere Benutzer blockiert.如果使用的应用程序将 Transact-SQL 语句透明地提交给服务器，则该应用程序必须提取所有结果行。如果应用程序没这样做(如果无法配置它执行此操作)，则可能无法解决阻塞问题。为避免此问题，可以将这些应用程序限制在报表或决策支持数据库上。
◆分布式客户端/服务器死锁。
与常规死锁不同，分布式死锁无法由 Microsoft? SQL Server? 2000 自动检测到。如果应用程序打开多个与 SQL Server 的连接并异步提交查询，则可能会发生分布式客户端/服务器死锁。
例如，一个客户端应用程序线程有两个开放式连接。该线程异步启动事务并在第一个连接上发出查询。应用程序随后启动其它事务，在另一个连接上发出查询并等待结果。当 SQL Server 返回其中一个连接的结果时，应用程序开始处理这些结果。应用程序就这样处理结果，直到生成结果的查询被另一个连接上执行的查询阻塞而导致再没有可用的结果为止。此时第一个连接阻塞，无限期等待处理更多的结果。第二个连接没有在锁上阻塞，但仍试图将结果返回给应用程序。然而，由于应用程序阻塞而在第一个连接上等待结果，第二个连接的结果将得不到处理。
若要避免此问题，请执行下列任一操作：
●对每个查询使用查询超时。
●对每个查询使用锁定超时。
●使用绑定连接。
SQL Server 本质上是受客户端应用程序操纵的傀儡。客户端应用程序对服务器上获取的锁几乎有完全的控制(并对锁负责)。虽然 SQL Server 锁管理器自动使用锁保护事务，但这受客户端应用程序发出的查询类型和对结果的处理方式的直接鼓动。因此，大多数阻塞问题的解决方案都涉及检查客户端应用程序。
阻塞问题常要求检查应用程序提交的 SQL 语句本身，以及检查与连接管理、所有结果行的处理等有关的应用程序行为本身。如果开发工具不允许显式控制连接管理、查询超时、结果处理等，阻塞问题可能得不到解决。
设计应用程序以避免阻塞的准则包括：
◆不要使用或设计使用户得以填写编辑框的应用程序，编辑框会生成长时间运行的查询。例如，不要使用或设计提示用户输入的应用程序，允许某些字段保留空白或允许输入通配符。这可能导致应用程序提交运行时间过长的查询，从而导致阻塞问题。
◆不要使用或设计使用户得以在事务内输入内容的应用程序。
◆允许取消查询。
◆使用查询或锁定超时，防止失控查询和避免分布式死锁。
◆立即完成提取所有结果行。
◆使事务尽可能简短。
◆显式控制连接管理。
◆在所预计的并发用户全负荷下对应用程序进行应力测试。