当前位置:我的异常网» 数据库 » 记一次Oracle 10g exp导出缓慢有关问题
记一次Oracle 10g exp导出缓慢有关问题
www.myexceptions.net 网友分享于:2013-08-12 浏览:131次
记一次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工具从而快速地解决问题。
文章评论