生产环境 Oracle 替换为 OceanBase 实战指南：OMS 反向增量回滚保障全解析
摘要：本文记录了一次真实的生产环境 Oracle 替换为 OceanBase 数据库的完整迁移方案。重点解析 OMS 反向增量（Reverse Incremental）作为回滚保障机制的工作原理、先决条件、隐藏列风险、停服迁移配置要点，以及正向切换的全流程操作。适合准备进行类似迁移的 DBA 和架构师参考。
一、业务场景与迁移策略
1.1 我们的场景
- 源库：Oracle 19C，承载核心业务数据
- 目标库：OceanBase Oracle 模式租户
- 迁移方式：停服迁移（在停服窗口内完成切换）
- 回滚保障：OMS 反向增量，确保 OB 出问题时可回退至 Oracle
- 同步频率：正向切换后每日同步一次，稳定运行 3~6 个月后降至每周一次
1.2 为什么不是实时同步？
我们的场景是停服迁移，不需要 7×24 实时同步。反向增量的定位是"回滚保险"而非"实时数据通道"：
| 阶段 | 频率 | 回滚丢失量 | 说明 |
|---|---|---|---|
| 正向切换后 0~3 个月 | 每日一次 | 最多 1 天 | OB 初上线，稳定性待观察 |
| 稳定运行 3~6 个月后 | 每周一次 | 最多 1 周 | OB 已稳定，团队运维成熟 |
| 长期稳定后 | 按需或停止 | - | 完全信任 OB，回滚需求极低 |
二、OMS 迁移类型概览
在 OMS 中创建迁移任务时，需要勾选以下迁移类型（同一个任务中一次性全部勾选）：
| 迁移类型 | 作用 | 是否必须 |
|---|---|---|
| 结构迁移 | 迁移表、索引、约束、视图等对象定义 | 是 |
| 全量迁移 | 迁移存量数据 | 是 |
| 增量同步 | 同步数据变更（INSERT/UPDATE/DELETE） | 是 |
| 全量校验 | 对比源端和目标端数据一致性 | 是 |
| 反向增量 | 正向切换后 OB 变更回流至 Oracle | 是（回滚保障） |
2.1 增量同步为什么必须勾选？
即使停服迁移也必须勾选增量同步，原因有三：
- 反向增量的前置依赖：反向增量复用增量同步的 DML 配置和组件，不勾选增量同步则无法启用反向增量
- 全量校验的前置条件：全量校验需要增量同步追平后才能发起
- 数据完整性兜底：停服窗口内仍可能有"尾巴"数据，增量同步确保真正的一致性
不停服 vs 停服场景的区别：两者都必须勾选增量同步，但同步频率不同——不停服场景按秒级实时追平，停服场景按需配置为每日/每周。
三、先决条件：表必须有唯一键
3.1 硬性要求
OMS 要求参与迁移的表必须具备唯一标识能力：
- 有主键表：存在 Primary Key 或 NOT NULL Unique Key（不含 function-based UK）
- 无主键表：OMS 通过在目标端（OB）新增隐藏列进行迁移
3.2 正向切换后隐藏列被删除：无主键表的风险
这是迁移中极易被忽视的一个坑。流程如下：
① 结构迁移：Oracle 无主键表 → OB
OMS 在 OB 端自动添加隐藏列 + 唯一索引
② 正向切换：OMS 自动删除隐藏列和唯一索引
OB 表恢复到"无唯一键"状态
③ 反向增量（OB→Oracle）时：
OMS 无法定位行 → UPDATE/DELETE 全表扫描 → 性能极差 + 数据质量风险
④ 回滚：停止反向增量，应用切回 Oracle，最大丢失一个同步周期
正向切换时 OMS 会自动删除隐藏列和唯一索引。如果原 Oracle 表本来就没有主键，切换后 OB 表也没有唯一键，反向增量就无法正常工作了。
3.3 解决方案
最佳实践：迁移前审查所有表，为无主键表执行：
ALTER TABLE table_name ADD PRIMARY KEY (column_name);
如果确实无法添加主键：
- 反向增量性能会受严重影响（全表扫描定位行）
- 建议反向增量期间避免对无主键表做大批量 UPDATE/DELETE
- 无主键且包含 LOB 类型字段的表，反向增量会出现数据质量问题
3.4 隐藏列加在哪里？
只在目标端（OB）添加，源库 Oracle 完全不受影响。
OB Oracle 模式下添加的隐藏列包括：
OBS_OBJECT_NUMBER -- 对象编号
OBS_RELATIVE_FNO -- 相对文件号
OBS_BLOCK_NUMBER -- 块编号
OBS_ROW_NUMBER -- 行号
+ 唯一索引 UK_<table>_OMS_ROWID
四、反向增量的工作原理
4.1 OMS 如何反向同步？
反向增量（OB → Oracle）的工作流程：
① Store 组件拉取 OB 增量日志（Clog）
② 解析 DML 变更，提取变更前后的行数据
③ JDBCWriter 根据唯一键（PK/UK）定位 Oracle 中的对应行
④ 执行 UPDATE/DELETE/INSERT 写入 Oracle
核心依赖：反向同步的每一步都依赖"按唯一键定位行"。没有唯一键就无法精确定位，只能退化为全表扫描，性能和数据一致性都无法保障。
4.2 完整的数据流向
Oracle（源库） ←──── 反向增量（回滚保障，按日频率） ←──── OceanBase（目标库/业务主库）
↑ |
└──────── 正向同步（全量迁移 + 增量同步） ───────────────────┘
- 正向：Oracle → OB（全量迁移 + 增量同步）
- 反向：OB → Oracle（回滚保障，按日/周频率）
4.3 不支持反向增量的场景
以下情况不支持配置反向增量，需要提前规避：
- 多表汇聚（多个源表同步到一个目标表）
- Schema 多到一映射
- 容灾双活场景（自动处理，无需手动配置）
- 表中全部列均为 LOB 类型（BLOB/CLOB/NCLOB）
- Oracle 执行
UPDATE TABLE_NAME SET KEY = KEY + 1（KEY 为主键）
五、创建迁移任务的完整步骤
5.1 源端和目标端环境准备
Oracle 源端：
- 开启 archivelog，确保已切换过 logfile
- 安装 LogMiner 工具
- 归档日志至少保存 7 天（全量 + 增量场景）
- 创建迁移用户并授权：
SESSION、ALTER SESSION、SELECT ANY TABLE、SELECT ANY DICTIONARY - 如需行过滤（非 PK/UK 列），开启补充日志：
ALTER TABLE table_name ADD SUPPLEMENTAL LOG DATA (ALL) COLUMNS;
OceanBase 目标端：
- 提前创建对应的 Schema
- 创建迁移用户并授权：
CONNECT、CREATE SESSION、SELECT ANY TABLE、CREATE ANY TABLE、CREATE ANY INDEX、INSERT ANY TABLE、UPDATE ANY TABLE、DELETE ANY TABLE - 创建内部用户：
CREATE USER __OCEANBASE_INNER_DRC_USER;
GRANT ALL PRIVILEGES TO __OCEANBASE_INNER_DRC_USER;
- OMS 中配置所属 OCP，否则增量同步和反向增量选项无法选择
5.2 创建迁移任务的五个步骤
步骤 1：登录 OMS 控制台 → 数据迁移 → 新建迁移任务
步骤 2：选择源端 Oracle 数据源和目标端 OB Oracle 数据源，配置任务名称
步骤 3：选择迁移类型（关键步骤）
- 「增量同步」必须勾选：反向增量的前置依赖
- 「反向增量」必须勾选：回滚保障机制
- 其他类型按需勾选
步骤 4：选择迁移对象（指定对象或匹配规则），支持列映射、行过滤、库表重命名
步骤 5：配置迁移选项，执行预检查，全部通过后启动任务
六、正向切换六步流程
正向切换是在停服窗口内完成的业务割接操作，包含六个步骤：
| 步骤 | 操作 | 说明 |
|---|---|---|
| 1 | 启动目标端 Store | OMS 自动拉取 OB 增量日志，预计 3~5 分钟 |
| 2 | 确认源端停写 | DBA 确认业务应用已停止写入 Oracle |
| 3 | 确认同步追平停写位点 | OMS 自动检查延迟，确认增量已追平 |
| 4 | 停止正向同步 | 停止 Oracle → OB 的写入 |
| 5 | 执行数据库对象处理 | 补充约束、禁用源端触发器/外键 |
| 6 | 启动反向同步 | OB 变更按每日频率回流至 Oracle，Oracle 成为"冷备" |
注意：正向切换流程进行时整个迁移任务不可暂停。切换前确保 Oracle 已停写，应用已切换到 OB。
七、同步频率调整策略
正向切换后，建议按以下策略逐步降低同步频率：
第一阶段（0~3 个月）：每日同步
- 反向增量和正向增量均按每日频率运行
- 最大回滚数据丢失量：1 天
- 适用：OB 初上线，稳定性待验证
第二阶段（3~6 个月后）：每周同步
- 反向增量频率降至每周
- 最大回滚数据丢失量：1 周
- 适用：OB 稳定运行，团队运维成熟
第三阶段（长期稳定）：按需或停止
- OB 完全稳定后可停止反向增量
- 或改为按需手动同步
- 适用：OB 成为核心生产库，回滚需求极低
降频决策依据：OB 稳定运行时长 + 团队运维成熟度 + 业务容忍的数据丢失量。建议每季度评估一次。
八、常见问题 FAQ
Q1：OB 稳定后反向增量可以停吗？
可以停，但建议保留一段时间作为保险。停掉前确保 OB 已稳定运行 3~6 个月，且团队已完全适配 OB 运维。
Q2：无主键表怎么迁移？
强烈建议迁移前
ALTER TABLE ADD PRIMARY KEY。如果确实无法添加，OMS 会使用隐藏列方案，但正向切换后隐藏列被删除，反向增量时会退化为全表扫描，性能和数据质量都有风险。
Q3：延迟时间显示不准确怎么办？
检查服务器时钟同步。节点间时钟不同步可能导致延迟显示为负数。
Q4：字符集不一致怎么办？
建议两端使用兼容字符集（UTF-8/UTF-16）。反向增量时可能出现数据超长无法写回源端的问题。
Q5：停服迁移也需要增量同步吗？
必须勾选。即使停服，增量同步也是反向增量的前置依赖，同时负责追平停服窗口内的"尾巴"数据。
九、最佳实践清单
- 迁移前统一为所有表添加主键，避免正向切换后反向增量出问题
- 创建任务时必须勾选：结构迁移 + 全量迁移 + 增量同步 + 全量校验 + 反向增量
- 割接前充分测试反向增量，验证按日频率同步的数据一致性
- Oracle 归档日志至少保留 7 天
- 停服窗口内执行正向切换，切换后持续监控每日同步状态
- OB 稳定 3~6 个月后反向增量可降频至每周，建议每季度评估
- 回滚操作：OB 出问题 → 停止反向增量 → 应用切回 Oracle → 最大丢失一个同步周期
十、总结
本次生产环境 Oracle 替换为 OceanBase 的迁移方案核心要点：
| 要点 | 说明 |
|---|---|
| 迁移方式 | 停服窗口内完成 |
| 回滚保障 | OMS 反向增量，按日/周频率同步 |
| 核心前提 | 所有表必须有主键 |
| 增量同步 | 停服也必须勾选，是反向增量的前置依赖 |
| 正向切换 | 停服窗口内执行，自动启动反向增量 |
| 频率策略 | 每日 → 每周 → 按需/停止，逐步降频 |
核心公式：反向增量 = 回滚保险丝。一次配置，按频率自动运行，出问题随时切回 Oracle。
📎 配套资料下载
- PPT 演示文稿：点击下载（含完整图文操作流程）
适合团队内部培训、会议汇报使用
汇聚全球AI编程工具，助力开发者即刻编程。
更多推荐
11
0- 0
已为社区贡献7条内容
所有评论(0)