スナップショット・モニタに基づくチューニング：DB2チューニング・ベストプラクティス（5）（2/4 ページ）

本連載は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.]

NUM_INITAGENTSおよびNUM_POOLAGENTS（DBM）

　NUM_INITAGENTSは、db2start時にプール内に作成されるアイドル・エージェントの数を定義します。これは、データベースの使用を開始するときの接続を高速化するのに役立ちます。NUM_POOLAGENTSも同様のもので、データベースがしばらく稼働した後では、NUM_POOLAGENTSの方がパフォーマンスに大きな影響を与えます。接続コンセントレータがOFF（デフォルト値。MAX_CONNECTIONS ＝ MAX_COORDAGENTS）の場合、NUM_POOLAGENTSはエージェント・プールの最大サイズを表します。接続コンセントレータがON（MAX_CONNECTIONS ＞ MAX_COORDAGENTS）の場合は、システムのワークロードが低い場合のエージェント・プールのサイズを表すガイドラインとして使用されます。

　NUM_INITAGENTSとNUM_POOLAGENTSには、予想されるインスタンス・レベルの同時接続の平均数を設定します。一般的に、OLAPの場合は少なく、OLTPの場合は多くなります。非常に多くの接続が使用されるパフォーマンス・ベンチマークの場合は、NUM_INITAGENTSの値を、予想される接続数に設定します（これにより、リソースの競合が減り、接続を確立するのに必要な時間が大幅に短縮されます）。接続プーリングを使用する3層環境では、NUM_INITAGENTSとNUM_POOLAGENTSはパフォーマンスにほとんど影響を与えません。このような環境では、アプリケーションがアイドル状態のときでも、アプリケーション・サーバによって接続が常に維持されるからです。

　「Idle agents」は、エージェント・プール内のアイドル・エージェントの数を表します。「Agents assigned from pool」は、エージェント・プールからエージェントが割り当てられた回数を表します。「Agents created from empty pool」は、（db2start直後のミスリードなどにより）プールが空であったために作成されたエージェントの数を表します。db2startの後では、単にNUM_INITAGENTSの数のエージェントが作成されたことを表します。「Agents created from empty pool」対「Agents assigned from pool」の比率が高い（5:1以上）場合は、NUM_POOLAGENTSを増やす必要があります。また、システム全体のワークロードが高過ぎることを示しています。ワークロードを調整するには、MAXCAGENTSの値を下げます。逆に比率が低い場合は、NUM_POOLAGENTSの設定が高すぎて、一部のエージェントがシステム・リソースを浪費していることを示しています。

FCM_NUM_BUFFERS（DBM）

　このパラメータは、複数の論理パーティションを使用しているDPF（Database Partitioning Feature：データベース・パーティショニング・フィーチャー）環境でのみ使用され、内部通信に使用される4Kbytesバッファの数を定義します。DPFを使用していない場合は、スナップショットには出力されません。また、この情報は、スナップショットが実行されたパーティションからのものになります。例えば、リスト2のDBMスナップショットでは「Node FCM information corresponds to」の値が「2」であるため、これはパーティション番号2のパーティションから取得された情報です。「Get

snapshot for dbm global」を使用すると、すべてのパーティションの合計値を取得できます。

　DBMスナップショットのFCMノードのセクションを使用すると、パーティション間通信が主にどこで行われているかを把握できます。通信が大量に行われている場合は、より多くのFCMバッファ・メモリ、または異なるパーティション・キーが必要です。あるいは、表スペースへの表の割り当てを変更する必要があります。「Free FCM buffers low water mark」（空きFCMバッファの最低水準点）がFCM_NUM_BUFFERSの15％未満である場合は、15％以上になるまでFCM_NUM_BUFFERSの値を増やします。これは、十分な量のFCMリソースを常に使用できるようにするためです。

AVG_APPLS（DB）

　このパラメータは、アプリケーションが複雑なSQL（例えば結合、関数、再帰などを含むもの）を発行する場合のみ変更し、それ以外の場合は「1」のままにしておきます。このパラメータは、実行時にアクセス・プラン用に使用可能なバッファ・プールのサイズを見積もるのに役立ちます。このパラメータの値には、「Applications connected currently」（現在接続されているアプリケーション）の平均数に、複雑なSQLを発行する割合（パーセンテージ）を掛け合わせた数値を設定します。

LOCKLISTおよびMAXLOCKS（DB）

　ロック・リストはデータベースごとに1つずつ存在します。ロックリストには、データベースに同時に接続しているすべてのアプリケーションによって保持されているロックが含まれます。32ビット・プラットフォームでは、あるオブジェクトに対する最初のロックは72bytesを必要とし、その後の追加ロックはそれぞれ36bytesを必要とします。64ビット・プラットフォームでは、最初のロックは112bytesを必要とし、追加のロックは56bytesを必要とします。

　1つのアプリケーションによって使用されるLOCKLISTの割合がMAXLOCKSに達すると、データベース・マネージャによってロック・エスカレーションが実行され、特定の表に対する複数の行ロックが単一の表ロックに置き換えられます。また、LOCKLISTが足りなくなると、データベース・マネージャは、1つの表に対して行ロックを最も多く保持している接続を識別し、それらの行ロックを表ロックに置き換えてLOCKLISTメモリを解放します。ただし、表全体をロックすると並行性が大幅に低下し、デッドロックの可能性も高くなります。

　「Lock list memory in use (Bytes)」（使用中のロック・リスト・メモリ）が、定義したLOCKLISTのサイズの50％を超える場合は、LOCKLIST内の4Kbytesページの数を増やします。「Lock escalations」（ロック・エスカレーション）または「Exclusive lock escalations」（排他ロック・エスカレーション）が発生している場合は、LOCKLISTまたはMAXLOCKS、あるいはその両方を増やしてください。

　データベース・スナップショットのロックに関するセクションには、貴重な情報がたくさん含まれています。「Locks held currently」（現在保持されているロック）、「Lock waits」（ロック待機数）、「Time database waited on locks (ms)」（データベースのロック待機時間）、「Agents currently waiting on locks」（現在ロックを待機しているエージェント）、「Deadlocks detected」（デッドロック検出数）に高い値が示されていないか調べてください。これらは、不適切なアクセス・プラン、時間のかかるトランザクション、アプリケーションの並行性の問題などの兆候を示します。デッドロックが示されている場合は、デッドロックの詳細に関するイベント・モニタを作成し、実際に何が起こっているのかを調べます。

　ロックの問題に関する詳しい情報については、Bill Wilkins氏の「Diagnosing and Resolving Lock Problems with DB2 Universal Database」という記事を参照してください。

　ロックの数を減らすには、以下のことを行います。

• アプリケーションが、必要最小限の分離レベルを使用していることを確認します。
• COMMITを頻繁に実行します。
• 大量の更新を行う場合は、更新前に（LOCK TABLEステートメントを使用して）表全体を明示的にロックします。
• 保持される共有ロックの数を減らすために、分離レベルにはできるだけ「CS」（デフォルト値）を使用します。ダーティー・リードでも問題のないアプリケーションでは、「UR」（非コミット読み取り）を使用すると、さらにロックを減らすことができます。

LOCKTIMEOUT（DB）

　このパラメータは、ロックを獲得するためにアプリケーションが待機する秒数を定義します。これは、グローバル・デッドロックを避けるのに役立ちます。このパラメータに「-1」を指定した場合、ロック待機状態になると、アプリケーションはフリーズしたように見えます。前述したロックに関するBill Wilkins氏の記事では、このことについても詳しく説明されています。

　実稼働環境では、OLAPについては「60」（秒）程度、OLTPについては「10」程度から始めるとよいでしょう。 開発環境では、ロック待機状態を識別し、解決するために「-1」を使用します。同時ユーザーの数が非常に多い場合は、ロールバックを避けるために、OLTPの時間を増やします。

　「Lock Timeouts」の値が大きい場合は、以下の原因が考えられます。

1. LOCKTIMEOUTの値が低過ぎる
2. 1つのトランザクションがロックを長い時間保持している
3. ロック・エスカレーションが発生している

（次ページに続く）