データベースの問題を発見するスクリプト：DB2チューニング・ベストプラクティス（4）（2/2 ページ）
本連載はDB2 UDB V8のシステム管理者、およびアプリケーション開発者のために、パフォーマンス・チューニングに必要な技法を紹介する。記事の原文はIBM developerWorksで2004年4月に公開された「Best practices for tuning DB2 UDB v8.1 and its databases」で、DB2の設計、配置、構成、SQL、運用管理、モニタリングといった内容を、実践的な操作を中心に解説している。想定する読者はDB2データベース管理の中級レベルのスキルを持っているユーザーである。スクリーン・ショットなど一部のコンテンツは、日本語版のものに差し替えている。（編集局）
「Rows read」（読み取られた行数）
これは、最も多くの行を読み取る動的SQLステートメントを識別するのに役立ちます。読み取られる行数が多いということは、一般的に表スキャンが行われていることを意味します。あるいは、選択性の極めて低い索引スキャンを意味する場合もあります。これは、表スキャンと同じくらいに望ましくないものです。
実際にどちらの状況が発生しているかを確かめるには、Explainを使用します。表スキャンが行われている場合は、表に対してRUNSTATSを実行するか、またはSQLステートメントを「設計アドバイザー」に入力して適切な索引を推奨させることによって、問題を改善できます。選択性の低い索引スキャンが行われている場合は、より適切な索引が必要です。「設計アドバイザー」を使用してください。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
「Total execution time」（合計実行時間）
これは、そのSQLステートメントのすべての実行についての合計実行時間です。この値を実行回数で割ると、平均実行時間が得られます。ステートメントの平均実行時間が非常に長い場合は、表スキャンまたはロック待機状態（あるいはその両方）が原因かもしれません。また、索引スキャンおよびページ・フェッチによる大量の入出力も原因として考えられます。多くの場合、索引を使用することで、表スキャンとロック待機の両方を避けることができます。ロックはコミット時に解放されるため、頻繁にコミットするように心掛けると、ロック待機の問題を改善できます。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
「Statement text」（ステートメント・テキスト）
SQLステートメントのテキストが表示されます。WHERE文節の述部の値だけが異なるステートメントが繰り返し使われている場合は、パラメータ・マーカーを使用することにより、ステートメントの再コンパイルを回避できます。つまり、同じパッケージを使用することで、コストのかかるPREPAREの繰り返しを避けることができます。また、このテキストを「設計アドバイザー」に入力すると、最適な索引を生成できます。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
バッファ・プールのサイズ変更
「get snapshot for all on dbname」を使用すると、データベース上のそれぞれのバッファ・プールごとに1つのスナップショットが生成されます。リスト4は、そのようなスナップショットの例を示しています。
- リスト4 バッファ・プールのスナップショットの例（別ウィンドウで表示します）
バッファ・プールの効率を判断するには、BPHR（Buffer Pool Hit Ratio：バッファ・プール・ヒット率）を計算します。計算に必要な情報と特に重要な情報は、リストの中で赤字で示してあります。理想的なBPHRの値は、90%以上です。BPHRの計算式は次のとおりです。
*** 一部省略されたコンテンツがあります。PC版でご覧ください。 ***
リスト4のIBMDEFAULTBPバッファ・プールのスナップショットでは、BPHRは次のように計算できます。
= (1-((54 + 94) / (370 + 221))) * 100
= (1-(148 / 591)) * 100
= (1- 0.2504) * 100
= 74.96
この場合のBPHRは、約75％です。現在のバッファ・プールのサイズは、たったの250×4Kbytesページ（1Mbytes）です。このバッファ・プールのサイズを増やして、BPHRが向上するかどうかを確かめます。それでもBPHRが低い場合は、「バッファ・プールの作成」および「表スペースの作成」の各セクションの説明に従って、論理レイアウトを再設計する必要があります。
ブロック・ベースのバッファ・プールの効率
ブロック・ベースのバッファ・プールを使用していて、「Block IOs」の値が少ない場合は、バッファ・プールを変更して、NUMBLOCKPAGESのサイズを増やしてみてください。結果として「Block IOs」の値が増えた場合は、サイズをさらに増やしてみてください。逆に、「Block IOs」の値が減った場合は、サイズを減らしてください。（次回に続く）
編集局：第4回は「パフォーマンス向上のためのスナップショット・モニタ（前編）」を扱いました。次回は「パフォーマンス向上のためのスナップショット・モニタ（後編）」を取り上げます。
著者紹介
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.