大集中的数据迁移方案该如何选择？大家有什么好经验 ？

排除其他非技术性条件的情况下，主要看预留的停机时间和数据量、业务复杂度的限制了。

应用层--数据库层--os层--存储层 ，定位在那一层都可以设计方案，而且根据停机时间可以做多样化选择。比如oracle的迁移，数据泵、rman肯定是可以做的，停机时间小的话，dg和ogg更合适。

越往下层走，上层的压力就越小。主机层的lvm实施，上层基本可以不用动。如果直接基于底层的存储复制，主机层都几乎不需要做调整，甚至可以做到无缝迁移，配合流量控制，基本可以做到对应用性能的最小影响。

大集中的数据迁移首先要考虑的是：

1、各业务及系统模块允许停机的时间。例如一大集中的系统做数据迁移，如果停机时间必须在1小时内完成，与停机时间允许在24小时以上。这两种时间成本可以采取的数据迁移方案是可以完全不同的，投入的人力物力自然也有差异。

2、数据的本身的逻辑结构和现有通用的数据迁移工具技术手段因素。例如集成的数据如果是以零散文件为主，则可以在业务运行的过程中提前同步迁移，完成数据追平后，部署对应的新的应用集群即可。又例如常见的ORACLE数据库为例，数据迁移采用在线迁移工具goldengate还是dataguard，甚至还是采取DSG,还是SymanTec等，都是需要进行各个工具特性与业务逻辑要求的。

3、数据迁移方案是否成功，最关键的一步是数据校对。如果说一个数据迁移方案设计完成了，而缺乏这一步，实际是一个不完整的方案。

以上对数据迁移项目中个人强调建议，仅供参考。

数据大集中有几种架构模式:统一中心数据库，数据库群，数据平台等不同模式。

数据集中迁移有数据初始化和数据同步过程。

数据集中迁移的难点在于前期数据梳理，数据标准制定，第一数据源确定，数据更新规则，迁移过程中业务部门，开发商配合等。

实施中取得高层支持，确认标准，在与业务部门在共识下开展工作，，先选技术风险小，合作好的部门做成功样板。