ログの配置
アクティブログに対する書き込み速度はアプリケーションのレスポンスに直接 影響する
アクティブログは安全性を考えると、二重化した方がよい
z （アクティブログの障害＝データベースの障害） である。
z DB2の二重ログは両方に書き出して終了なので、どちらか１つのディスクが遅い場合、ログへ
の書き込みは遅くなる。
ディスク容量が許すのであれば
z アクティブログ専用のディスク上に配置する
¾ ESSの場合ランクも別の方が理想的
¾ SCSI / Fibreなどのチャネルもできれば別 z RAID5ではなく、ミラーリングを使用する
z ストライピングによって書き込みを速くする
ログ
バッファプール
解説
ログはDB2にとって重要なオブジェクトです。特にアクティブログは非常に重要で、アクティブログが損傷したことは データベース自身が損傷したことを意味します。
つまり、アクティブログが壊れたら、データベースが壊れたのと同じです。
何故、アクティブログがそれほど重要なのでしょうか。更新処理を行う時のDB2の動作を考えてみます。
データベースが更新された場合、バッファプールと呼ばれるキャッシュのデータが更新されますが、ディスクにはすぐ には書き出されません（このようなデータが含まれるページをダーティーページと呼びます）。その更新処理がコミッ トされると、必ずログに書き出されます。
この状態でもしDBサーバーがクラッシュした場合、次にデータベースが使われる前に、クラッシュリカバリーという処 理を行う必要があります。クラッシュリカバリーによって、更新されたはずなのにディスクに反映されていない更新を、ログを読みながらディスクへ反映します。
ここで、重要な点はログがなければクラッシュ前にどのような更新処理が行われていたのかを知ることができないと いうことです。DB2はこのクラッシュリカバリーによって、突然のDB2の異常停止などの時でもデータベースに格納さ れているデータの論理的な整合性を保証しています。つまり、ログが壊れるということはDB2がデータの整合性を保 証できないということを意味しています。
ログの重要性を理解したところで、そのI/Oパフォーマンスが非常に重要であることも気が付かれたと思います。更 新処理がコミットされたら必ずログに書き出される訳ですから、ログへの書き出しが終わらないと次の処理へ進むこ とができません。
更新処理のボトルネックがログのI/Oにならないようにする為には、他のI/Oとの衝突をできる限り避ける必要があり ます。他のI/Oとは表や索引のデータが含まれるディスクへのI/Oが含まれます。つまり、ログは表や索引などとは 全く別のディスクに配置することが推奨されます。ESSのような１つのアレイが大きな場合でも、できる限り全く別の ディスク上に配置し、SCSIやファイバーチャネルなどのインターフェースも別にすることが推奨されます。
また、書き込みに対して多少不利なRAID5よりもできればミラーリング（RAID1）などを選択するようにしてください。
さらにディスクに余裕がある場合には、ストライピングなどによって高速化できれば更新処理にとって良い結果が期 待できます。ログの配置（続き）
アーカイブログとアクティブログは別のディスクに配置する
z アーカイブログ・ディレクトリ（コピー先）とアクティブログ・ディレクトリ（コピー元）は別にした方 がパフォーマンス的に有利
z 障害時の危険分散を考えても別の方がよい
¾ アクティブログとアーカイブログが壊れた場合、バックアップからのリストアーはできても、最新 状態へのロールフォワードができなくなる。
大量更新を行うバッチ系処理の場合(Importなど)
z ログに対するキャッシュに相当するログバッファー(LOGBUFSZ)を大きくする
ローデバイスロギングは、V9では推奨されない
z ローデバイスロギングを使用すると、二重ログが使えない
z USEREXITに何らかの問題があって、ログのコピーに失敗した場合、手動によるコピーが不可
ログ・アーカイブ機能（V8.2以降）を使用する場合は、アーカイブ先ディレ クトリとして容量と配置に注意する
z 二つのアーカイブ先ディレクトリ（LOGARCHMETH1, LOGARCHMETH2）を使用する場合
¾ 領域は2倍必要
– 代替ディレクトリ（FAILARCHPATH）を使用する場合は、更に領域が必要
¾ それぞれ別のディスクに配置する
解説
アクティブログの重要性を説明してきましたが、DB2にはもう一つアーカイブログというログがあります。通常、ログ・アーカイブ機能によって、アクティブログがアーカイブされた時に、そのアーカイブ・ログをアクティブログとは別のディ レクトリ（またはテープのような別のメディア）にコピーして保存します。このログファイルをコピーする処理も重要です。
コピー先のログファイルは、コピー元やデータベース自身の障害発生時に復元の為に必要になるので、コピー元と は全く別のディスクやメディアに保存する必要があります。また、ログ・アーカイブ機能はデータベースが使われてい る時に動作しますので、もし同じディスクにコピー先を配置してしまうと、コピー先の書き込みI/Oの為にアクティブロ グ自身のI/Oへ影響を与える可能性があります。データベースのパフォーマンスを維持するためには、できる限りこ のような影響は排除する必要があります。
１つの作業単位（UOW）によって大量のデータを更新するような場合、コミットとコミットの間隔が非常に長くなります。このような場合、データベース構成パラメータのログバッファー（LOGBUFSZ）を大きくするとパフォーマンスに好影響 を与えます。このような更新処理の場合、ログバッファが小さいと（デフォルトでは32KB）、更新処理がコミットされて いなくても、ログを頻繁にディスクに書き出さなければならなくなる為に、パフォーマンスに悪影響があります。
ログをローデバイスに配置する機能をDB2はサポートしていますが、V9では推奨されません。ローデバイスロギング を使用する場合、何らかの問題があってログ・アーカイブ機能によるログファイルのコピーに失敗し、アクティブログ のデバイス中に特定のログファイルが残ってしまったようなケースでは、手動でコピーすることができません。障害時 の復旧作業は、通常時とは異なり、多種の問題が発生している可能性があり、手動で復旧できないということは、安 全性が低いとも言えます。
また、DB2の二重ログの機能はローデバイスで使用することはできません。ワーク／バックアップ領域の配置
バックアップ時間の短縮が必要な場合、バックアップ領域のパフォーマンスを 考慮する
z ディスクへのバックアップの場合、バックアップ元のあるディスクとは別にする
z １つのディスクでは要求が満たせない場合、複数のディスクへのバックアップを検討
z テープへのバックアップは、TSMがサポートしていれば、複数テープへの同時書き込みによっ て高速化が可能
ロードの処理時間短縮が必要な場合
z ロード元のデータを格納するファイルシステムのパフォーマンスを考慮する
z AIXでは、以下のパラメータがパフォーマンスに影響する場合がある
¾ vmtuneのminpgahead, maxpgahead（ファイルシステムの先読み）
一時表スペースと同居できるか
z ロード時の入力ファイルと、ソート用の一時表スペースのI/Oが競合するとロードのパフォーマ ンスに悪影響が考えられる
z 通常は、再編成時にはロードやバックアップなどの処理は行わない。
その他の領域
DB2診断情報格納ディレクトリー
z インスタンス・ホーム・ディレクトリー（デフォルト）、または、データベース・マネージャ構成パラ メーターDIAGPATHにて指定した場所に格納される
z 管理通知ログ、db2diag.log、ダンプ・ファイル、トラップ・ファイル、コア・ファイル (UNIX のみ)を 格納する
¾ V8.2以降は、db2diag.logへ書かれる内容が増えているため、V8.1以前より容量が増 える可能性がある。
データベース・ディレクトリー
z バッファープール情報、表スペース情報、データベース構成情報、リカバリ履歴ファイル、ログ
制御ファイル
⑦構成パラメーターの設定
スレッドモデルへの変更
メモリーモデルの変更
バッファープール関連のパラメーター
z プリフェッチャー
z ページクリーナー
その他最低限構成すべきパラメーター
自己チューニングメモリー(Self Tuning Memory Manager)
スレッドモデルへの変更
V9.5からは、 UNIX、Linux プラットフォームにおいて、従来のようなプロセス・
モデルではなく、db2syscプロセスが 1つ存在し、残りのEDUは db2syscプロセ ス配下にスレッドとして存在するアーキテクチャーに変わった。
UDB
Client Library
Active
db2agntp
Write Log Requests
Vic tim
Notifications
Parallel, Page Write Requests
Shared Mem & Semaphores, TCPIP, Named Pipes,…
Process/Thread Organization
Instance Level
Per-instance
Idle, pooled agent or subagent
db2tcpcm db2ipccm
db2agent (idle)
Per-application
db2agent
db2pclnr db2pfchr
db2loggw
db2dlock
db2agntp
db2loggr
Per-database
Data Disks Common Client
Subagents UDB Server Listeners Coordinator Agents
Prefet chers Page Cleaners
Buffer Pool(s)
Dead l ock Detector
Log Disks
Idle Agent Pool
Logging
Subsystem Log Buffer
Database Level
Idle
Async
IO Prefetch
Requests
Parallel, Big-block, Read Requests
V9.5からは、点線
枠で囲まれた部分 は、1つのプロセス となる。各EDUは、スレッドとして存在 して、
db2syscプロ
セスに紐づく。db2acd
FMP
Health Monitor
db2wdog
ドキュメント内
データベース物理設計【DB2 9.5 対応版】
(ページ 147-156)