外連接在Oracle 12c中查看的性能問題

Question

我的兩個客戶最近升級到Oracle 12c 12.1.0.2。自從升級以來，我在使用具有外部聯接的視圖的查詢中經歷了顯着的性能下降。以下是一個簡單查詢的示例，該查詢在舊的Oracle 11g 11.2.0.2數據庫上以秒爲單位運行，但在新的12c數據庫上需要幾分鐘時間。更令人困惑的是，這個查詢在12c數據庫之一上運行得相當快（但速度不是很快），但是完全沒有。在一個12c數據庫上，性能非常糟糕，我開發的報告無法使用。

我已經比較了11g和兩個12c數據庫之間的索引和系統參數，但沒有發現任何顯着差異。然而，Execution Plans之間有區別。在11g外部聯接表示爲VIEW PUSHED PREDICATE，但在12c上表示爲HASH JOIN而沒有PUSHED PREDICATE。

當我將提示/*+ NO_MERGE(pt) PUSH_PRED(pt) */添加到12c數據庫的查詢中時，性能在幾秒鐘內。

在我們的Crystal Reports（至少我不這麼認爲，也有幾個報告）中不提供給SQL添加提示，所以我希望我們能夠找出爲什麼性能在一個12c數據庫上可以接受但不是另一方面。

我和我的團隊對於接下來要做什麼感到困惑，特別是爲什麼兩個12c數據庫之間的響應會如此不同。我們已經在12c中研究了幾篇關於性能下降的文章，但沒有任何文章特別適用於這個特定的問題。作爲補充說明，使用表格而不是視圖的查詢會在可接受的時間範圍內返回結果。任何見解或建議將不勝感激。

查詢：

select pi.* 
, pt.* 
from policyissuance_oasis pi 
, policytransaction_oasis pt 
where 
pi.newTranKeyJoin = pt.polTranKeyJoin(+) 
and pi.policyNumber = '1-H000133' 
and pi.DateChars='08/10/2017 09:24:51' -- 2016 data 
--and pi.DateChars = '09/26/2016 14:29:37' --2013 data 
order by pi.followup_time 

Answer 1

我們發現了性能問題的原因。下面的2組系統的參數是由數據庫管理員在系統級別更改爲使用客戶的Oracle服務器的主要應用：

_optimizer_cost_based_transformation = OFF 
_optimizer_reduce_groupby_key = FALSE 

當我們在會話級別以下內容改變了他們，上面查詢加入2分返回的結果小於2秒：

alter session set "_optimizer_cost_based_transformation"=LINEAR; 
alter session set "_optimizer_reduce_groupby_key" = TRUE; 
COMMIT; 

改變這個參數並沒有對性能產生影響：

alter session set optimizer_adaptive_features=FALSE; 
COMMIT; 

我們阿爾斯o發現改變以下參數對於我們更復雜的視圖更加改善了性能：

alter session set optimizer_features_enable="11.2.0.3"; 
COMMIT; 

Answer 2

爲krokodilko說，執行這些：

explain plan for 
select pi.* 
, pt.* 
from policyissuance_oasis pi 
, policytransaction_oasis pt 
where 
pi.newTranKeyJoin = pt.polTranKeyJoin(+) 
and pi.policyNumber = '1-H000133' 
and pi.DateChars='08/10/2017 09:24:51' -- 2016 data 
--and pi.DateChars = '09/26/2016 14:29:37' --2013 data 
order by pi.followup_time; 
select * from table(dbms_xplan.display()); 

，然後，你可能看到這個在計劃的底部：

Note 
----- 
    - dynamic statistics used: dynamic sampling (level=2) 

那裏，

dynamic sampling

概念應該是性能問題（等級= 2是默認值，0-11之間的範圍內）關注的中心。實際上，引入了動態採樣（DS）來提高優化器生成良好執行計劃的能力。此功能已得到增強並重命名爲Dynamic Statistics in Oracle Database 12c。最常見的誤解是，DS可以用作優化器統計的替代，而DS的目標是增加optimizer statistics;當regular statistics不足以獲得高質量的基數估計值時使用它。

對於串行SQL語句dynamic sampling level由

optimizer_dynamic_sampling

參數控制，但注意，從Oracle Database 12c Release 1的SQL plan directives的存在也可以啓動dynamic statistics聚會時，查詢編譯。這是自適應統計的特徵，並且通過數據庫參數

optimizer_adaptive_features (OAF)

在Oracle Database 12c Release 1和

optimizer_adaptive_statistics (OAS)

在Oracle Database 12c Release 2控制。

換句話說，從Oracle Database 12c Release 1（我們也是在辦公室中使用db12.1.0.2）起，DS將用於如果某些自適應功能由相關的參數設置爲啓用TRUE。

串行語句的運行時間通常很短，編譯時的任何開銷都會對整個系統性能產生很大的影響（如果語句經常被解析）。爲了匹配這個配置文件系統，設置OAF=FALSE建議（alter session set optimizer_adaptive_features=FALSE通知，

you shouldn't alter system but session

）。

對於Oracle Database 12c Release 2 onwards，建議使用默認的OAS=FALSE。

Parallel statements通常更耗費資源，所以在編譯時往往值得投入額外的開銷以潛在地找到更好的SQL execution plan。

對於serial type SQL statements，您可以嘗試手動設置optimizer_dynamic_sampling的值（假設沒有相關的SQL計劃指令）。如果我們針對具有並行屬性集的較大表格發出類似的查詢風格，我們可以看到動態採樣踢入。

何時應該使用dynamic sampling？當您知道由於複雜的謂詞而導致執行計劃錯誤時，通常會推薦使用DS。但是不應該像我之前提到的那樣是全系統的。

什麼時候使用dynamic sampling不是個好主意？ 如果查詢編譯時間需要儘可能快，例如，不重複OLTP查詢，您無法在許多執行中分攤編譯的額外成本。

As the last word, for your case, it could be beneficient to set optimizer_adaptive_features parameter to FALSE for individual SQL statements and see the gained results.