索引のチューニング・テクニックを一挙公開：DB2チューニング・ベストプラクティス（3）（2/2 ページ）
本連載はDB2 UDB V8のシステム管理者、およびアプリケーション開発者のために、パフォーマンス・チューニングに必要な技法を紹介する。記事の原文はIBM developerWorksで2004年4月に公開された「Best practices for tuning DB2 UDB v8.1 and its databases」で、DB2の設計、配置、構成、SQL、運用管理、モニタリングといった内容を、実践的な操作を中心に解説している。想定する読者はDB2データベース管理の中級レベルのスキルを持っているユーザーである。スクリーン・ショットなど一部のコンテンツは、日本語版のものに差し替えている。（編集局）
プロファイル・レジストリの構成
DB2のプロファイル・レジストリ変数は、主にオプティマイザとDB2エンジンそのものの動作方法に影響を与えます。さまざまなプロファイル・レジストリ変数がありますが、それらの多くは極めて限定された目的で使用され、ほとんどのDB2環境では使用されません。プロファイル・レジストリ変数のうち、よく使われるものを以下に示します。
表1は、プロファイル・レジストリの基本的な管理コマンドを示しています。
| コマンド | 説明 |
|---|---|
| db2set -all | 現在設定されているDB2レジストリ変数をすべて表示します |
| db2set -g | -i variable=value注1 | 指定されたDB2レジストリ変数を、グローバル・レベル（-g）またはインスタンス・レベル（-i）で設定します |
| 表1 プロファイル・レジストリの管理 | |
注1：変数（variable）と値（value）の間にスペースを入れてはいけません。
DB2_PARALLEL_IO
ディスク・アレイ上に存在する任意の表スペースに対する並列アクセスを可能にします。すべての表スペースがディスク・アレイ上に存在する場合は、この値を「*」に設定します。一部の表スペースだけがディスク・アレイ上に存在する場合は、「db2 list tablespaces」を使ってそれらの表スペースのIDを取得し、この値をそれらのIDに設定します（複数のIDを区切るには「,」を使います）。最適なパフォーマンスのためには、表スペースのプリフェッチ・サイズがエクステント・サイズよりも十分に大きくなるように設定してください。
DB2_EVALUNCOMMITTED
デフォルトではOFFです。これをONに設定すると、述部の評価が終わるまでロックが保留されます。これは、Oracleから移行されたアプリケーションでロックの競合を減らすのに役立ちます。
DB2_SKIPDELETED
デフォルトではOFFです。これをONに設定すると、CS（cursor stability：カーソル固定）またはRS（read stability：読み取り固定）を使用しているステートメントで、索引の削除済みキーと表の削除済み行がスキップされるようになります。これも、Oracleから移行されたアプリケーションでロックの競合を減らすのに役立ちます。
DB2_HASH_JOIN
デフォルトではYESです。OLTPでは、この値をNOに設定すると、良い結果が得られる場合があります。
（AIX）：DB2_FORCE_FCM_BP
デフォルトではNOです。DB2のDPF（Database Partitioning Feature：データベース・パーティショニング・フィーチャー）を使用していて、複数の論理パーティションが存在する場合は、パーティション間通信を高速化するためにYESに設定します。この場合、バッファ・プール用に使用可能な共有メモリ・セグメントの数は1つ減ります。DPFを使用していない場合は、NOに設定します。
（AIX 4.3）：DB2_MMAP_READおよびDB2_MMAP_WRITE
デフォルトでは、どちらもONです。AIX 4.3および32ビットDB2を使用していて、メモリの制限によりバッファ・プールのサイズを大きくできない場合は、この値をOFFに設定して、メモリ・セグメントを1つ解放します。これにより、約256MBytesの共有メモリが解放されます（この一部をバッファ・プールとして利用できます）。この変更によりパフォーマンスが向上するかどうかを確認するためにテストを行ってください。というのは、バッファ・プール・サイズを増やすよりも、メモリ・マップ式のディスク読み取り／書き込みを使用した方がパフォーマンスが向上する場合があるからです。ただし、これはよくあることではありません。
- 参照情報→レジストリーおよび環境変数
ランタイム・エラーを避けるための構成
アプリケーションを初めて実行したときに、構成パラメータの値に関する問題が発覚する場合がよくあります。アプリケーションの実行中にエラーや警告が生じなければ、問題はありません。エラーや警告が生じた場合は、第4回および第5回で説明するデータベース・マネージャおよびデータベースの構成パラメータ管理の項を参照してください。SQLを処理するためのメモリが足りない場合は、以下の構成パラメータを調整してください。
MON_HEAP_SZ (DBM)
これは、データベース・システム・モニタ・データに割り振られるメモリの量です。イベント・モニタの起動やスナップショット・モニタなど、データベース・モニタ・アクティビティを実行すると、モニタ・ヒープからメモリが割り振られます。使用可能なメモリが十分になく、DB2からエラーが返される場合は、値を「256」に設定してみてください。それでもエラーが返される場合は、エラーがなくなるまで「256」ずつ値を増やしてください。
QUERY_HEAP_SZ (DBM)
これは、照会ヒープに割り振ることのできるメモリの最大量です。照会ヒープは、それぞれの照会をエージェントの専用メモリに格納するために使われます。また、照会ヒープは、ブロック・カーソルに割り振られるメモリとしても使われます。照会ヒープのサイズは、ASLHEAPSZの値以上でなければなりません。DB2からエラーが返される場合、そのパフォーマンスは決して最適なものとはいえません。少なくともこの値を、ASLHEAPSZの5倍以上大きな値に設定してください。これにより、ASLHEAPSZよりも大きな照会が可能になり、3つまたは4つの同時に実行されるブロック・カーソルのための十分なメモリが得られます。
MAXAPPLS (DB)
これは、データベースに接続可能な同時アプリケーション（ローカル接続とリモート接続の両方）の最大数を指定します。この値は、必ずユーザー接続の数以上に設定してください。詳細については、第4回および第5回で説明するMAXAGENTSを参照してください。
STMTHEAP (DB)
ステートメント・ヒープは、SQLステートメントのコンパイル時にSQLコンパイラのワークスペースとして使われる領域です。この領域は、処理されるSQLステートメントごとに割り振られ、解放されます。警告やエラーが生じた場合は、エラーがなくなるまで「256」ずつ値を増やしてください。
APPLHEAPSZ (DB)
アプリケーション・ヒープは、特定のエージェントの代わりにデータベース・マネージャが使用することのできる専用メモリです。アプリケーション・ヒープは、アプリケーション用にエージェントまたはサブエージェントが初期化されるときに割り振られます。割り振られる量は、要求を処理するために必要な最小限の量です。より多くの量が必要な場合は、最大で、このパラメータで指定した量まで割り振られます。エラーがなくなるまで「256」ずつ値を増やしてください。（次回に続く）
編集局：第3回は「索引の作成」「プロファイル・レジストリの構成」「ランタイム・エラーを避けるための構成」を扱いました。次回は「パフォーマンス向上のためのスナップショット・モニタ（前編）」を取り上げます。
著者紹介
Fraser McArthur氏は、分散プラットフォーム（Windows／UNIX）用のDB2 UDBを開発しているIBMトロント研究所のコンサルタントです。同氏はData Management Partner Enablement organizationのメンバーであり、IBMビジネス・パートナーとともに、DB2へのアプリケーションの移行とパフォーマンス・チューニングに取り組んでいます。また同氏は、DB2管理とアプリケーション開発の両方におけるDB2 Certified Solutions Expertです。
Copyright © ITmedia, Inc. All Rights Reserved.