Transaction
了解事務恢復
在以下參考中,有一個算法概述了使用重做和撤消的事務恢復算法。算法如下:
UNDO and REDO: lists of transactions UNDO = all transactions running at the last checkpoint REDO = empty For each entry in the log, starting at the last checkpoint If a BEGIN TRANSACTION entry is found for T Add T to UNDO If a COMMIT entry is found for T Move T from UNDO to REDO
然後給出了例子:
但這顯然是錯誤的??由於 T2 已經送出,T 必須在 REDO 列表中。我錯過了什麼嗎?
如果您從頭到尾瀏覽幻燈片,您會發現解釋非常準確。
- 數據庫恢復開始。
所描繪的幻燈片向您展示了垂直軸位於檢查點時的情況。
- 此時 T2 和 T3 被放入 UNDO 隊列。
- 向前移動(在參考中)被檢查的時間(垂直軸)向前移動並到達 T4 的 BEGIN。事務 T4 被放入 UNDO 隊列。
- 向前移動(在參考中)被檢查的時間(垂直軸)向前移動並到達 T5 的 BEGIN。事務 T5 被放入 UNDO 隊列。
您現在在 UNDO 隊列中擁有所有四個事務 T1、T2、T3、T4。
- 進一步向前移動(在參考中),檢查的時間(垂直軸)向前移動並到達 T2 的 END。事務 T2 被放入 REDO 隊列。
- 向前移動(在參考中)被檢查的時間(垂直軸)向前移動並到達 T4 的 END。事務 T4 被放入 REDO 隊列。
事務 T3 和 T5 在 UNDO 隊列中。
事務 T2 和 T4 在 REDO 隊列中。
進一步向前移動(在參考中),檢查的時間(垂直軸)向前移動並到達故障。
T3 和 T5 是 UNDO-ne,T2 和 T4 是 REDO-ne(或重新應用)。
數據庫現在處於一致狀態。