ログオンは非常に単純です。新しいユーザー/セッションがシステムにログオンした回数です。通常、1 秒あたりのログオン数は非常に遅い操作であるため、望ましくありません。もしそうなら、おそらく接続プーリングを検討する必要があります。
並べ替え - 多くの場合、データを並べ替えます (日付、アルファベット順)。小さなデータ セットは、メモリ内で並べ替えることができます。より大きなものはディスクに流出する可能性があり、これは遅くなります。メモリ内ですべての並べ替えを行っている場合、それは問題を示唆していません。
実行 - SQL は通常、PARSE、BIND、EXECUTE、FETCH を通過します。実行ごとに複数のフェッチを行うことができます (最初の 10 行をフェッチし、次の 10 行をフェッチするなど)。同様に、一部の SQL にはフェッチ (挿入など) がありません。トランザクションは多数の SQL で構成されます。トランザクションごとに 20 ~ 30 の SQL がある場合、ある程度の複雑さが得られます。すべてのステートメントが、それ自体が独立したトランザクションであるとは限りません。1 秒あたりの実行数は、より基本的なものです。私の締めくくりのコメントを参照してください。
% SQL with execution > 1 - 解析ごとに複数のバインドと実行を行うことができます (解析にはコストがかかる可能性があるため、これは良いことです)。ほとんどの SQL は複数回実行されます。
バッファ キャッシュ - データ ブロックのコピー用のメモリの量。サーバーのメモリに依存するため、「良い」または「悪い」というものはありません。
ロールバック - トランザクションごとに 0.2 は....奇数です。トランザクションの 20% がコミットされるのではなく、ロールバックされることを示唆しています。心配する必要はないかもしれませんが、戻るボタンやキャンセル ボタンが機能するだけかもしれません。ロールバックの強制に関して多くのエラーがスローされない限り、これはデータベースの問題ではなく、アプリケーションの動作方法にすぎません。
Buffer Hit % - ディスクに移動する必要なくメモリから直接取得されるデータ ブロック読み取りの割合。メモリからの読み取りはディスクよりも高速であるため、高いほど「適切」です (特に OLTP アプリの場合 - データ ウェアハウスは通常、メモリに収まりきらないほど多くのデータを処理します)。しかし、比率に興奮しないでください。物理 IO (ディスクからの読み取り) を減らすことができれば問題ありませんが、比率を上げるためだけにメモリ内のブロックから追加の読み取りを生成してもメリットはありません。
共有プール サイズ - 繰り返しますが、これはメモリの測定値です。
================================================== ====================== 最終的に、これらのどれもデータベースのパフォーマンスを測定するのに最適ではありません。重要なのは、アプリケーションのユーザー (または開発者や管理者) が、自分のプログラムがパフォーマンス仕様を満たしている、または満たしていないと言っているかどうかです。
1 秒あたりの実行数は重要な指標ですが、必要なワークロードに対してのみです。ユーザーが 1 秒あたり 50 回の実行を希望しているのに 20 回しか実行しておらず、結果として残業している場合は、問題があります。彼らが 1 秒間に 10 回だけ行う必要があり、YouTube で半日を過ごす場合は、問題ありません。
同様に、その測定が就業日の 8 時間の場合、全員が 16 時間家にいる 24 時間をカバーする場合は、まったく異なる話になる可能性があります。