JP6110785B2 - アプリケーション開発段階でクエリにかかる経過応答時間を予測するシステム及び方法 - Google Patents

Description

本発明は、全体的に、クエリにかかる経過応答時間を予測するシステム及び方法に関する。詳細には、本システム及び方法は、アプリケーション開発段階でクエリにかかるディスクアクセスの応答時間を予測するシステム及び方法に関する。

データベースアプリケーションの開発環境において、アプリケーション開発段階で最も重要な要因は、アプリケーションのテスト中にクエリにかかる検索時間である。アプリケーションを開発した後、様々なデータベースに対して必要な結果すべてを調査するテストをする。クエリの実行及びその応答時間は、データベースのサイズに極めて大きく左右される。データベースのサイズは、むしろクエリの応答時間に影響を及ぼす最重要要因の１つである。その上、クエリの応答時間は、データベースのサイズが大きくなるにつれて劇的に影響を受ける。そのため、データベースのサイズが大きい場合にクエリの経過応答時間を予測、調査することが極めて重要である。データベースのサイズは、アプリケーションの性能に不都合な影響を及ぼすことがある。

アプリケーション開発段階でのクエリ経過応答時間、及び様々なサイズのデータベースに対してかかるクエリ経過応答時間に関する対策を提供するために、様々な負荷生成ツールが市販されている。最も広く用いられている手法は、データベースの一部を使用してアプリケーションをテストするものである。多くの場合、問題に関わる資源は、テストプロセスにも影響を及ぼす。テストに必要な膨大な量のデータ及びレコードを格納するためには、大きく高性能のストレージサーバが必要である。このような膨大なレコードの場合、データの負荷も直面することの多い問題の１つである。

本発明は、追加の資源を消費することなく、より短時間でテストを実行できる対策を提供することを課題とする。

ここでは、アプリケーション開発段階でクエリにかかる経過応答時間を予測するためのシステム及び方法に関する局面を紹介し、この局面を以下の説明でさらに詳細に記載する。この概要は、特許請求する主題の本質的な特徴を特定することを意図するものではなく、特許請求する主題の範囲を決定または限定するために使用することを意図するものでもない。

アプリケーション開発段階でクエリにかかる経過応答時間を予測するためのシステムを開示する。このシステムは、プロセッサ、及びこのプロセッサに接続するメモリを備えている。プロセッサは、メモリに格納された複数のモジュールを実行することができる。複数のモジュールは、データベースに対してクエリを実行するように構成されたクエリ実行モジュールと、エミュレートしたデータベースを得るためにデータベースをエミュレートするように構成されたエミュレーションモジュールと、クエリによりデータベースへアクセスするモードに基づいてクエリを分類するように構成された分類モジュールと、小サイズのデータベースに対して１つ以上のパラメータに沿ったアクセスパターンを決定するように構成されたパラメータ決定モジュールとを含む。アクセスパターン及びパラメータは、データベースのサイズに影響を受けやすい。モジュールは、さらに、アクセスパターン及び１つ以上のパラメータに対して特殊分類技術を用いることによって、エミュレートしたデータベースに対してクエリにかかる入出力アクセス時間を計算するように構成されるとともに、この入出力アクセス時間を用いてデータベースのサイズを変更することによって、エミュレートしたデータベースに対するクエリの経過応答時間を算出するように構成された計算モジュールを備えている。

アプリケーション開発段階でクエリにかかる経過応答時間を予測する方法を開示する。本方法は、クエリをデータベースに対して実行することと、エミュレートしたデータベースを得るためにデータベースをエミュレートすることと、このように実行したクエリを、クエリによりデータベースへアクセスするモードに基づいて分類することと、データベースのサイズに対して１つ以上のパラメータに沿ったアクセスパターンを決定することとを含む。アクセスパターン及びパラメータは、データベースのサイズに影響を受けやすい。本方法は、さらに、アクセスパターン及び１つ以上のパラメータに対して特殊分類技術を用いることによって、エミュレートしたデータベースに対するクエリにかかる入出力アクセス時間を計算することと、この入出力アクセス時間を用いてデータベースのサイズを変更することによって、クエリにかかる経過応答時間を算出することとを含む。この場合、１つ以上のパラメータに沿ったアクセスパターンの実行、分類、決定、経過応答時間のエミュレート、計算及び算出は、プロセッサによって実施される。

アプリケーション開発段階でクエリにかかる経過応答時間を予測するためのコンピュータプログラムを組み入れたコンピュータプログラム製品を開示する。本コンピュータプログラム製品は、小サイズのデータベースに対してクエリを実行するプログラムコードと、エミュレートしたデータベースを得るためにデータベースをエミュレートするためのプログラムコードと、このように実行したクエリを、クエリによりデータベースへアクセスするモードに基づいて分類するプログラムコードと、小サイズのデータベースに対して１つ以上のパラメータに沿ったアクセスパターンを決定するプログラムコードとを含み、この場合、アクセスパターン及びパラメータは、データベースのサイズに影響を受けやすい。コンピュータプログラム製品は、さらに、アクセスパターン及び１つ以上のパラメータに対して特殊分類技術を用いることによって、エミュレートしたデータベースへの入出力アクセス時間を計算するプログラムコードと、この入出力アクセス時間を用いてデータベースのサイズを変更することによって、クエリにかかる経過応答時間を算出するプログラムコードとを備えている。

本発明の実施形態によるシステムのネットワーク実装を示す説明図 本発明の実施形態によるシステムに搭載されている様々なモジュールを示す説明図 本発明の実施形態による、クエリの経過応答時間を予測するための段階的な方法論を示すフローチャート 本発明の例示的な実施形態による、フルテーブルスキャンクエリにかかる経過応答時間を示すグラフ 本発明の例示的な実施形態による、高速インデックススキャン及び主インデックススキャンクエリにかかる経過応答時間を示すグラフ 本発明の例示的な実施形態による、ノンユニークインデックススキャンクエリにかかる経過応答時間を示すグラフ

添付の図面を参照して詳細な説明を記載する。図面では、符号の一番左の数字（２桁の場合もある）は、その符号が最初に現れる図面を特定するものである。図面全体を通して、同じ符号は同様の特徴及び構成要素を指すものとして使用している。

アプリケーション開発段階でクエリにかかる経過応答時間を予測するためのシステム、方法及びコンピュータプログラム製品を開示する。まずクエリを実行し、データベースをエミュレートする。次に、クエリによりデータベースへアクセスするモードに基づいて、クエリを分類する。クエリを分類した後、クエリによるデータベースへのアクセスパターンを、１つ以上のパラメータに沿って決定する。アクセスパターン及びパラメータは、データベースのサイズ及びクエリの種類に影響を受けやすく、データベースのサイズが大きくなるにつれて、クエリの検索サイズに影響を及ぼす。エミュレートしたデータベースを得るために、アクセスパターン及び１つ以上のパラメータに対して分類アクセス技術を適用することによって、エミュレートしたデータベースに対する入出力アクセス時間を計算して、その後このエミュレートしたデータベースに対するクエリ経過応答時間を算出する。

アプリケーション開発段階でクエリにかかる経過応答時間を予測するためのシステム及び方法について記載した局面は、任意数の異なるコンピューティングシステム、環境、及び／または構成に実装できるが、以下の例示的なシステムの背景で実施形態を説明する。

ここで、図１を参照すると、本主題の実施形態による、経過応答時間を予測するためのシステム１０２のネットワーク実装１００が示されている。１つの実施形態では、システム１０２は、本番データベースをエミュレートすることによって、本番データベースに対するクエリの経過応答時間の予測を実現する。小サイズのデータベースを用いて、クエリによるデータベースへのアクセスパターン及び１つ以上のパラメータのような、様々な統計パラメータを算出する。次に、アクセスパターン及びパラメータを用いて本番データベースをエミュレートし、クエリの応答時間を計算する。

本主題は、システム１０２をサーバ上のアプリケーションとして実装することを考えて説明しているが、システム１０２を、ラップトップコンピュータ、デスクトップコンピュータ、ノートブックコンピュータ、ワークステーション、メインフレームコンピュータ、サーバ、ネットワークサーバなど、多様なコンピューティングシステムに実装してもよいことは理解されるであろう。システム１０２には、１つ以上のユーザデバイス１０４−１、１０４−２…１０４−Ｎ（以下、総称してユーザデバイス１０４と表記）を介して、またはユーザデバイス１０４に搭載されているアプリケーションを介して、複数のユーザがアクセスできることは理解されるであろう。ユーザデバイス１０４の例には、ポータブルコンピュータ、携帯情報端末、ハンドヘルドデバイス、ワークステーションなどがあってよいが、これに限定されない。ユーザデバイス１０４は、ネットワーク１０６を介してシステム１０２に通信接続されている。

１つの実装では、ネットワーク１０６は、無線ネットワーク、有線ネットワークまたはこれを組み合わせたものとすることができる。ネットワーク１０６は、イントラネット、ローカルエリアネットワーク（ＬＡＮ）、ワイドエリアネットワーク（ＷＡＮ）、インターネットなど、異なる種類のネットワークの１つとして実装することができる。ネットワーク１０６は、専用ネットワークまたは共有ネットワークのいずれであってもよい。共有ネットワークは、異なる種類のネットワークの集まりであり、多様なプロトコル、例えば、ハイパーテキストトランスファープロトコル（ＨＴＴＰ）、トランスミッションコントロールプロトコル／インターネットプロトコル（ＴＣＰ／ＩＰ）、ワイヤレスアプリケーションプロトコル（ＷＡＰ）などを用いて互いに通信する。さらにネットワーク１０６は、ルータ、ブリッジ、サーバ、コンピューティングデバイス、ストレージデバイスなどの多様なネットワークデバイスを備えることができる。

次に図２を参照すると、本主題の実施形態によるシステム１０２が示されている。１つの実施形態では、システム１０２は、少なくとも１つのプロセッサ２０２、入力／出力（Ｉ／Ｏ）インターフェース２０４、及びメモリ２０６を備えることができる。少なくとも１つのプロセッサ２０２は、１つ以上のマイクロプロセッサ、マイクロコンピュータ、マイクロコントローラ、デジタルシグナルプロセッサ、中央処理装置、ステートマシン、論理回路、及び／または動作命令に基づいて信号を制御する任意のデバイスとして実装することができる。その他の能力のうち、少なくとも１つのプロセッサ２０２は、メモリ２０６に格納されているコンピュータ可読命令をフェッチして実行するように構成される。

Ｉ／Ｏインターフェース２０４は、多様なソフトウェアインターフェース及びハードウェアインターフェース、例えば、ウェブインターフェース、グラフィカルユーザインタフェースなどを備えることができる。Ｉ／Ｏインターフェース２０４によって、システム１０２が直接またはクライアントデバイス１０４を介してユーザと相互作用することができる。さらに、Ｉ／Ｏインターフェース２０４によって、システム１０２が、ウェブサーバ及び外部データサーバ（図示せず）など、その他のコンピューティングデバイスと通信することができる。Ｉ／Ｏインターフェース２０４によって、例えば、ＬＡＮ、ケーブルなどの有線ネットワーク、及びＷＬＡＮ、セルラー、または衛星などの無線ネットワークを含む、多岐にわたるネットワーク及びプロトコルタイプ内での複数の通信を容易にすることができる。Ｉ／Ｏインターフェース２０４は、多数のデバイスを相互に接続したり、別のサーバに接続したりするための１つ以上のポートを備えることができる。

メモリ２０６は、先行技術で公知の任意のコンピュータ可読媒体を備えることができ、これには例えば、スタティック・ランダムアクセスメモリ（ＳＲＡＭ）及びダイナミックランダムアクセスメモリ（ＤＲＡＭ）などの揮発メモリ、ならびに／または読み出し専用メモリ（ＲＯＭ）、消去可能かつプログラム可能なＲＯＭ、フラッシュメモリ、ハードディスク、光ディスク、及び磁気テープなどの不揮発メモリがある。メモリ２０６は、モジュール２０８及びデータ２１０を備えることができる。

モジュール２０８は、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造など、特定のタスクを遂行するか、あるいは特定の抽象データ型を実装するものを備えることができる。１つの実装では、モジュール２０８は、クエリ実行モジュール２１２、エミュレーションモジュール２１４、分類モジュール２１６、パラメータ決定モジュール２１８、及び計算モジュール２２０ならびにその他のモジュール２１９を備えることができる。その他のモジュール２１９は、システム１０２のアプリケーション及び機能を補足するプログラムまたは符号化された命令を備えることができる。

データ２１０は、とりわけ、１つ以上のモジュール２０８が処理し、受信し、生成したデータを格納するためのリポジトリとしての役割を果たす。データ２１０（データベースエンジン）は、データベース２２２、本番データベース２２４（実際に作成されたもの）、小サイズのデータベース２２６及びその他のデータ１３０も備えることができる。その他のデータ１３０は、その他のモジュール２１９で１つ以上のモジュールを実行することで生成されたデータを備えることができる。

一実施形態によれば、システム１０２は、ウェブサーバでのクエリ処理時間が原因でクエリ結果に生じることがある時間の遅延を回避するために、データベース２２２のサーバにホストされる。

クエリは、クエリ実行モジュール２１２を用いて、まず小サイズのデータベース２２６に対して実行される。小サイズのデータベースに対してクエリを実行する目的は、本番データベース２２４をエミュレートできるように、データベースの統計項目（小サイズのデータベース２２６）を収集することである。

Ｏｒａｃｌｅなどのデータベースサーバは、クエリを発行して結果を得るためにＳＱＬクエリ及びＳＱＬクライアントを実行する２つの処理と、クエリを構文解析し、ディスクからデータをフェッチし、データを処理し、これをクライアントに送り返すためのクエリサーバとを有する。クエリの経過応答時間は、処理の際にクエリサーバで要する時間、及びクライアントに対してデータを出力する時間を含むものとする。

小サイズのデータベースに対してマイクロベンチマークツールを用いると、フルテーブルスキャンクエリの場合、クエリサーバは、連続するシステム読み出し要求のシーケンスとしてテーブルからデータにアクセスし、各々のサイズはデータベースブロックの倍数であることがわかる。各システムの読み出しの後、クエリサーバは、フィルタ条件の適用や、これをＳＱＬクライアントに対して準備するなどのデータ処理を行う。データの準備には、データを初期化すること、及びこのデータを複数のパケットに分割し、それぞれのサイズを、クライアントで規定された受信バッファサイズと同じにすることが含まれる。準備したデータパケットをクライアントに送信し、その後にクライアントからの承認を待ってから、次のパケットを送信する。さらに、最初のデータパケットを送信するまでに、クエリサーバで膨大な時間が費やされるが（この時間を「データ準備時間」と称する）、承認を受信すると即座に連続データパケットが送信されることがわかる。次のシステム読み出し要求は、全パケットがクライアントに送信されるまで発行されない。

インデックス（Ｂ木と仮定）を用いてデータにアクセスする場合、クエリプロセッサは、葉ブロックにヒットするまでインデックス木を探索する。葉ノード内のデータポインタを使用して、適格な葉ブロック及びマッチするデータブロックすべてにアクセスする。アクセスしたデータブロックから、要求された行のみを準備し、クライアントに送信する。この場合、各々のシステム読み出し要求またはインデックス木、葉ノード及びデータノードを含むディスクアクセスは、データベースブロックサイズのものである。したがって、インデックススキャンクエリにかかるＥＲＴ（Ｅｌａｐｓｅｄ Ｒｅｓｐｏｎｓｅ Ｔｉｍｅ、経過応答時間）は、以下の和である。
１． インデックス木の葉ノードまで探索するのにかかる時間
２． 適格な葉ノードにアクセスするための時間
３． マッチするデータブロックすべてにアクセスするのにかかる時間
４． 各システム読み出し要求の後のデータ準備に費やされる合計時間
５． 全データパケットの送信にかかる合計時間
６． 送信したデータパケットに対するクライアントからの各承認を受信するのを待つ際に費やされる合計時間であって、この時間には、受信を承認する前にデータを初期化するのにクライアントが費やした時間を含むことができる。

第２及び第３のステップは、異なるデータアクセスパターンでインターリーブされる。葉ノードブロックへのアクセスは、本質的に連続しているが、これらのアクセスは、データブロックアクセスと共にインターリーブされる。主インデックススキャンの場合、データブロックは、各葉ノードに向けて連続的にアクセスされるが、主ではないインデックススキャンの場合は、シーケンシャルアクセスのセグメントが多数ある。

クエリ実行モジュール２１２でクエリを実行した後、エミュレーションモジュール２１４でデータベースをエミュレートする。クエリは、分類モジュール２１６を用いて分類される。この分類は、クエリによりデータベースへアクセスするモードに基づいている。テーブル内のデータには、フルテーブルスキャン、高速インデックスフルスキャン、主キーを使用するインデックスレンジスキャンまたはノンユニークキーインデックスを使用するインデックスレンジスキャンとしてのクエリによってアクセスする。クエリは、クエリ実行中にデータにアクセスする方法、及びユーザに返されるデータ量に応じて分類される。

テーブルに対するクエリは、行を順に読み出すか、あるいはインデックスを使用して行を選択して読み出し、フルテーブルスキャンの場合は前者であり、インデックススキャンの場合は後者であり、これらはそれぞれ、フルテーブルスキャンクエリ、インデックススキャンクエリと呼ばれる。インデックススキャンクエリでは、選択は、そのクエリで与えられたフィルタ条件に左右される（ＷＨＥＲＥ句）。インデックススキャンでは、主キーまたは副キーに対して、インデックスを使用することができ、副キーは、データベース内の他のテーブルの主キーであってよく、前者は主インデックススキャンクエリ、後者はノンユニークインデックススキャンクエリとそれぞれ呼ばれる。クエリの要求するデータがインデックス内にあるという特殊なインデックススキャンの場合では、全テーブルを出力する場合であってもインデックスブロックのみを読み出すことができ、これは、高速フルインデックススキャンと呼ばれる。フルテーブルスキャンクエリの場合、全テーブルブロックが読み出され、フィルタは、これが存在すれば、選択行／データを得るためにアクセス後のみに適用されるが、インデックススキャンでは、選択したデータブロックのみが読み出される。フルスキャンまたはインデックススキャンによるテーブルスキャンを行った後、フェッチしたデータは、必要に応じて集約関数を使用して処理されてから、ユーザに送信される。上記のクエリの特徴はいずれも、データベースのサイズが大きくなるにつれてクエリの応答時間に影響を及ぼす。出力データのサイズが及ぼす影響は、テーブルへのアクセス後に含まれることがある。

このように、分類モジュール２１６は、アクセスモードのみに基づいてクエリを分類する。

クエリを分類する種類を以下に説明する。

フルテーブルスキャンクエリ：フィルタ条件内の選択に関わらず、テーブルの全ブロックに全面的にアクセスする。クエリには、集約した出力として単一行を返すか、あるいはテーブルから大部分の行を返すことができる。

主インデックススキャンクエリ：テーブルの主キーに対するインデックスを使用して、フィルタ条件を満たすブロックのみにアクセスする。クエリには、主キーｓ＿ｓｕｐｐｋｅｙに対するインデックスを使用してデータにアクセスする間に、集約した出力として単一行を返すか、あるいはテーブルから大部分の行を返すことができる。

ノンユニークインデックススキャンクエリ：テーブルのノンユニーク（副）キーであって、別のテーブルの主キーであってよいキーに対するインデックスを使用して、フィルタ条件を満たすブロックのみにアクセスする。クエリには、ノンユニークキーｓ＿ｎａｔｉｏｎｋｅｙに対するインデックスを使用してデータにアクセスする間に、集約した出力として単一行を返すか、あるいはテーブルから大部分の行を返すことができる。

高速インデックススキャン：インデックススキャンの場合、インデックスブロックまたはデータブロックのいずれかからデータを出力できる。前者の場合、クエリは、テーブルブロックにアクセスする必要はなく、インデックスブロックからのみデータを出力する。

例えば、フルテーブルスキャンクエリの集約出力は、Ｓｅｌｅｃｔ ｓｕｍ（ｓ＿ａｃｃｔｂａｌ） ｆｒｏｍ ｓｕｐｐｌｉｅｒであり、フルテーブルスキャンクエリのフル出力は、Ｓｅｌｅｃｔ ＊ ｆｒｏｍ ｓｕｐｐｌｉｅｒである。一方、高速インデックススキャンクエリの集約出力は、Ｓｅｌｅｃｔ ／＊＋ｉｎｄｅｘ （ｐｋ＿ｓｕｐｐ） ＊／ ｓｕｍ（ｓ＿ｓｕｐｐｋｅｙ） ｆｒｏｍ ｓｕｐｐｌｉｅｒ ｗｈｅｒｅ ｓ＿ｓｕｐｐｋｅｙ＞３であり、インデックススキャンクエリのフル出力は、Ｓｅｌｅｃｔ ／＊＋ｉｎｄｅｘ （ｐｋ＿ｓｕｐｐ） ＊／ ｓ＿ｓｕｐｐｋｅｙ ｆｒｏｍ ｓｕｐｐｌｉｅｒ ｗｈｅｒｅ ｓ＿ｓｕｐｐｋｅｙ＞３である。

したがって、上記の例から、一度に読み出されるデータのサイズ及び１つずつ読み出されるデータブロックの相対アドレスに関して、アクセスモードは１つ１つ異なることがわかる。これをデータアクセスパターンと呼ぶ。

次に、システム１０２は、小サイズのデータベースに対して１つ以上のパラメータに沿ったアクセスパターンを決定する。アクセスパターン、パラメータ及びクエリは、データベースのサイズにも、クエリが遂行するデータアクセスの種類にも影響を受けやすく、このクエリは、本特許によって分類されるクエリの種類によって異なる。

フルテーブルスキャンでは、読み出されるデータのサイズは、６４Ｋから１ＭＢまで幅があるが、インデックススキャンでは、読み出されるデータのサイズは、常に８ｋ（データベースブロックのサイズが８Ｋであれば）である。

フルテーブルスキャンでは、相対アドレスは、事実上連続している。しかし、インデックススキャンでは、常に１つの葉ノード（ブロック）から読み出され、この葉ノードに一連のデータブロックが続き、このシーケンスがこれ以降繰り返される。葉ブロックは、互いに連続しており、データブロックの相対アドレスは、インデックススキャンの種類によって異なる。

メモリは、さらに、小サイズのデータベース２２６に対して、１つ以上のパラメータに沿ってクエリによるデータベースへのアクセスパターンを決定するように構成された、パラメータ決定モジュール２１８を格納している。このアクセスパターン及びパラメータを、データベース統計項目と呼ぶ。

アクセスパターン及び１つ以上のパラメータに対して特殊分類技術を適用して、エミュレートしたデータベースへの入出力アクセス時間を算出する。

フルテーブルスキャンクエリのための特殊分類技術

フルテーブルスキャンクエリに対する分類技術において、クエリ、テーブルスキーマが投影するテーブルサイズＳ（つまり行数と行の平均サイズ）は、入力値として供給される。その後、計算モジュール２２０は、この入力値を処理して、フルテーブルスキャンクエリに対する入出力アクセス時間を計算する。

テーブルスキャンクエリに対する分類技術の段階的な詳細内容を以下に説明する。
１．サイズが数メガバイトである小データベースを作成する。このデータベースに対してクエリを実行し、マイクロベンチマークツールを起動させて以下を計算する。
ａ．クエリサーバからクライアントに送信されたデータパケットのサイズ
ｂ．データ準備にかかった平均時間
ｃ．１つのデータパケットを送信する平均時間
ｄ．各データパケットに対する承認を受信するまでの平均待ち時間
２．テーブルサイズ「Ｓ」の倍数サイズのファイルを生成する（ＤＢファイルのサイズに合わせるため）。
３．ファイルの先頭に近い方の無作為な数を開始アドレスとする。データアクセスパターンを、読み出すデータのサイズ及び読み出す元の場所を含むシステム読み出し要求のシーケンスとして生成する。フルテーブルスキャンでは、システム読み出し要求が、前段の読み出し要求に続く場所から読み出す。
４．まず、開始アドレスでサイズ８Ｋのシステム読み出しを生成する。これに続いて、ファイルサイズが４８４Ｋ（４×６４Ｋ×５６Ｋ）よりも大きい場合、サイズ６４Ｋとサイズ５６Ｋとの対からなるシステム読み出し要求を最大４対生成する。ファイルサイズを４８４Ｋ減らす、すなわちＳ＝Ｓ−４８４Ｋにする。Ｓが１Ｍよりも大きければ、サイズ１Ｍのシステム読み出しを生成し続け、Ｓを１Ｍ減らし、Ｓが１Ｍ未満に縮小するまで減らし続ける。サイズがＳのままである最後のシステム読み出し要求を生成する。
５．大サイズ（およそ１ＭＢ以上）のシステム読み出し要求数を計算する。
６．各システム読み出し要求に対するデータパケット数を、（１．ａから得られた）データパケットのサイズで除算した読み出し要求のサイズとして計算する。

集約関数を伴うクエリの場合のように出力が一行であれば、読み出し要求は、クライアントからの送受信を間に挟むことなく１つずつ実行される。全行が集約関数を使用して一緒に処理され、ネットワークに対して１行の出力をクライアントに返す。したがって、ネットワーク時間はごくわずかである。同じように、フルテーブルスキャンに対するフィルタ条件によっても、クライアントとクエリサーバとの間のデータ通信が縮小されるため、ネットワーク時間の短縮につながる。この場合、データパケットの合計数は、線形外挿した出力データサイズをデータパケットのサイズで除算して計算することができる。

７．１．ｂ、１．ｃ及び１．ｄで明らかになった合計遅延時間を、システム読み出し要求の中に分散して入れる。

８．上記で生成したデータアクセスパターンを、ステップ２で生成したファイルに当てはめる。すると、計算モジュール２２０は、かかった合計時間を計算し、これがクエリのＩＯアクセス時間に相当する。

インデックススキャンクエリに対する特殊分類技術

インデックス（Ｂ木と仮定）を用いてデータにアクセスする場合、クエリプロセッサは、ｋｅｙ＝ｖａｌなどのフィルタ条件にマッチする葉ブロックに達するまでインデックス木を探索し、式中ｋｅｙは、インデックスが作成されたテーブルの列である。データベースサーバは、各葉ノードにアクセスした後、葉ノード内のデータポインタを使用して、すべての適格な葉ブロックに１つ１つアクセスし、マッチするデータブロックすべてにアクセスする。アクセスしたデータブロックから、要求された行のみを読み出し、処理し、準備し、クライアントに送信する。この場合、各々のシステム読み出し要求またはインデックス木、葉ノード及びデータノードを含むディスクアクセスは、データベースブロックサイズのものである。したがって、インデックススキャンクエリに対する入出力アクセス時間は、以下の和である。
１．インデックス木の葉ノードまで探索するのにかかる時間
２．適格な葉ノードにアクセスするための時間
３．マッチするデータブロックすべてにアクセスするのにかかる時間
４．データを出力するためのネットワーク伝達時間

ステップ３から得られる時間の寄与は、データベース内で行がどのように配置されるかに依存している。インデックス木の葉ノードは、ｋｅｙ値の小さい順に格納されるため、葉ブロックには順番にアクセスされる。その上、葉ブロックは、インデックス構造の一部であるため、葉ブロックへのアクセスは、行がデータブロック内でどのように配置されているかには依存していない。

データが均一に分散され、削除されることのないデータベースの場合、主インデックスがキーをアドレス指定すれば、データベースはデータブロックに順次アクセスされる。ノンユニークインデックススキャンの場合、データブロックへのアクセスは、シーケンシャルアクセスの断片としてモデル化されてよい。高速インデックススキャンの場合、葉ノードに対してのみシーケンシャルアクセスがあり、データブロックは読み出されない。

データアクセスパターンは、葉ノード数、インデックス木の高さ及びデータブロックノード数を用いて生成することができ、これらの統計項目は、データベースを用いて入手可能である。しかし、大サイズが投影された場合、そのデータベースは存在しないため、これらの統計項目は、物理的に存在する小サイズのデータベースから収集され、線形外挿されて投影サイズに合わせられる。インデックススキャンでは、データの読み出しは、データベースブロックのサイズで読み出される。したがって、異なるインデックススキャンでは、各システム読み出しに対する場所の生成が異なる。ネットワーク上でのＩＯアクセス時間は、フルテーブルスキャンに対して考察した方法と同じように計算することができる。

高速インデックススキャンクエリに対する特殊分類技術

葉ノードのみにアクセスされ、データはインデックス構造からのみ出力される。

高速インデックススキャンクエリに対する特殊分類技術では、クエリ（ｋｅｙ＜ｖａｌ，ｋｅｙ＜ｖａｌ ａｎｄ ｋｅｙ＝ｖａｌ）は、テーブルスキーマ、テーブルサイズ（つまり行数と行の平均サイズ）は、入力値として供給される。計算モジュール２２０は、この入力値を処理して入出力アクセス時間を計算する。

特殊分類技術の詳細は、以下の通りである。
１．サイズが数メガバイトの小データベースを作成する。ＤＢ特殊ツールを使用して、次のデータベース統計項目−データベースブロックサイズ（Ｂｓｉｚｅ）、インデックスを付した列の最小値（ｍｉｎ）、列の最大値（ｍａｘ）、キーごとの葉ノード数（Ｌｓｉｚｅ）及び木の高さ（Ｈｓｉｚｅ）を取得する。これらのデータベース統計項目は、得られた統計項目を線形外挿することによって、投影されたデータベースサイズＳで得られる。
２．マッチしたｋｅｙ値（ＭＫＶ）の数を、
ａ．ｋｅｙ＝ｖａｌの場合は１
ｂ．ｋｅｙ＜ｖａｌの場合は（ｖａｌ−ｍｉｎ）
ｃ．ｋｅｙ＞ｖａｌの場合は（ｍａｘ−ｖａｌ）
として計算する。
３．合計適格葉ノード、ＱＬ＝Ｌｓｉｚｅ＊ＭＫＶ
４．連続するオフセットサイズ及び開始アドレスを有するデータアクセスパターンを生成し、オフセットをすべてＢｓｉｚｅのものにする。まずＨｓｉｚｅ＋１のシステム読み出しを生成し、各々を無作為なアドレスから開始させる。これに、ＱＬ−１のシーケンシャルアクセスが続く。
５．フルテーブルスキャンＡＦＴＳ．６で考察したようにネットワークパラメータを計算し、ＡＦＴＳ．１から得られた合計遅延時間をシステム読み出し要求の中に分散して入れる。
６．上記で生成されたデータアクセスパターンを当てはめる。計算モジュール２２０を用いてかかった合計時間を計算し、これが、クエリの入出力アクセス時間に相当する。

主インデックススキャンクエリに対する特殊分類技術

主インデックススキャンの場合、フィルタ条件がｋｅｙ＝ｖａｌ、またはｋｅｙ＜ｖａｌなどであるクエリでは、テーブルのサイズに関係なく、一定数の葉ブロック及びデータブロックに常にアクセスする。したがって、インデックス木の高さが増した場合にのみ、ブロックアクセスの合計数が増加する。したがって、このようなクエリのＩＯアクセス時間は、テーブルサイズに対して不変である。しかし、フィルタ条件がｋｅｙ＞ｖａｌなどであるクエリでは、アクセスされるデータブロックの数は、データサイズが増すと増加する。その上、データブロックは、そのデータブロックの主キーの小さい順にアクセスされるため、ブロックアドレス、すなわちデータブロックアクセスは繰り返されない。

主インデックススキャンクエリに対する特殊分類技術では、クエリ（ｋｅｙ＜ｖａｌ，ｋｅｙ＜ｖａｌ ａｎｄ ｋｅｙ＝ｖａｌ）は、テーブルスキーマ、テーブルサイズ（つまり行数と行の平均サイズ）は、入力値として供給される。その後、この入力値は、計算モジュール２２０によって処理されて、入出力アクセス時間を計算する。

主インデックススキャンクエリに対する特殊分類技術の詳細は、以下の通りである。
１．サイズが数メガバイトの小データベースを作成する。ＤＢ特殊ツールを使用して、次のデータベース統計項目−データベースブロックサイズ（Ｂｓｉｚｅ）、インデックスを付した列の最小値（ｍｉｎ）、列の最大値（ｍａｘ）、キーごとのデータブロック数（Ｄｓｉｚｅ）、キーごとの葉ノード数（Ｌｓｉｚｅ）及び木の高さ（Ｈｓｉｚｅ）を取得する。得られた統計項目を線形外挿することによって、投影されたデータベースサイズＳでこれらのデータベース統計項目を取得する。
２．これらのデータベース統計項目は、ステップ１から得られた統計項目を線形外挿することによって、投影されたデータベースサイズＳで得られる。
３． マッチしたｋｅｙ値（ＭＫＶ）の数を、
ａ．ｋｅｙ＝ｖａｌの場合は１
ｂ．ｋｅｙ＜ｖａｌの場合は（ｖａｌ−ｍｉｎ）
ｃ．ｋｅｙ＞ｖａｌの場合は（ｍａｘ−ｖａｌ）
として計算する。
４．合計適格葉ノード、ＱＬ＝Ｌｓｉｚｅ＊ＭＫＶ
５．連続するオフセットサイズ及び開始アドレスを有するデータアクセスパターンを生成し、オフセットをすべてＢｓｉｚｅのものにする。まずＨｓｉｚｅ＋１のシステム読み出しを生成し、各々が無作為なアドレスから開始する。これに、ＱＬ−１のシーケンシャルアクセスが続き、このシーケンシャルアクセスの中に、２つの葉ノードへアクセスする間のＤｓｉｚｅのシーケンシャルアクセスが分散して入れられる。葉ブロック及びデータブロックに対して開始されるブロックアドレスは異なるため、そのアドレスは、互いに無作為なものである。
６．フルテーブルスキャンＡＦＴＳ．６で考察したようにネットワークパラメータを計算し、ＡＦＴＳ．１から得られた合計遅延時間をシステム読み出し要求の中に分散して入れる。
７．上記で生成されたデータアクセスパターンを当てはめる。すると、計算モジュール２２０はかかった合計時間を計算し、これが、クエリの入出力アクセス時間に相当する。

ノンユニークインデックススキャンクエリに対する特殊分類技術

ノンユニークキーに対してインデックスを使用してテーブルにアクセスする場合、データブロックアクセスの順序は、テーブル内に分散されるデータの配置に依存する。ノンユニークインデックスを使用して、インデックスを付した列の値にマッチする一連の行にアクセスすることで、列の値がテーブル内の行に一様に無作為に分散される形で配置される場合、テーブルの全ブロックにアクセスすることになり得る。ノンユニークの列の値を決定的に小さい順に分散させて、主キーと同じデータアクセスパターンにマッピングする。

ノンユニークキーでのインデックススキャンの場合、フィルタ条件がｋｅｙ＝ｖａｌなどであるクエリでは、２つ以上の葉ブロック及び２つ以上のデータブロックにアクセスできるが、データブロックは、アドレスの小さい順にアクセスされる。しかし、フィルタ条件がｋｅｙ＞ｖａｌ、またはｋｅｙ＜ｖａｌなどであるクエリの場合は、データブロックを２回以上アドレス指定することができる。なぜなら、列の値は一様に無作為に分散されているため、１つのデータブロックが全ｋｅｙ値のレコードを有する確率は等しいからである。これが、データブロックに繰り返しアクセスすることにつながる。この繰り返しアクセスは、アクセスされるテーブルのサイズ及びキャッシュに応じて、データベースキャッシュ、ＯＳキャッシュまたはストレージデバイスから直接提供されてよい。

テーブルサイズ＜データベースキャッシュの場合、繰り返しアクセスは、データベースキャッシュから提供される。

データベースキャッシュ＜テーブルサイズ＜ＯＳキャッシュの場合、繰り返しアクセスは、ＯＳキャッシュから提供される。

テーブルサイズ＞ＯＳキャッシュの場合、繰り返しアクセスは、ハードディスクから提供される。

ノンユニークインデックススキャンクエリに対する特殊分類技術では、クエリ（ｋｅｙ＜ｖａｌ，ｋｅｙ＜ｖａｌ ａｎｄ ｋｅｙ＝ｖａｌ）、テーブルスキーマ、テーブルサイズ（つまり行数と行の平均サイズ）は、入力値として供給される。その後、この入力値は、計算モジュール２２０によって処理されて、入出力アクセス時間を計算する。

特殊分類技術の詳細は、以下の通りである。
１．サイズが数メガバイトの小データベースを作成する。ＤＢ特殊ツールを使用して、次のデータベース統計項目−データベースブロックサイズ（Ｂｓｉｚｅ）、葉ノードごとのデータポインタ数（Ｄｐｔｒ）、インデックスを付した列の最小値（ｍｉｎ）、列の最大値（ｍａｘ）、キーごとの葉ノード数（Ｌｓｉｚｅ）及び木の高さ（Ｈｓｉｚｅ）を取得する。得られた統計項目を線形外挿することによって、投影されたデータベースサイズＳでこれらのデータベース統計項目を取得する。
２．これらのデータベース統計項目は、ステップ１から得られた統計項目を線形外挿することによって、投影されたデータベースサイズＳで得られる。
３．マッチしたｋｅｙ値（ＭＫＶ）の数を、
ａ．ｋｅｙ＝ｖａｌの場合は１
ｂ．ｋｅｙ＜ｖａｌの場合は（ｖａｌ−ｍｉｎ）
ｃ．ｋｅｙ＞ｖａｌの場合は（ｍａｘ−ｖａｌ）
として計算する。
４．合計適格葉ノード、ＱＬ＝Ｌｓｉｚｅ＊ＭＫＶ
５．連続するオフセットサイズ及び開始アドレスを有するデータアクセスパターンを生成し、オフセットをすべてＢｓｉｚｅのものにする。まずＨｓｉｚｅ＋１のシステム読み出しを生成し、各々が無作為なアドレスから開始する。これに、ＱＬ−１のシーケンシャルアクセスが続き、このシーケンシャルアクセスの中に、２つの葉ノードへアクセスする間のＤｐｔｒのシーケンシャルアクセスが分散して入れられる。葉ブロック及びデータブロックに対して開始されるブロックアドレスは異なるため、そのアドレスは、互いに無作為なものである。テーブルサイズ＞データベースキャッシュの場合は、ＭＫＶ反復に対してこのステップを繰り返すが、最初の反復で生成されたものと同じセットのブロックアドレスが維持される。
６．フルテーブルスキャンＡＦＴＳ．６で考察したようにネットワークパラメータを計算し、ＡＦＴＳ．１から得られた合計遅延時間の中にシステム読み出し要求を分散して入れる。
７．上記で生成されたデータアクセスパターンを当てはめる。すると、計算モジュール２２０はかかった合計時間を計算し、これが、クエリの入出力アクセス時間に相当する。

次に、計算モジュール２２０は、入出力アクセス時間を使用してクエリにかかる経過応答時間（ＥＲＴ）を算出する。

計算モジュール２２０によって推定された通りの、フルテーブルスキャンクエリとインデックススキャンクエリとの両方に対するサイズ「Ｓ」のクエリＥＲＴ（Ｅｌａｐｓｅｄ Ｒｅｓｐｏｎｓｅ Ｔｉｍｅ、経過応答時間）は、以下の和である。
１．構文分析時間
２．すべてのシステム読み出し要求にかかった合計時間
３．システム読み出し要求の合計数×平均データ準備時間
４．データパケットの合計数×パケット送信にかかった平均時間
５．データパケットの合計数×クライアントからの承認を受信するまでの待ち時間

例示的な実施形態として、システム１０２の動作を説明するために、特定のＤＢサーバ、Ｏｒａｃｌｅ １１ｇを検討してみる。４ＧＢのＲＡＭを搭載したＩｎｔｅｌのクアッドコアサーバを使用する。データベーススキーマ及びデータは、ＴＰＣ−Ｈ（１１）ベンチマークに基づくｄｂｇｅｎユーティリティを使用して生成される。以下に挙げたように、供給側テーブル内の統合クエリのうちの５つに対して結果が得られる。これらのクエリは、テーブルへのアクセスモードに基づいて形成されている。線形外挿したＣＰＵの時間をＩＯ（Ｉｎｐｕｔ−ｏｕｔｐｕｔ、入力−出力）アクセス時間に加えることによってＥＲＴを計算できるように、ＣＰＵの計算時間がデータベースのサイズに対して線形的なクエリが選択される。
ＴＣＰ−Ｈスキーマの統合クエリ：
フルテーブルスキャンクエリ１：ｓｅｌｅｃｔ ＊ ｆｒｏｍ ｓｕｐｐｌｉｅｒ（フル出力）
フルテーブルスキャンクエリ２：ｓｅｌｅｃｔ ｓｕｍ（ｓ＿ａｃｃｔｂａｌ） ｆｒｏｍ ｓｕｐｐｌｉｅｒ（集約出力）
高速インデックススキャンクエリ３：ｓｅｌｅｃｔ ／＊＋ ｉｎｄｅｘ（ｓｕｐｐｌｉｅｒ ｐｋ＿ｓｕｐｐｌｉｅｒ） ＊／ ｓ＿ｓｕｐｐｋｅｙ ｆｒｏｍ ｓｕｐｐｌｉｅｒ
主インデックススキャンクエリ４：ｓｅｌｅｃｔ ／＊＋ ｉｎｄｅｘ（ｓｕｐｐｌｉｅｒ ｐｋ＿ｓｕｐｐｌｉｅｒ） ＊／ ｓｕｍ（ｓ＿ａｃｃｔｂａｌ） ｆｒｏｍ ｓｕｐｐｌｉｅｒ ｗｈｅｒｅ ｓ＿ｓｕｐｐｋｅｙ＞１０；
ノンユニークインデックススキャンクエリ５：ｓｅｌｅｃｔ ／＊＋ ｉｎｄｅｘ（ｓｕｐｐｌｉｅｒ ｓｕｐｐ＿ｎｋ） ＊／ ｓｕｍ（ｓ＿ａｃｃｔｂａｌ） ｆｒｏｍ ｓｕｐｐｌｉｅｒ ｗｈｅｒｅ ｓ＿ｎａｔｉｏｎｋｅｙ＝３

データベースは、インデックスｓｕｐｐ＿ｎｋ及びｐｋ＿ｓｕｐｐｌｉｅｒを含むテーブルｓｕｐｐｌｉｅｒからなり、このインデックスはそれぞれｓ＿ｎａｔｉｏｎｋｅｙ及びｓ＿ｓｕｐｐｋｅｙのフィールドにある。ｐｋ＿ｓｕｐｐｌｉｅｒは、主キーｓ＿ｓｕｐｐｋｅｙに対して作成された主インデックスであり、ｓｕｐｐ＿ｎｋは、外部キーｓ＿ｎａｔｉｏｎｋｅｙに対して作成されたノンユニークインデックスであることに注意されたい。サイズ１．３９Ｍの小データベースを作成し、データベースに対して上記に挙げた全クエリを実行する。ｓｔｒａｃｅ及びｔｋｐｒｏｆなどのマイクロベンチマークツールを使用して、（上記で考察したような）アルゴリズムＡＦＴＳ、ＡＦＩＳ、ＡＰＩＳ及びＡＮＵＩＳで要求されるデータを収集する。

アルゴリズムＡＦＴＳを、クエリ１及び２に対してサイズが５．６Ｍ、２１Ｍ、８７Ｍ及び１７５Ｍのデータベースのファイルに適用して、その推定ＩＯアクセス時間を取得し、これによって、線形外挿したＣＰＵ時間の要素を加えることで経過応答時間を取得する。さらに、１７５Ｍサイズのクエリを実行すると、９５％という大部分の読み出しにつながることがわかる。したがって、１７５Ｍは小サイズであり、これを使用してＩＯアクセス時間を予測し、よって、サイズが３５４Ｍ、７０８Ｍ、１４１６Ｍ及び２８３２Ｍのデータベースに線形外挿を使用して、クエリ１及び２に対するＥＲＴを予測する。クエリ１及び２に対する結果を、図４に示している。

インデックススキャンクエリ−クエリ３、４及びクエリ５の場合、サイズが５．６Ｍ、２１Ｍ、８７Ｍ及び１７５Ｍのデータベースは、アルゴリズムＡＦＩＳ、ＡＰＩＳ及びＡＮＵＩＳが要求するデータベース統計項目を取得するために、線形外挿を使用してエミュレートされる。アルゴリズムＡＦＩＳは、サイズが５．６Ｍ、２１Ｍ、８７Ｍ及び１７５Ｍのデータベースに対してクエリ３に適用される。アルゴリズムＡＰＩＳは、サイズが５．６Ｍ、２１Ｍ、８７Ｍ及び１７５Ｍのデータベースに対してクエリ４に適用される。ＤＢサイズがさらに大きい３５４Ｍから２８３２Ｍの場合のクエリＥＲＴは、線形外挿を使用してテーブルサイズ１７５Ｍから予測される。アルゴリズムＡＮＵＩＳは、クエリ５に適用されて、ＩＯアクセス時間を計算し、これによってＥＲＴを計算する。クエリ３、４及び５に対する結果を、図５及び図６に示している。

方法３００に記載した順序は、限定的なものと解釈するためのものではなく、方法３００または代替方法を実装するために、記載した方法のブロックをどのような順序でいくつ組み合わせてもよい。また、本明細書に記載の主題の趣旨及び範囲から逸脱しない限り、方法３００から個々のブロックを削除してもよい。このほか、本方法は、任意の適切なハードウェア、ソフトウェア、ファームウェア、またはこれらを組み合わせたものに実装されてよい。しかし、説明を簡易にするため、以下に記載する実施形態では、本方法３００は、上記のシステム１０２に実装されると考えてよい。

ブロック３０２では、データベースに対してクエリを実行する。

ブロック３０４では、データベースをエミュレートする。

ブロック３０６では、クエリによりデータベースへアクセスするモードに基づいてクエリを分類する。

ブロック３０８では、１つ以上のパラメータに沿ったアクセスパターンを決定する。

ブロック３１０では、特殊分類技術を適用することによって、エミュレートしたデータベースに対するクエリにかかる入出力アクセス時間を計算して、さらにクエリ経過応答時間を算出する。

以上は、本明細書の主題を説明して、当業者が本発明の実施形態を実現して使用できるようにしたものである。主題の実施形態の範囲は、特許請求の範囲に規定される範囲であり、この範囲には、当業者に生じる他の修正を含めることができる。このような他の修正は、その修正が同様の素子を含み、それが特許請求の範囲の文字通りの言葉と異なっていない場合、あるいは、その修正が同等の素子を含み、それが特許請求の範囲の文字通りの言葉と事実上差がない場合、特許請求の範囲内に含まれる。

Claims (11)

1. 本番データベースに対して実行されるクエリにかかる経過応答時間を予測するシステムであって、
   プロセッサと；
   前記プロセッサに接続するメモリであって、
   前記プロセッサは、前記メモリに格納された複数のモジュールを実行することができ、
   前記複数のモジュールは、
   データベースの統計項目を収集するためにデータベースに対して前記クエリを実行するように構成されたクエリ実行モジュールと；
   エミュレートしたデータベースを得るために前記データベースの統計項目をエミュレートするように構成されたエミュレーションモジュールと；
   前記クエリを、フルテーブルスキャンクエリ、高速インデックススキャンクエリ、主インデックススキャンクエリ、及びノンユニークインデックススキャンクエリの中の少なくとも１つに分類するように構成された分類モジュールであって、前記クエリは、前記クエリにより前記エミュレートしたデータベースへアクセスするモードに基づいて分類される、分類モジュールと；
   前記エミュレートしたデータベースの少なくとも１つのパラメータに沿ったアクセスパターンを決定するように構成されたパラメータ決定モジュールであって、前記アクセスパターン、前記パラメータ及び前記クエリは、前記エミュレートしたデータベースのサイズに影響を受けやすい、パラメータ決定モジュールと；
   計算モジュールであって、
   前記フルテーブルスキャンクエリ、前記高速インデックススキャンクエリ、前記主インデックススキャンクエリ、及び前記ノンユニークインデックススキャンクエリの中の少なくとも１つへの分類と、前記１つ以上のパラメータに基づいて、前記エミュレートしたデータベースに対して実行される前記クエリの入出力アクセス時間を計算し、
   更に前記入出力アクセス時間に基づいて本番データベースに対して実行される前記クエリの前記経過応答時間を算出するように構成された計算モジュールと、
   を備えるメモリを有する
   ことを特徴とするシステム。
2. 前記クエリは、前記本番データベースより小さいサイズのデータベースに対して実行される
   請求項１に記載のシステム。
3. 前記１つ以上のパラメータは、テーブルスキーマと、前記フルテーブルスキャンクエリ、前記高速インデックススキャンクエリ、前記主インデックススキャンクエリ及び前記ノンユニークインデックススキャンクエリの各々に対して投影されたテーブルのサイズとを含む
   請求項１に記載のシステム。
4. 前記エミュレーションモジュールは、前記エミュレートしたデータベースを得るために前記１つ以上のパラメータに沿った前記アクセスパターンを外挿するように構成される
   請求項１に記載のシステム。
5. 前記計算モジュールは、前記入出力アクセス時間を、線形外挿したＣＰＵ時間に加算して、前記クエリの前記経過応答時間を算出する
   請求項１に記載のシステム。
6. 前記エミュレートしたデータベースは、さらに、エミュレートした大サイズのデータベースからなる
   請求項１に記載のシステム。
7. 本番データベースに対して実行されるクエリにかかる経過応答時間を予測する方法であって、
   データベースの統計項目を収集するために前記クエリをデータベースに対して実行することと；
   エミュレートしたデータベースを得るために前記データベースの統計項目をエミュレートすることと；
   前記クエリを、フルテーブルスキャンクエリ、高速インデックススキャンクエリ、主インデックススキャンクエリ、及びノンユニークインデックススキャンクエリの中の少なくとも１つに分類することであって、前記クエリは、前記クエリにより前記エミュレートしたデータベースへアクセスするモードに基づいて分類されることと；
   前記エミュレートしたデータベースに対して１つ以上のパラメータに沿ったアクセスパターンを決定することであって、前記アクセスパターン、前記パラメータ及び前記クエリは、前記エミュレートしたデータベースのサイズに影響を受けやすいことと；
   前記フルテーブルスキャンクエリ、前記高速インデックススキャンクエリ、前記主インデックススキャンクエリ、及び前記ノンユニークインデックススキャンクエリの中の少なくとも１つへの分類と、前記１つ以上のパラメータに基づいて、前記エミュレートしたデータベースに対して実行される前記クエリの入出力アクセス時間を計算し、
   更に前記入出力アクセス時間に基づいて、本番データベースに対して実行される前記クエリにかかる前記経過応答時間を算出することと；を含み、
   １つ以上のパラメータに沿ったアクセスパターンの前記実行、前記分類、前記決定、前記経過応答時間の前記エミュレート、前記計算及び前記算出は、プロセッサによって実施される
   ことを特徴とする方法。
8. このように決定された前記パラメータは、さらに、テーブルスキーマと、前記フルテーブルスキャンクエリ、前記高速インデックススキャンクエリ、前記主インデックススキャンクエリ及び前記ノンユニークインデックススキャンクエリの各々に対して投影されたテーブルのサイズとを含む
   請求項７に記載の方法。
9. 前記アクセスパターン及び前記１つ以上のパラメータは、前記エミュレートしたデータベースを得るために外挿される
   請求項７に記載の方法。
10. 前記入出力アクセス時間は、線形外挿したＣＰＵ時間に加算されて、前記クエリの前記経過応答時間を算出する
    請求項７に記載の方法。
11. 前記入出力アクセス時間は、さらに、前記クエリの格納アクセス時間及びネットワーク伝達時間を含む
    請求項７に記載の方法。

Images