パーティション テーブル(行または列)では、PARTITION統計、および行パーティション列セットに関する統計を常に収集してください。行パーティションのデモグラフィックに著しく変更が加えられた場合には、必ず統計情報を更新してください。テーブルのデモグラフィックの10パーセントが変わった後、統計を更新する一般指針である10パーセント ルールは、行パーティション列に適用されません。代わりに、10パーセント以上、partitionのデモグラフィックが変わったときは常に統計を再収集する必要があります。この指針は、行パーティション列セットとパーティション テーブルのシステム派生PARTITION列の両方に適用します。パーティション テーブルのシステム派生PARTITION#L n列の統計を収集できません。
これはルールではなく指針です。場合によっては、高品質のクエリー計画を維持するためにパーティション統計を更新する点を上または下に調整する必要があります。
行パーティション テーブルの場合、最適化ルーチンは、PARTITION統計を使用することによって、パーティション排除や入出力削減率などに基づいて選択しつつ、データが入っているパーティションの数を見積もります。列パーティション テーブルの場合、最適化ルーチンは、PARTITION統計を使用することによって、列圧縮率を見積もります。標準データ統計とデモグラフィックを評価してもこの見積もりをすることはできません。
PARTITION統計が存在する場合には、最適化ルーチンにおいて、より正確なパーティション化コスト評価が可能になります。最適化ルーチンにおいてそれを活用できるようにするため、単一列PARTITION統計は必ず収集するようにしてください。システム派生PARTITION列についての詳細は、<Teradata Vantage™ - データベースの設計、B035-1094>を参照してください。これらの統計を収集することはかなり高速です。これはこのような統計の収集が、100パーセント レベルである場合でさえも、テーブルと多い場合でもn+1のデータ ブロックを加えたものに対してシリンダ インデックスのスキャンのみ必要とするからです。ここでnはテーブルのパーティション数です。したがって、システムはテーブルに対するすべてのデータ ブロックをスキャンしません。100パーセントのデータで統計を収集するとき、別の列に対する場合と同様にです。
システムは、PARTITION列が複数列の統計収集の一部である場合、この高速収集方式を使用ない。システム派生PARTITION列の統計は、統計が最後に収集されたとき、各パーティションのカーディナリティと入力されたパーティション数の最良の見積もりを最適化ルーチンに提供します。
PARTITION統計から、最適化ルーチンはパーティションが空または入力されているどうかの情報を取得します。最適化ルーチンは、多数の空のパーティションがあるとき、候補のクエリー計画のより良いコスト見積もりを実行するため、次にこの情報を使用できます。定義されたパーティションは計画が実行される時点で空ではない可能性があるので、最適化ルーチンはそれらのパーティションすべてにアクセスする計画を生成する必要があります。
PARTITION統計が収集されていない場合は、最適化ルーチンは、次のとおりパーティションのカーディナリティを見積もります。
したがって、空のパーティションにより、最適化ルーチンは、パーティションのカーディナリティを少なく見積もることがあります。最適化ルーチンは、場合により、少ない見積もりを避けるためにパーティション数(特に最大数が65,535の場合)を減らします。ただし、正確なパーティションのカーディナリティの見積もりを保証する最良のポリシーは、実際に使用しているパーティションのみ定義し、システム派生PARTITION列で統計を収集することです。
システム派生PARTITION列を含む実テーブルの複数列統計を収集すると、複数列統計でシステム派生PARTITION列を含むすべての列がクエリーの単一テーブルの等価述部をもつときクエリーの計画コストの見積もりでメリットがあります。
- システム派生PARTITION列に関する統計を削除する。
- パーティション式を変更する。
- PARTITION統計を再収集する。
パーティションが空の状態から入力された状態に(または入力された状態から空の状態に)変わった場合、システム派生PARTITION列で統計を再収集する必要があります。
テーブルが大幅に変更されたときは、統計も最新の情報に更新する必要があります。行の10パーセントの変更(挿入、更新、削除、マージ操作による)に関する指針は、テーブル レベルではなくパーティション テーブルのパーティション レベルに適用します。場合によっては、ユーザーのアプリケーションの必要に応じてこの指針を調整する必要があります。
この指針に対する唯一の例外は、単一列式でロー パーティション化されたパーティション テーブルです。この場合は、行パーティション化列で収集する統計に加えて別々のPARTITION統計を収集する必要はありません。これらの列統計は単一列PARTITION統計として自動的に継承されるからです。
例えば、次のテーブル定義を考えます。
CREATE TABLE table_1 ( col_1 INTEGER, col_2 INTEGER) PRIMARY INDEX(col_1) PARTITION BY col_2;
col_2で個別列統計を収集する場合、この列はパーティション化列なので、これらの統計もPARTITION統計として継承されます。
PARTITIONは予約キーワードではないので、テーブル定義の列名として使用可能ですが、使用をお勧めしません。このやり方はいかなる場合にも、特にパーティション テーブルでは、絶対にお勧めしません。明示的に列にpartitionという名前を付けると、データベースはそれを通常の列として解釈するからです。結果として、partitionという名前のユーザー定義関数が指定されたテーブルのシステム派生PARTITION列の統計を収集できなくなります。
システムは、PARTITION列を含めてすべての列に単一テーブル等価条件がある場合、複数列PARTITION統計を使用して単一テーブル見積もりを行ないます。
また、非パーティション テーブルでもSUMMARY統計を収集する必要があります。それらの統計はすぐに収集することができ、最適化ルーチンがカーディナリティの見積もりを作成する際に大いに役に立つからです。
単一列PARTITION統計を収集するのにUSING SAMPLE句を指定することはできますが、この指定は無視されます。代わりに、システムは自動的に内部サンプリング パーセンテージを100に設定し直します。正確な統計を収集することが重要であり、PARTITION統計の収集は非常に高速な操作です。結果として、これらの統計の収集のパフォーマンスを良くするのにサンプリングは必要ではありません。詳細統計レポートのサンプリング フラグは、この動作を説明するため常に0とレポートされます。SHOW STATISTICSを参照してください。USING SAMPLE句は、複数列PARTITION統計で使用します。データベースは、2%のサンプリング パーセンテージを使用して収集プロセスを開始し、値のばらつきがシステム定義しきい値を超えると判別した場合は、動的にパーセンテージを増やします。