根据Oracle的文档的描述,数据泵采用不同的方式导出导入,性能也会有明显的差别,这次正好有机会测试一下,迁移表空间、直接路径、外部表方式,以及数据库链方式导出、导入的性能差异。
数据泵不同工作方式性能比较(一):http://yangtingkun.itpub.net/post/468/496368
数据泵不同工作方式性能比较(二):http://yangtingkun.itpub.net/post/468/496396
数据泵不同工作方式性能比较(三):http://yangtingkun.itpub.net/post/468/496397
数据泵不同工作方式性能比较(四):http://yangtingkun.itpub.net/post/468/496398
数据泵不同工作方式性能比较(五):http://yangtingkun.itpub.net/post/468/496399
这篇总结一下数据泵不同工作方式的性能差异。
之所以写了这六篇文章,是因为在看Oracle的官方文档工具手册的时候,Oracle明确的说明了这四种方式的效率,TRANSPORT TABLESPACE > DIRECT > EXTERNAL TABLE > NETWORK LINK。所以打算验证一下Oracle给出的结论。
首先看看经过前面的测试,目前得到的测试数据:
SQL> SELECT * FROM T_EXPDP_IMPDP_RECORD;
TYPE EXPDP_TIME TRANS_TIME IMPDP_TIME OTHER_TIME TOTAL_TIME
-------------------- ---------- ---------- ---------- ---------- ----------
TRANSPORT_TABLESPACE 61 2639 262 58 3020
DIRECT 289 623 866 150 1928
NETWORK_LINK 0 0 2076 150 2226
EXTERNAL_TABLE 445 623 952 150 2170
SQL> SELECT TYPE,
2 TOTAL_TIME,
3 ROUND(EXPDP_TIME/TOTAL_TIME*100, 2) EXPDP_RATE,
4 ROUND(TRANS_TIME/TOTAL_TIME*100, 2) TRANS_RATE,
5 ROUND(IMPDP_TIME/TOTAL_TIME*100, 2) IMPDP_RATE,
6 ROUND(OTHER_TIME/TOTAL_TIME*100, 2) OTHER_RATE
7 FROM T_EXPDP_IMPDP_RECORD
8 ORDER BY 2;
TYPE TOTAL_TIME EXPDP_RATE TRANS_RATE IMPDP_RATE OTHER_RATE
-------------------- ---------- ---------- ---------- ---------- ----------
DIRECT 1928 14.99 32.31 44.92 7.78
EXTERNAL_TABLE 2170 20.51 28.71 43.87 6.91
NETWORK_LINK 2226 0 0 93.26 6.74
TRANSPORT_TABLESPACE 3020 2.02 87.38 8.68 1.92
根据测试的结果,直接路径用时最短:32分8秒;外部表方式次之:36分10秒;网络直接导入方式更慢:37分6秒,而传输表空间用时反而最多,居然用时50分20秒。
那么导出的结论就是直接路径、外部表和网络方式和Oracle文档描述的一致,而传输表空间导出效率最低。虽然导出的数据文件只有将近7个G,与数据文件的28G相比不算很大,但是当前的环境两个表空间的占用超过了80%,这对于大部分环境而言已经算很高的了。看来传输表空间并不像Oracle文档描述的效率最高,反而效率是最低的。
其实如果草率的就得出上面的结论,这篇文章就完全没有必要了。只需要在上面一篇文章的最后,把所有的测试结果一列,就可以结束了。
首先来看传输表空间导出模式,可以看到,整个操作的87%的时间用于网络传送。而第一篇文章单独来描述测试的环境其实是有意义的,由于当前环境是百兆网络,所以对于传送表空间的测试来说,网络性能就是性能的瓶颈所在。如果在一个千兆网中,网络速度提高10倍,则网络传送的时间将会变为1/10,这时传送表空间模式总共用时也不到11分钟,比目前速度最快的直接路径方式的导入这一个步骤还要快。因此,Oracle将传送表空间方式认为是速度最快是有道理的。何况对于有些情况而言,传输表空间是不需要网络传输的,这时传输表空间的性能优势就更加突出了。
那么对于百兆的网络而言,传送表空间是否优势不明显呢。其实也不见得,为了测试的方便,在这个例子中并没有对网络传输的对象进行压缩,如果网络传输成为瓶颈,那么可能压缩会带来一定的性能提升。当然压缩能否带来性能提升除了与压缩对象的大小已经网络传输速率有关,还与其他硬件的情况,比如CPU、内存和磁盘的IO能力有关。
其实从道理上也可以很容易分析,对于传输表空间方式,由于不需要逻辑方式处理数据,因此唯一耗时的就是数据文件的拷贝。对于当前环境,网络成为性能的瓶颈,那么传输表空间显然不会有太好的性能表现。举个极端的例子,如果网络条件是专线,至于10M甚至更少的传输速率,那么这种情况下使用传输表空间方式,绝对是噩梦的开始。
对于直接路径、外部表方式和网络导出方式而言,得到的结果基本上和预期一致。除了刚才提到的压缩导出文件来提高网络传送文件性能外,还可以采用并行的方式来提高导出和导入的性能。如果IO处理能力足够,使用并行能明显的提高导出和导入的速度。
至于外部表方式效率较低其实也不用过于关心,只要可能Oracle会自动使用直接路径方式进行导出和导入,只有条件不满足直接路径方式时,才会使用外部表方式。而且即使使用外部表,也不会想这个例子中,对所有表的导出和导入都使用外部表,而只是个别不满足直接路径条件的才使用外部表,因此不会带来太大的性能影响。
网络导出方式的效率最低,但是与其他方式相比,并没有数量级上的差异。如果只是将网络导出与直接路径、外部表导出做比较,或者将网络导入,与直接路径、外部表导入进行对比,都是不公平的,因为网络导出还要包括传送数据的步骤,而网络的导入不仅包括传送数据,还包括导出操作。
不过这篇中采用的对比方式,网络导入方式其实会占一定的便宜,因为这种方式不像外部表和直接路径那样导出就是导出,不会同时进行其他的操作,而是导出的同时数据就在传送,数据传送的同时,就在进行导入操作,可以认为是导出、数据传送和导入的并行操作。
第二个查询给出了每种数据库工作方式的各个步骤所占总体时间的百分比。通过这个结果可以找到每种类似最花费时间的操作,也就是性能瓶颈。如要进行优化,那么就可以将最大的精力放在花费时间最多的步骤上。以传输表空间方式而言,提高导出和导入的效率的意义就不大了。
对于提高数据泵的性能,找到最耗费时间的步骤,还要找到性能的瓶颈。一般而言,网络、IO能力是常见的性能瓶颈,如果这两方面都不是瓶颈,那么可能Oracle处理能力没有完全发挥出来,可以利用上面提到的并行方式来更充分的利用资源。
最后还要提一句,除了表中所列的步骤外,还有一些操作是不可避免的,比如传输表空间方式,就要进行大量的检查工作。除了检查字符集、版本以及BLOCK_SIZE之外,还要检查表空间的完整性、用户与表空间直接的关系等等。即使导出结束后,也要对比是否所有需要的对象都已经导入到目标数据库。而对于NETWORK_LINK方式而言,操作可以说是最简单的,只需要一个命令,导出、数据传输和导入就全部完成,对于数据量不是很大的情况,操作的复杂程度也是值得考虑的。
来自 “ ITPUB博客 ” ,链接:http://blog.itpub.net/4227/viewspace-626604/,如需转载,请注明出处,否则将追究法律责任。
转载于:http://blog.itpub.net/4227/viewspace-626604/