关于数据迁移，在之前也讨论过一些需要注意的地方，可能林林总总列了不少，都是在数据迁移迁移前和迁移时需要注意的。
http://blog.itpub.net/23718752/viewspace-1195364/
我在这个帖子的基础上进行更多的总结和补充。
数据升级前的测试
-）充分的测试，评估时间，总结经验,提升性能, 心中有数。
在生产中进行数据的大批量迁移时，充分的测试时必须的。一方面可以根据这些测试积累一些必要的数据作为生产中使用参考，另外一方面可以基于之前的测试，总结经验，总结不足之处，加入改进，在生产中每一分钟的改进都是很重要的。
补充：
需要做一些相关的性能测试，在条件允许的情况下在类似的环境中完全模拟，得到一些性能数据，然后不断的改进，看能够否有大的提升。
我们在做数据迁移的时候，就是在备份库中克隆的一套环境，然后在上面做的性能测试，在生产上的步骤方式都一样，结果在正式升级的时候就能够做到心中有数。什么时候需要注意什么，什么时候需要做哪些想关的检查。
完整的备份策略
热备甚至冷备
在数据迁移之前进行完整的备份，一定要是全量的。甚至在允许的情况下做冷备都可以。数据的备份越充分，出现问题时就有了可靠的保证。
lob数据类型的备份，做表级的备份（create table nologging....)
对于lob的数据类型，在使用imp,impdp的过程中，瓶颈都在lob数据类型上了，哪怕表里的lob数据类型是空的，还是影响很大。
自己在做测试的时候，使用Imp基本是一秒钟一千条的数据速度，impdp速度有所提升，但是parallle没有起作用，速度大概是1秒钟1万条的样子。
如果在数据的导入过程中出了问题，如果有完整快速的备份，自己也有了一定的数据保证，要知道出问题之后再从备份库中导入导出，基本上都是很耗费时间的。
补充：
关于lob数据的备份，大家可以根据自己的情况而定，如果使用数据泵来做数据迁移，强烈建议做表级备份，如果出现数据冲突的时候，能够很方便的排查。
而在系统级的备份，也是很重要的，这个也是整个升级的关键，如果出现任何预料之外的情况，我们还可以退回一步。
数据升级前的系统级检查
1）内存检查
可以使用top,free -m来做一个检查，看内存的使用情况是否正常，是否有足够的内存空间。
像下面的情况，在同一台机器上有多个实例，如果能够最大程度的释放内存给需要的库，可以考虑把剩下的库failover到别的服务器上。或者情况允许的情况下，直接停掉。
àDB instance in the same DB server(PRODB01)
As I remember XXXXX ,XXXX is on other DB server before, is it possible to switch to other DB servers?
> ps -ef|grep smon
oraccbs1 21056 1 0 Aug17 ? 00:00:17 ora_smon_PRODB01
oraaems2 22395 1 0 Aug17 ? 00:00:02 ora_smon_DBM02
oraarcs1 24868 1 0 Aug17 ? 00:00:02 ora_smon_DBC01
oramaes1 26396 1 0 Aug17 ? 00:00:01 ora_smon_DBE01
2）检查cpu,io情况，查看iowait是否稳定，保持在较低的一个幅度。
可以使用top,sar命令来查看或者通过shell脚本来得到一些系统的负载信息，及时排除不必要的隐患。
可以查看iowait的情况，如果超过30%,说明有比较严重的io等待了，一般都需要保持在一个很低的比例。
àIOwait
from system level has reduced much, as I remember, it is around 4% before. And vxfs_thread has gone.
top - 12:54:20 up 26 days, 11:51, 8 users, load average: 2.05, 2.22, 2.36
Tasks: 2150 total, 4 running, 2145 sleeping, 0 stopped, 1 zombie
Cpu(s): 5.8%us, 0.4%sy, 0.0%ni, 93.6%id, 0.1%wa, 0.0%hi, 0.1%si, 0.0%st
Mem: 371307496k total, 187371412k used, 183936084k free, 2043876k buffers
Swap: 377487328k total, 9440k used, 377477888k free, 112921640k cached
3）检查进程的情况
检查是否有高cpu消耗的异常进程
检查是否有僵尸进程
像下面的例子，进程中存在一个僵尸进程，可以查看倒底是什么进程，排查后可以杀掉。
top - 16:53:11 up 26 days, 15:50, 9 users, load average: 2.95, 2.61, 2.83
Tasks: 2096 total, 2 running, 2093 sleeping, 0 stopped, 1 zombie
Cpu(s): 5.8%us, 1.1%sy, 0.1%ni, 88.5%id, 4.2%wa, 0.0%hi, 0.2%si, 0.0%st
Mem: 371307496k total, 100558832k used, 270748664k free, 2047600k buffers
Swap: 377487328k total, 9440k used, 377477888k free, 26339800k cached
> ps -A -ostat,ppid,pid,cmd | grep -e '^[Zz]'
Zs 8739 8745 [sh]
> ps -ef|grep 8739
root 8739 10743 0 00:01 ? 00:00:00 crond
root 8745 8739 0 00:01 ? 00:00:00 [sh]
oraccbs1 20785 6780 0 16:54 pts/5 00:00:00 grep 8739
> ps -ef|grep 8745
root 8745 8739 0 00:01 ? 00:00:00 [sh]
oraccbs1 22222 6780 0 16:54 pts/5 00:00:00 grep 8745
4）是否有crontab的设置
这个检查太重要了，如果在升级的时候有什么例行的job在运行，会有很大的影响，可以使用crontab -l来查看crontab的情况
5）vxfs下的odm是否已经启用
如果使用的veritas的文件系统，需要检查一下odm是否正常启用。
àODM is enabled.
Oracle instance running with ODM: Veritas 6.0.100.000 ODM Library, Version 2.0
Sun Aug 17 23:24:39 2014
> ps -ef|grep odm
root 10615 1 0 Jul23 ? 00:00:17 [vxodm_ioreap]
root 10616 1 0 Jul23 ? 00:00:00 [vxodm_ioclean]
oraccbs1 24858 28913 0 12:58 pts/9 00:00:00 grep odm
6）IO 简单测试
从系统角度来考虑，需要保证io的高效性。可以使用iostat,sar等来评估
还可以使用如下的脚本简单来测试一下。
time dd if=/dev/zero bs=1M count=204 of=direct_200M
->DD testing, result is expected.
> time dd if=/dev/zero bs=1M count=204 of=direct_200M
204+0 records in
204+0 records out
213909504 bytes (214 MB) copied, 0.401999 seconds, 532 MB/s
real 0m0.404s
user 0m0.001s
sys 0m0.035s
> time dd if=/dev/zero bs=1M count=204 of=direct_200M
204+0 records in
204+0 records out
213909504 bytes (214 MB) copied, 0.424942 seconds, 503 MB/s
real 0m0.433s
user 0m0.000s
sys 0m0.030s
7） 网络带宽
网络是很重要的一个因素，数据迁移的时候肯定会从别的服务器中传输大量的文件,dump等，如果网络太慢，无形中就是潜在的问题。
可以使用scp来进行一个简单的测试，如果存储还不错的话，一般在50M左右/每秒 的速度