Oracle跨平台迁移的简单总结(r10笔记第91天)

前段时间测试了一下GoldenGate，结合我之前的一些尝试，对于小机环境的迁移，思路是逐步清晰了起来。

需求的核心是跨平台迁移数据库，最好能够升级到新的版本，对于一个核心系统的一主两备，需要保证数据完整性的前提，同时能够尽可能保持在一个较短的维护时间，对此自己也琢磨了很多方案。

想了NFS的方案，在备库端建立一个NFS挂载点，源端指向Linux环境，然后直接Failover，这样数据就能够直接到Linux端，然后做一个跨平台的convert操作

自己还为这种方案而沾沾自喜，最后试了一遍，发现其实不是那么回事。问题的瓶颈在哪里呢，就是跨平台的系统调用接口。

如果在Solaris端使用NFS共享的文件，尝试启动数据库，那么就会没有响应，会抛出一个比较奇怪的问题。

而对于大数据量的数据库做跨平台迁移，还有什么其他的思路吗，XTTS是一种方式，但是这种方案就比较纠结了，几乎是不可实现的，源端的数据库的网卡过旧，IO能力不足，拷贝基本上就是7M每秒的速度，对于一个近1T数据量的数据库做文件拷贝，简直不敢想象。方案虽然可行，但是不可接受。

那么使用Datapump呢，这个方案想比XTTS就更纠结了，传输，导入都更加耗时。如果保守估计，导出，传输，导入，整个过程估计得10多个小时，那我就可以直接下班回家了。

还有什么方案呢，其实还有不少，如果里面的表不多的话，可以直接使用物化视图的增量刷新来玩等。

最后到了我不大擅长的GoldenGate了，最后发现还是这种方式是一种可持续性的，维护时间最短的方案。

首先是全量同步，这个过程可以通过Datapump来完成，为什么选择Datapump呢，就因为是逻辑的，而物理的方式有一定的局限性，可以很轻松实现数据的跨版本导入。

那么问题来了，备库怎么datapump导出，这个不可行啊，我如果直接Failover了，备库就不可用了，还得重搭，这个还是有风险的。

如果你这么想，那就对了，其实可以充分利用闪回数据库的原理，先Failover，然后Datapump导出，完成这个工作之后，闪回继续接受归档，就是这个套路。

而接下来的事情就需要注意了，那就是主库端的增量同步。

使用GoldenGate的意义就在于此。

比如在目标端使用OGG同步，指定基于SCN 1887488就可以选择性同步了。

GGSCI (newtest.oracle.com) 3> start rep_tlbb, aftercsn 1887488

整个过程会保证数据的一致性，而且是一个持续性的同步过程，如果说夸张一些，是零维护时间的迁移式升级。总之，维护时间很短，对于业务端来说是透明的而且完全无感知。