DB2 10.5 for Linux, UNIX, and Windows

照会コンパイラー変数

照会コンパイラー変数を設定して、最適化に関する決定の強制適用や SQL 照会操作など、データベースに関する最適化の決定を制御できます。

DB2_ANTIJOIN
  • オペレーティング・システム: すべて
  • デフォルト = NO (ESE 環境)、デフォルト = EXTEND (非 ESE 環境)、 値: YES、NO、または EXTEND

  • この変数が YES に設定されていると、オプティマイザーでは、「NOT EXISTS」副照会を DB2 でより効率的に処理できるアンチ結合に変換する機会を探ります。

    この変数が NO に設定されていると、 オプティマイザーでは、「NOT EXISTS」副照会をアンチ結合に変換する機会を制限します。

    この変数が EXTEND に設定されていると、 オプティマイザーでは、「NOT IN」副照会および「NOT EXISTS」副照会の両方をアンチ結合に変換する機会を探ります。

    db2set コマンドに -immediate パラメーターを付けて発行した場合、この変数を変更すると、その変更はその後コンパイルされるすべての SQL ステートメントに対してただちに有効になります。 インスタンスを再始動する必要はありません。

DB2_DEFERRED_PREPARE_SEMANTICS
  • オペレーティング・システム: すべて
  • デフォルト = NO。値: YES または NO

  • このレジストリー変数を YES に設定すると、据え置き準備のセマンティクスが使用可能になり、PREPARE ステートメント内で使用されているすべての型なしパラメーター・マーカーのデータ・タイプおよび長さ属性が、後続の OPEN または EXECUTE ステートメントに関連付けられている入力記述子に基づく派生によって決まることになります。これにより、型なしパラメーター・マーカーを以前サポートされていたよりも多くの場所で使用できるようになりました。

    注: DB2_DEFERRED_PREPARE_SEMANTICS を YES に設定すると、意図しない影響または結果が発生する場合があります。 入力記述子内のデータ・タイプが型なし式のデータ・タイプの判別の規則を使用して派生したデータ・タイプと異なる場合、以下のことが発生する可能性があります。
    • 照会パフォーマンスが、追加キャスト操作のために低下します。
    • データ・タイプが変換できないために照会が失敗します。
    • 照会が異なる結果を戻す可能性があります。
    例えば、表 t1 に列 char_col があり、この列は VARCHAR(10) として定義されて、値「1」、「100」、「200」、「xxx」があるとします。 ユーザーが、以下の照会を実行します。 
    select * from t1 where char_col = ?
    入力パラメーターのデータ・タイプが INTEGER で、据え置き準備が使用されている場合、列 char_col は数値にキャストされます。ただし、照会は失敗します。表にある行の 1 つに、数値に変換できない非数値データ ('xxx') が含まれているためです。
    YES_DBCS_GRAPHIC_TO_CHAR に設定した場合、このレジストリー変数では、パラメーター・マーカーは VARGRAPHIC としてではなく VARCHAR として入力されることを示します。DB2_DEFERRED_PREPARE_SEMANTICS レジストリー変数は、 以下のすべてが当てはまる場合に、暗黙的にこの設定になります。
    • DB2_DEFERRED_PREPARE_SEMANTICS が設定されていない (つまり NULL に設定されている)。
    • DB2_COMPATIBILITY_VECTOR レジストリー変数が ORA、MYS、または MSS に設定されている。
    • 2 バイト文字セット (DBCS) 環境である。

    DB2_DEFERRED_PREPARE_SEMANTICS レジストリー変数は、db2start コマンドを発行する前に設定する必要があります。

    このレジストリー変数は、Unicode データベースと SBCS データベースでのみ推奨されています。

DB2_INLIST_TO_NLJN
  • オペレーティング・システム: すべて
  • デフォルト = NO。値: YES または NO
  • 状況によっては、SQL および XQuery コンパイラーは IN リスト述部を結合に書き換えることができます。例えば、次のような照会は、 
        SELECT *
     FROM EMPLOYEE
     WHERE DEPTNO IN ('D11', 'D21', 'E21')
    次のように書くことができます。 
        SELECT *
     FROM EMPLOYEE, (VALUES 'D11', 'D21', 'E21) AS V(DNO)
     WHERE DEPTNO = V.DNO

    DEPTNO に索引がある場合、この書き換えはより良いパフォーマンスを提供することがあります。 値のリストが最初にアクセスされて、結合述部に適用する索引を使用して NESTED LOOP 結合で EMPLOYEE に結合されます。

    場合によっては、オプティマイザーが照会の書き換えに最適な結合メソッドを判別するための正確な情報を持っていないことがあります。 IN リストにパラメーター・マーカーまたはホスト変数が含まれる場合に、このことが生じることがあります。これらはオプティマイザーがカタログ統計を使用して選択度を判別することを妨げます。 このレジストリー変数は、ホスト変数やパラメーター・マーカーを使った場合でも、 オプティマイザーが値のリストを結合するために、 IN リストを結合内の内部表として与える表を使用して、NESTED LOOP 結合を優先的に使用するようにします。

    注: DB2® 照会コンパイラー変数 DB2_MINIMIZE_LISTPREFETCH および DB2_INLIST_TO_NLJN の両方またはいずれかが YES に設定されると、REOPT(ONCE) が指定されていても、アクティブ状態のままになります。

    db2set コマンドに -immediate パラメーターを付けて発行した場合、この変数を変更すると、その変更はその後コンパイルされるすべての SQL ステートメントに対してただちに有効になります。 インスタンスを再始動する必要はありません。

DB2_LIKE_VARCHAR
  • オペレーティング・システム: すべて
  • デフォルト = Y,Y
  • サブエレメント統計の使用を制御します。 これらの統計は、データにブランクで区切られた一連のサブフィールドまたはサブエレメント形式の 構造がある場合、列内のデータ内容に関する統計です。 サブエレメント統計の収集はオプションで、RUNSTATS コマンドまたは API 内のオプションによって制御されます。
    重要: この変数は推奨されておらず、IBM® サービスのアドバイスがない限り設定を変更すべきでないため、将来のリリースでは、なくなる可能性があります。
    このレジストリー変数は、次の形式の述部をオプティマイザーが処理する方法に影響します。 
       COLUMN LIKE '%xxxxxx%'
    xxxxxx は文字のストリングです。

    このレジストリー変数の使用方法を示す構文は次のとおりです。

       db2set DB2_LIKE_VARCHAR=[Y|N|S|num1] [,Y|N|S|num2]
    説明
    • コンマの前にある項、または述部の右辺で唯一の項は、以下の意味になります。 ただしこれが有効なのは、2 番目の項が N に指定されているか、または列に正の値のサブエレメント統計がない場合のみです。
      • S - オプティマイザーは % 文字で囲まれたストリングの長さに基づいて、 列を形成するために連結する一連のエレメントの各エレメントの長さを見積もる。
      • Y - デフォルト。 アルゴリズム・パラメーターのデフォルト値 1.9 を使用する。 アルゴリズム・パラメーターで可変長サブエレメント・アルゴリズムを使用する。
      • N - 固定長サブエレメント・アルゴリズムを使用する。
      • num1 - 可変長サブエレメント・アルゴリズムにより、 アルゴリズム・パラメーターとして num1 の値を使用する。
    • コンマの後の項は以下のような意味がありますが、正の値のサブエレメント統計を持つ列に対してのみです。
      • N - サブエレメント統計を使用しない。 最初の用語が有効になります。
      • Y - デフォルト。 正の値のサブエレメント統計を持つ列の場合に、アルゴリズム・パラメーターの デフォルト値 1.9 と一緒にサブエレメント統計を使用する可変長サブエレメント・アルゴリズムを使用する。
      • num2 - 正の値のサブエレメント統計を持つ列の場合に、 アルゴリズム・パラメーターとして num2 の値と一緒に サブエレメント統計を使用する可変長サブエレメント・アルゴリズムを使用する。

    db2set コマンドに -immediate パラメーターを付けて発行した場合、この変数を変更すると、その変更はその後コンパイルされるすべての SQL ステートメントに対してただちに有効になります。 インスタンスを再始動する必要はありません。

DB2_MINIMIZE_LISTPREFETCH
  • オペレーティング・システム: すべて
  • デフォルト = NO。値: YES または NO
  • リスト・プリフェッチは特殊な表アクセス方式です。 索引から対象データのある RID を検索して、それらをページ番号でソートしてからデータ・ページをプリフェッチします。場合によっては、オプティマイザーがリスト・プリフェッチが良いアクセス方式であるかどうかを 判別するための正確な情報を持っていないことがあります。 オプティマイザーがカタログ統計を使用して選択度を判別することを妨げるパラメーター・マーカーまたはホスト変数が、述部選択度に含まれる場合にこのことが生じることがあります。

    このレジストリー変数は、そのような状況でオプティマイザーがリスト・プリフェッチを検討することを防止します。

    注: DB2 照会コンパイラー変数 DB2_MINIMIZE_LISTPREFETCH および DB2_INLIST_TO_NLJN の両方またはいずれかが YES に設定されると、REOPT(ONCE) が指定されていても、アクティブ状態のままになります。

    db2set コマンドに -immediate パラメーターを付けて発行した場合、この変数を変更すると、その変更はその後コンパイルされるすべての SQL ステートメントに対してただちに有効になります。 インスタンスを再始動する必要はありません。

DB2_NEW_CORR_SQ_FF
  • オペレーティング・システム: すべて
  • デフォルト = OFF。値: ON または OFF
  • ON に設定すると、照会オプティマイザーが特定の副照会述部について計算した選択度の値に影響します。 このパラメーターを使用すると、 副照会の SELECT リストで MIN または MAX 集約関数を使用する等価副照会述部の選択値の正確度を高めることができます。 例えば、
    SELECT * FROM T WHERE 
T.COL = (SELECT MIN(T.COL) 
FROM T WHERE …)

    db2set コマンドに -immediate パラメーターを付けて発行した場合、この変数を変更すると、その変更はその後コンパイルされるすべての SQL ステートメントに対してただちに有効になります。 インスタンスを再始動する必要はありません。

DB2_OPT_MAX_TEMP_SIZE
  • オペレーティング・システム: すべて
  • デフォルト= NULL。 値: すべての TEMPORARY 表スペースで照会が使用できるスペースの量 (メガバイト単位)
  • TEMPORARY 表スペースで照会が使用できるスペースの量を制限します。 DB2_OPT_MAX_TEMP_SIZE を設定すると、オプティマイザーはこれを設定しない場合に比べて高コストのプランを選択する可能性がありますが、そのプランが TEMPORARY 表スペースで使用するスペースは小さくなります。 DB2_OPT_MAX_TEMP_SIZE を設定する場合は、TEMPORARY 表スペースの使用を制限する必要性と、これを設定したために選択されるプランの効率のバランスを取るようにしてください。

    DB2_WORKLOAD=SAP に設定すると、DB2_OPT_MAX_TEMP_SIZE は自動的に 10240 (10 GB) に設定されます。

    DB2_OPT_MAX_TEMP_SIZE に設定した値を上回る TEMPORARY 表スペースを使用する照会を実行する場合、照会は失敗しませんが、すべてのリソースが使用可能とは限らないため、最適のパフォーマンスにならない可能性があるという警告が出されます。

    オプティマイザーが検討する操作のうち、DB2_OPT_MAX_TEMP_SIZE で設定された制限の影響を受けるものは、以下のとおりです。
    • ORDER BY、DISTINCT、GROUP BY、MERGE SCAN 結合、NESTED LOOP 結合などの操作での明示的ソート。
    • 明示的一時表
    • ハッシュ結合および DUPLICATE MERGE 結合での暗黙的一時表

    db2set コマンドに -immediate パラメーターを付けて発行した場合、この変数を変更すると、その変更はその後コンパイルされるすべての SQL ステートメントに対してただちに有効になります。 インスタンスを再始動する必要はありません。

DB2_REDUCED_OPTIMIZATION
  • オペレーティング・システム: すべて
  • デフォルト = NO。値: NO、YES、任意の整数、DISABLE、JUMPSCAN、NO_SORT_NLJOIN、または NO_SORT_MGJOIN
  • このレジストリー変数によって、最適化機能を削減したり、 最適化機能を指定した最適化レベルに固定して使用するように要求することができます。 使用される最適化手法の数を削減する場合、最適化の際に使用される時間およびリソースも削減されます。
    この変数を設定する場合、次の構文規則が適用されます。
    • 各オプションをコンマ (,) で区切り、コンマの前後にはスペースを入れません。
    • オプションと、そのオプションの値をスペース 1 つで区切ります。
    • 設定値にスペースが入っている場合、その設定値を二重引用符 (“”) で囲みます。
    次の例に、正しい構文を示します。 
    db2set DB2_REDUCED_OPTIMIZATION="NO_SORT_NLJOIN,JUMPSCAN ON"
    注: 最適化に必要な時間とリソースをより削減できるかもしれませんが、一方で最適ではないアクセス・プランが生成されるリスクは増えます。 このレジストリー変数は、IBM またはそのパートナーから指示された場合にのみ使用します。
    • NO に設定した場合

      オプティマイザーは最適化手法を変更しません。

    • YES に設定した場合

      最適化レベルが 5 (デフォルト) もしくは 5 未満の場合に、 通常はより良いアクセス・プランを生成することがなく、 相当量の準備時間とリソースを消費する、いくつかの最適化手法をオプティマイザーは使用不可にします。

      最適化レベルがちょうど 5 の場合、さらにいくつかの手法を制限または使用不可にします。 その結果、オプティマイザーによる最適化に必要な時間とリソースをより削減できるかもしれませんが、 一方で最適ではないアクセス・プランが生成されるリスクは増えます。 最適化レベルが 5 未満の場合、これらの技法のいくつかは最初から無効であることがあります。 しかしそれらが有効であれば、有効のままとなります。

    • 任意の整数に設定した場合

      YES と同じ効果があり、さらにレベル 5 で最適化され、動的に作成された照会に対して次のような追加の動作が伴います。 いずれかの照会ブロック内にある結合の合計数が設定値を超えると、前述のレベル 5 最適化レベルについての説明で示した追加の最適化手法を使用不可にする代わりに、オプティマイザーは欲張り型結合列挙に切り替わります。 これは、照会が最適化レベル 2 に類似したレベルで最適化されることを暗黙に示します。

    • DISABLE に設定した場合

      最適化レベル 5 での動的照会の時には、 この DB2_REDUCED_OPTIMIZATION 変数の指定がなくとも、オプティマイザーは動的に最適化レベルを下げることがあります。この設定値はこの動作を使用不可にして、オプティマイザーがレベル 5 の最適化を完全に実行することを要求します。

    • JUMPSCAN に設定した場合
      このオプションは、DB2 オプティマイザーがジャンプ・スキャン操作を使用できるかどうかを制御するために使用します。 以下の値を指定できます。
      • OFF = DB2 オプティマイザーはジャンプ・スキャンを使用するプランを作成しません。
      • ON = DB2 オプティマイザーはコスト・ベースの分析を使用して、ジャンプ・スキャンを使用するプランを生成するかどうかを決定します (デフォルト)。
    • NO_SORT_NLJOIN に設定した場合

      オプティマイザーは、NESTED LOOP 結合 (NLJOIN) の場合に、強制的にソートを行う照会プランは生成しません。 このようなタイプのソートは、パフォーマンスの改善に役立つことがあります。ということは、NO_SORT_NLJOIN オプションを使用するときは、パフォーマンスに大きく影響することがあるので注意が必要です。

    • NO_SORT_MGJOIN に設定した場合

      オプティマイザーは、MERGE SCAN 結合 (MSJOIN) の場合に、強制的にソートを行う照会プランは生成しません。 このようなタイプのソートは、パフォーマンスの改善に役立つことがあります。ということは、NO_SORT_MGJOIN オプションを使用するときは、パフォーマンスに大きく影響することがあるので注意が必要です。

      最適化レベル 5 での動的な最適化レベルの引き下げは、 DB2_REDUCED_OPTIMIZATION を YES に設定したときの最適化レベルがちょうど 5 の場合について説明された動作、および整数の設定値について説明された動作よりも優先されることに注意してください。

    • ZZJN に設定した場合:
      このオプションを使用して、DB2 オプティマイザーにおける、 ファクト表を 1 つ含むスター・スキーマ・ベースの照会でのジグザグ結合方式の使用方法を制御します。以下の値を指定できます。
      • OFF = DB2 オプティマイザーでは、ジグザグ結合方式を使用しません。
      • ON = DB2 オプティマイザーでは、コスト・ベースの分析を使用して、ジグザグ結合方式を使用するか、それとも 別の結合方式を使用するかを判断します (デフォルト)。
      • FORCE = ジグザグ結合方式が実行可能である場合、DB2 オプティマイザーではジグザグ結合方式を使用します。
    • ZZJN_MULTI_FACT に設定した場合:
      このオプションを使用して、DB2 オプティマイザーにおける、 ファクト表を複数含むスター・スキーマ・ベースの照会でのジグザグ結合方式の使用方法を制御します。以下の値を指定できます。
      • OFF = DB2 オプティマイザーでは、ジグザグ結合方式を使用しません。
      • ON = DB2 オプティマイザーでは、コスト・ベースの分析を使用して、ジグザグ結合方式を使用するか、それとも 別の結合方式を使用するかを判断します (デフォルト)。
      • FORCE = ジグザグ結合方式が実行可能である場合、DB2 オプティマイザーではジグザグ結合方式を使用します。

    db2set コマンドに -immediate パラメーターを付けて発行した場合、この変数を変更すると、その変更はその後コンパイルされるすべての SQL ステートメントに対してただちに有効になります。 インスタンスを再始動する必要はありません。

DB2_SELECTIVITY
  • オペレーティング・システム: すべて
  • デフォルト = NO。値: YES または NO
  • このレジストリー変数は、 SQL ステートメント内の検索条件で、SELECTIVITY 文節が使用できる場所を制御します。

    このレジストリー変数が NO に設定された場合、SELECTIVITY 節はユーザー定義述部にしか指定できません。

    このレジストリー変数が YES に設定された場合、以下の述部に SELECTIVITY 節を設定可能です。
    • ユーザー定義述部
    • ホスト変数またはパラメーター・マーカーを含む式を少なくとも 1 つは持つ基本述部

    db2set コマンドに -immediate パラメーターを付けて発行した場合、この変数を変更すると、その変更はその後コンパイルされるすべての SQL ステートメントに対してただちに有効になります。 インスタンスを再始動する必要はありません。

DB2_SQLROUTINE_PREPOPTS
  • オペレーティング・システム: すべて
  • デフォルト = 空ストリング。値は以下のようになります。
    • APREUSE {YES | NO}
    • BLOCKING {UNAMBIG | ALL | NO}
    • CONCURRENTACCESSRESOLUTION { USE CURRENTLY COMMITTED | WAIT FOR OUTCOME }
    • DATETIME {DEF | USA | EUR | ISO | JIS | LOC}
    • DEGREE {1 | degree-of-parallelism | ANY}
    • DYNAMICRULES {BIND | INVOKEBIND | DEFINEBIND | RUN | INVOKERUN | DEFINERUN}
    • EXPLAIN {NO | YES | ALL}
    • EXPLSNAP {NO | YES | ALL}
    • FEDERATED {NO | YES}
    • INSERT {DEF | BUF}
    • ISOLATION {CS | RR | UR | RS | NC}
    • OPTPROFILE {profile_name | schema_name.profile_name}
    • QUERYOPT optimization-level
    • REOPT {NONE | ONCE | ALWAYS}
    • STATICREADONLY {YES|NO|INSENSITIVE}
    • VALIDATE {RUN | BIND}
  • DB2_SQLROUTINE_PREPOPTS レジストリー変数を使用すると、SQL および XQuery プロシージャーと関数のプリコンパイル・オプションと BIND オプションをカスタマイズできます。この変数を設定する際は、次のように、各オプションをスペースで区切ります。 
    db2set DB2_SQLROUTINE_PREPOPTS="BLOCKING ALL VALIDATE RUN"
    各オプションとその設定についての完全な説明は、『BIND コマンド』を参照してください。

個々のプロシージャーを選択して、インスタンスを再始動させずに DB2_SQLROUTINE_PREPOPTS と同じ結果を得るためには、SET_ROUTINE_OPTS プロシージャーを使用します。

関連資料:
最適化クラス