Oracle：Big Select 语句在相同的数据库上给出不同的结果答案

【问题标题】：Oracle: Big Select statement gives different results on identical databasesOracle：Big Select 语句在相同的数据库上给出不同的结果
【发布时间】：2017-10-11 02:43:18
【问题描述】：

我有一个非常奇怪的问题。基本上，我对结构相同的 2 个数据库运行相同的查询，并且对于其中一个数据库上有数据的某些列，我得到空值。

我有 2 个结构相同的数据库，但以不同的方式获得该结构（我稍后会解释）。这是版本。

Oracle Database 12c 企业版 12.1.0.1.0 - 64 位生产
PL/SQL 版本 12.1.0.1.0 - 生产
核心 12.1.0.1.0 生产
适用于 Solaris 的 TNS：版本 12.1.0.1.0 - 生产
NLSRTL 版本 12.1.0.1.0 - 生产

Hibernate 正在从数据库中检索一些数据。我排除了休眠是问题的原因，因为通过一些调试跟踪，我发现了有问题的 sql 语句。当我在我的 2 个数据库上运行该语句时，我得到了 2 个不同的结果。

此 select 语句有 17 个 LEFT OUTER JOINS 并选择 230 列。我将把它称为 BigSelect 语句。就像我说的那样，对于其中一个数据库上有数据的某些列，我得到了 null。

现在得到这个。当我将语句收集的列数减少到 137 时，我得到了正确的结果。如果是 138，我缺少数据。如果小于 137，一切正常。

当然，无论我选择多少列，我的另一个数据库上的完全相同的语句每次都会得到正确的结果。

这是两个数据库之间的区别。就像我说的，它们在表、列、索引、约束等方面的结构是相同的。但是它们以不同的方式到达那里。

我们将给出错误结果的数据库称为 DATABASE A。我们将给出正确结果的数据库称为 DATABASE B。

这是两个数据库中的表：

create table TABLE3
(
    COLUMN1 number(10),
    COLUMN2 number(10) REFERENCES TABLE(COLUMN2) not null,
    COLUMN3 varchar2 (15) not null,
    COLUMN4 nvarchar2 (100) not null,
    COLUMN5 number(10) references TABLE1(COLUMN5) not null, 
    COLUMN6 varchar2 (30),
    COLUMN7 varchar2(25) not null,
    COLUMN8 binary_double,
    COLUMN9 number(10), 
    COLUMN10 number(10),
    COLUMN11 char(1) default 'N',
    COLUMN12 number(10) default 2 not null,
    COLUMN13 number(10) default 1 not null,
    COLUMN14 number(10) default 1 not null,
    COLUMN15 number(10) default 7,
    COLUMN16 number(7,2) default 99999,
    COLUMN17 number(7,2) default 99999,
    COLUMN18 number(7,2) default 99999,
    COLUMN19 number(7,2) default 99999,
    COLUMN20  number(10) default -1,
    COLUMN21 number(10) default 1,
    COLUMN22 char(1) default 'C',
    COLUMN23 char(1) default 'C',
    COLUMN24 char(1) default 'N',
    COLUMN25 char(1) default 'C',
    COLUMN26 char(1) DEFAULT 'C',
    COLUMN27 BINARY_DOUBLE,
    COLUMN28 char(1) default 'Y',
    primary key (COLUMN1),
    UNIQUE (COLUMN3,COLUMN2)
);

在 DATABASE B 中，此表是通过运行确切的创建表脚本来创建的。

在 DATABASE A 中，首先创建的表没有第 22 - 27 列，这些列后来被添加到表中。以下是可以运行的脚本。

create table TABLE3
(
    COLUMN1 number(10),
    COLUMN2 number(10) REFERENCES TABLE(COLUMN2) not null,
    COLUMN3 varchar2 (15) not null,
    COLUMN4 nvarchar2 (100) not null,
    COLUMN5 number(10) references TABLE1(COLUMN5) not null, 
    COLUMN6 varchar2 (30),
    COLUMN7 varchar2(25) not null,
    COLUMN8 binary_double,
    COLUMN9 number(10), 
    COLUMN10 number(10),
    COLUMN11 char(1) default 'N',
    COLUMN12 number(10) default 2 not null,
    COLUMN13 number(10) default 1 not null,
    COLUMN14 number(10) default 1 not null,
    COLUMN15 number(10) default 7,
    COLUMN16 number(7,2) default 99999,
    COLUMN17 number(7,2) default 99999,
    COLUMN18 number(7,2) default 99999,
    COLUMN19 number(7,2) default 99999,
    COLUMN20  number(10) default -1,
    COLUMN21 number(10) default 1,
    COLUMN28 char(1) default 'Y',
    primary key (COLUMN1),
    UNIQUE (COLUMN3,COLUMN2)
);

alter table TABLE3 add COLUMN22 char(1) default 'C';
alter table TABLE3 add COLUMN23 char(1) default 'C';
alter table TABLE3 add COLUMN24 char(1) default 'N';
alter table TABLE3 add COLUMN25 char(1) default 'C';
alter table TABLE3 add COLUMN26 char(1) DEFAULT 'C';
alter table TABLE3 add COLUMN27 BINARY_DOUBLE;

在 DATABASE B 中，执行 BigSelect 语句时，所有列都被正确选择。在 DATABASE A 中，当执行 BigSelect 语句时，第 22-26 列返回 null，即使那里有值。请注意，即使后来将它添加到表中，COLUMN27 也可以正常运行。会不会和 char 或 default 有关系？

实际上，我们在另一张桌子上也遇到了这个问题。我们只是在 DATABASE A 中删除了该表并重新创建它并解决了问题。这可能也适用于该表，但我们希望找到问题的根源，以便将来避免它。

为什么它适用于 137 列，而不适用于 138 列？我没有发现您可以从 Oracle 中选择的列数有任何限制。

如果我们在创建数据库后向数据库添加列，为什么情况会有所不同？为什么第 22-26 列不起作用，但第 27 列起作用？

我们在这里几乎没有想法。我们感谢任何建议。

编辑：这是大 Select 语句的一部分。很简单，从我所看到的情况来看，这里没有什么棘手的事情

SELECT table4_1.T4C4                AS T4C4   18_30_15_,
    table4_1.T4C1                            AS T4C115_,
  table4_1.T4C1                            AS T4C131_14_,
  table4_1.T4C17                   AS T4C17_31_14_,
  table4_1.T4C2                 AS T4C2_31_14_,
  table4_1.T4C3                        AS T4C331_14_,
  table4_1.T4C5               AS T4C5,
  table4_1.T4C6                  AS T4C6,
  table4_1.T4C7             AS QTY7_31_14_,
  table4_1.T4C8                  AS T4C7,
  table4_1.T4C9                   AS T4C9,
  table4_1.T4C10                 AS T4C10,
  table4_1.T4C11               AS T4C11,
  table4_1.T4C12                 AS T4C12,
  table4_1.T4C13               AS T4C13,
  table4_1.T4C14                 AS T4C14,
  table4_1.COLUMN1                             AS COLUMN1,
  table4_1.T4C4                     AS T4C4   T4C4,
  table4_1.COLUMNA                           AS COLUMNA,
  table4_1.COLUMND                AS COLUMND,
  table4_1.COLUMNF                            AS COLUMNF31_14_,
  table4_1.T4C15                AS T4C15,
  table4_1.T4C16              AS T4C16,
  table3_1.COLUMN1                             AS COLUMN120_0_,
  table3_1.COLUMN28                          AS COLUMN2820_0_,
  table3_1.COLUMN24        AS COLUMN24,
  table3_1.COLUMN7                   AS COLUMN7,
  table3_1.COLUMN22                       AS COLUMN22,
  table3_1.COLUMN15                 AS COLUMN15,
  table3_1.COLUMN7                            AS COLUMN7,
  table3_1.COLUMN10          AS COLUMN10,
  table3_1.COLUMN27          AS COLUMN27,
  table3_1.COLUMN11        AS COLUMN11,
  table3_1.COLUMN23        AS COLUMN23,
  table3_1.COLUMN14            AS COLUMN14,
  table3_1.COLUMN3                      AS COLUMN3,
  table3_1.COLUMN4                    AS COLUMN4,
  table3_1.COLUMN21               AS COLUMN21,
  table3_1.COLUMN5                             AS COLUMN5,
  table3_1.COLUMN26                   AS COLUMN26,
  table3_1.COLUMN25         AS COLUMN25,
  table3_1.COLUMN8              AS COLUMN8,
  table3_1.COLUMN9              AS COLUMN9,
  table3_1.COLUMN2                        AS COLUMN2,
  table3_1.COLUMN20                     AS COLUMN20,
  table3_1.COLUMN16                 AS COLUMN16,
  table3_1.COLUMN2               AS COLUMN2,
  table3_1.COLUMN2                 AS COLUMN2,
  table3_1.COLUMN17                  AS COLUMN17,
  table3_1.COLUMN12          AS COLUMN12,
  table3_1.COLUMN13                   AS COLUMN13,
  table1_1.COLUMN5                             AS COLUMN517_1_,
  .....(230 TOTAL COLUMNS SELECTED)...
FROM TABLE4 table4_1
LEFT OUTER JOIN TABLE3 table3_1
ON table4_1.COLUMN1=table3_1.COLUMN1
LEFT OUTER JOIN TABLE1 table1_1
ON table3_1.COLUMN5=table1_1.COLUMN5
LEFT OUTER JOIN TABLE5 table5_1
ON table3_1.COLUMN1=table5_1.COLUMN1
LEFT OUTER JOIN TABLE6 table6_1
ON table3_1.COLUMN1=table6_1.COLUMN1
LEFT OUTER JOIN TABLE7 table7_1
ON table4_1.COLUMNA=table7_1.COLUMNA
LEFT OUTER JOIN TABLE3 table3_2
ON table7_1.COLUMN1=table3_2.COLUMN1
LEFT OUTER JOIN TABLE8 table8_1
ON table7_1.COLUMNB=table8_1.COLUMNB
LEFT OUTER JOIN TABLE9 table9_1
ON table8_1.COLUMNC=table9_1.COLUMNC
LEFT OUTER JOIN TABLE10 table10_1
ON table4_1.COLUMND=table10_1.COLUMND
LEFT OUTER JOIN TABLE11 table11_1
ON table10_1.COLUMNE=table11_1.COLUMNE
LEFT OUTER JOIN TABLE12 table12_1
ON table4_1.COLUMNF=table12_1.COLUMNF
LEFT OUTER JOIN TABLE3 table_3_3
ON table12_1.COLUMN1=table_3_3.COLUMN1
LEFT OUTER JOIN TABLE13 table13_1
ON table12_1.COLUMNG=table13_1.COLUMNG
LEFT OUTER JOIN TABLE14 table14_1
ON table13_1.COLUMNH         =table14_1.COLUMNH
WHERE table4_1.T4C4=?

【问题讨论】：

您是否在数据已经存在时添加了列？
我认为默认值仅在您插入数据时适用，而不是在添加表中已有数据的列时适用
@maSTAShuFu 我已经删除了表的内容，并在第 22 - 27 列中添加了新行，但仍然出现错误。
是有错误还是只是一个问题？
您可能想在此处发布您的加入声明

标签： sql oracle hibernate oracle12c

【解决方案1】：

如果您看到的是 NULL 而不是 DEFAULT 值（而不是 NULL 而不是显式设置的值），我怀疑这是由于 Oracle 在添加具有默认值的列时使用的一些奇怪的规则。

他们引入了一种工具，这样，如果您添加具有 NOT NULL 约束和 DEFAULT 值的列，那么它将将该默认值存储在元数据中，而不是将其应用于每个预先存在的记录。查询时，它会将其从元数据中提取出来。在 USER_TAB_COLUMNS 中应该有一个可见的 DEFAULT_ON_NULL 来表明这一点。

这些列是否一次添加了 NOT NULL，然后变为可空？（可能已删除并重新添加）

数据是否通过非传统方式加载（例如分区交换、可传输表空间、数据泵）？

列是否被索引（这意味着值可能来自索引结构或基础表）？

是否涉及压缩？（多行的值将来自一个块的一个点）

https://www.pythian.com/blog/adding-columns-with-default-values-and-not-null-in-oracle-11g/

PS。这真的需要去 Oracle 支持。

【讨论】：

嗨，Gary，我得到的是 NULL，而不是显式设置的值，并且列在任何时候都不是 NOT NULL。我在 SQL Developer 中通过简单的休眠保存和手动插入单行添加了数据。