このセクションでは、連合データベース・システムにおける、 追加の照会処理フェーズについて説明します。 さらに、連合データベース照会のパフォーマンスを改善するための情報も載せられています。 主なトピックは以下のとおりです。
後入れ先出し分析を実行すると、 リモート・データ・ソースで特定の操作を実行できるかどうかが、 DB2 最適化プログラムに通知されます。 操作は、関係演算子、システムまたはユーザー関数、 または SQL 演算子 (GROUP BY、ORDER BY など) などの関数とすることができます。
後入れ先出しができない関数は、照会パフォーマンスに多大に影響することがあります。 選択述部を、データ・ソースで評価するのではなく、 ローカルに評価するときの影響を考慮する必要があります。 この方法を使う場合、DB2 はリモート・データ・ソースから表全体を検索し、 述部に対してローカルにフィルターしなければならないことがあります。 ネットワークに制約があり、なおかつ表が大きい場合、 照会パフォーマンスに影響する場合があります。
後入れ先出しされない演算子も、照会パフォーマンスに多大に影響することがあります。 たとえば、GROUP BY 演算子によってリモート・データ・ソースをローカルに集約すると、 DB2 はリモート・データ・ソースから表全体を検索しなければならない場合があります。
たとえば、ニックネーム N1 が、 DB2 (OS/390 版) データ・ソースに含まれるデータ・ソース表 EMPLOYEE を指しているとします。 さらに、この表には 10,000 の行があり、列の 1 つには従業員の名前が、 そして別の列には給与が入っているとします。 ステートメントは次のようになります。
SELECT LASTNAME, COUNT(*) FROM N1 WHERE LASTNAME > 'B' AND SALARY > 50000 GROUP BY LASTNAME;
いくつかの可能性が考えられます。
一般には、最適化プログラムによるデータ・ソースでの評価について、 関数や演算子を考慮に入れられることを確認することが目標です。 関数または SQL 演算子がリモート・データ・ソースで評価されるかどうかは、 多くの要素に左右されます。 キーとなる要素は、サーバー特性、ニックネーム特性、 および照会特性の 3 つのグループに分けて述べられます。
続くセクションでは、 後入れ先出しの機会に影響する可能性のあるデータ・ソース特有の要素を説明します。 一般には、DB2 では豊富な SQL ダイアレクトを使用して照会を実行依頼するため、 このような要素が存在しています。 このダイアレクトは、 DB2 照会時にアクセスされるサーバーがサポートしている SQL ダイアレクトよりも、 さらに多くの機能を提供することができます。 DB2 はデータ・サーバーでの機能の不足を補正することができますが、 そのようにすると、その操作は DB2 で実行する必要があります。
各データ・ソースは、さまざまな SQL ダイアレクト、 そして異なるレベルの機能をサポートしています。 たとえば、GROUP BY リストを考慮してください。 ほとんどのデータ・ソースは GROUP BY 演算子をサポートしていますが、 GROUP BY リストでの項目数に制限があるものもあれば、 GROUP BY リストで式が許可されるかどうかに関する制限があるものもあります。 リモート・データ・ソースで制限がある場合、 DB2 は GROUP BY 操作をローカルに実行しなければならないことがあります。
それぞれのデータ・ソースには、異なる SQL 制限が存在する可能性があります。 たとえば一部のデータ・ソースでは、 パラメーター・マーカーをリモート SQL ステートメントへの値にバインドする必要があります。 したがって、パラメーター・マーカーの制限を調べ、 各データ・ソースがそのようなバインド機構をサポートできることを確かめる必要があります。 ある関数の値にバインドする適切な方法を DB2 が判別できない場合、 この機能はローカルに評価する必要があります。
DB2 では、リモート・データ・ソースよりも大きい整数を使用することができます。 ただし、データ・ソースに送信されるステートメントに、限界を超過した値を組み込むことはできません。 したがって、この定数を操作する関数や演算子は、ローカルに評価される必要があります。
このカテゴリーには、いくつかの要因が該当します。 その 1 つの例は、NULL 値の分類 (最高値、最低値、 または配列によって決定する) です。 たとえば、NULL 値がデータ・ソースにおいて DB2 とは異なる方法で分類される場合、 ヌル可能な式での ORDER BY 操作をリモートに評価することはできません。
データ・ソースが使用するのと同じ照合順序を使うよう連合データベースを構成し、 collating_sequence サーバー・オプションを 'Y' に設定すると、 最適化プログラムは「後入れ先出し」による文字範囲比較述部を考慮できます。
連合サーバーからの照会で分類が必要な場合、 分類が行われる箇所は、いくつかの要因により異なります。 連合データベースの照合順序が、 照会されたデータの格納されているデータ・ソースでの照合順序と同じであれば、 分類はデータ・ソースで実行することができます。 照合順序が同じであれば、最適化プログラムは、 ローカル分類またはデータ・ソースでの分類のどちらが照会を完了するための最も効率的な方法であるかどうかを判断できます。 同様に、照会で文字データの比較が必要な場合、 この比較もデータ・ソースで実行できます。
数値比較は一般に、照合順序が異なっていたとしても、 いずれかの位置で実行できます。 ただし、連合データベースとデータ・ソースとの間でヌル文字の重みが違うと、 異常な結果が発生する可能性があります。 同じように、比較ステートメントの場合、 大文字小文字を区別しないデータ・ソースにステートメントを実行依頼するときには注意が必要です。 大文字小文字を区別しないデータ・ソースでは、 文字 "I" と "i" に割り当てられている重みは同じです。 省略時では DB2 は大文字小文字を区別し、 それぞれの文字に異なる重みを割り当てます。
連合データベースとデータ・ソースの照合順序が異なる場合、 DB2 はデータを連合データベースに送ることにより、 分類と比較をローカルに実行できるようにします。 これは、ユーザーが、 連合サーバーに定義した照合順序で並べられた照会結果を要求しているためです。 データをローカルに並べることにより、連合サーバーはこの要求を実現します。
ローカルの分類および比較のためにデータを検索すると、 一般的にパフォーマンスは低下します。 したがって、データ・ソースで使うのと同じ照合順序を使用するように、 連合データベースを構成することを考慮してください。 そのようにするなら、連合サーバーはデータ・ソースで分類と比較を行えるため、 パフォーマンスは向上します。 たとえば、DB2 UDB (OS/390 版) では、ORDER BY 文節で定義された分類は、 EBCDIC コード・ページに基づく照合順序で実行されます。 連合サーバーを使用し、ORDER BY 文節で分類された DB2 (OS/390 版) データを検索する場合、 EBCDIC コード・ページに基づいて事前定義された照合順序を使用するように連合データベースを構成することをお勧めします。
連合データベースとデータ・ソースでの照合順序が異なり、 データ・ソースの順序で並べられたデータが必要な場合は、 照会をパススルー・モードで実行依頼するか、 データ・ソース視点で照会を定義することができます。
照合順序およびその設定方法についての詳細は、 管理の手引き: 計画 を参照してください。 collating_sequence サーバー・オプションについての詳細は、 表 43 を参照してください。
一部のサーバー・オプションは、後入れ先出しの機会に影響します。 特に、collating_sequence、 varchar_no_trailing_blanks、 および pushdown の設定を検討してください。 これらのオプションの設定については、 "連合データベース照会に影響を与えるサーバー・オプション"を参照してください。
DB2 が備えている省略時のローカル・データ・タイプ・マッピング (データ・タイプの表については、 アプリケーション開発の手引き を参照) は、 各データ・ソースのデータ・タイプに十分なバッファー・スペースが確保されるように設計されています (データの消失を防ぐため)。 ユーザーは、特定のアプリケーションに合うように、 特定のデータ・ソースのタイプ・マッピングをカスタマイズすることもできます。 たとえば、Oracle データ・ソースの DATE データ・タイプ (省略時では、 DB2 TIMESTAMP データ・タイプにマップされる) にアクセスする場合、 ローカル・データ・タイプを DB2 DATE データ・タイプに変更できます。
DB2 は、データ・ソースでサポートされていない関数を補正できます。 関数が補正される場合には、以下の 3 つがあります。
続くセクションでは、 後入れ先出しの機会に影響することのあるニックネームに特有の要素を説明します。
列のローカル・データ・タイプがデータ・ソースでの述部の評価を妨げていないことを確認します。 前述したように、 省略時のデータ・タイプ・マッピングは桁あふれを避けるようになっています。 しかし、長さの異なる 2 つの列の間での述部の結合は、 DB2 が長い方の列をバインドする方法によっては、 短い列が存在するデータ・ソースでは行われません。 このような状況が生じると、 DB2 最適化プログラムによって評価できる結合順序の数に影響することがあります。 たとえば、 INTEGER または INT データ・タイプを使用して作成された Oracle データ・ソース列は、 タイプ NUMBER(38) になります。 DB2 整数の範囲は 2**31 から (-2**31)-1 で、NUMBER(9) とほぼ等しいため、 この Oracle データ・タイプのニックネーム列は、ローカル・データ・タイプ FLOAT となります。 この場合、DB2 整数列と Oracle 整数列の結合は、 DB2 データ・ソース (短い方の結合列) では行われません。 ただし、DB2 INTEGER データ・タイプがこの Oracle 整数列の領域を包含している場合は、 ALTER NICKNAME ステートメントを使用してローカル・データ・タイプを変更することによって、 DB2 データ・ソースで結合を実行できます。
ニックネームの列オプションを追加したり変更するには、 ALTER NICKNAME SQL ステートメントを使うことができます。
このようなオプションの 1 つに、"varchar_no_trailing_blanks" があります。 これは、後書きブランクを含まない列を識別するときに使用できます。 コンパイラーの後入れ先出し分析ステップでは、 列に対して実行するすべての操作を検査するときに、この情報を利用します。 この指示に基づき、DB2 は異なってはいても等価な形式の述部を生成し、 データ・ソースに送信されるリモート SQL ステートメントで使用できます。 データ・ソースに対して異なる述部が評価される可能性はありますが、 最終的な結果は同じになります。
別の列オプションは numeric_string です。 このオプションは、 その列の値が常に後書きブランクなしの数値であるかどうかを示します。
列オプションの値と省略時値については、
表 50 を参照してください。
照会では、複数のデータ・ソースにあるニックネームを使用する SQL 演算子を参照できます。 DB2 が、セット演算子 (たとえば UNION) などの 1 つの演算子を使用して、 参照された 2 つのデータ・ソースからの結果を結合しなければならない場合、 この操作は DB2 で実行される必要があります。 この演算子は、リモート・データ・ソースで直接に評価することはできません。
SQL ステートメントを書き直すと、DB2 照会処理のために、 さらに後入れ先出しの機会が提供されます。 このセクションでは、照会が評価される位置を判別するためのツールを紹介し、 照会分析と関連する一般的な質問 (および調査を提案する分野) をリストし、 最後にデータ・ソースのアップグレードについて短く説明します。
DB2 には、照会が評価される箇所を示すユーティリティーが 2 つ付属しています。
照会を完全に後入れ先出しする場合、 RQUERY 演算子の上に RETURN 演算子が示されているはずです。 この RETURN 演算子は、標準の DB2 演算子です。 RQUERY 演算子は、連合データベースの操作に固有のものです。 RQUERY は SQL SELECT ステートメントをデータ・ソースに送り、 照会結果を検索します。 この SELECT ステートメントは、 データ・ソースによってサポートされている SQL ダイアレクトを使用して生成されます。 該当するデータ・ソースのための有効な照会を含めることができます。
このセクションでは、一般的なプラン分析についての疑問と、 後入れ先出しの機会を増やすために調査する分野をリストしています。 主な疑問には、以下のものがあります。
述部が全く選択的なものであり、これを使用して行をフィルターし、 ネットワーク通信量を減らせる場合に、このような疑問が発生します。 リモートでの述部評価は、 同じデータ・ソースの 2 つの表間での結合をリモートに評価できるかどうかにも影響します。
調べる必要のある分野は、以下のものがあります。
いくつかの点を調べることができます。
いくつかの点を調べることができます。
以下の点を考慮してください。
DB2 SQL コンパイラーには、 データ・ソース SQL サポートについての情報が多数含まれていますが、 データ・ソースはアップグレードまたはカスタマイズできるため、 そのようなデータをたびたび調整する必要があります。 その場合、ローカル・カタログ情報を変更することにより、 機能の拡張を DB2 に通知してください。 カタログを更新するときには、 DB2 DDL ステートメント (CREATE FUNCTION MAPPING や ALTER SERVER など) を使用します。 詳細については、SQL 解説書 を参照してください。
この段階は、照会を評価するためのグローバルで最適なアクセス戦略の作成に役立ちます。 連合データベースの照会の場合、アクセス戦略には、 元の照会を一連のリモート照会単位に分解してから結果を結合することが関係する場合があります。
後入れ先出し分析の出力を推奨値として使用することにより、 最適化プログラムはそれぞれの操作が DB2 でローカルに評価されるのか、 それともデータ・ソースでリモートに評価されるのかを決定します。 この決定は、コスト・モデルの出力に基づくものです。 コスト・モデルには、操作を評価するときのコストだけではなく、 DB2 とデータ・ソース間でデータまたはメッセージを伝送するときのコストも含まれています。
目標は最適化された照会を作成することです。ただし、 グローバルな最適化からの出力には多くの要因が影響するため、 照会のパフォーマンスにも影響があります。 主な要因として、サーバー特性とニックネーム特性の 2 つを説明します。
グローバル最適化に影響することのあるデータ・ソース・サーバーの要因には、 以下のものがあります。
データ・ソースの CPU 速度が DB2 の CPU と比較してどの程度速いのか、 あるいは遅いのかを示すには、 cpu_ratio サーバー・オプションを使用します。 比率が低ければ、データ・ソースのワークステーション CPU は、 DB2 のワークステーション CPU よりも速いということです。 比率が低い場合、DB2 最適化プログラムは、 データ・ソースに対して後入れ先出しによる CPU 集約操作を実行しようとします。
この比率についての詳細は、 連合データベース照会に影響を与えるサーバー・オプションを参照してください。
データ・ソースのシステム入出力速度が DB2 のシステムと比較してどの程度速いのか、 あるいは遅いのかを示すには、 io_ratio サーバー・オプションを使用します。 比率が低ければ、データ・ソースのワークステーション入出力速度は、 DB2 のワークステーション入出力速度よりも速いということです。 比率が低い場合、DB2 最適化プログラムは、 データ・ソースに対して後入れ先出しによる入出力集約操作を実行します。 この比率についての詳細は、 連合データベース照会に影響を与えるサーバー・オプションを参照してください。
ネットワーク容量を表示するには、 comm_rate サーバー・オプションを使います。 比率が低い (DB2 とデータ・ソース間のネットワーク通信が遅いことを示す) 場合、 DB2 最適化プログラムは、このデータ・ソースとの間でやりとりするメッセージ数を減らそうとします。 比率を 0 に設定すると、最適化プログラムは、 必要なネットワーク通信量が最小となる照会を作成します。 この比率についての詳細は、 連合データベース照会に影響を与えるサーバー・オプションを参照してください。
データ・ソースの照合順序が、ローカル DB2 の照合順序と一致しているかどうかを示すには、 collating_sequence サーバー・オプションを使用します。 このオプションを 'Y' に設定しないと、最適化プログラムは、 このデータ・ソースから検索したデータが整列されていないとみなします。 照合順序とパフォーマンスについての詳細は、 照合順序を参照してください。
プラン・ヒントがデータ・ソースでサポートされているかどうかを示すには、 plan_hints サーバー・オプションを使用します。 プラン・ヒントはステートメントの一部分であり、 データ・ソース最適化プログラムについての追加情報を提供します。 特定の照会タイプについてこの情報を利用すれば、 照会パフォーマンスを改善することができます。 プラン・ヒントは、データ・ソース最適化プログラムが索引を使用するかどうか、 どの索引を使用するか、 またはどの表結合順序を使うかを判別するのに役立ちます。
プラン・ヒントが使用可能であれば、データ・ソースに送信される照会には、 追加情報が含まれます。 たとえば、プラン・ヒントを使用して Oracle 最適化プログラムへ送信するステートメントは、 次のようになります。
SELECT /*+ INDEX (table1, t1index)*/ col1 FROM table1
プラン・ヒントは、ストリング /*+ INDEX (table1, t1index)*/ です。
DB2 には最適化プログラムの知識ベースがあり、そこには、 固有のデータ・ソースについてのデータが含まれています。 DB2 最適化プログラムは、 特定の DBMS で生成できないリモート・アクセス・プランを生成しません。 つまり DB2 は、リモート・データ・ソースでの最適化プログラムが理解できない、 あるいは受け入れられないプランの生成を避けます。
続くセクションでは、グローバル最適化に影響する、ニックネームに特有の要因を説明します。
DB2 は、データ・ソースにある索引についての情報を使用して、 照会を最適化することができます。 この理由のため、DB2 で使用可能な索引情報が最新のものであることが重要となります。 ニックネームの作成時に、まずニックネームのための索引情報を獲得します。 視点のニックネームについては、索引情報が収集されることはありません。
ニックネームのために索引仕様を作成することができます。 索引仕様では、 DB2 最適化プログラムが使用する索引定義 (実際の索引ではない) をカタログ内に作成します。 索引仕様を作成するには CREATE INDEX SPECIFICATION ONLY ステートメントを使用します。 ニックネームに対する索引仕様を作成する構文は、 ローカル表で索引を作成する構文と似ています。 詳細については、管理の手引き: 計画 を参照してください。
以下の場合に、索引仕様の作成を考慮してください。
視点のニックネームに対する CREATE INDEX ステートメントを発行する前に、 必要事項を考慮してください。 1 つのケースとして、視点が索引付きの表での単なる SELECT である場合、 ニックネームに関する索引のうち、表の索引と一致するもの (ローカルに) データ・ソースで作成すると、 照会のパフォーマンスを著しく改善することができます。 ただし、索引を、単なる SELECT ステートメントではない視点 (たとえば、 2 つの表を結合することにより作成する視点) でローカルに作成すると、 照会のパフォーマンスが低下する可能性があります。 たとえば、2 つの表の結合である視点で索引を作成する場合、 最適化プログラムは、ネストされたループ結合の内部要素として、 その視点を選択する場合があります。 この結合は複数回評価されるため、照会のパフォーマンスは低下します。 別の方法としては、データ・ソースの視点で参照される表ごとにニックネームを作成し、 両方のニックネームを参照する部分視点を DB2 で作成することができます。
カタログ統計には、ニックネーム全体のサイズと、関連する列での値の範囲が示されます。 これらの統計は、 ニックネームを含む照会を処理するときのコストを最小にする方法を計算する場合に、 最適化プログラムによって使用されます。 ニックネーム統計は、表統計と同じカタログ視点に格納されます。 統計のタイプとそれらをローカルに更新する方法については、 第 24 章, システム・カタログ統計と 表統計とニックネーム統計の更新の規則を参照してください。
DB2 は、データ・ソースに保持されている統計データを検索することはできますが、 データ・ソースにある既存の統計データに対する更新を自動的に検出することはできません。 さらに、DB2 には、オブジェクト定義を処理するための機構、 あるいはデータ・ソースにあるオブジェクトに対する構造的な変更 (列の追加) を処理するための機構が備えられていません。 オブジェクトの統計データまたは構造データに変更がある場合、 以下の 2 つから処置を選択することができます。
このセクションでは、照会の最適化を分析するためのツールを紹介し、 照会の最適化と関連する一般的な質問 (および調査を提案する分野) を示します。
DB2 には、グローバル・アクセス・プランを示すユーティリティーが 2 つ付属しています。
このセクションでは、最適化についての疑問と、 パフォーマンスを改善するために調べる主な分野をリストします。 主な疑問には、以下のものがあります。
調べる必要のある分野は、以下のものがあります。
調べる必要のある分野は、以下のものがあります。
DB2 最適化プログラムは、コスト・ベースの最適化を実行します。 後入れ先出し分析で、各演算子はリモート・データ・ソースで評価できることが示されても、 最適化プログラムは、グローバル最適化プランを生成するときには、 コストによる見積もりを利用します。 そのプランに関与する要因は非常にたくさんあります。 たとえば、リモート・データ・ソースが元の照会でそれぞれの操作を処理できても、 リモート・データ・ソースの CPU 速度が DB2 の CPU 速度よりはるかに遅いため、 DB2 で操作を実行する方が有利であることが分かる場合があります。 結果に満足できない場合、SYSCAT.SERVEROPTIONS のサーバー統計を調べてください。
調べる必要のある分野は、以下のものがあります。
また、述部が置き換えられていないか調べます。 適切な照会最適化プログラムであれば、等価な述部の置き換えに影響されることはありません。 ただし、すべての DBMS 最適化プログラムが同じ動作をするわけではないので、 リモート・データ・ソースの最適化プログラムによっては、 入力述部に基づいて異なるプランを生成してしまう可能性があります。 たとえば、最適化プログラムによっては、 述部の変換防止ステートメントを生成できないものもあります。