資料結構
網路
關係資料庫管理系統 (RDBMS)
作業系統
Java
MS Excel
iOS
HTML
CSS
Android
Python
C語言程式設計
C++
C#
MongoDB
MySQL
Javascript
PHP
物理學
化學
生物學
數學
英語
經濟學
心理學
社會學
服裝學
法學基於延遲更新的NO-UNDO REDO恢復
資料庫管理系統 (DBMS) 中的延遲更新的概念是指將對磁碟上資料庫的實際更新推遲到事務成功完成執行併到達提交點。
在事務執行期間，更新僅記錄在日誌和快取緩衝區中。一旦事務到達其提交點並且日誌強制寫入磁碟，則將更新記錄到資料庫中。如果事務在到達提交點之前失敗，則無需撤消任何操作，因為磁碟上的資料庫保持不變。因此，日誌中只需要REDO型別的日誌條目，其中包含寫入操作寫入的專案的新值（AFIM）。由於在恢復期間無需撤消任何操作，因此不需要UNDO型別的日誌條目。但是，這種方法僅適用於更改較少的短期事務，否則緩衝區空間可能不足以容納事務更改直到提交點。
典型的延遲更新協議可以描述如下：
在事務到達其提交點之前，不允許修改磁碟上的資料庫。
只有當所有REDO型別的日誌條目都記錄在日誌中並且日誌緩衝區強制寫入磁碟時，事務才能到達其提交點。
需要注意的是，此協議的步驟2實際上重申了預寫日誌 (WAL) 協議。由於資料庫在事務提交後才更新到磁碟，因此永遠不需要撤消任何操作。相反，如果事務提交後但其所有更改在記錄到磁碟上的資料庫之前系統發生故障，則需要REDO操作。在這種情況下，在恢復過程中使用日誌條目重做事務操作。
對於採用併發控制的多使用者系統，併發控制和恢復的過程緊密交織在一起。在採用嚴格兩階段鎖進行併發控制的系統中，對專案的鎖保持有效，直到事務到達其提交點。只有在那之後，才能釋放鎖，確保嚴格和可序列化的排程。假設檢查點條目包含在日誌中，我們可以概述此場景的可能恢復演算法，稱為RDU_M（在多使用者環境中使用延遲更新的恢復）。
過程 RDU_M（無撤銷/重做，帶檢查點）
系統維護兩個事務列表：自上次檢查點以來已提交的事務T（提交列表）和活動事務T（活動列表）。該演算法涉及對日誌中記錄的已提交事務的寫入操作執行REDO操作，按照其寫入順序執行。
未提交的活動事務被視為有效取消，必須重新提交。
REDO過程定義如下。
過程 REDO (WRITE_OP)
重做write_item操作WRITE_OP需要檢查其日誌條目[write_item, T, X, new_value]並將資料庫中專案X的值設定為new_value，它表示後映像 (AFIM)。
在下圖中，給出了一個時間線來說明執行事務的潛在排程。在t1時刻，進行了檢查點，表明事務T1已提交，而事務T3和T4尚未到達其提交點。在t2時刻，系統崩潰。在崩潰之前，T3和T2已提交，但T4和T5尚未提交。根據前面描述的RDU_M方法，無需重做事務T1或在t1時刻上次檢查點之前提交的任何事務的write_item操作。但是，必須重做T2和T3的write_item操作，因為這兩個事務都在上次檢查點之後到達了其提交點。
重要的是要記住，在事務提交之前，日誌會強制寫入磁碟。在恢復過程中忽略事務T4和T5，因為在延遲更新協議下，它們的write_item操作未記錄在磁碟上的資料庫中。因此，這些事務被視為有效取消或回滾。
處理延遲更新中的已中止事務
為了提高NO-UNDO/REDO恢復演算法的效率，我們可以透過認識到以下事實來最佳化該過程：如果自上次檢查點以來，已提交的事務多次更新了資料項X，則在恢復期間僅從日誌中REDO X的最後一次更新就足夠了。這是因為之前的更新將被最後一次REDO操作覆蓋。為了實現這種最佳化，我們遵循以下步驟：
從日誌的末尾開始，在恢復過程中反向遍歷它。
維護一個已重做專案的列表，最初為空。
當需要重做專案時，檢查它是否已存在於已重做專案的列表中。
如果在列表中找到該專案，則無需再次重做它，因為它的最後一個值已恢復。
如果專案不在列表中，則執行REDO操作以根據相應的日誌條目設定其值。
重做專案後，將其新增到已重做專案的列表中。
繼續此過程，直到根據日誌條目重做所有必要的專案。
透過避免對已恢復專案的冗餘重做操作，這種最佳化減少了整體恢復時間和資源利用率。
優點和缺點
如果事務中止，無論原因是什麼（例如死鎖檢測），它都可以簡單地重新提交，因為它沒有對磁碟上的資料庫進行任何更改。但是，此處描述的方法具有一定的侷限性和考慮因素。一個缺點是它限制了事務的併發執行，因為寫鎖定的專案在事務到達其提交點之前保持鎖定狀態。此外，它可能需要大量的緩衝區空間來儲存所有更新的專案，直到事務提交為止。儘管存在這些限制，但該方法提供了兩個主要優點：
事務在到達其提交點之前不會在磁碟上的資料庫中記錄任何更改，這意味著由於事務執行期間的失敗而不會回滾它們。
事務永遠不會讀取未提交的事務寫入的專案的 value，因為專案在事務到達其提交點之前保持鎖定狀態。因此，不會發生級聯回滾。
3K+ 瀏覽量
