聊Flink CDC，绕不开Oracle连接器。

网上吹它的人很多：开源、免费、生态好、跟Flink无缝集成。但你去翻翻GitHub上的Issue，会发现另一番景象——一堆问题挂了半年、一年甚至更久，没人解决，或者根本解决不了。

这篇文章不聊虚的，直接从Issue出发，看看Flink CDC Oracle连接器到底有哪些“历史遗留问题”。

一、SCN暴涨就追不上：两年了，还是Open

Issue #1940 / FLINK-34775，2024年3月创建。

用户描述的场景很典型：Oracle数据库的SCN（系统变更号）发生大幅增长时，LogMinerStreamingChangeEventSource就追不上最新数据了。

根因是什么？LogMinerQueryResultProcessor在处理完一轮数据后，反馈的lastProcessedScn不够合理。第一轮能拿到正确的processedScn，但下一轮用这个值作为startScn去查询时，查不到任何数据，startScn就卡住不动了。与此同时，Oracle的SCN还在疯狂增长，源表的新数据就永远追不上了。

用户自己分析了代码、找到了根因、甚至表示愿意提交PR。

但Issue的状态呢？Open。Assignee：Unassigned。Fix Version：None。

一个用户愿意自己修的问题，挂了两年多，还是没人接。

二、数据丢失：五十万条丢一条，你敢用吗？

Debezium Issue #2184，2026年7月创建。

用户用的Debezium 3.4.0，Oracle 19c。配置跑起来之后，发现Kafka topic里缺了一些事件。

缺多少？“really rare, depending on the table, one missing in half a million events”——五十万条里丢一条。

五十万条丢一条，听起来概率不高对吧？但问题是——你永远不知道丢的是哪一条。

金融场景里，五十万笔交易丢一笔，谁能接受？更何况这个Issue到现在还是Open状态。用户怀疑跟reselector有关，但根本没人给出明确的修复方案。

三、大事务直接OOM：加内存没用

Discussion #1961，2023年3月创建。

用户更新大量数据时，直接报OutOfMemoryError: Java heap space。他做了详细的测试：

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

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

用户把能调的参数都调了——log.mining.batch.size.max、max.batch.size、max.queue.size，全试了一遍。没用。

他自己分析了Debezium的源码，发现根因是：Debezium在事务提交之前，会把所有变更先缓存到本地内存里。事务有多大，缓存就有多大。

他的问题是：“Is there a way to make the connector split a large amount of changes processing for a single transaction?”

答案呢？没人回答。 Discussion从2023年挂到现在。

四、表名超30字符：Oracle 19c能建表，但Flink CDC不抓

Issue #2475，2023年9月创建。

用户的表名叫GL_001_XPHARMA_PRIVILEGE_DETAIL，34个字符。Oracle 19c能正常建表——因为从Oracle 12c开始，表名最大长度已经从30个字符扩展到了128个字符。

但Flink CDC报了个WARN：Table '...' won't be captured by Oracle LogMiner because its name exceeds 30 characters。

用户很困惑：“我使用的是oracle19c，超过30个字符的表我是可以正常创建的，但使用flink cdc捕获数据时，为啥不行？”

他尝试调大STREAMS_POOL_SIZE、重启Oracle，全没用。最后问了一句：“Can anyone completely solve this problem?”

Issue状态：Open。

解决方案？官方建议只有一个：改表名，限制在30个字符以内。

五、同步慢到10分钟：查一次表花了1分钟

FLINK-34781，2024年3月创建。

用户描述：“数据同步非常慢，通常大约10分钟”。

根因是什么？Flink CDC在查询ALL_TABLES视图获取表列表时，没有加任何过滤条件。在有大量库和表的Oracle环境中，这个查询耗时1分钟，返回超过30万条记录，占用了大量内存。

用户自己提出了优化方案：加表名限定条件，把查询降到毫秒级。甚至表示愿意提交PR。

Issue状态：Open。Fix Version：None。

一个1分钟变毫秒级的优化，用户连代码都写好了，两年了没人合并。

六、还有一堆“新”问题

除了上面这些挂了很久的，最近还在不断冒出新的问题：

• FLINK-39834（2026年6月） ：Oracle CDC在处理包含||的UNISTR表达式时会重复输出，导致下游数据膨胀。Status：Open。
• FLINK-39832（2026年6月） ：Oracle的NUMBER(p,0)当p>=19时被错误映射为BIGINT，导致主键冲突、下游行数据折叠。
• FLINK-39840（2026年6月） ：Oracle pipeline连接器发出的表标识不完整。
• 还有SQL注入漏洞（CVE-2025-62228），影响3.0.0到3.5.0版本。

为什么这些问题修不了？

你可能会问：Flink CDC不是Apache顶级项目吗？社区不是很活跃吗？

问题不在Flink CDC社区，在LogMiner。

Flink CDC的Oracle连接器底层依赖的是Debezium，Debezium底层依赖的是Oracle LogMiner。LogMiner是Oracle内核的一部分——闭源的、黑盒的、你动不了的。

表名30字符限制？LogMiner的限制。
SCN追不上？LogMiner的lastProcessedScn反馈机制问题。
大事务OOM？LogMiner需要在内存里缓存整个事务。
数据丢失？LogMiner就是会漏事件。

Debezium和Flink CDC只能在LogMiner外面套一层壳，壳里面的东西，他们改不了。

这就是为什么这些Issue挂了半年、一年、两年——不是社区不努力，是根因在LogMiner里面，他们够不着。

说句实在话

Flink CDC在MySQL、PostgreSQL上确实好用。问题出在Oracle这里——它被LogMiner卡住了脖子。

你去翻GitHub，Issue #1940（SCN追不上）Open了两年多。Issue #2475（30字符表名）Open了快两年。Discussion #1961（大事务OOM）挂了三年多。

用户把根因分析出来了、把代码写好了、PR都准备好了——但还是没人合并。为什么？因为这些问题根子在LogMiner，改Flink CDC的代码解决不了根本问题。

这就是套壳方案的宿命：你永远受制于那个你改不了的黑盒。

欢迎交流。

---

补充：文中提到的Issue和Discussion均来自Apache Flink CDC和Debezium的公开GitHub仓库，可自行查证。Issue状态以文章发布时的公开信息为准。