課程名稱：資料庫系統 授課老師：李春雄 博士

Presentation on theme: "課程名稱：資料庫系統 授課老師：李春雄 博士"— Presentation transcript:

1 課程名稱：資料庫系統 授課老師：李春雄 博士
第 十二 章 回復技術 課程名稱：資料庫系統 授課老師：李春雄 博士

2 本章學習目標 1.讓讀者瞭解資料庫系統的故障種類及如何檢視 系統記錄檔中的確認點與檢查點。 2.讓讀者瞭解資料庫系統在故障之後，如何重新回
到一個交易前的正確狀態之各種方法(延遲更新與 立即更新)。

3 本章內容 12-1 資料庫系統的故障種類 12-2 系統記錄(System log) 12-3 確認點(commit point)
12-4 檢查點(check point) 12-5 回復處理(Recovery)

4 12-1 資料庫系統的故障種類　 我們都知道，任何硬體設備及資訊系統都有可能產生不可預期的故障，而資料庫系統也不例外。因此，我們在學習資料庫系統的交易管理單元時，也必須要同時學習資料庫可能的故障種類，而在故障發生時，如何透過DBMS的「回復處理」機制，以確保資料正確性及一致性，這將是本單元重要的課題。 基本上，資料庫可能產生的故障種類有以下三種： 1.交易失敗（Transaction Failure） 2.系統故障（System Failure） 3.儲存媒體故障（Media Failure）

5 1.交易失敗（Transaction Failure）
【定義】是指在執行交易的過程中所產生的軟體錯誤。 【解決方法】 利用系統日誌(System Journal, System Log)來進行回復處理 【圖解說明】

6 2.系統故障（System Failure） 【定義】
因電源中斷、網路問題或其它硬體或軟體錯誤所導致的系統當機。因此，儲存在主記憶體的相關資料都會遺失。 【解決方法】 利用系統日誌(System Journal, System Log)來進行回復處理 【圖解說明】

7 3.儲存媒體故障（Media Failure）
【定義】 因磁碟之讀寫頭或磁區損壞的問題，導致儲存失敗。因此，會導致資料庫系統的資料遺失，是屬於資料庫系統最嚴重的一種故障。一般而言，儲存體可以分為兩種： (1)揮發性儲存體（Volatile Storage）：當系統當機、斷電或停電時， 其儲存資料就會消失的儲存結構。例如：主記憶體。 (2)非揮發性儲存體（Nonvolatile Storage）：這種儲存結構不會因為 系統當機、斷電或停電而使其儲存的資料消失。例如：硬碟。

8 3.儲存媒體故障（Media Failure）
【解決方法】利用儲存設備定期備份資料以回復遺失的資料。 【圖解說明】

9 12-2 系統記錄(System log) 【引言】
我們都知道，全世界沒有百分之百絕對穩定的資訊系統。那如何解決這些不可預期的故障呢？因此，資料庫管理系統就必須要具備「回復功能」，亦即資訊系統在發生意外情況時，系統自動回復到交易前的狀態。 資料庫管理系統(DBMS)為了達到「回復功能」。所以，DBMS在運作時，必須先將使用者的所有交易原始記錄完整的記錄下來，以便做為系統故障時，能夠依此記錄作為「回復」的重要資訊。而此資訊我就是稱為「系統記錄(System log)」。

10 12-2 系統記錄(System log)<續>
【定義】 系統記錄(System log)又可稱為日誌檔(Journal)，其目的是用來追蹤所有交易動作中可能影響到資料庫某些欄位值(項目值)的所有交易動作，以便日後需要復原時提供訊息。亦即將資料庫系統中任一項交易所進行的磁碟存取動作,完整的紀錄在一個檔案裡。

11 12-2 系統記錄(System log)<續>
因此，我們可以清楚得知，使用者在遠端對資料庫進行「交易操作」時，並非直接對資料庫進行讀出與寫入動作。它主要透過DBMS的「交易回復機制」，亦即將使用者對資料庫的讀出與寫入操作，先寫入到「系統記錄(System log)」檔中，然後再寫入到「資料檔(data file)」。如下圖所示：

12 12-2 系統記錄(System log)<續>
由於資訊系統的主機(伺服器)通常24小時運作，因此，SQL Server資料庫管理系統的系統日誌(System log)就是專門用來協助我們記錄系統中所有交易操作及相關的事件記錄。因此，當交易失敗或系統故障時，並未真正損毀實體磁碟上的系統日誌或資料庫，因此即可。只要針對系統日誌中的紀錄進行復原的動作，因此，身為一位專業的資料庫管理者的我們，就必須要有能力去檢查系統日誌是否有正常，因此，才能提供穩定的資訊統的使用環境。

13 【語法】 說明： 1.Start_Transaction ：開始交易 2.WRITE：寫入 3.READ： 讀取 4.COMMIT：確認交易 5. abort ：撤回 [Start_Transaction，T] [read，T，X] [Write，T，X，old_value，new_value] [commit，T] [abort，T]

14 因此，基本上，系統記錄都是存在於磁碟中，以避免無法預期的障礙而導致交易失敗，除此之外，我們還必須定期的備份到其他輔助記憶裝置上以確保資料庫的安全，如表12-1即為某一系統記錄的內容：
表12-1 系統記錄的內容 <2012><02><13><00:10 >< starts_transaction, T1> <2012><02><13><00:11 ><read, T1 , x> <2012><02><13><00:12 ><write, T1, x,1, 10> <2012><02><13><00:13 ><commit, T1 > <2012><02><13><00:14 ><starts, T2> <2012><02><13><00:15 ><read, T2 , y> <2012><02><13><00:16 ><check point> <2012><02><13><00:17 ><write, T2 ,y,2,5 > <2012><02><13><00:20 >…System crash<系統故障>…

15 2.READ(讀取)： 表示對資料庫進行讀取動作，是以<read_item, T ,X>表示。
<2012><02><13><00:10 >< starts_transaction, T1> <2012><02><13><00:11 ><read, T1 , x> <2012><02><13><00:12 ><write, T1, x,1, 10> <2012><02><13><00:13 ><commit, T1 > <2012><02><13><00:14 ><starts, T2> <2012><02><13><00:15 ><read, T2 , y> <2012><02><13><00:16 ><check point> <2012><02><13><00:17 ><write, T2 ,y,2,5 > <2012><02><13><00:20 >…System crash<系統故障>… 其中必須記錄下列事項: 1.Start_Transaction (開始交易)： 表示開始執行交易，是以<starts_transaction ,T>表示，其中T是系統給此交易的通用 名稱。 2.READ(讀取)： 表示對資料庫進行讀取動作，是以<read_item, T ,X>表示。

16 4.COMMIT(確認交易)： 表示確認交易成功結束，是以<commit, T>表示。
<2012><02><13><00:10 >< starts_transaction, T1> <2012><02><13><00:11 ><read, T1 , x> <2012><02><13><00:12 ><write, T1, x,1, 10> <2012><02><13><00:13 ><commit, T1 > <2012><02><13><00:14 ><starts, T2> <2012><02><13><00:15 ><read, T2 , y> <2012><02><13><00:16 ><check point> <2012><02><13><00:17 ><write, T2 ,y,2,5 > <2012><02><13><00:20 >…System crash<系統故障>… 其中必須記錄下列事項: 3.WRITE(寫入)： 表示對資料庫進行寫入動作，是以<write_item , T,X, old value ,new value>表示， 其中X是要去寫入的資料庫項目。 4.COMMIT(確認交易)： 表示確認交易成功結束，是以<commit, T>表示。 5.CHECKPOINT(檢查點)： 表示所有已經確認的交易之寫入動作，真正的存入到資料庫中。

17 12-3 確認點(commit point) 【定義】
當某個交易中所有存取資料庫的動作(Read與Write)都已經被成功的執行完畢，且所有交易動作(如：write寫入)會影響資料庫時，都會被記錄到系統日誌(System journal)中，我們就說此一交易進入確認點。在確認點之後的交易，稱為已確認(Committed)。如圖12-7確認點運作流程圖所示。

18 【確認點之後對資料庫的影響】 【定義】 (1)所有已確認(Committed)的交易，必須全部記錄寫入(Write)系統
【確認點之後對資料庫的影響】　 【定義】 (1)所有已確認(Committed)的交易，必須全部記錄寫入(Write)系統 日誌(System Log)中。 (2)系統會寫入一個commit記錄到系統日誌(System Log)中。 (3)交易中所有的寫入動作在已確認(Committed)之後，會永久的存入 資料庫中。

19 12-4 檢查點(check point) 【定義】
是指由系統(DBMS)定期發動的系統日誌記錄強迫寫入(System Log force-writing)，會對檢查點(check point)之前已經確認的交易的所有寫入(write)動作真正儲存到資料庫中。如圖12-8檢查點運作流程圖所示。

20 【檢查點之後對資料庫的影響】 1.暫停所有正在執行的交易。 2.將主記憶體中已經確認(Committed)的交易寫入(Write)動作，
強迫寫入到磁碟的資料庫中。 3.系統會自動寫入一個<checkpoint>記錄到系統記錄中。 4.重新開始被暫停的交易。 說明：檢查點(check point)是指系統設定的時間（例如：10秒），DBMS會依照「檢查點(check point)」所設定的時間值，進行以上四個步驟。

21 12-5 回復處理(Recovery) 【定義】 是指在資料庫系統中，當資料庫在故障之後，又可以重新回到一個交易前的正確狀態。 【方法】
1.延遲更新(Deferred-update) 2.立即更新(Immediate-update)

22 【程序】 步驟1：設定Undo(取消)與Redo(重做)的串列之空集合 UNDO( )串列＝｛｝ REDO( )串列＝｛｝
【程序】　 步驟1：設定Undo(取消)與Redo(重做)的串列之空集合 UNDO( )串列＝｛｝ REDO( )串列＝｛｝ 步驟2：在交易活動時，將交易進入UNDO( )串列。 步驟3：當交易遇到commit確認點時，將UNDO( )串列中的交易移到 REDO( )串列中。 步驟4：當交易遇到checkpoint檢查點時，移除所有在REDO( )串列的 交易。 

23 12-5.1 延遲更新(Deferred-update)
【定義】 將交易執行的所有資料庫更新操作都寫到系統日誌(System Log)與主記憶體(Main memory)中，並非真正去更改資料庫中的內容，必須要等到確認點(commit point)之後，此時交易的更改動作才會真正寫入資料庫。 【使用的演算法】no-undo/ Redo

24 【運作流程圖】 揮發性記憶體 非揮發性記憶 【說明】
【運作流程圖】　 揮發性記憶體 非揮發性記憶 【說明】 在圖12-9延遲更新運作流程圖中，延遲更新時，交易未到達確認點(commit point)之前，資料庫中資料項x與y的內容不會改變。

25 【作法】 1.當系統軟體故障時，不需要進行UNDO動作，只要進行REDO動作 即可。【使用的演算法】no-undo/ Redo
2.未達到確認點(commit point)時，不能真正更改到資料庫中的內容， 所以不須要進行UNDO動作，因此，可以忽略原來的交易程序即可。 【使用的演算法】no-undo 3.當交易程序到達確認點(commit point)時，只要進行REDO動作。也 就是由上而下的動作再執行一次。 【使用的演算法】 Redo

26 【舉例】　 某一交易的系統日誌(System Log)的內容如下： 時間由t1~t12，實際交易過程如下所示：

27 【執行結果分析】 1.在System crash系統故障之前 UNDO( )與REDO( )串列的結果如下：
(1)UNDO( )串列={T3} (2)REDO( )串列={T2} 2.在System crash系統故障之後 (1)UNDO( )串列中的交易T3會被忽略，因為沒有真正更改到資料庫 中的內容，所以不須要進行UNDO動作。 (2)REDO( )串列中的交易T2有執行寫入動作，也就是<write,T2, z,3, 15>與<write, T2, x, 5,55>交易寫入動作由上而下重新執行一次。

28 12-4.2 立即更新(Immediate-update)
【定義】 當交易下達所有寫入動作(Write)命令時，交易未到達確認點(commit point)之前，就會將交易記錄真正寫入到資料庫中，並且這些動作也會被記錄在系統日誌(System Log)。 【使用的演算法】undo/No-redo

29 【運作流程圖】　 揮發性記憶體 非揮發性記憶 【說明】在圖12-10立即更新運作流程圖中，立即更新時交易在未到達確認點(commit point)之前，就會立即更改資料庫中資料項x與y的內容。

30 【作法】 1.建立未確認的UNDO( )串列與建立通過檢查點的已確認的REDO( )串列。
【作法】　 1.建立未確認的UNDO( )串列與建立通過檢查點的已確認的REDO( )串列。 2.當系統軟體故障時，只要進行UNDO動作以回復到先前的正確狀態。

31 【舉例】　 某一交易的系統日誌(System Log)的內容如下： 時間由t1~t12，實際交易過程如下所示：

32 【執行結果分析】 1.在System crash系統故障之前 UNDO( )與REDO( )串列的結果如下：
【執行結果分析】　 1.在System crash系統故障之前 UNDO( )與REDO( )串列的結果如下： (1)UNDO( )串列={T3} (2)REDO( )串列={T2} 2.在System crash系統故障之後 (1)UNDO( )串列中的交易T3的所有寫入動作，都會被執行UNDO動作， 也就是執行<write,T3, y,100, 10>動作。 註：由下而上執行回復的動作。因為已經真正更改到資料庫中的內容，所以必須要進行UNDO動作。 (2)REDO( )串列中的交易T2有執行寫入動作，也就是<write,T2, z,3, 15>與<write,T2, x,5, 55>這兩個交易寫入動作由上而下重新執行一次。