Data Pump Import速度问题

on

平台:HP安腾2
操作系统:Redhat Enterprise Linux 4
数据库版本:Oracle 10.2.0.2
架构:6节点RAC

问题现象:
用数据泵方法导出一个表的两个分区数据很快,而导入却很慢

数据:
用数据泵导出,速度为29万条/秒(37MB/秒)
用数据泵导入,速度为300条/秒(39KB/秒)

解决过程:
开始没有看到环境,个人猜测也许是6节点的RAC在数据导入的时候同步Buffer Cache导致速度变慢,也许将涉及到Oracle本身的bug,所以建议用户可以先在单节点的同样环境中作一次测试,但是客户暂时没有单节点的环境。
于是在同样的6节点RAC环境中再作一个Data Pump导入,期间检查V$SESSION_WAIT,多次执行,发现确实有gc相关的等待事件,但是并不明显,然后查看V$ACTIVE_SESSION_HISTORY,用下面的SQL:
select sum(time_waited), event
from v$active_session_history
where session_id = 501
group by event
order by 1 desc;

此时问题很明显的暴露出来了,大量的时间耗费在log file switch completion和log file switch (checkpoint incomplete)这两个事件上,于是查看数据库的redo logfile大小,发现只有50M。
由于客户的数据库运行在非归档模式上,所以直接将redo文件加大到1G,再次测试,速度超乎想像。客户很爽,我也很爽。

结论:
1。在没有V$ACTIVE_SESSION_HISTORY的10g以前版本中,不要奢望能通过频繁查询V$SESSION_WAIT来定位问题。
2。Oracle的bug虽然不少,但是也没有想象中那么多。

3 Comments Add yours

  1. 同事Operation DBA 回家生小孩,休一年产假,今天要面试一个来自IBM的Sr. DBA contractor,
    除了正好用Fenng的DB_FILE_MULTIBLOCK_READ_COUNT作为一个题目,
    redo logfile tuning, wait event based tuning and v$active_session_history 也可以作为一个题目.

    也在此谢过.

  2. piggy says:

    Kamus, 我突然想起你blog的名字有点问题: chanel的意思是法语“香奈儿”, channel才是频道的意思…

  3. kamus says:

    to piggy
    是,呵呵,我早就知道,我觉得香奈儿K挺不错的啊,^_^
    本来是想借用channel的,但是当时少打了一个n,后来看来chanel是香奈儿的意思,也觉得不错,就一直没改了

Leave a Reply to piggy Cancel reply

Your email address will not be published. Required fields are marked *