Veritas InfoScale™ 8.0 DB2 データベース用ストレージと可用性管理 - AIX, Linux
- 第 I 部 DB2 データベース用 SFHA (Storage Foundation High Availability) 管理ソリューション
- Storage Foundation for Databases の概要
- 第 II 部 Veritas InfoScale 製品を使用した DB2 の配備
- 第 III 部 Storage Foundation for Databases (SFDB) ツールの設定
- Storage Foundation for Databases リポジトリデータベースの設定および管理
- Storage Foundation for Databases (SFDB) リポジトリの設定
- Storage Foundation for Databases (SFDB) ツールの認証の設定
- Storage Foundation for Databases リポジトリデータベースの設定および管理
- 第 IV 部 DB2 データベースのパフォーマンスの向上
- データベースアクセラレータについて
- Quick I/O によるデータベースパフォーマンスの向上
- Veritas Concurrent I/O による DB2 データベースパフォーマンスの向上
- 第 V 部 PITC (Point-In-Time Copy) の使用
- PITC 方法の理解
- DB2 PITC に関する注意事項
- サードミラーブレークオフスナップショットの管理
- Storage Checkpoint の管理
- リカバリのための Database Storage Checkpoint
- SFHA 環境での NetBackup によるバックアップとリストア
- 第 VI 部 DB2 に対するストレージコストの最適化
- 第 VII 部 Storage Foundation for Databases 管理リファレンス
- Storage Foundation for Databases コマンドリファレンス
- Storage Foundation for Databases のチューニング
- SFDB ツールのトラブルシューティング
PREFETCHSIZE と EXTENTSIZE
プリフェッチは、DSS タイプの環境またはデータがデータベースのメモリで保守できないほど大きい環境のデータベースのパフォーマンスを高める動作です。エクステントサイズは、RAID デバイスに DB2 表領域とコンテナが存在する環境で重要です。一般に、EXTENTSIZE は必ず RAID ストライプサイズと等しい、または RAID ストライプサイズの倍数になります。
DB2_PARALLEL_IO の設定により、表領域の PREFETCHSIZE は特別な意味を持ちます。PREFETCHSIZE は EXTENTSIZE に分割され、I/O 並列処理の度合に達します。この環境変数セットがない場合、I/O 並列処理の程度は通常はコンテナの数から得られます。RAID のコンテナは通常 1 つだけであるため、PREFETCHSIZE を EXTENTSIZE の倍数に設定し、十分な数の IO_SERVERS(物理ディスクあたり 1 以上)を提供し、要求のプリフェッチを取り扱うのに十分な大きさのバッファプールに表領域を割り当てます。
一般的に、EXTENTSIZE はボリュームの物理属性に基づいて計算します。 適切な I/O 並列処理を実行するために、PREFETCHSIZE は必ず EXTENTSIZE(コンテナの数)以上である必要があります。ただし、RAID デバイスの取り扱いの際は、表領域内のコンテナは 1 つだけであり、コンテナ数がボリュームのデバイスまたはカラムの数で置き換えられる場合があります。
Quick I/O のような DMS デバイスコンテナを使う場合、、オペレーティングシステムはプリフェッチまたはキャッシュを一切実行しません。
???を参照してください。
メモリが DB2 表領域データのキャッシュやプリフェッチに割り当てられる場所と時期についての管理性を高める必要がある場合は、 Cached Quick I/O を使用します。
???を参照してください。
DB2 バッファプールにより多くのシステムメモリを永続的に割り当てる場合は、表領域の PREFETCHSIZE と DB2_PARALLEL_IO 設定を設定してください。
たとえば、カラムサイズが 64k の 10 のストライプの物理ディスクにまたがってストライプ化される VxVM RAID0 ボリュームがあります。ここではこのボリュームの VxFS ファイルシステムを作成し、DMS コンテナの表領域を作成します。
$ qiomkfile -s 1G /db2_stripe/cont001
$ db2 connect to PROD
$ db2 create tablespace DATA1 managed by database \
using (device '/db2_stripe/cont001' 128000 ) \ pagesize 8k extentsize 8 prefetchsize 80
using (FILE '/db2_stripe/cont001' 128000) \ pagesize 8k extentsize 8 prefetchsize 80 \ no file system caching
$ db2 terminate
この例では、エクステントの各読み込みによって物理ドライブ 1 つを分散しています(カラム幅は 64k 、エクステントサイズは 8(ページサイズ 8k))。プリフェッチの際、ストライプ全体に対する読み取りを 1 度に実行します(ストライプに 10 のディスクがあるため 10、エクステントは 80 ページ)。PREFETCHSIZE が EXTENTSIZE の倍数を維持していることを確認します。これらの設定は一般に約 640k 以下のクラスタを使用するデータベースに適切な環境を提供します。より大きなデータベースオブジェクトまたはデータのより積極的なプリフェッチのために、指定した PREFETCHSIZE を乗算できます。
DSS 作業負荷のようなデータベースの主要な作業負荷で高い順次 I/O 処理速度が求められる場合、Cached Quick I/O と PREFETCHSIZE の設定はさらに重要になります。
PREFETCHSIZE の値を大きく設定する、またはすべてをプリフェッチすることでパフォーマンスが低下する場合があります。データアクセスが非常にランダムである OLTP 環境では、EXTENTSIZE と等しい PREFETCHSIZE を設定することで、表領域のプリフェッチをオフにするか効果を最小化する必要がある場合があります。
この種の環境においても、インデックスへの素早いアクセスを確保し、さらに可能であればアクセスされる頻度の高いインデックスのすべてが Cached Quick I/O によってまたはバッファプールメモリ内でキャッシュされるようにすることが重要です。