須要咱們瞭解的SQL Server阻塞緣由與解決方法

上篇說SQL Server應用模式之OLTP系統性能分析。五種角度分析sql性能問題。本章依然是SQL性能 五種角度其一「阻塞與死鎖」

這裏經過鏈接在sysprocesses裏字段值的組合來分析阻塞源頭，能夠把阻塞分爲如下5種常見的類型（見表）。waittype,open_tran,status,都是sysprocesses裏的值，「自我修復？」列的意思,就是指阻塞能不能自動消失。

 5種常見的阻塞類型

類型	waittype	open_tran	status	自我修復	緣由/其餘特徵
1	不爲0	>=0	runnable	是的，當語句運行結束後	語句運行的時間比較長，運行時需等待某些系統資源（如硬盤讀寫、CPU或內存等）。
2	0x0000	>0	sleeping	不能，可是若是運行 KILL語句，這個連接可以很容易被終止	可能客戶端遇到了一個語句執行超時，或者主動取消了上一語句的執行，可是沒有回滾開啓的事務，在SQL Trace裏可以看到一個Attention事件
3	0x0000 0x0800 0x0063	>=0	runnable	不能。知道客戶端吧全部結果都主動取走，或者主動斷開鏈接，能夠運行KILL語句去終止它，可是可能要花長達30秒	客戶端沒有及時把全部結果都取走，這時可能open_tran=0，事務隔離級別也爲默認（READ COMMITTED），但這個鏈接還會持有鎖資源
4	0x0000	>0	rollback	是的	在SQL Trace裏可以看到這個SPID已經發來了一個Attention事件，說明客戶端已經遇到了超時，或者主動要求回滾事務
5	各類值都有可能	>=0	runnable	不能，直到客戶端取消語句運行或者主動斷開鏈接。能夠運行KILL語句終止它，可是可能要花長達30秒	應用程序運行中產生死鎖，在SQL Server中以阻塞形式體現。Sysprocesses裏阻塞和被阻塞的鏈接hostname值是同樣的

 

下面詳細介紹這些類型產生的緣由，以及解決方法

類型1：因爲語句運行時間太長而致使的阻塞，語句自己在正常運行中，只須等待某些系統資源。

解決方法：

要解決這一類阻塞，數據庫管理員須要和數據庫應用設計人員合做，共同解決如下問題。

1. 語句自己有沒有可優化的空間？
   這裏包括修改語句自己下降複雜度、修改表格設計、調整索引等。
2. SQL Server總體性能如何？是否是有資源瓶頸影響了語句執行速度？
   當SQL Server 遇到諸如內存、硬盤讀寫、CPU等資源瓶頸是，原來能很快完成的語句有可能會花很長時間。
3. 若是語句天生就很複雜，沒法調優（不少處理報表的語句就是這樣），就須考慮怎樣把這一類應用（通常就是數據倉庫應用）從OLTP系統中隔離出來。

 

類型2：因爲一個未按預期提交的事務致使的阻塞

這一類阻塞的特徵，就是問題鏈接早就進入了空閒狀態（sysprocesses.status=’sleeping’和sysprocesses.cmd=’AWAITING COMMAND’），可是，若是檢查sysprocesses.open_tran，就會發現它不爲0，以及事務沒有提交。這類問題不少都是由於應用端遇到一個執行超時，或者其餘緣由，當時執行的語句被提早終止了，可是鏈接還保留着。應用沒有跟隨發來的事務提交或回滾指令，致使一個事務被遺留在SQL Server裏。

遇到這類問題，許多使用者會誤覺得是SQL Server端什麼地方沒有處理好。其實，執行超時（command timeout）徹底是一個客戶端的行爲。當客戶端應用向SQL Server發來語句執行請求時，本身會有一個執行超時設置。通常ADO或ADO.NET的鏈接超時時限是30秒。若是30秒之內SQL Server沒有完成語句返回任何結果，客戶端就會發送一個Attention的消息給SQL Server，告訴SQL Server它不想繼續等下去了。SQL Server收到這個消息後，會終止當前正在運行的語句（或批處理）。可是，爲了維護客戶端的邏輯，SQL Server默認不會自動回滾或提交這個鏈接已經打開的事務，而是等待客戶端的後續決定。若是客戶端不發來回滾或提交指令，SQL Server會永遠的把這個事務保持下去，直到客戶端斷開鏈接爲止。

這裏能夠用下面這個實驗來模擬這個問題。在Management Studio裏建立一個鏈接到SQL Server，運行下面的批處理語句：

use sqlnexus
        go
BEGIN TRAN
SELECT *
FROM ReadTrace.tblInterestingEvents
WITH(HOLDLOCK) SELECT 
    * 
FROM sysobjects s1,sysobjects
    s2 COMMIT TRAN

因爲使用了HOLDLOCK參數，第一句SELECT會在運行結束後，在表格上維持一個TAB的S鎖。若是批處理所有完成，這個鎖會在提交事務的時候釋放。可是第二句的SELECT會執行好久。請在等待3～4秒鐘之後取消執行。而後運行下面的語句，檢查open_tran和鎖的狀況。

SELECT @@TRANCOUNT
GO sp_lock GO

經過結果（見圖）能夠得知：

(1)     批處理被取消的時候，「COMMIT TRAN」這條語句沒有被執行到。SQL Server沒有對「BEGIN TRAN」開啓的那個事務作任何處理，只保持其活動的狀態。

(2)     第一句SELECT帶來的鎖因爲事務沒有結束，因此鎖還保持着（objID=85575343, Type=TAB, Mode=IS）。

如今，若是有其餘鏈接要修改ReadTrace.tblInterestingEvents這張表，就會被阻塞住。

解決辦法：

1. 應用程序自己必須意識到審覈語句都有可能遇到意外終止狀況，作好錯誤處理工做。這些工做包括

　　a)   在作SQL Server調用的時候，必須加上錯誤捕捉和處理語句

　　SQL Server客戶端驅動程序（包括ODBC和OLE DB）當語句執行遇到意外終止（包括超時）的時候，都會嚮應用返回錯誤信息。客戶端在捕捉到錯誤信息時。除了作記錄之外（這對問題定位很是有幫助），還要運行下面這句話，把沒有提交的事務回滾掉。

IF @@TRANCOUNT>0 ROLLBACK TRAN

 

　　有些程序員會問，我在T-SQL批處理裏已經寫了T-SQL層面的錯誤捕捉和處理語句（IF @@ERROR<>0 ROLLBACK TRAN）,還有必要讓應用程序再作一遍麼？須要意識到的是，有些異常（好比超時）終止的是整個T-SQL批處理的執行，而不只僅是當前語句。因此當這些異常發生的時候，T-SQL層面錯誤捕捉和處理語句極可能也一塊兒被取消了。它們不能發揮想象中的做用。在應用程序裏的錯誤捕捉和處理語句是必不可少的。

　　b)   設置鏈接屬性「SET SACT_ABORT ON」

　　當SET SACT_ABORT爲ON時，若是執行T-SQL語句產生運行錯誤，整個事務將會終止並回滾

　　當SET SACT_ABORT爲OFF時，處理方法不是惟一的。有時只回滾產生錯誤的T-SQL語句，而事務將繼續進行處理。若是錯誤很嚴重，及時SET SACT_ABORT 爲OFF，也可能回滾整個事務。OFF是默認設置。

　　若是沒有辦法很快規範應用程序的錯誤捕捉和處理語句，一個最快的方法就是在每一個鏈接創建之後，或者是容易出問題的存儲過程的開頭，運行「SET XACT_ABORT ON」，讓SQL Server幫助應用程序回滾事務。

　　c)   考慮是否要關閉鏈接池

　　通常的SQL Server應用都會使用鏈接池來獲得良好的性能。若是有一個鏈接忘記把事務關閉就推出鏈接，那麼這個鏈接會被交還給鏈接池，可是這個時候事務不會被清理。客戶端驅動程序會在這個鏈接下一次被重用的時候（又有新的用戶要創建鏈接），發一句sp_reset_connection命令清理當前鏈接上次遺留下來的全部對象，包括回滾未提交的事務。若是鏈接交還給鏈接池之後好久都沒有被重用，那它的事務就會持續長時間，引發阻塞。有些Java程序使用的驅動程序，提供鏈接池功能，可是不提供鏈接重用時的事務清理功能。這樣的鏈接池對應用開發質量要求很高，比較容易發生阻塞。

    若是不能很快的實施建議a)和b)，把鏈接池關閉能縮短食事務持續時間，也能從必定程度上緩解阻塞問題。

2. 分析爲何鏈接會遇到異常終止

　　這裏又得談到錯誤信息記錄了。有了錯誤信息，就能夠斷定是超時問題，仍是其餘SQL Server錯誤。若是是超時問題，可按照第一種阻塞進行處理。

    還有一種孤兒事務的來源，是鏈接開啓了隱式事務（implicit transaction）而沒有加入及時提交事務的機制。若是鏈接處於隱式事務模式（SET IMPLICIT_TRANSACTIONS ON），而且鏈接當前再也不事務中，則執行下列任何一條語句都會開啓一個新的事務。

ALTER TABLE	FETCH	REVOKE
CREATE	GRANT	SELECT
DELETE	INSERT	TRUNCATE_TABLE
DROP	OPEN	UPDATE

對於由於此設置爲ON而自動打開的事務，SQL Server會自動幫你打開事務，可是不會自動幫你提交。用戶必須在該事務結束後將其顯式提交或回滾。不然，當用戶斷開鏈接時，事務及其包含的全部數據更改將被回滾。事務提交後，執行上述任意一條語句又會啓動一個新事務。隱式事務模式將始終生效，知道鏈接執行SET IMPLICIT_TRANSACTIONS OFF語句使鏈接恢復爲自動提交模式。在自動提交模式下，全部單個語句在成功完成時將被提交，不會有事務遺留。

爲何會有鏈接要開啓隱式事務呢？除了程序員有意爲之之外，不少是客戶端數據庫鏈接驅動，或者空間爲了實現它的事務功能（注意不是SQL Server經過T-SQL語句直接提供的）而選用這個機制。若是應用程序出現意外，或者腳本沒有處理好，會有應用層事務未提交的現象。在SQL Server裏也體現爲一個孤兒事務。嚴格約束應用層對事務的使用，直接使用SQL Server裏面的事務，是避免這種問題出現的好方法。

 

類型3：因爲客戶端沒有及時把結果集取出而致使的語句長時間運行。

         語句在SQL Server內執行總時間不只包含SQL Server的執行時間，還包含把結果集發給客戶端的時間。若是結果集比較大，SQL Server會分幾回打包發出，每發一次，都要等待客戶端的確認。只有確認之後，SQL Server纔會發送下一個結果集包。全部結果都發完之後，SQL Server才認爲語句執行完畢，釋放執行申請的資源（包括鎖資源）。

         若是處於某種緣由，客戶端應用處理結果很是緩慢甚至沒有相應，或者乾脆不理睬SQL Server發送結果集的請求，則SQL Server會耐心的等待，所以會致使語句長時間執行而發生阻塞。

解決方法：

1. 在設計程序時，必定要慎重返回大結果集。這種行爲不只會對SQL Server和網絡帶來很大負擔，對應用程序自己來說，也要花不少資源去處理結果集。若是最終用戶只須要部分結果集就能夠，則在發送SQL Server指令的時候就要指定好。要避免居於無論三七二十一全部數據都要，而結果集只取走開頭一部分去展現這樣的行爲發生。
2. 若是應用程序的確須返回大結果集，例如一些報表系統，則要考慮報表數據庫和生產數據庫分開。
3. 若是1和2在短時間內不能實現，能夠和最終用戶協商，返回大結果集的鏈接使用READ UNCOMMITTED事務隔離級別。這樣查詢語句就不會申請S鎖了。

 

類型4：阻塞的源頭鏈接一直處於rollback狀態。

這種狀況常是由第一類狀況衍生來的。有時候數據庫管理員發現一個鏈接阻塞住了別人，爲了解決問題，會讓鏈接主動退出或強制退出（輕質退出應用，或者直接在SQL Server端KILL鏈接）。對於大部分狀況，這些措施會消除阻塞。可是要記住的是，無論是在客戶端退出，仍是要服務器端KILL，爲了維護數據庫事務的一致性，SQL Server都會對鏈接尚未來得及完成提交的事務作回滾動做。SQL Server要找到全部當前事務修改過的記錄，把它們改回原來的狀態。因此，若是一個DELETE、INSERT或UPDATE已經運行了一個小時，可能回滾也須要一個小時，在這個過程當中，阻塞還會延續，咱們只能等待。

有些用戶可能等不及，直接重啓SQL Server。當SQL Server關閉的時候，回滾動做會被中斷，SQL Server會被很快關掉，可是這個回滾動做在下次SQL Server重啓的時候會從新開始（數據庫作恢復的時候）。重啓的時候若是回滾不能很快結束，整個數據庫都不可用，可能會帶來更嚴重的後果。

解決方法：

最好的方法是在工做時間儘可能不要作這種大的修改操做。這些操做盡可能安排在半夜或者週末的時間完成。若是操做已經作了好久，最好耐心等它作完。若是必定要在有工做負荷的時候作，最好把一個大操做分紅若干小操做分步完成。

 

類型5：應用程序運行中產生死鎖，在SQL Server中以阻塞形式體現。

一個客戶端的應用在運行過程當中會使用到許多資源，包括線程資源，信號量資源，內存資源，IO資源等，SQL Server也是資源之一。若是發生死鎖的兩端不全是SQL Server，SQL Server的死鎖判斷機制可能不起做用。這時若是應用端沒有處理好，可能會永遠等下去。而SQL Server內部的表現可能僅僅是一個阻塞。可是這個阻塞不會自動消除。這樣的阻塞對SQL Server的性能會產生很大影響。

下面咱們舉兩個這種應用端死鎖的例子。

1)  在應用的一個線程中開啓不止一個數據庫鏈接而產生的死鎖（見圖）。

假設應用有一個線程有這樣的邏輯：

    ●  開始運行

    ●  創建數據庫鏈接A，調用存儲過程ProcA。打開結果集A。

    ●  創建數據庫鏈接B，調用存儲過程ProcB。打開結果集B。

    ●  輪流讀取結果集A、B，整合輸出最終結果。

    ●  關閉結果集A、B，關機鏈接A、B。

    ●  結束運行

在正常狀況下這樣的設計看上去沒有問題，可是實際上很脆弱。由於在線程內部，這個邏輯是線程執行的。假設存儲過程ProcA是一個事務，在返回結果集以前由於一些操做申請了一些排他鎖，而ProcB爲了返回結果又要用到這些鎖，那會發生什麼狀況呢？

發生的狀況會是鏈接A在等線程把鏈接B上的結果讀出來，再來處理結果集A，而鏈接B等待鏈接A完成事務後再釋放鎖。雙方相互等待，產生思索。

1)  兩個線程間的死鎖（見圖）。

若是應用有兩個線程，每一個線程各開一個數據庫鏈接，那上面的邏輯不會出問題。由於運行ProcA的那個線程會先作完，釋放阻塞住鏈接B的鎖，讓B也可以接着跑完。可是假設有下列邏輯：

線程A：創建數據庫鏈接A，不斷讀取表格A，按條取出記錄，作必定處理後發給線程B的輸入緩存。

線程B：創建數據庫鏈接B，從輸入緩存讀取數據，依據收到的記錄對錶格A進行修改。

這個邏輯會產生什麼問題呢？咱們知道表格修改會在表上申請一些排他鎖。若是線程A正在讀取這條記錄，修改動做會被阻塞住。這個時候線程B就會進入等待狀態。可是線程A須要線程B輸入緩存清空後才能寫入。若是線程B還沒來得及清空，它也不得不等待，這時候也會產生死鎖（在SQL Server裏是一個阻塞）。

解決方法:

複雜的程序還可能會出現其餘的死鎖形式。爲了不這種死鎖，要在應用調用SQL Server的時候設置執行超時，並寫好錯誤處理機制（參見阻塞緣由2）。一旦死鎖發生，SQL Server的操做在等待一段時間後會由於超時而放棄，並釋放出SQL Server內部的資源，解決死鎖。

小結：應更多從程序設計着手解決阻塞問題

不少用戶有一種誤解，認爲阻塞是一個數據庫問題。當阻塞問題發生的時候，都但願從數據庫層面找到方法，一勞永逸地解決問題。但是，阻塞自己是爲了完成事務的隔離，是應用程序向SQL Server提出的要求。因此不少時候，光從數據庫端努力是不能解決阻塞問題的。在應用程序層面也要作不少工做。例如應用在作鏈接的時候選擇什麼樣的隔離級別，事務開始和結束的時間點選擇，鏈接的創建和回收機制，指令複雜度的控制等。應用程序還應該考慮到控制結果集大小，並及時從SQL Server端取走數據。還要考慮SQL Server指令執行時間長短控制，以及發生超時或其餘意外後的錯誤處理機制等。尤爲是對高併發量、高響應要求的關鍵業務系統，在設計應用時必需要考慮好上面這些關鍵因素。對於關鍵的業務邏輯，必須逐個審查，保證應用選擇的是可以知足業務需求的最低隔離級別，事務的大小已經控制到了最小的粒度。而運行的語句，也要有良好的數據庫設計，保證它不會隨着數據庫的增大和用戶量的增多，佔用更多的資源和運行時間。若是作不到這幾點，就會容易發生應用在用戶量比較少，或者數據庫比較小的初始階段性能不錯，可是當用戶量增加或數據量增大之後性能愈來愈慢的問題。