oracleexp导出慢

某客户数据库为10.2.0.4RAC，运行在HP-UX平台上，如下所示：某日，在使用exp进行本地全库逻辑导出时发现很慢，导出语句的主要语法如下：expfull=ybuffer=10Mdirect=ystatistics=nonefile=..log=..可以看到客户对exp导出已经进行了优化，使用了直接路径导出（direct=y），并且不导统计信息（statistics=none），但导出速度依然不可接受，一个晚上只导出了20G，这是极为不正常的。数据库exp导出速度的主要影响因素如下：存储的I/O性能。exp的导出参数。数据库资源的争用。exp导出期间，操作系统资源和存储I/O正常，如下所示：MonJul820:27:00EAT2013procsmemorypagefaultscpurbwavmfreereatpipofrdesrinsycsussyid6103632805698218500100001305913073142255194710384077369693430000000164922289799570151844103519137693693500000001369816200865908191410396747968931850000000136601759786911919051040219556847447000000014958204016839910189610391692067953870010000150592342397520111887104202389667334200000001664275668139425162833004274821665761500000001507918911583251118831038747846629859000000014310255546176191418550040848436605861000000016176163433780512187检查了存储I/O性能和exp导出参数，确定没有问题。于是进一步检查数据库资源的争用情况。AWR报告的采样时间为为20:00至第二天8:00，即exp逻辑导出时间。如下所示：exp导出期间，数据库的TOP5等待事件极为不正常，几乎可以肯定不正常的等待事件才导致了exp导出缓慢，如下所示：根据以上等待事件，可以看到SHAREDPOOL出现了严重问题，SQL的解析时间占DBTIME的88.56%。如下所示：但发生故障时，系统每秒的解析数并不高，每秒解析才50个左右，如下所示：进一步查看系统解析数最高的应用模块，发现全都是exp发起的，如下所示：AWR报告查看到这里，就已经很明确了。接下来就查看exp最消耗资源的SQL语句，在这里主要查看最消耗CPU资源的exp语句，发现是查询SYS用户下的EXU9XML。如下所示：而且每次执行需要读取58536个逻辑I/O。这是极为不正常的。如下所示：而且逻辑读最高的对象为SYS用户下OPQTYPE$基表（占83.84%），这同样是极为不正常的，如下所示：碰到这种情况，我们首先想到的是借助MOS工具，查询Oracle是否有相关BUG，果然在729248.1有相关解释，解决方法如下：$sqlplus/nologSQLconnect/assysdbaSQLcreateindexOPQTYPE_IDX1onOPQTYPE$(TYPE,BITAND(FLAGS,2));SQLexecutedbms_stats.gather_table_stats('SYS','OPQTYPE$');按照MOS提供的解决方法，在OPQTYPE$表建立相关索引之后，exp导出速度变为正常。总结：这个案例给我们的启发是当发生故障时，需要多角度的考察多个环节，然后借助MOS工具从而快速地解决问题。