管理の手引き


連合データベース照会コンパイラー・フェーズ

このセクションでは、連合データベース・システムにおける、 追加の照会処理フェーズについて説明します。 さらに、連合データベース照会のパフォーマンスを改善するための情報も載せられています。 主なトピックは以下のとおりです。

後入れ先出し分析

後入れ先出し分析を実行すると、 リモート・データ・ソースで特定の操作を実行できるかどうかが、 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 機能

各データ・ソースは、さまざまな SQL ダイアレクト、 そして異なるレベルの機能をサポートしています。 たとえば、GROUP BY リストを考慮してください。 ほとんどのデータ・ソースは GROUP BY 演算子をサポートしていますが、 GROUP BY リストでの項目数に制限があるものもあれば、 GROUP BY リストで式が許可されるかどうかに関する制限があるものもあります。 リモート・データ・ソースで制限がある場合、 DB2 は GROUP BY 操作をローカルに実行しなければならないことがあります。

SQL の制限

それぞれのデータ・ソースには、異なる SQL 制限が存在する可能性があります。 たとえば一部のデータ・ソースでは、 パラメーター・マーカーをリモート SQL ステートメントへの値にバインドする必要があります。 したがって、パラメーター・マーカーの制限を調べ、 各データ・ソースがそのようなバインド機構をサポートできることを確かめる必要があります。 ある関数の値にバインドする適切な方法を DB2 が判別できない場合、 この機能はローカルに評価する必要があります。

SQL の限界

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_sequencevarchar_no_trailing_blanks、 および pushdown の設定を検討してください。 これらのオプションの設定については、 "連合データベース照会に影響を与えるサーバー・オプション"を参照してください。

DB2 タイプ・マッピングおよび関数マッピングの要因

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 を参照してください。

表 50. 列オプションとその設定値
オプション 有効な設定値 省略時設定
numeric_string

'Y'
はい - この列には数値データのストリングだけが含まれます。 重要: この列に、後書きブランクを付けられた数値ストリングだけが含まれる場合、 'Y' を指定することはお勧めできません。

'N'
いいえ - この列は数値データのストリングに限定されていません。

列の numeric_string を 'Y' に設定すると、 列データの分類に干渉するブランクがこの列には含まれないことを、 最適化プログラムに知らせることになります。 このオプションは、データ・ソースの照合順序が DB2 の照合順序とは異なる場合に役立ちます。 このオプションでマークされた列は、 照合順序が異なるためにローカルな (データ・ソースの) 評価から除かれるということはありません。

'N'
varchar_no_trailing_blanks 特定の VARCHAR 列に後書きブランクがないかどうかを示します。

'Y'
はい - この VARCHAR 列に後書きブランクはありません。

'N'
いいえ - この VARCHAR 列には後書きブランクがあります。

データ・ソース VARCHAR 列に埋め込みブランクがない場合、 最適化プログラムがその列にアクセスするときの戦略は、 列に後書きブランクが含まれているかどうかによって異なる部分があります。 省略時では、 最適化プログラムは後書きブランクを実際に含んでいるものと「想定」しています。 この想定に基づき、 これらの列から返された値が希望する値になるように照会を変更するアクセス戦略が開発されます。 ただし、VARCHAR 列に後書きブランクがなく、 そのことを最適化プログラムに知らせてある場合、 さらに効果的なアクセス戦略を開発することができます。 特定の列に後書きブランクがないことを最適化プログラムに知らせるには、 ALTER NICKNAME ステートメントでその列を指定してください (構文については、 SQL 解説書 を参照してください)。

'N'

後入れ先出しの機会に影響する照会特性

照会では、複数のデータ・ソースにあるニックネームを使用する SQL 演算子を参照できます。 DB2 が、セット演算子 (たとえば UNION) などの 1 つの演算子を使用して、 参照された 2 つのデータ・ソースからの結果を結合しなければならない場合、 この操作は DB2 で実行される必要があります。 この演算子は、リモート・データ・ソースで直接に評価することはできません。

後入れ先出し分析による決定の分析と理解

SQL ステートメントを書き直すと、DB2 照会処理のために、 さらに後入れ先出しの機会が提供されます。 このセクションでは、照会が評価される位置を判別するためのツールを紹介し、 照会分析と関連する一般的な質問 (および調査を提案する分野) をリストし、 最後にデータ・ソースのアップグレードについて短く説明します。

照会が評価される位置の分析

DB2 には、照会が評価される箇所を示すユーティリティーが 2 つ付属しています。

照会がデータ・ソースまたは DB2 で評価される理由

このセクションでは、一般的なプラン分析についての疑問と、 後入れ先出しの機会を増やすために調査する分野をリストしています。 主な疑問には、以下のものがあります。

データ・ソースのアップグレードとカスタマイズ

DB2 SQL コンパイラーには、 データ・ソース SQL サポートについての情報が多数含まれていますが、 データ・ソースはアップグレードまたはカスタマイズできるため、 そのようなデータをたびたび調整する必要があります。 その場合、ローカル・カタログ情報を変更することにより、 機能の拡張を DB2 に通知してください。 カタログを更新するときには、 DB2 DDL ステートメント (CREATE FUNCTION MAPPING や ALTER SERVER など) を使用します。 詳細については、SQL 解説書 を参照してください。

リモートでの SQL 生成とグローバル最適化

この段階は、照会を評価するためのグローバルで最適なアクセス戦略の作成に役立ちます。 連合データベースの照会の場合、アクセス戦略には、 元の照会を一連のリモート照会単位に分解してから結果を結合することが関係する場合があります。

後入れ先出し分析の出力を推奨値として使用することにより、 最適化プログラムはそれぞれの操作が DB2 でローカルに評価されるのか、 それともデータ・ソースでリモートに評価されるのかを決定します。 この決定は、コスト・モデルの出力に基づくものです。 コスト・モデルには、操作を評価するときのコストだけではなく、 DB2 とデータ・ソース間でデータまたはメッセージを伝送するときのコストも含まれています。

目標は最適化された照会を作成することです。ただし、 グローバルな最適化からの出力には多くの要因が影響するため、 照会のパフォーマンスにも影響があります。 主な要因として、サーバー特性とニックネーム特性の 2 つを説明します。

サーバー特性 / グローバル最適化に影響するオプション

グローバル最適化に影響することのあるデータ・ソース・サーバーの要因には、 以下のものがあります。

グローバル最適化に影響するニックネーム特性

続くセクションでは、グローバル最適化に影響する、ニックネームに特有の要因を説明します。

索引についての考慮事項

DB2 は、データ・ソースにある索引についての情報を使用して、 照会を最適化することができます。 この理由のため、DB2 で使用可能な索引情報が最新のものであることが重要となります。 ニックネームの作成時に、まずニックネームのための索引情報を獲得します。 視点のニックネームについては、索引情報が収集されることはありません。

ニックネームに関する索引仕様の作成

ニックネームのために索引仕様を作成することができます。 索引仕様では、 DB2 最適化プログラムが使用する索引定義 (実際の索引ではない) をカタログ内に作成します。 索引仕様を作成するには CREATE INDEX SPECIFICATION ONLY ステートメントを使用します。 ニックネームに対する索引仕様を作成する構文は、 ローカル表で索引を作成する構文と似ています。 詳細については、管理の手引き: 計画 を参照してください。

以下の場合に、索引仕様の作成を考慮してください。

視点のニックネームに対する CREATE INDEX ステートメントを発行する前に、 必要事項を考慮してください。 1 つのケースとして、視点が索引付きの表での単なる SELECT である場合、 ニックネームに関する索引のうち、表の索引と一致するもの (ローカルに) データ・ソースで作成すると、 照会のパフォーマンスを著しく改善することができます。 ただし、索引を、単なる SELECT ステートメントではない視点 (たとえば、 2 つの表を結合することにより作成する視点) でローカルに作成すると、 照会のパフォーマンスが低下する可能性があります。 たとえば、2 つの表の結合である視点で索引を作成する場合、 最適化プログラムは、ネストされたループ結合の内部要素として、 その視点を選択する場合があります。 この結合は複数回評価されるため、照会のパフォーマンスは低下します。 別の方法としては、データ・ソースの視点で参照される表ごとにニックネームを作成し、 両方のニックネームを参照する部分視点を DB2 で作成することができます。

カタログ統計についての考慮事項

カタログ統計には、ニックネーム全体のサイズと、関連する列での値の範囲が示されます。 これらの統計は、 ニックネームを含む照会を処理するときのコストを最小にする方法を計算する場合に、 最適化プログラムによって使用されます。 ニックネーム統計は、表統計と同じカタログ視点に格納されます。 統計のタイプとそれらをローカルに更新する方法については、 第 24 章, システム・カタログ統計表統計とニックネーム統計の更新の規則を参照してください。

DB2 は、データ・ソースに保持されている統計データを検索することはできますが、 データ・ソースにある既存の統計データに対する更新を自動的に検出することはできません。 さらに、DB2 には、オブジェクト定義を処理するための機構、 あるいはデータ・ソースにあるオブジェクトに対する構造的な変更 (列の追加) を処理するための機構が備えられていません。 オブジェクトの統計データまたは構造データに変更がある場合、 以下の 2 つから処置を選択することができます。

グローバル最適化の決定の分析と理解

このセクションでは、照会の最適化を分析するためのツールを紹介し、 照会の最適化と関連する一般的な質問 (および調査を提案する分野) を示します。

照会の最適化の分析

DB2 には、グローバル・アクセス・プランを示すユーティリティーが 2 つ付属しています。

DB2 最適化の決定

このセクションでは、最適化についての疑問と、 パフォーマンスを改善するために調べる主な分野をリストします。 主な疑問には、以下のものがあります。


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]