數據庫事務

數據併發的問題 
    一個數據庫可能擁有多個訪問客戶端，這些客戶端都可以併發方式訪問數據庫。數據庫中的相同數據可能同時被多個事務訪問，如果沒有采取必要的隔離措施，就會導致各種併發問題，破壞數據的完整性。這些問題可以歸結爲5類，包括3類數據讀問題（髒讀、幻象讀和不可重複讀）以及2類數據更新問題（第一類丟失更新和第二類丟失更新）。下面，我們分別通過實例講解引發問題的場景。

髒讀（dirty read） 
    在講解髒讀前，我們先講一個笑話：一個有結巴的人在飲料店櫃檯前轉悠，老闆很熱情地迎上來：“喝一瓶？”，結巴連忙說：“我…喝…喝…”，老闆麻利地打開易拉罐遞給結巴，結巴終於憋出了他的那句話：“我…喝…喝…喝不起啊！”。在這個笑話中，飲料店老闆就對結巴進行了髒讀。 
A事務讀取B事務尚未提交的更改數據，並在這個數據的基礎上操作。如果恰巧B事務回滾，那麼A事務讀到的數據根本是不被承認的。來看取款事務和轉賬事務併發時引發的髒讀場景：
     

時間	轉賬事務A	取款事務B
T1		開始事務
T2	開始事務
T3		查詢賬戶餘額爲1000元
T4		取出500元把餘額改爲500元
T5	查詢賬戶餘額爲500元（髒讀）
T6		撤銷事務餘額恢復爲1000元
T7	匯入100元把餘額改爲600元
T8	提交事務

　　在這個場景中，B希望取款500元而後又撤銷了動作，而A往相同的賬戶中轉賬100元，就因爲A事務讀取了B事務尚未提交的數據，因而造成賬戶白白丟失了500元。

不可重複讀（unrepeatable read） 
   不可重複讀是指A事務讀取了B事務已經提交的更改數據。假設A在取款事務的過程中，B往該賬戶轉賬100元，A兩次讀取賬戶的餘額發生不一致：

 

時間	取款事務A	轉賬事務B
T1		開始事務
T2	開始事務
T3		查詢賬戶餘額爲1000元
T4	查詢賬戶餘額爲1000元
T5		取出100元把餘額改爲900元
T6		提交事務
T7	查詢賬戶餘額爲900元（和T4讀取的不一致）

 　　在同一事務中，T4時間點和T7時間點讀取賬戶存款餘額不一樣。
幻象讀（phantom read） 
    A事務讀取B事務提交的新增數據，這時A事務將出現幻象讀的問題。幻象讀一般發生在計算統計數據的事務中，舉一個例子，假設銀行系統在同一個事務中，兩次統計存款賬戶的總金額，在兩次統計過程中，剛好新增了一個存款賬戶，並存入100元，這時，兩次統計的總金額將不一致：  

時間	統計金額事務A	轉賬事務B
T1		開始事務
T2	開始事務
T3	統計總存款數爲10000元
T4		新增一個存款賬戶，存款爲100元
T5		提交事務
T6	再次統計總存款數爲10100元（幻象讀）

　　如果新增數據剛好滿足事務的查詢條件，這個新數據就進入了事務的視野，因而產生了兩個統計不一致的情況。 
　　幻象讀和不可重複讀是兩個容易混淆的概念，前者是指讀到了其它已經提交事務的新增數據，而後者是指讀到了已經提交事務的更改數據（更改或刪除），爲了避免這兩種情況，採取的對策是不同的，防止讀取到更改數據，只需要對操作的數據添加行級鎖，阻止操作中的數據發生變化，而防止讀取到新增數據，則往往需要添加表級鎖——將整個表鎖定，防止新增數據。

第一類丟失更新 
    A事務撤銷時，把已經提交的B事務的更新數據覆蓋了。這種錯誤可能造成很嚴重的問題，通過下面的賬戶取款轉賬就可以看出來： 
    

時間	取款事務A	轉賬事務B
T1	開始事務
T2		開始事務
T3	查詢賬戶餘額爲1000元
T4		查詢賬戶餘額爲1000元
T5		匯入100元把餘額改爲1100元
T6		提交事務
T7	取出100元把餘額改爲900元
T8	撤銷事務
T9	餘額恢復爲1000元（丟失更新）

　　A事務在撤銷時，“不小心”將B事務已經轉入賬戶的金額給抹去了。 
第二類丟失更新 
　　A事務覆蓋B事務已經提交的數據，造成B事務所做操作丟失：  

時間	轉賬事務A	取款事務B
T1		開始事務
T2	開始事務
T3		查詢賬戶餘額爲1000元
T4	查詢賬戶餘額爲1000元
T5		取出100元把餘額改爲900元
T6		提交事務
T7	匯入100元
T8	提交事務
T9	把餘額改爲1100元（丟失更新）

 

 

數據庫事務隔離級別與鎖
關鍵字: 事務 
一,事務的4個基本特徵 

Atomic（原子性）： 
事務中包含的操作被看做一個邏輯單元，這個邏輯單元中的操作要 
麼全部成功，要麼全部失敗。 

Consistency（一致性）： 
只有合法的數據可以被寫入數據庫，否則事務應該將其回滾到最初 
狀態。 

Isolation（隔離性）： 
事務允許多個用戶對同一個數據進行併發訪問，而不破壞數據的正 
確性和完整性。同時，並行事務的修改必須與其他並行事務的修改 
相互獨立。 

Durability（持久性）： 
事務結束後，事務處理的結果必須能夠得到固化。 

以上屬於廢話 

二,爲什麼需要對事務併發控制 

如果不對事務進行併發控制，我們看看數據庫併發操作是會有那些異常情形

Lost update： 
兩個事務都同時更新一行數據，但是第二個事務卻中途失敗退出， 
導致對數據的兩個修改都失效了。

Dirty Reads： 
一個事務開始讀取了某行數據，但是另外一個事務已經更新了此數 
據但沒有能夠及時提交。這是相當危險的，因爲很可能所有的操作 
都被回滾。 

Non-repeatable Reads： 
一個事務對同一行數據重複讀取兩次，但是卻得到了不同的結果。 

Second lost updates problem： 
無法重複讀取的特例。有兩個併發事務同時讀取同一行數據，然後其 
中一個對它進行修改提交，而另一個也進行了修改提交。這就會造成 
第一次寫操作失效。 

Phantom Reads： 
事務在操作過程中進行兩次查詢，第二次查詢的結果包含了第一次查 
詢中未出現的數據（這裏並不要求兩次查詢的SQL語句相同）。這是 
因爲在兩次查詢過程中有另外一個事務插入數據造成的。 

三, 數據庫的隔離級別 

爲了兼顧併發效率和異常控制，在標準SQL規範中，定義了4個事務隔
離級別，（ORACLE和SQLSERER對標準隔離級別有不同的實現）

Read Uncommitted： 
直譯就是"讀未提交",意思就是即使一個更新語句沒有提交,但是別 
的事務可以讀到這個改變.這是很不安全的. 

Read Committed： 
直譯就是"讀提交",意思就是語句提交以後即執行了COMMIT以後 
別的事務就能讀到這個改變. 

Repeatable Read： 
直譯就是"可以重複讀",這是說在同一個事務裏面先後執行同一個 
查詢語句的時候,得到的結果是一樣的. 

Serializable: 
直譯就是"序列化",意思是說這個事務執行的時候不允許別的事務 
併發執行. 

四，隔離級別對併發的控制 

下表是各隔離級別對各種異常的控制能力。

LU	DR	NRR	SLU	PR
RU	Y	Y	Y	Y	Y
RC	N	N	Y	Y	Y
RR	N	N	N	N	Y
S	N	N	N	N	N

(注：LU：丟失更新；DR：髒讀；NRR：非重複讀；SLU：二類丟失更新；PR：幻像讀)

順便舉一小例。

MS_SQL:
--事務一
set transaction isolation level serializable
begin tran
insert into test values('xxx')

--事務二
set transaction isolation level read committed
begin tran
select * from test

--事務三
set transaction isolation level read uncommitted
begin tran
select * from test

在查詢分析器中執行事務一後，分別執行事務二，和三。結果是事務二會等待，而事務三則會執行。

ORACLE：
--事務一
set transaction isolation level serializable;
insert into test values('xxx');
select * from test;

--事務二
set transaction isolation level read committed--ORACLE默認級別
select * from test

執行事務一後，執行事務二。結果是事務二隻讀出原有的數據，無視事務一的插入操作。

讀者是否發現MS_SQL和ORACLE對併發控制的處理有所不同呢？

五,鎖 

下表是鎖的兼容或衝突情形。
現有 S U X
請求
S Y Y N
U Y N N
X N N N

現有	S	U	X
申請
S	Y	Y	N
U	Y	N	N
X	N	N	N

 

oracle:

 

   

 

六，隔離級別與鎖 

七，注意點

 

一般處理併發問題時的步驟：

1、開啓事務。

2、申請寫權限，也就是給對象(表或記錄)加鎖。

3、假如失敗，則結束事務，過一會重試。

4、假如成功，也就是給對象加鎖成功，防止其他用戶再用同樣的方式打開。

5、進行編輯操作。

6、寫入所進行的編輯結果。

7、假如寫入成功，則提交事務,完成操作。

8、假如寫入失敗，則回滾事務，取消提交。

9、(7.8)兩步操作已釋放了鎖定的對象，恢復到操作前的狀態。

 

對多表的操作最好一起取得鎖,或則保證處理順序;個人感覺還是前者好,雖然效率低一些

八，附 
查看鎖
ORACLE：
selectobject_name,session_id,os_user_name,oracle_username,process,locked_mode,status
from v$locked_object l, all_objects a
where l.object_id=a.object_id;

MS_SQL：EXEC SP_LOCK

 

 

 

事務（Transaction）是併發控制的基本單位。所謂的事務，它是一個操作序列，這些操作要麼都執行，要麼都不執行，它是一個不可分割的工作單位。例如，銀行轉賬工作：從一個賬號扣款並使另一個賬號增款，這兩個操作要麼都執行，要麼都不執行。所以，應該把它們看成一個事務。事務是數據庫維護數據一致性的單位，在每個事務結束時，都能保持數據一致性。

       針對上面的描述可以看出，事務的提出主要是爲了解決併發情況下保持數據一致性的問題。

       事務具有以下4個基本特徵。

●   Atomic（原子性）：事務中包含的操作被看做一個邏輯單元，這個邏輯單元中的操作要麼全部成功，要麼全部失敗。

●   Consistency（一致性）：只有合法的數據可以被寫入數據庫，否則事務應該將其回滾到最初狀態。

●   Isolation（隔離性）：事務允許多個用戶對同一個數據進行併發訪問，而不破壞數據的正確性和完整性。同時，並行事務的修改必須與其他並行事務的修改相互獨立。

●   Durability（持久性）：事務結束後，事務處理的結果必須能夠得到固化。

2.事務的語句
　開始事物：BEGIN TRANSACTION
　提交事物：COMMIT TRANSACTION
　回滾事務：ROLLBACK TRANSACTION
3.事務的4個屬性
     ①原子性(Atomicity)：事務中的所有元素作爲一個整體提交或回滾，事務的個元素是不可分的，事務是一個完整操作。
  ②一致性(Consistemcy)：事物完成時，數據必須是一致的，也就是說，和事物開始之前，數據存儲中的數據處於一致狀態。保證數據的無損。
  ③隔離性(Isolation)：對數據進行修改的多個事務是彼此隔離的。這表明事務必須是獨立的，不應該以任何方式以來於或影響其他事務。
  ④持久性(Durability)：事務完成之後，它對於系統的影響是永久的，該修改即使出現系統故障也將一直保留，真實的修改了數據庫
4.事務的保存點
     SAVE TRANSACTION 保存點名稱 --自定義保存點的名稱和位置
     ROLLBACK TRANSACTION 保存點名稱 --回滾到自定義的保存點

 

 其他高手的一些補充：

 事務的標準定義： 指作爲單個邏輯工作單元執行的一系列操作，而這些邏輯工作單元需要具有原子性，  一致性，隔離性和持久性四個屬性，統稱爲ACID特性。

所謂事務是用戶定義的一個數據庫操作序列,這些操作要麼全做要麼全不做,是一個不可分割的工作單位。例如,在關係數據庫中,一個事務可以是一條SQL語句、一組SQL語句或整個程序。 
事務和程序是兩個概念。一般地講,一個程序中包含多個事務。
事務的開始與結束可以由用戶顯式控制。如果用戶沒有顯式地定義事務,則由DBMS按缺省規定自動劃分事 
務。在SQL語言中,定義事務的語句有三條： 
BEGIN TRANSACTION 
COMMIT 
ROLLBACK

 

同生共死。。
顯示事務被用begin transaction 與 end transaction 標識起來，其中的 update 與delete 語句或者全部執行或者全部不執行。。如：
begin transaction T1
update student
set name='Tank'
where id=2006010
delete from student
where id=2006011
commit
簡單地說，事務是一種機制，用以維護數據庫的完整性。

其實現形式就是將普通的SQL語句嵌入到Begin Tran...Commit Tran 中（或完整形式 BeginTransaction...Commit Transaction)，當然，必要時還可以使用RollBack Tran 回滾事務，即撤銷操作。

利用事務機制，對數據庫的操作要麼全部執行，要麼全部不執行，保證數據庫的一致性。需要使用事務的SQL語句通常是更新和刪除操作等。

end transaction T1

關於savepoint

用戶在事務（transaction）內可以聲明（declare）被稱爲保存點（savepoint）
的標記。保存點將一個大事務劃分爲較小的片斷。

用戶可以使用保存點（savepoint）在事務（transaction）內的任意位置作標
記。之後用戶在對事務進行回滾操作（rolling back）時，就可以選擇從當前
執行位置回滾到事務內的任意一個保存點。例如用戶可以在一系列複雜的更
新（update）操作之間插入保存點，如果執行過程中一個語句出現錯誤，用
戶 可以回滾到錯誤之前的某個保存點，而不必重新提交所有的語句。

在開發應用程序時也同樣可以使用保存點（savepoint）。如果一個過程
（procedure）內包含多個函數（function），用戶可以在每個函數的開始位置
創建一個保存點。當一個函數失敗時，就很容易將數據恢復到函數執行之前
的狀態，回滾（roll back）後可以修改參數重新調用函數，或執行相關的錯誤
處理。

當事務（transaction）被回滾（rollback）到某個保存點（savepoint）後，
Oracle將釋放由被回滾語句使用的鎖。其他等待被鎖資源的事務就可以繼續
執行。需要更新（update）被鎖數據行的事務也可以繼續執行。

將事務（transaction）回滾（roll back）到某個保存點（savepoint）的過程如
下：
1. Oracle 回滾指定保存點之後的語句
2. Oracle 保留指定的保存點，但其後創建的保存點都將被清除
3. Oracle 釋放此保存點後獲得的表級鎖（table lock）與行級鎖（row
lock），但之前的數據鎖依然保留。

被部分回滾的事務（transaction）依然處於活動狀態，可以繼續執行。

一個事務（transaction）在等待其他事務的過程中，進行回滾（roll back）到
某個保存點（savepoint）的操作不會釋放行級鎖（row lock）。爲了避免事務
因爲不能獲得鎖而被掛起，應在執行 UPDATE 或 DELETE 操作前使用 FOR
UPDATE ... NOWAIT 語句。（以上內容講述的是回滾保存點之前所獲得的
鎖。而在保存點之後獲得的行級鎖是會被釋放的，同時保存點之後執行的
SQL 語句也會被完全回滾）。