- PARTITION BY句でのパーティション式の順番は、システムがパーティションを除去する機能に影響を与えることはありませんが、パーティションのスキャンの効率には影響を与えます。各内部パーティションに多数の行がある場合、このことは問題にはなりません(この場合の多数とは、複数のデータ ブロックにまたがる範囲の行という意味です)。次の2つのケースを考えてみます。
- 65,535個の組み合わせパーティション(組み合わせパーティション式の65,535パーティション)、AMPごとに6.5535 x 109行、100バイトの行、および50 KBデータ ブロックを持つテーブルの場合、各組み合わせパーティションの範囲は200~201データ ブロックになります(行がパーティション間で均等に分布していることを想定)。この場合、内部パーティションをスキップすることで多大なオーバーヘッドを被ることがあってはなりません。データ ブロック読込みにおけるすべての、またはほとんどすべての行が修飾する必要があり、少なくとも199のデータ ブロックがデータ ブロック読込みの各セット間でスキップされます。
- テーブルに、AMPごとに6.5535 x 106行のみがある場合、各組み合わせパーティションには、約0.2データ ブロックのみがあります。最低レベルで1つおきのパーティションのみが排除されるという最悪のケースでは、各データ ブロックが読み込まれる必要があるため、フルテーブルスキャンのほうが効率的です。最適化ルーチンは、これら2つの選択肢の間の違いを見積もりません。行パーティション排除を実行できる場合、テーブルのフルテーブルスキャンのほうが効率的であっても、排除を実行します。
最低レベルに5パーティションがあり、5パーティションのうち4つが除去される場合、各データ ブロックは引き続き読み込まれる必要があります。
最低レベルに6パーティションがあり、6パーティションのうち5つが除去される場合、一部のデータ ブロックがスキップされることがありますが、被ったオーバーヘッドを克服するにはおそらく十分ではなく、テーブルの全テーブル スキャンより効率的ではない可能性があります。
最低レベルで除去される多数のパーティションと同様に、最低レベルでの多数のパーティションでは、十分な追加データ ブロックがスキップされて被ったオーバーヘッドを克服でき、結果としてテーブルの全テーブル スキャンよりも効率的になる場合があります。
この場合、マルチレベル パーティションの良い使用方法ではない。その代わりに、各内部パーティションに対して複数のデータ ブロックのあるパーティションや、内部パーティションにデータが入っていない代替パーティションを検討してください。より役立つパーティション スキームは、最低レベルに最も多いパーティションがあり、組み合わせパーティションごとにより多くの列がある状態で、より少ないレベルのパーティションを定義するスキームまたはレベルごとにより少ないパーティションを定義するスキームです。
たとえば、1つのレベルが1日おきにパーティション化されていた場合、この間隔を1週間または1か月に変更するほうが良いかもしれません。
行パーティション階層の低いレベルで行パーティション排除を行うと、より多くのスキップが必要になり、これが原因でI/Oが増えるだけでなく、CPUパスも長くなります。
最高のパフォーマンスを実現するには、一般的なワークロードに対してパーティション階層のより高いレベルで行パーティション排除が発生するようなパーティション式を指定する必要があります。行パーティション排除があまり発生ないパーティション式は、階層の低いレベルで指定するか、指定をすべて削除するべきです。
また、行パーティション数が最も多いパーティション式を、パーティション階層の最も低いレベルに置くことを検討してください。ただし、組み合わせパーティションあたりのデータ ブロックが多い場合には、行パーティション式の順番は重要な要素ではないかもしれないことを念頭に置いてください。
パーティションの数がRANGE_Nパーティション式のために変更されることが予想される場合、そのパーティション式は、階層の最高レベルで指定される必要があります。
次のクエリーを使用して、組み合わせパーティションごとの平均行数を調べることができます。
SELECT AVG(pc) FROM (SELECT COUNT(*) AS pc FROM t GROUP BY PARTITION) AS pt;
次のクエリーを使用して、組み合わせパーティションごとの平均データ ブロック数を調べることができます。
USING (b FLOAT, r FLOAT) SELECT (:r/:b) * AVG(pc) FROM (SELECT COUNT(*) AS pc FROM t GROUP BY PARTITION) AS pt;
説明
構文の要素 指定内容 b 平均ブロック サイズ r 行サイズ
- 通常、マルチレベル パーティションは、組み合わせパーティション式の多数のパーティションを定義します。組み合わせパーティション式の空でないパーティションの数が多くなっている場合、プライマリ インデックスアクセス、結合、プライマリ インデックスでの集約のパフォーマンスが低下することがあります。
結果として、マルチレベル パーティションが適切な選択となるのは、これらの操作をほとんど実行することがなく、パーティション排除もほとんど行なわない場合です。とはいえ、組み合わせパーティション式に対して多数のパーティションが割り当てられるという状況は、パーティション排除のおかげで少数のパーティションにのみアクセスすればよいという場合に、処理する必要のあるデータ ブロック数を減らします。
- マルチレベル パーティションによってパーティション化されたテーブルで、行のパーティション式の1つがnullになることのある場合は、テーブルに行を挿入または更新しようとすると、挿入または更新リクエスト(Teradataセッション モード)、あるいはトランザクション(ANSIセッション モード)はアボートし、システムはリクエスト側にエラー メッセージを返します。
- すべての有効な行が挿入可能で、そのためその行のすべてが更新可能であるようにテーブルを定義する場合、パーティション列の値をもつ、またはnullの1つの行が、RANGE_NまたはCASE_N関数がnullを返さない一部のパーティション番号に割り当てられるように、各パーティション式を構築する必要があります。
RANGE_N関数でNO RANGE [OR UNKNOWN]オプションとUNKNOWNオプションおよびアスタリスクを使用し、CASE_N関数でNO CASE [OR UNKNOWN]オプションおよびUNKNOWNオプションを使用して、そのパーティション式の構築を容易にできます。
これらのオプションを、テーブルの中にあってはならない行を含めることを許可するパーティション式を構築するためには使用しないでください。パーティションを定義することで、それらの行がクエリー パフォーマンスに悪影響を与えます。
これらのオプションおよびアスタリスクを使用すると、テーブルのパーティションを変更するためにALTER TABLE文を効果的に使用できなくなることもあります。ALTER TABLE (テーブルの基本的なパラメータ)を参照してください。
- パーティション式の評価時に、ゼロで割るなどの式の評価エラーが発生する可能性があり、ANSIモード リクエストまたはTeradataモード トランザクションがロールバックされます。
そのようなエラーが発生しないようにパーティション式を構築する必要があります。
- 超過したパーティションは、レベル1に予約され、他のレベルに追加することはできません。つまり、2バイト パーティションの場合、レベル1のパーティション最大数は次のようになります。
8バイト パーティションのレベル1のパーティションの最大数は、以下のようになります。
説明
等式要素 指定内容 式の下限または低いほうの切り捨て値 di レベルiで定義されるパーティション数 場合によっては、2とパーティション最大数の間になるようにレベル1を変更できます。
マルチレベル パーティションを定義したテーブルのさまざまな面について、次のような指針およびルールが適用されます。