管理の手引き


ベンチマーク・テストの準備

パフォーマンス・ベンチマークを開始する前に、 アプリケーションのデータベースの論理設計が完了していなければなりません。 表、視点、および索引を設定し、データを入れておく必要があります。 表を正規化し、アプリケーション・パッケージをバインドし、 表に実データを入れてください。

データベースの最終的な物理設計を決めておいてください。 データベース・マネージャーのオブジェクトを、それらの最終的なディスク位置に入れ、 ログ・ファイルのサイズを設定し、作業ファイルとバックアップの位置を決め、 さらにバックアップ手順をテストするようにします。 さらに、パッケージを調べて、 可能な場合には行ブロック化などのパフォーマンス・オプションを使用可能にします。

アプリケーションのプログラミングと単体テストの中で、 ベンチマーク・プログラムを作成できるような段階に達していなければなりません (次の部分を参照)。 アプリケーションの実際上の限界はベンチマーク・テスト時に分かりますが、 ここで説明するベンチマークの目的はパフォーマンスを測定することであり、 障害や異常終了を検出することではありません。

ベンチマーク・テスト・プログラムは、 最終的な実動環境を可能な限り正確に表す状態で実行する必要があります。 ベンチマークは、同じメモリー構成、 同じディスク構成の同じモデル・サーバー上で実行するのが理想的です。 最終的にアプリケーションに、たくさんのユーザーと大量のデータが関係してくる場合、 このことは特に重要になります。 ベンチマークで直接使用するオペレーティング・システム自体および通信機能またはファイル機能も、 やはり調整済みでなければなりません。

実動サイズのデータベースでベンチマークを行うことも重要です。 個々の SQL ステートメントが返すデータは、 実動で実施されるのと同じ量で、 同じ程度に分類されるものでなければなりません。 この規則に従うなら、 アプリケーションのメモリー要件が典型的なものになります。

ベンチマークの対象の SQL ステートメントのタイプは、 典型的最悪のケース のいずれかです。 これらは以下で説明します。

典型的な SQL
典型的な SQL には、 ベンチマークの対象のアプリケーションの一般的操作で実行されるステートメントが含まれます。 選択するステートメントは、アプリケーションの性質によって異なります。 たとえば、データ入力アプリケーションでは INSERT ステートメントをテストしますが、 銀行業務トランザクションでは、FETCH、UPDATE、 およびいくつかの INSERT をテストします。 実行の頻度および選択されたステートメントによって処理されるデータの量は、 標準的とみなされるものでなければなりません。 量が多過ぎると、典型的な SQL ステートメントであっても、 最悪のケース のカテゴリーに入るものとみなされます。

最悪のケースの SQL
このカテゴリーに該当するステートメントには、次のものがあります。


[ ページのトップ | 前ページ | 次ページ | 目次 | 索引 ]