如果数据库较大，全量迁移时间较长，如何尽可能缩短停机窗口？

总结来说，是异构数据库间迁移的问题
1.提供常规的全量及增量数据迁移能力，这对于有效缩短时间窗口有益。目前已有很多厂商提供此类能力。但需要注意的是，从集中式架构到分布式架构还可以；反之仍有一定局限。
2.提供全量及增量数据对比能力，满足对数据一致性的检验能力，这对于实施切换是重要参考依据。此外包括差异数据的正向、反向的补偿能力，也是需要的。
3.由业务逻辑方面提供一定的兼容能力，可满足短时间系统间迁移的数据补偿能力，有助于缩短窗口。
4.架构设计方面，提供多种数据同步考虑，除了数据库外，还可以考虑如应用报文、网络协议等方面的同步机制，作为有益的补充。

有两种思路：
1，先对Oracle的大表进行改造，分为历史表和当前表。把历史表先期迁移到国产数据库，停机窗口内再把当前用的表迁移过去。这种用法比较推荐；
2，利用同步工具。几家大厂的国产数据库，都有自己的数据同步工具，可以先期进行数据同步，但不能同步DDL。这个阶段不要进行Oracle表结构的表更。投产窗口内，把应用停掉后，等数据追平就可以了。

1、截止到一个时间点可以提前迁移历史数据，比如窗口前一周或者提前1、2天；
2、到了停机窗口，业务停运后补增量数据；
3、做好全量数据的检查，补完增量后，新老库数据量对比，做最终确认，这样就能大大减少数据迁移时间 。

目前我们接触的国产数据库厂商都有了适合自己的全量初始化加增量同步方案，有的是利用自有工具，有的是利用常见数据迁移软件，都能做到在切换前数据实时同步几乎无延迟。但是总结下来，迁移的过程还需要重点考虑这几个问题：
1、如果源库较大，为了保障全量初始化成功，需要考虑适当调大undo表空间，为了保障迁移时对生产影响较小，尽量使用物理备库抽取，全量迁移时合理分组初始化。如果是单表过大又没有物理备库的情况，可以考虑使用更高效的工具（数据泵等）将单表迁移至Oracle中转库（不承载业务）再慢慢导入到国产数据库。
2、如果迁移过程中使用了kettle、ogg、平面文件多种技术组合实现，上线前一定要对数据做验证，防止出现中文乱码。
3、各家都实现了实时增量同步，目前切换过程中占用停机时间的主要是这两个步骤，一是数据静态后的数据检验时间，二是反向同步启动前的配置和检查工作。

前几年做过国产数据库的迁移，主要考虑的是几个方面：
1.DDL的转置评审部署，和厂家频繁交流，找到影响业务的差一点。
2.部署自动的数据同步工具。
3.同步一个周期的数据，验证export/load性能、准确性。
4.验证测试程序，(如果有并行系统也可以拉起来试一试)
5.在合适的时间窗口，进行历史数据同步，做数据完整性验证，把数据追到日差/时差
6.制定割接计划

目前大部分厂商都提供迁移评估工具和 数据迁移工具：包含结构、全量、增量以及 全增量对比工具的能力，最大的问题本质还是源端oracle的字符集、Lob字段，宽表，脏数据等会影响工具的性能和稳定性。因此本质上还是先选好 国产数据库，是否满足企业对于性能、高可用抑或降本增效等诉求。

增量迁移

选了什么数据库