在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它表示為沒有PUSHED PREDICATE的HASH JOIN 。

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

在我們的Crystal Reports添加提示不是一個選項（至少我不相信，也有幾個報告），所以我希望我們可以弄清楚為什么性能在一個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

正如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)

那里，

動態采樣

概念應該是性能問題的關注中心（level = 2是默認值，范圍在0-11之間）。

實際上，引入了動態采樣（DS）來提高優化器生成良好執行計划的能力。 此功能已得到增強，並Dynamic Statistics in Oracle Database 12c重命名為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和Oracle Database 12c Release 1

optimizer_adaptive_statistics（OAS）

在Oracle Database 12c Release 2 。

換句話說，從Oracle Database 12c Release 1 （我們也在辦公室使用db12.1.0.2）開始，如果通過將相關參數設置為TRUE來啟用某些自適應功能，則將使用DS 。

串行語句通常運行時很短，編譯時的任何DS開銷都會對整體系統性能產生很大影響（如果語句經常被硬分析）。 對於與此配置文件匹配的系統，建議設置OAF=FALSE （ alter session set optimizer_adaptive_features=FALSE注意到

你不應該改變系統而是會話

）。

對於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查詢，您無法通過多次執行來分攤額外的編譯成本。

最后一句話，對於您的情況，將各個SQL語句的optimizer_adaptive_features參數設置為FALSE並查看獲得的結果可能是有益的。

Answer 2

我們發現了性能問題的原因。 對於使用客戶端Oracle服務器的主應用程序，DBA在系統級別更改了以下2個系統參數：

_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;

我們還發現，對於更復雜的視圖，更改以下參數可以進一步提高性能：

alter session set optimizer_features_enable="11.2.0.3";
COMMIT;