之前写了一篇文章分析了Datapump迁移数据的一些准备总结，反响还不错。最近碰到一个场景，根据评估还是使用Datapump比较好。主要的原因如下：
1.原来的环境在Solaris下，硬件资源老旧，需要迁移到Linux下，跨平台迁移使用逻辑迁移优先
2.原来的环境使用10gR2,现在需要顺带迁移到11gR2，充分解决备库“不中用”的情况
3.迁移的数据量不算大，在几百G以内，可以充分利用带宽和I/O吞吐量来达到预期的时间窗口。
而在这个方案之外，考虑到提高性能，我们采用了PCIE-SSD的方案加速I/O，当然使用了和源库不同的分区。
为了使应用的影响降低到最低，我们决定在迁移之后切换IP，使得新的数据库环境拥有原来的IP，这样应用端就无需做任何连接信息的修改了，DB Link的问题也能得到一并解决，无需确认更多的细节。
如果应用有重连机制，那么这种方案之外对于应用是完全透明的，就跟启停一下应用的效果一样。
这种方案使用Datapump迁移前看起来还是照葫芦画瓢，但是细细想来却有一些隐患和需要预先解决的地方，不知道大家看到我提供的背景是否有一些想法。
1.为了降低切换IP带来的繁琐和更多可能的隐患，所以在listener.ora,tnsnames.ora中的host信息都统一为主机名，这样在/etc/hosts中统一修改即可。切换IP后只修改这一处配置即可。
2.Solaris的防火墙信息设置和Linux还是截然不同的。这个里面就有很多信息需要确认。
Solaris环境下的防火墙开通是类似下面的形式：
如果要对10.xxxx的IP开通1522的端口访问权限，使用下面的方式在内存中和文件中都做配置
内存中设置，在线生效，其中e1000g0 为网卡的名称，就跟Linux中的eth0,eth1是一样的。
echo 'pass in quick on e1000g0 proto tcp from 10.xxxxx to any port = 1522' | ipf -f -
在文件中补充
/etc/ipf/ipf.conf ||pass in quick on e1000g0 proto tcp from 10.xxxxx to any port = 1522
在Linux下则要简单许多,类似下面的形式
iptables -I INPUT -s 10.xxxx -p tcp -m multiport --dports 1522 -i eth0 -j ACCEPT
如果要写入配置文件，则可以直接service iptables save
这个配置信息的变更让我花了些时间，其中还有一些空格类的，个别语法的差异，最后干脆直接手工来调整了。
3.对于目标库的设置，有一个很大的隐患，就是源库和目标库的文件路径不同，我在上面也提到了使用PCIE-SSD采用了不同的分区，所以如果直接采用全库导入是肯定会有隐患，倒不是出错，而是会造成资源的浪费。比如源库中的文件路径是/U01/xxxx 而在目标库是/U02/xxx，在这种情况下如果全库导入，生成的表空间，数据文件都会在/U01下，如果迁移完成之后反应过来，那已经有些晚了，还得重新再迁移一遍，要么重建控制文件，要么直接rename，在升级窗口有限的时间里这种突发情况花费的时间肯定不是一两分钟，恐惧和慌乱很可能会花去至少10多分钟的时间。
4.对于未知问题的考虑，我也有一些补充的想法，在源库中导出数据，如果开启大并行，有一种隐患就是老旧的服务器还是有潜在的风险，如果出现了宕机，那大家可就慌乱了，紧急处理思路就是做Failover，然后在备库端继续尝试导出，如果点更背，还是出现故障，还有异地备库2 ，再次做Failover，这种情况下就赶紧收手，安排下次的迁移了。当然我说的可能是微乎其微的概率，但是这些可能你如果认真想过，就算出了问题也会临危不太乱。
5.当然对于监控来说，有一个好处是可以统一在Linux下监控了，在Solaris下还总是有一些担心，所以只开启了Orabbix监控。
最后就是认真细心的处理各种可能发生的问题，统筹帷幄，一切尽在掌握之中。
Datapump数据迁移前的准备工作
Datapump数据迁移的实践总结
：