其实对于Datapump迁移而言，如果参与过XTTS,OGG,Veritas SF，外部表增量等迁移方式的话，会发现Datapump还是很简单清晰的，一个优点就是操作简单清晰，想必于imp而言性能要好。所以不要小看这种迁移方式，不是说哪些迁移方式就是最好的，数据迁移中也没有银弹，最合适的就是最好的。
迁移之前我们还是需要做一些准备工作，尽量避免临时的忙乱，减少出错概率，要知道升级迁移都是在大早上，大晚上，都是精力比较差的时候，如果迁移前的准备不足，没有充足的准备，就会忙乱一团。所以在这点上有一个详细的检查清单还是很有必要的。
假设下面的这种场景，我们有一套全新的硬件环境，数据量也不大，需要升级到11g环境，可以考虑Datapump方案。
迁移前的准备工作，自己想了不少，总结出来就是一套可实践的方案，可能有的朋友会想，如果升级一套数据库，这些工作是不是看起来有些多余啊，其实不然，一种情况下，升级的时候是多台联动升级，这时很容易遗留一些准备工作；另外一种情况是你做了很多准备工作，但是在紧急的情况下，你肯定不会那么淡定，这个时候这些准备就很有条理，严格按照计划就会省力很多。
拷机测试，检查是否有sysbench的进程存在,一般来说拷机测试需要一周左右，如果有硬件问题可以及时排除。
保证主备机不在同一个机架位，机房的服务器需要提前确认不在同一个机架位，排除断电造成的极端情况
两个服务器间配置无密码通信，方便dump传输
优化内核参数（比如设置HugePage),关闭NUMA，设置资源memlock
同步两个服务器的防火墙信息
同步/etc/hosts信息，修改主机IP
同步listener.ora tnsnames.ora信息，host统一为主机名而非IP
修改主机名root,oracle密码，改为安全模式的设置
检查数据库日志，是否有ORA相关的错误，从日志中检查大页是否开启
设置NTP时间同步
如果存在DB Link,需要开通相关的防火墙权限，保证访问畅通
如果其他服务器存在相关的DB Link,需要提前准备好连接新库的tnsnames.ora
图形界面检查，保证能够正常显示图形，有些操作可以的话使用图形工具也可以
检查主备库启用的监听端口是否一致
数据库参数调整和优化（关闭密码过期60天的设置，部分新特性）
目标服务器中的数据库temp,undo的大小设置
检查主备库的字符集是否一致
检查数据库中的无效对象
对演练中的数据问题进行确认， Foreign key相关的数据问题
检查备库是否可以启动到只读状态
安装zabbix客户端
检查源服务器端是否有足够的磁盘空间