スナップショット・モニタに基づくチューニング：DB2チューニング・ベストプラクティス（5）（4/4 ページ）
LOGPRIMARY、LOGSECOND、LOGFILSIZ（DB）
LOGPRIMARYは、事前に割り振りされる1次ログ・ファイルの数を定義します。LOGSECONDは、必要に応じて割り振られる2次ログ・ファイルの数を定義します。LOGFILSIZは、各ログ・ファイルのサイズを定義します。
「Secondary logs allocated currently」（現在割り振られている2次ログ）の値が大きい場合は、LOGFILSIZまたはLOGPRIMARYの値を増やします（ただし、LOGPRIMARYとLOGSECONDの合計値が「256」を超えないように注意してください）。また、「Maximum total log space used (Bytes)」（使用された最大合計ログ・スペース）を使用して、ログ・ファイル・スペース（1次ログ＋2次ログ）の必要量を求めることもできます。
ログ・ファイルのサイズは、ログ・シッピングを使用する災害時リカバリの構成に影響を与えます。ログ・ファイルのサイズを大きくすると、パフォーマンスは向上しますが、トランザクションの損失の度合いも大きくなります。1次システムがダウンした場合、最後のログ・ファイルとそのトランザクションは2次システムには送られません。なぜなら、そのファイルは障害が発生する前にクローズされていないからです。ログ・ファイルのサイズを大きくすればするほど、ログ・ファイルの損失によるトランザクションの損失の度合いは大きくなります。
LOGBUFSZ（DB）
このパラメータを使用すると、ディスクに書き込む前のログ・レコード用のバッファとして使用されるデータベース・ヒープ（DBHEAP）の量を指定できます。ログ・レコードは、トランザクションがコミットされた場合やログ・バッファがいっぱいになった場合にディスクに書き込まれます。ログ・レコードをバッファリングすると、ログ・レコードがディスクに書き込まれる頻度が下がり、より多くのログ・レコードがまとめて書き込まれるようになります。一般的にOLTPでは「256」（ページ）以上、OLAPでは「128」以上から始めるとよいでしょう。「Log pages read」（読み取られたログ・ページの数）の値が常に「3」以上である場合は、サイズを増やす必要があります。ロールバックが発生しても、ログ・ページは読み取ることができます。
LOGBUFSZを増やそうとしているときにエラーが生じた場合は、まず初めにDBHEAPを同じ量だけ増やしてから再度試みてください。
PKGCACHESZ（DB）
パッケージ・キャッシュは、静的SQLステートメントおよび動的SQLステートメントのためのセクションをキャッシュするために使われます。パッケージをキャッシュすると、パッケージを再ロードする場合にシステム・カタログにアクセスする必要がなくなり、また動的SQLの場合に再コンパイルの必要がなくなるため、データベース・マネージャ内部のオーバーヘッドを削減できます。
PKGCACHESZは、「Package cache high water mark (Bytes)」（パッケージ・キャッシュの最高水準点）よりも大きな値でなければなりません。「Package cache overflows」（パッケージ・キャッシュ・オーバーフロー）が「0」でない場合は、PKGCACHESZを増やすことで、値を「0」にすることができます。
PCHR（Package Cache Hit Ratio：パッケージ・キャッシュ・ヒット率）は、（バッファ・プールから必要なメモリを取り去ることがないように）100％にできるだけ近い値でなければなりません。PCHRは、次の式を使って計算します。
PCHR = (1-("Package cache inserts" / |
CATALOGCACHE_SZ（DB）
このパラメータは、SYSTABLE情報、許可情報、SYSROUTINES情報などのシステム・カタログ情報をキャッシュするために使われます。カタログ情報をキャッシュすることは、特にDPFを使用している場合に非常に重要です。以前に検索した情報を再び取得するためにシステム・カタログ（カタログ・パーティション）にアクセスする必要がなくなるため、内部オーバーヘッドを削減できます。
OLTPでは、CCHR（Catalog Cache Hit Ratio：カタログ・キャッシュ・ヒット率）が95％以上になるまで、この値を増やします。
CCHR = (1-("Catalog cache inserts" / |
「Catalog cache overflows」（カタログ・キャッシュ・オーバーフロー）が「0」より大きい場合も、この値を増やします。また、「Catalog cache high water mark (Bytes)」（カタログ・キャッシュ最高水準点）を使用して、カタログ・キャッシュによってこれまでに使用された最大メモリ量を判別することができます。最高水準点が、許可されている最大サイズと等しい場合は、カタログ・キャッシュのヒープ・サイズを増やします。
実験：DBMおよびDBの構成
以下のパラメータを使用すると、パフォーマンスをさらに向上させることができます。ただし、それらの影響は、スナップショット内の特定のモニタによって直接報告されるものではありません。代わりに、一度に1つのパラメータを変更して、アプリケーション全体のパフォーマンスを測定します。最もよい測定方法は、変更前と変更後の数回のスナップショットからSQL全体の実行時間を調べることです。
INTRA_PARALLEL（DBM）
このパラメータは、データベース・マネージャがパーティション内並列処理を使用できるかどうかを定義します。同時接続の数が多い場合（主にOLTP）は、デフォルト値のNOが最適です。同時接続の数が少ない場合や複雑なSQLを使用する場合（OLAP／DSS）は、YESに設定します。それらが混在するワークロードでは、一般的にNOの方がよい結果が得られます。
YESに設定すると、ソート・メモリが共有メモリから割り振られます。また、並行性のレベルが大幅に増加した場合、システムのオーバーヘッドが極めて大きくなる可能性があります。OLTP以外のシステムで、CPUとパーティションの数の比率が4:1で、CPU使用率が平均で50％未満である場合は、一般的にINTRA_PARALLELの設定を変更することでパフォーマンスが向上します。
DFT_QUERYOPT（DB）
このパラメータは、SQL照会のコンパイル時に使用される最適化のデフォルト・レベルを指定するために使われます。OLTP／OLAPが混在している場合は、この値を「5」または「3」に、OLTPの場合はそれより低い値に、OLAPの場合はそれより高い値に設定します。単純なSELECTや実行時間の短い照会（完了するのに1秒もかからないようなもの）の場合は、「1」または「0」が最適です。表の数が多く、同じ列に対して多くの結合述部を使用する場合は、「1」または「2」に設定してください。完了するのに30秒以上かかる実行時間の長い照会や、（FixPak 4で追加された）UNION ALLビューへの挿入を行う場合は、「7」に設定してください。特別な環境を除いて、「9」は使用しないでください。
UTIL_HEAP_SZ（DB）
このパラメータは、BACKUP、RESTORE、およびLOADユーティリティが同時に使用できるメモリの最大量を定義します。LOADユーティリティを使用する場合は、UTIL_HEAP_SZの値を、CPUごとに「10000」（ページ）以上に設定してください。
NEWLOGPATH（DB）
このパラメータは、ログ・ファイルの書き込みと保存を行うロケーションを変更するために使われます。このパラメータには最大で242bytesの文字列を指定しますが、この文字列には、絶対パス名とロー・デバイスのどちらも使用できます。ログ・ファイルのパスを、独立したローカル高速ディスク（ロギング以外に使用されていないディスク）に変更すると、パフォーマンスが大幅に向上する場合があります。（次回に続く）
編集局：第5回は「パフォーマンス向上のためのスナップショット・モニタ（後編）」を扱いました。次回は「詳細なSQL分析」を取り上げます。
著者紹介
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.
注目のテーマ
ITmediaはアイティメディア株式会社の登録商標です。