JP6764175B2 - データベース管理システム、及び、データベース管理方法 - Google Patents

Description

本発明は、概して、データベース管理に関し、特に、クエリ処理の中断に関する。

データベースに対するクエリに従うクエリ処理の中断と再開が望ましいケースが考えられる。クエリ処理の中断と再開に関する技術として、非特許文献１及び２に開示の技術がある。

非特許文献１によれば、ヒープ（実行状態）を出力して中断しヒープを読み込んで再開するDumpStateと、実行中の処理を放棄して中断し実行途中で適宜設定されたチェックポイントから処理を再開するGoBackという二種類の中断再開方法から、トータルコストが最小になる中断再開方法が選択され、選択された中断再開方法に従ってクエリ処理の中断と再開が行われる。

非特許文献２によれば、中断時には、中間結果の一部がダンプされ、再開時には、ダンプされた部分以外の部分についてスキャンが行われる。

Badrish Chandramouli et al., "Query Suspend and Resume", SIGMOD'07, June 12-14, 2007, Beijing, China Surajit Chaudhuri, et al., "Stop-and-Restart Style Execution for Long Running Decision Support Queries", VLDB ’07, September 23-28, 2007, Vienna, Austria

クエリ処理の中断を中断完了時刻までに完了することが必要とされるケースが考えられる。例えば、消費電力が増加する日中に行われる第１のクエリ処理の性能低下を避けるため、或いは、日中における消費電力の更なる増加を避けるために、夜間に行われる第２のクエリ処理の中断を日中の開始時刻までに完了するといったケースが考えられる。

しかし、非特許文献１及び２のいずれも、クエリ処理の中断を中断完了時刻までに完了するための技術を開示も示唆もしていない。このため、例えば、上述の第２のクエリ処理の中断を日中の開始時刻までに完了することができず、結果として、日中の上述の第１のクエリ処理の性能低下や、日中の消費電力の更なる増加といった問題が生じ得る。

クエリ処理を直ちに中断する方法が考えられるが、当該方法では、クエリ処理の進捗率の低下や、ダンプするデータの量の増加が懸念される。

データベース管理システム（ＤＢＭＳ）を、クエリ処理の中断完了時刻を先の時刻とした中断命令を受け付け可能とする。ＤＢＭＳは、クエリ処理の実行中に、当該クエリ処理について上記中断命令を受け付けた場合、中断命令が受け付けられてから中断完了時刻までの間に、予想完了時刻が中断完了時刻以前である対象オブジェクトがあれば、当該対象オブジェクトの状態をスナップショット中断を意味する状態に変更する。対象オブジェクトには、中断命令が受け付けられたときに実行中を意味する状態である処理オブジェクトが少なくとも該当する。スナップショット中断を意味する状態の処理オブジェクトであるスナップショット中断オブジェクトがあれば、ＤＢＭＳは、中断完了時刻まで当該スナップショット中断オブジェクトを実行する。

クエリ処理の進捗率の低下や中断時に保存するデータの量を抑えて当該クエリ処理の中断を中断完了時刻までに完了することができる。

実施例１の概要を示す。 実施例１に係るＤＢＭＳを実行するＤＢサーバを含むシステム全体の構成例を示す。 クエリ処理（中断と再開を含まない）の一例を示す。 クエリ処理（中断と再開を含む）の一例を示す。 クエリの一例を示す。 実行プランの一例を示す。 実施例１に係るオブジェクト一覧情報の一例を示す。 実施例１に係るトランザクション管理情報の一例を示す。 実施例１に係る状態管理情報（中断命令が受け付けられる前の情報）の一例を示す。 ダンプの一例を示す。 クエリ処理のフローを示す。 処理オブジェクトの実行のフローの一部を示す。 処理オブジェクトの実行のフローの残りを示す。 中断判定処理のフローを示す。 実施例１に係る状態管理情報（中断命令が受け付けられる後の情報）の一例を示す。 実施例２に係る匿名加工処理の流れの概要図である。 実施例２に係るトランザクション管理情報の一例を示す。 実施例２に係るデータ配置の一例を示す。 実施例２に係るオブジェクト一覧情報の一例を示す。 実施例２に係る状態管理情報の一例を示す。 実施例３に係るクエリ処理の一部を示す。 実施例３に係る状態管理情報の一例を示す。

以下の説明では、データベース管理システムを「ＤＢＭＳ」と言い、ＤＢＭＳを有するサーバを「ＤＢサーバ」と言う。ＤＢＭＳに対するクエリの発行元は、ＤＢＭＳの外部のコンピュータプログラム（例えばアプリケーションプログラム）でよい。外部のコンピュータプログラムは、ＤＢサーバ内で実行されるプログラムでもよいし、ＤＢサーバのクライアントで実行されるプログラムでもよい。

以下の説明では、「インターフェース装置」は、一つ以上のインターフェースデバイスでよい。当該一つ以上のインターフェースデバイスは、一つ以上の同種の通信インターフェースデバイス（例えば一つ以上のＮＩＣ（Network Interface Card））であってもよいし二つ以上の異種の通信インターフェースデバイス（例えばＮＩＣとＨＢＡ（Host Bus Adapter））であってもよい。

また、以下の説明では、「メモリ」は、一つ以上のメモリデバイスであり、典型的には主記憶デバイスでよい。メモリにおける少なくとも一つのメモリデバイスは、揮発性メモリデバイスであってもよいし不揮発性メモリデバイスであってもよい。

また、以下の説明では、「永続記憶装置」は、一つ以上の永続記憶デバイスである。永続記憶デバイスは、典型的には、不揮発性の記憶デバイス（例えば補助記憶デバイス）であり、具体的には、例えば、ＨＤＤ（Hard Disk Drive）又はＳＳＤ（Solid State Drive）である。

また、以下の説明では、「記憶装置」は、メモリと永続記憶装置の少なくともメモリでよい。

また、以下の説明では、「プロセッサ」は、一つ以上のプロセッサデバイスである。少なくとも一つのプロセッサデバイスは、典型的には、ＣＰＵ（Central Processing Unit）のようなマイクロプロセッサデバイスであるが、ＧＰＵ（Graphics Processing Unit）のような他種のプロセッサデバイスでもよい。少なくとも一つのプロセッサデバイスは、シングルコアでもよいしマルチコアでもよい。少なくとも一つのプロセッサデバイスは、プロセッサコアでもよい。少なくとも一つのプロセッサデバイスは、処理の一部又は全部を行うハードウェア回路（例えばＦＰＧＡ（Field-Programmable Gate Array）又はＡＳＩＣ（Application Specific Integrated Circuit））といった広義のプロセッサデバイスでもよい。

また、以下の説明では、「ｋｋｋ部」の表現にて機能を説明することがあるが、機能は、一つ以上のコンピュータプログラムがプロセッサによって実行されることで実現されてもよいし、一つ以上のハードウェア回路（例えばＦＰＧＡ又はＡＳＩＣ）によって実現されてもよい。プログラムがプロセッサによって実行されることで機能が実現される場合、定められた処理が、適宜に記憶装置及び／又はインターフェース装置等を用いながら行われるため、機能はプロセッサの少なくとも一部とされてもよい。機能を主語として説明された処理は、プロセッサあるいはそのプロセッサを有する装置が行う処理としてもよい。プログラムは、プログラムソースからインストールされてもよい。プログラムソースは、例えば、プログラム配布計算機又は計算機が読み取り可能な記録媒体（例えば非一時的な記録媒体）であってもよい。各機能の説明は一例であり、複数の機能が一つの機能にまとめられたり、一つの機能が複数の機能に分割されたりしてもよい。

また、以下の説明では、「クエリ処理」とは、クエリに従う処理である。クエリ処理は、複数の処理オブジェクトから構成される。「処理オブジェクト」は、クエリ処理の一部である。複数の処理オブジェクトの各々のコストは、同一でも異なっていてもよい。処理オブジェクトのコストとしては、例えば、処理オブジェクトの実行に要する時間である「時間コスト」や、処理オブジェクトの消費電力である「電力コスト」がある。

また、以下の説明では、同種の要素を区別しないで説明する場合には、参照符号のうちの共通部分を使用し、同種の要素を区別する場合は、参照符号を使用することがある。例えば、処理オブジェクトを区別しない場合には、「処理オブジェクト１２」と言い、処理オブジェクトを区別する場合には、「処理オブジェクト１２Ａ」、「処理オブジェクト１２Ｂ」のように言うことがある。

以下、図面を参照しながら、本発明の幾つかの実施例を説明する。なお、以下の説明により本発明が限定されるものではない。

図１は、実施例１の概要を示す。

ＤＢＭＳ１３０は、クエリ処理の中断完了時刻を先の時刻とした中断命令を当該クエリ処理の実行中に受け付けることができるよう構成されている。

本実施例では、クエリ処理は、ＤＢＭＳ１３０が受け付けたクエリに基づき生成されたクエリ実行プラン（以下、実行プラン）に従い行われる。ＤＢＭＳ１３０は、実行プランに従い、クエリ処理を構成する複数の処理オブジェクトを実行するようになっている。実行プランの一例が、図１に例示の実行プラン１１である。実行プラン１１に従う複数の処理オブジェクトの一例が、図１に例示の複数の処理オブジェクト１２である。「ＨＪ」はハッシュ結合を意味し、「Ａｇｇ．」は集約を意味する。また、図１の例によれば、４並列（Ｎ並列の一例）でクエリ処理を実行すること、すなわち、最大四つの処理オブジェクト１２を並列に実行することができる。

処理オブジェクトの状態として、例えば、“実行完了”、“実行中”及び“未実行”がある。そして、“未実行”として、少なくとも“実行不可”と“実行可”がある。

ＤＢＭＳ１３０が、クエリ処理の実行中に時刻Ｔ１で中断命令を受け付けたとする。この場合、ＤＢＭＳ１３０は、時刻Ｔ１から中断完了時刻Ｔ２までの間に、予想完了時刻が中断完了時刻Ｔ２以前である対象オブジェクトがあれば、当該対象オブジェクトの状態を“中断（ＳＳ）”（スナップショット中断を意味する状態）に変更する。スナップショット中断とは、区切りのよい状態まで処理オブジェクトの実行を進めて、実行状態を保存する処理オブジェクトの中断方法である。例えば、本実施例では、スキャンした対象データに対する処理をすべて実施することである。「対象オブジェクト」には、中断命令が受け付けられたときに状態が“実行中”である処理オブジェクト１２Ａ〜１２Ｄが少なくとも該当する。

具体的には、例えば、ＤＢＭＳ１３０は、処理オブジェクト１２Ａ〜１２Ｄの各々について、当該処理オブジェクト１２の予想完了時刻が中断完了時刻Ｔ２以前か否かの判定である中断判定を実行する。図１の例によれば、処理オブジェクト１２Ａ、１２Ｂ及び１２Ｄについて、それぞれ中断判定の結果が真となる。ＤＢＭＳ１３０は、処理オブジェクト１２Ａ、１２Ｂ及び１２Ｄの各々の状態を“中断（ＳＳ）”に変更する。

なお、「中断完了時刻」は、本実施例では、中断が完了する時刻として中断命令で指定されている時刻であるが、それに代えて、時刻Ｔ１から一定時間経過した時点での時刻でもよい。中断完了時刻Ｔ２の指定は、時刻それ自体の指定でもよいし、時刻Ｔ１又は中断命令のタイムスタンプ（例えば送信時刻）からの経過時間の指定でもよい。また、「中断判定」は、本実施例では時刻Ｔ１で行われるが、それに代えて、時刻Ｔ１又は中断命令のタイムスタンプから一定時間経過した時刻、或いは、中断完了時刻Ｔ２から一定時間前の時刻でもよい。

スナップショット中断オブジェクト（状態が“中断（ＳＳ）”である処理オブジェクト）があれば、ＤＢＭＳ１３０は、中断完了時刻Ｔ２まで当該スナップショット中断オブジェクトを実行する。図１の例によれば、処理オブジェクト１２Ａ、１２Ｂ及び１２Ｄの各々が、スナップショット中断オブジェクトである。

本実施例によれば、時刻Ｔ１において実行中の処理オブジェクトについて少なくとも中断判定が行われ、中断判定の結果が真であれば当該処理オブジェクトの実行が継続する。このため、クエリ処理の進捗率の低下や中断時に保存するデータの量を抑えて当該クエリ処理の中断を中断完了時刻までに完了することができる。また、動的な電力変動（例えば、外的なピークカット要請）に応じた処理管理を効率的に行なうことも期待できる。

ＤＢＭＳ１３０は、予想完了時刻が中断完了時刻よりも後である対象オブジェクトがあれば、当該対象オブジェクトの状態を“中断（ＤＰ）”（ダンプ中断を意味する状態）に変更する。ダンプ中断オブジェクト（状態が“中断（ＤＰ）”である処理オブジェクト）があれば、ＤＢＭＳ１３０は、当該オブジェクトの実行途中の情報を含んだダンプを保存することであるダンプ保存を実行する。図１の例によれば、「予想完了時刻が中断完了時刻よりも後である対象オブジェクト」は、中断判定の結果が偽である処理オブジェクト１２Ｃであり、処理オブジェクト１２Ｃの状態が、“中断（ＤＰ）”に変更される。結果として、処理オブジェクト１２Ｃについて、ダンプ保存が実行される。

少なくとも一つのスナップショット中断オブジェクトは、当該オブジェクトを実行する計算リソースの負荷又はその他の原因によって、当該オブジェクトの予想完了時刻までに完了しない可能性が考えられる。

そこで、本実施例では、ＤＢＭＳ１３０は、各スナップショット中断オブジェクトについて、当該オブジェクトがそれの予想完了時刻までに完了するかを監視する。ＤＢＭＳ１３０は、予想完了時刻が現在時刻より前のスナップショット中断オブジェクトがあれば、当該スナップショット中断オブジェクトの状態を“中断（ＤＰ）”に変更する。図１の例によれば、予想完了時刻が現在時刻Ｔ３よりも前のスナップショット中断オブジェクト１２Ａがあり、このため、ＤＢＭＳ１３０は、当該オブジェクト１２Ａの状態を“中断（ＤＰ）”に変更する。この場合、結果として、処理オブジェクト１２Ａについて、ダンプ保存が実行される。

また、ＤＢＭＳ１３０は、予想完了時刻が現在時刻より後のスナップショット中断オブジェクトがあれば、当該スナップショット中断オブジェクトの進捗を基に予想完了時刻を補正する。ＤＢＭＳ１３０は、当該補正された予想完了時刻が現在時刻よりも前であれば、当該スナップショット中断オブジェクトの状態を“中断（ＤＰ）”に変更する。これにより、中断時刻までにクエリ処理を中断することの確実性を高めることができる。

以下、本実施例を詳細に説明する。

図２は、実施例１に係るＤＢＭＳを実行するＤＢサーバを含むシステム全体の構成例を示す。

ＤＢサーバ１００は、計算機システムの一例である。ＤＢサーバ１００は、例えば、パーソナルコンピュータ、ワークステーション又はメインフレームであってよいし、これらの計算機において仮想化プログラムによって構成された仮想的な計算機であってよいし、クラウド環境（例えば、インターフェースデバイス、記憶デバイス及びプロセッサといった複数の計算リソースを含んだ計算リソースプール）上で実現されてもよい。

ＤＢサーバ１００に、クライアント１９及びストレージシステム１１０が接続される。

具体的には、例えば、ＤＢサーバ１００に、ネットワーク１６０Ａを介してクライアント１９が接続される。クライアント１９は、クエリ発行元の一例であり、ＤＢサーバ１００にデータベースに対するクエリを発行する。

また、例えば、ＤＢサーバ１００に、ネットワーク１６０Ｂを介してストレージシステム１１０が接続される。ストレージシステム１１０は、記憶装置を有している。ストレージシステム１１０は、ＤＢサーバ１００からＩ／Ｏ（Input/Output）要求を受けた場合には、当該Ｉ／Ｏ要求に応答して、記憶装置に対するデータのＩ／Ｏを行う。ストレージシステム１１０には、データベースの一部として、例えば、ＯＲＤＥＲＳ表５０Ａ（検索対象の表の一例）、及び、ＬＩＮＥＩＴＥＭ表５０Ｂ（検索対象の表の一例）が格納されている。また、クエリ処理において、ストレージシステム１１０には、作業表５１（クエリ処理中の中間結果（例えば、スキャンされた表の一部）が格納される一時表）がＤＢＭＳ１３０により格納される。また、クエリ処理の中断が行われる場合、ストレージシステム１１０には、クエリ処理の中断において出力されクエリ処理の再開に使用される情報である中間管理情報５２もＤＢＭＳ１３０により格納される。

ネットワーク１６０Ａ及び１６０Ｂは、通信速度及び消費電力の異なるネットワークでもよいし、ネットワーク１６０Ａ及び１６０Ｂが同一のネットワークでもよい。例えば、ネットワーク１６０Ａ及び１６０Ｂの各々は、ＦＣ（Fibre Channel）ネットワーク、イーサネット（登録商標）、InfiniBand及びLocal Area Network）のいずれでもよい。

ＤＢサーバ１００は、インターフェース装置１０１、メモリ１５０及びそれらに接続されたプロセッサ１０２を有する。ＤＢサーバ１００は、キーボードやポインティングデバイス等の入力デバイス（図示しない）と液晶ディスプレイ等の出力デバイス（図示しない）を有してもよい。入力デバイス及び出力デバイスは、プロセッサ１０２に接続されていてよい。入力デバイスと出力デバイスは一体であってもよい。

インターフェース装置１０１が、ネットワーク１６０Ａ及び１６０Ｂに接続される。インターフェース装置１０１経由で（ネットワーク１６０Ａ及び１６０Ｂ経由で）、ＤＢサーバ１００は、ストレージシステム１１０及びクライアント１９と通信することができる。

メモリ１５０が、プロセッサ１０２によって実行されるプログラムと、プログラムが使用するデータを記憶する。プログラムとして、例えば、ＤＢＭＳ１３０及びＯＳ（Operating System）１２０がある。ＤＢＭＳ１３０が、クライアント１９からクエリを受け、そのクエリを実行する。そのクエリの実行において、ＤＢＭＳ１３０は、データベースからデータを読み込むために、又は、データベースにデータを書き込むために、Ｉ／Ｏ要求をＯＳ１２０に発行する。ＯＳ１２０は、そのＩ／Ｏ要求を受け、そのＩ／Ｏ要求に基づくＩ／Ｏ要求をストレージシステム１１０へ発行し、結果をＤＢＭＳ１３０に返す。

ＤＢＭＳ１３０は、クエリ受付部１３１、プラン生成部１３２、クエリ実行部１３３、中断命令受付部１３４、及び中断再判定部１３５を有する。なお、ＤＢＭＳ１３０の構成は一例に過ぎない。例えば、ある構成要素は複数の構成要素に分割されていてもよく、複数の構成要素が一つの構成要素に統合されていてもよい。例えば、中断命令受付部１３４は、クエリ実行部１３３の中に存在してもよい。

クエリ受付部１３１は、データベースに対するクエリをクライアント１９から受け付ける。クエリは、例えば、ＳＱＬ（Structured Query Language）によって記述される。

プラン生成部１３２は、受け付けたクエリに基づいて当該クエリを実行するために必要な実行プラン１１を生成する。実行プラン１１は、例えば、一つ以上のデータベース演算子と、データベース演算子の実行順序の関係を含む情報である。実行プラン１１は、例えば、データベース演算子をノード、データベース演算子の実行順序の関係をエッジとする木構造で表されることがある。

クエリ実行部１３３は、生成された実行プラン１１に基づいてクエリ処理を実行し、当該クエリ処理の結果を示す応答をクライアント１９に返す。なお、クエリ処理において、クエリ実行部１３３は、データベース演算子を実行するためのタスクを生成し、生成されたタスクを実行することで、そのタスクに対応したデータベース演算子に必要なデータの読込み要求を発行することができる。クエリ実行部１３３は、一のタスクで複数のデータベース演算子を実行してもよい。タスクの実装としては、例えば、ＯＳ１２０が実現するプロセスやカーネルスレッド等のほか、ライブラリ等が実現するユーザスレッドを用いてよい。

中断命令受付部１３４は、クエリ処理の中断完了時刻を現在時刻より先の時刻とした中断命令を受け付ける。

中断再判定部１３５は、予想完了時刻が現在時刻より後のスナップショット中断オブジェクトがあれば、当該スナップショット中断オブジェクトの進捗を基に予想完了時刻を補正する。中断再判定部１３５は、当該補正された予想完了時刻が現在時刻を過ぎていれば、当該スナップショット中断オブジェクトの状態を“中断（ＤＰ）”に変更する。

ＤＢＭＳ１３０は、オブジェクト一覧情報１９０、トランザクション管理情報１９１、状態管理情報１９２、クエリ実行データ１９３、及び、オブジェクト実行データ１９４を管理する。クエリ処理は、一つ以上のトランザクション処理を含んでおり、オブジェクト一覧情報１９０、トランザクション管理情報１９１及び状態管理情報１９２は、トランザクション処理毎に存在する。クエリ実行データ１９３は、クエリ毎に存在する。図示しないが、クエリと当該クエリに対応した一つ以上のトランザクション処理（ＴｘＩＤ）との対応関係を示す情報もＤＢＭＳ１３０により管理されてよい。

オブジェクト一覧情報１９０は、当該情報１９０に対応するトランザクション処理に属する全ての処理オブジェクトの各々に関する情報を保持する。

トランザクション管理情報１９１は、当該情報１９１に対応するトランザクション処理に関する情報を保持する。本実施例では、トランザクション処理は、クエリ処理の開始から完了までにクライアント１９から発行される複数の要求（例えば、後述のCONNECT、PREPARE、OPEN、FETCH、CLOSE、DISCONNECT）にそれぞれ対応した複数の処理である。

状態管理情報１９２は、当該１９２に対応したトランザクション処理に属する全ての処理オブジェクトの各々の状態に関する情報を保持する。

クエリ実行データ１９３は、クエリ処理の実行において得られたデータ、本実施例では、ハッシュ表である。

オブジェクト実行データ１９４は、クエリ処理の並列度Ｎ分存在する。例えば、Ｎ＝４であれば、第１〜第４のオブジェクト実行データ１９４が存在する。オブジェクト実行データ１９４は、処理オブジェクトの実行において得られたデータである（詳細の一例は図１０を参照して後に説明する）。

以上が、本実施例に係るシステム全体についての説明である。

図２に示したシステムにおいて、一つのクエリの受け付けは、図３に例示するように、CONNECT要求の受け付けにより開始される。DECLARE CURSOR要求及びOPEN要求の受け付けにより実行プランが生成される。一つ以上のFETCH要求の受け付けにより実行プランに基づくクエリ処理が実行される。CLOSE要求及びDISCONNECT要求の受け付けにより当該一つのクエリについての処理が終了する。

ここで、図４に例示するように、クエリ処理の実行中に（例えば、FETCH要求が受け付けられてからFETCH応答（FETCH要求に対する応答）が返る前に）中断命令受付部１３４が当該クエリ処理の中断命令を受け付けると、当該クエリ処理が中断する。中断命令は、クライアント１９から発行されてもよいし、ＤＢサーバ１００内で発行されてもよい。中断命令には、例えば、ＴｘＩＤ（中断対象とされるトランザクション処理のＩＤ）と、中断所要時間ｔとが指定される。ここでは、ＴｘＩＤは、FETCH要求に従うトランザクション処理のＩＤである。

中断命令に応答して、クエリ実行部１３３が、中断命令が受け付けられてから中断所要時間ｔ以内にクエリ処理を中断し、中断されたトランザクション処理のＴｘＩＤを含みクエリ処理の中断を示す中断通知を、クエリ処理の再開主体に送信する。本実施例では、「再開主体」は、クエリ発行元の一例であるクライアント１９であり、「中断通知」は、FETCH応答が兼ねる。このように、本実施例では、効率的なクエリ中断の通知が行われる。クライアント１９は、中断通知を兼ねたFETCH応答を受けた場合、DISCONNECT要求を送信する。

中断通知に含まれているＴｘＩＤが、再開主体によって、クエリ処理の再開に使用される。本実施例では、FETCH応答から得られたＴｘＩＤを含むFETCH要求（言い換えれば、再開指示を兼ねたFETCH要求）がクライアント１９から送信され、当該FETCH要求に応答して、再開処理（当該ＴｘＩＤを用いて中間管理情報５２がクエリ実行部１３３により読み込まれることを含む処理）を経て、クエリ処理が再開する。

図５は、本実施例におけるクエリの一例を示す。図６は、図５に例示のクエリに基づく実行プランの一例を示す。実行プランは、複数（又は一つ）のブロック６０に分割される。ブロック６０は、同時実行可能な処理範囲であり一つ以上のデータベース演算子で構成されている。各ブロック６０について、当該ブロック６０を構成する一つ以上の処理オブジェクトが存在する。

図７は、オブジェクト一覧情報１９０の一例を示す。

オブジェクト一覧情報１９０は、当該情報１９０に対応するトランザクション処理のＩＤを示すＴｘＩＤ７０１の他に、当該トランザクション処理に属する処理オブジェクト毎にエントリを有する。各エントリは、オブジェクトＩＤ７０２、時間コスト７０３、ブロックＩＤ７０４及び対象データ７０５といった情報を保持する。以下、一つの処理オブジェクトを例に取る（図７の説明において「注目オブジェクト」）。

オブジェクトＩＤ７０２は、注目オブジェクトのＩＤを示す。図７の例によれば、注目オブジェクトのＩＤは、注目オブジェクトが属するブロックのＩＤと、当該ブロックにおける注目オブジェクトの通し番号との組合せである（例えば、注目オブジェクトが、ブロックＡにおける１番目の処理オブジェクトであれば、オブジェクトＩＤは、“Ａ−１”である）。時間コスト７０３は、注目オブジェクトの時間コスト、すなわち、注目オブジェクトの実行に要する時間（例えば単位は「分」）を示す。ブロックＩＤ７０４は、注目オブジェクトが属するブロックのＩＤを示す。対象データ７０５は、注目オブジェクトの実行によってアクセスされるデータを示す。図７において、「セグメント」とは、表や索引のようなデータベース構成要素の一部を意味、具体的には、例えば、一つ以上のレコードの全部又は一部、或いは、一つ以上のカラムの全部又は一部を意味する。本実施例では、「セグメント」とは、複数のレコードを意味する。

注目オブジェクトの時間コストは、既存技術を利用して算出可能である。例えば、注目オブジェクトの時間コストは、下記のうちのいずれかにより算出可能である。
（ｘ１）読込みサイズ÷Ｉ／Ｏスループット
（ｘ２）件数÷処理スループット
（ｘ３）（ｘ１）及び（ｘ２）のうちの大きい方

「読込みサイズ」は、注目オブジェクトの対象データ７０５が示すデータ（例えばＬＩＮＥＩＴＥＭ表のセグメント#1〜#10）のサイズである。「件数」は、注目オブジェクトの対象データ７０５が示すセグメントに格納したレコードの総数である。「Ｉ／Ｏスループット」は、単位時間当たりに入出力されるデータのサイズである。「処理スループット」は、単位時間当たりに処理されるレコードの数である。Ｉ／Ｏスループットや処理スループットは、事前に定義された値でもよいし、過去の実行履歴から算出された値でもよい。

また、本実施例では、クエリに関する全ての処理オブジェクトはクエリ処理の開始前に予めリストアップされるが、それに代えて、処理オブジェクトは、クエリ処理の実行に応じて動的に特定されてもよい。例えば、クエリ処理の実行において、クエリ実行部１３３は、処理オブジェクトを生成し、生成された処理オブジェクトを実行することでその処理オブジェクトに必要なデータの読込み要求を発行し、その結果に基づき新たな処理オブジェクトを実行する必要がある場合に当該新たな処理オブジェクトを生成してもよい。

図８は、トランザクション管理情報１９１の一例を示す。

トランザクション管理情報１９１は、当該情報１９１に対応するトランザクション処理ＩＤを示すＴｘＩＤ８０１の他に、当該トランザクション処理に対応した要求の種別を示す要求種別８０２と、当該トランザクション処理が中断の対象であるか否かを示す中断フラグ８０３と、クエリ処理の中断完了時刻を示す中断完了時刻８０４といった情報を保持する。

例えば、当該トランザクション処理のＴｘＩＤと、中断所要時間“３０分”を指定した中断命令を中断命令受付部１３４が２３：００に受け付けた場合、中断命令受付部１３４は、当該ＴｘＩＤと一致するＴｘＩＤ８０１を有するトランザクション管理情報１９１に関し、中断フラグ８０３を“ＯＮ”に変更し、中断完了時刻８０４“２３：３０”（受信時刻“２３：００”に中断所要時間“３０分”を加算した時刻）を設定する。つまり、中断命令が受け付けられたときに、中断完了時刻８０４が決まる。なお、時刻の単位は、時分以外の単位、例えば、年月日時分秒でもよい。

図９は、状態管理情報１９２の一例を示す。

状態管理情報１９２は、当該情報１９２に対応するトランザクション処理のＩＤを示すＴｘＩＤ９０１の他に、当該トランザクション処理に属する処理オブジェクト毎にエントリを有する。各エントリは、オブジェクトＩＤ９０２、状態９０３、開始時刻９０４及び終了時刻９０５といった情報を保持する。以下、一つの処理オブジェクトを例に取る（図９の説明において「注目オブジェクト」）。

オブジェクトＩＤ９０２は、注目オブジェクトのＩＤを示す。状態９０３は、注目オブジェクトの状態を示す。開始時刻９０４は、注目オブジェクトの開始時刻を示す。終了時刻９０５は、注目オブジェクトの終了時刻を示す。従って、注目オブジェクトが未完了の場合（すなわち、注目オブジェクトの状態９０３が“実行完了”ではない場合）、注目オブジェクトの終了時刻９０５は未設定である。

図９の例は、図１に例示の４並列が採用されている例である。図９の例によれば、ブロックＡが完了しているため、ブロックＢに属する処理オブジェクトの状態９０３は、“実行可”又は“実行中”である。また、ブロックＣに属する処理オブジェクトの状態９０３は、ブロックＢが完了するまで“実行不可”である。

また、本実施例では、クエリ処理は、ブロック単位で進む。或るブロックが開始されるときに、クエリ実行部１３３が、当該ブロックに属する各処理オブジェクトの開始時刻９０４を設定し、且つ、当該ブロックに属する処理オブジェクトが完了する都度に、当該処理オブジェクトの終了時刻９０５を設定する。

図１０は、ダンプの一例を示す。

図１０の例は、ブロックＢに属するノード３〜５の実行においてメモリ１５０に生成されるデータを示す（図６参照）。すなわち、ノード３に属する処理オブジェクトが実行されることで、スキャンデータ１００１が生成される。スキャンデータ１００１と、ブロックＡの結果として生成済のハッシュ表１００２とを用いて、ノード４に属する処理オブジェクトが実行されることで、ハッシュ結合結果１００３が生成される。ハッシュ結合結果１００３を用いて、ノード５に属する処理オブジェクトが実行されることで、集計結果１００４が生成される。

図１０の例では、ハッシュ表１００２が、上述のようにブロックＡの結果として生成済であり、クエリ実行データ１９３に含まれているデータである。スキャンデータ１００１、ハッシュ結合結果１００３及び集計結果１００４の少なくとも一部が、オブジェクト実行データ１９４に含まれるデータである。

ここで、ブロックＢの実行中にクエリ処理の中断が行われるとする。

ブロックＢに属する処理オブジェクトの中に、状態９０３が“中断（ＤＰ）”である処理オブジェクトがなければ、実行途中の情報であるダンプが存在しないため、ダンプの保存は行われない。なお、この場合、状態管理情報１９２（各“中断（ＳＳ）”が“実行完了”に変更された情報１９２）、及び、ハッシュ表１００２（クエリの実行状態に関する情報の一例）は、ストレージシステム１１０内の中間管理情報５２に保存される。また、完成した集計結果１００４があれば、当該表１００４が作業表５１に保存される。

ブロックＢに属する処理オブジェクトの中に、状態９０３が“中断（ＤＰ）”である処理オブジェクトがあれば、図１０に例示のデータ１００１、１００３及び１００４の全部又は一部を含んだダンプが、ストレージシステム１１０内の中間管理情報５２に保存される。また、状態管理情報１９２（例えば、少なくとも一つの“中断（ＤＰ）”を含んだ情報１９２）も、ストレージシステム１１０内の中間管理情報５２に保存される。なお、ダンプには、ハッシュ表１００２は含まれないでよい。ブロックＢに属する処理オブジェクトに固有の情報ではなく、クエリの実行状態に関する情報のためである。

以下、本実施例で行われる処理の一例を説明する。

図示は省略するが、本実施例では、例えば次の処理が行われる。すなわち、クエリ受付部１３１が、クエリをクライアント１９から受け付ける。プラン生成部１３２が、当該クエリの実行プランを生成する。クエリ実行部１３３が、当該実行プランに基づきクエリ処理を実行し、当該クエリ処理の結果を示す応答をクライアント１９に返す。図１１〜１６を参照して、クエリ処理に関する詳細説明を行う。

図１１は、クエリ処理のフローを示す。

クエリ実行部１３３が、再開指示（例えば、再開指示を兼ねたFETCH要求）があるか否かを判定する（Ｓ１１０１）。Ｓ１１０１の判定結果が真の場合（Ｓ１１０１：Ｙｅｓ）、クエリ実行部１３３は、再開処理を実行する（Ｓ１１０２）。再開処理は、再開に必要な情報（例えば、再開指示に関連付けられているＴｘＩＤに対応した情報）を中間管理情報５２から（必要があれば作業表５１からも）取得し当該取得した情報をメモリ１５０に復元する処理を含む。

Ｓ１１０１の判定結果が偽の場合（Ｓ１１０１：Ｎｏ）、又は、Ｓ１１０２の後、クエリ実行部１３３は、空きスレッド（処理オブジェクトが割り当てられていないスレッド）ができるまで待つ（Ｓ１１０３）。空きスレッドがあればＳ１１０３はスキップされる。また、或る処理オブジェクトが終了したことで空きスレッドが生じれば、Ｓ１１０３は終了する。

或る処理オブジェクトが終了した結果（例えば或るブロックが終了した結果）、状態９０３が“実行不可”である少なくとも一つの処理オブジェクトが実行可能である場合、クエリ実行部１３３は、当該処理オブジェクトの状態９０３を“実行不可”から“実行可”に変更する（Ｓ１１０４）。

現在実行中のトランザクション処理（例えば、現在実行中のブロックが属するトランザクション処理）に対応した中断フラグ８０３が“ＯＮ”の場合、クエリ実行部１３３は、予想完了時刻が中断完了時刻以前の実行可オブジェクト（状態９０３が“実行可”の処理オブジェクト）があれば、当該実行可オブジェクトの状態９０３を“実行可”から“中断（ＳＳ）”に変更する（Ｓ１１０５）。なお、当該オブジェクトの予想完了時刻は、当該オブジェクトの開始時刻９０４に当該オブジェクトの時間コスト７０３を加算することで得られた時刻である。また、中断フラグ８０３が“ＯＦＦ”の場合、Ｓ１１０５はスキップされる。

クエリ実行部１３３は、状態管理情報１９２から、条件を満たす処理オブジェクト、具体的には、状態９０３が“実行可”又は“中断（ＳＳ）”の処理オブジェクトを探す（Ｓ１１０６）。ここでは、“中断（ＳＳ）”が“実行可”よりも優先されてもよい。“中断（ＳＳ）”の方が、実行が開始されれば中断完了時刻８０４までに完了する可能性が高いことが期待されるからである。

条件を満たす処理オブジェクトが見つかれば（Ｓ１１０７：Ｙｅｓ）、クエリ実行部１３３は、当該処理オブジェクトに空きスレッドを割り当て、当該処理オブジェクトを実行する（Ｓ１１０８）。Ｓ１１０５〜Ｓ１１０８によれば、状態９０３が“実行中”の処理オブジェクトに加えて、元は状態９０３が“実行可”であった処理オブジェクトであり、予想完了時刻が中断完了時刻以前の処理オブジェクトについても実行が開始されることになる。これにより、中断完了時刻までになるべく多くの処理オブジェクトの実行を完了させられることが期待できる。なお、実行開始された処理オブジェクトのブローは、図１２及び図１３に示す通りである。

条件を満たす処理オブジェクトが見つからなければ（Ｓ１１０７：Ｎｏ）、クエリ実行部１３３は、実行中のスレッドがあるか否かを判定する（Ｓ１１０９）。Ｓ１１０９の判定結果が真の場合（Ｓ１１０９：Ｙｅｓ）、処理がＳ１１０３に戻る。

Ｓ１１０９の判定結果が偽の場合（Ｓ１１０９：Ｎｏ）、中断フラグ８０３が“ＯＮ”であれば、クエリ実行部１３３は、状態管理情報１９２及びハッシュ表１００２を中間管理情報５２に保存する（Ｓ１１１０）。これは、ダンプ保存が実行されるか否かに関わらず、クエリ処理の中断に共通の処理である。なお、中断フラグ８０３が“ＯＦＦ”の場合、Ｓ１１１０はスキップされる。

図１２及び図１３は、処理オブジェクトの実行のフローを示す。図１４は、図１３における中断判定処理のフローを示す。図１２〜図１４の説明では、一つの処理オブジェクトを例に取る（図１２〜図１４の説明において「注目オブジェクト」）。

クエリ実行部１３３は、注目オブジェクトが属するトランザクション処理に対応した中断フラグ８０３が“ＯＮ”か否かを判定する（Ｓ１２０１）。

Ｓ１２０１の判定結果が偽の場合（Ｓ１２０１：Ｎｏ）、クエリ実行部１３３は、注目オブジェクトに対応した対象データ７０５を参照し（Ｓ１２０４）、対象データ７０５が示すデータのうち少なくとも一部の未処理データ（例えば少なくとも一つの未処理セグメント）が存在するか否かを判定する（Ｓ１２０３）。Ｓ１２０３の判定結果が偽の場合（Ｓ１２０３：Ｎｏ）、注目オブジェクトが完了する。Ｓ１２０３の判定結果が真の場合（Ｓ１２０３：Ｙｅｓ）、クエリ実行部１３３は、注目オブジェクトが属するデータベース演算子に従い、少なくとも一部のデータを処理する（Ｓ１２０４）。Ｓ１２０４の後、処理がＳ１２０１に戻る。注目オブジェクトの実行中に、注目オブジェクトが属するトランザクション処理のＴｘＩＤを指定した中断命令が受け付けられ、中断フラグ８０３が“ＯＮ”に変更されることがあり得る。

Ｓ１２０１の判定結果が真の場合（Ｓ１２０１：Ｙｅｓ）、クエリ実行部１３３は、中断判定処理を行う（Ｓ１３０１）。

中断判定処理の結果、注目オブジェクトの状態が“中断（ＳＳ）”であれば（Ｓ１３０２：Ｙｅｓ）、クエリ実行部１３３は、注目オブジェクトの実行を継続する。すなわち、クエリ実行部１３３は、注目オブジェクトに対応した対象データ７０５を参照し（Ｓ１３０３）、対象データ７０５が示すデータのうち少なくとも一部の未処理データが存在するか否かを判定する（Ｓ１３０４）。Ｓ１３０４の判定結果が真の場合（Ｓ１３０４：Ｙｅｓ）、クエリ実行部１３３は、注目オブジェクトが属するデータベース演算子に従い、少なくとも一部のデータを処理する（Ｓ１３０５）。Ｓ１３０５の後、処理がＳ１３０３に戻る。Ｓ１３０４の判定結果が偽の場合（Ｓ１３０４：Ｎｏ）、注目オブジェクトが完了する。なお、ここでは、注目オブジェクトが属するクエリ、ブロック、ノード及びデータベース演算子の少なくとも一つに依存する所定の情報がストレージシステム１１０内の作業表５１及び中間管理情報５２の少なくとも一方に保存されてもよい。しかし、当該所定の情報の情報量は、通常、いずれの処理オブジェクトのダンプの情報量よりも小さい。

中断判定処理の結果、注目オブジェクトの状態が“中断（ＳＳ）”であれば（Ｓ１３０２：Ｙｅｓ）、クエリ実行部１３３は、注目オブジェクトの実行継続を止め、注目オブジェクトの実行途中の情報を含んだダンプをストレージシステム１１０内の中間管理情報５２に保存する（Ｓ１３０６）。なお、Ｓ１３０６で保存されるダンプは、注目オブジェクトが属するクエリ、ブロック、ノード及びデータベース演算子の少なくとも一つに依存する。

図１４は、中断判定処理のフローを示す。

クエリ実行部１３３は、注目オブジェクトの開始時刻９０４に注目オブジェクトの時間コスト７０３を加えることで、注目オブジェクトの予想完了時刻を算出する（Ｓ１４０１）。注目オブジェクトの時間コスト７０３は、注目オブジェクトが属するデータベース演算子に関する情報を基に決定された値であるため、注目オブジェクトの予想完了時刻は、注目オブジェクトが属するデータベース演算子に関する情報を基に予想された完了時刻である。

クエリ実行部１３３は、Ｓ１４０１で算出された予想完了時刻が中断完了時刻８０４以前か否かを判定する（Ｓ１４０２）。

Ｓ１４０２の判定結果が真の場合（Ｓ１４０２：Ｙｅｓ）、クエリ実行部１３３は、注目オブジェクトの状態９０３を“中断（ＳＳ）”に変更する（Ｓ１４０３）。

一方、Ｓ１４０２の判定結果が偽の場合（Ｓ１４０２：Ｎｏ）、クエリ実行部１３３は、注目オブジェクトの状態９０３を“中断（ＤＰ）”に変更する（Ｓ１４０４）。

クエリ処理において一つ以上の処理オブジェクトの各々について中断判定処理が行われることで、図９に例示の状態管理情報１９２が、図１５に例示の状態管理情報１９２となる。

図１１〜図１４によれば、状態９０３が“中断（ＳＳ）”の処理オブジェクトは、実行が継続され（又は新たに実行が開始され）、中断完了時刻までに当該オブジェクトが完了する。

しかし、処理オブジェクトの予想完了時刻は、必ずしも正確ではなく、故に、当該処理オブジェクトの完了は、予想完了時刻よりも遅れることがあり得る。この場合、クエリ処理の中断が中断完了時刻までに完了しない。

そこで、本実施例では、中断再判定処理を実行する上述の中断再判定部１３５が備えられている。

図１６は、中断再判定処理の流れを示す。図１６の説明では、状態９０３が“実行完了”以外の一つの処理オブジェクトを例に取る（図１６の説明において「注目オブジェクト」）。本実施例に係る中断再判定処理は、クエリ処理とは別の処理であり、例えばクエリ処理の実行中に定期的に行われる。このため（例えばＳ１１０５が実行された場合）、Ｓ１３０１の中断判定処理が行われていない処理オブジェクトについて中断再判定処理が実行されることもあり得る。

中断再判定部１３５が、注目オブジェクトの状態９０３が“中断（ＳＳ）”であるか否かを判定する（Ｓ１６０１）。Ｓ１６０１の判定結果が偽の場合（Ｓ１６０１：Ｎｏ）、処理が終了する。

Ｓ１６０１の判定結果が真の場合（Ｓ１６０１：Ｙｅｓ）、中断再判定部１３５は、注目オブジェクトの開始時刻９０４に注目オブジェクトの時間コスト７０３を加えることで、注目オブジェクトの予想完了時刻を算出する（Ｓ１６０２）。なお、注目オブジェクトについてＳ１３０１で算出済の予想完了時刻がオブジェクト一覧情報１９０及び状態管理情報１９２の少なくとも一方の情報に関連付けられていて、当該情報から予想完了時刻が特定可能であれば、Ｓ１６０２がスキップされてよい。

中断再判定部１３５は、Ｓ１６０２で算出された予想完了時刻が現在時刻よりも前か否かを判定する（Ｓ１６０３）。但し、ここでの「現在時刻」は、中断完了時刻よりも前である。

Ｓ１６０３の判定結果が真の場合（Ｓ１６０３：Ｙｅｓ）、中断再判定部１３５は、注目オブジェクトの状態９０３を“中断（ＳＳ）”から“中断（ＤＰ）”に変更する（Ｓ１６０６）。Ｓ１６０３：Ｙｅｓは、注目オブジェクトが完了しないまま現在時刻を過ぎたということを意味し、中断完了時刻までにクエリ処理を中断するためには、このような注目オブジェクトについては実行途中で中断した方が適切であるためである。

Ｓ１６０３の判定結果が偽の場合（Ｓ１６０３：Ｎｏ）、中断再判定部１３５は、注目オブジェクトの進捗を基に、注目オブジェクトの予想完了時刻を補正する（Ｓ１６０４）。具体的には、例えば、中断再判定部１３５は、スキャンしたセグメント数と処理したセグメント数から進捗率を算出し、進捗率と経過時間（注目オブジェクトの開始時刻９０４から現在時刻までの時間）から、残りの時間コストを算出し、当該時間コストを基に、補正後の予想完了時刻を算出する。

中断再判定部１３５は、補正後の予想完了時刻が現在時刻よりも前か否かを判定する（Ｓ１６０５）。

Ｓ１６０５の判定結果が偽の場合（Ｓ１６０５：Ｎｏ）、処理が終了する。すなわち、中断再判定部１３５は、注目オブジェクトの状態９０３が“中断（ＳＳ）”であることを維持する。

Ｓ１６０５の判定結果が真の場合（Ｓ１６０５：Ｙｅｓ）、中断再判定部１３５は、注目オブジェクトの状態９０３を“中断（ＳＳ）”から“中断（ＤＰ）”に変更する（Ｓ１６０６）。

このような中断再判定処理が実行されることで、中断命令が受け付けられた以降も実行が継続される（又は新たに実行が開始される）が中断完了時刻までに完了しない処理オブジェクトが生じないようにすることが期待できる。

以上が、実施例１の説明である。各処理オブジェクトについて、時間コストは、図７を参照して説明した方法に従い算出されることに代えて又は加えて、当該処理オブジェクトが属するデータベース演算子の実行時間を基に算出されてよい。各データベース演算子について、実行時間は、例えば下記のうちの少なくとも一つに基づく。以下、一つのデータベース演算子を例に取る（以下、「対象データベース演算子」と言う）。
・対象データベース演算子によってアクセスされる（Ｉ／Ｏがされる）表部分のサイズ、及び、当該表部分を格納した記憶領域の容量、の少なくとも一方。表部分のサイズは、例えば、当該表部分を構成するレコードの数と、一つのレコードのサイズとに基づく。表部分を格納した記憶領域の容量は、例えば、当該表部分を格納するページの数と、一つのページのサイズとに基づく。一つ以上の永続記憶デバイスに基づく論理的な記憶領域がデータベース領域として提供され、データベース領域が、複数のページで構成され、ページ単位でアクセスがされてよい。
・対象データベース演算子でのスループット、及び、対象データベース演算子でのレイテンシ、のうちの少なくとも一方。対象データベース演算子でのスループットは、例えば、対象データベース演算子に関わる複数の機器（例えば、ストレージシステム１１０、永続記憶デバイス、ネットワーク１６０及びＤＢサーバ１００のうちの一つ以上の機器）にそれぞれ対応した複数のスループットのうちの最小値でよい。最小のスループットの機器が対象データベース演算子のボトルネックとなり得るからである。対象データベース演算子でのレイテンシも、例えば、対象データベース演算子に関わる複数の機器にそれぞれ対応した複数のレイテンシのうちの最小値でよい。

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

実施例２では、中断命令に、消費電力上限の指定が可能である。受け付けられた中断命令に消費電力上限が指定されている場合、クエリ処理の中断において消費される電力が消費電力上限以下に維持される。

以下、実施例２を詳細に説明する。

図１７は、実施例２に係るトランザクション管理情報の一例を示す。

実施例２に係るトランザクション管理情報１７００は、図８に示した情報８０１〜８０４に加えて、消費電力上限を示す情報である消費電力上限１７０１を保持する。受け付けられた中断命令に消費電力上限が指定されている場合、当該消費電力上限が、消費電力上限１７０１としてトランザクション管理情報１７００に設定される。

図１８は、実施例２に係るデータ配置の一例を示す。

実施例２に係るストレージシステム１１０は、ボリューム１８０１Ａ〜１８０１Ｅ（複数のボリューム１８０１の一例）を提供する。ボリューム１８０１Ａ〜１８０１Ｅの各々について、当該ボリューム１８０１の基になる一つ以上の永続記憶デバイスは、当該ボリューム１８０１以外のボリュームの基にはなっていない。各ボリューム１８０１について、当該ボリュームの基になる一つ以上の永続記憶デバイスの各々は、消費電力に関する状態として、アクティブ状態（Ｉ／Ｏ可能な状態）と、省電力状態（アクティブ状態に比べて消費電力が低い状態）とがある。省電力状態としては、複数種類の省電力状態が用意されていてもよい。

ボリューム１８０１Ａ〜１８０１Ｅの各々にも、消費電力に関する状態として、アクティブ状態と省電力状態とがある。ボリューム１８０１の状態がアクティブ状態の場合、当該ボリューム１８０１の基になる各永続記憶デバイスの状態もアクティブ状態である。ボリューム１８０１の状態が省電力状態の場合、当該ボリューム１８０１の基になる各永続記憶デバイスの状態も省電力状態である。

図１８の例によれば、ボリューム１８０１Ａに、ＬＩＮＥＩＴＥＭ表５０Ｂの一部が配置されており、ボリューム１８０１Ｂに、ＬＩＮＥＩＴＥＭ表５０Ｂの残りが配置されている。ボリューム１８０１Ｃに、ＯＲＤＥＲＳ表５０Ａの一部が配置されており、ボリューム１８０１Ｄに、ＯＲＤＥＲＳ表５０Ａの残りが配置されている。ボリューム１８０１Ｅに、作業表５１及び中間管理情報５２が配置されている。

図１９は、実施例２に係るオブジェクト一覧情報の一例を示す。

実施例２に係るオブジェクト一覧情報１９００において、各エントリは、情報７０２〜７０５の他に、電力コスト１９０１及びボリュームＩＤ１９０２といった情報も保持する。以下、一つの処理オブジェクトを例に取る（図１９の説明において「注目オブジェクト」）。

電力コスト１９０１は、注目オブジェクトに関わる消費電力の一例であり、注目オブジェクトの実行において消費されると予想される最大の消費電力を示す。電力コスト１９０１は、例えば、実行プランの生成において算出されてよい。また、電力コスト１９０１は、例えば、注目オブジェクトが属するデータベース演算子が関わる消費電力に基づいてよい。なお、各データベース演算子について、消費電力は、例えば下記に基づく。以下、一つのデータベース演算子を例に取る（以下、「対象データベース演算子」と言う）。
・対象データベース演算子の実行においてアクセスされる一つ以上の永続記憶デバイスの消費電力と、対象データベース演算子の実行に関わる計算リソースの消費電力と、当該一つ以上の永続記憶デバイスを有する一つ以上の装置の消費電力とのうちの少なくとも一つ。例えば、対象データベース演算子の消費電力は、対象データベース演算子に関わる複数の機器（例えば、ストレージシステム１１０、永続記憶デバイス、ネットワーク１６０及びＤＢサーバ１００のうちの一つ以上の機器）にそれぞれ対応した複数の消費電力の総和でよい。

ボリュームＩＤ１９０２は、注目オブジェクトの実行によりアクセスされる一つ以上のボリュームの各々のＩＤを示す。

図２０は、実施例２に係る状態管理情報の一例を示す。

実施例２に係る状態管理情報２０００では、処理オブジェクトの状態９０３として、“中断（ＳＳ）”及び“中断（ＤＰ）”の他に、“中断（Ｗａｉｔ）”がある。実施例１では、４並列で処理オブジェクトを実行可能であるが、本実施例では、４並列で処理オブジェクトを実行すると、当該オブジェクトが属するトランザクション処理に対応した消費電力上限１７０１を消費電力が超える場合には、一部の処理オブジェクトの状態９０３が、“中断（Ｗａｉｔ）”とされる。

本実施例では、消費電力上限が指定されており、且つ、中断命令が受け付けられてから前記中断完了時刻までの間に、予想完了時刻が中断完了時刻以前である一つ又は複数のスナップショット中断オブジェクト対象オブジェクト（状態９０３が“実行可”又は“中断（ＳＳ）”である処理オブジェクト）がある場合、クエリ実行部１３３は、当該一つ又は複数の対象オブジェクトの各々に関わる電力コスト１９０１を基に、当該一つ又は複数の対象オブジェクトから、スナップショット中断を意味する状態に変更される一つ以上の対象オブジェクトを決定する。これにより、中断命令を受け付けてから中断完了時刻までの間のいずれの時点においても消費電力を消費電力上限１７０１以下に維持することができる。

また、本実施例では、クエリ実行部１３３は、複数の対象オブジェクトのうち、同じ計算リソースに関わる二つ以上の対象オブジェクトがあれば、当該二つ以上の対象オブジェクトのいずれも、スナップショット中断を意味する状態に変更される対象オブジェクトに決定する。これにより、クエリ処理の中断において消費電力上限１７０１以下の範囲でなるべく多くの処理オブジェクトを中断完了時刻までに実行することができる。

本実施例で行われる処理の詳細の一例は、例えば下記の通りである。なお、下記の説明において、スナップショット中断オブジェクトは、対象オブジェクトの一例である。
（Ａ）並列実行可能な複数のスナップショット中断オブジェクトがある場合、クエリ実行部１３３は、当該複数のスナップショット中断オブジェクトのアクセス先がそれぞれ異なる複数のボリューム１８０１であれば、消費電力を、当該複数のスナップショット中断オブジェクトにそれぞれ対応した複数の電力コスト１９０１の和とする。消費電力が消費電力上限１７０１以下であれば、クエリ実行部１３３は、当該複数のスナップショット中断オブジェクトを並列に実行する。クエリ実行部１３３は、アクセス先ボリューム（計算リソースの一例）が同じである二つ以上のスナップショット中断オブジェクトをアクセス先ボリュームが異なる二つ以上のスナップショット中断オブジェクトよりも優先的に実行してもよい。
（Ｂ）並列実行可能な複数のスナップショット中断オブジェクトにそれぞれ対応した複数の電力コスト１９０１の和が消費電力上限１７０１を超えているとしても、当該複数のスナップショット中断オブジェクトのうちの二つ以上のスナップショット中断オブジェクトのアクセス先が同一のボリューム１８０１の場合、クエリ実行部１３３は、当該二つ以上のスナップショット中断オブジェクトの消費電力を、当該二つ以上のスナップショット中断オブジェクトにそれぞれ対応した二つ以上の電力コスト１９０１の最大値とし、当該最大値と、他のスナップショット中断オブジェクトの電力コスト１９０１とを基に、消費電力を算出してもよい。当該算出された消費電力が消費電力上限１７０１以下であれば、クエリ実行部１３３は、当該複数のスナップショット中断オブジェクトを並列に実行する。
（Ｃ）並列実行可能な複数のスナップショット中断オブジェクトがある場合、（Ａ）及び（Ｂ）のうちのいずれにおいても、消費電力が消費電力上限１７０１を超える場合、クエリ実行部１３３は、一部のスナップショット中断オブジェクトの状態９０３を“中断（Ｗａｉｔ）”に変更する。待ち時間は、当該一部のスナップショット中断オブジェクトの予想完了時刻に加算される。その結果、予想完了時刻が中断完了時刻を超えるスナップショット中断オブジェクトが生じたならば、クエリ実行部１３３は、当該オブジェクトの状態９０３を“中断（ＤＰ）”に変更する。図１８図１９の例によれば、ダンプ保存は、ボリューム１８０５Ｅへの書込みである。ダンプ保存が実行される場合、ダンプ保存について定義された最大消費電力であるダンプ電力が、消費電力に加算される。クエリ実行部１３３は、消費電力を、消費電力上限１７０１からダンプ電力を減じた電力以下に維持してもよい。クエリ処理の中断においてダンプ保存がいつ生じてもよいようにするためである。

この（Ａ）乃至（Ｃ）の具体例の一つは、図１７〜図２０によれば、次の通りである。すなわち、アクセス先ボリュームが同じであるスナップショット中断オブジェクトＢ−２及びＢ−４と、アクセス先ボリュームが同じであるスナップショット中断オブジェクトＢ−１及びＢ−５のうち、クエリ実行部１３３は、スナップショット中断オブジェクトＢ−２及びＢ−４を並列に実行し、スナップショット中断オブジェクトＢ−１及びＢ−５を待ちとする（状態９０３を“中断（Ｗａｉｔ）”に変更する）。スナップショット中断オブジェクトＢ−１及びＢ−５を実行しない理由は、スナップショット中断オブジェクトＢ−２及びＢ−４を並列実行した場合の消費電力は２５０Ｗであり、スナップショット中断オブジェクトＢ−１及びＢ−５を並列実行した場合の消費電力も２５０Ｗであり、それらを並列に実行すると消費電力は合計５００Ｗとなり、消費電力上限１７０１“４００Ｗ”を超えるからである。また、スナップショット中断オブジェクトＢ−１及びＢ−５の状態９０３を“中断（ＤＰ）”ではなく“中断（Ｗａｉｔ）”とする理由は、スナップショット中断オブジェクトＢ−２及びＢ−４の予想完了時刻は２３：１２であり、その後にスナップショット中断オブジェクトＢ−１及びＢ−５を実行しても、中断完了時刻“２４：００”までに完了する見込みがあるからである。なお、もし、スナップショット中断オブジェクトＢ−１及びＢ−５が中断完了時刻までに終らない見込みであれば、クエリ実行部１３３は、スナップショット中断オブジェクトＢ−１及びＢ−５の状態９０３を“中断（ＤＰ）”に変更する。

以上が、実施例２の説明である。なお、実行プラン生成において消費電力を見積もったり、実行対象とする処理オブジェクトを決定したりすることには、例えば、特開２０１７−０４５３８１号公報（或いは、ＵＳ２０１８／０３２９４７７）に開示の技術を利用することができる。

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

実施例２でも、中断命令に、消費電力上限の指定が可能である。受け付けられた中断命令に消費電力上限が指定されている場合、クエリ処理の中断において消費される電力が消費電力上限以下に維持される。具体的には、例えば、実行プランのうち、一つ以上のデータベース演算子とそれの実行順序とで構成され中断完了時刻までに実行されるデータベース演算子までの実行プラン部分が、消費電力がより低い構成に変更される。

図２１は、実施例３に係るクエリ処理の一部を示す。図２２は、実施例３に係る状態管理情報の一例を示す。

図１１のＳ１１０４の後、クエリ実行部１３３は、現在実行中のトランザクション処理（例えば、現在実行中のブロックが属するトランザクション処理）に対応した中断フラグ８０３が“ＯＮ”か否かを判定する（Ｓ２１０１）。Ｓ２１０１の判定結果が偽の場合（Ｓ２１０１：Ｎｏ）、処理がＳ１１０５に進む（なお、中断フラグ８０３が“ＯＦＦ”のため、結果としてＳ１１０５がスキップされ処理がＳ１１０６に進む）。

Ｓ２１０１の判定結果が真の場合（Ｓ２１０１：Ｙｅｓ）、プラン生成部１３２が、中断命令が受け付けられてから中断完了時刻までの間において、状態９０３が“実行可”又は“実行不可”である一つ又は複数の処理オブジェクト（図２２に例示の状態管理情報２２００によれば、ブロックＢとブロックＣのいずれかに属する各処理オブジェクト）の各々の電力コスト１９０１を基に、中断完了時刻までに実行されるデータベース演算子までの実行プラン部分を変更する（Ｓ２１０２）。具体的には、例えば、プラン生成部１３２は、状態９０３が“実行可”又は“中断（ＳＳ）”である処理オブジェクトが属し状態９０３が“実行不可”である処理オブジェクトが属さないブロックの範囲で、実行プランを改めて探索し、現在の実行プランが示すアクセスパスよりも消費電力が小さいアクセスパスを示す実行プラン（部分的な実行プラン）が見つかれば、実行プランを新たに見つかった実行プランに変更する。

以上が、実施例３の説明である。なお、実行プラン（アクセスパス）の探索については、例えば、特開２０１８−１６９６４４号公報（或いは、ＵＳ２０１８／０２８５４２１）に開示の技術を利用することができる。

以上、幾つかの実施例を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。

１００…ＤＢサーバ

Claims (12)

1. クエリを受け付けるクエリ受付部と、
   前記受け付けたクエリに従う処理であるクエリ処理をデータベースに対して実行するクエリ実行部と、
   前記クエリ処理の中断完了時刻を先の時刻とした中断命令を受け付ける中断命令受付部と
   を備え、
   前記クエリ実行部は、前記中断命令が受け付けられた場合、前記中断命令が受け付けられてから前記中断完了時刻までの間に、
   予想完了時刻が前記中断完了時刻以前である対象オブジェクトがあれば、当該対象オブジェクトの状態をスナップショット中断を意味する状態に変更し、
   前記対象オブジェクトには、前記中断命令が受け付けられたときに実行中を意味する状態である処理オブジェクトが少なくとも該当し、
   スナップショット中断を意味する状態の処理オブジェクトであるスナップショット中断オブジェクトがあれば、前記中断完了時刻まで当該スナップショット中断オブジェクトを実行する、
   データベース管理システム。
2. 前記クエリ実行部は、予想完了時刻が前記中断完了時刻よりも後である対象オブジェクトがあれば、当該対象オブジェクトの状態をダンプ中断を意味する状態に変更し、
   ダンプ中断を意味する状態の処理オブジェクトであるダンプ中断オブジェクトがあれば、前記クエリ実行部は、当該オブジェクトの実行途中の情報を含んだダンプを保存することであるダンプ保存を実行する、
   請求項１に記載のデータベース管理システム。
3. 前記クエリ実行部は、予想完了時刻が現在時刻よりも前のスナップショット中断オブジェクトがあれば、当該スナップショット中断オブジェクトの状態をダンプ中断を意味する状態に変更する、
   請求項２に記載のデータベース管理システム。
4. 中断再判定部を更に備え、
   前記中断再判定部は、予想完了時刻が現在時刻より後のスナップショット中断オブジェクトがあれば、
   当該スナップショット中断オブジェクトの進捗を基に予想完了時刻を補正し、
   当該補正された予想完了時刻が現在時刻よりも前であれば、当該スナップショット中断オブジェクトの状態をダンプ中断を意味する状態に変更する、
   請求項２に記載のデータベース管理システム。
5. 前記対象オブジェクトには、実行可を意味する状態の処理オブジェクトも該当する、
   請求項１に記載のデータベース管理システム。
6. 前記中断命令が受け付けられてから前記中断完了時刻までの間に、状態が実行可に変わった処理オブジェクトの予想完了時刻が中断完了時刻以前であれば、前記クエリ実行部は、当該処理オブジェクトの状態をスナップショット中断を意味する状態に変更する、
   請求項５に記載のデータベース管理システム。
7. 一つ又は複数のデータベース演算子とデータベース演算子の実行順序の関係とを含む情報であり前記クエリ処理の実行のプランである実行プランを前記受け付けたクエリを基に生成するプラン生成部、
   を更に備え、
   各処理オブジェクトの予想完了時刻は、当該処理オブジェクトが属するデータベース演算子と当該処理オブジェクトの実行によってアクセスされるデータとを基に予想された完了時刻である、
   請求項１に記載のデータベース管理システム。
8. 前記実行プランは、一つ以上のブロックに分割され、
   前記一つ以上のブロックの各々は、同時実行可能な処理範囲であり一つ以上のデータベース演算子で構成されており、
   前記一つ以上のブロックの各々について、当該ブロックを構成する一つ以上の処理オブジェクトが存在する、
   請求項７に記載のデータベース管理システム。
9. 消費電力上限が指定されており、且つ、前記中断命令が受け付けられてから前記中断完了時刻までの間に、予想完了時刻が前記中断完了時刻以前である一つ又は複数の対象オブジェクトがある場合、前記クエリ実行部は、当該一つ又は複数の対象オブジェクトの各々に関わる消費電力を基に、当該一つ又は複数の対象オブジェクトから、スナップショット中断を意味する状態に変更される一つ以上の対象オブジェクトを決定する、
   請求項１に記載のデータベース管理システム。
10. 前記クエリ実行部は、前記複数の対象オブジェクトのうち、同じ計算リソースに関わる二つ以上の対象オブジェクトがあれば、当該二つ以上の対象オブジェクトのいずれも、スナップショット中断を意味する状態に変更される対象オブジェクトに決定する、
    請求項９に記載のデータベース管理システム。
11. 一つ又は複数のデータベース演算子とデータベース演算子の実行順序の関係とを含む情報であり前記クエリ処理の実行のプランである実行プランを前記受け付けたクエリを基に生成するプラン生成部、
    を更に備え、
    消費電力上限が指定されており、且つ、前記中断命令が受け付けられた場合、前記プラン生成部が、前記中断命令が受け付けられてから前記中断完了時刻までの間において、状態が実行可又はスナップショット中断である一つ又は複数の処理オブジェクトの各々が関わる消費電力を基に、一つ以上のデータベース演算子とそれの実行順序とで構成され前記中断完了時刻までに実行されるデータベース演算子までの実行プラン部分を変更する、
    請求項１に記載のデータベース管理システム。
12. データベースに対するクエリに従うクエリ処理の実行中に、当該クエリ処理の中断完了時刻を先の時刻とした中断命令が受け付けられた場合、前記中断命令が受け付けられてから前記中断完了時刻までの間に、
    予想完了時刻が前記中断完了時刻以前である対象オブジェクトがあれば、当該対象オブジェクトの状態をスナップショット中断を意味する状態に変更し、
    前記対象オブジェクトには、前記中断命令が受け付けられたときに実行中を意味する状態である処理オブジェクトが少なくとも該当し、
    スナップショット中断を意味する状態の処理オブジェクトであるスナップショット中断オブジェクトがあれば、前記中断完了時刻まで当該スナップショット中断オブジェクトを実行する、
    データベース管理方法。