JP2009037369A - データベースサーバへのリソース割当て方法 - Google Patents

Abstract

【課題】
データ量の増加や複数バッチ処理の同時実行によりバッチ処理が予め設定した要求時間内に終了しない課題がある。
【解決手段】
バッチ処理実行中にて既に実行済みＳＱＬの処理時間及びリソース使用量をもとに未実行バッチ処理手順の処理時間及びリソース使用量を算出した後、バッファヒット率等のデータベースサーバの状態を示す情報、I/O回数やCPU負荷などのOSの情報を用いて処理手順及びリソース使用量を再計算し、必要に応じてリソースの割当てを行う。
【選択図】 図１

Description

本発明は、データベース管理システムに適した予め実行する内容が既知である一連のデータベース実行処理に好適なリソース割当て方法に関するものである。

ＤＢＭＳ(DataBase Management System:データベース管理システム)は、データベースのデータに対する問い合わせに答えるシステムである。
データベースシステムへはデータベース処理要求、例えばＳＱＬ（Structured Query Language）を用いてデータの取り出し、書き込みを行う。
ひとつのデータベースシステムに対して、バッチ処理と呼ばれる予め実行する内容が既知である一連のＳＱＬでは、オンライン処理が停止もしくはアクセス量が少ない夜間等に行なわれる場合が多い。しかし、近年、ネットビジネスが拡大する中、２４時間３６５日のサービスを提供するシステムが求められている。
オンライン処理とバッチ処理が同時に稼働する環境において、複数のバッチ処理が要求時間内に確実に終了することが重要となっている。要求時間内にバッチ処理が終了しない現象が発生すると、業務に多大な影響を与える。また、バッチ処理はその特性上、負荷が集中するサーバやリソースが変化する場合が多い。

例えば、１ヶ月の注文表と商品表より１ヶ月の売上高表を作成するバッチ処理の場合、注文表及び商品表をデータベースよりアクセスする際、表がメモリ上に存在する場合は、該当データをメモリから取得する。メモリ上に存在しない場合は、該当データをディスクから取得する。該当データをディスクから取得する場合、Ｉ／Ｏが発生する。このため、該当データがメモリに存在しない場合が多いほど、ディスクＩ／Ｏが多く発生することになる。
また、注文表と商品表より売上高表を作成する際、一次表を作成するため、ＣＰＵの消費及びディスクＩ／Ｏが発生する。
このようなバッチ処理の場合、負荷が集中する箇所全てにＣＰＵやメモリを十分な量を割当てておくことは資源の有効活用の観点から得策ではない。
負荷が集中している箇所へのリソースの割当てが効果的であるが、バッチ処理では、前記のとおり、負荷の集中する箇所が時間によって変化するため、システム管理者が負荷の集中する時間帯を予測するのは困難であり、予め多くのリソース割当てている場合が多い。

バッチ処理を構成するＳＱＬを解析することで、大まかな処理時間及び必要なリソース量を算出することは可能である。例えば、非特許文献１に記載された技術は、ＤＢＭＳのディクショナリに保管された、処理対象となる問い合わせに関する各種統計情報を基にして、各処理フェーズを分配している。

Joel L. Wolf、John Turek、 Ming-Syan Chen and Philip S. Yu著、"A Hierarchical Approach to Parallel Multiquery Scheduling"、IEEE Transactionson Parallel and Distributed Systems、 6(6):578--590、 June 1995.

データ量の増加や複数バッチ処理の同時実行によりバッチ処理が予め設定した要求時間内に終了しない課題がある。
データ量の増加には、ＣＰＵやメモリの割当てを行う場合が多いが、バッチ処理の特性としてＣＰＵやメモリに対しての負荷の集中は一時的であり、負荷が集中するＣＰＵやメモリは変化するため、ＣＰＵやメモリを有効活用する必要がある。近年、サーバ仮想化技術によりＣＰＵやメモリを瞬時に切り替えることが可能となっているが、バッチ制御にあわせてＣＰＵやメモリを切り替えるには負荷が集中するリソースの予測が困難であるため、運用コスト削減の観点で問題であった。
複数バッチ処理の同時実行やオンライン処理との同時実行においても、バッチ処理の特性である負荷が集中するＣＰＵやＩ／Ｏへの負荷集中は一時的であるため、バッチ処理同士の実行制御を設計する必要があり、運用コスト削減の観点で問題であった。

バッチ処理実行中にて既に実行済みＳＱＬの処理時間及びリソース使用量をもとに未実行バッチ処理手順の処理時間及びリソース使用量を算出した後、バッファヒット率等のデータベースサーバの状態を示す情報、I/O回数やCPU負荷などのOSの情報を用いて処理手順及びリソース使用量を再計算し、必要に応じてリソースの割当てを行う。

本発明によれば、システムの負荷が変動する環境において、実行中のバッチ処理が続行可能かどうかを早期に判断し、システム運用管理者に連絡することにより、早期に対処を可能とする。

本発明を実施するための最良の形態について図１を用いて具体的に説明する。
予め実行する内容が既知である一連のＳＱＬをバッチ処理と呼ぶ。
また、オンラインショッピングに代表されるようなインターネット等を介して多数のユーザが接続し、実行する内容や手順が既知でない処理のことをオンライン処理と呼ぶ。
バッチ処理はオンライン処理と異なり、予め実行する内容が既知であり、実行する順序も決まっている。バッチ処理実行前もしくはバッチ処理実行中に、未実行のＳＱＬを事前に解析し、ＳＱＬ文の実際に実行するステップ数（ダイナミックステップ数）と予め割当てられたＣＰＵ数及び想定のＣＰＵ利用率より該当バッチ処理のＳＱＬの実行にかかる時間（処理時間）を算出する。
算出した処理時間によりバッチ処理の終了予想時刻が算出でき、バッチ処理の終了予想時刻が予め設定したバッチ処理終了要求時刻を越える場合は、管理者に通知し、バッチ処理の停止等の制御を行う。
具体的な例を用いて説明する。
アプリケーションプログラム１がバッチ処理を実行すると、データベース管理システムはＳＱＬを解析、実行する。
バッチ処理実行中に図１のフローチャートを定期的に実行することで、バッチ終了要求時間内に、バッチ処理を終了させることが可能となることを示している。

ステップ４０００より開始する。本実施例では、ＳＱＬが１０％実行済みの状態で開始していることを示している。ステップ４０００の実行間隔はユーザの設定により変更が可能である。実行間隔が短いほど必要なリソースをすばやく割当てることが可能となる。

ステップ４００１にて、現在実行中バッチの実行時間、バッチ実行時のバッファヒット率、バッチが作成する一次表サイズを取得する。ここでバッファヒット率とは、要求されたデータがメモリ上に存在する確率を表している。バッファヒット率が高いほど、実行時間は短くなる。

図１の例では、ステップ４００１にて１０％実行時の情報２０００を取得したとする。なお、バッチ実行前に予め図１６に示す方法で実行予定のＳＱＬを解析し、予想バッファヒット率、予想一次表サイズ、予想実行時間を算出済みとする。
ステップ４００２にて、現在の実行時間は予定通りか判定する。実行時間が予定時間よりも短い場合は、問題なしとしてステップ４０１０に移る。実行時間が予定通りでない場合は、リソース追加を行う必要があるため、ステップ４００３に移る。
ステップ４００３にて、１０％実行時のバッファヒット率が予想より高い場合は、問題なしとして、ステップ４００６に移る。１０％実行時のバッファヒット率が予想より低い場合は、バッファヒット率が低いために、実行時間が予定通り進んでないと判断し、ステップ４００４に移る。ステップ４００４ではメモリ割当て量を計算し、ステップ４００５に移る。

ステッ４００５において、ステップ４００４で算出したメモリを割当て、ステップ４００６に移る。
ステップ４００６にて、１０％実行時の一次表のサイズが予想より小さい場合は、問題なしとして、ステップ４００９に移る。
１０％実行時の一次表のサイズが予想より大きい場合は、一次表のサイズが大きいために実行時間が予定通り進んでいないと判断する。
このため、ステップ４００７において、１０％実行時の一次表のサイズでの必要なＣＰＵ量を算出し、ステップ４００８において、ステップ４００７で算出したＣＰＵ量を割当て、ステップ４００９に移る。

ステップ４００９では、ステップ４００５及びステップ４００８で割当てたリソースでの実行時間の再計算を行い、予定時間内にバッチが終了するかどうか判定する。
終了する見込みの場合は、ステップ４０１０にて終了時刻を提示し、終了する。
予定時間内にバッチが終了しない見込みの場合は、ステップ４０１１にて管理者に通知し、終了する。

図２は、本実施形態のデータベース管理システムの構成を示す一例である。
システム開発者が作成したアプリケーションプログラム１と問い合わせ処理やリソース管理などのデータベースシステム全体の管理を行うデータベース管理システム６がある。

上記のアプリケーションプログラム１は、ネットワークを通じて多数の要求を受け付けるオンライン処理または予め実行する内容が既知であるバッチ処理に分けられる。
バッチ処理では、実行する内容としてバッチ実行情報２１００を有する。

上記のデータベース管理システム６は、ＳＱＬ解析部１０、リソース管理部３０、処理部２０を具備する。
また、データベース管理システム６は、データベースアクセス対象となるデータを永続的にあるいは一時的に格納するデータベース３、そしてバッチ統計情報２２００、ＳＱＬ単価情報２３００、ＤＢ解析情報２４００、ＯＳ統計情報２５００、ＣＰＵ管理情報２６００を有する。
上記データベース管理システム６は、ネットワークなどを介して他のシステムと接続されている。１つのデータベース管理システムは複数の処理部２０を配置することにより負荷を分散させ、大規模なデータベースに対するデータ処理も高速に実現することができる。

サーバ仮想化機構２は、ＣＰＵ１００５、Ｉ／Ｏ制御装置１００６、通信制御装置１００１−３を具備しており、サーバ仮想化機構２の機能によってＤＢサーバの処理をＣＰＵ１００５、Ｉ／Ｏ制御装置、通信制御装置に割当てることができる。ＣＰＵは１つのＣＰＵもしくは複数のＣＰＵによって実現される。
上記データベース管理システム６は、サーバ仮想化機構２に対してＣＰＵ割当てを指示するリソース管理部３０を具備する。

図３は本実施形態におけるコンピュータシステムのハードウェア構成の一例を示す図である。
この例のコンピュータシステムは、情報処理装置１０００、１１００及び１２００を含む。
情報処理装置１０００は、通信制御装置１００１−１、ＣＰＵ１００５−１、主記憶装置１００２−１、Ｉ／Ｏ制御装置１００６−１により構成される。主記憶装置１００２−１上には、ＯＳ１００３−１及びアプリケーションプログラム１００４が置かれ、ＣＰＵ１００５−１を用いて稼働している。
アプリケーションプログラム１００４がＤＢＭＳ６の処理部２０にユーザ問い合わせを行うと、情報処理装置１０００の通信制御装置１００１−１と情報処理装置１１００の通信制御装置１００１−３によって、ネットワーク１３００を経由してＤＢＭＳ６の処理部２０に問い合わせ要求が送られる。
アプリケーションプログラム１００４は管理者が実行するため、実行する時刻が決められている場合が多い。

情報処理装置１１００は、サーバ仮想化機構２が配置されている。
サーバ仮想化機構２上には、ＣＰＵ１００５−３、ＣＰＵ１００５−４、ＣＰＵ１００５−５、通信制御装置１００１−３、主記憶装置１００２−３、主記憶装置１００２−４、Ｉ／Ｏ制御装置１００６−３により構成されている。
主記憶装置１００２上にはＯＳ１００３が配置されている。サーバ仮想化機構２では複数のＯＳを置くことが可能であり、独立して稼働することができる。
主記憶装置１００２上には、それぞれのＯＳ１００３−３、ＯＳ１００３−４上で稼働するデータベース処理部２０を有するデータベース管理システム６が置かれ、サーバ仮想化機構２によって割当てられたＣＰＵ１００５−３、ＣＰＵ１００５−４またはＣＰＵ１００５−５、を用いて稼働している。これら複数のＯＳ上で動作するＤＢＭＳ１００６は独立して稼働することができ、例えば一つのＤＢＭＳはバッチ処理用、もう一つのＤＢＭＳはオンライン用とすることが可能である。

外部記憶装置４上には、データベース管理システム６が管理するデータベース３が格納される。
ＤＢＭＳ６はＩ／Ｏ制御装置１００６−３によりＩ／Ｏパス１３００を通じて外部記憶装置４からデータの読み出し、書き出しを行い、通信制御装置１００１−３によりネットワークで接続された他の通信制御装置１００１−１または１００１−２とデータの送受信を行う。Ｉ／Ｏ制御装置１００６−３においても、サーバ仮想化機構２によって割当てられたＩ／Ｏパス１３００を使用して外部記憶装置４よりデータの読み出し、書き出しを行う。
通信制御装置１００１−３についてもサーバ仮想化機構２によって使用するネットワーク１３００が割当てられる。

情報処理装置１２００は、通信制御装置１００１−２、ＣＰＵ１００５−２、主記憶装置１００２−２、Ｉ／Ｏ制御装置１００６−２により構成される。主記憶装置１００２−２上には、ＯＳ１００３−２及びクライアントサーバ１００７が置かれ、ＣＰＵ１００５−２を用いて稼働している。
クライアントサーバ１００７はユーザ端末１００８よりネットワーク１３００を経由して問い合わせを受け取ると、情報処理装置１１００のＤＢＭＳ６に対してネットワーク１３００及び通信制御装置１００１−３を経由して問い合わせ処理を行う。通常、ユーザからの問い合わせは不定期である。

以下、具体例を用いて説明する。
図４は、顧客からの注文時に注文の内容を記録する注文表を示す。注文表には、注文時に採番される一意の注文No、一意の商品を表す商品No、一意の顧客を表す顧客ID、注文時の日時を表す注文日時がある。注文発生すると、注文表に一行追加される。
図５に商品表を示す。商品表には一意の商品を表す商品No、商品の名前を表す商品名、商品の値段を表す値段、商品の区分を表す商品区分がある。管理している全商品に商品Noが割当てられている。

図４の注文表及び図５の商品表より１ヶ月間の商品ごとの売上高を計算する。
売上高表を作成するために実行するＳＱＬ文の例を図６に示す。
図６の例では、注文表と商品表より注文表の注文日時が’06/04/01’以降の注文表に関して、注文表の商品Noと商品表の商品Noが一致した商品を抽出し、図７に示す売上高表を作成する。

図７に作成される売上高表を示す。
売上高表は一意の商品を表す商品No、商品の名前を表す商品名、商品ごとの一ヶ月間の注文の総数を表す総注文数、商品ごとの一ヶ月間の売上高を表す総売上高がある。
売上高表は商品コードで昇順にソートしている。注文表と商品表のマージ処理を行う際、作業表と呼ばれる一時的な表をデータベース領域に作成する。作業表はデータベース３に割当てられている。

図８に予想処理時間算出に必要な情報を示す。
一件検索するステップ数とは、ＳＱＬ実行時に１件を検索するときに実際に走行するステップ数を示す。本ステップ数より、１秒あたりＣＰＵが何ステップ実行可能かの情報を元に実行時間を算出する。注文表サイズ及び商品表サイズより一次表のサイズが算出可能である。一次表のサイズより単位時間あたりのＩ／Ｏ回数が算出可能である。上記予想値より、バッチの実行時間が算出可能である。
図１４のフローを用いて予想処理時間及び予想一次表サイズを計算する。

図９に予測値の一例を表す。
バッファヒット率とは、データベースアクセス時にディスクＩ／Ｏ時間の短縮のため、一部のデータベース情報をメモリ上に格納しており、そのヒット率である。ヒット率が高いほど、処理時間が長いＩ／Ｏ回数が減り、ＳＱＬの処理時間が早くなる。検索範囲が広範囲になるほど、バッファヒット率は低下する。
予想ＣＰＵ利用率とは、ＳＱＬ実行時のＣＰＵ利用率を表す。

図１０に、１０％実行時のバッチ実行中の実測値の例１を示す。
図１０の例では、１０％実行時の実行時間が予想値１００秒に対して１２０秒要している。このため、図１のステップ４００２において、実行時間が予想値を越えているため、ステップ４００３に移る。ステップ４００３において、バッファヒット率が予想値７０％に対して実測値が６０％となっているため、ステップ４００４に移る。ステップ４００４にて、バッファヒット率とメモリ量の統計データより予想バッファヒット率以上となるようにメモリ量を算出し、ステップ４００５において、メモリ割当て指示をリソース管理部３０に対して行う。リソース管理部３０では、サーバ仮想化機構２に対して要求量のメモリが割当て可能か問い合わせを行う。割当て可能な場合は、割当てを行う。
割り当てが不可能な場合は、割当て可能分のみ割当てを行う。

図１１にバッチ実行中の実測値の例２を示す。
図１１の例では、実行時間が予想値１００秒に対して１２０秒要している。このため、図１のステップ４００２において、実行時間が予想値を越えているため、ステップ４００３に移る。ステップ４００３において、バッファヒット率は予想値と同じであるため、ステップ４００６に移る。
ステップ４００６において、一次表のサイズが予想よりも大きいため、ステップ４００７に移る。ステップ４００７において、１０％実行時の一次表のサイズの処理を行うためにはどの程度のＣＰＵ数が必要か統計データより算出する。
ステップ４００８において、ステップ４００７で算出したＣＰＵ数をリソース管理部３０に通知する。リソース管理部３０では、サーバ仮想化機構２に対して必要なＣＰＵ数の割当て依頼を行い、割当てを行う。

ステップ４００４では、必要数分のメモリ量をサーバ仮想化機構２より割当てることになるが、サーバ仮想化機構２が要求数の割当量を確保していない場合がある。この場合は、他のオンライン処理等で使用しているメモリを割当てるかどうか判定し、割当てる場合は、他のオンライン処理等で使用しているメモリをバッチ処理に割当てる。他のオンライン処理等で使用しているメモリを割当てるかどうかは予め管理者が定義しているものとする。詳細は図２０に示す。

図１２にメモリ量とバッファヒット率の統計データの表を示す。バッチ実行前に統計データとして表ごとにメモリ量とバッファヒット率の統計情報を取得する。実測したバッファヒット率を、予測したバッファヒット率にするために、バッファメモリを何バイトにするかを判断するため、図１２のメモリ量とバッファヒット率を使用する。

図１３に一次表作成時に一定時間内で終了させるのに必要なCPU数と一次表サイズの関係を表す表を示す。一次表作成時、一次表に対してソート処理等が行われるため、一次表サイズが大きくなるほど必要なCPU数が多くなる。バッチ処理を行う前に必要なCPU数と一次表サイズの関係を統計データとして取得する。
図１４にステップ単価を表す図３０００を示す。
図１４では、１件selectを行うのに６０００ステップ必要であることを示している。同様に１件insertを行うのに５０００ステップ、１件updateを行うのに７０００ステップ、１件deleteを行うのに４０００ステップが必要であることを示している。

図１５に、ダイナミックステップ数を算出する処理フローを示す。
ステップ４００００より実行するトランザクションを解析する。
ステップ４００１０にて、トランザクションを構成するＳＱＬの解析を実行する。ステップ４００２０からステップ４００９０において、該当処理に応じてステップ単価を求めていく。図１４の例では、ステップ４００２０ではselect処理がある場合は、ステップ４００３０でselectのステップ単価を総量に加えることを示している。同様にステップ４００４０の場合はinsert処理がある場合は、ステップ４００５０でinsertのステップ単価を総量に加える。同様にステップ４００６０ではupdate処理がある場合はステップ４００７０でupdateのステップ単価を総量に加える。同様にステップ４００８０ではdelete処理がある場合はdelete処理のステップ単価を加える。
ステップ４０１００にて、全ての解析が完了したかどうかを判定し、解析が完了していない場合は、ステップ４０１２０に移る。
ステップ４０１２０では、未解析の次のＳＱＬに移り、ステップ４００１０より解析を行う。
ステップ４０１００にて、全ての解析処理が終了した場合は、ステップ４０１１０にてトランザクション解析処理を終了する。
例えば、図６のSQL文において１件あたりのselect単価が６０００ステップの場合、１００件検索するのに要するダイナミックステップ数は６０００００ステップとなる。

図１６に、予想処理時間及び予想一次表サイズの算出方法を示す、
ステップ５０００にて、バッチ処理を構成するＳＱＬを解析する。ステップ５００１にて、解析により、インデクスの有無、参照または更新する表のサイズを取得する。ステップ５００２にて、ステップ５０００、ステップ５００１の情報を元に、ＳＱＬのステップ単価を算出する。ここで、ＳＱＬのステップ単価とは、１ＳＱＬを実行するのに必要なステップ数である。
ステップ５００３にて、ステップ５００２で算出したＳＱＬステップ単価及び割当てられているCPU数、想定するCPU利用率、予想バッファヒット率より統計データに基づいて予想処理時間を算出する。
ステップ５００４にて、ＳＱＬ解析より予想一次表サイズを計算する。
具体的に図６の２１００で示すSQLと図７で示す商品表及び図８で示す予想処理時間算出に必要な情報より一時表のサイズを算出する。
ステップ５００１にて、インデクス有無と参照または更新する表のサイズを判定し、インデクスなしで表のサイズは５００Mbyteと取得する。
該当するSQLで１件検索するステップ単価を計算する。この計算式はSQLを実行するプログラムの走行するステップ数を求めるものであり、予め与えられている。これにより１件検索するステップ数は５０００ステップを算出する。

図１７にステップ４００４のメモリ割当量計算の詳細フローを示す。
ステップ５１００にて、DBMSより現在のバッファヒット率を取得する。
ステップ５１０１にて、予想バッファヒット率になるように、メモリ割当て統計データ２８００よりメモリ割当量を計算する。
実測値が２８００の例では、バッファヒット率が６０％、一次表のサイズが１００Mｂｙｔｅである。事前の統計データよりもヒット率が低いため、バッファヒット率を７０％にするようにメモリ割当量を計算する。

ステップ５１０２にて、サーバ仮想化機構２に対して、ステップ５１０１で算出したメモリ量を割当てるよう要求する。

図１８にステップ４００７のCPU量計算の詳細フローを示す。
ステップ５２００にて、DBMSより現在の一次表のサイズを取得する。
ステップ５２０１より現在の一次表サイズより最終的な一次表サイズを計算する。
ステップ５２０２にて、最終的な一次表サイズをもとに、CPU割当て統計データ２９００より必要なCPU数を算出する。
ステップ５２０３にてサーバ仮想化機構２に必要なCPU数を要求する。

図１９にＤＢＭＳシステム毎の優先度の例を表す図３０００を示す。
図３０００では、情報処理装置１１００上に３つのＤＢＭＳが稼働していることを表している。
ＤＢＭＳ１は情報処理装置１０００から実行されるバッチ処理１を実行しており、優先度は一番高い。ＢＤＭＳ２は情報処理装置１０００から実行されるバッチ処理２を実行しており、優先度はバッチ処理１の次に高い。ＤＢＭＳ３は情報処理装置１２００から実行されるオンライン処理を実行しており、優先度は低い事を表している。

図２０に図１のステップ４０１１の詳細フローを示す。
ステップ５３００にてサーバ仮想化機構が保持しているリソースを移動しても予想時間内にバッチが終了しない見込みの場合は、ステップ５３０１にて、サーバ仮想化機構内で他のＤＢＭＳが動作しているか判定し、他のＤＢＭＳで動作している場合は、ステップ５３０２に移る。
ステップ５３０２では、優先順位表３０００に従い他のＤＢＭＳで使用しているリソースを必要量だけ割当てるようサーバ仮想化機構に要求する。
ステップ５３０３にて、管理者に通知する。
具体的には、ステップ５２００にて最終的な処理量の半分時点での一次表のサイズが２００Ｍｂｙｔｅの場合、ステップ５２０１で最終的な一次表のサイズは４００Ｍｂｙｔｅとなる。この時の必要なＣＰＵ数はCPU割当て統計データ２９００より４つであるため、ステップ５２０３にてサーバ仮想化機構に４つのＣＰＵの割当てを要求する。

本発明の概念図である。 本実施形態のデータベース処理システムの機能ブロックを示す図である。 本実施形態のコンピュータシステムのハードウェア構成の一例を示す図である。 本実施形態のＤＢに格納する注文表の一例を示す図である。 本実施形態のＤＢに格納する商品表の一例を示す図である。 本実施形態のＳＱＬ文の一例を示す図である。 本実施形態のＤＢに格納する売上高表の一例を示す図である。 本実施形態の実行時間算出に用いるための事前取得情報を示す図である。 本実施形態の予測値の一例を示す図である。 本実施形態のバッチ実行中の実測値の例１を示す図である。 本実施形態のバッチ実行中の実測値の例２を示す図である。 本実施形態のメモリ割当て統計データを示す図である。 本実施形態のＣＰＵ割当て統計データを示す図である。 本実施形態のステップ単価を表す図である。 本実施形態のダイナミックステップ数を求めるフローチャートである。 本実施形態の一次表サイズを求めるフローチャートである。 本実施形態のメモリ割当量の算出方法を示すフローチャートである。 本実施形態のＣＰＵ割当量の算出方法を示すフローチャートである。 本実施形態のＤＢＭＳの優先順位を表す優先順位表の例である。 本実施形態の他ＤＢＭＳよりリソースを割当てるフローチャートである。

符号の説明

２０００・・・ＳＱＬ解析情報
２１００・・・バッチ実行情報
２２００・・・ＤＢに格納する商品表の一例
２３００・・・ＤＢに格納する売上高表の一例

Claims (8)

1. アプリケーションプログラムを実行するサーバとデータベースサーバとサーバ仮想化機構を備えるシステムのデータベースサーバへのリソース割当て方法であって、
   前記データベースサーバは一連の受付処理を行う処理部とは別に前記アプリケーションプログラムで実行される内容が既知である一連のデータベース処理要求を定期的に解析するＳＱＬ解析部において、
   前記アプリケーションプログラムで実行される内容が既知である一連のデータベース処理要求が現在の実行時間、バッファヒット率、データベースが内部で作成する一次表サイズを取得するステップと、
   現在の実行時間が予め設定した実行時間以下かどうか判定するステップと、
   現在の実行時間が予め設定した実行時間を超える場合は、データベースサーバの状態を示す情報とバッファヒット率とメモリ量との統計データより予想バッファヒット率になるようにメモリ割当量を算出するステップと、
   メモリ割当量に従いメモリを割当てる要求をするステップと、
   データベースが内部で作成する一次表サイズが予め予測したサイズを超える場合は、データベースサーバの状態を示す情報と現在の一次表のサイズにおいて、追加すべきＣＰＵ数を統計データより算出するステップと、
   算出した必要なＣＰＵ数を割当てる要求をするステップと、
   予定時間内にバッチ処理が終了する見込みか判定するステップと、
   予定時間内に終了する見込みの場合は、終了時刻を提示するステップと、
   予定時間内にバッチ処理が終了する見込みでない場合は管理者に通知するステップを有する
   ことを特徴とするデータベースサーバへのリソース割当て方法。
2. 請求項１に記載のデータベースサーバへのリソース割当て方法において、
   以前実行した前記アプリケーションプログラムで実行される内容が既知である一連のデータベース処理要求は、
   以前実行したデータベース処理要求のアクセスするデータベースが保持するデータ件数、データベース処理要求の実行に要した時間、ＣＰＵ利用率の情報を含むことを特徴とするデータベースサーバへのリソース割当て方法。
3. 請求項１に記載のデータベースサーバへのリソース割当て方法において、
   前記データベースサーバの状態を示す情報は、前記データベースサーバで使用されているアクセスするデータベースが保持するデータ件数、単位時間あたりのＩ／Ｏ回数のうちの少なくとも一つの情報を含むことを特徴とするデータベースサーバへのリソース割当て方法。
4. 請求項１に記載の前記ＣＰＵ使用量を算出した情報をもとに、サーバ仮想化機構に対してＣＰＵの割当てを指示することリソース管理部を有することを特徴とするデータベースサーバへのリソース割当て方法。
5. 請求項１に記載の前記アプリケーションプログラムは予め一連の要求元の指定によって一つないし複数を同時に実行することを特徴とするデータベースサーバへのリソース割当て方法。
6. 請求項１に記載の一連の手順を予め一連の要求元の指定によって定期的に実行することを特徴とするデータベースサーバへのリソース割当て方法。
7. 請求項１に記載の前記アプリケーションプログラムで実行される内容が既知である一連のデータベース処理要求が以前実行した前記アプリケーションプログラムで実行される内容が既知である一連のデータベース処理要求として、データベース格納領域に格納されるテーブル名、処理時間、リソース利用率の情報を含むことを特徴とするデータベースサーバへのリソース割当て方法。
8. 請求項１のリソースとは、ＣＰＵ、メモリの少なくとも一つを含むことを特徴とするデータベースサーバへのリソース割当て方法。

Images