數據庫恢復 UNDO 階段中的補償日誌記錄 (CLR)
補償日誌的重做資訊對應於日誌條目的撤消資訊，這使得在撤消階段必須創建它們。
在我看來，CLR 重做資訊與觸發它們的日誌的撤消資訊相同。
但是不應該是他們有REDO資訊以便在中斷恢復過程的情況下取消執行的UNDO操作嗎？
這是一個例子：
讓 T2 成為失敗交易：
<#55, T2, P3, J=J+9, J = J-9, #53>J=J+9 是重做操作，J = J-9 是撤消操作。
現在，在重做階段附加到日誌文件的 CLR 將是：
<#56, T2, J=J-9,__, #53>J=J-9 是原始日誌條目的撤消操作，作為 CLR 中的重做資訊。如果恢復中斷，日誌條目#56 將在重做階段執行。
CLR 的目的是確保重新啟動恢復過程並再次執行它總是會導致相同的結果。在重新執行的重做階段執行 J=J-9 操作如何確保這一點？
有人可以向我解釋一下嗎？
補償日誌記錄 (CLR) 在正常操作期間不會寫入日誌。它們是在處理回滾時產生的，無論是應用程序請求還是由於崩潰。由於它們的唯一用途是在回滾期間，它們只需要保存足夠的資訊來執行該操作，即範例中的 J=J-9。每個 CLR 通過 LSN 引用與其對應的原始日誌記錄配對。
恢復的重做階段的目的是將數據庫恢復到崩潰時的狀態。如果崩潰發生在恢復的中途，那麼第二次恢復的重做階段應該在第一次恢復的中途離開數據庫。第二次恢復的重做階段處理由第一次恢復的撤消階段寫入的 CLR。由於 CLR 連結到原始更新日誌記錄，知道最後處理的 CLR 會告訴第二個恢復的撤消階段要跳轉到哪個日誌記錄，以便它可以完成回滾。
使用給定的範例，第一個恢復的撤消階段將處理日誌記錄 #55 的撤消操作 (J = J-9) 並創建 CLR #56。然後它將返回到上一個連結記錄（#53）。假設我們在處理之前崩潰了。第二次恢復的重做階段將處理 CLR #56 的操作。如果這是最後一個 CLR，則第二次恢復的撤消階段將沿著連結返回到 #53 並從那裡完成回滾。在第二次和後續恢復期間，#56 有效地替換了#55。
那麼為什麼要為這一切煩惱呢？為什麼第二次恢復不能完全按照第一次恢復的方式進行？因為 Aries 假定緩衝區管理器使用竊取，沒有強制策略。在第一次恢復期間，頁面可能已部分回滾，然後從緩衝池中換出。因此，第二次恢復不是從第一次恢復的相同持久狀態開始，因此它不能簡單地第二次執行相同的操作。