简体   繁体   English

在Oracle 12c中,具有外连接的查询行为有所不同

[英]Query featuring outer joins behaves differently in Oracle 12c

I had a problem come through concerning missing data on Oracle 12c. 有关Oracle 12c上缺少数据的问题。

I took a look at the code and found a query that works on mysql, mssql, oracle 11g, but has different behaviour in oracle 12c. 我看了一下代码,发现了一个适用于mysql,mssql,oracle 11g的查询,但在oracle 12c中有不同的行为。

I have generalized the table structure and query somewhat and reproduced the issue. 我已经概括了表结构和查询,并重现了这个问题。

create table thing (thing_id number, display_name varchar2(500));
create table thing_related (related_id number, thing_id number, thing_type varchar2(500));
create table type_a_status (related_id number, status varchar2(500));
create table type_b_status (related_id number, status varchar2(500));

insert into thing values (1, 'first');
insert into thing values (2, 'second');
insert into thing values (3, 'third');
insert into thing values (4, 'fourth');
insert into thing values (5, 'fifth');
insert into thing_related values (101, 1, 'TypeA');
insert into thing_related values (102, 2, 'TypeB');
insert into thing_related values (103, 3, 'TypeB');
insert into thing_related (related_id, thing_id) values (104, 4);

insert into type_a_status values (101, 'OK');
insert into type_b_status values (102, 'OK');
insert into type_b_status values (103, 'NOT OK');

Running the query: 运行查询:

SELECT t.thing_id AS id, t.display_name as name,
       tas.status as type_a_status,
       tbs.status as type_b_status
FROM thing t LEFT JOIN thing_related tr 
  ON t.thing_id = tr.thing_id
LEFT JOIN type_a_status tas 
  ON (tr.related_id IS NOT NULL 
      AND tr.thing_type = 'TypeA' 
      AND tr.related_id = tas.related_id)
LEFT JOIN type_b_status tbs 
  ON (tr.related_id IS NOT NULL 
      AND tr.thing_type = 'TypeB' 
      AND tr.related_id = tbs.related_id)

on Oracle 11g gives (here's a SQL Fiddle ): 在Oracle 11g上给出(这里是一个SQL小提琴 ):

ID | NAME   | TYPE_A_STATUS | TYPE_B_STATUS
 1 | first  |            OK | (null)
 2 | second |        (null) | OK
 3 | third  |        (null) | NOT OK
 4 | fourth |        (null) | (null)
 5 | fifth  |        (null) | (null)

Yet the same schema, data, and query on Oracle 12c: Oracle 12c上的相同架构,数据和查询:

ID | NAME   | TYPE_A_STATUS | TYPE_B_STATUS
 1 | first  |            OK | (null)
 2 | second |        (null) | OK
 3 | third  |        (null) | NOT OK
 4 | fourth |        (null) | (null)

It seems that the second two outer joins are failing to bring back anything because there is no row in 'thing_related' to join by. 似乎第二个两个外部联接未能带回任何东西,因为“thing_related”中没有要加入的行。 However I don't understand why the outer join does not return nulls in this case as it does in Oracle 11g, Mysql, etc.. 但是我不明白为什么外连接在这种情况下不会像在Oracle 11g,Mysql等中那样返回空值。

I've been researching and found documentation the Oracle 12c had a number of enhancements for outer joins, but nothing that highlighted a change that would affect this. 我一直在研究并发现Oracle 12c对外连接有一些增强的文档,但没有任何突出显示会影响这种情况的更改。

Does anyone know why this is happening only for Oracle 12c, and how best would I rewrite this to work in 12c and maintain compatibility with 11g, mysql, etc.? 有谁知道为什么这只发生在Oracle 12c上,我最好如何重写它在12c中工作并保持与11g,mysql等的兼容性?

EDIT: Attached plans. 编辑:附加计划。

Oracle 11g: Oracle 11g:

在此输入图像描述

Oracle 12c: Oracle 12c:

在此输入图像描述

UPDATE: This is fixed in 12.1.0.2. 更新:这在12.1.0.2中得到修复。


This definitely looks like a bug in 12.1.0.1. 这绝对看起来像12.1.0.1中的错误。 I would encourage you to create a service request through Oracle support. 我建议您通过Oracle支持创建服务请求。 They might be able to find a fix or a better work around. 他们或许可以找到解决方案或更好的解决方法。 And hopefully Oracle can fix it in a future version for everyone. 希望Oracle能够在未来版本中为每个人修复它。 Normally the worst part about working with support is reproducing the issue. 通常,使用支持的最糟糕的部分是重现问题。 But since you already have a very good test case this issue may be easy to resolve. 但是,由于您已经有一个非常好的测试用例,这个问题可能很容易解决。

There are probably many ways to work around this bug. 有很多方法可以解决这个bug。 But it's difficult to tell which method will always work. 但是很难说哪种方法总能奏效。 Your query re-write may work now, but if optimizer statistics change perhaps the plan will change back in the future. 您的查询重写现在可以正常工作,但如果优化程序统计信息发生更改,则计划将来可能会更改。

Another option that works for me on 12.1.0.1.0 is: 在12.1.0.1.0上适用于我的另一个选项是:

ALTER SESSION SET optimizer_features_enable='11.2.0.3';

But you'd need to remember to always change this setting before the query is run, and then change it back to '12.1.0.1' after. 但是您需要记住在运行查询之前始终更改此设置,然后在之后将其更改回“12 .1.0.1”。 There are ways to embed that within a query hint, such as /*+ OPT_PARAM('optimizer_features_enable' '11.2.0.3') */ . 有一些方法可以在查询提示中嵌入它,例如/*+ OPT_PARAM('optimizer_features_enable' '11.2.0.3') */ But for some reason that does not work here. 但由于某种原因,这里不起作用。 Or perhaps you can temporarily set that for the entire system and change it back after a fix or better work around is available. 或者也许您可以暂时为整个系统设置它,并在修复或更好的解决方法可用后将其更改回来。

Whichever solution you use, remember to document it. 无论您使用哪种解决方案,请记住记录它。 If a query looks odd the next developer may try to "fix" it and hit the same problem. 如果查询看起来很奇怪,那么下一个开发人员可能会尝试“修复”它并遇到同样的问题。

Refer to: 参考:

ANSI Outer Join Query Returns Wrong Results After Upgrade to 12.1.0.1 (Doc ID 1957943.1) ANSI外部联接查询在升级到12.1.0.1后返回错误的结果(文档ID 1957943.1)

Unpublished bug 16726638 未公开的错误16726638

Fixed in 12.1.0.2 (I have tested this) 在12.1.0.2中修复(我测试了这个)

Workaround (I tested in 12.1.0.1): 解决方法(我在12.1.0.1中测试过):

alter session set "_optimizer_ansi_rearchitecture"=false;          

Note 1957943.1 recommends as an alternative: 注1957943.1建议作为替代方案:

optimizer_features_enable = '11.2.0.4';

but that does not work. 但是,这并不工作。

I've a migration planned from 11gR2 to 12c and whole lot of syntax is in ANSI. 我的迁移计划从11gR2到12c,并且整个语法都是ANSI。 Its really a nightmare to test each and every query and compare it with the 11g data. 测试每个查询并将其与11g数据进行比较确实是一场噩梦。 Is setting alter session set "_optimizer_ansi_rearchitecture"=false; 设置alter session set“_optimizer_ansi_rearchitecture”= false; is the only solution or the bug is fixed 是唯一的解决方案或修复错误

声明:本站的技术帖子网页,遵循CC BY-SA 4.0协议,如果您需要转载,请注明本站网址或者原文地址。任何问题请咨询:yoyou2525@163.com.

 
粤ICP备18138465号  © 2020-2024 STACKOOM.COM