Redo Transport

Undo Mechanism The Undo mechanism in Oracle is a logical rollback mechanism that allows the database to be restored to the state before a transaction began. However, it's important to note that Undo does not physically restore the database to its original state, but logically cancels all changes. After rollback, the database structures and blocks might differ significantly from their original form. Collaboration between Redo and Undo There is a close collaboration between Redo and Undo mechanisms in Oracle. Even though Undo information is stored in the Undo tablespace or Undo segments, it is also protected by Redo. In essence, modifications to Undo data are treated like changes to table or index data and generate Redo logs, which are then written to the log files. This ensures that even if changes are rolled back, the integrity of the database is maintained. COMMIT Operation The COMMIT operation is designed to be a very fast operation, regardless of the transaction size. It doesn't involve much work but plays a crucial role. Prior to the COMMIT, all the hard work has already been done, including modifying the database data. When COMMIT is executed, the remaining work is simply to generate a System Change Number (SCN), write the redo log entries to disk via LGWR, and log the SCN in the online redo log files. Block Cleanout Block cleanout refers to clearing out the lock-related information from the header of a database block. This process is done without generating redo log entries, thus avoiding extra work in the future. This efficient handling helps in reducing the overhead during the transaction lifecycle. Importance of Redo and Undo The Redo and Undo mechanisms are core components of Oracle, working together to ensure the consistency and reliability of database transactions. The Redo mechanism ensures that all changes to the database are logged for recovery, while the Undo mechanism ensures that changes can be rolled back to their initial state if necessary. Their collaboration is critical in maintaining transaction integrity and data consistency across the system.

Oracle备份恢复-redo文件损坏的各种场景恢复专题：redo文件损坏涉及到多种多样场景，具体场景可以分为四大部分： 1、按照redo的状态可以分为current、active和inactive； 2、按照数据库归档模式可以分为归档和非归档； 3、按照脏块有没写入数据文件可以分为有和无； 4、按照损坏时数据库的状态可以分为在线和关闭。

利用检查点优化数据库故障恢复策略 本节讲解如何利用检查点结合REDO和UNDO操作实现更高效的数据库故障恢复。 核心概念： 检查点(Tc): 数据库运行过程中创建的一致性状态快照。 系统故障(Tf): 导致数据库非正常停止的事件。 REDO: 重做已提交事务的操作，确保数据持久化。 UNDO: 撤销未提交事务的操作，回滚至一致状态。 场景分析: 假设数据库在时间轴上经历了T1、T2、T3、T4、T5多个事务操作，并在T3时刻创建了检查点Tc。系统在Tf时刻发生故障。 恢复策略: 分析日志: 识别Tc之后开始但未完成的事务（例如T4、T5），以及在Tc之前已提交但数据尚未写入磁盘的事务（例如T2）。 REDO操作: 对T2以及T4、T5进行REDO操作，确保已提交事务的数据更新持久化到数据库。 无需REDO操作: 对于T1，由于其在Tc之前已完成且数据已落盘，无需进行REDO操作。 总结: 利用检查点可以缩小故障恢复范围，避免对所有事务进行REDO操作，从而提高恢复效率。

随着数据库管理技术的进步，Oracle中的NOLOGGING、APPEND、ARCHIVE和PARALLEL等选项对REDO和UNDO日志以及SQL执行速度产生显著影响。每种选项在不同情境下都有其独特的优势和限制。了解这些选项如何影响数据库操作是数据库管理员和开发者的关键任务之一。