パーティション化されたテーブルのルールと使用上の注意 - Advanced SQL Engine - Teradata Database

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

Product
Advanced SQL Engine
Teradata Database
Release Number
17.05
17.00
Published
2020年6月
ft:locale
ja-JP
ft:lastEdition
2021-03-30
dita:mapPath
ja-JP/jpx1556733107962.ditamap
dita:ditavalPath
ja-JP/jpx1556733107962.ditaval
dita:id
B035-1184
Product Category
Software
Teradata Vantage
次の指針と制限は、すべてのパーティション化されたテーブルに適用されます。
  • テーブルのパーティション化が必要かどうかを分析するときには、常に、特定の戦略のコストとその利点とを注意深く比較検討してください。
    最低でも、次の要素すべてを考慮する必要があります。
    • パーティション式
      パーティション式の分析を行なうときは、次の要素すべてを考慮します。
      • テーブルに対して提供されるワークロードは、CASE_N、RANGE_N、またはその他の式に基づくパーティション式で十分にサポートされるか。
      • パーティション式では、NO RANGE、NO RANGE OR UNKNOWN、またはUNKNOWNオプションを指定する必要があるか。
      • テーブルをパーティション化する必要があるのは、1つのレベルでか、複数のレベルでか。
    • パーティション化されたテーブルにアクセスするクエリーのワークロード。

      この要素は、固有の、または特定のレベルと、一般的なレベル全体の両方で確認する必要があります。

      なかでも、特に考慮する必要があるのは次の点です。
      • パフォーマンス
        • 特定のワークロードまたは特に重要なクエリーで、パーティション化されていないテーブルがパーティション化されたテーブルよりも効率的に機能するか。
        • 1パーティション戦略は、他のパーティション戦略よりもパフォーマンスが優れているか。
        • USI、NUSI、結合インデックス、またはハッシュ インデックスなど、他のインデックスのほうがクエリーのパフォーマンスを向上させるか。
        • パーティション式によって、大幅な行または列パーティション排除が発生するかどうか。
      • アクセス方式および述部条件
        • プライマリ インデックス アクセス、セカンダリ インデックス アクセス、またはその他。
        • 通常のクエリーは、完全なパーティション列セットが含まれるプライマリ インデックスで等価条件を指定するか。
        • 通常のクエリーは、プライマリ インデックスに対して等価条件以外の条件を指定するか。
      • 結合戦略
        • 通常のクエリーは、プライマリ インデックス列セット(および、同じでない場合はパーティション列セット)で等価条件を指定するか。
        • 通常のクエリーは、パーティション列セットではなく、プライマリ インデックス列セットで等価条件を指定するか。
        • 代表的なクエリー条件は、行パーティション排除をサポートしているか。
    • データ保守
      • テーブルの保守ワークロードに関して、パーティション化されたテーブルとパーティション化されていないテーブルにどのような比較影響があるか。
      • 固有にするためにプライマリ インデックスでUSIを定義する必要がある場合、USIサブテーブルの更新にどのくらいの追加保守が必要か。
    • パーティション変更の頻度と簡易性
      • 必要に応じて範囲を追加および削除するプロセスがあるか。
      • パーティション式では、範囲の追加および削除が許可されるか。
      • 範囲の削除および追加で行が移動される場合に、移動される行が多いと、代わりに必要なパーティションで新しいテーブルを作成し、新しく作成したエラー ロギングの設定されたターゲット テーブルにソース テーブルの行をINSERT … SELECTまたはMERGEするプロセスがあるか。
      • パーティションが削除されたときに行を削除する場合に、NO RANGE、NO RANGE OR UNKNOWN、またはUNKNOWNのパーティションを指定したか。
    • バックアップおよび復元戦略
  • 以下のいずれかのテーブル タイプに対して、行パーティションを指定することができます。
    • SETテーブルまたはMULTISETテーブル
    • データ テーブルの実テーブル
    • グローバル一時テーブル
    • 揮発テーブル
    • 行圧縮されていない結合インデックス
  • 以下のどのテーブル タイプに対しても、行パーティションは指定できません。
    • キュー テーブル
    • 派生テーブル
    • 行圧縮された結合インデックス
    • ハッシュ インデックス
    • セカンダリ インデックス
  • 以下のいずれかのテーブル タイプに対して、列パーティションを指定することができます。
    • プライマリ インデックスの付いていないMULTISETテーブル
    • プライマリ インデックスの付いていない実データ テーブル
    • プライマリ インデックスの付いていない、行圧縮されていない結合インデックス
  • 以下のどのテーブル タイプについても、列パーティションは指定できません。
    • SETテーブル
    • グローバル一時テーブル
    • グローバル一時トレース テーブル
    • 揮発テーブル
    • キュー テーブル
    • 派生テーブル
    • 行圧縮されていない結合インデックス
  • 次のどのテーブル タイプにも、パーティション プライマリ インデックスは指定できません。
    • パーティション化されていないNoPIテーブル
    • 列パーティション テーブル
    • グローバル一時トレース テーブル
    • 行圧縮された結合インデックス
    • ハッシュ インデックス
    • セカンダリ インデックス
  • 識別列をパーティション列として使用してパーティション式を定義することはできません。
  • PPIをUNIQUEとして定義できるのは、パーティション式で参照されるすべての列が、プライマリ インデックスを定義する列リストでも参照される場合だけです。
  • LOB列をパーティション式で指定することはできません。
  • パーティション式には外部UDFもSQL UDFも指定することはできません。
  • パーティション式の中でPERIOD列を直接指定することはできません。ただし、パーティション式の中のPERIOD列で、BEGIN境界関数およびEND境界関数を指定することはできます
  • PRIMARY KEY制約またはUNIQUE制約を、プライマリ インデックス列リストと同じ列のセットに対して定義できるのは、次の条件が両方とも満たされる場合のみです。
    • すべてのパーティション列がプライマリ インデックス列リストに含まれるとは限らない場合。
    • USIが、プライマリ インデックスと同じ列セットに対して明示的に定義されていない場合。そのようなPRIMARY KEYまたはUNIQUE制約があれば、プライマリ インデックス列リストと同じ列のセット上で、暗黙にUSIを定義します。
  • すべてのパーティション列がプライマリ インデックス列リストでも参照される場合、PPIを持つテーブルでUSIを定義することはできません。

    その代わり、プライマリ インデックスを固有として定義してください。

  • PPIを持つテーブルにあるNUSIは、プライマリ インデックス列リストと同じ列のセットで定義され、すべてのパーティション列がプライマリ インデックス列リストで重複する場合、値によって順序を付けられなければなりません。

    注意するべき点として、ORDER BY句を指定して作成する複数列NUSIは、1つのテーブルに対して定義可能な最大32個のセカンダリ インデックス、ハッシュ インデックス、および結合インデックスの任意の組み合わせについて、2つの連続したインデックスとしてカウントされます。これには、PRIMARY KEYおよびUNIQUE制約を実装するために使用される、システム定義のセカンダリ インデックスが含まれます。

  • 列パーティション テーブルにNUSIが必要であるとは想定しないでください。

    列パーティション テーブルにNUSIを追加するのは、そのことにメリットがある場合だけにするべきです。

  • partitioning_expressionで参照する列は、行パーティション テーブルのパーティションが定義されているテーブルの列のセットから取る必要があります。

    これは、列パーティション テーブルには当てはまりません。そのテーブルにプライマリ インデックスはありません。

  • partitioning_expressionの結果のデータ型がINTEGER、BIGINT、またはCHARACTERでない場合、システムはその値をサイズに応じてINTEGER型またはBIGINT型に暗黙的にキャストします。
  • パーティション化されたテーブルに行を挿入または行を更新しようとした場合に、パーティション式の生成する値(結果の型がBIGINTでなければBIGINTにキャストした後の値)が1 ~  9,223,372,036,854,775,807の範囲内でないときに、その挿入操作または更新操作に対してシステムからエラーが返されます。

    すべての行の挿入または更新を許可するパーティション式を開発する場合、CASE式、CASE_NおよびRANGE_N関数のオプション、およびRANGE_N関数のアスタリスクを使用してそのような式を構築することができます。CASE_N関数およびRANGE_N関数の使用に関する詳細は、<Teradata Vantage™ - SQL関数、式、および述部、B035-1145>を参照してください。

  • DATE値をINTEGERおよびBIGINTにキャストすることは可能なので、これらの値はパーティション式に対して有効な値です。ただし、BIGINTにキャストした場合、DATE「1900-01-01」からDATE「1906-12-31」までの間の値のみが1から9,223,372,036,854,775,807までの値になります。

    これを補正するため、パーティション式を次の例のようにして調整できます。

    PARTITION BY d1 - 36890

    d1は、INTEGER値にキャストされる場合にDATE「2001-01-01」からDATE「2007-12-31」までの値にすることができます。

    日付を処理するさらに良い方法は、次の例で示すとおり、パーティション列がDATE型である場合にRANGE_N関数のみを使用する方法です。

    PARTITION BY RANGE_N(d1 BETWEEN DATE '2001-01-01'
                         AND DATE '2007-12-31')
                         EACH INTERVAL '1' DAY)
  • partitioning_expressionがCASE_N関数だけである場合、定義される条件数が214,748,647 以下のときに限って(<Teradata Vantage™ - SQL関数、式、および述部、B035-1145>にあるCASE_Nの説明を参照)、NO CASE [OR UNKNOWN]オプションおよびUNKNOWNオプションを使用できます。

    この制限は、パーティション式が、副式にCASE_N関数を使用している場合にも適用されます。

    さらに、追加のオプションを指定していない場合でも、システムはこの制限を強制します。

  • partitioning_expressionがRANGE_N関数だけである場合、NO RANGE [OR UNKNOWN]およびUNKNOWNオプションを使用可能にするためには、その関数に定義される組み合わせされた範囲の数が9,223,372,036,854,775,805以下でなければなりません。範囲が明示的に定義される場合(EACH句は使用ない )、65,535の範囲の制限を超過する前に、テーブル ヘッダー、リクエスト テキスト、暗黙制約チェック、またはEVLコードなどの他のサイズ制限に達することもあります。

    この制限は、これらのオプションが指定ないときでも適用されます。これにより、NO RANGE [OR UNKNOWN]オプションまたはUNKNOWNオプションを含めるよう後でインデックス定義を変更することができます。

    このルールは、パーティション式が、副式にRANGE_N関数を含めている場合には適用されません。

    RANGE_Nの説明については<Teradata Vantage™ - SQL関数、式、および述部、B035-1145>、ALTER TABLE文を使用してテーブルからパーティション範囲を削除するNO RANGEオプションの意味についてはADD RANGEオプションとDROP RANGEオプションを使用したパーティションの変更を参照してください。

  • 次のテーブル タイプについては、システム派生PARTITION列に関する統計を収集できません。
    • 結合インデックス (CREATE JOIN INDEXを参照)
    • グローバル一時テーブル
    • 揮発テーブル

パーティション プライマリ インデックスの詳細について、<Teradata Vantage™ - データベースの設計、B035-1094>および<Teradata Vantage™- SQLリクエストおよびトランザクション処理、B035-1142>を参照してください。

ALTER TABLE文を使用してテーブルのプライマリ インデックス定義を変更する方法については、テーブルのプライマリ インデックス、基本AMPインデックス、またはパーティションの再定義を参照してください。