共计 1196 个字符，预计需要花费 3 分钟才能阅读完成。
其实对于 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 客户端
检查源服务器端是否有足够的磁盘空间
更多 Oracle 相关信息见Oracle 专题页面 http://www.linuxidc.com/topicnews.aspx?tid=12
本文永久更新链接地址：http://www.linuxidc.com/Linux/2016-06/132435.htm
