1

最初のsomの基本。

Java 6 OJDBC6 Oracle 10.2.0.4（11gバージョンでも同じ結果）

OJDBC6クライアントを使用してJavaから実行し、おそらくネイティブ/OCIドライバーを使用するツールSQLGateを使用すると、SQLステートメントの動作が異なることがあります。何らかの理由で、オプティマイザはJavaで実行されたステートメントにハッシュ結合を使用することを選択しますが、他のステートメントには使用しません。

表は次のとおりです。

CREATE TABLE DPOWNERA.XXX_CHIP (
   xxxCH_ID        NUMBER(22)       NOT NULL, 
   xxxCHP_ID       NUMBER(22)       NOT NULL, 
   xxxSP_ID        NUMBER(22)           NULL, 
   xxxCU_ID        NUMBER(22)           NULL, 
   xxxFT_ID        NUMBER(22)           NULL, 
   UEMTE_ID        NUMBER(38)           NULL, 
   xxxCH_CHIPID    VARCHAR2(30)     NOT NULL
)

インデックス：

ALTER TABLE DPOWNERA.XXX_CHIP ADD
  (
     CONSTRAINT IX_AK1_XXX_CHIPV2
     UNIQUE ( XXXCH_CHIPID )
     USING INDEX
     TABLESPACE DP_DATA01 
     PCTFREE 10
     INITRANS 2
     MAXTRANS 255
     STORAGE (
        INITIAL 128 K
        NEXT 128 K
        MINEXTENTS 1
        MAXEXTENTS UNLIMITED
    )
);

これが私が使用したSQLです：

SELECT *
    FROM   (SELECT m2.*,
            rownum rnum
            FROM   (SELECT m_chip.xxxch_id,
                      m_chip.xxxch_chipid
                      FROM   xxx_chip m_chip
                      ORDER  BY m_chip.xxxch_chipid) m2
            WHERE  rownum < 101)
WHERE  rnum >= 1;

そして最後に、説明計画からの抜粋：

SQLツールクエリ：

OPERATION        OBJECT_NAME         COST  CARDINALITY CPU_COST
---------------- ------------------- ----- ----------- ----------
SELECT STATEMENT NULL                    2          10      11740
VIEW             NULL                    2          10      11740
COUNT            NULL                 NULL        NULL       NULL
VIEW             NULL                    2          10      11740
NESTED LOOPS     NULL                    2          10      11740
TABLE ACCESS     XXX_CHIP                1     1000000       3319
INDEX            IX_AK1_XXX_CHIPV2       1          10       2336
TABLE ACCESS     XXX_CUSTOMER            1           1        842
INDEX            IX_PK_XXX_CUSTOMER      1           1        105

QQL JavaクエリOJDBCシンクライアント：

**OPERATION        OBJECT_NAME         COST  CARDINALITY CPU_COST**
SELECT STATEMENT NULL                15100         100 1538329415
VIEW             NULL                15100         100 1538329415
COUNT            NULL                 NULL        NULL       NULL
VIEW             NULL                15100     1000000 1538329415
SORT             NULL                15100     1000000 1538329415
HASH JOIN        NULL                 1639     1000000  424719850
VIEW             index$_join$_004        3           3    2268646
HASH JOIN        NULL                 NULL        NULL       NULL
INDEX            IX_AK1_XXX_CUSTOMER     1           3        965
INDEX            IX_PK_XXX_CUSTOMER      1           3        965
TABLE ACCESS     xxx_CHIP             1614     1000000  320184788

だから、なぜハッシュ結合がオプティマイザーによって選択されるのか迷っていますか？私の推測では、varchar2の扱いは異なります。

4

1 に答える 1

2

答えを見つけたのですが、思ったより簡単でした。それはすべて、インデックス列のVARCHAR2データ型と関係があります。私のデータベースは言語と国「en」、「US」に設定されていましたが、ローカルでは別の言語と地域があります。したがって、オプティマイザーは、クライアントと同じ言語と国で構成されていないため、インデックスを正しく破棄しました。

それで、私がテストしたのは、eclipse.iniファイルに入力されたいくつかの追加の-Dパラメーターを使用してeclipseを開始することでした。

-Duser.language=en
-Duser.country=US
-Duser.region=US

次に、Eclipseのデータソースエクスプローラーで、接続を作成してステートメントを実行しましたが、それは魅力のように機能しました。

したがって、学んだ教訓は、クライアントとデータベースが言語的に互換性があることを常に確認することです。おそらく変更するので、データベースでUTF-8を使用するので、すべてのインストールで同じです。それ以外の場合は、国と言語に応じて、インストールごとに構成する必要があります。

これが誰かを助けることを願っています。答えが不明な場合はコメントを投稿してください。

于 2011-11-20T08:59:46.130 に答える