管理装置、データベース管理方法、及びプログラム
【課題】データベース管理システムにおいて、データベースが多重化されている場合であっても、不要領域の修復に関わる排他処理の時間を縮小し得る、管理装置、データベース管理方法、及びプログラムを提供する。
【解決手段】管理装置２１は、多重化された複数のデータベースサーバ２２〜２５を備えたデータベース管理システム２を構成する。管理装置２１は、データベースサーバ２２〜２５それぞれにおける不要領域の修復処理を管理する不要領域修復管理部２１２を備えている。不要領域修復管理部２１２は、複数のデータベースサーバ２２〜２５それぞれにおいて不要領域の修復処理が必要となると、一部のデータベースサーバに、先に修復処理を実行させ、その後、残りのデータベースサーバに、修復処理を実行させる。
【解決手段】管理装置２１は、多重化された複数のデータベースサーバ２２〜２５を備えたデータベース管理システム２を構成する。管理装置２１は、データベースサーバ２２〜２５それぞれにおける不要領域の修復処理を管理する不要領域修復管理部２１２を備えている。不要領域修復管理部２１２は、複数のデータベースサーバ２２〜２５それぞれにおいて不要領域の修復処理が必要となると、一部のデータベースサーバに、先に修復処理を実行させ、その後、残りのデータベースサーバに、修復処理を実行させる。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、多重化されたデータベースサーバを備えるデータベース管理システムにおいて管理を行うための、管理装置、データベース管理方法、及びプログラムに関する。
【背景技術】
【０００２】
一般に、マルチユーザ環境におけるデータベース管理システムでは、端末装置（データベースクライアント）からのデータベース操作の実行時において、トランザクションの同時実効性制御を考慮する必要がある。このため、追記型のストレージを備えるデータベース管理システムでは、多版式同時実行制御（Multi-Version Concurrency Control）が採用されている（例えば、特許文献１参照。）。
【０００３】
多版式同時実行制御では、更新前のデータと更新後のデータとの両方が保持されるため、この追記型ストレージを用いた多版式同時実効制御によれば、問い合わせロックの獲得と書き込みロックの獲得との競合が回避される。よって、データベースへのロールバック機能やリカバリ機能の実装が非常に容易となる。
【０００４】
但し、多版式同時実効制御を採用した場合は、更新が発生する度にデータ領域が消費されていくため、データベース管理システムでは、定期的に不要領域を修復する処理が必要である。不要領域を修復する方法は大きく以下の二つに大別される。
【０００５】
一つの方法は、記憶領域に設定されたページ内での不要領域を詰めて、利用可能なデータ領域を作り、データのアドレスと利用可能な領域の大きさとを記憶することによって、データを再利用する方法（以下「部分不要領域修復方法」と呼ぶ。）である。また、別の方法は、ページ間に渡って不要領域を詰め、ページ自体の削減を行う方法（以下「完全不要領域修復方法」と呼ぶ）である。
【０００６】
上記した方法のうち、部分不要領域修復方法では、修復中のデータ操作の排他対象はページのみであり、データベース管理システムの運用に大きな影響が及ぼされることなく、不要領域を修復することが出来る。
【０００７】
しかしながら、ページ数自体の削減は行われないため、ページを保存しているファイルが削減されないというデメリットがある。この結果、修復処理が適切に行われず、データの更新や削除に伴いファイルサイズが過大になってしまった場合に、このことを解消することが出来なくなる。そして、例えば全件検索を行う場合にはファイルＩ/Ｏが増大し、性能の劣化などが発生する可能性がある。
【０００８】
これに対して、完全不要領域修復方法では、ページ自体の削減が行われるため、ファイルサイズも同様に削減され、上記した部分不要領域修復方法における問題は解消可能である。
【０００９】
また、データベース管理システムでは、従来から、検索の性能向上や可用性の向上のため、データベースの多重化が行われている。デーベースが多重化されたデータベース管理システムについて、図９を用いて説明する。図９は、従来からの多重化データベース管理システムの一例を示すブロック図である。
【００１０】
図９に示すように、多重化データベース管理システム４０は、データベースクライアント３０からの問い合わせを受け付ける受付サーバ４１と、多重化されたデータベースサー
バ４２〜４５とを備えている。なお、図９の例では、データベースサーバは４台であるが、一般に、多重化データベース管理システムでは、データベースサーバは２台以上であれば良い。
【００１１】
そして、多重化データベース管理システム４０では、データベースクライアント３０は、全ての問合せを受付サーバ４１に対して行う。受付サーバ４１は、問い合わせの内容に応じて各データベースと連携し、得た結果をデータベースクライアント３０に返却する。
【００１２】
例えば、この時、問い合わせが検索であれば、受付サーバ４１は、データベースサーバ４２〜４５の中から負荷の少ないデータベースサーバを選択し、そのデータベースサーバに対して問い合わせを行う。そして、受付サーバ４１は、問い合わせの結果を受け取ると、結果を、そのままデータベースクライアント３０に返却する。
【００１３】
また、問い合わせが更新や削除であれば、受付サーバ４１は、データベースサーバ２２〜２５の全てのデータベースに対して、更新の問い合わせを発行する。そして、全ての処理が終われば、受付サーバ４１は、データベースクライアント３０に対して、更新結果を返却する。
【００１４】
このように、多重化データベース管理システム４０では、データベースサーバ２２〜２５の全てのデータベースが論理的に同じ情報を保持することとなる。よって、多数のデータベースクライアントが、大量の検索を実施する場合の性能の向上が図られる。更に、データベースサーバに異常が発生した場合は、他のデータベースサーバが補うことにより、データベース管理システム全体の可用性の向上が図られる。
【先行技術文献】
【特許文献】
【００１５】
【特許文献１】特開２００８−１８１２９７号公報
【発明の概要】
【発明が解決しようとする課題】
【００１６】
しかしながら、上述したデータベース管理システムで行われる従来からの不要領域の修復や、データベースサーバの多重化には、次のような問題点が存在する。以下に具体的に説明する。
【００１７】
第一に、従来からの完全不要領域修復方法では、部分不要領域修復方法のような問題は生じないが、不要領域を詰める修復処理の実行時に排他処理が必要であるため、データベース管理システムの運用を停止しなければならいという問題がある。このため、停止時間を取ることができないデータベースでは、完全不要領域修復方法を実施できず、性能の劣化を招くことがある。
【００１８】
第二に、排他処理の問題は、データベースが多重化されていると、より大きな問題となってしまう。具体的には、多重化されたデータベースに対して、完全不要領域修復方法による操作が行われると、全てのデータベースは、不要領域の修復処理が全て終了するまで、問い合わせ結果を返せず、排他処理に必要な時間は、単一のデータベースの場合よりも長時間となってしまう。
【００１９】
つまり、データベースクライアントから更新の問い合わせが来た場合は、同時に全てのデータベースに対して更新処理をかける必要があるため、このときに、いずれかのデータベースに排他がかかっていると更新を行うことができない状態となる。よって、多重化されたデータベースに対して、完全不要領域修復方法による操作が行われる場合は、各デー
タベースは、全てのデータベースに対する不良領域の修復処理が終了するまで、待機状態となってしまう。
【００２０】
本発明の目的は、上記問題を解消し、データベース管理システムにおいて、データベースが多重化されている場合であっても、不要領域の修復に関わる排他処理の時間を縮小し得る、管理装置、データベース管理方法、及びプログラムを提供することにある。
【課題を解決するための手段】
【００２１】
上記目的を達成するため、本発明における管理装置は、多重化された複数のデータベースサーバを備えたデータベース管理システムを構成する管理装置であって、
前記複数のデータベースサーバそれぞれにおける不要領域の修復処理を管理する不要領域修復管理部を備え、
前記不要領域修復管理部は、前記複数のデータベースサーバそれぞれにおいて不要領域の修復処理が必要となると、一部の前記データベースサーバに、先に前記修復処理を実行させ、その後、残りの前記データベースサーバに、前記修復処理を実行させる、
ことを特徴とする。
【００２２】
上記目的を達成するため、本発明におけるデータベース管理方法は、多重化された複数のデータベースサーバを備えたデータベース管理システムにおいてデータベースの管理を行うための方法であって、
（ａ）前記複数のデータベースサーバそれぞれにおいて不要領域の修復処理が必要となった場合に、一部の前記データベースサーバに、先に前記修復処理を実行させるステップと、
（ｂ）前記（ａ）のステップの実行後に、残りの前記データベースサーバに、前記修復処理を実行させるステップと、
を有することを特徴とする。
【００２３】
上記目的を達成するため、本発明におけるプログラムは、多重化された複数のデータベースサーバを備えたデータベース管理システムにおいて、コンピュータに、データベースの管理を行わせるためのプログラムであって、
前記コンピュータに、
（ａ）前記複数のデータベースサーバそれぞれにおいて不要領域の修復処理が必要となった場合に、一部の前記データベースサーバに、先に前記修復処理を実行させるステップと、
（ｂ）前記（ａ）のステップの実行後に、残りの前記データベースサーバに、前記修復処理を実行させるステップと、
を実行させることを特徴とする。
【発明の効果】
【００２４】
以上の特徴により、本発明における、管理装置、データベース管理方法、及びプログラムによれば、データベース管理システムにおいて、データベースが多重化されている場合であっても、不要領域の修復に関わる排他処理の時間を縮小することが可能となる。
【図面の簡単な説明】
【００２５】
【図１】図１は、本発明の実施の形態１における管理装置及びそれを備えるデータベース管理システムの概略構成を示すブロック図である。
【図２】図２は、本発明の実施の形態１における管理装置の動作を示すフロー図である。
【図３】図３は、本発明の実施の形態１の管理装置によって構成されたデータベース管理システムにおけるアクティビティの変化を示すアクティビティ図である。
【図４】図４は、本実施の形態１において行われる不要領域修復処理の概念を説明する説明図である。
【図５】図５は、図３に示したステップＢを具体的に示すアクティビティ図である。
【図６】図６は、図５に示したステップＣを具体的に示すアクティビティ図である。
【図７】図７は、本発明の実施の形態２の管理装置によって構成されたデータベース管理システムにおけるアクティビティの変化を示すアクティビティ図である。
【図８】図８は、図７に示したステップＢ１０に含まれる処理を具体的に示すアクティビティ図である。
【図９】図９は、図９は、従来からの多重化データベース管理システムの一例を示すブロック図である。
【発明を実施するための形態】
【００２６】
（実施の形態１）
以下、本発明の実施の形態１における、管理装置、データベース管理方法、及びプログラムについて、図１〜図６を参照しながら説明する。最初に、管理装置及びそれを備えるデータベース管理システムの構成について図１を用いて説明する。図１は、本発明の実施の形態１における管理装置及びそれを備えるデータベース管理システムの概略構成を示すブロック図である。
【００２７】
図１に示すように、本実施の形態１における管理装置２１は、多重化された複数のデータベースサーバ２２〜２５を備えたデータベース管理システム２を構成している。また、本実施の形態１では、デーベース管理装置２１には、データベース対して処理を要求するデータベースクライアント１が接続されている。更に、データベースサーバ２２〜２５は追記型のデータベースであり、データベース管理システム２では、多版式同時実行制御が採用されている。
【００２８】
なお、図１は、データベースサーバが４台の例を示しているが、本実施の形態１において、データベースサーバの数は限定されるものではなく、２台以上であれば良い。また、図１は、１台のデータクライアント１のみを示しているが、本実施の形態１において、データクライアントの数も限定されるものではない。
【００２９】
また、図１に示すように、管理装置２１は、データベースサーバ２２〜２５それぞれにおける不要領域の修復処理を管理する不要領域修復管理部２１２を備えている。不要領域修復管理部２１は、データベースサーバ２２〜２５それぞれにおいて不要領域の修復処理が必要となると、一部のデータベースサーバに、先に修復処理を実行させ、その後、残りのデータベースサーバに、修復処理を実行させる。
【００３０】
よって、管理装置２１によれば、不要領域の修復処理を、例えば、２つのステップに分割して行うことができるため、データベースが多重化されている場合であっても、不要領域の修復に関わる排他処理の時間を縮小できる。このため、不要領域の修復処理が実行中の場合でも、データベースクライアント１は検索処理や更新処理を要求することができる。
【００３１】
ここで、本実施の形態におけるシステム管理装置２１及びデータベース管理システム２の構成について具体的に説明する。図１に示すように、管理装置２１は、データベースサーバ２２〜２５に対する外部からの操作要求を管理するクエリ管理部２１１を備えている。
【００３２】
クエリ管理部２１１は、データクライアント１に接続され、データクライアント２１１からの要求、例えば、データの更新、検索等を受け付ける。そして、クエリ管理部２１１
は、受け付けた要求の内容を確認した後、要求内容に応じて、データサーバ２２〜２４に対して、問い合わせや、操作の指示を発行し、これらを送信する。データベース管理部２１は、クエリ管理部２１１により、問い合わせ受け付けサーバとして機能している。
【００３３】
また、本実施の形態１において、システム管理装置２１とデータベースクライアント１との接続は、ネットワークによって行われている。更に、同様に、システム管理装置２１と、データベースサーバ２２〜２５それぞれとの接続もネットワークによって行われている。
【００３４】
また、不要領域修復管理部２１２は、本実施の形態では、クエリ管理部２１１から、データベースサーバ２２〜２５への問い合わせの結果や、これらに対して行った操作の実行結果を受け取る。そして、不要領域修復管理部２１２は、不要領域の修復処理が指示された各データベースサーバにおける動作状況を判断し、判断結果に応じて、クエリ管理部２１１に対して指示を行う。
【００３５】
データベースサーバ２２〜２５は、それぞれ、同様の構成を備えており、データベース管理部と記憶装置とを備えている。例えば、データベースサーバ２２は、データベース管理部２２１と、記憶装置２２２とを備えている。データベース管理部２２１は、クエリ管理部２１１が発行した問い合わせや操作の指示を受けると、これらの内容を分析し、分析結果に応じて処理を実行する。また、データベース管理部２２１は、処理の結果をクエリ管理部２１１に返却する。
【００３６】
記憶装置２２２は、格納が指示されたデータ、インデックスデータ、データベースの統計情報、及びトランザクション情報等のデータベースの運用に必要な情報を記録している。なお、他のデータベースサーバ２３、２４及び２５の構成及び動作は、上述したデータベースサーバ２２と同様であり、これらのデータベースサーバについての説明は省略する。
【００３７】
次に、本発明の実施の形態１における管理装置２１の動作を、図２を用いて説明する。図２は、本発明の実施の形態１における管理装置の動作を示すフロー図である。なお、本実施の形態１におけるデータベース管理方法は、本実施の形態１における管理装置２１を動作させることによって実行される。よって、データベース管理方法の説明は、以下の管理装置２１の動作の説明に代える。また、以下の説明においては、適宜図１を参酌する。
【００３８】
図２に示すように、先ず、クエリ管理部２１１は、データベースクライアント１が不要領域の修復処理の要求コマンドを発行すると、これを受け付け、不要領域修復管理部２１２に、不要領域の修復処理の開始を通知する（ステップＳ１）。
【００３９】
次に、不要領域修復管理部２１２は、データベースサーバ２２〜２５のうちの一部、例えば、データベースサーバ２２と２３とを修復対象に割り当て、そのことをクエリ管理部２１１に通知する（ステップＳ２）。そして、クエリ管理部２１１は、データベースサーバ２２のデータベース管理部２２１とデータベースサーバ２３のデータベース管理部２３１とに、不要領域の修復処理の指示を発行する。これにより、データベースサーバ２２及び２３において、不要領域の修復処理が実行される。
【００４０】
次に、クエリ管理部２１１は、データベースクライアント１から、不要領域の修復処理とは別の操作要求、例えば、データの検索を受けた場合は、修復処理の指示を行っていない別のデータベースサーバ２４及び２５に、求められた処理の実行を指示する（ステップＳ３）。
【００４１】
このとき、データベースクライアント１から、データの更新が指示された場合は、データベースサーバ２２及び２３に対しては更新を行えないため、クエリ管理部２１１は、不要領域修復管理部２１２に更新内容をプールさせる。不要領域修復管理部２１２は、データベース２２及び２３において不要領域の修復処理が終了すると、これらに対して、クエリ管理部２１１を介して更新を行わせる。なお、上述した処理の詳細については後述する。
【００４２】
次に、データベースサーバ２２及び２３において、不要領域の修復処理が終了すると、不要領域修復管理部２１２は、修復処理が終了していないデータベースサーバ２４及び２５を修復対象に割り当て、そのことをクエリ管理部２１１に通知する（ステップＳ４）。これにより、修復対象となるデータベースが入れ替えられ、全てのデータベースに対する不要領域の修復処理が終了する。そして、ステップＳ１〜Ｓ４までの間、全てのデータベースにおいて同時に不要領域の修復処理が行われることはないため、上述したように、不要領域の修復に関わる排他処理の時間は縮小される。
【００４３】
ステップＳ４の実行後、クエリ管理部２１１は、通常の運用に戻り、データベースクライアント１から操作要求があった場合は、全てのデータベースに対して、操作要求を実行させる（ステップＳ５）。
【００４４】
次に、管理装置２１の動作を更に具体的に説明するため、データベース管理システム２の全体の動作を、図３及び図４を用いて説明する。図３は、本発明の実施の形態１の管理装置によって構成されたデータベース管理システムにおけるアクティビティの変化を示すアクティビティ図である。図４は、本実施の形態１において行われる不要領域修復処理の概念を説明する説明図である。
【００４５】
先ず、図３に示すように、データベースクライアント１から、データベース管理システム２全体に対して不要領域の修復処理を要求するコマンドが発行されると、クエリ管理部２１１は、不要領域の修復処理の要求コマンドを受け付ける（ステップＡ１）。そして、クエリ管理部２１１は、不要領域修復管理部２１２に、不要領域の修復処理の開始を通知する。なお、本実施の形態において行われる修復処理は、背景技術の欄で述べた「完全不要領域修復方法」である。
【００４６】
次に、不要領域修復管理部２１２は、データベースサーバ２２〜２５の半分を修復対象のデータベースサーバに割り当て、残りのデータベースサーバを通常対応のデータベースサーバに割り当て、結果を、クエリ管理部２１１に通知する（ステップＡ２）。本実施の形態１では、上述したように、例として、最初、データベースサーバ２２と２３とが修復対象のデータベースサーバに割り当てられ、データベースサーバ２４と２５とが通常対応のデータベースサーバに割り当てられるものとして説明する。
【００４７】
また、ステップＡ２では、クエリ管理部２１１は、不要領域の修復処理の指示を、修復対象のデータベースサーバ２２のデータベース管理部２２１と、データベースサーバ２３のデータベース管理部２３１とに対して、発行する。
【００４８】
また、複数の仮想ＯＳを保有可能な１つのコンピュータ上で仮想化された複数のデータベースサーバが動作し、且つ、各仮想マシンのＣＰＵやメモリ等のリソースを動的に別の仮想マシンに移行できる技術が知られている。この技術を本実施の形態１に適用すれば、修復対象の仮想データベースサーバのＣＰＵやメモリのリソースの一部を、通常対応の仮想データベースサーバに移行することができ、運用中のデータベースシステム全体としての性能低下を抑制することができる。
【００４９】
次に、修復処理の指示を受けたデータベース管理部２２１（又は２３１）は、修復対象のデータベースそれぞれのデータを格納している全てのページに対して完全修復操作を実行する（ステップＡ３）。ここで、ステップＡ３における修復操作を、図４に基づいて説明する。
【００５０】
図４に示すように、空き領域を有する連続したページ３及びページ４が存在しているとする。ページ３及び４に対しては、修復処理が未だ行われておらず、これらは解放前の状態にある。ページ３には、ページ管理情報３１と、タプルデータ３２１〜３２５とが存在している。また、タプルデータ３２１〜３２５のうち、有効タプルデータは３２１と３２４とであり、削除可能タプルデータは３２２、３２３、及び３２５である。
【００５１】
同様に、ページ４には、ページ管理情報３１と、タプルデータ４２１〜４２５とが存在している。また、タプルデータ４２１〜４２５のうち、有効タプルデータは４２２、４２３、及び４２４であり、削除可能タプルデータは４２１と４２５とである。
【００５２】
そして、解放前のページ３とページ４とに対して修復処理（完全修復操作）を行い、得られたページが、空き領域解放後のページ５となる。具体的には、データベース管理部は、有効タプルデータ３２１及び３２４を、順に、後方に向けて詰めていく操作を実行する。図４の例では、タプルデータ３２１が最も後方にあるので、タプルデータ３２４をその後方に向けて移動させ、その位置をページ５のタプルデータ５２２の位置とする。
【００５３】
更に、管理情報３１において、削除タプルデータ３３２、３３３、及び３３５のタプル情報は無効化され、管理情報３１は、ページ管理情報５１に書き換えられる。その後、ページ４の有効タプルデータであるタプルデータ４２２、４２３、及び４２４が、ページ５に書き込まれ、不要となったページ４が削除される。
【００５４】
つまり、図４の例では、タプルデータ３２１がタプルデータ５２１と等しくなり、タプルデータ３２４がタプルデータ５２２と等しくなる。また、タプルデータ４２２がタプルデータ５２３と等しくなり、タプルデータ４２３がタプルデータ５２４と等しくなり、更にタプルデータ４２４がタプルデータ５２５と等しくなる。この結果、有効なタプルのみがページ５に残る。そして、ページ４が削減されて、記憶装置の記憶領域にデータ領域を確保することができる。本実施の形態では、修復処理は、このような手順によって行なわれる。
【００５５】
また、上述のステップＡ３と平行して、又はステップＡ３の実行後に、クエリ管理部２１１が、データベースクライアント１から、検索や更新等の操作要求を受け取った場合は、ステップＢが実行される。ステップＢでは、クエリ管理部２１１は、通常対応のデータベースサーバのデータベース管理部２４１（又は２５１）に対して操作を発行する。なお、データベースクライアント１からの操作要求が、更新処理である場合は、不要領域修復管理部２１２は、更新命令をプールする。ステップＢの詳細は、図５を用いて後述する。
【００５６】
次に、修復対象データベースサーバにおいて修復処理が完了すると、その情報が、クエリ管理部２１１へ返却される。更に、ステップＡ２で対象となったデータベースサーバの修復処理が全て完了すると、クエリ管理部２１１は、不要領域修復管理部２１２に対して、対象となっていたデータベースサーバにおいて修復処理が完了したことを通知する（図３のステップＡ４）。
【００５７】
次に、不要領域修復管理部２１２は、修復処理の完了の通知を受けると、ステップＢにおいてプールしていた更新処理をクエリ管理部２１１に対して発行する（ステップＡ５）。そして、クエリ管理部２１１は、不要領域の修復処理が完了したデータベースのデータ
ベース管理部２２１及び２３１に対して、更新命令を発行する。
【００５８】
次に、データベース管理部２２１及び２３１は、クエリ管理部２１１が発行した更新命令に従い、対応する記憶部が構成するデータベースの更新を実行する（ステップＡ６）。そして、このステップＡ５〜ステップＡ６までの処理は、プールされていた更新命令の分だけ繰り返し行われる。これにより、ステップＢによって発生した、修復対象のデータベースサーバ２２及び２３と通常対応のデータベースサーバ２４及び２５との差分が、埋められて行くこととなる。
【００５９】
なお、ステップＡ５〜ステップＡ６の間に、更に新しい問合せがデータベースクライアント１からクエリ管理部２１１に発行された場合は、クエリ管理部２１１は、後述するステップＢと同様の操作を実行する。
【００６０】
そして、ステップＡ５〜ステップＡ６までの処理の繰り返しにより、全ての差分の反映が終了すると、不要領域修復管理部２１２は、修復対象のデータベースサーバと通常対応のデータベースサーバとの役割を入れ替えるため、割り当てを変更し、未だ不要領域の修復処理が行われていない未修復のデータベースサーバに対して、不要領域の修復処理を実行する（ステップＡ７）。
【００６１】
ステップＡ７の実行後、全てのデータベースサーバに対する不要領域の修復処理は終了する。なお、ステップＡ１〜Ａ７の動作では、修復処理中において、更新処理による不要領域が発生する可能性があるが、データベース全体としては、殆どの不要領域が修復され、大幅なページの削減が可能となる。
【００６２】
ここで、図３に示されたステップＢについて図５に基づいて具体的に説明する。図５は、図３に示したステップＢを具体的に示すアクティビティ図である。なお、図５の例においても、図３の例と同様に、修復対象のデータベースサーバとしてデーベースサーバ２２及び２３が割り当てられ、通常対応のデータベースサーバとしてデータベースサーバ２４及び２５が割り当てられているとする。
【００６３】
また、図５に示すステップＢによるデータベース操作受付処理は、不要領域の修復処理が完了し、修復対象のデータベースサーバと通常対応のデータベースサーバとの差分が解消され同期が完了（図３のステップＡ５〜Ａ６の繰り返しが終了）した時点で終了となる。
【００６４】
先ず、図５に示すように、クエリ管理部２１１は、上記の差分が解消するまでの間、データベースクライアント１からのデータベース操作を受け付ける（ステップＢ１）。次に、データベースクライアント１から操作要求が発行されると、クエリ管理部２１１は、操作内容の検証を行う（ステップＢ２）。
【００６５】
次に、ステップＢ２の検証の結果、操作の種類が検索処理であった場合は、クエリ管理部２１１は、通常対応のデータベースサーバの中で負荷の低いデータベースサーバ（ここでは２４だとする）のデータベース管理部に対して、検索命令を発行する（ステップＢ３）。
【００６６】
次に、検索命令を受けたデータベースサーバのデータベース管理部（ここでは、データベース管理部２４１）は、検索処理を実行する（ステップＢ４）。そして、データベース管理部は、検索処理の結果を、クエリ管理部２１１へ送信する（ステップＢ５）。その後、クエリ管理部２１１は、受け取った検索結果を、そのままデータベースクライアント１に送信する（ステップＢ６）。
【００６７】
また、ステップＢ２の検証の結果、操作の種類が更新処理であった場合は、クエリ管理部２１１は、通常対応のデータベースサーバ２４及び２５と不要領域修復管理部２１２とに更新命令を発行する（ステップＢ７）。この時、不要領域修復管理部２１２は、更新命令を受け付けた順に保持する。
【００６８】
また、更新命令を受け取ったデータベース管理部２４１及び２４２は、それぞれ更新処理を解釈し、それぞれの対応する記憶装置２４２（又は２４３）に記録されているデータベースを更新する（ステップＢ８）。
【００６９】
次に、更新処理が終了すると、データベース管理部２４１及び２４２は、それぞれクエリ管理部２１１に結果を送信する（ステップＢ９）。また、クエリ管理部２１１は全ての正常結果を受信したことを確認すると（ステップＢ１１）、上述の検索処理の場合と同様に、データベースクライアント１に結果を返却する（ステップＢ６）。更に、クエリ管理部２１１は、更新件数を、不要領域修復管理部２１２に通知する。
【００７０】
ここで、図５中に示されたステップＣ（例外処理）について説明する。上述したステップＢ１では、複数のデータベースクライアント１からデータベース操作が入力され、大量の操作処理を受け付けなければならない場合が想定される。一方、不要領域の修復処理中はデータベースとして運用されているサーバの台数は通常よりも少なくなっている。このため、データベースの検索処理性能も同様に通常よりも低下してしいる。
【００７１】
よって、ある程度までのデータベース操作であれば、既に述べたデータベースの検索処理や更新処理によって、データベースの性能低下を抑制することによって対応可能であるが、大量の検索処理等が要求された場合は、データベースとしてのレスポンス低下が懸念される。また、本実施の形態１を実施する際において、データベースに高い負荷がかかる状況は避けるべきではあるが、運用上確実に回避できない場合も想定される。
【００７２】
そこで、本実施の形態１においては、データベースクライアントからの操作要求に対して一定の閾値を設け、それ以上（又はそれを超える）のデータベース操作要求が来た場合は、不要領域の修復処理を中断することとしている。そして、この場合は、中断するまでに発生したデータベースへの更新差分の同期処理が即座に適用され、その後、通常運用に戻ることで、処理能力が低下した状態は回避される。
【００７３】
但し、このような処理を採用する場合は、更新差分の同期処理自体が大量にある事態も想定され、更に状況を悪化させる可能性がある。よって、このような事態の発生を回避するため、更新差分の発生量にも閾値を設け、それを上回る場合にも、同様に、不要領域の修復処理が中断されるようにするのが好ましい。
【００７４】
また、修復処理を中断させるデータベースサーバの台数は、複数の閾値を設定し、閾値毎に変化させても良い。つまり、更新差分の発生量に応じて、１台ずつ順に処理を中断させても良いし、全てのデータベースサーバに対して一度に中断させても良い。なお、不要領域の修復処理では、データの移動が行われているにすぎず、修復処理自体が途中で中断されても、データベースサーバは、直ぐにデータベースとしての利用が可能な状態である。
【００７５】
次に、図６を用いて、図５に示したステップＣ（例外処理）の内容を具体的に説明する。図６は、図５に示したステップＣを具体的に示すアクティビティ図である。図６に示すステップは、上記の説明の通り、データベースクライアント１からの操作要求（接続要求）の要求量又は要求件数（例えば、データベース更新の件数）が、それぞれに設定されて
いる閾値を超えた場合に開始される。
【００７６】
最初に、図６に示すように、クエリ管理部２１１は、閾値に対応させた修復対象のデータベースサーバのデータベース管理部に対して、不良領域の修復処理の中断を指示する命令（修復中断命令）を発行し、これを送信する（ステップＣ１）。
【００７７】
次に、修復中断命令を受けたデータベース管理部は、修復処理を即時終了させて（ステップＣ２）、停止完了をクエリ管理部２１１に報告する（ステップＣ３）。次に、クエリ管理部２１１は、終了報告を確認後、ステップＢ７と同様に、不要領域修復管理部２１２によってプールされていた更新命令を、再度、対象のデータベース管理部に対して発行する。（ステップＣ４）。
【００７８】
次に、更新命令を受けたデータベース管理部は、更新操作を実行し（ステップＣ５）、結果を、クエリ管理部２１１に送信する（ステップＣ６）。クリエ管理部２１１は、結果を受信する（ステップＣ７）。ステップＣ５〜Ｃ７が繰り返され、全ての更新命令が完了すると、不要領域修復管理部２１２は、ステップＡ７と同様に、対象のデータベースサーバの割り当てを修復対象のデータベースサーバから通常対応のデータベースサーバへと変更する（ステップＣ８）。これにより、通常対応のデータベースサーバが増加する。
【００７９】
また、本実施の形態１におけるプログラムは、コンピュータに、図２に示すステップＳ１〜Ｓ４、具体的には、ステップＡ１、Ａ２、Ａ５、Ａ７、Ｂ１、Ｂ２、Ｂ３、Ｂ６、Ｂ７、Ｂ１１、Ｃ１、Ｃ４、Ｃ７、Ｃ８を実行させるプログラムであれば良い。このプログラムをコンピュータにインストールし、実行することにより、本実施の形態１における管理装置及びデータベース管理方法を実現することができる。また、この場合、コンピュータのＣＰＵ（central processing unit）は、クエリ管理部２１１、不要領域修復管理部２１２として機能し、処理を行なう。
【００８０】
以上のように、本実施の形態１によれば、データベースが多重化されたデータベース管理システムにおいては、修復対象のデータベースと通常運用のデータベースとに分けて処理が行われる。よって、上述したように、不要領域の修復に関わる排他処理の時間は縮小される。そして、データベースにおいて不要領域の修復処理を実行しながら、データベースクライアントからの検索や更新といった通常の操作要求を受け、これらの処理を実行することができる。
【００８１】
また、修復対象のデータベースと通常運用のデータベースとの間に生じる差分は、不要領域修復管理部２１２によって管理され、不要領域の修復が完了すると適用される。更に、差分を適用する際において、通常運用のデータベースが停止されることはない。このため、本実施の形態１では、データベースクライアントからの更新処理を止めること無く、差分の適用を行うことができる。
【００８２】
更に、本実施の形態１では、図５及び図６においてステップＣで示したように、データベースクライアント１からの操作要求に応じて、データベースの性能が低下しないよう、自動的に不要領域の修復処理が中断される。このため、本実施の形態１は、データベースクライアント１の台数の増加や操作要求の増加にも対応することができる。
【００８３】
また、複数の仮想ＯＳ上でデータベースシステムを構築している場合では、ＣＰＵやメモリのリソースを動的に移行して通常対応データベースサーバの性能を向上させることにより、データベースサーバが少なくなることによる検索性能低下を補うことが可能となる。これは不要領域処理が記憶装置への負荷が高く、比較的ＣＰＵやメモリのリソースは必要としないことを利用したものである。この技術を本実施の形態１に適用すれば、上述し
たように、運用中のデータベースシステム全体の性能低下を抑制することができる。
【００８４】
（実施の形態２）
次に本発明の実施の形態２における、管理装置、データベース管理方法、及びプログラムについて説明する。但し、本実施の形態２における管理装置及びそれを備えるデータベース管理システムの構成は、実施の形態１において図１に示した管理装置及びデータベース管理システムの構成と同様である。
【００８５】
本実施の形態２は、管理装置及びデータベースサーバにおける一部の処理が、実施の形態１におけるこれらの処理と異なっている。つまり、実施の形態１では、不要領域の修復処理の終了後に、データベースクライアントからの操作は受け付けたまま、修復対象のデータベースに対して更新命令が発行され、更新差分の適用が行われている。但し、この方式では、通常対応のデータベースの更新完了日時と修復対象のデータベースの更新日時とに幾らかの差異が生じることがあり、データベースによっては、差異の解消が求められる場合がある。このため、本実施の形態２においては、実施の形態１と異なる処理が行われる。
【００８６】
本実施の形態２における処理について、図７及び図８を用いて以下に説明する。図７は、本発明の実施の形態２の管理装置によって構成されたデータベース管理システムにおけるアクティビティの変化を示すアクティビティ図である。図８は、図７に示したステップＢ１０に含まれる処理を具体的に示すアクティビティ図である。
【００８７】
図７に示されたステップのうち、実施の形態１で用いた図３に示された符号が付されたステップは、当該符号が付された図３のステップと同一ステップである。つまり、図７において、ステップＡ１〜Ａ４及びＡ７は、実施の形態１におけるステップＡ１〜Ａ４及びＡ７と同様に、クエリ管理部２１１、不要領域修復管理部２１２、データベース管理部２２１、２３１、２４１、２５１によって実行される。
【００８８】
一方、図７に示されたステップＢ１０は、図３に示されたステップＢとは、例外処理（図５及び図６に示すステップＣ）の点で異なっている。本実施の形態２においては、後述するように、例外処理は、図８に沿って実行される。図８に示す処理については後述する。また、ステップＤ１〜Ｄ４は、本実施の形態２に特有のステップである。以下に、ステップＤ１〜Ｄ４について説明する。
【００８９】
なお、以下の説明では、実施の形態１で用いた図１を適宜参酌する。また、本実施の形態２においても、実施の形態１と同様に、最初に、データベースサーバ２２及び２３が修復対象のデータベースサーバに割り当てられ、データベースサーバ２４及び２５が通常対応のデータベースサーバに割り当てられているとする。
【００９０】
図７に示すように、不要領域の修復処理が行われている間、クエリ管理部２１１は、データベースクライアント１からの検索や更新といった操作の受付を保留にし、不要領域修復管理部２１２に、これらをプールさせる（ステップＤ１）。
【００９１】
次に、クエリ管理部２１１は、通常対応のデータベースのデータベース管理部２４１及び２５１に対して、ジャーナルの転送命令を発行する。データベース管理部２４１及び２５１は、転送命令を受信すると、修復対象のデータベースのデータベース管理部２２１及び２３１にデータベースの更新情報であるジャーナルを転送する（ステップＤ２）。なお、通常対応のデータベースの台数より修復対象のデータベースの台数が多い場合は、ジャーナルの転送が早く終わったデータベースが、更に残りの修復対象のデータベースへジャーナルを転送する。
【００９２】
次に、クエリ管理部２１１は、ジャーナルの転送が完了した修復対象のデータベースサーバのデータベース管理部に対して、ジャーナルによる差分の適用を指示し、実行させる（ステップＤ３）。
【００９３】
ステップＤ３により、全ての差分更新（差分の適用）が完了すると、全てのデータベースの同期が取れた状態となる。そこで、クエリ管理部２１１は、保留していたデータベース操作を各データベースサーバに指示するため、これらを受け付けた順番で、その内容に従い、各データベースサーバに対して操作要求を発行する（ステップＤ４）。
【００９４】
その後、実施の形態１と同様に、不要領域修復管理部２１２は、修復対象のデータベースサーバと通常対応のデータベースサーバとの役割を入れ替え、未だ不要領域の修復処理が行われていないデータベースサーバに対して、不要領域の修復処理を実行する（ステップＡ７）。
【００９５】
次に、図８を用いて、ステップＢ１０に含まれる例外処理について説明する。図８に示されたステップのうち、実施の形態１で用いた図６に示された符号が付されたステップは、当該符号が付された図６のステップと同一ステップである。つまり、図８において、ステップＣ１〜Ｃ３及びＣ８は、実施の形態１におけるステップＣ１〜Ｃ３及びＣ８と同様に、クエリ管理部２１１、不要領域修復管理部２１２、データベース管理部２２１、２３１、２４１、２５１によって実行される。
【００９６】
一方、ステップＥ１〜Ｅ４は、本実施の形態２に特有のステップである。以下に、ステップＥ１〜Ｅ４について説明する。また、以下の説明においても、適宜図１を参酌する。
【００９７】
先ず、図８に示すように、修復処理の中断が完了すると、図７に示したステップＤ１と同様、クエリ管理部２１１は、データベースクライアント１からの検索や更新といった操作の受付を保留にし、不要領域修復管理部２１２に、これらをプールさせる。（ステップＥ１）。
【００９８】
次に、クエリ管理部２１１は、通常対応のデータベースのデータベース管理部２４１及び２５１に対して、ジャーナルの転送命令を発行する。データベース管理部２４１及び２５１は、ステップＤ２と同様、転送命令を受信すると、修復処理を停止している修復対象のデータベースのデータベース管理部２２１及び２３１にデータベースの更新情報であるジャーナルを転送する（ステップＥ２）。
【００９９】
次に、クエリ管理部２１１は、ステップＤ３と同様に、ジャーナルの転送が完了した修復対象のデータベースサーバのデータベース管理部に対して、ジャーナルによる差分の適用を指示し、実行させる（ステップＥ３）。
【０１００】
次に、全ての差分更新が完了すると、クエリ管理部２１１は、ステップＤ４と同様に、保留していたデータベース操作を各データベースサーバに指示するため、これらを受け付けた順番で、その内容に従い、各データベースサーバに対して操作要求を発行する（ステップＥ４）。
【０１０１】
その後、不要領域修復管理部２１２は、図６の例と同様に、対象のデータベースサーバの割り当てを、修復対象のデータベースサーバから通常対応のデータベースサーバへと変更する（ステップＣ８）。これにより、通常対応のデータベースサーバが増加する。
【０１０２】
このように、本実施の形態２では、実施の形態１と異なり、通常対応のデータベースサ
ーバから、その更新内容を含むジャーナルが、修復対象のデータベースサーバに対して送信され、ジャーナルを用いて更新が行われる。
【０１０３】
よって、本実施の形態２によれば、通常対応のデータベースの更新完了日時と修復対象のデータベースの更新日時とに差異が生じるのを抑制できる。このため、データベースクライアントからの更新処理の要求に、更新日時に関係する内容が含まれていても、修復対象のデータベースと通常対応のデータベースの同期を取ることが可能となる。本実施の形態２は、更新時に全てのデータベースサーバが更新結果をクエリ管理部２１１に送信することを利用している。データベース間の更新日時は完全とは言わないまでもほぼ同時刻となる。また、本実施の形態２においても、実施の形態１で述べた効果は全て得ることができる。
【産業上の利用可能性】
【０１０４】
以上のように、本発明は、データベース管理システム、特には、データベースサーバが多重化された、追記型データベース管理システムに有効である。本発明は、産業上の利用可能性を有している。
【符号の説明】
【０１０５】
１ データベースクライアント
２ データベース管理システム
３ ページ（解放前）
４ ページ（解放前）
５ ページ（解放後）
２１ 管理装置
２２ データベースサーバ
２３ データベースサーバ
２４ データベースサーバ
２５ データベースサーバ
３１ ページ管理情報
４１ ページ管理情報
５１ ページ管理情報
２１１ クエリ管理部
２１２ 不要領域修復管理部
２２１ データベース管理部
２２２ 記憶装置
２３１ データベース管理部
２３２ 記憶装置
２４１ データベース管理部
２４２ 記憶装置
２５１ データベース管理部
２５２ 記憶装置
３２１〜３２５ タプルデータ
４２１〜４２５ タプルデータ
５２１〜５２５ タプルデータ
【技術分野】
【０００１】
本発明は、多重化されたデータベースサーバを備えるデータベース管理システムにおいて管理を行うための、管理装置、データベース管理方法、及びプログラムに関する。
【背景技術】
【０００２】
一般に、マルチユーザ環境におけるデータベース管理システムでは、端末装置（データベースクライアント）からのデータベース操作の実行時において、トランザクションの同時実効性制御を考慮する必要がある。このため、追記型のストレージを備えるデータベース管理システムでは、多版式同時実行制御（Multi-Version Concurrency Control）が採用されている（例えば、特許文献１参照。）。
【０００３】
多版式同時実行制御では、更新前のデータと更新後のデータとの両方が保持されるため、この追記型ストレージを用いた多版式同時実効制御によれば、問い合わせロックの獲得と書き込みロックの獲得との競合が回避される。よって、データベースへのロールバック機能やリカバリ機能の実装が非常に容易となる。
【０００４】
但し、多版式同時実効制御を採用した場合は、更新が発生する度にデータ領域が消費されていくため、データベース管理システムでは、定期的に不要領域を修復する処理が必要である。不要領域を修復する方法は大きく以下の二つに大別される。
【０００５】
一つの方法は、記憶領域に設定されたページ内での不要領域を詰めて、利用可能なデータ領域を作り、データのアドレスと利用可能な領域の大きさとを記憶することによって、データを再利用する方法（以下「部分不要領域修復方法」と呼ぶ。）である。また、別の方法は、ページ間に渡って不要領域を詰め、ページ自体の削減を行う方法（以下「完全不要領域修復方法」と呼ぶ）である。
【０００６】
上記した方法のうち、部分不要領域修復方法では、修復中のデータ操作の排他対象はページのみであり、データベース管理システムの運用に大きな影響が及ぼされることなく、不要領域を修復することが出来る。
【０００７】
しかしながら、ページ数自体の削減は行われないため、ページを保存しているファイルが削減されないというデメリットがある。この結果、修復処理が適切に行われず、データの更新や削除に伴いファイルサイズが過大になってしまった場合に、このことを解消することが出来なくなる。そして、例えば全件検索を行う場合にはファイルＩ/Ｏが増大し、性能の劣化などが発生する可能性がある。
【０００８】
これに対して、完全不要領域修復方法では、ページ自体の削減が行われるため、ファイルサイズも同様に削減され、上記した部分不要領域修復方法における問題は解消可能である。
【０００９】
また、データベース管理システムでは、従来から、検索の性能向上や可用性の向上のため、データベースの多重化が行われている。デーベースが多重化されたデータベース管理システムについて、図９を用いて説明する。図９は、従来からの多重化データベース管理システムの一例を示すブロック図である。
【００１０】
図９に示すように、多重化データベース管理システム４０は、データベースクライアント３０からの問い合わせを受け付ける受付サーバ４１と、多重化されたデータベースサー
バ４２〜４５とを備えている。なお、図９の例では、データベースサーバは４台であるが、一般に、多重化データベース管理システムでは、データベースサーバは２台以上であれば良い。
【００１１】
そして、多重化データベース管理システム４０では、データベースクライアント３０は、全ての問合せを受付サーバ４１に対して行う。受付サーバ４１は、問い合わせの内容に応じて各データベースと連携し、得た結果をデータベースクライアント３０に返却する。
【００１２】
例えば、この時、問い合わせが検索であれば、受付サーバ４１は、データベースサーバ４２〜４５の中から負荷の少ないデータベースサーバを選択し、そのデータベースサーバに対して問い合わせを行う。そして、受付サーバ４１は、問い合わせの結果を受け取ると、結果を、そのままデータベースクライアント３０に返却する。
【００１３】
また、問い合わせが更新や削除であれば、受付サーバ４１は、データベースサーバ２２〜２５の全てのデータベースに対して、更新の問い合わせを発行する。そして、全ての処理が終われば、受付サーバ４１は、データベースクライアント３０に対して、更新結果を返却する。
【００１４】
このように、多重化データベース管理システム４０では、データベースサーバ２２〜２５の全てのデータベースが論理的に同じ情報を保持することとなる。よって、多数のデータベースクライアントが、大量の検索を実施する場合の性能の向上が図られる。更に、データベースサーバに異常が発生した場合は、他のデータベースサーバが補うことにより、データベース管理システム全体の可用性の向上が図られる。
【先行技術文献】
【特許文献】
【００１５】
【特許文献１】特開２００８−１８１２９７号公報
【発明の概要】
【発明が解決しようとする課題】
【００１６】
しかしながら、上述したデータベース管理システムで行われる従来からの不要領域の修復や、データベースサーバの多重化には、次のような問題点が存在する。以下に具体的に説明する。
【００１７】
第一に、従来からの完全不要領域修復方法では、部分不要領域修復方法のような問題は生じないが、不要領域を詰める修復処理の実行時に排他処理が必要であるため、データベース管理システムの運用を停止しなければならいという問題がある。このため、停止時間を取ることができないデータベースでは、完全不要領域修復方法を実施できず、性能の劣化を招くことがある。
【００１８】
第二に、排他処理の問題は、データベースが多重化されていると、より大きな問題となってしまう。具体的には、多重化されたデータベースに対して、完全不要領域修復方法による操作が行われると、全てのデータベースは、不要領域の修復処理が全て終了するまで、問い合わせ結果を返せず、排他処理に必要な時間は、単一のデータベースの場合よりも長時間となってしまう。
【００１９】
つまり、データベースクライアントから更新の問い合わせが来た場合は、同時に全てのデータベースに対して更新処理をかける必要があるため、このときに、いずれかのデータベースに排他がかかっていると更新を行うことができない状態となる。よって、多重化されたデータベースに対して、完全不要領域修復方法による操作が行われる場合は、各デー
タベースは、全てのデータベースに対する不良領域の修復処理が終了するまで、待機状態となってしまう。
【００２０】
本発明の目的は、上記問題を解消し、データベース管理システムにおいて、データベースが多重化されている場合であっても、不要領域の修復に関わる排他処理の時間を縮小し得る、管理装置、データベース管理方法、及びプログラムを提供することにある。
【課題を解決するための手段】
【００２１】
上記目的を達成するため、本発明における管理装置は、多重化された複数のデータベースサーバを備えたデータベース管理システムを構成する管理装置であって、
前記複数のデータベースサーバそれぞれにおける不要領域の修復処理を管理する不要領域修復管理部を備え、
前記不要領域修復管理部は、前記複数のデータベースサーバそれぞれにおいて不要領域の修復処理が必要となると、一部の前記データベースサーバに、先に前記修復処理を実行させ、その後、残りの前記データベースサーバに、前記修復処理を実行させる、
ことを特徴とする。
【００２２】
上記目的を達成するため、本発明におけるデータベース管理方法は、多重化された複数のデータベースサーバを備えたデータベース管理システムにおいてデータベースの管理を行うための方法であって、
（ａ）前記複数のデータベースサーバそれぞれにおいて不要領域の修復処理が必要となった場合に、一部の前記データベースサーバに、先に前記修復処理を実行させるステップと、
（ｂ）前記（ａ）のステップの実行後に、残りの前記データベースサーバに、前記修復処理を実行させるステップと、
を有することを特徴とする。
【００２３】
上記目的を達成するため、本発明におけるプログラムは、多重化された複数のデータベースサーバを備えたデータベース管理システムにおいて、コンピュータに、データベースの管理を行わせるためのプログラムであって、
前記コンピュータに、
（ａ）前記複数のデータベースサーバそれぞれにおいて不要領域の修復処理が必要となった場合に、一部の前記データベースサーバに、先に前記修復処理を実行させるステップと、
（ｂ）前記（ａ）のステップの実行後に、残りの前記データベースサーバに、前記修復処理を実行させるステップと、
を実行させることを特徴とする。
【発明の効果】
【００２４】
以上の特徴により、本発明における、管理装置、データベース管理方法、及びプログラムによれば、データベース管理システムにおいて、データベースが多重化されている場合であっても、不要領域の修復に関わる排他処理の時間を縮小することが可能となる。
【図面の簡単な説明】
【００２５】
【図１】図１は、本発明の実施の形態１における管理装置及びそれを備えるデータベース管理システムの概略構成を示すブロック図である。
【図２】図２は、本発明の実施の形態１における管理装置の動作を示すフロー図である。
【図３】図３は、本発明の実施の形態１の管理装置によって構成されたデータベース管理システムにおけるアクティビティの変化を示すアクティビティ図である。
【図４】図４は、本実施の形態１において行われる不要領域修復処理の概念を説明する説明図である。
【図５】図５は、図３に示したステップＢを具体的に示すアクティビティ図である。
【図６】図６は、図５に示したステップＣを具体的に示すアクティビティ図である。
【図７】図７は、本発明の実施の形態２の管理装置によって構成されたデータベース管理システムにおけるアクティビティの変化を示すアクティビティ図である。
【図８】図８は、図７に示したステップＢ１０に含まれる処理を具体的に示すアクティビティ図である。
【図９】図９は、図９は、従来からの多重化データベース管理システムの一例を示すブロック図である。
【発明を実施するための形態】
【００２６】
（実施の形態１）
以下、本発明の実施の形態１における、管理装置、データベース管理方法、及びプログラムについて、図１〜図６を参照しながら説明する。最初に、管理装置及びそれを備えるデータベース管理システムの構成について図１を用いて説明する。図１は、本発明の実施の形態１における管理装置及びそれを備えるデータベース管理システムの概略構成を示すブロック図である。
【００２７】
図１に示すように、本実施の形態１における管理装置２１は、多重化された複数のデータベースサーバ２２〜２５を備えたデータベース管理システム２を構成している。また、本実施の形態１では、デーベース管理装置２１には、データベース対して処理を要求するデータベースクライアント１が接続されている。更に、データベースサーバ２２〜２５は追記型のデータベースであり、データベース管理システム２では、多版式同時実行制御が採用されている。
【００２８】
なお、図１は、データベースサーバが４台の例を示しているが、本実施の形態１において、データベースサーバの数は限定されるものではなく、２台以上であれば良い。また、図１は、１台のデータクライアント１のみを示しているが、本実施の形態１において、データクライアントの数も限定されるものではない。
【００２９】
また、図１に示すように、管理装置２１は、データベースサーバ２２〜２５それぞれにおける不要領域の修復処理を管理する不要領域修復管理部２１２を備えている。不要領域修復管理部２１は、データベースサーバ２２〜２５それぞれにおいて不要領域の修復処理が必要となると、一部のデータベースサーバに、先に修復処理を実行させ、その後、残りのデータベースサーバに、修復処理を実行させる。
【００３０】
よって、管理装置２１によれば、不要領域の修復処理を、例えば、２つのステップに分割して行うことができるため、データベースが多重化されている場合であっても、不要領域の修復に関わる排他処理の時間を縮小できる。このため、不要領域の修復処理が実行中の場合でも、データベースクライアント１は検索処理や更新処理を要求することができる。
【００３１】
ここで、本実施の形態におけるシステム管理装置２１及びデータベース管理システム２の構成について具体的に説明する。図１に示すように、管理装置２１は、データベースサーバ２２〜２５に対する外部からの操作要求を管理するクエリ管理部２１１を備えている。
【００３２】
クエリ管理部２１１は、データクライアント１に接続され、データクライアント２１１からの要求、例えば、データの更新、検索等を受け付ける。そして、クエリ管理部２１１
は、受け付けた要求の内容を確認した後、要求内容に応じて、データサーバ２２〜２４に対して、問い合わせや、操作の指示を発行し、これらを送信する。データベース管理部２１は、クエリ管理部２１１により、問い合わせ受け付けサーバとして機能している。
【００３３】
また、本実施の形態１において、システム管理装置２１とデータベースクライアント１との接続は、ネットワークによって行われている。更に、同様に、システム管理装置２１と、データベースサーバ２２〜２５それぞれとの接続もネットワークによって行われている。
【００３４】
また、不要領域修復管理部２１２は、本実施の形態では、クエリ管理部２１１から、データベースサーバ２２〜２５への問い合わせの結果や、これらに対して行った操作の実行結果を受け取る。そして、不要領域修復管理部２１２は、不要領域の修復処理が指示された各データベースサーバにおける動作状況を判断し、判断結果に応じて、クエリ管理部２１１に対して指示を行う。
【００３５】
データベースサーバ２２〜２５は、それぞれ、同様の構成を備えており、データベース管理部と記憶装置とを備えている。例えば、データベースサーバ２２は、データベース管理部２２１と、記憶装置２２２とを備えている。データベース管理部２２１は、クエリ管理部２１１が発行した問い合わせや操作の指示を受けると、これらの内容を分析し、分析結果に応じて処理を実行する。また、データベース管理部２２１は、処理の結果をクエリ管理部２１１に返却する。
【００３６】
記憶装置２２２は、格納が指示されたデータ、インデックスデータ、データベースの統計情報、及びトランザクション情報等のデータベースの運用に必要な情報を記録している。なお、他のデータベースサーバ２３、２４及び２５の構成及び動作は、上述したデータベースサーバ２２と同様であり、これらのデータベースサーバについての説明は省略する。
【００３７】
次に、本発明の実施の形態１における管理装置２１の動作を、図２を用いて説明する。図２は、本発明の実施の形態１における管理装置の動作を示すフロー図である。なお、本実施の形態１におけるデータベース管理方法は、本実施の形態１における管理装置２１を動作させることによって実行される。よって、データベース管理方法の説明は、以下の管理装置２１の動作の説明に代える。また、以下の説明においては、適宜図１を参酌する。
【００３８】
図２に示すように、先ず、クエリ管理部２１１は、データベースクライアント１が不要領域の修復処理の要求コマンドを発行すると、これを受け付け、不要領域修復管理部２１２に、不要領域の修復処理の開始を通知する（ステップＳ１）。
【００３９】
次に、不要領域修復管理部２１２は、データベースサーバ２２〜２５のうちの一部、例えば、データベースサーバ２２と２３とを修復対象に割り当て、そのことをクエリ管理部２１１に通知する（ステップＳ２）。そして、クエリ管理部２１１は、データベースサーバ２２のデータベース管理部２２１とデータベースサーバ２３のデータベース管理部２３１とに、不要領域の修復処理の指示を発行する。これにより、データベースサーバ２２及び２３において、不要領域の修復処理が実行される。
【００４０】
次に、クエリ管理部２１１は、データベースクライアント１から、不要領域の修復処理とは別の操作要求、例えば、データの検索を受けた場合は、修復処理の指示を行っていない別のデータベースサーバ２４及び２５に、求められた処理の実行を指示する（ステップＳ３）。
【００４１】
このとき、データベースクライアント１から、データの更新が指示された場合は、データベースサーバ２２及び２３に対しては更新を行えないため、クエリ管理部２１１は、不要領域修復管理部２１２に更新内容をプールさせる。不要領域修復管理部２１２は、データベース２２及び２３において不要領域の修復処理が終了すると、これらに対して、クエリ管理部２１１を介して更新を行わせる。なお、上述した処理の詳細については後述する。
【００４２】
次に、データベースサーバ２２及び２３において、不要領域の修復処理が終了すると、不要領域修復管理部２１２は、修復処理が終了していないデータベースサーバ２４及び２５を修復対象に割り当て、そのことをクエリ管理部２１１に通知する（ステップＳ４）。これにより、修復対象となるデータベースが入れ替えられ、全てのデータベースに対する不要領域の修復処理が終了する。そして、ステップＳ１〜Ｓ４までの間、全てのデータベースにおいて同時に不要領域の修復処理が行われることはないため、上述したように、不要領域の修復に関わる排他処理の時間は縮小される。
【００４３】
ステップＳ４の実行後、クエリ管理部２１１は、通常の運用に戻り、データベースクライアント１から操作要求があった場合は、全てのデータベースに対して、操作要求を実行させる（ステップＳ５）。
【００４４】
次に、管理装置２１の動作を更に具体的に説明するため、データベース管理システム２の全体の動作を、図３及び図４を用いて説明する。図３は、本発明の実施の形態１の管理装置によって構成されたデータベース管理システムにおけるアクティビティの変化を示すアクティビティ図である。図４は、本実施の形態１において行われる不要領域修復処理の概念を説明する説明図である。
【００４５】
先ず、図３に示すように、データベースクライアント１から、データベース管理システム２全体に対して不要領域の修復処理を要求するコマンドが発行されると、クエリ管理部２１１は、不要領域の修復処理の要求コマンドを受け付ける（ステップＡ１）。そして、クエリ管理部２１１は、不要領域修復管理部２１２に、不要領域の修復処理の開始を通知する。なお、本実施の形態において行われる修復処理は、背景技術の欄で述べた「完全不要領域修復方法」である。
【００４６】
次に、不要領域修復管理部２１２は、データベースサーバ２２〜２５の半分を修復対象のデータベースサーバに割り当て、残りのデータベースサーバを通常対応のデータベースサーバに割り当て、結果を、クエリ管理部２１１に通知する（ステップＡ２）。本実施の形態１では、上述したように、例として、最初、データベースサーバ２２と２３とが修復対象のデータベースサーバに割り当てられ、データベースサーバ２４と２５とが通常対応のデータベースサーバに割り当てられるものとして説明する。
【００４７】
また、ステップＡ２では、クエリ管理部２１１は、不要領域の修復処理の指示を、修復対象のデータベースサーバ２２のデータベース管理部２２１と、データベースサーバ２３のデータベース管理部２３１とに対して、発行する。
【００４８】
また、複数の仮想ＯＳを保有可能な１つのコンピュータ上で仮想化された複数のデータベースサーバが動作し、且つ、各仮想マシンのＣＰＵやメモリ等のリソースを動的に別の仮想マシンに移行できる技術が知られている。この技術を本実施の形態１に適用すれば、修復対象の仮想データベースサーバのＣＰＵやメモリのリソースの一部を、通常対応の仮想データベースサーバに移行することができ、運用中のデータベースシステム全体としての性能低下を抑制することができる。
【００４９】
次に、修復処理の指示を受けたデータベース管理部２２１（又は２３１）は、修復対象のデータベースそれぞれのデータを格納している全てのページに対して完全修復操作を実行する（ステップＡ３）。ここで、ステップＡ３における修復操作を、図４に基づいて説明する。
【００５０】
図４に示すように、空き領域を有する連続したページ３及びページ４が存在しているとする。ページ３及び４に対しては、修復処理が未だ行われておらず、これらは解放前の状態にある。ページ３には、ページ管理情報３１と、タプルデータ３２１〜３２５とが存在している。また、タプルデータ３２１〜３２５のうち、有効タプルデータは３２１と３２４とであり、削除可能タプルデータは３２２、３２３、及び３２５である。
【００５１】
同様に、ページ４には、ページ管理情報３１と、タプルデータ４２１〜４２５とが存在している。また、タプルデータ４２１〜４２５のうち、有効タプルデータは４２２、４２３、及び４２４であり、削除可能タプルデータは４２１と４２５とである。
【００５２】
そして、解放前のページ３とページ４とに対して修復処理（完全修復操作）を行い、得られたページが、空き領域解放後のページ５となる。具体的には、データベース管理部は、有効タプルデータ３２１及び３２４を、順に、後方に向けて詰めていく操作を実行する。図４の例では、タプルデータ３２１が最も後方にあるので、タプルデータ３２４をその後方に向けて移動させ、その位置をページ５のタプルデータ５２２の位置とする。
【００５３】
更に、管理情報３１において、削除タプルデータ３３２、３３３、及び３３５のタプル情報は無効化され、管理情報３１は、ページ管理情報５１に書き換えられる。その後、ページ４の有効タプルデータであるタプルデータ４２２、４２３、及び４２４が、ページ５に書き込まれ、不要となったページ４が削除される。
【００５４】
つまり、図４の例では、タプルデータ３２１がタプルデータ５２１と等しくなり、タプルデータ３２４がタプルデータ５２２と等しくなる。また、タプルデータ４２２がタプルデータ５２３と等しくなり、タプルデータ４２３がタプルデータ５２４と等しくなり、更にタプルデータ４２４がタプルデータ５２５と等しくなる。この結果、有効なタプルのみがページ５に残る。そして、ページ４が削減されて、記憶装置の記憶領域にデータ領域を確保することができる。本実施の形態では、修復処理は、このような手順によって行なわれる。
【００５５】
また、上述のステップＡ３と平行して、又はステップＡ３の実行後に、クエリ管理部２１１が、データベースクライアント１から、検索や更新等の操作要求を受け取った場合は、ステップＢが実行される。ステップＢでは、クエリ管理部２１１は、通常対応のデータベースサーバのデータベース管理部２４１（又は２５１）に対して操作を発行する。なお、データベースクライアント１からの操作要求が、更新処理である場合は、不要領域修復管理部２１２は、更新命令をプールする。ステップＢの詳細は、図５を用いて後述する。
【００５６】
次に、修復対象データベースサーバにおいて修復処理が完了すると、その情報が、クエリ管理部２１１へ返却される。更に、ステップＡ２で対象となったデータベースサーバの修復処理が全て完了すると、クエリ管理部２１１は、不要領域修復管理部２１２に対して、対象となっていたデータベースサーバにおいて修復処理が完了したことを通知する（図３のステップＡ４）。
【００５７】
次に、不要領域修復管理部２１２は、修復処理の完了の通知を受けると、ステップＢにおいてプールしていた更新処理をクエリ管理部２１１に対して発行する（ステップＡ５）。そして、クエリ管理部２１１は、不要領域の修復処理が完了したデータベースのデータ
ベース管理部２２１及び２３１に対して、更新命令を発行する。
【００５８】
次に、データベース管理部２２１及び２３１は、クエリ管理部２１１が発行した更新命令に従い、対応する記憶部が構成するデータベースの更新を実行する（ステップＡ６）。そして、このステップＡ５〜ステップＡ６までの処理は、プールされていた更新命令の分だけ繰り返し行われる。これにより、ステップＢによって発生した、修復対象のデータベースサーバ２２及び２３と通常対応のデータベースサーバ２４及び２５との差分が、埋められて行くこととなる。
【００５９】
なお、ステップＡ５〜ステップＡ６の間に、更に新しい問合せがデータベースクライアント１からクエリ管理部２１１に発行された場合は、クエリ管理部２１１は、後述するステップＢと同様の操作を実行する。
【００６０】
そして、ステップＡ５〜ステップＡ６までの処理の繰り返しにより、全ての差分の反映が終了すると、不要領域修復管理部２１２は、修復対象のデータベースサーバと通常対応のデータベースサーバとの役割を入れ替えるため、割り当てを変更し、未だ不要領域の修復処理が行われていない未修復のデータベースサーバに対して、不要領域の修復処理を実行する（ステップＡ７）。
【００６１】
ステップＡ７の実行後、全てのデータベースサーバに対する不要領域の修復処理は終了する。なお、ステップＡ１〜Ａ７の動作では、修復処理中において、更新処理による不要領域が発生する可能性があるが、データベース全体としては、殆どの不要領域が修復され、大幅なページの削減が可能となる。
【００６２】
ここで、図３に示されたステップＢについて図５に基づいて具体的に説明する。図５は、図３に示したステップＢを具体的に示すアクティビティ図である。なお、図５の例においても、図３の例と同様に、修復対象のデータベースサーバとしてデーベースサーバ２２及び２３が割り当てられ、通常対応のデータベースサーバとしてデータベースサーバ２４及び２５が割り当てられているとする。
【００６３】
また、図５に示すステップＢによるデータベース操作受付処理は、不要領域の修復処理が完了し、修復対象のデータベースサーバと通常対応のデータベースサーバとの差分が解消され同期が完了（図３のステップＡ５〜Ａ６の繰り返しが終了）した時点で終了となる。
【００６４】
先ず、図５に示すように、クエリ管理部２１１は、上記の差分が解消するまでの間、データベースクライアント１からのデータベース操作を受け付ける（ステップＢ１）。次に、データベースクライアント１から操作要求が発行されると、クエリ管理部２１１は、操作内容の検証を行う（ステップＢ２）。
【００６５】
次に、ステップＢ２の検証の結果、操作の種類が検索処理であった場合は、クエリ管理部２１１は、通常対応のデータベースサーバの中で負荷の低いデータベースサーバ（ここでは２４だとする）のデータベース管理部に対して、検索命令を発行する（ステップＢ３）。
【００６６】
次に、検索命令を受けたデータベースサーバのデータベース管理部（ここでは、データベース管理部２４１）は、検索処理を実行する（ステップＢ４）。そして、データベース管理部は、検索処理の結果を、クエリ管理部２１１へ送信する（ステップＢ５）。その後、クエリ管理部２１１は、受け取った検索結果を、そのままデータベースクライアント１に送信する（ステップＢ６）。
【００６７】
また、ステップＢ２の検証の結果、操作の種類が更新処理であった場合は、クエリ管理部２１１は、通常対応のデータベースサーバ２４及び２５と不要領域修復管理部２１２とに更新命令を発行する（ステップＢ７）。この時、不要領域修復管理部２１２は、更新命令を受け付けた順に保持する。
【００６８】
また、更新命令を受け取ったデータベース管理部２４１及び２４２は、それぞれ更新処理を解釈し、それぞれの対応する記憶装置２４２（又は２４３）に記録されているデータベースを更新する（ステップＢ８）。
【００６９】
次に、更新処理が終了すると、データベース管理部２４１及び２４２は、それぞれクエリ管理部２１１に結果を送信する（ステップＢ９）。また、クエリ管理部２１１は全ての正常結果を受信したことを確認すると（ステップＢ１１）、上述の検索処理の場合と同様に、データベースクライアント１に結果を返却する（ステップＢ６）。更に、クエリ管理部２１１は、更新件数を、不要領域修復管理部２１２に通知する。
【００７０】
ここで、図５中に示されたステップＣ（例外処理）について説明する。上述したステップＢ１では、複数のデータベースクライアント１からデータベース操作が入力され、大量の操作処理を受け付けなければならない場合が想定される。一方、不要領域の修復処理中はデータベースとして運用されているサーバの台数は通常よりも少なくなっている。このため、データベースの検索処理性能も同様に通常よりも低下してしいる。
【００７１】
よって、ある程度までのデータベース操作であれば、既に述べたデータベースの検索処理や更新処理によって、データベースの性能低下を抑制することによって対応可能であるが、大量の検索処理等が要求された場合は、データベースとしてのレスポンス低下が懸念される。また、本実施の形態１を実施する際において、データベースに高い負荷がかかる状況は避けるべきではあるが、運用上確実に回避できない場合も想定される。
【００７２】
そこで、本実施の形態１においては、データベースクライアントからの操作要求に対して一定の閾値を設け、それ以上（又はそれを超える）のデータベース操作要求が来た場合は、不要領域の修復処理を中断することとしている。そして、この場合は、中断するまでに発生したデータベースへの更新差分の同期処理が即座に適用され、その後、通常運用に戻ることで、処理能力が低下した状態は回避される。
【００７３】
但し、このような処理を採用する場合は、更新差分の同期処理自体が大量にある事態も想定され、更に状況を悪化させる可能性がある。よって、このような事態の発生を回避するため、更新差分の発生量にも閾値を設け、それを上回る場合にも、同様に、不要領域の修復処理が中断されるようにするのが好ましい。
【００７４】
また、修復処理を中断させるデータベースサーバの台数は、複数の閾値を設定し、閾値毎に変化させても良い。つまり、更新差分の発生量に応じて、１台ずつ順に処理を中断させても良いし、全てのデータベースサーバに対して一度に中断させても良い。なお、不要領域の修復処理では、データの移動が行われているにすぎず、修復処理自体が途中で中断されても、データベースサーバは、直ぐにデータベースとしての利用が可能な状態である。
【００７５】
次に、図６を用いて、図５に示したステップＣ（例外処理）の内容を具体的に説明する。図６は、図５に示したステップＣを具体的に示すアクティビティ図である。図６に示すステップは、上記の説明の通り、データベースクライアント１からの操作要求（接続要求）の要求量又は要求件数（例えば、データベース更新の件数）が、それぞれに設定されて
いる閾値を超えた場合に開始される。
【００７６】
最初に、図６に示すように、クエリ管理部２１１は、閾値に対応させた修復対象のデータベースサーバのデータベース管理部に対して、不良領域の修復処理の中断を指示する命令（修復中断命令）を発行し、これを送信する（ステップＣ１）。
【００７７】
次に、修復中断命令を受けたデータベース管理部は、修復処理を即時終了させて（ステップＣ２）、停止完了をクエリ管理部２１１に報告する（ステップＣ３）。次に、クエリ管理部２１１は、終了報告を確認後、ステップＢ７と同様に、不要領域修復管理部２１２によってプールされていた更新命令を、再度、対象のデータベース管理部に対して発行する。（ステップＣ４）。
【００７８】
次に、更新命令を受けたデータベース管理部は、更新操作を実行し（ステップＣ５）、結果を、クエリ管理部２１１に送信する（ステップＣ６）。クリエ管理部２１１は、結果を受信する（ステップＣ７）。ステップＣ５〜Ｃ７が繰り返され、全ての更新命令が完了すると、不要領域修復管理部２１２は、ステップＡ７と同様に、対象のデータベースサーバの割り当てを修復対象のデータベースサーバから通常対応のデータベースサーバへと変更する（ステップＣ８）。これにより、通常対応のデータベースサーバが増加する。
【００７９】
また、本実施の形態１におけるプログラムは、コンピュータに、図２に示すステップＳ１〜Ｓ４、具体的には、ステップＡ１、Ａ２、Ａ５、Ａ７、Ｂ１、Ｂ２、Ｂ３、Ｂ６、Ｂ７、Ｂ１１、Ｃ１、Ｃ４、Ｃ７、Ｃ８を実行させるプログラムであれば良い。このプログラムをコンピュータにインストールし、実行することにより、本実施の形態１における管理装置及びデータベース管理方法を実現することができる。また、この場合、コンピュータのＣＰＵ（central processing unit）は、クエリ管理部２１１、不要領域修復管理部２１２として機能し、処理を行なう。
【００８０】
以上のように、本実施の形態１によれば、データベースが多重化されたデータベース管理システムにおいては、修復対象のデータベースと通常運用のデータベースとに分けて処理が行われる。よって、上述したように、不要領域の修復に関わる排他処理の時間は縮小される。そして、データベースにおいて不要領域の修復処理を実行しながら、データベースクライアントからの検索や更新といった通常の操作要求を受け、これらの処理を実行することができる。
【００８１】
また、修復対象のデータベースと通常運用のデータベースとの間に生じる差分は、不要領域修復管理部２１２によって管理され、不要領域の修復が完了すると適用される。更に、差分を適用する際において、通常運用のデータベースが停止されることはない。このため、本実施の形態１では、データベースクライアントからの更新処理を止めること無く、差分の適用を行うことができる。
【００８２】
更に、本実施の形態１では、図５及び図６においてステップＣで示したように、データベースクライアント１からの操作要求に応じて、データベースの性能が低下しないよう、自動的に不要領域の修復処理が中断される。このため、本実施の形態１は、データベースクライアント１の台数の増加や操作要求の増加にも対応することができる。
【００８３】
また、複数の仮想ＯＳ上でデータベースシステムを構築している場合では、ＣＰＵやメモリのリソースを動的に移行して通常対応データベースサーバの性能を向上させることにより、データベースサーバが少なくなることによる検索性能低下を補うことが可能となる。これは不要領域処理が記憶装置への負荷が高く、比較的ＣＰＵやメモリのリソースは必要としないことを利用したものである。この技術を本実施の形態１に適用すれば、上述し
たように、運用中のデータベースシステム全体の性能低下を抑制することができる。
【００８４】
（実施の形態２）
次に本発明の実施の形態２における、管理装置、データベース管理方法、及びプログラムについて説明する。但し、本実施の形態２における管理装置及びそれを備えるデータベース管理システムの構成は、実施の形態１において図１に示した管理装置及びデータベース管理システムの構成と同様である。
【００８５】
本実施の形態２は、管理装置及びデータベースサーバにおける一部の処理が、実施の形態１におけるこれらの処理と異なっている。つまり、実施の形態１では、不要領域の修復処理の終了後に、データベースクライアントからの操作は受け付けたまま、修復対象のデータベースに対して更新命令が発行され、更新差分の適用が行われている。但し、この方式では、通常対応のデータベースの更新完了日時と修復対象のデータベースの更新日時とに幾らかの差異が生じることがあり、データベースによっては、差異の解消が求められる場合がある。このため、本実施の形態２においては、実施の形態１と異なる処理が行われる。
【００８６】
本実施の形態２における処理について、図７及び図８を用いて以下に説明する。図７は、本発明の実施の形態２の管理装置によって構成されたデータベース管理システムにおけるアクティビティの変化を示すアクティビティ図である。図８は、図７に示したステップＢ１０に含まれる処理を具体的に示すアクティビティ図である。
【００８７】
図７に示されたステップのうち、実施の形態１で用いた図３に示された符号が付されたステップは、当該符号が付された図３のステップと同一ステップである。つまり、図７において、ステップＡ１〜Ａ４及びＡ７は、実施の形態１におけるステップＡ１〜Ａ４及びＡ７と同様に、クエリ管理部２１１、不要領域修復管理部２１２、データベース管理部２２１、２３１、２４１、２５１によって実行される。
【００８８】
一方、図７に示されたステップＢ１０は、図３に示されたステップＢとは、例外処理（図５及び図６に示すステップＣ）の点で異なっている。本実施の形態２においては、後述するように、例外処理は、図８に沿って実行される。図８に示す処理については後述する。また、ステップＤ１〜Ｄ４は、本実施の形態２に特有のステップである。以下に、ステップＤ１〜Ｄ４について説明する。
【００８９】
なお、以下の説明では、実施の形態１で用いた図１を適宜参酌する。また、本実施の形態２においても、実施の形態１と同様に、最初に、データベースサーバ２２及び２３が修復対象のデータベースサーバに割り当てられ、データベースサーバ２４及び２５が通常対応のデータベースサーバに割り当てられているとする。
【００９０】
図７に示すように、不要領域の修復処理が行われている間、クエリ管理部２１１は、データベースクライアント１からの検索や更新といった操作の受付を保留にし、不要領域修復管理部２１２に、これらをプールさせる（ステップＤ１）。
【００９１】
次に、クエリ管理部２１１は、通常対応のデータベースのデータベース管理部２４１及び２５１に対して、ジャーナルの転送命令を発行する。データベース管理部２４１及び２５１は、転送命令を受信すると、修復対象のデータベースのデータベース管理部２２１及び２３１にデータベースの更新情報であるジャーナルを転送する（ステップＤ２）。なお、通常対応のデータベースの台数より修復対象のデータベースの台数が多い場合は、ジャーナルの転送が早く終わったデータベースが、更に残りの修復対象のデータベースへジャーナルを転送する。
【００９２】
次に、クエリ管理部２１１は、ジャーナルの転送が完了した修復対象のデータベースサーバのデータベース管理部に対して、ジャーナルによる差分の適用を指示し、実行させる（ステップＤ３）。
【００９３】
ステップＤ３により、全ての差分更新（差分の適用）が完了すると、全てのデータベースの同期が取れた状態となる。そこで、クエリ管理部２１１は、保留していたデータベース操作を各データベースサーバに指示するため、これらを受け付けた順番で、その内容に従い、各データベースサーバに対して操作要求を発行する（ステップＤ４）。
【００９４】
その後、実施の形態１と同様に、不要領域修復管理部２１２は、修復対象のデータベースサーバと通常対応のデータベースサーバとの役割を入れ替え、未だ不要領域の修復処理が行われていないデータベースサーバに対して、不要領域の修復処理を実行する（ステップＡ７）。
【００９５】
次に、図８を用いて、ステップＢ１０に含まれる例外処理について説明する。図８に示されたステップのうち、実施の形態１で用いた図６に示された符号が付されたステップは、当該符号が付された図６のステップと同一ステップである。つまり、図８において、ステップＣ１〜Ｃ３及びＣ８は、実施の形態１におけるステップＣ１〜Ｃ３及びＣ８と同様に、クエリ管理部２１１、不要領域修復管理部２１２、データベース管理部２２１、２３１、２４１、２５１によって実行される。
【００９６】
一方、ステップＥ１〜Ｅ４は、本実施の形態２に特有のステップである。以下に、ステップＥ１〜Ｅ４について説明する。また、以下の説明においても、適宜図１を参酌する。
【００９７】
先ず、図８に示すように、修復処理の中断が完了すると、図７に示したステップＤ１と同様、クエリ管理部２１１は、データベースクライアント１からの検索や更新といった操作の受付を保留にし、不要領域修復管理部２１２に、これらをプールさせる。（ステップＥ１）。
【００９８】
次に、クエリ管理部２１１は、通常対応のデータベースのデータベース管理部２４１及び２５１に対して、ジャーナルの転送命令を発行する。データベース管理部２４１及び２５１は、ステップＤ２と同様、転送命令を受信すると、修復処理を停止している修復対象のデータベースのデータベース管理部２２１及び２３１にデータベースの更新情報であるジャーナルを転送する（ステップＥ２）。
【００９９】
次に、クエリ管理部２１１は、ステップＤ３と同様に、ジャーナルの転送が完了した修復対象のデータベースサーバのデータベース管理部に対して、ジャーナルによる差分の適用を指示し、実行させる（ステップＥ３）。
【０１００】
次に、全ての差分更新が完了すると、クエリ管理部２１１は、ステップＤ４と同様に、保留していたデータベース操作を各データベースサーバに指示するため、これらを受け付けた順番で、その内容に従い、各データベースサーバに対して操作要求を発行する（ステップＥ４）。
【０１０１】
その後、不要領域修復管理部２１２は、図６の例と同様に、対象のデータベースサーバの割り当てを、修復対象のデータベースサーバから通常対応のデータベースサーバへと変更する（ステップＣ８）。これにより、通常対応のデータベースサーバが増加する。
【０１０２】
このように、本実施の形態２では、実施の形態１と異なり、通常対応のデータベースサ
ーバから、その更新内容を含むジャーナルが、修復対象のデータベースサーバに対して送信され、ジャーナルを用いて更新が行われる。
【０１０３】
よって、本実施の形態２によれば、通常対応のデータベースの更新完了日時と修復対象のデータベースの更新日時とに差異が生じるのを抑制できる。このため、データベースクライアントからの更新処理の要求に、更新日時に関係する内容が含まれていても、修復対象のデータベースと通常対応のデータベースの同期を取ることが可能となる。本実施の形態２は、更新時に全てのデータベースサーバが更新結果をクエリ管理部２１１に送信することを利用している。データベース間の更新日時は完全とは言わないまでもほぼ同時刻となる。また、本実施の形態２においても、実施の形態１で述べた効果は全て得ることができる。
【産業上の利用可能性】
【０１０４】
以上のように、本発明は、データベース管理システム、特には、データベースサーバが多重化された、追記型データベース管理システムに有効である。本発明は、産業上の利用可能性を有している。
【符号の説明】
【０１０５】
１ データベースクライアント
２ データベース管理システム
３ ページ（解放前）
４ ページ（解放前）
５ ページ（解放後）
２１ 管理装置
２２ データベースサーバ
２３ データベースサーバ
２４ データベースサーバ
２５ データベースサーバ
３１ ページ管理情報
４１ ページ管理情報
５１ ページ管理情報
２１１ クエリ管理部
２１２ 不要領域修復管理部
２２１ データベース管理部
２２２ 記憶装置
２３１ データベース管理部
２３２ 記憶装置
２４１ データベース管理部
２４２ 記憶装置
２５１ データベース管理部
２５２ 記憶装置
３２１〜３２５ タプルデータ
４２１〜４２５ タプルデータ
５２１〜５２５ タプルデータ
【特許請求の範囲】
【請求項１】
多重化された複数のデータベースサーバを備えたデータベース管理システムを構成する管理装置であって、
前記複数のデータベースサーバそれぞれにおける不要領域の修復処理を管理する不要領域修復管理部を備え、
前記不要領域修復管理部は、前記複数のデータベースサーバそれぞれにおいて不要領域の修復処理が必要となると、一部の前記データベースサーバに、先に前記修復処理を実行させ、その後、残りの前記データベースサーバに、前記修復処理を実行させる、
ことを特徴とする管理装置。
【請求項２】
前記複数のデータベースサーバそれぞれに対する外部からの操作要求を管理し、これらに対して前記処理を指示するクエリ管理部を更に備え、
前記クエリ管理部は、いずれかの前記データベースサーバが前記修復処理を実行している間に、外部から操作要求があった場合に、前記修復処理を実行していない前記データベースサーバに、要求のあった前記処理を実行させる、請求項１に記載の管理装置。
【請求項３】
前記クエリ管理部は、前記外部からの操作要求として、前記複数のデータベースサーバの更新が要求された場合に、
前記修復処理を実行してない前記データベースサーバに対しては、前記更新を実行させ、前記修復処理を実行している前記データベースサーバに対しては、前記不要領域修復管理部の指示に応じて、前記修復処理の終了後に、前記更新を実行させる、
請求項２に記載の管理装置。
【請求項４】
前記クエリ管理部は、前記外部からの操作要求の要求量または要求件数が、設定された閾値を超えた場合又は前記閾値以上となった場合に、
前記修復処理を実行している前記データベースサーバに対して、前記修復処理を中断させる、請求項２または３に記載の管理装置。
【請求項５】
前記クエリ管理部が、
前記更新の実行が終了した前記データベースサーバに対して、前記更新の内容を含むジャーナルを、前記更新を実行していない前記データベースサーバに向けて送信させ、
前記更新を実行していない前記データベースサーバに対して、前記ジャーナルを用いて前記更新を実行させる、
請求項３に記載の管理装置。
【請求項６】
多重化された複数のデータベースサーバを備えたデータベース管理システムにおいてデータベースの管理を行うための方法であって、
（ａ）前記複数のデータベースサーバそれぞれにおいて不要領域の修復処理が必要となった場合に、一部の前記データベースサーバに、先に前記修復処理を実行させるステップと、
（ｂ）前記（ａ）のステップの実行後に、残りの前記データベースサーバに、前記修復処理を実行させるステップと、
を有することを特徴とするデータベース管理方法。
【請求項７】
（ｃ）いずれかの前記データベースサーバが前記修復処理を実行している間に、前記複数のデータベースサーバそれぞれに対して、外部から操作が要求されているかどうかを判定するステップと、
（ｄ）前記（ｃ）のステップで、外部から前記操作が要求されていると判定された場合に、前記修復処理を実行していない前記データベースサーバに、要求のあった前記処理を実
行させるステップとを、
更に有する請求項６に記載のデータベース管理方法。
【請求項８】
前記（ｄ）のステップにおいて、
前記外部からの操作要求として、前記複数のデータベースサーバの更新が要求された場合に、
前記修復処理を実行してない前記データベースサーバに対しては、前記更新を実行させ、前記修復処理を実行している前記データベースサーバに対しては、前記不要領域修復管理部の指示に応じて、前記修復処理の終了後に、前記更新を実行させる、請求項７に記載のデータベース管理方法。
【請求項９】
（ｅ）前記外部からの操作要求の要求量または要求件数が、設定された閾値を超えているか、又は前記閾値以上となっているかどうかを判定する、ステップと、
（ｆ）前記（ｅ）のステップで前記閾値を超えている、又は前記閾値上となっていると判定された場合に、前記修復処理を実行している前記データベースサーバに対して、前記修復処理を中断させる、ステップとを、
更に有する、請求項７または８に記載のデータベース管理方法。
【請求項１０】
（ｇ）前記更新の実行が終了した前記データベースサーバに対して、前記更新の内容を含むジャーナルを、前記更新を実行していない前記データベースサーバに向けて送信させる、ステップを更に有し、
前記（ｄ）のステップにおいて、前記更新を実行していない前記データベースサーバに対して、前記ジャーナルを用いて前記更新を実行させる、
請求項８に記載のデータベース管理方法。
【請求項１１】
多重化された複数のデータベースサーバを備えたデータベース管理システムにおいて、コンピュータに、データベースの管理を行わせるためのプログラムであって、
前記コンピュータに、
（ａ）前記複数のデータベースサーバそれぞれにおいて不要領域の修復処理が必要となった場合に、一部の前記データベースサーバに、先に前記修復処理を実行させるステップと、
（ｂ）前記（ａ）のステップの実行後に、残りの前記データベースサーバに、前記修復処理を実行させるステップと、
を実行させることを特徴とするプログラム。
【請求項１２】
（ｃ）いずれかの前記データベースサーバが前記修復処理を実行している間に、前記複数のデータベースサーバそれぞれに対して、外部から操作が要求されているかどうかを判定するステップと、
（ｄ）前記（ｃ）のステップで、外部から前記操作が要求されていると判定された場合に、前記修復処理を実行していない前記データベースサーバに、要求のあった前記処理を実行させるステップとを、
更に前記コンピュータに実行させる請求項１１に記載のプログラム。
【請求項１３】
前記（ｄ）のステップにおいて、
前記外部からの操作要求として、前記複数のデータベースサーバの更新が要求された場合に、
前記修復処理を実行してない前記データベースサーバに対しては、前記更新を実行させ、前記修復処理を実行している前記データベースサーバに対しては、前記不要領域修復管理部の指示に応じて、前記修復処理の終了後に、前記更新を実行させる、請求項１２に記載のプログラム。
【請求項１４】
（ｅ）前記外部からの操作要求の要求量または要求件数が、設定された閾値を超えているか、又は前記閾値以上となっているかどうかを判定する、ステップと、
（ｆ）前記（ｅ）のステップで前記閾値を超えている、又は前記閾値上となっていると判定された場合に、前記修復処理を実行している前記データベースサーバに対して、前記修復処理を中断させる、ステップとを、
更に前記コンピュータに実行させる、請求項１２または１３に記載のプログラム。
【請求項１５】
（ｇ）前記更新の実行が終了した前記データベースサーバに対して、前記更新の内容を含むジャーナルを、前記更新を実行していない前記データベースサーバに向けて送信させる、ステップを更に前記コンピュータに実行させ、
前記（ｄ）のステップにおいて、前記更新を実行していない前記データベースサーバに対して、前記ジャーナルを用いて前記更新を実行させる、
請求項１３に記載のプログラム。
【請求項１】
多重化された複数のデータベースサーバを備えたデータベース管理システムを構成する管理装置であって、
前記複数のデータベースサーバそれぞれにおける不要領域の修復処理を管理する不要領域修復管理部を備え、
前記不要領域修復管理部は、前記複数のデータベースサーバそれぞれにおいて不要領域の修復処理が必要となると、一部の前記データベースサーバに、先に前記修復処理を実行させ、その後、残りの前記データベースサーバに、前記修復処理を実行させる、
ことを特徴とする管理装置。
【請求項２】
前記複数のデータベースサーバそれぞれに対する外部からの操作要求を管理し、これらに対して前記処理を指示するクエリ管理部を更に備え、
前記クエリ管理部は、いずれかの前記データベースサーバが前記修復処理を実行している間に、外部から操作要求があった場合に、前記修復処理を実行していない前記データベースサーバに、要求のあった前記処理を実行させる、請求項１に記載の管理装置。
【請求項３】
前記クエリ管理部は、前記外部からの操作要求として、前記複数のデータベースサーバの更新が要求された場合に、
前記修復処理を実行してない前記データベースサーバに対しては、前記更新を実行させ、前記修復処理を実行している前記データベースサーバに対しては、前記不要領域修復管理部の指示に応じて、前記修復処理の終了後に、前記更新を実行させる、
請求項２に記載の管理装置。
【請求項４】
前記クエリ管理部は、前記外部からの操作要求の要求量または要求件数が、設定された閾値を超えた場合又は前記閾値以上となった場合に、
前記修復処理を実行している前記データベースサーバに対して、前記修復処理を中断させる、請求項２または３に記載の管理装置。
【請求項５】
前記クエリ管理部が、
前記更新の実行が終了した前記データベースサーバに対して、前記更新の内容を含むジャーナルを、前記更新を実行していない前記データベースサーバに向けて送信させ、
前記更新を実行していない前記データベースサーバに対して、前記ジャーナルを用いて前記更新を実行させる、
請求項３に記載の管理装置。
【請求項６】
多重化された複数のデータベースサーバを備えたデータベース管理システムにおいてデータベースの管理を行うための方法であって、
（ａ）前記複数のデータベースサーバそれぞれにおいて不要領域の修復処理が必要となった場合に、一部の前記データベースサーバに、先に前記修復処理を実行させるステップと、
（ｂ）前記（ａ）のステップの実行後に、残りの前記データベースサーバに、前記修復処理を実行させるステップと、
を有することを特徴とするデータベース管理方法。
【請求項７】
（ｃ）いずれかの前記データベースサーバが前記修復処理を実行している間に、前記複数のデータベースサーバそれぞれに対して、外部から操作が要求されているかどうかを判定するステップと、
（ｄ）前記（ｃ）のステップで、外部から前記操作が要求されていると判定された場合に、前記修復処理を実行していない前記データベースサーバに、要求のあった前記処理を実
行させるステップとを、
更に有する請求項６に記載のデータベース管理方法。
【請求項８】
前記（ｄ）のステップにおいて、
前記外部からの操作要求として、前記複数のデータベースサーバの更新が要求された場合に、
前記修復処理を実行してない前記データベースサーバに対しては、前記更新を実行させ、前記修復処理を実行している前記データベースサーバに対しては、前記不要領域修復管理部の指示に応じて、前記修復処理の終了後に、前記更新を実行させる、請求項７に記載のデータベース管理方法。
【請求項９】
（ｅ）前記外部からの操作要求の要求量または要求件数が、設定された閾値を超えているか、又は前記閾値以上となっているかどうかを判定する、ステップと、
（ｆ）前記（ｅ）のステップで前記閾値を超えている、又は前記閾値上となっていると判定された場合に、前記修復処理を実行している前記データベースサーバに対して、前記修復処理を中断させる、ステップとを、
更に有する、請求項７または８に記載のデータベース管理方法。
【請求項１０】
（ｇ）前記更新の実行が終了した前記データベースサーバに対して、前記更新の内容を含むジャーナルを、前記更新を実行していない前記データベースサーバに向けて送信させる、ステップを更に有し、
前記（ｄ）のステップにおいて、前記更新を実行していない前記データベースサーバに対して、前記ジャーナルを用いて前記更新を実行させる、
請求項８に記載のデータベース管理方法。
【請求項１１】
多重化された複数のデータベースサーバを備えたデータベース管理システムにおいて、コンピュータに、データベースの管理を行わせるためのプログラムであって、
前記コンピュータに、
（ａ）前記複数のデータベースサーバそれぞれにおいて不要領域の修復処理が必要となった場合に、一部の前記データベースサーバに、先に前記修復処理を実行させるステップと、
（ｂ）前記（ａ）のステップの実行後に、残りの前記データベースサーバに、前記修復処理を実行させるステップと、
を実行させることを特徴とするプログラム。
【請求項１２】
（ｃ）いずれかの前記データベースサーバが前記修復処理を実行している間に、前記複数のデータベースサーバそれぞれに対して、外部から操作が要求されているかどうかを判定するステップと、
（ｄ）前記（ｃ）のステップで、外部から前記操作が要求されていると判定された場合に、前記修復処理を実行していない前記データベースサーバに、要求のあった前記処理を実行させるステップとを、
更に前記コンピュータに実行させる請求項１１に記載のプログラム。
【請求項１３】
前記（ｄ）のステップにおいて、
前記外部からの操作要求として、前記複数のデータベースサーバの更新が要求された場合に、
前記修復処理を実行してない前記データベースサーバに対しては、前記更新を実行させ、前記修復処理を実行している前記データベースサーバに対しては、前記不要領域修復管理部の指示に応じて、前記修復処理の終了後に、前記更新を実行させる、請求項１２に記載のプログラム。
【請求項１４】
（ｅ）前記外部からの操作要求の要求量または要求件数が、設定された閾値を超えているか、又は前記閾値以上となっているかどうかを判定する、ステップと、
（ｆ）前記（ｅ）のステップで前記閾値を超えている、又は前記閾値上となっていると判定された場合に、前記修復処理を実行している前記データベースサーバに対して、前記修復処理を中断させる、ステップとを、
更に前記コンピュータに実行させる、請求項１２または１３に記載のプログラム。
【請求項１５】
（ｇ）前記更新の実行が終了した前記データベースサーバに対して、前記更新の内容を含むジャーナルを、前記更新を実行していない前記データベースサーバに向けて送信させる、ステップを更に前記コンピュータに実行させ、
前記（ｄ）のステップにおいて、前記更新を実行していない前記データベースサーバに対して、前記ジャーナルを用いて前記更新を実行させる、
請求項１３に記載のプログラム。
【図１】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【図２】
【図３】
【図４】
【図５】
【図６】
【図７】
【図８】
【図９】
【公開番号】特開２０１０−２１８１５９（Ｐ２０１０−２１８１５９Ａ）
【公開日】平成２２年９月３０日（２０１０．９．３０）
【国際特許分類】
【出願番号】特願２００９−６３３８１（Ｐ２００９−６３３８１）
【出願日】平成２１年３月１６日（２００９．３．１６）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
【公開日】平成２２年９月３０日（２０１０．９．３０）
【国際特許分類】
【出願日】平成２１年３月１６日（２００９．３．１６）
【出願人】（０００００４２３７）日本電気株式会社 (19,353)
【Ｆターム（参考）】
[ Back to top ]