exp与expdp在超大表导出的一些体验

  我平时用imp/exp更多，但有一次impdp导入1千多万数据的速度给了我很深的印象，于是有一种“IMPDP/EXPDP速度比imp/exp速度更快的观点。这次需要导出两张大表（一张10亿1个T，一张55亿记录2T），自然就首选了expdp; 

  但是感觉expdp导出非常的慢，由于表很大，所以我加了compress=all的参数，界面久久地停留在Processing object type TABLE_EXPORT/TABLE/STATISTICS/TABLE_STATISTICS这一行，感觉还没有进入正式的导出，但从OS看，文件也是在缓慢增长的，导出进程的等待事件是wait for unread message on broadcast channel，alert.log中并没有什么错误，先是尝试删除一些以前没有完成的导出任务的表，再重启导出，但没有效果，然后尝试了对session进行10046跟踪，但仍没有什么有用的发现，于是让它在后台运行，不过同时开启了exp来导出数据，没有压缩，并启用直接路径，感觉文件的增长快得多，一个小时后，数据就导完了；后来看expdp的完成时间，一共有4个小时多；

      当然这样比是有些不公平的，因为没有压缩，DMP文件是压缩后的三倍多，后来也gzip来压缩，发现4个小时还没有跑完；

      另一个2T的表是间隔分区，结果EXP报错了：EXP-00006: internal inconsistency error EXP-00000: Export terminated unsuccessfully,后来才想起EXP是不支持间隔分区的，所以只能用expdp,不过这一次，把并行加到了4，很快就进行了分区的导出中，没有在统计信息那里停留，不断地有分区被导出，看起来工作很正常，只是表太大了，跑了4个小时还没有完成，只能慢慢等了；

    其实在这里也遇到了一个坑，就是报ORA-19505, ORA-27037 No such file or directory错误，并行4个，3个正常，一个老报错，后来才发现它的并行是分布在RAC的两个节点的，导出路径是本地节点的，所以另一个节点自然是找不到文件了，这个需要加cluster=no参数。

    后来才发现metrics=y与trace= 480300这两个参数，在诊断expdp慢的时候或许有些作用，下次再尝试一下。

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

转载于:http://blog.itpub.net/13365316/viewspace-2564663/