レベル: 中級 香川 浩子 (eb82674@jp.ibm.com), Advisory IT Specialist, 日本アイ・ビー・エム システムズ・エンジニアリング株式会社
2009年 03月 05日 この記事では、DB2の構成パラメーターについてご紹介します。
はじめに
DB2のインスタンスやデータベースは、さまざまなパラメーターを持っています。その大量のパラメーターをどのように設定していけば良いのでしょうか。
昨今のバージョンではオートノミック化が進んできました。インスタンスやデータベース作成時に多くのパラメーターがオートノミック設定となり、また、運用の中でダイナミックにチューニングされていくものもあります。よって、手動で1つ1つのパラメーターを設計しなくても、基本的にはそのままで正常に稼働します。ただし、データベースを運用していく中で、パラメーターの変更が必要になることもあるでしょう。また、v8.2までは、このようなオートノミック機能は少ないため、設定が必要なパラメーターもあります。以上のことから、注意すべきパラメーターや、最低限設定すべきパラメーター（v8.2以前）について解説し
構成パラメーターの種類
DB2の構成パラメーターには以下の3種類があります。
- レジストリー変数
- データベース・マネージャー構成パラメーター
- データベース構成パラメーター
レジストリー変数
レジストリー変数は、主にオプティマイザーとDB2エンジンそのものの動作方法に影響を与えます。レジストリー変数はインスタンス・レベルでの構成を定義するパラメーターです。設定項目のカテゴリとしては、汎用レジストリー変数、システム環境変数などの変数があります。
データベース・マネージャー構成パラメーター
データベース・マネージャー構成パラメーターは、サーバーのプロセスやメモリー（エージェントの数、インスタンス共有メモリーなど）に影響を与えます。また、クライアントからインスタンスやデータベースに対する接続の定義（例えば権限など）を行うことができます。データベース・マネージャー構成パラメーターはインスタンス・レベルでの構成を定義するパラメーターです。
データベース構成パラメーター
データベース構成パラメーターは、データベースに影響を与えます。データベース・レベルでの構成を定義するパラメーターです。
構成アドバイザーを利用する
構成アドバイザーは管理者が使用するツールで、質問に答えるだけで自動的にチューニングが行われます。多々あるパラメーターをシステム環境にあわせて適切な値をアドバイスして設定してくれます。詳細なチューニングを行う前に、構成アドバイザーを実行してみましょう。
図1. 構成アドバイザーの効果
構成アドバイザーはコントロール・センターから起動するGUIツールになります。コントロール・センターで、対象のデータベースを選択し、選択メニューから「構成アドバイザー…」を実行します。
質問項目は以下の通りです。
- データベースに割り振るメモリー量を指定します。
デフォルトは80%。サーバーでほかのアプリケーションを実行している場合は100%より小さくします。
- データベースのワークロードのタイプを指定します。
「照会」、「混合」、「トランザクション」から選択します。ほとんどのデータベースは混合で対応できます。
- データベースで実行しているトランザクション数の見積もりを設定します。
コミット間に実行されるステートメント数を「10以上」、「10未満」から選択します。1分間に実行されるトランザクション数の見積もり数を入力します。
- データベース管理の優先順位を選択します。
「トランザクションのパフォーマンスを速くする（リカバリーはゆっくり）」、「両方」、「データベースリカバリーを速くする（トランザクションはゆっくり）」の3つから選択します。
- データベースのデータ量を考慮して推奨値を計算するかどうかを指定します。
「はい」、「いいえ」のどちらかを選択します。
- データベースに接続するアプリケーションを見積もります。
ローカルとリモートのアプリケーションの平均数をそれぞれ入力します。
- データベースの分離レベルを選択します。
適切な分離レベルを「反復可能読み取り」「読み取り固定」「カーソル固定」「非コミット読み取り」の4つから選択します。
- 推奨値のパラメーター設定の反映のタイミングを指定します。
「タスク履歴を保管しないで今すぐ実行」、「タスク・センターでタスクとして作成」から選択します。タスクとして作成した場合、スケジューリングすることが可能です。
構成アドバイザーの内容は、AUTOCONFIGUREコマンドや、CREATE DATABASEのAUTOCONFIGUREオプションと同じ内容です。AUTOCONFIGUREコマンドや、CREATE DATABASEのAUTOCONFIGUREオプションも、入力値をもとにバッファー・プール・サイズ、データベース・マネージャー構成パラメーター、データベース構成パラメーターの推奨値を計算し、適用します。
レジストリー変数
db2setコマンドを使用してレジストリー変数を参照、変更することができます。例えば、以下のように使用します。
実行コマンド例：
確認コマンド例：
DB2COMM
DB2COMMレジストリー変数は、クライアントとサーバー間で使用される通信プロトコルを指定します。
DB2はデータベース起動時(インスタンス起動時)にこの変数を参照し、クライアントからの接続を監視するためのリスナーを起動します。従って使用しないプロトコルが指定されていると、リソースを消費することとなります。クライアントからTCP/IPプロトコルのみでサーバーへ接続するのであれば、“TCPIP”のみを、NETBIOS プロトコルのみを使用するのであれば、“NETBIOS”のみを指定するようにしてください。
DB2_PARALLEL_IO
ディスク・アレイ上に存在する任意の表スペースに対する並列アクセスを可能にします。すべての表スペースがディスク・アレイ上に存在する場合は、この値を「*」に設定します。一部の表スペースだけがディスク・アレイ上に存在する場合は、「db2 list tablespaces」を使ってそれらの表スペースのIDを取得し、この値をそれらのIDに設定します。
データベース・マネージャー構成パラメーター
次にデータベース・マネージャー構成パラメーターについて解説します。冒頭で前述しましたとおり、基本的にはオートノミックで構成されているため、以下のパラメータ以外については検討する必要はありません。
実行コマンド例：
db2 update dbm cfg using intra_parallel YES
|
確認コマンド例：
INTRA_PARALLEL
データベースサーバーのCPUが複数（SMP構成）あり、パラレル処理をさせたい場合に設定します。一時点で1つのアプリケーションしか存在しない場合（バッチ処理など）や、DB2のユーティリティー（create indexなど）を高速に実行したい場合などに有効です。同時アクセスが多く、OLTPアプリケーションが主体の場合は、このパラメータの設定は不要です。
データベース構成パラメーター
次にデータベース構成パラメーターについて解説します。v9以降では、これらのパラメータはすべてオートノミックとなっていますので変更する必要はありません。v8.2以前のバージョンの場合は、下記パラメーターについて検討してください。
実行コマンド例：
db2 update db cfg for database-alias using num_ioservers 5
|
確認コマンド例：
db2 get db cfg for database-alias
|
num_ioservers､num_iocleaners
num_ioserversには、ディスクからバッファー・プールへのデータの読み込み（プリフェッチや、ユーティリティーなどの非同期I/O）を実行する入出力サーバー数を指定します。この数が少なすぎても多すぎても、ディスクからメモリーであるバッファー・プールへのデータの読み込みが効率よく行われないために、ディスクI/Oに待ちが発生しレスポンスを悪くする可能性があります。
num_iocleanersには､バッファー・プールへの書き込みを行うための空間（ページ）をあけるために､変更があったページをバッファー・プールからディスクへの書出しを実行するページ・クリーナーの数を指定します。
設定するパラメーター値ですが、num_ioservers､num_iocleaners共に実際に稼動しているディスク数を指定してください。例えばRAID5構成で5＋P（パリティー）＋S（スペア）という場合は、6（5＋P）を指定します。
注）num_ioserversに設定するディスク数に関しては、物理ディスク数にする場合と、物理ディスク数＋1もしくは＋2、＋3とする場合もあり、環境や状況によって多少異なります。
logfilsiz
データベースは、データの整合性を保つために、更新や追加、IMPORT作業などのデータに対して行われた変更作業の全てを記録し保持しています。全ての変更は、一旦メモリー上のログ・バッファーに書き込まれ、COMMIT時にディスク上のログ・ファイルに書き込まれます。logfilsizは、この書き込まれるログ・ファイルのサイズを指定します。
ログ・ファイルは障害時にデータベースを正常な状態に戻すために使用される重要なファイルです。従って、ある程度のサイズを確保しておく必要があります。
ログ・ファイルは1つでなく、複数のログ・ファイルを作成することが可能で、アクティブ・ログのファイル容量を増やすには以下の2つの方法があります。
- ログ・ファイル数を増やす
- 1つのログ・ファイルのサイズを多くする
一般に、適度に大きなログ・ファイルを少数持つほうが、パフォーマンスに良い傾向が見られます。従って、1作業単位（COMMITもしくはROLLBACKから、次のCOMMIT、ROLLBACKまで）の更新量、使用可能な物理ディスクのサイズを考慮し、logfilsizを拡張してください。
locklist、maxlocks
locklist やmaxlocks はデータベースに接続できるアプリケーションの最大数にあわせて増減してください。データベースは､データの整合性のためにロックを必要とします。しかし､不必要なロックはロック待ちを起こす要因となり､アプリケーション並行性のパフォーマンス低下を招きます。基本的な考え方として､不必要なロックやロック待ちが起こらないように､アプリケーションやデータベースを設計することが重要ですが、ロックは必ず発生するものです。DB2は行ロックにおいて､そのロック情報を保持するために非常に小さい量のメモリーを消費します。しかし､大量の行ロックが発生すると､その量は無視できないものとなります。その場合DB2では､ある一定以上の行ロックが発生すると、有限のシステムであるメモリーの浪費を防ぎ､システムダウンなど重大なエラーを引き起こさないように､ロック・エスカレーションを行い､大量の行ロックから表ロックへとロックのレベルを変更します。こうすることによって､メモリーを開放しシステムダウンを防ぎます。
ただし､表ロックは行ロックに比べてアプリケーションの並行性をさらに低減するので､ロックをきちんと管理して不用意なロック・エスカレーションが発生しないように、保持できるロック情報の数を増やしておく必要があります。
保持できるロック情報の数を増やすには、locklistとmaxlocksのパラメーターを調整します。
- locklist
locklistはロック情報のための割り振られる記憶域の量を示しています。データベースごとに1つのロック・リストが確保され､全てのロック情報が保持されます。
- maxlocks
maxlocksはパーセントで指定され､ロック・エスカレーションを自動実行する比率を指定します。locklistに指定された記憶域とアプリケーション稼動中のロック数を比較し、1つのアプリケーションのロック数がmaxlocksの値（%）を超えると､ロック･エスカレーションが自動実行されます。
従って､locklistが小さくても、maxlocksが小さくても、頻繁にロック･エスカレーションが発生することとなり､並行性のパフォーマンスが低減します。
バッファー・プール
最後に、バッファー・プールについて触れておきます。
バッファー・プールは、先ほどの3つの構成パラメーターに属していませんが、表スペースのディスクに対する入出力のキャッシュの役割を持ち、その他のメモリー関連のパラメーターと比較して、最も大きく、また最も重要なオブジェクトと言えます。v9以降については、STMM（自己チューニングメモリー）というオートノミック機能が提供されたため、バッファー・プール・サイズを予め検討しておく必要はなくなりました。ただし、v8.2以前は、オートノミック機能は無いため、事前にバッファー・プールについて設計する必要があります。
まず、バッファー・プールの使われ方について整理しておきましょう。
DB2はデータへのアクセスを、必ず物理メモリー上に確保されたバッファー・プール経由で行います。具体的にはデータがアクセスされた際に、DB2はバッファー・プールを確認し、バッファー・プール内に対象データが存在した場合にはディスクへはアクセスを行わず、バッファー・プール内のデータを返します。バッファー・プール内に対象データがない場合には、物理的にディスクへアクセスしデータを返します。従って、バッファー・プールが小さいとディスクへのアクセスが多くなり、メモリーI/O（バッファー・プールへのI/O）よりもはるかに遅いディスクI/Oが増えるために、レスポンス・タイムが遅くなることになります。いくらたくさんの物理メモリーを積んでも、バッファー・プール・サイズに適当な値を設定しなければ、それらのメモリーをDB2は有効に使用しません。
図2. バッファー・プールの位置づけ
デフォルトでは、IBMDEFAULTBPバッファー・プールが使用されます。IBMDEFAULTBPの初期値は小さすぎるので使用可能な物理メモリーのサイズに応じてバッファー・プール・サイズを拡張してください。基本的に1つのデータベースに1つのバッファー・プールの利用が最もメモリー全体を効率的に使用し、かつ管理が容易です。しかし、IBMDEFAULTBP以外のページサイズで表スペースを作成する場合は、表スペースと同じページサイズのバッファー・プールが必要となりますので、その場合は複数のバッファー・プールの作成を考慮してください。バッファー・プールの変更は以下のコマンドで実行します。
実行コマンド例：
db2 alter bufferpool IBMDEFAULTBP size 10000
|
確認コマンド例：
db2 select * from syscat.bufferpools
|
バッファー・プールのサイズについては、以下の2点のアプローチ方法が考えられます。
物理メモリーが予め決まっている場合
OSとサーバー上に存在する他のミドルウェアのメモリー使用率との兼ね合いになりますが、大きければ大きいほどよいと考えてください。使用可能な物理メモリーは、データベース専用マシンでも、OSが使用するメモリー、ファイルキャッシュなどを差し引く必要があります。それ以上にするとOSなどが使用するメモリーが不足し、システムに悪影響が出ることがあります。
物理メモリーが決まってない場合
全てのマスターデータ分、使用頻度が高いテーブル数分の索引量を足したサイズは最低限準備しておきたいところです。余裕率についても加味してください。
おわりに
これでデータベースの物理設計は完了となります。構成パラメーターはオートノミック化が進むことで、シンプル且つ管理性が高くなっていることが分かると思います。逆にv8.2以前のバージョンを使用する場合は、これらのパラメーターについて事前に設計しておく必要があります。パラメーターは設定したら変更できなくなるということは無いので、初期設定の値に拘らず、テストや実際の運用の中で、最適なパラメーター値を検討していくことが望ましいでしょう。
参考文献
著者について  | | | 香川浩子は主にプロジェクトサポートをメインにDB2の技術支援を担当してきました。現在はプロジェクトサポートに留まらず、新機能の稼動検証、資料開発、トラブルサポートなどにも従事しています。今年から部署のGroupLeaderとして日々のマネジメント業務をこなしながら、DB2やそれ以外のスキルの幅を広げるため、さまざまなスキル活動に参画しています。 |
記事の評価
| 
