JP4375121B2 - データベース管理システムにおける処理代行方法 - Google Patents

Description

本発明は、並列サーバ構成のデータベース管理システムにおけるデータ処理方法に係り、特に障害発生時のデータベース処理の代行方法に関する。

２４時間３６５日のシステム稼動が求められるノンストップビジネスでは、ビジネスを支えるデータ基盤として可用性の高いデータベース管理システムが必要とされている。また、ビジネスで扱うデータの量は増加傾向にあり、業務量・データ量の増加に応じたシステムの拡張もデータベース管理システムの重要な課題である。

データベース管理システムの可用性を向上する手段としては、系切り替えという技術が用いられている。系切り替えとは、障害が発生したマシンの処理を別のマシンに切り替えることでサービスを継続し、障害によるサービス停止時間を短縮する技術である。

系切り替えを適用したデータベース管理システムでは、処理を実行しているマシンごとに障害時の切り替え先となるマシンが定義される。ここで、処理を実行しているマシン上の実行環境を実行系、切り替え先のマシン上の実行環境を待機系という。また、システム開始時に実行系である実行環境を現用系、システム開始時に待機である実行環境を予備系という。系切り替えを適用したシステムでは、系切り替え機能が実行系の障害を検知すると待機系への系切り替えを開始する。系切り替えを開始すると、まず実行系のリソース、例えばデータベースを格納したディスク、ネットワークのアドレスなど、を待機系に切り替える。リソースの切り替えが完了すると、待機系において実行系から引き継いだデータベースに対するサービスの受け付けを開始して、系切り替えが完了する。この段階で、切り替え前に待機系であった実行環境が実行系となる。

この技術は、非特許文献１に説明されている。

一方、データベース管理システムの拡張性を重視する場合は、複数のサーバでシステムを構成し、各サーバがデータを並列に処理する方式をとる。その際に採用する並列処理アーキテクチャとして、Shared Nothingアーキテクチャがある。

Shared Nothingアーキテクチャとは、並列サーバ構成のシステムにおいてCPUやディスク、キャッシュをサーバ間で共有しない方式である。データを論理的なセグメントで分割してそれぞれ専用のＤＢ格納領域に格納し、各々のＤＢ格納領域には、対応する一つのサーバだけがアクセスする。この方式では、サーバ間でリソースが競合しないため、検索・更新などの処理を各サーバが一斉に行なうことができ、サーバ数に応じた処理性能を実現できる。つまり、サーバ台数を増やすことによりシステムの処理性能を向上させることができるため、業務量・データ量の増加がしても円滑に業務を遂行できる。

この技術は、非特許文献２に説明されている。

Shared Nothingアーキテクチャを採用したシステムにおいても、高可用性を提供するために系切り替えの技術を用いることが多い。

系切り替えでは、ＤＢ処理サーバごとに実行系と待機系を定義するのが一般的である。ＤＢ処理サーバごとに稼動状況を監視し、必要に応じて待機系に系切り替えを行なう。すなわち、系切り替えの単位はＤＢ処理サーバである。各ＤＢ処理サーバの待機系は、他のＤＢ処理サーバの実行系と同一のマシンとすることが多い。この場合、待機系となるマシンでは、系切り替え後には通常時の２倍の処理を実行することになる。

非特許文献３には、各マシンに複数のＤＢ格納領域を配置したデータベース管理システムにおいてＤＢ格納領域を切り替え単位とする系切り替え方法（負荷バランス型系切り替え）が開示されている。ＤＢ格納領域ごとに実行系と待機系を定義し、通常時は実行系が当該ＤＢ格納領域にアクセスし、障害発生時には待機系が当該ＤＢ格納領域にアクセスすることでサービスを継続する。

本方式では、同一マシンに属する複数のＤＢ格納領域に関しては、別々のマシンに分散して待機系を定義する。１つのマシンで障害が発生した場合には、当該マシン中に属する複数のＤＢ格納領域は別々のマシンに引き継がれる。これにより、系切り替え後の処理実行負荷を複数マシンに分散し、システム全体のスループット低下を軽減することができる。

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 Database Processing or a Passing Fad?", SIGMOD Record, Vol.19, No.4, pp. 104-112, 1990. Aslam Nomani:"Implementing IBM DB2 Universal Database V8.1 Enterprise Server Edition with Microsoft Cluster Server", International Business Machines Corporation, 2003

負荷バランス型系切り替えでは、ＤＢ格納領域単位に系切り替えを行なうため、ＤＢ処理サーバ単位の系切り替えに比べて待機系の数が多くなる。また、負荷バランス型系切り替えを採用したシステムでは、多重障害に備えて１つの実行系に対して複数の待機系を設定するのが一般的である。その場合、待機系の数は更に増加する。

非特許文献３には、系切り替えを適用したシステムを構築する場合には１つのマシン上で全ての系が実行系として動作することを想定してリソース（プロセスやメモリなど）を用意する必要があることが記載されている。従って、マシンに配置する待機系の数が多くなると、リソース所要量の増大につながり、システム構築コストが増大する。

また、待機系の数が増加するするとシステム内の管理対象の数が増えるため、システム管理コストとも増大する。

すなわち、従来の負荷バランス型系切り替え方法は、系切り替え後の負荷を複数のマシンに分散できるという利点はあるが、システム内に定義する待機系の数が増加するためにシステム構築コストおよびシステム管理コストが増大するという課題がある。

本発明の目的は、Shared Nothingアーキテクチャを用いたデータベース管理システムにおいて、待機系専用のリソースを必要とせず、かつ、待機系の管理を必要としない、負荷分散可能な系切り替え方法を提供することである。

本発明は、前記課題を以下の手段により解決する。

ＤＢ格納領域単位の系切り替えを適用したデータベース管理システムにおいて、ＤＢ格納領域と前記ＤＢ格納領域へのアクセスを担当するＤＢ処理サーバの対応関係を示す対応情報を持ち、あるＤＢ格納領域の切り替えが発生した際には当該ＤＢ格納領域へのアクセス処理を別の稼動中ＤＢ処理サーバが担当するように前記対応情報を更新し、ユーザからの問い合わせ要求を受けてあるＤＢ格納領域にアクセスする際には前記対応情報を参照してアクセス要求先となるＤＢ処理サーバを決定する。また、各ＤＢ処理サーバは、ＤＢ格納領域にアクセスする際の実行環境情報をもち、ＤＢ格納領域へのアクセス要求を受けた場合には、前記実行環境情報を参照してＤＢ処理サーバの実行環境を設定してＤＢ格納領域にアクセスする。

この方法により、ＤＢ格納領域単位の系切り替えにおいて、稼動中のＤＢ処理サーバを複数のＤＢ格納領域に対する待機系として使用することができるため、待機系用のリソースが不要となり、かつ、待機系の個別管理が不要になる。

本発明によれば、Shared Nothing方式のアーキテクチャを用いたデータベース管理システムにおいて、負荷分散可能な系切り替えを適用する際のリソース所要量と待機系管理コストを削減することができる。

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

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

本実施例に示すデータベース管理システムは、マシン０（１００）、マシン１（１０１）、マシン２（１０２）およびマシン３（１０３）という複数のマシンで構成されている。

マシン０（１００）では、処理要求受付サーバ（１１０）が稼動しいている。マシン１（１０１）、マシン２（１０２）およびマシン３（１０３）は、それぞれＤＢ処理サーバＡ（１１１）、ＤＢ処理サーバＢ（１１２）およびＤＢ処理サーバＣ（１１３）が稼動している。ここで、サーバとは、プロセス群、メモリ領域などから成るデータベース処理の実行環境を指す。

処理要求受付サーバは、ユーザからの問合せ（１３０）を受け付けて解析し、ＤＢ処理実行要求を生成し、ＤＢ処理サーバにＤＢ処理実行要求を行なう。そして、ＤＢ処理の結果を必要に応じてユーザに返す。

ＤＢ処理サーバは、処理要求受付サーバからのＤＢ処理実行要求を受け取り、要求に従ってＤＢ格納領域中のデータを操作し、必要に応じて実行結果を処理要求受付サーバに返す。

また、マシン１（１０１）、マシン２（１０２）およびマシン３（１０３）は、系切り替え機能（１１４）を具備している。系切り替え機能には、各ＤＢ格納領域を監視対象として登録することで、ＤＢ格納領域単位の系切り替えを実現する。

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

図１に示す例では、通常時、ＤＢ処理サーバＡ（１１１）にはＤＢ格納領域１（１２１）とＤＢ格納領域２（１２２）が対応付けられており、ＤＢ処理サーバＢ（１１２）にはＤＢ格納領域３（１２３）とＤＢ格納領域４（１２４）が対応付けられており、ＤＢ処理サーバＣ（１１３）にはＤＢ格納領域５（１２５）とＤＢ格納領域６（１６４）が対応付けられている。つまり、ＤＢ処理サーバＡ（１１１）は、ＤＢ格納領域１（１２１）とＤＢ格納領域２（１２２）に対するＤＢ処理実行要求のみを処理し、ＤＢ処理サーバＢ（１１２）は、ＤＢ格納領域３（１２３）とＤＢ格納領域４（１２４）に対するＤＢ処理実行要求のみを処理し、ＤＢ処理サーバＣ（１１３）は、ＤＢ格納領域５（１２５）とＤＢ格納領域６（１２６）に対するＤＢ処理実行要求のみを処理する。ＤＢ処理サーバＡ（１１１）とＤＢ処理サーバＢ（１１２）とＤＢ処理サーバＣ（１１３）が、同一のＤＢ格納領域をアクセスすることはない。

また、ＤＢ処理サーバＡ（１１１）はＤＢ格納領域３（１２３）の待機系としても動作し、ＤＢ処理サーバＣ（１１３）はＤＢ格納領域４（１２４）の待機系としても動作している。すなわち、特定のＤＢ格納領域に対する実行系として稼動中のＤＢ処理サーバを、他のＤＢ格納領域に対する待機系として使用している。

ここで例えば、ＤＢ処理サーバＢ（１１２）がダウンすると、マシン２（１０２）では、系切り替え機能（１１４）がダウンを検知し、マシン１（１０１）およびマシン３（１０３）上の系切り替え機能（１１４）に切り替えを要求し、ＤＢ格納領域３（１２３）およびＤＢ格納領域４（１２４）をそれぞれマシン１（１０１）およびマシン２（１０２）に切り替える。

マシン１（１０１）では、マシン２（１０２）からの切り替え要求を受けて、ＤＢ格納領域３（１２３）をＤＢ処理サーバＡ（１１１）に対応付け、ＤＢ格納領域３（１２３）の代行通知（１４１）を処理要求受付サーバ（１１０）に送信する。同様に、マシン３（１０３）では、ＤＢ格納領域４（１２４）をＤＢ処理サーバＣ（１１３）に対応付け、ＤＢ格納領域４（１２４）の代行通知（１４２）を処理要求受付サーバ（１１０）に送信する。

ユーザから問合せ（１３０）を受け取った処理要求受付サーバ（１１０）は、問合せ要求を解析し、アクセスするデータが存在するＤＢ格納領域を決定し、当該ＤＢ格納領域を担当するＤＢ処理サーバに実行処理要求を送信する。ＤＢ処理サーバＢ（１１２）がダウンしている場合は、アクセス先がＤＢ格納領域３（１２３）の実行要求はＤＢ処理サーバＡ（１１１）に送信し、アクセス先がＤＢ格納領域４（１２４）の実行要求はＤＢ処理サーバＣ（１１３）に送信する。

ＤＢ処理サーバＡ（１１１）は、通常、ＤＢ格納領域１（１２１）およびＤＢ格納領域２（１２２）に対する実行要求（１５１、１５２）を受け付けて各ＤＢ領域にアクセスしているが、ＤＢ処理サーバＢ（１１２）がダウンしている場合は、実行要求（１５３）も同時に受け付けてＤＢ格納領域３（１２３）へのアクセス処理を代行する。

また、ＤＢ処理サーバＣ（１１３）は、通常、ＤＢ格納領域５（１２５）に対するおよびＤＢ格納領域６（１２６）に対する実行要求（１５５、１５６）を受け付けて各ＤＢ領域にアクセスしているが、ＤＢ処理サーバＢ（１１２）がダウンしている場合は、実行要求（１５４）も同時に受け付けてＤＢ格納領域４（１２４）へのアクセス処理を代行する。

このとき、ＤＢ処理サーバＡ（１１１）およびＤＢ処理サーバＣ（１１３）では、あらたなプロセスを生成するのではなく、既存のプロセスを代用することで代行処理を実行する。また、データバッファに関しては、既存処理用のデータバッファを共用する。

以上のように、複数の稼動中ＤＢ処理サーバが、ダウンしたＤＢ処理サーバの処理をＤＢ格納領域単位で分担して代行することにより、待機系専用のリソースを有することなく、また、待機系を個別に管理することなく、負荷分散型の系切り替えを実現することができる。

次に、図２を用いて、本実施例のデータベース処理を実行するためのシステム構成を説明する。

この例のコンピュータシステムは、情報処理装置２０００、２１００および２２００を含む。

情報処理装置２０００は、ＣＰＵ２００１、主記憶装置２００２、通信制御装置２００３、Ｉ／Ｏ制御装置２００４及び端末２００５により構成される。主記憶装置２００１上には、アプリケーションプログラム２００６が置かれ、ＣＰＵ２００１を用いて稼動している。アプリケーションプログラム２００６が情報処理装置２１００に問い合わせを行なうと、情報処理装置２０００の通信制御装置２００３と情報処理装置２１００の通信制御装置２１０３によって、ネットワーク２５００を経由してデータベース管理システムに問い合わせ要求が送られる。

情報処理装置２１００は、ＣＰＵ２１０１、主記憶装置２１０２、通信制御装置２１０３、Ｉ／Ｏ制御装置２１０４、端末２１０５及び磁気ディスク装置等の外部記憶装置２６００により構成される。主記憶装置２１０２上には、データベース管理システムの処理要求受付サーバ１１０が置かれ、ＣＰＵ２１０１を用いて稼動している。外部記憶装置２６００上には処理要求受付サーバ１１０を実現する処理プログラム２６０１および代行先情報テーブル２６０２が格納される。

処理要求受付サーバ１１０は、Ｉ／Ｏ制御装置２１０４により外部記憶装置２６００からデータの読み出し／書き込みを行い、通信制御装置２１０３によりネットワーク２５００で接続された情報処理装置とデータの送受信を行なう。また、処理要求受付サーバ１１０は、通信制御装置２１０３によりネットワーク２５００で接続された情報処理装置２２００にＤＢ処理実行要求を送信する。

情報処理装置２２００は、ＣＰＵ２２０１、主記憶装置２２０２、通信制御装置２２０３、Ｉ／Ｏ制御装置２２０４、端末２２０５及び磁気ディスク装置等の外部記憶装置２７００、２８００、２８１０より構成される。主記憶装置２２０２上には、データベース管理システムのＤＢ処理サーバＡ（１１１）、ＤＢ処理サーバＢ（１１２）、ＤＢ処理サーバＣ（１１３）のうちいずれかと系切り替え機能（１１４）が置かれ、ＣＰＵ２２０１を用いて稼動している。また、データベースへのアクセスで使用するバッファ２２０８も主記憶装置２２０２上に置かれる。外部記憶装置２７００上にはＤＢ処理サーバＡ（１１１）、ＤＢ処理サーバＢ（１１２）、ＤＢ処理サーバＣ（１１３）のうちいずれかと系切り替え機能（１１４）を実現する処理プログラム２７０１および代行制御情報テーブル２７０２が格納される。外部記憶装置２８００上にはＤＢ格納領域２８０１が格納される。また、外部記憶装置２８１０上にはＤＢ格納領域２８１１が格納される。ＤＢ格納領域２８０１、２８１１には、本データベース管理システムにおいてアクセス対象となるデータを永続的あるいは一時的に格納する。ＤＢ処理サーバＡ（１１１）、ＤＢ処理サーバＢ（１１２）およびＤＢ処理サーバＣ（１１３）は、Ｉ／Ｏ制御装置２２０４により外部記憶装置置２７００、２８００、２８１０からデータの読み出し／書き込みを行い、通信制御装置２２０３によりネットワーク２５００で接続された情報処理装置とデータの送受信を行なう。 ここで、情報処理装置２２００にまずそれぞれ関連付けられた外部記憶装置２８００、２８１０は共用ディスクであり、当該情報処理装置２２００以外の情報処理装置２２００からもアクセス可能である。系切り替え機能（１１４）の制御により、上記共用ディスクのアクセス制御は行なわれる。

図３は、本実施例の処理要求受付サーバ１１０の概略構成を示す図である。

処理要求受付サーバ１１０は、処理要求制御部３００と代行先判定制御部３１０を具備する。

処理要求制御部３００は、ユーザから問合せ１３０を受け付け（３０１）、問合せ要求を解析してアクセスするデータが存在するＤＢ格納領域を特定し（３０２）、前記ＤＢ格納領域に対する処理実行要求先を代行先判定制御部３１０に問合せて、ＤＢ処理実行要求先を決定し（３０３）、決定した要求先（ＤＢ処理サーバ）に実行要求１５０を送信する（３０４）。

代行先判定制御部３１０は、処理要求制御部３００からの問合せを受けると、外部記憶装置２６００上の代行先情報テーブル２６０２を参照して、ＤＢ処理実行要求先（ＤＢ処理サーバ）を決定し、通知する（３１１）。また、代行先判定制御部３１０は、ＤＢ処理サーバから代行通知１４０を受けると、外部記憶装置２６００上の代行先情報テーブル２６０２に代行先情報を登録する（３１２）。

図４は、本実施例のＤＢ処理サーバＡ（１１１）の概略構成を示す図である。

ＤＢ処理サーバＡ（１１１）は、系切り替え機能連携制御部４００とＤＢ処理実行制御部４１０と代行処理制御部４２０を具備する。系切り替え機能連携制御部４００と代行処理制御部４２０が連動して系切り替え機能連携機能を提供し、ＤＢ処理実行制御部４１０と代行処理制御部４２０が連動してＤＢ処理実行機能を提供する。

系切り替え機能連携制御部４００は、系切り替え機能１１４と連携してＤＢ格納領域の切り替えを制御する（４０１）。外部記憶装置２７００上の代行情報テーブルを参照して、ＤＢ格納領域の処理状況を判定し、各ＤＢ格納領域の系状況を系切り替え機能に通知する。ＤＢ処理サーバ障害を検知すると、系切り替え機能１１４に切り替えを要求する。また、系切り替え機能１１４から切り替え受入要求を受信すると、外部記憶装置２７００上の代行制御情報テーブル２７０２に代行状況を登録し、代行処理制御部４２０に代行通知１４０送信を指示する。

ＤＢ処理実行制御部４１０は、実行要求１５０を受け付け（４１１）、アクセスするＤＢ格納領域を決定し（４１２）、アクセス先が代行対象ＤＢ格納領域の場合は前記ＤＢ格納領域の属するＤＢ処理サーバを代行処理制御部４２０に問合せて、実行環境を代行処理対応の環境に変更し（４１３）、外部記憶装置２９００上のＤＢ格納領域２９０１にアクセスしてＤＢ処理を実行する（４１４）。

代行処理制御部４２０は、ＤＢ処理実行制御部４１０から問い合わせを受けると、外部
記憶装置２７００上の代行制御情報テーブル２７０２を参照して、ＤＢ処理実行制御部４
１０がアクセスするＤＢ格納領域が属するＤＢ処理サーバを特定し、通知する（４２１）
。また、系切り替え機能連携制御部４００から指示を受けると、外部記憶装置２７００上
の代行制御情報テーブル２７０２を参照して、代行通知１４０を処理要求受付サーバに送信する。

ＤＢ処理サーバＢ（１１２）およびＤＢ処理サーバＣ（１１３）もＤＢ処理サーバＡ（１１１）と同様の構成である。

図５は、処理要求受付サーバ１１０の処理手順を示すフローチャートである。

まず、ステップ５０１において代行通知の有無を判定する。代行通知がある場合はステップ５０２に進み、代行通知がない場合はステップ５０３に進む。

ステップ５０２では、代行通知を参照して、実行要求先変更対象ＤＢ格納領域とその処理実行要求先（ＤＢ処理サーバ）を特定し、ステップ５０３に進む。

ステップ５０３では、外部記憶装置２６００上の代行先情報テーブル２６０２に、ステップ５０２で特定した実行要求先変更対象ＤＢ格納領域の実行要求先情報（ＤＢ処理サーバ名）を登録して、ステップ５０４に進む。 ステップ５０４では、ユーザからの問い合わせを受け取り、ステップ５０５では、ステップ５０４で受け取った問い合わせを解析してアクセス対象ＤＢ格納領域を特定し、ステップ５０６に進む。

ステップ５０６では、ステップ５０５で特定したＤＢ格納領域の属するＤＢ処理サーバが稼動中かどうかを判定する。稼動中でない場合はステップ５０７に進み、稼動中の場合はステップ５０９に進む。

ステップ５０７では、外部記憶装置２６００上の代行先情報テーブル２６０２を参照してアクセス対象ＤＢ格納領域に対する代行先ＤＢ処理サーバを特定し、ステップ５０８では、ステップ５０７で特定した代行先ＤＢ処理サーバを実行要求送信先に設定し、ステップ５１０に進む。

ステップ５０９では、ＤＢ格納領域の属するＤＢ処理サーバを実行要求送信先に設定し、ステップ５１０に進む。

ステップ５１０では、ステップ５０８またはステップ５０９で設定した実行要求送信先に、ＤＢ処理実行要求を送信し、ステップ５１１に進んで処理を終了する。

図６は、ＤＢ処理サーバＡ（１１１）、ＤＢ処理サーバＢ（１１２）およびＤＢ処理サ
ーバＣ（１１３）の系切り替え機能連携機能の処理手順を示すフローチャートである。

まず、ステップ６０１において、外部記憶装置２７００上の代行制御情報テーブル２７０２を取得し、ステップ６０２に進む。

ステップ６０２では、ステップ６０１で取得した代行制御情報テーブル２７０２から１番目の代行制御情報を取得し、ステップ６０３に進む。

ステップ６０３では、取得した代行制御情報を参照して、対応するＤＢ格納領域の処理状況を判定する。処理状況が実行中または代行中の場合はステップ６０４に進み、実行中でも代行中でもない場合はステップ６０５に進む。

ステップ６０４では、ステップ６０３で処理状況を判定したＤＢ格納領域の実行系が当該ＤＢ処理サーバであることを系切り替え機能１１４に連絡し、ステップ６０６に進む。

ステップ６０５では、ステップ６０３で処理状況を判定したＤＢ格納領域の待機系が当該ＤＢ処理サーバであることを系切り替え機能１１４に連絡し、ステップ６０６に進む。

ステップ６０６では、代行制御情報テーブル２７０２中に次の情報があるかどうかを判定する。次の情報がある場合はステップ６０７に進み、ない場合はステップ６０８に進む。

ステップ６０７では、代行制御情報テーブル２７０２から次の情報を取得し、ステップ６０３に進む。

ステップ６０８では、系切り替え機能１１４から切り替え受入要求があるかどうかを判定する。切り替え受入要求がある場合はステップ６０９に進み、ない場合はステップ６１１に進む。

なお、本実施例では、系切り替え機能からの切り替え受入要求に基づいて系切り替えを受け入れる例を説明しているが、ステップ６０８において、他のＤＢ処理サーバの稼動状況に基づいて別の切り替え先を決定して、別の切り替え先を系切り替え機能に通知し、受け入れを拒否することも可能である。

ステップ６０９では、切り替え受入対象のＤＢ格納領域について代行制御情報テーブル２７０２中の処理状態を代行中に変更し、ステップ６１０に進む。

ステップ６１０では、代行処理制御部４２０に指示して、切り替え受入対象のＤＢ格納領域についての代行通知を処理要求受付サーバに送信し、ステップ６１１に進む。

ステップ６１１では、ＤＢ処理サーバの障害発生状況を判定する。障害が発生していない場合はステップ６０１に進み、障害が発生している場合はステップ６１２に進む。

ステップ６１２では、ＤＢ処理サーバで実行中または代行中のＤＢ格納領域の系切り替え要求を系切り替え機能１１４に送信し、ステップ６１３に進んで処理を終了する。

なお、本実施例では、系切り替え機能が切り替え先を決定する例を説明しているが、ステップ６１２において、他のＤＢ処理サーバの稼動状況に基づいて切り替え先を決定して、決定した切り替え先を系切り替え機能に通知することも可能である。

図７は、ＤＢ処理サーバＡ（１１１）、ＤＢ処理サーバＢ（１１２）およびＤＢ処理サ
ーバＣ（１１３）のＤＢ処理実行機能の処理手順を示すフローチャートである。

まず、ステップ７０１において、外部記憶装置２７００上の代行制御情報テーブル２７０２を取得して、ステップ７０２に進む。

ステップ７０２において、各ＤＢ格納領域が属するＤＢ処理サーバを特定して代行制御情報に反映し、前記代行制御情報を代行制御情報テーブル２７０２に登録して、ステップ７０３に進む。

ステップ７０３において、ステップ７０２で代行制御情報を登録した代行制御情報テーブル２７０２を外部記憶装置２７００に格納し、ステップ７０４に進む。

次に、ステップ７０４において、処理要求受付サーバから実行要求を受け取り、ステップ７０５に進む。

ステップ７０５では、ステップ７０４で受信した実行要求を解析してアクセス先ＤＢ格納領域を決定し、ステップ７０６に進む。

ステップ７０６では、ＤＢ格納領域が代行対象ＤＢ格納領域であるかどうかを判定する。代行対象ＤＢ格納領域である場合はステップ７０７に進み、代行対象ＤＢ格納領域でない場合はステップ７０９に進む。

ステップ７０７では、外部記憶装置２７００上から代行制御情報テーブル２７０２を取得し、ステップ７０８に進む。

ステップ７０８では、代行制御情報テーブル２７０２を参照してアクセス対象ＤＢ格納領域が属するＤＢ処理サーバを特定し、ＤＢ処理サーバプロセスの実行環境を代行処理用に変更して、ステップ７０９に進む。

ステップ７０９では、アクセス対象ＤＢ格納領域にアクセスしてＤＢ処理を実行し、ステップ７１０に進む。

ステップ７１０では、次の実行要求があるかどうかを判定する。実行要求がある場合にはステップ７０４に進み、実行要求がない場合にはステップ７１１に進んで処理を終了する。

図８は、本実施例の代行先情報テーブルの例を示す。代行先情報テーブルは、システム内の各ＤＢ格納領域について、当該ＤＢ格納領域に対するＤＢ処理実行要求の送信先を登録するテーブルである。

図８（ａ）は、データベース管理システムに属するすべてのＤＢ処理サーバが稼動中の場合の代行先情報テーブルである。このテーブルに登録されている情報は、システムの初期設定値である。前記初期設定値は、システム構築時またはシステム起動時に、システムがシステム構成に基づいて設定する。ＤＢ格納領域１およびＤＢ格納領域２の実行要求先としてＤＢ処理サーバＡが登録されており、ＤＢ格納領域３およびＤＢ格納領域４の実行要求先としてＤＢ処理サーバＢが登録されており、ＤＢ格納領域５およびＤＢ格納領域６の実行要求先としてＤＢ処理サーバＣが登録されている。

図８（ｂ）は、ＤＢ処理サーバＢがダウン中の代行先情報テーブルである。本テーブルに登録されている情報は、ＤＢ処理サーバから受信した代替通知に基づいて初期設定値から変更されている。ＤＢ格納領域１およびＤＢ格納領域２の実行要求先としては通常時と同様にＤＢ処理サーバＡが登録されており、ＤＢ格納領域５およびＤＢ格納領域６の実行要求先としては通常時と同様にＤＢ処理サーバＣが登録されている。ＤＢ格納領域３については、ＤＢ処理サーバＢがダウンしているため、実行要求先には代行サーバであるＤＢ処理サーバＡが登録されている。また、ＤＢ格納領域４については、ＤＢ処理サーバＢがダウンしているため、実行要求先には代行サーバであるＤＢ処理サーバＣが登録されている。

なお、代行先情報テーブルに登録されている情報は、データベース管理システムの稼動状況確認コマンドなどにより確認可能である。

図９は、本実施例の代行制御情報テーブルの例を示す。代行制御情報テーブルは、システム内の各ＤＢ格納領域について、当該ＤＢ格納領域に関するＤＢ処理サーバの系状態と実行環境情報（所属ＤＢ処理サーバ）を登録するテーブルである。

図９（ａ）は、データベース管理システムに属する全ＤＢ処理サーバが稼動中である場合のＤＢ処理サーバＡ用の代行制御情報テーブルである。このテーブルに登録されている情報は、システムの初期設定値である。前記初期設定値は、システム構築時またはシステム起動時に、ユーザが登録する。ユーザは、各ＤＢ格納領域について、現用系とするＤＢ処理サーバ（所属ＤＢ処理サーバ）と予備系とするＤＢ処理サーバ（代行ＤＢ処理サーバ）を決定する。この決定に基づいて、ＤＢ処理サーバＡを現用系とするＤＢ格納領域については、系の状態に「実行中」と登録し、所属ＤＢ処理サーバにＤＢ処理サーバＡを登録する。また、ＤＢ処理サーバＡを予備系とするＤＢ格納領域については、系の状態に「待機中」と登録し、所属ＤＢ処理サーバには現用系とするＤＢ処理サーバを登録する。ＤＢ処理サーバＢおよびＤＢ処理サーバＣについても同様に初期設定値を登録する必要がある。なお、本実施例では、前記初期設定値をユーザが登録する例を説明しているが、システムが自動決定することも可能である。

図９（ａ）では、ＤＢ格納領域１およびＤＢ格納領域２の処理状況は、ＤＢ処理サーバＡにおいて実行中として登録されている。また、ＤＢ格納領域３、ＤＢ格納領域４、ＤＢ格納領域５およびＤＢ格納領域６の処理状況は、待機中として登録されている。また、各ＤＢ格納領域が属するＤＢ処理サーバが所属ＤＢ処理サーバとして登録されている。ＤＢ格納領域１およびＤＢ格納領域２の所属ＤＢ処理サーバにはＤＢ処理サーバＡが登録されており、ＤＢ格納領域３およびＤＢ格納領域４の所属ＤＢ処理サーバにはＤＢ処理サーバＢが登録されており、ＤＢ格納領域５およびＤＢ格納領域６の所属ＤＢ処理サーバにはＤＢ処理サーバＣが登録されている。

図９（ｂ）は、ＤＢ処理サーバＢダウン中のＤＢ処理サーバＡ用の代行制御情報テーブルである。本テーブルに登録されている情報は、系切り替え機能からの切り替え受け入れ要求に基づいて初期設定値から変更されている。ＤＢ格納領域１およびＤＢ格納領域２の処理状況は、ＤＢ処理サーバＡにおいて実行中として登録されている。また、ＤＢ格納領域４、ＤＢ格納領域５およびＤＢ格納領域６の処理状況は、待機中として登録されている。ＤＢ格納領域３の処理状況に関しては、ＤＢ処理サーバＡがＤＢ処理サーバＢから引き継いで処理を代行しているため、代行中として登録されている。各ＤＢ格納領域の所属ＤＢ処理サーバは通常時と同じである。

なお、代行制御情報テーブルに登録されている情報は、データベース管理システムの稼動状況確認コマンドまたは系切り替え機能の系状態確認コマンドなどにより確認可能である。

図８および図９を参照して、本実施例におけるデータベース管理システムの動作を説明する。

図８を参照して、本実施例における処理要求受付サーバ（１１０）の動作と代行先情報テーブルの関係を説明する。

まず、ＤＢ処理サーバＢがダウンして系切り替えが発生した場合の動作を説明する。ＤＢ処理サーバＢ（１１２）がダウンして系切り替えが発生すると、ＤＢ処理サーバＡ（１１１）から処理要求受付サーバ（１１０）にＤＢ格納領域３（１２３）に対する代行通知（１４１）が送信され、ＤＢ処理サーバＣ（１１３）から処理要求受付サーバ（１１０）にＤＢ格納領域４（１２４）に対する代行通知（１４２）が送信される。処理要求受付サーバ（１１０）では、代行先判定制御部（３１０）が代行通知（１４１）および代行通知（１４２）を受信して、代行先情報テーブル（２６０２）を更新する。更新前のテーブルは図８（ａ）であり、更新後のテーブルは図８（ｂ）である。処理要求受付サーバ（１１０）は、ＤＢ格納領域３（１２３）に対する代行通知（１４１）を受けてＤＢ格納領域３の実行要求先をＤＢ処理サーバＢからＤＢ処理サーバＡに変更し、ＤＢ格納領域４（１２４）に対する代行通知（１４２）を受けてＤＢ格納領域３の実行要求先をＤＢ処理サーバＢからＤＢ処理サーバＣに変更する。

次に、ＤＢ処理サーバＢがダウン中にユーザから問合せ（１３０）を受け付け、問合せ要求を解析し、アクセス先がＤＢ格納領域３であった場合の動作を説明する。ＤＢ格納領域３の属するＤＢ処理サーバＢがダウンしているため、処理要求制御部（３００）は、ＤＢ格納領域３に関する処理実行要求先を代行先判定制御部（３１０）に問い合わせる。代行先判定制御部（３１０）は、代行先情報テーブル（２６０２）を参照して処理実行要求先を決定する。このとき、代行先情報テーブル（２６０２）に登録されている情報は図８（ｂ）に示すとおりであるため、代行先判定制御部（３１０）は、ＤＢ格納領域３の実行要求先をＤＢ処理サーバＡと決定して、処理要求制御部（３００）に連絡する。その結果、処理要求制御部（３００）は、ＤＢ処理サーバＡ（１１１）に実行要求（１５３）を送信する。

図９を参照して、本実施例におけるＤＢ処理サーバＡ（１１１）の動作と代行制御情報テーブルの関係を説明する。

まず、ＤＢ処理サーバＢがダウンして系切り替えが発生した場合の動作を説明する。ＤＢ処理サーバＢ（１１２）がダウンして系切り替えが発生すると、系切り替え機能（１１４）からＤＢ処理サーバＡ（１１１）にＤＢ格納領域３（１２３）の切り替え受入要求が届く。ＤＢ処理サーバＡ（１１１）では、系切り替え機能連携制御部（４００）がＤＢ格納領域３の切り替え受入要求を受信して、代行制御情報テーブル（２７０２）を更新する。更新前のテーブルは図９（ａ）であり、更新後のテーブルは図９（ｂ）である。ＤＢ処理サーバＡ（１１１）は、ＤＢ格納領域３（１２３）の切り替え受入要求を受けてＤＢ格納領域３の処理状況が待機中から代行中に変更する。

次に、ＤＢ処理サーバＡ（１１１）がＤＢ格納領域３（１２３）の系状況を系切り替え機能（１１４）に連絡する処理の動作を説明する。ＤＢ処理サーバＡ（１１１）の系切り替え機能連携制御部（４００）は、代行制御情報テーブル（２７０２）を参照してＤＢ格納領域３の処理状況を特定し、系切り替え機能に系状況を連絡する。

ＤＢ処理サーバＢが稼動中の場合は、代行制御情報テーブルは図９（ａ）に示すとおりであり、ＤＢ格納領域３の処理状況は待機中である。従って、系切り替え機能連携制御部（４００）は、ＤＢ処理サーバＡがＤＢ格納領域３の待機系であることを系切り替え機能に連絡する。

ＤＢ処理サーバＢがダウン中の場合は、代行制御情報テーブルは図９（ｂ）に示すとおりであり、ＤＢ格納領域３の処理状況は代行中である。従って、系切り替え機能連携制御部（４００）は、ＤＢ処理サーバＡがＤＢ格納領域３の実行系であることを系切り替え機能に連絡する。

次に、ＤＢ処理サーバＢがダウン中に処理要求受付サーバ（１１０）からＤＢ格納領域３（１２３）に対する実行要求（１５３）を受信した場合の動作を説明する。処理サーバＡ（１１１）においてはＤＢ格納領域３（１２３）は代行対象ＤＢ格納領域であるため、ＤＢ処理実行制御部（４１０）は、ＤＢ格納領域３の所属ＤＢ処理サーバを代行処理制御部（４２０）に問合せる。代行処理制御部（４２０）は、代行制御情報テーブル（２７０２）を参照してＤＢ格納領域３の所属ＤＢ処理サーバを参照する。

このとき、代行制御情報テーブル（２７０２）に登録されている情報は図９（ｂ）に示すとおりであるため、代行処理制御部（４２０）は、ＤＢ格納領域３の所属ＤＢ処理サーバをＤＢ処理サーバＢと特定して、ＤＢ処理実行制御部（４１０）に連絡する。その結果、ＤＢ処理実行制御部（４１０）は、実行環境をＤＢ処理サーバＢの実行環境に変更し、ＤＢ格納領域３にアクセスしてＤＢ処理を実行する。

実行環境とは、ＤＢ処理サーバがＤＢ格納領域に対する処理を実行する際の動作環境であり、例えば、データバッファ、プロセスの属性、ＤＢ処理サーバの状態管理テーブルなどがある。
実行環境はＤＢ処理サーバの定義情報に基づいて変更可能であり、前記定義情報はＤＢ処理サーバの名称により特定可能である。

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

本発明の一実施例の概念図である。 本発明の一実施例におけるコンピュータシステムのシステム構成を示す図である。 本発明の一実施例における処理要求受付サーバの機能構成を示す図である。 本発明の一実施例におけるＤＢ処理サーバの機能構成を示す図である。 本発明の一実施例における処理要求受付サーバの処理手順を示すフローチャートである。 本発明の一実施例におけるＤＢ処理サーバの系切り替え機能連携機能の処理手順を示すフローチャートである。 本発明の一実施例におけるＤＢ処理サーバのＤＢ処理実行機能の処理手順を示すフローチャートである。 本発明の一実施例における代行先情報テーブルを示す図である。 本発明の一実施例における代行制御情報テーブルを示す図である。

符号の説明

１１０・・・処理要求受付サーバ、１１１・・・ＤＢ処理サーバＡ、
１１２・・・ＤＢ処理サーバＢ、１１３・・・ＤＢ処理サーバＣ、１１４・・・系切り替え機能、
３００・・・処理要求制御部、３１０・・・代行判定制御部、
４００・・・系切り替え機能連携制御部、４１０・・・ＤＢ処理実行制御部、
４２０・・・代行処理制御部、
２６０２・・・代行先情報テーブル、
２７０２・・・代行制御情報テーブル

Claims (9)

1. データベースを複数の格納領域に分割して格納し、１つ以上の領域に対して１つのＤＢ処理サーバが対応するように、それぞれの領域に対してＤＢ処理サーバを関連付けてデータ処理を行なうデータベース処理方法において、
   前記ＤＢ処理サーバが、系切り替え機能の指示に従って、ＤＢ格納領域の処理状況を代行
   中に変更し、当該ＤＢ処理サーバが前記ＤＢ格納領域の代行中であることを示す代行通知
   を処理要求受付サーバに送信するステップと、
   前記処理要求受付サーバが、ＤＢ格納領域と前記ＤＢ格納領域に対応するＤＢ処理サーバ
   の対応関係を示す代行先情報を登録するステップと、
   前記処理要求受付サーバが、前記ＤＢ処理サーバから代行通知を受け取った際に、ＤＢ格
   納領域とＤＢ処理サーバの対応関係の変更に応じて前記代行先情報を変更するステップと
   、
   前記処理要求受付サーバが、ユーザから問い合わせを受け取った際に、問い合わせを解析
   してアクセス対象ＤＢ格納領域を特定し、あるＤＢ格納領域に対する処理を要求する際に
   、前記代行先情報を参照して、処理要求先ＤＢ処理サーバを決定し、前記実行要求先とな
   る前記ＤＢ処理サーバにＤＢ処理実行要求を送信するステップと、
   前記ＤＢ処理サーバが、ＤＢ格納領域に対する代行処理を実行する際に必要となる代行制
   御情報を登録するステップと、
   前記ＤＢ処理サーバが、前記処理要求受付サーバからＤＢ格納領域に対する処理要求を受
   け取った際に、前記ＤＢ格納領域が代行中かどうかを判定し、代行中で無い場合はＤＢ格納領域に対するＤＢ処理を実行し、代行中の場合は前記代行制御情報を参照してＤＢ処理サーバプロセスの実行環境を切り替えて、ＤＢ格納領域に対するＤＢ処理を実行するステップと
   を有することを特徴とするデータベース処理方法。
2. システム構築時あるいはシステム起動時のいずれかにおいて、前記処理要求受付サーバが
   、前記ＤＢ処理サーバと前記ＤＢ格納領域の対応を決定するステップを有することを特徴
   とする請求項１記載のデータベース処理方法。
3. 前記ＤＢ処理サーバが、前記ＤＢ処理サーバの稼動状況に応じて前記ＤＢ格納領域の切り
   替え先を変更するステップを有することを特徴とする請求項１記載のデータベース処理方
   法。
4. 請求項１記載のデータベース処理方法において、前記ＤＢ処理サーバが、前記ＤＢ格納領
   域を監視対象として監視をするステップと、前記ＤＢ処理サーバに障害があった場合に前
   記ＤＢ処理サーバが前記系切り替え機能に切り替え要求をするステップを有することを特
   徴とするデータベース処理方法。
5. 請求項４記載のデータベース処理方法において、前記ＤＢ処理サーバが、前記ＤＢ格納領
   域を監視対象として監視をするステップにおいて、前記ＤＢ格納領域に対応するＤＢ処理
   サーバの対応関係から実行、代行といった処理状況を取得して前記ＤＢ格納領域に対する
   処理要求を当該ＤＢ処理サーバが受け入れ中かどうかを判断することを特徴とするデータ
   ベース処理方法。
6. データベースを複数の格納領域に分割して格納し、１つ以上の領域に対して１つのＤＢ処理サーバが対応するように、それぞれの領域に対してＤＢ処理サーバを関連付けてデータ処理を行なうデータベース管理システムにおいて、
   前記ＤＢ処理サーバが、系切り替え機能の指示に従って、ＤＢ格納領域の処理状況を代行中に変更し、前記ＤＢ処理サーバが前記ＤＢ格納領域の代行中であることを示す代行通知を処理要求受付サーバに送信する手段と、
   ＤＢ格納領域と前記ＤＢ格納領域に対応するＤＢ処理サーバの対応関係を示す代行先情報
   を登録する代行先情報登録手段と、
   前記処理要求受付サーバが前記ＤＢ処理サーバから代行通知を受け取った際に、ＤＢ格納領域とＤＢ処理サーバの対応関係の変更に応じて前記代行先情報を変更する代行先情報変更手段と、
   前記処理要求受付サーバがユーザから問い合わせを受け取った際に、問い合わせを解析し
   てアクセス対象ＤＢ格納領域を特定し、あるＤＢ格納領域に対する処理を要求する際に、
   前記代行先情報を参照して、処理要求先ＤＢ処理サーバを決定し、前記実行要求先となる
   ＤＢ処理サーバにＤＢ処理実行要求を送信する手段と、
   ＤＢ格納領域に対する代行処理を実行する際に必要となる代行制御情報を登録する代行制
   御情報登録手段と、
   ＤＢ格納領域に対する処理要求を受け取った際に、前記ＤＢ格納領域が代行中かどうかを判定し、代行中で無い場合はＤＢ格納領域に対するＤＢ処理を実行し、代行中の場合は前記代行制御情報を参照してＤＢ処理サーバプロセスの実行環境を切り替えて、ＤＢ格納領域に対するＤＢ処理を実行するＤＢ処理実行手段とを有することを特徴とするデータベース管理システム。
7. 前記ＤＢ処理サーバの稼動状況に応じて前記ＤＢ格納領域の切り替え先を変更する手段を
   有することを特徴とする請求項６記載のデータベース管理システム。
8. 請求項６記載のデータベース管理システムにおいて、前記ＤＢ格納領域を監視対象として
   監視をする監視手段と、前記ＤＢ処理サーバに障害があった場合に前記系切り替え機能に
   切り替え要求をする切り替え要求手段とを有することを特徴とするデータベース管理シス
   テム。
9. 請求項８記載のデータベース管理システムにおいて、前記ＤＢ格納領域を監視対象として
   監視をする監視手段において、前記ＤＢ格納領域に対応するＤＢ処理サーバの対応関係か
   ら実行、代行といった処理状況を取得して前記ＤＢ格納領域に対する処理要求を当該ＤＢ
   処理サーバが受け入れ中かどうかを判断することを特徴とするデータベース管理システム
   。

Images