案例 - EBS SQL性能诊断

 环境 Oracle 11.2.0.1,  EBS R12.1.3 ，分别有两套系统。

一个比较复杂的SQL,涉及到20多个表的一个视图，在A环境上运行很快，在B环境中运行很慢。

 

大致分析过程：

1. 我们将视图的查询部分剥离出来，在两台不同DB上的查看执行计划来检查问题在哪里。对应视图如下： apps.HW_SWIFT_PAYMENT_V 。具体SQL见如下附件。 

在数据库A, B 上分别使用 dbms_sqltune.report_sql_monitor 方式查询执行计划(这种方式得出的执行计划信息相对更加详细)，方法如下(工具为Toad)：

(1). 在数据库A上执行SQL语句，执行完毕或执行过程中可以通过如下语句查询到 SQL_ID 。
select *  from  v$sql  where  sql_text like  '%SELECT   BOOK.DESCRIPTION AS%' 
order by first_load_time  desc  ; 

(2). 在数据库A上执行如下语句。
select dbms_sqltune.report_sql_monitor(type=>'TEXT', sql_id=>'4t6jwa8nrg0dp'，report_level=>'ALL') monitor_report from dual;

点击查询出来的"HUGECLOB"值，可以看到TEXT格式的详细执行计划(最好保存为txt后以ultraEdit工具打开，看得比较清晰，这里不贴出来)。一般在SQL运行后1-3分钟内可以取到结果，SQL执行超过一定时间后查询不出执行计划(已经被删除)。
注意：不是所有的SQL都会被monitor到，如果没有看到执行计划，可以在SQL中加入 提示 /*+monitor*/ 强制对SQL进行监控。 
(3). 同样方法在数据库B上也执行SQL,并提取详细的执行计划 。执行计划见下面附件。

(4). 查看运行慢的执行计划，我们发现表AP.AP_CHECKS_ALL  使用到索引AP_CHECKS_N11， read bytes达到5G大小，对比执行速度快的数据库执行计划，此表使用到的索引是时间索引 AP_CHECKS_N1，且read bytes 比较小 。由于未能及时保存运行慢时的执行计划，这里不能贴出来。

(5). 查询此表 AP.AP_CHECKS_ALL 的大小及数据量，发下有800多万行，大小为5G多，初步判断问题出在这里 。

 

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/35489/viewspace-777368/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/35489/viewspace-777368/