从ORACLE迁移到信创数据库后的应急预案？
对于一些大企业的数据库从传统的oracle迁移到信创。很多时候会存在一种顾虑。就是长久的性能和可靠性，比如在迁移到了信创数据库，在短时间内的性能指标和功能都满足了需求。但有些业务可能是周期性的。有些问题也可能是累积后出现的。这种情况可能会导致割接一段时间后数据库出现问题。对于这样的顾虑和可能发生的风险。有那些应急预案呢?
3同行回答
一般涉及到关键业务系统的数据库信创迁移都会提前做迁移演练以及逃生机制的这种至少要分三走：
1. 从架构上做调整：做双活两地三中心容灾，数据库同城双活，所有机器都提供服务，应用读写分离，两个机房独立访问，互不影响；实现双库并跑的逃生机制，可以一主拖两备
2. 用一库多芯，混部灰度的方式，实现稳妥的信创替换，第一阶段先信创验证，单独分一个集群放纯信创芯片和OS，确保可在平稳运行符合预期，第二阶段再把信创软硬件放到主集群里，实现灰度混合部署，实现完整集群的全栈信创
3.最后，如韩老师提的，用双写机制把逃生集群和全栈信创集群并跑，且要并跑一段时间，各项业务跑稳定后再撤掉把逃生集群，淘换下来的挪到其他地方再利旧
上线是需要制定应急预案，出现问题要把数据倒刷回去紧急回退，对于已经上线并运行一段时间出现问题想回退，需要满足两个条件。第一应用支持两种不同数据库，支持oracle和国产数据库，并且应用两套代码都支持同步开发，可以更改配置数据源后能切换数据库。第二，两个数据库间数据准实时同步。
收起- 理论上是这样。可是有些老业务因为年代久远，缺少技术支撑，信创更新是基于业务的全新开发，在这种情况下。可能很难做到两套代码的同步，甚至有不少案例都是硬着头皮在没有应急预案的情况下进行的割接升级，跟新到信创数据库之后如果一段时间后出现了问题。老旧的业务应用和数据库可能因为缺少技术支持和原始资料而无法做到紧急回退。这种情况请问有什么更好的办法避免吗？
- 这个不是理论上的，我们银行2019年上线的新核心就是采用该方案并且同步运行了一年，当时投入了很多资源，包括应用厂商，数据库厂商以及我们行方。要做到运行一段时间后还能回退，目前我们就是这么做的。不过现在三年过去了，都在成熟，只要做好充分测试，不需要应急回退的了，也不现实，成本太高了。
- 还有一种思路是上线前在信创环境导入真实业务流量，充分验证功能及性能。老系统按照现有节奏进行监管升级，验证期间新环境可以不升级新功能，只在验证流程完毕后追平功能。