分布式數(shù)據(jù)庫中的事務(wù)管理和恢復(fù)

分布式數(shù)據(jù)庫中的事務(wù)管理和恢復(fù)第一頁，共五十頁，2022年，8月28日4.1分布式事務(wù)概述4.2分布式事務(wù)的執(zhí)行與恢復(fù)4.3兩階段提交協(xié)議4.4分布式數(shù)據(jù)庫中的數(shù)據(jù)更新4.5分布式事務(wù)增強數(shù)據(jù)庫一致性4.6本章小結(jié)第二頁，共五十頁，2022年，8月28日4.1分布式事務(wù)概述4.1.1分布式事務(wù)定義和特性4.1.2分布式事務(wù)的結(jié)構(gòu)和事務(wù)狀態(tài)4.1.3分布式事務(wù)管理的問題和目標第三頁，共五十頁，2022年，8月28日4.1.1分布式事務(wù)定義和特性1.分布式事務(wù)的定義

事務(wù)——是為了實現(xiàn)特定的業(yè)務(wù)功能，而訪問數(shù)據(jù)庫的一個最小的邏輯工作單位，它是一個操作序列。分布式事務(wù)——在分布式系統(tǒng)中，任何一個應(yīng)用的請求最終都將轉(zhuǎn)化成對分布在網(wǎng)絡(luò)中相應(yīng)站點上數(shù)據(jù)庫存取操作的序列，因此分布式數(shù)據(jù)庫系統(tǒng)中的事務(wù)是一個分布式操作的序列，因被操作的數(shù)據(jù)分布在不同的站點上，所以稱為分布式事務(wù)。第四頁，共五十頁，2022年，8月28日集中式事務(wù)與分布式事務(wù)的比較：繼承——外部特性擴充——執(zhí)行方式不同，ACID特性復(fù)雜恢復(fù)第五頁，共五十頁，2022年，8月28日在分布式數(shù)據(jù)庫系統(tǒng)中，一個分布式事務(wù)即全局事務(wù)，通常由一個主（父）事務(wù)和在不同站點上執(zhí)行的子事務(wù)（局部事務(wù)）組成。一般的，主事務(wù)負責事務(wù)的開始，提交和異常中止。各個子事務(wù)完成對相應(yīng)站點上數(shù)據(jù)庫的訪問操作。全局事務(wù)——一個要求訪問或更新多個站點上數(shù)據(jù)的事務(wù)。局部事務(wù)——一個僅僅訪問或更新一個站點上數(shù)據(jù)的事務(wù)。第六頁，共五十頁，2022年，8月28日2.分布式事務(wù)的特性分布式數(shù)據(jù)庫系統(tǒng)中的事務(wù)也應(yīng)具有事務(wù)的ACID四個特性。即：原子性（atomicity）——指事務(wù)執(zhí)行時的不可分割性。這個特性確保了每個事務(wù)要么全部發(fā)生，要么全部不發(fā)生。如果發(fā)生，就是不可分割的瞬間的操作。當一個事務(wù)處在處理過程中時，其他進程（無論是否與事務(wù)有關(guān)）都不能看到任何中間狀態(tài)。一致性（consistency）——指事務(wù)的正確性，或者說一個分布式事務(wù)是一個使分布式數(shù)據(jù)庫從一個一致狀態(tài)轉(zhuǎn)變?yōu)榱硪粋€狀態(tài)的正確程序。例如在一個銀行系統(tǒng)中，最關(guān)鍵的不變性是資金守恒規(guī)則。在任何內(nèi)部轉(zhuǎn)帳之后，銀行的資金賬目應(yīng)與轉(zhuǎn)帳前保持一致，但是在事務(wù)執(zhí)行的短暫時刻內(nèi)，這種不變性會受到損害。然后，事務(wù)結(jié)束之后，這種損害就沒有了。如果若干個事務(wù)并發(fā)執(zhí)行的結(jié)果與按希望的順序串行執(zhí)行的結(jié)果時等價的，稱該若干個事務(wù)的并發(fā)執(zhí)行是可串行的，且其結(jié)果是正確的。因此，一致性特征也用可串行性（serializability）特征表示，此時，事務(wù)具有ASID特性。第七頁，共五十頁，2022年，8月28日隔離性（isolaty）——指在一個正在執(zhí)行的事務(wù)在其提交之前，決不允許把它對共享的數(shù)據(jù)所作改變的結(jié)果提供給其他事務(wù)使用。這就是說，事務(wù)的執(zhí)行似乎與其他事務(wù)相隔離，即事務(wù)的執(zhí)行不應(yīng)受到其他并發(fā)事務(wù)執(zhí)行的干擾。保持事務(wù)的隔離性是有許多原因的，保證維護事務(wù)的交互一致性是原因之一。耐久性（durability）——指一旦某個事務(wù)被提交了，則無論系統(tǒng)發(fā)生任何故障，都不會丟失該事務(wù)的執(zhí)行結(jié)果。這就是說，已提交事務(wù)對數(shù)據(jù)庫的改變在數(shù)據(jù)庫中應(yīng)該是持續(xù)存在的，這些改變不會因為故障而發(fā)生丟失。第八頁，共五十頁，2022年，8月28日例如：某銀行的存款系統(tǒng)，賬號001的存款余額為0元。分布式事務(wù)T由兩個子事務(wù)T1和T2組成。站點i上的事務(wù)T1在001賬號中存入1000元。如果在事務(wù)T1還未提交之前，站點j上的事務(wù)T2讀取此1000元，并從001賬號中取走1000元，事務(wù)T2提交，此時現(xiàn)金1000元就交給事務(wù)T2的用戶。假定此時因某種原因，使事務(wù)T1的存款操作無效，即事務(wù)T1撤銷。事務(wù)T1的撤銷要求事務(wù)T2也撤銷，因為事務(wù)T2的操作是建立在事務(wù)T1操作的基礎(chǔ)上的。但是此時要撤銷事務(wù)T2的操作是不可能的了，因為事務(wù)T2已經(jīng)提交，其產(chǎn)生的結(jié)果是無法由系統(tǒng)來撤銷的。第九頁，共五十頁，2022年，8月28日

由于分布式數(shù)據(jù)庫的分布特性，使得分布式事務(wù)還具有自己獨有的特性：在分布式事務(wù)中，除需要考慮訪問數(shù)據(jù)庫的存取操作序列外，還必須考慮大量的數(shù)據(jù)傳送，通信原語和控制報文等，這些都是分布式事務(wù)所特有的性質(zhì)。第十頁，共五十頁，2022年，8月28日4.1.2分布式事務(wù)的結(jié)構(gòu)和事務(wù)狀態(tài)第十一頁，共五十頁，2022年，8月28日應(yīng)用分布式事務(wù)的結(jié)構(gòu)

分布式事務(wù)分布式事務(wù)分布式事務(wù)子事務(wù)子事務(wù)子事務(wù)子事務(wù)子事務(wù)子事務(wù)第十二頁，共五十頁，2022年，8月28日分布式事務(wù)的一般結(jié)構(gòu)為：BeginTransaction原語：開始一個事務(wù)T1[T2[：子事務(wù)或操作序列：Tn[Commit原語：事務(wù)成功完成的結(jié)束RollBack或Abort原語：事務(wù)失敗的結(jié)束第十三頁，共五十頁，2022年，8月28日2.分布式數(shù)據(jù)庫中進程的協(xié)作（1）兩個概念進程:是一個具有一定獨立功能的程序關(guān)于某個數(shù)據(jù)集合的一次運行活動。它有兩個側(cè)面:進程說明：定義進程的行為模式,包括數(shù)據(jù)和對數(shù)據(jù)的一組操作,執(zhí)行這組操作,完成某一功能。進程執(zhí)行：按進程說明中所定義的模式來啟動這個進程，執(zhí)行其中的那組操作。事務(wù)代理（Agent）：在分布式數(shù)據(jù)庫系統(tǒng)中，為了完成在不同站點上的相應(yīng)功能，分布式應(yīng)用必須在這些站點中執(zhí)行若干進程，這些進程就稱為該應(yīng)用在那個站點上的“事務(wù)代理”。所以，一個事務(wù)代理是一個本地進程，它代表應(yīng)用來執(zhí)行某些 動作。啟動一個事務(wù)造成在某一站點開始執(zhí)行那個事務(wù)代 理。這個事務(wù)代理的執(zhí)行又可能引起在另一個站點開始執(zhí)行 另一個事務(wù)。第十四頁，共五十頁，2022年，8月28日（2）進程的協(xié)作為了協(xié)調(diào)地執(zhí)行分布式應(yīng)用的全局操作，分駐于不同站點的諸事務(wù)代理必須進行協(xié)調(diào)。為考慮事務(wù)的特性，把各站點上的諸代理組建成協(xié)作進程來完成一個全局應(yīng)用，并作如下規(guī)定：1）每一應(yīng)用均有一個負責啟動整個事務(wù)的總代理或稱根代理，建立總代理的站點稱為源站點；2）只有總代理才能發(fā)出全局有效的事務(wù)開始，提交和撤銷原語；3）只有總代理才能請求建立新的事務(wù)代理； 4）各站點上的子事務(wù)都執(zhí)行成功，總代理才能決定提交該事務(wù)，否則總代理將決定撤銷該事務(wù)。第十五頁，共五十頁，2022年，8月28日FUND_TRANSFER:

Read(terminal,$AMOUNT,$FROM_ACC,$TO_ACC);Begin_Transaction;SelectAMOUNTinto$FROM_AMOUNTfromACCOUNTwhereACCOUNT_NUMBER=$FROM_ACC;if$FROM_AMOUNT-$AMOUNT<0thenabortelsebeginUpdateACCOUNTsetAMOUNT=AMOUNT-$AMOUNTwhereACCOUNT_NUMBER=$FROM_ACC;UpdateACCOUNTsetAMOUNT=AMOUNT-$AMOUNTwhereACCOUNT_NUMBER=$TO_ACC;Commitend圖4.1全局級的FUND_TRANSFER事務(wù)第十六頁，共五十頁，2022年，8月28日ROOT_AGENTAGENT:輸入：匯出金額和轉(zhuǎn)出/轉(zhuǎn)入賬號事務(wù)開始：檢查轉(zhuǎn)出賬號中是否又足夠的轉(zhuǎn)出資金更新轉(zhuǎn)出賬號存款余額創(chuàng)建代理Agent向代理送信息：轉(zhuǎn)入帳號，金額等待來自Agent的消息成功提交事務(wù)：成功結(jié)束否撤銷事務(wù)：失敗結(jié)束接收來自根代理的消息更新轉(zhuǎn)入賬號存款余額發(fā)送執(zhí)行消息給根代理（成功或失?。┑谑唔?，共五十頁，2022年，8月28日ROOT-AGENT；Read(terminal,$AMOUNT,$FROM_ACC,$TO_ACC);Begin_transaction;SelectAMOUNTinto$FROM_AMOUNTfromACCOUNTwhereACCOUNT_NUMBER=$FROM_ACCOUNT;if$FROM_AMOUNT-$AMOUNT<0thenabortelsebeginUpdateACCOUNTsetAMOUNT=AMOUNT-$AMOUNTwhereACCOUNT=$FROM_ACC;CreateAGENT;SENDtoAGENT($AMOUNT,$TO_ACC);CommitendAGENT;ReceivefromROOT_AGENT($AMOUNT,$TO_ACC);UpdateACCOUNTsetAMOUNT=AMOUNT+$AMOUNTwhereACCOUNT=$TO_ACC;SendtoROOT_AGENT(‘SUCCESS’/’FALL’)圖4.3兩個代理組成的FUND_TRANSFER事務(wù)第十八頁，共五十頁，2022年，8月28日4.1.3分布式事務(wù)管理的問題和目標分布式事務(wù)管理的問題（1）處理數(shù)據(jù)項的多個副本分布式事務(wù)管理負責保持同一數(shù)據(jù)的多個副本間的一致性。（2）單個站點的故障當故障站點得到恢復(fù)時，DDBMS協(xié)同該故障站點上的DBMS，必須在該站點與系統(tǒng)重新連接時，使它的局部數(shù)據(jù)與其他站點同步。（3）通信網(wǎng)絡(luò)的故障系統(tǒng)必須有能力處理一個或多個連接站點的通信網(wǎng)絡(luò)故障。這個問題的一個極端情況是發(fā)生網(wǎng)絡(luò)分割。（4）分布式提交如果在提交一個分布式事務(wù)過程中至少有一個站點發(fā)生故障的話，那么這個分布式事務(wù)的提交將會產(chǎn)生問題。第十九頁，共五十頁，2022年，8月28日2.分布式事務(wù)管理的目標事務(wù)管理的任務(wù)就是負責當若干個事務(wù)并發(fā)執(zhí)行和事務(wù)執(zhí)行發(fā)生錯誤時，使數(shù)據(jù)庫仍保持一致狀態(tài)。

第二十頁，共五十頁，2022年，8月28日例如：某公司在銀行中有A,B兩個賬號，現(xiàn)在公司想從賬號A中取出一萬元，存入賬號B。那么就可以定義一個事務(wù)，該事務(wù)包括兩個操作，第一個操作是從賬號A中減去一萬元，第二個操作是向賬號B中加入一萬元。在事務(wù)開始時，數(shù)據(jù)庫是處于一個一致性狀態(tài)。在事務(wù)執(zhí)行時，如果只做第一個操作則用戶邏輯上就會發(fā)生錯誤，少了一萬元，這時數(shù)據(jù)庫就處于非一致性狀態(tài)。當我們接著做第二個操作，且成功提交后，數(shù)據(jù)庫又處在了一致性的狀態(tài)。第二十一頁，共五十頁，2022年，8月28日

事務(wù)管理所追求的理想目標是高執(zhí)行效率，高并行性和高可靠性。這三大理想目標往往不能兼得，因為他們之間密切相關(guān)，而又矛盾。可靠性措施會使效率下降，而事務(wù)運行效率不僅取決于采用的策略，還與下列因素有關(guān)：（1）CPU和主存利用率（2）控制報文（3）相應(yīng)時間（4）可用性由此可見事務(wù)管理的目標是：（1）維護分布式事務(wù)的原子性，一致性，耐久性和隔離性。（2）獲得最小的主存和CPU開銷，降低控制報文的傳輸個數(shù)和加快分布式事務(wù)的響應(yīng)速度；（3）獲得最大限度的系統(tǒng)可靠性和可用性。第二十二頁，共五十頁，2022年，8月28日4.2分布式事務(wù)的執(zhí)行與恢復(fù)第二十三頁，共五十頁，2022年，8月28日4.2.1分布式事務(wù)管理的抽象模型在分布式數(shù)據(jù)庫系統(tǒng)中，事務(wù)管理功能分成兩個層次。在每個站點上，又類似于集中式數(shù)據(jù)庫系統(tǒng)中的局部事務(wù)管理器（LTM）進行局部事務(wù)的管理，負責本站點事務(wù)的執(zhí)行，完成對本站點數(shù)據(jù)庫數(shù)據(jù)的訪問；對整個分布式數(shù)據(jù)庫系統(tǒng)，由駐留在各個站點上的分布式事務(wù)管理器（DTM）共同協(xié)作，實現(xiàn)對分布式事務(wù)的協(xié)調(diào)和管理。第二十四頁，共五十頁，2022年，8月28日圖4.5分布式事務(wù)管理的抽象模型站點1站點3站點2本地事務(wù)管理器LTM1分布式事務(wù)管理器DTM1分布式事務(wù)管理器DTM1本地事務(wù)管理器LTM2分布式事務(wù)管理器DTM1本地事務(wù)管理器LTM3第二十五頁，共五十頁，2022年，8月28日

局部事務(wù)管理器LTM的結(jié)構(gòu)和功能在許多方面與集中式系統(tǒng)類似，主要包括：（1）保證本地事務(wù)的ACID特性；（2）維護一個用于恢復(fù)的日志，代替DTM把用于分布式事務(wù)執(zhí)行和恢復(fù)的信息記入日志。（3）參與適當?shù)牟l(fā)控制模式，以協(xié)調(diào)在該站點上執(zhí)行的事務(wù)的并發(fā)執(zhí)行。接收并聽從本站點上DTM代理發(fā)來的LOG原語，記入日志并執(zhí)行之。LOG原語包括：localbegin_transaction,localcommitlocalabort第二十六頁，共五十頁，2022年，8月28日分布式事務(wù)管理器DTM的功能包括：（1）保證分布式事務(wù)的ACID特性，尤其是執(zhí)行分布式事務(wù)的原子性,使每個站點的子事務(wù)都成功執(zhí)行，或都不執(zhí)行。這是通過向各個站點發(fā)begin_transaction,commit或abort,create原語來實現(xiàn)的。（2）負責協(xié)調(diào)由該站點發(fā)出的所有分布式事務(wù)的執(zhí)行。包括：啟動分布式事務(wù)的執(zhí)行；將分布式事務(wù)分解為一些子事務(wù)，并將這些子事務(wù)分派到恰當?shù)恼军c上去執(zhí)行；決定分布式事務(wù)的終止，即決定在該分布式事務(wù)中所包含的所有站點上的子事務(wù)都撤銷或都提交。

第二十七頁，共五十頁，2022年，8月28日（3）支持分布式事務(wù)的執(zhí)行位置透明性，這也是分布式事務(wù)管理的最基本要求。分布式事務(wù)管理器根據(jù)事務(wù)內(nèi)部的邏輯劃分為若干子事務(wù)，按某種要求分布到相應(yīng)站點上執(zhí)行，最后由源發(fā)站點提供事務(wù)的最終結(jié)果。它實現(xiàn)了對網(wǎng)絡(luò)上各站點的各個子事務(wù)的監(jiān)督與管理，完成對整個分布式事務(wù)執(zhí)行過程的調(diào)度和管理，從而保證分布式數(shù)據(jù)庫系統(tǒng)的高效率。第二十八頁，共五十頁，2022年，8月28日4.2.2分布式事務(wù)執(zhí)行的控制模型分布式事務(wù)的控制模型是指協(xié)調(diào)分布式事務(wù)中各成員DBMS執(zhí)行其子事務(wù)的通用方法；控制分布式事務(wù)執(zhí)行的控制模型有:1）主從模型2）三角模型3）層次控制模型第二十九頁，共五十頁，2022年，8月28日圖4.6分布式執(zhí)行的主從控制模型第三十頁，共五十頁，2022年，8月28日圖4.7分布式執(zhí)行的三角控制模型第三十一頁，共五十頁，2022年，8月28日圖4.8分布式執(zhí)行的層次控制模型第三十二頁，共五十頁，2022年，8月28日4.2.3分布式數(shù)據(jù)庫系統(tǒng)中的故障第三十三頁，共五十頁，2022年，8月28日4.2.4事務(wù)故障恢復(fù)的基本概念研究數(shù)據(jù)庫系統(tǒng)中故障的恢復(fù)，主要是指如何恢復(fù)因故障而破壞的數(shù)據(jù)庫，使數(shù)據(jù)庫恢復(fù)到一個正確，一致的狀態(tài)?；謴?fù)的基本原理是數(shù)據(jù)冗余，即利用冗余存儲在別處的信息和數(shù)據(jù)，部分或全部重建數(shù)據(jù)庫。1.事務(wù)故障和事務(wù)恢復(fù)當發(fā)生事務(wù)故障時，保證事務(wù)原子性的措施稱為事務(wù)故障恢復(fù)，簡稱為事務(wù)恢復(fù)。事務(wù)恢復(fù)主要時依靠日志來實現(xiàn)的。2.事務(wù)狀態(tài)及狀態(tài)轉(zhuǎn)移為保證可恢復(fù)性，系統(tǒng)需要保存事務(wù)的起始，終止，提交或撤銷的時間軌跡，事務(wù)恢復(fù)管理器還對下列操作進行跟蹤記錄。第三十四頁，共五十頁，2022年，8月28日1)begintransaction:標記事務(wù)開始執(zhí)行。2)read或write:表示事務(wù)對某個數(shù)據(jù)項進行讀或?qū)憽?)End_transaction:表示事務(wù)的讀或?qū)懖僮饕呀?jīng)結(jié)束，并標記事務(wù)執(zhí)行結(jié)束。但是，在這一點，需要檢查被該事務(wù)所作的改變是否永久寫入數(shù)據(jù)庫（已提交），或事務(wù)由于違反可串行性或其他原因而被撤銷。4)commit_transaction：表示事務(wù)已經(jīng)成功結(jié)束,因此事務(wù)執(zhí)行的任何改變可以安全提交到數(shù)據(jù)庫并且不會被撤銷。5)rollback(或abort)：表示事務(wù)沒有成功結(jié)束,因此必須撤銷事務(wù)對數(shù)據(jù)庫所作的任何改變或影響。

第三十五頁，共五十頁，2022年，8月28日

read/writeBeginendtransactiontransactioncommitabortabort

activePartiallycommittedcommittedfailedterminated第三十六頁，共五十頁，2022年，8月28日3.事務(wù)的提交點當事務(wù)T所有的站點數(shù)據(jù)庫存取操作都已成功執(zhí)行，并且所有操作對數(shù)據(jù)庫的影響都已記錄在日志中時，該事務(wù)T就到達提交點(committedpoint).提交點后事務(wù)就成為已提交的事務(wù)，并且假定其結(jié)果已永久記錄在數(shù)據(jù)庫中(事務(wù)的永久性)。然后事務(wù)在日志中寫入提交記錄[commit,T].在系統(tǒng)發(fā)生故障時，需要掃描日志，檢查那些已在日志中寫入[start_transaction,T],但沒有寫入[commit,T]的所有事務(wù)T；恢復(fù)時必須回滾這些事務(wù)以取消他們對數(shù)據(jù)庫的影響。此外，還必須對日志中記錄的已提交事務(wù)的所有寫操作進行恢復(fù)，這樣他們對數(shù)據(jù)庫的作用才可根據(jù)這些記錄重做。需要注意的是，必須將日志文件保存在磁盤上。在事務(wù)到達提交點以前，還未寫到磁盤的日志的任何部分，必須被寫入磁盤，這稱為事務(wù)提交前強制寫(forcewriting)日志。第三十七頁，共五十頁，2022年，8月28日4.日志，檔案庫和檢查點(1)日志為了能夠從故障狀態(tài)中恢復(fù)由影響的事務(wù)，系統(tǒng)維護一個日志(log)來保存所有影響數(shù)據(jù)庫項的值的事務(wù)操作的信息，這些信息可以用于故障時的恢復(fù)。日志保存在磁盤上，這樣除了磁盤和災(zāi)難性故障外，它不會受到任何影響。另外，日志會被定期備份到歸檔存儲設(shè)備（例如磁帶）中，以預(yù)防磁盤和災(zāi)難性故障。下面列出的是日志的條目類型（稱為日志記錄）和每個類型設(shè)計的相關(guān)動作。在條目中。T表示唯一事務(wù)標識(transaction_id)用于標識每個事務(wù)，通常由系統(tǒng)自動生成：第三十八頁，共五十頁，2022年，8月28日[start_transaction,T]:表示事務(wù)T開始執(zhí)行。[write_item,T,X,舊值,新值]:表示事務(wù)T已將數(shù)據(jù)項X的值從舊值改為新值。[read_item,T,X]:表示事務(wù)T已讀取數(shù)據(jù)項X的值。[commit,T]:表示事務(wù)T已成功完成，其結(jié)果已被提交(永久記錄)給數(shù)據(jù)庫。[abort,T]:表示事務(wù)T已被撤銷。Log:記錄長度及用于恢復(fù)過程的輔助信息，如指向本事務(wù)前一日志記錄的指針，檢查點記錄等。第三十九頁，共五十頁，2022年，8月28日(2)檔案庫一個大型的系統(tǒng)一天可以很容易地產(chǎn)生大量的Log記錄．因此，將日志全部存放在盤中是不現(xiàn)實的。故一般將日志劃分為兩部分，一部分是當前活動的聯(lián)機部分，存放在直接存取設(shè)備上，稱為直接存取數(shù)據(jù)集(directaccessdataset)或簡稱日志數(shù)據(jù)集(logdataset).另一部分是檔案存儲部分，存放在二級存儲設(shè)備上，例如磁帶上。每當數(shù)據(jù)集滿時就轉(zhuǎn)存到檔案存儲設(shè)備中去。存放日志的檔案存儲設(shè)備稱日志檔案庫(logarchive).為了防止因介質(zhì)故障而破壞數(shù)據(jù)庫，要定期將整個數(shù)據(jù)庫的全部內(nèi)容轉(zhuǎn)儲到檔案庫中去。存放數(shù)據(jù)庫的檔案存儲設(shè)備稱數(shù)據(jù)庫檔案庫(DBarchive).

第四十頁，共五十頁，2022年，8月28日(3)檢查點為了便于恢復(fù)，在日志中增加一類新的記錄——檢查點(checkpoint),以標識檢查點前已執(zhí)行完的事務(wù)是正確的，增加一個重啟動文件。檢查點記錄的內(nèi)容包括：1建立檢查點時刻所有正在執(zhí)行的事務(wù)清單。2這些事務(wù)最近一個日志記錄的地址。重啟動文件記錄各個檢查點記錄在日志文件中的地址。每遇檢查點，就做如下工作：1)將Log緩沖區(qū)內(nèi)容寫入LogDataSet中；2)在LogDataSet中寫入這次檢查點記錄信息：當前活動事務(wù)表，每一事務(wù)最近一次Log記錄在LogDataSet中的位置；3)將DB緩沖區(qū)內(nèi)容寫入DB(更新當前DB)；4)將這次CheckpointRecord在LogDataSet中的地址記入”重啟動文件”中。第四十一頁，共五十頁，2022年，8月28日在寫檢查點時，為了保證檢查點之前所作的工作都是有效的，防止故障引起緩沖區(qū)信息的丟失，因此在寫檢查點時要將緩沖區(qū)中的所有內(nèi)容寫入到永久存儲設(shè)備中，而且采取“先寫日志”的原則。使用檢查點方法可以改善恢復(fù)效率。當事務(wù)T在一個檢查點之前提交，T對數(shù)據(jù)庫所做的修改一定都已寫入數(shù)據(jù)庫，寫入時間是在這個檢查點建立之前或在這個檢查點建立之時。這樣在進行恢復(fù)處理時，沒有必要對事務(wù)T執(zhí)行REDO操作。第四十二頁，共五十頁，2022年，8月28日系統(tǒng)出現(xiàn)故障時恢復(fù)子系統(tǒng)將根據(jù)事務(wù)的不同狀態(tài)采取不同的恢復(fù)策略，如圖：

Tc(檢查點)Tf（系統(tǒng)故障）

時間

t1不要REDO

t2REDO

t3

撤銷

t4REDO

t5撤銷 T1：在檢查點之前提交。 T2：在檢查點之前開始執(zhí)行，在檢查點之后故障點之前提交。 T3：在檢查點之前開始執(zhí)行，在故障點時還未完成。 T4：在檢查點之后開始執(zhí)行，在故障點之前提交。 T5：在檢查點之后開始執(zhí)行，在故障點時還未完成。第四十三頁，共五十頁，2022年，8月28日4.2.5事務(wù)故障的恢復(fù)1.事務(wù)恢復(fù)的原則(1)孤立和逐步退出事務(wù)的原則對于不影響其他事務(wù)的可排除性局部故障．例如事務(wù)操作的刪除、超時、違反完整性規(guī)則、資源、限制、死鎖等，應(yīng)令某個事務(wù)孤立地和逐步地退出．將其所做過的修改復(fù)原，即做UND0。(2)成功結(jié)束事務(wù)原則成功結(jié)束事務(wù)所做過的修改應(yīng)超越各種故障而存在,也就是重做(REDO)它所做過的所有修改數(shù)據(jù)庫的操作。(3)夭折事務(wù)的原則若發(fā)生了非局部性的不可排除的故障，例如系統(tǒng)崩潰，則撤消全部事務(wù)，恢復(fù)到初態(tài)：這有兩種做法，一種是利用數(shù)據(jù)庫的備份實現(xiàn)；另一種是按逆向順序操作，復(fù)原其啟動以來所做過的一切修改。第四十四頁，共五十頁，2022年，8月28日2.本地事務(wù)的恢復(fù)本地事務(wù)的恢復(fù)過程類似于集中式數(shù)據(jù)庫系統(tǒng)中事務(wù)的恢復(fù)。當故障排除后，由局部事務(wù)管理器的恢復(fù)子系統(tǒng)執(zhí)行事務(wù)恢復(fù)，過程如圖4.11所示。第四十五頁，共五十頁，2022年，8月28日(1)從“重啟動文件”中讀出最近的CheckpointRecord的地址，定出CheckpointRecord在LogDataSet中的地址；(2)創(chuàng)建REDO表，初態(tài)為空:創(chuàng)建UNDO表,將CheckpointRecord中的活動事務(wù)表內(nèi)容復(fù)制到UNDO表；(3)從Checkpo