## Oracle redo log二进制格式解析：从Change Vector到完整事务的重建之路

做数据库日志解析，绕不开的一个问题是：**redo log里面到底存了什么？**

网上讲redo log的文章很多，但大部分停留在“记录数据变更”这个层面。真要动手去解析二进制日志，光知道这点远远不够。你得搞清楚它具体怎么存的、每个字节代表什么、怎么把一堆散落的二进制块拼回一个完整的事务。

这篇文章不聊虚的，直接从二进制层面拆解Oracle redo log的存储格式，然后讲清楚一个事务是怎么从Change Vector一步步重建出来的。

### 一、先看物理存储：redo log长什么样？

redo log文件在磁盘上就是一串连续的二进制块。每个块大小通常是512字节，这个值跟操作系统有关——Windows、Linux、Solaris上一般是512字节，HP-UX上可能是1024字节。

整个文件的构成很简单：**文件头 + N个数据块**。

**文件头（File Header）** 占用第一个块。里面存了一些基础信息：

- 前2个字节是**文件类型**。0x22表示这是一个redo log文件，0xA2是数据文件，0xC2是控制文件
- 偏移量20处、2个字节存的是**块大小**
- 偏移量24处、4个字节存的是**块数量**

每个数据块开头都有一个**16字节的块头（Block Header）**。块头以签名0x0122开头，里面包含了三个关键信息：块在文件中的编号、日志序号、以及该块内第一条记录起始位置的偏移量——**这三个值合起来就是RBA（Redo Byte Address）**。

简单说，RBA就是每条redo记录在文件里的“门牌号”：哪个日志文件（日志序列号）、哪个块、块内哪个位置开始。

### 二、Redo Record：变更的基本单位

跳过文件头，从第二个块开始，里面存的就是真正的redo数据了。

redo log file由一系列的**redo record**（也叫redo entry）组成。一个redo record代表一次原子性的数据库更改操作。

每个redo record由两部分构成：**记录头（Redo Record Header）+ 一个或多个Change Vector**。

**记录头**里面存的是这个record的元信息：线程号、RBA、SCN等。SCN（System Change Number）是Oracle的全局时钟，决定了变更的顺序。

**重点在Change Vector。**

### 三、Change Vector：最小粒度的变更描述

Change Vector（改变向量）是redo log里**最小粒度的变更单元**——它描述了对**单个数据块**的一次变更。

一个Change Vector只针对一个数据块，一个Change Vector只包含一个变化。这个数据块可以是普通数据块、回滚块、数据段头块、回滚段头块等等。

每个Change Vector由**头（Header）和体（Body）** 两部分组成。

**头里包含的关键字段**：

- **change #**：同一个redo record中change vector的编号
- **TYP**：变更类型
- **CLS**：本次修改对应的block类别（跟x$bh.class一致）
- **AFN**：绝对文件号
- **DBA**：数据块地址
- **SCN**：修改时的系统变更号
- **SEQ**：同一个SCN下的不同修改序号
- **OP**：操作码，由layer code和sub code组成

**操作码（OP Code）是最重要的字段之一**，它告诉你这个Change Vector描述的是什么类型的操作：

| OP Code | 含义 |
|---|---|
| 5.1 | 撤销修改（Undo Record） |
| 5.2 | 事务开始 |
| 5.4 | 事务提交（Commit） |
| 10.2 | 插入索引（INSERT LEAF ROW） |
| 10.4 | 删除索引（DELETE LEAF ROW） |
| 11.2 | 插入一行数据 |
| 11.3 | 删除一行数据 |
| 11.5 | 更新一行数据 |
| 11.11 | 插入多行数据 |
| 11.19 | 更新多行数据 |
| 13.1 | 申请空间（CREATE TABLE） |
| 24.1 | DDL操作 |

**体（Body）** 里存的是具体的变更数据——修改前的值（前镜像）、修改后的值（后镜像），以及数据块的版本号等信息。

### 四、一个事务是怎么产生redo的？

以一条UPDATE语句为例，看看整个过程：

**第一步：构建Change Vector。**

用户执行UPDATE时，Oracle在内存中（PGA）生成对应的Change Vector。这不是一个，是**多个**：

- 一个Change Vector描述**数据块**的变更（后镜像）
- 一个Change Vector描述**回滚块**的变更（前镜像，用于UNDO）
- 一个Change Vector描述**事务开始**（OP 5.2）
- 如果有索引，还需要索引相关的Change Vector

**第二步：组装成Redo Record。**

多个Change Vector按顺序组装成一个Redo Record。

**第三步：写入Redo Log Buffer。**

Redo Record从PGA拷贝到SGA的Redo Log Buffer中。

**第四步：LGWR刷盘。**

当事务提交（COMMIT）时，LGWR进程将Redo Log Buffer中的内容写入磁盘上的redo log文件。**只有redo落盘了，Oracle才会给客户端返回“提交成功”**。

**第五步：应用到数据块。**

Change Vector最终会被应用到对应的数据块上。注意，**此时Change Vector里存的不是SQL语句，而是物理级别的块变更信息**。

Oracle的redo记录的是**物理更改（Physical Changes）**，而不是逻辑SQL语句。它记录的是数据块从A状态变成B状态所需的最小信息。

这意味着什么？意味着**你没法直接从redo里拿到原始SQL**。LogMiner所谓的“还原SQL”，其实是根据Change Vector反向构造出来的单行操作——一个DELETE删了10000行，LogMiner会给你10000条"delete from t where rowid = ..."。

### 五、从Change Vector重建完整事务

现在问题来了：**一堆散落在不同redo record里的Change Vector，怎么拼回一个完整的事务？**

**第一步：按事务ID（XID）分组。**

每个事务有一个唯一的事务ID（XID），由三部分组成：Undo Segment号、事务表槽位号、序列号。同一个事务产生的所有Change Vector，XID是一样的。

TLA解析的时候，读到Change Vector就先提取XID，按XID把散落的Change Vector归类。

**第二步：按操作码识别事务边界。**

- 读到OP 5.2 → 事务开始
- 读到OP 5.4 → 事务提交
- 读到OP 5.1 → 撤销修改（说明这个操作被回滚了）

有了开始和结束，就能确定一个事务的完整范围。

**第三步：按SCN和RBA排序。**

同一个事务内的Change Vector可能分散在不同的redo record里，甚至跨多个日志文件。但它们有共同的XID，通过SCN和RBA可以还原出**时间顺序**。

**第四步：按Change Vector还原数据变更。**

每个Change Vector的Body里存了**前镜像和后镜像**。把同一行数据的所有Change Vector按顺序应用——先还原前镜像（UNDO），再应用后镜像（REDO）——就能得到完整的数据变更记录。

**第五步：处理回滚。**

如果一个事务最终回滚了，redo里会有对应的OP 5.1（撤销修改）。TLA在重建事务的时候会检查：如果事务以回滚结束，**这个事务的所有Change Vector都不应该输出**。

这就是为什么TLA能做到“只输出已提交事务”——因为它是在二进制层面完整还原了事务的生命周期，而不是像LogMiner那样依赖数据库接口去查询。

### 六、TLA怎么做的？

说完了原理，再说TLA的具体实现。

**TLA不调用LogMiner，不调用XStream，直接读redo log的二进制文件。**

流程是这样的：

1. **读取**：从磁盘或ASM存储中读取redo log的二进制块
2. **解析块头**：识别块头签名0x0122，提取RBA信息
3. **遍历Redo Record**：按块内偏移量逐个解析Redo Record
4. **提取Change Vector**：从每个Redo Record里提取Change Vector，解析Header（XID、OP、SCN、AFN、DBA等）和Body（前镜像、后镜像）
5. **事务归集**：按XID分组，按SCN/RBA排序
6. **事务重建**：识别事务边界（OP 5.2开始、OP 5.4提交、OP 5.1回滚），输出已提交事务的完整变更

**关键差异在哪？**

LogMiner的方案是：Oracle内核解析redo → 生成SQL接口数据 → 外部工具查询。

TLA是：**直接读二进制 → 自己解析Change Vector → 自己还原事务**。

前者依赖Oracle的闭源组件，后者完全不依赖。

这也是为什么TLA能突破LogMiner的各种限制——表名超30字符、不支持BLOB/CLOB/XMLTYPE、大事务OOM、RAC日志切换丢数据——因为这些限制都是LogMiner这个“中间层”带来的。TLA直接读二进制，绕过了这层，自然不受这些限制影响。

### 七、说句实在话

redo log的二进制格式解析，说起来不复杂——就是文件头、块头、Record头、Change Vector头一层层剥开。但真要做起来，坑很多：

- 不同Oracle版本的redo格式有差异
- Change Vector的操作码有150多种
- 大事务可能跨多个日志文件
- RAC环境下多个实例的日志需要按全局SCN排序

把这些全部吃透，才能把一个完整的CDC组件做出来。

TLA在这条路上已经走通了。如果你对具体的解析实现细节感兴趣，欢迎交流。

---

*补充：文中提到的OP Code列表基于Oracle 10g/11g版本，不同版本可能有细微差异。实际解析时需要根据目标版本做适配。*

网上讲redo log的文章很多，但大部分停留在“记录数据变更”这个层面。真要动手去解析二进制日志，光知道这点远远不够。你得搞清楚它具体怎么存的、每个字节代表什么、怎么把一堆散落的二进制块拼回一个完整的事务。

Oracle redo log二进制格式解析：从Change Vector到完整事务的重建之路

数据库

大数据

架构设计

深入解析Oracle RedoLog二进制格式，揭秘从ChangeVector到完整事务的重建过程。详解RedoLog物理存储结构、ChangeVector组成及操作码含义，剖析UPDATE语句生成RedoRecord的全流程。掌握事务ID分组、操作码识别、SCN排序等关键技术，实现事务精准还原。突破LogMiner限制，直接解析二进制日志，构建高效CDC方案。

2026上云采购 | AI焕新·智启新局

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

腾讯iOA零信任安全管理系统专区

腾讯云架构师技术同盟交流圈

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

涵盖代码开发、场景应用、自动测试全流程，助你从零构建专属AI助手

一站式MCP教程库，解锁AI应用新玩法

聚焦“写作效率、视觉美观与运行性能”三方面进行全面升级，为您提供更高效、稳定的创作环境

社区富文本&Markdown编辑器全新改版上线，欢迎大家体验!

诚挚邀请您参与本次调研，分享您的真实使用感受与建议。您的反馈至关重要，感谢您的支持与参与！

社区新版编辑器体验调研

深入解析Oracle RedoLog二进制格式，揭秘从ChangeVector到完整事务的重建过程。详解RedoLog物理存储结构、ChangeVector组成及操作码含义，剖析UPDATE语句生成RedoRecord的全流程。掌握事务ID分组、操作码识别、SCN排序等关键技术，实现事务精准还原。突破LogMiner限...

Oracle redo log二进制格式解析：从Change Vector到完整事务的重建之路-腾讯云开发者社区-腾讯云

Oracle redo log二进制格式解析：从Change Vector到完整事务的重建之路

Oracle redo log二进制格式解析：从Change Vector到完整事务的重建之路

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐