JP4572581B2 - データベース処理方法およびシステム並びにその処理プログラム - Google Patents

Description

本発明はデータ処理技術に関し、系切り替え機能を有するデータベース管理システム（ＤＢＭＳ）に適用して有効な技術に関するものである。

サービスの停止が重大なビジネスチャンスの喪失に直結するネットビジネスの世界では、２４時間３６５日稼動し続ける堅牢性を備えたシステムが求められる。その中でも特に、障害発生時の影響の局所化と迅速なシステム回復が重要である。従来より、データベース（ＤＢ）システムでは、障害発生時の迅速なシステム回復のために、サービス実行用の実行系マシンとは別に待機系マシンと用意し、障害発生時に待機系マシンにサービスの実行を切り替える「系切り替え」という技術が用いられてきた。
例えば、非特許文献１（Jim Gray and Andreas Reuter:"TRANSACTION PROCESSING:CONCEPTS AND TECHNIQUES"，Morgan Kaufmann Publishers, 1993）は、ＨＡ(High Availability)システム構成によるＤＢ障害対策としてホットスタンバイ無停止運用について開示している。

一方、非特許文献２（"Parallel Database Systems :The Future of High Performance Database Systems",COMMUNICATIONS OF THE ACM, Vol.35, No.6, 1992, P.85-P.98）には、データベースの処理負荷を複数のプロセッサに分散させ並列に実行するアーキテクチャが開示されている。上記従来技術に記載のShared Everything, Shared Disk（共用型）アーキテクチャでは、ＤＢ処理を実行する全ての計算機が全てのデータをアクセスすることが可能であり、Shared Nothing（非共用型）アーキテクチャでは、自計算機に接続されたディスクに格納されたデータのみアクセス可能である。

Shared Nothing（非共用型）アーキテクチャは、共用型アーキテクチャにくらべ、ＤＢ処理を実行する構成単位の間での共有リソースが少なく、スケーラビリティの点で非常に優れている。Shared Nothing（非共用型）アーキテクチャにおいても、高可用性を提供するために系切り替えの技術を用いることが多い。

非特許文献３（Aslam Nomani:"Implementing IBM DB2 Universal Database V8.1 Enterprise Server Edition with Microsoft Cluster Server", International Business Machines Corporation, 2003）には、各マシンに複数のＤＢ格納領域を配置したデータベース管理システムにおいてＤＢ格納領域を切り替え単位とする系切り替え方式（負荷分散型系切り替え方式）が開示されている。ＤＢ格納領域ごとに実行系と待機系を定義し、通常時は実行系が当該ＤＢ格納領域にアクセスし、障害発生時には待機系が当該ＤＢ格納領域にアクセスすることでサービスを継続する。この方式では、同一マシンに属する複数のＤＢ格納領域に関して、別々のマシンに分散して待機系を定義する。１つのマシンで障害が発生した場合に、当該マシン中に属する複数のＤＢ格納領域は別々のマシンに引き継がれる。これにより、系切り替え後の処理実行負荷を複数マシンに分散し、システム全体のスループット低下を軽減することができる。

Jim Gray and Andreas Reuter:"TRANSACTION PROCESSING:CONCEPTS AND TECHNIQUES"，Morgan Kaufmann Publishers, 1993 David Dewitt and Jim Gray:"Parallel Database Systems :The Future of High Performance Database Systems", COMMUNICATIONS OF THE ACM, Vol.35, No.6, 1992 Aslam Nomani:"Implementing IBM DB2 Universal Database V8.1 Enterprise Server Edition with Microsoft Cluster Server", International Business Machines Corporation, 2003

しかし、系切り替えでは、実行系マシンとは別に待機系マシンとを用意しなければならず、通常サービス実行時には待機系マシンは遊んでいる状態である。また、系切り替えでも「相互待機」という形態で、待機系マシンにも通常のサービス実行を割り当てることもできるが、切り替え時のシステム回復の高速化を図るために、待機系でのシステム立上げをあらかじめ途中まで行っておく(「ウォームスタンバイ」、「ホットスタンバイ」)ことが多く、待機系システムのリソース(プロセスやメモリなど)を余分に用意しなければならない。

上記のような通常時未稼動状態である待機専用のリソースを必要とするシステムにおいては通常時にリソースを有効に利用できておらず、システム構築・運用におけるTCO(Total Cost of Ownership)削減の観点で問題である。さらにまた、ある稼動状態のマシンに障害が発生し、系切り替えにより他の稼動中マシンにフェイルオーバしても、切り替え先マシンに処理負荷が集中(通常片寄せされていない場合の負荷が２倍になることもありうる)し、システム全体としての処理性能が劣化してしまう。

本発明の目的は、前述のような通常時未稼動状態である待機専用のリソースを抑えることにある。他の目的は、障害発生時の系切り替え後におけるシステム全体の処理性能劣化や負荷のアンバランスを改善することにある。

上記目的を達成するために、Shared Nothing(非共用型)アーキテクチャを用いたデータベース管理システムにおいて、障害発生時に稼動中ユニットに切り替える手段を提供するようにしたものである。かつ、障害が発生したユニットに含まれる複数のサーバ(ＤＢＭＳにおけるＤＢアクセス機能を提供する論理コンポーネント)を複数の稼動中ユニットに分散するように切り替える手段を提供するようにしたものである。その手段においては、切り替え先ユニットに対して、切り替え対象のサーバを構成上追加する機能、および切り替え対象のサーバを起動し、当該サーバがアクセスを担当するＤＢ格納領域に対するＤＢ回復処理および当該サーバが障害にあった際に実行中であった処理に関してトランザクション回復を施す機能を有するものである。さらに、障害発生時の系切り替え後にシステム全体の処理性能の安定化を図るために、障害発生時のサーバ移動先(系切り替え先ユニット)を決定する方法について、予めユーザが指定したサーバ移動先にしたがいサーバ移動先を決定する機能、予めユーザが指定した指針(ポリシー)に従いシステムが内部にて静的にサーバ移動先を決定する機能、もしくは予めユーザが指定した指針(ポリシー)にしたがいＤＢＭＳが障害発生の際に動的にサーバ移動先を決定する機能を備えたものである。

本発明によれば、待機専用のリソースを削減することが可能となる。

以下、本発明を実施するための最良の形態について図面を用いて具体的に説明する。

まず、図１を用いて本発明の概念を簡単に説明する。

本実施例のデータベース管理システムは、処理要求受付サーバ（ＦＥＳ：Ｆｒｏｎｔ Ｅｎｄ Ｓｅｒｖｅｒ）１０およびＤＢアクセスサーバ（ＢＥＳ：Ｂａｃｋ Ｅｎｄ Ｓｅｒｖｅｒ）２０を具備する。ＤＢアクセスサーバはＤＢ処理サーバとも言う。ここでのサーバとはデータベース管理システム内の論理的な機能コンポーネントであり、物理的なマシンすなわち情報処理装置のことを指しているわけではない。本例での各種のサーバは、プログラムやオブジェクト、プロセス、スレッドにより実現されるものである。

処理要求受付サーバ（ＦＥＳ）１０は、ユーザからの問合せ７０を受け付け解析し、ＤＢアクセス要求を生成し、ＤＢアクセスサーバへＤＢアクセス要求を行う。そしてＤＢアクセスの結果を必要に応じてユーザに返す。ＤＢアクセスサーバ（ＢＥＳ）２０は、処理要求受付サーバ１０からのＤＢアクセス要求を受け取り、要求にしたがってＤＢ格納領域上のデータを操作し、必要に応じて結果を処理要求受付サーバに返す。ＦＥＳ１０およびＢＥＳ２０とも１つもしくは複数のプロセスまたはスレッドによって実現される。

本実施例のデータベース管理システムのアーキテクチャは、Shared Nothing(非共用型)アーキテクチャであり、本システムが管理するデータベース(例えばテーブル、インデクス)は、さまざまな手法により複数の分割テーブルおよび分割インデクスに分割され、複数のＤＢ格納領域に分散格納される。あるＤＢ格納領域は決まったＤＢアクセスサーバに対応付けられており、ＤＢアクセスサーバは、そのＤＢアクセスサーバに対応付けられたＤＢ格納領域内のデータ(例えばテーブルデータ、インデクスデータ)のみをアクセスする。

図１の例では、通常、ＢＥＳ１は、ＤＢ格納領域１へのアクセス要求のみを、ＢＥＳ２は、ＤＢ格納領域２へのアクセス要求のみを処理する。また、同様に、ＢＥＳ３は、ＤＢ格納領域３へのアクセス要求のみを、ＢＥＳ４は、ＤＢ格納領域４へのアクセス要求のみを、そしてＢＥＳ５は、ＤＢ格納領域５へのアクセス要求のみを処理する。ＢＥＳ１、ＢＥＳ２、ＢＥＳ３、ＢＥＳ４およびＢＥＳ５は同じＤＢ格納領域をアクセスすることはない。あるＤＢ格納領域に対するアクセス要求をどのＢＥＳが処理するかは、後述するサーバ−ＤＢ格納領域担当情報５０によってシステム内で静的に決定する。

通常時、ＢＥＳ１、ＢＥＳ２、ＢＥＳ３、ＢＥＳ４およびＢＥＳ５とも稼動状態であり、すべてのリソース（ＤＢアクセスサーバを実現するプロセス、メモリ等）が有効に活用されている。

ここで、例えば情報処理装置３２００に電源等の障害が発生し、ＢＥＳ１、ＢＥＳ２およびＢＥＳ３を有するＤＢＭＳ２(unit2)がダウンした場合、他の稼動中のＤＢＭＳユニット(本例ではunit1およびunit3)にBESごとに処理を引き継いでサービスを続行する。すなわち、稼動中ユニットunit1へと障害対象のＢＥＳ１およびＢＥＳ２が移動する。同様に、稼動中ユニットunit3へと障害対象のＢＥＳ３が移動する。

具体的には、ユニットunit2に障害が発生したことをユニットunit1と同一の情報処理装置上に配置されている系監視・系切り替え制御機構５およびユニットunit3を同一の情報処理装置上に配置されている系監視・系切り替え制御機構５が検知し、ＢＥＳ１、ＢＥＳ２、ＢＥＳ３おのおののＢＥＳに関して以下で述べる系切り替えを実行制御する。以降ＢＥＳ１の系切り替えを例に説明する。

まず、ＢＥＳ１の障害を検知した系監視・系切り替え制御機構５では、障害対象のＢＥＳ１のサーバ移動先（系切り替え先）のユニットを障害時のサーバ移動先情報３０により決定する（７０３）。ここではユニットunit1に決定したとしよう。その場合、ＢＥＳ１がアクセスを担当しているＤＢ格納領域１（６１）が格納されている共用ディスク装置（６０）の切り替えを行い、ユニットunit1が配置されている情報処理装置からアクセスができるような状態にする（７０４）。そして、ＤＢＭＳ２（ユニットunit1）に対して系切り替え連絡をＢＥＳ１指定により行う（７０５）。

系監視・系切り替え制御機構５からの連絡を受けたＤＢＭＳ２（ユニットunit1）は、まず、ユニットunit1に切り替え対象のBES1を追加するため構成情報を変更する（７１２）。次にユニットunit1にBES1を追加した旨を他の情報処理装置に配置されている他のユニットに対して通知する。そして、切り替え対象であるＢＥＳ１の起動（開始）を行う（７１４）。起動処理の延長で、ＤＢ格納領域１に対するＤＢ回復処理を行う。

以上のサーバ単位の系切り替え処理は、稼動中の系切り替え先のユニットにおいて稼動していた他のＢＥＳ（ＢＥＳ４）の処理には影響を与えない。他の障害対象サーバＢＥＳ２、ＢＥＳ３もＢＥＳ１と同様にサーバ単位に稼動中ユニット（それぞれユニットunit1、ユニットunit3）に、おのおの独立に切り替えを実行する。

ここで、切り替え後にユーザ(すなわちアプリケーションプログラム)からの問合せ要求７０を受け取ったＦＥＳ（１０）は、問合せ要求を解析し、アクセスするデータが存在するＤＢ格納領域を決定する。決定されたＤＢ格納領域へのアクセスを担当するＤＢアクセスサーバが現在(系切り替え後)稼動中であるユニットに対してＤＢアクセス要求８０を送信する。

要求された稼動中ユニットは、受け取ったＤＢアクセス処理を指定サーバ(ＢＥＳ１)で実行し、ＤＢ格納領域１をアクセスして要求されたデータ操作を行う。本例では、データベース６０内のＤＢ格納領域１（６１）に格納されたテーブルデータ（６２）の"12"を実行結果として、ＦＥＳに送信する。送信されたテーブルデータは問合せ結果としてＦＥＳ（１０）によってユーザに返却される。すなわち、障害発生前からユニットunit1で稼動しているＢＥＳ４と全く同じ処理で障害対象のＢＥＳ１へのＤＢアクセス処理要求を実現することができる。

本例でも分かるように、障害対象のユニットunit2で稼動していたＢＥＳ１、ＢＥＳ２、ＢＥＳ３がすべてある１つの特定ユニットへ切り替わるわけではないため、障害発生後の負荷分散が図られ、切り替え先（移動先）の指定により、切り替え後のシステム全体の処理性能劣化を最小限に抑えることも可能である。ここでは、切り替え先である稼動中ユニットに対するトランザクション到着率を負荷として考えると、ユニットunit1で対切り替え前300％、ユニットunit3で対切り替え前200%。特定１ユニットとしてユニットunit1もしくはユニットunit3を想定した場合の400%に比べ１ユニットに着目した場合でも負荷分散の効果が伺える。ユニットunit1およびユニットunit3に関しては実システムではユニットunit2と同等のＢＥＳを通常時より配置および稼動されるのがシステム設計上望ましく、その場合３つのＢＥＳが稼動中の状態に１つのＢＥＳが切り替わって（移動して）くるため対切り替え前133%となる。

ここでの障害時のサーバ移動先情報３０は、ＤＢＭＳの管理者などのユーザによりあらかじめＤＢＭＳに登録されているものとして記述しているが、ＤＢＭＳが内部で自動生成することにより管理者の負担を低減することができる。その場合、システム内のユニット数に対し全てBESの数が均等になるように割り振るなどが考えられる。管理者の負担軽減のためにもちろん障害時のサーバ移動先情報３０をシステムのサーバ−ユニット構成情報等を入力としたツールにより生成してもよい。

また、障害発生時に動的にサーバ移動先ユニットを決定してもよい。その場合、サーバ移動先を決定するための指針(ポリシー)９０をあらかじめＤＢＭＳの管理者などが指定しておくことが考えられる。サーバ移動先を決定するための指針(ポリシー)として、例えば以下のようなものが挙げられる。
（１）ＣＰＵ利用率、トランザクション到着率、ディスクアクセス率等の負荷の軽い稼動中ユニットをサーバ移動先(切り替え先)を選定する。
（２）メモリ等のリソースに空きがある稼動中ユニットをサーバ移動先(切り替え先)を選定する。
（３）複数稼動中ユニットを切り替えＢＥＳが数的に均等になるようにサーバ移動先(切り替え先)を割り振る。

上記（１）、（２）および（３）に挙げられた負荷、リソースの空き等の情報を稼動情報１００としてＤＢＭＳ内に蓄積し、系切り替え時に参照する。

以上のように、障害発生時に、障害対象のユニットに含まれる複数のＤＢアクセスサーバ（ＢＥＳ）をサーバごとに複数の稼動中ユニットに分散されて切り替えることにより、障害発生時の系切り替え後、システム全体の処理性能劣化を最小限に抑えることが可能となる。

ここでは、ＦＥＳとＢＥＳとを別々の情報処理装置上に配置したが、同一の情報処理装置上に配置することによりハードウェア資源の有効活用が可能である。また、本実施例で示したＦＥＳの機能およびＢＥＳの機能を１つのＤＢサーバとして実装することにより、データベース管理システムの管理者は、ＦＥＳとＢＥＳとを意識して管理する必要がなくなり、管理コストを低減することができる。本例における切替先のDBサーバは、サーバ移動先情報３０が設定されたときにユニットで実行可能な状態で待機させてもよい。

次に図２を用いて、本実施形態のデータベース管理システムの概略構成を説明する。

ユーザが作成したアプリケーションプログラム６と、問い合わせ処理やリソース管理などのデータベースシステム全体の管理を行うデータベース管理システム２がある。上記のデータベース管理システム２は、処理要求受付サーバ（ＦＥＳ）１０、ＤＢアクセスサーバ（ＢＥＳ）２０を具備する。また、データベース管理システム２はデータベースバッファ２３０を具備し、データベースアクセス対象となるデータを永続的にあるいは一時的に格納するデータベース３、そして障害時のサーバ移動先情報３０、サーバ−ユニット構成情報４０、サーバ−ＤＢ格納領域担当情報５０、系切り替え先決定指針９０および稼動情報１００を有する。

処理要求受付サーバ（ＦＥＳ）１０は、アプリケーションプログラム６から投入される問合せを受け付け解析し、ＤＢアクセス要求を生成し、ＤＢアクセスサーバへＤＢアクセス要求を行う。そしてＤＢアクセスの結果を必要に応じてアプリケーションプログラム６に返す。ＤＢアクセスサーバ（ＢＥＳ）２０は、処理要求受付サーバ１０からのＤＢアクセス要求を受け取り、要求にしたがって外部記憶装置上に記憶されるデータベース３に対しデータベースバッファ２３０を通じてアクセスする。先に図１において説明した系切り替え対象のＤＢアクセスサーバのＤＢアクセス処理では、もともと切り替え先ユニットで稼動していたＢＥＳが使用しているものと同じデータベースバッファを利用することもありうる。すなわち、もともとのＢＥＳと系切り替えにより移ってきたＢＥＳとではデータベースバッファを共用する。

上記データベース管理システム２はネットワークなどを介して他のシステムと接続されている。また、処理要求受け付けサーバ（ＦＥＳ）１０およびＤＢアクセスサーバ（ＢＥＳ）２０は必ずしも同一の情報処理装置上に配置される必要はない。それぞれ別々の情報処理装置上に配置され、ネットワーク等を介して１つのデータベース管理システムとして機能すればよい。また、１つのデータベース管理システムは複数のＦＥＳを配置することにより多量のユーザからの要求の負荷を分散させることができる。また、複数のＢＥＳを有することによりデータ処理の並列度が高まり、大規模なデータベースに対するデータ処理も高速に実現することができる。以降、１情報処理装置に配置されるFESもしくはBESを具備したデータベース管理システムの単位をユニットもしくはインスタンスと呼ぶことにする。

上記処理要求受付サーバ１０は、問合せの構文解析・意味解析を行い、適切な処理手順を決定し、その処理手順に対応したコードを生成し、ＤＢアクセスサーバ２０に対しＤＢアクセス要求を行う処理要求制御部２１１を具備している。

上記ＤＢアクセスサーバ２０は、処理要求受付サーバ１０から受け取ったＤＢアクセス要求（生成したコード）にしたがってデータベース３上のデータのアクセス制御等を行うデータ処理制御部２２１を具備している。

また、上記ＤＢアクセスサーバ２０は、他の情報処理装置もしくは他の情報処理装置に配置されたユニットに障害が発生した場合、系管理および系切り替え機能５と連携し、系切り替え要求を受け取りサーバ単位の系切り替え処理を起動する系監視・系切り替え機構連携部２２２、２２２から要請を障害対象の指定サーバの系切り替え処理を制御するサーバ単位系切り替え処理部２２３、２２３制御の下で切り替え処理の一部として切り替え対象サーバの当該ユニットへの構成上の追加を行うサーバ−ユニット構成情報管理部２２４、さらに切り替えサーバを起動し当該サーバがアクセスを担当しているＤＢ格納領域ほかの回復を行い、実行中だった処理の更新結果を取り消すトランザクション回復を制御するサーバ起動制御部２２５を具備する。サーバ−ユニット構成情報管理部２２４は、前述の処理受付サーバ１０にも具備される。

図３は本実施形態におけるコンピュータシステムのハードウエア構成の一例を示す図である。この例のコンピュータシステムは、情報処理装置３０００、３１００および３２００を含む。

情報処理装置３０００は、ＣＰＵ３００２、主記憶装置３００１、通信制御装置３００３、Ｉ／Ｏ制御装置３００４及び端末３００６により構成される。主記憶装置３００１上には、アプリケーションプログラム３００８が置かれ、ＣＰＵ３００２を用いて稼動している。アプリケーションプログラム３００８がＤＢＭＳ２の処理要求受付サーバ１０にユーザ問合せを行うと、情報処理装置３０００の通信制御装置３００３と情報処理装置３１００の通信制御装置３００３によって、ネットワーク３００７を経由して処理要求受付サーバ１０に問合せ要求が送られる。

情報処理装置３１００は、ＣＰＵ３００２、主記憶装置３００１、通信制御装置３００３、Ｉ／Ｏ制御装置３００４、磁気ディスク装置等の外部記憶装置３００５及び端末３００６により構成される。情報処理装置３１００の主記憶装置３００１上には、図２を用いて先に説明した処理要求受付サーバ１０を有するデータベース管理システム２が置かれ、ＣＰＵ３００２を用いて稼動している。外部記憶装置３００５上にはデータベース管理システム３が管理するデータベース３が格納される。また、データベース管理システム２を実現するプログラム３１００も外部記憶装置３００３上に格納される。処理要求受付サーバ１０は、Ｉ／Ｏ制御装置装置３００４により外部記憶装置３００５からデータの読み出し/書き込みを行い、通信制御装置３００３によりネットワーク３００７で接続された他の情報処理装置とデータの送受信を行う。

情報処理装置３２００は、ＣＰＵ３００２、主記憶装置３００１、通信制御装置３００３、Ｉ／Ｏ制御装置３００４、磁気ディスク装置等の外部記憶装置３００５及び端末３００６により構成される。情報処理装置３２００の主記憶装置３００１上には、図２を用いて先に説明したＤＢアクセスサーバ２０を有するデータベース管理システム２が置かれ、ＣＰＵ３００２を用いて稼動している。外部記憶装置３００５上にはデータベース管理システム３が管理するデータベース３が格納される。また、データベース管理システム２を実現するプログラム３１００も外部記憶装置３００３上に格納される。ＤＢアクセスサーバ２０は、Ｉ／Ｏ制御装置装置３００４により外部記憶装置３００５からデータの読み出し/書き込みを行い、通信制御装置３００３によりネットワーク３００７で接続された他の情報処理装置とデータの送受信を行う。

ここで、２つの情報処理装置３２００にまずそれぞれ関連付けられたデータベース３が格納された外部記憶装置３００５は、共用ディスクであり、他方の情報処理装置からのアクセスも可能である。データベース管理システム２の稼動状況の監視(系の監視)および種々の障害発生にともなう系切り替え操作を制御する系監視・系切り替え制御機構５(クラスタウエアと呼ぶこともある)により、上記共用ディスクのアクセス制御は行われる。

図４は本実施形態のサーバ−ＤＢ格納領域担当情報の一例を示す図である。

図４の例では、サーバ−ＤＢ格納領域担当情報５０は、ＤＢ格納領域を示すＤＢ格納領域名（４０１）と、そのＤＢ格納領域名（４０１）で識別されるＤＢ格納領域へのアクセスを担当するＤＢアクセスサーバのサーバ名（４０２）より構成される。情報エントリ４１１は、ＤＢ格納領域１はＢＥＳ１がそのアクセスを担当することを示している。同様に、情報エントリ４１２はＤＢ格納領域２へのアクセス担当をＢＥＳ２が、情報エントリ４１３はＤＢ格納領域３へのアクセス担当をＢＥＳ３が行うことをそれぞれ示している。本情報は、系切り替えをまたがって変更されることはない静的はシステム構成情報である。

図５は本実施形態における障害時のサーバ移動先情報の一例を示す図である。

図５の例では、障害時のサーバ移動先情報３０は、ＤＢアクセスサーバを示すサーバ名（５０１）と、そのＤＢアクセスサーバで識別されるサーバに障害が発生した場合に、系切り替え先となるユニットのユニット名（５０２）より構成される。情報エントリ５１１は、障害発生時ＢＥＳ１はユニットunit1へ切り替わる、すなわちユニットunit1に配置されたＢＥＳ１として処理を引き継ぎ、サービスを続行することを示す。同様に、情報エントリ５１２はＢＥＳ２が障害時にユニットunit1へ切り替わることを、情報エントリ５１３はＢＥＳ３が障害時にユニットunit3へ切り替わることをそれぞれ示している。本情報はシステム起動時にあらかじめＤＢＭＳ管理者が指定することもありうるし、またシステムが自動的にシステム内部で生成することもありうる。その場合、あらかじめユーザによりサーバ切り替え先を決定するための指針（ポリシー）９０が設定される。その指針（ポリシー）の例としては、
（１）あるユニット内に含まれる全てのＤＢアクセスサーバを全て別々のユニットに切り替えるように生成する
（２）複数のある特定ユニット間に均等にＤＢアクセスサーバが切り替わるように生成するなどが挙げられる。

障害時のサーバ移動先情報３０は、ＤＢＭＳが稼動する情報処理装置上のメモリに配置され容易にＤＢＭＳからアクセスされるよう実装されることが多い。またさらに本例では、ＢＥＳ１、ＢＥＳ２、ＢＥＳ３とも情報エントリが１つずつしか記載していないが、それぞれ複数エントリを有すること、すなわち切り替え先ユニットが複数存在することも可能であり、障害発生時のユニット稼動情報と、それら複数の切り替え先ユニットとしての優先度から切り替え先を決定すればよい。

図６は本実施形態のサーバ−ユニット構成情報の一例を示す図であり、上側の６１１から６１５まではユニットunit2の障害が発生する前の情報を、下側の６２１から６２５まではユニットunit2に障害が発生し系切り替えが行われた後の情報を示している。

図６の例では、サーバ−ユニット構成情報４０は、ＤＢアクセスサーバを示すサーバ名（６０１）と、そのＤＢアクセスサーバが構成上配置されるユニットのユニット名（６０２）より構成される。情報エントリ６１１および情報エントリ６２１、情報エントリ６１２および情報エントリ６２２、そして情報エントリ６１３および情報エントリ６２３に示すように、通常時ユニットunit2に配置され稼動していたＢＥＳ１、ＢＥＳ２そしてＢＥＳ３は、ユニットunit2障害発生に伴う系切り替えによって、ＢＥＳ１およびＢＥＳ２はユニットunit1へ、ＢＥＳ３はユニットunit3へと構成が変更となっている。

図７および図８は、本実施形態の系監視・系切り替え制御機構および切り替え先のユニットでの、障害発生時の系切り替え処理の手順を示すフローチャートである。図７は系監視・系切り替え制御機構での、図８は切り替え先のユニットでの処理の手順をそれぞれ示すフローチャートである。

まず、系監視・系切り替え制御機構５では、ステップ７０１において他ユニットの障害発生を検知し、ステップ７０２において、障害時のサーバ移動先情報を取得する。そして取得した障害時のサーバ移動先情報を元に、サーバ移動先すなわち系切り先ユニットを決定する（ステップ７０３）。当該ユニットが切り替え先として決定された場合（ステップ７０４）、ステップ７０５に進み共用ディスクの切り替えを行う。さらにステップ７０６においてＤＢＭＳに対して障害発生サーバ（切り替え対象サーバ）を指定し、系切り替え連絡を行う。また、ステップ７０４において、当該ユニットが切り替え先として決定されたかった場合、そのままステップ７０７へ進み処理を終了する。

系監視・系切り替え制御機構５からステップ８０１において系切り替え連絡を受けたユニット（ＤＢＭＳ（２））は、ステップ８０２においてサーバ−ユニット構成情報を変更する。具体的には、指定された切り替え対象サーバの配置ユニットを当該ユニットに変更する。指定サーバが系切り替えにより当該ユニットに移動してくるからである。続いて、ステップ８０３において、当該ユニットに切り替え対象サーバを追加した旨を他の情報処理装置に配置されている他ユニットに対して通知する。そして、ステップ８０４において、切り替え対象のサーバの起動（開始）を行う。ステップ８０５において、切り替え対象サーバがアクセスを担当しているＤＢ格納領域に対するＤＢ回復処理および障害発生時に実行中だった処理の更新結果を取り消すトランザクション回復処理を行う。

図９は、本実施形態の障害発生時の系切り替え処理におけるサーバ移動先ユニット決定の処理手順を示すフローチャートである。

まず、ステップ９０１において障害時のサーバ移動先情報エントリをサーチし、障害対象サーバに関連する情報エントリを確定する。そして、ステップ９０２において、確定した情報エントリからサーバ移動先ユニットのユニット名を取得する。ここでステップ９０３において、取得したユニットが現在稼動中であり切り替え先として有効かどうかと判断する。取得したユニットが稼動中でない場合、ステップ９０１へ戻り別の切り替え先ユニットを探す。ここで取得したユニットが稼動中である場合、ステップ９０４に進み、取得したユニットをサーバ移動先に決定する。

図１０は、さらに別な実施形態の障害発生時の系切り替え処理において、サーバ移動先ユニット決定の処理手順を示すフローチャートである。ここでは障害発生時に動的にサーバ移動先ユニットを決定する処理手順について示す。サーバ移動先を決定するための指針（ポリシー）９０はあらかじめＤＢＭＳの管理者などにより指定され、指定された情報はＤＢＭＳ内に保持されている。

まず、ステップ１００１において、切り替え先を決定するための指針（ポリシー）を取得する。そして、ステップ１００２において取得した指針（ポリシー）を判断し、その判断結果に基づき切り替え先を決定する。本例では３つの指針（ポリシー）について示している。

まず、ステップ１００２においてポリシーが「負荷の軽いユニット」である場合、ステップ１０１１に進み、自ユニットの負荷情報を取得する。負荷情報の例としては、ＣＰＵ利用率、トランザクション到着率、ディスクアクセス率等が挙げられる。さらに、ステップ１０１２において他稼動中ユニットの負荷情報も収集し、ステップ１０１３において、自ユニットと他ユニットの負荷状況を比較する。ステップ１０１３において自ユニットの負荷が他ユニットの負荷よりも軽かった場合、ステップ１００３に進み自ユニットを切り替え先に決定する。ステップ１０１３において自ユニットの負荷が他ユニットに比べ重い場合、ステップ１００４に進み、自ユニットを切り替え先としては決定しない。

２つ目のポリシーとして、ステップ１００２においてポリシーが「リソースに空きのあるユニット」である場合、ステップ１０２１に進み、自ユニットのリソース(メモリやサーバに関連する情報を管理する制御ブロックなど)の空き状況を取得する。さらに、ステップ１０２２において他稼動中ユニット内のリソースの空き状況も取得し、ステップ１０２３において自ユニットと他ユニットのリソースの空き状況を比較する。ステップ１０２３において自ユニットのリソースが他ユニットのそれよりも多かった場合、ステップ１００３に進み自ユニットを切り替え先に決定する。ステップ１０１３において自ユニットのリソースが他ユニットに比べ少なかった場合、ステップ１００４に進み、自ユニットを切り替え先としては決定しない。

３つ目のポリシーとして、ステップ１００２においてポリシーが「複数の稼動中ユニットへ均等に切り替える」である場合、ステップ１０３１に進み、他ユニットの稼動情報を取得する。取得した稼動中ユニットの数により自ユニットは切り替え先がどうかを判断し、特に切り替え先として不適切ではない場合、ステップ１００３に進み自ユニットを切り替え先に決定する。他稼動中ユニットおよび切り替え対象となっているサーバの数等により自ユニットは切り明け先ではない場合には、ステップ１００４に進み、自ユニットを切り替え先としては決定しない。

図１１は、本実施形態の処理要求制御部での障害発生時切り替え処理後のユーザ問合せ処理の手順を示すフローチャートである。

まず、ステップ１１０１においてユーザ問合せを受け付け解析し、ステップ１１０２において、ユーザ問合せを実現するためにアクセスするＤＢ格納領域を特定する。続いて、ステップ１１０３において、サーバ−ＤＢ格納領域担当情報をサーチし、特定したＤＢ格納領域へのアクセスを担当しているサーバ（ＢＥＳ）を特定する（ステップ１１０４）。
そして、ステップ１１０５において、サーバ−ユニット構成情報をサーチし、特定したサーバ（ＢＥＳ）が稼動しているユニットを特定する（ステップ１１０６）。ここで特定したユニットの先に特定したサーバに対してＤＢアクセス要求を送信する（ステップ１１０７）。最終的に送信先からＤＢアクセスの結果を受け取り（ステップ１１０８）、ユーザ問合せ結果として返却する（ステップ１１０９）。

なお図７、図８、図９、図１０および図１１で示したフローチャートの処理は、図３で例として示したコンピュータシステムにおけるプログラムとして実行される。しかし、そのプログラムは図３の例の様にコンピュータシステムに物理的に直接接続される外部記憶装置に格納されるものと限定はしない。ハードディスク装置、フレキシブルディスク装置等のコンピュータで読み書きできる記憶媒体に格納することができる。また、ネットワークを介して図３のコンピュータシステムを構成する情報処理装置とは別の情報処理装置に接続される外部記憶装置に格納することもできる。

以上によれば、Shared Nothing(非共用型)アーキテクチャを用いたデータベース管理システムにおいて、障害の発生に備えて待機専用のリソース(マシン、DBMSインスタンス)を有することなく、障害発生時の系切り替え後においても、システム全体の処理性能劣化を最小限に抑えることができ、安定性能を維持することが可能となる。

本発明の概念図である。 本実施形態のデータベース処理システムの機能ブロックを示す図である。 本実施形態におけるコンピュータシステムのハードウエア構成の一例を示す図である。 本実施形態のサーバ−ＤＢ格納領域担当情報の一例を示す図である。 本実施形態における障害時のサーバ移動先情報の一例を示す図である。 本実施形態のサーバ−ユニット構成情報の一例を示す図である。 本実施形態の系監視・系切り替え制御機構での障害発生時の系切り替え処理の手順を示すフローチャートである。 本実施形態の切り替え先のユニットでの障害発生時の系切り替え処理の手順を示すフローチャートである。 本実施形態の障害発生時の系切り替え処理におけるサーバ移動先ユニット決定の処理手順を示すフローチャートである。 さらに別の実施形態における障害発生時の系切り替え処理におけるサーバ移動先ユニット決定の処理手順を示すフローチャートである。 本実施形態の処理要求制御部での障害発生時切り替え処理後のユーザ問合せ処理の手順を示すフローチャートである。

符号の説明

２…データベース管理システム、５…系監視・系切り替え制御機構、２０…ＤＢアクセスサーバ、３０…障害時のサーバ移動先情報、４０…サーバ−ユニット構成情報、５０…サーバ−ＤＢ格納領域担当情報、６０…データベース、９０…系切り替え先決定指針、１００…稼動情報。

Claims (5)

1. データベース処理プログラムを有するデータベース処理装置を複数備え、複数の格納領域にデータベースを分割して格納し、該格納領域のそれぞれに割当てられたデータベース処理プログラムの実行によりデータベース処理を行なうデータベース管理システムにおけるデータベース管理方法において、
   前記データベース処理装置に障害が発生したことを前記障害が発生していないデータベース処理装置が有する検知手段が検知した場合、稼動中の前記データベース処理装置のうち系切替え先となるデータベース処理装置を決定するステップと、
   前記系切替え先となるデータベース処理装置にて前記障害が発生したデータベース処理装置に割当てられた前記格納領域を前記系切替え先となるデータベース処理装置で稼動するデータベース処理プログラムに割当てるステップと、
   前記系切替え先となるデータベース処理装置におけるデータベース処理プログラムの開始処理を行うステップとを有し、
   前記開始処理を行った前記データベース処理プログラムは、切り替え先データベース処理装置に稼動していた他のデータベース処理プログラムに関連付けられたＤＢ格納領域として前記切り替え先データベース処理装置に備えられたデータベースバッファを利用することを特徴とすることを特徴とするデータベース処理方法。
2. 前記系切替え先となるデータベース処理装置におけるデータベース処理プログラムの開始処理を行うステップは、
   前記障害が発生したデータベース処理装置に関連付けられている該分割されたデータベース格納領域に対する回復を行うステップと、
   前記データベース処理装置が、障害が発生したことを検知した際に実行中であった処理を回復するステップと、を有することを特徴とする請求項１記載のデータベース処理方法。
3. 該記載の障害が発生したことを前記検知手段が検知した際に、該障害の影響を受けダウンした前記データベース処理装置の切替え先を決定するステップは、
   あらかじめユーザから与えられた指針を参照するステップと、
   前記参照結果が「負荷の軽いデータベース処理装置」の場合には、自データベース処理装置の負荷と他データベース処理装置の負荷とを比較し、自データベース処理装置の負荷の方が軽い場合に自データベース処理装置を切替え先に決定するステップと、
   前記参照結果が「リソースに空きのあるデータベース処理装置」の場合には、自データベース処理装置のメモリやメモリ上に配置される制御ブロック等であるリソースの空きと、他データベース処理装置のリソースの空きと、を比較し、自データベース処理装置のリソースの空きのほうが多い場合に自データベース処理装置を切替え先に決定するステップと、
   前記参照結果が「複数の稼動中データベース処理装置へ均等に切替える」の場合には、他データベース処理装置の稼動状況を取得し、稼動中データベース処理装置の数により自データベース処理装置を切替え先に決定するステップと、を含むことを特徴とする請求項１記載のデータベース処理方法。
4. データベース処理プログラムを有するデータベース処理装置を複数備え、複数の格納領域にデータベースを分割して格納し、該格納領域のそれぞれに割当てられたデータベース処理プログラムの実行によりデータベース処理を行なうデータベース管理システムにおいて、
   前記データベース処理装置に障害が発生したことを前記障害が発生していないデータベース処理装置が有する検知手段が検知した場合、稼動中の前記データベース処理装置のうち系切替え先となるデータベース処理装置を決定する手段と、
   前記系切替え先となるデータベース処理装置にて前記障害が発生したデータベース処理装置に割当てられた前記格納領域を前記系切替え先となるデータベース処理装置で稼動するデータベース処理プログラムに割当てる手段と、
   前記系切替え先となるデータベース処理装置におけるデータベース処理プログラムの開始処理を行う手段とを備え、
   前記開始処理を行った前記データベース処理プログラムは、切り替え先データベース処理装置に稼動していた他のデータベース処理プログラムに関連付けられたＤＢ格納領域として前記切り替え先データベース処理装置に備えられたデータベースバッファを利用することを特徴とすることを特徴とするデータベース処理システム。
5. データベース処理プログラムを有するデータベース処理装置を複数備え、複数の格納領域にデータベースを分割して格納し、該格納領域のそれぞれに割当てられたデータベース処理プログラムの実行によりデータベース処理を行なうデータベース管理システムにおけるデータベース管理方法を実現するためのデータベース管理プログラムにおいて、
   前記データベース処理装置に障害が発生したことを前記障害が発生していないデータベース処理装置が有する検知手段が検知した場合、稼動中の前記データベース処理装置のうち系切替え先となるデータベース処理装置を決定するステップと、
   前記系切替え先となるデータベース処理装置にて前記障害が発生したデータベース処理装置に割当てられた前記格納領域を前記系切替え先となるデータベース処理装置で稼動するデータベース処理プログラムに割当てるステップと、
   前記系切替え先となるデータベース処理装置におけるデータベース処理プログラムの開始処理を行うステップと、
   前記開始処理を行った前記データベース処理プログラムは、切り替え先データベース処理装置に稼動していた他のデータベース処理プログラムに関連付けられたＤＢ格納領域として前記切り替え先データベース処理装置に備えられたデータベースバッファを利用するステップと、を有することを特徴とするデータベース管理プログラム。

Images