數據庫事務介紹
數據庫事務(Database Transaction) ,是指作爲單個邏輯工作單元執行的一系列操作。 事務處理可以確保除非事務性單元內的所有操作都成功完成,否則不會永久更新面向數據的資源。通過將一組相關操作組合爲一個要麼全部成功要麼全部失敗的單元,可以簡化錯誤恢復並使應用程序更加可靠。一個邏輯工作單元要成爲事務,必須滿足所謂的ACID(原子性、一致性、隔離性和持久性)屬性。
例子:
設想網上購物的一次交易,其付款過程至少包括以下幾步數據庫操作:
· 更新客戶所購商品的庫存信息
· 保存客戶付款信息--可能包括與銀行系統的交互
· 生成訂單並且保存到數據庫中
· 更新用戶相關信息,例如購物數量等等
正常的情況下,這些操作將順利進行,最終交易成功,與交易相關的所有數據庫信息也成功地更新。但是,如果在這一系列過程中任何一個環節出了差錯,例如在更新商品庫存信息時發生異常、該顧客銀行帳戶存款不足等,都將導致交易失敗。一旦交易失敗,數據庫中所有信息都必須保持交易前的狀態不變,比如最後一步更新用戶信息時失敗而導致交易失敗,那麼必須保證這筆失敗的交易不影響數據庫的狀態--庫存信息沒有被更新、用戶也沒有付款,訂單也沒有生成。否則,數據庫的信息將會一片混亂而不可預測。
數據庫事務正是用來保證這種情況下交易的平穩性和可預測性的技術。
(atomic)(atomicity)
事務必須是原子工作單元;對於其數據修改,要麼全都執行,要麼全都不執行。通常,與某個事務關聯的操作具有共同的目標,並且是相互依賴的。如果系統只執行這些操作的一個子集,則可能會破壞事務的總體目標。原子性消除了系統處理操作子集的可能性。
(consistent)(consistency)
事務在完成時,必須使所有的數據都保持一致狀態。在相關數據庫中,所有規則都必須應用於事務的修改,以保持所有數據的完整性。事務結束時,所有的內部數據結構(如 B 樹索引或雙向鏈表)都必須是正確的。某些維護一致性的責任由應用程序開發人員承擔,他們必須確保應用程序已強制所有已知的完整性約束。例如,當開發用於轉帳的應用程序時,應避免在轉帳過程中任意移動小數點。
(insulation)(isolation)
由併發事務所作的修改必須與任何其它併發事務所作的修改隔離。事務查看數據時數據所處的狀態,要麼是另一併發事務修改它之前的狀態,要麼是另一事務修改它之後的狀態,事務不會查看中間狀態的數據。這稱爲隔離性,因爲它能夠重新裝載起始數據,並且重播一系列事務,以使數據結束時的狀態與原始事務執行的狀態相同。當事務可序列化時將獲得最高的隔離級別。在此級別上,從一組可並行執行的事務獲得的結果與通過連續運行每個事務所獲得的結果相同。由於高度隔離會限制可並行執行的事務數,所以一些應用程序降低隔離級別以換取更大的吞吐量。防止數據丟失
(Duration)(durability)
事務完成之後,它對於系統的影響是永久性的。該修改即使出現致命的系統故障也將一直保持。
企業級的數據庫管理系統(DBMS)都有責任提供一種保證事務的物理完整性的機制。就常用的SQL Server2000系統而言,它具備鎖定設備隔離事務、記錄設備保證事務持久性等機制。因此,我們不必關心數據庫事務的物理完整性,而應該關注在什麼情況下使用數據庫事務、事務對性能的影響,如何使用事務等等。
本文將涉及到在.net框架下使用C#語言操縱數據庫事務的各個方面。
體驗SQL語言的事務機制
作爲大型的企業級數據庫,SQL Server2000對事務提供了很好的支持。我們可以使用SQL語句來定義、提交以及回滾一個事務。
如下所示的SQL代碼定義了一個事務,並且命名爲"MyTransaction"(限於篇幅,本文並不討論如何編寫SQL語言程序,請讀者自行參考相關書籍):
事務有三種模型:
1.隱式事務是指每一條數據操作語句都自動地成爲一個事務,每個事務都有顯式的開始和結束標記。
2.顯式事務是指有顯式的開始和結束標記的事務,事務的開始是隱式的,事務的結束有明確的標記。
3.自動事務是系統自動默認的,開始和結束不用標記。
併發控制
1. 數據庫系統一個明顯的特點是多個用戶共享數據庫資源,尤其是多個用戶可以同時存取相同數據。
串行控制:如果事務是順序執行的,即一個事務完成之後,再開始另一個事務
並行控制:如果DBMS可以同時接受多個事務,並且這些事務在時間上可以重疊執行。
2.併發控制概述
事務是併發控制的基本單位,保證事務ACID的特性是事務處理的重要任務,而併發操作有可能會破壞其ACID特性。
DBMS併發控制機制的責任:
對併發操作進行正確調度,保證事務的隔離性更一般,確保數據庫的一致性。
如果沒有鎖定且多個用戶同時訪問一個數據庫,則當他們的事務同時使用相同的數據時可能會發生問題。由於併發操作帶來的數據不一致性包括:丟失數據修改、讀”髒”數據(髒讀)、不可重複讀、產生幽靈數據。
(1)丟失數據修改
當兩個或多個事務選擇同一行,然後基於最初選定的值更新該行時,會發生丟失更新問題。每個事務都不知道其它事務的存在。最後的更新將重寫由其它事務所做的更新,這將導致數據丟失。如上例。
再例如,兩個編輯人員製作了同一文檔的電子複本。每個編輯人員獨立地更改其複本,然後保存更改後的複本,這樣就覆蓋了原始文檔。最後保存其更改複本的編輯人員覆蓋了第一個編輯人員所做的更改。如果在第一個編輯人員完成之後第二個編輯人員才能進行更改,則可以避免該問題。
(2)讀“髒”數據(髒讀)
讀“髒”數據是指事務T1修改某一數據,並將其寫回磁盤,事務T2讀取同一數據後,T1由於某種原因被除撤消,而此時T1把已修改過的數據又恢復原值,T2讀到的數據與數據庫的數據不一致,則T2讀到的數據就爲“髒”數據,即不正確的數據。
例如:一個編輯人員正在更改電子文檔。在更改過程中,另一個編輯人員複製了該文檔(該複本包含到目前爲止所做的全部更改)並將其分發給預期的用戶。此後,第一個編輯人員認爲目前所做的更改是錯誤的,於是刪除了所做的編輯並保存了文檔。分發給用戶的文檔包含不再存在的編輯內容,並且這些編輯內容應認爲從未存在過。如果在第一個編輯人員確定最終更改前任何人都不能讀取更改的文檔,則可以避免該問題。
( 3)不可重複讀
指事務T1讀取數據後,事務T2執行更新操作,使T1無法讀取前一次結果。不可重複讀包括三種情況:
事務T1讀取某一數據後,T2對其做了修改,當T1再次讀該數據後,得到與前一不同的值。
(4)產生幽靈數據
按一定條件從數據庫中讀取了某些記錄後,T2刪除了其中部分記錄,當T1再次按相同條件讀取數據時,發現某些記錄消失
T1按一定條件從數據庫中讀取某些數據記錄後,T2插入了一些記錄,當T1再次按相同條件讀取數據時,發現多了一些記錄。
發表評論
所有評論
還沒有人評論,想成為第一個評論的人麼? 請在上方評論欄輸入並且點擊發布.