(57)【要約】      （修正有）【課題】計算機システムのデータベースに対するアクセス時の負荷を見積もること。【解決手段】記憶装置には、複数のレコードを有するテーブルの構造を定義する構造情報Ｄ１と、テーブルに対するクエリＤ３の条件変数の確率分布を示す第１分布情報Ｄ４と、テーブルの要素の確率分布を示す第２分布情報Ｄ２とが格納される。レコード数算出モジュール２０は、構造情報Ｄ１、第１分布情報Ｄ４及び第２分布情報Ｄ２に基づいて、複数のレコードのうち条件変数で規定される条件に適合するレコード数の平均値を算出する。アクセス回数算出モジュール３０は、算出されたレコード数の平均値に基づいて、クエリＤ３に応じてアクセスされるブロックの数を算出する。【選択図】図３
2008225575.tif 000002
【特許請求の範囲】
【請求項１】
データベースの負荷を見積もるための計算機負荷見積システムであって、
複数のレコードを有し前記データベースに含まれるテーブルの構造を定義する構造情報と、前記テーブルに対するクエリの条件変数の確率分布を示す第１分布情報と、前記テーブルの要素の確率分布を示す第２分布情報と、が格納される記憶装置と、
前記構造情報、前記第１分布情報及び前記第２分布情報に基づいて、前記複数のレコードのうち前記条件変数で規定される条件に適合するレコードの数の平均値である選択レコード数を算出するレコード数算出モジュールと、
前記選択レコード数に基づいて、前記クエリに応じてアクセスされるブロックの数を算出するアクセス回数算出モジュールと
を備える
計算機負荷見積システム。
【請求項２】
請求項１に記載の計算機負荷見積システムであって、
前記構造情報は、前記複数のレコードの総数、及び前記複数のレコードの各々のサイズを示す
計算機負荷見積システム。
【請求項３】
請求項２に記載の計算機負荷見積システムであって、
前記条件変数は、数値幅を規定し、
前記第１分布情報は、前記数値幅の確率分布を示しており、
前記レコード数算出モジュールは、前記第１分布情報に基づいて、前記数値幅の平均値である平均選択幅を算出し、
前記レコード算出モジュールは、前記レコードの総数と前記第２分布情報に基づいて、１レコードあたりに前記要素が取り得る数値幅の平均値であるレコード幅を算出し、
前記レコード数算出モジュールは、前記平均選択幅を前記レコード幅で割ることによって前記選択レコード数を算出する
計算機負荷見積システム。
【請求項４】
請求項３に記載の計算機負荷見積システムであって、
前記記憶装置には更に、ブロックへの前記複数のレコードの配置方法を示す配置情報と、索引検索に利用されるメタデータの構造を定義するメタデータ構造情報とが格納され、
前記アクセス回数算出モジュールは、前記選択レコード数、前記配置情報及び前記メタデータ構造情報に基づいて、前記アクセスされるブロックの数を算出する
計算機負荷見積システム。
【請求項５】
請求項４に記載の計算機負荷見積システムであって、
前記配置情報は、前記複数のレコードが前記要素に拘わらずランダムに配置されることを示し、
前記アクセス回数算出モジュールは、前記メタデータが格納されるブロックへのアクセス回数と前記選択レコード数との和を、前記アクセスされるブロックの数として算出する
計算機負荷見積システム。
【請求項６】
請求項４又は５に記載の計算機負荷見積システムであって、
前記配置情報は、前記複数のレコードが前記要素の値順にシーケンシャルに配置されることを示し、
１ブロックあたりに格納されるレコード数がＡ１であり、前記選択レコード数がＡ２であるとき、
前記アクセス回数算出モジュールは、式：Ａ３＝１＋（Ａ２−１）／Ａ１に基づいて値Ａ３を算出し、更に、前記メタデータが格納されるブロックへのアクセス回数と前記値Ａ３との和を、前記アクセスされるブロックの数として算出する
計算機負荷見積システム。
【請求項７】
請求項２乃至６のいずれかに記載の計算機負荷見積システムであって、
前記アクセス回数算出モジュールは、前記レコードの総数、前記各レコードのサイズ、及び１ブロックのサイズに基づいて、前記複数のレコードの全てを格納するために必要なブロックの総数を算出し、
前記アクセス回数算出モジュールは、前記算出されたブロックの総数を、全件検索時の場合の前記アクセスされるブロックの数として算出する
計算機負荷見積システム。
【請求項８】
請求項１乃至７のいずれかに記載の計算機負荷見積システムであって、
前記アクセスされるブロックの数を表示する表示装置を更に備える
計算機負荷見積システム。
【請求項９】
請求項１乃至７のいずれかに記載の計算機負荷見積システムであって、
性能見積モジュールを更に備え、
前記記憶装置には更に、１ブロックに対するアクセスに要する計算機負荷を示す負荷量情報が格納され、
前記性能見積モジュールは、前記計算機負荷と前記アクセスされるブロックの数とに基づいて、前記クエリの処理に必要な負荷を算出する
計算機負荷見積システム。
【請求項１０】
請求項９に記載の計算機負荷見積システムであって、
前記クエリの処理に必要な負荷を表示する表示装置を更に備える
計算機負荷見積システム。
【請求項１１】
データベースの負荷を見積もるための計算機負荷見積方法であって、
（Ａ）複数のレコードを有し前記データベースに含まれるテーブルの構造を定義する構造情報を、記憶装置から読み出すステップと、
（Ｂ）前記テーブルに対するクエリの条件変数の確率分布を示す第１分布情報を、前記記憶装置から読み出すステップと、
（Ｃ）前記テーブルの要素の確率分布を示す第２分布情報を、前記記憶装置から読み出すステップと、
（Ｄ）前記構造情報、前記第１分布情報及び前記第２分布情報に基づいて、前記複数のレコードのうち前記条件変数で規定される条件に適合するレコードの数の平均値である選択レコード数を算出するステップと、
（Ｅ）前記選択レコード数に基づいて、前記クエリに応じてアクセスされるブロックの数を算出するステップと
を有する
計算機負荷見積方法。
【請求項１２】
請求項１１に記載の計算機負荷見積方法をコンピュータに実行させる
計算機負荷見積プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベースを備える計算機システムの負荷を見積もるための技術に関する。
【背景技術】
【０００２】
計算機上に構築されたデータベースの運用／管理を行うためのソフトウエアとして、「データベース管理システム（DBMS: Database Management System）」が一般的に知られている。そのデータベース管理システムにおいては、「クエリ（query）」と呼ばれるコマンドが使用される。クエリとは、データベースに対する処理要求を表す文字列であり、データの検索、更新、削除などを指定する文字列である。例えば、データ検索クエリは、検索対象のテーブルやデータの抽出条件を指定する。データベースの一種であるリレーショナルデータベースの場合、クエリは、ＳＱＬ（Structured Query Language）で記述される（非特許文献１参照）。
【０００３】
図１及び図２を参照して、一般的なクエリ処理を説明する。図１には、あるリレーショナルデータベース内のあるテーブルＴＢＬが示されている。テーブルＴＢＬは複数のレコード（行）を有しており、各レコードは３つのカラムＣＯＬ１〜ＣＯＬ３から構成されている。例えば、第１カラムＣＯＬ１はＩＤを示し、第２カラムＣＯＬ２は商品名を示し、第３カラムＣＯＬ３は価格を示している。
【０００４】
また、図１には、クエリの一例が示されている。クエリは、データベースに対するアクセス方法を示す「アクセス種」、アクセス対象を示す「ターゲット」、アクセス対象が含まれる領域を示す「スコープ」、及びアクセス対象の条件を示す「条件節」を含んでいる。「アクセス種」としては、“ｓｅｌｅｃｔ（データ読み出し）”、“ｕｐｄａｔｅ（データ更新）”、“ｉｎｓｅｒｔ（レコード挿入）”、“ｄｅｌｅｔｅ（レコード削除）”などが挙げられる。図１に示された例の場合、クエリは、「テーブルＴＢＬから、価格５００〜１０００のレコード（ターゲット“＊”はカラムＣＯＬ１〜ＣＯＬ３の全てを意味する）を読み出すこと」を指示している。
【０００５】
そのクエリに従って、ＤＢＭＳは、テーブルＴＢＬから条件を満たすレコードを読み出す。図１に示された例の場合、３つのレコード（ＩＤ＝１，ＩＤ＝３１２３，ＩＤ＝９９９８）が該当する。テーブルＴＢＬの各レコードは実際には記憶領域（メモリ等）に格納されており、ＤＢＭＳはその記憶領域にアクセスすることになる。
【０００６】
図２は、記憶領域へのアクセスを説明するための図である。一般的に、記憶領域はブロック単位で管理され、アクセス時には、必要なブロックに含まれるデータがまとめて読み出される。テーブルＴＢＬのデータが格納されているブロックは、特に「テーブルブロック」と参照される。例えば、３つのレコード（ＩＤ＝１，３１２３，９９９８）は、テーブルブロックＢＬ−ｊ，ＢＬ−ｉ，ＢＬ−ｋのそれぞれに格納されている。従って、ＤＢＭＳは、少なくとも３つのテーブルブロックＢＬにアクセスする必要がある。
【０００７】
また、記憶領域内には膨大なデータが格納されており、その膨大なデータへのアクセスを容易にするために「メタデータ」が利用される場合がある。メタデータとは、記録データの“索引（インデックス）”である。メタデータ自身も、記憶領域内の所定のブロックに格納されている。メタデータによる索引は階層的に構築されており、最下位の階層の索引は「リーフブロック」と呼ばれるブロックに格納されている。複数のリーフブロックを束ねる上位階層の索引、すなわちリーフブロックの索引は、「ブランチブロック」と呼ばれるブロックに格納されている。
【０００８】
図２に示されるように、リーフブロックは複数のエントリを有しており、各エントリはキー値とポインタから構成されている。本例において、キー値は、第３カラムＣＯＬ３の値（価格）を示しているとする。各リーフブロックにおいて、複数のエントリは、キー値に基づいてソートされている。ポインタは、キー値が格納されているレコードの先頭アドレスを指し示す。尚、第３カラムＣＯＬ３の値（キー値）が複数のレコード間で同じ場合、その同じキー値に対して異なるポインタが割り当てられる。
【０００９】
メタデータが利用可能な場合、ＤＢＭＳは、そのメタデータを参照することによってテーブルブロックにアクセスする。すなわち、ＤＢＭＳは、メタデータを参照して読み出し対象のキー値に対応づけられたポインタＰ３、Ｐ４、Ｐ５を取得した後、それらポインタＰ３、Ｐ４、Ｐ５が指し示すアドレスにアクセスする。この場合、ＤＢＭＳは、全体として５つのブロック（ブランチブロック、リーフブロック、テーブルブロックＢＬ−ｉ、ＢＬ−ｊ、ＢＬ−ｋ）にアクセスする必要がある。
【００１０】
以上に説明されたように、ＤＢＭＳはクエリに従って、記憶領域内の必要なブロックにアクセスし、そのブロックのデータをまとめて読み出す。あるブロックへのアクセスは、以下「ブロックアクセス」と参照される。また、あるクエリ処理に必要なブロックアクセスの回数は、以下「ブロックアクセス回数」と参照される。また、そのクエリ処理に必要なブロックからのデータ読み出しは、以下「フェッチ」と参照される。
【００１１】
あるクエリ処理におけるフェッチの負荷量は、ブロックアクセス回数、すなわちクエリの内容に大きく依存する。例えば、多数のデータを処理対象とするクエリの場合、多数のブロックアクセスを実行する必要があり、フェッチの負荷量は大きくなる。フェッチの負荷量は、ＤＢＭＳが構築された計算機システムの処理能力を大きく左右する。従って、計算機システムの運用においては、フェッチの負荷量、すなわちブロックアクセス回数を適正な値に抑えることが重要である。
【００１２】
データベース管理システム（ＤＢＭＳ）に関連する一般的な技術として、次のものが知られている。
【００１３】
特許文献１には、クライアントサーバ型のデータベースシステムが開示されている。サーバ計算機システムには、データベースに対する具体的な処理履歴をログ情報として蓄積するログファイルが用意される。サーバ計算機システムは、クライアント計算機システムからの新たな処理要求に応答してログファイルを参照し、その処理要求に類似している他の処理要求に関するログ情報をクライアント計算機システムに通知する。クライアント計算機システムは、処理要求に応じて通知されるログ情報に基づいて、処理要求実現時の見積処理性能を提示する。
【００１４】
【特許文献１】特開平９−９７２００号公報
【非特許文献１】「Ｏｒａｃｌｅ  Ｄａｔａｂａｓｅ  パフォーマンス・チューニング・ガイド」，１０ｇリリース１（１０．１）、部品番号：Ｂ１２４４９−０１
【発明の開示】
【発明が解決しようとする課題】
【００１５】
上述の通り、計算機システムの処理性能の観点から、フェッチの負荷量、すなわちブロックアクセス回数を適正な値に抑えることが重要である。従って、ブロックアクセス回数を見積もることができる技術が望まれる。
【課題を解決するための手段】
【００１６】
以下に、［発明を実施するための最良の形態］で使用される番号・符号を用いて、［課題を解決するための手段］を説明する。これらの番号・符号は、［特許請求の範囲］の記載と［発明を実施するための最良の形態］との対応関係を明らかにするために括弧付きで付加されたものである。ただし、それらの番号・符号を、［特許請求の範囲］に記載されている発明の技術的範囲の解釈に用いてはならない。
【００１７】
本発明の第１の観点において、計算機負荷見積システムが提供される。その計算機負荷見積システムは、データベースに対するアクセス時の負荷を見積もる。具体的には、計算機負荷見積システムは、記憶装置（１２０）、レコード数算出モジュール（２０）、及びアクセス回数算出モジュール（３０）を備える。
【００１８】
記憶装置（１２０）には、構造情報（Ｄ１）、第１分布情報（Ｄ４）、及び第２分布情報（Ｄ２）が格納される。構造情報（Ｄ１）は、複数のレコードを有しデータベースに含まれるテーブルの構造を定義する。第１分布情報（Ｄ４）は、そのテーブルに対するクエリ（Ｄ３）の条件変数の確率分布を示す。第２分布情報（Ｄ２）は、そのテーブルの要素の確率分布を示す。
【００１９】
レコード数算出モジュール（２０）は、上記構造情報（Ｄ１）、第１分布情報（Ｄ４）及び第２分布情報（Ｄ２）に基づいて、複数のレコードのうち条件変数で規定される条件に適合するレコードの数の平均値を算出する。算出された平均値は、クエリに応じて選択される平均的なレコード数である。アクセス回数算出モジュール（３０）は、その平均的なレコード数に基づいて、クエリに応じてアクセスされるブロックの数、すなわちブロックアクセス回数を算出する。
【００２０】
このように、本発明によれば、テーブルの構造を示す情報や、要素及びクエリに関する統計的な情報を利用することにより、ブロックアクセス回数を見積もることが可能となる。例えば、計算機システムの構築前や、計算機システムが使用不可能な場合、実際のテーブルの要素値を知ることはできない。そのような場合であっても、本発明によれば、ブロックアクセス回数を見積もることが可能である。あるいは、データベースが巨大な場合、実際のテーブルを参照してブロックアクセス回数を測定するためには非常に長い時間を要する。一方、本発明によれば、ブロックアクセス回数を簡便に、且つ、短時間で見積もることが可能となる。
【００２１】
本発明の第２の観点において、計算機負荷見積方法が提供される。その計算機負荷見積方法は、（Ａ）複数のレコードを有しデータベースに含まれるテーブルの構造を定義する構造情報（Ｄ１）を、記憶装置（１２０）から読み出すステップと、（Ｂ）テーブルに対するクエリの条件変数の確率分布を示す第１分布情報（Ｄ４）を、記憶装置（１２０）から読み出すステップと、（Ｃ）テーブルの要素の確率分布を示す第２分布情報（Ｄ２）を、記憶装置（１２０）から読み出すステップと、（Ｄ）構造情報（Ｄ１）、第１分布情報（Ｄ４）及び第２分布情報（Ｄ２）に基づいて、複数のレコードのうち条件変数で規定される条件に適合するレコードの数の平均値である選択レコード数を算出するステップと、（Ｅ）選択レコード数に基づいて、クエリに応じてアクセスされるブロックの数を算出するステップと、を有する。
【００２２】
本発明の第３の観点において、上記計算機負荷見積方法をコンピュータに実行させるプログラムが提供される。
【発明の効果】
【００２３】
本発明によれば、クエリ処理に伴って発生するブロックアクセス回数を見積もることが可能となる。
【発明を実施するための最良の形態】
【００２４】
１．第１の実施の形態
１−１．構成
図３は、本発明の第１の実施の形態に係る計算機負荷見積システムの構成を示すブロック図である。本実施の形態に係る計算機負荷見積システムは、クエリ解析モジュール１０、レコード数算出モジュール２０、ブロックアクセス回数算出モジュール３０、及び出力モジュール６０を備えている。モジュール１０〜３０は、ブロックアクセス回数見積モジュール４０を構成している。そのブロックアクセス回数見積モジュール４０には、データ構造情報Ｄ１、論理分布情報Ｄ２、クエリ情報Ｄ３、変数分布情報Ｄ４、レコード配置情報Ｄ５、及びメタデータ構造情報Ｄ６が入力情報として入力される。また、場合によっては、デフォルト情報Ｄ７が入力される。まず、それら入力情報に関して詳しく説明する。
【００２５】
図４には、あるテーブルＳＡＭＰＬＥと、そのテーブルＳＡＭＰＬＥに対するクエリの一例が示されている。テーブルＳＡＭＰＬＥは、負荷見積対象である計算機システムのデータベース（例えば、リレーショナルデータベース）に含まれる。計算機システムの構築前であれば、テーブルＳＡＭＰＬＥは使用予定のテーブルである。本実施の形態において、テーブルＳＡＭＰＬＥの各要素は未定であってよく、また、必要とされない。但し、テーブルＳＡＭＰＬＥの型や構造に関しては、計算機システムの構築前であっても定義することができる。その定義を示すのが、データ構造情報Ｄ１である。
【００２６】
データ構造情報Ｄ１は、テーブルＳＡＭＰＬＥの型や構造、総レコード数を示している。例えば図４において、データ構造情報Ｄ１は、（１）データベース中にテーブルＳＡＭＰＬＥが存在すること、（２）そのテーブルＳＡＭＰＬＥの各レコードは、４バイトの数値カラムＣＯＬ１、２４バイトの文字列カラムＣＯＬ２、４バイトの数値カラムＣＯＬ３から成ること、（３）そのテーブルＳＡＭＰＬＥの総レコード数は１０万であること、を示している。更に、データ構造情報Ｄ１は、（４）データベースが実際に格納される記憶領域上のテーブルブロックの１つあたりのサイズ（有効ブロックサイズ）も示している。図４に示された例では、有効ブロックサイズは８０００バイトである。このように、データ構造情報Ｄ１は、データベースやテーブルに関連する構造を定義している。
【００２７】
上述の通り、テーブルＳＡＭＰＬＥの各要素は未定であってよい。しかしながら、テーブルＳＡＭＰＬＥの各要素が取り得る値の分布は、あらかじめ定義することができる。その定義を示すのが、論理分布情報Ｄ２である。具体的には、論理分布情報Ｄ２は、テーブルＳＡＭＰＬＥが有し得る値を統計的に示している、すなわち、テーブルＳＡＭＰＬＥの要素の確率分布を示している。例えば図４において、論理分布情報Ｄ２は、「第３カラムＣＯＬ３の要素は、範囲０〜９９９，９９９の値を一様な確率でとること」を示している。
【００２８】
クエリ情報Ｄ３は、テーブルＳＡＭＰＬＥに対する所定のクエリを示している。そのクエリはＳＱＬで記述され、「アクセス種」、「ターゲット」、「スコープ」、及び「条件節」を含んでいる。例えば図４において、クエリ情報Ｄ３は、あるクエリ“select * from SAMPLE where COL3 between :a and :b”を示している。記号＊は、カラムＣＯＬ１〜ＣＯＬ３の全て、すなわちレコードを意味する。従って、このクエリは、“テーブルＳＡＭＰＬＥから、第３カラムＣＯＬ３の値が範囲ａ〜ｂにあるレコードを読み出すこと”を指示している。このようなクエリに伴って発生するブロックアクセス回数を見積もることが、本発明の目的の１つである。
【００２９】
クエリの条件節中の変数ａ，ｂは、以下「条件変数」と参照される。上記論理分布情報Ｄ２に対応して、条件変数ａ，ｂが取り得る値の分布もあらかじめ定義することができる。その定義を表すのが、変数分布情報Ｄ４である。具体的には、変数分布情報Ｄ４は、条件変数ａ，ｂが有し得る値を統計的に示している、すなわち、条件変数ａ，ｂの確率分布を示している。例えば図４において、変数分布情報Ｄ４は、（１）条件変数ａが範囲０〜９９９，９９９の値を一様な確率でとること、及び（２）条件変数ｂは条件変数ａに０〜９９の値を一様な確率で加えた値であること、を示している。尚、条件変数は離散的であってもよい。
【００３０】
図５は、データベースが実際に格納される記憶領域上のブロック構成を概念的に示している。ブロックは、所定のサイズを有する物理記憶領域であり、ブロックアクセス時には、そのブロックに含まれるデータがまとめて読み出される（フェッチ）。上記テーブルＳＡＭＰＬＥのデータは、複数のテーブルブロックＢＬにわたって格納される。各テーブルブロックＢＬの有効ブロックサイズ（例えば８０００バイト）は、上述のデータ構造情報Ｄ１で定義されている。
【００３１】
レコード配置情報Ｄ５は、テーブルＳＡＭＰＬＥのレコードがテーブルブロックＢＬに対してどのように配置されるかを示す。つまり、レコード配置情報Ｄ５は、テーブルブロックＢＬへのレコードの配置方法を示す。例えば、レコード配置情報Ｄ５は、「テーブルＳＡＭＰＬＥの各レコードは、第３カラムＣＯＬ３の値に拘わらず、ランダムに配置される」という“ランダム配置”を示す。または、レコード配置情報Ｄ５は、「テーブルＳＡＭＰＬＥの各レコードは、第３カラムＣＯＬ３の値順にシーケンシャルに配置される」という“シーケンシャル配置”を示してもよい。あるいは、レコード配置情報Ｄ５は、“ランダム配置”な度合いと“シーケンシャル配置”な度合いを示すパラメータＰを示していてもよい。
【００３２】
また、データベースにおいてメタデータが利用されてもよい。メタデータは、テーブルブロックＢＬに格納されるデータの索引であり、図５に示されるようなツリー状の階層構造を有している。そのような索引は、ツリーインデックスと呼ばれる場合もある。ツリーインデックスの最下位の階層の索引は、リーフブロックＬＢＬに格納される。各リーフブロックＬＢＬは複数のエントリを有しており、各エントリは「キー値」と「内部アドレスポインタ」から構成される。内部アドレスポインタは、キー値が格納されているレコードの先頭アドレスを指し示す。各リーフブロックＬＢＬにおいて、複数のエントリはキー値に基づいてソートされる。また、ツリーインデックスの上層の索引は、リーフブロックＬＢＬの索引であり、ブランチブロックＢＢＬに格納される。
【００３３】
メタデータ構造情報Ｄ６は、メタデータの型や構造を定義している。データ構造情報Ｄ１の場合と同様に、本実施の形態において、メタデータの各要素は未定であってよく、また、必要とされない。例えば図５において、メタデータ構造情報Ｄ６は、（１）第１カラムＣＯＬ１と第３カラムＣＯＬ３に対してツリーインデックスが使用されること、（２）ブランチブロックＢＢＬやリーフブロックＬＢＬの有効ブロックサイズが８０００バイトであること、及び（３）内部アドレスポインタのサイズは６バイトであること、を示している。
【００３４】
デフォルト情報Ｄ７は、論理分布情報Ｄ２、変数分布情報Ｄ４、及びレコード配置情報Ｄ５のデフォルト設定を示す。論理分布情報Ｄ２、変数分布情報Ｄ４、及びレコード配置情報Ｄ５のいずれかが用意されていない場合、その不足している情報は、デフォルト情報Ｄ７が示すデフォルト設定で補われる。
【００３５】
以上に説明された入力情報Ｄ１〜Ｄ７は、例えば、設計仕様書や運用中の計算機システムの運用情報から得られる。そして、それら入力情報Ｄ１〜Ｄ７は、所定の記憶装置に格納される。
【００３６】
再度図３を参照して、ブロックアクセス回数見積モジュール４０は、所定の記憶装置から上述の入力情報Ｄ１〜Ｄ７を読み出す。そして、ブロックアクセス回数見積モジュール４０は、それら入力情報Ｄ１〜Ｄ７を用いることによって、クエリ情報Ｄ３が示すクエリ処理に必要なブロックアクセス回数を見積もり、その見積値を示すブロックアクセス回数情報Ｄ１０を作成する。出力モジュール６０は、作成されたブロックアクセス回数情報Ｄ１０を、表示装置やプリンタ等の出力装置に出力する。
【００３７】
以下、各モジュールによる処理を、更に詳細に説明する。
【００３８】
１−２．第１の処理例
図６は、本実施の形態に係る計算機負荷見積システムによる処理を示すフローチャートである。図６に示されたフローに沿って、処理の一例を説明する。入力情報Ｄ１〜Ｄ６は、図４及び図５に示されたものであるとする。レコード配置情報Ｄ５は、“ランダム配置”を示しているとする。
【００３９】
ステップＳ１〜Ｓ３：入力情報の読み込み
まず、ブロックアクセス回数見積モジュール４０は、記憶装置から入力情報Ｄ１〜Ｄ６を読み込む（ステップＳ１）。論理分布情報Ｄ２、変数分布情報Ｄ４、レコード配置情報Ｄ５のいずれかが空の場合（ステップＳ２；Ｙｅｓ）、不足情報がデフォルト情報Ｄ７から読み込まれる（ステップＳ３）。本例の場合、不足情報は無いので、処理はステップＳ１０に進む。
【００４０】
ステップＳ１０：クエリ解析処理
次に、クエリ解析モジュール１０は、データ構造情報Ｄ１とクエリ情報Ｄ３を受け取る（図３参照）。そして、クエリ解析モジュール１０は、データ構造情報Ｄ１を参照しながらクエリ情報Ｄ３が示すクエリを解析し、クエリから「アクセス種」、「ターゲット」、「スコープ」、及び「条件節」を抽出する。図４で示されたように、本例におけるクエリは、“select * from SAMPLE where COL3 between :a and :b”である。この場合、「アクセス種」は、Ｓｅｌｅｃｔ（読み出し）である。「スコープ」は、データ構造情報Ｄ１で定義されているテーブルＳＡＭＰＬＥである。「条件節」は、「データ構造情報Ｄ１で定義されている第３カラムＣＯＬ３の値が、条件変数ａとｂとの間の範囲であること」である。読み出し対象の「ターゲット」は、全カラム、すなわちレコード（行）である。
【００４１】
ステップＳ２０：選択レコード数の算出
次に、レコード数算出モジュール２０は、データ構造情報Ｄ１、論理分布情報Ｄ２、及び変数分布情報Ｄ４を受け取る（図３参照）。更に、レコード数算出モジュール２０は、クエリ解析モジュール１０から、抽出された「アクセス種」、「スコープ」、及び「条件節」を受け取る。そして、レコード数算出モジュール２０は、受け取った情報に基づいて、読み出し対象のレコードの数を統計的に見積もる。つまり、レコード数算出モジュール２０は、テーブルＳＡＭＰＬＥの複数のレコードのうち、条件変数ａ、ｂで規定される条件に適合するレコードの数を統計的に算出する。
【００４２】
図４で示された例において、変数分布情報Ｄ４は、条件変数ａが範囲０〜９９９，９９９の値を一様な確率でとることを示している。また、変数分布情報Ｄ４は、条件変数で規定される数値幅（選択幅）ｂ−ａが範囲０〜９９の値を一様な確率でとることを示している。図７は、これら条件変数ａや数値幅ｂ−ａの確率分布関数を示している。図７において、横軸は条件変数ａや数値幅ｂ−ａを示し、縦軸は確率密度ｆ（ａ）やｆ（ｂ−ａ）を示している。本例では、読み出し条件を示す数値幅ｂ−ａは０〜９９であり、その確率分布は一様である。従って、図７に示されるように、数値幅ｂ−ａの平均値は“５０”であることがわかる。すなわち、平均的に、数値幅５０に相当するレコード群がテーブルＳＡＭＰＬＥから選択されることがわかる。以下、その平均値“５０”は、「平均選択幅」と参照される。
【００４３】
また、図４で示された例において、論理分布情報Ｄ２は、第３カラムＣＯＬ３の要素が範囲０〜９９９，９９９の値を一様な確率でとることを示している。図８は、第３カラムＣＯＬ３の値の分布を概念的に示している。図８において、横軸は各レコードを示し、縦軸は第３カラムＣＯＬ３の値を示している。図８で示されるように、第３カラムＣＯＬ３の値は、０〜９９９，９９９の範囲にわたって一様に分布している。また、データ構造情報Ｄ１から、総レコード数が１００，０００であることがわかる。従って、第３カラムＣＯＬ３の数値幅１０（＝１００万／１０万）につき、平均的に１レコードが存在することがわかる。言い換えれば、１レコードあたりに第３カラムＣＯＬ３が取り得る数値幅の平均値は“１０”であることがわかる。以下、その平均値“１０”は、「レコード幅」と参照される。
【００４４】
このように、数値幅１０につき平均的に１レコードが存在する状況で、数値幅５０に相当するレコード群が選択され、読み出される。従って、本例のクエリに応じて、テーブルＳＡＭＰＬＥから平均的に５レコードが読み出されると見積もられる。この見積値“５”は、以下「選択レコード数」と参照される。レコード数算出モジュール２０は、受け取った情報を用いて上述の平均選択幅“５０”とレコード幅“１０”を算出する。そして、レコード数算出モジュール２０は、平均選択幅“５０”をレコード幅“１０”で割ることによって、選択レコード数“５”を算出することができる。算出された選択レコード数“５”が、読み出し条件に適合するレコード数の平均値であり、読み出し対象のレコード数の見積値である。
【００４５】
ステップＳ３０：ブロックアクセス回数の算出
次に、ブロックアクセス回数算出モジュール３０は、データ構造情報Ｄ１、レコード配置情報Ｄ５、及びメタデータ構造情報Ｄ６を受け取る（図３参照）。更に、ブロックアクセス回数算出モジュール３０は、レコード数算出モジュール２０から上記選択レコード数を受け取り、クエリ解析モジュール１０から「ターゲット」及び「条件節」を受け取る。そして、ブロックアクセス回数算出モジュール３０は、受け取った情報に基づいてブロックアクセス回数を算出する。具体的な処理は、次の通りである。
【００４６】
まず、データ構造情報Ｄ１から、各レコードが４バイトの数値カラムＣＯＬ１、２４バイトの文字列カラムＣＯＬ２、４バイトの数値カラムＣＯＬ３から成ることがわかる（図４参照）。つまり、１レコードのサイズは３２バイトである。また、データ構造情報Ｄ１は、１つのテーブルブロックＢＬの有効ブロックサイズが８０００バイトであることを示している。従って、１つのテーブルブロックＢＬの容量は、２５０レコード分に相当することがわかる（図５参照）。更に、データ構造情報Ｄ１は、テーブルＳＡＭＰＬＥの総レコード数が１００，０００であることを示している。従って、テーブルＳＡＭＰＬＥの全レコードを格納するために必要なテーブルブロックＢＬの総数は、“４００（＝１００，０００／２５０）”と算出される。
【００４７】
図５で示されるように、テーブルＳＡＭＰＬＥの全レコードは、４００個のテーブルブロックＢＬ−０〜ＢＬ−３９９にわたって格納されると推測される。アクセス回数算出モジュール３０は、これら４００個のテーブルブロックＢＬ−０〜ＢＬＬ−３９９のうち、クエリに応じてアクセスされるテーブルブロックＢＬの数を算出する。このとき、アクセス回数算出モジュール３０は、クエリの実行計画毎に、アクセスされるテーブルブロックＢＬの数を算出する。「実行計画」とは、クエリをどのように実行するか示すプランである。本例の読み出しクエリの場合、実行計画は、読み出し対象のデータの探索方法を意味し、その探索方法としては、「全件検索」、「索引検索」、及び「キー検索」が挙げられる。
【００４８】
ステップＳ３１：全件検索
全件検索の場合、全てのテーブルブロックＢＬ−０〜ＢＬ−３９９に対して読み出しアクセスが発生する。つまり、全件検索の場合のブロックアクセス回数は４００回である（図５参照）。アクセス回数算出モジュール３０は、テーブルブロックＢＬの総数“４００”を、全件検索の場合のブロックアクセス回数として算出する。
【００４９】
ステップＳ３２：
索引検索は、図５で示されたメタデータによるツリーインデックスを利用した検索である。アクセス回数算出モジュール３０は、今回のクエリ処理においてメタデータが利用可能かどうかを判定する。メタデータが利用不可能の場合（ステップＳ３２；Ｎｏ）、ステップＳ３０は終了する。本例の場合、メタデータ構造情報Ｄ６が入力されており、且つ、そのメタデータ構造情報Ｄ６が、「条件節」に現れる第３カラムＣＯＬ３に対してツリーインデックスが付与されていることを示している。従って、索引検索が可能である（ステップＳ３２；Ｙｅｓ）。
【００５０】
ステップＳ３３：索引検索
図５を参照して、索引検索の場合のブロックアクセス回数の算出方法を説明する。第３カラムＣＯＬ３に対して与えられるツリーインデックスにおいて、キー値は第３カラムＣＯＬ３の要素値である。その第３カラムＣＯＬ３のサイズが４バイトであることが、データ構造情報Ｄ１に示されている。また、内部アドレスポインタのサイズが６バイトであることが、メタデータ構造情報Ｄ６に示されている。従って、リーフブロックＬＢＬやブランチブロックＢＢＬの１エントリのサイズは１０バイトである。更に、メタデータ構造情報Ｄ６は、リーフブロックＬＢＬやブランチブロックＢＢＬの有効ブロックサイズが８０００バイトであることを示している。従って、リーフブロックＬＢＬやブランチブロックＢＢＬの各々は、８００個のエントリを有していることがわかる。更に、データ構造情報Ｄ１は、テーブルＳＡＭＰＬＥの総レコード数が１００，０００であることを示している。従って、その総レコード数の索引を構築するために、１２５（＝１００，０００／８００）のリーフブロックＬＢＬ−０〜ＬＢＬ−１２４が必要であることがわかる。
【００５１】
１２５個のリーフブロックＬＢＬ−０〜ＬＢＬ−１２４に対する索引は、８００エントリ有する１個のブランチブロックＢＢＬで十分である。従って、ブロックアクセス回数算出モジュール３０は、ブランチブロックＢＢＬに対するアクセス回数は“１回”であると見積もる。
【００５２】
また、本例において選択レコード数は“５”である。つまり、テーブルＳＡＭＰＬＥのうち読み出し対象のレコード数は“５”である。１つのリーフブロックＬＢＬは８００エントリ有しており、その８００エントリはキー値に基づいてソートされている。従って、読み出し対象の５レコードに対応する５エントリは、ある１つのリーフブロックＬＢＬ−ｍ内に含まれている確率が極めて高い。従って、ブロックアクセス回数算出モジュール３０は、リーフブロックＬＢＬに対するアクセス回数は“１回”であると見積もる。
【００５３】
また、本例において、レコード配置情報Ｄ５は、「各レコードは、第３カラムＣＯＬ３の値に拘わらずランダムに配置される」という“ランダム配置”を示す。よって、読み出し対象の５レコードは、４００個のテーブルブロックＢＬ−０〜ＢＬ−３９９のうち互いに異なる５個のテーブルブロックＢＬに記録されている確率が極めて高い。従って、ブロックアクセス回数算出モジュール３０は、テーブルブロックＢＬに対するアクセス回数は“５回”であると見積もる。
【００５４】
このように、索引検索の場合、１個のブランチブロックＢＢＬ、１個のリーフブロックＬＢＬ、及び５個のテーブルブロックＢＬに対して、合計７回の読み出しアクセスが発生する（図５参照）。すなわち、ブロックアクセス回数算出モジュール３０は、索引検索の場合のブロックアクセス回数を“合計７回”と算出する。これは、メタデータが格納されるブロックへのアクセス回数と上述の選択レコード数との和に相当する。
【００５５】
ステップＳ３４：キー検索
メタデータが利用可能であり、且つ、クエリの「ターゲット」がツリーインデックスのキー値そのものであれば、キー検索を実行することが可能である。キー検索の場合、テーブルブロックＢＬまでアクセスする必要はなく、リーフブロックＬＢＬまでのアクセスでターゲットを読み出すことが可能である。本例の場合、クエリの「ターゲット」が全カラムであるため、ブロックアクセス回数算出モジュール３０は、キー検索は不可能であると判断する。もし、「ターゲット」が全カラムではなく第３カラムＣＯＬ３であれば、ブロックアクセス回数は“合計２回”となる。
【００５６】
以上に説明されたように、ブロックアクセス回数算出モジュール３０は、クエリの実行計画毎にブロックアクセス回数を算出する。このブロックアクセス回数が、データベースアクセス時の計算機システムの負荷に相当する。ブロックアクセス回数算出モジュール３０は、負荷の観点から最適な実行計画を選択してもよい。本例の場合、最適な実行計画は、ブロックアクセス回数が７回である索引検索である。
【００５７】
ステップＳ４０：ブロックアクセス回数情報
このようにして、ブロックアクセス回数見積モジュール４０は、クエリ情報Ｄ３が示すクエリに伴って発生するブロックアクセスの回数を見積もる。結果として、見積もられたブロックアクセス回数を示すブロックアクセス回数情報Ｄ１０が作成される。図９は、本例において作成されるブロックアクセス回数情報Ｄ１０を示している。ブロックアクセス回数情報Ｄ１０は、実行計画毎に見積もられたブロックアクセス回数を示している。また、ブロックアクセス回数情報Ｄ１０は、最適な実行計画が索引検索であることも示している。
【００５８】
ステップＳ６０：出力
出力モジュール６０は、ブロックアクセス回数情報Ｄ１０を、ディスプレイやプリンタといった出力装置に出力する。以上に説明された処理フローは、クエリごとに実行される。結果として、多数のクエリに関して、ブロックアクセス回数情報Ｄ１０が得られる。
【００５９】
１−３．第２の処理例
次に、他の処理例を説明する。第２の処理例では、第１の処理例とは異なる論理分布情報Ｄ２と変数分布情報Ｄ４が入力される。それ以外の入力情報は、第１の処理例と同じである。
【００６０】
図１０は、既出の図７に対応する図であり、本例における変数分布情報Ｄ４を概念的に示している。本例において、変数分布情報Ｄ４は、（１）条件変数ａが範囲０〜２４９，９９９の値をとる確率が０．５であり、その確率分布が一様であること、（２）条件変数ａが範囲２５０，０００〜９９９，９９９の値をとる確率が０．５であり、その確率分布が一様であること、及び（３）数値幅（選択幅）ｂ−ａが範囲０〜９９の値を一様な確率でとることを示している。第１の処理例の場合と同様に、数値幅ｂ−ａの平均値、すなわち、「平均選択幅」は５０である。
【００６１】
図１１は、既出の図８に対応する図であり、本例における論理分布情報Ｄ２を概念的に示している。本例において、論理分布情報Ｄ２は、（１）第３カラムＣＯＬ３の要素が０〜４９９，９９９の値をとる確率が０．２であり、その確率分布が一様であること、及び（２）第３カラムＣＯＬ３の要素が５００，０００〜９９９，９９９の値をとる確率が０．８であり、その確率分布が一様であること、を示している。つまり、図１１に示されるように、第３カラムＣＯＬ３の大多数は５００，０００〜９９９，９９９の値を取り、残りが０〜４９９，９９９の値を取る。言い換えれば、値０〜４９９，９９９は全１０万レコードのうち２万レコードだけで分担され、値５００，０００〜９９９，９９９は全１０万レコードのうち８万レコードで分担される。従って、範囲０〜４９９，９９９の場合、レコード幅は２５（＝５０万／２万）であり、範囲５００，０００〜９９９，９９９の場合、レコード幅は６．２５（＝５０万／８万）である。
【００６２】
この場合、ステップＳ２０の処理結果が、第１の処理例と異なってくる。ステップＳ２０において、レコード数算出モジュール２０は、平均選択幅をレコード幅で割ることによって選択レコード数を算出する。図１０で示されるように、条件変数ａが範囲０〜２４９，９９９の値をとる確率は０．５であり、その場合の選択レコード数は“０．５×（５０／２５）＝１”と算出される。同様に、条件変数ａが範囲２５０，０００〜４９９，９９９の値をとる確率は０．５／３であり、その場合の選択レコード数は“０．５／３×（５０／２５）＝１／３”と算出される。条件変数ａが範囲５００，０００〜９９９，９９９の値をとる確率は０．５×２／３であり、その場合の選択レコード数は“０．５×２／３×（５０／６．２５）＝８／３”と算出される。従って、選択レコード数の合計は“４（＝１＋１／３＋８／３）”となる。つまり、レコード数算出モジュール２０は、クエリに応じてテーブルＳＡＭＰＬＥから平均的に４レコードが読み出されると見積もる。
【００６３】
その後の処理は、第１の処理例と同じである。図１２は、本例において作成されるブロックアクセス回数情報Ｄ１０を示している。本例の場合、索引検索の場合のブロックアクセス回数は“合計６回”と見積もられている。
【００６４】
１−４．第３の処理例
更に他の処理例を説明する。第３の処理例では、レコード配置情報Ｄ５は、「テーブルＳＡＭＰＬＥの各レコードは、第３カラムＣＯＬ３の値順にシーケンシャルに配置される」という“シーケンシャル配置”を示す。それ以外の入力情報は、第１の処理例と同じである。従って、ステップＳ２０において、レコード数算出モジュール２０は、選択レコード数“５”を算出する。ステップＳ３０中、索引検索の場合のブロックアクセス回数の算出処理（ステップＳ３３）の結果が、第１の処理例と異なってくる。
【００６５】
ランダム配置の場合、読み出し対象の５レコードはそれぞれ異なるテーブルブロックＢＬへ配置されると推測されるため、テーブルブロックＢＬへのアクセス回数は、選択レコード数と同じ５回と見積もられた。一方、シーケンシャル配置の場合、読み出し対象の５レコードは連続的に配置されるため、テーブルブロックＢＬへのアクセス回数はより少なくなるはずである。図１３は、本例における読み出し対象の５レコードの様々な配置例を示している。図１３中、２つのテーブルブロックＢＬ１、ＢＬ２が示されている。上述の通り、各テーブルブロックは、２５０レコード分の記憶領域を有している（図５参照）。
【００６６】
図１３中のパターン（Ａ）の場合、５レコードは、テーブルブロックＢＬ１中の第１〜第５記憶領域に配置されている。パターン（Ｃ）の場合、５レコードは、テーブルブロックＢＬ１の第２４６〜第２５０記憶領域に配置されている。パターン（Ｂ）は、パターン（Ａ）とパターン（Ｃ）の中間のパターンである。これらパターン（Ａ）〜パターン（Ｃ）の場合、読み出し対象の５レコードは、１つのテーブルブロックＢＬ１に配置される。つまり、テーブルブロックＢＬへのアクセス回数は１回である。
【００６７】
一方、図１３中のパターン（Ｄ）の場合、５レコードは、テーブルブロックＢＬ１中の第２４７〜第２５０記憶領域とテーブルブロックＢＬ２中の第１記憶領域に配置されている。パターン（Ｅ）の場合、５レコードは、テーブルブロックＢＬ１中の第２５０記憶領域とテーブルブロックＢＬ２中の第１記憶領域〜第４記憶領域に配置されている。これらパターン（Ｄ）、（Ｅ）の場合、読み出し対象の５レコードは、２つのテーブルブロックＢＬ１、ＢＬ２に配置される。つまり、テーブルブロックＢＬへのアクセス回数は２回である。
【００６８】
図１３から明らかなように、テーブルブロックＢＬへのアクセス回数が１回であるパターンは２４６種類存在し、２回であるパターンは４種類存在する。従って、テーブルブロックＢＬへのアクセス回数の“平均値（期待値）”は、式：１×２４６／２５０＋２×４／２５０から“１．０１６”と算出される。
【００６９】
上記式を一般化すると次の通りである。ここで、１テーブルブロックＢＬあたりの総レコード数（２５０）を“Ａ１”とする。また、選択レコード数（５）を“Ａ２”とする。更に、テーブルブロックＢＬへのアクセス回数の平均値（１．０１６）を“Ａ３”とする。この場合、上記式はＡ３＝１×（Ａ１−（Ａ２−１））／Ａ１＋２×（Ａ２−１）／Ａ１と表される。この式を整理することにより、次の式が得られる。
【００７０】
Ａ３＝１＋（Ａ２−１）／Ａ１
【００７１】
この式から分かるように、選択レコード数Ａ２が１の場合、テーブルブロックＢＬへのアクセス回数の期待値Ａ３は１である。右辺の定数項「１」は、選択レコードが存在する以上、少なくとも１回のアクセスが存在することを意味する。選択レコード数Ａ２が増加するにつれて、期待値Ａ３も増加する。
【００７２】
ブロックアクセス回数算出モジュール３０は、上記式に基づいて、テーブルブロックＢＬへのアクセス回数の期待値Ａ３を算出する。更に、ブロックアクセス回数算出モジュール３０は、算出された期待値Ａ３に、メタデータが格納されるブロックへのアクセス回数（２回）を加算する。結果として得られる値３．０１６（＝１．０１６＋２）が、索引検索の場合のブロックアクセス回数である。その他の処理は、第１の処理例と同じである。図１４は、本例において作成されるブロックアクセス回数情報Ｄ１０を示している。
【００７３】
１−５．第４の処理例
更に他の処理例を説明する。第４の処理例では、レコード配置情報Ｄ５は、“ランダム配置”と“シーケンシャル配置”の両方を指定する。それ以外の入力情報は、第１の処理例と同じである。本例の場合、ランダム配置とシーケンシャル配置の双方の場合のブロックアクセス回数が一度に算出される。図１５は、本例において作成されるブロックアクセス回数情報Ｄ１０を示している。索引検索が行われる際のブロックアクセス回数は、ランダム配置の場合に最大となり、シーケンシャル配置の場合に最小となる。従って、本例では、索引検索の場合のブロックアクセス回数の分布範囲が得られると言える。
【００７４】
１−６．第５の処理例
更に他の処理例を説明する。第５の処理例では、レコード配置情報Ｄ５は、“ランダム配置”な度合いと“シーケンシャル配置”な度合いを示すパラメータＰを示す。このパラメータＰは、テーブルブロックＢＬへのアクセス回数Ａ３を補正するパラメータである。ランダム配置の場合のアクセス回数Ａ３（５回）をＭＡＸとし、シーケンシャル配置の場合のアクセス回数Ａ３（１．０１６回）をＭＩＮとする。本例では、アクセス回数Ａ３は、式：ＭＩＮ＋（ＭＡＸ−ＭＩＮ）×Ｐで算出される（０≦Ｐ≦１）。
【００７５】
１−７．効果
以上に説明されたように、本実施の形態によれば、クエリ処理に伴って発生するブロックアクセス回数を見積もることが可能となる。その処理において、テーブルの各要素は未定であってよい。テーブルの構造を示す情報や、要素及びクエリに関する統計的な情報を利用することにより、ブロックアクセス回数を簡単に見積もることができる。クエリ処理におけるフェッチの負荷量は、ブロックアクセス回数に大きく依存する。従って、ブロックアクセス回数を見積もることは、フェッチの負荷量を見積もることと等価である。
【００７６】
例えば、計算機システムの構築前には、実際のテーブルの要素値を知ることはできない。そのような場合であっても、ブロックアクセス回数やフェッチ負荷量を見積もることが可能である。もし、計算機システムの構築後に、フェッチ負荷量が適正値を超えていることが発覚した場合、計算機システムを再度構築し直す必要がある。本実施の形態によれば、あらかじめブロックアクセス回数やフェッチ負荷量を予測することにより、そのような事態を回避することが可能となる。従って、設計者の負担が軽減される。
【００７７】
また例えば、計算機システムが使用不可能な場合にも、本実施の形態は適用可能である。あるいは、本実施の形態は、データベースが巨大な場合にも有効である。データベースが巨大な場合、実際のテーブルを参照してブロックアクセス回数を測定するためには非常に長い時間を要する。本実施の形態によれば、ブロックアクセス回数を簡便に、且つ、短時間で見積もることが可能となる。
【００７８】
ブロックアクセス回数は、クエリの内容によって大きく異なる。多数のクエリに関して本実施の形態に係る処理を適用することにより、負荷量が大きくなるクエリを検知することが可能となる。言い換えれば、計算機資源を多量に消費し、性能不足の要因となり得る負荷量の大きいクエリを特定することが可能となる。設計者は、特定されたクエリによる負荷量が軽減されるように、データベースの設計仕様（例えばメタデータ構造）を変更することができる。あるいは、設計者は、負荷量の大きいクエリも処理できるように、計算機システムを設計することもできる。また、本実施の形態によれば、クエリの実行計画毎にブロックアクセス回数が見積もられ出力される。これにより、どの実行計画を採用するか比較検討することが可能となる。
【００７９】
２．第２の実施の形態
本発明の第２の実施の形態では、第１の実施の形態で予想されたブロックアクセス回数から、更にクエリ処理の負荷量や計算機システムの処理性能が見積もられる。第１の実施の形態と同様の構成には同じ符号が付され、重複する説明は省略される。
【００８０】
２−１．構成
図１６は、第２の実施の形態に係る計算機負荷見積システムの構成を示すブロック図である。本実施の形態に係る計算機負荷見積システムは、第１の実施の形態における構成に加えて、性能見積モジュール５０を備えている。その性能見積モジュール５０には、ブロックアクセス回数情報Ｄ１０と負荷量情報Ｄ８が入力される。場合によっては、デフォルト負荷量情報Ｄ９が入力される。
【００８１】
図１７は、負荷量情報Ｄ８の一例を示している。負荷量情報Ｄ８は、１ブロックに対するアクセス（フェッチ）に要する計算機負荷と、その他の処理に要する計算機負荷を示す。計算機負荷は、例えばＣＰＵ時間で与えられる。例えば図１７において、負荷量情報Ｄ８は、（１）１ブロックアクセスあたりのＣＰＵ時間が０．００１ｍｓであること、及び（２）その他の処理に対するＣＰＵ時間が０．１ｍｓであることを示している。この負荷量情報Ｄ８は、例えば、設計仕様書や運用中の計算機システムの運用情報から得られる。また、この負荷量情報Ｄ８は、所定の記憶装置に格納される。
【００８２】
デフォルト負荷量情報Ｄ９は、計算機負荷のデフォルト設定を示す。負荷量情報Ｄ８が特に指定されていない場合、デフォルト負荷量情報Ｄ９が負荷量情報Ｄ８として用いられる。
【００８３】
２−２．処理例
図１８は、本実施の形態に係る計算機負荷見積システムによる処理を示すフローチャートである。図１６〜図１８を参照して、本実施の形態における処理の一例を説明する。負荷量情報Ｄ８は、図１７で示されたものであるとする。
【００８４】
ステップＳ１〜Ｓ４０：
まず、第１の実施の形態と同様に、ブロックアクセス回数見積モジュール４０が、入力情報Ｄ１〜Ｄ６に基づいて、ブロックアクセス回数情報Ｄ１０を作成する。作成されるブロックアクセス回数情報Ｄ１０は、例えば、上述の第１の処理例で作成されたものと同じであるとする（図９参照）。当然、他の処理例で作成されるブロックアクセス回数情報でもよい。
【００８５】
ステップＳ５０：
次に、図１６に示されるように、性能見積モジュール５０は、記憶装置からブロックアクセス回数情報Ｄ１０及び負荷量情報Ｄ８を読み込む（ステップＳ５１）。負荷量情報Ｄ８が空の場合（ステップＳ５２；Ｙｅｓ）、デフォルト負荷量情報Ｄ９が読み込まれる（ステップＳ５３）。本例の場合、負荷量情報Ｄ８が与えられているので（ステップＳ５２；Ｎｏ）、処理はステップＳ５４に進む。
【００８６】
ステップＳ５４：
性能見積モジュール５０は、ブロックアクセス回数情報Ｄ１０が示すブロックアクセス回数と、負荷量情報Ｄ８が示す１ブロックアクセスあたりのＣＰＵ時間との乗算を行う。その乗算により得られる値は、フェッチのＣＰＵ時間に相当する。更に、性能見積モジュール５０は、算出されたフェッチのＣＰＵ時間に、負荷量情報Ｄ８が示すその他の処理に対するＣＰＵ時間を加える。その加算により得られる値が、１つのクエリ処理に要するＣＰＵ時間である。また、性能見積モジュール５０は、算出されたＣＰＵ時間に基づいて、計算機システムの処理性能（例えばスループット）を算出する。
【００８７】
例えば、全件検索の場合、ブロックアクセス回数は“４００”である。従って、フェッチのＣＰＵ時間は０．４ｍｓ（＝０．００１ｍｓ×４００）と算出される。クエリ処理のＣＰＵ時間は０．５ｍｓ（＝０．４ｍｓ＋０．１ｍｓ）と算出される。スループットは２０００ｔｐｓ（＝１０００／０．５ｍｓ）である。
【００８８】
また、索引検索の場合、ブロックアクセス回数は“７”である。従って、フェッチのＣＰＵ時間は０．００７ｍｓ（＝０．００１ｍｓ×７）と算出される。クエリ処理のＣＰＵ時間は０．１０７ｍｓ（＝０．００７ｍｓ＋０．１ｍｓ）と算出される。スループットは９３４５ｔｐｓ（＝１０００／０．１０７ｍｓ）である。
【００８９】
このようにして、性能見積モジュール５０は、ブロックアクセス回数情報Ｄ１０と負荷量情報Ｄ８に基づいて、クエリ処理に必要なＣＰＵ時間（負荷量）やクエリ処理のスループットを算出する。算出されたＣＰＵ時間やスループットが、計算機システムの「性能指標」である。性能見積モジュール５０は、得られた性能指標を示す性能指標情報Ｄ２０を作成する。図１９は、本例において作成される性能指標情報Ｄ２０を示している。図１９において、性能指標情報Ｄ２０は、実行計画毎に、ブロックアクセス回数、ＣＰＵ時間、及びスループットを示している。また、性能指標情報Ｄ２０は、最適な実行計画が索引検索であることも示している。
【００９０】
ステップＳ６０：出力
出力モジュール６０は、性能指標情報Ｄ２０を、ディスプレイやプリンタといった出力装置に出力する。以上に説明された処理フローは、クエリごとに実行される。結果として、使用予定の多数のクエリに関して、ブロックアクセス回数や性能指標が得られる。
【００９１】
２−３．効果
本実施の形態によれば、第１の実施の形態と同じ効果が得られる。更に、クエリ処理の負荷量や計算機システムの性能指標を見積もることが可能となる。
【００９２】
３．計算機負荷見積システム
以上に説明された計算機負荷見積システムは、コンピュータシステムにより実現される。図２０は、計算機負荷見積システム１００の構成の一例を示している。計算機負荷見積システム１００は、プロセッサ１１０、記憶装置１２０、入力装置１３０、出力装置１４０、ネットワークインタフェース１５０、及びメディアドライブ１６０を備えている。プロセッサ１１０はＣＰＵを含み、各種処理を行う。記憶装置１２０として、ＲＡＭやハードディスクが例示される。入力装置１３０として、キーボードやマウスが例示される。出力装置１４０として、表示装置やプリンタが例示される。
【００９３】
記憶装置１２０には、上述のデータ構造情報Ｄ１、論理分布情報Ｄ２、クエリ情報Ｄ３、変数分布情報Ｄ４、レコード配置情報Ｄ５、メタデータ構造情報Ｄ６、デフォルト情報Ｄ７、負荷量情報Ｄ８、デフォルト負荷量情報Ｄ９が格納される。それら情報Ｄ１〜Ｄ９は、入力装置１３０により入力されてもよいし、ネットワークインタフェース１５０を介して提供されてもよい。また、記憶装置１２０は、本実施の形態に係る処理フローにより作成されるブロックアクセス回数情報Ｄ１０や性能指標情報Ｄ２０が格納される。
【００９４】
記憶装置１２０には更に、計算機負荷見積プログラムＰＲＯが格納される。この計算機負荷見積プログラムＰＲＯは、プロセッサ１１０によって実行されるソフトウエアである。計算機負荷見積プログラムＰＲＯは、例えば、コンピュータ読み取り可能な記録媒体に記録されており、メディアドライブ１６０によって読み込まれる。
【００９５】
プロセッサ１１０は、計算機負荷見積プログラムＰＲＯを実行することによって、本発明に係る処理を実現する。つまり、プロセッサ１１０と計算機負荷見積プログラムＰＲＯとの協働により、上述のクエリ解析モジュール１０、レコード数算出モジュール２０、ブロックアクセス回数算出モジュール３０、ブロックアクセス回数見積モジュール４０、性能見積モジュール５０、及び出力モジュール６０が提供される。各モジュールは、必要な情報を記憶装置１２０から読み出し、上述の処理を実現する。出力モジュール６０は、作成されたブロックアクセス回数情報Ｄ１０や性能指標情報Ｄ２０を、出力装置１４０に出力させる。このようにして、本発明に係る処理が実現される。
【図面の簡単な説明】
【００９６】
【図１】図１は、一般的なクエリ処理を説明するための概念図である。
【図２】図２は、一般的なブロックアクセスを説明するための概念図である。
【図３】図３は、本発明の第１の実施の形態に係る計算機負荷見積システムの構成を示すブロック図である。
【図４】図４は、第１の処理例を説明するための概念図である。
【図５】図５は、第１の処理例を説明するための概念図である。
【図６】図６は、第１の実施の形態に係る計算機負荷見積方法を示すフローチャートである。
【図７】図７は、第１の処理例を説明するための概念図である。
【図８】図８は、第１の処理例を説明するための概念図である。
【図９】図９は、第１の処理例において得られるブロックアクセス回数情報を示すテーブルである。
【図１０】図１０は、第２の処理例を説明するための概念図である。
【図１１】図１１は、第２の処理例を説明するための概念図である。
【図１２】図１２は、第２の処理例において得られるブロックアクセス回数情報を示すテーブルである。
【図１３】図１３は、第３の処理例を説明するための概念図である。
【図１４】図１４は、第３の処理例において得られるブロックアクセス回数情報を示すテーブルである。
【図１５】図１５は、第４の処理例において得られるブロックアクセス回数情報を示すテーブルである。
【図１６】図１６は、本発明の第２の実施の形態に係る計算機負荷見積システムの構成を示すブロック図である。
【図１７】図１７は、負荷量情報を示す図である。
【図１８】図１８は、第２の実施の形態に係る計算機負荷見積方法を示すフローチャートである。
【図１９】図１９は、性能指標情報を示すテーブルである。
【図２０】図２０は、本発明の実施の形態に係る計算機負荷見積システムの構成を示すブロック図である。
【符号の説明】
【００９７】
１０    クエリ解析モジュール
２０    レコード数算出モジュール
３０    ブロックアクセス回数算出モジュール
４０    ブロックアクセス回数見積モジュール
５０    性能見積モジュール
６０    出力モジュール
Ｄ１    データ構造情報
Ｄ２    論理分布情報
Ｄ３    クエリ情報
Ｄ４    変数分布情報
Ｄ５    レコード配置情報
Ｄ６    メタデータ構造情報
Ｄ７    デフォルト情報
Ｄ８    負荷量情報
Ｄ９    デフォルト負荷量情報
Ｄ１０    ブロックアクセス回数情報
Ｄ２０    性能指標情報
１００    計算機負荷見積システム
１１０    プロセッサ
１２０    記憶装置
１３０    入力装置
１４０    出力装置
１５０    ネットワークインタフェース
１６０    メディアドライブ
ＰＲＯ    計算機負荷見積プログラム
【図１】
2008225575.tif 000003
【図２】
2008225575.tif 000004
【図３】
2008225575.tif 000005
【図４】
2008225575.tif 000006
【図５】
2008225575.tif 000007
【図６】
2008225575.tif 000008
【図７】
2008225575.tif 000009
【図８】
2008225575.tif 000010
【図９】
2008225575.tif 000011
【図１０】
2008225575.tif 000012
【図１１】
2008225575.tif 000013
【図１２】
2008225575.tif 000014
【図１３】
2008225575.tif 000015
【図１４】
2008225575.tif 000016
【図１５】
2008225575.tif 000017
【図１６】
2008225575.tif 000018
【図１７】
2008225575.tif 000019
【図１８】
2008225575.tif 000020
【図１９】
2008225575.tif 000021
【図２０】
2008225575.tif 000022