統計を収集または再収集するための最適なタイミング - Advanced SQL Engine - Teradata Database

Teradata Vantage™ - SQLリクエストおよびトランザクション処理

Product
Advanced SQL Engine
Teradata Database
Release Number
17.10
Published
2021年7月
Language
日本語
Last Update
2021-09-23
dita:mapPath
ja-JP/uqf1592445067244.ditamap
dita:ditavalPath
ja-JP/wrg1590696035526.ditaval
dita:id
B035-1142
Product Category
Software
Teradata Vantage

長い目で見たときに最良のテーブル統計を提供する方法が全テーブル統計を頻繁に収集および再収集することであると知っている以上、フル テーブル統計を収集するか、何らかのサンプル統計を収集するか、または統計を収集しないかを選ぶことはユーザー自身がすることです。サンプリング パーセンテージ、経過日数しきい値、またはデータ デモグラフィック変更パーセンテージしきい値を指定して、Vantageに、指定されたしきい値未満の場合は統計を再収集しないように指示するという選択肢もあります。テーブル内の行が更新または削除された場合あるいはオブジェクト使用カウントおよびUDIシステムによってテーブルに新しい行が追加された場合はテーブル カーディナリティが更新されるため、統計が最新かどうかに関係なく、最適化ルーチンは正確なカーディナリティ情報にアクセスできることにも注意してください。これらのシステムの詳細については、オブジェクト使用カウントとUDIカウントを参照してください。

Teradataは、常に定期的にフル テーブル統計を収集することをお勧めします(ただし、USING句のサンプリングまたはしきい値オプションを指定する場合を除きます)。この場合は、最適化ルーチンが、列またはインデックス セットに関する統計の再収集要求を実行すべきかどうかを判断します。COLLECT STATISTICS要求を発行する責任はユーザー側にありますが、1つ以上のサンプリングまたはしきい値オプションが指定された場合に、Vantageは関連ヒストグラムのさまざまな履歴基準に基づいて指定された統計を再収集するかどうかを判断します。詳細については、サンプル統計の再収集と<Teradata Vantage™ - SQLデータ定義言語-構文規則および例、B035-1144>のCOLLECT STATISTICS(最適化ルーチン形式)に関する情報を参照してください。

どれくらいの頻度で統計を再収集すべきかは、複数の要因に依存します。また、最初の統計収集時に使用可能なサンプリング オプションとしきい値オプションを利用した場合は、統計の再収集が必要になるタイミングを判断する必要がありません。これは、Vantageによって自動的に判断されるためです。

この判断を自動的に行わないようにする場合は、1つ以上のサンプリングまたはしきい値オプションを使用して統計の収集リクエストと再収集リクエストを発行する必要があります。これらのオプションについては、このトピックでも簡単に説明されていますが、Teradata Vantage™ - SQLデータ定義言語-構文規則および例、B035-1144の「COLLECT STATISTICS (最適化ルーチン形式)」文に関するマニュアルに詳細が記載されています。その後は、統計再収集のリクエストを実行するだけです。Vantageは、指定したしきい値とサンプリング基準に基づいて、統計の再収集が必要かどうかを判断します。システムが統計の収集は不要と判断すると、再収集リクエストは無視されます。そのため、不要な統計の再収集について配慮する必要はありません。

列とインデックスのデモグラフィックに加えられたさまざまな質的および量的変更によっては、残余統計が新しく収集した統計と同じくらい有用であることがあります(これを評価するときに考慮に入れる要因の一部については、静的列における残余統計と動的AMPサンプル統計の相対的な正確度を参照)。

もちろん、実働環境で遭遇するさまざまな状況においてどの方式が最適かを決めるのはユーザー自身です。種類の異なるテーブルすべてに対して、1つの方法では不十分であると判断するかもしれません。全AMPサンプル統計を使用することで、非常に大さなテーブルでも十分に正確さを得られ、フル テーブル統計を収集したなら消費したかもしれないシステム リソースを使わずにすむという場合もあります。

良い統計の操作上の定義は最適な問合わせ計画を作成する統計である、ということを常に念頭においてください。テーブルの列およびインデックスの統計をいつどのように収集するかは、最適な問合わせ計画を自分がどのように定義しているかによって左右されます。

動的AMPサンプリングによって得られる統計を除いて、統計はグローバルに収集されるので、システムの再構成には影響を受けないことに注意してください。言い換えれば、すべてが等しいので、システムの再構成後に統計を再収集する必要はありません。

Teradata Viewpoint統計マネージャの使用

Teradata Viewpoint統計マネージャ ポートレットは、新しい統計の収集すべき時期を決定するメソッドを提供します。

このポートレットの使用法と機能の詳細については、Teradata Viewpoint統計マネージャおよび<Teradata® Viewpointユーザー ガイド、B035-2206>を参照してください。

統計を収集するためのポリシー

統計を収集する際のポリシーとして提案されているもののいくつかを、次のテーブルに示します。各ポリシーの評価を「推奨」または「強く推奨」で表わします。

Vantageは指定されたしきい値が満たされていなければ統計を再収集しないため、しきい値を使用して統計を収集する場合は、このようなポリシーの順守がそれほど重要ではありません。COLLECT STATISTICSリクエストを発行する必要はありますが、指定されたしきい値未満の場合は統計が再収集されません。これにより、不要な統計を再収集するために、貴重なシステム リソースを浪費しなくて済みます。

ポリシー 必須または推奨
データベースを新しいリリースにアップグレードしたときに、すべての統計を再収集する。 強く推奨
10パーセント ルールにより、テーブルまたはパーティションのデモグラフィックを10パーセント以上変更する際に常に統計を再収集する。このルールは、行パーティション化と列パーティション化の両方に適用します。
  • 非パーティション テーブルの場合、テーブルのデモグラフィックが10パーセント以上変化したときには、必ず統計を再収集します。
  • 行パーティション化されたテーブルの場合、行パーティションのデモグラフィックが10パーセント以上変化したときには、必ず統計を再収集します。
  • 列パーティション化されたテーブルの場合、列パーティションのデモグラフィックが10パーセント以上変化したときには、必ず統計を再収集します。

日付やタイムスタンプなどの極めて非固有性の高い値が大量である場合は、集団が7パーセントでも変更したときに統計を再収集することを考慮してください。

強く推奨
統計を収集および再収集する場合は、適切なサンプリング オプションとしきい値オプションのどちらかまたはその両方を指定します。こうすると、新しい統計を収集する必要があるかどうかを最適化ルーチンで判断できます。COLLECT STATISTICSリクエストのUSING句でサンプリング オプションとしきい値オプションを指定する方法については、Teradata Vantage™ - SQLデータ定義言語-構文規則および例、B035-1144のCOLLECT STATISTICS (最適化ルーチン形式)を参照してください。 強く推奨
新しく作成された空のテーブルで統計を収集して、それ以降の統計収集に備えてデータ構造の概要を作成する。 推奨
固有値あたりの行数が100より少なくなったときに必ず統計を再収集する。 推奨

次のテーブルでは、統計の収集についてより具体的な推奨事項を示します。ここに示す推奨事項は、最低限必要なものと理解してください。

テーブルのカテゴリ 収集すべき統計
すべて 結合条件に使用されているすべての列
すべてのNUPI
小さいテーブル

この文脈での小さいテーブルとは、カーディナリティがシステムにあるAMPの数の5倍より少ないテーブルのことです。20のAMPがあるシステムの場合、テーブルのカーディナリティが100行未満のとき、小さいテーブルとみなされ、同様に100のAMPがあるシステムでは500行未満、というようになります。

プライマリ インデックス
最良のクエリー計画を確実にするには、次のより一般的なテーブル列の統計を収集することも考慮してください。
  • すべてのインデックス。
  • アクセス頻度の高い結合列
  • WHERE句述部で頻繁に参照されているインデックス付きでない列(特にそれらの列にひずみがあるデータが含まれている場合)。
  • 行パーティション化されたテーブルのパーティション列のセット。
  • 全パーティション(列または行)テーブルの、システム定義PARTITION列。

    列パーティション化されたテーブルでは、システム派生PARTITION列の列パーティション番号の値が必ず1になるので、PARTITION列で収集された統計は、それぞれの結合行パーティションに含まれる行の数と等しくなります。