ITPub博客

首页 > Linux操作系统 > Linux操作系统 > 案例 - EBS SQL性能诊断

案例 - EBS SQL性能诊断

原创 Linux操作系统 作者:tolywang 时间:2013-11-22 18:08:39 2 删除 编辑

 环境 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/,如需转载,请注明出处,否则将追究法律责任。

请登录后发表评论 登录
全部评论
Oracle , MySQL, SAP IQ, SAP HANA, PostgreSQL, Tableau 技术讨论,希望在这里一起分享知识,讨论技术,畅谈人生 。

注册时间:2007-12-10

  • 博文量
    5595
  • 访问量
    13337495