シリンダ読み取りは、単一データベース入出力操作にデータ ブロックをロードする方法です。テーブルのデータ ブロックの大部分またはすべてを処理するテーブル スキャンや結合などの操作に対する入出力をブロックする代わりに、最大2 MBのひとつの入出力を発行します。
シリンダ読み取りは1回のデータベース入出力操作で必要なデータ ブロックをロードするため、Vantageで発生する入出力オーバーヘッドは各データ ブロック当たりではなくシリンダあたり1回のみです。
シリンダ読み取りと入出力
ブロック サイズを大きくすると、特にサイズが小さめのテーブルではシリンダ読み取りの頻度が少なくなることが考えられます。これにより、ブロック単位の入出力リクエストが増加し、入出力リクエストが非常に増えることがあります。
AMP上でシリンダ読み取りの候補となるためには、アクセスするテーブルに関するデータ ブロックがシリンダに6個以上入っている必要があります。ブロック サイズを大幅に増加させると、各データ ブロックに入る行数が多くなるため、各AMPでテーブルの行を入れるために必要となるデータ ブロックは少なくなります。大きなテーブルの場合、これは問題になりませんが、小さめのテーブルの場合には、結果的に実行する入出力操作が増える場合があります。
シリンダ読み取りによって、スキャン時に1回の入出力操作で多数の行を読み取れるという利点を維持しながら、ブロック サイズを常に小さく保つことが可能になります。
シリンダ読み取りを使用したWALログ保守
ctlを使用してシリンダ読み取りをLogOnlyに設定すると、シリンダ スキャンがWALログ保守のみに制限されます。LogOnlyでは、WALログの平均サイズが小さくなります。シリンダ全体に代わって個々のデータ ブロックが読み込まれるため、テーブルのスキャン ジョブの実行が遅くなる可能性があります。
シリンダ読み取りをLogOnlyに設定すると、ユーザーがまず最初にシリンダ読み取りを無効にする原因となったシリンダ読み取りの性能異常が再発する可能性がありますが、 シリンダ読み取りを完全に無効にすると、WALログ保守に後れが生じるため、一般にシステムの処理速度が低下します。
しかし、シリンダ読み取りをLogOnlyに設定すると、シリンダ読み取りをWALログ保守にしか使用せず、テーブル スキャンには使用しない上に、WALログ保守は1分に1度バックグラウンドで実行するだけです。このため、異常の発生回数はシリンダ読み取りを完全に有効にした場合よりも少なくなります。
シリンダ読み取りのリソース利用の追跡
リソース利用ロギングを有効にした場合にシリンダ読み取り動作を追跡するためには、<Teradata Vantage™ - リソース利用マクロおよびテーブル、B035-1099>の「ResUsageSvpr Table」の「Cylinder Read Columns(シリンダ読み取り列)」を参照してください。