Redo日志采用物理与逻辑混合设计以兼顾恢复效率和重放准确性：物理记录（如Change Vector、OP代码）精确描述数据块字节级变更，保障快速块级恢复；逻辑记录（如LCR、事务元数据）嵌套其中，支撑索引同步、事务一致性等高级功能。
Redo日志是Oracle数据库实现崩溃恢复和事务持久性的核心机制，其内容既包含物理层面的数据块变更（如某数据块第X行的Y字节被改写为Z），也包含逻辑层面的操作语义（如“对表EMP的ID=100的记录执行UPDATE salary=8000”）。这种混合设计并非随意，而是兼顾恢复效率与重放准确性之间的权衡。
物理记录：面向数据块的精确变更描述
Redo日志中的物理记录直接映射到数据库缓冲区中数据块（data block）的修改。它不关心SQL含义，只记录“哪里改了、怎么改的”。典型形式包括：
-
Block Image Redo：记录整个数据块在变更前或变更后的完整镜像（多见于初始插入或块格式化）
-
Change Vector（变更向量）：最常见类型，描述某个块内某偏移位置的字节级变化，例如“file 4, block 12345, offset 1024, length 6 → new value: 0x00001F40”
-
Physical Operation Codes：如OP:11.2（插入一行）、OP:11.3（删除一行）、OP:11.5（更新行），这些代码标识操作类型，但本身不携带表名或列名
这类记录确保实例崩溃后能按物理顺序精确还原块状态，是快速恢复的基础。
逻辑记录：嵌套在物理结构中的语义信息
纯粹物理重放无法处理跨块、跨段或依赖对象定义的操作（如索引同步、LOB定位符更新）。因此Oracle在Redo流中嵌入逻辑记录，它们不独立存在，而是作为物理变更向量的补充元数据：
-
Logical Change Record (LCR)：出现在某些DML重做中，包含对象号（OBJ#）、数据操作类型（INSERT/UPDATE/DELETE）、主键值或ROWID，用于驱动逻辑层的二次处理
-
Transaction Layer Metadata：如SCN、XID（事务ID）、Commit SCN，使Redo能按事务边界切分，支持一致性读与回滚段联动
-
Dictionary Information：部分Redo条目会附带对象名称哈希、列数、数据类型标识等轻量字典线索，供介质恢复时校验对象是否存在
注意：Oracle不记录原始SQL文本，逻辑信息是精简编码后的运行时上下文，体积小且可解析，但不可直接阅读。
物理与逻辑如何协同工作？
一次UPDATE语句产生的Redo，并非先写逻辑再写物理，而是由底层存储引擎统一生成一组有序的变更向量，其中部分向量标记为“含逻辑属性”。恢复时流程如下：
- Redo Apply进程按SCN顺序读取Redo流
- 对每个变更
向量，先执行物理写入（如覆盖块中某字段）
- 若该向量携带逻辑标记（如指向某索引叶块），则触发逻辑动作（如同步更新索引键）
- 遇到COMMIT记录时，结合XID与SCN确认事务完成，释放锁并更新数据字典状态
这种设计让单条Redo记录既能保证块级一致性，又能支撑高级功能（如逻辑复制、闪回查询、Active Data Guard）。
查看与验证Redo内容的方法
直接解析Redo二进制文件需工具支持，常用方式有：
-
DBMS_LOGMNR：将归档日志或联机日志加载为可查视图（V$LOGMNR_CONTENTS），返回的是解码后的逻辑事件（如SQL_REDO字段显示重构SQL），但底层仍依赖物理Redo解析
-
LogMiner with DICT_FROM_ONLINE_CATALOG：利用当前数据字典动态反推列名与类型，提升逻辑可读性
-
Oracle内部视图 V$ARCHIVED_LOG / V$LOGFILE：仅提供日志文件元信息，不含记录细节
-
第三方解析器（如LogMiner替代工具或C语言Redo dump程序）：可输出原始Change Vector结构，适合深度故障分析
需注意：不同Oracle版本对逻辑信息的封装粒度略有差异，12c以后增强对JSON、分区等新特性的Redo语义表达。
向量，先执行物理写入（如覆盖块中某字段）