记一次Oracle 10g exp导出缓慢问题

阅读更多

某客户数据库为10.2.0.4 RAC，运行在HP-UX平台上，如下所示：

某日，在使用exp进行本地全库逻辑导出时发现很慢，导出语句的主要语法如下：
exp full=y buffer=10M  direct=y statistics=none file=..  log =..
可以看到客户对exp导出已经进行了优化，使用了直接路径导出（direct=y ），并且不导统计信息（statistics=none） ，但导出速度依然不可接受，一个晚上只导出了20G，这是极为不正常的。
数据库exp导出速度的主要影响因素如下：
 存储的I/O性能。
 exp的导出参数。
 数据库资源的争用。
exp导出期间，操作系统资源和存储I/O正常，如下所示：
Mon Jul  8 20:27:00 EAT 2013
         procs           memory                   page                              faults       cpu
    r     b     w      avm    free   re   at    pi   po    fr   de    sr     in     sy    cs  us sy id
    6     1     0  3632805  6982185    0    0     1    0     0    0     0  13059 130731  4225   5  1 94
    7     1     0  3840773  6969343    0    0     0    0     0    0     0  16492 228979  9570  15  1 84
    4     1     0  3519137  6936935    0    0     0    0     0    0     0  13698 162008  6590   8  1 91
    4     1     0  3967479  6893185    0    0     0    0     0    0     0  13660 175978  6911   9  1 90
    5     1     0  4021955  6847447    0    0     0    0     0    0     0  14958 204016  8399  10  1 89
    6     1     0  3916920  6795387    0    0     1    0     0    0     0  15059 234239  7520  11  1 88
    7     1     0  4202389  6673342    0    0     0    0     0    0     0  16642 756681 39425  16  2 83
    3     0     0  4274821  6657615    0    0     0    0     0    0     0  15079 189115  8325  11  1 88
    3     1     0  3874784  6629859    0    0     0    0     0    0     0  14310 255546 17619  14  1 85
    5     0     0  4084843  6605861    0    0     0    0     0    0     0  16176 163433  7805  12  1 87
检查了存储I/O性能和exp导出参数，确定没有问题。于是进一步检查数据库资源的争用情况。AWR报告的采样时间为为20:00至第二天8:00，即exp逻辑导出时间。如下所示：

exp导出期间，数据库的TOP 5等待事件极为不正常，几乎可以肯定不正常的等待事件才导致了exp导出缓慢，如下所示：

根据以上等待事件，可以看到SHARED POOL出现了严重问题，SQL的解析时间占DB TIME的88.56%。如下所示：

但发生故障时，系统每秒的解析数并不高，每秒解析才50个左右，如下所示：

进一步查看系统解析数最高的应用模块，发现全都是exp发起的，如下所示：

AWR报告查看到这里，就已经很明确了。接下来就查看exp最消耗资源的SQL语句，在这里主要查看最消耗CPU资源的exp语句，发现是查询SYS用户下的EXU9XML。如下所示：


而且每次执行需要读取58536个逻辑I/O。这是极为不正常的。如下所示：

而且逻辑读最高的对象为SYS用户下OPQTYPE$基表（占83.84%），这同样是极为不正常的，如下所示：

碰到这种情况，我们首先想到的是借助MOS工具，查询Oracle是否有相关BUG，果然在729248.1有相关解释，解决方法如下：
$ sqlplus /nolog

SQL> connect / as sysdba
SQL> create index OPQTYPE_IDX1 on OPQTYPE$(TYPE,BITAND (FLAGS, 2));
SQL> execute dbms_stats.gather_table_stats ('SYS', 'OPQTYPE$');
按照MOS提供的解决方法，在OPQTYPE$表建立相关索引之后，exp导出速度变为正常。
总结：
这个案例给我们的启发是当发生故障时，需要多角度的考察多个环节，然后借助MOS工具从而快速地解决问题。