データベースエージェントが割り振るアプ リケーションメモリーの最大量を制御
INSTANCE_MEMORY
1 つのデータベースパーティションに
割り振ることができるメモリー最大量
Automatic管理となったヒープ(メモリー関連)
V9.1でautonomic管理となっているヒープ(=STMMが管理)
¾ buffer pools
¾ lock list
¾ max locks
¾ package cache
¾ sort heap
V9.5でautonomic管理となるヒープ
¾ application heap
¾ dbheap
¾ monitor heap
¾ statement heap
¾ statistics heap
メモリー構成単純化のメリット
構成の簡素化
z V9.1において、パフォーマンスに影響を与える一部のヒープが自動管理(=STMM)となり、
V9.5では、その他のヒープも自動管理となりDBAによる手動構成が不要となる
¾ V9.1でSTMM機能によりautonomic管理となったヒープ – buffer pools, lock list, max locks, package cache, sort heap
¾ V9.5でautonomic管理となるヒープ
– application heap, dbheap, monitor heap, statement heap, statistics heap z 各データベースパーティションで使用可能な合計メモリーサイズの上限を
INSTANCE_MEMORYに設定可能
¾ 消費される合計メモリーサイズがINSTANCE_MEMORYのサイズ内であれば、各ヒープはメ モリーサイズを増加させることが可能となる
¾ 新しく作成されるDBでは、メモリー関連(一部例外あり)のパラメーターはデフォルトで AUTOMATICと設定され必要に応じてDB2が自動調整する
– 例外)utility heap, catalog cache, audit buffer, java heap, etc
メモリー不足によるエラーの削減
z 各構成パラメーターをAUTOMATICと設定することで、必要に応じてメモリーサイズを調
整する
INSTANCE_MEMORY1/2
１つのデータベースパーティションに割り当てることが可能な最 大メモリーサイズを指定する
z デフォルト値(=AUTOMATIC)
¾ 実際の設定値は、db2start時にサーバーの実メモリーの75% - 95%の間で割り当てられる
¾ 実メモリーが割り当てられるわけではなく構成パラメーター値に上限値がセットされる
V9.1までとは意味が異なる
¾ インスタンス管理用として予約する必要のあるメモリーサイズを指定(V9.1)
INSTANCE_MEMORYの更新
z INSTANCE_MEMORYの動的増加は成功し、動的減少の場合は、現在使用されているメ
モリー量よりも大きい場合に成功する
z サーバーの実メモリーより大きい値がINSTANCE_MEMORYに設定された場合、db2start はSQL1220Nで失敗する
z インスタンス稼動中に、実メモリーよりも大きい値にINSTANCE_MEMORYが更新された
場合、更新要求は据え置かれ、次回のdb2startがSQL1220Nで失敗する
INSTANCE_MEMORY2/2
INSTANCE_MEMORYサイズに達した状態で、特定ヒープに対してメモリー拡 張要求が来た場合
１．DB2は全ての共有メモリー、プライベートメモリーから要求されたメモリー量を削減しようと試みる ２．上記対応後も十分な空きINSTANCE_MEMORY領域を確保できなかった場合、拡張要求は失敗す
る
(例外)DB2の稼動に致命的な影響を与えるメモリーに対して拡張要求が来た
場合
z 致命的な影響
¾ メモリー拡張要求が失敗することで、DBが無効とみなされる
¾ インスタンスがシャットダウンしてしまう
１．データベースパーティションで使用している現在の使用メモリーサイズの削減を試みる
２．上記対応後も十分な空きINSTANCE_MEMORY領域を確保できなかった場合、DB2はOSにメモリー 要求を出し、OSからメモリーを確保する
¾ OSからメモリーを確保できた場合、INSTANCE_MEMORYのサイズが構成値を上回ることがある
考慮点
z 同一サーバー上で、別ミドルウェアも並行稼動する場合、もしくは複数のインスタンスが並行稼動す
る場合には、INSTANCE_MEMORYに適切な値を設定することで効率良いメモリー配分が可能とな
る
APPL_MEMORY
アプリケーションを実行するために割り当てることが可能な最大 メモリーサイズを指定する
z DBで消費されるアプリケーションメモリーの合計量をこのパラメーターで制限することが
できる
デフォルト値(=AUTOMATIC)
z DB活動化の時点で、最少のメモリーが割り当てられる
APPL_MEMORYに数値が設定された場合
z DB活動化の時点で、設定されたメモリーサイズが割り当てられ、APPL_MEMORYサイズ
の増減は発生しない
z 初期設定値のメモリーをサーバーから取得できなかった場合、もしくは、
INSTANCE_MEMORYの値を超えた場合、DBの活動化はSQL1084Cで失敗する
考慮点
z DATABASE_MEMORYに一定量のメモリーサイズを確保しておきたい場合には、
APPL_MEMORYで使用可能なメモリーサイズを制限する
バッファープール関連のパラメーター
バッファプールの構成
z 表スペースのディスクに対する入出力のキャッシュ
z LOBに対してバッファプールは効果が無い
プリフェッチャー（NUM_IOSERVERS）を十分に構成する
z このパラメータは必要より大きく構成しても、ほんの少しメモリを消費するだけで他の悪影 響は考えられない
z 物理ディスクの数＋２ 程度が推奨
ページクリーナー（NUM_IOCLEANERS）も十分に構成する
z このパラメータは大きく構成し過ぎると、CPUの負荷を必要以上に大きくする可能性があ る
z CPUの数を初期値に、最大で物理ディスク数迄
解説
パフォーマンスに最も影響を与えるパラメータがバッファプールと言われています。DB2が使 用するメモリー領域の中で通常、最も大量にメモリーを使用します。
バッファプールは表及び索引・データのキャッシュに相当します。
バッファプールはデータベースが活動化時（通常最初の接続が行われた時）にアロケーショ ンされ、非活動化時（最後の接続が切断された時）に解放されます。
バッファプールのみを大きくしても、物理ディスクのIOを行うプリフェッチャーとページクリー ナーが少なければ、効果が上がらない可能性があります。
プリフェッチャーの初期値は、表及び索引を配置している物理ディスクの数+2（物理ディスク 数はRAID5ディスクの場合、パリティ・スペアを除く）と一般的に言われています。
ページクリーナーはCPUの数から物理ディスクの数の間で調整します。初期値はCPUの数
（物理ディスク数はRAID5ディスクの場合、パリティ・スペアを除く）。
RAID5等ストライピングされたディスクを表スペースに使用する場合、プリフェッチャー及び
ページクリーナーは通常ディスクと同様に調整する必要がありますが、さらにdb2setコマンド で設定する環境変数：db2_parallel_ioに＊（全ての表スペース）また特定の表スペースIDを指 定する必要があります。
バッファプールのサイズは、スナップショットによってバッファープールヒット率（（論理読出数
－物理読出数）／論理読出数×１００）を計算して通常評価します。通常80%から90%以上が
目安ですが、システムの性格によってはそれ以下でも問題がない場合もあります。
プリフェッチャー（NUM_IOSERVERS）
プリフェッチャーは先読みを行う時に使用される。
データベース構成パラメーター「NUM_IOSERVERS」にて数を指定。
z V9以降、デフォルト値はAUTOMATIC（V8以前のデフォルト値は「3」）
¾ AUTOMATICの場合、データベース活動化時点で、適正値を計算
cont cont
cont
Bufferpool
Prefetcher Prefetcher
Prefetcher Prefetcher
必要のないプリフェッチャ ーは使用されない
page page page page page page page page
page
page page page
Prefetcher Prefetcher
Prefetch 単位
Extent Extent Extent
表スペース
解説
バッファプールに表スペースからデータを読み込む時に、小さなデータを読み込むのであれば、通常はエージェント が直接読み出して、バッファプールに格納します。しかし、連続したデータを読み込むような場合は、DB2が判断し、プリフェッチ（Pre-Fetch：先読み）を行います。このプリフェッチは、プリフェッチャーと呼ばれるプロセスによって行わ れます。プリフェッチャーの数はデータベース毎に指定できます。データベース構成パラメータ：NUM_IOSERVERSで す。
プリフェッチャーが効率よく動作するためにはもう一つ構成が必要です。それは表スペースの属性である、PrefetchSizeです。各プリフェッチャーはそれぞれ１回の読み込みで、ExtentSize分のページを読み込みます。
PrefetchSizeはExtentSizeの何倍になっているかによって、幾つのプリフェッチャーが必要なのかが決まります。ここ
で重要なのは、PrefetchSizeはExtentSizeの倍数である必要があるという点です。何倍かは、コンテナー数倍を基本 とします。
上記の図の例で考えてみましょう。表スペースは、物理ディスク３つから構成されています。表スペースのExtentSize はデフォルトの32ページとします。この場合、この表スペースの最適なPrefetchSizeは、ExtentSize×表スペースを 構成する物理ディスク数となり、96ページということになります。
この構成によって、プリフェッチャーはこの表スペースを先読みする際には、３つ使用され、それぞれのディスクを 別々のプリフェッチャー・プロセスがIOし、ディスクIOの効率化を図ります。
この際、表スペースは、各ディスクに１つずつ合計３つのコンテナーから構成する必要があります。OSのストライピン グによって複数のディスクから単一のコンテナーを構成することも可能ですが、DB2に複数ディスクから構成されて いることを明確にし、ディスクの入出力をDB2によって効率化する為にも、OSのストライピングよりDB2のストライピン グの方が推奨されます。
最近の物理ディスクは、飛躍的に速度が速くなっているので、PrefetchSizeは必ずしもExtentSize×物理ディスク数 でなくても、その倍程度でも効果があることが確認されています。物理ディスク装置へのSCSI またはファイバーチャ ネルの速度などにもよるので、一概には言えませんが、倍、3倍、4倍程度を試してみて効果があればそのPrefetchSizeが、最もパフォーマンス的に優れているということになります。
プリフェッチャーの構成（NUM_IOSERVERS）は、大きすぎても使われないプロセスが起動されているだけなので、多
ドキュメント内
データベース物理設計【DB2 9.5 対応版】
(ページ 157-170)