关于redo log的修改与重建

### Redo Log与Undo Log在数据库事务管理中的区别 #### 定义与功能 Redo log 和 Undo log 是数据库管理系统 (DBMS) 中两种重要的日志机制，它们分别承担不同的职责来维护数据的一致性和持久性。 - **Redo Log**: 主要用于记录所有已提交事务的操作细节。当数据库发生崩溃或其他异常情况时，可以通过重放 redo 日志将数据库恢复到最近一次正常状态下的全部已提交事务的结果[^3]。 - **Undo Log**: 则主要用于保存事务执行过程中的旧版本数据。它允许系统在必要时撤销未完成或失败的事务，从而保持数据库内部数据的一致性。 #### 存储位置 - **Redo Log** 的信息通常被写入独立的物理文件或者特定区域中，并且这些文件可以配置为循环使用的模式以便节省磁盘空间。此外，在某些实现里还会有在线redo logs以及归档redo logs之分用来满足不同场景下对于高可用性的需求[^1]。 - 对于 **Undo Log**, 大多数情况下它是存放在专门分配给它的表空间之内（即所谓的undo tablespace），不过也有例外比如Oracle早期版本可能会将其嵌套进datafile之中。 #### 使用时机 - 当某个事务成功结束并标记为 COMMIT 后, 数据库引擎会立即将此事件连同相关变更描述一起追加至当前活跃的 REDO LOG BUFFER 并最终刷盘形成永久记录; 这样做的好处在于即便之后遭遇意外停机也能依靠这部分历史资料重建丢失的信息[^2]. - 而 UNDO RECORDS 则是在每次修改之前先复制原始副本出来再加以处理, 整个流程贯穿整个交易周期直至最后确认完毕才会释放关联资源[ ^3 ]. #### 性能影响因素分析 由于两者工作原理上的差异决定了各自对整体性能表现会产生不一样的效果: - 频繁的小规模更新操作会使REDO GENERATION速率加快进而加大I/O负担; - 如果存在长时间运行的大批量DML语句则可能导致TEMPORARY SEGMENTS膨胀甚至引发SPACE CONTENTION现象同时也增加了UNDO RETENTION压力使得清理变得困难起来. ```sql -- Example SQL demonstrating how to check undo and redo settings in Oracle. SELECT value AS undo_retention_seconds FROM v$parameter WHERE name='undo_retention'; SELECT GROUP#, STATUS, BYTES/1024/1024 MB_SIZE FROM V$LOG ORDER BY 1; ```