在生产环境中，做数据迁移需要考虑很多的可能性和场景，尽量排除可能发生的问题。我自己总结了下，大体有如下需要注意的地方。
1）充分的测试，评估时间，总结经验，提升性能
在生产中进行数据的大批量迁移时，充分的测试时必须的。一方面可以根据这些测试积累一些必要的数据作为生产中使用参考，另外一方面可以基于之前的测试，总结经验，总结不足之处，加入改进，在生产中每一分钟的改进都是很重要的。
2）完整的备份策略
热备甚至冷备
在数据迁移之前进行完整的备份，一定要是全量的。甚至在允许的情况下做冷备都可以。数据的备份越充分，出现问题时就有了可靠的保证。
lob数据类型的备份，做表级的备份（create table nologging....)
对于lob的数据类型，在使用imp,impdp的过程中，瓶颈都在lob数据类型上了，哪怕表里的lob数据类型是空的，还是影响很大。
自己在做测试的时候，使用Imp基本是一秒钟一千条的数据速度，impdp速度有所提升，但是parallle没有起作用，速度大概是1秒钟1万条的样子。
如果在数据的导入过程中出了问题，如果有完整快速的备份，自己也有了一定的数据保证，要知道出问题之后再从备份库中导入导出，基本上都是很耗费时间的。
3)网络
网络带宽
网络是很重要的一个因素，数据迁移的时候肯定会从别的服务器中传输大量的文件,dump等，如果网络太慢，无形中就是潜在的问题。
可以使用scp来进行一个简单的测试，如果存储还不错的话，一般在50M左右/每秒 的速度
网络临时中断
网络的问题需要格外重视，可能在运行一些关键的脚本时，网络突然中断，那对于升级就是灾难，所以在准备脚本的时候，需要考虑到这些场景，保留完整的日志记录。
可以使用nohup来做外后台运行某些关键的脚本。这样网络断了以后，还有一线希望。
4）完整的日志
在数据迁移，数据升级的时候，一定要保留完整的日志记录，这样如果稍候有问题，也可以及时查验，也可以避免很多不必要的纷争。如果有争议，可以找出日志来，一目了然。
5）存储
存储也是很重要的一个方面。从系统角度来考虑，需要保证io的高效性。可以使用iostat,sar等来评估
还可以使用如下的脚本简单来测试一下。
time dd if=/dev/zero bs=1M count=204 of=direct_200M
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的时候需要花费一些时间，做为数据检查。
11）trigger的影响
tigger在数据的dml操作中都有这潜移默化的影响，所以对于trigger最好和开发部分做确认，是否需要禁用trigger
12）materialized view log的影响
有些外部系统可能为了数据同步，可能会在系统中创建一些物化视图日志，可以和他们做一个确认，删除物化视图日志，减少数据插入的时候物化视图日志的影响，
还有一个问题就是物化视图日志会使rename table等操作无法进行。
13）godlengate的影响
goldengate的影响不容小视，需要和部分做一个确认在数据迁移之前停掉goldengate相关的进程。
14）主键冲突数据排除
主键冲突数据的排查是一个很重要的环节，如果之前的准备工作不到位，到了生产之后，那就是数据灾难。大半夜修复数据的痛苦真是不言而喻啊。如果数据前一部分不给力，你就得给力，想想办法来排查吧。
15）constraint级的数据不一致
这种问题存在而且很隐蔽，比如如下的错误。就是not null constraint在源schema中不存在，在导入目标库的时候出问题了。
cannot insert NULL into
("xxxx"."test_data"."TOT_OBLIGATION_PCT")
对于这类问题需要和数据迁移组协调，尽可能保证constraint的一致性。
16）undo的考虑
对于数据迁移来说，对于undo的空间使用来说是极大的挑战，可能在Impdp的时候出了Undo的问题，那就是极为奔溃的问题了。
还要考虑undo_retention的设置，可以在数据迁移之前可以把retention调低一些，保证undo的使用率足够用