JP4675174B2

JP4675174B2 - データベース処理方法、システム及びプログラム

Info

Publication number: JP4675174B2
Application number: JP2005203138A
Authority: JP
Inventors: 憲宏原; 哲也鈴木; 星野　　隆一
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2005-07-12
Filing date: 2005-07-12
Publication date: 2011-04-20
Anticipated expiration: 2025-07-12
Also published as: US20070016589A1; JP2007025785A; US7853570B2

Description

本発明はデータベースを複数に分割した各分割データベースに対してサーバを関連付けてデータ処理を行うデータベース処理技術に関し、特に分割データベースのそれぞれにマスタデータを格納・保持してデータベース処理を行うデータベース処理技術に適用して有効な技術に関するものである。

大規模ＤＢ及び高負荷な処理要求に対応する為に、データベースの処理負荷を複数のプロセッサに分散させ並列に実行するアーキテクチャが開示されている（例えば非特許文献１参照）。上記従来技術のShared everything, Shared disk（共用型）アーキテクチャでは、ＤＢ処理を実行する全ての計算機が全てのデータをアクセスすることが可能であり、Shared nothing（非共用型）アーキテクチャでは、自計算機に接続されたディスクに格納されたデータのみをアクセスすることが可能である。

Shared nothing（非共用型）アーキテクチャは、共用型アーキテクチャにくらべ、ＤＢ処理を実行する構成単位の間での共有リソースが少なく、スケーラビリティの点で非常に優れている。

David J. DeWitt and Jim Gray, "Parallel Database Systems: The Future of High Performance Database Systems", COMMUNICATIONS OF THE ACM, Vol.36, No.6, 1992, P.85-P.98

しかしながら、データベースを分割し(分割ＤＢと呼ぶ)、その各々の分割ＤＢへのアクセスの為に専用サーバを割り当て、ユーザからのＤＢアクセス要求をそれらの複数の専用サーバで並列処理することにより高速アクセスとスケーラビリティを実現するシェアドナッシング型アーキテクチャの並列ＲＤＢＭＳにおいて、専用サーバそれぞれに関連付けられたＵＡＰ(ユーザアプリケーションプログラム)が共通に参照する様なマスタデータは、アクセスが集中してシステム全体のボトルネックとなってしまう。ここで言う専用サーバとは、ハードウェアとしてのサーバマシンとは限らず、データベース管理システムを構成する１コンポーネントを示すこともある。以降この専用サーバを単に"サーバ"若しくは“バックエンドサーバ(ＢＥＳ)”と呼ぶことにする。

このマスタデータへのアクセス集中を回避する為の一つの方法として、上記分割ＤＢのそれぞれにマスタデータを格納・保持する方法が挙げられる。しかし、この方法にはマスタデータへの更新が頻繁に発生する場合に以下の様な可用性の問題が存在する。具体的には、ある一つのＢＥＳ若しくはＢＥＳを配置したサーバマシンに障害が発生した場合には、このマスタデータに対する更新処理はエラーとなり、結果として障害が発生しているＢＥＳ以外のＢＥＳに関連付けられたマスタデータに対する更新も滞り、当該マスタデータを参照している全ての業務が実質的にサービス停止となってしまう。すなわち、ある一つのＢＥＳの障害がシステム全体に影響を与えてしまうこととなる。

本発明の目的は上記問題を解決し、ある情報処理装置に障害が発生した場合でも、その影響を局所化してシステム全体に与える影響を最小限にすることが可能な技術を提供することにある。

本発明は、データベースを複数に分割した各分割データベースに対して情報処理装置を関連付けてデータ処理を行うデータベース処理システムにおいて、サービス可能状態の情報処理装置を処理要求先として決定して処理要求を行うものである。

前記課題を解決するため、本発明のデータベース処理システムでは、データベースを複数に分割した各分割データベースに対して情報処理装置であるＤＢアクセスサーバ（ＢＥＳ）を関連付けてデータ処理を行う際に、ＡＰ（アプリケーションプログラム）からの問合せを処理要求受付サーバ（フロントエンドサーバ：ＦＥＳ）で受け取り、そのＡＰがＤＢ処理サービス適用かどうか、すなわちＢＥＳのサービス可能状態により処理制御されるものであるかを判定し、そのＡＰがＤＢ処理サービス適用である場合には、各ＢＥＳがサービス可能状態であるかどうかを示すＤＢ処理サービス状況を取得し、サービス中("Available")のＢＥＳのみを処理要求先として決定して、その決定したＢＥＳに前記問合せに対応する処理（ＤＢアクセス）要求を送信する。

前記処理要求を受信したＢＥＳでは、その受信した処理要求に従ってデータベース上のデータを処理し、その処理結果を当該処理要求の送信元のＦＥＳへ送信する。ＦＥＳでは、処理要求を行ったＢＥＳからの結果を受け取り、全てのＤＢアクセスの結果が正常終了の場合に問合せ結果を正常終了としてＡＰに返す。

なお、本発明のサービスとは、プログラムやオブジェクトの実行により実現される機能を指し、またＦＥＳやＢＥＳは、計算機等のハードウェアや、またはその様な処理を実施するプログラムやオブジェクトでも良い。

本発明によれば、ある情報処理装置に障害が発生した場合でも、その影響を局所化してシステム全体に与える影響を最小限にすることが可能である。

以下にデータベースを複数に分割した各分割データベースに対してＢＥＳを関連付けてデータ処理を行う一実施形態のデータベース処理システムについて説明する。

図１は本実施形態のデータベース処理システムの概念を示す図である。本実施形態のデータベース処理システムは、先に説明したデータベース管理システムのコンポーネントとして、処理要求受付サーバ（ＦＥＳ）１０（ＦＥＳ：ＦｒｏｎｔＥｎｄＳｅｒｖｅｒ）及びＤＢアクセスサーバ（ＢＥＳ）２０（ＢＥＳ：ＢａｃｋＥｎｄＳｅｒｖｅｒ）を具備する。

処理要求受付サーバ（ＦＥＳ）１０は、ユーザアプリケーションプログラム６（名称：MSTUP）からのユーザ問合せ５０を受け付け、それを解析し、ＤＢアクセス要求を生成し、ＤＢアクセスサーバへＤＢアクセス要求を行う。そしてＤＢアクセスの結果を必要に応じてユーザアプリケーションプログラム６に返す。ＤＢアクセスサーバ（ＢＥＳ）２０は、処理要求受付サーバ（ＦＥＳ）１０からのＤＢアクセス要求を受け取り、要求に従ってＤＢ格納領域上のデータを操作し、必要に応じて結果を処理要求受付サーバ（ＦＥＳ）１０に返す。処理要求受付サーバ（ＦＥＳ）１０及びＤＢアクセスサーバ（ＢＥＳ）２０ともに１プロセス若しくは複数のプロセスによって実現される。

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

図１の例では、通常、ＢＥＳ１は、ＤＢ格納領域１へのアクセス要求のみを、ＢＥＳ２は、ＤＢ格納領域２へのアクセス要求のみを処理する。ＢＥＳ１及びＢＥＳ２は同じＤＢ格納領域をアクセスすることはない。

図１の例では、ＵＡＰが共通データとして参照する為の「マスタ表」が複数の分割テーブル６２(分割マスタ表１、分割マスタ表２、分割マスタ表３、分割マスタ表４)に分割され、その各々にマスタデータが格納されて、各々のＤＢアクセスサーバ（ＢＥＳ）２０（ＢＥＳ１、ＢＥＳ２、ＢＥＳ３、ＢＥＳ４）を経由してデータベースをアクセスするＵＡＰにより参照される。すなわち、ＢＥＳ１をアクセスするＵＡＰは常に分割マスタ表１のマスタデータを、ＢＥＳ２をアクセスするＵＡＰは常に分割マスタ表２のマスタデータを、ＢＥＳ３をアクセスするＵＡＰは常に分割マスタ表３のマスタデータを、そしてＢＥＳ４をアクセスするＵＡＰは常に分割マスタ表４のマスタデータを参照する。分割マスタ表に格納されたマスタデータは、別のユーザアプリケーションプログラム６（ＭＳＴＵＰ）によって適時最新の値に更新される。マスタデータを更新する為のユーザ問合せ５０は例えば次の様なＳＱＬ文で実現する。
UPDATE T1 SET C2=5000 WHERE C1=2

通常は、本ユーザ問合せ５０は処理要求受付サーバ（ＦＥＳ）１０により受け付けられ、処理(ＤＢアクセス)要求３０として、マスタデータが格納された全分割マスタ表に関連付けられたＤＢアクセスサーバ（ＢＥＳ）２０（ＢＥＳ１、ＢＥＳ２、ＢＥＳ３、ＢＥＳ４）に制御が渡る。ＤＢアクセス要求３０を受け取った各ＤＢアクセスサーバ（ＢＥＳ）２０は、関連付いた分割マスタ表に格納された該当マスタデータを更新（ＤＢアクセス処理）する。そして実行結果を処理要求受付サーバ（ＦＥＳ）１０へ送る。各ＢＥＳからの実行結果を受け取った処理要求受付サーバ（ＦＥＳ）１０はＢＥＳからの全実行結果が正常であることをもって、ＵＡＰからの問合せ要求の結果を正常としてＵＡＰへ返す。

ここで、ＤＢアクセスサーバＢＥＳ１が何らかの要因（マシンのハードウェア障害等）にて停止中であるとする。その場合、マスタデータ更新である本ユーザ問合せ５０を受け取った処理要求受付サーバ（ＦＥＳ）１０は、まず、本ユーザ問合せ５０の要求元であるＵＡＰが「ＤＢ処理サービス適用」であるかどうかを、ＤＢ処理サービス適用ＡＰテーブル４００を参照して判定する。この「ＤＢ処理サービス適用」は、ＤＢアクセスサーバ障害の場合等、停止対象のＤＢアクセスサーバのサービスが論理的に停止状態かどうかを意識して処理制御を行うことを示す。ここでは、要求元ＵＡＰである"ＭＳＴＵＰ"が「ＤＢ処理サービス適用」であり、その場合に次のステップとしてＤＢ処理サービス状況を、ＤＢ処理サービス状況テーブル５００を参照して取得する。ここではＢＥＳ１は障害中であり"Unavailable"な状態である。ＢＥＳ２、ＢＥＳ３、及びＢＥＳ４は、稼動中であり"Available"な状態である。この"Unavailable"/"Available"を管理するＤＢ処理サービス状況テーブル５００は、一般にはＦＥＳがアクセス可能なメモリ上に配置され、ＢＥＳに障害が発生した場合に自動的に更新される。若しくは、データベース管理者等によりＤＢＭＳ（データベース管理システム）が提供するユティリティやコマンド等を経由して更新される。

"Unavailable"な状態のＢＥＳが存在しない場合、ＢＥＳ１からＢＥＳ４の全てのＢＥＳに対して処理（ＤＢアクセス）要求を送信する。ここで"Unavailable"な状態のＢＥＳが存在する場合には、その情報を先に取得しておいて"Available"なＢＥＳのみを処理要求先として決定する。すなわち、更新処理のトランザクションを構成するＢＥＳを変更(縮小)する。本例では、ＢＥＳ２、ＢＥＳ３、ＢＥＳ４がトランザクションを構成するＢＥＳとして決定される。処理要求は、先に更新処理を構成するＢＥＳとして決定されたＢＥＳに対して送信され、本ＢＥＳからの結果が全て正常である場合に更新結果を正常として要求元ＵＡＰ６に返す。すなわち、本例ではＢＥＳ１はトランザクションを構成する要素からは外される。以上の結果より、例えＢＥＳ１が障害中の場合であっても、マスタデータの更新処理は滞りなく実行され、ＢＥＳ１の障害の影響をＢＥＳ２、ＢＥＳ３、ＢＥＳ４は受けずに済む。すなわちシステムにＢＥＳ１の障害が与える影響を最小限に抑えることができる。

図２は本実施形態のデータベース処理システムの概略構成を示す図である。図２に示す様に本実施形態のデータベース処理システムには、ユーザが作成したアプリケーションプログラム６と、問い合わせやリソース管理等のデータベースシステム全体の管理を行うデータベース管理システム２がある。

上記のデータベース管理システム２は、処理要求受付サーバ（ＦＥＳ）１０、ＤＢアクセスサーバ（ＢＥＳ）２０を具備する。また、データベース管理システム２は、データベースアクセス対象となるデータを永続的に或いは一時的に格納するデータベース３、そしてＤＢ処理サービス適用ＡＰテーブル４００及びＤＢ処理サービス関連テーブル６００を有する。

処理要求受付サーバ（ＦＥＳ）１０は、アプリケーションプログラム６から投入される問合せを受け付けて解析し、ＤＢアクセス要求を生成し、ＤＢアクセスサーバ（ＢＥＳ）２０へＤＢアクセス要求を行う。そしてＤＢアクセスの結果を必要に応じてアプリケーションプログラム６に返す。ＤＢアクセスサーバ（ＢＥＳ）２０は、処理要求受付サーバ（ＦＥＳ）１０からのＤＢアクセス要求を受け取り、要求に従って外部記憶装置上に記憶されるデータベース３をアクセスする。

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

上記処理要求受付サーバ（ＦＥＳ）１０は、問合せの構文解析・意味解析を行い、適切な処理手順を決定し、その処理手順に対応したコードを生成し、ＤＢアクセスサーバ（ＢＥＳ）２０に対してＤＢアクセス要求を行う処理要求制御部２１１を具備している。また、上記処理要求受付サーバ（ＦＥＳ）１０の処理要求制御部２１１では、ＤＢアクセス要求を行う前に要求先ＤＢアクセスサーバのＤＢ処理サービスの状況を判定し、状況に応じて処理要求先を選定する。

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

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

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

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

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

図４は本実施形態のＤＢ処理サービス適用ＡＰテーブル４００の一例を示す図である。図４に示す様にＤＢ処理サービス適用ＡＰテーブル４００のエントリ４０１〜４０３は、ＢＥＳに障害が発生した際にＤＢ処理サービスを停止中状態("Unavailable")として認識し、処理制御させる様に宣言したＡＰの名称を含んでいる。

例えば図１における例として、エントリ４０１にＡＰ"MSTUP"が登録されている。本テーブルエントリへのＡＰ名称の登録は、ＡＰが動作する前に予めＤＢ管理者等のユーザがＤＢＭＳ提供の手段により実施する。また、ＡＰがＤＢＭＳに最初に問合せを行う際に動的に登録することも可能である。

図５は本実施形態のＤＢ処理サービス状況テーブル５００の一例を示す図である。図５に示す様にＤＢ処理サービス状況テーブル５００の個々のエントリ５０１〜５０４は、対応するＢＥＳがＤＢ処理サービスを提供中が停止中かを示す情報を含んでいる。本例では、提供中の状態を"Available"で、停止中の状態を"Unavailable"で示している。

本ＤＢ処理サービスの提供中/停止中とは、実施のＢＥＳがマシン障害等でＤＢ処理が可能かどうかとは独立した概念的なものである。具体的には、図５の例ではＢＥＳ１（５０１）及びＢＥＳ２（５０２）が停止中(Unavailable)、ＢＥＳ３（５０３）及びＢＥＳ４（５０４）が提供中(Available)となっているが、図１の例において実際にマシン障害が発生しＤＢ処理を行うことができないのはＢＥＳ１のみであり、ＢＥＳ２ではＤＢ処理が可能である。停止状態のＢＥＳ１及びＢＥＳ２を停止中と認識するのは図４のＤＢ処理サービス適用テーブルに登録されたＡＰのみである。すなわち、ＡＰ"ＭＳＴＵＰ"からの問合せはＢＥＳ１及びＢＥＳ２はサービス停止状態としてＤＢＭＳ内で処理させる。処理制御に関しては、図７を用いて後記する。

図６は本実施形態のＤＢ処理サービス関連テーブル６００の一例を示す図である。図６に示す様にＤＢ処理サービス関連テーブル６００の各エントリは、サーバマシン障害等に伴いＤＢ処理サービス停止状態とするＢＥＳに関連して停止状態とするＢＥＳの名称を含んでいる。例えば、エントリ６０１はＢＥＳ１を停止状態とする際に、それと連動してＢＥＳ２も停止状態にすることを示している。エントリ６０４及びエントリ６０５で、ＢＥＳ４を停止状態とする際には、ＢＥＳ２及びＢＥＳ３の２つのＢＥＳのＤＢ処理サービスを停止状態にすることを示している。

本テーブルへのエントリ登録は、まずはデータベースシステム構築時にＤＢ管理者等のユーザによって行われる。

図７は本実施形態の処理要求制御部２１１の処理手順を示すフローチャートである。図７に示す様に処理要求受付サーバ（ＦＥＳ）１０の処理要求制御部２１１では、まずＵＡＰ６からのユーザ問合せ５０を通信制御装置３００３により受け取る（ステップ７０１）。

次に受け取った問合せ要求を解析して処理要求先候補を決定する（ステップ７０２）。要求先候補は、一般にＤＢＭＳが管理するディクショナリ情報を参照して決定する。そして、ＤＢアクセスサーバ（ＢＥＳ）２０のサービス可能状態により処理制御されるＡＰを示すＤＢ処理サービス適用ＡＰテーブル４００をサーチし（ステップ７０３）、当該ＡＰに関連するテーブルエントリが見つかったかどうかを判断する（ステップ７０４）。テーブルエントリが見つからなかった場合にはステップ７０９に進み、全ての処理要求先候補を取得してＤＢアクセス要求先として決定する。またＵＡＰ６に関連するテーブルエントリが見つかった場合には、ステップ７０５に進み、処理要求先候補を取得してメモリに格納する。

次に、取得した候補であるＢＥＳの名称をキーとしてＤＢ処理サービス状況テーブル５００をサーチし（ステップ７０６）、当該ＢＥＳに関連するテーブルエントリのサービス状況は"Available"かを判定する（ステップ７０７）。サービス状況が"Available"の場合には、ステップ７０８に進み、当該ＢＥＳをＤＢアクセス要求先に決定し、ＤＢアクセス要求を決定したＢＥＳへ送信する（ステップ７１０）。ステップ７０７でサービス状況が"Available"ではない、すなわち"Unavailable"の場合、当該ＢＥＳをＤＢアクセス要求先には決定せず、これまで決定したＤＢアクセス要求先のＢＥＳへＤＢアクセス要求を送信する（ステップ７１０）。

ＦＥＳからＤＢアクセス要求を受信したデータ処理制御部２２１では、その受け取ったＤＢアクセス要求に従ってデータベース３上のデータのアクセス制御等を行い、ＤＢアクセス結果をＦＥＳへ送信する。

図８は本実施形態の処理要求制御部２１１の処理の続きを示す図である。その後、ステップ７１１では、送信したＢＥＳからのＤＢアクセス結果を受け取り、ＤＢアクセス結果が全て正常終了かを判定する（ステップ７１２）。ＤＢアクセス結果が全て正常終了の場合、問合せ結果を正常終了としてＡＰに返す（ステップ７１３）。ＤＢアクセス結果にエラー終了が含まれていた場合、ステップ７１４に進み、正常終了を返したＢＥＳに対して取り消し処理(ロールバック)を要求する。その後、問合せ結果をエラー終了としてＡＰに返す（ステップ７１５）。

図９は本実施形態のＢＥＳ障害時の対処の処理手順を示すフローチャートである。ＢＥＳを配置及び稼動しているサーバマシンのハードウェア障害等で、そのＢＥＳでのＤＢ処理が実行できなくなってしまった場合に、ＤＢＭＳが提供するユティリティをユーザ若しくはＤＢＭＳ外の運用管理プログラムにより実行することにより、本対処が実施される。

本対処により、ＤＢ処理が実行できなくなってしまったＢＥＳ及びそれに関連するＢＥＳのＤＢ処理サービスを概念的に停止状態に変更し、図４に記載のＤＢ処理サービス適用ＡＰテーブル４００に登録されたＡＰの実行制御をＤＢＭＳが行う。

本対処のステップとしては、まず本対処を実現するユティリティに指定されたＢＥＳ名称を用いてＤＢ処理サービス関連テーブル６００のエントリを特定し、そのエントリに含まれる「関連サービス（ＢＥＳ）」を取得する（ステップ８０１）。次に、前記取得した「関連サービス（ＢＥＳ）」に関連するＤＢ処理サービス状況テーブル５００のエントリを特定し、そのエントリの「サービス状況」を"Unavailable"に変更する（ステップ８０２）。

先の図１を用いて説明した例では、ＢＥＳ１を配置しているサーバマシンに障害が発生した際に、本対処によりＢＥＳ１及びＢＥＳ２をＤＢ処理サービス停止状態に変更している。

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

以上説明した様に本実施形態のデータベース処理システムによれば、サービス可能状態の情報処理装置を処理要求先として決定して処理要求を行うので、ある情報処理装置に障害が発生した場合でも、その影響を局所化してシステム全体に与える影響を最小限にすることが可能である。

本実施形態のデータベース処理システムの概念を示す図である。本実施形態のデータベース処理システムの概略構成を示す図である。本実施形態のコンピュータシステムのハードウェア構成の一例を示す図である。本実施形態のＤＢ処理サービス適用ＡＰテーブル４００の一例を示す図である。本実施形態のＤＢ処理サービス状況テーブル５００の一例を示す図である。本実施形態のＤＢ処理サービス関連テーブル６００の一例を示す図である。本実施形態の処理要求制御部２１１の処理手順を示すフローチャートである。本実施形態の処理要求制御部２１１の処理の続きを示す図である。本実施形態のＢＥＳ障害時の対処の処理手順を示すフローチャートである。

符号の説明

６…ユーザアプリケーションプログラム、１０…処理要求受付サーバ（ＦＥＳ）、２０…ＤＢアクセスサーバ（ＢＥＳ）、３０…処理(ＤＢアクセス)要求、５０…ユーザ問合せ、６０…分割マスタ表、６１…ＤＢ格納領域、６２…分割テーブル、４００…ＤＢ処理サービス適用ＡＰテーブル、５００…ＤＢ処理サービス状況テーブル、２…データベース管理システム、３…データベース、４…テーブル、２１１…処理要求制御部、２２１…データ処理制御部、６００…ＤＢ処理サービス関連テーブル、３０００、３１００及び３２００…情報処理装置、３００１…主記憶装置、３００２…ＣＰＵ、３００３…通信制御装置、３００４…Ｉ／Ｏ制御装置、３００５…外部記憶装置、３００６…端末、３００７…ネットワーク、３００８…アプリケーションプログラム、３３００…プログラム、４０１〜４０３…エントリ、５０１〜５０４…エントリ、６０１〜６０５…エントリ。

Claims

データベースを複数に分割した各分割データベースに対して情報処理装置を関連付けてデータ処理を行うデータベース処理システムにおけるデータベース処理方法において、
前記データベース処理システムは処理要求制御部とデータ処理制御部を備え、
前記処理要求制御部が、データベースへの問合せを通信装置により受信した際に、各情報処理装置がサービス可能状態であるかどうかを示すＤＢ処理サービス状況テーブルを記憶装置から読み出して、前記受信した問合せを処理する情報処理装置の内で前記ＤＢ処理サービス状況テーブルにおいてサービス可能状態であるものを処理要求先として決定し、その決定した処理要求先の情報処理装置に対して前記問合せに対応する処理要求を通信装置により送信する第１のステップと、
前記データ処理制御部が、前記処理要求を通信装置により受信して、その受信した処理要求に従ってデータベース上のデータを処理し、その処理結果を通信装置により当該処理要求の送信元へ送信する第２のステップと、
前記処理要求制御部が、前記処理要求を送信した全ての情報処理装置から処理結果を通信装置により受信し、それらの処理結果が正常終了を示している場合に、前記問合せの結果を示す問合せ結果を正常終了としてその問合せの送信元へ通信装置により送信する第３のステップと、
前記データベース処理システムが、情報処理装置で障害が発生した場合に、その情報処理装置がサービス可能状態ではないことを示す情報を前記ＤＢ処理サービス状況テーブルに格納する第４のステップと、
前記データベース処理システムが、ある情報処理装置のサービス停止状態に関連してサービス停止状態となる情報処理装置を示すＤＢ処理サービス関連テーブルを記憶装置から読み出して、前記障害の発生した情報処理装置と関連する情報処理装置の情報を前記ＤＢ処理サービス関連テーブルから取得し、その関連する情報処理装置がサービス可能状態ではないことを示す情報を前記ＤＢ処理サービス状況テーブルに格納する第５のステップとを有することを特徴とするデータベース処理方法。
前記処理要求制御部は、前記第１のステップにおいて、データベースへの問合せを通信装置により受信した際に、前記情報処理装置のサービス可能状態により処理制御されるアプリケーションプログラムを示すＤＢ処理サービス適用ＡＰテーブルを記憶装置から読み出して、前記問合せを送信したアプリケーションプログラムが前記ＤＢ処理サービス適用ＡＰテーブル中に示されたものである場合に、前記サービス可能状態による処理要求先の決定を行うことを特徴とする請求項１に記載されたデータベース処理方法。
前記処理要求制御部は、前記問合せを送信したアプリケーションプログラムが前記ＤＢ処理サービス適用ＡＰテーブル中に示されたものでない場合に、全ての情報処理装置を処理要求先として決定することを特徴とする請求項２に記載されたデータベース処理方法。
前記処理要求制御部は、前記第３のステップにおいて、前記受信した処理結果中にエラー終了を示すものが含まれている場合に、正常終了を示す処理結果を送信した情報処理装置に対して、当該処理を取り消す取り消し処理要求を通信装置により送信し、前記問合せ結果をエラー終了としてその問合せの送信元へ通信装置により送信することを特徴とする請求項１乃至請求項３のいずれか１項に記載されたデータベース処理方法。
前記処理要求制御部は、前記第１のステップにおいて、各情報処理装置に関連付けられた分割データベース中のマスタデータの更新を行う為の問合せを通信装置により受信した場合に、それらの情報処理装置の内でサービス可能状態であるものをマスタデータ更新の処理要求先として決定することを特徴とする請求項１乃至請求項４のいずれか１項に記載されたデータベース処理方法。
データベースを複数に分割した各分割データベースに対して情報処理装置を関連付けてデータ処理を行うデータベース処理システムにおいて、
データベースへの問合せを通信装置により受信した際に、各情報処理装置がサービス可能状態であるかどうかを示すＤＢ処理サービス状況テーブルを記憶装置から読み出して、前記受信した問合せを処理する情報処理装置の内で前記ＤＢ処理サービス状況テーブルにおいてサービス可能状態であるものを処理要求先として決定し、その決定した処理要求先の情報処理装置に対して前記問合せに対応する処理要求を通信装置により送信し、前記処理要求を送信した全ての情報処理装置から処理結果を通信装置により受信し、それらの処理結果が正常終了を示している場合に、前記問合せの結果を示す問合せ結果を正常終了としてその問合せの送信元へ通信装置により送信する処理要求制御部と、
前記処理要求を通信装置により受信して、その受信した処理要求に従ってデータベース上のデータを処理し、その処理結果を通信装置により当該処理要求の送信元へ送信するデータ処理制御部とを備え、
情報処理装置で障害が発生した場合に、その情報処理装置がサービス可能状態ではないことを示す情報を前記ＤＢ処理サービス状況テーブルに格納し、
ある情報処理装置のサービス停止状態に関連してサービス停止状態となる情報処理装置を示すＤＢ処理サービス関連テーブルを記憶装置から読み出して、前記障害の発生した情報処理装置と関連する情報処理装置の情報を前記ＤＢ処理サービス関連テーブルから取得し、その関連する情報処理装置がサービス可能状態ではないことを示す情報を前記ＤＢ処理サービス状況テーブルに格納することを特徴とするデータベース処理システム。
データベースを複数に分割した各分割データベースに対して情報処理装置を関連付けてデータ処理を行うデータベース処理システムにおけるデータベース処理方法をコンピュータに実行させる為のプログラムにおいて、
前記データベース処理システムは処理要求制御部とデータ処理制御部を備え、
前記処理要求制御部が、データベースへの問合せを通信装置により受信した際に、各情報処理装置がサービス可能状態であるかどうかを示すＤＢ処理サービス状況テーブルを記憶装置から読み出して、前記受信した問合せを処理する情報処理装置の内で前記ＤＢ処理サービス状況テーブルにおいてサービス可能状態であるものを処理要求先として決定し、その決定した処理要求先の情報処理装置に対して前記問合せに対応する処理要求を通信装置により送信するステップと、
前記データ処理制御部が、前記処理要求を通信装置により受信して、その受信した処理要求に従ってデータベース上のデータを処理し、その処理結果を通信装置により当該処理要求の送信元へ送信するステップと、
前記処理要求制御部が、前記処理要求を送信した全ての情報処理装置から処理結果を通信装置により受信し、それらの処理結果が正常終了を示している場合に、前記問合せの結果を示す問合せ結果を正常終了としてその問合せの送信元へ通信装置により送信するステップと、
前記データベース処理システムが、情報処理装置で障害が発生した場合に、その情報処理装置がサービス可能状態ではないことを示す情報を前記ＤＢ処理サービス状況テーブルに格納するステップと、
前記データベース処理システムが、ある情報処理装置のサービス停止状態に関連してサービス停止状態となる情報処理装置を示すＤＢ処理サービス関連テーブルを記憶装置から読み出して、前記障害の発生した情報処理装置と関連する情報処理装置の情報を前記ＤＢ処理サービス関連テーブルから取得し、その関連する情報処理装置がサービス可能状態ではないことを示す情報を前記ＤＢ処理サービス状況テーブルに格納するステップとをコンピュータに実行させることを特徴とするプログラム。