如果有一套环境，业务优先级很高，服务器的服役时间比我工作时间都长，现在需要迁移到X86平台，而且经过评估，如果能够升级数据库的软件版本，可以使用到更多的特性和功能。这套环境的数据量大概是800G,停机维护时间在2个小时的样子，对于很多公司来说，尽可能缩短维护窗口时间，提前起服就意味着有更多的收入，所以2个小时如果能够再缩短一些的话，就太好了，这样一个需求该怎么办?
这里我刻意可以弱化了数据库类型，其实这个需求具有一定的普适性，都可以参考借鉴。
而另一方面，我暂且按照Oracle为例来说明，过于笼统，可操作性，实践性不强，实际意义会打折扣。
这个需求是一个硬骨头，前前后后几代DBA也是前仆后继，总算到了非迁不可的地步了。而且因为环境的限制，有一些硬伤，比如主库承担不了太大的压力，网络条件不佳等。所以事儿真不好做，方案也不好来定。
这里我建议大家先熟悉一下整个数据库的情况，数据的分布情况之后再结合一些可行方案来得到一个最合适的方案。
在梳理了初步的方案之后，在这个基础上再细化了数据的分布情况，我想到了一种相对可控的方案。
这个库磁盘空间占用有800G,但是不是800G的纯数据，还有相当一部分是索引的消耗，经过分析，这个环境90%的数据在属主用户上，而索引占据了近40%的空间，这样一来实际的数据空间也就在50%左右，最后的10%的数据是一些数据字典信息，补充辅助的一些数据信息。
所以这样一来我们可以把数据分为三类，然后给出相应的解决方案：
- 索引段数据，索引段的数据其实可以提前进行准备，能够大大减少迁移过程中的资源消耗，整个过程中不需要同步，自适应即可。
- 数据字典和其它信息，这部分数据都是数据字典，权限信息，少量的辅助数据等，经过评估这部分数据一次同步后，就不需要反复同步了。
- 数据段，这部分数据占用空间400G左右,这个是迁移的关键所在。这个数据显然是需要持续同步的。
这样一来800G的迁移我们可以先简化到400G的规格，听起来难度降低了一半。
我们再来看看这400G数据的情况，大部分的数据都集中在了20个大表里面，占用的空间远超95%以上。而一些基础的表数据大概只占用了5%的比例。
通过这些信息，我们可以设想400G的数据迁移，大部分数据在20个表里面，那这个事情可不可以这么做：
20个大表的数据通过持续的同步来满足，而其他表的数据则不需要持续同步，在迁移的时候直接导出导入即可。
而且更关键的是20个表里面，70%的数据集中在了3个表上，剩下的30%的信息集中在了17个表上。
我们可以做成哟䘺弹性的方案，比如使用Oracle的物化视图prebuilt属性，因为涉及的表很少，直接物化视图增量刷新即可。
而3个大表的数据量实在太大，这部分信息就可以通过OGG来逻辑同步。
有的同学可能会问都用物化视图增量刷新得了，这样一来3个大表的数据同步，数据库层面没有可以设定的阈值，控制措施，比如限定流量情况等。所以3个大表是不建议物化视图增量刷新来操作的。
而那17个表相对来说数据量较大，几百MB其实还可以接受的，使用增量刷新就可以。
或者有的同学说，干脆都使用OGG同步得了，这个在目前的考虑方案中也是可行的。无非就是基础的配置上需要提前准备调试。
遮掩下来，整个的数据迁移其实绝大部分工作都可以提前安排好，到了迁移的时候，只是把5%的数据重新同步即可。
