测验：数据迁移与校验
为什么数据迁移应从项目初期起作为独立工作流管理？
- 迁移中发现的数据问题可能要求修改架构设计或业务规则
- 迁移工作量很大，需要提前分配人员
- 迁移计划和结果确认书属于监理交付物
- 购买和引入商业迁移工具许可证耗时很长
迁移演练最重要的产出是什么？
- 演练迁移的数据本身——正式迁移时可以直接使用
- 记录参与者和职责的名单——正式迁移时按同样配置投入
- 迁移脚本源码——经过演练打磨后的最终版本
- 实测耗时——让迁移时间线建立在测量而非估算之上
为什么 AS-IS → TO-BE 映射定义中的“未映射时如何处理”一列尤其重要？
- 只有填满映射表所有列才能进入评审
- 若未规定，开发者会自行处理，差异最终会表现为“数量对不上”
- 存在未映射值会导致加载失败，使整个迁移停止
- 未映射处理方式会显著影响转换逻辑速度
迁移验证中行数和合计值都一致，为什么仍需比较校验和？
- 校验和一次即可计算，比行数和合计验证快得多
- 为了发现一条遗漏、另一条重复，却使行数和合计恰好一致的情况
- 因为规范明确要求迁移验证必须比对校验和
- 计算校验和时还能同时检查索引是否损坏
制定旧数据去重规则（保留哪条记录）时，正确做法是什么？
- 与业务负责人达成一致，因为最新记录有时反而不完整
- 始终保留最新修改的记录才是技术上正确的做法
- 保留内容更长的记录
- 随机选择一条
迁移过程中发生问题时，正确的恢复措施优先级是什么？
- 立即从备份恢复数据
- 先回滚架构，再根据情况处理其余问题
- 继续迁移，同时并行解决问题
- 关闭功能开关 → 切回流量 → 回滚架构 → 最后恢复数据
在迁移结果确认书中附上“排除记录清单”，能获得什么实际收益？
- 上线后收到“数据不见了”的询问时，可以立即说明原因和重新迁移计划
- 排除原因形成文档，交付物评审时能得到更高评价
- 提前过滤排除对象，可缩短正式迁移处理时间
- 减少未迁移的数据后，备份对象更少，节省保存容量