Wanneer de aanvraag programma van de eerste verbinding te vergrendelen en de tweede verbinding vereist een tegenstrijdige lock type, blokkeren zal optreden. Het resultaat is gedwongen om te wachten voor de tweede verbinding, een verbinding in het eerste blok. Of van dezelfde toepassing of een andere cliënt op een aparte toepassing is, kan een verbinding blokkeren een andere aansluiting.
Beschrijf een aantal van de noodzaak de werking van de sluis te beschermen mogen niet zichtbaar, zoals systeem-catalogus tabellen en indexen op het slot.
De meeste problemen gebeuren, omdat het blokkeren van een proces te vergrendelen te lang, wat resulteert in het blokkeren van de procesketen wachten voor andere processen sluizen.
Vaak blokkeren situaties behoren met name:
◆ vragen ingediend bij het College een lange tijd.
Langlopende query kan blokkeren andere vragen. Bijvoorbeeld, invloed op vele rijen DELETE of UPDATE operatie kan heel veel sluizen te krijgen, deze sloten, al dan niet om te upgraden naar tabel sloten blokkeren andere vragen. Daarom is de algemene mag niet worden long-running queries en ondersteuning van de besluitvorming online transaction processing (OLTP) zoekopdrachten gemengd. De oplossing is naar manieren om queries te optimaliseren vinden, zoals het veranderen van de index, om de grote, complexe zoekopdrachten in eenvoudige vragen, of vrije tijd of een aparte computer queries.
Query en de daaruit voortvloeiende lange termijn het blokkeren van een van de redenen is het oneigenlijk gebruik van deze vragen een cursor. Cursor kan een handige manier om de resultaat set bladeren, maar het gebruik van de cursor dan het gebruik van set-georiënteerde zoekopdrachten langzamer.
◆ annuleren query geen commit of rollback.
Indien de aanvraag te annuleren van de zoekopdracht (zoals het gebruik van Open Database Connectivity (ODBC) sqlcancel functie), maar ook niet het vereiste aantal afgegeven van de terugdraaiing en COMMIT verklaringen zullen gebeuren. Annuleer de query niet automatisch terugdraaien of het begaan van de transactie. Mocht u, alle sloten verworven binnen de transactie zal worden gehandhaafd. Aanvragen moeten worden ingediend of terugdraaien van de transactie is geannuleerd, zodat een goed beheer van de transactie nesting-niveau.
◆ de aanvraag niet alle resultaten worden verwerkt.
Zoeken naar de server verzonden, moeten alle aanvragen worden ingevuld direct resultaat te halen alle rijen. Indien de aanvraag niet te halen resultaat alle rijen, sloten kan worden overgelaten op de tafel, terwijl het blokkeren van andere gebruikers.如果使用的应用程序将 Transact-SQL 语句透明地提交给服务器，则该应用程序必须提取所有结果行。如果应用程序没这样做(如果无法配置它执行此操作)，则可能无法解决阻塞问题。为避免此问题，可以将这些应用程序限制在报表或决策支持数据库上。
◆分布式客户端/服务器死锁。
与常规死锁不同，分布式死锁无法由 Microsoft? SQL Server? 2000 自动检测到。如果应用程序打开多个与 SQL Server 的连接并异步提交查询，则可能会发生分布式客户端/服务器死锁。
例如，一个客户端应用程序线程有两个开放式连接。该线程异步启动事务并在第一个连接上发出查询。应用程序随后启动其它事务，在另一个连接上发出查询并等待结果。当 SQL Server 返回其中一个连接的结果时，应用程序开始处理这些结果。应用程序就这样处理结果，直到生成结果的查询被另一个连接上执行的查询阻塞而导致再没有可用的结果为止。此时第一个连接阻塞，无限期等待处理更多的结果。第二个连接没有在锁上阻塞，但仍试图将结果返回给应用程序。然而，由于应用程序阻塞而在第一个连接上等待结果，第二个连接的结果将得不到处理。
若要避免此问题，请执行下列任一操作：
●对每个查询使用查询超时。
●对每个查询使用锁定超时。
●使用绑定连接。
SQL Server 本质上是受客户端应用程序操纵的傀儡。客户端应用程序对服务器上获取的锁几乎有完全的控制(并对锁负责)。虽然 SQL Server 锁管理器自动使用锁保护事务，但这受客户端应用程序发出的查询类型和对结果的处理方式的直接鼓动。因此，大多数阻塞问题的解决方案都涉及检查客户端应用程序。
阻塞问题常要求检查应用程序提交的 SQL 语句本身，以及检查与连接管理、所有结果行的处理等有关的应用程序行为本身。如果开发工具不允许显式控制连接管理、查询超时、结果处理等，阻塞问题可能得不到解决。
设计应用程序以避免阻塞的准则包括：
◆不要使用或设计使用户得以填写编辑框的应用程序，编辑框会生成长时间运行的查询。例如，不要使用或设计提示用户输入的应用程序，允许某些字段保留空白或允许输入通配符。这可能导致应用程序提交运行时间过长的查询，从而导致阻塞问题。
◆不要使用或设计使用户得以在事务内输入内容的应用程序。
◆允许取消查询。
◆使用查询或锁定超时，防止失控查询和避免分布式死锁。
◆立即完成提取所有结果行。
◆使事务尽可能简短。
◆显式控制连接管理。
◆在所预计的并发用户全负荷下对应用程序进行应力测试。