2017-05-11 30 views
1

私は本当に奇妙な問題があります。基本的には、同じ構造の2つのデータベースに対して同じクエリを実行し、データベースの1つにデータがある場合は、一部の列に対してnullが返されます。Oracle:Big Select文が同じデータベースで異なる結果を返す

私は2つのデータベースを同じ構造にしていますが、異なる方法でその構造になっています(後で説明します)。ここにバージョンがあります。

のOracle Database 12cのEnterprise Editionのリリース12.1.0.1.0 - 64ビットの生産
PL/SQLリリース12.1.0.1.0 - Solaris用の生産
CORE 12.1.0.1.0生産
TNS:バージョン12.1.0.1 .0 - Production
NLSRTLバージョン12.1.0.1.0 - Production

Hibernateはデータベースからいくつかのデータを取得しています。私は問題の原因として休止状態を除外していました。デバッグトレースがあったので、問題のSQL文が見つかりました。 2つのデータベースでステートメントを実行すると、2つの異なる結果が得られます。

このSELECT文は、LEFT OUTER JOINSが17個あり、230個の列を選択します。私はこれをBigSelectステートメントと呼ぶつもりです。そして、私が言ったように、私はデータベースの1つにデータがあるいくつかの列ではnullになっています。

これを取得します。文が137に集める列の数を減らすと、正しい結果が得られます。それが138の場合は、データが欠落しています。それが137未満の場合、すべて正常に動作します。

もちろん、私の他のデータベースの全く同じステートメントは、選択した列の数に関係なく毎回適切な結果を得ることができます。

2つのデータベースの違いは次のとおりです。私が言ったように、それらはテーブル、列、インデックス、制約などと同じように構成されています。しかし、それらはさまざまな方法でそこにあります。

我々は間違った結果データベース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) 
); 

データベースBでは、このテーブルは、まったく同じcreate tableスクリプトを実行することによって作成されました。

データベース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; 

データベースBでは、BigSelect文の実行時にすべての列が正しく選択されます。 DATABASE Aでは、値があってもBigSelect文を実行すると、カラム22-26がnullを返します。 COLUMN27は後で表に追加されても正常に機能します。それはcharまたはdefaultと何か関係がありますか?

実際には別のテーブルでこの問題も発生しました。そのテーブルをDATABASE Aに落として再作成し、問題を修正しました。それはおそらくこのテーブルでもうまくいくでしょうが、私たちは将来問題を避けるために問題の根本を見つけたいと思います。

137の列では動作しますが、138では動作しないのはなぜですか?Oracleから選択できる列の数に制限はありませんでした。

データベースを作成した後にデータベースに追加すると、さまざまな理由がありますか?なぜ列22-26は機能しませんが、列27は機能しますか?

ここでは、かなり多くのアイディアがあります。ご提案いただきありがとうございます。

編集:ここは大きなSelect文の一部です。私はあなたがNULLの代わりに(むしろ代わりに、明示的に設定された値のNULLを除く)DEFAULT値を見ている場合は、私はそれはいくつかの奇妙に起因している疑いがある

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=? 
+0

既にデータがある間に列を追加しましたか? – maSTAShuFu

+0

私はデフォルト値がデータを挿入するときにのみ適用され、テーブルにすでにデータが入っている列を追加しないときにのみ適用されると思います – maSTAShuFu

+0

@maSTAShuFuテーブルの内容を削除し、22〜27列の値を持つ新しい行を追加しました。エラー。 – Justin

答えて

1

を見ることができるものから、ここで起こってトリッキーに非常に簡単、何もありませんOracleが列をデフォルト値で追加するときに使用するルール。

NOT NULL制約とDEFAULT値を持つ列を追加すると、既存の各レコードに適用するのではなく、その既定値をメタデータに格納する機能が導入されました。クエリが実行されると、メタデータからメタデータが取り出されます。これを示すには、USER_TAB_COLUMNSにDEFAULT_ON_NULLが表示されている必要があります。

これらの列は、一度にNOT NULLで追加された後、NULL可能になりましたか? (ドロップされ、再追加される可能性があります)

データは、非従来の手段(パーティション交換、転送可能な表領域、データポンプなど)によってロードされましたか?

列はインデックスされていますか(つまり、インデックス構造またはその基礎となるテーブルの値である可能性があります)。

圧縮が行われていますか?

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

PSの(複数行の値は、ブロックに対して一箇所から来ます)。これは実際にOracleサポートに行く必要があります。

+0

こんにちはゲイリー、明示的に値を設定するのではなく、NULLを取得しています。単純な休止状態の保存とSQL Developerの単一行の手動挿入を介してデータを追加しました。 – Justin

関連する問題