JP6210501B2 - データベース管理システム、計算機、データベース管理方法 - Google Patents

Description

本発明は、概して、処理要求の処理に関し、例えば、データベース管理技術に関する。

企業活動において、大量に生じる業務データの活用は不可欠になっている。そのため、大量の業務データを蓄積したデータベースを解析処理するシステムが既に考案されている。この解析処理において、データベース管理システム（以下、ＤＢＭＳ）は、クエリを受け付け、データベース（以下、ＤＢ）を格納するストレージ装置にデータ読出し要求を発行する。１つのクエリの実行におけるデータ読出しの待ち時間の短縮化を図る技術として、特許文献１に開示の技術が知られている。特許文献１によれば、ＤＢＭＳは、クエリ実行に要するデータ読出しの都度にタスクを動的に生成し並行実行することでデータ読出し要求を多重化する。タスクの実行では、システム性能の上限の一部が発揮される。「システム性能」とは、ＤＢＭＳを含んだ計算機の性能を含み、更に、その計算機と他の装置とを含んだ計算機システムの性能を含んでもよい。

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

システム性能としては、例えば、ＣＰＵ（Central Processing Unit）性能と、Ｉ／Ｏ性能とがある。特許文献１によれば、ＤＢＭＳは、１つのクエリを実行する際に、タスクを動的に生成し並行実行することで、データ読出し要求を多重化する。タスクの並行実行により、ＣＰＵ性能をその上限まで発揮でき、データ読出し要求の多重化により、Ｉ／Ｏ性能をその上限まで発揮できる。

しかし、１つのクエリの処理において必ずしもシステム性能がその上限まで発揮されているわけではない。

このような問題は、クエリを処理するＤＢＭＳに限らず、クエリのような処理要求を処理する他のコンピュータプログラム或いは計算機システム等のシステムについても存在し得る。

ＤＢＭＳが、ＤＢＭＳの実行状態に基づいて、実行中のクエリの実行により発揮される性能である発揮性能が或る時点以降継続して所定の条件を満たすか否かを判定する。その判定の結果の真の場合、実行待ちのクエリがあれば、ＤＢＭＳは、実行中のクエリの実行終了前に、実行待ちのクエリの実行を開始する。

システム性能をなるべくその上限まで発揮することができる。

実施例１にかかる計算機システムの構成を示す。 実施例１にかかる第１のクエリの一例である。 実施例１にかかる第２のクエリの一例である。 実施例１にかかる第１のクエリのクエリ実行プランの一例を示す。 実施例１にかかるクエリ実行プラン情報の一例を示す。 実施例１にかかるＤＢＭＳの実行状態の管理の一例を示す。 実施例１にかかるクエリ実行開始判定の流れを示すフローチャートである。 実施例１にかかるテールフェーズ判定の流れを示すフローチャートである。 実施例１にかかる性能余力判定の流れを示すフローチャートである。 実施例２にかかるＤＢＭＳの実行状態の管理の一例を示す。 実施例２にかかるテールフェーズ判定の流れを示すフローチャートである。 実施例３にかかる計算機システムの構成を示す。

以下、図面を参照しながら、幾つかの実施例を説明する。データベース管理システム（以下、ＤＢＭＳ）へのクエリの発行元としては、ＤＢＭＳの内部のコンピュータプログラムであってよく、もしくは、外部のコンピュータプログラムであってよい。例えば、クエリ発行元は、ＤＢＭＳを有するデータベースサーバ（以下、ＤＢサーバ）内で実行されるコンピュータプログラム（例えばアプリケーションプログラム）であってもよいし、ＤＢサーバに接続されたクライアント計算機等の装置で実行されるコンピュータプログラム（例えば、アプリケーションプログラム）であってもよい。

図１は、実施例１にかかる計算機システムの構成を示す。

ＤＢサーバ１０１は、計算機の一例であって、例えば、パーソナルコンピュータ、ワークステーションまたはメインフレームであってよく、もしくは、これらの計算機において仮想化プログラムによって構成された仮想的な計算機であってよい。ＤＢサーバ１０１は、ネットワークアダプタ１１５、メモリ１０２、ストレージ装置１１７およびそれらに接続されたＣＰＵ１１６を有する。ＣＰＵ１１６は、コンピュータプログラムを実行する。ＣＰＵ１１６により実行されるコンピュータプログラムは、例えば、オペレーティングシステム（以下、ＯＳ）１１４、ＤＢＭＳ１０４、ＤＢＭＳ１０４にクエリを発行するアプリケーションプログラム１０３である。メモリ１０２は、例えば、揮発性のＤＲＡＭ（Dynamic Random-Access Memory）等であり、ＣＰＵ１１６によって実行されるプログラムと、プログラムが使用するデータを一時的に記憶する。ストレージ装置１１７は、例えば、不揮発性の磁気ディスク、フラッシュメモリ等であり、プログラムおよびプログラムが使用するデータを格納する。ネットワークアダプタ１１５は、通信ネットワーク４０３とＤＢサーバ１０１を接続する。アプリケーションプログラム１０３は、ＤＢサーバ１０１ではなく、通信ネットワーク４０３に接続される別の計算機（図示しない）で動作するものであってもよい。ＣＰＵ１１６は、ネットワークアダプタ１１５およびメモリ１０２等に接続されたプロセッサの一例でよい。

ＤＢサーバ１０１は、性能や冗長性を高めるために、ＣＰＵ１１６、メモリ１０２、ストレージ装置１１７およびネットワークアダプタ１１５の少なくとも１つの要素を複数有してもよい。ＤＢサーバ１０１は、キーボードやポインティングデバイス等の入力デバイス（図示しない）と液晶ディスプレイ等の出力デバイス（図示しない）を有してもよい。入力デバイスおよび出力デバイス（例えば表示デバイス）は、ＣＰＵ１１６に接続されていてよい。入力デバイスと出力デバイスは一体であってもよい。

ＤＢサーバ１０１では、ＤＢＭＳ１０４がアプリケーションプログラム１０３から発行されたクエリを実行し、そのクエリの実行において、データベース（以下、ＤＢ）１２２からデータを読み込むために、もしくは、ＤＢ１２２にデータを書き込むために、そのＤＢ１２２を格納する外部ストレージ装置１１８に対する入出力要求をＯＳ１１４に発行する。ＯＳ１１４は、その入出力要求を受け付け、外部ストレージ装置１１８へ入出力要求を発行する。

外部ストレージ装置１１８は、複数の記憶デバイスを含む記憶デバイス群１２１を有する装置であり、例えば、ディスクアレイ装置であるが、それに代えて、単一の記憶デバイスであってもよい。外部ストレージ装置１１８は、ＤＢ１２２を記憶するが、ＤＢ１２２のデータに加えて、プログラムを記憶してもよい。外部ストレージ装置１１８は、ＤＢサーバ１０１から入出力要求を受け付け、その入出力要求に従いデータの読み書きを行い、その結果をＤＢサーバ１０１に返す。

外部ストレージ装置１１８は、記憶デバイス群１２１に加えて、ネットワークアダプタ１１９およびこれらに接続されたストレージコントローラ１２０を有する。

ネットワークアダプタ１１９は、外部ストレージ装置１１８を通信ネットワーク４０３に接続し、これを介して、ＤＢサーバ１０１と接続される。通信ネットワーク４０３を介した通信プロトコルとしては、例えば、ファイバチャネル（ＦＣ）、ＳＣＳＩ（Small Computer System Interface）、または、ＴＣＰ／ＩＰ（Transmission Control Protocol／Internet Protocol）が採用されてよい。例えば、ファイバチャネルもしくはＳＣＳＩが採用される場合、ＤＢサーバ１０１のネットワークアダプタ１１５および外部ストレージ装置１１８のネットワークアダプタ１１９は、ホストバスアダプタと呼ばれることがある。

記憶デバイス群１２１が有する記憶デバイスは、不揮発性の記憶媒体を有するデバイスであって、例えば、磁気ディスクドライブ、フラッシュメモリドライブ、その他半導体メモリドライブである。記憶デバイス群１２１は、ＲＡＩＤ（Redundant Array of Independent Disks）機構を有し、所定のＲＡＩＤレベルでデータを記憶してもよい。記憶デバイス群１２１の記憶空間に基づく論理的な記憶デバイス（例えば、論理ユニット、論理ボリューム、ファイルシステムボリューム）が、ＤＢサーバ１０１に提供され、その論理的な記憶デバイス上にＤＢ１２２が格納されてもよい。

ストレージコントローラ１２０は、例えば、メモリおよびプロセッサを含み、ＤＢサーバ１０１からの入出力要求に応じて、ＤＢ１２２を格納した記憶デバイス群１２１との間でデータの読込み、もしくは、書込みを行う。例えば、ストレージコントローラ１２０は、ＤＢサーバ１０１から、データの読出し要求を受け付けると、その要求に従って記憶デバイス群１２１からデータを読み出し、読み出したデータをＤＢサーバ１０１に返す。

外部ストレージ装置１１８は、性能や冗長性を高めるために、ストレージコントローラ１２０等の構成要素を複数有してもよい。

ＤＢＭＳ１０４は、ＤＢ１２２を管理する。ＤＢ１２２は、１以上の表１２４を含み、更に１以上の索引１２３を含んでよい。表１２４は、１以上のレコードの集合であり、レコードは１以上のカラムから構成される。索引１２３は、表１２４の１以上のカラム等を対象として作成されるデータ構造であり、その索引１２３が対象とするカラム等を含む選択条件による表１２４へのアクセスを高速化するためのものである。例えば、表１２４は、対象とするカラムの値の毎に、表１２４の中でその値を含むレコードを特定するための情報を保持するデータ構造である。データ構造としては、例えばＢ木等が用いられる。レコードを特定するための情報としては、物理アドレスや論理的な行ＩＤ等が用いられることがある。

ＤＢＭＳ１０４は、クエリ受付部１０５、実行待ちクエリ管理部１０６、クエリ実行プラン生成部１０７、クエリ実行部１０８および実行クエリ制御部１１０を有する。

クエリ受付部１０５は、アプリケーションプログラム１０３が発行するクエリを受け付ける。クエリは、例えば、ＳＱＬによって記述される。クエリ受付部１０５は、クエリを受け付ける都度に、クエリを受け付けたことを、実行待ちクエリ管理部１０６に伝える。第１のクエリの一例を図２に示し、第２のクエリの一例を図３に示す。

実行クエリ待ちクエリ管理部１０６は、クエリ受付部１０５が受け付けた１以上のクエリの各々について、実行待ちか否かを管理する。なお、「実行待ちのクエリ」とは、典型的には、未実行のクエリ（一度も実行開始とされていないクエリ）であるが、未実行のクエリに加えて、実行が一時中断とされているクエリであってもよい。

クエリ実行プラン生成部１０７は、クエリ受付部１０５が受け付けたクエリから、そのクエリを実行するために必要な１以上のＤＢオペレーションを含むクエリ実行プランを生成する。クエリ実行プランは、例えば、１以上のＤＢオペレーションと、ＤＢオペレーションの実行順序の関係を含む情報である。クエリ実行プランは、ＤＢオペレーションをノード、ＤＢオペレーションの実行順序の関係をエッジとする木構造で表されることがある。クエリ実行プランは、クエリが受け付けられたときにそのクエリについて生成されてもよいし、クエリが受け付けられたときにはそのクエリについて生成されずクエリが実行待ちから実行開始とされたときにそのクエリについて生成されてもよい。

クエリ実行部１０８は、クエリ実行プラン生成部１０７が生成したクエリ実行プランに従って、実行クエリ制御部１１０により実行開始とされたクエリを実行する。クエリ実行部１０８は、クエリの実行において、ＤＢオペレーションを実行するためのタスクを動的に生成し、動的に生成されたタスクを実行し、２以上の実行可能なタスクが存在する場合には、それら２以上のタスクのうちの少なくとも２つのタスクを並行して実行することで、データ読出し要求を多重化して発行することができる。クエリ実行部１０８は、特許文献１に記載の技術が適用されたクエリ実行部でよい。具体的には、クエリ実行部１０８は、（ａ）ＤＢオペレーションを実行するためのタスクを生成し、（ｂ）生成されたタスクを実行することで、そのタスクに対応したＤＢオペレーションに必要なデータの読出し要求を発行し、（ｃ）（ｂ）で実行されたタスクに対応したＤＢオペレーションの実行結果に基づき別のＤＢオペレーションを実行する必要がある場合には、その別のＤＢオペレーションをそれぞれ実行する１以上のタスクを新たに生成し、（ｄ）その新たに生成した１以上のタスクのそれぞれについて（ｂ）および（ｃ）を行ってよい。また、クエリ実行部１０８は、このようにして生成された１以上のタスクを並行して実行してよい。クエリ実行部１０８は、２以上の実行可能なタスクが存在する場合には、それら２以上のタスクのうちの少なくとも２つのタスクを並行して実行してよい。クエリ実行部１０８は、一のタスクで複数のＤＢオペレーションを実行してもよい。また、クエリ実行部１０８は、都度に新たにタスクを生成することはせず、同じタスクにおいて次のＤＢオペレーションを実行してもよい。タスクの実装としては、例えば、ＯＳ１１４が実現するプロセスやカーネルスレッド等のほか、ライブラリ等が実現するユーザスレッドを用いてよい。

クエリ実行部１０８は、コンテキスト管理部１０９を有する。コンテキスト管理部１０９は、タスクにおいて実行を行う内容を示す情報のコンテキストを管理する。例えば、クエリ実行部１０８は、クエリ実行プランに従って、コンテキストを動的に生成し、且つ、そのコンテキストに基づいてタスクを実行することで、クエリ実行プラン内のＤＢオペレーションを実行する。コンテキスト管理部１０９は、コンテキストを管理する。コンテキストは、例えば、データアドレス集合が記憶されている外部ストレージ装置１１８の記憶デバイス群１２１におけるページを特定する情報（例えば、ページＩＤ）、データアドレス集合に格納されたエントリのうち次に実行開始されるタスクによりアクセスするエントリを示す情報、さらにタスク実行によりアクセスするエントリの残数（タスク生成可能数）を格納してよい。コンテキスト管理部１０９は、コンテキストが生成される都度に、そのコンテキストを管理対象に追加し、コンテキストが削除される都度に、そのコンテキストを管理対象から削除してよい。

実行クエリ制御部１１０は、ＤＢＭＳ１０４の実行状態に基づいて、実行中のクエリの実行を継続することにより発揮される性能である発揮性能が或る時点以降継続して所定の条件を満たすか否かを判定する。その判定の結果の真の場合、実行待ちのクエリがあれば、実行クエリ制御部１１０は、実行中のクエリの実行終了前に、実行待ちのクエリの実行を開始する。具体的には、実行クエリ制御部１１０は、クエリ実行開始制御部１１１を有する。クエリ実行開始制御部１１１は、クエリ実行開始するか否かを判定する。実行クエリ制御部１１０は、クエリ実行開始制御部１１１がクエリ実行開始と判定した場合に、実行待ちクエリ管理部１０６が管理する実行待ちのクエリを特定し（例えば実行待ちクエリを取得し）、特定したクエリをクエリ実行部１０８に伝える（例えば取得したクエリをクエリ実行部１０８に渡す）。クエリ実行開始制御部１１１は、実行情報取得部１１２と、サーバ性能取得部１１３とを有する。実行情報取得部１１２およびサーバ性能取得部１１３については、それぞれ後述する。

上述したクエリ受付部１０５、実行待ちクエリ管理部１０６、クエリ実行プラン生成部１０７、クエリ実行部１０８および実行クエリ制御部１１０は、ＤＢＭＳ１０４がＣＰＵ１１６で実行されることによって実現されるが、これらのうち、少なくとも一の構成要素が行う処理の少なくとも一部が、ハードウェアによって実現されていてもよい。ＤＢＭＳ１０４をはじめとするコンピュータプログラムは、プログラムソースからＤＢサーバ１０１にインストールされていてもよい。プログラムソースは、例えば、ＤＢサーバ１０１が読み取り可能な記憶媒体であってもよい。

図１に示すＤＢＭＳ１０４の構成は一例に過ぎない。例えば、ある構成要素は複数の構成要素に分割されていてもよく、複数の構成要素が１つの構成要素に統合されていてもよい。

図４Ａは、図２に示した第１のクエリのクエリ実行プランの一例を示す。

クエリ実行プラン生成部１０７は、図２に示した第１のクエリから、図４Ａに示すクエリ実行プランを生成する。図４Ａの例によれば、２つの結合オペレーションがある。各結合オペレーションは、ネステッドループ結合である。具体的には、Ｐａｒｔ表からの抽出結果を外表（結合元）としＬｉｎｅｉｔｅｍ表からの抽出結果を内表（結合先）とする第１のネステッドループ結合と、第１のネステッドループ結合の結果を外表としＯｒｄｅｒｓ表からの抽出結果を内表とする第２のネステッドループ結合とがある。

クエリ実行部１０８は、図４Ａのクエリ実行プランに従って、まず、ｐ＿ｔｙｐｅ索引を用いて、ｐ＿ｔｙｐｅが「ＥＣＯＮＯＭＹ ＡＮＯＤＩＺＥＤ ＳＴＥＥＬ」に合致するｐａｒｔ表レコードの格納位置を取得し、取得した格納位置に格納されているｐａｒｔ表レコードをｐａｒｔ表から読み出す。次に、クエリ実行部１０８は、ｌ＿ｐａｒｔｋｅｙ索引を用いて、上記読み出したｐａｒｔ表レコードのｐ＿ｐａｒｔｋｅｙにｌ＿ｐａｒｔｋｅｙが合致するｌｉｎｅｉｔｅｍ表レコードの格納位置を取得し、取得した格納位置に格納されているｌｉｎｅｉｔｅｍ表レコードをｌｉｎｅｉｔｅｍ表から読み出す。次に、クエリ実行部１０８は、ｏ＿ｏｒｄｅｒｋｅｙ索引を用いて、上記読み出したｌｉｎｅｉｔｅｍ表レコードのｌ＿ｏｒｄｅｒｋｅｙにｏ＿ｏｒｄｅｒｋｅｙが合致するｏｒｄｅｒｓ表レコードの格納位置を取得し、取得した格納位置に格納されているｏｒｄｅｒｓ表レコードをｏｒｄｅｒｓ表から読み出す。最後に、クエリ実行部１０８は、読み出した全てのレコードを突き合わせてｐ＿ｎａｍｅ毎にｔｏｔａｌ＿ｐｒｏｆｉｔを集計し、生成した集計結果をｔｏｔａｌ＿ｐｒｏｆｉｔの値に基づいてソートする。

なお、クエリ実行プラン生成部１０７は、クエリ実行プランの生成の際に、結合オペレーション毎に、推定結合率を算出し、算出された推定結合率を、対応する結合オペレーションに関連付ける。結合オペレーションにおいて、「結合率」とは、結合元の件数に対する結合結果の件数の倍率である。例えば、結合率＝２の場合、結合元の件数に対し、結合結果の件数が２倍になることを示す。「推定結合率」とは、結合率の推定値である。例えば、結合元の件数に対し結合先の件数が２倍であるとき、推定結合率＝２と推定する。推定結合率の算出は、クエリ実行プラン生成部１０７に代えて、クエリ実行プラン生成部１０７以外の要素（例えば実行情報取得部１１２）が行ってもよい。また、推定結合率の算出は、クエリ実行プラン生成の際に行われてもよいし、クエリ実行開始の際に行われてもよい。

図４Ｂは、クエリ実行プラン情報の一例を示す。

クエリ実行プラン情報は、ＤＢＭＳ１０４に含まれる情報の一部である。クエリ実行プラン生成部１０７により生成されたクエリ実行プランは、図４Ａに例示したように、１以上のデータベースオペレーションと、データベースオペレーションの実行順序の関係を含む情報であり、クエリ実行プラン情報に格納される。クエリ実行プラン情報は、実行プラン情報と、実行状態情報とを含む。実行プラン情報は、クエリ実行プランの構成を表す情報であり、例えば、ＤＢオペレーション毎に、「Ｏｐｅｒａｔｉｏｎ」（例えば、ＤＢオペレーションの名称）、「Ｓｏｒｕｃｅ １」（外表又は前段のＤＢオペレーションを表す情報）、「Ｓｏｒｕｃｅ ２」（内表又は別の前段のＤＢオペレーションを表す情報）、および「Ｃｏｎｄｉｔｉｏｎ」（条件を表す情報）を含む。実行状態情報は、各ＤＢオペレーションの実行状態と確保されているワーク領域のアドレスとを表す情報であり、例えば、ＤＢオペレーション毎に、「Ｏｐｅｒａｔｉｏｎ Ｓｔａｔｅ」（ＤＢオペレーションの状態（実行済、実行中又は未実行）を表す情報）および「Ｗｏｒｋ ａｒｅａ ａｄｄｒｅｓｓ」（確保されているワーク領域のアドレス）を含む。このクエリ実行プラン情報から、クエリ実行プランの構成、および、後段のＤＢオペレーションについてワーク領域を確保済みか否かがわかる。

図５は、ＤＢＭＳ１０４の実行状態の管理の一例を示す。

コンテキスト管理部１０９は、クエリ実行部１０８がクエリ実行プランに従ってクエリを処理する際に生成したコンテキストのうち、実行前および実行中のコンテキストを、クエリ実行プランのノード毎に管理する。例えば、図４Ａのクエリ実行プランに従ってクエリを処理する際には、クエリ実行部１０８は、ｐ＿ｔｙｐｅ索引およびｐａｒｔ表の読出しの際にデータ読出し要求を多重化する。コンテキスト管理部１０９は、多重化したデータ読出し要求の内容を含んだコンテキストをｐａｒｔ ｃｏｎｔｅｘｔ５０４に追加する。また、クエリ実行部１０８は、ｌ＿ｐａｒｔｋｅｙ索引およびｌｉｎｅｉｔｅｍ表の読み出しの際にデータ読出し要求を多重化し、コンテキスト管理部１０９は、その多重化したデータ読出し要求の内容を含んだコンテキストを、ｌｉｎｅｉｔｅｍ ｃｏｎｔｅｘｔ）５０５に追加する。また、クエリ実行部１０８は、ｏ＿ｏｒｄｅｒｋｅｙ索引およびｏｒｄｅｒｓ表の読み出しの際にデータ読出し要求を多重化し、コンテキスト管理部１０９は、その多重化したデータ読出し要求の内容を含んだコンテキストを、ｏｒｄｅｒｓ ｃｏｎｔｅｘｔ５０６に追加する。参照符号５０４〜５０８がそれぞれ表す５つのボックスは、それぞれ、１つのＤＢオペレーションに対応している。

実行情報取得部１１２は、クエリ実行情報を取得する。クエリ実行情報は、各結合オペレーションの推定結合率、クエリ実行プランの特定ノード毎に管理されているコンテキストの数、および、メモリ確保情報を含んでよい。メモリ確保情報は、例えば、図４Ｂに例示した情報のうちの少なくとも実行状態情報を含む。各結合オペレーション（ネステッドループ結合）の推定結合率、および、クエリ実行プランの特定ノード毎に管理されているコンテキストの数は、例えば、クエリ実行プラン生成部１０７を通じて取得される。図５の例によれば、第１の結合オペレーションの推定結合率（ｐａｒｔ表の抽出結果とｌｉｎｅｉｔｅｍ表の抽出結果との推定結合率）として「３０」が取得され、その結合結果とｏｒｄｅｒｓ表の抽出結果との推定結合率として「１」が取得される（図５では、推定結合率は「ｆａｎ−ｏｕｔ」と記載）。また、図５に示す実行状態の例によれば、ｐａｒｔ ｃｏｎｔｅｘｔ５０４に登録されているコンテキスト数として「０」、ｌｉｎｅｉｔｅｍ ｃｏｎｔｅｘｔ５０５に登録されているコンテキスト数として「２」、および、ｏｒｄｅｒｓ ｃｏｎｔｅｘｔ５０６に登録されているコンテキスト数として「１」が取得される。また、図５に示す実行状態の例によれば、取得されるメモリ確保情報から、後段の各ＤＢオペレーションについてワーク領域が確保済か否かと、ワーク領域が確保済であれば確保されているワーク領域のアドレスとがわかる。具体的には、メモリ確保情報から、後段ＤＢオペレーション「Ｇｒｏｕｐｉｎｇ」（集計）のために確保されたワーク領域５１３のアドレスと、後段ＤＢオペレーション「Ｏｒｄｅｒｉｎｇ」（ソート）のために確保されたワーク領域５１４のアドレスがわかる。

サーバ性能取得部１１３は、ＯＳ１１４が提供する機能を利用して、サーバ性能情報を取得する。サーバ性能情報は、実行中のクエリの実行により発揮されているサーバ性能（性能指標）を表し、例えば、ＣＰＵ性能及びＩ／Ｏ性能を表す。ＣＰＵ性能は、例えば、ＣＰＵ使用率である。Ｉ／Ｏ性能は、例えば、Ｉ／Ｏスループット使用率およびＩ／Ｏ多重度使用率である。ＣＰＵ使用率は、許容されたＣＰＵ資源量に対して使用されているＣＰＵ資源量の割合である。Ｉ／Ｏスループット使用率は、許容されたＩ／Ｏスループット（発揮できる最大Ｉ／Ｏスループット）に対して使用されている（発揮されている）Ｉ／Ｏスループットの割合である。Ｉ／Ｏ多重度使用率は、許容されたＩ／Ｏ多重度（発揮できるＩ／Ｏ多重度）に対して使用されている（発揮されている）Ｉ／Ｏ多重度の割合である。図５に示す実行状態の例によれば、ＣＰＵ使用率が「７０％」であり、Ｉ／Ｏスループット使用率が「３０％」であり、Ｉ／Ｏ多重度使用率が「８０％」である。各種使用率（性能指標）は、例えば、各種性能値の上限値に対する各種性能値（ＯＳ１１４が提供する機能を利用して取得できる値）の割合でよい。各種性能値の上限値は、ＯＳ１１４が提供する機能を利用して取得されてもよいし、上述した入力デバイス（図示せず）を通じてユーザから入力されてもよいし、ネットワークアダプタ１１５を通じて管理計算機（図示せず）等から取得されてもよい。

クエリ実行開始制御部１１１は、繰り返し（例えば定期的に）、実行情報取得部１１２によりクエリ実行情報を取得し、サーバ性能取得部１１３よりサーバ性能情報を取得し、取得したクエリ実行情報およびサーバ性能情報に基づいて、実行待ちクエリを実行するか否かを判定する。

図６は、クエリ実行開始判定の流れを示すフローチャートである。クエリ実行開始判定は、繰り返し（例えば定期的に）行われてよい。

クエリ実行開始制御部１１１は、実行情報取得部１１２によりクエリ実行情報を取得し、取得したクエリ実行情報を基に、実行中のクエリがテールフェーズにあるか否かを判定する（Ｓ６０１）。「テールフェーズ」とは、実行中クエリについてＳ６０１の判定時点から実行中クエリの終了時点まで実行中クエリの実行により発揮される性能が低くなっていくフェーズ（ＣＰＵ使用率、Ｉ／Ｏスループット使用率およびＩ／Ｏ多重度、メモリ使用量といった少なくとも１つの性能指標に対応した性能値がＳ６０１の判定時点の性能値よりも低くなっていくフェーズ）である。

Ｓ６０１の判定の結果が、実行中のクエリがテールフェーズにない、である場合（Ｓ６０２：ＮＯ）、クエリ実行開始制御部１１１は、クエリ実行開始判定を終了する。

Ｓ６０１の判定の結果が、実行中のクエリがテールフェーズにある、である場合（Ｓ６０２：ＹＥＳ）、クエリ実行開始制御部１１１は、サーバ性能取得部１１３よりサーバ性能情報を取得し、取得したサーバ性能情報に基づいて、サーバ性能に余力があるか否かを判定する（Ｓ６０３）。Ｓ６０３の判定の結果が、性能余力なし、である場合（Ｓ６０４：ＮＯ）、クエリ実行開始制御部１１１は、クエリ実行開始判定を終了する。

Ｓ６０３の判定の結果が、性能余力あり、である場合（Ｓ６０４：ＹＥＳ）、クエリ実行開始制御部１１１は、実行中クエリの実行終了前に実行待ちクエリを実行開始とする。実行開始とされたクエリが、クエリ実行部１０８により処理される。

図７は、テールフェーズ判定（図６のＳ６０１）の流れを示すフローチャートである。

クエリ実行開始制御部１１１は、クエリ実行情報（特に、クエリ実行プランの構成、クエリ実行プランの進捗、および、各結合オペレーションの推定結合率）を基に、最外表から推定結合率が１より大きい結合オペレーションの外表までの、実行前および実行中のコンテキスト数の総和が０であるか否かを判定する（Ｓ７０１）。「最外表から推定結合率が１より大きい結合オペレーションの外表までの、実行前および実行中のコンテキスト数の総和が０である」ということは、タスク（データ読出し要求）の多重度が、Ｓ７０１の判定時点での多重度より増えないことを意味する。推定結合率が１より大きければ、結合オペレーションにおける結合元の件数より結合結果の件数が多くなり、それらの後続処理を多重実行する際の多重度が大きくなる。このような場合に、実行待ちのクエリが実行開始とされると、新たに実行開始とされたクエリの実行による性能増加と、実行中のクエリについての性能増加により、性能過剰（言い換えれば、資源不足）になることがある。このようなことを回避するために、Ｓ７０１の判定が有効である。

Ｓ７０１の判定の結果が偽の場合（Ｓ７０１：ＮＯ）、クエリ実行開始制御部１１１は、テールフェーズ判定の結果として、実行中クエリがテールフェーズにない、を出力する（Ｓ７０４）。

Ｓ７０１の判定の結果が真の場合（Ｓ７０１：ＹＥＳ）、クエリ実行開始制御部１１１は、クエリ実行情報（特に、クエリ実行プランの構成、クエリ実行プランの進捗、および、メモリ確保情報）を基に、後段のＤＢオペレーション（未実行のＤＢオペレーション）で必要なワーク領域が確保済であるか否かを判定する（Ｓ７０２）。後段のＤＢオペレーションで必要なワーク領域が確保されていなければ、そのようなワーク領域を確保する際に、Ｓ７０２の判定時点よりメモリ使用量が増える可能性があるためである。そのため、Ｓ７０２の判定の結果が偽の場合（Ｓ７０２：ＮＯ）、クエリ実行開始制御部１１１は、テールフェーズ判定の結果として、実行中クエリがテールフェーズにない、を出力する（Ｓ７０４）。

Ｓ７０２の判定の結果が真の場合（Ｓ７０２：ＹＥＳ）、クエリ実行開始制御部１１１は、テールフェーズ判定の結果として、実行中クエリがテールフェーズにある、を出力する（Ｓ７０３）。

このようなテールフェーズ判定は、特に、例えば特許文献１のように、クエリ実行部１０８が、クエリの実行において、ＤＢオペレーションを実行するためのタスクを動的に生成し、動的に生成されたタスクを実行し、２以上の実行可能なタスクのうちの少なくとも２つのタスクを並行して実行するようになっている場合には、有効である。

図８は、性能余力判定（図６のＳ６０３）の流れを示すフローチャートである。

クエリ実行開始制御部１１１は、サーバ性能情報中のＣＰＵ使用率が、Ｘ％未満（Ｘ＝ＣＰＵ使用率の上限）か否かを判定する（Ｓ８０１）。

Ｓ８０１の判定の結果が真の場合（Ｓ８０１：ＹＥＳ）、クエリ実行開始制御部１１１は、性能余力判定の結果として、性能余力あり、を出力する（Ｓ８０４）。

Ｓ８０１の判定の結果が偽の場合（Ｓ８０１：ＮＯ）、クエリ実行開始制御部１１１は、サーバ性能情報中のＩ／Ｏスループット使用率が、Ｙ％未満（Ｙ＝Ｉ／Ｏスループット使用率の上限）か否かを判定する（Ｓ８０２）。Ｓ８０２の判定の結果が真の場合（Ｓ８０２：ＹＥＳ）、更に、クエリ実行開始制御部１１１は、サーバ性能情報中のＩ／Ｏ多重度使用率が、Ｚ％未満（Ｚ＝Ｉ／Ｏ多重度使用率の上限）か否かを判定する（Ｓ８０３）。

Ｓ８０３の判定の結果が真の場合（Ｓ８０３：ＹＥＳ）、クエリ実行開始制御部１１１は、性能余力判定の結果として、性能余力あり、を出力する（Ｓ８０４）。

Ｓ８０２またはＳ８０３の判定の結果が偽の場合（Ｓ８０２：ＮＯまたはＳ８０３：ＮＯ）、クエリ実行開始制御部１１１は、性能余力判定の結果として、性能余力なし、を出力する（Ｓ８０５）。

実施例１によれば、クエリ実行情報を基に、テールフェーズ判定と性能余力判定の両方が行われ、両方の判定の結果が真の場合、実行中クエリの実行終了前に実行待ちクエリが実行開始とされる。実行中クエリがテールフェーズにあり、且つ、サーバ性能が上限に達していなければ、実行中クエリの実行終了前に実行待ちクエリを開始することで、サーバ性能をなるべく上限まで発揮させることが期待できる。

以上が、実施例１の説明である。なお、性能余力ありは、ＣＰＵ性能とＩ／Ｏ性能の両方が上限に達していないことであってよい。また、サーバ性能（性能指標）は、ＣＰＵ性能およびＩ／Ｏ性能の少なくとも１つに代えてまたは加えて、他種の性能（性能指標）、例えば、メモリ性能（例えばメモリ使用率）を含んでもよい。また、発揮されるサーバ性能が上限に達する（サーバ性能が上限を下回る）という表現は、使用されるシステム資源量が上限に達する（システム資源量が上限を下回る）という表現に言い換えられてもよい。システム資源とは、ＤＢサーバ１０１における資源を含み、更に、ＤＢ１１０と他の装置（例えば外部ストレージ装置１１８）とを含んだ計算機システムの資源でもよい。システム資源としても、例えば、ＣＰＵ使用率、Ｉ／Ｏスループット使用率およびＩ／Ｏ多重度使用率の少なくとも１つが採用されてよい。

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

クエリ（クエリ実行プラン）によっては、タスクを並行実行できないＤＢオペレーションが存在することがある。そのようなＤＢオペレーションの一例として、例えば、検索結果集合のソート処理が挙げられる。ソート処理は、一部ではタスクの並行実行が可能ではあるが、ソート処理全般に渡ってタスクを並行実行することはできない。

そこで、実施例２では、テールフェーズ判定において、タスクを多重実行可能なＤＢオペレーションが全て実行終了しているか否かが判定され、その判定の結果が、実行中タスクがテールフェーズにあるか否かの結論に影響する。

図９は、実施例２にかかるＤＢＭＳ１０４の実行状態の管理の一例を示す。

実行情報取得部１１２がクエリ実行部（１０８）から取得するクエリ実行情報は、クエリ実行プランのノード毎に管理されているコンテキストの数、および、メモリ確保情報を含む。実行情報取得部１１２は、クエリ実行情報中の、各ノードについてのコンテキスト数に基づき、各ノード（ＤＢオペレーション）が、未実行（Ｕｎｅｘｅｃｕｔｅｄ）、実行中（Ｅｘｅｃｕｔｉｎｇ）および実行済（Ｅｘｅｃｕｔｅｄ）のいずれの状態であるかを判定する。図９に示す実行状態の例によれば、ｐａｒｔ ｃｏｎｔｅｘｔ９０４、ｌｉｎｅｉｔｅｍ ｃｏｎｔｅｘｔ９０５およびｏｒｄｅｒｓ ｃｏｎｔｅｘｔ９０６に登録されているコンテキストの数が０であることから、Ｓｅｌｅｃｔｉｏｎ ｏｐｅｒａｔｉｏｎ（Ｐａｒｔ）、Ｓｅｌｅｃｔｉｏｎ ｏｐｅｒａｔｉｏｎ（Ｌｉｎｅｉｔｅｍ）、および、Ｓｅｌｅｃｔｉｏｎ ｏｐｅｒａｔｉｏｎ（Ｏｒｄｅｒｓ）は、Ｅｘｅｃｕｔｅｄと判定される。また、Ｇｒｏｕｐｉｎｇ ｃｏｎｔｅｘｔ９０７に登録されているコンテキストの数が０であることから、Ｇｒｏｕｐｉｎｇ Ｏｐｅｒａｔｉｏｎも、Ｅｘｅｃｕｔｅｄと判定される。また、Ｏｒｄｅｒｉｎｇ ｃｏｎｔｅｘｔ９０８に登録されているコンテキストの数が１であることから、Ｏｒｄｅｒｉｎｇ Ｏｐｅｒａｔｉｏｎは、Ｅｘｅｃｕｔｉｎｇと判定される。ＤＢオペレーションの直前のＤＢオペレーションに対応したコンテキストの数も１以上であれば、当該ＤＢオペレーションについては未実行もしくは実行中と判定される。また、クエリ実行開始制御部１１１は、クエリ実行情報が含むクエリ実行プラン情報を基に、各ＤＢオペレーションについて、タスクを多重実行可能か否か取得し、多重実行可能なＤＢオペレーションについては「Ｍｕｌｔｉｐｌｅ Ｅｘｅ」と管理し、多重実行不可能なＤＢオペレーションについては「Ｓｉｎｇｌｅ Ｅｘｅ」と管理する。

図１０は、実施例２にかかるテールフェーズ判定の流れを示すフローチャートである。

実施例２にかかるテールフェーズ判定では、図７のＳ７０１に代えて、Ｓ１００１が行われ、それ以外は同じである。Ｓ１００１では、クエリ実行開始制御部１１１は、クエリ実行情報（特に、実行情報取得部１１２により特定された、各ノード（ＤＢオペレーション）の状態）を基に、多重実行可能なＤＢオペレーションが全て終了しているか否かを判定する。Ｓ１００１の判定の結果が真の場合（Ｓ１００１：ＹＥＳ）、Ｓ７０２が行われ、Ｓ１００１の判定の結果が偽の場合（Ｓ１００１：ＮＯ）、Ｓ７０４が行われる。

多重実行可能なＤＢオペレーションが全て終了していれば、実行中クエリの実行において性能が高くなることはない（言い換えれば、消費される資源量が増えることはない）。実施例２によれば、多重実行可能なＤＢオペレーションが全て終了していると判定され、且つ、後段のＤＢオペレーションで必要なワーク領域が確保されていれば、実行中クエリがテールフェーズにあると判定される。

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

図１１は、実施例３にかかる計算機システムの構成を示す。

アプリケーションサーバ１１０２は、ＤＢサーバ１０１に、通信ネットワーク１１０９を介して通信可能に接続されている。また、ＤＢサーバ１０１は、外部ストレージ装置１１８に、通信ネットワーク４０３を介して通信可能に接続されている。ユーザ端末（クライアント端末）１１０１は、アプリケーションサーバ１１０２に、通信ネットアーク１１０８を介して通信可能に接続されている。ＤＢサーバ１０１は、ＤＢ１２２を管理するＤＢＭＳ１０４を実行する。外部ストレージ装置１１８は、ＤＢ１２２を格納する。アプリケーションサーバ１１０２は、ＤＢＭＳ１０４に対してクエリを発行するアプリケーションプログラムを実行する。ユーザ端末１１０１は、アプリケーションサーバ１１０２で実行されるアプリケーションプログラムに要求を出す。なお、ユーザ端末１１０１、または、アプリケーションサーバ１１０２は、複数存在しても良い。

アプリケーションサーバ管理端末１１０５は、通信ネットワーク１１１１を介してアプリケーションサーバ１１０２に通信可能に接続されている。ＤＢサーバ管理端末１１０６は、通信ネットワーク１１１２を介してＤＢサーバ１０１に通信可能に接続されている。外部ストレージ管理端末１１０７は、通信ネットワーク１１１３を介して外部ストレージ装置１１８に通信可能に接続されている。アプリケーションサーバ管理端末１１０５は、アプリケーションサーバ１１０２を管理する端末である。ＤＢサーバ管理端末１１０６は、ＤＢサーバ１０１を管理する端末である。外部ストレージ管理端末１１０７は、外部ストレージ装置１１８を管理する端末である。なお、管理端末１１０５〜１１０７のうちの少なくとも２つが共通（一体）であっても良い。また、通信ネットワーク４０３および１１０８〜１１１３のうちの少なくとも２つが共通（一体）であっても良い。

実施例３では、例えば、下記の通り処理が実行される。
（Ｓ１１１４）ユーザ端末１１０１は、アプリケーションサーバ１１０２に要求（以下、ユーザ要求）を発行する。
（Ｓ１１１５）アプリケーションサーバ１１０２は、Ｓ１１１４で受信したユーザ要求に従いクエリを生成する。そして、生成したクエリをＤＢサーバ１０１に発行する。
（Ｓ１１１６）ＤＢサーバ１０１は、アプリケーションサーバ１１０２からのクエリを受け付け、受け付けたクエリを実行する。ＤＢサーバ１０１は、受け付けたクエリの実行において必要なデータ入出力要求（例えばデータ読出し要求）を外部ストレージ装置１１８に発行する。ＤＢサーバ１０１は、１つのクエリの実行において、複数のデータ入出力要求を並行して発行することがある。そのため、ＤＢサーバ１０１は、１つのクエリの実行において、Ｓ１１１６の要求を複数回並行して行うことがある。
（Ｓ１１１９）外部ストレージ装置１１８は、Ｓ１１１６で発行されたデータ入出力要求について、ＤＢサーバ１０１に応答する。外部ストレージ装置１１８は、Ｓ１１１９の応答を複数回並行して行うことがある。
（Ｓ１１１８）ＤＢサーバ１０１は、クエリの実行結果を生成し、アプリケーションサーバ１１０２に送信する。
（Ｓ１１１７）アプリケーションサーバ１１０２は、クエリの実行結果を受信する。そして、該実行結果に従う、Ｓ１１１４で受信したユーザ要求に対する回答を、ユーザ端末１１０１に送信する。

なお、アプリケーションサーバ１１０２に発行されるユーザ要求、または、ＤＢサーバへ発行されるクエリは、同時に複数あっても良い。

以上、幾つかの実施例を説明したが、本発明は、これらの実施例に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能である。例えば、本発明は、ＤＢＭＳ以外のシステム、例えば、ファイルシステムにも適用できる。そのようなシステムを実行する計算機（又はその計算機を含んだ計算機システム）は、例えば、複数の処理要求の各々の実行開始を制御する実行処理要求制御部と、実行開始とされた処理要求を実行する要求実行部とを有してよい。実行処理要求制御部が、計算機（又は計算機システム）の実行状態に基づいて、実行中の処理要求の実行により発揮される性能である発揮性能が或る時点以降継続して所定の条件を満たすか否かを判定し、判定の結果の真の場合、実行中の処理要求の実行終了前に実行待ちの処理要求を実行開始としてよい。このように、ＤＢＭＳ以外のシステムでは、上記の説明において、ＤＢオペレーションをオペレーションと読み替え、クエリを処理要求と読み替えることができる。

１０４…データベース管理システム（ＤＢＭＳ）

Claims (12)

1. データベースへの複数のクエリの各々の実行開始を制御する実行クエリ制御部と、
   実行開始とされたクエリを実行するクエリ実行部と
   を有し、
   前記実行クエリ制御部が、
   データベース管理システムの実行状態に基づいて、実行中のクエリの実行により発揮される性能である発揮性能が或る時点以降継続して所定の条件を満たすか否かを判定し、
   前記判定の結果が真の場合、前記実行中のクエリの実行終了前に実行待ちのクエリを実行開始とする、
   データベース管理システム。
2. 前記発揮性能が前記所定の条件を満たすとは、データベース管理システムを含んだ計算機の性能を含むシステム性能についての所定の閾値を前記発揮性能が下回ることである、
   請求項１記載のデータベース管理システム。
3. 前記データベース管理システム実行状態は、前記実行中のクエリの実行状態である実行クエリ状況を含み、
   前記発揮性能が前記或る時点以降継続して前記所定の条件を満たすとは、前記データベース管理システムを含んだ計算機の性能を含むシステム性能についての所定の閾値を前記発揮性能が下回り、且つ、前記実行クエリ状況が、前記実行中のクエリがテールフェーズにあることを表すことである、
   請求項１記載のデータベース管理システム。
4. 前記複数のクエリの各々について、クエリを実行するために必要な複数のデータベースオペレーションと前記複数のデータベースオペレーションの実行手順とを表す情報を含んだクエリ実行プランを生成するクエリ実行プラン生成部、
   を更に有し、
   前記実行クエリ状況は、前記実行中のクエリのクエリ実行プランと、前記実行中のクエリの進捗とに基づいている、
   請求項３記載のデータベース管理システム。
5. 複数のデータベースオペレーションは、１以上の結合オペレーションを含み、
   前記１以上の結合オペレーションの各々は、外表から取得されたレコードを用いて内表から取得されたレコードの結果を生成するデータベースオペレーションであり、
   前記実行クエリ状況は、更に、メモリ領域の確保状況を含み、
   前記クエリ実行部は、前記複数のクエリの各々の実行において、データベースオペレーションを実行するためのタスクを動的に生成し、動的に生成されたタスクを実行し、２以上の実行可能なタスクが存在する場合には、それら２以上のタスクのうちの少なくとも２つのタスクを並行して実行することで、データ読出し要求を多重化して発行し、且つ、多重化したデータ読出し要求の内容を含んだコンテキストを保持し、
   前記実行中のクエリが前記テールフェーズにあるとは、最外表から推定結合率が１より大きい結合オペレーションの外表までのデータベースオペレーションに対応したコンテキストの総和が０であり、且つ、前記実行中のクエリの後段のデータベースオペレーションで必要なメモリ領域が確保済である、
   各結合オペレーションについて、推定結合率は、結合元の件数に対する結合結果の件数の倍率の推定値である、
   請求項３記載のデータベース管理システム。
6. 前記実行中のクエリが前記テールフェーズにあるとは、２以上のタスクが並行実行されるデータベースオペレーションが全て実行済である、
   請求項３記載のデータベース管理システム。
7. 前記発揮性能が前記所定の条件を満たすとは、ＣＰＵ性能が第１の条件を満たすこと、および、Ｉ／Ｏ性能が第２の条件を満たすこと、のうちの少なくとも１つである、
   請求項１記載のデータベース管理システム。
8. 前記ＣＰＵ性能は、ＣＰＵ使用率であり、
   前記Ｉ／Ｏ性能は、Ｉ／ＯスループットとＩ／Ｏ多重度であり、
   前記ＣＰＵ性能が前記第１の条件を満たすとは、前記ＣＰＵ使用率が所定の使用率を下回ることであり、
   前記Ｉ／Ｏ性能が前記第２の条件を満たすとは、前記Ｉ／Ｏスループットが所定のスループットを下回り、且つ、前記Ｉ／Ｏ多重度が、所定の多重度を下回ることである、
   請求項７記載のデータベース管理システム。
9. 前記或る時点以降継続してとは、前記或る時点からクエリ実行終了までである、
   請求項１記載のデータベース管理システム。
10. 前記発揮性能が或る時点以降継続して所定の条件を満たすか否かの判定は、定期的に行われる、
    請求項１記載のデータベース管理システム。
11. データベース管理システムの実行状態を表す情報を記憶するメモリと、
    データベースへの複数のクエリの各々の実行開始を制御し実行開始とされたクエリを実行するプロセッサと
    を有し、
    前記プロセッサが、
    前記情報に基づいて、実行中のクエリの実行により発揮される性能である発揮性能が或る時点以降継続して所定の条件を満たすか否かを判定し、
    前記判定の結果が真の場合、前記実行中のクエリの実行終了前に実行待ちのクエリを実行開始とする、
    計算機。
12. コンピュータが、データベース管理システムの実行状態に基づいて、実行中のクエリの実行により発揮される性能である発揮性能が或る時点以降継続して所定の条件を満たすか否かを判定し、
    前記コンピュータが、前記判定の結果が真の場合、実行待ちのクエリがあれば、前記実行中のクエリの実行終了前に、前記実行待ちのクエリの実行を開始する、
    データベース管理方法。

Images