JPWO2015029208A1 - データベース管理装置、データベース管理方法及び記憶媒体 - Google Patents

Abstract

プロセッサとメモリとストレージ装置を備えて、ストレージ装置に格納されたデータベースを管理するデータベース管理装置であって、データベースへのクエリを受け付けるクエリ受付部と、受け付けたクエリを実行するために必要なデータベースオペレーションを含むクエリ実行プランを生成するクエリ実行プラン生成部と、生成したクエリ実行プランに基づいて受け付けたクエリを実行する際に、データベースオペレーションを実行するためのタスクを動的に生成し、前記動的に生成されたタスクを実行するクエリ実行部と、を有し、クエリ実行部は、リソースの利用状況を取得して、次のデータベースオペレーションを実行する場合には、リソースの利用状況に基づいて新たなタスクを生成し、当該新たなタスクを前記タスクと並列して実行する。

Description

本発明は、データ管理技術に関する。

企業活動において、大量に生じる業務データの活用は不可欠になっている。そのため、大量の業務データを蓄積したデータベース（以下、「ＤＢ」）を解析処理するシステムが既に考案されている。

この解析処理において、データベース管理システム（以下、「ＤＢＭＳ」）は、クエリを受け付け、ＤＢを格納する記憶デバイスにデータ読出し要求を発行する。

１つのクエリの処理におけるデータ読出しの待ち時間の短縮化を図る技術として、特許文献１に開示される技術が知られている。特許文献１によれば、ＤＢＭＳは、クエリを実行するために必要な複数のデータベースオペレーション（ＤＢオペレーション、または、処理ステップと呼ぶ）を組合せたプラン（以下、クエリ実行プラン）を生成し、前記処理ステップを実行するタスクを動的に生成し、前記タスクを並行実行することでデータ読出し要求を多重化する。特許文献１によれば、ＤＢＭＳは、所定数まではタスクを増加させ、その後所定数を維持するようタスクを生成する。

特開２００７−３４４１４号公報

近年、計算機の高性能化が進んでいる。例えば、演算を行うコア（これをプロセッサコアと呼ぶ）を複数搭載したプロセッサが一般化しており、計算機はこのようなプロセッサを複数搭載することで複数のプロセッサコアを持つ。ストレージ装置では、従来は直接ハードディスクドライブ（ＨＤＤ）を接続していたが、ＨＤＤを複数搭載したストレージ装置を高速ネットワークで接続した形態も一般化している。

タスクを動的に生成するＤＢＭＳは、複数のタスクを実行することで、計算機のＣＰＵリソースやＩ／Ｏリソース、メモリリソースなどのクエリの実行に利用されるリソースを活用し、クエリの処理時間を短縮している。Ｉ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）とは、計算機がネットワークによって接続している外部の装置（例えば、ストレージ装置や別の計算機）からデータを入力する、または計算機が外部の装置へデータを出力する動作のことである。Ｉ／Ｏ要求とは外部装置からの入力要求又は外部装置への出力要求のことであり、例えば、ＤＢＭＳを実行する計算機から外部装置へ発行される。ストレージ装置へ発行されるＩ／Ｏ要求は、ストレージ装置からの入力要求又はストレージ装置への出力要求となる。別計算機へ発行されるＩ／Ｏ要求は、別計算機からの入力要求又は別計算機への出力要求となる。

しかし、前記従来の技術において、タスクを動的に生成するＤＢＭＳでは、タスクの数を指定する必要があり、前記従来のＤＢＭＳでは、タスク数の指定を誤るとＣＰＵリソース、メモリリソース、又はＩ／Ｏリソースなどのリソースを有効に活用できず、クエリの処理時間を短縮できないといった問題があった。

また、前記従来のＤＢＭＳは、クエリごとに処理が変わりＣＰＵリソース、メモリリソース、又はＩ／Ｏリソースなどの使い方が異なる。このため、単にタスクの数を適切に設定しても、ＣＰＵリソース、メモリリソース、又はＩ／Ｏリソースを十分に使えない場合もあった。

そこで、本発明の目的は、タスクを動的に生成するＤＢＭＳが、ＣＰＵリソース、メモリリソース、又はＩ／Ｏリソースなどのリソースを有効に活用できるようタスクの生成を制御することである。

ここでＣＰＵリソースとは、ＣＰＵ（プロセッサコア）またはＣＰＵの処理能力のことをいい、ＤＢＭＳによるＤＢオペレーションが割り当てられたタスクの実行処理によって消費される。

また、メモリリソースとは、計算機に搭載されたメモリ（空き記憶領域）のことをいい、タスクがメモリにデータを記憶することで消費される。

Ｉ／Ｏリソースとは、ＤＢＭＳにおけるタスクの実行により発行されるＩ／Ｏ要求の性能（データ読出しの待ち時間など）に影響を与えるリソースのことをいい、例えば、計算機、ストレージ装置、若しくは計算機とストレージとを接続するネットワークなど、又は、計算機、ストレージ装置、若しくはネットワークなどの性能がＩ／Ｏリソースにあたる。具体的には、計算機がネットワークに接続するためのネットワークアダプタの性能であったり、Ｉ／Ｏ要求やそのＩ／Ｏ要求に対するデータを転送するネットワークのケーブルの性能（帯域幅など）である。他には、計算機から発行されたＩ／Ｏ要求をストレージ装置で処理するためにストレージ装置がネットワークに接続するためのネットワークアダプタの性能であったり、ストレージ装置でＩ／Ｏ要求を処理するためのプロセッサの処理能力、データを記録するためのＨＤＤの容量などがＩ／Ｏリソースにあたる。これらのＩ／Ｏリソースにおいて、ネットワークアダプタが同時に発行できるＩ／Ｏ要求の数であったり、ネットワークケーブルのデータ転送速度の上限であったり、Ｉ／Ｏ要求を処理するＨＤＤの数などがＩ／Ｏ性能に影響を与える。これらのＩ／Ｏリソースは、ＤＢＭＳにおけるタスクの実行によりＩ／Ｏ要求を処理する際に消費される。

本発明は、ストレージ装置に格納されたデータベースを管理するデータベース管理装置であって、データベースへのクエリを受け付けるクエリ受付部と、受け付けたクエリを実行するために必要な１以上のデータベースオペレーションを表す情報を含むクエリ実行プランを生成するクエリ実行プラン生成部と、生成したクエリ実行プランに基づいて受け付けたクエリを実行する際に、データベースオペレーションを実行するためのタスクを動的に生成し、動的に生成されたタスクを実行するクエリ実行部と、を有し、クエリ実行部は、受け付けたクエリの実行に利用されるリソースの利用状況を取得し、生成されたタスクで実行されるデータベースオペレーションの次のデータベースオペレーションを実行する場合には、リソースの利用状況に基づいて新たなタスクを生成し、新たなタスクを他のタスクと並列して実行するものである。

本発明によれば、タスクを動的に生成するデータベース管理装置において、ＣＰＵリソース、メモリリソース、又はＩ／Ｏリソースなどのクエリの実行に利用されるリソースの利用が十分になるようタスクを生成することが可能となる。また、データベース管理装置がタスクを生成する際には、利用が不十分なリソースを活用するタスクを生成することにより、ＣＰＵリソース、メモリリソース、又はＩ／Ｏリソースなどのクエリの実行に利用されるリソースの利用率を向上させることが可能となる。

本発明の実施例１を示し、計算機システムの一例を示すブロック図である。 本発明の実施例１を示し、ＤＢＭＳの一例を示すブロック図である。 本発明の実施例１を示し、データベースの表及び索引の定義を説明する図である。 本発明の実施例１を示し、データベースのＰａｒｔ表の一例を示す図である。 本発明の実施例１を示し、データベースのＬｉｎｅｉｔｅｍ表の一例を示す図である。 本発明の実施例１を示し、データベースの第一のクエリの一例を示す図である。 本発明の実施例１を示し、データベースのＰａｒｔ索引のデータ構造の一例を説明する図である。 本発明の実施例１を示し、データベースでＰａｒｔ索引のキー値＝１３０におけるＲｏｗＩＤを保持するデータ構造の一例を説明する図である。 本発明の実施例１を示し、データベースを構成するＰａｒｔ表のキー値＝１３０におけるデータ構造の一例を説明する図である。 本発明の実施例１を示し、データベースの記憶領域１〜４への配置の一例を説明する図である。 本発明の実施例１を示し、ＤＢ領域管理表の一例を示す図である。 本発明の実施例１を示し、クエリ実行プランの一例を示す図である。 本発明の実施例１を示し、各処理ステップでのＣＰＵコストを設定したコストテーブルの一例を示す図である。 本発明の実施例１を示し、タスク実行状態情報の一例を示す図である。 本発明の実施例１を示し、処理ステップ実行状態情報の第１の例を示す図である。 本発明の実施例１を示し、処理ステップ実行状態情報の第２の例を示す図である。 本発明の実施例１を示し、処理ステップ実行状態情報の第３の例を示す図である。 本発明の実施例１を示し、タスク管理情報のデータ構造の一例を示す図である。 本発明の実施例１を示し、コンテキストの一例を示す図である。 本発明の実施例１を示し、生成された第１のコンテキストの一例を示す図である。 本発明の実施例１を示し、生成された第２のコンテキストの一例を示す図である。 本発明の実施例１を示し、クエリを受け付けてから結果を応答するまでの処理全体を示すフローチャートである。 本発明の実施例１を示し、クエリ実行処理のフローチャートである。 本発明の実施例１を示し、タスク実行処理のフローチャートである。 本発明の実施例１を示し、処理ステップ実行処理のフローチャートである。 本発明の実施例１を示し、コンテキスト生成処理のフローチャートである。 本発明の実施例１を示し、ＤＢのページ取得処理のフローチャートである。 本発明の実施例１を示し、システム性能閾値表の一例を示す図である。 本発明の実施例１を示し、性能データ表の一例を示す図である。 本発明の実施例１を示し、タスク生成処理のフローチャートである。 本発明の実施例１を示し、記憶領域性能データ表の一例を示す図である。 本発明の実施例１を示し、コンテキスト取得処理のフローチャートである。 本発明の実施例１を示し、記憶領域性能閾値表の一例を示す図である。 本発明の実施例２を示し、コンテキスト取得処理のフローチャートである。 本発明の実施例３を示し、データベースの第二のクエリの一例を示す図である。 本発明の実施例３を示し、クエリ実行プランの一例を説明する図である。 本発明の実施例３を示し、各処理ステップにおけるＣＰＵコストの一例を示す図である。 本発明の実施例３を示し、第５のコンテキストの一例を示す図である。 本発明の実施例３を示し、第６のコンテキストの一例を示す図である。 本発明の実施例３を示し、第７のコンテキストの一例を示す図である。 本発明の実施例３を示し、コンテキスト取得処理のフローチャートである。 本発明の実施例４を示し、コンテキスト取得処理のフローチャートである。 本発明の実施例５を示し、コンテキスト取得処理のフローチャートである。 本発明の実施例６を示し、計算機システムの一例を示すブロック図である。 本発明の実施例６を示し、ＤＢ領域管理表の一例を示す図である。 本発明の実施例６を示し、第８のコンテキストの一例を示す図である。 本発明の実施例６を示し、第９のコンテキストの一例を示す図である。 本発明の実施例６を示し、タスク実行処理のフローチャートである。 本発明の実施例６を示し、コンテキスト取得処理のフローチャートである。 本発明の実施例７を示し、計算機システムの一例を示すブロック図である。

以下、図面を用いて実施例１を説明する。

図１Ａは、本発明の実施例１に係る計算機システムの一例を示すブロック図である。また、図１Ｂは、計算機１００で実行されるＤＢＭＳの一例を示すブロック図である。

計算機システムは、計算機１００と、外部ストレージ装置２００とを有する。計算機１００と、外部ストレージ装置２００とは、通信ネットワーク３００を介して接続されている。通信ネットワーク３００を介した通信のプロトコルとしては、例えば、ＦＣ（Fibre Channel）、ＳＣＳＩ（Small Computer System Interface）、ＩＢ（Infini Band）、又は、ＴＣＰ／ＩＰ（Transmission Control Protocol／Internet Protocol）等を採用することができる。

計算機１００は、例えば、パーソナルコンピュータや、ワークステーション又はメインフレームである。計算機１００は、ネットワークアダプタ１１０と、プロセッサ（典型的にはマイクロプロセッサ（例えばＣＰＵ（Central Processing Unit）））１２０と、ローカル記憶デバイス１３０と、メモリ１４０を有する。

プロセッサ１２０は、コンピュータプログラム、例えば、図示しないＯＳ（Operating System）や、ＤＢＭＳ（Data Base Management System）１４１を実行する。１又は複数のプロセッサ１２０は、１又は複数のプロセッサコアを有する。各プロセッサコアがそれぞれ独立して、または並列的に処理を実行することができる。

メモリ１４０は、プロセッサ１２０によって実行されるプログラムと、プログラムが使用するデータとを一時的に記憶する。本実施例では、メモリ１４０は、ＤＢ（DataBase）の管理や関連する一連の処理を行うプログラムであるＤＢＭＳ１４１及びデータを記憶する。メモリ１４１は、ＤＢＭＳ１４１にクエリを発行するためのＡＰ（Application Program）１４８を記憶するようにしても良い。

ローカル記憶デバイス１３０は、計算機１００のプログラム、及びプログラムが使用するデータを格納する。ローカル記憶デバイス１３０は、不揮発性の記憶媒体であって、例えば、磁気ディスク、フラッシュメモリ、その他の不揮発性半導体メモリである。

ネットワークアダプタ１１０は、通信ネットワーク３００と計算機１００とを接続する。また、プロセッサ１２０は、ネットワークアダプタ１１０及びメモリ１４０等に接続された制御デバイスに含まれている要素であっても良い。制御デバイスは、プロセッサ１２０の他に、専用ハードウェア回路（例えば、データの暗号化及び／又は復号化を行う回路や、データの圧縮及び／又は伸張を行う回路）を含むことができる。

なお、計算機１００は、性能面や冗長性の観点から、ネットワークアダプタ１１０、プロセッサ１２０、ローカル記憶デバイス１３０、及びメモリ１４０のうちの少なくとも１つの要素を複数備えていても良い。また、計算機１００は、図示しない入力デバイス（例えば、キーボード及びポインティングデバイス）と表示デバイス（例えば液晶ディスプレイ）とを有しても良い。入力デバイスと表示デバイスは一体になっていても良い。

計算機１００は、データベース２０６に対して発行されたクエリをＤＢＭＳ１４１が実行するデータベース管理装置である。このクエリは、計算機１００で実行されるＡＰ１４８又は、通信ネットワーク３００に接続された図示しない計算機（クライアント）で実行されるＡＰによって発行される。

ＤＢＭＳ１４１は、ＡＰ１４８により発行されたクエリを実行し、前記クエリの実行に伴い、外部ストレージ装置２００に格納されたＤＢ２０６に対するＩ／Ｏ要求を、ＯＳを介して外部ストレージ装置２００に送信する。

なお、本実施例において、計算機１００で実行されるＤＢＭＳ１４１は一つだけであるが、ＤＢＭＳ１４１が複数実行されてもよい。なお、図示しないＯＳは、仮想化プログラムが生成した仮想マシン上で実行されるゲストＯＳであっても良い。そして、仮想化マシン上のＯＳがＤＢＭＳ１４１を実行してもよい。そして計算機１００が実行する仮想マシンは複数であってもよい。

外部ストレージ装置２００は、計算機１００が使用するデータを記憶する。外部ストレージ装置２００は、計算機１００からＩ／Ｏ要求を受信し、Ｉ／Ｏ要求に対応した処理を実行し、処理結果を計算機１００に送信する。

外部ストレージ装置２００は、ネットワークアダプタ２０１と、記憶デバイス群２０３及びそれらに接続されたコントローラ２０２を有する。

ネットワークアダプタ２０１は、外部ストレージ装置２００を通信ネットワーク３００に接続する。

記憶デバイス群２０３は、１つ以上の記憶デバイスを含む。記憶デバイスは、不揮発性の記憶媒体であって、例えば、磁気ディスク、フラッシュメモリ、その他の不揮発性半導体メモリである。記憶デバイス群２０３は、ＲＡＩＤ（Redundant ARRAY of Independent Disks）に従い所定のＲＡＩＤレベルでデータを記憶するグループであっても良い。

記憶デバイス群２０３の記憶空間に基づく論理的な記憶デバイス（論理ボリューム）が計算機１００に提供されても良い。記憶デバイス群２０３は、ＤＢ２０６を記憶する。ＤＢ２０６は、１つ以上の表２０５や索引２０４を含む。

表２０５は１つ以上のレコードの集合であり、レコードは１つ以上のカラムから構成される。索引２０４は、表２０５の中の１つ以上のカラムを対象に生成されるデータ構造であり、当該索引が対象とするカラムを含む選択条件による表２０５へのアクセスを高速化する。例えば、索引は、対象とするカラムの値毎に前記値を含む表の中のレコードを特定する情報（ＲｏｗＩＤ）を保持するデータ構造であり、Ｂ木構造などが用いられる。ＤＢの表２０５の構成例や表２０５同士の関連性の一例は、後述する。

コントローラ２０２は、例えば、図示しないメモリ及びプロセッサを含んでおり、計算機１００からのＩ／Ｏ要求に従って、ＤＢ２０６を記憶した記憶デバイス群２０３に対してデータの入出力を実行する。例えば、コントローラ２０２は、計算機１００からの書込み要求に従う書込み対象のデータを、記憶デバイス群２０３に格納したり、計算機１００からの読出し要求に従う読出し対象のデータを記憶デバイス群２０３から読み出し、前記データを計算機１００に送信する。

なお、外部ストレージ装置２００は、性能面や冗長性確保の観点から、コントローラ２０２などの要素を複数備えても良い。また、外部ストレージ装置２００を複数備えても良い。

ＤＢＭＳ１４１は、業務データを含んだＤＢ２０６を管理する。図１Ｂで示すようにＤＢＭＳ１４１は、クライアント通信制御部１４２、クエリ実行プラン生成部１４３、クエリ実行部１４４、実行タスク管理部１４５、ＤＢバッファ管理部１４６、ＤＢバッファ１４６０、コストテーブル１４３１及びＤＢ領域管理表１４７を含む。

クライアント通信制御部１４２は、通信ネットワーク３００に接続されたクライアントまたは計算機１００で実行されるＡＰ１４８との間の通信を制御する。具体的には、クライアント通信制御部（クエリ受付部）１４２は、図示しないクライアントまたはＡＰ１４８から発行されたクエリを受け付け、クエリの処理結果をクライアントまたはＡＰ１４８に応答する処理を実行する。クエリは、例えばＳＱＬ（Structured Query Language）で記述されている。

クエリ実行プラン生成部１４３は、クライアント通信制御部１４２が受け付けたクエリを実行するために必要な１つ以上の処理ステップを有するクエリ実行プランを生成する。クエリ実行プランは、例えば、クエリの実行の際に行うべき処理ステップの実行順序を木構造で定義した情報であり、メモリ１４０に格納される。クエリ実行プランの一例については、後述する。

ＤＢバッファ管理部１４６は、ＤＢ２０６内のデータを一時的に格納するための記憶領域としてのＤＢバッファ１４６０（またはＤＢキャッシュ）を管理する。ＤＢバッファ１４６０は、メモリ１４０上に構築される。あるいは、ＤＢバッファを、ローカル記憶デバイス１３０上に構築しても良い。

クエリ実行部１４４は、クエリ実行プラン生成部１４３が生成したクエリ実行プランに従って処理を行うタスクを動的に生成し、前述タスクを実行することでＤＢ２０６へアクセスし、クエリの結果を生成する。クエリ実行部１４４は、タスクが生成したＤＢ２０６へのアクセス結果をクエリの発行元に応答する。クエリ実行部１４４は、タスク生成制御部１５２と、コンテキスト管理部１５３と、システム性能閾値表１５４と、性能データ表１５５とを有する。

タスク生成制御部１５２は、タスク生成の要求を受け付けた時にリソースの利用状況に基づいて新たなタスクを生成する。リソースとは、クエリの実行で利用する計算機のＣＰＵリソース（プロセッサ１２０）やＩ／Ｏリソース（ネットワークアダプタ１１０や記憶デバイス群２０３等）、メモリリソース（メモリ１４０）などである。ＣＰＵリソースの利用状況はＣＰＵ利用率により示される。Ｉ／Ｏリソースの利用状況は、外部ストレージ装置２００などの外部装置から計算機１００へのデータ転送量や、計算機１００から外部ストレージ装置２００などの外部装置へのデータ転送量、又は、計算機１００から外部ストレージ２００などの外部装置に発行されるＩ／Ｏ要求数により示される。データ転送量は、単位時間当たりのデータ転送量であるデータ転送速度でもよく、累積したデータ転送量である累積データ転送量でもよい。Ｉ／Ｏ要求数は、単位時間あたりの処理したＩ／Ｏ要求数であるＩＯＰＳ（Input/Output Per Second）でもよく、累積されたＩ／Ｏ要求数である累積Ｉ／Ｏ要求数でもよく、Ｉ／Ｏが完了していない発行済みＩ／Ｏ要求数であるアウトスタンディングＩ／Ｏ数でもよい。メモリリソースの利用状況は、メモリ使用量により示される。例えば、タスク生成制御部１５２は、ＣＰＵリソースやＩ／Ｏリソースの利用が不十分な場合にタスクを生成する。具体的には、現時点でのＣＰＵ利用率や、外部ストレージ装置２００やローカル記憶デバイス１３０のディスク転送速度（またはデータ転送速度）やＩＯＰＳ等のリソースの利用状況をタスク生成制御部１５２が取得して、予め設定したＣＰＵ利用率の閾値やディスク転送速度の閾値やＩＯＰＳの閾値と比較する。そして、タスク生成制御部１５２は利用量が閾値未満であれば、ＣＰＵリソースやＩ／Ｏリソース等のリソースが十分利用できていない（あるいは所定の条件を満足していない）と判定する。

そして、タスク生成制御部１５２は、リソースの使用状況が不十分であればタスクを生成する。リソースの使用状況が十分であるか否かを判定するため、タスク生成制御部１５２はシステム性能閾値表１５４から値を参照し、現時点でのＣＰＵ利用率やディスク転送速度やＩＯＰＳは性能データ表１５５を参照する。

コンテキスト管理部１５３は、新たに生成するタスクの実行に必要な情報を含むコンテキストを管理する。ここで、コンテキストは、タスクにおいて実行を開始する処理ステップが、クエリ実行プランが表す１以上の処理ステップのうちのいずれであるかを示す第１の情報と、第１の情報が示す処理ステップに要するデータのアクセス先に関する第２の情報と、タスクにより結果を生成するために必要なデータに関する第３の情報とを含む情報である。コンテキストを管理するための情報であるコンテキスト管理情報の構造については後述する。

システム性能閾値表１５４は、ＣＰＵリソースおよびＩ／Ｏリソースの利用が十分か否かを判定するための閾値を予め保持しており、タスク生成制御部１５２が参照する。

性能データ表１５５は、ＣＰＵリソースおよびＩ／Ｏリソースの現在の利用状況を判定するための値を保持しており、タスク生成制御部１５２が参照する。

実行タスク管理部１４５は、クエリを実行するためのタスクを管理する。ここで、タスクとしては、任意のモジュールを採用することができる。例えば、タスクは、ＯＳ４１５が管理するプロセス又はスレッドでも良いし、ＤＢＭＳ４１２で実装される疑似プロセス又は疑似スレッドでも良い。また、タスクは、各処理を関数としてまとめた関数へのポインタ（関数ポインタ）の集合であってもよい。タスクを管理するための情報であるタスク管理情報の構造については、後述する。

クライアント通信制御部１４２、クエリ実行プラン生成部１４３、クエリ実行部１４４、及びＤＢバッファ管理部１４６の少なくとも１つの処理部が行う処理の少なくとも一部が、ハードウェアで行われても良い。また、本実施例の説明において、処理部が主語になる場合は、実際には前記処理部を実行するプロセッサ１２０によって処理が行われるが、処理部の少なくとも一部がハードウェアで実現されている場合は、プロセッサ１２０に代えて又は加えて、前記ハードウェアも、主語とされ得る。ＤＢＭＳ１４１を実現するコンピュータプログラムは、プログラムソースから計算機１００にインストールされて良い。プログラムソースは、例えば、計算機１００が読み取り可能な記憶メディアで良いし、他の計算機でも良い。

また、図１に示したＤＢＭＳ１４１の構成は、一例である。例えば、或る処理部が複数の処理部に分割されたり、複数の処理部の機能を統合した１つの処理部が構築されたりしても良い。

ＤＢＭＳ１４１を構成するクライアント通信制御部１４２と、クエリ実行プラン生成部１４３と、クエリ実行部１４４と、実行タスク管理部１４５及びＤＢバッファ管理部１４６の各機能部はプログラムとしてメモリ１４０にロードされ、プロセッサ１２０によって実行される。

プロセッサ１２０は、各機能部のプログラムに従って処理を実行することによって、所定の機能を実現する機能部として動作する。例えば、プロセッサ１２０は、クエリ実行プログラムに従って処理を実行することでクエリ実行部１４４として機能する。他のプログラムについても同様である。さらに、プロセッサ１２０は、各プログラムが実行する複数の処理のそれぞれを実現する機能部としても動作する。計算機及び計算機システムは、これらの機能部を含む装置及びシステムである。

ＤＢＭＳ１４１の各機能を実現するプログラム、テーブル等の情報は、ローカル記憶デバイス１３０や外部ストレージ装置２００や不揮発性半導体メモリ、ハードディスクドライブ、ＳＳＤ（Ｓｏｌｉｄ Ｓｔａｔｅ Ｄｒｉｖｅ）等の記憶デバイス、または、ＩＣカード、ＳＤカード、ＤＶＤ等の計算機読み取り可能な非一時的データ記憶媒体に格納することができる。

図２は、実施例１に係るＤＢ２０６の表２０５及び索引２０４の定義を説明する図である。

ＤＢ２０６は、表２０５として、例えば、カラムｃ１（２０５２）及びカラムｃ２（２０５３）を含むＰａｒｔ表２０５１（図３参照）と、カラムｃ３（２０５５）及びカラムｃ４（２０５６）を含むＬｉｎｅｉｔｅｍ表２０５４（図４参照）とを有する。

また、ＤＢ２０６は、索引２０４として、カラムｃ１（２０５２）の値に基づいたＰａｒｔ表２０５１に関する索引（Ｐａｒｔ索引）と、カラムｃ３（２０５５）の値に基づいたＬｉｎｅｉｔｅｍ表に関する索引（Ｌｉｎｅｉｔｅｍ索引）とを有する。

図３は、実施例１に係るＤＢ２０６のＰａｒｔ表２０５１の一例を示す図である。ＤＢ２０６のＰａｒｔ表２０５１は、論理的には、例えば、カラムｃ１（２０５２）の値と、対応するカラムｃ２（２０５３）の値とを対応付けた表である。

図４は、実施例１に係るＤＢ２０６のＬｉｎｅｉｔｅｍ表２０５４の一例を示す図である。ＤＢ２０６のＬｉｎｅｉｔｅｍ表（２０５４）は、例えば、カラムｃ３（２０５５）の値と、対応するカラムｃ４（２０５６）の値とを対応付けた表である。

図５は、実施例１に係るＤＢの第一のクエリの一例を示す図である。図５に示すクエリは、図２〜図４、図６〜図８に示す構造のＤＢ２０６に対するクエリの一例である。図５に示すクエリは、Ｐａｒｔ表２０５１及びＬｉｎｅｉｔｅｍ表２０５４から、カラムｃ１（２０５２）の値が"１３０"であり、且つカラムｃ２（２０５３）の値とカラムｃ３（２０５５）の値とが同じであるものについて、カラムｃ１（２０５２）の値とカラムｃ４（２０５６）の値とを抽出することを意味している。

図６は、実施例１に係るＤＢ２０６におけるｐａｒｔ索引２０４１のデータ構造の一例を説明する図である。

Ｐａｒｔ索引２０４１は、例えば、カラムｃ１（２０５２）の値に基づいて、対応するレコードを格納するｐａｒｔ表のページ（Ｐ、Ｐ１〜Ｐ９）及びページ内のスロットを検索するためのＢ木構造である。なお、索引のデータ構造には、Ｒ木やハッシュ、ビットマップなどのデータ構造を用いても良い。同様に、Ｌｉｎｅｉｔｅｍ索引２０４２は、例えば、カラムｃ３（２０５５）の値に基づいて、対応するレコードを格納するＬｉｎｅｉｔｅｍ表２０５４のページ及びページ内のスロットを検索するためのＢ木構造である。

ここで、ページとは、ＤＢ２０６に対する入出力における最小のデータ単位である。本実施例では、Ｐａｒｔ索引２０４１は、ページＰを入出力単位としたＢ木構造としている。Ｐａｒｔ索引２０４１においては、最下位のページであるリーフページ（Ｐ４〜Ｐ９）と、リーフページの上位のページである上位ページＰ１〜Ｐ３とがある。ここで、上位ページＰ１〜Ｐ３の中の最上位のページ（Ｐ１）をルートページという。

Ｐａｒｔ索引２０４１のルートページ（ページＰ１）には、一つ下の階層のページに対するポインタＰｔと、当該一つ下の階層のページが管理対象とするカラムｃ１（２０５２）の値の最大値とを対応付けたエントリが１以上設けられる。

例えば、ページＰ１には、"１００"以下のカラムｃ１（２０５２）の値に対する対応関係を管理するページＰ２へのポインタＰｔ１２と、"１００"より大きく"２００"以下のカラムｃ１の値に対する対応関係を管理するページＰ３へのポインタＰｔ１３が格納される。同様に、上位ページにおいては、それぞれのページの一つ下の階層のページに対するポインタと、当該１つ下の階層のページに管理されているカラムｃ１（２０５２）の値の最大値とを対応付けたエントリＰｔが１以上設けられる。

一方、リーフページには、カラムｃ１（２０５２）の値と、当該値に対応するＰａｒｔ表のレコードの格納位置であるＲｏｗＩＤ（例えば、Ｐａｒｔ表２０５１のページ番号及び当該ページ中のスロット番号）とを対応付けたエントリＥを１以上格納する。例えば、リーフページであるページＰ７には、カラムｃ１（２０５２）の値"１１０"に対応するカラムｃ２（２０５３）の値が格納されているページ及びスロットの番号を含むエントリＥ７１と、カラムｃ１（２０５２）の値"１３０"に対応するカラムｃ２（２０５３）の値が格納されているページ及びスロットの番号を含むエントリ（Ｅ７２）とが格納される。なお、その他のリーフページも同様であり、図中エントリＥで表す。

図７は、実施例１に係るＤＢ２０６におけるＰａｒｔ索引２０４１のキー値が１３０におけるＲｏｗＩＤを保持するデータ構造の一例を説明する図である。

例えば、図３に示したＰａｒｔ表２０５１のカラムｃ１（２０５２）の値"１３０"に対応するレコードのＲｏｗＩＤ（２０４１１）には、ページＰ２１のスロット２、ページＰ２２のスロット１、ページＰ２３のスロット４など、合計１０個のＲｏｗＩＤが格納される。

図８は、実施例１に係るＰａｒｔ表（２０５１）のデータ構造の一例を説明する図である。

ページＰ２１のスロット２にあるレコードは、カラムｃ１が１３０でカラムｃ２がｉｄ１３１である。ページＰ２２のスロット１にあるレコードは、カラムｃ１が１３０でカラムｃ２がｉｄ１３２である。ページＰ２３のスロット４にあるレコードは、カラムｃ１が１３０でカラムｃ２がｉｄ１３３である。以上のように、図７で示したカラムｃ１の値"１３０"に対応するレコードのＲｏｗＩＤは、カラムｃ１が１３０である１０個のレコード２０４１１を指し示している。

図９は、実施例１に係るＤＢ２０６を外部ストレージ装置２００の複数の記憶領域へ配置した一例を説明するブロック図である。外部ストレージ装置２００は、複数の論理的な記憶領域（論理ボリュームまたは論理ユニット：ＬＵ）＃１〜＃４で構成され、これらの記憶領域＃１〜＃４に、ＤＢ２０６の索引２０４と表２０５を分散して配置した例を示す。

図９において、索引２０４はＰａｒｔ索引２０４１とＬｉｎｅｉｔｅｍ索引２０４２に２分割される。Ｌｉｎｅｉｔｅｍ表２０５４は、ＬＩＮＥＩＴＥＭ（１）２０５４−１〜ＬＩＮＥＩＴＥＭ（４）２０５４−４に４分割される。

Ｐａｒｔ索引ＩＤＸ＿ＰＡＲＴ２０４１は記憶領域＃１に格納されており、Ｌｉｎｅｉｔｅｍ索引ＩＤＸ＿ＬＩＮＥＩＴＥＭ２０４１は記憶領域＃２に格納されている。

Ｐａｒｔ表２０５１は４つの領域（ＰＡＲＴ（１）２０５１−１とＰＡＲＴ（２）２０５１−２とＰＡＲＴ（３）２０５１−３とＰＡＲＴ（４）２０５１−４）から構成される。Ｐａｒｔ表のＰＡＲＴ（１）２０５１−１は記憶領域＃１に、ＰＡＲＴ（２）２０５１−２は記憶領域＃２に、ＰＡＲＴ（３）２０５１−３は記憶領域＃３に、ＰＡＲＴ（４）２０５１−４は記憶領域＃４に格納されている。

Ｌｉｎｅｉｔｅｍ表２０５４も、Ｐａｒｔ表２０５１と同様に、４つの領域２０５４−１〜２０５４−４から構成されており、それぞれの領域２０５４−１〜２０５４−４が記憶領域＃１〜４に格納される。

図１０は、実施例１に係るＤＢ領域管理表１４７の一例を示す図である。

図１０のＤＢ領域管理表１４７は、ＤＢオブジェクト（本実施例では、Ｐａｒｔ索引、Ｐａｒｔ表、Ｌｉｎｅｉｔｅｍ索引、Ｌｉｎｅｉｔｅｍ表）１４７１と、ＤＢオブジェクトを構成するページ番号１４７２と、当該ページ番号がいずれの記憶領域＃１〜＃４に格納されているかを示す記憶領域名１４７３からひとつのエントリが構成される。例えば、ＤＢオブジェクト１４７１がＰａｒｔ索引ＩＤＸ＿ＰＡＲＴの場合、ページ番号１４７２がＰ１〜Ｐ２０であり、ページ番号Ｐ１〜Ｐ２０は記憶領域＃１に格納されていることを示す。また、Ｐａｒｔ表２０５１を構成するＰＡＲＴ（２）のページ番号はＰ１２１〜Ｐ１５０であり、ページＰ１２１〜Ｐ１５０は記憶領域＃２に格納されている事を示す。

なお、本実施例では、ＤＢ領域管理表１４７をＤＢＭＳ１４１が保持する例を示したが、外部ストレージ装置２００の記憶デバイス群２０３に保持されていても良い。

図１１は、実施例１に係るクエリ実行プランの一例を示す図である。

図１１に示すクエリ実行プランは、ＤＢＭＳ１４１が図５に示すクエリを受け付けた場合に、クエリ実行プラン生成部１４３により生成されるクエリ実行プランの一例を示している。

図５に示すクエリに対応するクエリ実行プランは、図１１に示すように、Ｐａｒｔ索引２０４１による索引検索を行う処理ステップ＃１と、Ｐａｒｔ表２０５１からレコードを取得する処理ステップ＃２と、Ｌｉｎｅｉｔｅｍ索引２０４２による索引検索を行う処理ステップ＃３と、Ｌｉｎｅｉｔｅｍ表２０５４からレコードを取得する処理ステップ＃４と、これらの結果をネストループ結合する処理ステップ＃５と、ネストループ結合した結果に対して演算を実行する処理ステップ＃６と、を含む。図中外側は、ネストの外側のループを示し、本実施例では、Ｐａｒｔ表２０５１に対する処理となる。また、図中内側は、ネストの内側のループを示し、本実施例では、Ｌｉｎｅｉｔｅｍ表２０５４に対する処理となる。

図１２は、図１１に示した各処理ステップ＃１〜＃６におけるＣＰＵコストを設定したコストテーブル１４３１の一例を示す図である。

コストテーブル１４３１は、クエリ実行プラン生成部１４３によってメモリ１４０上で管理される。コストテーブル１４３１は、処理ステップの番号を格納する処理ステップ１４３２と、プロセッサ１２０のコストを格納するＣＰＵコスト１４３３からひとつのエントリが構成される。

各処理ステップ＃１〜＃６におけるＣＰＵコスト１４３３とは、対応する処理ステップを実行する際にプロセッサ１２０が必要とする処理量を数値で表したものである。処理量としては、例えば、各処理ステップの命令数であったり、各処理ステップを実行するのにプロセッサ１２０が必要とするクロック数、処理ステップの処理に要する処理時間などを採用することができる。本実施形態では、計算機１００で各処理ステップ１４３２を実行したときの処理時間（μｓｅｃ）でＣＰＵコスト１４３３を表す例を示す。

クエリ実行プラン生成部１４３では、例えば、各処理ステップのＣＰＵコストやＩ／Ｏコストを元にクエリ実行プランを決定しているため、ＣＰＵコストはクエリ実行プラン生成部１４３のコスト見積りで使うＣＰＵコストを用いてもよい。

また、クエリ実行プラン生成部が、１４３事前に処理ステップ毎の処理時間や処理に要するクロック数を計測した結果をコストテーブル１４３１に設定しておいてもよい。また、クエリを実行中にＣＰＵコストを検出して、この値をコストテーブル１４３１に設定するようにしてもよい。さらには、検出したＣＰＵコストをクエリ実行中の処理ステップの処理時間を用いて補正してもよい。

図１３は、実施例１に係るタスク実行状態情報７３の一例を示す図である。タスク実行状態情報７３は、実行タスク管理部１４５がメモリ１４上で保持する。

タスク実行状態情報７３には、メモリ１４０上に設定されたワーク領域７３ａと、実行する処理ステップの番号を格納する処理ステップ７３ｂと、処理ステップ実行状態７３ｃが含まれる。

ワーク領域７３ａには、対応するタスクがクエリ実行プランを処理する際にカラムの値を格納するワーク領域７３ｄを示すポインタが格納される。処理ステップ７３ｂには、対応するタスクで実行する処理ステップを識別する情報、例えば、処理ステップ番号が格納される。処理ステップ実行状態７３ｃには、対応する処理ステップの実行状態情報（処理ステップ実行状態情報）７４が格納される。処理ステップの実行状態情報７４の具体例については、後述する。

図１４は、実施例１に係る処理ステップの実行状態情報７４の第１の例を示す図である。図１４は、索引検索における上位ページを使用するタスクについての処理ステップ実行状態情報を示す。

処理ステップ実行状態情報７４Ａは、検索条件７４ａと、ページ番号７４ｂと、スロット番号７４ｃとを含む。検索条件７４ａには、検索条件が格納される。図示の例では、検索条件７４ａには、図５に示したクエリに含まれる検索条件である"ｃ１＝１３０"を格納される。ページ番号７４ｂには、タスクの処理で使用する上位ページの番号（ページ番号）を格納される。スロット番号７４ｃには、図８で示したように、タスクの処理で使用するページにおけるスロットの番号（スロット番号）を格納される。

図１５は、実施例１に係る処理ステップの実行状態情報７４の第２の例を示す図である。図１５は、索引検索におけるリーフページＰ４〜Ｐ９（図６参照）を使用するタスクについての処理ステップ実行状態情報を示す。

処理ステップ実行状態情報７４Ｂは、検索条件７４ｄと、ページ番号７４ｅと、スロット番号７４ｆと、処理ＲｏｗＩＤ番号７４ｇとを含む。検索条件７４ｄには、検索条件が格納される。図示の例では、検索条件７４ｄには、検索条件である"ｃ１＝１３０"が格納される。ページ番号７４ｅには、タスクの処理で使用するリーフページのページ番号"７"が格納される。

スロット番号７４ｆには、タスクの処理で使用するページにおけるスロットのスロット番号"２"が格納される。処理ＲｏｗＩＤ番号７４ｇには、対応するタスクで処理するスロット内のＲｏｗのＩＤ番号（処理ＲｏｗＩＤ番号）"１"が格納される。

図１６は、実施例１に係る処理ステップの実行状態情報７４の第３の例を示す図である。図１６は、レコード取得を行うタスクについての処理ステップ実行状態情報７４Ｃを示す。

処理ステップ実行状態情報７４Ｃは、ページ番号７４ｈと、スロット番号７４ｉとを含む。ページ番号７４ｈには、タスクの処理で使用するページのページ番号"２"が格納される。スロット番号７４ｉには、タスクの処理で使用するページにおけるスロットのスロット番号"２"が格納される。

図１７は、実施例１に係るタスク管理情報１４５０のデータ構造の一例を示す図である。タスク管理情報１４５０は、実行タスク管理部１４５によって管理されるデータ構造で、メモリ１４０上に保持される。

タスク管理情報１４５０のデータ構造は、実行可能なタスクを管理するための実行可能リスト１４５１と、Ｉ／Ｏ要求の完了を待っているタスクなど、実行待ち状態であるタスクを管理するための待ちリスト１４５２が含まれる。

実行可能リスト１４５１は、実行可能なタスクに関する実行状態情報であるタスク実行状態情報７３（図１３参照）へのポインタ１４５３を有する。待ちリスト１４５２も同様に、待機中のタスクに関する実行状態情報であるタスク実行状態情報７３（図１３参照）へのポインタ１４５４を有する。また、タスク実行状態情報７３は、実行可能な他のタスクに関するタスク実行状態情報７３へのポインタを有する。

図１８は、初期のコンテキスト１５３０の一例を示す図である。上述のように、コンテキスト１５３０は、新たに生成するタスクの実行に必要な情報であり、コンテキスト管理部１５３が管理する。

初期のコンテキスト１５３０には、図１８で示すように、開始ステップ１５３１と、中間結果１５３２と、生成可能数１５３３と、実行状態１５３４と、を含む。開始ステップ１５３１には、実行する処理ステップの番号または識別子が格納される。

中間結果１５３２には、処理ステップを実行するタスクに必要な中間結果を格納するワーク領域１５３９の所在を示すポインタが格納される。ここで、中間結果とは、クエリの結果を生成するために必要な取得済みのデータである。また、ワーク領域１５３９はメモリ１４０上に設定された領域である。

実行状態１５３４には、次に実行するタスクの処理の内容を特定する情報を格納される。例えば、図示の例では、処理対象のページ番号１５６１と、まだ処理されていないデータのリストで構成された未処理データリスト１５６２である。未処理データリスト１５６２は、例えば、処理されていないページ番号とスロット番号の組で構成することができる。

生成可能数１５３３には、タスクの実行状態において、タスク生成制御部１５２がさらに生成することのできるタスクの数（タスク生成可能数）が格納される。このタスク生成可能数は、開始ステップ１５３１の実行状態のページ番号において、論理的に分岐する処理の数の内で、タスクとして生成されていない処理の数である。図１８の例では、図６に示したＰａｒｔ索引２０４１において、"ｃ１＝１３０"という検索条件で検索している際に、"ｃ１＝１３０"のエントリをページＰ７で取得した際のコンテキストを示している。

図１８の例では、開始ステップ１５３１には、"処理ステップ＃１"が格納される。中間結果１５３２には、コンテキストを生成する時点のタスクが保持するワーク領域７３ｄの内容をコピーした領域であるワーク領域１５３９のポインタが格納される。

ページ番号１５６１には、図６で示したように、コンテキストから生成されるタスクの処理で使用するリーフページのページ番号である"Ｐ７"が格納される。ここで、図７に示した最初のＲｏｗＩＤ２０４１１＝"Ｐ２１，２"は、コンテキストを生成するタスクが処理するため、未処理データリスト１５６２には、残りの９個のＲｏｗＩＤ２０４１１のデータを格納する。この初期のコンテキスト１５３０から生成可能なタスクは９個のため、タスク生成可能数１５３３には"９"が格納される。

図１９は、実施例１に係る第１のコンテキスト１５３０−１の一例を示す図である。

本発明において、Ｉ／ＯリソースやＣＰＵリソースの利用状況によって生成するタスクを選択できるようにするために、生成されるタスクの特徴（または種類）ごとにコンテキスト１５３０−１〜１５３０−ｎを生成することができる。本実施例では、タスクの特徴として、Ｉ／Ｏ要求を出す記憶領域＃１〜＃４と、Ｉ／Ｏ要求の大きさであるＩ／Ｏサイズ、Ｉ／Ｏパターン、そしてＣＰＵコストを特徴とする。Ｉ／Ｏパターンとは、複数のＩ／Ｏ要求に記されたアドレスの特徴である。例えば、前に行われたＩ／Ｏ要求のアドレスに隣接したアドレスへのＩ／Ｏ要求が連続して処理される場合、そのＩ／Ｏパターンはシーケンシャルと呼ばれる。一方、前に行われたＩ／Ｏ要求のアドレスとは無関係なアドレスへのＩ／Ｏ要求が連続して処理される場合、そのＩ／Ｏパターンをランダムと呼ぶ。タスクの特徴としてのＩ／Ｏパターンとは、当該タスクを実行した場合にそれらのＩ／Ｏ要求のアドレスがどのような特徴となるかを示すものである。そして、ＤＢＭＳ１４１では、初期のコンテキスト１５３０から分類された特徴毎にコンテキスト１５３０−１〜１５３０−ｎを生成する。

このため、図１９に示す第１のコンテキスト１５３０−１には、図１８に示した開始ステップ１５３１と中間結果１５３２と生成可能数１５３３と実行状態１５３４に加え、記憶領域名１５３５と、Ｉ／Ｏサイズ１５３６と、Ｉ／Ｏパターン１５３７と、ＣＰＵコスト１５３８とを含む。

図１９は、上記図１８に示した初期のコンテキスト１５３０に含まれるＲｏｗＩＤ２０４１１（図７参照）を分類した場合に、記憶領域＃１にアクセスするＲｏｗＩＤを集めた第１のコンテキスト１５３０−１の一例である。特徴に基づいて生成すべきコンテキストを分類する処理の詳細に関しては後述する。

上記コンテキスト１５３０−１から生成されるタスクは、記憶領域＃１にアクセスし、Ｉ／Ｏサイズ１５３６は４ＫＢで、Ｉ／Ｏパターン１５３７はランダムで、そのＣＰＵコスト１５３８は１２５のタスクである。

図２０は、実施例１に係る第２のコンテキストの一例を示す図である。

図２０は、上記図１８に示した初期のコンテキスト１５３０に含まれるＲｏｗＩＤ２０４１１（図７参照）を分類した場合に、記憶領域＃２にアクセスするＲｏｗＩＤを集めたコンテキスト１５３０−２の一例である。このコンテキスト１５３０−２から生成されるタスクは、記憶領域＃２にアクセスし、Ｉ／Ｏサイズ１５３６は４ＫＢで、Ｉ／Ｏパターン１５３７はランダムで、そのＣＰＵコスト１５３８は１２５のタスクとなる。

なお、本実施例ではＩ／ＯリソースやＣＰＵリソースの利用が区別できるようなコンテキストの分類をしているが、メモリリソースの利用に関する分類ができてもよい。例えば、本コンテキストで処理を開始するタスクのメモリ消費量を特徴にしても良い。

図２１は、実施例１を示し、ＤＢＭＳ１４１がクエリを受け付けてから、結果を応答するまでの処理全体のフローチャートである。

クエリ受付時の処理においては、クライアント通信制御部１４２が、ＡＰ１４８からクエリを受け付けると（ステップＳ１）、受け付けたクエリをクエリ実行プラン生成部１４３に渡し、クエリ実行プラン生成部１４３がクエリ実行プランを生成する（ステップＳ２）。

続いて、クエリ実行部１４４が、初期タスク数と上限タスク数と下限タスク数を設定する（ステップＳ３）。本実施例では、初期タスク数と上限タスク数と下限タスク数を設定しているが、いずれか１つでもよく、または初期タスク数と上限タスク数と下限タスク数を任意に組み合わせても良い。

ここで、初期タスク数とは、クエリ実行処理の開始後にＣＰＵリソースやＩ／Ｏリソースの利用状況とは関係なく、クエリ実行部１４４が生成するタスクの数である。初期タスク数は、ユーザが指定しても良く、あるいは、ＤＢＭＳ１４１がハードウェア構成から自動的に計算しても良い。例えば、通信ネットワーク３００と計算機１００をＦｉｂｒｅ Ｃｈａｎｎｅｌで接続している場合、Ｆｉｂｒｅ Ｃｈａｎｎｅｌのポートで同時に発行できるＩ／Ｏ要求数であるタグ数が１０２４であるとすると、"Ｆｉｂｒｅ Ｃｈａｎｎｅｌポート数×１０２４"を初期タスク数に設定する。

あるいは、外部ストレージ装置２００の同時コマンド受付数が２０４８であれば、初期タスク数に"２０４８"を設定する。外部ストレージ装置２００がｎ台のハードディスクドライブ（ＨＤＤ）を使って計算機１００に論理ボリュームを提供している場合、"ｎ×３２"を初期タスク数に設定する。

上限タスク数とはＤＢＭＳ１４１上で同時に存在するタスクの上限であり、ＣＰＵリソースやＩ／Ｏリソースが十分利用されていない場合でも、上限タスク数を超えるタスクがＤＢＭＳ１４１上で同時に存在しないことを保証する。上限タスク数は、ユーザが指定してもよく、ＤＢＭＳ１４１がハードウェア構成から自動的に計算しても良い。例えば、通信ネットワーク３００と計算機１００をＦｉｂｒｅ Ｃｈａｎｎｅｌで接続している場合、Ｆｉｂｒｅ Ｃｈａｎｎｅｌポートで同時に発行できるＩ／Ｏ要求数であるタグ数が１０２４であるとすると、"Ｆｉｂｒｅ Ｃｈａｎｎｅｌポート数×１０２４"を上限タスク数に設定する。外部ストレージ装置２００の同時コマンド受付数が２０４８であれば、上限タスク数に"２０４８"を設定する。外部ストレージ装置２００がｎ台のハードディスクドライブ（ＨＤＤ）を使って計算機１００に論理ボリュームを提供している場合、"ｎ×３２"を上限タスク数に設定する。

下限タスク数とは、ＣＰＵリソースやＩ／Ｏリソースの利用状況とは関係なく生成するタスクの数である。下限タスク数は、ユーザが指定してもよく、ＤＢＭＳ１４１がハードウェア構成から自動的に計算しても良い。例えば、プロセッサコアを活用できるようにプロセッサコアの数を下限タスク数に設定する。下限タスク数は外部ストレージ装置２００のＨＤＤを活用できるようＨＤＤの数を下限タスク数に設定する。

次に、クエリ実行部１４４が、初期のコンテキスト１５３０を生成する（ステップＳ４）。初期のコンテキスト１５３０とは、図１８で示したように、クエリ実行プランを最初に実行するタスクを生成するコンテキスト１５３０である。例えば、図１１に示したクエリ実行プランの場合、Ｐａｒｔ索引のルートページから"ｃ１＝１３０"という検索条件で処理ステップ＃１を開始させるコンテキスト１５３０である。生成した初期のコンテキスト１５３０は、コンテキスト管理部１５３に登録される。

クエリ実行部１４４がクエリ実行処理を行う（ステップＳ５）。クエリ実行部１４４が新たなタスクを生成し、タスクを実行することでクエリの処理を行い、外部ストレージ装置２００のＤＢ２０３に対するクエリの結果を生成する。クエリ実行処理の具体的な内容は、図２２にて説明する。

クエリ実行部１４４が生成した結果を、クライアント通信制御部１４２がクエリを送付してきたＡＰ１４８に応答する（ステップＳ６）。クエリ実行部１４４が生成する結果がなくなった時に、全体の処理が終了する。

以上の処理が、ＤＢＭＳ１４１がＡＰ１４８からクエリを受け付けて、クエリに対応するタスクを生成し、タスクを実行して外部ストレージ装置２００のＤＢ２０３にアクセスを実行し、アクセス結果をクエリの処理結果として生成する。

図２２は、実施例１に係るクエリ実行処理の一例を示すフローチャートである。この処理は、図２１のステップＳ５で行われる処理である。

クエリ実行部１４４は、コンテキスト１５３０の有無とタスクの有無を判定する（ステップＳ１１）。コンテキスト１５３０の有無は、コンテキスト管理部１５３に登録されているコンテキスト１５３０の有無を判定する。タスクの有無は、実行タスク管理部１４５にタスクが存在しているか否かを判定する。コンテキスト１５３０が無く、かつ、タスクもない場合には、クエリ実行処理が終了する。一方、コンテキスト１５３０が有る、または、タスクがある場合は、ステップＳ１２の処理に進む。

クエリ実行部１４４は、実行可能なタスクの有無を判定する（ステップＳ１２）。実行可能なタスクの有無は、実行タスク管理部１４５にて判定する。実行可能なタスクがなければステップＳ１３へ進み、実行可能なタスクがあればステップＳ１６へ進む。

実行可能なタスクがない場合、クエリ実行部１４４は、タスク生成処理を行う（ステップＳ１３）。タスク生成処理は、コンテキスト１５３０を読み込んで新たなタスクを生成する処理である。具体的な処理については後述する。

タスク生成処理の後に、クエリ実行部１４４は、再度実行可能なタスクの有無を判定する（ステップＳ１４）。実行可能なタスクがない場合は、コンテキストもなく、存在するタスクは全て待ちリスト１４５２のポインタ１４５４（図１７参照）に保持された状態なので、一定時間スリープする（ステップＳ１５）。

一方、ステップＳ１２またはステップＳ１４で実行可能なタスクがある場合には、クエリ実行部１４４は、タスクを１つ選択し（ステップＳ１６）、選択したタスクを実行する（ステップＳ１７）。タスクの実行とは、新規のタスクであれば、図２３に示すタスク実行処理を開始することである。一方、待ちリスト１４５２のポインタ１４５４から実行可能リストに移ったタスクであれば、待ちリスト１４５２のポインタ１４５４へ入ったときの処理から再開する。

クエリ実行部１４４は、新規または再開したタスクの実行が終了すると、ステップＳ１１に戻り、コンテキスト１５３０とタスクがなくなるまで上記処理を繰り返す。

図２３は、実施例１に係るタスク実行処理の一例を示すフローチャートである。この処理は、図２２のステップＳ１７で新たなタスクに対して行われる処理である。

このタスク実行処理は、クエリ実行部１４４が、処理の決まっていない新規のタスクを実行する際に適用される。クエリ実行部１４４は、新たなタスクの処理の内容を決めるために、コンテキスト管理部１５３でコンテキスト取得処理を行う（ステップＳ２１）。コンテキスト取得処理の具体的な内容は、図３１にて説明する。

クエリ実行部１４４は、取得したコンテキスト１５３０を使ってタスクの実行状態情報７３（図１３参照）を設定する（ステップＳ２２）。ここでは、図１９に示した第１のコンテキスト１５３０−１を例に説明する。クエリ実行部１４４は、コンテキスト１５３０−１の開始ステップ１５３１の値（処理ステップ＃１）を、タスク実行状態情報７３の処理ステップ７３ｂにコピーする。

クエリ実行部１４４は、コンテキスト１５３０の中間結果１５３２のポインタが示すワーク領域１５３９のデータを、タスク実行状態情報７３のワーク領域７３ａのポインタが示すワーク領域にコピーする。

クエリ実行部１４４は、取得したコンテキスト１５３０の未処理データリスト１５６２からデータを一つ取り出し、処理ステップ実行状態情報７４Ｃを設定する。クエリ実行部１４４は、未処理データリスト１５６２からデータを一つ取り出したので、コンテキスト１５３０の生成可能数１５３３を１減らす。

処理ステップ実行状態情報７４Ｃの設定について、具体的な例を説明する。例えば、クエリ実行部１４４が、図７に示したＲｏｗＩＤ（Ｐ２２，１）を未処理データリスト１５６２から取得したとする。図１８で示したようにコンテキスト１５３０の実行状態のページ番号が"Ｐ７"であることから、未処理データリスト１５６２のデータは、レコードの取得を行うＲｏｗＩＤである。

そこで、クエリ実行部１４４は、レコードの取得を行うステップ実行状態である図１６の処理ステップ実行状態情報７４Ｃを準備する。すなわち、クエリ実行部１４４は、処理ステップ実行状態情報７４Ｃのページ番号７４ｈには"Ｐ２２"を設定し、スロット番号７４ｉには"１"を設定する。

クエリ実行部１４４は、タスクを開始する際、レコードの取得から処理を実行するため、タスク実行状態情報７３内の処理ステップ７３ｂを一つ進め、図１１で示すように処理ステップ＃２を設定する。以上で、クエリ実行部１４４は、タスクの実行状態情報７３を設定する処理が完了する。

クエリ実行部１４４は、ステップＳ２２で設定された状態に従い、処理ステップ実行処理を実行する（ステップＳ２３）。処理ステップ実行処理に関しては図２４で説明する。処理ステップ実行処理が終了すると、タスク実行処理は終了する。

図２４は、実施例１に係る処理ステップ実行処理のフローチャートである。この処理は、図２３のステップＳ２３で実行される処理である。

クエリ実行部１４４は、ＤＢバッファ管理部１４６にＤＢページ取得処理（図２６参照）を実行させる（ステップＳ３０）ことにより、ＤＢ２０６からクエリの対象となるページ（ＤＢページ）を取得する。

次いで、クエリ実行部１４４は、取得したページにおけるデータについて、検索条件と合致するものがあるか否かを判定する（ステップＳ３１）。例えば、索引の上位ページであれば、上位ページ内の検索処理であり、リーフページであればリーフページの検索処理である。この判定の結果、ページにおけるデータに、検索条件と合致するデータがない場合（ステップＳ３１で"偽"）には、処理ステップ実行処理が終了する。

一方、検索条件に合致するデータがある場合（ステップＳ３１で"真"）には、クエリ実行部１４４は、検索条件に合致するデータが１つであるか、２つ以上であるか否かを判定する（ステップＳ３２）。

この判定の結果、検索条件に合致するデータが１つである場合（ステップＳ３２で"１つ"）には、クエリ実行部１４４は、処理をステップＳ３５に進める。一方、検索条件に合致するデータが２つ以上である場合（ステップＳ３２で"２つ以上"）には、クエリ実行部１４４がコンテキスト生成処理（図２５）を行い（ステップＳ３３）、クエリ実行部１４４のタスク生成制御部１５２はタスク生成処理（図２９）を実行し（ステップＳ３４）、処理をステップＳ３５に進める。

ステップＳ３５では、クエリ実行部１４４は、当該タスクによる処理ステップにおけるＤＢ２０６のページに対する処理を実行する。ここで、ＤＢ２０６のページに対する処理とは、例えば、索引の上位ページであれば、検索条件に合致するページ番号を読み出す処理であり、リーフページであれば検索条件に合致するＲｏｗＩＤを読み出す処理であり、表２０４のページであればレコードのカラムを読み出す処理である。

次いで、クエリ実行部１４４は、次のＤＢ２０６のページと、当該ページに対する処理を決定し（ステップＳ３６）、ステップＳ３７に処理を進める。

ステップＳ３７では、クエリ実行部１４４は、処理が終了したので、取得しているＤＢ２０６のページを解放する。次いで、ステップＳ３８では、クエリ実行部１４４は、次の処理があるか否かを判定する。具体的には、現在行っている処理ステップ７３ｂが完了しており、当該処理ステップを含む処理ブロックにおいて次の処理ステップがない場合にクエリ実行部１４４は処理が"無"と判定する。

この判定の結果、次の処理がある場合（ステップＳ３８で"有"）には、クエリ実行部１４４は、処理をステップＳ３０に戻す一方、次の処理がない場合（ステップＳ３８で"無"）には、処理結果をクエリ実行部１４４に渡し（ステップＳ３９）、処理ステップ実行処理を終了する。

ここで、次のＤＢ２０６から取得したページと、当該ページに対する処理の決定について、図２〜図４と図６〜図８に示すＤＢ２０６に対して、"ｃ１＝１３０"を検索条件として、Ｐａｒｔ索引２０４１を索引検索する場合を例にして、以下に説明する。

最初に索引検索を開始している場合においては、クエリ実行部１４４は、索引のルートページ（図６に示したページ番号"Ｐ１"のページ）を次のＤＢ２０６のページと決定し、当該ページに対して"１３０"というキーを検索する上位ページ内の検索処理をＤＢ２０６のページに対する処理として決定し、処理を開始する。

ステップＳ３０で、クエリ実行部１４４はページＰ１を読み込み、ステップＳ３１で当該ページＰ１の中でカラムｃ１（２０５２）に"１３０"を含むエントリを検索する。図６において、クエリ実行部１４４は、カラムｃ１（２０５２）に"２００"を含むエントリ（Ｐｔ１３）を１つ取得するので、ステップＳ３５とステップＳ３６で、次の処理としてページＰ３に対して上位ページ内の検索処理をＤＢ２０６のページに対する処理と決定する。

また、ステップＳ３０からステップＳ３５で、索引の下位ページＰ３に対する処理を行う。クエリ実行部１４４は、ＤＢ２０６からページＰ３を読み込み、当該ページＰ３でカラムｃ１（２０５２）に"１３０"を含むエントリを検索し、カラムｃ１（２０５２）に"１３０"を含むエントリにおいてページＰ７へのポインタＰｔを取得する。この結果、クエリ実行部１４４は、ページＰ７を次のＤＢ２０６の処理対象ページと決定し、当該ページＰ７に対してリーフページ内の検索処理をＤＢ２０６のページに対する処理と決定する。

クエリ実行部１４４は、ステップＳ３０からステップＳ３３で、ページＰ７を読み込み、図６で示したように、当該ページＰ７でカラムｃ１（２０５２）に"１３０"を含むエントリ（Ｅ７２）を取得する。ここで図７に示したように、検索条件に合致するデータが１０個あるので、当該タスクで処理するデータ以外の９個のデータの処理を行うために、クエリ実行部１４４は、コンテキスト生成処理（ステップＳ３３）を行い、タスク生成処理（ステップＳ３４）を行う。

本実施例では、当該タスクで処理するデータを最初のデータとし、ステップＳ３６でＰａｒｔ表２０５１のページＰ２１を次のＤＢ２０６の対象ページと決定し、図８で示したように、当該ページＰ２１に対してスロット番号２にあるレコードを取得する処理をＤＢ２０６のページに対する処理と決定する。

以上の処理により、ＤＢＭＳ１４１では、処理対象の先頭のＤＢ２０６のページから、検索条件に合致するデータを処理するコンテキスト１５３０を図１８で示したように生成し、このコンテキスト１５３０からタスクを生成することで、複数のタスクとして実行することができる。

図２５は、実施例１に係るコンテキスト生成処理のフローチャートである。この処理は図２４のステップＳ３３で行われる処理である。

クエリ実行部１４４は、まず、図１８に示した初期のコンテキスト１５３０から生成されるタスクを、Ｉ／Ｏ要求を出す記憶領域＃１〜＃４と、Ｉ／Ｏパターンと、Ｉ／Ｏサイズと、ＣＰＵコストで分類する（ステップＳ４１）。

例えば、リーフページ（Ｐ４〜）の処理で作られたコンテキスト１５３０から生成されるタスクは、コンテキスト１５３０の未処理データリスト１５６２に格納されるＲｏｗＩＤを元に生成される。クエリ実行部１４４は、コンテキストに保持するＲｏｗＩＤを、Ｉ／Ｏ要求を出す記憶領域名、Ｉ／Ｏ要求の大きさであるＩ／Ｏサイズ、Ｉ／Ｏパターン、ＣＰＵコストにより分類し、分類された未処理データリスト１５６２ごとにコンテキスト１５３０−１〜１５３０−ｎを生成する。

例えば、図１８における未処理データリスト１５６２に含まれるＲｏｗＩＤ（Ｐ２１，２）は、クエリ実行部１４４が図１０のＤＢ領域管理表１４７を参照して、記憶領域＃１にＩ／Ｏ要求を発行する。

また、クエリ実行部１４４はＤＢ領域管理表１４７から処理ステップ＃１の前記Ｉ／Ｏ要求がリーフページからの処理となるため、Ｉ／Ｏサイズ１５３６はＤＢ２０６のページサイズ（ここでは４ＫＢを仮定）であり、Ｉ／Ｏパターン１５３７はランダムとする。

また、クエリ実行部１４４は、図１２のコストテーブル１４３１を参照してＣＰＵコストを取得する。クエリ実行部１４４は、初期のコンテキスト１５３０から生成されるタスクは、処理ステップ＃１から処理ステップ＃６まで行う可能性があるため、初期のコンテキスト１５３０のＣＰＵコスト１５３８はコストテーブル１４３１のＣＰＵコスト１４３３を合計した１２５となる。クエリ実行部１４４は、上記処理を図７に示した残りのＲｏｗＩＤ２０４１１についても実行し、記憶領域＃、Ｉ／Ｏサイズ、Ｉ／Ｏパターン、ＣＰＵコストから生成するタスクを、利用するリソースの種類に応じて分類する。

そして、クエリ実行部１４４は、上述の分類ごとにコンテキスト１５３０−１〜１５３０−ｎを生成して（ステップ４２）、コンテキスト管理部１５３に登録する。

図１８に示すコンテキスト１５３０の場合、本実施例では記憶領域＃１にアクセスする第１のコンテキスト１５３０−１（図１９）と記憶領域＃２にアクセスする第２のコンテキスト１５３０−１（図２０）、記憶領域＃３にアクセスする第３のコンテキスト（図示省略）と記憶領域＃４にアクセスする第４のコンテキスト（図示省略）を生成する。

図２６は、実施例１に係るＤＢページ取得処理のフローチャートである。この処理は、図２４のステップＳ３０で行われる処理の一例を示すフローチャートである。

ＤＢバッファ管理部１４６は、取得対象のＤＢ２０６のページに対応するバッファページ（ＤＢバッファ１４６０に保持されたページ）を検索し（ステップＳ５１）、取得対象のＤＢ２０６のページに対応するＤＢバッファページの有無を判定する（ステップＳ５２）。

この判定の結果、ＤＢバッファ管理部１４６は、ＤＢバッファページがＤＢバッファ１４６０にある場合（ステップＳ５２で"有"）には、ＤＢバッファ管理部１４６は、ＤＢ２０６から当該ページの読込みが完了しているか否かを判定する（ステップＳ５３）。外部ストレージ装置２００からの読み込みが完了している場合（ステップＳ５３で"完了"）には、ＤＢバッファ管理部１４６は、ＤＢページ取得処理を終了する。一方、ＤＢ２０６からの読み込みが完了していない場合（ステップＳ５３で"未完"）には、ステップＳ５６に処理を進める。

一方、ステップ５２の判定で、取得対象のＤＢ２０６のページに対応するＤＢバッファページがない場合（ステップＳ５２で"無"）には、ＤＢバッファ管理部１４６は、ＤＢバッファ１４６０から空きＤＢバッファページを取得する（ステップＳ５４）。そして、ＤＢバッファ管理部１４６は、ＤＢ２０６に対して取得対象のページを空きＤＢバッファページに読込むためにページ読込み要求を発行し（ステップＳ５５）、処理をステップＳ５６に進める。これにより、ＤＢバッファ１４６０から取得した空きＤＢバッファページに、取得対象のページがＤＢ２０６から読み込まれる。

ステップＳ５６では、ＤＢバッファ管理部１４６が、ＤＢ２０６からのページの読込みが完了するのを待つ。ここで、ＤＢバッファ管理部１４６は、ページの読込みが完了するまで待つ同期Ｉ／Ｏ、または、ページの読込みが完了していなくて他の処理を実行する非同期Ｉ／Ｏの何れかを採用することができる。

例えば、ＤＢバッファ管理部１４６は、実行中のタスクの処理を中断して待ち状態とし、タスク実行状態情報７３を待ちリスト１４５２に移動する。そして、ＤＢバッファ管理部１４６は、別のタスクにより取得対象のページの読込みの完了を判定する。ＤＢバッファ管理部１４６は、当該別のタスクでページの読込みの完了を判定した場合には、当該タスクのタスク実行状態情報７３を実行可能リスト１４５１に移動し、当該タスクの処理を再開させるようにしてもよい。

このように、非同期Ｉ／Ｏを採用すると、ＤＢバッファ管理部１４６は、ページの読込み完了を待たずに、他のタスクの実行を行うことができるようになり、ＤＢＭＳ１４１の処理能力を向上することができる。なお、ＤＢ２０６からのページの読み込みが完了した場合には、ＤＢバッファ管理部１４６は、ＤＢページ取得処理を終了する。

図２７は、実施例１に係るシステム性能閾値表の一例を示す図である。

システム性能閾値表１５４は、ＣＰＵリソースおよびＩ／Ｏリソースの利用が十分であるか否かを判定するための閾値を保持する。ＣＰＵリソースの閾値は計算機１００に搭載された全てのプロセッサの利用率であるＣＰＵ利用率１５４１とする。Ｉ／Ｏリソースの閾値は、外部ストレージ装置２００からの単位時間あたりのデータ転送量であるディスク転送速度１５４２（単位：ＭＢ／ｓ）と、外部ストレージ装置２００の単位時間あたりのＩ／Ｏ要求処理数であるＩＯＰＳ１５４３（単位：ＩＯＰＳ）とする。また、計算機が複数存在するシステムでは、他の計算機との単位時間あたりのパケットの送受信数であるパケット転送レート１５４４（単位：ｐｐｓ（Packet Per Second））もＩ／Ｏリソースの閾値に加えることもできる。本実施例では他の計算機との通信のＩ／Ｏリソースにパケット転送レートを用いているが、他の計算機とのデータ転送量であるネットワーク転送速度（単位：ＭＢ／ｓ）をパケット転送レートの代わりに用いてもよい。

システム性能閾値表１５４の閾値は、ユーザが値を指定しても良いし、計算機システムの構成からＤＢＭＳ１４１が自動計算しても良い。また、性能を測定するためのテストクエリを実行させたり、単純なＣＰＵ処理や単純なランダムＲＥＡＤやシーケンシャルＲＥＡＤを行うことで閾値の値を求めてもよい。

図２７の例では、ＣＰＵ利用率１５４１が閾値の９０％以上であれば、ＣＰＵリソースの活用が十分であると判断する。一方、ディスク転送速度１５４２が閾値の２０００ＭＢ／ｓ以上か、またはＩＯＰＳ１５４３が閾値の６００００ＩＯＰＳ以上であればＩ／Ｏリソースの活用が十分と判断する。なお、実施例１では、計算機１００が１台でありパケット転送レート１５４４は考慮しない。このため、パケット転送レート１５４４には"−１"を設定する。

図２８は、実施例１に係る性能データ表１５５の一例を示す図である。

性能データ表１５５は、システム性能閾値表１５４に登録された閾値に対応する性能データについて現在の値を保持する。性能データ表１５５は、ＣＰＵリソースの性能データとして計算機１００に搭載された全てのプロセッサの利用率であるＣＰＵ利用率１５５１を含む。また、性能データ表１５５は、Ｉ／Ｏリソースの性能データとして、外部ストレージ装置２００からの単位時間あたりのデータ転送量であるディスク転送速度１５５２と、外部ストレージ装置２００の単位時間あたりのＩ／Ｏ要求処理数であるＩＯＰＳ１５５３を含む。

また、計算機１００が複数存在する計算機システムでは、性能データ表１５５に、他の計算機とのデータ転送量であるパケット転送レート１５５４も含める。これらの値は、ＤＢＭＳ１４１がＣＰＵ利用時間やＩ／Ｏコマンドの履歴を保持し、性能データ表１５５を参照するたびに計算してもよい。また、ＤＢＭＳ１４１がＣＰＵ利用時間やＩ／Ｏコマンドの履歴を保持し、一定間隔で性能データ表１５５の値を更新する方法でもよい。また、計算機１００で稼働するＯＳのコマンド（ｍｐｓｔａｔコマンドやｉｏｓｔａｔコマンド）から一定間隔で出力される値から算出した値を、性能データ表１５５に設定してもよい。

なお、性能データ表１５５の各値は、ＤＢＭＳ１４１や計算機１００のＯＳ（図示省略）が所定の周期で取得した値を用いることができる。

図２９は、実施例１に係るタスク生成処理のフローチャートである。この処理は、図２４のステップＳ３４で、クエリ実行部１４４のタスク生成制御部１５２が実行する。

タスク生成処理では、タスク生成制御部１５２がＣＰＵリソースやＩ／Ｏリソースの利用状況によりタスクの生成を調整する。また、タスク生成制御部１５２は、クエリ実行部１４４が図２１のステップＳ３で設定した初期タスク数と上限タスク数または下限タスク数によってもタスク数の調整を行う。タスク数は、実行タスク管理部１４５においてその時点で存在しているタスクの数である。

タスク生成制御部１５２は、初期タスク数が１以上か否かを判定し（ステップＳ５９）、１以上であれば初期状態のタスクを生成する（ステップＳ６７）。その際、タスク生成制御部１５２は、タスク数と初期タスク数を比較して（ステップＳ６８）、タスク数が初期タスク数と同じであれば初期タスク数に０を設定する（ステップＳ６９）。一方、タスク数が初期タスク数と異なれば、タスク生成処理は終了する。これにより、タスク生成制御部１５２は、ＣＰＵリソースやＩ／Ｏリソースの利用状況に関係なく、初期タスク数まではタスク数を増加させることができる。

初期タスク数が１以上でない場合（ステップＳ５９で偽の場合）、タスク生成制御部１５２は、下限タスク数とタスク数の比較を行う（ステップＳ６０）。下限タスク数よりタスク数以下の場合は、タスク生成制御部１５２が初期状態のタスクを生成する（ステップＳ６６）。

下限タスク数よりタスク数が多い場合（ステップＳ６０で真の場合）、タスク生成制御部１５２はＣＰＵリソースやＩ／Ｏリソースの利用状況により初期タスクの生成の可否を判定する。具体的には、性能データ表１５５のＣＰＵ利用率１５５１がシステム性能閾値表１５４のＣＰＵ利用率１５４１より小さいか否かを判定する（ステップＳ６１）。性能データ表１５５のＣＰＵ利用率１５５１が、閾値のＣＰＵ利用率１５４１以上であれば、タスク生成制御部１５２は、タスク生成処理を終了する。

次に、タスク生成制御部１５２は、性能データ表１５５のディスク転送速度１５５２がシステム性能閾値表１５４のディスク（またはデータ）転送速度１５４２より小さいか否かを判定する（ステップＳ６２）。性能データ表１５５のディスク転送速度１５５２が、閾値のディスク転送速度１５４２以上であれば、タスク生成制御部１５２は、タスク生成処理を終了する。

次に、タスク生成制御部１５２は、性能データ表１５５のＩＯＰＳ１５５３がシステム性能閾値表１５４のＩＯＰＳ１５４３より小さいか否かを判定する（ステップＳ６３）。性能データ表１５５のＩＯＰＳ１５５３が、閾値のＩＯＰＳ１５４３以上であれば、タスク生成制御部１５２は、タスク生成処理を終了する。

次に、タスク生成制御部１５２は、性能データ表１５５のパケット転送レート１５５４がシステム性能閾値表１５４のパケット転送レート１５４４より小さいか否かを判定する（ステップＳ６４）。性能データ表１５５のパケット転送レート１５５４が、閾値のパケット転送レート１５４４以上であれば、タスク生成制御部１５２は、タスク生成処理を終了する。

これにより、ＣＰＵリソースやＩ／Ｏリソースの利用が十分であると判断されれば新たなタスクは生成されず、計算機１００の利用が不十分であると判定された場合にタスク生成が行われる。

最後に、タスク生成制御部１５２は、上限タスク数と現在のタスク数を比較し（ステップＳ６５）、タスク数が上限タスク数以上の場合は、タスク生成処理を終了する。一方、タスク数が上限タスク数よりも小さい場合に、タスク生成制御部１５２は、初期状態のタスクを生成する（ステップＳ６６）。

以上の処理により、上限タスク数以上のタスクが生成されるのを防いでいる。なお、図２９では、ＣＰＵリソースの利用とＩ／Ｏリソースの利用の双方をチェックしているが、Ｉ／Ｏリソースの利用状況のチェックだけでもよい。または、ＣＰＵリソースの利用状況のチェックだけでもよい。また、Ｉ／Ｏリソースの利用状況のチェックには、ＩＯＰＳだけを対象にしてもよく、あるいは、ディスク転送速度だけを対象にしてもよく、パケット転送レートだけを指標にしてもよい。また、これらの性能データを組合せたものと、閾値を比較するようにしてもよい。

図３０は、実施例１に係る記憶領域性能データ表１５７の一例を示す図である。

記憶領域性能データ表１５７は、記憶領域＃１〜＃４間のＩ／Ｏリソースの利用状況の偏りの有無を判定するために、記憶領域ごとのＩ／Ｏリソースの利用状況の指標を保持する。記憶領域性能データ表１５７は、記憶領域名１５７１と、指標１５７２と、値１５７３からエントリが構成される。指標１５７２としては、例えば、発行中のＩ／Ｏ要求数であるアウトスタンディングＩ／Ｏ数１５７４と、ディスク転送速度１５７５と、ＩＯＰＳ１５７６とを保持する。これらの値は、図２８に示した性能データ表１５５と同じ方法によって設定される。

図３１は、実施例１に係るコンテキスト取得処理のフローチャートである。この処理は、図２３のステップＳ２１で行われる処理である。

実施例１のコンテキスト取得処理では、Ｉ／Ｏリソースの利用に記憶領域＃１〜＃４間で偏りがある場合に、クエリ実行部１４４のコンテキスト管理部１５３は空いている記憶領域を優先的に利用するようにコンテキストを選択する。これにより、空いている記憶領域＃１〜＃４を活用するタスクを生成させることができる。図３１の例では、Ｉ／Ｏリソースの利用状況を示す指標に、図３０に示したアウトスタンディングＩ／Ｏ数１５７４を用いる。しかし、図３０に示したディスク転送速度１５７５やＩＯＰＳ１５７６を指標にしてＩ／Ｏリソースの利用状況を判定しても良い。

まず、コンテキスト管理部１５３は記憶領域性能データ表１５７を参照し、アウトスタンディングＩ／Ｏ数１５７４が最も小さい記憶領域名１５７１を選択する（ステップＳ７１）。

コンテキスト管理部１５３は、ステップＳ７１で選択した記憶領域名１５７１がＩ／Ｏ要求を発行する記憶領域となっているコンテキスト１５３０を、処理ステップの番号の大きい順に検索する（ステップＳ７２）。コンテキスト管理部１５３は、自身が管理するコンテキスト１５３０の中から検索し、該当するコンテキスト１５３０が存在する場合は、コンテキスト取得処理を終了する（ステップＳ７３）。

一方、コンテキスト管理部１５３は、該当するコンテキスト１５３０が存在しない場合は、その他の記憶領域にＩ／Ｏ要求を発行するコンテキスト１５３０を、処理ステップ番号の大きいものから順に検索する（ステップＳ７４）。

これにより、クエリ実行部１４４のコンテキスト管理部１５３は、Ｉ／Ｏリソースの利用が少ない記憶領域名１５７１にＩ／Ｏ要求を発行するコンテキストが優先的に選択される。この結果、クエリ実行部１４４は、Ｉ／Ｏリソースの利用が少ない記憶領域にＩ／Ｏ要求を発行するタスクを生成することができる。

本発明を用いない従来例の場合は、図１８に示したコンテキスト１５３０が生成される。そして、コンテキスト１５３０の未処理データリスト１５６２の順にタスクを生成するため、ＲｏｗＩＤ（Ｐ２２，１）、ＲｏｗＩＤ（Ｐ２３，４）、ＲｏｗＩＤ（Ｐ２４，２）と記憶領域＃１にＩ／Ｏ要求を行うタスクを生成する。

これに対して、本実施例１では、図３０に示した記憶領域性能データ表１５７からアウトスタンディングＩ／Ｏ数１５７４が小さい記憶領域名１５７１を選択し、選択した記憶領域名１５７１にＩ／Ｏ要求を発行するコンテキスト１５３０を選択してタスクを生成する。このため、クエリ実行部１４４は、全ての記憶領域＃１〜＃４に均等にＩ／Ｏ要求を発行するタスクを生成することが可能となる。

具体的には、既に既存のタスクが、図７で示したＲｏｗＩＤ（Ｐ２１，２）にＩ／Ｏ要求を発行しているため，新規タスクが追加された際にはＲｏｗＩＤ（Ｐ１２０，１）、ＲｏｗＩＤ（Ｐ２２０，２）、ＲｏｗＩＤ（Ｐ３２１、４）という順にタスクを生成する。つまり、従来技術では記憶領域＃１に偏ってＩ／Ｏ要求が発行されていたのに対し、本実施例では４つの記憶領域＃１〜＃４へ均等にＩ／Ｏ要求を発行することが可能となるのである。

以上の処理により、タスクを動的に生成するＤＢＭＳ１４０では、ＣＰＵリソースやＩ／Ｏリソースの利用状況がシステム性能閾値表１５４の閾値以内でタスクを生成することが可能となる。また、ＤＢＭＳ１４０がタスクを生成する際には、利用が不十分なリソースを優先して利用するタスクを生成することにより、ＣＰＵリソースやＩ／Ｏリソースの利用率を向上させることが可能となる。これにより、特定のリソースに処理が偏るのを防いで、ＤＢＭＳ１４１の処理能力を向上させることが可能となるのである。

以下、実施例２を説明する。その際、実施例１との相違点を主に説明し、実施例１との共通点については説明を省略或いは簡略する。

図３２は、実施例２に係る記憶領域性能閾値表１５４Ａの一例を示す図である。

記憶領域性能閾値表１５４Ａは、記憶領域ごとに性能が十分であると判定するために性能の閾値を保持している。これら閾値の設定は、前記実施例１の図２７に示したシステム性能閾値表１５４の閾値の設定と同様の手法にて設定するのでも良い。

記憶領域性能閾値表１５４Ａは、記憶領域名１５４１Ａと、項目１５４２Ａと、値１５４３Ａからエントリが構成される。そして、項目１５４２Ａとしては、例えば、ディスク転送速度１５４４Ａの閾値と、ＩＯＰＳ１５４５Ａの閾値とを保持する。

図３３は、実施例２に係るコンテキスト取得処理のフローチャートである。この処理は、実施例１の図２３のステップＳ２１で行われる処理である。

クエリ実行部１４４のコンテキスト管理部１５３は、図３３Ａの記憶領域性能閾値表１５４Ａのディスク転送速度（閾値）１５４４ＡとＩＯＰＳ１５４５Ａ（閾値）を指標とする。コンテキスト管理部１５３は、ディスク転送速度を指標としたＩ／Ｏリソースの利用率であるディスク転送利用率と、ＩＯＰＳを指標にしたＩ／Ｏリソースの利用率であるＩＯＰＳ利用率を計算する（ステップＳ８１）。ここで、ディスク転送利用率は、前記実施例１の図２８に示した性能データ表１５５のディスク転送速度１５５２を、図３２に示した記憶領域性能閾値表１５４Ａの記憶領域名１５４１Ａ毎のディスク転送速度（閾値）１５４２で割った値である。また、ＩＯＰＳ利用率は、前記実施例１の図２８に示した性能データ表１５５のＩＯＰＳ１５５３を、システム性能閾値表１５４のＩＯＰＳ１５４３で割った値である。

コンテキスト管理部１５３は、ディスク転送利用率とＩＯＰＳ利用率を比較する（ステップＳ８２）。ディスク転送利用率の方が大きければ、ディスク転送速度がＩ／Ｏ性能の決定要因であるためステップＳ８３に進み、コンテキスト管理部１５３は、記憶領域＃１〜＃４ごとにディスク転送利用率を計算する（ステップＳ８３）。

そして、コンテキスト管理部１５３は、ディスク転送利用率が最も小さい記憶領域を選択する（ステップＳ８４）。

一方、ステップＳ８２の判定で、ＩＯＰＳ利用率の方が大きければ、ＩＯＰＳがＩ／Ｏ性能を決定する要因であるため、コンテキスト管理部１５３は、記憶領域＃１〜＃４ごとにＩＯＰＳ利用率を計算し（ステップＳ８５）、ＩＯＰＳ利用率が最も小さい記憶領域を選択する（ステップＳ８６）。

コンテキスト管理部１５３は、ステップＳ８４またはステップＳ８６で選択した記憶領域にＩ／Ｏ要求を出すコンテキストを処理ステップの大きい順に検索し（ステップＳ８７）、該当するコンテキストが存在すれば、そのコンテキストを選択する（ステップＳ８８）。

一方、ステップＳ８８でコンテキストが見つからない場合、コンテキスト管理部１５３は、ステップＳ８４またはステップＳ８６で選択された記憶領域以外で処理ステップの大きい順にコンテキストを選択する（ステップＳ８９）。

これにより、実施例２では、記憶領域＃１〜＃４ごとに設定された閾値によりＩ／Ｏリソースの利用率を計算し、前記Ｉ／Ｏリソースの利用率の低い記憶領域＃１〜＃４にＩ／Ｏ要求を発行するタスクを生成することができる。

以下、実施例３を説明する。その際、実施例１との相違点を主に説明し、実施例１との共通点については説明を省略或いは簡略する。

図３４は、実施例３に係るＤＢ２０６の第二のクエリの一例を示す図である。

図３４に示すクエリは、Ｐａｒｔ表２０５１（カラムｃ１、ｃ２）及びＬｉｎｅｉｔｅｍ表２０５４（カラムｃ３、ｃ４）から、カラムｃ１の値が"１３０"であり、且つカラムｃ４の値が"ｚ"であり、且つカラムｃ２の値とカラムｃ３の値とが同じであるものについて、カラムｃ１の値とカラムｃ４の値とを抽出することを意味している。

図３５は、実施例３に係るクエリ実行プランの一例を説明する図である。

図３５に示すクエリ実行プランは、ＤＢＭＳ１４１が、図３４に示したクエリを受け付けた場合に、クエリ実行プラン生成部１４３により生成されるクエリ実行プランの一例を示している。

図３４に示したクエリに対応するクエリ実行プランは、図３５に示すように、ＤＢＭＳ１４１がＬｉｎｅｉｔｅｍ表２０５４の全てのＤＢ２０６のページを読込んで、条件に合致したレコードを取得するテーブルスキャンを行う処理ステップ＃１と、Ｐａｒｔ索引２０４１による索引検索を行う処理ステップ＃２と、Ｐａｒｔ表２０５１からレコードを取得する処理ステップ＃３と、Ｌｉｎｅｉｔｅｍ表２０５４から読み込んだデータと、Ｐａｒｔ表２０５１から読み込んだデータをハッシュ結合する処理ステップ＃４と、これらの結果をネストループ結合する処理ステップ＃５とを含む。なお、図３５のクエリ実行プランでは、Ｌｉｎｅｉｔｅｍ表２０５４のデータをＢｕｉｌｄ側とし、Ｐａｒｔ表２０５１のデータをＰｒｏｂｅ側とする。

図３６は、実施例３に係る処理ステップ毎にＣＰＵコストを設定したコストテーブル１４３１の一例を示す図である。

処理ステップにおけるＣＰＵコストは、図１２で説明したＣＰＵコストと同様の方法にて取得するのでもよい。図示のコストテーブル１４３１では、前記実施例１の図１２と同様にＣＰＵコストが設定され、処理ステップ＃４については、上述のＢｕｉｌｄ側と、Ｐｒｏｂｅ側のＣＰＵコストがそれぞれ設定される。

実施例３では、図３５に示したクエリ実行プランで生成される３種類のコンテキストを想定する。なお本実施例のテーブルスキャン（処理ステップ＃１）では、６４個のＤＢページを一つの管理領域として管理し、１６個のＤＢページで１個のＩ／Ｏ要求とすることを想定する。なお、管理するページ数は他の管理単位であってもよく、Ｉ／Ｏ要求する際のページ数は他の値でも良い。

図３７は、実施例３に係る第５コンテキスト１５３０−５の一例を示す図である。

第５のコンテキストは、処理ステップ＃１のテーブルスキャンでＩ／Ｏ要求を発行するタスクを生成するためのコンテキストである。Ｉ／Ｏ要求は１６個のページ（４ＫＢ／ページ）を連続して読むため、Ｉ／Ｏサイズ１５３６は６４ＫＢとなる。また、上述のように、６４個のＤＢページで一つの管理領域となるため、コンテキスト１５３０−５では４個のタスクが生成可能となる。このため、生成可能数１５３３には"４"が設定される。

Ｉ／Ｏパターン１５３７は、ＤＢＭＳ１４１が連続してＤＢ２０６のページを読み込むため、シーケンシャルとする。ＣＰＵコスト１５３８は、処理ステップ＃１の後に処理ステップ＃４のＢｕｉｌｄ処理を行うため、図３６のコストテーブル１４３１より１０＋１０＝２０を設定する。なお、中間結果１５３２や実行状態１５３４に関しては、実施例１と同様に設定すればよいので、ここでは説明を省略する。

図３８は、実施例３に係る第６のコンテキスト１５３０−６の一例を示す図である。

第６のコンテキスト１５３０−６は、処理ステップ＃１のテーブルスキャンでＩ／Ｏ要求を伴わないタスクを生成するためのコンテキストである。これらのタスクは第５のコンテキスト１５３０−５から生成されたタスクがＩ／Ｏ要求を完了した後に生成するコンテキスト１５３０−６で、このコンテキスト１５３０−６がある限りはＤＢＭＳ１４１が読み込んだＤＢ２０６のページはメモリ１４０に保持しておく。

例えば、１６個のＤＢページに１６１レコード格納されている場合は、生成可能数１５３３に１６０を設定する。本タスクはＩ／Ｏ要求を伴わないので、記憶領域名１５３５は"なし"、Ｉ／Ｏサイズ１５３６は"０"、Ｉ／Ｏパターン１５３７は"なし"を設定する。ＣＰＵコスト１５３８は、第５のコンテキスト１５３０−５と同様に"２０"を設定する。

図３９は、実施例３に係る第７のコンテキスト１５３０−７の一例を示す図である。

第７のコンテキスト１５３０−７は、処理ステップ＃２で生成されるランダムなＩ／Ｏ要求を行うタスクを生成するコンテキストである。これは、実施例１のコンテキスト１５３０−１と同様のため、説明は省略する。

図４０は、実施例３に係るコンテキスト取得処理の一例を示すフローチャートである。この処理は、実施例１の図２３のステップＳ２１で行われる処理である。

クエリ実行部１４４のコンテキスト管理部１５３は、前記実施例２と同様にして、ディスク転送利用率とＩＯＰＳ利用率を計算し、利用率が大きい方をＩ／Ｏリソース利用率とする（ステップＳ９１）。ディスク転送利用率と、ＩＯＰＳ利用率は、実施例２のステップＳ８１の方法と同じでよい。また、コンテキスト管理部１５３は、ＣＰＵ利用率を算出する。ここで、ＣＰＵ利用率は、前記実施例１の図２８に示した性能データ表１５５のＣＰＵ利用率１５５１を、図２７に示したシステム性能閾値表１５４のＣＰＵ利用率１５４１で割った値である。

コンテキスト管理部１５３は、Ｉ／Ｏリソース利用率とディスク転送利用率を比較し（ステップＳ９２）、Ｉ／Ｏリソース利用率が低ければ、Ｉ／Ｏリソース利用率を高める必要があると判断し、処理ステップ番号の大きい順にＩ／Ｏを行うコンテキストから優先的に検索する（ステップＳ９３）。例えば、第５のコンテキスト１５３０−５と第６のコンテキスト１５３０−６と第７のコンテキスト１５３０−７が存在している状況では、第５のコンテキスト１５３０−５が選択される。

一方、コンテキスト管理部１５３は、Ｉ／Ｏリソース利用率が高ければ、Ｉ／Ｏリソース利用率を高める必要がないと判定し、処理ステップ番号の大きい順に、Ｉ／Ｏを行わないコンテキストを優先的に選択する（ステップＳ９４）。例えば、第５のコンテキスト１５３０−５と第６のコンテキスト１５３０−６と第７のコンテキスト１５３０−７が存在している状況では、第６のコンテキスト１５３０−６が選ばれる。

なお、実施例３ではＩ／Ｏリソースの利用率が低いことを、ＣＰＵ利用率とＩ／Ｏリソース利用率を比較することで判断したが、これ以外の方法で判断してもよい。例えば、外部からＩ／Ｏリソース利用率が高いと判断できる値を設定してもよい。

これにより、実施例３では、Ｉ／Ｏリソースの利用が低い場合には、Ｉ／Ｏリソースの利用率の高いコンテキストを選択することで、Ｉ／Ｏリソースの利用率の高いタスクを生成することができる。一方、Ｉ／Ｏリソースの利用が高い場合には、Ｉ／Ｏリソースの利用率が低いコンテキストを選択することで、Ｉ／Ｏリソースの利用率の低いタスクを生成することができる。

以下、実施例４を説明する。その際、実施例３との相違点を主に説明し、実施例３との共通点については説明を省略或いは簡略する。

図４１は、実施例４に係るコンテキスト取得処理の一例を示すフローチャートである。この処理は、実施例１の図２３のステップＳ２１で行われる処理である。

クエリ実行部１４４のコンテキスト管理部１５３は、前記実施例２と同様にして、ディスク転送利用率とＩＯＰＳ利用率を計算し、利用率が大きい方をＩ／Ｏリソース利用率とする（ステップＳ１０１）。ディスク転送利用率とＩＯＰＳ利用率は、ステップＳ８１の方法と同じでよい。また、コンテキスト管理部１５３は、前記実施例３と同様にしてＣＰＵ利用率を演算する。

コンテキスト管理部１５３は、Ｉ／Ｏリソース利用率とＣＰＵ利用率を比較し（ステップＳ１０２）、ＣＰＵ利用率が高ければ、ＣＰＵ利用率を高める必要がないと判定し、処理ステップ番号の大きい順にＣＰＵコストが小さいコンテキストから優先的に選択する（ステップＳ１０３）。例えば、第５のコンテキスト１５３０−５と第６のコンテキスト１５３０−６と第７のコンテキスト１５３０−７が存在している状況では、第５のコンテキスト１５３０−５または第６のコンテキスト１５３０−６が選ばれる。

一方、コンテキスト管理部１５３は、ＣＰＵ利用率が低ければ、ＣＰＵ利用率を高める必要があると判断し、処理ステップ番号の大きい順に、ＣＰＵコストが大きいコンテキストから優先的に選択する（ステップＳ１０４）。例えば、第５のコンテキスト１５３０−５と第６のコンテキスト１５３０−６と第７のコンテキスト１５３０−７が存在している状況では、第７のコンテキスト１５３０−７が選択される。

なお、実施例４ではＣＰＵリソースの利用率（ＣＰＵ利用率）が低いことを、ＣＰＵ利用率とＩ／Ｏリソース利用率を比較することで判定したが、これ以外の方法で判定してもよい。例えば、外部からＣＰＵ利用率が高いと判定できる値を設定してもよい。あるいは、予め設定したＣＰＵ利用率の閾値と、ＣＰＵ利用率を比較しても良い。

これにより、実施例４では、ＣＰＵリソースの利用率が低い場合には、ＣＰＵコストの高いコンテキストを選択することで、ＣＰＵリソースをより利用するタスクを生成することができる。なお、ＤＢＭＳ１４１は、ＣＰＵ利用率が低いときには、コストテーブル１４３１を参照して最もＣＰＵコスト１４３３が大きい処理ステップ１４３２のタスクを生成し、ＣＰＵコスト１４３３が高いときには、コストテーブル１４３１を参照して最もＣＰＵコスト１４３３が小さい処理ステップ１４３２のタスクを生成するようにしても良い。

なお、実施例３および実施例４においては、Ｉ／ＯリソースとＣＰＵリソースのどちらかで空いているリソースを利用するコンテキストを選択したが、メモリリソースと比較してもよい。具体的には、Ｉ／Ｏリソースの利用率とメモリリソースの利用率を比較して、メモリリソースが空いているかどうかを判定し、メモリリソースが空いていればメモリリソースをより多く利用するコンテキストを選択してもよい。また、ＣＰＵリソースの利用率とメモリリソースの利用率を比較して、メモリリソースが空いているかどうかを判定し、メモリリソースが空いていればメモリリソースをより多く利用するコンテキストを選択してもよい。

以下、実施例５を説明する。その際、実施例３との相違点を主に説明し、実施例３との共通点については説明を省略或いは簡略する。

図４２は、実施例５に係るコンテキスト取得処理の一例を示すフローチャートである。この処理は、実施例１の図２３のステップＳ２１で行われる処理である。

クエリ実行部１４４のコンテキスト管理部１５３は、前記実施例２と同様にして、ディスク転送利用率とＩＯＰＳ利用率を計算する（ステップＳ１１１）。ディスク転送利用率とＩＯＰＳ利用率は、ステップＳ８１の方法と同じでよい。

コンテキスト管理部１５３は、ディスク転送利用利率とＩＯＰＳ利用率を比較し（ステップＳ１１２）、ディスク転送利用率が高い場合は、Ｉ／Ｏパターンがシーケンシャルのコンテキストを、処理ステップ番号の大きい順に検索する（ステップＳ１１３）。例えば、第５のコンテキスト１５３０−５と第７のコンテキスト１５３０−７がある状況では、第５のコンテキスト１５３０−５が選択される。コンテキスト管理部１５３は、コンテキストが取得できれば終了する（ステップＳ１１４）。

コンテキストが取得できない場合、コンテキスト管理部１５３は、Ｉ／Ｏパターン１５３７がランダムのコンテキストを、処理ステップ番号の大きい順に検索する（ステップＳ１１５）。例えば、第５のコンテキスト１５３０−５と第７のコンテキスト１５３０−７がある状況では、第７のコンテキスト１５３０−７が選択される。

一方、コンテキスト管理部１５３は、ディスク転送利用利率とＩＯＰＳ利用率を比較し（ステップＳ１１２）、ＩＯＰＳ利用率が高い場合は、Ｉ／Ｏパターン１５３７がランダムのコンテキストを、処理ステップ番号の大きい順に検索する（ステップＳ１１６）。コンテキスト管理部１５３はコンテキストを取得すれば処理を終了する（ステップＳ１１７）。

コンテキストを取得できない場合、コンテキスト管理部１５３は、Ｉ／Ｏパターン１５３７がシーケンシャルのコンテキストを、処理ステップ番号の大きい順に検索する（ステップＳ１１８）。

なお、実施例５では、現在のＩ／Ｏパターンを判定するのにディスク転送利用率とＩＯＰＳ利用率を比較することで判断している。つまり、ディスク転送利用率が高い場合はシーケンシャルであり、ＩＯＰＳ利用率が高い場合はランダムである。この他の方法を用いてＩ／Ｏパターンを判断してもよい。例えば、一定数のＩ／Ｏパターンの履歴をＤＢＭＳが保持しておき、Ｉ／Ｏパターンを判断するのでもよい。ＯＳがＩ／Ｏパターンを判定し、ＤＢＭＳ１４１が前記結果を参照するのでもよい。

これにより、実施例５では、Ｉ／Ｏパターンに応じて同じＩ／Ｏパターンを行うコンテキストを選択し、同じＩ／Ｏパターンを行うタスクを生成することができる。

以下、実施例６を説明する。その際、実施例１との相違点を主に説明し、実施例１との共通点については説明を省略或いは簡略する。

図４３は、実施例６に係る計算機システムの構成を示すブロック図である。

実施例６は複数の計算機１００−１〜１００−４で動作するＤＢＭＳ１４１−１〜１４１−４が協調して処理を行うデータベース管理システムの一例を示す。

図４３では、４台の計算機（計算機１、計算機２、計算機３、計算機４）１００−１〜１００−４でデータベース管理システムが構成される例を示す。４台の計算機１００−１〜１００−４はネットワーク３００で接続されている。

各計算機１００−１〜１００−４は外部ストレージ装置２００−１〜２００−４をそれぞれ有しており、計算機１００−１〜１００−４と外部ストレージ装置２００−１〜２００−４はネットワークによって接続されている。計算機１（１００−１）が接続している外部ストレージ装置２００−１は記憶領域＃１を含み、計算機２（１００−２）と接続している外部ストレージ装置２００−２は記憶領域＃２を含み、計算機３（１００−３）と接続している外部ストレージ装置２００−３は記憶領域＃３を含み、計算機４（１００−４）と接続している外部ストレージ装置２００−３は記憶領域＃４を含む。なお、図４３では独立した外部ストレージ装置２００−１〜２００−４で構成された例を示すが、複数の計算機１００−１〜１００−４でひとつの外部ストレージ装置２００を共有しても良い。この場合、共有される外部ストレージ装置２００内には、独立した記憶領域＃１〜＃４があれば良い。なお、計算機１００−１〜１００−４、ＤＢＭＳ１４１−１〜１４１−４、外部ストレージ装置２００−１〜２００−４は、それぞれ前記実施例１の計算機１００、ＤＢＭＳ１４１及び外部ストレージ装置２００と同様の構成である。

図４４は、実施例６に係るＤＢ領域管理表１４７Ａの一例を示す図である。実施例６のＤＢ領域管理表１４７Ａは、前記実施例１の図１０に示したＤＢ領域管理表１４７にＤＢＭＳ識別子１４７４を加えた点が、前記実施例１のＤＢ領域管理表１４７と相違し、その他は、同様の構成である。

複数の計算機１００−１〜１００−４が協調して処理を行うＤＢＭＳ１４０−１〜１４０−４では、記憶領域＃１〜＃４ごとにアクセスするＤＢＭＳ１４０−１〜１４０−４が決定される。このため、ＤＢ領域管理表１４７Ａは、ＤＢオブジェクト１４７１、ページ番号１４７２、記憶領域名１４７３に、ＤＢＭＳ識別子１４７４を追加したものである。ＤＢＭＳ識別子１４７４はＤＢＭＳ１４０−１〜１４０−４を識別するための情報で、本識別子により、いずれの計算機１００−１〜１００−４上で動作しているのかも特定可能である。

図４５は、実施例６に係る第８のコンテキスト１５３０−８の一例を示す図である。

独立した外部ストレージ装置２００−１〜２００−４を有する複数の計算機１００−１〜１００−４が、協調して処理を行うデータベース管理システムでは、タスクを処理可能なＤＢＭＳ１４０−１〜１４０−４が限られるため、コンテキスト１５３０−８に処理を実行するＤＢＭＳを設定するＤＢＭＳ識別子１５６３を加える。

図４５は前記実施例１の第８のコンテキスト１５３０−８を、複数の計算機１００−１〜１００−４が協調して処理を行うデータベース管理システムで処理する場合の例である。記憶領域＃１にＩ／Ｏ要求を発行するタスクは、計算機１００−１のＤＢＭＳ１でのみ処理可能なため、ＤＢＭＳ識別子１５６３には"ＤＢＭＳ１"を設定する。

図４６は、実施例６に係る第９のコンテキスト１５３０−９の一例を示す図である。

図４６は前記実施例１に示した第９のコンテキスト１５３０−９を複数の計算機１００−１〜１００−４が協調して処理を行うデータベース管理システムで処理する場合の例である。

独立した外部ストレージ装置２００−１〜２００−４を有する複数の計算機１００−１〜１００−４が、協調して処理を行うデータベース管理システムでは、タスクを処理可能なＤＢＭＳ１４０−１〜１４０−４が限られる。

このため、第９のコンテキスト１５３０−９には、処理を実行するＤＢＭＳ１４０−１〜１４０−４を設定するＤＢＭＳ識別子１５６３を加える。図示の例では、記憶領域＃２にＩ／Ｏ要求を発行するタスクは、計算機１００−２で実行されるＤＢＭＳ２でのみ処理可能なため、ＤＢＭＳ識別子１５６３には"ＤＢＭＳ２"を設定する。

図４７は、実施例６に係るタスク実行処理の一例を示すフローチャートである。この処理は、前記実施例１の図２２のステップＳ１７において、新たなタスクに対して行われる処理で、複数の計算機１００−１〜１００−４が協調して処理を行うデータベース管理システムに適用される。

タスク実行処理は、クエリ実行部１４４が、処理の決まっていない新規のタスクを実行する際に適用される。処理が決まっていない新規タスクを生成して処理を開始する。新規タスクの処理を決めるために、コンテキスト取得処理を行う（ステップＳ１２１）。コンテキスト取得処理の内容は、後述する図４８で説明する。

クエリ実行部１４４は、取得したコンテキストのＤＢＭＳ識別子１５６３を判定し、現在処理しているＤＢＭＳ１４０−１〜１４０−４の識別子と比較する（ステップＳ１２２）。例えば、このタスク実行処理をＤＢＭＳ１（１４０−１）で処理しており、図４５に示した第８のコンテキスト１５３０−８を取得した場合は、コンテキスト１５３０−８のＤＢＭＳ識別子１５６３と自ＤＢＭＳのＤＢＭＳ識別子が同じとなる。この場合、ステップＳ１２２の判定結果は"真"となって、ステップＳ１２３の処理へ進む。一方、図４６の第９のコンテキスト１５３０−９を取得した場合は、コンテキストのＤＢＭＳ識別子１５６３と自ＤＢＭＳのＤＢＭＳ識別子が異なる。この場合、ステップＳ１２２の判定結果は"偽"となって、ステップＳ１２５の処理へ進む。

コンテキスト１５３０のＤＢＭＳ識別子１５６３と自ＤＢＭＳのＤＢＭＳ識別子が同じ場合、クエリ実行部１４４は、タスクの実行状態情報を設定する（ステップＳ１２３）。この処理は、図２３のステップＳ２２と同様に、クエリ実行部１４４が、取得したコンテキストを使ってタスクの実行状態情報７３（図１３参照）を設定する。

そして、クエリ実行部１４４は、処理ステップ実行処理を行う（ステップＳ１２４）。この処理は、前記実施例１に示した図２３のステップＳ２２と同様であり、クエリ実行部１４４は、ステップＳ１２３で設定された状態に従い、処理ステップ実行処理を実行する。

コンテキストのＤＢＭＳ識別子１５６３と自ＤＢＭＳのＤＢＭＳ識別子が異なる場合は、タスクを実行させるために入手したコンテキストを、コンテキストのＤＢＭＳ識別子１５６３のＤＢＭＳ１４０−１〜１４０−４へネットワーク３００を介して送信する（ステップＳ１２５）。このコンテキストは、送信されたＤＢＭＳ１４０−１〜１４０−４上で再びコンテキスト管理部１５３に登録され、送信されたＤＢＭＳ１４０−１〜１４０−４上でコンテキストからタスクを生成し、タスクを実行する。

図４８は、実施例６に係るコンテキスト取得処理の一例を示すフローチャートである。

複数の計算機１００−１〜１００−４が協調して処理を行うデータベース管理システムでは、システム性能閾値表１５４（図２７参照）のパケット転送レート１５４４と性能データ表１５５（図２８参照）のパケット転送レート１５５４に値が設定される。

クエリ実行部１４４は、システム性能閾値表１５４のパケット転送レート１５４４と、性能データ表１５５のパケット転送レート１５５４を比較し（ステップＳ１３１）、性能データ表１５５のパケット転送レート１５５４が小さい場合は、処理ステップ番号の大きい順に、自ＤＢＭＳ識別子と異なるＤＢＭＳ識別子１５６３のコンテキストを優先的に選択する（ステップＳ１３２）。

一方、性能データ表１５５のパケット転送レート１５５４が小さい場合は、処理ステップ番号の大きい順に、自ＤＢＭＳ識別子と同じＤＢＭＳ識別子１５６３のコンテキストから優先的に選択する（ステップＳ１３３）。

これにより、実施例６では、計算機１００−１〜１００−４間のデータ転送に関するＩ／Ｏリソースであるネットワークリソースの利用が低い場合に、ネットワークリソースをより多く使うタスクを生成することができる。

以上、実施例１から実施例６を説明したが、各実施例では１つの指標においてタスクを選択してきた。実際は１つの指標だけでなく複数の指標を混ぜてタスクを選択することで、ＣＰＵリソースやＩ／Ｏリソース、メモリリソースを活用することも可能である。例えば、メモリの使用率が指定された閾値より小さい場合に、新たなタスクを生成するといったことも可能である。さらに、タスクを生成する際には、メモリの使用率に応じてタスクを生成する。指定されたメモリ使用率より小さい場合はメモリリソースの利用が大きいタスクを生成し、指定されたメモリ使用率より大きい場合はメモリリソースの利用が小さいタスクを生成したりする。

上記実施例１から実施例６では、一つのＡＰ１４８が一つのＤＢＭＳ１４１で一つのクエリを実行する場合について説明したが、ＡＰ１４８が複数であってもよく、ＤＢＭＳ１４１が複数であってもよく、クエリが複数であってもよい。

また、ＤＢＭＳ１４１がクエリを複数実行する場合は、トランザクションＩＤやユーザＩＤ，スキーマＩＤなどでコンテキストを識別でき、クエリの優先度に応じてタスクを生成する順番を変更してもよい。ＤＢＭＳ１４１が複数稼働する場合は、ＤＢＭＳ１４１の識別子でコンテキストを識別し、ＤＢＭＳ１４１の優先度に応じてタスクを生成する順序を変えてもよい。また、仮想マシンにより複数のＤＢＭＳ１４１を実行する場合は、仮想マシンの識別子でコンテキストを識別し、仮想マシンの優先度に応じてタスクを生成する順番を変えてもよい。

以下、実施例７を説明する。その際、実施例１との相違点を主に説明し、実施例１との共通点については説明を省略或いは簡略する。

図４９は、実施例７に係る計算機システムの構成を示すブロック図である。

アプリケーションサーバ（以下、ＡＰサーバ）４９０２は、ＤＢＭＳ１４１が稼働する計算機（以下、ＤＢサーバ）１００に、通信ネットワーク４９１２を介して通信できるように接続されている。また、ＤＢサーバ１００は、外部ストレージ装置２００に、通信ネットワーク３００を介して通信できるように接続されている。

ユーザ端末（クライアント端末）４９０１は、ＡＰサーバ４９０２に、通信ネットワーク４９１１を介して通信できるように接続されている。ＤＢサーバ１００は、前記実施例１に示したＤＢ２０６を管理するＤＢＭＳ１４１を実行する。外部ストレージ装置２００は、ＤＢ２０６を格納する。ＡＰサーバ４９０２は、ＤＢサーバ１００で実行されるＤＢＭＳ１４１に対してクエリを発行するＡＰを実行する。ユーザ端末４９０１は、ＡＰサーバ４９０２で実行されるＡＰに要求を出す。なお、ユーザ端末４９０１、又は、ＡＰサーバ４９０２は、複数存在しても良い。

ＡＰサーバ管理端末４９０３は、通信ネットワーク４９１４を介してＡＰサーバ４９０２に接続されている。ＤＢサーバ管理端末４９０４は、通信ネットワーク４９１５を介してＤＢサーバ１００に接続されている。ストレージ管理端末４９０５は、通信ネットワーク４９１６を介して外部ストレージ装置２００に接続されている。ＡＰサーバ管理端末４９０３は、ＡＰサーバ４９０２を管理する端末である。ＤＢサーバ管理端末４９０４は、ＤＢサーバ１００を管理する端末である。ストレージ管理端末４９０５は、外部ストレージ装置２００を管理する端末である。ＤＢサーバ管理者又はユーザは、ＤＢサーバ管理端末４９０４から、ＤＢＭＳ１４１に関する設定を行っても良い。なお、管理端末４９０３〜４９０５のうちの少なくとも二つが共通（一体）であっても良い。また、通信ネットワーク４９１１、４９１２、４９１４、４９１５、４９１６、及び３００のうちの少なくとも二つが共通（一体）であっても良い。

実施例７では、例えば、下記の通り処理が実行される。

ステップＳ１４１では、ユーザ端末４９０１は、ＡＰサーバ４９０２に要求（以下、ユーザ要求）を発行する。

ステップＳ１４２では、ＡＰサーバ４９０２が、ステップＳ１４１で受信したユーザ要求に従いクエリを生成する。そして、生成したクエリをＤＢサーバ１００に発行する。

ステップＳ１４３では、ＤＢサーバ１００は、ＡＰサーバ４９０２からのクエリを受け付け、受け付けたクエリを実行する。ＤＢサーバ１００は、受け付けたクエリの実行において必要なデータの入出力要求（例えば、データの読出し要求）を外部ストレージ装置２００に発行する。ＤＢサーバ１００は、一つのクエリの実行において、複数のデータ入出力要求を並行して発行することがある。そのため、ＤＢサーバ１００は、一つのクエリの実行において、ステップＳ１４３の要求を複数回並行して行うことがある。

ステップＳ１４４では、外部ストレージ装置２００は、Ｓ１４３で発行されたデータ入出力要求について、ＤＢサーバ１００に応答する。外部ストレージ装置２００は、Ｓ１４４の応答を複数回並行して行うことがある。

ステップＳ１４５では、ＤＢサーバ１００は、クエリの実行結果を生成し、ＡＰサーバ４９０２に送信する。

ステップＳ１４６では、ＡＰサーバ４９０２は、クエリの実行結果を受信する。そして、該実行結果に従う、Ｓ１４１で受信したユーザ要求に対する回答を、ユーザ端末４９０１に送信する。

なお、ＡＰサーバ４９０２に発行されるユーザ要求、又は、ＤＢサーバ１００へ発行されるクエリは、同時に複数あっても良い。

以上のように、実施例７では、ＡＰサーバ４９０２をＤＢサーバ１００から分離した構成であっても、本発明を適用することができる。

なお、本発明において説明した計算機等の構成、処理部及び処理手段等は、それらの一部又は全部を、専用のハードウェアによって実現してもよい。

また、本実施例で例示した種々のソフトウェアは、電磁的、電子的及び光学式等の種々の記録媒体（例えば、非一時的な記憶媒体）に格納可能であり、インターネット等の通信網を通じて、コンピュータにダウンロード可能である。

また、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上記した実施例は本発明をわかりやすく説明するために詳細に説明したものであり、必ずしも説明した全ての構成を備えるものに限定されるものではない。

Claims (15)

1. ストレージ装置に格納されたデータベースを管理するデータベース管理装置であって、
   前記データベースへのクエリを受け付けるクエリ受付部と、
   前記受け付けたクエリを実行するために必要な１以上のデータベースオペレーションを表す情報を含むクエリ実行プランを生成するクエリ実行プラン生成部と、
   前記生成したクエリ実行プランに基づいて前記受け付けたクエリを実行する際に、データベースオペレーションを実行するためのタスクを動的に生成し、前記動的に生成されたタスクを実行するクエリ実行部と、
   を有し、
   前記クエリ実行部は、
   受け付けたクエリの実行に利用されるリソースの利用状況を取得し、
   前記生成されたタスクで実行されるデータベースオペレーションの次のデータベースオペレーションを実行する場合には、前記リソースの利用状況に基づいて新たなタスクを生成し、
   当該新たなタスクを前記生成されたタスクと並列して実行する、ことを特徴とするデータベース管理装置。
2. 請求項１に記載のデータベース管理装置であって、
   前記クエリ実行部は、
   前記リソースの利用状況としてＩ／Ｏリソースの利用状況を用い、
   前記Ｉ／Ｏリソースの利用状況として、前記ストレージ装置からの、若しくは前記ストレージ装置へのデータ転送量、又は、前記ストレージ装置へのＩ／Ｏ要求数を取得し、前記データ転送量、又は、前記Ｉ／Ｏ要求数に基づいて新たなタスクを生成する、ことを特徴とするデータベース管理装置。
3. 請求項２に記載のデータベース管理装置であって、
   前記Ｉ／Ｏ要求数は、前記ストレージ装置に発行される前記ストレージ装置からの入力要求数であることを特徴とするデータベース管理装置。
4. 請求項１に記載のデータベース管理装置であって、
   前記クエリ実行部は、
   前記リソースの利用状況としてＣＰＵリソースの利用状況を用い、
   前記ＣＰＵリソースの利用状況としてＣＰＵ利用率を取得し、前記ＣＰＵ利用率に基づいて新たなタスクを生成する、ことを特徴とするデータベース管理装置。
5. 請求項２に記載のデータベース管理装置であって、
   前記クエリ実行部は、
   前記データ転送量が予め設定されたデータ転送量閾値よりも小さく、かつ、前記Ｉ／Ｏ要求数が予め設定されたＩ／Ｏ要求数閾値よりも小さい場合に前記新たなタスクを生成することを特徴とするデータベース管理装置。
6. 請求項５に記載のデータベース管理装置であって、
   前記クエリ実行部は、
   前記リソースの利用状況として前記Ｉ／Ｏリソースに加えてＣＰＵリソースの利用状況を用い、
   前記ＣＰＵリソースの利用状況としてＣＰＵ利用率を取得し、
   前記ＣＰＵ利用率が予め設定されたＣＰＵ利用率閾値よりも小さく、かつ、前記データ転送量が前記データ転送量閾値よりも小さく、かつ、前記Ｉ／Ｏ要求数が前記Ｉ／Ｏ要求数閾値よりも小さい場合に前記新たなタスクを生成することを特徴とするデータベース管理装置。
7. 請求項１に記載のデータベース管理装置であって、
   前記クエリ実行部は、
   前記新たなタスクを生成する際には、前記リソースの利用状況が所定の閾値未満となる空きリソースを利用するタスクを、分類されたタスクから選択し、生成することを特徴とするデータベース管理装置。
8. 請求項１に記載のデータベース管理装置であって、
   前記クエリ実行部は、
   前記リソースの利用状況としてＩ／Ｏリソースの利用状況を用い、
   前記Ｉ／Ｏリソースの利用状況として、前記ストレージ装置における前記データベースが分割して配置された記憶領域ごとのＩ／Ｏ要求数を取得し、前記Ｉ／Ｏ要求数が最小の記憶領域に分割して配置された前記データベースのデータに対するＩ／Ｏ要求を発行するタスクを生成することを特徴とするデータベース管理装置。
9. 請求項１に記載のデータベース管理装置であって、
   前記クエリ実行部は、
   前記リソースの利用状況としてＩ／Ｏリソースの利用率と、ＣＰＵ利用率を取得し、前記Ｉ／Ｏリソースの利用率が前記ＣＰＵ利用率よりも低い場合には、前記Ｉ／Ｏリソースを利用するタスクを生成し、前記Ｉ／Ｏリソースの利用率が前記ＣＰＵ利用率よりも高い場合には、前記データベース管理装置のプロセッサを利用するタスクを生成することを特徴とするデータベース管理装置。
10. 請求項４記載のデータベース管理装置であって、
    前記クエリ実行プラン生成部は、
    処理ステップごとのＣＰＵコストを予め設定したコスト情報を保持し、
    前記クエリ実行部は、
    当該ＣＰＵ利用率と予め設定した閾値とを比較して、前記ＣＰＵ利用率が前記閾値未満の場合には、前記コスト情報を参照してＣＰＵコストが大きい処理ステップを実行するためのタスクを生成し、前記ＣＰＵ利用率が前記閾値以上の場合には、前記コスト情報を参照してＣＰＵコストが小さい処理ステップを実行するためのタスクを生成することを特徴とするデータベース管理装置。
11. 請求項１に記載のデータベース管理装置であって、
    前記クエリ実行部は、
    前記リソースの利用状況としてＩ／Ｏリソースの利用状況を用い、
    前記Ｉ／Ｏリソースの利用状況として、Ｉ／Ｏパターンを識別し、前記新たなタスクは、前記取得したＩ／Ｏパターンと同一のＩ／Ｏパターンであることを特徴とするデータベース管理装置。
12. 請求項１に記載のデータベース管理装置であって、
    前記データベース管理装置は、ネットワークを介して他の計算機に接続され、
    前記クエリ実行部は、
    前記リソースの利用状況としてＩ／Ｏリソースの利用状況を用い、
    前記Ｉ／Ｏリソースの利用状況として、前記他の計算機と送受信するパケット数である転送パケット数を取得し、
    前記転送パケット数が予め設定された転送パケット数閾値よりも小さい場合に前記新たなタスクを生成することを特徴とするデータベース管理装置。
13. 計算機がストレージ装置に格納されたデータベースを管理するデータベース管理方法であって、
    前記計算機が、前記データベースへのクエリを受け付ける第１のステップと、
    前記計算機が、前記受け付けたクエリを実行するために必要な１以上のデータベースオペレーションを表す情報を含むクエリ実行プランを生成する第２のステップと、
    前記計算機が、前記生成したクエリ実行プランに基づいて前記受け付けたクエリを実行する際に、データベースオペレーションを実行するためのタスクを動的に生成する第３のステップと、
    前記計算機が、前記動的に生成されたタスクを実行する第４のステップと、
    を含み、
    前記第３のステップは、
    受け付けたクエリの実行に利用されるリソースの利用状況を取得し、
    前記生成されたタスクで実行されるデータベースオペレーションの次のデータベースオペレーションを実行する場合には、前記リソースの利用状況に基づいて新たなタスクを生成し、
    前記第４のステップは、
    前記新たなタスクを前記生成されたタスクと並列して実行することを特徴とするデータベース管理方法。
14. 請求項１３に記載のデータベース管理方法であって、
    前記第３のステップは、
    前記リソースの利用状況としてＩ／Ｏリソースの利用状況を用い、
    前記Ｉ／Ｏリソースの利用状況として、前記ストレージ装置からの、若しくは前記ストレージ装置へのデータ転送量と、前記ストレージ装置へのＩ／Ｏ要求数と、を取得するステップと、
    前記データ転送量が予め設定されたデータ転送量閾値よりも小さく、かつ、前記Ｉ／Ｏ要求数が予め設定されたＩ／Ｏ要求数閾値よりも小さい場合に前記新たなタスクを生成するステップと、
    を含むことを特徴とするデータベース管理方法。
15. 計算機でストレージ装置に格納されたデータベースを管理するプログラムを格納した記憶媒体であって、
    前記データベースへのクエリを受け付ける第１のステップと、
    前記受け付けたクエリを実行するために必要な１以上のデータベースオペレーションを表す情報を含むクエリ実行プランを生成する第２のステップと、
    前記生成したクエリ実行プランに基づいて前記受け付けたクエリを実行する際に、データベースオペレーションを実行するためのタスクを動的に生成する第３のステップと、
    前記動的に生成されたタスクを実行する第４のステップと、
    を前記計算機に実行させるプログラムを格納した非一時的な計算機読み取り可能な記憶媒体であって、
    前記第３のステップは、
    受け付けたクエリの実行に利用されるリソースの利用状況を取得して、前記生成されたタスクで実行されるデータベースオペレーションの次のデータベースオペレーションを実行する場合には、リソースの利用状況に基づいて新たなタスクを生成し、
    前記第４のステップは、
    前記新たなタスクを前記生成されたタスクと並列して実行することを特徴とする記憶媒体。

Images