题记：最近有些人问我，undo和redo到底是什么关系，他们中不乏已经入行3-4年的同学，今天咱们就来深入探讨下到底什么是undo和redo，他们分别做什么，底层逻辑原理是什么等等。

1. undo

1.1 undo的存储结构

1. Undo段（Undo Segment）：
   –Undo信息存储在数据库的undo段中，这些段是特殊的数据库对象，用于记录事务的回滚信息。
   –每个undo段都包含一个或多个undo块，用于存储具体的回滚数据。
2. ITL（Interest Transaction List）：
   –数据块的头部包含一个ITL列表，用于记录与该数据块相关的事务信息。
   –每个ITL条目都包含事务ID（XID）、回滚指针（指向undo段中该事务的回滚信息）等信息。
3. Undo表空间：
   –Undo表空间是用于存储undo段的特殊表空间。
   –当创建数据库实例时，Oracle会自动创建一个默认的undo表空间（如UNDOTBS1）。
   –管理员也可以创建额外的undo表空间来满足特定的性能和容量需求。

1.2 undo的作用机制

1. 回滚事务：
   –当事务执行失败或用户执行rollback操作时，Oracle会利用undo信息将数据库恢复到事务开始前的状态。
   –通过遍历ITL列表和undo段中的回滚信息，Oracle可以找到并撤销事务所做的所有更改。
2. 提供一致性读：
   –一致性读是Oracle数据库的一种重要特性，它允许用户在查询时看到数据库在某个时间点上的快照。
   –当用户发出查询请求时，Oracle会记录当时的SCN（System Change Number）号。
   –如果查询过程中发现数据块被其他事务修改（SCN号发生变化），Oracle会利用undo信息构造一个CR（Consistent Read）块，以提供一致性读视图。
3. 实例恢复：
   –在数据库实例崩溃后，Oracle会使用redo日志和undo信息来恢复数据库的状态。
   –首先，SMON（System Monitor）进程会利用redo日志将已提交的事务重新应用到数据文件中。
   –然后，Oracle会使用undo信息来回滚未提交的事务，以确保数据库的一致性。

1.3 undo与Redo的交互

1. 事务提交时的交互：
   –当事务提交时，Oracle会生成相应的redo信息，并将其写入重做日志文件中。
   –同时，Oracle也会更新undo段中的信息，以标记该事务已提交。
   –在某些情况下（如IMU模式下），undo信息可能会延迟写入undo块中，但redo信息仍然会实时写入重做日志中。
2. 实例恢复时的交互：
   –在实例恢复过程中，Oracle会首先利用redo日志将已提交的事务重新应用到数据文件中。
   –然后，Oracle会使用undo信息来回滚未提交的事务。
   –这两个过程是相互独立的，但共同协作以确保数据库在崩溃后能够恢复到一致的状态。

1.4 Undo的管理

1. UNDO_MANAGEMENT参数：
   –通过设置UNDO_MANAGEMENT参数来选择undo的管理方式。
   –当设置为AUTO时，Oracle会使用undo表空间来自动管理undo段；当设置为MANUAL时，则使用rollback segment方式存储undo信息。
2. UNDO_RETENTION参数：
   –UNDO_RETENTION参数用于指定undo信息在undo表空间中保存的最长时间。
   –可以根据实际需求动态调整该参数的值。该参数并不是指undo数据在undo表空间中一定要保存指定的时间长度；当新的事务需要空间时，已提交事务的undo数据可能会被覆盖。

2. Redo

2.1 redo的组成与结构

1. Redo Log Buffer：
   –位于SGA（System Global Area）中，是一块循环使用的内存区域。
   –保存数据库变更的相关信息，这些信息以重做条目（Redo Entries）的形式存储，也称为Redo Records。
   –Redo Entries包含重构、重做数据库变更的重要信息，如INSERT、UPDATE、DELETE、CREATE、ALTER或DROP等操作。
2. Redo Log File：
   –在线重做日志文件，物理文件，默认与数据文件存储在同一位置。
   –循环使用，Oracle允许使用至少两个日志组，数据库创建时默认会建立三个日志组。
   –当一个日志文件写满后，会切换到另一个日志文件，这个过程称为Log Switch，会触发一个检查点，促使DBWR（Database Writer）进程将写满的日志文件保护的变更数据写回数据库。
3. Redo Header与Redo Record：
   –Redo Header记录Redo的基本概要信息，如数据库名称、控制文件序列号及日志Thread号等。
   –Redo Record记录数据库的详细更改，由Redo Record Header和更改矢量（Change Vector）组成。Change Vector详细描述了数据库块级的更改信息。

2.2 redo的作用机制

1. 数据修改与缓存：
   –用户数据通常在Buffer Cache中修改，Oracle通过高速缓存来提高数据操作的性能。
   –在提交时并不强制将数据变更立即写出到数据文件上，以减少磁盘I/O操作的压力。
2. Redo Log Buffer的写入：
   –Oracle通过一个后台进程LGWR（Log Writer）不断把Redo Log Buffer的内容写出到Redo Log File中。
   –LGWR的写入触发条件包括用户提交、重做日志缓冲区未满但达到一定量（如1/3或大于1M）等。
3. 检查点与恢复：
   –检查点是一个数据库事件，用于减少恢复时间。
   –当检查点发生时，Oracle会通知DBWR进程将修改过的数据（即此检查点之前的脏数据）从Buffer Cache写入磁盘。
   –在检查点完成后，此检查点之前修改过的数据都已经写回磁盘，重做日志文件中的相应重做记录对于崩溃/实例恢复不再有用。
4. 实例恢复：
   –在数据库实例崩溃后，Oracle会使用redo日志来恢复数据库的状态。
   –首先，SMON（System Monitor）进程会利用redo日志将已提交的事务重新应用到数据文件中。
   –这个过程确保了即使数据库实例崩溃，已提交的事务也不会丢失。

2.3 redo与undo的交互

1. 事务提交：
   –当事务提交时，Oracle会生成相应的redo信息，并将其写入重做日志文件中。
   –同时，Oracle也会更新undo段中的信息，以标记该事务已提交。
2. 数据恢复：
   –在实例恢复过程中，Oracle会首先利用redo日志将已提交的事务重新应用到数据文件中。
   –如果需要回滚未提交的事务，Oracle会使用undo信息来实现。
3. IMU（In Memory Undo）机制：
   –从Oracle 10g开始引入的IMU机制对redo的内部原理进行了改动。
   –IMU减少了redo recorder的数量，通过优化流程来提高性能。
   –在IMU下，很多工作延迟到了提交时完成，如将undo信息暂时存放在共享池的IMU区，可以改造redo数据的流程，将多条redo recorder合成一条。

2.4 redo的管理

1. 日志组与成员的管理：
   –可以配置多个日志组和成员来提高重做日志的可用性和性能。
   –在配置时需要考虑日志组的大小、数量以及磁盘I/O性能等因素。
2. 归档模式：
   –在归档模式下，重做日志文件在重用之前会被写出到归档日志文件中。
   –归档日志在介质恢复时可以用来恢复数据库故障。

3. undo和redo的区别与联系

3.1 区别：参考下图

1.功能与作用：
undo（撤销信息）：用于取消或回滚事务。当用户对数据库执行修改操作（如DML操作：增、删、改）时，数据库会生成undo信息。如果事务或语句由于某些原因失败，或者用户执行rollback操作请求回滚时，数据库可以利用这些undo信息将数据返回到修改前的状态。undo信息存储在数据库内部一组特殊的段中，称为undo段（或回滚段）。
redo（重做信息）：用于在失败时重放（或重做）事务。redo信息记录在Oracle的在线（或归档）重做日志文件中。如果数据库实例失效或介质失败（如硬盘故障），Oracle可以使用这些重做日志文件来恢复数据，将数据库恢复到故障发生前的状态。
2. 存储位置：
undo信息存储在数据库的undo段中。
redo信息则记录在在线重做日志文件和归档重做日志文件中。
3. 恢复机制：
undo通过逻辑恢复的方式，将数据库恢复到事务开始前的状态。
redo则通过物理恢复的方式，利用重做日志文件重放事务，以恢复数据库的状态。

3.2. undo和redo的联系：

1. 事务管理：undo和redo共同协作，确保数据库事务的完整性和一致性。undo用于回滚未提交的事务，而redo用于在故障后恢复已提交的事务。
2. 数据恢复：在数据库恢复过程中，undo和redo都起着重要作用。undo用于撤销未提交的事务，以防止数据不一致；而redo则用于重放已提交的事务，以恢复数据库到故障前的状态。
3. 相互依赖：尽管undo信息存储在undo表空间或undo段中，但它也会受到redo的保护。对undo的修改会生成一些redo信息，这些redo信息会被记入重做日志中。这样，即使undo信息在内存中丢失，也可以通过重做日志进行恢复。

4. Undo和Redo的底层逻辑

如上图所示：
–日志在内存里也是有缓存的，即log buffer，磁盘上的日志文件称为log file。log file一般是追加内容，可以认为是顺序写，顺序写的磁盘IO开销要小于随机写。
–Undo日志记录某数据被修改前的值，可以用来在事务失败时进行rollback；
–Redo日志记录某数据块被修改后的值，可以用来恢复未写入data file的已成功事务更新的数据。
–当用户生成一个数据库事务时，undo log buffer会记录被修改的数据的原始值，redo会记录被修改的数据的更新后的值。
–redo日志应首先持久化在磁盘上，然后事务的操作结果才写入db buffer，（此时，内存中的数据和data file对应的数据不同，一般内存中的数据是脏数据），db buffer再选择合适的时机将数据持久化到data file中。这种顺序可以保证在需要故障恢复时恢复最后的修改操作。先持久化日志的策略叫做Write Ahead Log，即预写日志。
–在很多系统中，undo日志并非存到日志文件中，而是存放在数据库内部的一个特殊段中，即Undo段。
–在db buffer中的内容写入磁盘数据库文件之前，应当把log buffer的内容写入磁盘日志文件。
本篇完结。
码字不易，宝贵经验分享不易，请各位支持原创，转载注明出处，多多关注作者，后续不定期分享DB基本知识和排障案例及经验、性能调优等。