17.00 - 17.05 - パーティション テーブルと結合インデックス - Advanced SQL Engine - Teradata Database

Teradata Vantage™ - SQLデータ定義言語 詳細トピック

Product
Advanced SQL Engine
Teradata Database
Release Number
17.00
17.05
Release Date
2020年6月
Content Type
プログラミング リファレンス
Publication ID
B035-1184-170K-JPN
Language
日本語 (日本)

結合インデックスは、行単位、列単位、または複数レベル列の単位でパーティションされた(1つ以上の行パーティション レベルで)テーブルで作成することができます。さらに、結合インデックスを行パーティションまたは列パーティションすることもできます。列パーティション結合インデックスのルールと制限を参照してください。

結合インデックスのパーティション式は、数値データまたは文字データのいずれかに基づいて作成できます。パーティション プライマリ インデックスと非パーティション プライマリ インデックスを参照してください。

結合インデックスの行パーティションは、その基盤である基本テーブルで、例えばSQL DELETE、INSERT、MERGE、またはUPDATE操作によって更新できる行の制約として機能します。基本テーブルにおける行の挿入、更新、または削除を妨げない、結合インデックスのパーティション式を定義します。

パーティション式の1つ以上でDATE関数、CURRENT_DATE関数、またはCURRENT_TIMESTAMP関数を指定する結合インデックスに対してパーティションを作成できます。DATEまたはTIMESTAMPの組み込み関数を使用したパーティション式を参照してください。これらのパーティション式の日付値およびタイムスタンプ値を定期的に調整するには、ALTER TABLE TO CURRENT文を使用します。ALTER TABLE TO CURRENTを参照してください。

行パーティションは、パーティション列セットに対する範囲クエリーのパフォーマンスの最適化には有効ですが、非範囲クエリーや、結合インデックスのパーティション式に含まれない列に対する範囲クエリーの場合は、変化がないか、最適には及ばないことがあります。そのため、実働環境に行パーティション結合インデックスを導入する前に、十分なパフォーマンスのテストが必要です。

アプリケーションによっては、NO RANGEパーティションおよびUNKNOWNパーティションを使用して(NO RANGEおよびUNKNOWNパーティションの目的と動作を参照)、結合インデックスのパーティション式の1つ以上の結果がNULLになるINSERTリクエスト、UPDATEリクエスト、およびDELETEリクエストを、アボートされることなく安全に扱うことができます。処理の難しいこのような更新リクエストは、これ以外の方法ではアボートされます。ここでは、更新という語は一般的な意味で使用され、削除、挿入、更新、またはマージ操作を意味しています。

CREATE JOIN INDEX文でWHERE句を指定して、WHERE句の条件に一致する行だけがインデックスに挿入されるスパース結合インデックスを作成できます。結合インデックスの行が更新され、更新後にWHERE句の条件に一致しなくなる場合は、その行はインデックスから削除されますスパース結合インデックスを参照してください。

このアクティビティのプロセスは次のとおりです。

  1. 行への更新が行なわれた後、Teradata DatabaseはWHERE句の条件が真の値になるかどうかをチェックします。
    条件の結果 説明
    FALSE スパース結合インデックスから行を削除します。
    TRUE スパース結合インデックスに行を残し、ステップbに進みます。
  2. Teradata Databaseは、更新された行のパーティション式の新しい結果を評価します。
    パーティション式の結果 説明
    nullまたは範囲(1~65,035)外の値である(2バイト パーティションの場合)、あるいは範囲(1~9,223,372,036,854,775,807)外の値である(8バイト パーティションの場合)。 基本テーブルまたはスパース結合インデックスが更新されず、エラーが返されました。
    範囲内(1~65,035)の値である(2バイト パーティションの場合)、あるいは範囲内(1~9,223,372,036,854,775,807)の値である(8バイト パーティションの場合)。 おそらく以前格納されたときとは異なる適切なパーティションに行を格納し、処理リクエストを続行します。

また、インデックスの保守が必要な場合にはTeradata DatabaseによってWHERE句が最初にチェックされ、WHERE句の条件を満たせる場合にのみパーティション式の制約がチェックされるため、スパース結合インデックスも役に立ちます。

ワークロードをサポートするために作成する結合インデックスを決定するときは、次の要素をすべて考慮する必要があります。
  • データ モデル
    • テーブル定義
    • 外部キーとプライマリ キーの制約
    • 次元階層
  • ワークロード
    • クエリー パターン
    • クエリー頻度
    • クエリーの優先順位
  • データ保守
    • 保守の頻度
    • データ保守文およびコマンドで指定された制約

ワークロードに最適なインデックスを確実に定義するため、パーティション インデックスと結合インデックスの利点と欠点の両方を考慮します。結合インデックスが実際に使用されるかどうかを検証し、最適化ルーチンがクエリーにパーティション関連の最適化を適用するかどうかを判別するには、EXPLAINリクエスト修飾子を使用します。

パーティション式の評価中に、式の評価エラー(ゼロで割られているなど)が発生することがあります。こういったエラーに対するシステムの応答は、エラー発生時に有効になっているセッション モードによって異なります。

セッション モード 実行されたロールバック
ANSI アボートされた文を含むリクエスト。
Teradata アボートされたリクエストを含むトランザクション。

パーティション式を設計する場合、式のエラーが発生しない、または発生する可能性が低いように式を作成する必要があります。

場合によっては、ALTER TABLE文を使用して結合インデックスのパーティションを再検証するか、ALTER TABLE TO CURRENT文を使用できます。MODIFY PRIMARY句に関する一般的なルールALTER TABLE TO CURRENTおよびALTER TABLE … REVALIDATEの比較を参照してください。

ALTER TABLE TO CURRENT文を使用すると、まず削除した後に再作成するという処理なしに、結合インデックスの内容を更新できます。削除して作成する方式のALTER TABLE代替手段と比較したALTER TABLE TO CURRENTリクエストの相対的効率は、結合インデックスを更新するために必要となるALTER TABLEリクエストの実行回数だけでなく、パーティションで定義されたDATE、CURRENT_DATE、またはCURRENT_TIMESTAMP条件のタイプによっても異なります。

結合インデックスをめったに更新せず、DATE、CURRENT_DATE、またはCURRENT_TIMESTAMP条件のために古い行を大量に削除して新しい行を大量に挿入する必要がある場合は、結合インデックスを削除して再作成した方が効率的な場合があります。

例えば、DATE、CURRENT_DATE、またはCURRENT_TIMESTAMPの新しい値の結果として結合インデックスのパーティション列のセットが更新される場合のような明らかなケースでは、ALTER TABLE TO CURRENTリクエストはパーティション式のすべての行を内部的に削除した後に、DATE、CURRENT_DATE、またはCURRENT_TIMESTAMPの新しい値を使用して結合インデックスを再作成します。

DELETE ALL操作に続いてインデックスの再作成を必要とする、あまり明らかでない場合は、その方式の方が効率的です。しかし、ALTER TALBE TO CURRENTリクエストはその方式を使用しないので、削除して再作成する代替手段を使用することを考慮に入れる必要があります。

結合インデックスを削除した後、再作成する場合は、結合インデックスを削除した時点で、既存のセキュリティ権限と結合インデックスについて収集されたすべての統計が削除されています。

実テーブルとその結合インデックスの両方に対してALTER TABLEリクエストを実行しなければならない場合は、DATE、CURRENT_DATE、またはCURRENT_TIMESTAMPの下限条件のみを指定した結合インデックスに対してALTER TABLEリクエストを実行することを考慮に入れる必要があります。DATE、CURRENT_DATE、またはCURRENT_TIMESTAMPの下限条件とは、DATE、CURRENT_DATE、またはCURRENT_TIMESTAMPが最新の日付値またはタイムスタンプ値に更新されると(例えばj > CURRENT_DATEの場合)、結合インデックスの行が削除されることになる条件のことです。

この方式を使用した場合、実テーブルに対するALTER TABLEリクエストの実行後に必要な結合インデックスの保守は、結合インデックスに対するALTER TABLEリクエストによって削除された結合インデックス行に対して余計に行なう必要はありません。

パーティション プライマリ インデックスおよびそれらを使用する際のルールと推奨事項についての追加情報は、パーティション プライマリ インデックスと非パーティション プライマリ インデックスパーティション化されたテーブルのルールと使用上の注意、およびTeradata Vantage™ - データベースの設計、B035-1094を参照してください。

Teradata Databaseでは、以下のような結合インデックス保守の場合に、高速パスのDELETE操作と高速パスの遅延パーティションDELETE操作の両方が使用されます。
  • 以下のシナリオでの高速パスの遅延パーティションDELETE操作。
    • 非パーティション結合インデックスを使用して定義されているテーブル。
    • パーティション結合インデックスを使用して定義されている非パーティション テーブル。
    • PPI結合インデックスを使用して定義されているPPIテーブル。
  • 複数のDELETE ALLリクエストを含む暗黙的な複数文リクエスト トランザクションまたは複数文トランザクションでの複数のDELETE ALLステップに対する高速パスのDELETE操作。Teradata Databaseでは、DELETE ALL table_nameリクエストがtable_nameを参照しているトランザクション内の最後のリクエストの場合にこのリクエストを処理するために、ANSIセッション モードとTeradataセッション モードの両方で高速パスDELETE操作を使用します。
  • テーブルに単一テーブル結合インデックスまたは集約結合インデックスが含まれていて、インデックスが以下のいずれかである場合の高速パスのDELETE操作。
    • 単一テーブル結合インデックス。
    • 内部結合とともに定義された複数テーブルの結合インデックス。
    • 削除されるテーブルが外部結合の外部テーブルである複数テーブルの結合インデックス。

    上記の条件は、以下の場合に適用される。

    • 単純結合インデックスまたは集約結合インデックスを含むテーブルに対するDELETE ALL操作。Teradata Databaseでは、基本テーブルとその結合インデックスの両方を処理するために高速パスDELETE操作が使用されます。
    • 単純結合インデックスまたは集約結合インデックスを含むテーブルに対する条件付きDELETE操作。Teradata Databaseでは、DELETE条件がインデックス全体をカバーしている場合に結合インデックスを処理するためにのみ高速パスDELETE操作を使用します。

結合インデックス パーティションDELETE操作およびDELETE ALL操作によって、結合インデックス保守のパフォーマンスが大幅に向上します。