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

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

表スペースの作成

　表スペースにはバッファ・プールが割り当てられるため、表スペースに関係するパフォーマンスの問題には、前のセクション（バッファ・プールの作成）が大きく関係してきます。表スペースを作成し、構成するには、GUIツールの「コントロール・センター」を使用するのが最も簡単で、推奨できる方法です（データベースの「表スペース」フォルダを右クリックし、「作成（C）...」を選択します。図1参照）。

図1　「コントロール・センター」を使った表スペースの作成

作成する表スペースのタイプの決定（DMSまたはSMS）

　SMS（System-managed Space：システム管理スペース）は、システムTEMPORARY表スペースとシステム・カタログ表スペースに対して使用します。これは、表スペースの動的な拡張や縮小を可能にするためです。（十分なソート・スペースがない、あるいは一時表を明示的に作成するために）ディスクにフラッシュされる大きな一時表が存在する場合は、DMSの方が効率的です。SMSを使用する場合は、db2empfaというユーティリティを実行します。これは複数ページのファイル割り振りを可能にし、表スペースを1度に1ページではなく、1エクステントずつ拡張できるようにします。

　DMS（Database-managed Space：データベース管理スペース）は、ほかのすべての表スペースに対して使用します。DMSを使用すると、1つの表を複数の表スペースに分散させることができます（索引、ユーザー・データ、およびLOB）。これにより、プリフェッチ操作および更新操作の間の索引データ、ユーザー・データ、LOBデータの競合が減少し、その結果、データ・アクセス時間が短縮されます。DMSローを使用すると、パフォーマンスがさらに5〜10％向上します。

ページ・サイズの決定

　表を作成するためには、行を格納するだけの十分なページ・サイズを持つ表スペースがなければなりません。4Kbytes、8Kbytes、16Kbytes、32Kbytesのいずれかのページ・サイズを使用できます。場合によっては、単にデータベース・マネージャの制限を回避するために大きなページ・サイズを使用しなければならないこともあります。例えば、表スペースの最大サイズは表スペースのページ・サイズに比例しますが、（パーティションごとの）表スペースのサイズは、4Kbytesのページ・サイズを使用すると64Gbytesに制限され、32Kbytesのページ・サイズを使用すると512Gbytesに制限されます。

　ランダム更新操作を実行するOLTPアプリケーションでは、大抵小さいページ・サイズの方が良好な結果を得られます。その方が、バッファ・プール内のスペースの消費量が少なくて済むからです。

　連続する多くの行に一度にアクセスするOLAPアプリケーションでは、大抵大きなページ・サイズの方が良好な結果を得られます。特定の数の行を読み取るのに必要な入出力要求の数が減るからです。また、ページ・サイズが大きいと、1つのページ内により多くの行ポインタを保持できるため、索引内のレベルの数を減らすことができます。ただし、これには例外があります。行のサイズが「ページ・サイズ／255」より小さいと、ページごとの最大行数である255の制限に達してしまうため（これは索引データ・ページには適用されません）、各ページ内に無駄なスペースが生じてしまいます。このような状況では、小さいページ・サイズを使用する方が適切です。

　例えば、平均的なサイズが100bytesである行を格納するために32Kbytesのページ・サイズを使用したとすると、各ページには、100×255＝25500bytes（24.9Kbytes）しか格納できません。つまり、32Kbytesのページごとに約7Kbytesが無駄になってしまうのです。これは、大規模なデータベースでは大量のスペースに相当します。

表スペースの数の決定

　バッファ・プールと同様に、使用するそれぞれのページ・サイズに対して1つの表スペースから始めるとよいでしょう。使用する各ページ・サイズに対して、それと同じページ・サイズを持つシステムTEMPORARY表スペースが存在していなければなりません（ソートとREORGをサポートするため）。同じページ・サイズを共有するすべての表スペースを、一致するページ・サイズを持つバッファ・プールに割り当てます。

　パフォーマンスが大きな問題であり、時間に余裕がある場合は、DMS表スペースを使用し、用途に基づいて表をグループ化します。また、複数のバッファ・プールを使用するための前述の推奨事項に従います。

　それぞれのページ・サイズに対して、以下を作成します。

• システムTEMPORARY表スペース
• 索引のための通常の表スペース
• 頻繁にアクセスされる表のための通常の表スペース
• アクセス頻度の低い表、ランダムにアクセスされる表、順次にアクセスされる表のための通常の表スペース
• LOBデータのための大きな表スペース

コンテナのレイアウト

　初めは、CPUごとに6〜10個程度のディスクを表スペース専用として使用するとよいでしょう。それぞれの表スペースは、すべてのディスクにまたがるようにします。つまり、それぞれの表スペースが、使用可能な各ディスク上に1つ（だけ）のコンテナを持つようにします。

　各ディスク上に、表スペースと同じ数の論理ボリューム（UNIX）を作成します。このようにすると、それぞれの表スペースが各ディスク上に独自の論理ボリュームを持つようになり、コンテナを配置できます。DMSローを使用しない場合は、それぞれの論理ボリューム内にファイル・システムを作成する必要があります。

ディスク・アレイとストレージ・サブシステム

　大規模なディスク・システムに対しては、1つのコンテナを使用します。また、その表スペースのために、DB2プロファイル・レジストリ変数のDB2_PARALLEL_IOを設定する必要があります。これについては、第3回の「プロファイル・レジストリ」のセクションで説明します。

エクステント・サイズ

　エクステント・サイズは、次のコンテナに移る前にコンテナに書き込まれる（大きさがPAGESIZEの）ページの数を指定します。エクステント・サイズは、表スペースの作成時に定義します（作成後に変更するのは困難です）。小さな表を効率よく扱うには、小さなエクステントを使用します。

　一般的な目安として、表スペース内の表の平均サイズに基づいてエクステント・サイズを決定します。

• 25Mbytes未満の場合は、エクステント・サイズを8にします
• 25〜250Mbytesの間の場合は、エクステント・サイズを16にします
• 250〜2Gbytesの間の場合は、エクステント・サイズを32にします
• 2Gbytesを超える場合は、エクステント・サイズを64にします

　OLAPデータベース、主にスキャンされる表（照会のみ）、急速に増大する表の場合は、より大きな値を使用します。

　表スペースがディスク・アレイ上に存在する場合は、エクステント・サイズをストライプ・サイズ（すなわち、アレイ内の1つのディスクに書き込まれるデータのサイズ）に設定します。

プリフェッチ・サイズ

　プリフェッチ・サイズは、ALTER TABLESPACEを使って簡単に変更できます。最適な設定は次のとおりです。

プリフェッチ・サイズ＝（複数の物理ディスク上に存在する表スペースのコンテナ数）×エクステント・サイズ

リスト2　プリフェッチ・サイズの計算方法

　表スペースがディスク・アレイ上に存在する場合は、次のように設定します。

プリフェッチ・サイズ＝エクステント・サイズ×（アレイ内のパリティ・ディスク以外のディスクの数）

リスト3　プリフェッチ・サイズの計算方法（表スペースがディスク・アレイ上に存在する場合）

　（次ページに続く）

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

• 概念→管理→データベース設計→物理→表スペースの設計
• 参照情報→SQL→SQLステートメント→CREATE TABLESPACE
• 参照情報→SQL→SQLステートメント→ALTER TABLESPACE