Ha a kérelem program az első csatlakozás ellenőrzés zár, a második kapcsolathoz ütköző zárolási típus, blokkoló fog bekövetkezni. Az eredmény kénytelen megvárni a második kapcsolat, a kapcsolat az első blokk. Akár ugyanezt a kérelmet, vagy egy másik ügyfél egy különálló alkalmazás, a kapcsolat blokk egy másik kapcsolatot.
Mutassa be néhány meg kell védeni a működését a zár nem lehet nyilvánvaló, mint például a rendszer katalógusában a táblák és indexek a zárat.
A legtöbb problémát zárolás történt, mert a folyamat-ellenőrzés zár túl sokáig, ami gátolja a folyamat lánc várnak más folyamat zárolja.
Blokkoló gyakori esetek a következők:
◆ lekérdezések benyújtani a Végrehajtó sokáig.
Hosszú futás lekérdezés blokk más lekérdezések. Például, befolyásolhatják sok sort a DELETE vagy UPDATE művelet kap egy csomó zárak, zárak e, vagy nem frissíteni a táblázatot zárak blokkolja más lekérdezések. Ezért az általános nem kell hosszú ideig futó döntéstámogató kérdések és on-line tranzakció-feldolgozási (OLTP) lekérdezések vegyes. A megoldás az, hogy megtalálják a módját, hogy optimalizálja kérdések, például a változó az index, a nagy és összetett lekérdezések a lekérdezések egyszerű, vagy a szabad idő vagy egy külön számítógépet lekérdezések futtatásához.
Lekérdezést, és az abból eredő hosszú távon gátolja az egyik oka a nem megfelelő alkalmazása ezeket a lekérdezéseket a kurzor. Kurzor lehet kényelmesen böngészhet az eredmény meg, de a használata kurzor mint használ set-orientált lekérdezések lassabb.
◆ törli a lekérdezés nem kötelezi, vagy visszagurítás.
Ha az alkalmazás törli a lekérdezés (mint például a nyílt adatbázis-kapcsolat (ODBC) sqlcancel funkció), de nem is ki a szükséges számú ROLLBACK és COMMIT nyilatkozatot fog történni. Mégsem a lekérdezés nem automatikusan visszaállíthatja vagy követnek el a tranzakciót. Törölt ellenőrizze, minden zár belül szerezték meg az ügylet megmaradnak. Kell benyújtani, vagy visszaállíthatja az ügyletet törölték, így megfelelő kezelése az ügylet fészkelő szinten.
◆ a kérelmet nem minden folyamat eredménye.
Lekérdezést küldeni a szerverre, minden alkalmazás ki kell tölteni azonnal letölti az összes eredmény sort. Ha a kérelem nem letölteni az összes eredmény sort, zárak lehet hagyni az asztalon, miközben blokkolja a többi felhasználó.如果使用的应用程序将 Transact-SQL 语句透明地提交给服务器，则该应用程序必须提取所有结果行。如果应用程序没这样做(如果无法配置它执行此操作)，则可能无法解决阻塞问题。为避免此问题，可以将这些应用程序限制在报表或决策支持数据库上。
◆分布式客户端/服务器死锁。
与常规死锁不同，分布式死锁无法由 Microsoft? SQL Server? 2000 自动检测到。如果应用程序打开多个与 SQL Server 的连接并异步提交查询，则可能会发生分布式客户端/服务器死锁。
例如，一个客户端应用程序线程有两个开放式连接。该线程异步启动事务并在第一个连接上发出查询。应用程序随后启动其它事务，在另一个连接上发出查询并等待结果。当 SQL Server 返回其中一个连接的结果时，应用程序开始处理这些结果。应用程序就这样处理结果，直到生成结果的查询被另一个连接上执行的查询阻塞而导致再没有可用的结果为止。此时第一个连接阻塞，无限期等待处理更多的结果。第二个连接没有在锁上阻塞，但仍试图将结果返回给应用程序。然而，由于应用程序阻塞而在第一个连接上等待结果，第二个连接的结果将得不到处理。
若要避免此问题，请执行下列任一操作：
●对每个查询使用查询超时。
●对每个查询使用锁定超时。
●使用绑定连接。
SQL Server 本质上是受客户端应用程序操纵的傀儡。客户端应用程序对服务器上获取的锁几乎有完全的控制(并对锁负责)。虽然 SQL Server 锁管理器自动使用锁保护事务，但这受客户端应用程序发出的查询类型和对结果的处理方式的直接鼓动。因此，大多数阻塞问题的解决方案都涉及检查客户端应用程序。
阻塞问题常要求检查应用程序提交的 SQL 语句本身，以及检查与连接管理、所有结果行的处理等有关的应用程序行为本身。如果开发工具不允许显式控制连接管理、查询超时、结果处理等，阻塞问题可能得不到解决。
设计应用程序以避免阻塞的准则包括：
◆不要使用或设计使用户得以填写编辑框的应用程序，编辑框会生成长时间运行的查询。例如，不要使用或设计提示用户输入的应用程序，允许某些字段保留空白或允许输入通配符。这可能导致应用程序提交运行时间过长的查询，从而导致阻塞问题。
◆不要使用或设计使用户得以在事务内输入内容的应用程序。
◆允许取消查询。
◆使用查询或锁定超时，防止失控查询和避免分布式死锁。
◆立即完成提取所有结果行。
◆使事务尽可能简短。
◆显式控制连接管理。
◆在所预计的并发用户全负荷下对应用程序进行应力测试。