4、风险评估与迁移策略选择
朋友们，系统迁移最怕什么？不是技术难，是心里没底。
你想想看，一套审计系统用了好几年，数据、流程、权限都盘根错节。直接硬迁？那叫赌博。我们得先做个体检，把风险摸清楚，再选个合适的策略。
说白了，这就是本章要聊的核心：怎么通过风险评估，来决定用全量、增量还是混合迁移。
4.1 风险从哪来？先摸清家底
做风险评估之前，你得先回答三个问题：
- 数据有多大？ 别光看数据库文件大小，得算上索引、日志、临时表空间。
- 业务能不能停？ 审计系统虽然不像交易系统那么敏感，但年底决算期间你敢停吗？
- 技术债有多深？ 老系统里的存储过程、触发器、自定义函数，这些才是真正的“定时炸弹”。
数据摸底清单（建议整理成表格）
| 检查项 | 风险等级 | 影响策略 |
|---|---|---|
| 总数据量 > 1TB | 高 | 不建议全量直接复制 |
| 存在超过100个存储过程 | 中 | 需要充分测试兼容性 |
| 业务7×24小时使用 | 高 | 必须选择增量或混合策略 |
| 历史归档数据占比较大 | 低 | 可以采用分批迁移 |
我个人习惯，先把这些信息收集全，然后在会议室白板上画个大表格。大家一看就明白，风险点在哪，重点该盯哪。
4.2 三大迁移策略，选哪个？
先看定义，再看选型。三种策略各有各的脾气。
| 策略 | 核心做法 | 优点 | 缺点 |
|---|---|---|---|
| 全量迁移 | 一次性把所有数据、配置、应用全部搬到新系统。 | 逻辑简单，容易回滚，适合小数据量。 | 窗口长，停机影响大。数据量大时不现实。 |
| 增量迁移 | 先做一次全量基座，然后持续同步变更数据。 | 停机时间短，业务影响小。 | 需要搭建数据同步链路，技术复杂度高。 |
| 混合迁移 | 结合两者，核心库全量，历史库分批增量。 | 灵活，平衡风险与效率。 | 管理复杂，需要前置规划好分片策略。 |
你可能会问，怎么判断该用哪个？我通常按这个原则来：
- 数据 < 500GB，停机窗口 > 8小时：直接全量。别折腾，干就完了。
- 数据 500GB ~ 5TB，允许少量停机：增量迁移。先全量做个基座，再用日志解析或触发器同步增量。
- 数据 > 5TB，或业务不允许长时间停机：混合迁移。核心表走增量，历史表走全量。关键是做好分片和校验。
我的经验：不要迷信技术文档里的理论值。我之前遇到一个项目，理论上数据只有800GB，结果上线前发现归档日志占了400GB。嗯，全量策略直接报废，临时改成增量方案。所以，摸清总量和增量变化率，比什么都重要。
4.3 避坑指南：混合策略的“坑”
混合迁移听起来挺美，但你别以为就是“全量+增量”这么简单。这里面有几个关键点，搞不好就翻车。
坑一：数据一致性校验怎么搞？
全量搬过去了，增量在同步，你怎么知道两边一模一样？我曾经踩过一个坑——同步了三天，最后发现一张配置表的主键冲突，导致业务大面积报错。
解决办法：
- 对核心表，用
checksum或count(*)做分块比对。 - 每同步一轮，就做一次快照校验。
- 不能只依赖数据库的同步工具，必须要有业务层面的对账脚本。
坑二：全量迁移时产生的增量数据怎么处理？
你全量迁移跑着跑着，业务还在写数据。等你全量跑完，这些新数据已经存在了。你再做增量同步时，容易重复或者漏掉。
我建议：
- 全量迁移前，记录一个准确的“时间戳”或“SCN号”。
- 增量同步的起始位置，就从这个点开始。
- 全量迁移过程中，对业务表加一个“迁移标记”，但别锁表，否则业务方会骂人。
-- 示例：记录全量迁移的起始 SCN
SELECT CURRENT_SCN FROM V$DATABASE;
-- 然后在增量解析时，只拉取 >= 该 SCN 的日志
-- 这样全量期间产生的数据就不会丢，也不会重复
重要警告：不要忽视网络带宽
很多团队迁移失败，不是因为技术选型不对，而是网络撑不住。尤其是全量迁移，动辄几百GB甚至TB级的数据，千兆网络极限也就100MB/s，你算算理论时间。我见过一个案例，迁了8小时没跑完，最后发现交换机端口协商到了百兆……
所以，迁移前务必：
- 做一次带宽压测（就用
iperf这类工具）。 - 留出20%的冗余，别把带宽跑满。
- 实在不行，就用硬盘快递（物理迁移），别觉得老土，有时候最快。
4.4 制定你的风险评估矩阵
好了，现在你会摸底了，也知道三种策略的脾性了。怎么做出最终选择？我建议你把风险量化。
我习惯用这么一个矩阵：
| 影响因素 | 分数权重 | 低风险 (1分) | 中风险 (2分) | 高风险 (3分) |
|---|---|---|---|---|
| 总数据量 | 30% | < 200GB | 200GB ~ 2TB | > 2TB |
| 数据峰值变化率 | 20% | < 1%/天 | 1% ~ 5%/天 | > 5%/天 |
| 允许停机时间 | 30% | > 12小时 | 4 ~ 12小时 | < 4小时 |
| 系统复杂度 | 20% | 单应用，无依赖 | 少量依赖，接口明确 | 多系统耦合，有定制开发 |
算出总分后，对照这个判断：
- <= 1.5分：放心全量迁移。
- 1.5 ~ 2.5分：考虑增量或混合，需要进一步分析压力点。
- > 2.5分：强烈建议混合策略，且要有完善的回滚预案。
说到底，没有完美的策略，只有最合适的策略。关键是你要搞清楚风险在哪里，然后做取舍。别想着一步到位，系统迁移本身就是一门权衡的艺术。