风险控制方面考虑，例如白名单灰度迁移，回退方案等？
迁移过程中风险必须是可控的，由于是对于重要在线业务系统，一方面要确保业务系统尽可能短暂的影响，又要确保出现问题能够快速应对或者回退，该问题难点在于涉及数据库的切换，如果只涉及应用，那么可以通过灰度发布实现，出现问题也可以及时回退，而数据库的迁移是否可以借鉴类似的思路去实现白名单灰度迁移，出现问题快速回退，整个过程中ORACLE和国产数据库之间的数据如何处理？
2同行回答
谢邀！从我们的经验看，灰度迁移是个危险的想法，哈哈！真的，容易把数据搞脏掉，不建议这样做。虽然整体数据迁移，风险高，但是容易保持数据一致性。一旦失败后，可以追日志来找到数据一致点。至于您担心的事情，我个人的意见是：
1，提前把国产数据的环境搭好，小库要提前两周，大库要提前一个月；
2，在生产上，切换投产窗口前提前做几轮的迁移测试。比如9月1日迁移，在8月中旬和下旬各做两轮的迁移，在生产上做的话，注意窗口，以防对现有系统造成影响。可以选择深夜交易低谷进行。
3，每轮迁移完成后，对数据进行校验和比对。
目前我们接触到的国产数据库厂商暂时还做不到同时双向同步，即同一个表内的数据Oracle的变更向国产写，同时国产的变更向Oracle写。但是目前都实现了单向同步， Oracle的变更向国产写没问题， 切换之后国产的变更向Oracle回写也没有问题。针对快速回切，实践中我们会用这两种方式：
1、针对核心系统，切换后开启反向实时同步。上线前准备好回切方案，数据库部分主要是涉及序列的变更和数据校验脚本。数据库切换之后立刻开启反向回退，保障国产数据库内的变更可以准实时的写回原Oracle数据库。由于中间件切换异构数据库的数据源需要重启，所以切换后老应用的中间件数据源不调整，仅从F5中摘掉，需要回切时候完成数据库切换动作后直接把老应用挂回F5。
2、针对可自行稽核并补录数据的系统，我们是直接在新环境搭建新库并按照业务团队的要求导入某一时间的数据，业务切换后数据库层不提供数据实时同步服务，直接将Oracle数据库的表空间设为只读避免流量没有切干净。
