SQL Server死鎖問(wèn)題相信大家都遇到過(guò)，下面就為您分析SQL Server死鎖問(wèn)題產(chǎn)生的原因，供您參考學(xué)習(xí)之用。

1 .提交執(zhí)行時(shí)間長(zhǎng)的查詢。

長(zhǎng)時(shí)間運(yùn)行的查詢會(huì)阻塞其它查詢。例如，影響很多行的DELETE 或UPDATE操作能獲取很多鎖，這些鎖不論是否升級(jí)到表鎖都阻塞其它查詢。因此，一般不要將長(zhǎng)時(shí)間運(yùn)行的決策支持查詢和聯(lián)機(jī)事務(wù)處理 (OLTP)

查詢混在一起。解決方案是想辦法優(yōu)化查詢，如更改索引、將大的復(fù)雜查詢分成簡(jiǎn)單的查詢或在空閑時(shí)間或單獨(dú)的計(jì)算機(jī)上運(yùn)行查詢。

2 .查詢不適當(dāng)?shù)厥褂糜螛?biāo)。游標(biāo)可能是在結(jié)果集中瀏覽的便利方法，但使用游標(biāo)可能比使用面向集合的查詢慢。

3 .取消沒(méi)有提交或回滾的查詢。
如果應(yīng)用程序取消查詢(如使用開(kāi)放式數(shù)據(jù)庫(kù)連接 (ODBC) sqlcancel 函數(shù))但沒(méi)有同時(shí)發(fā)出所需數(shù)目的 ROLLBACK 和 COMMIT
語(yǔ)句，則會(huì)發(fā)生這種情況。取消查詢并不自動(dòng)回滾或提交事務(wù)。取消查詢后，所有在事務(wù)內(nèi)獲取的

4 .應(yīng)用程序沒(méi)處理完所有結(jié)果。
將查詢發(fā)送到服務(wù)器后，所有應(yīng)用程序必須立即完成提取所有結(jié)果行。如果應(yīng)用程序沒(méi)有提取所有結(jié)果行，鎖可能會(huì)留在表上而阻塞其他用戶。如果使用的應(yīng)用程序?qū)?br /> Transact-SQL 語(yǔ)句透明地提交給服務(wù)器，則該應(yīng)用程序必須提取所有結(jié)果行。如果應(yīng)用程序沒(méi)這樣做(如果無(wú)法配置它執(zhí)行此操作)，則可能無(wú)法解決阻塞問(wèn)題。為避免此問(wèn)題，可以將這些應(yīng)用程序限制在報(bào)表或決策支持?jǐn)?shù)據(jù)庫(kù)上。

5 .分布式客戶端/服務(wù)器死鎖。
與常規(guī)死鎖不同，分布式死鎖無(wú)法由 Microsoft SQL Server? 2000 自動(dòng)檢測(cè)到。如果應(yīng)用程序打開(kāi)多個(gè)與 SQL Server 的連接并異步提交查詢，則可能會(huì)發(fā)生分布式客戶端/服務(wù)器死鎖。
例如，一個(gè)客戶端應(yīng)用程序線程有兩個(gè)開(kāi)放式連接。該線程異步啟動(dòng)事務(wù)并在***個(gè)連接上發(fā)出查詢。應(yīng)用程序隨后啟動(dòng)其它事務(wù)，在另一個(gè)連接上發(fā)出查詢。

避免阻塞方法

1 .對(duì)每個(gè)查詢使用查詢超時(shí)。

2 .對(duì)每個(gè)查詢使用鎖定超時(shí)。有關(guān)更多信息，請(qǐng)參見(jiàn)自定義鎖超時(shí)。

3 .使用綁定連接。有關(guān)更多信息，請(qǐng)參見(jiàn)使用綁定連接。

4 .SQL Server 本質(zhì)上是受客戶端應(yīng)用程序操縱的傀儡。客戶端應(yīng)用程序?qū)Ψ?wù)器上獲取的鎖幾乎有完全的控制(并對(duì)鎖負(fù)責(zé))。雖然 SQL Server 鎖管理器自動(dòng)使用鎖保護(hù)事務(wù)，但這受客戶端應(yīng)用程序發(fā)出的查詢類型和對(duì)結(jié)果的處理方式的直接鼓動(dòng)。因此，大多數(shù)阻塞問(wèn)題的解決方案都涉及檢查客戶端應(yīng)用程序。

5 .阻塞問(wèn)題常要求檢查應(yīng)用程序提交的 SQL 語(yǔ)句本身，以及檢查與連接管理、所有結(jié)果行的處理等有關(guān)的應(yīng)用程序行為本身。如果開(kāi)發(fā)工具不允許顯式控制連接管理、查詢超時(shí)、結(jié)果處理等，阻塞問(wèn)題可能得不到解決。
 

【編輯推薦】

SQL Server2008版本和組件

四種SQL Server安全性策略

修改SQL Server默認(rèn)安全設(shè)置

SQL Server跨服務(wù)器查詢

SQL Server資源鎖模式大全