I/O 関係を診断してみて （272ページ 参照）、I/O 負荷が高くないにもかかわらず、パフォーマンス が悪いときには、以下の I/O 以外の諸点を診断したほうがよい。

　　（1） バッファ の使用状態 （refresh 回数）
　　（2） ロー・レベル・インデックス の split 状態
　　（3） データ 圧縮 （compress） の有無

　市販されている データベース は、それぞれ、独自の バッファ 法 （buffering） を使っているので、バッファ 法を一般論として述べることはできない。したがって、DBA は、自らが担当している データベース の バッファ 法を熟知されたい。注意してほしい点は、バッファ を多く割り当てるということが、かならずしも、高 パフォーマンス の実現に直結する訳ではない、という点である。過剰な （too much） バッファ は パフォーマンス を逆に低下する点に注意されたい。
　たとえば、小生の担当した チューニング では、ベンダー が割り当てた データ・バッファ 数を 50％ にしたら──ベンダー が割り当てた バッファ 数は、ユーザ 数から判断して、過剰な バッファ であると小生は判断して バッファ 数を修正したのだが──、3倍の パフォーマンス になった。適切な バッファ 数は、同時 （concurrent） アクセス の タスク 数を考慮しながら割り当てなければならない。

　バッファ の再利用が低ければ、バッファ が効率的に使用されていない。
　たとえば、バッファ が、1回、利用されて リフレッシュ （refresh） されるようなら、非効率である。1回から 5回くらいまでの リフレッシュ 回数を モニタリング すれば、バッファ 再利用の効率性を判断できる。効率的な バッファ 利用は、一般的に言うなら、1回の リフレッシュ 回数から 5回の リフレッシュ 回数まで順次逓減的な傾向を示すのが普通である。
　バッファ の再利用が非効率なら、スペース 管理 （space-management、248ページ 参照） および データ の native-sequence を再考したほうがよい。

　（indexing の） B ツリー 構造では、low-level-index の split が多ければ、high-level-index 再編成されて、パフォーマンス が低下する。また、データ 圧縮の負荷が高いなら、パフォーマンス は低下する。
　I/O 関係や バッファ 使用状態のなかに問題点がないにもかかわらず、パフォーマンス が悪いなら、low-level-index の split 状態や データ の圧縮有無を調べたほうがよい。

　以上の諸点のなかに問題点がなければ、チャネル の状態 （priority および busy 状態）、ディスク の アーム 稼働状態 （busy状態） および データセット の割り当てを調べる。

　
　I/O 以外の モニタリング のなかで問題点を捕捉できなかったなら、課金情報を採取して、以下の情報を コマンド 単位に追跡する。

　　（1） 論理 I/O 回数 （プログラム が出した I/O 回数）
　　（2） 物理 I/O 回数 （EXCP）
　　（3） run-time （あるいは、CPU-time）
　　（4） elapse-time