TOPサーバ構築・運用> カタログ・キャッシュ
Linux+DB2
Linux+DB2のパフォーマンスチューニング

第9回:稼動情報からボトルネックを探し出す
著者:日本アイ・ビー・エム  中坪 宏明   2007/1/10
前のページ  1  2  3  4
カタログ・キャッシュ

   データベース・スナップショットにて、以下の情報を得ることができます。
  • カタログ・キャッシュ検索(累積値)
  • カタログ・キャッシュ挿入(累積値)
  • カタログ・キャッシュ・オーバーフロー(累積値)
  • カタログ・キャッシュの最高水準点(水準値)

表12:取得できるカタログ・キャッシュに関する情報

   ヒット率は、次の式で計算できます。

カタログ・キャッシュのヒット率の計算式
図3:カタログ・キャッシュのヒット率の計算式

   SQLをコンパイル(最適化)する際に利用する、統計情報を読み出すのに時間がかからないように、こののヒット率も高く保つようにします。なお、カタログ表スペースは、SMS表スペースが推奨であるため、通常は、カタログ情報は、Linuxのファイル・キャッシュに保存されていて、ここの値が小さくても問題ないことになります。Linuxファイル・キャッシュを利用しないケースで、考慮が必要となります。


ロック

   データベース・スナップショットにて、ロックに関して、以下の情報を取得できます。

  • ロック保留(現在値、保持されたロック数のこと)
  • ロック待機(現在値)
  • ロック上で待機される時間データベース(ミリ秒、累積値)
  • 使用中のロック・リスト・メモリ(バイト、現在値)
  • デッドロック検出(累積値)
  • ロック・エスカレーション(累積値)
  • 排他ロック・エスカレーション(累積値)
  • ロック上で待機中のエージェント(現在値)
  • ロック・タイムアウト(累積値)

表13:取得できるロックに関する情報

   ロック・エスカレーションが起きていないこと、ロック待ち数・時間が多くないことを確認します。ロック・エスカレーションが起きている場合には、データベース構成パラメータのLOCKLIST, MAXLOCKS パラメータを調整します。なお、特に、LOCKLISTについては、デフォルト値では利用しないでください。どの値にして良いかよくわからない場合には、ひとまず、5120(=20MB)としてください。なお、このあたりは、V9で大きく改善されております。詳しくは、後続のDB2 9のところで説明予定です。


CPU時間

   アプリケーション・スナップショットでは、以下の情報が得ることができます。

  • エージェントによって使用される合計ユーザCPU時間(秒、累積値)
  • エージェントによって使用される合計システムCPU時間(秒、累積値)

表14:取得できるエージェントに関するCPU情報

   動的SQLスナップショットでは、以下の情報を得ることができます。

  • 合計実行時間(sec.ms、累積値)
  • ユーザCPU時間の合計(sec.ms、累積値)
  • システムCPU時間の合計(sec.ms、累積値)

表15:動的スナップショットで取得できるCPUの情報

   CPU時間や実行時間を多く消費している、接続およびSQLを見つけて、チューニングを進めて行きます。なお、動的SQLスナップショットでは、実行回数で割って、1つのSQLの実行ごとに評価するという方法もあります。


まとめ

   今回は、DB2の主な稼動情報の内容、確認ポイント、および対応方法について紹介しました。次回は、Linux環境でのDB2チューニングについて説明する予定です。

前のページ  1  2  3  4


日本アイ・ビー・エム  中坪 宏明
著者プロフィール
日本アイ・ビー・エム株式会社  中坪 宏明
インフォメーション・マネジメント・テクニカル・セールス所属
DB2の技術支援(設計支援、パフォーマンス・チューニング、障害解決支援、案件サポートなど)を10年以上実施している。Linuxをはじめとして各オペレーティングシステムおよびハードウェアとの組み合わせでの機能検証および性能検証も実施している。


INDEX
第9回:稼動情報からボトルネックを探し出す
  主な稼動情報の取得
  バッファプール〜先読み情報
  SQL実行数
カタログ・キャッシュ