連載
» 2004年10月09日 00時00分 公開

データベースの問題を発見するスクリプトDB2チューニング・ベストプラクティス(4)(2/2 ページ)

[Fraser McArthur,DB2 Enablement Consultant/IBM Canada Ltd.]
前のページへ 1|2       

「Rows read」(読み取られた行数)

 これは、最も多くの行を読み取る動的SQLステートメントを識別するのに役立ちます。読み取られる行数が多いということは、一般的に表スキャンが行われていることを意味します。あるいは、選択性の極めて低い索引スキャンを意味する場合もあります。これは、表スキャンと同じくらいに望ましくないものです。

 実際にどちらの状況が発生しているかを確かめるには、Explainを使用します。表スキャンが行われている場合は、表に対してRUNSTATSを実行するか、またはSQLステートメントを「設計アドバイザー」に入力して適切な索引を推奨させることによって、問題を改善できます。選択性の低い索引スキャンが行われている場合は、より適切な索引が必要です。「設計アドバイザー」を使用してください。

UNIX:
grep -n " Rows read" snap.out | grep -v "= 0" | sort -k 5,5rn

Windows:
findstr /C:" Rows read" snap.out | findstr /V /C:"= 0"

「Total execution time」(合計実行時間)

 これは、そのSQLステートメントのすべての実行についての合計実行時間です。この値を実行回数で割ると、平均実行時間が得られます。ステートメントの平均実行時間が非常に長い場合は、表スキャンまたはロック待機状態(あるいはその両方)が原因かもしれません。また、索引スキャンおよびページ・フェッチによる大量の入出力も原因として考えられます。多くの場合、索引を使用することで、表スキャンとロック待機の両方を避けることができます。ロックはコミット時に解放されるため、頻繁にコミットするように心掛けると、ロック待機の問題を改善できます。

UNIX:
grep -n " Total execution time" snap.out | grep -v "= 0.0" | sort -k 5,5rn | more

Windows:
findstr /C:" Total execution time" snap.out | findstr /V /C:"= 0.0" |sort /R

「Statement text」(ステートメント・テキスト)

 SQLステートメントのテキストが表示されます。WHERE文節の述部の値だけが異なるステートメントが繰り返し使われている場合は、パラメータ・マーカーを使用することにより、ステートメントの再コンパイルを回避できます。つまり、同じパッケージを使用することで、コストのかかるPREPAREの繰り返しを避けることができます。また、このテキストを「設計アドバイザー」に入力すると、最適な索引を生成できます。

UNIX:
grep -n " Statement text" snap.out | more

Windows:
findstr /C:" Statement text" snap.out

バッファ・プールのサイズ変更

 「get snapshot for all on dbname」を使用すると、データベース上のそれぞれのバッファ・プールごとに1つのスナップショットが生成されます。リスト4は、そのようなスナップショットの例を示しています。

 バッファ・プールの効率を判断するには、BPHR(Buffer Pool Hit Ratio:バッファ・プール・ヒット率)を計算します。計算に必要な情報と特に重要な情報は、リストの中で赤字で示してあります。理想的なBPHRの値は、90%以上です。BPHRの計算式は次のとおりです。

BPHR (%) = (1 - (("Buffer pool data physical reads" + "Buffer pool index physical reads") / ("Buffer pool data logical reads" + "Buffer pool index logical reads"))) * 100

 リスト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

Fraser McArthur氏は、分散プラットフォーム(Windows/UNIX)用のDB2 UDBを開発しているIBMトロント研究所のコンサルタントです。同氏はData Management Partner Enablement organizationのメンバーであり、IBMビジネス・パートナーとともに、DB2へのアプリケーションの移行とパフォーマンス・チューニングに取り組んでいます。また同氏は、DB2管理とアプリケーション開発の両方におけるDB2 Certified Solutions Expertです。



前のページへ 1|2       

Copyright © ITmedia, Inc. All Rights Reserved.

編集部からのお知らせ

6月16日にフォーマット統一のため利用規約を変更します

RSSについて

アイティメディアIDについて

メールマガジン登録

@ITのメールマガジンは、 もちろん、すべて無料です。ぜひメールマガジンをご購読ください。