お客様が developerWorks に初めてサインインすると、プロフィールが作成されます。プロフィールで選択した情報は公開されますが、いつでもその情報を編集できます。お客様の姓名（非表示設定にしていない限り）とディスプレイ・ネームは、投稿するコンテンツと一緒に表示されます。

送信されたすべての情報は安全です。

developerWorks に初めてサインインするとプロフィールが作成されますので、その際にディスプレイ・ネームを選択する必要があります。ディスプレイ・ネームは、お客様が developerWorks に投稿するコンテンツと一緒に表示されます。

ディスプレイ・ネームは、3文字から31文字の範囲で指定し、かつ developerWorks コミュニティーでユニークである必要があります。また、プライバシー上の理由でお客様の電子メール・アドレスは使用しないでください。

送信されたすべての情報は安全です。

My developerWorks：

通知：

サイン・アウト

言語を選択する：

OLTP アプリケーションのための DB2® のチューニング・ヒント

Yongli An (yongli@ca.ibm.com), DB2 Performance Engineer, IBM Toronto Lab

Yongli An は DB2/UDB パフォーマンス・エンジニアで、UNIX、Windows、および OS/2R 用の DB2 UDB 7.1 データベース管理分野の IBM 認定ソリューション・エキスパートです。TPC-C ベンチマーク経験を有し、現在は WebSphereR Advanced Server および e-business アプリケーションを中心に活動中です。

Peter Shum (shum@ca.ibm.com), DB2 e-business Performance Manager, IBM Toronto Lab

Peter Shum は、DB2 e-business パフォーマンス・マネージャーです。TPC-C、TPC-W、WebSphere Advanced Server、および CommerceSuite 用の DB2 パフォーマンスを担当しています。パフォーマンスに関与する前は、TP モニター・サポートおよび分散リレーショナル・データベース・アーキテクチャー (DRDA) の経験があります。

概要： OLTP アプリケーションのためのDB2のチューニング・ヒント

タグを付ける!

日付: 2001年 7月
レベル: 初級
この記事の原文: 英語
アクティビティー： 3254 ビュー
お気軽にご意見・ご感想をお寄せください：

はじめに

DB2 ユニバーサル・データベース (UDB) は、マルチメディア対応、Web 対応の最初のリレーショナル・データベース管理システムで、大企業の要件にも対応できる頑健さと小規模や中規模のビジネスにも対応できる柔軟性を兼ね備えています。DB2 製品ファミリーとインターネット技術の融合により、さまざまなプラットフォームにまたがる情報の容易なアクセス性、可用性、安全性を実現しています。世界中で 30 万社以上、6000 万人を超える DB2 ユーザーが、IBM のデータ管理ソリューションに依存しています。

DB2 UDB は、e コマース、エンタープライズ・リソース・プランニング (ERP)、カスタマー・リレーションシップ・マネージメント (CRM)、サプライ・チェーン・マネージメント (SCM)、Web セルフサービス、およびビジネス・インテリジェンスなど、要求レベルのもっとも高い e-business アプリケーションの基盤です。DB2 UDB は、e-business を展開するためのデータ管理の基盤として理想的な、スケーラブルで高性能のデータベースです。

オンライン・トランザクション処理 (OLTP) は、トランザクション指向アプリケーションを促進し管理するアプリケーション・クラスで、金融、航空会社、通信販売、スーパーマーケット、製造業などを含む多くの業界におけるデータの入力および取り出しトランザクション用です。通常、OLTP ワークロードは、同時に実行される多数の軽いトランザクションで構成されます。今日のオンライン・トランザクション処理では、ネットワークにまたがり複数の企業を含むトランザクションをサポートする必要性が増しています。このため、新しい OLTP ソフトウェアでは、トランザクションをネットワーク内の複数のコンピューター・プラットフォーム上で実行できるクライアント/サーバー処理やブローカー・ソフトウェアを使用しています。

パフォーマンスは、どのようなタイプのデータベース・システムでも最重要課題の 1 つです。この記事では、OLTP タイプのパフォーマンス・ベンチマーク (TPC-C、TPC-W、Trade2 など) から学んだことに基づいて、DB2 パフォーマンスのチューニングのヒントを中心に説明します。データベース・アプリケーションのパフォーマンスは多くの要因により左右されますが、ここでは、DB2 の構成に焦点を絞り、キャパシティー計画、データベース設計、またはアプリケーション設計の詳細については触れません。

この記事の編成は次のとおりです。

パフォーマンスに関する基本事項

カタログ統計情報の更新最新のデータベース統計情報を収集し保守することの重要性を説明します。最新でないと、パフォーマンスの問題が引き起こされることになりかねません。

データベース構成パラメーターの監視とチューニングデータベース・マネージャーのパラメーターとデータベース・パラメーターを重要なものから順番に説明します。パフォーマンス目標を達成しようとする場合、通常はリスト内のパラメーターをすべて調べる必要はありません。リストの上位を占めるいくつかのパラメーターを試してみて、パフォーマンスが向上したかどうかを確認します。

ここで説明するヒントにより、妥当なパフォーマンスで OLTP を開始し実行することができます。

上に戻る

パフォーマンスに関する基本事項

1. 十分なメモリーを確保する。

32 ビット・システムの場合は、バッファー・プール、DB2 エージェント、および大量同時ユーザーのサポートに必要なその他の共用メモリーをサポートするために、CPU 1 台につき少なくとも 512MB の RAM で、マシン 1 台につき最大 4GB を使用します (DB2 で使用できるバッファー・プールのサイズの詳細は、後述の「バッファー・プール・サイズ (BUFFPAGE)」を参照してください)。ローカルに実行されるアプリケーションやストアード・プロシージャーとして実行されるアプリケーションをサポートするには、これ以上のメモリーが必要になる可能性があります。AIX® 上では、JFS ファイル・キャッシュで追加メモリーを使用して、バッファー・プールを補完できます。
64 ビット・システムの場合は、バッファー・プールのサイズは任意です。ただし、大規模データベースを使用する eコマース OLTP アプリケーションのほとんどでは、8GB 以上のバッファー・プールは必要ありません。大きければそれに越したことはありませんが、バッファー・プール・ヒット率が 98+% の範囲に近づくにつれ、ある時点でパフォーマンスは減衰します。同時ユーザーの数 (および DB2 エージェント数に与えるその影響) により、必要なメモリー量が決定されます。
データベースへの各ユーザー接続 (DB2 エージェント) が必要とするメモリー量は、アプリケーションにより実行される SQL ステートメントの特性 (同時にオープンされるカーソルの数や必要なソート・スペースおよび一時スペースなど) に依存します。OLTP アプリケーションの場合、必要なソート・スペースや一時スペースは少なくなり、同時カーソル数は少数 (たとえば、一時点でオープンされる数は 5 つ) です。経験則では、DB2 エージェント 1 つにつき、最低限で UNIX の場合は 1MB、Windows の場合は 500KB を使用します。分離ストアード・プロシージャーを使用する場合は、ストアード・プロシージャー・アプリケーションの実行に必要なメモリーに加えて、各ユーザー接続で DB2 エージェントを 2 つ使用します。
経験則：DB2 エージェント 1 つにつき、最低限で UNIX の場合は 1MB、Windows の場合は 500KB を使用します。分離ストアード・プロシージャーを使用する場合は、ストアード・プロシージャー・アプリケーションの実行に必要なメモリーに加えて、各ユーザー接続で DB2 エージェントを 2 つ使用します。

2. 十分な I/O 処理能力を確保する。

大量の同時トランザクションをサポートする十分な I/O 並列処理が実行されるように、ディスク・アーム数が十分になければなりません。中程度のトランザクション量の場合は少なくとも 5 ～ 10 ディスク、大量 I/O の OLTP トランザクションの場合は少なくとも 20 ディスクが必要です。オペレーティング・システム (ページング・スペースを含む)、DB2 のログ、および DB2 表スペースにそれぞれ専用のディスクが必要です。DB2 ログ、表、および索引用にそれぞれ複数のディスクが必要になります。
優れたパフォーマンスを上げるために必要な I/O 処理能力の正しい見積り方法は、トランザクションのプロトタイプを実際に作成し、トランザクションごとに I/O がいくつ必要か、1 秒間にトランザクションがいくつ必要かを確認します。次に、ディスク制御装置とディスク・サブシステムの I/O レートを確認し、制御装置とディスクがいくつ必要かを判断します。

3. 十分なネットワーク帯域幅を用意する。

ワークロードをサポートする十分なネットワーク帯域幅が必要です。ネットワークまたは中間ハブがボトルネックにならないことを確認します。これは、リモートからのアクセスをサポートする場合に特に重要です。たとえば、T1 回線は 1.544Mビット/秒をサポートしますが、これは 0.193MB/秒であり、通常の 10Mビット/秒イーサネット LAN は、1.25MB/秒で 6 倍のスループットをサポートします。UNIX 上では netstat などのコマンドを使用して、接続での通信量を監視します。

4. DB2 データベース・マネージャーおよびデータベース構成パラメーターの初期設定には、DB2 コントロール・センターの DB2 パフォーマンス構成ウィザードを使用する。

このツールは、ワークロードの特性に関して一連の質問を表示し、構成パラメーターの適切な値を判断します。これらのパラメーターは、本番のワークロードに見合うように変更できます。

5. 表の列に適切な索引を付ける

照会で結合される列には索引が必要です。
ORDER BY および GROUP BY に関与する列に索引を付けると、パフォーマンスが上がります。
頻繁にアクセスされるデータも、INCLUDED 列として索引内に含めることができます。
使用する表および SQL ステートメントに基づいて最適の索引を判断するには、索引アドバイザー(DB2 コントロール・センターの索引ウィザードとも呼ぶ) を使用します。

6. ロックの保持期間はできるだけ短くする

ユーザー操作に複数の対話が含まれる場合、それぞれの対話にはコミット対象の独自のトランザクションが含まれ、ユーザーにアクティビティーを戻す前にロックを解放する必要があります。(トランザクションを開始する) 最初の SQL ステートメントをできるだけ遅く開始するようにし、このステートメントによる更新 (排他ロックを使用する挿入、更新、削除) はできるだけコミット段階の近くで実行するようにして、トランザクションの実行時間をできるだけ短くするようにします。
DB2 レジストリー・パラメーター DB2_RR_TO_RS を使用すると、挿入または更新された行の次のキーをロックしないため、並行性レベルが向上します。これは、同一の表に対して操作するプログラムで分離レベル RR (反復可能読取り) が使用されない場合に使用できます。デッドロック数とロック待機数を監視するには、DB2 スナップショットを使用します。

7.ストアード・プロシージャーまたは複合 SQL を使用して、ネットワーク・コストを最小化する。

SQL ステートメントのネットワーク・トリップ数を最小化すると、ネットワーク待ち時間とコンテキストの切替え回数が節約され、ロックを保持するアプリケーションの実行時間が短くなります。一般に、OLTP トランザクションにステートメントが 4 〜 5 以上ある場合は、ストアード・プロシージャーを使用します。
一方、アプリケーション・ロジックに CPU 集中型の複雑な処理がある場合は、データベース・サーバーに対して実行されるストアード・プロシージャーの中にこれを残しておくと、データベース・サーバーの CPU サイクルがかなり占有され、データベース操作に影響が出る可能性があります。この場合は、ストアード・プロシージャーを使用しないか、ロジックの一部をクライアント側で実行し、残りをストアード・プロシージャーで実行するようにします。

8. SQL を効率的に使用する。

一般に、SQL ステートメントは、1 つで済む場合には複数を使用しないようにします。照会に使用する述部の数を増やして詳細な検索条件を提供すると、オプティマイザーが最適な選択を行える可能性が高くなります。照会は正しい選択を行って絞り込むようにして、必要以上の行や列をデータベースが返さないようにします。たとえば、SQL を使用して必要な行をフィルタリングします。行をすべて返し、その後でアプリケーションでフィルタリングしなければならないような状況は避けます。

9. アクセス・プランを分析する。

Visual Explain または db2exfmt を使用して、それぞれの SQL ステートメントを分析します。表を選択および結合するときに内部的にフェッチされる行数が少なくなるように、適切な索引を使用します。

上に戻る

カタログ統計情報の更新

背景
RUNSTATS ユーティリティーは、照会の最適化処理に役立つように、システム・カタログ表の統計情報を更新します。このような統計情報がないと、データベース・マネージャーが SQL ステートメントのパフォーマンスに悪影響を及ぼすような判断をしかねません。RUNSTATS ユーティリティーを使用すると、表、索引、または表と索引の両方に含まれているデータに関する統計情報を収集できます。RUNSTATS ユーティリティーを使用して、表データと索引データの両方に基づく統計情報を収集し、次のような状況でのアクセス・プランの選択プロセスに対して正確な情報を提供します。

表にデータがロード済みで、適切な索引が作成済みであるとき
REORG ユーティリティーを使用して表が再編成されたとき
表およびその索引に影響する大量の更新、削除、および挿入操作があったとき (この場合の「大量」とは、表データおよび索引データの 10 〜 20% に影響があることを意味します)
パフォーマンスが重要であるアプリケーション・プログラムをバインドする前
新規統計情報と以前の統計情報を比較するとき。RUNSTATS を定期的に実行すると、パフォーマンスの問題を早期に発見できます。
プリフェッチ量が変更されたとき
REDISTRIBUTE NODEGROUP ユーティリティーを使用したとき

SQL 照会を最適化するとき、SQL コンパイラーにより行われる判断は、データベース内容に関するオプティマイザー・モデルにより大きく影響されます。このデータ・モデルは、特定の照会を解決するために使用できる代替アクセス・パスのコストをオプティマイザーが見積もるために使用します。データ・モデルの重要な要素は、データベース内に含まれていてシステム・カタログ表に保管されているデータに関して収集される一連の統計情報です。これには、表、ニックネーム、索引、列、およびユーザー定義関数 (UDF) の統計情報が含まれます。データ統計情報が変更されると、対象データのアクセスにもっとも効率的な方法として選択されているアクセス・プランが変更される可能性があります。
オプティマイザーに対してデータ・モデルを定義するために役立つ統計情報の例としては、以下が含まれます。

表に含まれているページ数および空でないページ数。
行が元のページから別 (オーバーフロー) ページに移動された度合い。
表に含まれている行数。
列の中の個別の値など、個々の列に関する統計情報。
索引のクラスター化程度。つまり、行に含まれている物理的な行順序が索引に対応する程度。
索引レベルの数と、各索引に含まれているリーフ・ページの数。
頻繁に使用される列値の発生頻度。
列に含まれている値の範囲全体にわたる列値の分布。
ユーザー定義関数 (UDF) のコスト見積もり。

RUNSTATS は、データベース内の変更とパフォーマンスがどのように関連するかを判断するために役立ちます。統計情報により、表の中のデータ分布が示されます。RUNSTATS を定期的に使用すると、一定期間にわたる表と索引に関するデータが提供され、時間の経過に伴うデータ・モデルのパフォーマンス傾向を判断できます。静的 SQL を使用するアプリケーションの場合は、照会オプティマイザーが新しい統計情報に基づいて最善のアクセス・プランを選択できるように、RUNSTATS を実行した後再バインドする必要があります。ただし、動的 SQL を使用するアプリケーション (ほとんどのベンダー・アプリケーション) の場合は、ステートメントが実行時に統計情報に基づいて最適化されるため、再バインドは不要です。表に関する統計情報が正確でないと、パフォーマンス上の問題が発生することがあります。最悪の場合、特定の SQL ステートメントにより、索引スキャンのかわりに表スキャンを使用されてしまう可能性があります。

統計情報の更新方法

システム・カタログ表のオブジェクトの統計情報は、明示的に要求された場合にだけ更新されます。統計情報を部分的にまたは全体的に更新する方法はいくつかあります。

RUNSTATS (統計情報の実行) ユーティリティーの使用
統計情報収集オプションを指定した LOAD の使用
事前定義の一連のカタログビューに対して操作される SQL UPDATE ステートメントの作成
「reorgchk update statistics」コマンドの使用

表の名前がすべてわかっているわけではない場合、あるいは表の数が多すぎる場合、RUNSTATS のもっとも簡単な実行方法は、「db2 reorgchk update statistics」コマンドの使用です。正確なスクリプトは、次のとおりです。

db2 -v connect to DB_NAME
db2 -v "select tbname, nleaf, nlevels, stats_time from sysibm.sysindexes"
db2 -v reorgchk update statistics on table all
db2 -v "select tbname, nleaf, nlevels, stats_time from sysibm.sysindexes"
db2 -v terminate

例として使用したスクリプトには表の名前は不要です。1 つのコマンドですべての表に対して RUNSTATS が実行されます。

注：データベースにデータを挿入する前に RUNSTATS を実行してはいけません。

表の名前がわかっていて、完了までに時間のかかる大量の表を避けたい場合は、各表に対して RUNSTATS を 1 つずつ実行するようにします。このコマンドは、次のようになります。

db2 -v runstats on table TAB_NAME and indexes all

これで、表ごととすべての索引 (基本レベル) に対する統計情報が収集されます

RUNSTATS が実行されたかどうかの確認
データベースに対して RUNSTATS が実行されたかどうかを確認する簡単な方法としては、システム・カタログの表をいくつか照会してみる方法があります。たとえば、前述のスクリプトのように、次のコマンドを実行できます。

db2 -v "select tbname, nleaf, nlevels, stats_time from sysibm.sysindexes"

RUNSTATS が実行されていない場合は、nleaf 列と nlevels 列に「-1」が表示され、stats_time 列に「-」が表示されます。RUNSTATS が実行された場合はこれらの列に実数が含まれ、stats_time 列には RUNSTATS が実行されたときのタイムスタンプが含まれます。stats_time に示されている時刻が古すぎる場合は、RUNSTATS を再度実行します。

上に戻る

データベース構成パラメーターの監視とチューニング

データベース構成のチューニングに関する以下のヒントにより、妥当なパフォーマンスの OLTP 環境で作業を開始し、同時に明らかな落し穴を回避できます。変更を有効にするには、データベース・マネージャー構成パラメーターの場合はデータベース・マネージャーを再起動する必要があり、ほとんどのデータベース構成パラメーターでは、アプリケーションをデータベースに再接続する必要があります。ここで説明する構成パラメーターは、次のとおりです。

バッファー・プール・サイズ
ログ・バッファー・サイズ
アプリケーション・ヒープ・サイズ
ソート・ヒープ・サイズとソート・ヒープしきい値
エージェント数
ロック
アクティブ・アプリケーションの最大数
非同期ページ・クリーナーの数
I/O サーバーの数
グループに対するコミット数

上に戻る

バッファー・プール・サイズ

背景
バッファー・プールとは、(表の行または索引項目を含む) データベース・ページが一時的に読み込まれて変更される記憶領域です。バッファー・プールの目的は、データベース・システムのパフォーマンスの向上です。データはディスクよりもメモリーからアクセスする方がかなり高速です。従って、データベース・マネージャーからディスクへの読み書き回数が少ないほど、パフォーマンスは上がります。1 つ以上のバッファー・プールを構成することがもっとも重要なチューニング分野です。データベースに接続されるアプリケーションの場合には (ラージ・オブジェクトや長いフィールドのデータを除く) データ操作のほとんどはバッファー・プール内で発生します。

デフォルトでは、アプリケーションは IBMDEFAULTBP というバッファー・プールを使用します。このバッファー・プールはデータベースの作成時に作成されます。DB2 データベース構成パラメーターの BUFFPAGE は、SYSCAT.BUFFERPOOLS カタログ表内のバッファー・プールの NPAGES の値が -1 の場合、そのバッファー・プールのサイズを制御します。それ以外の場合、BUFFPAGE パラメーターは無視され、NPAGES パラメーターにより指定されたページ数のバッファー・プールが作成されます。

推奨事項
バッファー・プールを 1 つだけ使用するアプリケーションの場合は、BUFFPAGE でバッファー・プールのサイズが制御されるように、NPAGES を -1 に変更します。これにより、その他の DB2 データベース構成パラメーターとともにバッファー・プール・サイズを変更したりレポートすることが容易になります。

バッファー・プール・サイズの制御にデータベース構成の BUFFPAGE パラメーターを使用できることを確認した後、これを適切な値に設定します。データベースのサイズとアプリケーションの特性に基づいて、このパラメーターを無理なく大きな値に設定した方が安全です。通常、このパラメーターのデフォルト値は非常に小さいので不十分な可能性があります。次のことを考慮に入れます。

マシン上でメモリー上の制約がない場合、このパラメーターの開始値は 40,000 ページ (160MB) またはマシン上の合計メモリーの 10% に設定します。
大規模な OLTP データベースの場合は、システムの安定性を保ちつつ、できるだけ多くのメモリーをバッファー・プール用として確保します。この場合は 1.6GB から開始して、さらに増やしてみます。

パラメーターの変更方法

以下のスクリプトを実行して、次のことを行います。

カタログ値を確認する。
データベース構成パラメーター BUFFPAGE を使用可能にする。
BUFFPAGE の値をすべてのデータベースで更新する。

db2 -v connect to DB_NAME
db2 -v select * from syscat.bufferpools
db2 -v alter bufferpool IBMDEFAULTBP size -1
db2 -v connect reset
db2 -v update db cfg for dbname using BUFFPAGE bigger_value
db2 -v terminate

確認手順
データベースのバッファー・プール・サイズに BUFFPAGE パラメーターが使用されているかどうかを判断するには、以下を実行します。

db2 -v connect to DB_NAME
db2 -v SELECT * from SYSCAT.BUFFERPOOLS
db2 -v connect reset
db2 -v terminate

結果を調べます。各バッファー・プールの NPAGES の値が -1 の場合、バッファー・プール・サイズはデータベース構成の BUFFPAGE パラメーターにより制御されています。

データベースのバッファー・プール・サイズが十分な大きさかどうかを判断するには、アプリケーションの実行中にデータベースまたはバッファー・プール (あるいはその両方) のスナップショットを収集します。以下のようなスクリプトにより、必要な情報を取得できます。

db2 -v update monitor switches using bufferpool on
db2 -v get monitor switches
db2 -v reset monitor all

-- run your application --
db2 -v get snapshot for all databases > snap.out
db2 -v get snapshot for dbm >> snap.out
db2 -v get snapshot for all bufferpools >> snap.out
db2 -v reset monitor all
db2 -v terminate

データベース接続を失う前に「db2 -v get snapshot」コマンドを発行するようにします。最後のアプリケーションがデータベースから切断されると、データベースは終了し、スナップショット統計情報はすべて失われます。データベースを稼働状態に保つ接続が常に 1 つあるようにするには、次の方法のいずれかを使用します。

スナップショットを収集しているウィンドウで別の接続を維持する。
DB2 ACTIVATE DATABASE コマンドを使用する。

データベース・スナップショットまたはバッファー・プール・スナップショットのいずれでも、スナップショット出力に示される次の「論理読み込み」および「物理読み込み」を調べて、バッファー・プール・ヒット率を計算します。これがバッファー・プールのチューニングに役立ちます。

-- Related lines from a sample of bufferpool snapshots --
Buffer pool data logical reads = 702033
Buffer pool data physical reads = 0
Buffer pool data writes = 414
Buffer pool index logical reads = 168255
Buffer pool index physical reads = 0

バッファー・プール・ヒット率は、データベース・マネージャーがページ要求に対してサービス提供する場合にディスクからページをロードする必要がなかった回数、つまりページがバッファー・プールにすでに存在していた回数の割り合いを示します。バッファー・プール・ヒット率が高いほど、ディスク I/O の頻度は下がります。バッファー・プール・ヒット率は次のように計算します。

(1 - ((buffer pool data physical reads + buffer pool index physical reads) /
(buffer pool data logical reads + pool index logical reads))
) * 100%

この計算では、バッファー・プールによりキャッシュされているすべてのページ (索引およびデータ) が考慮に入れられています。この数値は、95% 以上、できるだけ 100% に近いのが理想的です。バッファー・プール・ヒット率を上げるには、次のことを試してみます。

バッファー・プール・サイズを増やす。
複数のバッファー・プール (専用の表スペースを持つ頻繁にアクセスされる大きな表ごとに 1 つ、小さい表のグループに 1 つ) を割り当てることを考慮する。次にバッファー・プールにさまざまなサイズを試してみて、どの組み合わせが最善のパフォーマンスになるかを確認する。

割り当てられたメモリーがパフォーマンスの改善に貢献しない場合は、バッファー・プールにメモリーを割り当てすぎないようにします。バッファー・プール・サイズは、テスト環境で取得されたスナップショット情報に基づいて判断する必要があります。

上に戻る

ログ・バッファー・サイズ (LOGBUFSZ)

背景
LOGBUFSZ はデータベース構成パラメーターで、ログ・バッファー用のパラメーターです。これを使用すると、ログ・レコードをディスクに書き込む前にログ・レコードのバッファーとして使用されるデータベース共用メモリーの量を指定できます。ログ・レコードは、次のイベントのいずれかが発生したときにディスクに書き込まれます。

トランザクションをコミットする。
ログ・バッファーが満杯になる。
その他のデータベース・マネージャー内部イベントの結果

ログ・レコードをバッファーに入れると、ログ・レコードがディスクに書き込まれる頻度が下がり、書き込み時に書き込まれるレコード数が増えるため、ログ・ファイル I/O がより効率的になります。専用ログ・ディスクに対する読み込みアクティビティーがかなり多い場合、またはディスク使用率が高い場合は、このバッファー領域のサイズを増やします。ログ・バッファー領域は、DBHEAP パラメーターにより制御されているスペースを使用するため、このパラメーターの値を増やすときは、DBHEAP パラメーターも考慮します。

パラメーターの変更方法
このパラメーターのデフォルト値の 8 (4KB ページ) では、通常の OLTP データベースには十分でないことがわかりました。LOGBUFSZ の最適値は 128 個または 256 個の 4KB ページです。たとえば、次のコマンドを使用してこのパラメーターを変更できます。

db2 -v update database cfg for DB_NAME using LOGBUFSZ 256
db2 -v terminate

確認手順
LOGBUFSZ パラメーターが最適かどうかを判断するには、データベースのスナップショットを使用します。次の例に示されている行を確認します。

Log pages read = 0
Log pages written = 12644

一般に、「log pages read」と「log pages written」との間の比率はできるだけ小さくします。理想的な値としては log pages read がゼロで、log pages written は大きな値です。log pages read の数が多すぎると、大きな LOGBUFSZ が必要であることを意味します。

アプリケーション・ヒープ・サイズ (APPHEAPSZ)

背景
APPHEAPSZ は、データベース・マネージャーが特定のエージェントまたはサブエージェントに代わって使用するための私用メモリー・ページの数を定義するデータベース構成パラメーターです。ヒープは、エージェントまたはサブエージェントがアプリケーション用に初期化されるときに割り当てられます。割り当てられる量は、エージェントまたはサブエージェントに渡された要求の処理に必要な最低限の量です。エージェントまたはサブエージェントが大きな SQL ステートメントの処理にそれ以上のヒープ・スペースを必要とする場合は、このパラメーターで指定されている値を上限にして、データベース・マネージャーが必要に応じてメモリーを割り当てます。

パラメーターの変更方法
デフォルト値 (DB2 EE の場合は 128 個の 4KB ページ、DB2 EEE の場合は 64 個の 4KB ページ) を最適値に変更するコマンドは、次のとおりです。

db2 -v update db cfg for DB_NAME using applheapsz 256
db2 -v terminate

確認手順
アプリケーション・ヒープに十分な記憶域がないことを示すエラーをアプリケーションで受け取った場合は、APPHEAPSZ の値を増やします。

上に戻る

ソート・ヒープ・サイズ (SORTHEAP) とソート・ヒープしきい値 (SHEAPTHRES)

背景
SORTHEAP は、私用ソートのために使用される私用メモリー・ページ数の最大値、または共用ソートのために使用される共用メモリー・ページ数の最大値を定義するデータベース構成パラメーターです。ソートが私用ソートの場合は、このパラメーターがエージェント私用メモリーに影響します。共用ソートの場合は、データベース共用メモリーに影響します。ソートのそれぞれには、必要に応じてデータベース・マネージャーにより個別のソート・ヒープが割り当てられます。このソート・ヒープが、データがソートされる領域です。オプティマイザーで指示された場合は、オプティマイザーが提供する情報を使用して、このパラメーターで指定された値より小さいソート・ヒープが割り当てられます。

SHEAPTHRES は、データベース・マネージャー構成パラメーターです。私用ソートおよび共用ソートでは、2 つの異なるメモリー・ソースのメモリーを使用します。共用ソート・メモリー領域のサイズは、データベースに最初に接続されたときに、SHEAPTHRES の値に基づいて静的に事前に決定されます。私用ソート・メモリー領域のサイズは、無制限です。SHEAPTHRES パラメーターの適用は、私用ソートと共用ソートでは異なります。

私用ソートの場合、SHEAPTHRES は任意の時点で私用ソートが消費可能な合計メモリー量に対するインスタンス全体でのソフトな上限です。インスタンスの私用ソート・メモリー消費合計がこの上限に達すると、それ以上着信する私用ソート要求に割り当てられるメモリーは、かなり少なくなります。
共用ソートの場合、SHEAPTHRES は任意の時点で共用ソートが消費可能な合計メモリー量に対するデータベース全体でのハードな上限です。この上限に達すると、共用ソートのメモリー消費合計が SHEAPTHRES で指定されている上限を下回るまで、それ以上の共用ソート・メモリー要求は受け付けられません。

ソート・ヒープを使用する操作の例としては、ハッシュ結合や表がメモリー内にある場合の操作があります。しきい値を明示的に定義することにより、データベース・マネージャーが大量のソートにメモリーを消費しないで済みます。

推奨事項

ソート・アクティビティーの追跡にはデータベース・システム・モニターを使用します。
ソート・ヒープの使用を最小化するには、適切な索引を使用します。
大規模なソートが頻繁に必要な場合は、SORTHEAP の値を増やします。
SORTHEAP を増やす場合は、データベース・マネージャーの構成ファイルにある SHEAPTHRES パラメーターも調整する必要があるかどうかを判断します。
ソート・ヒープ・サイズは、オプティマイザーがアクセス・パスの判断に使用します。このパラメーターを変更した後は、(REBIND PACKAGE コマンドを使用して) アプリケーションを再バインドすることを考慮します。
理想的には、ソート・ヒープしきい値 (SHEAPTHRES) パラメーターは、データベース・マネージャー・インスタンス内の最大の SORTHEAP パラメーターの適切な倍数に設定します。このパラメーターは、インスタンス内のデータベースに定義されている最大の SORTHEAP の少なくとも 2 倍にする必要があります。

パラメーターの変更方法

SORTHEAP および SHEAPTHRES の値を変更するには、次のコマンドを実行します。

-- SORTHEAP should be changed for individual database --
db2 -v update db cfg for DB_NAME using SORTHEAP a_value
-- SHEAPTHRES is a database manager parameter --
db2 -v update dbm cfg using SHEAPTHRES b_value
db2 -v terminate

確認手順
OLTP アプリケーションでは大規模ソートを実行すべきではありません。CPU リソースおよび I/O リソースの観点から、大規模ソートはコストが高すぎます。通常は、SORTHEAP サイズのデフォルト値 (256 個の 4KB ページ) で十分です。実際、並列性の高い OLTP の場合はこのデフォルト値を減らすことがあります。さらに確認が必要な場合は、次のコマンドを発行します。

db2 -v update monitor switches using sort on

アプリケーションをしばらく実行してから、次のように入力します。

db2 -v get snapshot for database on DBNAME

次の例のような出力になります。

Total sort heap allocated = 0
Total sorts = 1
Total sort time (ms) = 0
Sort overflows = 0
Active sorts = 0
Commit statements attempted = 1
Rollback statements attempted = 0
Dynamic statements attempted = 4
Static statements attempted = 1
Binds/precompiles attempted = 0

この情報を基に、トランザクション当たりのソート数とソートで使用可能なメモリーをオーバーフローしたソートの割合を計算できます。

SortsPerTransaction
= (Total Sorts) / (Commit statements attempted + Rollback statements attempted)

PercentSortOverflow
= (Sort overflows * 100 ) / (Total sorts)

経験則：SortsPerTransaction が 5 より大きい場合は、トランザクション当たりのソート数が多すぎる可能性があります。PercentSortOverflow が 3% より大きい場合は、予期していなかった大規模ソートが発生している可能性があります。これが発生したときに SORTHEAP を増やすと、パフォーマンスの問題が隠れてしまうことになります。問題は修正されません。この問題に対する解決策は、正しい索引を追加して、問題のある SQL ステートメントに対するアクセス・プランを改善することです。

上に戻る

エージェント数 (MAXAGENTS、NUM_POOLAGENTS、および NUM_INITAGENTS)

背景
これらは、データベース・マネージャー構成パラメーターです。

MAXAGENTS パラメーターは、一時点でアプリケーション要求の受け入れ用として使用可能なデータベース・マネージャー・エージェントの最大数を示します。MAXAGENTS の値は、少なくとも、各データベース内で同時にアクセスされる MAXAPPLS (最大同時アプリケーション数) 値の合計にする必要があります。データベースの数が NUMDB パラメーターより多い場合は、MAXAPPLS にもっとも大きい値を指定して NUMDB の積を使用すると安全です。エージェントを追加するたびに、データベース・マネージャーが起動されたときに割り当てられているリソース・オーバーヘッドをいくらか消費します。
NUM_POOLAGENTS パラメーターは、エージェント・プールの最大規模を示す指針です。このパラメーターの値で示されている数より多いエージェントが作成された場合、エージェントは現在の要求を実行した後、プールには戻されずに終了します。このパラメーターの値が 0 の場合、エージェントは必要に応じて作成され、現在の要求を実行した後終了します。
多数のアプリケーションが同時に接続されている OLTP 環境で、エージェントの頻繁な作成や終了に伴うコストを回避するには、NUM_POOLAGENTS の値を MAXAGENTS の値に近づくまで増やします。
NUM_INITAGENTS パラメーターは、DB2START 時にエージェント・プール内に作成されるアイドル・エージェント数の初期値を決定します。必要ではありませんが、かなりの数の初期エージェントを指定すると、ウォーミングアップ時間が短くなります。

推奨事項
ほとんどの場合、MAXAGENTS および NUM_POOLAGENTS は、予想される最大同時アプリケーション接続数より多少大きい値に設定します。 NUM_INITAGENTS はデフォルトのままで十分です。

パラメーターの変更方法
これらのパラメーターを変更するには、次のコマンドを実行します。

db2 -v update dbm cfg using MAXAGENTS a_value
db2 -v update dbm cfg using NUM_POOLAGENTS b_value
db2 -v update dbm cfg using NUM_INITAGENTS c_value
db2 -v terminate

確認手順
実行中ならいつでも、次のコマンドを使用して、データベース・マネージャーのスナップショットを取得できます。

db2 -v get snapshot for database manager

以下の出力行を確認します。

High water mark for agents registered = 4
High water mark for agents waiting for a token = 0
Agents registered = 4
Agents waiting for a token = 0
Idle agents = 0
Agents assigned from pool = 5
Agents created from empty pool = 4
Agents stolen from another application = 0
High water mark for coordinating agents = 4
Max agents overflow = 0

「Agents waiting for a token」または「Agents stolen from another application」が 0 以外の場合は、データベース・マネージャーでより多くのエージェントを使用できるように、MAXAGENTS を増やさなければならないことがあります。

上に戻る

ロック (LOCKLIST、MAXLOCKS、および LOCKTIMEOUT)

背景
これらのロック関連のパラメーターは、データベース構成パラメーターです。

LOCKLIST は、ロック・リストに割り当てられる記憶域の量を示します。ロック・リストは 1 データベース当たりに 1 つあり、そのデータベースに同時に接続されているすべてのアプリケーションにより保持されているロックが含まれます。ロックとは、データベース内のデータに対する複数アプリケーションからの同時アクセスを制御するために、データベース・マネージャーが使用するメカニズムです。行も表もロックできます。ロック 1 つにつき、ロック・リストに 32 バイトまたは 64 バイトが必要になります。この値は、対象のオブジェクトに対して他のロックが保持されているかどうかに依存します。
他のロックが保持されていないオブジェクトにロックを保持するには、64 バイト必要です。
ロックがすでに保持されているオブジェクトにロックを記録するには、32 バイト必要です。
MAXLOCKS は、アプリケーションにより保持されるロック・リストの割合を定義します。この割合を超えると、データベース・マネージャーがロック・エスカレーションを実行します。1 つのアプリケーションにより使用されるロック・リストの割合が MAXLOCKS を超えると、データベース・マネージャーがロックをエスカレーションします。これは、行ロックを表ロックに置き換えて、リスト内のロック数を減らすことを意味します。1 つのアプリケーションにより保持されるロック数がロック・リストの合計サイズに占めるこの割合に達すると、そのアプリケーションにより保持されているロック・エスカレーションが発生します。ロック・エスカレーションは、ロック・リストのスペースが不足したときにも発生します。データベース・マネージャーは、ロック・リスト内でそのアプリケーションを探して、行ロックのもっとも多い表を見つけることにより、どのロックをエスカレーションするかを判断します。行ロックを 1 つの表ロックに置き換えた後、MAXLOCKS 値より小さい場合は、ロック・エスカレーションが停止します。そうでない場合は、保持されているロック・リストの割合が MAXLOCKS の値より小さくなるまで、ロック・エスカレーションが続行されます。MAXLOCKS パラメーターと MAXAPPLS パラメーターの積は、100 未満にはなリ得ません。
エスカレーション・プロセス自体は時間はほとんどかかりませんが、(個別の行ではなく) 表全体をロックすると並行性が低下し、影響される表に対する後続アクセスでデータベース全体のパフォーマンスが下がる可能性があります。ロック・リストのサイズを制御するための推奨事項は、次のとおりです。
- 頻繁にコミットしてロックを解放する。
- 更新を多数実行するときは、更新の前に (SQL LOCK TABLE ステートメントを使用して) トランザクションの期間中、表全体をロックする。このために使用されるロックは 1 つだけで、他のロックにより更新が邪魔されることはありませんが、他のユーザーに対するデータの並行性は低下します。
- 特定の表に対する永久的なロック方法を制御するには、ALTER TABLE ステートメントの LOCKSIZE パラメーターを使用する。
- アプリケーションで使用される分離レベルを調べる。反復可能読取り分離レベルを使用すると、場合によっては表が自動的にロックされることになります。可能な場合はカーソル固定分離レベルを使用して、保持される共用ロックの数を減らします。アプリケーション保全要件が損なわれない場合は、カーソル固定ではなく非コミット読取り分離レベルを使用して、ロック量をさらに減らします。
ロック・リストに必要なページ数を判断するには、次の手順を実行します。
1. ロック・リスト・サイズの下限の計算：(512 * 32 * MAXAPPLS) / 4096 です。512 は、アプリケーション 1 つ当たりの予測平均ロック数で、32 は、すでにロックのあるオブジェクトに対する各ロックに必要なバイト数です。
2. ロック・リスト・サイズの上限の計算：(512 * 64 * MAXAPPLS) / 4096 です。64 は、オブジェクトに対する最初のロックに必要なバイト数です。
3. データに対する並行性の程度を予測に基づいて求め、計算した上限と下限の間に収まるロック・リストの初期値を選びます。
  
  MAXLOCKS 値のチューニングにはデータベース・システム・モニターを使用します
  
  MAXLOCKS を設定するときは、ロック・リスト (LOCKLIST) のサイズを考慮します
  
  MAXLOCKS = 100 * (512 ロック/アプリケーション * 32 バイト/ロック * 2) / (LOCKLIST * 4096 バイト)
  
  このサンプル式を使用すると、任意のアプリケーションが平均の 2 倍のロック数を保持できます。MAXLOCKS を増やせるのは、同時に実行されるアプリケーションが少ない場合だけです。これは、このような状況ではロック・リスト・スペースの競合があまり発生しないからです。
4. LOCKTIMEOUT は、アプリケーションがロックを取得するために待機する秒数を指定します。これは、アプリケーションのグローバル・デッドロックの回避に役立ちます。
  - このパラメーターを 0 に設定した場合、アプリケーションはロックの取得を待機しません。この場合、要求した時に使用できるロックがないと、アプリケーションは即座に -911 を受け取ります。
  - このパラメーターを -1 に設定した場合、ロック・タイムアウト検出はオフになります。この場合、アプリケーションは (要求した時に使用できるロックがない場合は) ロックが付与されるまで、あるいはデッドロックが発生するまで、ロックを待機します。

推奨事項
(たとえばユーザーが離席した結果) トランザクションが停止したなどの異常な状況のために発生中の待機をすばやく検出するには、LOCKTIMEOUT を設定します。ピーク時の作業負荷が原因で有効なロック要求がタイムアウトしないように、この値は十分高くします。ピーク時にはロック待機時間が長くなります。

オンライン・トランザクション処理 (OLTP) 環境では、値は 30 秒から開始します。照会専用環境の場合は、これより高い値で開始します。いずれの場合も、このパラメーターのチューニングにはベンチマーク技法を使用します。

パラメーターの変更方法
ロック・パラメーターを変更するには、次のコマンドを実行します。

db2 -v update db cfg for DB_NAME using LOCKLIST a_number
db2 -v update db cfg for DB_NAME using MAXLOCKS b_number
db2 -v update db cfg for DB_NAME using LOCKTIMEOUT c_number
db2 -v terminate

確認手順
ロック・リストがいっぱいになると、ロック・エスカレーションでは表ロックが行ロックよりも多く作成されるため、パフォーマンスが減衰する可能性があり、このためデータベース内の共用オブジェクトに対する並行性が低下します。さらに、(すべてのアプリケーションが限られた数の表ロックを待機するため) アプリケーション間のデッドロック数が増える可能性があり、トランザクションがロールバックされることになります。データベースに対するロック要求数が最大値に達すると、アプリケーションは SQLCODE -912 を受け取ります。ロック・エスカレーションが原因でパフォーマンスが憂慮される場合は、LOCKLIST パラメーターまたは MAXLOCKS パラメーターの値を増やします。ロック・エスカレーションが発生しているかどうかの判断、アプリケーション (接続) でのロック・タイムアウト回数の追跡、接続されているすべてのアプリケーションでタイムアウト状況がデータベースにより検出されたかどうかの判断には、データベース・システム・モニターを使用できます。

最初に次のコマンドを実行して、DB2 モニターをロックに対してオンにします。
db2 -v update monitor switches using lock on db2 -v terminate
次にデータベースのスナップショットを収集します。
db2 -v get snapshot for database on DB_NAME

スナップショット出力で、次の項目を調べます。

Locks held currently = 0
Lock waits = 0
Time database waited on locks (ms) = 0
Lock list memory in use (Bytes) = 504
Deadlocks detected = 0
Lock escalations = 0
Exclusive lock escalations = 0
Agents currently waiting on locks = 0
Lock Timeouts = 0
Internal rollbacks due to deadlock = 0

上に戻る

アクティブ・アプリケーション数の最大値 (MAXAPPLS)

背景
MAXAPPLS は、データベース構成パラメーターです。データベースに接続可能な同時実行アプリケーション (ローカルおよびリモート) の最大数を指定します。データベースに接続される各アプリケーションには私用メモリーを割り当てる必要があるため、同時実行アプリケーションの数を大きくすると、メモリーの使用量も上がります。このパラメーターの値は、接続アプリケーションの合計数と、これらのアプリケーションで 2 フェーズ・コミットまたはロールバック処理を同時に行うアプリケーションの数を加算した値以上に設定する必要があります。

推奨事項
OLTP アプリケーションを実行するには、同時実行ユーザー/接続の最大数に対応できる (大きくはあるが、必要以上に大きすぎない) 適切な値に MAXAPPLS を設定するようにします。接続プールを使用するアプリケーションの場合は、MAXAPPLS を接続プール・サイズより 1 か 2 大きい値に設定することをお勧めします (コマンド行接続を起動して何か行うときのため)。

パラメーターの変更方法
MAXAPPLS の値を変更するには、次のコマンドを実行します。

db2 -v update db cfg for DB_NAME using MAXAPPLS a_number
db2 -v terminate

確認手順
アプリケーションがデータベースに接続しようとしたときに、MAXAPPLS の値にすでに達している場合は、次のエラーがアプリケーションに返され、データベースにはすでに最大数のアプリケーションが接続されていることを示します。

SQL1040N データベースに接続しているアプリケーションの数が、既に最大数に達しています。
SQLSTATE=57030

上に戻る

非同期ページ・クリーナー数 (NUM_IOCLEANERS)

背景
NUM_IOCLEANERS は、データベースの非同期ページ・クリーナーの数を指定するデータベース構成パラメーターです。これらのページ・クリーナーは、データベース・エージェントによりバッファー・プール内のスペースが必要になる前に、変更済みページをバッファー・プールからディスクに書き出します。これにより、エージェントは変更済みページの書き出しを待機せずに新しいページを読み込めます。この結果、アプリケーションのトランザクションの実行速度が上がります。

このパラメーターをゼロ (0) に設定すると、ページ・クリーナーは開始されず、その結果、データベース・エージェントがバッファー・プールからディスクへのページ書き込みをすべて実行します。データベースが多数の物理記憶装置にまたがって保管されている状況では、装置の 1 つがアイドルになっている可能性が高いため、そのような状況では、このパラメーターによりパフォーマンスに重大な影響があります。ページ・クリーナーが構成されていない場合は、アプリケーションが定期的に「ログフル」状態を検出する可能性があります。

データベース・アプリケーションが主にデータ更新トランザクションで構成されている場合、クリーナー数を増やすとパフォーマンスが上がります。ページ・クリーナーを増やすと、ディスク上のデータベースの内容が常に最新であるため、停電などのソフト障害からの回復時間も短縮されます。

このパラメーターに値を設定するときに考慮する要因をいくつか次に示します。

トランザクションがデータベースに対して実行される場合は、このパラメーターを 1 からデータベース用に使用される物理記憶装置数までの間の値に設定します。少なくともシステム上の CPU の数に設定することをお勧めします。
更新トランザクション率の高い環境では、より多くのページ・クリーナーの設定が必要になることがあります。
大きいバッファー・プールのある環境でも、より多くのページ・クリーナーの設定が必要になることがあります。

パラメーターの変更方法
このパラメーターを新しい値に設定するには、次のコマンドを使用できます。

db2 -v update db cfg for DB_NAME using NUM_IOCLEANERS a_number
db2 -v terminate

確認手順
この構成パラメーターのチューニングにはデータベース・システム・モニターを使用します。バッファー・プールからの書き込みアクティビティーに関するスナップショット・データ (またはイベント・モニター) の情報を使用します。

スナップショットを使用し、バッファー・プールのスナップショット・データを収集するときは、以下のカウンターを監視します。

Buffer pool data writes = 0
Asynchronous pool data page writes = 0

Buffer pool index writes = 0
Asynchronous pool index page writes = 0

LSN Gap cleaner triggers 	= 0
Dirty page steal cleaner triggers  = 0
Dirty page threshold cleaner triggers = 0

NUM_IOCLEANERS を減らすか増やすかを判断する方法

以下の条件が両方とも真の場合は、NUM_IOCLEANERS を減らします。

「Buffer pool data writes」が「Asynchronous pool data page writes」にほぼ等しい。
「Buffer pool index writes」が「Asynchronous pool index page writes」にほぼ等しい。

以下の条件のいずれかが真の場合は、NUM_IOCLEANERS を増やします。

「Buffer pool data writes」が「Asynchronous pool data page writes」よりもかなり大きい。
「Buffer pool index writes」が「Asynchronous pool index page writes」よりもかなり大きい。

Dirty page steal cleaner triggers は、データベース用のビクティム・バッファーの置き換え中に同期書き込みが必要になったためにページ・クリーナーが起動された回数を示します。応答時間を上げるために、この数値はできるだけ低くします。前述のカウンターを使用して次の式を使用すれば、クリーナーの全起動のうちの何パーセントがこの要素に起因しているかを計算できます。

BDirty page steal cleaner triggers / (Dirty page steal cleaner triggers + 
	           Dirty page threshold cleaner triggers +
	           LSN Gap cleaner triggers)

この数値が高い場合は、定義されているページ・クリーナーの数が少なすぎることを示します。ページ・クリーナーの数が少なすぎると、障害後の回復時間が長くなります。

上に戻る

I/O サーバー数 (NUM_IOSERVERS)

背景
I/O サーバーは、データベース・エージェントに代わって、バックアップおよび復元などのユーティリティーにより事前取り出し I/O および非同期 I/Oを実行します。このパラメーターはデータベース構成パラメーターで、データベース用の I/O サーバーの数を指定します。事前取り出しおよびユーティリティー用にこの数以上の I/O を同時にデータベースに対して実行することはできません。I/O サーバーは、自身が開始した I/O 操作が処理中は待機します。事前取り出し以外の I/O はデータベース・エージェントから直接スケジュールされるため、NUM_IOSERVERS による制約は受けません。

推奨事項
OLTP 環境ではデフォルトを使用します。

パラメーターの変更方法
NUM_IOSERVERS を新しい値に設定するには、次のコマンドを使用します。

db2 -v update db cfg for DB_NAME using NUM_IOSERVERS a_number
db2 -v terminate

上に戻る

グループへのコミット数 (MINCOMMIT)

背景
MINCOMMIT は、最低限の数のコミットが実行されるまで、ログ・レコードのディスクへの書き出しを遅延するデータベース構成パラメーターです。この遅延は、ログ・レコードの書き出しに伴うデータベース・マネージャーのオーバーヘッドの削減に役立ちます。これは、データベースに対して複数のアプリケーションを実行していて、短時間の間にアプリケーションによりコミットが多数要求されたときに、パフォーマンスが改善されることを意味します。このコミットのグループ化は、このパラメーターの値が 1 より大きく、データベースに接続されているアプリケーション数がこのパラメーターの値より大きいか等しい場合にだけ発生します。コミットのグループ化を実行中は、1 秒経過するまで、またはコミット要求数がこのパラメーターの値に等しくなるまで、アプリケーションのコミット要求は保留されます。

推奨事項
MINCOMMIT のデフォルト値は 1 です。複数の読み取り/書き込みアプリケーションのほとんどが同時データベース・コミットを要求する場合は、このパラメーターをデフォルト値より増やします。これにより、ログ用ファイル I/O の頻度が下がり、書き込みのたびにログ・レコードが多数書き込まれるため、ログ用のファイル I/O が効率的になります。デフォルト値が適切でないと考える場合は、3 から開始して増やしたり減らしたりしてみて、作業負荷のパフォーマンスに与える影響を調べます。1 秒当たりのトランザクション数をサンプリングし、このパラメーターを調整して、ピーク時の 1 秒当たりのトランザクション数 (またはその大部分) に対応できるようにします。ピーク時のアクティビティーに対応すれば、負荷の多い期間中のログ・レコード書き込みオーバーヘッドが最小化されます。

MINCOMMIT を増やす場合は、負荷の多い期間中にログ・バッファーがいっぱいになって書き込みが強制されることを避けるために、LOGBUFSZ パラメーターも増やさなければならないことがあります。この場合、LOGBUFSZ は次の値に等しくなるように設定します。

MINCOMMIT * (log space used, on average, by a transaction)

データベース・システム・モニターを使用してこのパラメーターをチューニングする方法を、以下に示します。

ピーク時の 1 秒当たりのトランザクション数の計算：

モニターで典型的な 1 日のサンプルを取ると、負荷の多い時間帯がわかります。これを行う方法の 1 つは、次のとおりです。

測定の最初に次のコマンドを発行します。
db2 -v reset monitor for database db_name
(これにより、最高水準点用のカウンターはリセットされません。)
測定の最後に次のコマンドを発行します。
db2 -v get snapshot for database on db_name

次の出力を使用して、ピーク時のトランザクション数を計算します。

Last reset timestamp = 06-12-2001 14:51:43.786876
Snapshot timestamp = 06-12-2001 14:56:27.787088
Commit statements attempted = 1011
Rollback statements attempted = 10
Log space used by the database (Bytes) = 3990

「commit statements attempted」と「rollback statements attempted」を加算して totalTransactions を求めます。

「Snapshot timestamp」から「Last reset timestamp」を減算して totalElapsedTime (秒単位) を求めます。1 秒当たりのトランザクション数を次のように計算します。

NumOfTransPerSecond = totalTransactions / totalElapsedTime

トランザクション当たりに使用されるログ・スペースの計算：

同じような方法で、一定期間にわたるサンプリング技法とトランザクション数を使用すると、モニター要素 log_space_used (使用された作業ログ・スペース) を使用して平均ログ・スペースを計算できます。
1. 測定の最初に次のコマンドを使用して、該当データベースのモニターをリセットします。
  db2 -v reset monitor for database db_name
2. 測定の最後に次のコマンドを使用してスナップショットを取ります。
  db2 -v get snapshot for database on db2_name.
3. 前述のような出力が作成されます。
4. 次の式を使用して、トランザクション当たりに使用されるログ・スペースを計算します。
  LogSpaceUsedPerTrans = log_space_used / totalTransactions

パラメーターの変更方法

MINCOMMIT 値を変更するには、次のコマンドを使用します。

db2 -v update db cfg for DB_NAME using MINCOMMIT a_number
db2 -v terminate

上に戻る

まとめ

ここでは、DB2 パフォーマンスに関する多くの基礎的事項、チューニングのヒントとその技法、および OLTP パフォーマンスに影響する主な DB2 構成パラメーターについて説明しました。ここで説明した簡単な手順に従えば、DB2 データベース・システムのセットアップ、監視、およびチューニングを行えます。ここで説明されているガイドが、DB2 アプリケーションのパフォーマンスの最適化目標の達成に役立つように願っています。

参考文献