(57)【要約】複数のデータベースを集約する前に、集約後のデータベースにおけるバッファキャッシュのヒット率等の稼働状況を推定できる技術を提供する。  推定装置１は、取得部２と、推定部３とを有している。取得部２は、集約対象のデータベースにおける稼働状況の情報を取得する機能を有する。推定部３は、取得した前記稼働状況を利用して、前記集約対象のデータベースにおける稼働状況と当該データベースに関連付けられるバッファキャッシュの容量との関係を表す方程式を生成する機能を備えている。推定部３は、さらに、複数の前記集約対象のデータベースを集約した後の集約データベースに関連付けられる集約バッファキャッシュの容量と、前記方程式とに基づいて、前記集約データベースの稼働状況を推定する機能を備えている。
2014041760.tif 000002
【特許請求の範囲】
【請求項１】
集約対象のデータベースにおける稼働状況の情報を取得する取得手段と、
取得した前記稼働状況を利用して、前記集約対象のデータベースにおける稼働状況と当該データベースに関連付けられるバッファキャッシュの容量との関係を表す方程式を生成し、複数の前記集約対象のデータベースを集約した後の集約データベースに関連付けられる集約バッファキャッシュの容量と、前記方程式とに基づいて、前記集約データベースの稼働状況を推定する推定手段とを有する推定装置。
【請求項２】
前記取得手段は、前記集約対象のデータベースの稼働状況として、当該集約対象のデータベースに対するデータ読み出し要求に該当するデータが前記バッファキャッシュに格納されている確率であるヒット率を取得し、
前記推定手段は、前記方程式として、その取得したヒット率とバッファキャッシュの容量との関係を表す方程式を生成し、当該方程式を利用して、前記集約データベースの稼働状況を推定する請求項１記載の推定装置。
【請求項３】
前記取得手段は、さらに、前記集約対象のデータベースの稼働状況として、単位時間当たりのデータ読み出し要求の数であるデータ読み出し要求数を取得し、
前記推定手段は、前記取得手段が取得した前記データ読み出し要求数と前記ヒット率を利用して、前記データ読み出し要求に該当するデータが前記バッファキャッシュに格納されていない単位時間当たりの前記データ読み出し要求の数である物理ＩＯ（Input Output）数を前記集約対象のデータベースにおける稼働状況として算出し、さらに、当該推定手段は、その物理ＩＯ数と前記バッファキャッシュの容量との関係を表す方程式をも生成し、当該方程式をも利用して、前記集約データベースの稼働状況を推定する請求項２記載の推定装置。
【請求項４】
前記推定手段は、前記各集約対象のデータベースに対応する前記物理ＩＯ数の比と、前記集約バッファキャッシュにおいて前記各集約対象のデータベースが占める容量の比とが等しいという条件に基づいて、前記集約バッファキャッシュにおいて前記各集約対象のデータベースが占める容量、あるいは、前記各集約対象のデータベースに対応する物理ＩＯ数を解とする連立方程式を、前記方程式および前記集約バッファキャッシュの容量を利用して生成し、当該連立方程式を解くことにより、前記集約データベースの稼働状況を推定する請求項３記載の推定装置。
【請求項５】
前記推定手段は、前記方程式を生成する雛形を利用して、前記方程式を生成する請求項１乃至請求項４の何れか一つに記載の推定装置。
【請求項６】
集約対象のデータベースにおける稼働状況の情報をコンピュータが取得し、
取得した前記稼働状況を利用して、前記集約対象のデータベースにおける稼働状況と当該データベースに関連付けられるバッファキャッシュの容量との関係を表す方程式をコンピュータが生成し、
複数の前記集約対象のデータベースを集約した後の集約データベースに関連付けられる集約バッファキャッシュの容量と、前記方程式とに基づいて、前記集約データベースの稼働状況を推定するデータベース稼働状況推定方法。
【請求項７】
集約対象のデータベースにおける稼働状況の情報を取得する処理と、
取得した前記稼働状況を利用して、前記集約対象のデータベースにおける稼働状況と当該データベースに関連付けられるバッファキャッシュの容量との関係を表す方程式を生成する処理と、
複数の前記集約対象のデータベースを集約した後の集約データベースに関連付けられる集約バッファキャッシュの容量と、前記方程式とに基づいて、前記集約データベースの稼働状況を推定する処理とをコンピュータに実行させる処理手順を示すコンピュータプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、データベースの稼働状況（バッファキャッシュのヒット率や物理ＩＯ(Input Output)／秒）を推定する技術に関する。
【背景技術】
【０００２】
特許文献１には、キャッシュヒット率を推定する装置（キャッシュヒット率推定装置）が開示されている。キャッシュヒット率とは、データの読み出し指令（データを読み出すことを要求する指令）において指定されたデータがキャッシュ装置にキャッシュされている確率である。特許文献１に開示されているキャッシュヒット率推定装置は、キャッシュ装置にキャッシュされている各データが読み出される状況を計測し、この計測値を利用してキャッシュヒット率を推定している。【０００３】
また、非特許文献１には、ワーキングセット法に基づいた式（１）に従って、キャッシュヒット率Ｈを算出する記載がある。
2014041760.tif 000003
【０００４】
ただし、式（１）中におけるｘはオブジェクト（読み出し対象データ）を表す。Ｄxは、オブジェクトｘが参照される（読み出される）時間間隔（参照間隔）を表す。πxは、オブジェクトｘが参照される確率を表す。Ｐr｛Ｄx≦Ｔ｝は、時間Ｔ内にオブジェクトｘが参照される確率を表す。
【先行技術文献】
【特許文献】
【０００５】
【特許文献１】特開２００５−３３９１９８号公報
【非特許文献】
【０００６】
【非特許文献１】田中淳裕著、「キャッシュのモデル化とその応用」、オペレーションズリサーチ、Vol.４９、２００４年７月、pp.４３４−４３７
【発明の概要】
【発明が解決しようとする課題】
【０００７】
ところで、データベースシステムでは、データベースを管理するコンピュータ（サーバ）における主記憶装置（メインメモリ）において、データベース管理単位であるインスタンス毎に、バッファキャッシュとして機能するメモリ領域が割り当てられる。また、規模の大きなデータベースシステムは、１台のサーバや１台のストレージ装置（ハードディスク装置）では処理し切れないことが多いため、複数のサーバおよび複数のストレージ装置により構築される。【０００８】
これに対し、近年、性能的な理由から分かれていた複数のインスタンスが１つのインスタンスに集約（統合）される場合が出てきている。その理由の一つは、ＣＰＵ（Central Processing Unit）のコア数が増加したことによりＣＰＵ性能が向上したことである。また別の理由の一つは、フラッシュメモリドライブ（ＳＳＤ（Solid State Drive））が登場したことである。【０００９】
複数のインスタンスを集約する前（換言すれば、データベースを集約する前）に、例えばシステム設計のために、インスタンス（データベース）を集約した後のデータベースの稼働状況を推定したい場合がある。データベースの稼働状況とは、例えば、バッファキャッシュのヒット率である。【００１０】
しかしながら、特許文献１や非特許文献１に示されている技術を利用して、データベース集約前に、集約後のデータベースの稼働状況を推定しようとしても推定することが難しいという問題がある。つまり、特許文献１や非特許文献１に示されている技術では、キャッシュヒット率を推定する場合に、データの読み出しに関する計測値（実測値）を利用する。しかし、集約する前には集約後のデータベースに関する計測値（実測値）を得ることができない。このために、特許文献１や非特許文献１に示される技術では、集約後のデータベースに関するキャッシュヒット率を推定できない。【００１１】
本発明は上記課題を解決するために考え出された。すなわち、本発明の主な目的は、複数のデータベース（インスタンス）を集約する前に、集約後のデータベースにおけるバッファキャッシュのヒット率等の稼働状況を予め推定できる技術を提供することにある。
【課題を解決するための手段】
【００１２】
上記目的を達成するために、本発明の推定装置は、
集約対象のデータベースにおける稼働状況の情報を取得する取得手段と、
取得した前記稼働状況を利用して、前記集約対象のデータベースにおける稼働状況と当該データベースに関連付けられるバッファキャッシュの容量との関係を表す方程式を生成し、複数の前記集約対象のデータベースを集約した後の集約データベースに関連付けられる集約バッファキャッシュの容量と、前記方程式とに基づいて、前記集約データベースの稼働状況を推定する推定手段とを有する。【００１３】
本発明のデータベース稼働状況推定方法は、
集約対象のデータベースにおける稼働状況の情報をコンピュータが取得し、
取得した前記稼働状況を利用して、前記集約対象のデータベースにおける稼働状況と当該データベースに関連付けられるバッファキャッシュの容量との関係を表す方程式をコンピュータが生成し、
複数の前記集約対象のデータベースを集約した後の集約データベースに関連付けられる集約バッファキャッシュの容量と、前記方程式とに基づいて、前記集約データベースの稼働状況を推定する。【００１４】
本発明のプログラム記憶媒体は、
集約対象のデータベースにおける稼働状況の情報を取得する処理と、
取得した前記稼働状況を利用して、前記集約対象のデータベースにおける稼働状況と当該データベースに関連付けられるバッファキャッシュの容量との関係を表す方程式を生成する処理と、
複数の前記集約対象のデータベースを集約した後の集約データベースに関連付けられる集約バッファキャッシュの容量と、前記方程式とに基づいて、前記集約データベースの稼働状況を推定する処理とをコンピュータに実行させるコンピュータプログラムが記憶されている。【００１５】
なお、本発明の前記主な目的は、上記構成の本発明の推定装置に対応するデータベース稼働状況推定方法によっても達成される。また、本発明の主な目的は、本発明の推定装置、データベース稼働状況推定方法をコンピュータによって実現するコンピュータプログラム、および、当該コンピュータプログラムを格納する記憶媒体によっても達成される。
【発明の効果】
【００１６】
本発明によれば、複数のデータベース（インスタンス）を集約する前に、集約後のデータベースにおけるバッファキャッシュのヒット率等の稼働状況を予め推定できる。
【図面の簡単な説明】
【００１７】
【図１】本発明に係る第１実施形態の推定装置の構成を簡略化して表すブロック図である。
【図２】第１実施形態の推定装置を実現するハードウェア構成を説明するブロック図である。
【図３】データベースを集約する前と集約後のハードウェア構成の変更例（１）をイメージで表すモデル図である。
【図４】データベースを集約する前と集約後のハードウェア構成の変更例（２）をイメージで表すモデル図である。
【図５】データベースを集約する前と集約後のハードウェア構成の変更例（３）をイメージで表すモデル図である。
【図６】本発明に係る第２実施形態の推定装置の構成を簡略化して表すブロック図である。
【図７】データベース管理システムの構成例を簡略化して表すブロック図である。
【図８】データベースに関連付けられるバッファキャッシュの容量とヒット率との関係を説明するグラフである。
【発明を実施するための形態】
【００１８】
以下に、本発明に係る実施の形態を図面を参照しながら説明する。
【００１９】
（第１実施形態）
図１は、本発明に係る第１実施形態の推定装置の構成を簡略化して表すブロック図である。この第１実施形態の推定装置１は、複数のデータベースを集約する前に、集約後のデータベースの稼働状況を推定できる装置である。
【００２０】
ここで、データベースを集約する前と集約後のハードウェア構成の変更に関し簡単に説明する。図３は、データベースを集約する前と集約後のハードウェア構成の変更例（１）をイメージで表すモデル図である。この図３において、データベースが集約される前には、データベースＡはサーバＡによって管理されている。このサーバＡにおけるメインメモリＡには、データベースＡに関連付けられているバッファキャッシュＡとして機能するメモリ領域が割り当てられている（設定されている）。また、データベースＢは、サーバＢによって管理されている。このサーバＢにおけるメインメモリＢには、データベースＢに関連付けられているバッファキャッシュＢとして機能するメモリ領域が割り当てられている（設定されている）。
【００２１】
図３の例では、データベースＢを格納しているハードディスク装置（記憶装置）にデータベースＡが追加（集約）され、データベースＣが構築される。また、サーバＡにおけるデータベースＡに関わる情報（管理情報など）がサーバＢに追加される。さらに、サーバＢにおけるメインメモリＢには、データベースＣに関連付けられているバッファキャッシュＣとして機能するメモリ領域が割り当てられる。このような集約処理によって、サーバＢがデータベースＣを一つのインスタンス（データベース管理単位）として管理するデータベース管理システム（ＤＢＭＳ（Database Management System））が構築される。
【００２２】
図４は、データベースを集約する前と集約後のハードウェア構成の変更例（２）をイメージで表すモデル図である。この変更例（２）では、サーバＡによって管理されているデータベースＡと、サーバＢによって管理されているデータベースＢとが、サーバＣによって管理されるハードディスク装置に集約される。これにより、データベースＣが構築される。また、サーバＡ，ＢからデータベースＡ，Ｂに関わる情報（管理情報など）がサーバＣに移される。さらに、サーバＣにおけるメインメモリＣには、データベースＣに関連付けられるバッファキャッシュＣとして機能するメモリ領域が割り当てられる。このような集約処理によって、サーバＣがデータベースＣを一つのインスタンスとして管理するデータベース管理システム（ＤＢＭＳ）が構築される。
【００２３】
図５は、データベースを集約する前と集約後のハードウェア構成の変更例（３）をイメージで表すモデル図である。この変更例（３）では、サーバＡによってそれぞれ管理されているデータベースＡ，Ｂが集約されることによって、データベースＣが構築される。また、サーバＡにおいて、データベースＡ，Ｂに関する各情報（管理情報など）が集約される。さらに、データベースＣに関連付けられているバッファキャッシュＣとして機能するメモリ領域がメインメモリＡに割り当てられる。このような集約処理によって、サーバＡがデータベースＣを一つのインスタンスとして管理するデータベース管理システム（ＤＢＭＳ）が構築される。
【００２４】
この第１実施形態の推定装置１は、上記のように集約した後のデータベースの稼働状況を推定できる装置である。当該推定装置１は、図１に表されるように、取得部（取得手段）２と、推定部（推定手段）３とを有している。なお、推定装置１は、データベース管理システムを構成する管理装置（サーバ）に内蔵されていてもよいし、当該管理装置とは別であってもよい。
【００２５】
取得部２は、集約する対象のデータベース（以下、対象データベースとも記す）の稼働状況の情報を取得する機能を有する。推定部３は、取得した前記稼働状況を利用して、前記対象データベースにおける稼働状況と当該対象データベースに関連付けられているバッファキャッシュの容量との関係を表す方程式を生成する機能を有する。さらに、推定部３は、複数の前記対象データベースを集約した後の集約データベースに関連付けられる集約バッファキャッシュの容量と、前記方程式とに基づいて、前記集約データベースの稼働状況を推定する機能を備えている。
【００２６】
この第１実施形態の推定装置１は、上記の如く、複数の対象データベースを集約して集約データベースを構築する場合に、集約前の各データベース（対象データベース）の稼働状況を取得する。そして推定装置１は、その取得した集約前のデータベースの稼働状況を利用して、集約後のデータベース（集約データベース）の稼働状況を推定する。つまり、推定装置１は、集約データベースの稼働状況に関わる実測値を用いずに、集約データベースの稼働状況を推定できる。このことから、推定装置１は、複数のデータベース（対象データベース）を集約する前に、予め、集約データベースの稼働状況を得る（推定する）ことができる。
【００２７】
この第１実施形態の推定装置１は、例えば、図２に表されるようなハードウェアによって実現できる。すなわち、図２に表される推定装置１は、記憶装置５と、処理装置６とを有している。
【００２８】
記憶装置５は、コンピュータプログラム（プログラム）やデータを記憶する装置である。例えばＲＡＭ（Random Access Memory）やハードディスク装置が記憶装置５として用いられる。この第１実施形態では、記憶装置５には、推定装置１の動作を制御する処理手順を含むプログラム７が格納されている。つまり、記憶装置５は、プログラム７を記憶するプログラム記憶媒体として機能する。
【００２９】
処理装置６は、例えばＣＰＵ（Central Processing Unit）を含むハードウェア資源により構成されている。この処理装置６は記憶装置５からプログラム７を読み込み、当該プログラム７を実行することにより、取得部２および推定部３を実現する。
【００３０】
（第２実施形態）
以下に、本発明に係る第２実施形態を説明する。
【００３１】
図６は、本発明に係る第２実施形態の推定装置２０の構成を簡略化して表すブロック図である。この推定装置２０は、前記図３〜図５に表されるようにデータベースが集約される前に、集約後のデータベース（集約データベース）の稼働状況を推定する装置である。
【００３２】
ところで、図７に表されるように、データベース管理システム（ＤＢＭＳ（Database Management System））３２は、管理装置（サーバ）３３と、記憶装置３４とを有し、例えば、クライアントサーバシステムのサーバとして機能する。管理装置３３は、コンピュータである。当該管理装置３３はメインメモリ３５を備え、当該メインメモリ３５には、バッファキャッシュ３７として機能する領域が割り当てられている。記憶装置３４は、例えば、ハードディスク装置により構成され、データベース（データ）を格納する。
【００３３】
データベース管理システム３２では、データは、ブロックやページと呼ばれる単位（例えば数キロバイトから数十キロバイト）に分割された状態で、記憶装置３４に記憶される。管理装置３３は、クライアント３６からデータ読み出し要求を受け取ると、そのデータ読み出し要求に該当するデータを記憶装置３４から読み出し、当該読み出したデータを整形した後にクライアント３６に返す。また、管理装置３３は、再度読み出される確率が高いと想定されるデータをバッファキャッシュ３７に格納する。メインメモリ３５（バッファキャッシュ３７）は、記憶装置（ハードディスク装置）３４よりも読み出し速度が速い記憶装置である。このため、データベース管理システム３２は、以前に読み出したデータと同じデータを読み出す要求（データ読み出し要求）があった場合に、記憶装置３４ではなく、メインメモリ３５（バッファキャッシュ３７）からそのデータを読み出す。これにより、データベース管理システム３２は、データの読み出し速度を速めることができる。
【００３４】
この第２実施形態の推定装置２０は、コンピュータにより構成される。当該推定装置２０は、図６に表されるように、処理装置２１と、記憶装置２２とを有する。この第２実施形態では、推定装置２０は、データベース（対象データベース）を集約する前に、集約後のデータベース（集約データベース）の稼働状況として、ヒット率および物理ＩＯ（Input Output）／秒を推定する。ヒット率とは、データ読み出し要求に該当するデータがバッファキャッシュに格納されている確率である。通常、データベースでは、ヒット率が９０％以上となるように構成される。物理ＩＯ／秒（物理ＩＯ数）は、データ（データベース）を格納している記憶装置（ハードディスク装置）の負荷を表す値である。当該物理ＩＯ／秒（物理ＩＯ数）は、データ読み出し要求に応じて単位時間（この第２実施形態では１秒）当たりに記憶装置（ハードディスク装置）から読み出されたデータの数（物理ＩＯ数）を表す（この第２実施形態では、ブロック数により表される）。物理ＩＯ／秒は、物理ＩＯＰＳ(Input Output Per Second)と表記される場合もある。
【００３５】
なお、クライアントから発行されるデータ読み出し要求には、例えば、ＳＱＬ（Structured Query Language）と呼ばれるデータベース用言語が利用される。そのＳＱＬは、ＤＤＬ（Data Definition Language)、ＤＭＬ（Data Manipulation Language)およびＤＣＬ（Data Control Language）によって構成される。ＤＤＬとは、データの構造（テーブル）を定義するデータ定義言語である。ＤＭＬとは、データの追加や検索を操作するデータ操作言語である。ＤＣＬとは、トラザクション等の制御を行うデータ制御言語である。この第２実施形態では、ＤＭＬによるデータの読み出しに着目している。
【００３６】
推定装置２０を構成する記憶装置２２は、例えば、ＲＡＭ（Random Access Memory）やＨＤＤ（Hard Disk Drive）により構成される。この記憶装置２２には、雛形３８のデータと、プログラム３９とが格納されている。プログラム３９は、推定装置２０の動作を制御する処理手順が表されているプログラムである。つまり、記憶装置２２は、プログラム３９を記憶するプログラム記憶媒体として機能する。
【００３７】
雛形３８は、集約データベースの稼働状況を推定する際に利用される複数の情報（この第２実施形態では主に数式）である。雛形３８は、次のような考えに基づいて定められている。
【００３８】
すなわち、バッファキャッシュとして割り当てられている容量Ｘとヒット率ｈ(Ｘ)との一般的な関係は図８の実線Ａに表されるような関係となる。つまり、容量Ｘが少ないうちは容量Ｘが増加するにつれてヒット率ｈ(Ｘ)も上昇するが、ある程度の容量に達すると、その容量Ｘの増加に対するヒット率ｈ(Ｘ)の上昇傾向（傾き）は小さくなる。ここでは、処理を簡略化するために、ヒット率ｈ(Ｘ)に関して保守的な（悲観的な）見積もりを行うことにより、容量Ｘとヒット率ｈ(Ｘ)との関係は、図８の鎖線Ｂに示されるような関係（以下、関係Ｂとも記す）であるとみなす。この関係Ｂは次式（２）により書き表すことができる。
2014041760.tif 000004
【００３９】
ただし、式（２）中のＸは容量を表す。第２実施形態では、Ｍは、バッファキャッシュとして実際に割り当てられている容量を表す。h(Ｍ)は、容量がＭであるときに観測されたヒット率を表す。
【００４０】
また、物理ＩＯ／秒は、単位時間（つまり、１秒）当たりクライアントに返されたデータのうち、記憶装置（ハードディスク装置）から読み出されたデータ（つまり、バッファキャッシュに格納されていなかったデータ）の数（ブロック数）である。このことから、物理ＩＯ／秒をｐとすると、当該物理ＩＯ／秒は、式（３）のように書き表すことができる。
2014041760.tif 000005
【００４１】
ただし、式（３）中のｒは、単位時間（つまり、１秒）当たりクライアントから発行されたデータ読み出し要求の数（以下、論理ＩＯ(Input Output)／秒）とも記す）を表す。なお、論理ＩＯ／秒は論理ＩＯＰＳ（Input Output Per Second）と書き表すこともある。
【００４２】
式（２）および式（３）に基づくと、物理ＩＯ／秒（ｐ(Ｘ)）と容量（Ｘ）の関係は、式（４）に表される。
2014041760.tif 000006
【００４３】
ところで、複数の集約対象のデータベース（例えば、対象データベースＡ，Ｂ）を集約して集約データベース（データベースＣ）を構築するとする。この場合に、その集約データベースＣに関連付けられる集約バッファキャッシュＣにおいて各対象データベースＡ，Ｂのデータに使用される容量の配分比は、各対象データベースＡ，Ｂに関わる物理ＩＯ／秒の比と等しくなる。つまり、多くの場合、バッファキャッシュのデータは、ＬＲＵ（Least Recently Used）や当該ＬＲＵに類似のアルゴリズムを利用して管理される。そのアルゴリズムでは、バッファキャッシュにおいて、読み出し回数の少なかったデータから削除される。物理ＩＯ／秒は、記憶装置から新たなデータが読み込まれ当該データをバッファキャッシュに書き換える速度の指標ともなる。サーバが、複数の対象データベースＡ，Ｂに共有のメモリ領域のデータを競争的に書き換える場合、そのメモリ領域における対象データベースＡ，Ｂの配分比は、データを書き換える速度、つまり、物理ＩＯ／秒の比率と同様になる。
【００４４】
上記のことから、集約バッファキャッシュにおける対象データベースＡ，Ｂの配分比と物理ＩＯ／秒の比率とが等しいとすると、その関係は、次式（５）のように表すことができる。
2014041760.tif 000007
【００４５】
なお、式（５）におけるｘは、集約バッファキャッシュにおいて対象データベースＡのデータに使用される容量を表す。ｙは、集約バッファキャッシュにおいて対象データベースＢのデータに使用される容量を表す。ｐA(ｘ)は、対象データベースＡに関する物理ＩＯ／秒を表す。ｐB(ｙ)は、対象データベースＢに関する物理ＩＯ／秒を表す。
【００４６】
式（５）は式（６）のように変形できる。
2014041760.tif 000008
【００４７】
また、メインメモリから集約バッファキャッシュとして割り当てられる容量をＮとした場合に式（７）が成り立つ。
2014041760.tif 000009
【００４８】
式（４）に基づいて得られるｐA(ｘ)，ｐB(ｙ)を用いて、式（６）と式（７）による連立方程式を解くことにより、集約バッファキャッシュにおいて各対象データベースＡ，Ｂのデータに使用される容量ｘ，ｙを算出できる。そして、その算出された容量ｘ，ｙと、式（２）および式（４）とを利用することにより、集約データベースの稼働状況であるヒット率と物理ＩＯ／秒を算出できる。
【００４９】
上記のようなことから、この第２実施形態では、記憶装置２２は、雛形３８として、式（２），式（４），式（６）および式（７）に基づいた数式を格納している。
【００５０】
処理装置２１は、例えばＣＰＵを含むハードウェア資源により構成されている。当該処理装置２１は、記憶装置２２に格納されているプログラム３９を読み出し、当該プログラム３９を実行することにより、次のような機能部を実現する。すなわち、処理装置２１は、取得部（取得手段）２４と、推定部（推定手段）２５とを有している。
【００５１】
取得部２４は、集約対象のデータベース（例えば、対象データベースＡ，Ｂ）の稼働状況の情報をデータベース管理システムのサーバから取得する機能を有する。その取得する稼働状況の情報は、対象データベースＡ，Ｂに関するヒット率と、単位時間（１秒）当たりのデータ読み出し要求の数（論理ＩＯ／秒）と、バッファキャッシュの容量との情報を含んでいる。
【００５２】
具体例を挙げると、取得部２４は、例えば、対象データベースＡに関し、バッファキャッシュの容量が１．０ＧＢであり、当該バッファキャッシュのヒット率が９６％であり、論理ＩＯ／秒が２０００であるという稼働状況の情報を取得する。また、取得部２４は、例えば、データベースＢに関し、バッファキャッシュの容量が１．０ＧＢであり、当該バッファキャッシュのヒット率が９２％であり、論理ＩＯ／秒が３０００であるという稼働状況の情報を取得する。
【００５３】
推定部２５は、取得部２４が取得した集約対象のデータベースの稼働状況の情報を利用して、集約データベースの稼働状況を推定する機能を備えている。この第２実施形態では、推定部２５は、方程式生成部２７と、求解部２８と、計算部２９とを有している。
【００５４】
方程式生成部２７は、記憶装置２２に格納されている雛形３８と、取得部２４により取得された集約対象のデータベースＡ，Ｂの稼働状況の情報とに基づいて、前述した式（６），式（７）に応じた方程式を生成する機能を備えている。つまり、方程式生成部２７は、式（６）に基づいて、対象データベースＡ，Ｂの稼働状況（物理ＩＯ／秒）と、集約バッファキャッシュにおいて対象データベースＡ，Ｂのデータに使用される容量との関係を表す方程式を生成する。また、方程式生成部２７は、式（７）に基づいて、集約バッファキャッシュにおいて対象データベースＡ，Ｂのデータに使用される容量と、集約バッファキャッシュの容量との関係を表す方程式を生成する。
【００５５】
具体例を以下に述べる。すなわち、ここでは、前述したように、取得部２４が、対象データベースＡに関し、バッファキャッシュの容量ＭAが１．０ＧＢであり、バッファキャッシュのヒット率ｈA（ＭA）が９６％であり、論理ＩＯ／秒ｒAが２０００であるという稼働状況を取得しているとする。また、取得部２４が、対象データベースＢに関し、バッファキャッシュの容量ＭBが１．０ＧＢであり、バッファキャッシュのヒット率ｈB（ＭB）が９２％であり、論理ＩＯ／秒ｒBが３０００であるという稼働状況を取得しているとする。また、対象データベースＡ，Ｂを集約した集約データベースＣに関連付けられる集約バッファキャッシュＣの容量Ｎは２．０ＧＢとする。
【００５６】
上記のような条件の下で、方程式生成部２７は、式（６）と式（７）に基づいて、式（８）のような連立方程式を生成する。
2014041760.tif 000010
【００５７】
また、式（２）と式（４）に基づくと、式（９）〜（１２）が得られる。
2014041760.tif 000011
【００５８】
2014041760.tif 000012
【００５９】
2014041760.tif 000013
【００６０】
2014041760.tif 000014
【００６１】
求解部２８は、方程式生成部２７により生成された連立方程式を解く機能を備えている。具体的には、例えば、求解部２８は、式（９）〜式（１２）を考慮し、連立方程式（８）を解く。なお、連立方程式を解くアルゴリズムとして、例えば、奥村晴彦著「C言語による最新アルゴリズム事典」技術評論社、１９９１年２月、ｐｐ.３５４−３５７に記載されているGauss法やGauss-Jordan法のアルゴリズムを利用することができる。
【００６２】
この第２実施形態では、求解部２８は、連立方程式を解くことにより、ｘ，ｙの値、つまり、集約バッファキャッシュＣにおける対象データベースＡ，Ｂのデータに使用される容量を得ることができる。式（８）〜式（１２）に基づいたｘは０．９３３ＧＢであり、ｙは１．０７ＧＢである。
【００６３】
計算部２９は、求解部２８により算出されたｘ，ｙの値を利用して、さらに、集約データベースの稼働状況を算出する機能を備えている。例えば、計算部２９は、次のようにして、集約データベースの稼働状況である物理ＩＯ／秒、ヒット率、ミス率（データ読み出し要求に該当するデータがバッファキャッシュに格納されていない確率）を算出する。
【００６４】
まず、計算部２９は、算出された容量ｘ，ｙの値を式（９）〜式（１２）に代入し、これらの式を計算する。これにより、集約データベースの稼働状況が推定される。具体的には、計算部２９は、ｘ＝０．９３３、ｙ＝１．０７を式（９）〜式（１２）に代入し、当該（９）〜式（１２）を算出することにより、下記のような結果が得られる。
2014041760.tif 000015
【００６５】
そして、計算部２９は、ｐA+B＝ｐA(ｘ)＋ｐB(ｙ)を計算することにより、集約データベースに関する物理ＩＯ／秒(ｐA+B)を算出する。例えば、計算部２９は、物理ＩＯ／秒(ｐA+B)を、２４０＋２１０の計算により４５０と算出する。
【００６６】
また、計算部２９は、式（１３）に従って、集約データベースに関連付けられている集約バッファキャッシュのミス率（IA+B）を算出する。
2014041760.tif 000016
【００６７】
なお、式（１３）中におけるｒAは集約対象のデータベースＡに関する論理ＩＯ／秒を表す。ｒBは集約対象のデータベースＢに関する論理ＩＯ／秒を表す。
【００６８】
具体的には、計算部２９は、前記計算結果を利用して、ミス率ＩA+B＝４５０÷（２０００＋３０００）＝０．０９（９％）を算出する。
【００６９】
さらに、計算部２９は、算出したミス率を利用して、ヒット率ｈA+B（ｈA+B＝１−ＩA+B＝０．９１（９１％））を算出する。
【００７０】
すなわち、この第２実施形態では、計算部２９は、集約データベースの稼働状況として、ヒット率と、物理ＩＯ／秒（物理ＩＯ数）とを算出する。このように算出された稼働状況は、予め定められた送付先（出力先）に出力される。
【００７１】
この第２実施形態の推定装置２０は、上記のように、集約後のデータベース（集約データベース）に関する物理ＩＯ／秒やヒット率等の稼働状況を推定できる。この推定に際し、推定装置２０は、集約前のデータベースに関する実測値を利用する。このことから、推定装置２０は、第１実施形態と同様に、集約する前に、集約データベースの稼働状況を推定することができるという効果を得ることができる。
【００７２】
（その他の実施形態）
なお、本発明は第１や第２の実施形態に限定されず、様々な実施の形態を採り得る。例えば、第２実施形態では、方程式生成部２７が生成する連立方程式は、集約データベースに関連付けられている集約バッファキャッシュの容量が定まっている条件を基にした連立方程式（式（８）を参照）である。これに対し、例えば、方程式生成部２７は、集約データベースに関する物理ＩＯ／秒（ｐS）が定まっている条件で、式（１４）のような連立方程式を生成してもよい。
2014041760.tif 000017
【００７３】
なお、式（１４）中におけるｐSは、集約データベースに対して要求された物理ＩＯ／秒を表す定数である。
【００７４】
そして、求解部２８は、例えば、前記同様のアルゴリズムを利用して、式（１４）の連立方程式を解く。また、計算部２９は、その算出結果を利用して、前記同様に、集約データベースに関する物理ＩＯ／秒を算出し、さらに、ヒット率を算出する。これにより、たとえばハードディスク装置の処理能力の上限（ｐ<SUB>S</SUB>）が決まっている場合に、集約後のバッファキャッシュとしてどれくらいの容量を確保すればよいかが算出される。
【００７５】
さらに、第２実施形態では、具体例として、２つの対象データベースＡ，Ｂを集約する例を述べている。これに対して、３つ以上の対象データベースを集約して集約データベースを構築する場合にも、第２実施形態を応用することで、集約データベースの稼働状況を推定できる。
【００７６】
例えば、集約バッファキャッシュにおいて集約対象の各対象データベースのデータに使用される容量の比率（配分比）は、それら対象データベースの物理ＩＯ／秒の比率と同様であるから、方程式生成部２７は、式（１５）のような連立方程式を生成する。なお、式（１５）中におけるｘ，ｙ，ｚは、３つの対象データベースＡ，Ｂ，Ｃを集約して集約データベースを構築する場合において、その集約データベースに関連付けられる集約バッファキャッシュにおいて各データベースのデータに使用される容量を表す。また、Ｓは、集約データベースに関連付けられる集約バッファキャッシュの容量を表す。さらに、ｐA(ｘ)，ｐB(ｙ)，ｐC(ｚ)は、３つの集約対象のデータベースに関する物理ＩＯ／秒を表す。
2014041760.tif 000018
【００７７】
求解部２８が連立方程式（１５）を解き、当該解を利用して計算部２９が上記同様に計算することにより、推定部２５は、集約データベースの稼働状況を前記同様に算出できる。
【００７８】
このように、本発明は、３つ以上の対象データベースを集約して集約データベースを構築する場合にも適用することができる。
【００７９】
以上、各実施形態を例にして本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【００８０】
なお、この出願は、２０１２年９月１３日に出願された日本出願特願２０１２−２０１７４８を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【産業上の利用可能性】
【００８１】
本発明は、大量のデータを記憶することとおよび管理することが可能なデータベースシステムに有効な技術である。
【符号の説明】
【００８２】
１，２０  推定装置
２，２４  取得部
３，２５  推定部
２７  方程式生成部
２８  求解部
【図１】
2014041760.tif 000019
【図２】
2014041760.tif 000020
【図３】
2014041760.tif 000021
【図４】
2014041760.tif 000022
【図５】
2014041760.tif 000023
【図６】
2014041760.tif 000024
【図７】
2014041760.tif 000025
【図８】
2014041760.tif 000026
【国際調査報告】
2014041760.tif 000027
2014041760.tif 000028
2014041760.tif 000029
2014041760.tif 000030