(57)【要約】【課題】消費電力量を低減するデータベース管理システムを提供する。【解決手段】データベース管理システムが稼働するホスト計算機と、ストレージ装置の消費電力を低減するスリープ状態と、データを読み書き可能なアクティブ状態とを切り替える省電力機能を備えるストレージ装置とを含む計算機システムにおいて、ストレージ装置の消費電力を調整する指示を含む問い合わせを受け付け、受け付けた問い合わせを解析して、一つ以上の実行計画案を作成し、ストレージ装置の消費電力を調整する指示に基づいて、一つ以上の実行計画案を最適化することによって、実行計画を決定し、決定された実行計画に基づいて、ストレージ装置にデータの読み書きを指示する。【選択図】図１
2008210003.tif 000002
【特許請求の範囲】
【請求項１】
データベース管理システムが実行されるホスト計算機と、前記ホスト計算機とネットワークを介して接続され、前記データベース管理システムによって管理されるデータが格納されるストレージ装置とを備える計算機システムであって、
前記ホスト計算機は、前記ネットワークに接続されるインタフェースと、前記インタフェースに接続される演算装置と、前記演算装置に接続される主記憶装置と、を備え、
前記主記憶装置には、前記データベース管理システムが記憶され、
前記ストレージ装置は、前記データベース管理システムによって管理されるデータが格納される記憶部と、前記記憶部に格納されたデータの読み書きを制御する制御部と、を備え、
前記制御部は、
前記ストレージ装置の消費電力を低減するスリープ状態と、データを読み書き可能なアクティブ状態とを切り替える省電力機能を備え、
前記記憶部は、データが読み書きされる記憶領域として、前記ホスト計算機に提供されるボリュームが作成され、
前記データベース管理システムは、前記演算装置によって実行されることによって、
前記ストレージ装置の消費電力を調整する指示を含む問い合わせを受け付け、
前記受け付けた問い合わせを解析して、一つ以上の実行計画案を作成し、
前記ストレージ装置の消費電力を調整する指示に基づいて、前記一つ以上の実行計画案を最適化することによって、実行計画を決定し、
前記決定された実行計画に基づいて、前記制御部にデータの読み書きを指示することを特徴とする計算機システム。
【請求項２】
前記記憶部は、磁気ディスクドライブを含み、
前記スリープ状態は、前記磁気ディスクドライブの回転を停止又は減速させた状態であることを特徴とする請求項１に記載の計算機システム。
【請求項３】
前記制御部は、前記ボリュームが所定の時間アクセスされない場合に前記省電力機能を実行し、前記スリープ状態にすることを特徴とする請求項１に記載の計算機システム。
【請求項４】
前記制御部は、前記省電力機能の実行又は停止する電力制御命令を受け付けることによって、前記スリープ状態と前記アクティブ状態とを切り替え、
前記データベース管理システムは、前記作成された実行計画案に前記電力制御命令を付与することによって、前記ボリュームにアクセスする事前に前記ボリュームをアクティブ状態に切り替え、前記ボリュームにアクセスが完了した直後に前記ボリュームをスリープ状態に切り替えることを特徴とする請求項１に記載の計算機システム。
【請求項５】
前記制御部は、前記記憶部に作成されたボリュームの消費電力情報を保持し、
前記データベース管理システムは、
前記作成された実行計画案に基づいて、アクセスするボリュームを特定し、
前記アクセスするボリュームの消費電力情報に基づいて、前記実行計画を決定することを特徴とする請求項１に記載の計算機システム。
【請求項６】
前記ストレージ装置は、複数のホスト計算機によってアクセスされ、
前記制御部は、前記複数のホスト計算機によって決定された実行計画に基づいて、アクセス予定情報を保持し、
前記データベース管理システムは、
前記アクセス予定情報を前記制御部から取得し、
前記取得されたアクセス予定情報に基づいて、前記省電力機能を実行又は停止するタイミングを含む調停情報を前記実行計画案に付与し、
前記調停情報を含む実行計画案を最適化することによって、前記実行計画を決定することを特徴とする請求項４に記載の計算機システム。
【請求項７】
前記データベース管理システムは、前記問い合わせを複数受け付けた場合に、前記受け付けた複数の問い合わせについて、実行計画をそれぞれ決定し、前記決定された実行計画の処理の一部又は全部が、他の決定された実行計画の処理と重複する場合には、重複する処理を共有した実行計画を新たに作成することを特徴とする請求項１に記載の計算機システム。
【請求項８】
データベース管理システムが実行されるホスト計算機と、前記ホスト計算機とネットワークを介して接続され、前記データベース管理システムによって管理されるデータが格納されるストレージ装置とを備える計算機システムの省電力化方法であって、
前記ホスト計算機は、前記ネットワークに接続されるインタフェースと、前記インタフェースに接続される演算装置と、前記演算装置に接続される主記憶装置と、を備え、
前記主記憶装置には、前記データベース管理システムが記憶され、
前記ストレージ装置は、前記データベース管理システムによって管理されるデータが格納される記憶部と、前記記憶部に格納されたデータの読み書きを制御する制御部と、を備え、
前記制御部は、
前記ストレージ装置の消費電力を低減するスリープ状態と、データを読み書き可能なアクティブ状態とを切り替える省電力機能を備え、
前記記憶部は、データが読み書きされる記憶領域として、前記ホスト計算機に提供されるボリュームが作成され、
前記省電力化方法は、
前記演算装置が、前記ストレージ装置の消費電力を調整する指示を含む問い合わせを受け付け、
前記演算装置が、前記受け付けた問い合わせを解析して、一つ以上の実行計画案を作成し、
前記演算装置が、前記ストレージ装置の消費電力を調整する指示に基づいて、前記一つ以上の実行計画案を最適化することによって、実行計画を決定し、
前記演算装置が、前記決定された実行計画に基づいて、前記制御部にデータの読み書きを指示することを特徴とする省電力化方法。
【請求項９】
前記省電力化方法は、前記ボリュームに所定の時間アクセスされない場合に、前記制御部が、前記省電力機能を実行し、前記スリープ状態にすることを特徴とする請求項８に記載の省電力化方法。
【請求項１０】
前記省電力化方法は、
前記制御部が、前記省電力機能の実行又は停止する電力制御命令を受け付けることによって、前記スリープ状態と前記アクティブ状態とを切り替え、
前記演算装置が、前記作成された実行計画案に前記電力制御命令を付与することによって、前記ボリュームにアクセスする事前に前記ボリュームをアクティブ状態に切り替え、前記ボリュームにアクセスが完了した直後に前記ボリュームをスリープ状態に切り替えることを特徴とする請求項８に記載の省電力化方法。
【請求項１１】
前記省電力化方法は、
前記制御部が、前記記憶部に作成されたボリュームの消費電力情報を保持し、
前記演算装置が、前記作成された実行計画案に基づいて、アクセスするボリュームを特定し、
前記演算装置が、前記アクセスするボリュームの消費電力情報に基づいて、前記実行計画を決定することを特徴とする請求項８に記載の省電力化方法。
【請求項１２】
前記ストレージ装置は、複数のホスト計算機によってアクセスされ、
前記省電力化方法は、
前記制御部が、前記複数のホスト計算機によって決定された実行計画に基づいて、アクセス予定情報を保持し、
前記演算装置が、前記アクセス予定情報を前記制御部から取得し、
前記演算装置が、前記取得されたアクセス予定情報に基づいて、前記省電力機能の実行又は停止するタイミングを含む調停情報を前記実行計画案に付与し、
前記演算装置が、前記調停情報を含む実行計画案を最適化することによって、前記実行計画を決定することを特徴とする請求項１０に記載の省電力化方法。
【請求項１３】
前記省電力化方法は、前記演算装置が、前記問い合わせを複数受け付けた場合に、前記受け付けた複数の問い合わせについて、実行計画をそれぞれ決定し、前記決定された実行計画の処理の一部又は全部が、他の決定された実行計画の処理と重複する場合には、重複する処理を共有した実行計画を新たに作成することを特徴とする請求項８に記載の省電力化方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、計算機システムの省電力化技術に関し、特に、データベース管理システムにおける問い合わせ実行時の省電力化技術に関する。
【背景技術】
【０００２】
データベース管理システムでは、問い合わせ指示を受け付けると、問い合わせの実行計画を作成し、処理が実行される。従来技術においては、主記憶容量又は二次記憶容量などの利用可能な計算機資源の制約下において、処理性能が最大化されるように問い合わせ実行計画が生成されていた。
【０００３】
一方、今日では、計算機システムは、処理性能の向上に加え、消費電力の低減が求められている。そこで、非特許文献１には、ディスクドライブのスピンダウンなどの省電力機能が提案されている。
【非特許文献１】H. Yada,他7名 "Head positioning servo and data channel for HDDs with multiple spindle speeds" IEEE Transactions on Magnetics, 36(5), pp. 2213-2215. 2000.
【発明の開示】
【発明が解決しようとする課題】
【０００４】
しかし、データベース管理システムにおいて、問い合わせ実行計画は、ストレージ装置の省電力機能を考慮せずに生成されるため、消費電力を低減させるには不十分であった。
【０００５】
本発明は、データベース管理システムにおいて、省電力化機能を考慮して問い合わせ実行計画を最適化することによって、処理性能と消費電力量とを調整可能なシステムを提供することを目的とする。
【課題を解決するための手段】
【０００６】
本発明の代表的な実施形態では、データベース管理システムが実行されるホスト計算機と、前記ホスト計算機とネットワークを介して接続され、前記データベース管理システムによって管理されるデータが格納されるストレージ装置とを備える計算機システムであって、前記ホスト計算機は、前記ネットワークに接続されるインタフェースと、前記インタフェースに接続される演算装置と、前記演算装置に接続される主記憶装置と、を備え、前記主記憶装置には、前記データベース管理システムが記憶され、前記ストレージ装置は、前記データベース管理システムによって管理されるデータが格納される記憶部と、前記記憶部に格納されたデータの読み書きを制御する制御部と、を備え、前記制御部は、前記ストレージ装置の消費電力を低減するスリープ状態と、データを読み書き可能なアクティブ状態とを切り替える省電力機能を備え、前記記憶部は、データが読み書きされる記憶領域として、前記ホスト計算機に提供されるボリュームが作成され、前記データベース管理システムは、前記演算装置によって実行されることによって、前記ストレージ装置の消費電力を調整する指示を含む問い合わせを受け付け、前記受け付けた問い合わせを解析して、一つ以上の実行計画案を作成し、前記ストレージ装置の消費電力を調整する指示に基づいて、前記一つ以上の実行計画案を最適化することによって、実行計画を決定し、前記決定された実行計画に基づいて、前記制御部にデータの読み書きを指示する。
【発明の効果】
【０００７】
本発明の代表的な実施形態によれば、ストレージ装置の省電力機能が有効に機能するように実行計画を生成することによって、問い合わせ処理の消費電力を低減させることができる。
【発明を実施するための最良の形態】
【０００８】
以下、本発明の実施形態について図面を用いて説明する。
【０００９】
（第１の実施形態）
図１は、本発明の第１の実施形態の計算機システムの構成を示す図である。計算機システムは、ホスト計算機１、ストレージ装置２及びクライアント３を含む。
【００１０】
ホスト計算機１及びストレージ装置２は、ネットワーク５を介して互いに接続され、データを送受信する。ネットワーク５は、例えば、ＳＡＮ（Storage Area Network）である。ホスト計算機１及びクライアント３は、ネットワーク６を介して互いに接続される。なお、第１の実施形態では、ネットワーク５と、ネットワーク６とが、それぞれ独立した形態となっているが、双方の機能を兼ねる単一のネットワークであってもよい。
【００１１】
ホスト計算機１は、ストレージ装置２によって提供される記憶資源を利用して各種の業務処理を実行する。ホスト計算機１は、演算装置１０１、主記憶装置１０２、ネットワーク５に接続されるインタフェース１０３、及びネットワーク６に接続されるインタフェース１０４を備える。演算装置１０１、主記憶装置１０２、インタフェース１０３、及びインタフェース１０４は、内部バスを介して互いに接続される。
【００１２】
演算装置１０１は、主記憶装置１０２に記憶されたプログラムを実行することによって、各種業務処理を実行する。
【００１３】
主記憶装置１０２は、演算装置１０１によって実行される各種プログラム、及びプログラムの実行に必要なデータを記憶する。第１の実施形態では、アプリケーションプログラム１１０及びデータベース管理システム１２０が記憶される。
【００１４】
アプリケーションプログラム１１０は、演算装置１０１によって実行されることによって、ホスト計算機１に各種業務処理を実行させる。アプリケーションプログラム１１０は、例えば、Ｗｅｂアプリケーションなどである。
【００１５】
データベース管理システム１２０は、ストレージ装置２などに格納されたデータを管理する。データベース管理システム１２０は、問い合わせ受付部１２１、問い合わせ実行計画生成部１２２、問い合わせ実行計画最適化部１２３及び問い合わせ実行部１２４を含む。
【００１６】
問い合わせ受付部１２１は、外部又はアプリケーションプログラム１１０からのデータアクセス要求を受け付ける。また、問い合わせ受付部１２１は、要求されたデータを外部又はアプリケーションプログラム１１０に応答する。問い合わせ受付部１２１の処理の詳細は、図４にて後述する。
【００１７】
問い合わせ実行計画生成部１２２は、受け付けたデータアクセス要求に基づいて、要求されたデータを取得するための実行計画を作成する。問い合わせ実行計画は、例えば、アクセス対象の関係表及び索引から対象のデータを抽出する手順である。問い合わせ実行計画生成部１２２の処理の詳細は、図５にて後述する。
【００１８】
問い合わせ実行計画最適化部１２３は、問い合わせ実行計画生成部１２２によって作成された問い合わせ実行計画案を最適化する。最適化とは、一つ以上作成された問い合わせ実行計画案を検証及び修正し、所定の方針に基づいて、検証及び修正された問い合わせ実行計画案を選択することである。問い合わせ実行計画最適化部１２３の処理の詳細は、図７にて後述する。
【００１９】
問い合わせ実行部１２４は、最適化された問い合わせ実行計画に基づいて、関係表及び索引にアクセスし、要求されたデータを読み書きする。問い合わせ実行部１２４の処理の詳細は、図１５にて後述する。
【００２０】
ボリューム消費電力モデル情報表１２６は、問い合わせを実行する場合に消費される電力量を算出するための情報を格納する。ボリューム消費電力モデル情報表１２６の詳細は、図８にて後述する。
【００２１】
問い合わせ実行計画案実行コスト表１２７は、問い合わせ実行計画最適化部１２３の処理において、問い合わせ実行計画案の実行コストを一時的に格納するために用いられる。問い合わせ実行計画案実行コスト表１２７の詳細は、図１１にて後述する。
【００２２】
本発明の第１の実施形態では、アプリケーションプログラム１１０とデータベース管理システム１２０とが同じホスト計算機１に格納されているが、別の計算機に格納されていてもよい。
【００２３】
ストレージ装置２は、ホスト計算機１によって読み書きされるデータを格納する。ストレージ装置２は、制御部２０１、記憶部２０２及びインタフェース２０３を備える。また、ストレージ装置２には、図示しない電源部及び冷却部が含まれる。冷却部は、例えば、複数の冷却ファンによって構成される。電源部は、例えば、複数の電源モジュールによって構成される。
【００２４】
制御部２０１は、インタフェース２０３を介して受け付けたアクセス要求に基づいて、記憶部２０２に格納されたデータを外部に提供する。制御部２０１は、入出力処理部２１１及び自動電力制御部２１２を含む。
【００２５】
入出力処理部２１１は、記憶部２０２に格納されたデータのアクセス要求を受け付ける。また、入出力処理部２１１は、要求されたデータが取得されると、要求元にデータを送信する。
【００２６】
自動電力制御部２１２は、二次記憶装置２２２の電力消費を制御する。例えば、二次記憶装置２２２に一定時間アクセスされなかった場合に省電力機能を実行する。
【００２７】
記憶部２０２は、ホスト計算機１によって読み書きされるデータを格納する。記憶部２０２は、補助記憶装置２２１及び二次記憶装置２２２を備える。
【００２８】
補助記憶装置２２１は、二次記憶装置２２２に格納されたデータの読み書きを高速化するために一時的にデータを格納する記憶装置であって、いわゆるキャッシュメモリである。補助記憶装置２２１は、データを高速に読み書きすることができる。また、補助記憶装置２２１は、揮発性メモリであっても、不揮発性メモリであってもよい。具体的には、補助記憶装置２２１は、アクセスされるデータを予測してあらかじめ格納しておくことによって、二次記憶装置にアクセスせずに要求されたデータを提供することができる。
【００２９】
二次記憶装置２２２は、ホスト計算機１によってアクセスされるデータを格納する記憶装置である。二次記憶装置２２２には、大容量の記憶資源が用いられ、例えば、磁気ディスク装置が用いられる。
【００３０】
また、制御部２０１は、二次記憶装置２２２によって提供される複数の記憶領域を論理的に１つのボリューム２２３として、ホスト計算機１などに提供する。ホスト計算機１は、ボリューム２２３に対してデータを読み書きする。
【００３１】
クライアント３は、ネットワーク５を介して、ホスト計算機１に接続し、各種処理の実行を指示する。
【００３２】
図２は、本発明の第１の実施形態のボリュームに格納されるデータベースの構成要素を示す図である。
【００３３】
本発明の第１の実施形態では、ストレージ装置２に作成されたボリューム２２３は、データベース管理システム１２０によってアクセスされる関係表３０１及び索引３０２を格納する。
【００３４】
関係表３０１は、アプリケーションによって使用されるデータが格納される。本発明の第１の実施形態で用いられるデータベースは、関係データベースとする。関係データベースでは、１件のデータ（レコード）を複数のフィールドの集合とし、データの集合が表形式で表現される。
【００３５】
索引３０２は、各レコードを識別する項目と各レコードへのポインタで構成されたインデックスが格納される。インデックスを利用することによって、関係表３０１に格納されたレコードを高速に検索することができる。なお、レコードを挿入又は削除する場合には、レコードの他にインデックスを作成又は削除する必要があるため、処理性能が低下する場合がある。
【００３６】
なお、関係表３０１及び索引３０２は、同じボリューム２２３に格納する必要はなく、図２に示すように、一方のボリューム２２３に関係表３０１及び索引３０２を格納し、他方のボリュームには関係表３０１のみを格納してもよい。
【００３７】
図３は、本発明の第１の実施形態の問い合わせを受け付けてから回答を取得するまでの処理の流れを示す図である。図３では、ホスト計算機１で実行されたアプリケーションプログラム１１０の処理から、データベース管理システム１２０によって管理されるデータにアクセスする手順について説明する。ここでは、アプリケーションプログラム１１０が実行されることによって、データが取得される手順について説明する。
【００３８】
演算装置１０１は、まず、アプリケーションプログラム１１０が実行され、データベース管理システム１２０の問い合わせ受付部１２１にデータを取得するための問い合わせを送信する。
【００３９】
演算装置１０１は、問い合わせ受付部１２１にデータの問い合わせを受信すると、問い合わせ実行計画生成部１２２に問い合わせを送信する。
【００４０】
演算装置１０１は、問い合わせ実行計画生成部１２２が問い合わせを受信すると一つ以上の問い合わせ実行計画案を生成する。演算装置１０１は、問い合わせ実行計画最適化部１２３に生成された問い合わせ実行計画案を送信する。
【００４１】
演算装置１０１は、問い合わせ実行計画生成部１２２から問い合わせ実行計画案を問い合わせ実行計画最適化部１２３が受信すると、まず、問い合わせ実行計画の実行コストを算出する。そして、問い合わせの構造及び問い合わせに含まれるデータの性質などに基づいて、問い合わせ実行計画案を最適化し、問い合わせ実行計画とする。演算装置１０１は、最適化された問い合わせ実行計画を問い合わせ実行部１２４に送信する。
【００４２】
演算装置１０１は、最適化された問い合わせ実行計画を問い合わせ実行部１２４が受信すると、問い合わせ実行計画に基づいて、問い合わせを実行する。演算装置１０１は、ストレージ装置２の制御部２０１に対し、ネットワーク５を介して、データの入出力要求を送信する。
【００４３】
ストレージ装置２の制御部２０１は、受信した入出力要求に基づいて、記憶部２０２にデータの入出力を送信し、ボリューム２２３に格納された関係表３０１から、索引３０２に格納されたインデックス情報などを用いて、要求されたデータを取得する。
【００４４】
記憶部２０２は、要求されたデータを取得すると、取得されたデータを制御部２０１に送信する。制御部２０１は、受信したデータをホスト計算機１のデータベース管理システム１２０に含まれる問い合わせ実行部１２４に送信する。
【００４５】
演算装置１０１は、取得されたデータを問い合わせ実行部１２４が受信すると、問い合わせ受付部１２１に取得されたデータを送信する。演算装置１０１は、問い合わせ受付部１２１が取得されたデータを受信すると、アプリケーションプログラム１１０によって実行された処理に取得されたデータを送信する。
【００４６】
図４は、本発明の第１の実施形態の問い合わせ受付部１２１によって、問い合わせを受け付けてから、要求元にデータを回答するまでの手順を示すフローチャートである。
【００４７】
演算装置１０１は、問い合わせ受付部１２１の処理において、アプリケーションプログラム１１０からの問い合わせを受信すると（Ｓ４０１）、受信した問い合わせを問い合わせ実行計画生成部１２２に送信する（Ｓ４０２）。
【００４８】
演算装置１０１は、問い合わせの回答を問い合わせ実行部１２４から受信すると（Ｓ４０３）、アプリケーションプログラム１１０に問い合わせの回答を送信する（Ｓ４０４）。
【００４９】
このように、問い合わせ受付部１２１では、アプリケーションプログラム１１０からの問い合わせを受け付け、問い合わせの結果をアプリケーションプログラム１１０に回答する処理が実行される。
【００５０】
図５は、本発明の第１の実施形態の問い合わせ実行計画生成部１２２によって、問い合わせの実行計画を生成する手順を示すフローチャートである。
【００５１】
演算装置１０１は、問い合わせ実行計画生成部１２２の処理において、問い合わせ受付部１２１から問い合わせを受信すると（Ｓ５０１）、一つ以上の問い合わせ実行計画案を生成する（Ｓ５０２）。そして、生成された問い合わせ実行計画案を問い合わせ実行計画最適化部１２３に送信する（Ｓ５０３）。
【００５２】
なお、受信した問い合わせは、同じ結果を得ることができる異なった方法で実行することが可能であり、それぞれについて、問い合わせ実行計画案を生成することができる。
【００５３】
具体的には、問い合わせ実行計画生成部１２２は、まず、問い合わせに含まれる各テーブルを走査するための計画を生成する。そして、単一のテーブルを走査する計画を生成すると、各テーブルを結合するための計画を生成し、問い合わせ実行計画案とする。
【００５４】
ここで、具体的な問い合わせ（ＳＱＬ）に基づいて生成される問い合わせ実行計画案について、図６を用いて説明する。
【００５５】
図６は、本発明の第１の実施形態の問い合わせ実行計画生成部１２２によって生成された問い合わせ実行計画案の一例を示す図である。
【００５６】
問い合わせ６０１は、関係表Ｒ及び関係表Ｓを、共通のフィールド「ｉｄ」によって結合し、関係表Ｒ及び関係表Ｓのレコードを抽出し、抽出されたレコードを「ｉｄ」に基づいて整列するＳＱＬである。
【００５７】
演算装置１０１は、問い合わせ受付部１２１から送信された問い合わせ６０１を受信すると、問い合わせ実行計画生成部１２２の処理によって、問い合わせ６０１を実行するために複数の問い合わせ実行計画案が生成される。図６に示された問い合わせ実行計画案６１１、６１２及び６１３は、生成された問い合わせ実行計画案の一例である。
【００５８】
問い合わせ実行計画案６１１は、ステップ１として、関係表Ｒからハッシュ表を作成する。次に、ステップ２として、関係表Ｓを走査し、ハッシュ表Ｒ’と照合する。最後に、ステップ３として、照合結果を整列する。問い合わせ実行計画案６１１は、ハッシュ結合と呼ばれる。
【００５９】
問い合わせ実行計画案６１２は、ステップ１として、関係表Ｒを走査し、各行について、索引Ｓ’を参照して関係表Ｓを検索する。そして、ステップ２として、検索結果を整列する。問い合わせ実行計画案６１２は、ネステッドループ結合と呼ばれる。
【００６０】
問い合わせ実行計画案６１３は、ステップ１として、関係表Ｒを整列する。そして、ステップ２として、整列された関係表Ｒと、索引Ｓ’を参照して関係表Ｓを走査して照合する。問い合わせ実行計画案６１３は、整列併合（ソート＆マージ）結合と呼ばれる。
【００６１】
以上に示した問い合わせ実行計画案は、それぞれに長所短所があり、必要とされる性能に応じて選択される。
【００６２】
図７は、本発明の第１の実施形態の問い合わせ実行計画最適化部１２３によって、問い合わせ実行計画を最適化する手順を示すフローチャートである。
【００６３】
演算装置１０１は、問い合わせ実行計画生成部１２２によって生成された問い合わせ実行計画案を受信すると（Ｓ７０１）、各問い合わせ実行計画案について、実行コストの見積りを計算する（Ｓ７０２）。実行コストとは、例えば、レコードを取得するために必要とする実行時間など、処理性能を数値化したものである。本発明の第１の実施形態では、実行時間以外にも消費電力についても考慮して実行コストを計算する。なお、実行コストの見積りを計算する手順については、図８にて後述する。
【００６４】
演算装置１０１は、受信した問い合わせ実行計画案について、計算された実行コストの見積りに基づいて、問い合わせ実行計画を決定する（Ｓ７０３）。演算装置１０１は、決定された問い合わせ実行計画を問い合わせ実行部１２４に送信する（Ｓ７０４）。
【００６５】
図８は、本発明の第１の実施形態の問い合わせ実行計画最適化部１２３において、問い合わせ実行計画案の実行コストの見積りを算出する手順を示すフローチャートである。本処理は、受信したすべての問い合わせ実行計画案に対して実行される。
【００６６】
演算装置１０１は、見積り計算対象の問い合わせ実行計画案について、まず、実行性能についての実行コストの見積りを計算する（Ｓ８０１）。実行コストの計算では、一例として、データベースのカタログ情報（ディクショナリ）にある統計情報に基づいて、実行コストを計算する。統計情報には、例えば、関係表の行数、データの分布状況及びＩ／Ｏ性能などが含まれる。これらの値は、データベースに格納されたデータが更新されるたびに随時変化する。したがって、統計情報を定期的に更新することによって、格納されるデータの変化にも対応することができる。
【００６７】
続いて、演算装置１０１は、見積り計算対象の問い合わせ実行計画案について、消費電力についての実行コストの見積りを計算する（Ｓ８０２）。計算方法については、実行性能についての実行コストの計算と同様である。ただし、コスト計算の元となる統計情報は、一例として、図９にて後述するボリューム消費電力モデル情報表を用いる。
【００６８】
最後に、演算装置１０１は、計算された実行コストの見積りの値を図１０にて後述する問い合わせ実行計画案実行コスト表１２７に記録する（Ｓ８０３）。
【００６９】
図９は、本発明の第１の実施形態の問い合わせ実行計画最適化部１２３の処理において、問い合わせ実行計画案の実行コストを算出するために使用されるボリューム消費電力モデル情報表１２６を示す図である。なお、ボリューム消費電力モデル情報表１２６は、データベース管理システム１２０の内部に事前に設定されているが、ユーザによって別途設定されてもよい。
【００７０】
ボリューム消費電力モデル情報表に含まれる情報は、ボリュームの状態に応じた消費電力量、ボリュームの状態遷移に要する時間及び消費電力が含まれる。また、ボリュームのスリープ化などのいわゆる省電力モードを移行するまでの時間なども含まれる。
【００７１】
スリープ化とは、例えば、二次記憶装置２２２が磁気ディスクドライブである場合に、磁気ディスクドライブの回転を減速若しくは停止させること、又は、磁気ディスクドライブのヘッドの動作を停止させることなどをいう。
【００７２】
本発明のスリープ化には、二次記憶装置２２２以外のストレージ装置２の各部の消費電力を低減させることも含まれる。例えば、補助記憶装置２２１の一部の給電を停止し、補助記憶装置２２１の記憶容量を減らすことによって、消費電力を低減することができる。このように、補助記憶装置２２１の一部の給電を停止することもスリープ化に含む。
【００７３】
さらに、補助記憶装置２２１及び二次記憶装置２２２の一部が停止されている状態では、当該停止部位を冷却する冷却ファンを停止させてもよい。また、停止部位を制御する制御部２０１の給電を部分的に停止させてもよい。さらに、給電が停止されている部位に対応する電源モジュールを停止させてもよい。
【００７４】
また、ボリュームがスリープ化されている状態をスリープ状態という。一方、ボリュームにアクセスしている場合など、通常の稼働状態をアクティブ状態という。
【００７５】
図９を参照すると、レコード９０１から９０３には、ボリュームの状態に応じた単位時間当たりの消費電力が格納されている。また、レコード９０４及び９０５には、アクティブ状態及びスリープ状態に切替えるために必要な時間が格納されている。レコード９０６には、状態が遷移する際の平均消費電力が格納されている。さらに、レコード９０７には、アクティブ状態において、ボリュームに対しアクセスされない状態が継続している場合に、スリープ状態に遷移するまでの時間の閾値が格納されている。
【００７６】
図１０は、本発明の第１の実施形態のボリュームの状態遷移、ボリュームの状態ごとの消費電力量、及びボリュームの状態遷移の際の消費する電力量を示す図である。
【００７７】
各円は、ボリュームの状態を示している。また、各ボリュームの状態は、図９に示したボリューム消費電力モデル情報表１２６に基づいて、消費電力が記載されている。また、アクティブ状態及びスリープ状態に遷移する場合の所要時間及び消費電力についても、該当する矢印に対応して記載している。
【００７８】
図１１は、本発明の第１の実施形態の問い合わせ実行計画最適化部１２３によって記録される問い合わせ実行計画案実行コスト表１２７である。問い合わせ実行計画案実行コスト表１２７は、問い合わせ実行計画最適化部１２３の処理が開始されてから、実行される実行計画が決定されるまでの間、ホスト計算機１の主記憶装置１０２に格納される。
【００７９】
問い合わせ実行計画案実行コスト表１２７には、問い合わせ実行計画案ごとに、実行コストの見積りが記録される。本発明の第１の実施形態では、実行性能情報だけでなく、消費電力情報も算出される。消費電力情報には、予測総消費電力量、予測最大消費電力及び予測平均消費電力が含まれている。
【００８０】
予測総消費電力量は、問い合わせの実行が完了するまでの総消費電力量の見積りである。予測最大消費電力は、いわゆるピーク時の消費電力であって、瞬間的に消費される電力量の見積りである。予測平均消費電力は、問い合わせの実行が完了するまでに単位時間当たりの消費電力量の見積りである。
【００８１】
図１２は、本発明の第１の実施形態の最適化指標に対応するＳＱＬヒント指示子の例を示す表である。ＳＱＬヒント指示子をＳＱＬに含ませることによって、最適化の指標を指示することができる。最適化の指標としては、図１２に示すように、消費電力量の閾値を指定する場合と、最適化する指標を指定し、最も実行コストの見積りが良好な問い合わせ実行計画案を選択する場合とがある。
【００８２】
例えば、最大消費電力の閾値を指定する場合には（レコード１２０１）、ＳＱＬにＳＱＬヒント指示子として「MAX_POWER(p)」を指定し、さらに「p」に閾値を指定する。演算装置１０１は、問い合わせ実行計画最適化部１２３の処理において、最大消費電力が「ｐ」以下の問い合わせ実行計画を選択する。なお、最大消費電力が「ｐ」以下の実行計画が複数存在する場合には、実行時間が最短の問い合わせ実行計画を選択してもよいし、総消費電力量が最小の問い合わせ実行計画を選択してもよい。
【００８３】
一方、総消費電力が少ない実行計画を優先して選択する場合には（レコード１２０２）、複数の問い合わせ実行計画案のうち、総消費電力の実行コストが最小の問い合わせ実行計画案を選択すればよい。
【００８４】
なお、閾値の指定と優先するコストの指定を同時に行なうことも可能である。この場合には、指定された閾値を満足する問い合わせ実行計画案のうち、優先すべきコストが最も良好な問い合わせ実行計画案を選択すればよい。
【００８５】
図１３は、本発明の第１の実施形態のＳＱＬヒント指示子を追加したＳＱＬの一例を示す図である。図１３に示すＳＱＬは、総消費電力が少ない実行計画を優先して選択する場合を示している。図１３に示すように、ＳＱＬにＳＱＬヒント指示子を含ませることによって、データベース管理システム１２０に最適化する指標を指示することができる。
【００８６】
以下、問い合わせ実行計画生成部１２２によって生成された問い合わせ実行計画案に対し、実行コストの見積りを算出した結果である問い合わせ実行計画案実行コスト表１２７を参照し、指定された指標に基づいて実行計画を選択する手順について説明する。
【００８７】
図１４は、本発明の第１の実施形態の問い合わせ実行計画最適化部１２３によって、複数の問い合わせ実行計画案から問い合わせ実行計画を決定する手順を示すフローチャートである。問い合わせ実行計画最適化部１２３では、受信された問い合わせに含まれるＳＱＬヒント指示子に応じて、問い合わせ実行計画案が選択される。
【００８８】
演算装置１０１は、まず、受信した問い合わせに最大消費電力量の閾値の指定が含まれるか否かを判定する（Ｓ１４０１）。演算装置１０１は、受信した問い合わせに最大消費電力量の閾値の指定が含まれる場合には（Ｓ１４０１の結果が「Ｙｅｓ」）、指定された閾値を上回る最大消費電力を有する問い合わせ実行計画案を問い合わせ実行計画案実行コスト表１２７から除外する（Ｓ１４０２）。受信した問い合わせに最大消費電力閾値の指定が含まれない場合には（Ｓ１４０１の結果が「Ｎｏ」）、Ｓ１４０３の処理を実行する。
【００８９】
続いて、演算装置１０１は、受信した問い合わせに総消費電力量の閾値の指定が含まれるか否かを判定する（Ｓ１４０３）。演算装置１０１は、受信した問い合わせに総消費電力量の閾値の指定が含まれる場合には（Ｓ１４０３の結果が「Ｙｅｓ」）、指定された閾値を上回る予測総消費電力量を有する問い合わせ実行計画案を問い合わせ実行計画案実行コスト表１２７から除外する（Ｓ１４０４）。受信した問い合わせに総消費電力量の閾値の指定が含まれない場合には（Ｓ１４０３の結果が「Ｎｏ」）、Ｓ１４０５の処理を実行する。
【００９０】
さらに、演算装置１０１は、受信した問い合わせに優先するコストが指示されているかを判定する（Ｓ１４０５）。
【００９１】
演算装置１０１は、受信した問い合わせに総消費電力量を優先する指示が含まれている場合には（Ｓ１４０５の結果が「総消費電力量優先」）、問い合わせ実行計画案実行コスト表１２７に含まれる問い合わせ実行計画案のうち、予測総消費電力量の値が最も小さい問い合わせ実行計画案を選択し、他の問い合わせ実行計画案を除外する（Ｓ１４０６）。
【００９２】
演算装置１０１は、受信した問い合わせに平均消費電力を優先する指示が含まれている場合には（Ｓ１４０５の結果が「平均消費電力優先」）、問い合わせ実行計画案実行コスト表１２７に含まれる問い合わせ実行計画案のうち、予測平均消費電力の値が最も小さい問い合わせ実行計画案を選択し、他の問い合わせ実行計画案を除外する（Ｓ１４０７）。
【００９３】
最後に、演算装置１０１は、受信した問い合わせに実行時間を優先する指示が含まれている場合（Ｓ１４０５の結果が「なし」又は「実行時間優先」）、又は、総消費電力量若しくは平均消費電力優先によって選択された問い合わせ実行計画案が複数存在する場合には、最も予測実行時間の小さい問い合わせ実行計画案を選択する（Ｓ１４０８）。
【００９４】
演算装置１０１は、その後、本処理を終了し、選択された問い合わせ実行計画案を問い合わせ実行計画として、問い合わせ実行部１２４に送信する（図７のＳ７０４）。
【００９５】
図１５は、本発明の第１の実施形態の問い合わせ実行部１２４によって、問い合わせ実行計画を実行する手順を示すフローチャートである。
【００９６】
演算装置１０１は、実行する問い合わせ実行計画が決定されると、問い合わせ実行計画最適化部１２３から、決定された問い合わせ実行計画を受信する（Ｓ１５０１）。
【００９７】
演算装置１０１は、問い合わせ実行計画に含まれる各ステップの処理を実行し、ストレージ装置２にデータを入出力する（Ｓ１５０２）。
【００９８】
演算装置１０１は、問い合わせ実行計画に含まれる各ステップの処理の実行が完了すると、問い合わせ受付部１２１に問い合わせの実行結果を送信する（Ｓ１５０３）。
【００９９】
図１６は、本発明の第１の実施形態のストレージ装置２の入出力処理部２１１によって、ホスト計算機１から受信した入出力要求を処理する手順を示すフローチャートである。
【０１００】
ストレージ装置２の制御部２０１は、まず、図１５のＳ１５０２の処理によって、ホスト計算機１から送信されたデータの入出力要求を受信する（Ｓ１６０１）。
【０１０１】
制御部２０１は、入出力処理部２１１の処理によって、データの入出力要求を受信すると、データを入出力する対象のボリューム２２３を特定する。制御部２０１は、対象ボリュームの状態を取得するために、ボリューム情報表２１６を参照する（Ｓ１６０２）。ボリューム情報表２１６は、記憶部２０２によって提供されるボリュームの情報を格納する表である。ボリューム情報表２１６の詳細は、図１７にて後述する。
【０１０２】
図１７は、本発明の第１の実施形態のストレージ装置２によって提供されるボリューム２２３の情報を格納するボリューム情報表２１６である。ボリューム情報表２１６は、ボリューム名１７０１、電力モード１７０２、及び最終アクセス時間１７０３を含む。
【０１０３】
ボリューム名１７０１は、ストレージ装置２によって提供されるボリューム２２３の名称が格納される。電力モード１７０２は、ボリューム２２３の状態が格納される。具体的には、ボリューム２２３が稼働中である場合には「アクティブ」、ボリューム２２３に一定期間アクセスがない場合など、ボリューム２２３がスリープ状態（例えば、磁気ディスクドライブの回転が停止）の場合には「スリープ」となる。最終アクセス時間１７０３は、ボリューム２２３に最後にアクセスした日時が記録される。
【０１０４】
ここで、図１６のフローチャートの説明に戻る。
【０１０５】
制御部２０１は、ボリューム情報表２１６を参照し、対象ボリュームの状態を取得する。そして、対象ボリュームの状態がスリープ状態か否かを判定する（Ｓ１６０２）。スリープ状態でない場合には（Ｓ１６０２の結果が「Ｎｏ」）、Ｓ１６０５の処理を実行する。
【０１０６】
制御部２０１は、対象ボリュームの状態がスリープ状態である場合には（Ｓ１６０２の結果が「Ｙｅｓ」）、対象ボリュームをアクティブ化する（Ｓ１６０３）。ボリュームのアクティブ化とは、例えば、磁気ディスクドライブの回転を再開させるなどによって、ボリューム２２３をアクセス可能な状態とすることである。そして、ボリューム情報表２１６の電力モード１７０２を「スリープ」から「アクティブ」に更新する（Ｓ１６０４）。
【０１０７】
制御部２０１は、ボリューム情報表２１６の最終アクセス時間１７０３を更新する（Ｓ１６０５）。さらに、制御部２０１は、記憶部２０２にデータの入出力要求を送信し、対象ボリュームのデータを読み書きする（Ｓ１６０６）。
【０１０８】
以上の処理が終了すると、制御部２０１は、ホスト計算機１に対して、問い合わせの回答を送信し、処理の完了を通知する。
【０１０９】
図１８は、本発明の第１の実施形態のストレージ装置２の自動電力制御部２１２によって、アクティブ状態のボリュームをスリープ状態に移行させる手順を示すフローチャートである。
【０１１０】
本発明の第１の実施形態のストレージ装置２では、ホスト計算機１の処理とは独立して、一定時間アクセスされないボリュームがスリープ状態となるように制御される。したがって、本処理は、制御部２０１の自動電力制御部２１２によって、定期的に実行される。
【０１１１】
制御部２０１は、ボリューム情報表２１６を参照し、すべてのボリュームに対して以下の処理を実行する。制御部２０１は、まず、ボリューム情報表２１６の電力モード１７０２を参照し、対象のボリュームがスリープ状態か否かを判定する（Ｓ１８０１）。スリープ状態である場合には（Ｓ１８０１の結果が「Ｙｅｓ」）、別のボリュームについて処理を実行する。
【０１１２】
一方、制御部２０１は、対象のボリュームがスリープ状態でない場合には（Ｓ１８０１の結果が「Ｎｏ」）、ボリューム情報表２１６の最終アクセス時間１７０３を参照し、対象のボリュームがアクセスされていない期間が所定の時間（例えば、Ｎ秒）以上であるか否かを判定する（Ｓ１８０２）。判定の基準となる所定の時間は、事前に設定されている。
【０１１３】
制御部２０１は、対象のボリュームがアクセスされていない期間が所定の時間以上の場合には（Ｓ１８０２の結果が「Ｙｅｓ」）、対象ボリュームをスリープ状態とすることによって（Ｓ１８０３）、消費電力を低減させる。そして、対象ボリュームについて、ボリューム情報表２１６の電力モード１７０２の値を「スリープ」に更新する（Ｓ１８０４）。
【０１１４】
以上のように、所定の時間、ボリュームにアクセスされない場合には、当該ボリュームはスリープ状態に移行し、消費電力を低減することができる。そこで、本発明の第１の実施形態では、ボリュームのアクセスが一時に集中するように制御することなどによって、ボリュームの省電力機能を稼働させ、消費電力を低減させる。
【０１１５】
ここで、以上説明した本発明の第１の実施形態の構成及び処理に従って、具体例を説明する。
【０１１６】
図１９は、本発明の第１の実施形態のアクセス対象の関係表を格納するボリュームの構成を示す図である。
【０１１７】
本発明の第１の実施形態の具体例では、ボリュームＡに関係表Ｒ及び関係表Ｓが格納され、ボリュームＢに関係表Ｔ及び関係表Ｕが格納されている。また、関係表Ｒ、関係表Ｓ、関係表Ｔ及び関係表Ｕには、各レコードに共通のフィールド「ｉｄ」が含まれている。
【０１１８】
そこで、関係表Ｒ、関係表Ｓ、関係表Ｔ及び関係表Ｕの共通のフィールド「ｉｄ」をキーとして、各関係表を結合し、さらに、平均消費電力が少なくなるようにデータベース管理システム１２０に指示する。
【０１１９】
図２０は、本発明の第１の実施形態の問い合わせに対応するＳＱＬ２００を示す図である。
【０１２０】
ＳＱＬ２００は、前述した処理を実行するＳＱＬであり、関係表Ｒ、関係表Ｓ、関係表Ｔ及び関係表Ｕについて、フィールド「ｉｄ」が一致するレコードをすべて結合する。また、平均消費電力が少なくなるようにデータベース管理システム１２０に指示するために、ＳＱＬ２００には、ＳＱＬヒント指示子「／＊＋ＰＲＩＯＲ＿ＰＯＷＥＲ＊／」が含まれている。
【０１２１】
前述のように、演算装置１０１は、問い合わせとしてＳＱＬ２００を受信すると、データベース管理システム１２０の問い合わせ受付部１２１がＳＱＬ２００を受け付ける。演算装置１０１は、受け付けたＳＱＬ２００を解析し、問い合わせ実行計画案を作成する。
【０１２２】
なお、本発明の第１の実施形態の具体例では、結合方法は各関係表のレコード数及び構造などに依存するため、各関係表の結合処理はハッシュ結合のみを用いる。
【０１２３】
ここで、本発明の第１の実施形態の具体例では、２種類の結合方法について問い合わせ実行計画案を作成する。第１の結合方法は、同じボリュームに含まれる関係表をそれぞれ結合して一時表を作成し、各ボリュームに作成された一時表をさらに結合する。第２の結合方法は、各関係表を一つずつ順次結合する。
【０１２４】
以下、各結合方法について、図１９の構成に基づいて、具体的に説明する。ここで、第１の結合方法に基づく問い合わせ実行計画案を問い合わせ実行計画案１１とし、第２の結合方法に基づく問い合わせ実行計画案を問い合わせ実行計画案１２として説明する。
【０１２５】
図２１及び図２２は、第１の結合方法である問い合わせ実行計画案１１を説明する図面である。
【０１２６】
図２１は、本発明の第１の実施形態の問い合わせ実行計画案１１の関係表を結合する組み合わせを示す図面である。図２１では、関係表Ｒ及び関係表Ｓを結合して一時表を作成し、並行して、関係表Ｔ及び関係表Ｕを結合して一時表を作成する。そして、作成された各一時表を結合することによって最終結果を得る。
【０１２７】
図２２は、本発明の第１の実施形態の問い合わせ実行計画案１１の手順を示す図である。
【０１２８】
問い合わせ実行計画案１１は、ステップ１として、まず、関係表Ｒを読み込み、ハッシュ表Ｒ’を作成し、同時に、関係表Ｔを読み込み、ハッシュ表Ｔ’を作成する。
【０１２９】
次に、ステップ２として、関係表Ｓを読み込み、ハッシュ表Ｒ’を検索し、照合結果を主記憶装置１０２に一時表ＲＳとして格納する。同時に、関係表Ｕを読み込み、ハッシュ表Ｔ’を検索し、同様に、照合結果を主記憶装置１０２に一時表ＴＵとして格納する。
【０１３０】
さらに、ステップ３として、一時表ＲＳから、ハッシュ表ＲＳ’を作成する。
【０１３１】
最後に、ステップ４として、一時表ＴＵを読み込み、ハッシュ表ＲＳ’を検索し、照合結果を回答として出力する。
【０１３２】
図２３及び図２４は、第２の結合方法である問い合わせ実行計画案１２を説明する図面である。
【０１３３】
図２３は、本発明の第１の実施形態の問い合わせ実行計画案１２の関係表を結合する組み合わせを示す図面である。図２３では、関係表Ｒ及び関係表Ｓを結合して一時表を作成し、順次、関係表Ｔ及び関係表Ｕを結合して最終結果を得る。
【０１３４】
図２４は、本発明の第１の実施形態の問い合わせ実行計画案１２の手順を示す図である。
【０１３５】
問い合わせ実行計画案１１は、ステップ１として、まず、関係表Ｒを読み込み、ハッシュ表Ｒ’を作成する。
【０１３６】
次に、ステップ２として、関係表Ｓを読み込み、ハッシュ表Ｒ’を検索し、照合結果からハッシュ表ＲＳ’を作成する。
【０１３７】
さらに、ステップ３として、関係表Ｔを読み込み、ハッシュ表ＲＳ’を検索し、照合結果からハッシュ表ＲＳＴ’を作成する。
【０１３８】
最後に、ステップ４として、関係表Ｕを読み込み、ハッシュ表ＲＳＴ’を検索し、照合結果を回答として出力する。
【０１３９】
続いて、図２５及び図２６に各問い合わせ実行計画案を実行した場合に、各ボリュームの稼働状況を示す。なお、各問い合わせ実行計画案が実行される前には、各ボリュームは、アクティブ状態となっている。
【０１４０】
ここで、説明を容易にするために、各関係表を結合する処理は、組み合わせによらずに一定時間とする。具体的には、各関係表を読み込むために要する時間を３０秒とする。また、主記憶装置１０２に記憶されているデータに対するアクセスは高速であるため、主記憶装置１０２に記憶されている一時表からハッシュ表を作成する処理及び主記憶装置１０２に記憶されている一時表とハッシュ表を照合する処理は１秒未満とし、無視する。その他の制御時間などについては、図９に示したボリューム消費電力モデル情報表１２６から取得できる。
【０１４１】
なお、実際には、関係表のレコード件数及び構造によって読み込み時間は異なるため、各関係表の構造及びレコード件数などに基づいて、問い合わせ実行計画が作成される。
【０１４２】
図２５は、本発明の第１の実施形態の具体例の問い合わせ実行計画案１１のボリュームの稼働状況を示す図である。
【０１４３】
問い合わせ実行計画案１１のステップ１では、ボリュームＡにおいて、関係表Ｒが読み込まれてハッシュ表Ｒ’が作成され、並行して、ボリュームＢにおいて、関係表Ｔが読み込まれてハッシュ表Ｔ’が作成される。前述のように、関係表Ｒ及び関係表Ｔの読み込みには３０秒、ハッシュ表Ｒ’及びハッシュ表Ｔ’の作成には１秒未満の時間がかかる。
【０１４４】
また、消費電力については、図９のレコード９０１の値から、ボリュームごとに２０Ｗとなる。したがって、ステップ１の消費電力は、単位時間当たり４０Ｗとなる。
【０１４５】
ステップ２では、ボリュームＡにおいて、関係表Ｓが読み込まれてハッシュ表Ｒ’を検索し、照合結果として一時表ＲＳが作成される。同様に、ボリュームＢにおいて、関係表Ｕが読み込まれてハッシュ表Ｔ’を検索し、照合結果として一時表ＴＵが作成される。このとき、ボリュームＡでは、関係表Ｓの読み込みに３０秒、他の処理に１秒未満の時間がかかる。ボリュームＢについても同様に、関係表Ｕの読み込みに３０秒、他の処理に１秒未満の時間がかかる。
【０１４６】
また、消費電力については、ステップ１と同様に、単位時間当たり４０Ｗとなる。
【０１４７】
ステップ３及びステップ４の処理については、主記憶装置１０２に記憶されたデータに対する処理であるため、所要時間は１秒未満である。なお、この間ボリュームＡ及びボリュームＢは、アクセスされないためアイドル状態となるが、消費電力については、所要時間が短いため、無視することができる。
【０１４８】
図２６は、本発明の第１の実施形態の問い合わせ実行計画案１２のボリュームの稼働状況を示す図である。
【０１４９】
問い合わせ実行計画案１２のステップ１では、ボリュームＡにおいて、関係表Ｒが読み込まれてハッシュ表Ｒ’が作成される。このとき、関係表Ｒの読み込みには３０秒、ハッシュ表Ｒ’の作成には１秒未満の時間がかかる。したがって、ステップ１の所要時間は、約３０秒である。また、消費電力については、単位時間当たり２０Ｗとなる。
【０１５０】
また、ボリュームＢは、ステップ１の処理によってアクセスされないため、ステップ１が開始されてから５秒経過すると（図９のレコード９０７）、アイドル状態からスリープ状態に遷移する。アイドル状態では、単位時間当たりの消費電力は１５Ｗとなる（図９のレコード９０２）。また、アイドル状態からスリープ状態に遷移するための制御の所要時間は５秒（図９のレコード９０４）、制御中の単位時間当たりの消費電力は１０Ｗとなる（図９のレコード９０６）。スリープ状態では、単位時間当たりの消費電力は１Ｗである（図９のレコード９０３）。
【０１５１】
ステップ２では、ボリュームＡにおいて、関係表Ｓが読み込まれてハッシュ表Ｒ’を検索し、照合結果からハッシュ表ＲＳ’が作成される。このとき、ボリュームＡでは、関係表Ｓの読み込みに３０秒、ハッシュ表ＲＳ’の作成に１秒未満の時間がかかる。また、消費電力については、同様に、単位時間当たり２０Ｗとなる。ボリュームＢについては、この間、スリープ状態となっている。
【０１５２】
ステップ３では、ボリュームＡはアクセスされないため、ステップ２が終了してから５秒経過すると、スリープ状態に移行する。消費電力については、ステップ１におけるボリュームＢの説明と同様である。
【０１５３】
また、ボリュームＢにおいて、関係表Ｔを読み込み、ハッシュ表ＲＳ’を検索し、照合結果からハッシュ表ＲＳＴ’が作成される。このとき、ボリュームＢは、スリープ状態からアクティブ状態に遷移するため、制御に５秒の時間を要する（図９のレコード９０５）。さらに、関係表Ｓの読み込みに３０秒、ハッシュ表ＲＳ’の作成に１秒未満の時間がかかる。
【０１５４】
ステップ４では、ボリュームＡは引き続きスリープ状態となっている。ボリュームＢでは、関係表Ｕが読み込まれ、ハッシュ表ＲＳＴ’を検索し、照合結果を回答として出力する。
【０１５５】
図２７は、本発明の第１の実施形態の問い合わせ実行計画案実行コスト表１２７を示す図である。
【０１５６】
ここで、図２５及び図２６に示した各問い合わせ実行計画案のボリュームの稼働状況を参照し、実行コストを計算する。
【０１５７】
まず、問い合わせ実行計画案１１について実行コストを計算する。図２５を参照すると、予測実行時間は、各ステップの所要時間を合計して６０秒となる。さらに、総消費電力量は、４０Ｗ×３０秒＋４０Ｗ×３０秒＝２４００Ｊ（ジュール）となる。
【０１５８】
また、予測最大消費電力は、処理期間を通じて両方のボリュームがアクセス中であるため、４０Ｗとなる。
【０１５９】
さらに、予測平均消費電力は、２４００Ｊ（Ｗ・秒）／６０秒＝４０Ｗとなる。
【０１６０】
次に、問い合わせ実行計画案１２について実行コストを計算する。図２６を参照すると、各ステップの所要時間を合計すると、１２０秒となり、さらに、ステップ２からステップ３の間にボリュームＢをアクティブ化するために５秒要する。したがって、予測実行時間は、１２５秒となる。
【０１６１】
消費電力量については、ボリュームＡは、２０Ｗ×３０秒（ステップ１）＋２０Ｗ×３０秒（ステップ２）＋１５Ｗ×５秒＋１０Ｗ×５秒＋１Ｗ×５５秒＝１３８０Ｊとなる。一方、ボリュームＢは、１５Ｗ×５秒＋１０Ｗ×５秒＋１Ｗ×５０秒＋１０Ｗ×５秒＋２０Ｗ×３０秒（ステップ３）＋２０Ｗ×３０秒（ステップ４）＝１４２５Ｊとなる。したがって、総消費電力量は、２８０５Ｊとなる。
【０１６２】
また、予測最大消費電力は、一方のボリュームがアクセス中で他方のボリュームがアイドル中であるタイミングであるから、２０＋１５＝３５Ｗとなる。
【０１６３】
さらに、予測平均消費電力は、２８０５／１２５＝２２．４Ｗとなる。
【０１６４】
以上の計算結果から図２７に示す問い合わせ実行計画案実行コスト表１２７を得ることができる。図２７に示す問い合わせ実行計画案実行コスト表１２７を参照すると、実行時間については、問い合わせ実行計画案１１の方が短く、総消費電力量も少ない。一方、問い合わせ実行計画案１２は、ピーク時の消費電力である最大消費電力が問い合わせ実行計画案１１よりも少なく、平均消費電力も少なくなることがわかる。
【０１６５】
ここで、本発明の第１の実施形態の具体例では、問い合わせとして図２０に示したＳＱＬがホスト計算機１に送信され、ＳＱＬヒント指示子に「平均消費電力優先」が指定されている。したがって、問い合わせ実行計画最適化部１２３は、各問い合わせ実行計画案の実行コストの予測平均消費電力の値を比較し、予測平均消費電力の値の少ない問い合わせ実行計画案１２を選択する。
【０１６６】
第１の実施形態によれば、問い合わせに消費電力を考慮した指示子を含ませることによって、指示に応じた問い合わせ実行計画を決定し、実行時間の高速化を優先させるか消費電力の低減を優先させるかを選択することができる。
【０１６７】
また、第１の実施形態によれば、ストレージ装置の消費電力の低減を含む問い合わせ指示に対し、問い合わせの実行時ではなく、問い合わせ実行計画を作成する段階で事前に最適化することができる。問い合わせ実行計画は、一般的に、実行時間を高速化するように作成されるため、実行時に消費電力を低減させようとしても、作成された問い合わせ実行計画に依存し、十分に消費電力を低減することができない。一方、第１の実施形態では、事前に消費電力を考慮して問い合わせ実行計画を作成するため、柔軟に消費電力を調整することができる。
【０１６８】
なお、本発明の第１の実施形態の計算機システムでは、ホスト計算機１とストレージ装置２とが別に配置されているが、ホスト計算機１に二次記憶装置を搭載する構成とし、搭載された二次記憶装置に対して本発明を適用してもよい。
【０１６９】
（第２の実施形態）
第２の実施形態では、問い合わせ実行計画最適化部からストレージ装置に対し、電力制御命令を送信することによって省電力化する例について説明する。なお、第２の実施形態以降、第１の実施形態と同じ機能を果たす構成には同一の符号を付して重複する説明を適宜省略する。
【０１７０】
図２８は、本発明の第２の実施形態の計算機システムの構成を示す図である。
【０１７１】
ホスト計算機１は、第１の実施形態の構成に加えて、主記憶装置１０２に関係表等割当表１２８が記憶される。関係表等割当表１２８は、関係表又は索引などのデータと、当該データが格納されるボリューム２２３の対応を格納する。関係表等割当表１２８の詳細については、図３１にて後述する。
【０１７２】
また、ストレージ装置２は、第１の実施形態の構成に加えて、制御部２０１に電力制御命令処理部２１３を含む。電力制御命令処理部２１３は、ホスト計算機１から受信した電力制御命令を解析し、記憶部２０２の電力制御を実行する。
【０１７３】
続いて、第２の実施形態におけるホスト計算機１のデータベース管理システム１２０及びストレージ装置２の制御部２０１の処理について説明する。
【０１７４】
まず、ホスト計算機１のデータベース管理システム１２０について、問い合わせ受付部１２１及び問い合わせ実行計画生成部１２２の処理は、第１の実施形態と同じである。
【０１７５】
問い合わせ実行計画最適化部１２３の処理は、問い合わせ実行計画生成部１２２によって生成された問い合わせ実行計画に電源制御命令を付与する処理が追加される。電源制御命令を付与する処理については、詳細を図２９及び図３０にて後述する。
【０１７６】
問い合わせ実行部１２４の処理は、問い合わせ実行計画最適化部１２３の処理によって付与された電源制御命令に基づいて、ストレージ装置２に電源制御命令を送信する処理が追加される。問い合わせ実行部１２４の処理については、図３３にて後述する。
【０１７７】
次に、ストレージ装置２の制御部２０１について、入出力処理部２１１及び自動電力制御部２１２の処理は、第１の実施形態と同じである。
【０１７８】
また、ストレージ装置２の制御部２０１には、電力制御命令処理部２１３が追加されており、処理の詳細は、図３４にて後述する。
【０１７９】
図２９は、本発明の第２の実施形態の問い合わせ実行計画最適化部１２３よって、問い合わせ実行計画を最適化する手順を示すフローチャートである。
【０１８０】
本処理は、図７に示した第１の実施形態の処理と比較して、問い合わせ実行計画に電力制御命令を付与する処理（Ｓ２９０１）が追加されている点で相違する。
【０１８１】
演算装置１０１は、問い合わせ実行計画生成部１２２によって生成された問い合わせ実行計画案を受信すると（Ｓ７０１）、各問い合わせ実行計画案に電力制御命令を付与する（Ｓ２９０１）。具体的に電力制御命令を付与する処理の詳細は、図３０にて後述する。
【０１８２】
続いて、演算装置１０１は、各問い合わせ実行計画案の実行コストの見積りを計算する（Ｓ７０２）。実行コストの見積りは、付与された電力制御命令に対応して計算される。さらに、演算装置１０１は、計算された問い合わせ実行計画案の実行コストの見積りに基づいて、問い合わせ実行計画を決定する（Ｓ７０３）。最後に、演算装置１０１は、決定された問い合わせ実行計画を問い合わせ実行部１２４に送信する（Ｓ７０４）。
【０１８３】
図３０は、本発明の第２の実施形態の問い合わせ実行計画最適化部１２３において、問い合わせ実行計画案に電力制御命令を付与する手順を示すフローチャートである。本処理は、すべての問い合わせ実行計画案に対して実行される。
【０１８４】
演算装置１０１は、問い合わせ実行計画案の各ステップに対し、関係表等割当表１２８を参照し、各ステップ内の処理でアクセスされるボリュームを識別する（Ｓ３００１）。
【０１８５】
演算装置１０１は、問い合わせに電力制御を許可する指示子が含まれているか否かを判定する（Ｓ３００２）。具体的には、問い合わせに対応するＳＱＬに電力制御を許可するＳＱＬヒント指示子「ＥＮＡＢＬＥ＿ＰＯＷＥＲ＿ＣＯＮＴＲＯＬ」が含まれている場合である。
【０１８６】
演算装置１０１は、受信した問い合わせに電力制御を許可する指示子が含まれている場合には（Ｓ３００２の結果が「Ｙｅｓ」）、アクセスされるボリュームに対してはアクティブ化する命令を、アクセスされないボリュームに対してはスリープ化する命令を問い合わせ実行計画案に付与する（Ｓ３００３）。
【０１８７】
なお、演算装置１０１は、受信した問い合わせに電力制御を許可する指示子が含まれていない場合には（Ｓ３００２の結果が「Ｎｏ」）、本処理を終了する。
【０１８８】
図３１は、本発明の第２の実施形態の関係表と関係表が格納されたボリュームとの対応を含む関係表等割当表１２８を示す図面である。
【０１８９】
関係表等割当表１２８は、前述のように、関係表等と、関係表等が割り当てられているボリュームとの対応が格納される。関係表等には、関係表以外にも、索引などが含まれる。図３１を参照すると、関係表Ｒは、ボリュームＡに格納され、関係表Ｓ及び索引Ｓ’は、ボリュームＢに格納されていることがわかる。
【０１９０】
ここで、問い合わせ実行計画案に電力制御命令を付与する具体的手順について、図３２を参照しながら説明する。
【０１９１】
図３２は、本発明の第２の実施形態の電力制御命令が付与された問い合わせ実行計画を示す表である。電力制御命令が付与された問い合わせ実行計画は、問い合わせ実行計画生成部１２２によって生成された処理部３２１と、電力制御命令部３２２によって構成される。
【０１９２】
ステップ１の処理は、関係表Ｒからハッシュ表を作成する。図３１に示す関係表等割当表１２８を参照すると、関係表Ｒは、ボリュームＡに格納される。したがって、演算装置１０１は、ステップ１の処理を実行する直前に、ボリュームＡをアクティブ化する命令を付与する（図３０のＳ３００３）。同じく、ボリュームＢには、アクセスされないため、ボリュームＢをスリープ化する命令を付与する（図３０のＳ３００３）。
【０１９３】
ステップ２の処理は、関係表Ｓを走査し、ハッシュ表Ｒ’と照合する。関係表等割当表１２８を参照すると、関係表Ｓは、ボリュームＢに格納される。したがって、演算装置１０１は、ステップ１の処理を実行する直前に、ボリュームＢをアクティブ化する処理を付与する（図３０のＳ３００３）。このとき、ボリュームＡのアクセスは終了しているため、ボリュームＡに対しては、スリープ化する命令を付与する。
【０１９４】
ステップ３の処理は、照合結果を整列する処理であって、ボリュームＡ及びボリュームＢのいずれにもアクセスしない。したがって、ステップ２の処理でアクセスされていたボリュームＢに対してスリープ化する命令を付与する。なお、ボリュームＡに対してもスリープ化する命令を付与してもよいが、既にボリュームＡがスリープ状態である場合には、無視される。
【０１９５】
図３３は、本発明の第２の実施形態の問い合わせ実行部１２４によって、受信した問い合わせ実行計画を実行する手順を示すフローチャートである。第１の実施形態との相違点は、付与された電力制御命令が実行される点である。
【０１９６】
演算装置１０１は、実行する問い合わせ実行計画が決定されると、問い合わせ実行部１２４の処理において、決定された問い合わせ実行計画を受信する（Ｓ１５０１）。
【０１９７】
演算装置１０１は、問い合わせ実行計画に含まれる各ステップの処理直前に実行する電力制御命令が含まれているか否かを判定する（Ｓ３３０２）。問い合わせ実行計画に含まれる各ステップの処理直前に実行する電力制御命令が含まれている場合には（Ｓ３３０２の結果が「Ｙｅｓ」）、ストレージ装置２に電力制御命令を送信する（Ｓ３３０３）。なお、ボリュームをアクティブ化する電力制御命令の場合は、スリープ状態からアクティブ化が完了するまでに要する時間を考慮して、事前に実行されるようにしてもよい。
【０１９８】
続いて、演算装置１０１は、問い合わせ実行計画に含まれる各ステップの処理を実行し、ストレージ装置２にデータを入出力する（Ｓ１５０２）。
【０１９９】
演算装置１０１は、問い合わせ実行計画に含まれる各ステップの処理直後に実行する電力制御命令が含まれているか否かを判定する（Ｓ３３０４）。問い合わせ実行計画に含まれる各ステップの処理直後に実行する電力制御命令が含まれている場合には（Ｓ３３０４の結果が「Ｙｅｓ」）、ストレージ装置２に電力制御命令を送信する（Ｓ３３０５）。
【０２００】
演算装置１０１は、問い合わせ実行計画に含まれる各ステップの処理の実行が完了すると、問い合わせ受付部１２１に問い合わせの実行結果を送信する（Ｓ１５０３）。
【０２０１】
図３４は、本発明の第２の実施形態のストレージ装置２の制御部２０１が電力制御命令を受信したときの電力制御命令処理部２１３による処理の手順を示す図である。
【０２０２】
制御部２０１は、ホスト計算機１から電力制御命令を受信すると（Ｓ３４０１）、受信した電力制御命令が、スリープ化であるかアクティブ化であるかを判定する（Ｓ３４０２）。
【０２０３】
制御部２０１は、受信した電力制御命令が、スリープ化である場合には（Ｓ３４０２の結果が「スリープ化」）、指定されたボリュームを制御し、スリープ状態に移行させる（Ｓ３４０３）。一方、受信した電力制御命令が、アクティブ化である場合には（Ｓ３４０２の結果が「アクティブ化」）、指定されたボリュームを制御し、アクティブ状態に移行させる（Ｓ３４０４）。
【０２０４】
最後に、制御部２０１は、電力制御されたボリュームについて、ボリューム情報表２１６のデータを更新する（Ｓ３４０５）。
【０２０５】
ここで、以上説明した本発明の第２の実施形態の構成及び処理に従って、具体例を説明する。
【０２０６】
図３５は、本発明の第２の実施形態のアクセス対象の関係表を格納するボリュームの構成を示す図である。
【０２０７】
本発明の第２の実施形態の具体例では、ボリュームＡ及びボリュームＢに関係表Ｒ及び関係表Ｓが、結合鍵を「ｉｄ」として、ハッシュ分割されて格納されている。具体的には、関係表Ｒは、ボリュームＡ及びボリュームＢに部分Ｒ１及び部分Ｒ２が格納される。また、関係表Ｓは、ボリュームＡ及びボリュームＢに部分Ｓ１及び部分Ｓ２が格納される。
【０２０８】
本発明の第２の実施形態の具体例では、関係表Ｒ及び関係表Ｓに含まれる共通のフィールド「ｉｄ」をキーとして、関係表Ｒ及び関係表Ｓを結合する。さらに、電力制御を可能としながら、最大消費電力の閾値を指定し、実行時間を優先する。
【０２０９】
図３６は、本発明の第２の実施形態の問い合わせに対応するＳＱＬ３６０を示す図である。
【０２１０】
ＳＱＬ３６０は、前述した処理を実行するＳＱＬであり、関係表Ｒ及び関係表Ｓについて、フィールド「ｉｄ」が一致するレコードを結合する。また、電力制御を可能とするために、ＳＱＬ３６０には、ＳＱＬヒント指示子「／＊＋ＥＮＡＢＬＥ＿ＰＯＷＥＲ＿ＣＯＮＴＲＯＬ＊／」が含まれている。また、最大消費電力の閾値は、３０Ｗと指定され、ＳＱＬ３６０にはＳＱＬヒント指示子「／＊＋ＭＡＸ＿ＰＯＷＥＲ（３０Ｗ）＊／」が含まれる。さらに、ＳＱＬ３６０には実行時間優先を指定する「／＊＋ＰＲＩＯＲ＿ＴＩＭＥ＊／」が含まれている。
【０２１１】
本発明の第２の実施形態の具体例では、各ボリュームにおける処理を並列して実行する問い合わせ実行計画案２１と、ボリュームＡにおける処理が終了した後、ボリュームＢにおける処理を実行する問い合わせ実行計画案２２が作成される。
【０２１２】
以下、各問い合わせ実行計画案について、図３７及び図３８を参照しながら具体的に説明する。
【０２１３】
図３７は、本発明の第２の実施形態の問い合わせ実行計画案２１の手順を示す図である。
【０２１４】
問い合わせ実行計画案２１では、演算装置１０１は、ステップ１として、まず、ボリュームＡから関係表の部分Ｒ１を読み込み、ハッシュ表Ｒ１’を作成する。さらに同時に、ボリュームＢから関係表の部分Ｒ２を読み込み、ハッシュ表Ｒ２’を作成する。
【０２１５】
このとき、演算装置１０１は、ステップ１の処理の直前にボリュームＡ及びボリュームＢをアクティブ化する電力制御命令を追加する。
【０２１６】
次に、演算装置１０１は、ステップ２として、関係表の部分Ｓ１を読み込み、ハッシュ表Ｒ１’を検索し、照合結果を回答として出力する。それと同時に、関係表の部分Ｓ２を読み込み、ハッシュ表Ｒ２’を検索し、照合結果を回答として出力する。
【０２１７】
演算装置１０１は、ステップ２の処理の直後に、ボリュームＡ及びボリュームＢをスリープ化する電力制御命令を追加する。このように、処理終了後に各ボリュームをアイドル状態に移行することなく、スリープ状態に移行することによって、消費される電力をより低減することができる。
【０２１８】
図３８は、本発明の第２の実施形態の問い合わせ実行計画案２２の手順を示す図である。
【０２１９】
問い合わせ実行計画案２２では、演算装置１０１は、ステップ１として、まず、ボリュームＡから関係表の部分Ｒ１を読み込み、ハッシュ表Ｒ１’を作成する。
【０２２０】
このとき、演算装置１０１は、ステップ１の処理の直前にボリュームＡをアクティブ化し、ボリュームＢをスリープ化する電力制御命令を追加する。ステップ１において、アクセスされないボリュームＢをスリープ化することによって、省電力化を図ることができる。
【０２２１】
次に、演算装置１０１は、ステップ２として、関係表の部分Ｓ１を読み込み、ハッシュ表Ｒ１’を検索し、照合結果を回答として出力する。
【０２２２】
さらに、演算装置１０１は、ステップ３として、ボリュームＢから関係表の部分Ｒ２を読み込み、ハッシュ表Ｒ２’を作成する。また、演算装置１０１は、ステップ３の処理の直前にボリュームＡをスリープ化し、ボリュームＢをアクティブ化する電力制御命令を追加する。
【０２２３】
最後に、演算装置１０１は、ステップ４として、関係表の部分Ｓ２を読み込み、ハッシュ表Ｒ２’を検索し、照合結果を回答として出力する。そして、演算装置１０１は、ステップ４の処理の直後にボリュームＢをスリープ化する電力制御命令を追加する。
【０２２４】
続いて、図３９及び図４０に各問い合わせ実行計画案を実行した場合の各ボリュームの稼働状況を示す。関係表Ｒの部分Ｒ１及び部分Ｒ２、関係表Ｓの部分Ｓ１及びＳ２を読み込むために要する時間は、各３０秒とする。ボリュームの各状態における電力消費量などは、図９のボリューム消費電力モデル情報表１２６に従う。なお、各問い合わせ実行計画案が実行される前には、各ボリュームは、アクティブ状態となっている。
【０２２５】
図３９は、本発明の第２の実施形態の問い合わせ実行計画案２１のボリュームの稼働状況を示す図である。
【０２２６】
問い合わせ実行計画案２１のステップ１では、ボリュームＡ及びボリュームＢにおいて、並列して関係表Ｒの部分Ｒ１及びＲ２が読み込まれる。したがって、ステップ１の処理には、３０秒の時間を必要とする。
【０２２７】
また、消費電力については、ボリュームごとに２０Ｗとなる。したがって、ステップ１の消費電力は、単位時間当たり４０Ｗとなる。
【０２２８】
ステップ２では、ボリュームＡ及びボリュームＢにおいて、並列して関係表Ｓの部分Ｓ１及びＳ２が読み込まれる。したがって、ステップ２の処理には、３０秒の時間を必要とする。
【０２２９】
また、消費電力については、ステップ１と同様に、ボリュームごとに２０Ｗとなる。したがって、ステップ１の消費電力は、単位時間当たり４０Ｗとなる。
【０２３０】
図４０は、本発明の第２の実施形態の問い合わせ実行計画案２２のボリュームの稼働状況を示す図である。
【０２３１】
問い合わせ実行計画案２２のステップ１では、ボリュームＡにおいて、関係表Ｒの部分Ｒ１が読み込まれてハッシュ表Ｒ１’が作成される。このとき、関係表Ｒの部分Ｒ１の読み込みには３０秒の時間を要する。したがって、ステップ１の所要時間は、３０秒である。また、消費電力は、図９を参照すると、単位時間当たり２０Ｗとなる。
【０２３２】
一方、ボリュームＢは、ステップ１の処理の直前に、スリープ化させる電力制御命令が送信されている。前述のように、本処理実行時には、各ボリュームはアクティブ化されているため、アクティブ状態からスリープ状態に移行するように制御される。したがって、図９を参照すると、ステップ１の開始から５秒間は状態移行のための制御が実行され、この間の単位時間当たりの消費電力は、１０Ｗとなる。また、ステップ１の処理が完了する時刻までの残り２５秒間はスリープ状態となるため、単位時間当たりの消費電力は、１Ｗとなる。
【０２３３】
ステップ２では、ボリュームＡにおいて、関係表Ｓの部分Ｓ１が読み込まれてハッシュ表Ｒ１’を検索し、照合結果が回答として出力される。したがって、ステップ２においてもステップ１に引き続いて、ボリュームＡで処理が実行される。また、ステップ１の所要時間は、３０秒であり、消費電力は、単位時間当たり２０Ｗとなる。
【０２３４】
ボリュームＢについては、ステップ２の処理の間、スリープ状態であるため、単位時間当たりの消費電力は、１Ｗとなる。
【０２３５】
ここで、演算装置１０１は、ステップ３以降では、ボリュームＡはアクセスされないため、ボリュームＡをスリープ化させる。一方、ボリュームＢは、アクティブ化される。したがって、ステップ３の処理開始前に、ボリュームＡ及びボリュームＢについて、５秒間ずつ電力制御が実行される。
【０２３６】
ステップ３では、ボリュームＡは、スリープ状態となっている。したがって、単位時間当たりの消費電力は、１Ｗとなる。
【０２３７】
ボリュームＢでは、関係表Ｒの部分Ｒ２が読み込まれてハッシュ表Ｒ２’が作成される。関係表Ｒの部分Ｒ２の読み込みに３０秒の時間を要するため、ステップ３の所要時間は３０秒である。また、単位時間当たりの消費電力は、２０Ｗとなる。
【０２３８】
ステップ４では、ボリュームＡは、ステップ３と同様にスリープ状態となっている。したがって、単位時間当たりの消費電力は、１Ｗとなる。
【０２３９】
ボリュームＢでは、関係表Ｓの部分Ｓ２が読み込まれてハッシュ表Ｒ２’を検索し、照合結果が回答として出力される。関係表Ｓの部分Ｓ２の読み込みに３０秒の時間を要するため、ステップ４の所要時間は３０秒である。消費電力は、単位時間当たり２０Ｗとなる。
【０２４０】
図４１は、本発明の第２の実施形態の問い合わせ実行計画案実行コスト表１２７を示す図である。
【０２４１】
ここで、図３９及び図４０に示した各問い合わせ実行計画案のボリュームの稼働状況を参照し、実行コストを計算する。
【０２４２】
まず、問い合わせ実行計画案２１について実行コストを計算する。図３９を参照すると、予測実行時間は、各ステップの所要時間を合計して６０秒となる。さらに、総消費電力量は、２０Ｗ×３０秒×２＋２０Ｗ×３０秒×２＝２４００Ｊとなる。
【０２４３】
また、予測最大消費電力は、処理期間を通じて両方のボリュームがアクセス中であるため、４０Ｗとなる。
【０２４４】
さらに、予測平均消費電力は、２４００Ｊ（Ｗ・秒）／６０秒＝４０Ｗとなる。
【０２４５】
次に、問い合わせ実行計画案２２について実行コストを計算する。図４０を参照すると、各ステップの所要時間を合計すると、１２０秒となり、さらに、ステップ２からステップ３の間にボリュームＡ及びボリュームＢの状態を変更するために５秒要する。したがって、予測実行時間は、１２５秒となる。
【０２４６】
消費電力量については、ボリュームＡは、２０Ｗ×３０秒（ステップ１）＋２０Ｗ×３０秒（ステップ２）＋１０Ｗ×５秒＋１Ｗ×６０秒＝１３１０Ｊとなる。一方、ボリュームＢは、１０Ｗ×５秒＋１Ｗ×５５秒＋１０Ｗ×５秒＋２０Ｗ×３０秒（ステップ３）＋２０Ｗ×３０秒（ステップ４）＝１３５５Ｊとなる。したがって、総消費電力量は、２６６５Ｊとなる。
【０２４７】
また、予測最大消費電力は、処理開始時のボリュームＡがアクセス中、ボリュームＢが制御中であるタイミングであり、２０＋１０＝３０Ｗとなる。
【０２４８】
さらに、予測平均消費電力は、２６６５／１２５＝２１．３Ｗとなる。
【０２４９】
以上の計算結果から図４１に示す問い合わせ実行計画案実行コスト表１２７を得ることができる。図４１に示す問い合わせ実行計画案実行コスト表１２７を参照すると、実行時間については、問い合わせ実行計画案２１の方が短く、総消費電力量も少ない。一方、問い合わせ実行計画案２２は、ピーク時の消費電力である最大消費電力が問い合わせ実行計画案２１よりも少なく、平均消費電力も少なくなることがわかる。
【０２５０】
ここで、本発明の第２の実施形態の具体例では、問い合わせとして図３６に示したＳＱＬがホスト計算機１に送信され、ＳＱＬヒント指示子に「最大消費電力閾値」が３０Ｗに指定され、条件を満たす問い合わせ実行計画案が複数作成された場合には、実行時間が優先される。そこで、問い合わせ実行計画最適化部１２３は、各問い合わせ実行計画案の実行コストの予測最大消費電力の値を参照し、指定された閾値を満足する問い合わせ実行計画案２２を選択する。
【０２５１】
第２の実施形態によれば、ＳＱＬに電力制御を許可するＳＱＬヒント指示子を含ませることによって、電力制御命令を含んだ問い合わせ実行計画案を作成することができる。したがって、ボリュームに対するアクセスが終了した後、すぐにボリュームをスリープ状態に移行させることができるため、より消費電力を低減させることができる。
【０２５２】
（第３の実施形態）
第３の実施形態では、ストレージ装置にボリュームごとのボリューム消費電力モデル情報表を有する構成となっており、各ボリュームの消費電力モデル情報に基づいて、問い合わせ実行計画を作成し、実行する例について説明する。
【０２５３】
図４２は、本発明の第３の実施形態の計算機システムの構成を示す図である。
【０２５４】
ホスト計算機１は、ボリュームごとにボリューム消費電力モデル情報表１２６を有する。ボリューム消費電力モデル情報表１２６は、ボリュームごとに保持してもよいし、性能に応じて種類別に保持していてもよい。ボリューム消費電力モデル情報表１２６の詳細については、図４４にて後述する。
【０２５５】
また、ストレージ装置２は、第２の実施形態の構成に加えて、制御部２０１に消費電力情報管理部２１４を含む。消費電力情報管理部２１４は、各ボリュームの詳細なボリューム消費電力モデル情報表を収集し、ホスト計算機１に送信する。
【０２５６】
続いて、第３の実施形態におけるホスト計算機１のデータベース管理システム１２０及びストレージ装置２の制御部２０１の処理について、第２の実施形態と相違する点について説明する。
【０２５７】
まず、ホスト計算機１のデータベース管理システム１２０について、問い合わせ受付部１２１及び問い合わせ実行計画生成部１２２の処理は、第２の実施形態と同じである。
【０２５８】
問い合わせ実行計画最適化部１２３の処理では、実行コストの見積りを計算する場合に、ボリューム消費電力モデル情報表１２６の内容をストレージ装置２から取得する。具体的な手順については、図４３にて後述する。
【０２５９】
次に、ストレージ装置２の制御部２０１は、消費電力情報管理部２１４が追加されており、処理の詳細は、図４５にて後述する。
【０２６０】
図４３は、本発明の第３の実施形態の問い合わせ実行計画最適化部１２３おいて、問い合わせ実行計画案の実行コストを算出する手順を示すフローチャートである。なお、問い合わせ実行計画最適化部１２３の処理手順は、図２９に示した第２の実施形態の処理手順と同じである。
【０２６１】
問い合わせ実行計画最適化部１２３から実行コストを算出する処理が実行されると、ホスト計算機１の演算装置１０１は、ストレージ装置２の制御部２０１に対し、ボリューム消費電力モデル情報表の要求を送信する（Ｓ４３０１）。
【０２６２】
ストレージ装置２の制御部２０１は、ボリューム消費電力モデル情報表の要求を受信すると、ホスト計算機１にボリューム消費電力モデル情報表を送信する。演算装置１０１は、ストレージ装置２の制御部２０１から、ボリューム消費電力モデル情報表を受信すると（Ｓ４３０２）、受信したボリューム消費電力モデル情報表に基づいて、図８に示した第１の実施形態の実行コストを算出する処理を実行する（Ｓ８０１〜Ｓ８０３）。処理の詳細については、前述したとおりである。
【０２６３】
図４４は、本発明の第３の実施形態のボリューム消費電力モデル情報表１２６の構成を示す図である。第１及び第２の実施形態では、共通のボリューム消費電力モデル情報表を使用していたが、第３の実施形態では、ストレージ装置２から詳細な消費電力情報を取得し、ボリュームごとの消費電力情報に基づいて、実行コストを計算する。なお、すべてのボリュームを統合したボリューム消費電力モデル情報表１２６の符号を１２６とし、ボリュームごとのボリューム消費電力モデル情報表を１２６Ａ〜１２６Ｎとする。
【０２６４】
具体的には、第３の実施形態のボリューム消費電力モデル情報表１２６は、ボリュームと、当該ボリュームに対応するボリュームごとのボリューム消費電力モデル情報表（１２６Ａ〜１２６Ｎ）を指すポインタとによって構成される。
【０２６５】
図４５は、本発明の第３の実施形態の問い合わせ実行計画案の実行コストを計算する際に、ボリューム消費電力モデル情報表１２６を要求する処理の手順を示すフローチャートである。
【０２６６】
ボリューム消費電力モデル情報表要求処理は、ストレージ装置２の制御部２０１に含まれる消費電力情報管理部２１４によって、実行される。
【０２６７】
ストレージ装置２の制御部２０１は、ボリューム消費電力モデル情報表の要求をホスト計算機から受信すると（Ｓ４４０１）、各ボリュームのボリューム消費電力モデル情報表を取得する。ストレージ装置２の制御部２０１は、ボリューム消費電力モデル情報表が取得されていないボリュームについては消費電力情報を収集する。そして、ストレージ装置２の制御部２０１は、要求されたボリューム消費電力モデル情報をホスト計算機１に送信する（Ｓ４４０２）。
【０２６８】
ここで、以上説明した本発明の第３の実施形態の構成及び処理に従って、具体例を説明する。
【０２６９】
図４６は、本発明の第３の実施形態のアクセス対象の関係表を格納するボリュームの構成を示す図である。
【０２７０】
本発明の第３の実施形態の具体例では、ボリュームＡに関係表Ｒ及び関係表Ｓの索引Ｓ’が格納されている。ボリュームＢからボリュームＤには、関係表Ｓがラウンドロビン方式によって分割されて格納されている。ボリュームＢには部分Ｓ１、ボリュームＣには部分Ｓ２、ボリュームＤには部分Ｓ３が格納されている。ラウンドロビン方式では、ボリュームＢからボリュームＤの負荷が均等になるように、データが割り当てられる。なお、本発明の第３の実施形態の具体例では、結合鍵とは独立してデータが格納されている。
【０２７１】
本発明の第３の実施形態の具体例では、関係表Ｒ及び関係表Ｓに含まれる共通のフィールド「ｉｄ」をキーとして、関係表Ｒ及び関係表Ｓを結合する。さらに、電力制御を可能としながら、総消費電力量を優先する。
【０２７２】
図４７は、本発明の第３の実施形態の問い合わせに対応するＳＱＬ４７０を示す図である。
【０２７３】
ＳＱＬ４７０は、前述した処理を実行するＳＱＬであり、関係表Ｒ及び関係表Ｓについて、フィールド「ｉｄ」が一致するレコードを結合する。また、電力制御を可能とするために、ＳＱＬ４７０には、ＳＱＬヒント指示子「／＊＋ＥＮＡＢＬＥ＿ＰＯＷＥＲ＿ＣＯＮＴＲＯＬ＊／」が含まれている。さらに、ＳＱＬ４７０には、総消費電力量優先を指定する「／＊＋ＰＲＩＯＲ＿ＥＮＥＲＧＹ＊／」が含まれる。
【０２７４】
図４８及び図４９は、本発明の第３の実施形態の具体例におけるボリュームごとのボリューム消費電力モデル情報表を示す表である。
【０２７５】
図４８は、本発明の第３の実施形態のボリュームＡ及びボリュームＢのボリューム消費電力モデル情報表１２６Ａを示す表である。ボリュームＡ及びボリュームＢは、同じ構成となっているものとする。なお、格納される各数値は、図９と同じである。
【０２７６】
図４９は、本発明の第３の実施形態のボリュームＣ及びボリュームＤのボリューム消費電力モデル情報表１２６Ｂを示す表である。ボリュームＣ及びボリュームＤは、同じ構成となっているものとする。なお、格納される各数値は、ボリューム消費電力モデル情報表１２６Ａと比較すると、消費電力が二倍程度大きくなっている。
【０２７７】
本発明の第３の実施形態の具体例では、ネステッドループ結合によって、各関係表又は関係表の部分を結合する。ネステッドループ結合は、索引が設定されていない小さな関係表と、索引が設定されている大きな関係表の二つを結合する場合に効果的である。例えば、図４６に示したように、関係表Ｒの索引が設定されておらず、さらに、関係表Ｒのレコード数が少ない場合に、索引Ｓ’が設定されている関係表Ｓのレコード数が関係表Ｒのレコード数よりも著しく大きい場合には特に有効となる。
【０２７８】
図５０及び図５１は、問い合わせ実行計画案３１を説明する図面である。
【０２７９】
図５０は、本発明の第３の実施形態の問い合わせ実行計画案３１の関係表を結合する組み合わせを示す図面である。図５０では、関係表Ｒの１レコードごとに索引Ｓ’を検索し、関係表Ｓの一部Ｓ１、Ｓ２、Ｓ３のいずれかから合致するレコードを抽出し、結合する。
【０２８０】
図５１は、本発明の第１の実施形態の具体例の問い合わせ実行計画案３１の手順を示す図である。
【０２８１】
問い合わせ実行計画案３１は、関係表の部分Ｒを読み込み、読み込んだ１レコードごとに対して、索引Ｓ’を検索する。そして、検索結果に基づいて、関係表の一部Ｓ１、Ｓ２、Ｓ３のいずれかから合致するレコードを回答として出力する。
【０２８２】
また、ステップ１の処理を実行する直前には、電力制御命令として、ボリュームＡ、Ｂ、Ｃ及びＤをアクティブ化する。
【０２８３】
図５２及び図５３は、問い合わせ実行計画案３２を説明する図面である。
【０２８４】
図５２は、本発明の第３の実施形態の問い合わせ実行計画案３２の関係表を結合する組み合わせを示す図面である。図５２では、関係表Ｒに対して、関係表ＳのＳ１、Ｓ２、Ｓ３をそれぞれ結合することによって、関係表Ｒと関係表Ｓを結合する。
【０２８５】
図５２は、本発明の第１の実施形態の問い合わせ実行計画案３２の手順を示す図である。
【０２８６】
問い合わせ実行計画案３１は、ステップ１として、まず、関係表Ｒを読み込み、読み込まれた１レコードごとに索引Ｓ’を検索する。そして、検索結果に基づいて、関係表の一部Ｓ１に合致する場合には、合致するレコードを回答として出力する。
【０２８７】
また、ステップ１の処理を実行する直前には、電力制御命令として、ボリュームＡ及びボリュームＢをアクティブ化し、ボリュームＣ及びボリュームＤをスリープ化する。
【０２８８】
次に、ステップ２として、関係表Ｒを読み込み、読み込まれた１レコードごとに索引Ｓ’を検索する。そして、検索結果に基づいて、関係表の一部Ｓ２に合致する場合には、合致するレコードを回答として出力する。
【０２８９】
また、ステップ２の処理を実行する直前には、電力制御命令として、ボリュームＢをスリープ化し、ボリュームＣをアクティブ化する。
【０２９０】
最後に、ステップ３として、関係表Ｒを読み込み、読み込まれた１レコードごとに索引Ｓ’を検索する。そして、検索結果に基づいて、関係表の一部Ｓ３に合致する場合には、合致するレコードを回答として出力する。
【０２９１】
また、ステップ３の処理を実行する直前には、電力制御命令として、ボリュームＣをスリープ化し、ボリュームＤをアクティブ化する。そして、ステップ３の処理の終了後には、ボリュームＡ及びボリュームＤをスリープ化する。
【０２９２】
続いて、図５４及び図５５に各問い合わせ実行計画案を実行した場合の各ボリュームの稼働状況を示す。
【０２９３】
ここで、関係表Ｓは、Ｓ１、Ｓ２及びＳ３に、均等に分割されている。そこで、関係表Ｓの一部（Ｓ１、Ｓ２又はＳ３）を読み込む時間の合計は、それぞれ３０秒とする。また、関係表Ｒはデータ量が小さいため、読み込み時間を無視できる。なお、各問い合わせ実行計画案が実行される前には、各ボリュームは、アクティブ状態となっている。
【０２９４】
図５４は、本発明の第３の実施形態の問い合わせ実行計画案３１のボリュームの稼働状況を示す図である。
【０２９５】
問い合わせ実行計画案３１のステップ１では、関係表Ｒを読み込み、１レコードごとに索引Ｓ’を検索し、合致するレコードをボリュームＢ、ボリュームＣ又はボリュームＤに格納された関係表Ｓの一部Ｓ１、Ｓ２又はＳ３を検索する。
【０２９６】
ステップ１では、最終的には、関係表Ｓのすべてのレコードを読み出すため、関係表Ｓの一部Ｓ１、Ｓ２及びＳ３それぞれについて３０秒ずつ時間を要する。したがって、ステップ１の処理に９０秒の時間を必要とする。
【０２９７】
また、ボリュームＡからボリュームＤまでのすべてのボリュームは、アクティブ状態となっている。したがって、ボリュームＡ及びボリュームＢについては、図４８のボリューム消費電力モデル情報表１２６Ａを参照すると、それぞれ単位時間当たり２０Ｗの消費電力となり、計４０Ｗとなる。同じく、ボリュームＣ及びボリュームＤについては、図４９のボリューム消費電力モデル情報表１２６Ｂを参照すると、それぞれ単位時間当たり４０Ｗの消費電力となり、計８０Ｗとなる。よって、ステップ１では、単位時間当たり１２０Ｗの消費電力となる。
【０２９８】
図５５は、本発明の第３の実施形態の問い合わせ実行計画案３２のボリュームの稼働状況を示す図である。
【０２９９】
問い合わせ実行計画案３２のステップ１では、ボリュームＡにおいて、関係表Ｒが読み出され、１レコードごとに索引Ｓ’が検索される。検索に合致する関係表Ｓのレコードが関係表Ｓの一部Ｓ１に含まれる場合には、合致するレコード関係表Ｒのレコードと結合して出力する。このとき、検索に合致する関係表Ｓのレコードが関係表Ｓの一部Ｓ１に含まれない場合には、次のレコードを処理する。
【０３００】
前述のように、関係表Ｒの読み込み時間は無視できるため、ステップ１の所要時間は、関係表Ｓの一部Ｓ１を読み出す時間、すなわち、３０秒となる。
【０３０１】
また、消費電力については、ボリュームＡ及びボリュームＢはアクティブ化されているため、図４８のボリューム消費電力モデル情報表１２６Ａを参照すると、それぞれ単位時間当たり２０Ｗの消費電力となり、計４０Ｗとなる。さらに、ボリュームＣ及びボリュームＤについては、スリープ化する電力制御命令をステップ１の処理直前に受信しているため、５秒間の制御時間の後、スリープ化される。したがって、図４９のボリューム消費電力モデル情報表１２６Ｂを参照すると、５秒間は電力制御され、単位時間当たり２０Ｗの消費電力となる。その後、スリープ状態となり、単位時間当たり２Ｗの消費電力となる。
【０３０２】
ステップ２では、ステップ１の処理と同様にボリュームＡにおいて、関係表Ｒが読み出され、１レコードごとに索引Ｓ’が検索される。検索に合致する関係表Ｓのレコードが関係表Ｓの一部Ｓ２に含まれる場合には、合致するレコード関係表Ｒのレコードと結合して出力する。このとき、検索に合致する関係表Ｓのレコードが関係表Ｓの一部Ｓ２に含まれない場合には、ステップ１の処理と同様に、次のレコードを処理する。
【０３０３】
前述のように、関係表Ｒの読み込み時間は無視できるため、ステップ２の所要時間は、ステップ１の処理と同様に、関係表Ｓの一部Ｓ２を読み出す時間、すなわち、３０秒となる。
【０３０４】
また、消費電力については、ボリュームＡ及びボリュームＣはアクティブ化されているため、ボリュームＡの消費電力は単位時間当たり２０Ｗ、ボリュームＣの消費電力は単位時間当たり４０Ｗとなり、計６０Ｗとなる。ボリュームＢ及びボリュームＤはスリープ化されているため、ボリュームＢの消費電力は単位時間当たり１Ｗ、ボリュームＤの消費電力は単位時間当たり２Ｗとなり、計３Ｗとなる。
【０３０５】
なお、ステップ２の処理の開始直前には、ボリュームＣをアクティブ化するための制御が実行される。ボリュームＣをアクティブ化するために必要な時間は、図４９のボリューム消費電力モデル情報表１２６Ｂを参照すると５秒となる。この間、ボリュームＡは、アイドル状態となっている。
【０３０６】
このとき、消費電力は、ボリュームＡについては、単位時間当たり１５Ｗ、ボリュームＢについては、単位時間当たり１０Ｗとなる。また、ボリュームＣについては、単位時間当たり２０Ｗ、ボリュームＤについては、単位時間当たり２Ｗとなる。
【０３０７】
ステップ３では、ステップ１の処理と同様にボリュームＡにおいて、関係表Ｒが読み出され、１レコードごとに索引Ｓ’が検索される。検索に合致する関係表Ｓのレコードが関係表Ｓの一部Ｓ３に含まれる場合には、合致するレコード関係表Ｒのレコードと結合して出力する。このとき、検索に合致する関係表Ｓのレコードが関係表Ｓの一部Ｓ３に含まれない場合には、ステップ１の処理と同様に、次のレコードを処理する。
【０３０８】
前述のように、関係表Ｒの読み込み時間は無視できるため、ステップ３の所要時間は、ステップ１の処理と同様に、関係表Ｓの一部Ｓ３を読み出す時間、すなわち、３０秒となる。
【０３０９】
また、消費電力については、ボリュームＡ及びボリュームＤはアクティブ化されているため、ボリュームＡの消費電力は単位時間当たり２０Ｗ、ボリュームＤの消費電力は単位時間当たり４０Ｗとなり、計６０Ｗとなる。ボリュームＢ及びボリュームＣはスリープ化されているため、ボリュームＢの消費電力は単位時間当たり１Ｗ、ボリュームＣの消費電力は単位時間当たり２Ｗとなり、計３Ｗとなる。
【０３１０】
なお、ステップ２の処理の開始直前には、ボリュームＣをアクティブ化するための制御が実行される。ボリュームＣをアクティブ化するために必要な時間は、前述のように、５秒となる。この間、ボリュームＡは、アイドル状態となっている。
【０３１１】
このとき、消費電力は、ボリュームＡについては、単位時間当たり１５Ｗ、ボリュームＢについては、単位時間当たり１Ｗとなる。また、ボリュームＣについては、単位時間当たり２０Ｗ、ボリュームＤについては、単位時間当たり２０Ｗとなる。
【０３１２】
図５６は、本発明の第３の実施形態の問い合わせ実行計画案実行コスト表１２７を示す図である。
【０３１３】
ここで、図５４及び図５５に示した各問い合わせ実行計画案のボリュームの稼働状況を参照し、実行コストを計算する。
【０３１４】
まず、問い合わせ実行計画案３１について実行コストを計算する。図５４を参照すると、予測実行時間は、ステップ１であって前述のように９０秒となる。さらに、総消費電力量は、（２０Ｗ×９０秒）×２＋（４０Ｗ×９０秒）×２＝１０８００Ｊとなる。
【０３１５】
また、予測最大消費電力は、処理期間を通じて両方のボリュームがアクセス中であるため、２０Ｗ×２＋４０Ｗ×２＝１２０Ｗとなる。
【０３１６】
さらに、予測平均消費電力は、１０８００Ｊ／９０秒＝１２０Ｗとなる。
【０３１７】
次に、問い合わせ実行計画案３２について実行コストを計算する。図５５を参照すると、各ステップの所要時間を合計すると、９０秒となり、さらに、ステップ１からステップ２、ステップ２からステップ３の間に制御時間が各５秒かかる。したがって、予測実行時間は、９０＋５×２＝１００秒となる。
【０３１８】
消費電力量については、ボリュームＡは、２０Ｗ×３０秒×３（ステップ１〜３）＋１５Ｗ×５秒×２（ステップ間のアイドル時間）＝１９５０Ｊとなる。ボリュームＢは、２０Ｗ×３０秒（ステップ１）＋１０Ｗ×５秒（制御時間）＋１Ｗ×６５秒（スリープ時間）＝７１５Ｊとなる。ボリュームＣは、４０Ｗ×３０秒（ステップ２）＋２０Ｗ×５秒×３（制御時間）＋２Ｗ×（２５秒＋３０秒）（スリープ時間）＝１６１０Ｊとなる。ボリュームＤは、４０Ｗ×３０秒（ステップ３）＋２０Ｗ×５秒×２（制御時間）＋２Ｗ×６０秒（スリープ時間）＝１５２０Ｊとなる。
【０３１９】
以上より、予測総消費電力量は、１９５０（ボリュームＡ）＋７１５（ボリュームＢ）＋１６１０（ボリュームＣ）＋１５２０（ボリュームＤ）＝５７９５Ｊとなる。
【０３２０】
また、予測最大消費電力は、ボリュームＡのアクセス中にボリュームＣ又はボリュームＤがアクセス中のタイミングであるから、２０＋１＋４０＋２＝６３Ｗとなる。
【０３２１】
さらに、予測平均消費電力は、５７９５／１００＝５８．０Ｗとなる。
【０３２２】
以上の計算結果から図５６に示す問い合わせ実行計画案実行コスト表１２７を得ることができる。図５６に示す問い合わせ実行計画案実行コスト表１２７を参照すると、実行時間については、問い合わせ実行計画案３１の方が短いが、消費電力については問い合わせ実行計画案３２の方が少ない。
【０３２３】
ここで、本発明の第３の実施形態の具体例では、問い合わせとして図４７に示したＳＱＬがホスト計算機１に送信され、ＳＱＬヒント指示子に「総消費電力量優先」が指定されている。したがって、問い合わせ実行計画最適化部１２３は、各問い合わせ実行計画案の実行コストの予測総消費電力量の値を比較し、予測総消費電力量の値の少ない問い合わせ実行計画案３２を選択する。
【０３２４】
第３の実施形態によれば、ボリューム消費電力モデル情報表１２６をストレージ装置２から取得することによって、より詳細に消費電力量を調整することができる。
【０３２５】
また、第３の実施形態のように、データ量の少ない関係表Ｒと、複数のボリュームに分割され、膨大なデータ量を有し、かつ、索引を有する関係表Ｓを結合する場合には、消費電力量を大幅に削減することができる。
【０３２６】
（第４の実施形態）
第４の実施形態では、データが格納されるストレージ装置に対し、複数のデータベース管理システムからアクセスされる構成の省電力化について説明する。第４の実施形態では、ストレージ装置が各ボリュームのアクセス情報をホスト計算機１に提供することによって、各データベース管理システムで作成される問い合わせ実行計画を調停する。
【０３２７】
調停とは、作成された問い合わせ実行計画案の各ステップの実行が、処理を予定している他の問い合わせの実行と重なる場合に、重複する処理の実行を調整することをいう。
【０３２８】
図５７は、本発明の第４の実施形態の計算機システムの構成を示す図である。本発明の第４の実施形態の計算機システムは、第１の実施形態の構成に加えてホスト計算機１Ａを含む。なお、本発明の第４の実施形態の計算機システムでは、２台のホスト計算機が含まれているが、３台以上のホスト計算機が含まれていてもよい。
【０３２９】
ホスト計算機１は、第３の実施形態と同じ構成である。また、ホスト計算機１とホスト計算機１Ａは、同じ構成となっている。
【０３３０】
ストレージ装置２は、第３の実施形態の構成に加えて、制御部２０１に問い合わせ実行計画調停部２１５及びボリュームアクセス予定情報マスタ２１７を含む。
【０３３１】
問い合わせ実行計画調停部２１５は、各ホスト計算機のデータベース管理システム１２０の問い合わせ実行計画を調停するために、ストレージ装置２のボリュームのアクセス情報を提供する。
【０３３２】
ボリュームアクセス予定情報マスタ２１７は、ストレージ装置２によって提供されるボリュームのアクセス情報である。なお、ボリュームアクセス予定情報マスタ２１７の詳細は、図６１にて後述する。
【０３３３】
続いて、第４の実施形態におけるホスト計算機１のデータベース管理システム１２０及びストレージ装置２の制御部２０１の処理について、第３の実施形態と相違する点について説明する。
【０３３４】
ホスト計算機１のデータベース管理システム１２０では、問い合わせ実行計画最適化部１２３の処理が相違する。具体的には、調停情報を付与する処理と、決定された実行計画によるボリュームのアクセス予定情報をストレージ装置２に通知する処理が追加されている。問い合わせ実行計画最適化部１２３の処理の詳細は、図５８にて後述する。また、調停情報を付与する処理の詳細は、図５９にて後述する。
【０３３５】
ストレージ装置２の制御部２０１については、問い合わせ実行計画調停部２１５が追加されており、処理の詳細は図６０にて後述する。
【０３３６】
図５８は、本発明の第４の実施形態の問い合わせ実行計画最適化部１２３によって、問い合わせ実行計画を最適化する手順を示すフローチャートである。前述のように、本処理は、図２９に示した第２の実施形態の処理と比較して、問い合わせ実行計画に調停情報を付与する処理及び決定された実行計画によるボリュームのアクセス予定情報をストレージ装置２に通知する処理が追加されている点で相違する。
【０３３７】
演算装置１０１は、問い合わせ実行計画生成部１２２によって生成された問い合わせ実行計画案を受信すると（Ｓ７０１）、各問い合わせ実行計画案に調停情報を付与する（Ｓ５８０１）。具体的に調停情報を付与する処理の詳細は、図５９にて後述する。
【０３３８】
続いて、演算装置１０１は、各問い合わせ実行計画案に電力制御命令を付与する（Ｓ２９０１）。電力制御命令は、Ｓ５８０１の処理によって付与された調停情報を考慮して、付与される。
【０３３９】
さらに、演算装置１０１は、各問い合わせ実行計画案の実行コストの見積りを計算する（Ｓ７０２）。また、演算装置１０１は、計算された問い合わせ実行計画案の実行コストの見積りに基づいて、問い合わせ実行計画を決定する（Ｓ７０３）。
【０３４０】
演算装置１０１は、問い合わせ実行計画が決定すると、当該問い合わせ実行計画をストレージ装置２の制御部２０１に送信する（Ｓ５８０２）。このとき、ストレージ装置２の制御部２０１では、問い合わせ実行計画調停部２１５の処理が実行される。
【０３４１】
最後に、演算装置１０１は、決定された問い合わせ実行計画を問い合わせ実行部１２４に送信する（Ｓ７０４）。
【０３４２】
図５９は、本発明の第４の実施形態の問い合わせ実行計画最適化部１２３において、問い合わせ実行計画案に調停情報を付与する処理の手順を示すフローチャートである。本処理は、すべての問い合わせ実行計画案に対して実行される。
【０３４３】
演算装置１０１は、まず、ストレージ装置２の制御部２０１にボリュームアクセス予定情報要求を送信する（Ｓ５９０１）。
【０３４４】
演算装置１０１は、ストレージ装置２の制御部２０１からボリュームアクセス予定情報を受信すると（Ｓ５９０２）、すべての問い合わせ実行計画案のすべてのステップに対して、関係表等割当表１２８を参照し、アクセス対象のボリュームを特定する（Ｓ５９０３）。
【０３４５】
演算装置１０１は、問い合わせに電力調停許可を示す指示子が含まれているか否かを判定する（Ｓ５９０４）。具体的には、問い合わせに対応するＳＱＬに電力調停を許可するＳＱＬヒント指示子「ＥＮＡＢＬＥ＿ＰＯＷＥＲ＿ＡＲＢＩＴＲＡＴＩＯＮ」が含まれている場合である。
【０３４６】
演算装置１０１は、受信した問い合わせに電力調停を許可する指示子が含まれている場合には（Ｓ５９０４の結果が「Ｙｅｓ」）、アクセスされるボリュームのボリュームアクセス予定情報を参照し、ボリュームアクセス予定情報に合わせて各ステップの処理が実行されるように、待機等の調停情報を実行計画案に付与する（Ｓ５９０５）。
【０３４７】
なお、演算装置１０１は、受信した問い合わせに電力調停を許可する指示子が含まれていない場合には（Ｓ５９０４の結果が「Ｎｏ」）、本処理を終了する。
【０３４８】
図６０は、本発明の第４の実施形態のボリュームアクセス予定情報を読み書きする問い合わせ実行計画調停部２１５の処理手順を示すフローチャートである。
【０３４９】
ストレージ装置２の制御部２０１は、ホスト計算機からボリュームアクセス予定情報に関する要求を受信すると（Ｓ６００１）、受信した要求がボリュームアクセス予定情報の取得要求又はボリュームアクセス予定情報の通知のいずれかであるかを判定する（Ｓ６００２）。
【０３５０】
制御部２０１は、受信した要求がボリュームアクセス予定情報の通知の場合には（Ｓ６００２の結果が「ボリュームアクセス予定情報通知」）、通知されたボリュームアクセス予定情報に基づいて、ボリュームアクセス予定情報マスタ２１７を更新する（Ｓ６００３）。
【０３５１】
一方、制御部２０１は、受信した要求がボリュームアクセス予定情報の取得要求の場合には（Ｓ６００２の結果が「ボリュームアクセス予定情報の取得要求」）、ボリュームアクセス予定情報マスタ２１７を参照し、ボリュームアクセス予定情報を送信する（Ｓ６００４）。
【０３５２】
図６１は、本発明の第４の実施形態のホスト計算機及びストレージ装置間で送受信されるボリュームアクセス予定情報を示す図である。
【０３５３】
ホスト計算機及びストレージ装置間で送受信されるボリュームアクセス予定情報は、ボリュームごとに、ボリュームに対して実行される処理及び当該処理が実行される予定時刻が記録される。ストレージ装置２は、図６０に示した問い合わせ実行計画調停部２１５の処理によって、ホスト計算機１からボリュームアクセス予定情報を受信すると、ボリュームアクセス予定情報マスタ２１７を更新する。また、ホスト計算機１からの要求に応じて、ボリュームアクセス予定情報マスタ２１７を参照し、ボリュームアクセス予定情報を提供する。
【０３５４】
図６２は、本発明の第４の実施形態のボリュームアクセス予定情報マスタ２１７を示す図である。ボリュームアクセス予定情報マスタ２１７は、ボリュームごとに、計算機名、問い合わせ識別子、時刻及び情報が記録される。
【０３５５】
計算機名は、ストレージ装置２によって提供されるボリュームにアクセスするホスト計算機の名前が格納される。問い合わせ識別子は、当該ボリュームにアクセスする問い合わせの識別子が格納される。計算機名及び問い合わせ識別子は、ホスト計算機において、問い合わせ実行計画が決定されたときに、ボリュームアクセス予定情報とともに送信される。ボリュームアクセス予定情報は、図６１に示した内容と同じである。
【０３５６】
ここで、作成された問い合わせ実行計画案に調停情報を付与する手順について説明する。第２の実施形態において、図３２に示した問い合わせ実行計画案に基づいて説明する。
【０３５７】
図６３は、本発明の第４の実施形態の調停情報が付与された問い合わせ実行計画案を示す図である。
【０３５８】
問い合わせ実行計画案は、問い合わせ実行計画生成部１２２によって、処理部３２１が生成される。続いて、問い合わせ実行計画最適化部１２３によって、調停情報部６３０１が付与され（図５８のＳ５８０１）、さらに、電力制御命令部３２２が付与される（図５８のＳ２９０１）。その後、当該問い合わせ実行計画案の実行コストが計算され、問い合わせ実行計画が決定される。
【０３５９】
調停情報部６３０１は、図５９の処理によって付与される。現在時刻を「００：０４：５１」として、具体的に調停情報部６３０１を付与する手順を説明する。
【０３６０】
まず、演算装置１０１は、ストレージ装置２の制御部２０１にボリュームアクセス予定情報を要求し、取得する（図５９のＳ５９０１及びＳ５９０２）。
【０３６１】
続いて、演算装置１０１は、各ステップに調停情報を付与する。まず、関係表等割当表１２８を参照することによって、各ステップの処理でアクセスされるボリュームを特定する。具体的には、図３１に示した関係表等割当表１２８を参照すると、関係表ＲはボリュームＡ、関係表ＳはボリュームＢに格納されていることがわかる。
【０３６２】
次に、演算装置１０１は、図５９のＳ５９０２の処理で取得されたボリュームアクセス予定情報を参照し、アクセス対象のボリュームのボリューム予定情報に基づいて、待機等の調停情報を問い合わせ実行計画案に付与する。
【０３６３】
ここで、演算装置１０１は、ボリュームＡに「００：０５：０１」からアクセス可能な場合には、ステップ１の調停情報として「００：０５：０１まで待機」する旨の指示を付与する。同様に、ボリュームＢについては、ステップ１の処理が完了する００：０５：３６まで待機する旨の調停情報をステップ２に付与する。なお、別の問い合わせ処理によってボリュームＢが使用されている場合には、当該問い合わせ処理が完了する時刻まで待機するように調停情報を付与する。ステップ３については、ボリュームに直接アクセスしないため、調停情報は付与されない。
【０３６４】
その後、問い合わせ実行計画最適化部１２３の電力制御命令付与処理によって、電力制御命令部３２２が付与され、図６３に示した問い合わせ実行計画案を得ることができる。
【０３６５】
第４の実施形態では、複数のホスト計算機のデータベース管理システムがストレージ装置２のボリュームにアクセスする場合に、当該ボリュームのアクセス予定情報が保持される。第４の実施形態によれば、各ホスト計算機は、ボリュームのアクセス予定情報を参照することによって、各ホスト計算機による問い合わせ処理の実行タイミングを含む問い合わせ実行計画案を作成することができる。したがって、第４の実施形態によれば、他のホスト計算機による問い合わせ処理を考慮して、ストレージ装置２の消費電力を調整することができる。
【０３６６】
また、第４の実施形態によれば、アクセス予定情報を参照することによって、他の問い合わせ実行計画を考慮して問い合わせ実行計画を事前に作成するため、問い合わせ実行計画の各ステップの実行タイミングを調整することができる。一方、実行時に消費電力を調整する場合には、問い合わせ実行計画の各ステップは即時実行されるため、ボリュームのアクセス状況によっては、各ステップの実行間隔が長くなってしまい、十分に消費電力を低減することができない場合が考えられる。
【０３６７】
（第５の実施形態）
第５の実施形態では、同時期に受け付けた問い合わせを並列して処理する場合に、各問い合わせ処理について作成される問い合わせ実行計画の処理の一部又は全部が共有可能である場合には、処理を共有して問い合わせ実行計画を作成することによって、消費電力の低減を図る。
【０３６８】
第５の実施形態の計算機システムは、第２の実施形態の計算機システムと同じである。また、ホスト計算機１のデータベース管理システム１２０及びストレージ装置２の制御部２０１の処理についても、特に明示した処理を除き、第２の実施形態の共通である。さらに、ボリューム消費電力モデル情報表１２６についても、第２の実施形態と同じである。
【０３６９】
図６４は、本発明の第５の実施形態のアクセス対象のデータを含む関係表を格納するボリュームの構成を示す図である。
【０３７０】
本発明の第５の実施形態では、ボリュームＡに関係表Ｒが、ボリュームＢに関係表Ｓが、ボリュームＣに関係表Ｔが、ボリュームＤに関係表Ｕが格納されている。
【０３７１】
そこで、本発明の第５の実施形態では、具体例として、関係表Ｒ、Ｓ及びＴを結合する問い合わせ１と、関係表Ｒ、Ｓ及びＵを結合する問い合わせ２とが同時期に受け付けられ、並列して処理される場合について説明する。
【０３７２】
図６５は、本発明の第５の実施形態の問い合わせ１に対応するＳＱＬ６５０を示す図である。ＳＱＬ６５０は、関係表Ｒ、Ｓ及びＴを結合する。また、ＳＱＬ６５０には、電力制御を許可し、最大消費電力を優先するＳＱＬヒント指示子が含まれている。
【０３７３】
図６６は、本発明の第５の実施形態の問い合わせ２に対応するＳＱＬ６６０を示す図である。ＳＱＬ６６０は、関係表Ｒ、Ｓ及びＵを結合する。また、ＳＱＬ６６０には、ＳＱＬ６５０と同様に、電力制御を許可し、最大消費電力を優先するＳＱＬヒント指示子が含まれている。
【０３７４】
以下、問い合わせ１及び問い合わせ２の問い合わせ実行計画を生成し、処理を共有する手順について説明する。そして、問い合わせ１及び問い合わせ２を逐次実行する場合と、一部処理を共有して実行する場合について比較する。
【０３７５】
図６７は、本発明の第５の実施形態の問い合わせ１に対応する問い合わせ実行計画案５１と問い合わせ２に対応する問い合わせ実行計画案５２を説明する図である。
【０３７６】
問い合わせ実行計画案５１は、関係表Ｒと関係表Ｓを照合し、照合結果と関係表Ｔを照合する。
【０３７７】
詳細には、ステップ１として、関係表Ｒを読み込み、ハッシュ表Ｒ’を作成する。ステップ２として、関係表Ｓを読み込み、ハッシュ表Ｒ’を検索した照合結果に基づいて、ハッシュ表ＲＳ’を作成する。さらに、ステップ３として、関係表Ｔを読み込み、ハッシュ表ＲＳ’を検索した照合結果を回答として出力する。
【０３７８】
同様に、問い合わせ実行計画案５２は、関係表Ｒと関係表Ｓを照合し、照合結果と関係表Ｕを照合する。
【０３７９】
さらに詳細には、ステップ１として、関係表Ｒを読み込み、ハッシュ表Ｒ’を作成する。ステップ２として、関係表Ｓを読み込み、ハッシュ表Ｒ’を検索した照合結果に基づいて、ハッシュ表ＲＳ’を作成する。さらに、ステップ３として、関係表Ｕを読み込み、ハッシュ表ＲＳ’を検索した照合結果を回答として出力する。
【０３８０】
問い合わせ実行計画案５１及び問い合わせ実行計画案５２を比較すると、ステップ１及びステップ２（図６７の太線で囲った部分）が共通する。そこで、問い合わせ実行計画案５１及び問い合わせ実行計画案５２を逐次実行する手順を新たに問い合わせ実行計画案５３とし、ステップ１及びステップ２の処理を共有化した手順を新たに問い合わせ実行計画案５４とする。
【０３８１】
図６８は、本発明の第５の実施形態の問い合わせ実行計画案５３の手順を示す図である。問い合わせ実行計画案５３の各ステップは、問い合わせ実行計画案５１の各ステップと問い合わせ実行計画案５２の各ステップとを連結したものである。
【０３８２】
また、問い合わせ実行計画案５３には、電力制御命令が付与されている。付与された電力制御命令は、ボリュームのアクセス前にアクティブ化し、アクセス終了後にスリープ化するのみであるため、詳細の説明は省略する。
【０３８３】
図６９は、本発明の第５の実施形態の問い合わせ実行計画案５４の手順を示す図である。問い合わせ実行計画案５４では、問い合わせ実行計画案５１及び問い合わせ実行計画案５２に共通するステップ１及びステップ２の処理を共有する。具体的には、ステップ１及びステップ２の処理によって作成されるハッシュ表ＲＳ’を共有する。
【０３８４】
また、問い合わせ実行計画案５４にも、問い合わせ実行計画案５３と同様に、電力制御命令が付与されている。
【０３８５】
続いて、図７０及び図７１に各問い合わせ実行計画案を実行した場合の各ボリュームの稼働状況を示す。関係表Ｒ、関係表Ｓ、関係表Ｔ及び関係表Ｕを読み込むために要する時間は、各３０秒とする。ボリュームの各状態における電力消費量などは、図９のボリューム消費電力モデル情報表１２６に従う。なお、各問い合わせ実行計画案が実行される前には、各ボリュームは、アクティブ状態となっている。
【０３８６】
図７０は、本発明の第５の実施形態の問い合わせ実行計画案５３のボリュームの稼働状況を示す図である。
【０３８７】
問い合わせ実行計画案２２のステップ１では、ボリュームＡにおいて、関係表Ｒが読み込まれてハッシュ表Ｒ’が作成される。このとき、関係表Ｒの読み込みには３０秒の時間を要する。したがって、ステップ１の所要時間は、３０秒である。また、消費電力は、図９を参照すると、単位時間当たり２０Ｗとなる。
【０３８８】
一方、ボリュームＢ、ボリュームＣ及びボリュームＣは、ステップ１の処理の直前に、スリープ化させる電力制御命令が送信される。本処理実行時には、各ボリュームはアクティブ化されているため、アクティブ状態からスリープ状態に移行するように制御される。したがって、図９を参照すると、ステップ１の開始から５秒間は状態移行のための制御が実行され、この間の単位時間当たりの消費電力は、１０Ｗとなる。また、ステップ１の処理が完了する時刻までの残り２５秒間はスリープ状態となるため、単位時間当たりの消費電力は、１Ｗとなる。
【０３８９】
ステップ２では、ボリュームＢにおいて、関係表Ｓが読み込まれてハッシュ表Ｒ’を検索し、照合結果に基づいてハッシュ表ＲＳ’が作成される。このとき、関係表Ｓの読み込みには３０秒の時間を要する。したがって、ステップ２の所要時間は、３０秒である。また、消費電力は、単位時間当たり２０Ｗとなる。
【０３９０】
ボリュームＡは、ステップ１の処理が終了したため、アクティブ状態からスリープ状態に移行するように制御される。また、ボリュームＢについては、スリープ状態からアクティブ状態に移行するように制御される。そこで、ステップ２の処理開始前に、ボリュームＡ及びボリュームＢについて、５秒間ずつ電力制御が実行される。なお、この間の消費電力は単位時間当たり１０Ｗである。ボリュームＣ及びボリュームＤについては、ステップ１からスリープ状態が継続される。
【０３９１】
ステップ３では、ボリュームＣにおいて、関係表Ｔが読み込まれてハッシュ表ＲＳ’を検索し、照合結果を回答として出力する。このとき、関係表Ｔの読み込みには３０秒の時間を要する。したがって、ステップ３の所要時間は、３０秒である。また、消費電力は、単位時間当たり２０Ｗとなる。
【０３９２】
ボリュームＢは、ステップ２の処理が終了したため、アクティブ状態からスリープ状態に移行するように制御される。また、ボリュームＣについては、スリープ状態からアクティブ状態に移行するように制御される。そこで、ステップ３の処理開始前に、ボリュームＢ及びボリュームＣについて、５秒間ずつ電力制御が実行される。ボリュームＡ及びボリュームＤについては、ステップ２からスリープ状態が継続される。
【０３９３】
ステップ４及びステップ５の処理は、概ねステップ１及びステップ２の処理と同じである。また、ステップ６の処理は、ボリュームＣに格納された関係表Ｔを読み込む代わりにボリュームＤに格納された関係表Ｕについて処理する点がステップ３の処理と相違する。
【０３９４】
図７１は、本発明の第５の実施形態の問い合わせ実行計画案５４のボリュームの稼働状況を示す図である。
【０３９５】
ステップ１、ステップ２及びステップ３の処理は、問い合わせ実行計画案５３のステップ１、ステップ２及びステップ３の処理と同じである。また、ステップ４の処理は、問い合わせ実行計画案５３のステップ６の処理と同じである。ただし、ステップ６の処理で検索されるハッシュ表ＲＳ’は、ステップ３の処理と共有される。
【０３９６】
図７１を参照すると、問い合わせ実行計画案５３のステップ４及びステップ５の処理が削減されたため、実行時間及び消費電力ともに削減されている。
【０３９７】
図７２は、本発明の第５の実施形態の問い合わせ実行計画案実行コスト表１２７を示す図である。
【０３９８】
以下、図７０及び図７１に示した各問い合わせ実行計画案のボリュームの稼働状況を参照し、実行コストを計算する。
【０３９９】
まず、問い合わせ実行計画案５３について実行コストを計算する。図７０を参照すると、各ステップの実行時間が３０秒で、３０秒×６＝１８０秒、さらに、各ステップ間の制御時間が５秒で、５秒×５＝２５秒要する。したがって、予測実行時間は、１８０＋２５＝２０５秒となる。
【０４００】
続いて、消費電力について計算する。ステップ１では、ボリュームＡについては、アクセス中であるため、２０Ｗ×３０秒＝６０Ｊとなる。ボリュームＢ〜Ｄについては、最初にスリープ状態とするために制御時間５秒を要し、その後２５秒スリープ状態となる。したがって、１０Ｗ×５秒＋１Ｗ＋２５秒＝７５Ｊとなる。よって、ステップ１は、６００Ｊ＋７５Ｊ×３＝８２５Ｊとなる。
【０４０１】
次に、ステップ２の処理開始前に、ボリュームＡをスリープ状態に、ボリュームＢをアクティブ状態に移行させる。この間、ボリュームＡ及びボリュームＢについては、１０Ｗ×５秒＝５０Ｊ、ボリュームＣ及びボリュームＤについては、スリープ状態であるため、１Ｗ×５秒＝５Ｊとなる。したがって、この間の消費電力は、５０Ｊ×２＋５Ｊ×２＝１１０Ｊとなる。また、ステップ２の処理自体は、２０Ｗ×３０秒＋１Ｗ×３０秒×３＝６９０Ｊとなる。
【０４０２】
ステップ３からステップ６の処理についても、ボリュームＡ〜Ｄのいずれかのボリュームが１つずつアクティブ化及びスリープ化され、その後、１つのボリュームにアクセスされる。したがって、消費電力は、ステップ２と同様に、それぞれ６９０Ｗとなる。
【０４０３】
よって、予測総消費電力量は、８２５Ｊ（ステップ１）＋（１１０Ｊ＋６９０Ｊ）×５（ステップ２〜６）＝４８２５Ｊとなる。
【０４０４】
また、予測最大消費電力は、処理開始時のボリュームＡがアクセス中、ボリュームＢ〜Ｄが制御中のタイミングとなるため、２０Ｗ＋１０Ｗ×３＝５０Ｗとなる。
【０４０５】
さらに、予測平均消費電力は、４８２５Ｊ／２０５秒＝２３．５４Ｗとなる。
【０４０６】
次に、問い合わせ実行計画案５４について実行コストを計算する。図７１を参照すると、各ステップの実行時間が３０秒で、３０秒×４＝１２０秒、さらに、各ステップ間の制御時間が５秒で、５秒×３＝１５秒要する。したがって、予測実行時間は、１２０＋１５＝１３５秒となる。
【０４０７】
消費電力量については、ステップ１からステップ４までの処理について、問い合わせ実行計画案５３と同じである。したがって、予測総消費電力量は、８２５Ｊ（ステップ１）＋（１１０Ｊ＋６９０Ｊ）×３（ステップ２〜４）＝３２２５Ｊとなる。
【０４０８】
また、予測最大消費電力は、問い合わせ実行計画案５３と同じく、処理開始時のボリュームＡがアクセス中、ボリュームＢ〜Ｄが制御中のタイミングとなるため、２０Ｗ＋１０Ｗ×３＝５０Ｗとなる。
【０４０９】
さらに、予測平均消費電力は、３２２５Ｊ／１３５秒＝２３．８９Ｗとなる。
【０４１０】
以上の計算結果から図７２に示す問い合わせ実行計画案実行コスト表１２７を得ることができる。本発明の第５の実施形態では、問い合わせに「総消費電力量優先」が指定されている。したがって、問い合わせ実行計画最適化部１２３は、各問い合わせ実行計画案の実行コストの予測総消費電力量の値を比較し、予測総消費電力量の値の少ない問い合わせ実行計画案５４を選択する。
【０４１１】
第５の実施形態によれば、複数の問い合わせ処理が同時に実行される場合には、共有可能な処理を共有して実行することができる。したがって、処理を高速化するとともに、本発明の電力制御命令などを加えて問い合わせ実行計画を作成することによって、消費電力をより一層削減することが可能となる。また、過去に実行されたＳＱＬの処理又は解析結果がキャッシュされている場合には、キャッシュされたＳＱＬの処理又は解析結果を利用してもよい。
【０４１２】
以上説明した本発明の実施形態では、ＳＱＬに指示子を含ませることによって省電力指示を行なっていたが、データベース管理システムのシステム設定によって省電力指示を行なってもよい。例えば、データベース管理システムの設定ファイルに図１２に示した最適化指標を指定する項目を追加する。そして、設定ファイルに指定された最適化指標に基づいて、問い合わせ実行計画最適化部１２３の処理を実行すればよい。このように、データベース管理システムの設定ファイルに最適化指標を指定することによって、ＳＱＬに指示子を含ませずに、指定された最適化指標に基づいて、問い合わせ実行計画を最適化することができる。
【０４１３】
また、以上説明した実施形態では、問い合わせ実行計画の最適化方法として、コストベースの最適化方法を適用したが、ルールベースの最適化方法を併用してもよい。
【図面の簡単な説明】
【０４１４】
【図１】本発明の第１の実施形態の計算機システムの構成を示す図である。
【図２】本発明の第１の実施形態のボリュームに格納されるデータベースの構成要素を示す図である。
【図３】本発明の第１の実施形態の問い合わせを受け付けてから回答を取得するまでの処理の流れを示す図である。
【図４】本発明の第１の実施形態の問い合わせ受付部によって、問い合わせを受け付けてから、要求元にデータを回答するまでの手順を示すフローチャートである。
【図５】本発明の第１の実施形態の問い合わせ実行計画生成部によって、問い合わせの実行計画を生成する手順を示すフローチャートである。
【図６】本発明の第１の実施形態の問い合わせ実行計画生成部によって生成された問い合わせ実行計画案の一例を示す図である。
【図７】本発明の第１の実施形態の問い合わせ実行計画最適化部によって、問い合わせ実行計画を最適化する手順を示すフローチャートである。
【図８】本発明の第１の実施形態の問い合わせ実行計画最適化部において、問い合わせ実行計画案の実行コストの見積りを算出する手順を示すフローチャートである。
【図９】本発明の第１の実施形態の問い合わせ実行計画最適化部の処理において、問い合わせ実行計画案の実行コストを算出するために使用されるボリューム消費電力モデル情報表を示す図である。
【図１０】本発明の第１の実施形態のボリュームの状態遷移、ボリュームの状態ごとの消費電力量、及びボリュームの状態遷移の際の消費する電力量を示す図である。
【図１１】本発明の第１の実施形態の問い合わせ実行計画最適化部によって記録される問い合わせ実行計画案実行コスト表である。
【図１２】本発明の第１の実施形態の最適化指標に対応するＳＱＬヒント指示子の例を示す表である。
【図１３】本発明の第１の実施形態のＳＱＬヒント指示子を追加したＳＱＬの一例を示す図である。
【図１４】本発明の第１の実施形態の問い合わせ実行計画最適化部によって、問い合わせ実行計画案から問い合わせ実行計画を決定する手順を示すフローチャートである。
【図１５】本発明の第１の実施形態の問い合わせ実行部によって、問い合わせ実行計画を実行する手順を示すフローチャートである。
【図１６】本発明の第１の実施形態のストレージ装置の入出力処理部によって、ホスト計算機から受信した入出力要求を処理する手順を示すフローチャートである。
【図１７】本発明の第１の実施形態のストレージ装置によって提供されるボリュームの情報を格納するボリューム情報表である。
【図１８】本発明の第１の実施形態のストレージ装置の自動電力制御部によって、アクティブ状態のボリュームをスリープ状態に移行させる手順を示すフローチャートである。
【図１９】本発明の第１の実施形態のアクセス対象の関係表を格納するボリュームの構成を示す図である。
【図２０】本発明の第１の実施形態の問い合わせに対応するＳＱＬを示す図である。
【図２１】本発明の第１の実施形態の問い合わせ実行計画案１１の関係表を結合する組み合わせを示す図面である。
【図２２】本発明の第１の実施形態の問い合わせ実行計画案１１の手順を示す図である。
【図２３】本発明の第１の実施形態の問い合わせ実行計画案１２の関係表を結合する組み合わせを示す図面である。
【図２４】本発明の第１の実施形態の問い合わせ実行計画案１２の手順を示す図である。
【図２５】本発明の第１の実施形態の問い合わせ実行計画案１１のボリュームの稼働状況を示す図である。
【図２６】本発明の第１の実施形態の問い合わせ実行計画案１２のボリュームの稼働状況を示す図である。
【図２７】本発明の第１の実施形態の問い合わせ実行計画案実行コスト表を示す図である。
【図２８】本発明の第２の実施形態の計算機システムの構成を示す図である。
【図２９】本発明の第２の実施形態の問い合わせ実行計画最適化部によって、問い合わせ実行計画を最適化する手順を示すフローチャートである。
【図３０】本発明の第２の実施形態の問い合わせ実行計画最適化部において、問い合わせ実行計画案に電力制御命令を付与する手順を示すフローチャートである。
【図３１】本発明の第２の実施形態の関係表と関係表が格納されたボリュームとの対応を含む関係表等割当表を示す図面である。
【図３２】本発明の第２の実施形態の電力制御命令が付与された問い合わせ実行計画を示す表である。
【図３３】本発明の第２の実施形態の問い合わせ実行部によって、問い合わせ実行計画を実行する手順を示すフローチャートである。
【図３４】本発明の第２の実施形態のストレージ装置の制御部が電力制御命令を受信したときの電力制御命令処理部による処理の手順を示す図である。
【図３５】本発明の第２の実施形態のアクセス対象の関係表を格納するボリュームの構成を示す図である。
【図３６】本発明の第２の実施形態の問い合わせに対応するＳＱＬを示す図である。
【図３７】本発明の第２の実施形態の問い合わせ実行計画案２１の手順を示す図である。
【図３８】本発明の第２の実施形態の問い合わせ実行計画案２２の手順を示す図である。
【図３９】本発明の第２の実施形態の問い合わせ実行計画案２１のボリュームの稼働状況を示す図である。
【図４０】本発明の第２の実施形態の問い合わせ実行計画案２２のボリュームの稼働状況を示す図である。
【図４１】本発明の第２の実施形態の問い合わせ実行計画案実行コスト表を示す図である。
【図４２】本発明の第３の実施形態の計算機システムの構成を示す図である。
【図４３】本発明の第３の実施形態の問い合わせ実行計画最適化部において、問い合わせ実行計画案の実行コストを算出する手順を示すフローチャートである。
【図４４】本発明の第３の実施形態のボリューム消費電力モデル情報表の構成を示す図である。
【図４５】本発明の第３の実施形態の問い合わせ実行計画案の実行コストを計算する際に、ボリューム消費電力モデル情報表を要求する処理の手順を示すフローチャートである。
【図４６】本発明の第３の実施形態のアクセス対象の関係表を格納するボリュームの構成を示す図である。
【図４７】本発明の第３の実施形態の問い合わせに対応するＳＱＬを示す図である。
【図４８】本発明の第３の実施形態のボリュームＡ及びボリュームＢのボリューム消費電力モデル情報表を示す表である。
【図４９】本発明の第３の実施形態のボリュームＣ及びボリュームＤのボリューム消費電力モデル情報表を示す表である。
【図５０】本発明の第３の実施形態の問い合わせ実行計画案３１の関係表を結合する組み合わせを示す図面である。
【図５１】本発明の第３の実施形態の問い合わせ実行計画案３１の手順を示す図である。
【図５２】本発明の第３の実施形態の問い合わせ実行計画案３２の関係表を結合する組み合わせを示す図面である。
【図５３】本発明の第３の実施形態の問い合わせ実行計画案３２の手順を示す図である。
【図５４】本発明の第３の実施形態の問い合わせ実行計画案３１のボリュームの稼働状況を示す図である。
【図５５】本発明の第３の実施形態の問い合わせ実行計画案３２のボリュームの稼働状況を示す図である。
【図５６】本発明の第３の実施形態の問い合わせ実行計画案実行コスト表を示す図である。
【図５７】本発明の第４の実施形態の計算機システムの構成を示す図である。
【図５８】本発明の第４の実施形態の問い合わせ実行計画最適化部によって、問い合わせ実行計画を最適化する手順を示すフローチャートである。
【図５９】本発明の第４の実施形態の問い合わせ実行計画最適化部において、問い合わせ実行計画案に調停情報を付与する処理の手順を示すフローチャートである。
【図６０】本発明の第４の実施形態のボリュームアクセス予定情報を読み書きする問い合わせ実行計画調停部の処理手順を示すフローチャートである。
【図６１】本発明の第４の実施形態のホスト計算機及びストレージ装置間で送受信されるボリュームアクセス予定情報を示す図である。
【図６２】本発明の第４の実施形態のボリュームアクセス予定情報マスタ２１７を示す図である。
【図６３】本発明の第４の実施形態の調停情報が付与された問い合わせ実行計画案を示す図である。
【図６４】本発明の第５の実施形態のアクセス対象のデータを含む関係表を格納するボリュームの構成を示す図である。
【図６５】本発明の第５の実施形態の問い合わせ１に対応するＳＱＬを示す図である。
【図６６】本発明の第５の実施形態の問い合わせ２に対応するＳＱＬを示す図である。
【図６７】本発明の第５の実施形態の問い合わせ１に対応する問い合わせ実行計画案５１と問い合わせ２に対応する問い合わせ実行計画案５２を説明する図である。
【図６８】本発明の第５の実施形態の問い合わせ実行計画案５３の手順を示す図である。
【図６９】本発明の第５の実施形態の問い合わせ実行計画案５４の手順を示す図である。
【図７０】本発明の第５の実施形態の問い合わせ実行計画案５３のボリュームの稼働状況を示す図である。
【図７１】本発明の第５の実施形態の問い合わせ実行計画案５４のボリュームの稼働状況を示す図である。
【図７２】本発明の第５の実施形態の問い合わせ実行計画案実行コスト表を示す図である。
【符号の説明】
【０４１５】
１、１Ａ  ホスト計算機
２        ストレージ装置
３        クライアント
５        ネットワーク
１０１    演算装置
１０２    主記憶装置
１０３、１０４    インタフェース
１１０    アプリケーションプログラム
１２０    データベース管理システム
１２１    問い合わせ受付部
１２２    問い合わせ実行計画生成部
１２３    問い合わせ実行計画最適化部
１２４    問い合わせ実行部
１２６    ボリューム消費電力モデル情報表
１２７    問い合わせ実行計画案実行コスト表
１２８    関係表等割当表
２０１    制御部
２０２    記憶部
２０３    インタフェース
２１１    入出力処理部
２１２    自動電力制御部
２１３    電力制御命令処理部
２１４    消費電力情報管理部
２１５    問い合わせ実行計画調停部
２１６    ボリューム情報表
２１７    ボリュームアクセス予定情報マスタ
２２１    補助記憶装置
２２２    二次記憶装置
【図１】
2008210003.tif 000003
【図２】
2008210003.tif 000004
【図３】
2008210003.tif 000005
【図４】
2008210003.tif 000006
【図５】
2008210003.tif 000007
【図６】
2008210003.tif 000008
【図７】
2008210003.tif 000009
【図８】
2008210003.tif 000010
【図９】
2008210003.tif 000011
【図１０】
2008210003.tif 000012
【図１１】
2008210003.tif 000013
【図１２】
2008210003.tif 000014
【図１３】
2008210003.tif 000015
【図１４】
2008210003.tif 000016
【図１５】
2008210003.tif 000017
【図１６】
2008210003.tif 000018
【図１７】
2008210003.tif 000019
【図１８】
2008210003.tif 000020
【図１９】
2008210003.tif 000021
【図２０】
2008210003.tif 000022
【図２１】
2008210003.tif 000023
【図２２】
2008210003.tif 000024
【図２３】
2008210003.tif 000025
【図２４】
2008210003.tif 000026
【図２７】
2008210003.tif 000027
【図２８】
2008210003.tif 000028
【図２９】
2008210003.tif 000029
【図３０】
2008210003.tif 000030
【図３１】
2008210003.tif 000031
【図３２】
2008210003.tif 000032
【図３３】
2008210003.tif 000033
【図３４】
2008210003.tif 000034
【図３５】
2008210003.tif 000035
【図３６】
2008210003.tif 000036
【図３７】
2008210003.tif 000037
【図３８】
2008210003.tif 000038
【図４１】
2008210003.tif 000039
【図４２】
2008210003.tif 000040
【図４３】
2008210003.tif 000041
【図４４】
2008210003.tif 000042
【図４５】
2008210003.tif 000043
【図４６】
2008210003.tif 000044
【図４７】
2008210003.tif 000045
【図４８】
2008210003.tif 000046
【図４９】
2008210003.tif 000047
【図５０】
2008210003.tif 000048
【図５１】
2008210003.tif 000049
【図５２】
2008210003.tif 000050
【図５３】
2008210003.tif 000051
【図５６】
2008210003.tif 000052
【図５７】
2008210003.tif 000053
【図５８】
2008210003.tif 000054
【図５９】
2008210003.tif 000055
【図６０】
2008210003.tif 000056
【図６１】
2008210003.tif 000057
【図６２】
2008210003.tif 000058
【図６３】
2008210003.tif 000059
【図６４】
2008210003.tif 000060
【図６５】
2008210003.tif 000061
【図６６】
2008210003.tif 000062
【図６７】
2008210003.tif 000063
【図６８】
2008210003.tif 000064
【図６９】
2008210003.tif 000065
【図７２】
2008210003.tif 000066
【図２５】
2008210003.tif 000067
【図２６】
2008210003.tif 000068
【図３９】
2008210003.tif 000069
【図４０】
2008210003.tif 000070
【図５４】
2008210003.tif 000071
【図５５】
2008210003.tif 000072
【図７０】
2008210003.tif 000073
【図７１】
2008210003.tif 000074