在测试环境中做了3轮数据迁移的演练，最终到了生产环境中，还是出现了不少问题，经过大半夜的奋战，终于是数据都迁移成功了。
1）共享存储的配置问题
共享存储使用NFS来共享存储，但是在实际操作中发现配置出了问题，原因是因为两台服务器上的用户不同在，目标机器上没有任何写权限。
1）共享存储的配置问题
共享存储使用NFS来共享存储，但是在实际操作中发现配置出了问题，原因是因为两台服务器上的用户不同在，目标机器上没有任何写权限。
-rw-r--r-- 1
3160 dba 6608 Jun 26 23:35 tmp_gunzip.sh
-rw-r--r-- 1 3160 dba 624 Jun 26 23:30 tmp_gzip.sh
oraccbs1@ccbdbpr3:/ccbs/migration/ext_datapump/DUMP> ksh gunzip.sh
gunzip.sh[1]: tmp_gunzip.sh: cannot create [Permission denied]
最终还是采取了保守的方式，使用scp来传输文件。压缩文件后，文件的大小还是可以接受的。而且可以在数据迁移之前完成，虽然在稍后更正了nfs的配置，还是保守的使用了本地文件。
2）人为失误，遗漏了脚本
在数据迁移之前运行了一些脚本来设置table nologging,index nologging,disable trigger..结果把最重要的foreign key的脚本给遗漏了，结果在使用sqlldr加载数据的时候reject了部分的数据。
幸亏及时发现。赶紧执行disable的脚本，报了如下的错误，好吧，对于已经收影响的数据来说，只能通过.bad文件来逐一恢复数据了。
不过个人总结还是觉得对于异常情况的考虑需要需要比较充分，在出问题的时候才不会乱了阵脚。
在数据加载的过程中，cpu使用率一直上不去，开启了150个并行的insert进程，但是cpu使用率还是在90%左右，速度上不去。这和之前在测试环境的测试结果又很大的出入。
180G的内存，但是剩余内存却只有400多M
而且根据我的观察Undo的使用率极高，按照之前的统计数据来说不会这么异常。
4）升级的过程中环境非法访问
按照约定，在升级的过程中，环境是不允许开发访问的，但是在这次数据迁移中，发现有一些资源消耗比较的sql语句都是从客户端发过来的。经过确认是客户的卡发人员想查验数 据迁移的情况，这个会对数据的迁移造成一定的影响。可以通过修改数据库listener的端口号来进行屏蔽，在数据迁移完成之后，在修改端口重启监听即可，对于外部来说，就可以排除不必要的影响
5)统计信息的收集
数据迁移之后，统计信息的收集也是一个很关键的步骤，如果不进行统计信息收集，会导致执行计划有较大的误差。可能导致严重的性能问题。
但是生产系统中时间是最高贵的资源。收集统计信息会耗费不少的时间，这个时候可以根据表的大小来进行统计信息比例的调整。对于比较大的表来说，比例可以在40%左右，开启并行，速度会有一定的提升。
6）外部表加载的性能问题
在之前的测试中，外部表加载的性能还是不错的，但是在生产中发现速度一下子打了折扣，本来一分钟150万的数据加载速度。结果在生产中大概在4，5分钟的样子（150万条数据）
对于这个问题，可能还需要考虑并行的情况。因为cpu的使用率一直没有上去。需要考虑稍后抓取ash报告来查验当时倒底有哪些瓶颈。
最终还是采取了保守的方式，使用scp来传输文件。压缩文件后，文件的大小还是可以接受的。而且可以在数据迁移之前完成，虽然在稍后更正了nfs的配置，还是保守的使用了本地文件。
2）人为失误，遗漏了脚本
在数据迁移之前运行了一些脚本来设置table nologging,index nologging,disable trigger..结果把最重要的foreign key的脚本给遗漏了，结果在使用sqlldr加载数据的时候reject了部分的数据。
幸亏及时发现。赶紧执行disable的脚本，报了如下的错误，好吧，对于已经收影响的数据来说，只能通过.bad文件来逐一恢复数据了。
不过个人总结还是觉得对于异常情况的考虑需要需要比较充分，在出问题的时候才不会乱了阵脚。
ALTER TABLE xxxx
DISABLE CONSTRAINT xxxxx_ACCOUNT_1FK
*
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired
ALTER TABLE xxxx_ACCOUNT disable CONSTRAINT xxxx_ACCOUNT_1FK
*
ERROR at line 1:
ORA-00054: resource busy and acquire with NOWAIT specified or timeout expired
最后使用如下的脚本来修复，收到影响的文件有70多个，大半夜修复数据真是压力和痛苦啊。不过还好，数据都最后成功加载了。
#sqlldr xxxx/xxxx
@xxxx
control=./TEST_LOG/TEST
_BEN_sqlldr.ctl log=./TEST_LOG/Imp_sqlldr_TEST_BEN_10.log direct=false parallel=true errors=10000000 bindsize=7500000 readsize=7500000 streamsize=7500000 rows=50000 data=./TEST_DUMP/TEST_BEN_10.dat discard=./TEST
_LOG/TEST_BEN_10.di
3)内存导致的问题
在数据加载的过程中，cpu使用率一直上不去，开启了150个并行的insert进程，但是cpu使用率还是在90%左右，速度上不去。这和之前在测试环境的测试结果又很大的出入。
180G的内存，但是剩余内存却只有400多M
top - 03:48:47 up 413 days, 57 min, 11 users, load average: 7.22, 8.40, 8.79
Tasks: 1906 total, 1 running, 1905 sleeping, 0 stopped, 0 zombie
Cpu(s): 0.4%us, 0.6%sy, 0.0%ni,
98.9%id, 0.0%wa,
0.0%hi, 0.2%si, 0.0%st
Mem: 189675188k total, 189233496k used,
441692k
free, 30368k buffers
Swap: 377487328k total, 25844k used, 377461484k free, 117830432k cached
根据我的监控，发现对于大的分区表来说，剩余内存就耗尽了。并行插入数据的时候遇到了瓶颈，可能和生产库没有开启异步io有关,数据库参数为filesystem_io,当前设置为none,而在测试环境中则为setall.而且根据我的观察Undo的使用率极高，按照之前的统计数据来说不会这么异常。
4）升级的过程中环境非法访问
按照约定，在升级的过程中，环境是不允许开发访问的，但是在这次数据迁移中，发现有一些资源消耗比较的sql语句都是从客户端发过来的。经过确认是客户的卡发人员想查验数 据迁移的情况，这个会对数据的迁移造成一定的影响。可以通过修改数据库listener的端口号来进行屏蔽，在数据迁移完成之后，在修改端口重启监听即可，对于外部来说，就可以排除不必要的影响
5)统计信息的收集
数据迁移之后，统计信息的收集也是一个很关键的步骤，如果不进行统计信息收集，会导致执行计划有较大的误差。可能导致严重的性能问题。
但是生产系统中时间是最高贵的资源。收集统计信息会耗费不少的时间，这个时候可以根据表的大小来进行统计信息比例的调整。对于比较大的表来说，比例可以在40%左右，开启并行，速度会有一定的提升。
6）外部表加载的性能问题
在之前的测试中，外部表加载的性能还是不错的，但是在生产中发现速度一下子打了折扣，本来一分钟150万的数据加载速度。结果在生产中大概在4，5分钟的样子（150万条数据）
对于这个问题，可能还需要考虑并行的情况。因为cpu的使用率一直没有上去。需要考虑稍后抓取ash报告来查验当时倒底有哪些瓶颈。
