环境 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/