Oracle 到达梦迁移评估：先量数据，再谈方案

迁移项目启动会上，第一个被问的通常是“用哪个工具迁”。这个问题问早了。

真正决定方案形态的是数据量和增长曲线，不是工具。同样一套 PACS 库，20 GB 和 2 TB 的迁移路径完全不同：前者一个周末就能切，后者要停机窗口、增量同步、甚至分批切换。

第一步：把数据量算准

不要用“大概几个 G”来估。至少要拿到三个数：

• 各表当前行数与占用空间（按段统计，不是按文件大小）
• 近 12 个月每月增量
• 大字段（LOB）单独占比

Oracle 里可以直接查：

SELECT segment_name,
       segment_type,
       ROUND(SUM(bytes) / 1024 / 1024 / 1024, 2) AS size_gb
FROM   user_segments
GROUP  BY segment_name, segment_type
ORDER  BY SUM(bytes) DESC
FETCH FIRST 30 ROWS ONLY;

注意 user_segments 只统计当前用户的段。如果要看全库，换成 dba_segments 并按 owner 分组。

第二步：分清“数据”和“垃圾数据”

这一步经常被跳过，但收益最大。

我见过一个库，2 TB 里有 1.4 TB 是已经作废的检查报告和重复的影像日志。这些数据在新系统里根本不需要迁。

处理顺序建议：

1. 先和业务方确认保留期限，把过期数据归档到冷存储
2. 再确认哪些是中间表、临时表，可以直接不迁
3. 最后才计算真正要迁的体积

结论：迁移前做一次数据治理，往往能把迁移量压掉一半以上。这比优化迁移工具有效得多。

第三步：看兼容性，别只看语法

语法兼容只是第一层。真正会在上线后出问题的是这几类：

• 隐式类型转换：Oracle 里 '123' = 123 能跑，达梦不一定
• 空字符串与 NULL：Oracle 把 '' 当 NULL，这个差异会直接影响 IS NULL 的查询结果
• 分页写法：ROWNUM、FETCH FIRST、LIMIT 的支持程度不同
• 函数行为：日期格式化、LISTAGG、分析函数的边界情况
• 执行计划：同样的 SQL 在两边可能走完全不同的索引

建议做一张兼容性清单，把每一条都在测试库上跑一遍，记录实际结果，而不是查文档推断。

第四步：算停机窗口

这一步最容易被低估。

按“全量 + 增量”的模式，停机时间大致等于：

• 最后一次增量同步的追平时间
• 加上数据校验时间
• 加上回滚预案的验证时间

第三项经常被算成零，实际上必须有。切换到一半发现问题要回退，没有回滚方案就只能硬着头皮往下走。

---

小结

评估报告的骨架应该是这样：

1. 数据量现状与增长预测
2. 治理后可迁移的实际体积
3. 兼容性清单与改造工作量
4. 迁移模式（全量 / 全量+增量 / 分批）
5. 停机窗口测算与回滚方案
6. 资源需求（CPU、内存、磁盘 IO）

工具选型放在最后一节写，因为它取决于前五节的结论，而不是反过来。