數據庫管理——併發控制

併發控制

目錄：

1.併發操做帶來的3個問題

2.封鎖技術

3.封鎖帶來的問題

4.併發操做的調度

5.SQL對事務併發處理的支持

 

1.併發操做帶來的幾個問題

1.丟失更新問題

2.讀髒數據問題

3.不可重複讀問題

4.幻讀

 

2.封鎖技術

定義：鎖是一個與數據項相關的變量，對可能應用於該數據項上的操做而言，鎖描述了該數據項的狀態。

一般在數據庫中的每一個數據項都有一個鎖。鎖的做用是使併發事務對數據庫中數據項的訪問可以同步。封鎖技術中主要有兩種封鎖：排他型封鎖和共享型封鎖。

1.排他型封鎖（寫鎖，X鎖）

定義：若是事務T對某個數據R實現了X鎖，那麼在T對數據R解除封鎖以前，不容許其餘事務T再對該數據加任何類型的鎖。

2.共享型封鎖（讀鎖，S鎖）

定義：若是事務T對某數據加上S鎖後，仍容許其餘事務再對該數據加S鎖，但在對該數據的全部S鎖都接觸以前，決不容許任何事務對該數據加X鎖。

3.封鎖的粒度

X鎖和S鎖都是加在某一個數據對象上的。封鎖的對象能夠是邏輯單元，也能夠是物理單元。

定義：封鎖對象的大小稱爲封鎖的粒度。

封鎖粒度與系統的併發度和併發控制的開銷密切相關。封鎖的力度越大，併發度也就越小，同時系統的開銷也就越小。

所以選擇封鎖粒度時必須同時考慮封鎖機構和併發度兩個因素，對系統的開銷與併發度進行權衡。

 

3.封鎖帶來的問題

採用封鎖技術，能夠避免併發操做引發的各類錯誤，但有可能產生其餘3個問題：活鎖，餓鎖，死鎖。

1.「活鎖」問題

定義：系統可能使某個事務永遠處於等待狀態，得不到封鎖的機會，這種現象稱爲「活鎖」。

解決：①先來先服務；②若是事務有優先級，能夠採用等待時間長「升級」的策略。

2.「餓鎖」問題

定義：有可能存在一個事務序列，其中每一個事務都申請對某數據項加S鎖，且每一個事務在受權加鎖後的一小段時間內釋放封鎖，此時若另有一個事務T2欲在該數據項上加X鎖，則將永遠輪不上封鎖的機會。

解決：能夠用下列方式受權加鎖來避免事務餓死。

①不存在數據項Q上持有X鎖的其餘事務。

②不存在等待對數據項Q加鎖且優先於T2申請加鎖的事務。

3.「死鎖」問題

定義：系統中有兩個或兩個以上的事務都處於等待狀態，而且每一個事務都在等待其中另外一個事務接觸封鎖，它才能繼續執行下去，結果形成任何一個事務都沒法繼續執行，這種現象成系統進入「死鎖」狀態。

解決：若是發生死鎖，那麼只能抽取某個事務做爲犧牲品，把它撤銷，作回退操做，解除它的全部封鎖，恢復到該事務的初始狀態。

 

4.併發操做的調度

1.事務的調度、串行調度和併發調度

定義：事務的執行次序稱爲「調度」。若是多個事務依次執行，則稱爲事務的串行調度。若是利用分時的方法同時處理多個事務，則稱爲事務的併發調度。

若是有n個事務併發調度，可能的併發調度數目遠遠大於n！。但其中有的併發調度是正確的，有的是不正確的。如何產生正確的併發調度，是由DBMS的併發控制子系統實現的。

2.可串行化概念

每一個事務中，語句的前後順序在各類調度中始終保持一致。在這個前提下，若是一個併發調度的執行結果與某一串行調度的執行結果等價，那麼這個併發調度稱爲「可串行化的調度」，不然是不可串行化的調度。

 

5.SQL對事務併發處理的支持

SQL2對事務的存取模式和隔離級別作了具體規定，並提供語句讓用戶使用，以控制事務的併發執行。

1.事務的存取模式

①READ ONLY（只讀型）。事務對數據庫的操做只能是讀操做。定義這個模式後，表示隨後的事務均是隻讀型。

②READ WRITE（讀寫型）。事務對數據庫的操做可使讀操做，也能夠是寫操做。定義了這個模式後，表示隨後的事務均是讀寫型。在程序開始時，默認爲這種模式。

2.事務的隔離級別

①SERIALIZABLE（可串行化）。容許事務與其餘事務併發執行，單系統必須保證併發調度是可串行化的，不致發生錯誤。在程序開始時默認這個級別。

②REPEATABLE READ（可重複讀）。只容許事務讀已提交的數據，而且在兩次讀同一個數據時不容許其餘事務修改此數據。

③READ COMMITTED（讀提交數據）。容許事務讀已提交的數據，但不要求「可重複讀」。

④READ UNCOMMITTED（能夠讀未提交數據）。容許事務讀已提交或未提交的數據。這是SQL2中所容許的最低一致性級別。