第7章事務(wù)管理-全文預(yù)覽
【正文】 前像塊，按照邏輯塊號寫入到關(guān)系的對應(yīng)塊，從而消除該事務(wù)對數(shù)據(jù)庫的影響。 否則，一旦發(fā)生故障，該事務(wù)的狀態(tài)將丟失！ 問題：某事務(wù)需要提交時，該按照什么順序?qū)?ATL和 CTL進(jìn)行更新？ 可以看成一個堆文件。（假設(shè) log和 DBMS同時失效的概率為零；一般假設(shè) log不會損壞，若運(yùn)行中 DBMS測得 log損壞，則采取強(qiáng)制措施，例如拒絕新事務(wù)，完成已提交事務(wù)，停止運(yùn)行，修復(fù) log）。 當(dāng)一個磁盤的數(shù)據(jù)丟失時，可以用另一個磁盤的數(shù)據(jù)來恢復(fù)。 如果系統(tǒng)中有多個 DB副本，且這些副本具有 獨立的失效模式 (independent failure mode)， 則可利用這些副本互為備份，用于恢復(fù)。 回卷 (Rollback或 Abort)——消除事務(wù)對數(shù)據(jù)庫的影響 (do nothing)。 運(yùn)行記錄（ log或 journal） 由系統(tǒng)維護(hù)，一般包括下列內(nèi)容： （ 1）前像（ Before Image,BI） 當(dāng)數(shù)據(jù)庫被一個事務(wù)更新時，所涉及的物理塊更新前的映像（ image） 稱為該事務(wù)的 前像（ BI） ， 前像以物理塊為單位；有了前像可以使數(shù)據(jù)庫恢復(fù)到更新前狀態(tài)，對應(yīng)操作 undo(撤銷 )。 對于恢復(fù)，數(shù)據(jù)冗余是必需的！ 一致 狀 態(tài) 恢復(fù)技術(shù)大致可以分為下列三種 ? 從文件系統(tǒng)繼承而來，周期性的把磁盤上的數(shù)據(jù)庫轉(zhuǎn)儲（ dump） 到脫機(jī)存放的磁帶上。 事務(wù)管理（ transaction management）： 恢復(fù)引論 故障的可能性總是存在的。 ? 并發(fā)控制 ——保證事務(wù)在并發(fā)執(zhí)行時滿足ACID準(zhǔn)則的技術(shù)。 系統(tǒng)發(fā)生故障時，可能會導(dǎo)致數(shù)據(jù)的丟失 (loss)，要恢復(fù)丟失的數(shù)據(jù)，必須有后備副本。 多用于文件系統(tǒng)以及小型的不重要的數(shù)據(jù) 庫系統(tǒng)。 事務(wù)失敗 事務(wù)開始 活動狀態(tài) 操作結(jié)束 事務(wù)提交 回卷 事務(wù)結(jié)束 提交 (Commit)——成功執(zhí)行 (do all)。大多數(shù)商品化 DBMS采用這種恢復(fù)技術(shù)。 寫數(shù)據(jù)時，兩個磁盤都寫入同樣的內(nèi)容。 運(yùn)行記錄 (log)一般不能和數(shù)據(jù)庫放在同一磁盤上，以免兩者皆失。 注意 ： 提交時，先將要提交事務(wù)的 TID加入 CTL， 再從 ATL中刪除相應(yīng)的 TID。 邏輯塊號在關(guān)系中是唯一的。這相當(dāng)于按提交的次序重做各個事務(wù)。 （對給定邏輯塊號的物理塊，如多次更新，可只保留最近的后像） 如何判斷該做 undo還是 redo呢？下一節(jié)，將解決這 個問題。 即后像不能僅留在內(nèi)存中！ 三種更新策略 a) 后像在事務(wù)提交前完全寫入 DB TID → active list → Log (按 Log Ahead Rule) → DB ┇ TID → mit list delete TID from active list 在這種情況下，如果出現(xiàn)故障，如何恢復(fù)？ Restart時，對每個 TID， 查兩個 list： Commit list Active list ? undo ? ? delete TID from active list ? nothing to do b) 后像在事務(wù)提交后寫入數(shù)據(jù)庫 TID → active list → Log (按 mit rule) ┇ TID → mit list → DB delete TID from active list 在這種情況下，如果出現(xiàn)故障，如何恢復(fù) Restart時，對每個 TID， 查兩個 list： Commit list Active list ? delete TID from active list ? ? redo, delete TID from active list ? nothing to do c) 后像在事務(wù)提交前后寫入數(shù)據(jù)庫 TID → active list , → Log (按 2 rules) → DB (partially done) ┇ TID → mit list → DB (pleted) delete TID from active list 在這種情況下，如果出現(xiàn)故障，如何恢復(fù)？ Restart時，對每個 TID， 查兩個 list： Commit list Active list ? undo ? ? redo, delete TID from active list ? nothing to do 思考：方案 3均勻的將寫入 DB的 I/O操作分散在事務(wù)提交前后，有什么優(yōu)點？ 有利于磁盤均衡負(fù)載 消息的處理 一個事務(wù)常常要給用戶發(fā)送有影響的消息 (message)，不是指需要用戶輸入的指示消息 。 因此，在事務(wù)結(jié)束前，消息不能發(fā)出，只有等事務(wù)結(jié)束后才能發(fā)出。 為了保證消息能可靠的發(fā)送給有關(guān)用戶， MM采用 “ 發(fā)送 確認(rèn) ” 方式傳遞。 例如：數(shù)據(jù)庫中沒有要訪問的數(shù)據(jù)、輸入數(shù)據(jù)類型不對、除數(shù)為零等。 (system failure) 系統(tǒng) (包括 OS和 DBMS)崩潰，需要重新啟動 (restart)，DB未被破壞，但系統(tǒng)失去控制 。 系統(tǒng)中，活動事務(wù)表 (ATL)的長度是有限的；由于累積效應(yīng)，提交事務(wù)表（ CTL） 可能很長。 最近后備副本 失效 運(yùn)行記錄 最近后備副本 CP CP CP CP CP 運(yùn)行記錄 失效 顯然，在最近檢查點以前提交的 事務(wù)，恢復(fù)時，不用 redo。 ? 修復(fù)系統(tǒng)，必要時
環(huán)評公示相關(guān)推薦
鄂ICP備17016276號-1