一次IMP大表的加速导入过程

一张大表，导出的dmp文件达300多G
光copy数据文件到PC Server上就花了12个小时（100M网络）

目标是将这些数据文件中的数据导入到小型机上的数据库中
头天晚上正式开始导入，由于PC Server和小型机之间走了一堆乱七八糟的设备才通的
结果16个小时导入了1.6G，一小时100M，太慢了，一个数据文件都没导入完

受不了，重来，truncate table，同时将数据库设置到noarchivelog模式
PC Server直接接到小型机所在局域网
网卡立马显示1G，咔咔
开始重新导入，导入进去1G的数据，耗时17分钟，按20分钟算
一小时3G，300多G的文件至少需要100小时，就是4天还多的时间

数据文件有十来个，数据库为10G，目标表空间又是本地自动管理的
俺不免产生了并行导入的办法，咨询了老杨，可行
检查了一下网络利用率，天，1％都不到
太浪费这1G的网速了
于是开了仨进程，buffer开到512M
再同时ftp到俩小型机上（Oracle做的RAC）
将较大的几个数据文件分别传上去
然后每个小机各开两个进程导入dmp文件，buffer一样是开到512M
后台开启一个job，检测数据的导入情况
发现速度最高的时候，1小时竟然导入了20多G的数据，哈哈

第二天一看，差不多24小时的时间，完成了300多G数据的导入
再次感谢老杨



后记：
导入采用了commit=y参数
看了 http://www.itpub.net/viewthread.php?tid=699653&highlight=imp 才知道
原来这是效率非常低的一种做法
不过想了一下，高峰时期7个进程同时导入数据，我那64G的UNDO表空间很可能不够
再说，要是用这种方式，就没法监测导入进度了


ps：途中问题处理
1、在导入期间出过一次问题，就是笔记本IP与PC Server冲突，结果直接导致数据文件导入进程失败
而且无法回退（因为加了commit=y参数），只好truncate再重来
2、ftp的时候没注意到默认是按ascii方式传输的，命令行的ftp不熟悉呀，结果在小机上导入的时候发现
导入了60条数据后失败鸟，才60条，这好处理。我重新传数据文件，然后新建一个test用户，将该数据文件
中的数据导入test用户下，大约导入几千条记录后中断imp进程。然后用delete从表中删除id与test用户下同名表中
id相重的记录，正好60条   commit，ok

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/29867/viewspace-567351/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/29867/viewspace-567351/