フェデレーテッド・データベースのプッシュダウン分析
フェデレーテッド・データベースに対して実行される照会では、オプティマイザーは、 プッシュダウン分析を実行することによって、リモート・データ・ソースで特定の操作を実行できるかどうかを判別します。
操作は、関係演算子、システム関数、ユーザー関数などの関数である場合もあり、例えば ORDER BY、GROUP BY などの SQL 演算子の場合もあります。
ローカル・カタログ情報を定期的に更新するようにしてください。 Db2® クエリ・コンパイラがリモート・データ・ソースの SQL サポートに関する正確な情報にアクセスできるようにするためです。 カタログを更新するときには、Db2 データ定義言語 (DDL) ステートメント (例えば、CREATE FUNCTION MAPPING や ALTER SERVER など) を使用します。
関数がリモート・データ・ソースにプッシュダウンできない場合、 その関数は、照会のパフォーマンスに大きな影響を与える可能性があります。 選択述部をデータ・ソースで評価したときではなく、ローカルに評価したときの影響を考慮してください。 このような評価では、Db2 サーバーにリモート・データ・ソースから表全体を検索させ、それを述部に対してローカルにフィルター操作しなければならない場合があります。 またネットワークに制約があったり、表が大きかったりする場合も、それによってパフォーマンスが影響を受ける可能性があります。
プッシュダウンされない演算子も、照会のパフォーマンスに大きな影響を与えることがあります。 例えば、GROUP BY 演算子でリモート・データ・ソースをローカルに集約するなら、Db2 サーバーにリモート・データ・ソースから表全体を検索させる必要も生じるかもしれません。
select lastname, count(*) from n1
where
lastname > 'B' and
salary > 50000
group by lastname- 照合シーケンスが同じ場合は、照会述部を Db2 for z/OSにプッシュダウンできる可能性があります。 通常は、表全体をコピーしてからローカルに操作を実行するよりも、データ・ソースで結果をフィルターに掛けてグループ分けする方が効率的です。 このような照会では、述部および GROUP BY 操作をデータ・ソースで実行できます。
- 照合シーケンスが異なる場合は、両方の述部をデータ・ソースで評価することはできません。 ただし、オプティマイザーは、
salary > 50000述部をプッシュダウンする方法をとる場合があります。 その場合でも、範囲の比較はローカルに実行する必要があります。 - 照合シーケンスが同じで、ローカル Db2 サーバーが非常に高速であることをオプティマイザーが認識している場合は、GROUP BY 操作をローカルに実行するのが最もコストのかからない方法であると判断される可能性があります。 述部はデータ・ソースで評価されます。 これは、グローバルな最適化と組み合わされたプッシュダウン分析の例です。
プッシュダウンの使用に影響を与えるサーバー特性
特定のデータ・ソースに固有の要因により、プッシュダウンが行われるかどうかに影響が生じる場合があります。 一般に、このような要因が存在するのは、Db2 製品で豊富な SQL ダイアレクトがサポートされているためです。 Db2 データ・サーバーは別のデータ・サーバーで使用できる機能の不足を補正することができますが、そのようにすると、その操作は Db2 サーバーで実行する必要があります。
- SQL 機能
それぞれのデータ・ソースは、SQL ダイアレクトのバリエーションをサポートし、 いろいろなレベルの機能をサポートします。 例えば、ほとんどのデータ・ソースは GROUP BY 演算子をサポートしていますが、その中には、GROUP BY リストの項目数が制限されているものもあれば、GROUP BY リストで式が許可されるかどうかに制限があるものもあります。 リモート・データ・ソースで制限がある場合、Db2 サーバーは GROUP BY 操作をローカルに実行しなければならないことがあります。
- SQL 制約
それぞれのデータ・ソースには、異なる SQL 制約が存在する可能性があります。 例えば一部のデータ・ソースでは、 パラメーター・マーカーをリモート SQL ステートメントへの値にバインドする必要があります。 したがって、各データ・ソースがこのようなバインド・メカニズムをサポートできるかを確認するため、 パラメーター・マーカー制約をチェックする必要があります。 ある関数の値をバインドする適切な方法を Db2 サーバーが判別できない場合、この機能はローカルに評価する必要があります。
- SQL 制限
Db2 サーバーでは、リモート・データ・ソースで許可されている整数よりも大きい整数を使用できる場合がありますが、リモートでの限度を超える値をデータ・ソースに送られるステートメントに組み込むことはできませんし、影響を受ける関数または演算子はローカルに評価する必要があります。
- サーバーの特性
いくつかの要因がこのカテゴリーに含まれます。 例えば、データ・ソースにある NULL 値のソート方法が Db2 サーバーのソート方法と異なる場合には、NULL 可能な式での ORDER BY 操作はリモートでは評価できません。
- 照合シーケンスローカルでソートや比較を行うためにデータを取り出すと、通常はパフォーマンスが低下します。 データ・ソースが使用するものと同じ照合シーケンスを使うようにフェデレーテッド・データベースを構成してから、COLLATING_SEQUENCE サーバー・オプションを Y に設定した場合、オプティマイザーは、多くの照会操作をプッシュダウンすることを考慮に入れることができます。 照合シーケンスが同一である場合は、以下の操作をプッシュダウンできるかもしれません。
- 文字データや数値データの比較
- 文字範囲比較述部
- ソート
ただし、フェデレーテッド・データベースとデータ・ソースとの間で NULL 文字の並び順序が違うと、異常な結果が発生する可能性があります。 比較の際に大/小文字を区別しないデータ・ソースにステートメントをサブミットすると、予期しない結果が返される場合があります。 大/小文字を区別しないデータ・ソースでは、文字
I
とi
に割り当てられる重みは同じです。 デフォルトでは Db2 サーバーは大文字小文字を区別し、それぞれの文字に異なる並び順序を割り当てます。パフォーマンスを向上させるため、フェデレーテッド・サーバーでは、データ・ソースでソートや比較を行うことが可能です。 例えば、 Db2 for z/OSでは、ORDER BY 節によって定義されるソートは、EBCDIC コード・ページに基づく照合シーケンスによって実装されます。 フェデレーテッド・サーバーを使用して、ORDER BY 節に従ってソートされた Db2 for z/OS データを取得するには、EBCDIC コード・ページに基づいて事前定義された照合シーケンスを使用するようにフェデレーテッド・データベースを構成します。
フェデレーテッド・データベースとデータ・ソースの照合シーケンスが異なる場合、Db2 サーバーはデータをフェデレーテッド・データベースに取り出します。 ユーザーは、フェデレーテッド・サーバーに定義されている照合シーケンスに従って配列された照会結果を必要としているため、データをローカルに配列することによってこの必要に応えます。 データ・ソースの照合シーケンスにある順序でデータを示させる必要がある場合は、照会をパススルー・モードでサブミットするか、データ・ソース・ビューでその照会を定義してください。
- サーバー・オプション
COLLATING_SEQUENCE、VARCHAR_NO_TRAILING_BLANKS、PUSHDOWN などのいくつかのサーバー・オプションが、プッシュダウンが行われるかどうかに影響を与える場合があります。
- Db2 タイプ・マッピングおよび関数マッピングの要因
Db2 サーバーのデフォルトのローカル・データ・タイプ・マッピングは、データの損失を防ぐため、データ・ソースの各データ・タイプに十分なバッファー・スペースを割り振るよう設計されています。 特定のアプリケーションに合わせて、特定のデータ・ソースのタイプ・マッピングをカスタマイズすることもできます。 例えば、Oracle データ・ソース列の DATE データ・タイプ (デフォルトでは、 Db2 TIMESTAMP データ・タイプにマップされる) にアクセスする場合は、 ローカル・データ・タイプを Db2 DATE データ・タイプに変更できます。
- 関数がリモート・データ・ソースに存在しない。
- 関数は存在するが、オペランドの特性が関数の制限に違反している。 この状況の一例として、IS NULL 関係演算子が挙げられます。 ほとんどのデータ・ソースはこの演算子をサポートしていますが、列名は IS NULL 演算子の左辺にしか使用できないなど、制限が存在する場合もあります。
- 関数は、リモート側で評価されると違う値を戻すことがあります。 この状況の例としては、An example of this situation is the greater than ('>') 演算子があります。 照合シーケンスの異なるデータ・ソースでは、「より大きい」演算子が Db2 サーバーによってローカルに評価されると、異なった結果が返される可能性があります。
プッシュダウンの使用に影響を与えるニックネーム特性
- ニックネーム列のローカル・データ・タイプ
列のローカル・データ・タイプにより、 述部をデータ・ソース側で評価することが妨げられないようにしてください。 オーバーフローが生じるのを潜在的に防ぐため、デフォルトのデータ・タイプ・マッピングを使用してください。 しかし、長さの異なる 2 つの列の間での述部の結合は、Db2 が長い方の列をバインドする方法によっては、短い列が存在するデータ・ソースでは行われません。 このような状況が生じると、 Db2 のオプティマイザーが結合シーケンスで評価を行える機会の数に影響することがあります。 例えば、INTEGER または INT データ・タイプを使用して作成された Oracle データ・ソース列は、タイプ NUMBER(38) になります。 Db2 整数の範囲は 2**31 から (-2**31)-1 で、NUMBER(9) とほぼ等しいため、この Oracle データ・タイプのニックネーム列は、ローカル・データ・タイプ FLOAT となります。 この場合、Db2 整数列と Oracle 整数列の結合は、 Db2 データ・ソースでは行えません (結合列が Oracle 整数列より短いため)。 ただし、この Oracle 整数列の領域を Db2 INTEGER データ・タイプに合わせられる場合は、ALTER NICKNAME ステートメントを使用してローカル・データ・タイプを変更することによって、 Db2 データ・ソースで結合を実行できます。
- 列オプション
ニックネームの列オプションを追加したり変更したりするには、ALTER NICKNAME ステートメントを使用します。
末尾ブランクが含まれていない列の識別には、VARCHAR_NO_TRAILING_BLANKS オプションを使用します。 その後コンパイラーのプッシュダウン分析ステップで、そのような列に対して実行するすべての操作を検査するときに、この情報が考慮されます。 Db2 サーバーは、データ・ソースに送信される SQL ステートメントで使用するための、異なってはいても等価な形式の述部を生成する場合があります。 データ・ソースに対して異なる述部が評価される可能性はありますが、最終的な結果は同じになります。
この列の値が常に末尾ブランクなしの数値であるかどうかを識別するには、NUMERIC_STRING オプションを使用してください。
表 1 で、これらのオプションについて説明します。表 1. 列オプションとその設定値 オプション 有効な設定値 デフォルト設定 NUMERIC_STRING はい - この列には数値データのストリングだけが含まれます。 列データのソートを妨げる可能性があるブランク文字は含まれません。 このオプションは、データ・ソースの照合シーケンスが Db2 サーバーの照合シーケンスとは異なる場合に役立ちます。 このオプションでマークされた列は、照合シーケンスが異なるためにローカルな (データ・ソースの) 評価から除かれるということはありません。 この列に、末尾ブランク文字が付いた数値ストリングしか含まれない場合は、Y は指定しないでください。
いいえ - この列は数値データのストリングに限定されていません。
N VARCHAR_NO_TRAILING_BLANKS Y: このデータ・ソースが、Db2 データ・サーバーのように、ブランクが埋め込まれていない VARCHAR 比較セマンティクスを使用することを指定します。 末尾ブランク文字を含んでいない可変長文字ストリングについては、一部のデータ・サーバーのブランク埋め込みなしの比較セマンティクスでは、Db2 の比較セマンティクスと同じ結果が戻されます。 データ・ソースにあるすべての VARCHAR 表またはビューの列に末尾ブランク文字が含まれていないことが明らかである場合は、この値を指定してください。
N: このデータ・ソースが、Db2 データ・サーバーのようにブランクが埋め込まれていない VARCHAR 比較セマンティクスを使用することがないことを指定します。
N
プッシュダウンの使用に影響を与える照会特性
照会では、複数のデータ・ソースにあるニックネームを使用する SQL 演算子を参照できます。 セット演算子 (例えば UNION) などの 1 つの演算子を使用して、参照された 2 つのデータ・ソースからの結果を組み合わせる場合は、この操作を Db2 サーバーで実行する必要があります。 この演算子は、 リモート・データ・ソースで直接評価することはできません。