2003年12月16日 モニタリング と チューニング (I/O 関係) >> 目次 (作成日順)


 
レコード・アット・ア・タイム 法の パフォーマンス 診断

 レコード・アット・ア・タイム 法の パフォーマンス を診断するには、統計情報から以下の数値を入手する。

 (1) リクエスト 総数
 (2) 1次排他制御の リクエスト 回数
 (3) 1次排他制御の衝突 (conflict) 回数
 (4) 先読み (READ-AHEAD) の I/O 回数
 (5) 2次排他制御の衝突回数

[ 参考 ]
 排他制御には、1次排他制御と 2次排他制御があるが、1次排他制御は更新の際に リクエスト される排他制御のことをいい、2次排他制御は、ロールバック あるいは トランザクション・バックアウト の際に リクエスト される排他制御である。

 以上の統計情報を使って、I/O 関係の パフォーマンス 計測として、以下の診断をする。

 (1) 「1次排他制御の衝突回数」 ÷ 「1次排他制御の リクエスト 回数」
 (2) 「先読みの I/O 回数」 ÷ 「リクエスト 総数」
 (3) 「2次排他制御の衝突回数」 ÷ 「1次排他制御の リクエスト 回数」

 まず、(1) の値が 0.05 以上であれば、排他制御が効率的ではない (負荷が高い)。言い換えれば、ジョブ が、過度の 「待ち (wait) 状態」 に陥っている。その原因として、プログラム の設計 ミス と テーブル (ファイル) の設計 ミス が考えられる。プログラム の設計 ミス というのは、同一の テーブル を更新する アルゴリズム が 1つの プログラム として集成されていなければならないはずが、複数の プログラム として拡散されてしまって、排他制御が衝突している状態である。テーブル の設計 ミス というのは、本来、べつべつの テーブル であるはずが、1つの テーブル としてまとめられて非正規形になっていて、排他制御が衝突している状態をいう。

 (2) の値が 0.5 以上であれば、シーケンシャル READ (順次読み) 用の バッファ (SEQBUFS) が少ない。SEQBUFS は、ダブル・バッファリング を使っているので、バッファ を拡張するには、偶数の倍数でなければならない。たとえば、SEQBUFS が 「2」 であれば、(2 の倍数として) 「4」 とか 「8」 というふうに拡張する。
 ただ、SEQBUFS は、少々、拡張しても、目立った改善を得ることがむずかしい。たとえば、SEQBUFS を 「8」 や 「16」 にしても、目立った パフォーマンス の改善にはならない、と思う。「32」 くらいにしなければ際立った改善にならない。しかも、「32」のような高い数値にすれば、CPU が、ときには、100 % を超える負荷を示す。したがって、SEQBUFS を拡張することを お薦めできない。そこで、「INDEX-only」 を使って、leaf を GETNEXT するようにすればよい。

 (3) の値が 0.25 以上であれば、チェックポイント の頻度が少ない (チェックポイント の間隔が長すぎる)。
 したがって、チェックポイント の間隔を短くすればよい。

 
セット・アット・ア・タイム 法の パフォーマンス 診断

 「INDEX-only」 を使っていれば、セット・アット・ア・タイム 法の パフォーマンス 診断は論点にはならない。ただし、「INDEX-only」 では、つねに、execution-plan を確認して、optimizer が table-scan しないように監視してほしい。

 セット・アット・ア・タイム 法の パフォーマンス は、以下の情報を入手して診断する。

 (1) traversal table (テンポラリー・インデックス) の生成状態
 (2) 多用されている column(s)

 traversal table (テンポラリー・インデックス) は、CBS や order-by が リクエスト されたら生成される。
 indexing の対象になっていない column(s) が、CBS や order-by のなかに、たびたび、使われているなら、インデックス として定義すれば良い。





  << もどる HOME すすむ >>
  ベーシックス