Flink CDC同步Oracle分区表实战：ORA-08103与ORA-01555的完整解法

最近在做一个Oracle到Kafka的实时同步需求，数据源是一张按月RANGE分区的订单历史表，用的Flink CDC Oracle Connector 3.5.0。任务本身也不复杂，没想到一张分区表把整个上线流程卡了两天。期间遇到了ORA-08103、ORA-01555，还有增量阶段日志出不来、表分区被自动扩展导致快照失败等问题。最终问题解决后，我把整个过程完整复盘了一遍，从报错规律、连接器工作方式到参数调整都捋清楚了。这里直接把处理过程和踩坑记录分享出来，给正在用Flink CDC同步Oracle分区表的同学做个参考。

如果是为了找现成答案，可以先看核心结论：Flink CDC Oracle Connector 3.5.0在同步分区表时，最大的坑并不是连接器不支持分区表，而是增量快照算法在分片阶段和Oracle分区元数据变化之间产生竞态，导致快照期间出现ORA-08103或ORA-01555。解决方向是控制分区表元数据稳定性、合理指定分片键、缩小chunk，并配合日志挖掘参数做增量侧兜底。

1. 问题复盘：一次Oracle分区表CDC同步的报错现场

1.1 同步环境与业务背景

先说环境。Flink版本用的1.18.1，Flink CDC版本是3.5.0，源库是Oracle 19c，启用了CDB/PDB模式，业务数据在PDB里。同步对象是一张订单历史表，表结构大概是这样的：

sql复制CREATE TABLE APP.ORDER_HIS (
    ORDER_ID      NUMBER(18) NOT NULL,
    ORDER_STATUS  VARCHAR2(10),
    AMOUNT        NUMBER(12,2),
    ORDER_DATE    DATE,
    CREATE_TIME   TIMESTAMP(6)
)
PARTITION BY RANGE (ORDER_DATE)
INTERVAL(NUMTOYSMINTERVAL(1, 'MONTH'))
(
    PARTITION P_202501 VALUES LESS THAN (TO_DATE('2025-02-01', 'YYYY-MM-DD'))
);

这张表的特点很典型：按月自动分区，每个月有新的INTERVAL分区自动生成；同时业务上每天还有少量历史数据修正，会产生DML。目标端是Kafka，后续接数据湖做事件归档。

我最初的Flink SQL写法也很常规，没有做任何特殊分区表适配，就是在Flink SQL Client里创建了一个oracle-cdc source表，然后insert into kafka sink。任务启动后，全量阶段一开始跑得还算正常，能看到source表数据量在增长，但跑到十几分钟时作业突然失败。

1.2 报错日志与故障表象

JobManager日志里报错的关键部分是这样：

text复制Caused by: java.sql.SQLException: ORA-08103: object no longer exists
    at oracle.jdbc.driver.T4CTTIoer11.processError(T4CTTIoer11.java:509)
    at oracle.jdbc.driver.T4CTTIoer11.processError(T4CTTIoer11.java:461)
    ...
    at org.apache.flink.cdc.connectors.oracle.source.reader.fetch.SnapshotSplitReader.fetchNextBatch

第一次看到这个错误时，我以为是权限问题或者表名大小写问题，因为ORA-08103这个报错在Oracle里并不常见，平时手动查表几乎遇不到。我又重新检查了授权，确认账号可以正常查询这张分区表，甚至单独对某个分区执行count(*)也完全正常。把任务重启后，报错依然在，只是报错时间点略有不一致。更诡异的是，某一次重跑时错误变成了：

text复制ORA-01555: snapshot too old

这两个错误放在一起，基本上就能定位到问题方向了：这已经不是权限问题，而是快照一致性和元数据稳定性问题。ORA-08103意味着在快照查询的SCN对应时间点，某个对象已经不存在了；ORA-01555则意味着UNDO数据被覆盖，快照读无法拿到一致性数据。两种情况都和“长时间扫描一张还在持续变化的表”强相关。

而我这张表偏偏是INTERVAL分区表。于是问题指向就很明确了：Flink CDC的增量快照机制扫描分区表时，和分区表的动态扩展产生了冲突。

2. 3.5.0连接器在分区表场景的运作原理

2.1 一条完整的Oracle CDC数据链路

先理清Flink CDC 3.5.0读取Oracle数据的链路。连接器底层是构建在Debezium Oracle connector之上的，整体分为两大块：全量快照（Snapshot）和增量日志读取（LogMiner）。

全量快照阶段，连接器会读取源表当前的数据，为下游准备一份初始数据。增量阶段则通过Oracle的LogMiner解析redo log和archive log，把事务提交后的变更记录提取出来，再转成Flink的CDC事件。整个过程对外表现为“初次启动时先全量，再无缝切增量”。

在Flink CDC 3.x版本里，全量快照默认采用增量快照算法（Incremental Snapshot），不再像2.x那样一把梭直接把整表查出来。它会把一张表按主键或指定唯一键切成多个chunk，然后逐个chunk去查询和回填。这样做的好处是任务可以断点续传、支持并行快照，缺点是对分片键的合理性要求比较高。

2.2 快照阶段对分区表的分片处理逻辑

增量快照算法处理普通表时，流程是这样的：先查询表的主键或唯一索引元数据，然后计算数据分布（min/max/count），把键值范围均匀切成N个chunk，每个chunk单独执行一次SELECT * FROM table WHERE pk_col > ? AND pk_col <= ?来完成快照。

这本身对普通表很友好。但到了Oracle分区表这里，有几个特殊点必须注意：

第一，分区表对连接器来说仍然是“一张表”。Flink CDC拿到的元数据是逻辑表结构，并不感知Oracle底层的分区段。分片SQL默认走主键列，这和分区无关，所以只要表有主键，分片逻辑本身不会因为分区而报错。

第二，问题出在Oracle执行分片SQL时的优化器行为。对范围分区表而言，优化器有可能在解析SQL时做分区裁剪，然后以分区为单位去读取数据。如果在快照查询进行期间，表发生了分区维护操作（比如INTERVAL分区自动创建新分区、手工TRUNCATE旧分区、分区SPLIT/MERGE），Oracle的SCN一致性读就可能拿到“某个对象在当前SCN之后已经不存在”的结果，这就是ORA-08103的来源。

第三，INTERVAL分区表的自动扩展是无感的。只要业务侧插入一条ORDER_DATE超出当前最大分区的数据，Oracle就会自动创建一个新分区。这个动作发生在Flink CDC快照扫描过程中，就会改变表的分区元数据状态。如果连接器在统计分片时刚好读到了旧的元数据，而回填阶段Oracle已经按新元数据重写了计划，两边对不上就报错。

所以我这次遇到的ORA-08103，本质上不是连接器的bug，而是“分区表元数据动态变化”和“增量快照分片回填”之间的竞态。普通表没有这个动作，自然不会出问题。

2.3 增量阶段日志挖掘对表结构变化的影响

全量问题解决之后，增量阶段也可能有独立的风险点，而且分区表比普通表更明显。

LogMiner在解析redo日志时，会读取数据字典信息和补充日志。Oracle分区表上的DML操作本身和普通表没有本质区别，redo记录里会包含行的变更信息。但有一个很常见的问题：业务侧为了清理历史数据，经常对分区表做TRUNCATE PARTITION，而且很多DBA在操作时不会特意开启补充日志对DDL的捕获支持。

TRUNCATE PARTITION和普通DELETE不一样，它属于DDL操作。LogMiner虽然能捕获到DDL记录，但Debezium对这类事件的解析能力有限，默认往往是忽略或者报错。如果连接器把这类事件当成异常处理，同步作业很容易在“没有任何明显报错”的情况下停止推进，表现为：任务还在运行、source一直没有新增记录、延迟越来越大。

另外，分区表的索引如果是LOCAL分区索引，LogMiner解析SCN时需要访问的索引片段和表片段是对应的。如果业务侧对某些分区做了索引重建，可能导致日志挖掘过程中SCN跳跃异常，出现类似“ORA-00354 corrupt redo log block header”的报错。这类问题通常不是redo日志真的损坏，而是日志挖掘读到的SCN上下文和在线数据字典不一致。

3. 分步排查与参数修正：从报错到恢复同步

3.1 源库侧前置检查与授权整理

不管报了什么错，第一步永远是确认源库的CDC前置条件。Oracle 19c上做Flink CDC，至少需要满足三件事：开启归档模式、开启补充日志、给同步账号足够的权限。

先用DBA权限账号检查：

sql复制-- 查看数据库是否开启归档
SELECT LOG_MODE, SUPPLEMENTAL_LOG_DATA_MIN, SUPPLEMENTAL_LOG_DATA_ALL
FROM V$DATABASE;

正常情况下需要看到LOG_MODE=ARCHIVELOG，SUPPLEMENTAL_LOG_DATA_MIN=YES，SUPPLEMENTAL_LOG_DATA_ALL=YES。如果没有开启，执行：

sql复制-- 开启数据库级补充日志
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA;
ALTER DATABASE ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

表级也可以单独开：

sql复制ALTER TABLE APP.ORDER_HIS ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;

同步账号如果是新建的，建议直接把这套权限全部授权：

sql复制GRANT CREATE SESSION TO flink_user;
GRANT LOGMINING TO flink_user;
GRANT SELECT ON V_$DATABASE TO flink_user;
GRANT SELECT ON V_$ARCHIVED_LOG TO flink_user;
GRANT SELECT ON V_$LOG TO flink_user;
GRANT SELECT ON V_$LOGFILE TO flink_user;
GRANT SELECT ON V_$LOGMNR_CONTENTS TO flink_user;
GRANT SELECT ON V_$LOGMNR_LOGS TO flink_user;
GRANT SELECT ON V_$LOGMNR_PARAMETERS TO flink_user;
GRANT SELECT ON V_$PARAMETER TO flink_user;
GRANT SELECT ANY TRANSACTION TO flink_user;
GRANT EXECUTE ON DBMS_LOGMNR TO flink_user;
GRANT SELECT ON ALL_USERS TO flink_user;
GRANT SELECT ON ALL_OBJECTS TO flink_user;
GRANT SELECT ON ALL_TAB_PARTITIONS TO flink_user;
GRANT SELECT ON ALL_TAB_SUBPARTITIONS TO flink_user;
GRANT SELECT ON ALL_TAB_COLS TO flink_user;
GRANT SELECT ON ALL_ENABLED_COLS TO flink_user;
GRANT SELECT ON ALL_CONSTRAINTS TO flink_user;
GRANT SELECT ON ALL_CONS_COLUMNS TO flink_user;
GRANT SELECT ON ALL_INDEXES TO flink_user;
GRANT SELECT ON ALL_IND_COLUMNS TO flink_user;

注意，LOG_MODE是实例级参数，不能在PDB里单独设置。如果发现数据库没开归档，需要联系DBA处理，这一步不能跳过。

3.2 处理INTERVAL分区的动态扩展问题

确认完前置条件后，我把重点放在了分区表本身。既然报错是ORA-08103，最直接的怀疑对象就是INTERVAL分区自动扩展。

我当时做了一个验证：在业务低峰期手动禁掉INTERVAL，提前手工创建未来两个月的分区，然后再启动Flink CDC任务。结果全量快照稳定跑完，问题消失。这基本坐实了“分区动态扩展与快照分片冲突”的判断。

操作思路是这样：

sql复制-- 先复制当前表的INTERVAL定义
-- 然后禁用自动扩展
ALTER TABLE APP.ORDER_HIS SET INTERVAL ();

-- 手工创建未来两个月的分区
ALTER TABLE APP.ORDER_HIS
ADD PARTITION P_202503 VALUES LESS THAN (TO_DATE('2025-04-01', 'YYYY-MM-DD'))
UPDATE INDEXES;
ALTER TABLE APP.ORDER_HIS
ADD PARTITION P_202504 VALUES LESS THAN (TO_DATE('2025-05-01', 'YYYY-MM-DD'))
UPDATE INDEXES;

-- 启动Flink CDC任务，等待全量快照完成
-- 完成后恢复自动扩展
ALTER TABLE APP.ORDER_HIS
SET INTERVAL (NUMTOYSMINTERVAL(1, 'MONTH'));

这个做法有两个非常明显的好处：第一，全量快照窗口内分区元数据完全不变，增量快照可以放心切割chunk；第二，手工创建分区时可以顺手加上UPDATE INDEXES，避免局部索引在后续DML时状态异常。

如果业务上不允许停掉INTERVAL自动扩展，退而求其次的做法是让连接器只同步“存量分区”。但这要求Flink SQL里写死过滤条件，比如WHERE ORDER_DATE < TO_DATE('2025-03-01', 'YYYY-MM-DD')。这种方案适合一次性历史数据迁移，不适合长期实时同步。长期同步建议还是和DBA沟通好维护窗口。

3.3 调整快照分片参数，规避ORA-08103

环境问题处理完后，我开始思考另一个层面的优化：如果下次业务表的INTERVAL不能像这次一样好商量，怎么靠连接器参数降低风险。

Flink CDC 3.5.0的增量快照分片参数里，和分区表最相关的是scan.incremental.snapshot.chunk.size和scan.incremental.snapshot.chunk.key-column。

chunk.size默认值是8096，表示每个分片大约包含8096行。对于大分区表来说，这个值意味着分片数量很多，每个分片执行一次查询和回填。分片多不一定会出问题，但每个分片执行时间越长，期间遇到源库变化的概率越大。所以我把chunk.size从默认值调小到2000甚至1000，让单个分片快速执行完，缩短单次快照查询的SCN窗口：

sql复制'scan.incremental.snapshot.chunk.size' = '2000'

调小chunk.size后，全量阶段对Oracle的查询次数会变多，但每次时间更短，配合主键分片，对数据库的压力反而更平滑。

chunk.key-column针对的是无主键表。如果源表没有主键，增量快照无法自动确定分片列，就需要手动指定一个非空唯一列。这个列必须是数值或字符串类型，不能是LONG、CLOB、BLOB这类大字段。

如下配置可以放在Flink CDC source表的WITH参数里：

sql复制'scan.incremental.snapshot.chunk.key-column' = 'ORDER_ID'

这里有个经验供参考：如果分区表有主键，就不要额外指定chunk.key-column，否则可能和连接器内部的主键分片逻辑冲突。如果分区表确实没有主键，也不要随便选个普通列，必须用有唯一索引约束的列，否则数据一致性无法保证。

对分片键还有一种补充思路：如果分区键本身是日期，且业务上“只关心某个时间范围”，可以在Flink SQL层把分区字段转换为过滤条件下推到Oracle，比如：

sql复制WHERE ORDER_DATE >= TO_TIMESTAMP('2025-01-01 00:00:00')

这能让全量快照阶段提前裁剪数据量，规避“扫描全表但只需要最近分区”的性能浪费。注意Flink CDC对分区表本身不会做Oracle分区裁剪，它仍然读取整表所有分区，所以这种过滤条件只能减少下游数据量，不能减少源库扫描量。

3.4 优化增量日志挖掘配置，保障DDL场景稳定

全量阶段稳定后，增量阶段还要针对分区表特点做参数加固。Flink CDC 3.5.0的Oracle connector把Debezium的参数通过debezium.前缀透传，和分区表同步强相关的是debezium.log.mining.strategy。

online_catalog表示LogMiner在解析日志时直接查数据库数据字典，获取表结构信息；redo_log_catalog则把LogMiner所需的数据字典快照持久化到redo log中，不依赖数据库当前数据字典。

分区表场景下，如果业务侧经常做分区维护DDL，online_catalog可能因为数据字典变化导致解析不连续。我把任务配置改成了redo_log_catalog，实测对跨分区维护窗口的稳定性有帮助：

sql复制'debezium.log.mining.strategy' = 'redo_log_catalog'

另外几个增量侧参数我也一并调整了：

sql复制'debezium.log.mining.continuous.mine' = 'true',
'debezium.log.mining.batch.size.default' = '100000',
'debezium.log.mining.batch.size.max.default' = '200000',
'debezium.log.mining.sleep.time.ms' = '500',
'debezium.log.mining.inactivity.timeout.ms' = '120000'

这些参数的作用是增加每次LogMiner批量处理的redo记录数，降低频繁切换带来的SCN间隙，同时把空闲时等待时间控制在一个合理范围。对于高峰时段有大量分区DML写入的业务，适当调大batch size可以让增量解析更跟手。

如果任务长期跑在增量阶段，archive log的清理策略要和LogMiner的读取进度匹配。Flink CDC的source状态里会记录当前的SCN位置，如果archive log被提前删除，下游任务重启后可能找不到日志。建议在Oracle侧至少保留48小时以上的归档日志，视数据量而定。

3.5 可复用的Flink SQL建表与启动配置

经过上述调整，我最终落地的Flink SQL建表语句如下，可以直接作为参考模板：

sql复制CREATE TABLE source_order_his (
    ORDER_ID      DECIMAL(18, 0),
    ORDER_STATUS  STRING,
    AMOUNT        DECIMAL(12, 2),
    ORDER_DATE    TIMESTAMP(3),
    CREATE_TIME   TIMESTAMP(3),
    PRIMARY KEY (ORDER_ID) NOT ENFORCED
) WITH (
    'connector' = 'oracle-cdc',
    'hostname' = '10.10.10.10',
    'port' = '1521',
    'username' = 'flink_user',
    'password' = 'your_password',
    'database-name' = 'ORCLPDB1',
    'schema-name' = 'APP',
    'table-name' = 'ORDER_HIS',
    'scan.startup.mode' = 'initial',
    'scan.incremental.snapshot.chunk.size' = '2000',
    'debezium.log.mining.strategy' = 'redo_log_catalog',
    'debezium.log.mining.continuous.mine' = 'true',
    'debezium.log.mining.batch.size.default' = '100000',
    'debezium.log.mining.sleep.time.ms' = '500',
    'debezium.event.deserialization.failure.handling.mode' = 'warn'
);

几个需要注意的细节：

• database-name要填PDB名字，比如ORCLPDB1，而不是CDB的根库名。
• schema-name和table-name的大小写要和Oracle数据字典保持一致。Oracle默认是大写，如果建表时用了小写带引号，这里也要相应处理。
• scan.startup.mode用initial表示全量+增量，如果只做增量，可以改成latest-offset。
• debezium.event.deserialization.failure.handling.mode建议设为warn而不是默认的fail，避免遇到个别无法反序列化的事件直接中断整个任务。

启动方式我用的Flink SQL Client：

bash复制bin/flink-sql.sh -f sync_order_his.sql

如果是提交到Flink集群，可以打成SQL作业包，或者用Flink CDC的YAML作业方式提交。3.5.0版本对YAML作业的整库同步支持已经比较成熟，如果同步多张表，可以优先考虑YAML pipeline方式。

4. 分区表同步报错速查表与排查脚本

4.1 高频报错对照表

把这次踩坑和其他项目里遇到的Oracle分区表CDC问题放到一起，整理成了一张常见报错对照表：

这张表不一定能覆盖所有问题，但Oracle分区表CDC场景里的高频故障基本都在里面。遇到新问题建议按“先明确是快照阶段还是增量阶段，再进入对应参数排查”的思路来。

4.2 通过日志快速区分快照阶段与增量阶段

排障时第一步不是调参数，而是先判断作业到底死在哪个阶段。Flink CDC 3.5.0的日志里会有比较明显的阶段特征。

快照阶段的日志会出现类似：

text复制Starting Snapshotter
SnapshotSplitReader read chunk: [1] of table APP.ORDER_HIS

增量阶段的日志会出现：

text复制LogMiner is reading redo log
LogMiner is mining archived log thread:1 sequence:xxxxx

如果日志里频繁出现SnapshotSplitReader相关堆栈，那就是全量快照问题，优先查分区元数据稳定性和chunk参数。如果日志停在LogMiner相关位置，或者source端一直不更新，那就是增量阶段问题，优先查补充日志、权限和archive log。

在Flink的Web UI上也可以辅助判断。查看算子背压情况，如果Source算子背压很高而下游没有数据，大概率是源端查询卡住了；如果Source算子既不背压也无输出，可能是增量日志挖掘在等待新日志。

4.3 DBA视角的源库巡检SQL

分区表CDC同步几乎离不开DBA配合。建议在启动任务前，让DBA帮忙跑一遍下面的巡检脚本，确认源库处于健康状态：

sql复制-- 1. 检查归档模式和补充日志
SELECT LOG_MODE,
       SUPPLEMENTAL_LOG_DATA_MIN,
       SUPPLEMENTAL_LOG_DATA_ALL
FROM V$DATABASE;

-- 2. 检查最近归档日志是否连续
SELECT THREAD#, SEQUENCE#, FIRST_TIME, NEXT_TIME, STATUS
FROM V$ARCHIVED_LOG
WHERE STATUS = 'A'
ORDER BY THREAD#, SEQUENCE# DESC
FETCH FIRST 10 ROWS ONLY;

-- 3. 查看分区表当前分区情况
SELECT TABLE_OWNER, TABLE_NAME, PARTITION_NAME, HIGH_VALUE, NUM_ROWS
FROM ALL_TAB_PARTITIONS
WHERE TABLE_OWNER = 'APP'
  AND TABLE_NAME = 'ORDER_HIS'
ORDER BY PARTITION_NAME;

-- 4. 检查UNDO保留时间
SHOW PARAMETER UNDO_RETENTION;

-- 5. 查看归档空间使用率
SELECT NAME, ROUND(SPACE_LIMIT/1024/1024/1024, 2) AS SPACE_GB,
       ROUND(SPACE_USED/1024/1024/1024, 2) AS USED_GB
FROM V$RECOVERY_FILE_DEST;

巡检脚本跑完，基本能排除数据库侧的隐患。如果归档空间使用率超过80%，建议先清理历史归档，或者扩容快速恢复区，再启动Flink CDC任务。

5. 大分区表同步的后续优化建议

5.1 全量快照吞吐与并行度取舍

Flink CDC 3.5.0支持并行快照，并行度过高不一定是好事。Oracle数据库对并发查询有自身限制，尤其分区表在执行全表扫描时，优化器可能并行触发多个分区段的I/O。如果Flink侧再同时发起大量chunk查询，很容易把数据库的I/O打满。

经验值是把source的并行度控制在4到8之间。如果表特别大，可以适当增加到12，但需要和DBA确认数据库资源水位。分区表全量同步耗时，本质上取决于数据量和网络带宽，不会因为并行度翻倍就时间减半。更合理的做法是先小并行度跑通，再逐步提升。

5.2 增量阶段关于commit频率与LogMiner参数的配合

增量阶段一个容易被忽略的问题是业务侧的大事务。LogMiner只能在事务提交后读到变更记录，如果业务表上有超大事务长时间不提交，下游看到的延迟会持续增长，而且很难通过Flink参数解决。

分区表场景尤其要注意批量UPDATE或批量INSERT。比如业务侧在夜间做数据订正，一个事务更新几百万行，Oracle会生成大量redo，但LogMiner必须等到commit后才能解析。建议在业务侧把这类批量操作拆成小事务，比如每1万行提交一次。这个改动对Flink CDC同步的稳定性提升非常明显。

LogMiner相关参数和业务DML频率的配合，建议这样设置：普通在线业务，batch.size.default保持50000到100000即可；夜间批量业务高峰，可以临时调大到300000，但要注意TaskManager内存和CPU开销。

5.3 从“一次性修复”走向常态化监控

Flink CDC同步Oracle分区表并不是配置完就结束了。分区表天然有动态变化的属性，如果业务侧每个月都在做分区维护，那么每次维护窗口都可能触发同步异常。

我的建议是至少做三件事：

第一，监控Source端的SCN进度。可以通过Flink的Checkpoint状态或者日志中的LogMiner sequence号判断增量解析是否在正常推进。如果SCN长时间不前进，优先排查源库归档日志状态和权限。

第二，监控Oracle的补充日志与归档空间。这两项是CDC同步的命脉，任何一项被关闭或写满，下游数据都会断流。

第三，把分区维护操作纳入变更通知。在业务侧每次执行TRUNCATE/SPLIT/MERGE/DROP PARTITION前，提前通知实时同步负责人，必要时先在Flink侧暂停任务，等分区维护完成后再恢复。

这次用Flink CDC Oracle Connector 3.5.0同步Oracle分区表，整个过程不算顺利，但也让我把分区表在CDC场景下的几个关键卡点彻底搞明白了。后续如果再遇到类似的报错，我不会再盲目重启任务，而是先确认分区元数据是否稳定、分片参数是否合理、LogMiner配置是否到位。如果你现在正被同样的问题卡住，建议按文中的顺序从源库巡检开始排查，大概率能找到突破点。