生产环境数据迁移问题汇总(r2第16天)

在测试环境中做了3轮数据迁移的演练，最终到了生产环境中，还是出现了不少问题，经过大半夜的奋战，终于是数据都迁移成功了。 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文件来逐一恢复数据了。 不过个人总结还是觉得对于异常情况的考虑需要需要比较充分，在出问题的时候才不会乱了阵脚。

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@xxxxcontrol=./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报告来查验当时倒底有哪些瓶颈。