最適なバッファ・プール、表スペース、表の設計：DB2チューニング・ベストプラクティス（2）（1/3 ページ）

本連載はDB2 UDB V8のシステム管理者、およびアプリケーション開発者のために、パフォーマンス・チューニングに必要な技法を紹介する。記事の原文はIBM developerWorksで2004年4月に公開された「Best practices for tuning DB2 UDB v8.1 and its databases」で、DB2の設計、配置、構成、SQL、運用管理、モニタリングといった内容を、実践的な操作を中心に解説している。想定する読者はDB2データベース管理の中級レベルのスキルを持っているユーザーである。スクリーン・ショットなど一部のコンテンツは、日本語版のものに差し替えている。（編集局）

[Fraser McArthur，DB2 Enablement Consultant／IBM Canada Ltd.]

バッファ・プールの作成

本記事は、IBM developerWorksからアットマーク・アイティが許諾を得て翻訳、転載したものです。

　バッファ・プールを適切に定義することは、システムを快適に動作させるための重要な要素の1つです。32ビット・オペレーティング・システムでは、共有メモリに関する制限を理解しておくことが重要です。この制限により、データベースのバッファ・プール（すなわちデータベース・グローバル・メモリ）が次の値を超えないように制限されます（64ビット・システムには、このような制限はありません）。

プラットフォーム	共有メモリの制限
AIX	1.75Gbytes
Linux	1.75Gbytes
Sun	3.35Gbytes
HP-UX	約800Mbytes
Windows	2〜3Gbytes（NT／2000のboot.iniで「/3GB」スイッチを使用）
表1　プラットフォームごとの共有メモリ制限

　データベース・グローバル・メモリのおおよその使用量を計算するには、次の式を使います。

バッファ・プール＋dbheap＋util_heap_sz＋pkgcachesz＋aslheapsz＋locklist＋約10％のオーバーヘッド

リスト1　データベース・グローバル・メモリの使用量（共有メモリ）の計算方法

　INTRA_PARALLELがオンの場合は、さらにsheapthres_shrの値を加えます。

バッファ・プールの数の決定

　データベース内の表スペースによって使用されるそれぞれのページ・サイズに対して、少なくとも1つのバッファ・プールが必要です。通常、デフォルトのIBMDEFAULTBPバッファ・プールは、システム・カタログのために残しておきます。異なるページ・サイズや異なる表スペースの動作を扱うために、新しいバッファ・プールを作成します。

　最初は、使用しているページ・サイズごとに1つのバッファ・プールを作成します。特に、OLAP／DSSタイプのワークロードの場合はそのようにします。DB2では、バッファ・プールのセルフチューニングが適切に行われ、頻繁にアクセスされる行がメモリ内に保持されるため、1つのバッファ・プールがあれば十分です（これにより、複数のバッファ・プールを管理するという複雑さも避けられます）。

　さらに改善が必要で、時間に余裕がある場合は、複数のバッファ・プールを使用しても構いません。頻繁にアクセスされる行をバッファ・プール内に保持することが、その目的です。ランダムにアクセスされる表やアクセス頻度の低い表の間でバッファ・プールを共有してしまうと、バッファ・プールの「汚染」の原因になります。再びアクセスされることのない行のためにスペースを消費し、頻繁にアクセスされる行をディスクに追い出してしまうことになるからです。索引を頻繁に使用する場合（索引スキャンなど）は、それぞれの索引を個別のバッファ・プール内に保持することによって、パフォーマンスを大きく改善できます。

　バッファ・プールの作成は、表スペースと密接に関係します。なぜなら、表スペース内での表の動作に基づいてバッファ・プールを割り当てたいからです。複数のバッファ・プールを使用する場合は、まず次の4つのバッファ・プールから始めるとよいでしょう。

• TEMPORARY表スペースのための中間サイズのバッファ・プール
• 索引表スペースのための大きなサイズのバッファ・プール
• 頻繁にアクセスされる表を含んでいる表スペースのための大きなサイズのバッファ・プール
• アクセス頻度の低い表、ランダムにアクセスされる表、順次にアクセスされる表を含んでいる表スペースのための小さなサイズのバッファ・プール

　LOBデータだけを含んでいるDMS（Database-managed Space：データベース管理スペース）表スペースは、任意のバッファ・プールに割り当てることができます。LOBはバッファ・プールのスペースを使用しないからです。

バッファ・プール用のメモリ割り振りの決定

　使用可能なメモリよりも多くのメモリを割り振ってはいけません。そうしてしまうと、負荷の大きいOSのメモリ・ページングが発生してしまいます。一般的にいって、各バッファ・プールに最初に割り振るメモリの量を、モニタせずに決めることはとても困難です。

　OLTPタイプのワークロードの場合、初めは使用可能メモリの75％をバッファ・プールに割り振るとよいでしょう。

　OLAP／DSSの場合は、一般的な目安として、使用可能メモリの50％を1つのバッファ・プールに割り振り（1つのページ・サイズだけを使用している場合）、残りの50％をSORTHEAPに割り振ります。

ブロック・ベースのバッファ・プールの使用

　プリフェッチに大きく依存するOLAP照会では、ブロック・ベースのバッファ・プールを使用すると効果的です。デフォルトでは、すべてのバッファ・プールはページ・ベースです。つまり、プリフェッチによって、ディスク上の連続するページが連続していないメモリ上に配置されます。ブロック・ベースのバッファ・プールを使用すると、DB2はブロック入出力を使用して、単一の入出力で複数ページをバッファ・プールに読み込みます。これにより、順次プリフェッチのパフォーマンスが大きく向上します。

　ブロック・ベースのバッファ・プールは、標準的なページ域とブロック域の両方で構成されます。SQLステートメントのCREATE BUFFERPOOLおよびALTER BUFFERPOOLのNUMBLOCKPAGESパラメータは、ブロック・メモリのサイズを定義するために使われます。これに対してBLOCKSIZEパラメータは、ブロックのサイズ、すなわち1回のブロック入出力でディスクから読み取るページの数を指定します。

　同じエクステント・サイズを共有する複数の表スペースだけが、特定のブロック・ベースのバッファ・プールを使用するようにします。BLOCKSIZEの値を、そのバッファ・プールを使用している表スペースのEXTENT SIZEと同じ値に設定します。

　バッファ・プール内でどれくらいのメモリをブロッキング専用にするかを決定する方法は、もう少し複雑です。多くの順次プリフェッチが行われている場合、おそらくブロック・ベースのバッファ・プールをより多く使用可能にしたいと思うでしょう。NUMBLOCKPAGESはBLOCKSIZEの倍数に設定すべきであり、この値はバッファ・プール用のページ数の98％を超えることはできません。最初は小さい値（バッファ・プールの総サイズの15％以下程度）に設定します。この値は、後でスナップショットのモニタに基づいて調整することができます。（次ページに続く）

DB2 V8 ドキュメンテーション

• 概念→管理→データベース・オブジェクト→バッファー・プール
• 参照情報→SQL→SQLステートメント→CREATE BUFFERPOOL
• 参照情報→SQL→SQLステートメント→ALTER BUFFERPOOL
• 概念→管理→パフォーマンス・チューニング→操作パフォーマンス→メモリー使用の最適化