Performance Data Investigatorを使用してデータベースのパフォーマンスを確認する、パート1
この記事は、Performance Data Investigator（PDI）を使用してDb2 for iのパフォーマンスを調査する方法について紹介する2部シリーズのパート1です。Db2のパフォーマンスの分析用ツールとして、一番に使用されるのは、 Access Client Solutions のSQL Performance Centerですが、PDIを使用することで得られる有益な情報もあります。PDIは、パフォーマンスの問題を確認しようとするときに、適切な手順で調査を行うための有用な出発点となることもよくあります。私の経験から言えば、PDIはDb2の調査に十分に活用されていないように思います。PDIにあまり馴染みがないという方は、先に進む前に、こちらの記事「 Getting Started with the Performance Data Investigator（Performance Data Investigator入門）」をお読みになることをお勧めします。
IBM Navigator for i の中にある「データの調査」のパースペクティブは、いくつかの コンテンツ パッケージにまとめられています。コンテンツ パッケージは、共通の基礎となるデータがベースとなっている図表を集めたもの（パースペクティブ）です。たとえば、「収集サービス」というコンテンツ パッケージは、収集サービスのデータがベースとなっている図表を集めたものです。
この記事では、「データベース」コンテンツ パッケージについて見て行くつもりです。このコンテンツ パッケージは、Performance Toolsライセンス プログラム製品（5770-PT1、オプション1）に組み込まれています。この製品はほとんどのショップにあると思われますが、5770-PT1がインストールされていない場合は、「データベース」コンテンツ パッケージは表示されません。
「データベース」コンテンツ パッケージを展開すると、数多くのパースペクティブが表示されます。ナビゲーション ツリーの上側にある3つのパースペクティブは、一般に、調査の 出発点と称されています。これらは、調査をどこから始めたらよいかを判断するのに役立つ、システム全体の概観を提供するからです。確認を行うために図表を選択するときには、その図表を作成するのに使用されるデータを持つコレクションも選択する必要があります。「データベース」コンテンツ パッケージのほとんどの図表は、収集サービスのデータがベースとなっています。
入出力読み取りおよび書き込みの数
「入出力読み取りおよび書き込みの数」図表は、データベース読み取りおよび書き込みについてのシステム全体の概観であり、物理入出力と論理入出力、および同期入出力と非同期入出力を表示します。一般に、読み取りおよび書き込みのベースラインのシグニチャーがどのようなものか把握しておくことは有用です。大幅に変動している場合は、問題発生の兆候の可能性があるからです。
物理入出力は、入出力要求が、読み取りか書き込みかを問わず、操作を完了するためにはディスク上のデータにアクセスする必要があることを意味します。論理入出力は、データがすでにメモリー内にあり、アプリケーションがそのデータにアクセスするために位置を特定する必要が生じたときに発生します。同期入出力は、制御が戻される前に読み取りまたは書き込みが完了しなければならないときに発生します。非同期入出力では、入出力操作の完了を待機している間に他の処理が行われることが可能です。物理および同期入出力操作は、パフォーマンスの点で、より大きな問題になるのが一般的です。
以下の画面キャプチャーは、「入出力読み取りおよび書き込みの数」図表の表示例です。自分の会社で、実行されるプロセスについての毎日のスケジュールが定まっているとしたら、傾向は毎日同じようなものになるはずです。この図表からドリルダウンすると、「 データベース入出力 」フォルダー内にある概要図表に移動することができます。あるいは、直接、「データベース入出力」フォルダー内にあるさらに別の図表を調べることもできます。それらの図表では、データベース入出力に関するより詳細な情報を確認することができます。たとえば、ジョブ、汎用ジョブ、現行のユーザー プロファイル、サブシステムなどがベースとなっている入出力を確認する機能を使用することもできます。データベース入出力に関する図表については、筆者のブログ記事「 Viewing Job Level SQL Metrics with the Performance Data Investigator（Performance Data Investigatorを使用してジョブ レベルSQLメトリックを確認する）」に、詳しい説明を記していますので、そちらを参照してください。
SQL CPU使用率の概要
「SQL CPU使用率の概要」図表は、CPU使用率に関して問題があり、SQLの使用に関係があるのか、その他の理由なのか分からないときの良い調査出発点となります。この図表は、CPUがSQLワークロードで使用されているか、非SQLワークロードで使用されているかを示すシステム全体の概観です。
以下の画面キャプチャーでは、1日を通してのCPU使用率が示されていますが、概して、CPU使用率とSQLは関係がなかったことが見て取れます。2つ目の画面キャプチャーでは、「SQL CPU使用率の概要」をより詳細に確認できるように、「Non-SQL CPU Utilization（非SQL CPU使用率）」メトリックの表示をオフにしています。これにより、1日を通してのSQL CPU使用率シグニチャーを確認しやすくなっています。
この図表は、どのようなツールを使用するべきか判断するのに役立つため、CPUの問題が生じたときの良い調査出発点となります。SQLのCPU使用率が主な要因であることが分かった場合は、ご承知のように、より深く掘り下げるために、SQL Performance Centerを使用する必要があります。
データベース・ロックの概要
「データベース・ロックの概要」図表は、データベース レコード ロックの待機に費やされる時間を表示する、システム全体を概観した図表です。データベース レコード ロックの競合は、通常の状況でも起こり得ます。データ保全性を確保するために、レコードが追加、更新、または削除されるときにシステムがロックを保持する必要があるためです。しかし、異常なほどの大量のレコード ロックの競合が発生する場合は、アプリケーションの問題が示されていることもよくあります。通常は、競合を解決することで、パフォーマンスが改善します。「収集サービス」のデータをドリルダウンして、影響を受けているジョブを特定することができます。そうしたジョブは、ロックを要求しているが、取得することができない競合の被害者です。
データベース レコード ロックの競合の問題を抱えている場合は、おそらくJob Watcherのデータを収集して根本原因を特定する必要があります。Job Watcherのデータでは、ロックを保持しているスレッドを特定することができます。また、Job Watcherは、競合問題を解決する上で非常に有用である、コール スタックおよびSQLステートメントも収集します。詳細については、「 The basics of IBM i wait accounting （IBM i 待機アカウンティングの基礎）」を参照してください。
パート2の記事では、「データベース」コンテンツ パッケージに含まれる、残りのパースペクティブについて概観する予定です。
