现网使用 OceanBase 迁移服务（OMS）将 Oracle RAC 实时同步到 OceanBase 集群（租户 t_oracle），链路中包含全量迁移和增量同步。某天源端 Oracle 执行了一个大批量 DELETE误删了 300 万行数据，在发现时增量同步已经将删除操作同步到了 OceanBase，且 OMS 链路仍在运行。此外，OMS 也因大事务出现了短暂的延迟和位点回溯, 不重新执行全量同步，利用 OceanBase 的 闪回查询或 回收站功能将目的端恢复到误删前一刻的一致状态，并保证在恢复后 OMS 链路的增量续接不中断、不丢数据, 如果 OMS 已经将后续事务与误删操作混合在一个分区上，如何利用 OceanBase 的 闪回表/闪回租户和时间戳精确恢复，并重新修正 OMS 位点
3 个赞
一：确定误删时间点 T
在源端 Oracle 查询误删 DELETE 事务的提交时间：
– 通过 LogMiner 或闪回查询视图获取
SELECT VERSIONS_STARTTIME, VERSIONS_ENDTIME,
FROM orders VERSIONS BETWEEN TIMESTAMP …;
最终锁定一个精确到秒或毫秒的时间戳，例如 2025-06-05 02:30:00。
暂停 OMS 增量同步链路
在 OMS 控制台暂停该数据迁移任务，确保暂停后 OB 端不会继续写入，为闪回提供静止环境。
二、源端 Oracle 数据恢复（不可缺少）
OB 端闪回后，如果源端误删数据未恢复，重启同步后 DELETE 会再次同步。源端可采用：
闪回表（最优）：如果表 DDL 变化不大且闪回日志充足：
FLASHBACK TABLE orders TO TIMESTAMP TO_TIMESTAMP(‘2025-06-05 02:29:55’, ‘YYYY-MM-DD HH24:MI:SS’);
闪回查询 + 插入：如果闪回表不可行，创建临时表补回数据：
INSERT INTO orders SELECT * FROM orders AS OF TIMESTAMP TO_TIMESTAMP(…) WHERE …;
COMMIT;
此时源端和目的端目标状态一致：都应该是 T 之前的状态。
三、目的端 OceanBase 精确闪回
根据误删影响的表和关联关系，选择闪回表或闪回租户。
FLASHBACK TABLE orders TO TIMESTAMP TO_TIMESTAMP(‘2025-06-05 02:29:55’, ‘YYYY-MM-DD HH24:MI:SS’);
要求对应租户的 undo_retention 足够大，闪回日志未被回收。
如果有外键约束，可能需要先禁用或闪回相关表。
执行前需确保该时间点后无 DDL 变更，否则闪回会失败。
四、修正 OMS 增量位点
闪回后，OB 端的数据版本已经回到 T 之前，但 OMS 的 Store 组件记录的 checkpoit 已经大于 T，直接启动会从错误位点开始，导致数据冲突或丢失。必须将位点回退到 T 或 T 之前的一小段时间。
查看当前 OMS 位点信息
在 OMS 控制台 → 迁移项目 → 组件监控，找到 Store 组件的 当前位点时间戳（即已同步的 source 端时间）。或者直接查询 OMS 元数据库的 store_checkpoint 表。
重置位点到 T 之前
OMS 提供位点回溯功能：在链路高级选项中，选择“重置位点”，输入希望重新拉取的起始时间戳 2025-06-05 02:29:50。
如果没有 GUI 入口，可通过 OMS 内部 API 或元数据库修改：
– 仅在 OMS 元数据库执行（需谨慎）
UPDATE oms_store_checkpoint
SET checkpoint_timestamp = ‘2025-06-05 02:29:50’
WHERE task_id = ‘<your_task_id>’;
校验位点
重置后，确认新位点早于误删开始时间，覆盖整个需要重放的范围。
五、启动同步与验证
启动 OMS 链路
恢复暂停的同步组件，Store 会从新的位点开始重新解析源端 Redo/Archive Log，将该时间点之后的所有事务（包括误删前那些被闪回消除的 DELETE）重新投递到 OB 端。
数据一致性验证
对关键表进行行数、checksum 对比。
检查 OB 端是否存在误删数据（应该恢复）。
在源端插入一条测试数据，验证能否正常同步到 OB。
监控 OMS 延迟
重新同步初期会有追赶延迟，确认 RT 逐步降低并最终稳定在秒级。
六、原理说明与注意事项
为什么闪回后必须重置位点：OB 闪回只改变了数据状态，不会影响 OMS 已记录的消费位点。若位点不回退，OMS 认为 T 之后的事务已经同步完毕，就不会再重放，导致 OB 端丢失 T 之后的所有正常事务（因为闪回把它们也抹掉了）。
混合分区下的特殊处理：当后续事务与误删操作发生在同一个分区上时，该分区的增量日志是混合的。闪回表/租户可以直接将该分区的所有修改（包括误删和后续事务）一并回滚到时间点，然后通过 OMS 位点重置，精确地将 T 之后的事务重新有序重放，完美恢复数据。
回收站备选：如果只是表被误删（DROP），可通过 FLASHBACK TABLE orders FROM RECYCLEBIN; 恢复，但本题是 DELETE，必须用闪回时间戳。
闪回窗口：整个过程要求 OceanBase 的 undo_retention 足够长（例如 86400 秒），以保证 T 时刻的 undo 日志未被清理。可通过 ALTER SYSTEM SET undo_retention=86400; 提前设定。
不丢数据的保证：源端闪回 + OB 闪回 + 位点回溯，两端状态对齐且重放有序，理论上不会丢任何一笔 T 之后的正常事务。
4 个赞
感谢老师的思路讲解