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