主要內容
事務（transaction）是一系列的數據庫操作，是數據庫應用程序的基本邏輯單元。事務處理技術主要包括數據庫恢復技術和併發控制技術。數據庫恢復機制和併發控制機制是數據庫管理系統（DBMS）的重要組成部分。
事務的基本概念
事務是用戶定義的一個數據庫操作序列，這些操作要麼全做，要麼全不做，是一個不可分割的工作單位。
在關係數據庫中，一個事務可以是一條或一組SQL語句，甚至是整個程序。事務與程序是兩個概念，一般一個程序中包含多個事務。
事務的開始和結束可以由用戶顯式控制。如果用戶沒有顯式定義，DBMS會按默認規定自動劃分事務。
定義事務的三條SQL語句：
BEGIN TRANSACTION;
COMMIT; /*提交事務的所有操作，將數據庫的更新內容寫入物理數據庫中*/
ROLLBACK; /*撤回事務的所有操作，將數據庫恢復到事務開始時的狀態*/
事務通常是以BEGIN TRANSACTION開始，以COMMIT或ROLLBACK結束。
事務的ACID特性：原子性（Atomicity）、一致性（Consistency）、隔離性（Isolation）和持續性（Durability）。
（1）原子性：事務中的所有操作，要麼全部都做，要麼全部不做。
（2）一致性：若事務在執行過程中被中斷，就會出現部分更新被寫入物理數據庫，而部分操作未被執行的情況。事務的不完全執行可能使得數據庫處於一種不確定，不一致的狀態。例如在甲對乙的轉賬操作中，甲轉賬後操作被中斷，甲少了一筆錢，乙卻沒有得到那筆錢，這樣就不符合事務執行的理想結果。可見，事務的一致性和原子性是密切相關的。
（3）隔離性：併發執行的各個事務之間不能互相干擾。
（4）持續性：一個事務一旦提交，它對數據庫中數據的改變是永久的。
保護事務的ACID特性正是DBMS中數據恢復機制和併發控制機制的責任。
故障的種類
1. 事務內部的故障
事務內部的故障又分爲可預期和不可預期的故障。
對於可預期的故障，可以在定義事務的同時定義故障的處理方式。
例如在轉賬事務中應對轉出用戶餘額不足的情況：
BEGIN TRANSACTION
讀入甲的餘額BALANCE1;
BALANCE1 = BALANCE1 - AMOUNT; /*AMOUNT爲轉賬金額*/
/*該語句表示先轉賬*/
IF(BALANCE1 < 0) THEN
{
打印'餘額不足，不能轉賬';
ROLLBACK; /*如果餘額不足，撤回剛纔的轉賬操作*/
}
ELSE
{
讀入乙的餘額BALANCE2;
BALANCE2 = BALANCE2 + AMOUNT;
寫入BALANCE1、BALANCE2;
COMMIT; /*提交操作*/
}
實際上，事務內部更多的故障是不可預期的，這些故障不能由應用程序來處理。
事務故障意味着事務未被完全執行，因此數據庫可能處於不一致（不確定）狀態。恢復程序要在不影響其他事務的情況下，撤回（UNDO）該事務。
2. 系統故障
系統故障是指造成系統停止運轉的任何事件，其中最常見的情況就是電腦強制關機、臺式電腦被斷電等（超級心痛的...）。除此之外還包括硬件故障、操作系統故障等。
這類故障影響所有正在執行或未被寫入物理數據庫的事務，其中包括未完成的事務和已完成的事務。
未完成的事務可能有部分操作結果被寫入物理數據庫，使數據庫處於一種不確定的狀態。爲保證一致性，需要強行回滾（UNDO）該類事務。
已完成的事務可能有一部分甚至全部操作結果保存在緩衝區中，而發生系統故障時，緩衝區的內容會全部丟失，這同樣會使數據庫處於一種不確定的狀態，所以應該重做（REDO）此類事務。
3. 介質故障
介質故障指外存故障，如磁盤損壞、磁頭碰撞、瞬時強磁場干擾等。這類故障會破壞數據庫，並影響所有與被破壞數據庫有關的事務。這類故障比前兩類故障發生的可能性小，但破壞性最大。
4. 計算機病毒
計算機病毒的種類很多，小的只有20條指令，不到50B，大的可以像一個操作系統，由上萬條指令組成。
數據庫恢復技術
恢復的基本原理非常簡單：冗餘。數據庫中任何一部分被破壞或不正確的數據可以根據存儲在系統別處的冗餘數據來重建。
建立冗餘數據最常用的技術是數據轉儲和登記日誌文件。
數據轉儲
數據庫管理員定期地把整個數據庫複製到磁帶、磁盤或其他存儲介質上保存起來。這些備用的數據稱爲後備副本（backup）。
當數據庫遭到破壞後，可以將後備副本重新裝入，但重裝後備副本只能將數據庫恢復到轉儲完畢時的狀態（進行轉儲需要一個時間段），想要恢復到故障發生時的狀態，必須重新運行自轉儲以後的所有更新事務。
轉儲十分耗費時間和資源，不能頻繁地進行。
轉儲可以分爲靜態轉儲和動態轉儲：
（1）靜態轉儲：在系統中無運行事務時進行轉儲操作。靜態存儲簡單，但轉儲必須等待正運行的用戶事務結束才能進行，同樣下一個用戶事務必須等待轉儲完畢才能進行。顯然，這會降低數據庫的利用率。
（2）動態轉儲：轉儲期間允許事務運行，允許對數據庫的存取或修改。雖然動態轉儲克服了靜態轉儲的缺點，使得轉儲和用戶事務能併發運行，但是轉儲完畢時，後備副本保存的數據有可能是過時的。比如上一個時刻剛轉儲完數據A，下一個時刻就改變了數據A的值，那樣重裝後備副本時，載入的數據就是不正確的。
因此，必須把轉儲期間各事務對數據庫的修改登記下來，建立日誌文件（log file）。這樣，後備副本配合上日誌文件就能把數據庫恢復到某一時刻的正確狀態。
轉儲還可以再分爲海量轉儲和增量轉儲：
（1）海量轉儲：轉儲整個數據庫；
（2）增量轉儲：每次只轉儲上一次轉儲後更新過的數據。
從恢復角度來看，海量轉儲更方便用於恢復。但如果數據庫很大，事務處理又十分繁瑣，建議使用增量轉儲。
登記日誌文件
日誌文件是用來記錄事務對數據庫的更新操作的文件。不同數據庫系統採用的日誌文件格式不完全一樣。概括起來日誌文件主要有兩種格式：以記錄爲單位的日誌文件和以數據塊爲單位的日誌文件。
（1）以記錄爲單位的日誌文件需要登記三種日誌記錄（log record）：
1. 各個事務的開始（BEGIN TRANSACTION）標記；
2. 各個事務的結束（COMMIT或ROLLBACK）標記；
3. 各個事務的所有更新操作。
每個日誌記錄又包括：
1. 事務標識（哪個事務）；
2. 操作的類型（插入、刪除或修改）；
3. 操作對象；
4. 更新前的數據；
5. 更新後的數據。
（2）以數據塊爲單位的日誌文件：
日誌記錄的內容包括事務標識和被更新的數據塊。
由於更新前後的整塊數據都放入日誌文件中，所以不需要再記錄操作類型和操作對象等信息。
登記日誌文件的作用以及原則
（1）三個作用：
1. 事務故障和系統故障的恢復必須用到日誌文件；
2. 動態轉儲中必須建立日誌文件，後備副本和日誌文件結合起來纔能有效地恢復數據庫；
3. 靜態轉儲中也可以建立日誌文件，重裝後備副本後，可利用日誌文件把已完成的事務進行重做（REDO），並對故障發生時尚未完成的事務作撤銷（UNDO）處理。這樣不需要重新運行已完成的事務程序就能把數據庫恢復到數據庫故障前的某一時刻；
*從上面一行文字可以瞭解到重做和重新運行不是同一個概念。
（2）兩個原則：
1. 登記的次序嚴格按照併發事務執行的時間次序；
2. 必須先寫日誌文件，後更新數據庫。
把對數據的修改寫到數據庫和把表示這個修改的日誌記錄寫到日誌文件中是兩個不同的操作。
如果先修改數據庫，後寫日誌文件，以後就無法恢復這個修改了。
恢復策略
事務故障的恢復
事務故障是指事務在運行至正常終點前被終止，這時恢復子系統應利用日誌文件撤銷（UNDO）此事務對數據庫的修改。
（1）反向（從後往前）掃描日誌文件，對事務執行逆操作。插入→刪除，刪除→插入，修改後→修改前；
（2）直至讀到事務的開始標記（BEGIN TRANSACTION）。
系統故障的恢復
（1）正向（從前往後）掃描日誌文件，找出故障發生前已經提交（COMMIT）的事務，將其事務標識記入重做隊列（REDO-LIST），同時將未完成事務的事務標識記入撤銷隊列（UNDO-LIST）。
（2）對撤銷隊列中的各個事務進行撤銷處理。（如同事務故障的恢復）
（3）對重做隊列中的各個事務進行重做處理。正向掃描日誌文件，將日誌記錄中“更新後的值”直接寫入數據庫。
介質故障的恢復
介質故障是最嚴重的故障，只能重裝數據庫，然後重做已完成的事務。
（1）裝入最新的數據庫後備副本（靜態轉儲），使數據庫恢復到最近一次轉儲時的一致性狀態；
對於動態轉儲的後備副本，還需要裝入日誌文件，利用恢復系統故障的方法才能將數據庫恢復到一致性狀態。
（2）裝入日誌文件，重做已完成的事務。
利用檢查點技術的恢復策略
爲什麼要引入檢查點？
一方面是恢復數據庫時掃描整個日誌文件將耗費大量時間，另一方面是很多需要重做的事務實際上已經將更新操作結果寫入數據庫中，恢復子系統重新執行又浪費了大量時間。
引入檢查點（checkpoint）記錄，增加一個重新開始文件，並讓恢復子系統在登記日誌文件期間動態地維護（更新）日誌，這樣可以大大提高恢復數據庫的效率。
恢復數據庫時，恢復子系統將根據事務的不同狀態採取不同的恢復策略。
（1）不執行操作：
T1：在檢查點前提交
（2）執行重做操作：
T2：在檢查點前開始執行，在檢查點後、故障點前提交
T3：在檢查點後開始執行，在故障點前提交
（3）執行撤銷操作：
T4：在檢查點前開始執行，在故障點後提交
T5：在檢查點後開始執行，在故障點後提交
數據庫鏡像
根據數據庫管理員的要求，自動把整個數據庫或其中的關鍵數據複製到另一個磁盤上，每當主數據庫更新時，DBMS自動把更新的數據複製過去。
數據庫鏡像是通過複製數據實現的，頻繁的複製操作自然會降低系統運行效率，因此在實際應用中，用戶往往只選擇對關鍵數據和日誌文件進行鏡像。