



第一次听到这两个词的时候，很多人会以为是什么高深的概念。其实说白了很简单：

- **前镜像**：数据修改之前长什么样
- **后镜像**：数据修改之后长什么样

但问题在于——**这两个东西在redo log里到底是怎么存的？CDC解析的时候到底该用哪个？**

这篇文章把这件事聊透。

### 前镜像和后镜像，到底存在哪？

redo log里，每个Change Vector的Body部分，存的就是变更的具体数据。

以一条UPDATE为例：

```sql
UPDATE employees SET salary = 8000 WHERE employee_id = 1001;
```

假设修改前salary是5000。这个Change Vector的Body里，会记录：

- **前镜像**：employee_id=1001这一行的原始数据（salary=5000，以及其他列的值）
- **后镜像**：修改后的数据（salary=8000，以及其他列的值）

**但这里有一个很容易被忽略的细节：前镜像和后镜像不一定都完整。**

Oracle的redo log里，前镜像的完整性取决于**补充日志（Supplemental Logging）** 的配置。

### 补充日志：前镜像完整性的开关

Oracle默认不记录完整的前镜像。它只记录**修改涉及的列的前后值**。

比如你执行`UPDATE employees SET salary = 8000 WHERE employee_id = 1001`，默认情况下：

- 前镜像：只记录了employee_id和salary的旧值
- 后镜像：只记录了employee_id和salary的新值

其他列（比如name、department、hire_date）不记录。

**这意味着什么？**

如果你只靠redo log来还原数据变更，你拿到的是一个“残缺”的前镜像——只知道哪一行的哪个字段被改了，但不知道这一行的完整数据长什么样。

要拿到完整的前镜像，必须开启**补充日志**。

补充日志有几个级别：

- **最小补充日志（Minimal）** ：默认级别，只记录必要的信息
- **主键补充日志（Primary Key）** ：额外记录主键列的值
- **唯一键补充日志（Unique Key）** ：额外记录唯一键列的值
- **全列补充日志（All Columns）** ：记录所有列的前镜像

`ALL_COLUMNS`级别的补充日志，会让redo log里记录每一行的完整前镜像。但这会显著增加redo log的大小——可能增加20%-50%的日志量。

**这就是为什么CDC方案通常要求开启补充日志。** LogMiner需要前镜像来重构完整的行数据，Debezium和Flink CDC的文档里也都明确要求开启`ALL_COLUMNS`补充日志。

### 前镜像和后镜像，CDC到底用哪个？

答案是：**两个都用，但用途不同。**

**后镜像用于同步。**

CDC的核心目标是“把源库的变更同步到目标端”。后镜像是修改之后的值——目标端需要的就是这个值。你拿到后镜像，就知道目标端应该把这一行改成什么样。

**前镜像用于判断和回滚。**

前镜像虽然不直接同步到目标端，但在解析过程中有非常重要的作用：

**第一，判断事务是否回滚。**

如果一个事务最终回滚了，redo里会有OP 5.1（撤销修改）的Change Vector。这个Change Vector的Body里存的就是前镜像——Oracle要把数据恢复到修改之前的状态。解析器看到OP 5.1，就知道这个事务要回滚，所有变更都不应该输出。

**第二，处理UPDATE的WHERE条件。**

LogMiner在重构SQL的时候，需要用前镜像来构造WHERE条件。比如`UPDATE employees SET salary = 8000 WHERE employee_id = 1001`，LogMiner需要从Change Vector里提取employee_id的旧值来拼出WHERE子句。

**第三，处理链式变更。**

如果同一行数据在一个事务里被修改了多次（UPDATE→UPDATE→UPDATE），前镜像和后镜像会形成一条链。解析器需要按顺序应用这些变更，才能得到最终结果。

**第四，处理行迁移和行链接。**

如果一行数据太大，跨了多个数据块，前镜像可以帮助解析器识别和还原完整的行数据。

### 实际解析中，前镜像和后镜像会遇到哪些坑？

**第一个坑：前镜像不完整。**

如果没有开启补充日志，前镜像只包含修改涉及的列，其他列是空的。这时候你拿到的UPDATE变更，只知道salary从5000改成了8000，但不知道这一行的其他字段是什么。

对于CDC来说，这通常不是问题——你只需要同步变更的字段。但如果目标端需要完整的行数据（比如做全量比对），前镜像不完整就会导致数据缺失。

**第二个坑：大字段的前镜像被截断。**

对于BLOB、CLOB这些大字段，前镜像和后镜像可能不是完整的——redo log里可能只记录了locator的变更，实际数据在别的数据块里。解析器需要跟踪这些数据块的变更，把完整的数据拼出来。

**第三个坑：LONG类型的前镜像不记录。**

Oracle的LONG类型在redo log里不记录前镜像——这是一个历史遗留问题。LogMiner不支持LONG类型，很大程度上就是因为前镜像不完整。

**第四个坑：虚拟列没有前镜像。**

虚拟列的值是计算出来的，redo log里不记录虚拟列本身的前后镜像。解析器需要拿到依赖列的值，然后按照虚拟列的定义自己计算。

**第五个坑：行迁移导致的前镜像跨块。**

如果一行数据被迁移到了新的数据块，前镜像和后镜像可能分布在不同的块里。解析器需要能跨块关联，把完整的数据拼出来。

### LogMiner怎么处理前镜像和后镜像？

LogMiner在处理前镜像和后镜像的时候，有一个关键的限制：**它需要连接数据库，依赖数据字典。**

具体来说，LogMiner拿到Change Vector之后，需要：

1. 从Change Vector里提取前镜像和后镜像
2. 根据对象ID去数据字典里查这个表的结构——有哪些列、什么类型、什么顺序
3. 按列的顺序和类型，把前镜像和后镜像解码成可读的值
4. 拼成SQL语句（`SQL_REDO`和`SQL_UNDO`）

这个过程有几个问题：

**第一，必须连接数据库。** 没有数据字典，LogMiner只能返回内部对象ID和十六进制数据，根本没法用。

**第二，字典必须是最新的。** 如果表结构变了（加了列、改了类型），LogMiner的字典必须同步更新，否则解析出来的数据就是错的。

**第三，某些类型处理不了。** 前面说的BLOB、CLOB、XMLTYPE这些，LogMiner拿到前镜像和后镜像之后，不知道怎么解码，直接标记为NULL或UNSUPPORTED。

### 裸日志解析怎么处理前镜像和后镜像？

直接解析二进制的时候，前镜像和后镜像的处理逻辑是自己控制的。

**核心思路：不依赖数据字典，按二进制格式直接解码。**

具体来说：

**第一，识别Change Vector的类型。** 通过OP Code判断这是INSERT、UPDATE还是DELETE。INSERT没有前镜像，DELETE没有后镜像，UPDATE两个都有。

**第二，解析Body里的二进制数据。** Change Vector的Body里，前镜像和后镜像按列顺序排列。每一列的编码方式由数据类型决定——NUMBER有NUMBER的编码，VARCHAR2有VARCHAR2的编码。

**第三，自己维护类型映射。** 不依赖Oracle的数据字典，自己维护表和列的元数据。列的顺序、类型、长度，全部自己管理。这样就不会受LogMiner字典翻译层的限制。

**第四，按类型逐列解码。** NUMBER类型按Oracle的NUMBER编码规则解码，VARCHAR2按字符集解码，DATE按7字节格式解码，BLOB/CLOB按locator关联实际数据块解码。

**第五，处理回滚判断。** 读到OP 5.1（撤销修改）时，把对应的前镜像应用到已经解析的变更上，把数据恢复到修改前的状态。如果整个事务最终回滚，所有变更都不输出。

> 我们团队在做TLA的时候，前镜像和后镜像的解析就是按这个思路实现的。自己维护列的类型和顺序，自己按二进制格式解码，不依赖LogMiner的字典翻译层。所以BLOB、CLOB、XMLTYPE这些LogMiner不支持的类型，我们都能处理。流式解析，不缓存整个事务，大事务也不会OOM。

### 一个容易搞混的点

**前镜像不是“上一行的值”，后镜像不是“下一行的值”。**

前镜像和后镜像是针对**同一个数据块、同一行数据**的修改前后状态。不是两个不同行的值。

**前镜像不一定完整。** 取决于补充日志的配置。默认情况下只记录修改涉及的列。

**后镜像也不一定完整。** 对于大字段，后镜像可能只是locator，不是完整数据。

**前镜像和后镜像可能不在同一个Change Vector里。** 一个大的UPDATE可能被拆成多个Change Vector，前镜像和后镜像分散在不同的record里。

### 说句实在话

前镜像和后镜像，名字听起来很学术，其实本质很简单——就是修改前和修改后的数据。

但在实际解析中，这两个东西涉及的问题很多：补充日志的配置、数据类型的处理、大字段的关联、回滚的判断、行迁移的处理……

套壳LogMiner的方案，把这些事情交给了LogMiner。代价是：需要连接数据库、依赖数据字典、不支持某些类型、大事务OOM。

裸日志解析的方案，自己处理前镜像和后镜像的解析。难走，但走通了就不受任何人限制。

这是“LogMiner vs 裸日志解析”系列的第三篇。后面会继续聊其他几个坑——大事务OOM、SCN追不上、在线日志读写冲突，等等。

欢迎交流。

---

*补充：文中提到的补充日志配置和数据类型处理方式基于Oracle主流版本的通用机制，不同版本可能有细微差异。实际解析时需要根据目标版本做适配。*

但问题在于——这两个东西在redo log里到底是怎么存的？CDC解析的时候到底该用哪个？

聊Oracle日志解析，绕不开两个词：前镜像（Before Image） 和后镜像（After Image）

数据库

开发工具

后端

前镜像与后镜像是Oracle redo log中记录数据修改前后状态的机制，本文解析其存储位置、CDC解析中各自用途（后镜像用于同步、前镜像用于回滚判断），并深入探讨补充日志配置、大字段截断、LONG类型不支持等实际解析中的常见坑点，对比LogMiner与裸日志解析两种方案的差异与优劣。

数据恢复

代码解释

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

聊Oracle日志解析，绕不开两个词：前镜像（Before Image） 和后镜像（After Image）-腾讯云开发者社区-腾讯云

聊Oracle日志解析，绕不开两个词：前镜像（Before Image）和后镜像（After Image）

聊Oracle日志解析，绕不开两个词：前镜像（Before Image）和后镜像（After Image）

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

聊Oracle日志解析，绕不开两个词：前镜像（Before Image） 和后镜像（After Image）

聊Oracle日志解析，绕不开两个词：前镜像（Before Image） 和后镜像（After Image）

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

聊Oracle日志解析，绕不开两个词：前镜像（Before Image）和后镜像（After Image）

聊Oracle日志解析，绕不开两个词：前镜像（Before Image）和后镜像（After Image）