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

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

　（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)