Oracle 12c 子查询分解内联视图现在有不好的计划？

Question

11 月 2 日更新

经过一些额外的故障排除后，我的团队能够将这个 Oracle 错误直接与查询停止工作前一天晚上在 12c 数据库上所做的参数更改联系起来。在遇到与此数据库相关的应用程序的一些性能问题后，我的团队让我们的 DBA 将 OPTIMIZER_FEATURES_ENABLE 参数从 12.1.02 更改为 11.2.0.4。这解决了问题应用程序的性能问题，但导致了我上面描述的错误。为了验证，我已经能够通过更改此参数在单独的环境中复制同样的问题。我的 DBA 已向 Oracle 提交了一张票，以查看此问题。

作为一种解决方法，我可以对我的查询稍作更改以检索预期结果。具体来说，我将Subquery1 与Subquery2 组合在一起，并将Subquery1 中的一些谓词从WHERE 子句移到JOIN （它们更适合归属）。此更改编辑了我的执行计划（它的效率略低于之前列出的内容），但足以解决最初的问题。

---

原帖

首先，让我为这个问题的含糊之处道歉，但我正在处理一个机密的金融系统，所以我不得不隐藏某些实施细节。

背景

我有一个很久以前投入生产的Oracle 查询，在从11g 升级到12c 之后巧合地最近停止产生预期结果。据我（和我的生产支持团队）所知，此查询在此之前已经运行了一年多。

详情

查询过于复杂且效率不高，但这在很大程度上是因为我正在处理非规范化表（历史上以大型机建模）和来自上游系统的不良数据输入。为了处理复杂的业务情况，我利用了多个级别的子查询因子（WITH 语句），然后我的最终语句将两个内联视图连接在一起。没有所有复杂谓词的查询的基本结构如下：

我有 3 张桌子 Table1、Table2、Table3。 Table1 是一个处理表，由来自Table2 的记录组成。

--This grabs a subset from Table1
WITH Subquery1 as (
   SELECT FROM Table1),

--This eliminates certain records from the first subset based on sister records 
--from the original source table 
Subquery2 as (
   SELECT FROM Subquery1
   WHERE NOT EXISTS FROM (SELECT from Table2)),

--This ties the records from Subquery2 to Table3
Subquery3 as (
   SELECT FROM Table3
   JOIN (SELECT Max(Date) FROM Table3)
   JOIN Subquery2)

--This final query evaluates subquery3 in two different ways and 
--only takes those records which fit the criteria items from both sets
SELECT FROM 
(SELECT FROM Subquery3)             -- Call this Inline View A
JOIN (SELECT FROM Subquery3)        -- Call this Inline View B

最终查询非常基本：

   SELECT A.Group_No, B.Sub_Group, B.Key, B.Lob               
   FROM   (SELECT Group_No, Lob, COUNT(Sub_Group) 
           FROM   Subquery3 
           GROUP BY Group_No, Lob
           HAVING COUNT(Sub_Group) = 1) A 
   JOIN (SELECT Group_No, Sub_Group, Key, Lob
         FROM   Subquery3 
         WHERE  Sub_Group LIKE '0000%') B 
   ON A.Group_No = B.Group_No
   AND A.Lob = B.Lob

问题

如果我编辑最终查询以删除第二个内联视图并评估 A 内联视图的输出，我会得到 0 个返回的行。我已经手动评估了每个单独子查询的记录，并且可以确认这是预期结果。

同样，如果我编辑最终查询以仅生成“B”内联视图的输出，我会得到 6 个返回的行。同样，我手动评估了数据，这完全符合预期。

现在，当将这两个子集（内联视图 A 和内联视图 B）连接在一起时，我希望最终查询结果为 0 行（因为完整集和空集之间的内连接会产生无匹配）。但是，当我如上所述使用内部联接运行整个查询时，我得到了 1158 行！

我已经查看了执行计划，但没有任何问题：

问题

很明显，我做了一些事情来混淆 Oracle 优化器，并且更新后的查询计划正在拉回一个与我提交的查询完全不同的查询。我最好的猜测是，所有这些临时视图都在同一个查询中浮动，我混淆了 Oracle 以评估它所依赖的某个集合之前的某些集合。

直到今天，我一直无法在 WITH 语句周围找到官方 Oracle 文档，因此我对评估子查询的顺序从未完全有信心。我在搜索 SO（现在找不到）时确实注意到有人提到一个因式子查询不能引用另一个因式查询。我以前从不知道这是真的，但上面奇怪的输出让我想知道我之前是否只是幸运地使用了这个查询？

谁能解释我看到的行为？我是否试图用这个查询计划做一些明显不正确的事情？或者，是否有任何可能在 11g 和 12c 之间发生了一些变化，这可以解释为什么这个查询的行为可能发生了变化？

Answer 1

这听起来像是 Oracle 中的“错误结果”错误。这些错误通常非常特定于您使用的版本和功能。您发布的查询或执行计划没有明显问题。

您有两种处理方式：

1. 尝试找出确切的错误。您对公用表表达式所做的工作看起来不错。有时您的查询在技术上是无效的，您在一个版本中获得“幸运”并且它可以工作，而当您升级时它会失败。但是当这种情况发生时，新版本通常会抛出错误，而不是返回错误的结果。您正在使用的一些非常奇怪的特定功能组合可能会导致问题。要找到真正的问题，您需要大量简化查询，直到您可以进行最小的更改并看到问题出现和消失。您还需要删除所有对象并仅使用DUAL。此过程可能需要数小时。最后，如果您只剩下几行代码，请在此处发布它们、查看 Oracle 支持或创建服务请求。
2. 避免该错误。即使您完成了上述步骤，也可能无法修复。有时最好的解决方法是做一些不同的事情。深入了解每个问题是件好事，但你并不总是有时间。相反，请尝试以语法不同但逻辑等效的方式重新编写查询。删除部分或全部公用表表达式，甚至可能重复一些 SQL。但请务必留下评论，警告未来的程序员您为什么会以奇怪的方式做事。