在生产环境中，做数据迁移需要考虑很多的可能性和场景，尽量排除可能发生的问题。我自己总结了下，大体有如下需要注意的地方。

数据升级前的测试
1）充分的测试，评估时间，总结经验，提升性能
在生产中进行数据的大批量迁移时，充分的测试时必须的。一方面可以根据这些测试积累一些必要的数据作为生产中使用参考，另外一方面可以基于之前的测试，总结经验，总结不足之处，加入改进，在生产中每一分钟的改进都是很重要的。
补充：
需要做一些相关的性能测试，在条件允许的情况下在类似的环境中完全模拟，得到一些性能数据，然后不断的改进，看能够否有大的提升。
我们在做数据迁移的时候，就是在备份库中克隆的一套环境，然后在上面做的性能测试，在生产上的步骤方式都一样，结果在正式升级的时候就能够做到心中有数。什么时候需要注意什么，什么时候需要做哪些想关的检查。

2）完整的备份策略
热备甚至冷备
在数据迁移之前进行完整的备份，一定要是全量的。甚至在允许的情况下做冷备都可以。数据的备份越充分，出现问题时就有了可靠的保证。
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左右/每秒 的速度

   网络临时中断
网络的问题需要格外重视，可能在运行一些关键的脚本时，网络突然中断，那对于升级就是灾难，所以在准备脚本的时候，需要考虑到这些场景，保留完整的日志记录。
可以使用nohup来做后台运行某些关键的脚本。这样网络断了以后，还有一线希望。

 
 
数据库级的检查和建议
1)参数检查

有些参数是需要在数据迁移前临时做变更的，有些是性能相关的，需要考虑。
log_buffer在数据导入的过程中会有极高的消耗，如果并发数够多，对控制文件的scn更新也有一定的影响，根据测试情况抓取addm报告，得到一个比较适合的lob_buffer值

àDB parameters

SQL> show parameter log_buffer

 NAME                                 TYPE        VALUE

 ------------------------------------ ----------- ------------------------------

 log_buffer                           integer     31252480
关于pga的调整可以根据系统的情况适当加大，在数据迁移完成之后改回原值也可以。
SQL> show parameter pga

 NAME                                 TYPE        VALUE

 ------------------------------------ ----------- ------------------------------

 pga_aggregate_target                 big integer 6G
关于buffer_cache的调整可以根据系统的情况适当加大，一般最好能在sga的范围之内尽可能加大，在数据迁移完成之后改回原值也可以。

 SQL> show parameter db_cache

 NAME                                 TYPE        VALUE

 ------------------------------------ ----------- ------------------------------

 db_cache_advice                      string      ON

 db_cache_size                        big integer 11872M

关于异步io在11g是默认开启的，不过filesystem_options一般都建议开启
SQL> show parameter filesys

 NAME                                 TYPE        VALUE

 ------------------------------------ ----------- ------------------------------

 filesystemio_options                 string      SETALL

 SQL> show parameter asy

 NAME                                 TYPE        VALUE

 ------------------------------------ ----------- ------------------------------

 disk_asynch_io                       boolean     TRUE

 tape_asynch_io                       boolean     TRUE

2)表空间评估
表空间的情况，根据数据分布预估数据空间的情况，保留一定的额外空间。最好能富裕30%以上，毕竟数据迁移的过程中没空间了还是很要命的。

 
3)归档频率
归档的频率也是衡量系统负载的一个很直观的方法。
查看归档的在一个小时内切换多少次，可以查看最近两周左右的情况，这样在数据迁移的时候能够有一个很清晰的评估。
比如下面的库，切换频率还是比较低的，日志为1G大小，在半夜的时候因为备份，会有比较多的日志切换。

 DBNAME    TIME_STAMP
--------- --------------------
CUST01    2014-Aug-19 23:46:03

GROUP#    THREAD#  SEQUENCE#    MEMBERS    SIZE_MB ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
         1          1      23289          2       1024 YES INACTIVE
         2          1      23290          2       1024 YES INACTIVE
         3          1      23291          2       1024 YES INACTIVE
         4          1      23292          2       1024 NO  CURRENT

 Redo Switch times per hour                                             xxxxxx                                                    2014-Aug-19 23:46:03
MON DA   00   01   02   03   04   05   06   07   08   09   10   11   12   13   14   15   16   17   18   19   20   21   22   23
--- -- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
08  05    3   25    1    1    6    8    1    1    3    1    1    3    5    2    1    3    2    3    2    3    1    1    7    0
08  06    0    0    0    0    0    0    0    0    0    1    0    1    1    3    6    3    4    2    2    2    2    1   12    0
08  07    0    2    2    2   12   19    2    1    3    3    4    2    2    2    2    3    5   20   14    3   11    2    4    0
08  08    5    1   11   25    4    2    2    2    3    3    2    4   12    3    6   13    2    2    2    3    1    1    3    1
08  09    0    5    0    1    0    3    3    1   21    3    3    2    1    2    2    2    1    2    2    1    1    1    1    1
08  10    2    0    0   17    0    4    0    1    1    2    1    1    2    1    2    2    1    2    2    1    1    4    1    1
08  11    2    1   16    3    0    0    0    1    1    1    1    2    2    1    2    2    2    2    2    2    1    1    2    2
08  12    5    2   17    1    0    1    0    1    1    1    2    2    2    2    1    2    2    2    2    1    1    2    1    2
08  13    2    0    1   20    0    1    0    1    1    3    2    2    3    2    1    3    2    8    5    2    1    1    1    6
08  14    2    1    0   17    0    2    1    1    2    6    1    7    1    2    1    4    1    2    2    3    1    1    4    2
08  15    1    2    0    7    0    1    0    1    1    2    3    4    2    3    1    2    3    6    2    2    1    1    4    1
08  16    2    2    5    6   22    1    0    1    1    5    1    2    1    2    2    6   10    4    1    5    2    1    1    1
08  17    3    6    1    1    0    1    0    1    1    2    2    1    2    3    1   25   10    4    2    2    1    2    0    1
08  18    0    0    2   55    0    1    0    1    3    2    2    2    2    2    2    2    2    2    1    3    1    1    1    1
08  19    2   18    0    1    0    1    0    1    3    2    1    3    1    3    1   13    5    2    3    2    1    0    0    0

看一下数据迁移的时候的情况,在数据迁移的工程中，几乎跑到了极致，一个小时切换300多次。

  GROUP#    THREAD#  SEQUENCE#    MEMBERS    SIZE_MB ARC STATUS
---------- ---------- ---------- ---------- ---------- --- ----------------
         1          1      23813          2       1024 YES ACTIVE
         2          1      23814          2       1024 NO  CURRENT
         3          1      23811          2       1024 YES INACTIVE
         4          1      23812          2       1024 YES ACTIVE

Redo Switch times per hour                                              CUST01                                                    2014-Aug-20 02:08:17
MON DA   00   01   02   03   04   05   06   07   08   09   10   11   12   13   14   15   16   17   18   19   20   21   22   23
--- -- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ---- ----
08  05    0    0    1    1    6    8    1    1    3    1    1    3    5    2    1    3    2    3    2    3    1    1    7    0
08  06    0    0    0    0    0    0    0    0    0    1    0    1    1    3    6    3    4    2    2    2    2    1   12    0
08  07    0    2    2    2   12   19    2    1    3    3    4    2    2    2    2    3    5   20   14    3   11    2    4    0
08  08    5    1   11   25    4    2    2    2    3    3    2    4   12    3    6   13    2    2    2    3    1    1    3    1
08  09    0    5    0    1    0    3    3    1   21    3    3    2    1    2    2    2    1    2    2    1    1    1    1    1
08  10    2    0    0   17    0    4    0    1    1    2    1    1    2    1    2    2    1    2    2    1    1    4    1    1
08  11    2    1   16    3    0    0    0    1    1    1    1    2    2    1    2    2    2    2    2    2    1    1    2    2
08  12    5    2   17    1    0    1    0    1    1    1    2    2    2    2    1    2    2    2    2    1    1    2    1    2
08  13    2    0    1   20    0    1    0    1    1    3    2    2    3    2    1    3    2    8    5    2    1    1    1    6
08  14    2    1    0   17    0    2    1    1    2    6    1    7    1    2    1    4    1    2    2    3    1    1    4    2
08  15    1    2    0    7    0    1    0    1    1    2    3    4    2    3    1    2    3    6    2    2    1    1    4    1
08  16    2    2    5    6   22    1    0    1    1    5    1    2    1    2    2    6   10    4    1    5    2    1    1    1
08  17    3    6    1    1    0    1    0    1    1    2    2    1    2    3    1   25   10    4    2    2    1    2    0    1
08  18    0    0    2   55    0    1    0    1    3    2    2    2    2    2    2    2    2    2    1    3    1    1    1    1
08  19    2   18    0    1    0    1    0    1    3    2    1    3    1    3    1   13    5    2    3    2    1    1    0    0
08  20  303  212    6    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0    0

 
4）重启数据库，释放session，停掉listener
一般在数据迁移之前，最好能够停掉相关的服务，比较直接的方式就是重启数据库，可以很快的清除系统中的一些Inactive session和客户端链接的session
根据自己的情况来评估，如果库的高可用性比较高，可以手工清理session。

5）parallel的选择
这个部分我的感触很深，比如数据库服务器里有40个cpu，那么一般默认一个cpu对应两个并行，那么就能支持大概80多个，还需要考虑系统的负载。
对于比较大的表适用一些并行度较高的操作，如果表本来很小，可以不用开启，或者开启很低的并行，要不得不偿失，对于分区表，还是比较纠结的，因为自身使用并行有一些限制。而且如果做全表插入，会有和分区数相当的锁，开启的并行很可能不会适用。

6）undo的考虑
对于数据迁移来说，对于undo的空间使用来说是极大的挑战，可能在Impdp的时候出了Undo的问题，那就是极为奔溃的问题了。
还要考虑undo_retention的设置，可以在数据迁移之前可以把retention调低一些，保证undo的使用率足够用，然后在升级之后恢复设置。

6）归档空间
数据迁移的时候会有大量的日志产生，一定需要保证归档空间足够大，及时的转移归档文件。排除归档爆了以后数据的问题，使用sqlloader,impdp等数据迁移策略的时候，如果归档出了问题，是很头疼的问题。如果可以的话，可以申请临时加入一些文件空间，在数据迁移之后把空间大小恢复。

7）表级nologging
如果条件允许，可以考虑对一些相关的表开启nologging，在数据迁移之后再设置logging.
对速度有一些的提升，如果使用insert /*+append */的时候，那速度就很明显了。

8）index级nologging
数据的insert操作，如果没有index速度很有成倍的提高，但是在生产中可能并不能建议这么做，如果重建索引的时候，也需要一定的时间，还需要一定保证索引和之前一定要没有任何的差错。所以一般来说，如果开启Index的nologging也会有一定的提升。

9）lob级nologging
对于lob数据类型来说，在允许的条件下，可以设置为nologging，速度会有所提升。

10）foreign key
外键的影响需要重视，如果外键存在对于数据的插入顺序无形中对会有一定的约束，所以在大批量的数据并发插入条件下，disable foreign key，可以更加高效，当然在enable foreign key的时候需要花费一些时间，做为数据检查。
主键冲突数据排除
主键冲突数据的排查是一个很重要的环节，如果之前的准备工作不到位，到了生产之后，那就是数据灾难。大半夜修复数据的痛苦真是不言而喻啊。如果数据前一部分不给力，你就得给力，想想办法来排查吧。

constraint级的数据不一致
这种问题存在而且很隐蔽，比如如下的错误。就是not null constraint在源schema中不存在，在导入目标库的时候出问题了。

cannot insert NULL into ("xxxx"."test_data"."TOT_OBLIGATION_PCT")

对于这类问题需要和数据迁移组协调，尽可能保证constraint的一致性。

11）trigger的影响
tigger在数据的dml操作中都有这潜移默化的影响，所以对于trigger最好和开发部分做确认，是否需要禁用trigger
要不很可能在数据迁移之后发现一些莫名其貌的数据多出来了。

12）materialized view log的影响
有些外部系统可能为了数据同步，可能会在系统中创建一些物化视图日志，可以和他们做一个确认，删除物化视图日志，减少数据插入的时候物化视图日志的影响，
还有一个问题就是物化视图日志会使rename table等操作无法进行。

13）godlengate的影响
goldengate的影响不容小视，需要和部分做一个确认在数据迁移之前停掉goldengate相关的进程。

14)数据统计信息的收集
数据迁移之后会有大量的数据变化，这个时候需要考虑收集统计信息，可以开启多个session做并行的收集。
以下是在做数据迁移的时候，分10个session并行收集统计信息的top信息，cpu的使用率已经达到了极致，收集工作不会持续太久，一般在一个小时的样子。不过可以同时做一些相关的检查了。

top - 02:21:54 up 28 days,  1:19, 21 users,  load average: 37.15, 22.01, 12.09
Tasks: 927 total,  27 running, 897 sleeping,   2 stopped,   1 zombie
Cpu(s): 62.6%us,  3.1%sy,  0.0%ni, 33.5%id,  0.0%wa,  0.2%hi,  0.6%si,  0.0%st
Mem:  371307496k total, 337238216k used, 34069280k free,  1259404k buffers
Swap: 377487328k total,     9440k used, 377477888k free, 266625964k cached

  PID USER      PR  NI  VIRT  RES  SHR S %CPU %MEM    TIME+  COMMAND
 4602 oraccbs1  19   0 18.3g 132m  28m R 93.9  0.0   1:53.45 ora_p027_CUST01
 4580 oraccbs1  19   0 18.3g 132m  28m R 91.6  0.0   2:05.36 ora_p026_CUST01
 4612 oraccbs1  16   0 18.3g 132m  28m S 88.3  0.0   2:38.77 ora_p032_CUST01
 4604 oraccbs1  16   0 18.3g 129m  25m R 87.6  0.0   1:59.36 ora_p028_CUST01
 4616 oraccbs1  16   0 18.3g 132m  29m R 84.4  0.0   2:03.56 ora_p033_CUST01
23619 oraccbs1  18   0 18.2g  28m  21m R 82.7  0.0   1:35.33 ora_p042_CUST01
 4606 oraccbs1  16   0 18.3g 132m  28m R 82.4  0.0   2:13.57 ora_p029_CUST01
25504 oraccbs1  18   0 18.2g  28m  23m R 81.4  0.0   1:00.60 ora_p046_CUST01
10342 oraccbs1  18   0 18.3g 129m  26m R 81.1  0.0   0:46.80 ora_p062_CUST01
23621 oraccbs1  18   0 18.2g  38m  32m R 80.4  0.0   1:38.34 ora_p043_CUST01
23600 oraccbs1  18   0 18.2g  31m  25m R 79.4  0.0   1:44.57 ora_p040_CUST01
31081 oraccbs1  17   0 18.2g  33m  20m D 78.7  0.0   2:43.19 ora_p003_CUST01
 4620 oraccbs1  25   0 18.3g 129m  24m R 78.4  0.0   2:33.77 ora_p035_CUST01
 4618 oraccbs1  17   0 18.3g 129m  24m D 78.1  0.0   2:31.58 ora_p034_CUST01
31079 oraccbs1  16   0 18.2g  36m  23m R 77.1  0.0   2:40.58 ora_p002_CUST01
 6167 oraccbs1  18   0 18.3g 132m  28m S 74.5  0.0   0:36.50 ora_p056_CUST01
25506 oraccbs1  18   0 18.2g  26m  20m R 72.2  0.0   0:59.59 ora_p047_CUST01
23602 oraccbs1  18   0 18.2g  28m  21m R 71.2  0.0   1:47.88 ora_p041_CUST01
23623 oraccbs1  18   0 18.2g  28m  21m R 71.2  0.0   0:43.13 ora_p044_CUST01
 6209 oraccbs1  18   0 18.3g 113m  19m D 69.5  0.0   0:38.34 ora_p057_CUST01
23625 oraccbs1  18   0 18.2g  32m  25m R 69.5  0.0   0:44.14 ora_p045_CUST01
10344 oraccbs1  18   0 18.3g 132m  28m S 67.9  0.0   0:46.73 ora_p063_CUST01
30746 oraccbs1  16   0 18.2g  23m  19m R 67.5  0.0   2:16.49 ora_p018_CUST01
25537 oraccbs1  16   0 18.2g  22m  18m R 64.6  0.0   0:49.59 ora_p048_CUST01
30748 oraccbs1  16   0 18.2g  24m  19m D 63.3  0.0   2:16.43 ora_p019_CUST01
25539 oraccbs1  16   0 18.2g  21m  18m D 62.9  0.0   0:49.08 ora_p049_CUST01
19872 oraccbs1  18   0 18.2g  26m  22m R 52.4  0.0   1:23.81 ora_p007_CUST01
19870 oraccbs1  18   0 18.2g  27m  23m R 52.1  0.0   1:43.02 ora_p006_CUST01
30760 oraccbs1  16   0 18.2g  24m  20m D 46.1  0.0   2:02.59 ora_p022_CUST01
25541 oraccbs1  16   0 18.2g  22m  17m R 44.5  0.0   0:53.93 ora_p050_CUST01
25543 oraccbs1  16   0 18.2g  21m  17m D 44.5  0.0   0:55.90 ora_p051_CUST01
30758 oraccbs1  16   0 18.2g  24m  19m R 41.8  0.0   2:07.19 ora_p021_CUST01
30756 oraccbs1  16   0 18.2g  24m  20m R 40.2  0.0   2:09.89 ora_p020_CUST01
30762 oraccbs1  16   0 18.2g  24m  20m R 39.9  0.0   1:52.12 ora_p023_CUST01
22568 oraccbs1  18   0 18.2g  20m  15m R 35.6  0.0   0:01.68 ora_p064_CUST01
 1492 oraccbs1  15   0 18.2g  23m  19m S 28.0  0.0   0:15.01 ora_p053_CUST01
22570 oraccbs1  18   0 18.2g  22m  17m D 27.0  0.0   0:01.51 ora_p065_CUST01

同时及时查看收集的进度，根据日志或者进程情况。
> ps -ef|grep sqlplus
oraccbs1   853 18167  0 02:26 pts/7    00:00:00 grep sqlplus
oraccbs1  1486 18167  0 02:19 pts/7    00:00:00 sqlplus
oraccbs1  6099 18167  0 02:20 pts/7    00:00:00 sqlplus
oraccbs1  9260 25974  0 02:14 pts/5    00:00:00 sqlplus
oraccbs1  9932 18167  0 02:20 pts/7    00:00:00 sqlplus
oraccbs1 15320 18167  0 02:18 pts/7    00:00:00 sqlplus
oraccbs1 19862 18167  0 02:15 pts/7    00:00:00 sqlplus
oraccbs1 23615 18167  0 02:18 pts/7    00:00:00 sqlplus
oraccbs1 25533 18167  0 02:19 pts/7    00:00:00 sqlplus
oraccbs1 30209 18167  0 02:19 pts/7    00:00:00 sqlplus
oraccbs1 30498 18167  0 02:16 pts/7    00:00:00 sqlplus

14)申请较大的mount point

数据迁移的时候往往需要临时的挂载点存放dump文件，这个需要提前申请和准备。
像下面的情况，一定得提前检查保证有足够的权限。

àShared mount point permission:

> touch testfile

touch: cannot touch `testfile': Permission denied

15)查看数据的负载情况
提前查看数据库的运行情况，是否已经有过高的负载，及时进行排查。
以下是数据迁移的时候数据库负载情况。在数据迁移之后就马上恢复了正常。
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
BEGIN_TIME------------------------- END_TIME--------------------------- ELAPSED_TIME- BTIME----- WORKLOAD_PER--------
----------------------------------- ----------------------------------- ------------- ---------- --------------------

14134 ** 20-AUG-14 12.00.05.845 AM  14135 ** 20-AUG-14 01.00.10.524 AM         60.078    1170.81 1948%
14135 ** 20-AUG-14 01.00.10.524 AM  14136 ** 20-AUG-14 02.00.12.741 AM         60.037      612.2 1019%
14136 ** 20-AUG-14 02.00.12.741 AM  14137 ** 20-AUG-14 03.00.14.846 AM         60.035     745.48 1241%
14137 ** 20-AUG-14 03.00.14.846 AM  14138 ** 20-AUG-14 04.00.16.889 AM         60.034      72.05 120%
14138 ** 20-AUG-14 04.00.16.889 AM  14139 ** 20-AUG-14 05.00.19.070 AM         60.036      50.53 84%
14139 ** 20-AUG-14 05.00.19.070 AM  14140 ** 20-AUG-14 06.00.21.069 AM         60.033      28.27 47%

15)完整的日志和报告
在数据迁移，数据升级的时候，一定要保留完整的日志记录，这样如果稍候有问题，也可以及时查验，也可以避免很多不必要的纷争。如果有争议，可以找出日志来，一目了然。

提前准备好一些awr，ash之类的报告，作为一些备份和适当的参考材料