最近リリースされた10000のユーザー分析アプリケーションがありますが、トランザクションが多すぎるためにパフォーマンスの問題が発生しています。パフォーマンスを向上させるためにアプリケーションでSQLの多くを書き直すこととは別に、メモリなどにボリュームとtweeksを追加するトップダウンアプローチも採用しています。Oracleスペシャリストは、サーバーを2つのボリュームを持つ単一のテーブルスペースから2つのテーブルスペースに再設計しました。インデックスが独自のボリュームとテーブルスペースを持つ4つのボリュームを使用します。各ボリュームは個別のディスクアレイであるため、IOをめぐって競合することはありません。
私たちはこの開発環境の変更を実行し、受け入れに移行しようとしていますが、変更の支払いを行う前に、ビジネスは測定可能な利益を見たいと考えています。
AWRレポートのどこで、変更が実行される前後のそのようなデータを測定するために比較を行うことができますか？
AWRには、IOStatsと呼ばれるこのセクションがあります。不合理ではありませんが、これはIOアクティビティの統計を報告する場所です。そのセクション内には、各テーブルスペースの数値があります。これらのレポートは、ターゲットデータベースに対して実行する必要があります。理想的には、いくつかの異なる実行が必要であり、各実行の長さは20分以内です。実行時間が長いほど、平均の法則が得られる数値から意味を失う可能性が高くなります。
したがって、原則は次のとおりです。このレポートを実行してベンチマークを取得します。次に、変更を展開してレポートを再実行します。さまざまな列の違いは、変更によるパフォーマンス上の利点です。本当に、リクエストと1秒あたりのデータが増え、平均時間と待機時間が減りたいと思うでしょう。
これらの図をより説得力のあるものにするには、テストの前後で同じワークロードを実行する必要があります。ここで、RealApplicationTestingのようなものが実際に登場します。