データベース管理システム及び方法
【課題】 一つのクエリの実行に要する時間を短縮化する。
【解決手段】 クエリを受け付けるクエリ受付部７と、受け付けたクエリを実行するクエリ実行部９とが備えられる。クエリ実行部９は、動的にタスクを生成していき、生成された複数のタスクを並行して実行する。クエリ実行部９は、各タスクの実行において、データベースのデータを必要とする都度に、そのデータを取得するためのタスクを生成し、該生成されたタスクの実行において、必要に応じて、データベースからデータを読み出すためのデータ読出し要求を発行する。
【解決手段】 クエリを受け付けるクエリ受付部７と、受け付けたクエリを実行するクエリ実行部９とが備えられる。クエリ実行部９は、動的にタスクを生成していき、生成された複数のタスクを並行して実行する。クエリ実行部９は、各タスクの実行において、データベースのデータを必要とする都度に、そのデータを取得するためのタスクを生成し、該生成されたタスクの実行において、必要に応じて、データベースからデータを読み出すためのデータ読出し要求を発行する。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベース管理技術に関わる。
【背景技術】
【０００２】
例えば、特開２００４−１９２２９２号公報には、バーチャリゼーション環境上にＤＢ（データベース）を構築したシステムにおける管理サーバが開示されている。その管理サーバは、ＤＢＭＳ（データベース管理システム）からＤＢ処理の実行計画や処理優先度等のＤＢ処理情報を取得し、その情報を基にこれからアクセスが行われるデータとそのアクセス順を予測し、予測結果に基づいて近い将来アクセスが行われるデータを記憶装置のキャッシュ上に読み出すよう指示し、最も近い将来にアクセスが行われるデータを自サーバのキャッシュメモリに読み出す。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００４−１９２２９２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、通常、ＤＢＭＳは、クエリを受け付け、クエリを受け付けた場合には、そのクエリを実行してその実行結果を出力するようになっている。クエリの実行結果を出力するまでには、複数段階のデータベースオペレーションが実行される場合がある。それら複数段階のデータベースオペレーションは、一般に、所定の順序で実行されるようになっており、それら複数段階のデータベースオペレーションのうちの少なくとも一つのデータベースオペレーションでは、記憶装置に対して読出し要求を発行する必要のある場合がある。以下、図１Ａ〜図１Ｃを参照して一つの具体例を説明する。
【０００５】
例えば、ＤＢＭＳが、ＤＢＭＳの上位にあるコンピュータプログラム（例えばアプリケーションプログラム）からクエリを受け付けた場合に、そのクエリの実行プラン（以下、単に「クエリプラン」と言う）として、図１Ａに記載のクエリプランを生成したとする。そして、図１Ｂに記載のパート表２３Ａ、ラインアイテム表２３Ｂ、オーダ表２３Ｃ及び各種インデックス２５が、記憶装置（例えば、ＤＢＭＳを備えた情報処理端末に通信可能に接続された外部記憶装置）に格納されているとする。
【０００６】
図１Ａに例示したクエリプランによれば、パート表２３Ａから未読の行がなくなるまで、データベースオペレーション（以下、「ＯＰ」と略記）１〜５が繰り返される。ＯＰ１は、初期データベースオペレーションであり、パート表２３Ａ（図１Ｂ参照）から１行読む処理である。ＯＰ２は、読まれた行中のＰＩＤに対応するラインアイテム表２３Ｂ（図１Ｂ参照）のポインタ（rowid）をラインアイテムインデックス２５Ａで検索する処理である。ＯＰ３は、得られたポインタでラインアイテム表２３Ｂをフェッチし、ＯＩＤでフィルタをかける処理（例えば、ＯＩＤが５０４未満のもののみを出力する処理）である。ＯＰ４は、出力されたＯＩＤに対応するオーダ表２３Ｃ（図１Ｂ参照）のポインタ（rowid）をオーダインデックス２５Ｂで検索する処理である。ＯＰ５は、得られたポインタでオーダ表２３Ｃをフェッチし、結果としてリターンする処理である。以上のようなＯＰ１〜ＯＰ５が繰り返されることにより、図１Ｃに例示するようなクエリ実行結果を、クエリの発行元のコンピュータプログラムに返すことができる。
【０００７】
上記のようにして一つのクエリを実行する場合には、複数のＯＰが繰り返し実行され、且つ、各回の実行において、一つのＯＰが終了してから次のＯＰが開始される。このため、例えば、或るＯＰ（例えばＯＰ３）において、読出し要求が発行された場合には、その読出し要求に応答してデータが読み出されるまで処理が中断してしまう。故に、一つのクエリの実行に要する時間が長くなってしまう。
【０００８】
また、上記のようにして一つのクエリを実行する場合には、記憶装置をランダムアクセスすることがある。具体的には、ラインアイテム表２３Ｂ、オーダ表２３Ｃ及びインデックスの読み込みがランダムになってしまうことがある。より具体的には、例えば、ラインアイテム表２３Ｂの一行目にアクセスした後、６行目及び９行目もパート表２３Ａの行に対応した行であるにも関わらず、一旦１２行目にアクセスした後に、６行目へのアクセスが行われてしまう。一つのクエリの実行の際、ＤＢＭＳから読出し要求が複数回発行されることになるが、上記のようなランダムアクセスが行われると、全体としてのデータ読出し待ち時間が長くなってしまう。
【０００９】
従って、本発明の一つの目的は、一つのクエリの実行に要する時間を短縮化することにある。具体的には、例えば、一つのクエリの実行における全体としてのデータ読出し待ち時間を短縮化することにある。
【００１０】
本発明の他の目的は、後述の説明から明らかになるであろう。
【課題を解決するための手段】
【００１１】
本発明の一つの観点に従うデータベース管理システムは、クエリを受け付けるクエリ受付部と、前記受け付けたクエリを実行し、その際、必要に応じて、記憶装置（例えば主記憶装置）からデータベースのデータを読み出すためのデータ読出し要求を発行するクエリ実行部とを備える。前記クエリ実行部は、動的にタスクを生成していき、生成された複数のタスクを並行して実行する。前記クエリ実行部は、各タスクの実行において、前記データベースのデータを必要とする都度に、そのデータを取得するためのタスクを生成する。また、前記クエリ実行部は、該生成されたタスクの実行において、必要に応じて、前記データベースからデータを読み出すための前記データ読出し要求を発行する。
【００１２】
このデータベース管理システムの具体例としては、以下の通りである。すなわち、データベース管理システムは、上位のコンピュータプログラム（例えば、アプリケーションプログラム）からクエリ（例えばＳＱＬ）を受け付けるクエリ受付部と、該受け付けたクエリを実行するプランであるクエリプランを生成するクエリプラン生成部と、該生成されたクエリプランに従いクエリを実行するクエリ実行部とを備えることができる。クエリプランは、例えば、データ読出しを伴う一つ以上のデータベースオペレーションで構成され、該データベースオペレーション間の実行順序には木構造の順序関係が存在する。クエリ実行部は、他のデータベースオペレーションに依存しない初期データベースオペレーションを抽出してタスクを割り当てるステップと、該割り当てられたタスクを実行するステップとで構成することができる。
【００１３】
該データベースオペレーションに対応したタスクを実行するステップでは、以下の（Ａ）〜（Ｄ）のステップ、
（Ａ）データ読出し処理に対して複数の独立したタスクを生成するステップ、
（Ｂ）該生成された複数のタスクのデータ読出し処理において、外部記憶装置からのデータ読出しが必要な場合、オペレーティングシステムにデータ読出し要求を発行するステップ、
（Ｃ）該データ読出しが完了したタスクから当該データベースオペレーションの実行を再開するステップ、
（Ｄ）該データベースオペレーションに依存した次のデータベースオペレーションがある場合、該次のデータベースオペレーションを実行するステップ、
を実行することができる。
【００１４】
第一の態様では、前記クエリ実行部は、所定の状況にあるタスクの現存数が所定数に達している場合には、新たなタスクの生成を待ち、前記現存数が減った場合に、前記新たなタスクを生成することができる。所定の状況とは、例えば、単に現存している状況であっても良いし、データ取得待ちの状況であっても良い。
【００１５】
第二の態様では、データベース管理システムは、読出し順序制御部を更に備えることができる。読出し順序制御部は、前記クエリ実行部から発行された複数個のデータ読出し要求を受け、受け付けた複数個のデータ読出し要求を、前記複数個のデータ読出し要求を受け付けた順序とは異なる、全体としてのデータ読出し時間長（すなわち、複数個のデータ読出し要求に応じてデータが読み出されるまでの時間長）を短縮化するための順序で発行することができる。
【００１６】
具体的には、例えば、データベース管理システムは、前記クエリ実行部からのデータ読出し要求を受け付け、そのデータ読出し要求をオペレーティングシステムに発行する読出し最適化部を備えることができる。読出し最適化部は、受け付けたデータ読出し要求をキューイングし、データ読出し要求を発行するタイミングを制御するための条件（例えば、後述する第二実施例のバッチスケジューリング駆動条件）が満たされた場合に、キューイングされた複数のデータ読出し要求の出力順序を変更することで、データ読出し時間を最適化することができる。
【００１７】
第三の態様では、データベース管理システムは、優先順位の異なる複数のキューを更に備えることができる。前記クエリ実行部は、前記生成されたタスクの実行により、前記複数のキューのうち、所定の条件に適合する優先度に対応したキューに、前記データ読出し要求を格納することができる。前記読出し順序制御部は、優先度の高いキューに格納されているデータ読出し要求ほど優先的に発行することができる。
【００１８】
具体的には、例えば、読出し最適化部は、スケジュール対象外を含む複数の読出し要求キューを有し、読出し要求キュー毎に設定された処理手順に従い、データ読出し要求を発行することができる。この場合において、タスクを実行することによってデータ読出し要求を読出し最適化部へ発行する際に、以下の（ａ）〜（ｃ）の処理、
（ａ）読出し要求に対するスケジューリングフラグを付与する処理、
（ｂ）該スケジューリングフラグの値に応じて複数の読出し要求キューの中から一つの読出し要求キューを選択する処理、
（ｃ）選択した読出し要求キューへ読出し要求を格納する処理、
を実行することができる。読出し最適化部では、データ読出し要求をキューに保管し続ける時間長を変更することができる。
【００１９】
第四の態様では、上述の第三の実施態様において、前記読出し順序制御部は、所定のコマンドを受け付けた場合には、或る優先度のキューに格納されている少なくとも一つの読出し要求を別の優先度のキューに移動させることができる。
【００２０】
具体的には、例えば、データベース管理システムは、スケジュール対象の読出し要求キューにキューイングされたデータ読出要求に対してスケジュールキャンセルコマンドを発行することにより、該データ読出し要求をスケジュール対象外の読出し要求キューに移すことができる。
【００２１】
第五の態様では、上述の第三の態様において、前記クエリ実行部は、前記受け付けたクエリの実行プランの内容、又は、前記受け付けたクエリの実行に求められる性能要件に応じて、どの優先度のキューに読出し要求を格納するかを決定することができる。
【００２２】
第六の態様では、上述の第三の態様において、データベース管理システムは、タスク管理部を備えることができる。タスク管理部は、クエリ実行プランに基づいて、残存ステップ数を計算し、計算された残存ステップ数の少ないタスクの優先度を上げることができる。この場合において、前記クエリ実行部が、優先度の上がったタスクを実行することにより発行される読出し要求を、該優先度に対応するキューに格納することができる。ここで、残存ステップとは、例えば、残存するデータオペレーションの数とすることができる。
【００２３】
第七の態様では、前記クエリ実行部は、生成された各タスクの実行において、前記データベースのデータの取得を待ち、該データを取得した後、データの取得待ちを開始した順序と同じ順序で、タスクの実行を再開することができる。これは、上記第二の態様においても行うことができる。
【００２４】
本発明の別の観点に従うコンピュータシステムは、上述したデータベース管理システムと、読出し順序制御部とを備える。読出し順序制御部は、データベース管理システムから発行された複数個のデータ読出し要求を受け付け、受け付けた複数個のデータ読出し要求を、前記複数個のデータ読出し要求を受け付けた順序とは異なる、全体としてのデータ読出し時間長を短縮化するための順序で発行する。
【発明の効果】
【００２５】
本発明に従うデータベース管理システムによれば、一つのクエリの実行に要する時間長を短縮化することができる。
【図面の簡単な説明】
【００２６】
【図１】図１Ａは、クエリプランの一例を示す。図１Ｂは、パート表、ラインアイテム表及びオーダ表の構成例と表同士の関連とを示す。図１Ｃは、クエリの実行結果として出力される情報の例を示す。
【図２】図２は、本発明の第一実施例に係るシステムの構成例を示す。
【図３】図３は、クエリ実行部９が行う処理の流れの一例を示す。
【図４】図４Ａは、図３のＳ２のタスク生成待ち処理において行われる処理の流れの一例を示す。図４Ｂは、図３のＳ１１のデータ取得処理において行われる処理の流れの一例を示す。
【図５】図５Ａは、従来のクエリ実行の流れの一例を示す。図５Ｂは、本発明の第一実施例におけるクエリ実行の流れの一例を示す。
【図６】図６は、本発明の第二実施例に係るシステムの構成例を示す。
【図７】図７Ａは、本発明の第二実施例で行われるデータ取得処理の流れの一例を示す。図７Ｂは、Ｉ／Ｏ要求発行処理の流れの一例を示す。
【図８】図８は、Ｉ／Ｏ最適化部２７の説明図である。
【図９】図９Ａは、Ｉ／Ｏ最適化部２７が行う処理の流れの一例を示す。図９Ｂは、即時発行処理の流れの一例を示す。
【図１０】図１０Ａは、スケジュールキャンセル処理の流れの一例を示す。図１０Ｂは、バッチスケジュール処理の流れの一例を示す。
【図１１】図１１Ａ及び図１１Ｂは、本発明の第一実施例のＤＢＭＳ５によって期待される効果の一例の説明図である。具体的には、図１１Ａは、第一実施例におけるＩ／Ｏ要求の発行とデータの読み出しの流れの一例を示す。図１１Ｂは、図１１Ａに示した流れにおけるディスクシークイメージの一例を示す。
【図１２】図１２Ａ及び図１２Ｂは、本発明の第二実施例のＤＢＭＳ５によって期待される効果の一例であって、即時発行処理が行われない場合の説明図である。
【図１３】図１３Ａ及び図１３Ｂは、本発明の第二実施例のＤＢＭＳ５によって期待される効果の一例であって、即時発行処理が行われる場合の説明図である。
【図１４】図１４Ａは、本発明の第三実施例におけるデータ取得待ち表の構成例を示す。図１４Ｂは、生成された子タスクが第一実施例で行う処理との第一の相違部分を示す。図１４Ｃは、生成された子タスクが第一実施例で行う処理との第二の相違部分を示す。
【図１５】図１５Ａは、データ取得処理の開始順序、データの取得順序、及びタスクの再開順序の関係の一例を示す。図１５Ｂは、図１５Ａにおけるディスクシークイメージの一例を示す。
【発明を実施するための形態】
【００２７】
以下、図面を参照して、本発明についての幾つかの実施例を説明する。
【実施例１】
【００２８】
図２は、本発明の第一実施例に係るシステムの構成例を示す。
【００２９】
データベースサーバ１と、データベースサーバ１の外に存在する記憶装置である外部記憶装置１９とが、通信ネットワーク１７を介して通信可能に接続されている。
【００３０】
外部記憶装置１９は、記憶資源を有する装置であればどのような装置であっても良い。例えば、外部記憶装置１９は、ファイルサーバであっても良いし、単体のディスクドライブ（例えばハードディスクドライブ）であっても良いし、複数のディスクドライブを備えた記憶装置システムであっても良い。外部記憶装置１９は、データベース２１を有し、データベース２１内に、複数の電子的な索引２５、２５、…と、複数の電子的な表２３、２３、…とを記憶することができる。各索引２５は、例えば、或る表における各行と別の表における各行との繋がりを表すポインタを複数個備えるデータ（例えば、図１Ｂにおけるインデックス２５Ａ、２５Ｂ）であり、B-木インデクスなどが用いられる。各表２３は、複数の行要素から成る行を複数個有するデータ（例えば、図１Ｂにおけるパート表２３Ａ、ラインアイテム表２３Ｂ又はオーダ表２３Ｃ）である。
【００３１】
データベースサーバ１は、例えば、格別図示しないが、複数のコンピュータプログラムを記憶することができる記憶資源（例えばメモリやハードディスク）や、記憶資源からコンピュータプログラムを読み込んで実行することができるプロセッサ（例えばＣＰＵ）等を有するコンピュータマシンである。記憶資源に記憶されているコンピュータプログラムとして、例えば、クエリ（例えばＳＱＬ（Structured Query Language））を発行するアプリケーションプログラム（以下、ＡＰ）３と、ＡＰ３からクエリを受けて実行し実行結果をＡＰ３に返すデータベース管理システム（以下、ＤＢＭＳ）５と、ウィンドウズ（登録商標）等のオペレーティングシステム（以下、ＯＳ）１５とがある。ＯＳ１５の上位にＤＢＭＳ５があり、ＤＢＭＳ５の上位にＡＰ３が存在する。なお、ＡＰはＤＢＭＳと異なるコンピュータに存在していても良い。その場合には、ＡＰからの問合せ要求はネットワーク経由で受け付ける。また、記憶資源の一部を利用して、例えば、ＤＢＭＳ５で利用されるデータベースバッファ（以下、ＤＢバッファ）１２を構築することができる。
【００３２】
ＤＢＭＳ５は、例えば、ＡＰ３からクエリを受け付けるクエリ受付部７と、クエリ受付部７が受け付けたクエリに基づいて例えば図１Ａに例示したようなクエリプランを生成するクエリプラン生成部１１と、生成されたクエリプランに従がってクエリを実行するクエリ実行部９と、クエリの実行のためのタスクを管理する（例えばタスクに対してＣＰＵやメモリ等のリソースを割り当てる）実行タスク管理部１３とを有する。クエリプランは、複数のデータベースオペレーション（ＯＰ）の実行順序を定義したものである。
【００３３】
この第一実施例では、特にクエリ実行部９が行う処理に特徴がある。クエリ実行部９は、少なくとも一つのＯＰを割り当てたタスクを実行することにより、当該少なくとも一つのＯＰを実行することができる。そして、クエリ実行部９は、そのタスクの実行中において、外部記憶装置１９からのデータの読出しが必要になれば、そのデータを読み出して次のＯＰを実行するタスクを生成し、生成されたタスクを実行することにより、データの入出力要求（以下、「Ｉ／Ｏ要求」と記載）を発行することができる。タスクを複数個生成した場合には、複数個のタスクを並行して実行することができ、故に、複数個のＩ／Ｏ要求を並行して発行することができる。なお、タスクの実装としては、ＯＳが管理するプロセスやスレッド、または、アプリケーションやミドルウェアが実装する擬似プロセスや擬似スレッドなど任意の実行環境が利用できる。
【００３４】
以下、クエリ実行部９が行う処理について説明する。なお、以下、説明を分かり易くするために、一つのタスクを実行することにより一つのＯＰが実行されるものとする。しかし、勿論それに限定する必要は無く、例えば、一つのタスクを実行することにより、複数のＯＰが実行されても良い。具体的には、例えば、一つのタスクが、或るＯＰを実行し、その実行結果を引き継いで、次のＯＰを実行しても良い。
【００３５】
図３は、クエリ実行部９が行う処理の流れの一例を示す。
【００３６】
クエリ実行部９は、或る段階のデータベースオペレーション（ＯＰ）を割り当てたタスク（以下、便宜上「親タスク」と言う）を実行することにより、そのＯＰを実行することができる。
【００３７】
実行された親タスクは、そのＯＰの実行において、残りのデータ（例えば、索引２５又は表２３から未だ読み出されていないデータ）があれば（ステップＳ１で「データあり」）、タスク生成待ち処理を実行する（Ｓ２）。タスク生成待ち処理により、タスクを生成することができるようになったら、親タスクは、残りのデータを読み出して次のＯＰを実行することを割り当てたタスク（以下、便宜上「子タスク」と言う）３１を生成する（Ｓ３）。親タスクの実行中においては（Ｓ４で「親タスク」）、再びＳ１が実行される。また、Ｓ１で「データなし」の場合には、当該親タスクは消滅することができる。
【００３８】
クエリ実行部９は、並行して、生成された子タスク３１を実行することができる。Ｓ１からＳ４の「親タスク」の処理が繰り返されることにより、同一の次のＯＰを実行する子タスクが複数個生成された場合には、生成された複数個の子タスク３１、３１、…を並行して実行することができる。
【００３９】
実行された子タスク３１は、Ｓ１における残りのデータを取得するデータ取得処理を実行し（Ｓ１１）、データを取得できれば（Ｓ１１で「データあり」）、その取得されたデータが選択条件にマッチするか否かを判断するＳ１２の処理を行う（なお、このＳ１２は、ＯＰの種類によっては行われない）。マッチすれば（Ｓ１２で「あり」）、子タスク３１は、自分に割り当てられたＯＰの次のＯＰがあれば（Ｓ１３で「あり」）、次のＯＰを実行し（Ｓ１４）、なければ（Ｓ１３で「なし」）、結果をリターンする（Ｓ１５）。次のＯＰがあるか否かは、例えば、クエリプラン生成部１１によって生成された図１Ａに例示したクエリプランを参照することにより判別することができる。また、Ｓ１４の次のＯＰの実行では、当該子タスクは、親タスクとして、上述したＳ１の処理を実行し、Ｓ３で子タスクを生成することができる。
【００４０】
図４Ａは、図３のＳ２のタスク生成待ち処理において行われる処理の流れの一例を示す。
【００４１】
親タスクは、自分より高い優先度のタスクが生成待ちか否かを判定する（Ｓ２−１）。具体的には、例えば、親タスクは、クエリプランを参照し、他の親タスクの実行において生成待ちとなっている子タスクが、自分よりも後段のＯＰを実行するタスクか否かを判定する。
【００４２】
Ｓ２−１の判定の結果、待ちであれば（Ｓ２−１で「あり」）、親タスクは、タスクの生成が行われる契機となるイベントの発生を待つ（Ｓ２−２）。
【００４３】
一方、Ｓ２−１の判定の結果、待ちでなければ（Ｓ２−１で「なし」）、親タスクは、現存するデータ取得待ちタスク数が所定の閾値未満か否かを判定する（Ｓ２−３）。現存するデータ取得待ちタスク数は、例えば、クエリ実行部９が、タスクを生成する都度に所定のカウント値を１増やし、データ取得が完了する都度にそのカウント値を１減らすことで、そのカウント値を参照することにより、判別することができる。また、閾値は、データベースサーバ１の記憶資源に記憶される値である。閾値は、例えば、一種のチューニングパラメータであり、ＤＢＭＳ５の管理者が所望の値とすることができる。また、閾値は、ＤＢＭＳシステム全体で決めることも可能であるし、問合せやユーザなど任意の単位で設定することが可能である。
【００４４】
Ｓ２−３の判定の結果、残存タスク数が所定の閾値未満であれば（Ｓ２−３で「はい」）、親タスクは、図３のＳ２のタスク生成待ち処理を終えて次のＳ３を実行することができ、そうでなければ（Ｓ２−３で「いいえ」）、少なくとも一つのタスクが消滅する契機となるイベントの発生を待つ（Ｓ２−４）。ここでのイベントとしては、例えば、図３のＳ１において「データなし」となることが挙げられる。
【００４５】
図４Ｂは、図３のＳ１１のデータ取得処理において行われる処理の流れの一例を示す。
【００４６】
子タスクは、ＤＢバッファ１２にアクセスし、過去に読み出されたデータが残っている等の理由により、ＤＢバッファ１２に、自分の読出し対象のデータが存在していれば（Ｓ１１−１で「ヒット」）、そのデータをＤＢバッファ１２から取得して（Ｓ１１−５）、このデータ取得処理を終える。
【００４７】
子タスクは、ＤＢバッファ１２に、自分の読出し対象のデータが存在していない場合（Ｓ１１−１で「フォルト」）、そのデータが存在する領域に対してＩ／Ｏ要求が未だ発行されていなければ（Ｓ１１−２で「未」）、ＯＳシステムコールによるＩ／Ｏ発行を行う（Ｓ１１−３）。すなわち、子タスクは、ＯＳ１５にＩ／Ｏ要求を出すことで、ＯＳ１５から外部記憶装置１９に対するＩ／Ｏ要求を発行させる。子タスクの実行は、それに応答して、外部記憶装置１９からＯＳ１５を介してデータが読み出されるまで待ちとなる。データが読み出されたならば（Ｓ１１−５）、子タスクは、処理を再開し、読み出されたデータをＤＢバッファ１２に格納して、このデータ取得処理を終える。
【００４８】
子タスクは、Ｓ１１−１で「フォルト」の場合、自分の読出し対象のデータが存在する領域に対してＩ／Ｏ要求が既に発行されていれば（Ｓ１１−２で「既」）、Ｉ／Ｏ要求の完了を待つ（Ｓ１１−４）。データが読み出されたならば（Ｓ１１−５）、子タスクは、処理を再開し、読み出されたデータをＤＢバッファ１２に格納して、このデータ取得処理を終える。なお、自分の読出し対象のデータが存在する領域に対してＩ／Ｏ要求が既に発行されているか否かは、例えば、各タスクが、Ｉ／Ｏ要求をＯＳ１５に発行する都度に、そのＩ／Ｏ要求によるアクセス先に関するＩ／Ｏ先情報を、データベースサーバ１の記憶資源上の所定記憶領域に書き、子タスクは、その所定記憶領域上の各Ｉ／Ｏ先情報を参照することにより、判定することができる。Ｉ／Ｏ先情報としては、例えば、外部記憶装置１９に設けられた論理ユニットの識別子（例えば論理ユニット番号）と、アクセス先の論理ブロックアドレス（以下、ＬＢＡ）とを含んだ情報とすることができる。データベースサーバ１の記憶資源は、例えば、ＤＢオブジェクト（例えば、表２３、索引２５、又は表２３や索引２５上の各行要素（例えばＰＩＤ、ＯＩＤ等））と記憶位置（例えば、論理ユニット識別子及び／又はＬＢＡ）との対応関係を表すマッピング情報を記憶することができ、各タスクは、そのマッピング情報に基づいて、ＯＳ１５に対してＩ／Ｏ要求を発行したり、上記Ｉ／Ｏ先情報を所定記憶領域に書き込んだりすることができる。
【００４９】
上述した第一実施例によれば、クエリ実行部９は、タスクの実行中において、外部記憶装置１９からのデータの読出しが必要になれば、そのデータを読み出して次のＯＰを実行するタスクを生成し、生成されたタスクを実行することにより、Ｉ／Ｏ要求を発行することができる。タスクを複数個生成した場合には、複数個のタスクを並行して実行することができ、故に、複数個のＩ／Ｏ要求を並行して発行することができる。このことを、図１Ａに例示したクエリプランに従がってクエリを実行する場合を例に採って説明すると、従来の技術によれば、図５Ａに示すように、パート表２３Ａから未読の行がなくなるまで、ＯＰ１からＯＰ５までを終えて再びＯＰ１から開始することを繰り返す必要があるが、上述した第一実施例によれば、図５Ｂに示すように、同一段階のＯＰを並行して実行することができる。具体的には、例えば、パート表２３Ａの行数は３なので、ＯＰ１が割り当てられたタスクが実行されることにより、複数の子タスクが生成され、それら複数の子タスクが並行して実行されることにより、パート表２３Ａの３行にそれぞれ対応した３つのＯＰ２を並行して実行することができる。各ＯＰ２の実行後、ＯＰ３も並行して実行され、その実行結果に応じて、タスクが消滅してＯＰ４以降が実行されなかったり（例えば、フェッチされたＯＩＤが５０４未満であったため図３のＳ１２の選択条件にマッチしないが故に終了となってタスクが消滅したり）、一つのＯＰ３の実行後に更に複数のＯＰ４が並行して実行されたりする（例えば、ＰＩＤ「３０１」に対応する行が２つ見つかったために２つの行にそれぞれ対応した２つのＯＰ４が並行して実行されたりする）。Ｉ／Ｏ要求を発行する処理が必要となるＯＰが並行して実行されるため、複数のＩ／Ｏ要求が並行して発行される。これにより、例えば、生成されたタスク毎に読出し要求が発行され、その読出し要求に応答してデータが読み出されるまで該タスクの処理が中断しても、他の生成されたタスクは独立して実行されるので、クエリの実行それ自体が中断してしまうわけではない。以上の結果、従来に比べて、一つのクエリの実行に要する時間を短縮することができる。
【００５０】
また、上述した第一実施例によれば、タスクが無制限に生成されるわけではなく、現存するデータ取得待ちタスク数が所定値になったら、新たにタスクは生成されず、現存のデータ取得待ちタスク数が所定値未満になった場合に、新たなタスクの生成が行われる。これにより、ＤＢＭＳ５での処理によって消費されるコンピュータリソース（例えば、ＣＰＵ使用率、メモリ使用量等）の量を抑えることができる。
【実施例２】
【００５１】
以下、本発明の第二実施例を説明する。なお、その際、第一実施例との相違点を主に説明し、第一実施例との共通点については、重複した説明を省くために、説明を簡略或いは省略する。
【００５２】
図６は、本発明の第二実施例に係るシステムの構成例を示す。この図において、第一実施例と同一の要素については同一の番号を付してある。
【００５３】
この第二実施例では、ＤＢＭＳ５に、Ｉ／Ｏ最適化部２７が備えられる。この場合、クエリ実行部９は、ＯＳ１５にではなく、Ｉ／Ｏ最適化部２７にＩ／Ｏ要求を発行する。Ｉ／Ｏ最適化部２７は、クエリ実行部９から並行して発行された複数のＩ／Ｏ要求を受けて保持し、受け付けた複数のＩ／Ｏ要求の順序を、データ読出し時間長を最適化するための順序に変更し、変更後の順序で複数のＩ／Ｏ要求をＯＳ１５に発行することができる。
【００５４】
以下、この第二実施例について詳細に説明する。
【００５５】
図７Ａは、本発明の第二実施例で行われるデータ取得処理の流れの一例を示す。
【００５６】
この図７Ａにおいて、Ｓ３１、Ｓ３２、Ｓ３５及びＳ３６は、図４ＡのＳ１１−１、Ｓ１１−２、Ｓ１１−４及びＳ１１−５にそれぞれ対応している。相違点は、Ｓ３３及びＳ３４である。
【００５７】
Ｓ３３では、クエリ実行部９によって実行されている子タスクは、発行するＩ／Ｏ要求をスケジュール対象とするか否かを判断し、スケジュール対象とする場合に、スケジュールフラグを付与することを決定する。スケジュール対象とする場合とは、例えば、Ｉ／Ｏ要求をＯＳ１５に発行する緊急性が低い場合であり、そうではなく、その緊急性が高い場合には、スケジュール対象外となる。スケジュール対象とするか否かは、例えば、クエリプランの内容、又は、クエリの実行に求められる性能要件に応じて、決定することができる。前者の具体例では、当該子タスクが、クエリプランを参照し、当該子タスクに割り当てられているＯＰが或る段階よりも後段のＯＰであると認識された場合に、スケジュール対象外とし、そうではない場合には、スケジュール対象としても良い。後者の具体例では、当該子タスクは、意思決定支援システムなどの緊急性の低いアクセス特性を有するデータベースアクセスのためのＩ／Ｏ要求を発行する場合には、スケジュール対象とし、オンライントランザクションシステムなどの緊急性の高いアクセス特定を有するデータベースアクセスのためのＩ／Ｏ要求を発行する場合には、スケジュール対象外としてもよい。
【００５８】
Ｓ３３の後、当該子タスクは、Ｉ／Ｏ要求発行処理を実行する（Ｓ３４）。
【００５９】
図７Ｂは、Ｉ／Ｏ要求発行処理の流れの一例を示す。
【００６０】
子タスクは、スケジュールフラグを付与する場合（Ｓ３４−１で「有」）、スケジュール対象キューに、Ｉ／Ｏ要求を挿入し（Ｓ３４−２）、スケジュールフラグを付与しない場合（Ｓ３４−１で「無」）、スケジュール対象外キューに、Ｉ／Ｏ要求を挿入する。
【００６１】
ここで、スケジュール対象キュー及びスケジュール対象外キューとは、Ｉ／Ｏ最適化部２７が有するキューである。
【００６２】
図８は、Ｉ／Ｏ最適化部２７の説明図である。
【００６３】
Ｉ／Ｏ最適化部２７は、スケジュール対象外キュー６１Ａと、スケジュール対象キュー６１Ｂとを有する。スケジュール対象外キュー６１Ａの優先度（換言すれば、Ｉ／Ｏ要求の発行の緊急度）は、スケジュール対象キュー６１Ｂの優先度よりも高い。スケジュール対象外キュー６１Ａには、スケジュール対象外とされたＩ／Ｏ要求６３がクエリ実行部９によって格納され、スケジュール対象キュー６１Ｂには、スケジュール対象とされたＩ／Ｏ要求６３がクエリ実行部９によって格納される。
【００６４】
以下、図９Ａ、図９Ｂ、図１０Ａ及び図１０Ｂを参照して、Ｉ／Ｏ最適化部２７が行う処理の流れについて説明する。その際、適宜に、図８も参照する。
【００６５】
図９Ａは、Ｉ／Ｏ最適化部２７が行う処理の流れの一例を示す。
【００６６】
Ｉ／Ｏ最適化部２７は、条件１〜条件３のうちの少なくとも一つの条件にマッチするイベントが発生するのを待つ（Ｓ４１）。ここで、条件１とは、スケジュール対象外キュー６１ＡにＩ／Ｏ要求が格納されることである。条件２とは、スケジュールキャンセルコマンドの到着である。条件３とは、後述するバッチスケジューリング駆動条件の成立である。
【００６７】
上記の条件１〜条件３のうちの少なくとも一つの条件にマッチするイベントが発生した場合には、Ｉ／Ｏ最適化部２７は、発生したイベントがマッチする条件を判別し（Ｓ４２）、判別された条件に応じた処理を実行する。すなわち、Ｉ／Ｏ最適化部２７は、条件１であると判別された場合には、即時発行処理を実行し（Ｓ４３）、条件２であると判別された場合には、スケジュールキャンセル処理を実行し（Ｓ４４）、条件３であると判別された場合には、バッチスケジュール処理を実行する（Ｓ４５）。なお、複数の条件にマッチした場合には、例えば、Ｉ／Ｏ最適化部２７は、優先順位の高い条件に対応した処理を優先して実行することができる。例えば、条件１の方が条件３よりも優先順位が高い場合において、条件１及び条件３の両方にマッチしたイベントが発生した場合には、Ｉ／Ｏ最適化部２７は、条件１に対応した即時発行処理を、条件３に対応するバッチスケジュール処理よりも先に実行することができる。
【００６８】
図９Ｂは、即時発行処理の流れの一例を示す。
【００６９】
Ｉ／Ｏ最適化部２７は、スケジュール対象外キュー６１Ａから全てのＩ／Ｏ要求を取り出し（Ｓ４３−１）、取り出したＩ／Ｏ要求を、ＯＳ１５のシステムコールを用いて発行する（Ｓ４３−２）。これにより、外部記憶装置１９へとＩ／Ｏ要求が発行される。この即時発行処理は、スケジュール対象外キュー６１ＡにＩ／Ｏ要求が格納されていることがＩ／Ｏ最適化部２７によって検出される度に行われるので、後述のバッチスケジュール処理よりも、キューにおけるＩ／Ｏ要求の滞在時間が短い。
【００７０】
図１０Ａは、スケジュールキャンセル処理の流れの一例を示す。
【００７１】
Ｉ／Ｏ最適化部２７は、図８で点線で示すように、スケジュールキャンセルコマンドで指定されているＩ／Ｏ要求６３Ｔをスケジュール対象キュー６１Ｂから取得し（Ｓ４４−１）、取得されたＩ／Ｏ要求６３Ｔをスケジュール対象外キュー６１Ａに挿入する（Ｓ４４−２）。挿入する位置は、どこでも良い。例えば、スケジュール対象外キュー６１Ａに存在する一以上のＩ／Ｏ要求の最後尾であっても良いし、先頭であっても良いし、それらの間の任意の位置であっても良い。
【００７２】
図１０Ｂは、バッチスケジュール処理の流れの一例を示す。
【００７３】
このバッチスケジュール処理は、前述したように、バッチスケジューリング駆動条件が成立した場合に開始される。バッチスケジューリング駆動条件としては、例えば、直前回にバッチスケジュール処理が行われてから所定時間経過した、又は、スケジュール対象キュー６１Ｂの使用率が所定値以上になったという条件を採用することができる。
【００７４】
Ｉ／Ｏ最適化部２７は、スケジュール対象キュー６１Ｂに格納されている複数のＩ／Ｏ要求の順序を、それら複数のＩ／Ｏ要求のトータルのデータ読出し時間長を最適化するための順序に並び替える（Ｓ４５−１）。この並び替えは、例えば、前述したマッピング情報に基づいて行うことができる。具体的には、例えば、Ｉ／Ｏ最適化部２７は、各Ｉ／Ｏ要求毎のアクセス先ＬＢＡを特定し、外部記憶装置１９におけるディスクシーク時間長が最も短くなるような順序に並び替えることができる。なお、並び替えの対象は、例えば、バッチスケジュール処理が開始された時点でスケジュール対象キュー６１Ｂに存在するＩ／Ｏ要求とすることができる。この場合、バッチスケジュール処理を開始した後にスケジュール対象キュー６１ＢにＩ／Ｏ要求が入っても、そのＩ／Ｏ要求は、今回のバッチスケジュール処理では並び替えの対象とされず、次回以降のバッチスケジュール処理で、並び替えの対象とされることになる。
【００７５】
Ｉ／Ｏ最適化部２７は、スケジュール対象外キュー６１Ａが空か否かを判別し（Ｓ４５−２）、空あれば（Ｓ４５−２でＹＥＳ）、スケジュール対象キュー６１ＢにＩ／Ｏ要求があるか否かを判断し（Ｓ４５−３）、あれば（Ｓ４５−３で「あり」）、スケジュール対象キュー６１ＢからＩ／Ｏ要求を取り出し、取り出したＩ／Ｏ要求をＯＳ１５に発行する。Ｉ／Ｏ最適化部２７は、Ｓ４５−２において、スケジュール対象外キュー６１Ａが空でなければ（Ｓ４５−２でＮＯ）、スケジュール対象外キュー６１ＡにおけるＩ／Ｏ要求を優先して出すために、バッチスケジュール処理を一旦終え、図９ＡのＳ４１及びＳ４２を経てＳ４３の即時処理を実行することができる。
【００７６】
以上が、第二実施例についての説明である。この第二実施例によれば、クエリ実行部９から発行された複数のＩ／Ｏ要求が、クエリ実行部９から発行された順序で外部記憶装置１９に送信されるのではなく、一旦、蓄積され、蓄積された複数のＩ／Ｏ要求の順序が、Ｉ／Ｏ最適化部２７によって最適化されてから出力される。これにより、複数のＩ／Ｏ要求がクエリ実行部９から発行されてからクエリ実行部９にデータが読出されるまでの全体としての読出し時間長を短縮することができる。以下、この第二実施例で期待される効果について、第一実施例で期待される効果と比較して説明する。なお、以下の説明は、第一実施例と第二実施例の理解をより深めるためのものに過ぎず、以下の期待される効果を奏しないからといって、本願発明の技術的範囲から外れるものではない。故に、その説明で用いる図１１Ａ〜図１３Ｂは、必ずしも精密な記載にはなっていない。例えば、図１１Ｂ、図１２Ｂ及び図１３Ｂのディスクシークイメージの図において、横軸における単位距離が表す時間長は必ずしも同じではない。
【００７７】
例えば、第一実施例において、図１１Ａに例示するように、クエリ実行部９から、６つのＩ／Ｏ要求Ａ〜Ｆが発行されたとする。第一実施例では、Ｉ／Ｏ最適化部２７が存在しないので、ＤＢＭＳ５において、第二実施例のように、ＤＢＭＳ５内で、ＯＳ１５へ発行する複数のＩ／Ｏ要求Ａ〜Ｆの並び替えは行われない。この場合には、例えば、ＯＳ１５のカーネル、或いは、外部記憶装置１９の機能によって、Ｉ／Ｏ要求の並び替えが行われる場合がある。例えば、全Ｉ／Ｏ要求Ａ〜Ｆのうち、Ｉ／Ｏ要求Ａ〜ＣとＤ〜Ｆとの各グループ別に並び替えが行われる場合がある。全Ｉ／Ｏ要求Ａ〜Ｆではなく、グループ別に行われるのは、例えば、ＯＳ１５や外部記憶装置１９にとっては、どれだけの数のＩ／Ｏ要求が来るかわからないので、所定数或いは一定時間待って蓄積された段階でＩ／Ｏ要求の並び替えを行わないと、上位の装置或いはコンピュータプログラムを長く待たせてしまうことになるからである。図１１Ａの例では、ＯＳ１５又は外部記憶装置１９が、Ｉ／Ｏ要求Ａ〜Ｃまで受け付けた段階で、「Ａ→Ｂ→Ｃ」の順から「Ｂ→Ｃ→Ａ」の順に並び替えてデータ読出しを行う。次に、ＯＳ１５又は外部記憶装置１９が、次のＩ／Ｏ要求Ｄ〜Ｆまで受け付けた段階で、「Ｄ→Ｅ→Ｆ」の順から「Ｅ→Ｆ→Ｄ」の順に並び替えてデータ読出しを行う。この結果、図１１Ｂに例示するように、Ｉ／Ｏ要求Ａ〜Ｆに対応するデータの読み出しのためのディスクシーク時間長をある程度短縮化することができる（しかし、前述したようにＩ／Ｏ要求が並行して発行されるので、これでも、従来技術に比べれば、短縮化される）。
【００７８】
これに対し、第二実施例では、図１２Ａに例示するように、ＤＢＭＳ５内で、ＯＳ１５へ発行する複数のＩ／Ｏ要求Ａ〜Ｆの順序が最適化され、最適化後の順序で、Ｉ／Ｏ要求がＯＳ１５を介して外部記憶装置１９へと発行される。このため、図１２Ｂに例示するように、第一実施例に比べて、Ｉ／Ｏ要求Ａ〜Ｆに対応するデータの読み出しのためのディスクシーク時間長を短縮化することができる。なお、この第二実施例において、第一実施例のように、ＯＳ１５或いは外部記憶装置１９によってＩ／Ｏ要求の並び替えが行われたとしても、Ｉ／Ｏ最適化部２７によって並び返された順序と同じ順序になる可能性が大きいので、図１２Ａ及び図１２Ｂに例示の効果が期待される。
【００７９】
また、第二実施例において、例えば、バッチスケジュール処理によってＩ／Ｏ要求の発行順序が最適化された後に、スケジュール対象外のＩ／Ｏ要求が発行されて、そのＩ／Ｏ要求が優先的にＤＢＭＳ５から発行された場合には、Ｉ／Ｏ要求Ａ〜Ｆに対応するデータの読み出しのためのディスクシーク時間長は、図１３Ａ及び図１３Ｂに例示するように、即時発行が全く無い場合に比べて、長くなる可能性がある。しかし、それでも、少なくとも従来よりは、Ｉ／Ｏ要求Ａ〜Ｆに対応するデータの読み出しのためのディスクシーク時間長を短縮化することができる。なお、図１３Ａ、図１３Ｂにおいて、Ｉ／Ｏ最適化部２７は、Ｉ／Ｏ要求Ｅの即時発行が決まった場合、残りのＩ／Ｏ要求Ａ〜Ｄ及びＦの並び替えをやり直しても良い。
【実施例３】
【００８０】
以下、本発明の第三実施例について説明する。
【００８１】
この第三実施例では、クエリ実行部９は、第一実施例（又は第二実施例）において、複数のデータが読み出された場合、読み出された順にタスクの実行を再開していくのではなく、データ取得処理を開始した順に、タスクの実行を再開していく。タスクの実行を再開する順序を制御するための方法として、例えば、データ取得待ち表を用いる方法がある。
【００８２】
図１４Ａは、本発明の第三実施例におけるデータ取得待ち表の構成例を示す。
【００８３】
データ取得待ち表７１は、データベースサーバ１の記憶資源に記憶される情報である。データ取得待ち表７１は、複数の待ち情報７１Ｒ、７１Ｒ、…から構成される。待ち情報７１Ｒは、データ取得順序番号とタスクＩＤとで構成される。データ取得順序番号は、データ取得処理を開始する順序を表した番号である。タスクＩＤは、待ち情報７１Ｒを記述したタスクのＩＤである。
【００８４】
図１４Ｂは、生成された子タスクが第一実施例で行う処理との第一の相違部分を示す。
【００８５】
生成された子タスクは、データ取得処理を実行する前に、データ取得待ち表７１に、自分に対応した待ち情報を挿入する（Ｓ６１）。具体的には、当該子タスクは、自分に対応した待ち情報７１Ｒとして、図３のＳ１１のデータ取得処理を開始する順番であるデータ取得順序番号と、自分のタスクのＩＤとを、データ取得待ち表７１に挿入する。
【００８６】
図１４Ｃは、生成された子タスクが第一実施例で行う処理との第二の相違部分を示す。
【００８７】
当該子タスクは、データ取得処理によってデータが取得された場合、データ取得待ち表７１を検索し、自タスクが最も古い待ちタスクとなるまで待ち、そうなった後、データ取得待ち表７１から、Ｓ６１で自分が挿入した待ち情報７１Ｒを削除する（Ｓ６２）。なお、最も古い待ちタスクになったかどうかは、データ取得待ち表７１に記入されているデータ取得順序番号の中で、自分が挿入した待ち情報７１Ｒ中のデータ取得順序番号が若い番号かどうかを判別することにより、特定することができる。なお、別法として、例えば、データ取得待ち表７１Ｒが、待ち行列であって、自分が書いた待ち情報７１Ｒが先頭アドレスになったときに、自タスクが最も古い待ちタスクであると判別しても良い。
【００８８】
以上の処理により、生成された複数の子タスクは、データ取得処理によってデータ待ちとなった場合、データが取得された順に実行の再開となるのではなく、データ取得処理を開始した順に、実行の再開となる。具体的には、例えば、図１５Ａに例示するように、データ取得処理の開始順序と同じ順序でＩ／Ｏ要求Ａ〜Ｆが発行された場合、その順序と違って、例えば、Ｉ／Ｏ要求Ａに対応したデータＡよりも先に、Ｉ／Ｏ要求Ｂ、Ｃの応答としてデータＢ、Ｃが取得されたとしても、データＢ、Ｃを処理するタスクＢ、Ｃの実行の再開は待ちとなり、データＡが取得されてそれを処理するタスクＡの実行が再開された後に、タスクＢ、Ｃの順序で実行が再開される（なお、ディスクシークイメージとしては、図１５Ｂに例示する通りであり、例えば第一実施例と同じである）。このように、この第三実施例では、各タスクの実行を、データ取得処理の開始順序と同じ順序で再開していくことができる。
【００８９】
以上、本発明の好適な幾つかの実施例を説明したが、本発明は、それらの実施例に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【００９０】
例えば、第二実施例において、Ｉ／Ｏ最適化部２７は、別種の所定のキャンセルコマンドを受け付けた場合には、そのキャンセルコマンドで指定されているＩ／Ｏ要求、又は、スケジュール対象外キュー６１Ａに残っている全てのＩ／Ｏ要求を、スケジュール対象外キュー６１Ａから取り出し、取り出されたＩ／Ｏ要求を、スケジュール対象キュー６１Ｂに格納してもよい。
【００９１】
また、例えば、各実施例において、ＤＢＭＳ５の処理は、それを読込んだプロセッサによって実行することができる。具体的には、例えば、親タスクを実行するプロセッサは、データベースサーバ１の記憶資源（例えばメモリ）上に子タスクを生成し、その子タスクを読込んで実行することにより、例えば図３のＳ１１以降の処理を実行することができる。
【００９２】
また、例えば、実行タスク管理部１３が、所定のタイミングで、クエリプランに基づいて、残存ステップ数（例えば、最後のＯＰまでに残っているＯＰの数）を計算し、残存ステップ数の少ないタスクの優先度を上げても良い。この場合、例えば、図３のＳ２、Ｓ３の処理によって、優先度が上げられたタスクを優先的に生成することができる。また、そのタスクは、自分の優先度が高いので、Ｉ／Ｏ要求を発行する場合、スケジュール対象外キュー６１Ａに、発行したＩ／Ｏ要求を挿入することができる。
【００９３】
また、例えば、第二実施例において、スケジュール対象とスケジュール対象外との二種類のキューではなく、三以上の優先度の異なるキューが用意されても良い。その場合、クエリ実行部９は、Ｉ／Ｏ要求の優先度に応じた値のスケジュールフラグを決定し、その決定されたスケジュールフラグ値に応じたキューに、Ｉ／Ｏ要求を格納してもよい。
【００９４】
また、例えば、第二実施例において、Ｉ／Ｏ最適化部２７は、ＤＢＭＳ５の外に存在しても良い。具体的には、例えば、Ｉ／Ｏ最適化部２７は、ＤＢＭＳ５とＯＳ１５との間に介在しても良い。Ｉ／Ｏ最適化部２７は、ＤＢＭＳ５から発行された複数のＩ／Ｏ要求を受け付けることができる。また、Ｉ／Ｏ最適化部２７は、ＡＰ３からもＩ／Ｏ要求をうつけても良い。Ｉ／Ｏ最適化部２７は、受け付けた複数のＩ／Ｏ要求（発行元はＤＢＭＳ５又はＡＰ３）を、受け付けた順序と異なる順序に並び替え、並び替え後の順序でＩ／Ｏ要求をＯＳ１５に発行することができる。
【００９５】
また、例えば、データベース管理システムは、一つのコンピュータマシン上に構築されてもよいし、複数のコンピュータマシン上に構築されても良い。具体的には、例えば、各実施例にけるＤＢＭＳ５の処理は複数のコンピュータ上で並列に動作する並列ＤＢＭＳにおいても同様に適用することができる。並列ＤＢＭＳでは、クエリ生成部でクエリプランを生成した後、処理を複数のＤＢＭＳサーバに割り当てる。そのため、各ＤＢＭＳサーバにおいて、本発明の技術を用いて、割り当てられた処理を複数のタスクを生成しながらＩ／Ｏ要求を並列に処理することで、問合せの実行時間の短縮を図ることが可能である。
【符号の説明】
【００９６】
１…データベースサーバ ３…アプリケーションプログラム ５…データベース管理システム ７…クエリ受付部 ９…クエリ実行部 １１…クエリプラン生成部 １２…データベースバッファ １３…実行タスク管理部 １５…オペレーティングシステム １７…通信ネットワーク １９…外部記憶装置 ２１…データベース ２３…表 ２５…索引 ２７…Ｉ／Ｏ最適化部 ６１Ａ…スケジュール対象外キュー ６１Ｂ…スケジュール対象キュー ６３…Ｉ／Ｏ要求
【技術分野】
【０００１】
本発明は、データベース管理技術に関わる。
【背景技術】
【０００２】
例えば、特開２００４−１９２２９２号公報には、バーチャリゼーション環境上にＤＢ（データベース）を構築したシステムにおける管理サーバが開示されている。その管理サーバは、ＤＢＭＳ（データベース管理システム）からＤＢ処理の実行計画や処理優先度等のＤＢ処理情報を取得し、その情報を基にこれからアクセスが行われるデータとそのアクセス順を予測し、予測結果に基づいて近い将来アクセスが行われるデータを記憶装置のキャッシュ上に読み出すよう指示し、最も近い将来にアクセスが行われるデータを自サーバのキャッシュメモリに読み出す。
【先行技術文献】
【特許文献】
【０００３】
【特許文献１】特開２００４−１９２２９２号公報
【発明の概要】
【発明が解決しようとする課題】
【０００４】
ところで、通常、ＤＢＭＳは、クエリを受け付け、クエリを受け付けた場合には、そのクエリを実行してその実行結果を出力するようになっている。クエリの実行結果を出力するまでには、複数段階のデータベースオペレーションが実行される場合がある。それら複数段階のデータベースオペレーションは、一般に、所定の順序で実行されるようになっており、それら複数段階のデータベースオペレーションのうちの少なくとも一つのデータベースオペレーションでは、記憶装置に対して読出し要求を発行する必要のある場合がある。以下、図１Ａ〜図１Ｃを参照して一つの具体例を説明する。
【０００５】
例えば、ＤＢＭＳが、ＤＢＭＳの上位にあるコンピュータプログラム（例えばアプリケーションプログラム）からクエリを受け付けた場合に、そのクエリの実行プラン（以下、単に「クエリプラン」と言う）として、図１Ａに記載のクエリプランを生成したとする。そして、図１Ｂに記載のパート表２３Ａ、ラインアイテム表２３Ｂ、オーダ表２３Ｃ及び各種インデックス２５が、記憶装置（例えば、ＤＢＭＳを備えた情報処理端末に通信可能に接続された外部記憶装置）に格納されているとする。
【０００６】
図１Ａに例示したクエリプランによれば、パート表２３Ａから未読の行がなくなるまで、データベースオペレーション（以下、「ＯＰ」と略記）１〜５が繰り返される。ＯＰ１は、初期データベースオペレーションであり、パート表２３Ａ（図１Ｂ参照）から１行読む処理である。ＯＰ２は、読まれた行中のＰＩＤに対応するラインアイテム表２３Ｂ（図１Ｂ参照）のポインタ（rowid）をラインアイテムインデックス２５Ａで検索する処理である。ＯＰ３は、得られたポインタでラインアイテム表２３Ｂをフェッチし、ＯＩＤでフィルタをかける処理（例えば、ＯＩＤが５０４未満のもののみを出力する処理）である。ＯＰ４は、出力されたＯＩＤに対応するオーダ表２３Ｃ（図１Ｂ参照）のポインタ（rowid）をオーダインデックス２５Ｂで検索する処理である。ＯＰ５は、得られたポインタでオーダ表２３Ｃをフェッチし、結果としてリターンする処理である。以上のようなＯＰ１〜ＯＰ５が繰り返されることにより、図１Ｃに例示するようなクエリ実行結果を、クエリの発行元のコンピュータプログラムに返すことができる。
【０００７】
上記のようにして一つのクエリを実行する場合には、複数のＯＰが繰り返し実行され、且つ、各回の実行において、一つのＯＰが終了してから次のＯＰが開始される。このため、例えば、或るＯＰ（例えばＯＰ３）において、読出し要求が発行された場合には、その読出し要求に応答してデータが読み出されるまで処理が中断してしまう。故に、一つのクエリの実行に要する時間が長くなってしまう。
【０００８】
また、上記のようにして一つのクエリを実行する場合には、記憶装置をランダムアクセスすることがある。具体的には、ラインアイテム表２３Ｂ、オーダ表２３Ｃ及びインデックスの読み込みがランダムになってしまうことがある。より具体的には、例えば、ラインアイテム表２３Ｂの一行目にアクセスした後、６行目及び９行目もパート表２３Ａの行に対応した行であるにも関わらず、一旦１２行目にアクセスした後に、６行目へのアクセスが行われてしまう。一つのクエリの実行の際、ＤＢＭＳから読出し要求が複数回発行されることになるが、上記のようなランダムアクセスが行われると、全体としてのデータ読出し待ち時間が長くなってしまう。
【０００９】
従って、本発明の一つの目的は、一つのクエリの実行に要する時間を短縮化することにある。具体的には、例えば、一つのクエリの実行における全体としてのデータ読出し待ち時間を短縮化することにある。
【００１０】
本発明の他の目的は、後述の説明から明らかになるであろう。
【課題を解決するための手段】
【００１１】
本発明の一つの観点に従うデータベース管理システムは、クエリを受け付けるクエリ受付部と、前記受け付けたクエリを実行し、その際、必要に応じて、記憶装置（例えば主記憶装置）からデータベースのデータを読み出すためのデータ読出し要求を発行するクエリ実行部とを備える。前記クエリ実行部は、動的にタスクを生成していき、生成された複数のタスクを並行して実行する。前記クエリ実行部は、各タスクの実行において、前記データベースのデータを必要とする都度に、そのデータを取得するためのタスクを生成する。また、前記クエリ実行部は、該生成されたタスクの実行において、必要に応じて、前記データベースからデータを読み出すための前記データ読出し要求を発行する。
【００１２】
このデータベース管理システムの具体例としては、以下の通りである。すなわち、データベース管理システムは、上位のコンピュータプログラム（例えば、アプリケーションプログラム）からクエリ（例えばＳＱＬ）を受け付けるクエリ受付部と、該受け付けたクエリを実行するプランであるクエリプランを生成するクエリプラン生成部と、該生成されたクエリプランに従いクエリを実行するクエリ実行部とを備えることができる。クエリプランは、例えば、データ読出しを伴う一つ以上のデータベースオペレーションで構成され、該データベースオペレーション間の実行順序には木構造の順序関係が存在する。クエリ実行部は、他のデータベースオペレーションに依存しない初期データベースオペレーションを抽出してタスクを割り当てるステップと、該割り当てられたタスクを実行するステップとで構成することができる。
【００１３】
該データベースオペレーションに対応したタスクを実行するステップでは、以下の（Ａ）〜（Ｄ）のステップ、
（Ａ）データ読出し処理に対して複数の独立したタスクを生成するステップ、
（Ｂ）該生成された複数のタスクのデータ読出し処理において、外部記憶装置からのデータ読出しが必要な場合、オペレーティングシステムにデータ読出し要求を発行するステップ、
（Ｃ）該データ読出しが完了したタスクから当該データベースオペレーションの実行を再開するステップ、
（Ｄ）該データベースオペレーションに依存した次のデータベースオペレーションがある場合、該次のデータベースオペレーションを実行するステップ、
を実行することができる。
【００１４】
第一の態様では、前記クエリ実行部は、所定の状況にあるタスクの現存数が所定数に達している場合には、新たなタスクの生成を待ち、前記現存数が減った場合に、前記新たなタスクを生成することができる。所定の状況とは、例えば、単に現存している状況であっても良いし、データ取得待ちの状況であっても良い。
【００１５】
第二の態様では、データベース管理システムは、読出し順序制御部を更に備えることができる。読出し順序制御部は、前記クエリ実行部から発行された複数個のデータ読出し要求を受け、受け付けた複数個のデータ読出し要求を、前記複数個のデータ読出し要求を受け付けた順序とは異なる、全体としてのデータ読出し時間長（すなわち、複数個のデータ読出し要求に応じてデータが読み出されるまでの時間長）を短縮化するための順序で発行することができる。
【００１６】
具体的には、例えば、データベース管理システムは、前記クエリ実行部からのデータ読出し要求を受け付け、そのデータ読出し要求をオペレーティングシステムに発行する読出し最適化部を備えることができる。読出し最適化部は、受け付けたデータ読出し要求をキューイングし、データ読出し要求を発行するタイミングを制御するための条件（例えば、後述する第二実施例のバッチスケジューリング駆動条件）が満たされた場合に、キューイングされた複数のデータ読出し要求の出力順序を変更することで、データ読出し時間を最適化することができる。
【００１７】
第三の態様では、データベース管理システムは、優先順位の異なる複数のキューを更に備えることができる。前記クエリ実行部は、前記生成されたタスクの実行により、前記複数のキューのうち、所定の条件に適合する優先度に対応したキューに、前記データ読出し要求を格納することができる。前記読出し順序制御部は、優先度の高いキューに格納されているデータ読出し要求ほど優先的に発行することができる。
【００１８】
具体的には、例えば、読出し最適化部は、スケジュール対象外を含む複数の読出し要求キューを有し、読出し要求キュー毎に設定された処理手順に従い、データ読出し要求を発行することができる。この場合において、タスクを実行することによってデータ読出し要求を読出し最適化部へ発行する際に、以下の（ａ）〜（ｃ）の処理、
（ａ）読出し要求に対するスケジューリングフラグを付与する処理、
（ｂ）該スケジューリングフラグの値に応じて複数の読出し要求キューの中から一つの読出し要求キューを選択する処理、
（ｃ）選択した読出し要求キューへ読出し要求を格納する処理、
を実行することができる。読出し最適化部では、データ読出し要求をキューに保管し続ける時間長を変更することができる。
【００１９】
第四の態様では、上述の第三の実施態様において、前記読出し順序制御部は、所定のコマンドを受け付けた場合には、或る優先度のキューに格納されている少なくとも一つの読出し要求を別の優先度のキューに移動させることができる。
【００２０】
具体的には、例えば、データベース管理システムは、スケジュール対象の読出し要求キューにキューイングされたデータ読出要求に対してスケジュールキャンセルコマンドを発行することにより、該データ読出し要求をスケジュール対象外の読出し要求キューに移すことができる。
【００２１】
第五の態様では、上述の第三の態様において、前記クエリ実行部は、前記受け付けたクエリの実行プランの内容、又は、前記受け付けたクエリの実行に求められる性能要件に応じて、どの優先度のキューに読出し要求を格納するかを決定することができる。
【００２２】
第六の態様では、上述の第三の態様において、データベース管理システムは、タスク管理部を備えることができる。タスク管理部は、クエリ実行プランに基づいて、残存ステップ数を計算し、計算された残存ステップ数の少ないタスクの優先度を上げることができる。この場合において、前記クエリ実行部が、優先度の上がったタスクを実行することにより発行される読出し要求を、該優先度に対応するキューに格納することができる。ここで、残存ステップとは、例えば、残存するデータオペレーションの数とすることができる。
【００２３】
第七の態様では、前記クエリ実行部は、生成された各タスクの実行において、前記データベースのデータの取得を待ち、該データを取得した後、データの取得待ちを開始した順序と同じ順序で、タスクの実行を再開することができる。これは、上記第二の態様においても行うことができる。
【００２４】
本発明の別の観点に従うコンピュータシステムは、上述したデータベース管理システムと、読出し順序制御部とを備える。読出し順序制御部は、データベース管理システムから発行された複数個のデータ読出し要求を受け付け、受け付けた複数個のデータ読出し要求を、前記複数個のデータ読出し要求を受け付けた順序とは異なる、全体としてのデータ読出し時間長を短縮化するための順序で発行する。
【発明の効果】
【００２５】
本発明に従うデータベース管理システムによれば、一つのクエリの実行に要する時間長を短縮化することができる。
【図面の簡単な説明】
【００２６】
【図１】図１Ａは、クエリプランの一例を示す。図１Ｂは、パート表、ラインアイテム表及びオーダ表の構成例と表同士の関連とを示す。図１Ｃは、クエリの実行結果として出力される情報の例を示す。
【図２】図２は、本発明の第一実施例に係るシステムの構成例を示す。
【図３】図３は、クエリ実行部９が行う処理の流れの一例を示す。
【図４】図４Ａは、図３のＳ２のタスク生成待ち処理において行われる処理の流れの一例を示す。図４Ｂは、図３のＳ１１のデータ取得処理において行われる処理の流れの一例を示す。
【図５】図５Ａは、従来のクエリ実行の流れの一例を示す。図５Ｂは、本発明の第一実施例におけるクエリ実行の流れの一例を示す。
【図６】図６は、本発明の第二実施例に係るシステムの構成例を示す。
【図７】図７Ａは、本発明の第二実施例で行われるデータ取得処理の流れの一例を示す。図７Ｂは、Ｉ／Ｏ要求発行処理の流れの一例を示す。
【図８】図８は、Ｉ／Ｏ最適化部２７の説明図である。
【図９】図９Ａは、Ｉ／Ｏ最適化部２７が行う処理の流れの一例を示す。図９Ｂは、即時発行処理の流れの一例を示す。
【図１０】図１０Ａは、スケジュールキャンセル処理の流れの一例を示す。図１０Ｂは、バッチスケジュール処理の流れの一例を示す。
【図１１】図１１Ａ及び図１１Ｂは、本発明の第一実施例のＤＢＭＳ５によって期待される効果の一例の説明図である。具体的には、図１１Ａは、第一実施例におけるＩ／Ｏ要求の発行とデータの読み出しの流れの一例を示す。図１１Ｂは、図１１Ａに示した流れにおけるディスクシークイメージの一例を示す。
【図１２】図１２Ａ及び図１２Ｂは、本発明の第二実施例のＤＢＭＳ５によって期待される効果の一例であって、即時発行処理が行われない場合の説明図である。
【図１３】図１３Ａ及び図１３Ｂは、本発明の第二実施例のＤＢＭＳ５によって期待される効果の一例であって、即時発行処理が行われる場合の説明図である。
【図１４】図１４Ａは、本発明の第三実施例におけるデータ取得待ち表の構成例を示す。図１４Ｂは、生成された子タスクが第一実施例で行う処理との第一の相違部分を示す。図１４Ｃは、生成された子タスクが第一実施例で行う処理との第二の相違部分を示す。
【図１５】図１５Ａは、データ取得処理の開始順序、データの取得順序、及びタスクの再開順序の関係の一例を示す。図１５Ｂは、図１５Ａにおけるディスクシークイメージの一例を示す。
【発明を実施するための形態】
【００２７】
以下、図面を参照して、本発明についての幾つかの実施例を説明する。
【実施例１】
【００２８】
図２は、本発明の第一実施例に係るシステムの構成例を示す。
【００２９】
データベースサーバ１と、データベースサーバ１の外に存在する記憶装置である外部記憶装置１９とが、通信ネットワーク１７を介して通信可能に接続されている。
【００３０】
外部記憶装置１９は、記憶資源を有する装置であればどのような装置であっても良い。例えば、外部記憶装置１９は、ファイルサーバであっても良いし、単体のディスクドライブ（例えばハードディスクドライブ）であっても良いし、複数のディスクドライブを備えた記憶装置システムであっても良い。外部記憶装置１９は、データベース２１を有し、データベース２１内に、複数の電子的な索引２５、２５、…と、複数の電子的な表２３、２３、…とを記憶することができる。各索引２５は、例えば、或る表における各行と別の表における各行との繋がりを表すポインタを複数個備えるデータ（例えば、図１Ｂにおけるインデックス２５Ａ、２５Ｂ）であり、B-木インデクスなどが用いられる。各表２３は、複数の行要素から成る行を複数個有するデータ（例えば、図１Ｂにおけるパート表２３Ａ、ラインアイテム表２３Ｂ又はオーダ表２３Ｃ）である。
【００３１】
データベースサーバ１は、例えば、格別図示しないが、複数のコンピュータプログラムを記憶することができる記憶資源（例えばメモリやハードディスク）や、記憶資源からコンピュータプログラムを読み込んで実行することができるプロセッサ（例えばＣＰＵ）等を有するコンピュータマシンである。記憶資源に記憶されているコンピュータプログラムとして、例えば、クエリ（例えばＳＱＬ（Structured Query Language））を発行するアプリケーションプログラム（以下、ＡＰ）３と、ＡＰ３からクエリを受けて実行し実行結果をＡＰ３に返すデータベース管理システム（以下、ＤＢＭＳ）５と、ウィンドウズ（登録商標）等のオペレーティングシステム（以下、ＯＳ）１５とがある。ＯＳ１５の上位にＤＢＭＳ５があり、ＤＢＭＳ５の上位にＡＰ３が存在する。なお、ＡＰはＤＢＭＳと異なるコンピュータに存在していても良い。その場合には、ＡＰからの問合せ要求はネットワーク経由で受け付ける。また、記憶資源の一部を利用して、例えば、ＤＢＭＳ５で利用されるデータベースバッファ（以下、ＤＢバッファ）１２を構築することができる。
【００３２】
ＤＢＭＳ５は、例えば、ＡＰ３からクエリを受け付けるクエリ受付部７と、クエリ受付部７が受け付けたクエリに基づいて例えば図１Ａに例示したようなクエリプランを生成するクエリプラン生成部１１と、生成されたクエリプランに従がってクエリを実行するクエリ実行部９と、クエリの実行のためのタスクを管理する（例えばタスクに対してＣＰＵやメモリ等のリソースを割り当てる）実行タスク管理部１３とを有する。クエリプランは、複数のデータベースオペレーション（ＯＰ）の実行順序を定義したものである。
【００３３】
この第一実施例では、特にクエリ実行部９が行う処理に特徴がある。クエリ実行部９は、少なくとも一つのＯＰを割り当てたタスクを実行することにより、当該少なくとも一つのＯＰを実行することができる。そして、クエリ実行部９は、そのタスクの実行中において、外部記憶装置１９からのデータの読出しが必要になれば、そのデータを読み出して次のＯＰを実行するタスクを生成し、生成されたタスクを実行することにより、データの入出力要求（以下、「Ｉ／Ｏ要求」と記載）を発行することができる。タスクを複数個生成した場合には、複数個のタスクを並行して実行することができ、故に、複数個のＩ／Ｏ要求を並行して発行することができる。なお、タスクの実装としては、ＯＳが管理するプロセスやスレッド、または、アプリケーションやミドルウェアが実装する擬似プロセスや擬似スレッドなど任意の実行環境が利用できる。
【００３４】
以下、クエリ実行部９が行う処理について説明する。なお、以下、説明を分かり易くするために、一つのタスクを実行することにより一つのＯＰが実行されるものとする。しかし、勿論それに限定する必要は無く、例えば、一つのタスクを実行することにより、複数のＯＰが実行されても良い。具体的には、例えば、一つのタスクが、或るＯＰを実行し、その実行結果を引き継いで、次のＯＰを実行しても良い。
【００３５】
図３は、クエリ実行部９が行う処理の流れの一例を示す。
【００３６】
クエリ実行部９は、或る段階のデータベースオペレーション（ＯＰ）を割り当てたタスク（以下、便宜上「親タスク」と言う）を実行することにより、そのＯＰを実行することができる。
【００３７】
実行された親タスクは、そのＯＰの実行において、残りのデータ（例えば、索引２５又は表２３から未だ読み出されていないデータ）があれば（ステップＳ１で「データあり」）、タスク生成待ち処理を実行する（Ｓ２）。タスク生成待ち処理により、タスクを生成することができるようになったら、親タスクは、残りのデータを読み出して次のＯＰを実行することを割り当てたタスク（以下、便宜上「子タスク」と言う）３１を生成する（Ｓ３）。親タスクの実行中においては（Ｓ４で「親タスク」）、再びＳ１が実行される。また、Ｓ１で「データなし」の場合には、当該親タスクは消滅することができる。
【００３８】
クエリ実行部９は、並行して、生成された子タスク３１を実行することができる。Ｓ１からＳ４の「親タスク」の処理が繰り返されることにより、同一の次のＯＰを実行する子タスクが複数個生成された場合には、生成された複数個の子タスク３１、３１、…を並行して実行することができる。
【００３９】
実行された子タスク３１は、Ｓ１における残りのデータを取得するデータ取得処理を実行し（Ｓ１１）、データを取得できれば（Ｓ１１で「データあり」）、その取得されたデータが選択条件にマッチするか否かを判断するＳ１２の処理を行う（なお、このＳ１２は、ＯＰの種類によっては行われない）。マッチすれば（Ｓ１２で「あり」）、子タスク３１は、自分に割り当てられたＯＰの次のＯＰがあれば（Ｓ１３で「あり」）、次のＯＰを実行し（Ｓ１４）、なければ（Ｓ１３で「なし」）、結果をリターンする（Ｓ１５）。次のＯＰがあるか否かは、例えば、クエリプラン生成部１１によって生成された図１Ａに例示したクエリプランを参照することにより判別することができる。また、Ｓ１４の次のＯＰの実行では、当該子タスクは、親タスクとして、上述したＳ１の処理を実行し、Ｓ３で子タスクを生成することができる。
【００４０】
図４Ａは、図３のＳ２のタスク生成待ち処理において行われる処理の流れの一例を示す。
【００４１】
親タスクは、自分より高い優先度のタスクが生成待ちか否かを判定する（Ｓ２−１）。具体的には、例えば、親タスクは、クエリプランを参照し、他の親タスクの実行において生成待ちとなっている子タスクが、自分よりも後段のＯＰを実行するタスクか否かを判定する。
【００４２】
Ｓ２−１の判定の結果、待ちであれば（Ｓ２−１で「あり」）、親タスクは、タスクの生成が行われる契機となるイベントの発生を待つ（Ｓ２−２）。
【００４３】
一方、Ｓ２−１の判定の結果、待ちでなければ（Ｓ２−１で「なし」）、親タスクは、現存するデータ取得待ちタスク数が所定の閾値未満か否かを判定する（Ｓ２−３）。現存するデータ取得待ちタスク数は、例えば、クエリ実行部９が、タスクを生成する都度に所定のカウント値を１増やし、データ取得が完了する都度にそのカウント値を１減らすことで、そのカウント値を参照することにより、判別することができる。また、閾値は、データベースサーバ１の記憶資源に記憶される値である。閾値は、例えば、一種のチューニングパラメータであり、ＤＢＭＳ５の管理者が所望の値とすることができる。また、閾値は、ＤＢＭＳシステム全体で決めることも可能であるし、問合せやユーザなど任意の単位で設定することが可能である。
【００４４】
Ｓ２−３の判定の結果、残存タスク数が所定の閾値未満であれば（Ｓ２−３で「はい」）、親タスクは、図３のＳ２のタスク生成待ち処理を終えて次のＳ３を実行することができ、そうでなければ（Ｓ２−３で「いいえ」）、少なくとも一つのタスクが消滅する契機となるイベントの発生を待つ（Ｓ２−４）。ここでのイベントとしては、例えば、図３のＳ１において「データなし」となることが挙げられる。
【００４５】
図４Ｂは、図３のＳ１１のデータ取得処理において行われる処理の流れの一例を示す。
【００４６】
子タスクは、ＤＢバッファ１２にアクセスし、過去に読み出されたデータが残っている等の理由により、ＤＢバッファ１２に、自分の読出し対象のデータが存在していれば（Ｓ１１−１で「ヒット」）、そのデータをＤＢバッファ１２から取得して（Ｓ１１−５）、このデータ取得処理を終える。
【００４７】
子タスクは、ＤＢバッファ１２に、自分の読出し対象のデータが存在していない場合（Ｓ１１−１で「フォルト」）、そのデータが存在する領域に対してＩ／Ｏ要求が未だ発行されていなければ（Ｓ１１−２で「未」）、ＯＳシステムコールによるＩ／Ｏ発行を行う（Ｓ１１−３）。すなわち、子タスクは、ＯＳ１５にＩ／Ｏ要求を出すことで、ＯＳ１５から外部記憶装置１９に対するＩ／Ｏ要求を発行させる。子タスクの実行は、それに応答して、外部記憶装置１９からＯＳ１５を介してデータが読み出されるまで待ちとなる。データが読み出されたならば（Ｓ１１−５）、子タスクは、処理を再開し、読み出されたデータをＤＢバッファ１２に格納して、このデータ取得処理を終える。
【００４８】
子タスクは、Ｓ１１−１で「フォルト」の場合、自分の読出し対象のデータが存在する領域に対してＩ／Ｏ要求が既に発行されていれば（Ｓ１１−２で「既」）、Ｉ／Ｏ要求の完了を待つ（Ｓ１１−４）。データが読み出されたならば（Ｓ１１−５）、子タスクは、処理を再開し、読み出されたデータをＤＢバッファ１２に格納して、このデータ取得処理を終える。なお、自分の読出し対象のデータが存在する領域に対してＩ／Ｏ要求が既に発行されているか否かは、例えば、各タスクが、Ｉ／Ｏ要求をＯＳ１５に発行する都度に、そのＩ／Ｏ要求によるアクセス先に関するＩ／Ｏ先情報を、データベースサーバ１の記憶資源上の所定記憶領域に書き、子タスクは、その所定記憶領域上の各Ｉ／Ｏ先情報を参照することにより、判定することができる。Ｉ／Ｏ先情報としては、例えば、外部記憶装置１９に設けられた論理ユニットの識別子（例えば論理ユニット番号）と、アクセス先の論理ブロックアドレス（以下、ＬＢＡ）とを含んだ情報とすることができる。データベースサーバ１の記憶資源は、例えば、ＤＢオブジェクト（例えば、表２３、索引２５、又は表２３や索引２５上の各行要素（例えばＰＩＤ、ＯＩＤ等））と記憶位置（例えば、論理ユニット識別子及び／又はＬＢＡ）との対応関係を表すマッピング情報を記憶することができ、各タスクは、そのマッピング情報に基づいて、ＯＳ１５に対してＩ／Ｏ要求を発行したり、上記Ｉ／Ｏ先情報を所定記憶領域に書き込んだりすることができる。
【００４９】
上述した第一実施例によれば、クエリ実行部９は、タスクの実行中において、外部記憶装置１９からのデータの読出しが必要になれば、そのデータを読み出して次のＯＰを実行するタスクを生成し、生成されたタスクを実行することにより、Ｉ／Ｏ要求を発行することができる。タスクを複数個生成した場合には、複数個のタスクを並行して実行することができ、故に、複数個のＩ／Ｏ要求を並行して発行することができる。このことを、図１Ａに例示したクエリプランに従がってクエリを実行する場合を例に採って説明すると、従来の技術によれば、図５Ａに示すように、パート表２３Ａから未読の行がなくなるまで、ＯＰ１からＯＰ５までを終えて再びＯＰ１から開始することを繰り返す必要があるが、上述した第一実施例によれば、図５Ｂに示すように、同一段階のＯＰを並行して実行することができる。具体的には、例えば、パート表２３Ａの行数は３なので、ＯＰ１が割り当てられたタスクが実行されることにより、複数の子タスクが生成され、それら複数の子タスクが並行して実行されることにより、パート表２３Ａの３行にそれぞれ対応した３つのＯＰ２を並行して実行することができる。各ＯＰ２の実行後、ＯＰ３も並行して実行され、その実行結果に応じて、タスクが消滅してＯＰ４以降が実行されなかったり（例えば、フェッチされたＯＩＤが５０４未満であったため図３のＳ１２の選択条件にマッチしないが故に終了となってタスクが消滅したり）、一つのＯＰ３の実行後に更に複数のＯＰ４が並行して実行されたりする（例えば、ＰＩＤ「３０１」に対応する行が２つ見つかったために２つの行にそれぞれ対応した２つのＯＰ４が並行して実行されたりする）。Ｉ／Ｏ要求を発行する処理が必要となるＯＰが並行して実行されるため、複数のＩ／Ｏ要求が並行して発行される。これにより、例えば、生成されたタスク毎に読出し要求が発行され、その読出し要求に応答してデータが読み出されるまで該タスクの処理が中断しても、他の生成されたタスクは独立して実行されるので、クエリの実行それ自体が中断してしまうわけではない。以上の結果、従来に比べて、一つのクエリの実行に要する時間を短縮することができる。
【００５０】
また、上述した第一実施例によれば、タスクが無制限に生成されるわけではなく、現存するデータ取得待ちタスク数が所定値になったら、新たにタスクは生成されず、現存のデータ取得待ちタスク数が所定値未満になった場合に、新たなタスクの生成が行われる。これにより、ＤＢＭＳ５での処理によって消費されるコンピュータリソース（例えば、ＣＰＵ使用率、メモリ使用量等）の量を抑えることができる。
【実施例２】
【００５１】
以下、本発明の第二実施例を説明する。なお、その際、第一実施例との相違点を主に説明し、第一実施例との共通点については、重複した説明を省くために、説明を簡略或いは省略する。
【００５２】
図６は、本発明の第二実施例に係るシステムの構成例を示す。この図において、第一実施例と同一の要素については同一の番号を付してある。
【００５３】
この第二実施例では、ＤＢＭＳ５に、Ｉ／Ｏ最適化部２７が備えられる。この場合、クエリ実行部９は、ＯＳ１５にではなく、Ｉ／Ｏ最適化部２７にＩ／Ｏ要求を発行する。Ｉ／Ｏ最適化部２７は、クエリ実行部９から並行して発行された複数のＩ／Ｏ要求を受けて保持し、受け付けた複数のＩ／Ｏ要求の順序を、データ読出し時間長を最適化するための順序に変更し、変更後の順序で複数のＩ／Ｏ要求をＯＳ１５に発行することができる。
【００５４】
以下、この第二実施例について詳細に説明する。
【００５５】
図７Ａは、本発明の第二実施例で行われるデータ取得処理の流れの一例を示す。
【００５６】
この図７Ａにおいて、Ｓ３１、Ｓ３２、Ｓ３５及びＳ３６は、図４ＡのＳ１１−１、Ｓ１１−２、Ｓ１１−４及びＳ１１−５にそれぞれ対応している。相違点は、Ｓ３３及びＳ３４である。
【００５７】
Ｓ３３では、クエリ実行部９によって実行されている子タスクは、発行するＩ／Ｏ要求をスケジュール対象とするか否かを判断し、スケジュール対象とする場合に、スケジュールフラグを付与することを決定する。スケジュール対象とする場合とは、例えば、Ｉ／Ｏ要求をＯＳ１５に発行する緊急性が低い場合であり、そうではなく、その緊急性が高い場合には、スケジュール対象外となる。スケジュール対象とするか否かは、例えば、クエリプランの内容、又は、クエリの実行に求められる性能要件に応じて、決定することができる。前者の具体例では、当該子タスクが、クエリプランを参照し、当該子タスクに割り当てられているＯＰが或る段階よりも後段のＯＰであると認識された場合に、スケジュール対象外とし、そうではない場合には、スケジュール対象としても良い。後者の具体例では、当該子タスクは、意思決定支援システムなどの緊急性の低いアクセス特性を有するデータベースアクセスのためのＩ／Ｏ要求を発行する場合には、スケジュール対象とし、オンライントランザクションシステムなどの緊急性の高いアクセス特定を有するデータベースアクセスのためのＩ／Ｏ要求を発行する場合には、スケジュール対象外としてもよい。
【００５８】
Ｓ３３の後、当該子タスクは、Ｉ／Ｏ要求発行処理を実行する（Ｓ３４）。
【００５９】
図７Ｂは、Ｉ／Ｏ要求発行処理の流れの一例を示す。
【００６０】
子タスクは、スケジュールフラグを付与する場合（Ｓ３４−１で「有」）、スケジュール対象キューに、Ｉ／Ｏ要求を挿入し（Ｓ３４−２）、スケジュールフラグを付与しない場合（Ｓ３４−１で「無」）、スケジュール対象外キューに、Ｉ／Ｏ要求を挿入する。
【００６１】
ここで、スケジュール対象キュー及びスケジュール対象外キューとは、Ｉ／Ｏ最適化部２７が有するキューである。
【００６２】
図８は、Ｉ／Ｏ最適化部２７の説明図である。
【００６３】
Ｉ／Ｏ最適化部２７は、スケジュール対象外キュー６１Ａと、スケジュール対象キュー６１Ｂとを有する。スケジュール対象外キュー６１Ａの優先度（換言すれば、Ｉ／Ｏ要求の発行の緊急度）は、スケジュール対象キュー６１Ｂの優先度よりも高い。スケジュール対象外キュー６１Ａには、スケジュール対象外とされたＩ／Ｏ要求６３がクエリ実行部９によって格納され、スケジュール対象キュー６１Ｂには、スケジュール対象とされたＩ／Ｏ要求６３がクエリ実行部９によって格納される。
【００６４】
以下、図９Ａ、図９Ｂ、図１０Ａ及び図１０Ｂを参照して、Ｉ／Ｏ最適化部２７が行う処理の流れについて説明する。その際、適宜に、図８も参照する。
【００６５】
図９Ａは、Ｉ／Ｏ最適化部２７が行う処理の流れの一例を示す。
【００６６】
Ｉ／Ｏ最適化部２７は、条件１〜条件３のうちの少なくとも一つの条件にマッチするイベントが発生するのを待つ（Ｓ４１）。ここで、条件１とは、スケジュール対象外キュー６１ＡにＩ／Ｏ要求が格納されることである。条件２とは、スケジュールキャンセルコマンドの到着である。条件３とは、後述するバッチスケジューリング駆動条件の成立である。
【００６７】
上記の条件１〜条件３のうちの少なくとも一つの条件にマッチするイベントが発生した場合には、Ｉ／Ｏ最適化部２７は、発生したイベントがマッチする条件を判別し（Ｓ４２）、判別された条件に応じた処理を実行する。すなわち、Ｉ／Ｏ最適化部２７は、条件１であると判別された場合には、即時発行処理を実行し（Ｓ４３）、条件２であると判別された場合には、スケジュールキャンセル処理を実行し（Ｓ４４）、条件３であると判別された場合には、バッチスケジュール処理を実行する（Ｓ４５）。なお、複数の条件にマッチした場合には、例えば、Ｉ／Ｏ最適化部２７は、優先順位の高い条件に対応した処理を優先して実行することができる。例えば、条件１の方が条件３よりも優先順位が高い場合において、条件１及び条件３の両方にマッチしたイベントが発生した場合には、Ｉ／Ｏ最適化部２７は、条件１に対応した即時発行処理を、条件３に対応するバッチスケジュール処理よりも先に実行することができる。
【００６８】
図９Ｂは、即時発行処理の流れの一例を示す。
【００６９】
Ｉ／Ｏ最適化部２７は、スケジュール対象外キュー６１Ａから全てのＩ／Ｏ要求を取り出し（Ｓ４３−１）、取り出したＩ／Ｏ要求を、ＯＳ１５のシステムコールを用いて発行する（Ｓ４３−２）。これにより、外部記憶装置１９へとＩ／Ｏ要求が発行される。この即時発行処理は、スケジュール対象外キュー６１ＡにＩ／Ｏ要求が格納されていることがＩ／Ｏ最適化部２７によって検出される度に行われるので、後述のバッチスケジュール処理よりも、キューにおけるＩ／Ｏ要求の滞在時間が短い。
【００７０】
図１０Ａは、スケジュールキャンセル処理の流れの一例を示す。
【００７１】
Ｉ／Ｏ最適化部２７は、図８で点線で示すように、スケジュールキャンセルコマンドで指定されているＩ／Ｏ要求６３Ｔをスケジュール対象キュー６１Ｂから取得し（Ｓ４４−１）、取得されたＩ／Ｏ要求６３Ｔをスケジュール対象外キュー６１Ａに挿入する（Ｓ４４−２）。挿入する位置は、どこでも良い。例えば、スケジュール対象外キュー６１Ａに存在する一以上のＩ／Ｏ要求の最後尾であっても良いし、先頭であっても良いし、それらの間の任意の位置であっても良い。
【００７２】
図１０Ｂは、バッチスケジュール処理の流れの一例を示す。
【００７３】
このバッチスケジュール処理は、前述したように、バッチスケジューリング駆動条件が成立した場合に開始される。バッチスケジューリング駆動条件としては、例えば、直前回にバッチスケジュール処理が行われてから所定時間経過した、又は、スケジュール対象キュー６１Ｂの使用率が所定値以上になったという条件を採用することができる。
【００７４】
Ｉ／Ｏ最適化部２７は、スケジュール対象キュー６１Ｂに格納されている複数のＩ／Ｏ要求の順序を、それら複数のＩ／Ｏ要求のトータルのデータ読出し時間長を最適化するための順序に並び替える（Ｓ４５−１）。この並び替えは、例えば、前述したマッピング情報に基づいて行うことができる。具体的には、例えば、Ｉ／Ｏ最適化部２７は、各Ｉ／Ｏ要求毎のアクセス先ＬＢＡを特定し、外部記憶装置１９におけるディスクシーク時間長が最も短くなるような順序に並び替えることができる。なお、並び替えの対象は、例えば、バッチスケジュール処理が開始された時点でスケジュール対象キュー６１Ｂに存在するＩ／Ｏ要求とすることができる。この場合、バッチスケジュール処理を開始した後にスケジュール対象キュー６１ＢにＩ／Ｏ要求が入っても、そのＩ／Ｏ要求は、今回のバッチスケジュール処理では並び替えの対象とされず、次回以降のバッチスケジュール処理で、並び替えの対象とされることになる。
【００７５】
Ｉ／Ｏ最適化部２７は、スケジュール対象外キュー６１Ａが空か否かを判別し（Ｓ４５−２）、空あれば（Ｓ４５−２でＹＥＳ）、スケジュール対象キュー６１ＢにＩ／Ｏ要求があるか否かを判断し（Ｓ４５−３）、あれば（Ｓ４５−３で「あり」）、スケジュール対象キュー６１ＢからＩ／Ｏ要求を取り出し、取り出したＩ／Ｏ要求をＯＳ１５に発行する。Ｉ／Ｏ最適化部２７は、Ｓ４５−２において、スケジュール対象外キュー６１Ａが空でなければ（Ｓ４５−２でＮＯ）、スケジュール対象外キュー６１ＡにおけるＩ／Ｏ要求を優先して出すために、バッチスケジュール処理を一旦終え、図９ＡのＳ４１及びＳ４２を経てＳ４３の即時処理を実行することができる。
【００７６】
以上が、第二実施例についての説明である。この第二実施例によれば、クエリ実行部９から発行された複数のＩ／Ｏ要求が、クエリ実行部９から発行された順序で外部記憶装置１９に送信されるのではなく、一旦、蓄積され、蓄積された複数のＩ／Ｏ要求の順序が、Ｉ／Ｏ最適化部２７によって最適化されてから出力される。これにより、複数のＩ／Ｏ要求がクエリ実行部９から発行されてからクエリ実行部９にデータが読出されるまでの全体としての読出し時間長を短縮することができる。以下、この第二実施例で期待される効果について、第一実施例で期待される効果と比較して説明する。なお、以下の説明は、第一実施例と第二実施例の理解をより深めるためのものに過ぎず、以下の期待される効果を奏しないからといって、本願発明の技術的範囲から外れるものではない。故に、その説明で用いる図１１Ａ〜図１３Ｂは、必ずしも精密な記載にはなっていない。例えば、図１１Ｂ、図１２Ｂ及び図１３Ｂのディスクシークイメージの図において、横軸における単位距離が表す時間長は必ずしも同じではない。
【００７７】
例えば、第一実施例において、図１１Ａに例示するように、クエリ実行部９から、６つのＩ／Ｏ要求Ａ〜Ｆが発行されたとする。第一実施例では、Ｉ／Ｏ最適化部２７が存在しないので、ＤＢＭＳ５において、第二実施例のように、ＤＢＭＳ５内で、ＯＳ１５へ発行する複数のＩ／Ｏ要求Ａ〜Ｆの並び替えは行われない。この場合には、例えば、ＯＳ１５のカーネル、或いは、外部記憶装置１９の機能によって、Ｉ／Ｏ要求の並び替えが行われる場合がある。例えば、全Ｉ／Ｏ要求Ａ〜Ｆのうち、Ｉ／Ｏ要求Ａ〜ＣとＤ〜Ｆとの各グループ別に並び替えが行われる場合がある。全Ｉ／Ｏ要求Ａ〜Ｆではなく、グループ別に行われるのは、例えば、ＯＳ１５や外部記憶装置１９にとっては、どれだけの数のＩ／Ｏ要求が来るかわからないので、所定数或いは一定時間待って蓄積された段階でＩ／Ｏ要求の並び替えを行わないと、上位の装置或いはコンピュータプログラムを長く待たせてしまうことになるからである。図１１Ａの例では、ＯＳ１５又は外部記憶装置１９が、Ｉ／Ｏ要求Ａ〜Ｃまで受け付けた段階で、「Ａ→Ｂ→Ｃ」の順から「Ｂ→Ｃ→Ａ」の順に並び替えてデータ読出しを行う。次に、ＯＳ１５又は外部記憶装置１９が、次のＩ／Ｏ要求Ｄ〜Ｆまで受け付けた段階で、「Ｄ→Ｅ→Ｆ」の順から「Ｅ→Ｆ→Ｄ」の順に並び替えてデータ読出しを行う。この結果、図１１Ｂに例示するように、Ｉ／Ｏ要求Ａ〜Ｆに対応するデータの読み出しのためのディスクシーク時間長をある程度短縮化することができる（しかし、前述したようにＩ／Ｏ要求が並行して発行されるので、これでも、従来技術に比べれば、短縮化される）。
【００７８】
これに対し、第二実施例では、図１２Ａに例示するように、ＤＢＭＳ５内で、ＯＳ１５へ発行する複数のＩ／Ｏ要求Ａ〜Ｆの順序が最適化され、最適化後の順序で、Ｉ／Ｏ要求がＯＳ１５を介して外部記憶装置１９へと発行される。このため、図１２Ｂに例示するように、第一実施例に比べて、Ｉ／Ｏ要求Ａ〜Ｆに対応するデータの読み出しのためのディスクシーク時間長を短縮化することができる。なお、この第二実施例において、第一実施例のように、ＯＳ１５或いは外部記憶装置１９によってＩ／Ｏ要求の並び替えが行われたとしても、Ｉ／Ｏ最適化部２７によって並び返された順序と同じ順序になる可能性が大きいので、図１２Ａ及び図１２Ｂに例示の効果が期待される。
【００７９】
また、第二実施例において、例えば、バッチスケジュール処理によってＩ／Ｏ要求の発行順序が最適化された後に、スケジュール対象外のＩ／Ｏ要求が発行されて、そのＩ／Ｏ要求が優先的にＤＢＭＳ５から発行された場合には、Ｉ／Ｏ要求Ａ〜Ｆに対応するデータの読み出しのためのディスクシーク時間長は、図１３Ａ及び図１３Ｂに例示するように、即時発行が全く無い場合に比べて、長くなる可能性がある。しかし、それでも、少なくとも従来よりは、Ｉ／Ｏ要求Ａ〜Ｆに対応するデータの読み出しのためのディスクシーク時間長を短縮化することができる。なお、図１３Ａ、図１３Ｂにおいて、Ｉ／Ｏ最適化部２７は、Ｉ／Ｏ要求Ｅの即時発行が決まった場合、残りのＩ／Ｏ要求Ａ〜Ｄ及びＦの並び替えをやり直しても良い。
【実施例３】
【００８０】
以下、本発明の第三実施例について説明する。
【００８１】
この第三実施例では、クエリ実行部９は、第一実施例（又は第二実施例）において、複数のデータが読み出された場合、読み出された順にタスクの実行を再開していくのではなく、データ取得処理を開始した順に、タスクの実行を再開していく。タスクの実行を再開する順序を制御するための方法として、例えば、データ取得待ち表を用いる方法がある。
【００８２】
図１４Ａは、本発明の第三実施例におけるデータ取得待ち表の構成例を示す。
【００８３】
データ取得待ち表７１は、データベースサーバ１の記憶資源に記憶される情報である。データ取得待ち表７１は、複数の待ち情報７１Ｒ、７１Ｒ、…から構成される。待ち情報７１Ｒは、データ取得順序番号とタスクＩＤとで構成される。データ取得順序番号は、データ取得処理を開始する順序を表した番号である。タスクＩＤは、待ち情報７１Ｒを記述したタスクのＩＤである。
【００８４】
図１４Ｂは、生成された子タスクが第一実施例で行う処理との第一の相違部分を示す。
【００８５】
生成された子タスクは、データ取得処理を実行する前に、データ取得待ち表７１に、自分に対応した待ち情報を挿入する（Ｓ６１）。具体的には、当該子タスクは、自分に対応した待ち情報７１Ｒとして、図３のＳ１１のデータ取得処理を開始する順番であるデータ取得順序番号と、自分のタスクのＩＤとを、データ取得待ち表７１に挿入する。
【００８６】
図１４Ｃは、生成された子タスクが第一実施例で行う処理との第二の相違部分を示す。
【００８７】
当該子タスクは、データ取得処理によってデータが取得された場合、データ取得待ち表７１を検索し、自タスクが最も古い待ちタスクとなるまで待ち、そうなった後、データ取得待ち表７１から、Ｓ６１で自分が挿入した待ち情報７１Ｒを削除する（Ｓ６２）。なお、最も古い待ちタスクになったかどうかは、データ取得待ち表７１に記入されているデータ取得順序番号の中で、自分が挿入した待ち情報７１Ｒ中のデータ取得順序番号が若い番号かどうかを判別することにより、特定することができる。なお、別法として、例えば、データ取得待ち表７１Ｒが、待ち行列であって、自分が書いた待ち情報７１Ｒが先頭アドレスになったときに、自タスクが最も古い待ちタスクであると判別しても良い。
【００８８】
以上の処理により、生成された複数の子タスクは、データ取得処理によってデータ待ちとなった場合、データが取得された順に実行の再開となるのではなく、データ取得処理を開始した順に、実行の再開となる。具体的には、例えば、図１５Ａに例示するように、データ取得処理の開始順序と同じ順序でＩ／Ｏ要求Ａ〜Ｆが発行された場合、その順序と違って、例えば、Ｉ／Ｏ要求Ａに対応したデータＡよりも先に、Ｉ／Ｏ要求Ｂ、Ｃの応答としてデータＢ、Ｃが取得されたとしても、データＢ、Ｃを処理するタスクＢ、Ｃの実行の再開は待ちとなり、データＡが取得されてそれを処理するタスクＡの実行が再開された後に、タスクＢ、Ｃの順序で実行が再開される（なお、ディスクシークイメージとしては、図１５Ｂに例示する通りであり、例えば第一実施例と同じである）。このように、この第三実施例では、各タスクの実行を、データ取得処理の開始順序と同じ順序で再開していくことができる。
【００８９】
以上、本発明の好適な幾つかの実施例を説明したが、本発明は、それらの実施例に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【００９０】
例えば、第二実施例において、Ｉ／Ｏ最適化部２７は、別種の所定のキャンセルコマンドを受け付けた場合には、そのキャンセルコマンドで指定されているＩ／Ｏ要求、又は、スケジュール対象外キュー６１Ａに残っている全てのＩ／Ｏ要求を、スケジュール対象外キュー６１Ａから取り出し、取り出されたＩ／Ｏ要求を、スケジュール対象キュー６１Ｂに格納してもよい。
【００９１】
また、例えば、各実施例において、ＤＢＭＳ５の処理は、それを読込んだプロセッサによって実行することができる。具体的には、例えば、親タスクを実行するプロセッサは、データベースサーバ１の記憶資源（例えばメモリ）上に子タスクを生成し、その子タスクを読込んで実行することにより、例えば図３のＳ１１以降の処理を実行することができる。
【００９２】
また、例えば、実行タスク管理部１３が、所定のタイミングで、クエリプランに基づいて、残存ステップ数（例えば、最後のＯＰまでに残っているＯＰの数）を計算し、残存ステップ数の少ないタスクの優先度を上げても良い。この場合、例えば、図３のＳ２、Ｓ３の処理によって、優先度が上げられたタスクを優先的に生成することができる。また、そのタスクは、自分の優先度が高いので、Ｉ／Ｏ要求を発行する場合、スケジュール対象外キュー６１Ａに、発行したＩ／Ｏ要求を挿入することができる。
【００９３】
また、例えば、第二実施例において、スケジュール対象とスケジュール対象外との二種類のキューではなく、三以上の優先度の異なるキューが用意されても良い。その場合、クエリ実行部９は、Ｉ／Ｏ要求の優先度に応じた値のスケジュールフラグを決定し、その決定されたスケジュールフラグ値に応じたキューに、Ｉ／Ｏ要求を格納してもよい。
【００９４】
また、例えば、第二実施例において、Ｉ／Ｏ最適化部２７は、ＤＢＭＳ５の外に存在しても良い。具体的には、例えば、Ｉ／Ｏ最適化部２７は、ＤＢＭＳ５とＯＳ１５との間に介在しても良い。Ｉ／Ｏ最適化部２７は、ＤＢＭＳ５から発行された複数のＩ／Ｏ要求を受け付けることができる。また、Ｉ／Ｏ最適化部２７は、ＡＰ３からもＩ／Ｏ要求をうつけても良い。Ｉ／Ｏ最適化部２７は、受け付けた複数のＩ／Ｏ要求（発行元はＤＢＭＳ５又はＡＰ３）を、受け付けた順序と異なる順序に並び替え、並び替え後の順序でＩ／Ｏ要求をＯＳ１５に発行することができる。
【００９５】
また、例えば、データベース管理システムは、一つのコンピュータマシン上に構築されてもよいし、複数のコンピュータマシン上に構築されても良い。具体的には、例えば、各実施例にけるＤＢＭＳ５の処理は複数のコンピュータ上で並列に動作する並列ＤＢＭＳにおいても同様に適用することができる。並列ＤＢＭＳでは、クエリ生成部でクエリプランを生成した後、処理を複数のＤＢＭＳサーバに割り当てる。そのため、各ＤＢＭＳサーバにおいて、本発明の技術を用いて、割り当てられた処理を複数のタスクを生成しながらＩ／Ｏ要求を並列に処理することで、問合せの実行時間の短縮を図ることが可能である。
【符号の説明】
【００９６】
１…データベースサーバ ３…アプリケーションプログラム ５…データベース管理システム ７…クエリ受付部 ９…クエリ実行部 １１…クエリプラン生成部 １２…データベースバッファ １３…実行タスク管理部 １５…オペレーティングシステム １７…通信ネットワーク １９…外部記憶装置 ２１…データベース ２３…表 ２５…索引 ２７…Ｉ／Ｏ最適化部 ６１Ａ…スケジュール対象外キュー ６１Ｂ…スケジュール対象キュー ６３…Ｉ／Ｏ要求
【特許請求の範囲】
【請求項１】
クエリを受け付けるクエリ受付部と、
前記受け付けたクエリを実行し、その際、必要に応じて、記憶装置からデータベースのデータを読み出すためのデータ読出し要求を発行するクエリ実行部と
を備え、
前記クエリ実行部は、
動的にタスクを生成していき、生成された複数のタスクを並行して実行するようになっており、
各タスクの実行において、前記データベースのデータを必要とする都度に、そのデータを取得するためのタスクを生成し、
該生成されたタスクの実行において、必要に応じて、前記データベースからデータを読み出すための前記データ読出し要求を発行する、
データベース管理システム。
【請求項２】
前記クエリ実行部は、所定の状況にあるタスクの現存数が所定数に達している場合には、新たなタスクの生成を待ち、前記現存数が減った場合に、前記新たなタスクを生成する、
請求項１記載のデータベース管理システム。
【請求項３】
前記クエリ実行部から発行された複数個のデータ読出し要求を受け付け、受け付けた複数個のデータ読出し要求を、前記複数個のデータ読出し要求を受け付けた順序とは異なる、全体としてのデータ読出し時間長を短縮化するための順序で発行する読出し順序制御部を更に備える、
請求項１記載のデータベース管理システム。
【請求項４】
優先度の異なる複数のキューを更に備え、
前記クエリ実行部が、前記生成されたタスクの実行により、前記複数のキューのうち、所定の条件に適合する優先度に対応したキューに、前記データ読出し要求を格納し、
前記読出し順序制御部は、優先度の高いキューに格納されているデータ読出し要求ほど優先的に発行する、
請求項３記載のデータベース管理システム。
【請求項５】
前記読出し順序制御部は、所定のコマンドを受け付けた場合には、或る優先度のキューに格納されている少なくとも一つの読出し要求を別の優先度のキューに移動させる、
請求項４記載のデータベース管理システム。
【請求項６】
前記クエリ実行部は、前記受け付けたクエリの実行プランの内容、又は、前記受け付けたクエリの実行に求められる性能要件に応じて、どの優先度のキューに読出し要求を格納するかを決定する、
請求項４記載のデータベース管理システム。
【請求項７】
クエリ実行プランに基づいて残存ステップ数を計算し、前記計算された残存ステップ数の少ないタスクの優先度を上げるタスク管理部を更に備え、
前記クエリ実行部が、優先度の上がったタスクを実行することにより発行される読出し要求を、該優先度に対応するキューに格納する、
請求項４記載のデータベース管理システム。
【請求項８】
前記クエリ実行部は、生成された各タスクの実行において、前記データベースのデータの取得を待ち、該データを取得した後、データの取得待ちを開始した順序と同じ順序で、タスクの実行を再開する、
請求項１又は３記載のデータベース管理システム。
【請求項９】
クエリを受け付けるステップと、
前記受け付けたクエリを実行し、その際、必要に応じて、記憶装置からデータベースのデータを読み出すためのデータ読出し要求を発行するクエリ実行ステップと
を有し
前記クエリ実行ステップでは、
動的にタスクを生成していき、生成された複数のタスクを並行して実行し、
各タスクの実行において、前記データベースのデータを必要とする都度に、そのデータを取得するためのタスクを生成し、
該生成されたタスクの実行において、必要に応じて、前記データベースからデータを読み出すための前記データ読出し要求を発行する、
データベース管理方法。
【請求項１０】
請求項１記載のデータベース管理システムと、
前記データベース管理システムから発行された複数個のデータ読出し要求を受け付け、受け付けた複数個のデータ読出し要求を、前記複数個のデータ読出し要求を受け付けた順序とは異なる、全体としてのデータ読出し時間長を短縮化するための順序で発行する読出し順序制御部と
を備えるコンピュータシステム。
【請求項１】
クエリを受け付けるクエリ受付部と、
前記受け付けたクエリを実行し、その際、必要に応じて、記憶装置からデータベースのデータを読み出すためのデータ読出し要求を発行するクエリ実行部と
を備え、
前記クエリ実行部は、
動的にタスクを生成していき、生成された複数のタスクを並行して実行するようになっており、
各タスクの実行において、前記データベースのデータを必要とする都度に、そのデータを取得するためのタスクを生成し、
該生成されたタスクの実行において、必要に応じて、前記データベースからデータを読み出すための前記データ読出し要求を発行する、
データベース管理システム。
【請求項２】
前記クエリ実行部は、所定の状況にあるタスクの現存数が所定数に達している場合には、新たなタスクの生成を待ち、前記現存数が減った場合に、前記新たなタスクを生成する、
請求項１記載のデータベース管理システム。
【請求項３】
前記クエリ実行部から発行された複数個のデータ読出し要求を受け付け、受け付けた複数個のデータ読出し要求を、前記複数個のデータ読出し要求を受け付けた順序とは異なる、全体としてのデータ読出し時間長を短縮化するための順序で発行する読出し順序制御部を更に備える、
請求項１記載のデータベース管理システム。
【請求項４】
優先度の異なる複数のキューを更に備え、
前記クエリ実行部が、前記生成されたタスクの実行により、前記複数のキューのうち、所定の条件に適合する優先度に対応したキューに、前記データ読出し要求を格納し、
前記読出し順序制御部は、優先度の高いキューに格納されているデータ読出し要求ほど優先的に発行する、
請求項３記載のデータベース管理システム。
【請求項５】
前記読出し順序制御部は、所定のコマンドを受け付けた場合には、或る優先度のキューに格納されている少なくとも一つの読出し要求を別の優先度のキューに移動させる、
請求項４記載のデータベース管理システム。
【請求項６】
前記クエリ実行部は、前記受け付けたクエリの実行プランの内容、又は、前記受け付けたクエリの実行に求められる性能要件に応じて、どの優先度のキューに読出し要求を格納するかを決定する、
請求項４記載のデータベース管理システム。
【請求項７】
クエリ実行プランに基づいて残存ステップ数を計算し、前記計算された残存ステップ数の少ないタスクの優先度を上げるタスク管理部を更に備え、
前記クエリ実行部が、優先度の上がったタスクを実行することにより発行される読出し要求を、該優先度に対応するキューに格納する、
請求項４記載のデータベース管理システム。
【請求項８】
前記クエリ実行部は、生成された各タスクの実行において、前記データベースのデータの取得を待ち、該データを取得した後、データの取得待ちを開始した順序と同じ順序で、タスクの実行を再開する、
請求項１又は３記載のデータベース管理システム。
【請求項９】
クエリを受け付けるステップと、
前記受け付けたクエリを実行し、その際、必要に応じて、記憶装置からデータベースのデータを読み出すためのデータ読出し要求を発行するクエリ実行ステップと
を有し
前記クエリ実行ステップでは、
動的にタスクを生成していき、生成された複数のタスクを並行して実行し、
各タスクの実行において、前記データベースのデータを必要とする都度に、そのデータを取得するためのタスクを生成し、
該生成されたタスクの実行において、必要に応じて、前記データベースからデータを読み出すための前記データ読出し要求を発行する、
データベース管理方法。
【請求項１０】
請求項１記載のデータベース管理システムと、
前記データベース管理システムから発行された複数個のデータ読出し要求を受け付け、受け付けた複数個のデータ読出し要求を、前記複数個のデータ読出し要求を受け付けた順序とは異なる、全体としてのデータ読出し時間長を短縮化するための順序で発行する読出し順序制御部と
を備えるコンピュータシステム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図１０】
【図１１】
【図１２】
【図１３】
【図１４】
【図１５】
【公開番号】特開２０１１−３４５７５（Ｐ２０１１−３４５７５Ａ）
【公開日】平成２３年２月１７日（２０１１．２．１７）
【国際特許分類】
【出願番号】特願２０１０−２１４２３９（Ｐ２０１０−２１４２３９）
【出願日】平成２２年９月２４日（２０１０．９．２４）
【分割の表示】特願２００５−２１３０９０（Ｐ２００５−２１３０９０）の分割
【原出願日】平成１７年７月２２日（２００５．７．２２）
【出願人】（０００１５８７０３）
【Ｆターム（参考）】
【公開日】平成２３年２月１７日（２０１１．２．１７）
【国際特許分類】
【出願日】平成２２年９月２４日（２０１０．９．２４）
【分割の表示】特願２００５−２１３０９０（Ｐ２００５−２１３０９０）の分割
【原出願日】平成１７年７月２２日（２００５．７．２２）
【出願人】（０００１５８７０３）
【Ｆターム（参考）】
[ Back to top ]