パフォーマンス・ベンチマークを開始する前に、 アプリケーションのデータベースの論理設計が完了していなければなりません。 表、視点、および索引を設定し、データを入れておく必要があります。 表を正規化し、アプリケーション・パッケージをバインドし、 表に実データを入れてください。
データベースの最終的な物理設計を決めておいてください。 データベース・マネージャーのオブジェクトを、それらの最終的なディスク位置に入れ、 ログ・ファイルのサイズを設定し、作業ファイルとバックアップの位置を決め、 さらにバックアップ手順をテストするようにします。 さらに、パッケージを調べて、 可能な場合には行ブロック化などのパフォーマンス・オプションを使用可能にします。
アプリケーションのプログラミングと単体テストの中で、 ベンチマーク・プログラムを作成できるような段階に達していなければなりません (次の部分を参照)。 アプリケーションの実際上の限界はベンチマーク・テスト時に分かりますが、 ここで説明するベンチマークの目的はパフォーマンスを測定することであり、 障害や異常終了を検出することではありません。
ベンチマーク・テスト・プログラムは、 最終的な実動環境を可能な限り正確に表す状態で実行する必要があります。 ベンチマークは、同じメモリー構成、 同じディスク構成の同じモデル・サーバー上で実行するのが理想的です。 最終的にアプリケーションに、たくさんのユーザーと大量のデータが関係してくる場合、 このことは特に重要になります。 ベンチマークで直接使用するオペレーティング・システム自体および通信機能またはファイル機能も、 やはり調整済みでなければなりません。
実動サイズのデータベースでベンチマークを行うことも重要です。 個々の SQL ステートメントが返すデータは、 実動で実施されるのと同じ量で、 同じ程度に分類されるものでなければなりません。 この規則に従うなら、 アプリケーションのメモリー要件が典型的なものになります。
ベンチマークの対象の SQL ステートメントのタイプは、 典型的 か最悪のケース のいずれかです。 これらは以下で説明します。
たとえば、ある顧客から電話がかかったときに実行されるアプリケーションとそのステートメントとは、 顧客を待たせている間に、顧客の情報の検索や更新を行わなければなりません。
たとえば、口座の異なる種類すべての月ごとの活動を行うための組み合わされた顧客ステートメントを生成する銀行業務アプリケーション。 共通表には顧客の住所と口座番号のリストを入れ、 他のいくつかの表は結合して、 すべての必要な口座トランザクション情報を処理および統合するようにしなければなりません。 1 つの口座に必要な作業量に、 同じ期間内に処理しなければならない何千もの口座の数を乗算し、 潜在的な時間の節約を考慮すると、パフォーマンス要件が導き出されます。
たとえば、その日のうちに処理されなければならない会計作業のリストを生成するアプリケーション。 このアプリケーションが開始されると、 最初の主要 SQL ステートメントにより 7 とおりの結合が生成され、 それらによりこのアプリケーションのユーザーが担当する全会計の大きなリストが作成されます。 このステートメントは 1 日のうち数回実行されるだけですが、 正しく調整されていないと実行に数分間もかかってしまいます。