## 一个COMMIT在redo里长什么样？你可能猜错了

聊到Oracle的事务提交，很多人脑子里是这样一个画面：

客户端发了一个`COMMIT`，Oracle在redo log里写一条“提交”记录，完事。

**这个理解，不能说错，但漏掉了太多东西。**

真实情况是：一个COMMIT在redo log里远不止“一条记录”那么简单。它涉及的Change Vector数量、写入顺序、以及跟其他事务的交叉方式，比大多数人想象的要复杂得多。

搞清楚这件事，对理解CDC的检查点、事务一致性、以及为什么有些方案会丢数据，都很关键。

### 先猜一下：一个COMMIT会产生几个Change Vector？

假设有一个简单的事务：

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

你觉得这个COMMIT在redo里对应几个Change Vector？

**很多人会猜：一个。** 就是OP 5.4，事务提交。

**有人会猜：两个。** 一个数据变更（OP 11.5），一个提交（OP 5.4）。

**实际答案：至少4个，可能更多。**

### COMMIT到底做了什么？

要理解COMMIT在redo里长什么样，得先搞清楚COMMIT时Oracle内部发生了什么。

**第一，COMMIT不是“一个动作”，是一系列动作。**

当你发出COMMIT时，Oracle要做这几件事：

1. **在回滚段头的事务表里，把该事务的状态标记为“已提交”** ——这个动作本身会产生一个Change Vector
2. **在数据块的ITL（Interested Transaction List）里，更新事务槽的状态** ——这个也会产生Change Vector
3. **清理回滚段里的UNDO信息**（或者标记为可清理）——如果涉及清理操作，还会产生Change Vector
4. **写一条提交记录到redo log** ——这就是大家熟知的OP 5.4

**第二，OP 5.4只是“提交标记”，不是“提交本身”。**

OP 5.4的Change Vector，体里存的东西其实很少——它主要是一个标记，告诉解析器“这个事务到此结束了”。真正的“提交”动作，是分散在多个Change Vector里的。

**第三，提交SCN跟事务内的其他SCN不一样。**

一个事务在运行过程中，会产生多个Change Vector，每个都有自己的SCN。但提交的时候，Oracle会分配一个**新的SCN**作为提交SCN。这个SCN才是这个事务的“最终时间戳”。

这意味着：**同一个事务内的Change Vector，SCN可能是不同的。** 解析器不能简单地按SCN分组来归集事务，必须结合XID一起判断。

### 完整的COMMIT序列长什么样？

还是用刚才那个UPDATE为例，把完整的Change Vector序列拆开看：

**第1步：事务开始（OP 5.2）**

在回滚段头的事务表里分配一个槽位，生成一个XID。这个Change Vector标记事务启动。

**第2步：修改回滚块（OP 5.1）**

把数据修改前的旧值写入Undo块。这个Change Vector的Body里存的是前镜像。

**第3步：修改数据块（OP 11.5）**

更新employees表的数据块，记录前后镜像。这个Change Vector的Body里存的是修改前的值和修改后的值。

**第4步：提交时更新回滚段头（OP 5.4 或其他提交相关的操作码）**

COMMIT时，Oracle需要更新回滚段头的事务表状态，把该事务标记为“已提交”。这个动作本身会产生一个Change Vector。

**第5步：更新数据块ITL（可能）**

数据块的ITL里有一个事务槽，记录了哪些事务修改了这个块。COMMIT时，这个槽位的状态也需要更新，这又是一个Change Vector。

**第6步：提交标记（OP 5.4）**

最后，写一条OP 5.4的Change Vector，标记事务结束。

**所以一个简单的UPDATE+COMMIT，redo里至少产生了4-6个Change Vector。**

而且这些Change Vector不一定连续——在高并发场景下，多个事务的Change Vector会交织在一起。同一个事务的Change Vector可能被其他事务的Change Vector隔开。

### 这对CDC意味着什么？

理解了COMMIT的真实结构，就能理解为什么CDC方案在事务处理上会遇到各种问题。

**第一，事务归集不能只看SCN。**

因为同一事务内不同Change Vector的SCN可能不同，而不同事务的Change Vector可能SCN相同（同一批次分配）。必须用XID来归集，SCN只用来排序。

**第二，检查点不能随便打。**

如果一个检查点打在了“事务已经修改了数据块但还没提交”的位置，恢复的时候怎么办？这个事务的数据块变更已经写进redo了，但还没有COMMIT标记。

LogMiner的方案是：把整个事务的所有Change Vector都缓存在内存里，等到看见COMMIT才输出。这就是为什么大事务会OOM。

**第三，回滚事务的处理更复杂。**

如果一个事务执行到一半回滚了，redo里会有OP 5.1（撤销修改）的Change Vector。解析器必须能识别“这个事务最终是回滚了”，然后把所有相关的Change Vector都丢弃。

**第四，COMMIT的OP 5.4可能丢。**

如果解析器读到OP 5.4的时候，因为某种原因（网络中断、进程崩溃）没有正确记录检查点，重启后可能重复输出这个事务的变更。这就是“数据重复”的来源。

### 裸日志解析怎么处理COMMIT？

直接解析二进制的时候，COMMIT的处理逻辑是自己控制的。

**核心思路：按XID归集，按OP识别边界，按提交SCN输出。**

具体来说：

1. **读到Change Vector，先提取XID。** 按XID分组，把同一个事务的所有碎片放在一起。
2. **识别事务边界。** OP 5.2是开始，OP 5.4是提交，OP 5.1是回滚。
3. **判断事务状态。** 如果事务以OP 5.4结束，输出所有变更；如果以OP 5.1结束，丢弃所有变更。
4. **以提交SCN作为事务的最终SCN。** 同一个事务内的Change Vector可能SCN不同，但提交SCN是唯一的。
5. **检查点只在COMMIT边界打。** 确认一个事务的所有Change Vector都处理完毕了，才记录检查点。这样恢复的时候不会遇到“半个事务”的问题。

> 我们团队在做TLA的时候，COMMIT的处理逻辑就是按这个思路实现的。流式解析，按XID归集事务，只在COMMIT边界打检查点。不需要把整个事务缓存在内存里，大事务也不会OOM。目前Oracle版本已经跑通了，后续MySQL、PG和国产数据库的支持也在推进中。

### 再说一个反直觉的点

**COMMIT的OP 5.4，不一定在最后一个Change Vector里。**

在高并发场景下，Oracle可能先把COMMIT标记写进redo，然后再写其他Change Vector。或者反过来，先写其他Change Vector，最后写COMMIT标记。

**所以解析器不能简单地“读到OP 5.4就以为事务结束了”。** 需要结合XID和SCN来判断——确认这个事务的所有Change Vector都已经读到了，才能输出。

这也是为什么有些CDC方案会丢数据——它们只看到了OP 5.4，但漏掉了OP 5.4之前或之后的某些Change Vector。

### 说句实在话

一个COMMIT在redo里长什么样？

**它不是一条记录，是一组Change Vector的集合。**

事务开始、数据修改、UNDO、提交标记——每个动作都是一个独立的Change Vector。这些Change Vector可能分散在不同的redo record里，可能被其他事务的Change Vector隔开，SCN可能不同，顺序可能交错。

把这组碎片正确地拼回一个完整的事务，判断它是提交还是回滚，按提交SCN输出——这就是日志解析的核心工作。

套壳LogMiner的方案，把这件事交给了LogMiner。代价是：大事务OOM、回滚判断不准确、检查点受制于人。

裸日志解析的方案，自己实现这套逻辑。难走，但走通了就不受任何人限制。

欢迎交流。

---

*补充：文中提到的OP Code和事务行为基于Oracle主流版本的通用机制，不同版本可能有细微差异。实际解析时需要根据目标版本做适配。*

客户端发了一个COMMIT，Oracle在redo log里写一条“提交”记录，完事。

一个COMMIT在redo里长什么样？你可能猜错了

数据库

编程语言

开发工具

一个COMMIT在redo中并非单条记录，而是由多个ChangeVector组成的集合，包含事务开始、数据修改、UNDO更新、ITL变更及提交标记等操作，这些向量可能交错分散且SCN不同。解析需按XID归集，识别OP边界，以提交SCN为准，在COMMIT边界设检查点，避免大事务OOM及数据重复或丢失。

代码解释

MySQL

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

一个COMMIT在redo里长什么样？你可能猜错了-腾讯云开发者社区-腾讯云

一个COMMIT在redo里长什么样？你可能猜错了

一个COMMIT在redo里长什么样？你可能猜错了

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐