案例 - 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多，初步判斷問題出在這裡 。