データ ブロックのマージのパフォーマンスの事項 - Advanced SQL Engine - Teradata Database

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

Product
Advanced SQL Engine
Teradata Database
Release Number
17.05
17.00
Published
2020年6月
Language
日本語
Last Update
2021-03-30
dita:mapPath
ja-JP/jpx1556733107962.ditamap
dita:ditavalPath
ja-JP/jpx1556733107962.ditaval
dita:id
B035-1184
Product Category
Software
Teradata Vantage

小さいデータ ブロックを大きいデータ ブロックにマージしても、テーブル全体をスキャンするデータ変更ワークロードのパフォーマンスにしか影響を与えないため、SELECT文には直接の影響はありません。ただし、データ ブロックのマージが完了した後は、スキャンするデータ ブロックの数が少なくなるため、それ以降のすべてのテーブルの全テーブルスキャンおよびテーブルの全テーブル変更リクエストのパフォーマンスに間接的なプラスの影響を与えます。これは、テーブルの全テーブル スキャン操作は、ほとんどがI/Oバウンドであり、テーブルのデータ ブロックの数が減ると、I/Oのロードに直接的な影響があるためです。

データ ブロックのマージでは、テーブルの変更操作のパフォーマンスにプラスの影響とマイナスの影響の両方がありますが、テーブルの小さなデータ ブロックの大多数が大きなデータ ブロックにマージされると、マイナスの影響は無視できます。

たとえば、小さなデータ ブロックが過剰であるテーブルについて考えます。このようなテーブルは、通常、再構成、またはテーブルから多数の行を削除した場合のいずれかが理由で発生します。

データ ブロックのマージが有効になった後で、このテーブルの最初の全テーブル変更リクエストを実行した場合、マージ機能を有効にしなかった場合のデータ ブロックのマージより、コストが多くかかります。これは、多数の小さなデータ ブロックのマージに必要とされる作業すべてが原因です。

このテーブルで2番目の全テーブル変更リクエストを実行すると、データ ブロックのマージを有効にしなかった場合よりも、同じ操作に対するコストが高くなることも、低くなることもあります。このコストに対する不確定性に関連する要因は、次のとおりです。
  • 最初のテーブルの全テーブル変更中にマージされずに残っているデータ ブロックが多数ある場合、操作のコストは高くなります。
  • 最初の全テーブル変更中にデータ ブロックが多数マージされた場合、操作のコストは低くなります。
  • 操作のコストは、これらの両方の要因の組み合わせによって決定されます。

これらの要因は、データ ブロックの多数でマージが必要なくなる状態にテーブルが到達する、十分なテーブルの全テーブル変更が実行されるまで、継続して当てはまります。この場合、上記のリストの2番目の項目のみが当てはまり、テーブルの全テーブル変更は、データ ブロックのマージをまったく有効にしなかった場合より、パフォーマンスの大幅な向上が継続します。

データ ブロックの数が最も少ないテーブルは、ほとんどがI/Oバウンドであるテーブルの全テーブル スキャン変更操作中に、最も優れたパフォーマンスを実現します。

データ ブロックのマージが有効なテーブルの初期に行なわれるテーブルの全テーブル変更は、最初の項目で述べたように、I/Oパフォーマンスにマイナスの影響を与える傾向があります。これは、この機能を有効にしていない場合より、ディスクからの書き取りまたは読み取り(あるいはその両方)が行なわれるデータ ブロックの数と頻度が多くなるためです。ただし、そのようなテーブルの全テーブル スキャン変更を後で行なうと、I/O操作に改善が見られます。これは、2番目の項目で述べたように、テーブルでスキャンまたは変更するブロックの数が少なくなるためです。インデックス サブテーブルの更新でも、同様の傾向が見られます(例外はNUSIサブテーブルの更新で、小さいデータ ブロックを大きいデータ ブロックにマージしても影響を受けません)。

基本的な操作が、サブテーブルの最後に新しいデータを追加するテーブルでも、パフォーマンスの影響は見られません。これは、この機能では、基礎となる更新リクエストによってはスキャンされないテーブルの一部でデータ ブロックのセットをスキャンまたは更新しないためです。

単一のデータ ブロックのマージ操作中は、8個のデータ ブロックだけをマージできます。デフォルトでは、結果としてマージされたデータ ブロックは、テーブルの最大複数行データ ブロック サイズの60 %以上になることはできません。このパーセンテージのしきい値は、テーブルのマージ ブロック率を定義します。

最小ブロック サイズで定義されているテーブルの操作のパフォーマンスは、小さなデータ ブロックのマージによっては向上しません。これは、ほとんどのデータ ブロックのサイズがすでにマージ ブロック率のしきい値に近い場合、そのようなテーブルでデータ ブロックをマージする機会が少ないためです。さらに、最も負荷が高いワークロードを処理するよう注意深く設計されたデータベース スキーマは、小さなデータ ブロックのマージによって影響を受けません。これは、一般的なワークロードが行なう最も一般的な更新操作を最適化するよう、すでにテーブルのブロック サイズを調整しているからです。

ALTER TABLE文を使用してMERGEBLOCKRATIOの値を変更すると、各テーブルのマージ ブロック率を調整できます。ALTER TABLE (テーブルの基本的なパラメータ)を参照してください。

また、空のテーブルに対するINSERT操作およびINSERT … SELECT操作についても、目立つようなパフォーマンスの変化は見られないはずです。この場合、新しい行を作成するだけで、調査してマージする必要のあるブロックが存在しないからです。ただし、データが取り込まれたテーブルにINSERT…SELECT操作を実行すると、テーブルに対する最初の一連の更新操作のパフォーマンスが低下する可能性が高くなります。ただし、後で実行される一連の更新操作でパフォーマンスが改善されるため、このパフォーマンスの低下は相殺されるはずです。

ソース テーブルとマージ先のテーブルでプライマリ インデックスが異なる場合にINSERT … SELECT操作が発生するときは、行がAMP間で再配布されるため、テーブルの最初から最後まで操作がスムーズに進みません。この場合では、行はテーブルの最後に追加されるだけではないため、パフォーマンスが低下する可能性があります。

多数のテーブルの小さなデータ ブロックのマージが、システムのパフォーマンスに非常に大きな悪影響を与えている場合、多数のALTER TABLE文を実行して、テーブルごとにテーブルのマージ ブロック率の値を下げるのではなく、DisableMergeBlocks DBS制御パラメータの設定をデフォルト値のFALSEからTRUEに変更することによって、この機能をグローバルに無効にすることができます。詳細については、Teradata Vantage™ - データベース ユーティリティ、B035-1102を参照してください。