
聊完单线程和堆实例的问题，今天说一个更直接、更暴力的坑——**大事务直接把内存撑爆。**

### 先看一个真实场景

半夜两点，业务方跑了一个批量任务，更新了几百万行数据。

第二天早上，运维发现Debezium任务挂了。日志里躺着：

```
java.lang.OutOfMemoryError: Java heap space
```

这不是第一次了。上次也是批量任务，堆内存加到960MiB，撑过去了。这次加到1.5GiB，又撑过去了。但下次呢？业务数据量还在涨，总有一天加内存也扛不住。

**这不是配置问题，是机制问题。**

### 为什么LogMiner/Debezium路线会OOM？

要理解这个，得先搞清楚LogMiner和Debezium在处理事务时的两种不同内存机制。

**机制一：LogMiner的COMMITTED_DATA_ONLY缓存**

LogMiner有一个常用选项叫`COMMITTED_DATA_ONLY`——只返回已提交事务的数据，自动过滤掉未提交和回滚的事务。

这个选项有个特性，Oracle官方文档里写得很清楚：

> If the COMMITTED_DATA_ONLY option is specified and you issue a query, LogMiner stages all redo records within a single transaction in memory until LogMiner finds the commit record for that transaction. Therefore, it is possible to exhaust memory.

翻译一下：**如果你用了COMMITTED_DATA_ONLY，LogMiner会在内存里缓存一个事务的所有redo记录，直到找到这个事务的提交记录。因此，有可能耗尽内存。**

这就是根因。

LogMiner为了判断一个事务是否已提交，必须把整个事务的所有变更全部读进PGA，等到看见COMMIT记录，才知道“哦，这个事务可以输出”。

一个事务有多大，PGA就得装多大。修改100万行，redo可能几个GB——这几个GB全要塞进PGA。

有团队实测过，一个修改几百万行的事务，LogMiner的PGA占用直接飙到**20GB以上**，然后触发`PGA_AGGREGATE_LIMIT`限制，整个LogMiner会话被强制终止。

**机制二：Debezium的内存缓存**

Debezium官方文档里也写得明明白白：

> The Oracle connector uses an in-memory buffer to cache in-progress transaction changes until the transaction is committed or rolled back. This cache might require significant memory, depending on the number of events in the transaction.

翻译一下：**Debezium在事务提交之前，会把所有变更先缓存到本地内存里。事务有多大，缓存就有多大。**

有开发者做了详细的测试：

| TaskManager堆内存 | 最大成功行数 | 最小失败行数 |
|---|---|---|
| 540MiB | 25万行 | 30万行 |
| 960MiB | 35万行 | 40万行 |

**加了将近一倍的内存，只多撑了10万行。**

这意味着什么？意味着**增加内存只是把阈值往上推了一点，根因根本没解决。** 业务数据量在涨，大事务的规模在涨，你永远在追着加内存。

### 为什么不能“分批处理”？

有人会问：LogMiner不能把大事务拆成小批处理吗？

**不能。**

因为LogMiner必须在内存里维护整个事务的上下文。它需要按XID归集同一个事务的所有Change Vector，按SCN排序，按OP识别边界。这些操作的前提是——**事务的所有碎片都在内存里。**

你不能说“先处理前半部分，再处理后半部分”。因为前半部分可能还没提交，你还不知道这个事务最终是提交还是回滚。如果先输出了一半，后来发现事务回滚了，那已经发出去的数据怎么办？

**事务的原子性，要求解析器必须等到看见COMMIT才能输出。**

这就是问题的根源：**原子性和内存是矛盾的。** 要保证原子性，就必须缓存整个事务；缓存整个事务，就必然面临大事务OOM。

### 社区能修吗？

Debezium社区讨论过这个问题。有人在Discussion #1961里问：“能不能让连接器拆分大事务的处理？”

**没有答案。**

社区说未来版本会引入新的缓存机制——但那是“未来版本”，你在生产环境等不起。

而且就算Debezium改了缓存机制，它底层的LogMiner也没变。LogMiner的COMMITTED_DATA_ONLY还是要把事务缓存在PGA里。Debezium能优化的只是自己的那层缓存，LogMiner那层它动不了。

**根因在LogMiner里面，外面改不了。**

### 裸日志解析怎么做？

TLA的流式解析，从机制上避开了这个问题。

核心差异在于：**不需要把整个事务缓存在内存里等提交。**

具体来说：

**第一，流式读取，边读边解析。**

TLA直接读redo log的二进制块，逐个解析Change Vector。读到OP 5.2（事务开始），标记事务启动；读到OP 11.5（数据修改），记录变更；读到OP 5.4（提交），确认事务完成。

整个过程是流式的——读到哪解析到哪，不需要预读整个事务。

**第二，按XID归集，但不缓存全量数据。**

按XID分组是需要的——同一个事务的Change Vector要归到一起。但归集的方式不是把整个事务的所有数据缓存在内存里，而是维护一个轻量的上下文。

每个事务的上下文只记录关键信息：XID、事务状态、已处理的Change Vector数量、当前SCN等。真正的变更数据，解析出来之后直接往输出通道推，或者按需落盘。

**第三，提交前不输出，提交后才输出。**

读到OP 5.2（事务开始）时，把这个事务标记为“进行中”。这个事务产生的所有变更，暂时不输出。

读到OP 5.4（提交）时，确认事务完成。这时候再把这个事务的变更输出。

如果读到OP 5.1（回滚），直接丢弃这个事务的所有变更。

**这个逻辑不需要缓存整个事务的数据。** 只需要维护事务的状态和已处理的位置信息。变更数据本身不需要长期驻留内存。

**第四，内存占用平稳，不随事务大小增长。**

TLA的内存占用是稳定的——不管事务多大、变更多少，内存占用基本在同一个水平。因为它不需要缓存全量数据，只需要维护状态。

有测试数据显示，TLA解析一个几十GB的redo文件，内存波动不超过100MB。

**第五，没有磁盘I/O拖累。**

有些方案用磁盘临时文件来缓解内存压力——内存不够了就把数据写到磁盘上。但这会引入新的问题：磁盘I/O可能成为瓶颈，而且读写临时文件本身也消耗资源。

TLA的流式处理不需要磁盘临时文件。解析出来的变更直接推给下游，或者写入输出队列。

> 我们团队在做TLA的时候，就是按这个思路设计的。流式解析，按XID归集但不缓存全量数据，只在COMMIT边界输出。实测大事务场景下内存占用平稳，不会OOM。目前Oracle版本已经跑通了，后续MySQL、PG和国产数据库的支持也在推进中。

### 一个直观的对比

假设有一个100万行的批量UPDATE，redo量大约2GB。

| 方案 | 内存占用 | 处理方式 | 结果 |
|---|---|---|---|
| LogMiner（COMMITTED_DATA_ONLY） | 2GB+ PGA | 全量缓存，等COMMIT | 可能OOM |
| Debezium | 2GB+ Java堆 | 全量缓存，等COMMIT | 可能OOM |
| TLA（流式解析） | 约100MB | 边读边推，等COMMIT | 正常完成 |

**这个差异的核心在于：LogMiner和Debezium需要“全量缓存”，TLA只需要“状态跟踪”。**

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

**大事务OOM不只是“任务挂了”这么简单。**

任务挂了，重启就行。但重启之后呢？

如果检查点没对齐，重启后可能重复输出一部分数据。如果检查点落后太多，重启后可能要重新解析大量日志。如果大事务还在继续产生，重启后可能再次OOM。

**这是一个恶性循环。**

而且OOM的时候，任务崩溃的时间点是不可控的。可能是在凌晨业务低谷期，也可能是在业务高峰期。如果在高峰期崩溃，源库本来就在扛业务压力，你还要重启解析任务、重新扫描日志——进一步加剧资源竞争。

流式解析的方案不存在这个问题。大事务来了，内存不涨；任务重启了，从检查点继续。不需要额外的资源，不需要等业务低谷。

### 说句实在话

大事务OOM这件事，是LogMiner/ Debezium路线的一个结构性缺陷。

不是配置没调好，不是内存不够大——是**机制决定了它必须把整个事务缓存在内存里**。事务越大，内存消耗越大，最终必然OOM。

社区能优化，但改不了根因。根因在LogMiner里面，在“必须等COMMIT才能输出”这个原子性要求里面。

TLA的流式解析，从机制上避开了这个问题。不需要全量缓存，不需要磁盘临时文件，内存占用平稳。

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

欢迎交流。

---

*补充：文中提到的内存数据和案例来自公开的GitHub Issue、技术社区讨论和官方文档，可自行查证。实际效果受硬件配置、数据库版本、事务大小等因素影响。*

这不是第一次了。上次也是批量任务，堆内存加到960MiB，撑过去了。这次加到1.5GiB，又撑过去了。但下次呢？业务数据量还在涨，总有一天加内存也扛不住。

LogMiner vs 裸日志解析（七）：大事务直接把内存撑爆

数据库

开发工具

架构设计

大事务内存OOM是LogMiner/Debezium架构的结构性缺陷：COMMITTED_DATA_ONLY机制要求整个事务缓存于PGA，Debezium同步缓存至Java堆，内存随事务规模线性增长直至崩溃。TLA流式解析改以状态跟踪代替全量缓存，边读边推，大事务下内存占用仅约100MB，稳定不随事务增大，规避了原子性要求与内存容量的矛盾。

数据缓存

代码解释

MySQL

Java

文章

问答

视频

教程

学习中心

腾讯云实验室

直播

竞赛

腾讯云代码分析专区

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

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

腾讯云数据库专区

腾讯云智能顾问专区

腾讯云原生专区

腾讯混元专区

腾讯云TCE专区

腾讯云Lighthouse专区

腾讯云HAI专区

腾讯云Edgeone专区

腾讯云存储专区

腾讯云智能专区

腾讯轻联专区 

腾讯云开发专区

TAPD专区

腾讯轻量云游戏服专区

EdgeOne AI 安全实战专区

腾讯云最具价值专家

腾讯云架构师技术同盟

腾讯云创作之星

腾讯云开发者先锋

腾讯云代码助手

云原生构建

TAPD 敏捷项目管理

Cloud Studio

SDK中心

API中心

命令行工具

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

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

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

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

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

社区新版编辑器体验调研

大事务内存OOM是LogMiner/Debezium架构的结构性缺陷：COMMITTED_DATA_ONLY机制要求整个事务缓存于PGA，Debezium同步缓存至Java堆，内存随事务规模线性增长直至崩溃。TLA流式解析改以状态跟踪代替全量缓存，边读边推，大事务下内存占用仅约100MB，稳定不随事务增大，规避了原子性...

LogMiner vs 裸日志解析（七）：大事务直接把内存撑爆-腾讯云开发者社区-腾讯云

LogMiner vs 裸日志解析（七）：大事务直接把内存撑爆

LogMiner vs 裸日志解析（七）：大事务直接把内存撑爆

社区

活动

圈层

关于

腾讯云开发者

热门产品

热门推荐

更多推荐