Oracle數據庫UNDO LOG日志回放過程的相關知識是本文我們主要要介紹的內容，接下來我們看一段描述：一個看起來正確的過程，系統宕機後需要重啟，重啟過程中需要對事務涉及到的數據進行“整理”，包括：宕機時刻尚未提交的事務對數據的修改需要回滾。實現整理的過程稱之為“日志回放”。通過從後向前回放UNDO LOG日志，直到找到commit點為止，這樣就保證了數據一致性。
上面的過程看起來很完美。真的完美嗎？問題出在這裡：如果系統中同時有多個事務在執行，UNDO LOG中的commit點該如何定義呢？可能存在多個等待Commit的點。（繼續之前考慮一下Global Serializability，多個commit點與此沖突嗎？）
實戰：可以工作的過程
方法1：系統重啟回放日志，只需要從後往前掃描日志文件，對於所有沒有commit的事務按照日志記錄中的數據做回滾操作。這個方法肯定是可以工作的，其問題在於要求掃描所有commit日志，代價不菲。
方法2：使用Checkpoint，拉起一個大柵欄。Checkpoint可以看做是對引言中“commit點“的展開，它好比一個較寬的柵欄（fence），將所有已經開始、尚未commit的事務都記錄下來，等待這些事務完成之後再在日志中寫入一條“在這個柵欄架起來之前的那些狀態一致了”的標記。
為什麼是“架起來之前的”呢？因為在架起柵欄後有一段等待事務完成時間，這段時間裡會有新的事務發起，他們也會繼續寫日志，對於這些事務Checkpoint不關注。
生成checkpoint的過程：
1. 在日志中寫下CREATE_CKPT(T1,T2,..,Tn)，其中Ti表示寫入CREATE_CKPT之前尚未完成的事務
2. 等待T1~Tn這些事務完成。在等待過程中可能會有新的事務寫日志。
3. 在日志中寫入END_CKPT
日志回放過程：
從後往前掃描日志，如果先遇到END_CKPT，那麼說明CREATE_CKPT中記錄的T1~Tn這些事務都已經完成，將日志回放至CREATE_CKPT處即可。之前的日志均可以丟棄。如果先遇到CREATE_CKPT，那麼說明T1~Tn這些事務可能還有沒完成的，那麼為了保證Global Serialization，將日志回滾到T1~Tn中最早出現的那一條之前即可。例如T3是T1~Tn中最先開始的事務，則將事務回滾檢查做到T3之前即可，因為T3前的所有數據均已經確保Commit了。
關於Oracle數據庫UNDO LOG日志回放過程的相關知識就介紹到這裡了，希望本次的介紹能夠對您有所收獲！
