以下のセクションを変更する必要があります:
以下の情報はこのセクションにすでにある情報と置き換えるか 追加されます:
複製要約表は結合の並びの中で補助機構として使用することができます。 たとえば、ノードが 20 を超える大規模なファクト表スプレッドがあるスタースキーマを 所有していた場合、これらの表が連結されていると、ファクト表間の結合と ディメンション表が最も影響を受けます。
同一のノード・グループ内にすべての表を配置しようとすると、連結された結合の場合、多くても、正しく分割された一次元の表になります。 すべての他のディメンション表は連結された結合の中では使用することができません。 それは、ファクト表上の結合列がファクト表の区分化キーと対応している ためです。
たとえば、以下のようにコールされた表を所有することができます。 C1 で区分に分割された FACT (C1, C2, C3, ...) 表、C1 で区分に分割された DIM1 (C1, dim1a, dim1b, ...) 表、C2 で区分に分割された DIM2 (C2, dim2a, dim2b, ...) 表、など。
この例から、述部の DIM1.C1 = FACT.C1 が連結できるので、FACT と DIM1 間の結合が 完全であることがご覧いただけます。 これら表の両方は C1 列上で区分に分割されています。
述部 WHERE DIM2.C2 = FACT.C2 による DIM2 間の結合は連結できません。 これは FACT が C1 列上で分割されており、C2 列上ではないからです。
このケースで、ファクト表のノード・グループ内で DIM2 を複製することは 適しています。 この方法でそれぞれの区分をローカルで結合できるようになります。
複製要約表を作成する際に、ソース表は、シングル・ノード・グループか マルチ・ノード・グループが可能です。 ほとんどのケースで、表は小さく、シングル・ノード・グループ内に配置することができます。 以下のような方法で複製するデータに対して制限がかけられます。表から列まで サブセットのみ指定する方法、述部で使用された番号を通して行番号に制限をかける 方法、複製要約表を作成する際に、2 つの方法を利用する 方法です。
複製要約表はマルチ・ノード・グループでも生成することができます。 ノード・グループは、ユーザーの大規模な表のノード・グループと 同じです。 この場合、ソース表のコピーはノード・グループのすべての区分に作成 されます。 大規模なファクト表とディメンション表間の結合は、全区分に対し、ソース表を ブロードキャストするよりも、この環境内で、ローカルで行うことのできる よい機会になります。
複製された表の索引は、自動的に作成されません。 索引が作成されるとソース表で確認されているものとは異なる場合があります。
REFRESH ステートメントを使用した後は、他の表と同様に複製表で RUNSTATS を実行する必要があります。
複製表は照会で直接参照することができます。 ただし、特殊な区分で表データを参照するために複製表と一緒に 述部 NODENUMBER() を使用することはできません。
参照するために複製要約表が使用されている場合 (ソース表を参照した照会がある場合) は、EXPLAIN 機能を使用することができます。 始めに、EXPLAIN 表が存在することを確認します。 それから、実行しようとしている SELECT ステートメントの説明計画を 立てます。 最後に、EXPLAIN 出力をフォーマットするため db2exfmt ユーティリティーを使用します。
最適化プログラムによって選択されたアクセス・プランは、結合する必要がある、などの 情報に依存する複製要約表を使用する場合としない場合があります。 最適化プログラムが、他の区分に対してオリジナル・ソース表をブロードキャストするほうが より安価であると決定した場合、複製要約表は使用されないことも あります。
「"索引スキャン概念"」の下の「"重複索引アクセス"」セクション は変更されました。
そのセクションの終わりの注の前に、次の情報を追加します:
重複索引走査時の、ダイナミック・ビットマップのパフォーマンスを 認識するには、ソート・ヒープ・サイズ (sortheap) データベース構成パラメーターと、 ソート・ヒープのしきい値 (sheapthres) データベース・マネージャー構成パラメーターとの値を 変更する必要のある場合があります。
動的ビットマップがアクセス・プランの中で使用されている場合は、 追加のソート・ヒープ・スペースが必要になります。 sheapthres が比較的、sortheap に近い (つまり、並列問い合わせの割合が 2、3 回の係数よりも少ない) 場合、 重複索引アクセスに伴う動的ビットマップは、最適化プログラムが 想定した値よりずっと少ないメモリーで作動しなくてはなりません。
これを解決するには、sheapthres の値を sortheap と比較して増加させます。
「"述部用語"」の下の「"スター型結合の検索ストラテジー"」のセクションは 変更されました。
そのセクションの終わりに、次の情報を追加します:
スター型結合技法の一部によって、作成、使用された動的ビットマップは ソート・ヒープ・メモリーを使用します。 ソート・ヒープ・サイズ (sortheap) データベース構成パラメーターについて 詳しくは、管理の手引き: パフォーマンス マニュアルの第 13 章、「DB2 の構成」を ご覧ください。