Oracle：Big Select语句在相同的数据库

时间：2017-05-11 22:25:45

标签： sql oracle hibernate oracle12c

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

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

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

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

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

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

当然，无论我选择了多少列，每次在我的其他数据库上完全相同的语句都能得到正确的结果。

这是两个数据库之间的区别。就像我说的那样，就表格，列，索引，约束等而言，它们的结构完全相同。但是它们以不同的方式实现了它们。

我们将调用提供错误结果数据库DATABASE A的数据库。我们将调用数据库以提供正确的结果数据库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中，该表是通过运行确切的create table脚本创建的。

在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中，第22-26列在执行BigSelect语句时返回null，即使存在值。请注意，即使稍后将COLUMN27添加到表中，它也会很好。它可能与char或默认有关吗？

我们实际上也遇到了另一个表的这个问题。我们只是在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=?

1 个答案:

答案 0 :(得分：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 Support。

相关问题
最新问题