JPH10111825A - 複数データベース一致化更新方法および装置 - Google Patents

Abstract

(57)【要約】 【課題】 更新するデータの特徴および更新する種別等
に応じて、適切なデータベースの更新方法を動的に選択
することのでき、また複数のサーバのうちの一つに障害
が発生しても、データベースの更新が可能となる複数デ
ータベース一致化更新方法を提供することにある。 【解決手段】 サーバ１と２をＬＡＮまたはＷＡＮ３で
接続するシステムにおいて、サービス処理機能部１１ま
たは２１は、更新するデータの特徴および更新する種別
等に応じて決定されたデータベースの更新方法を送出す
る。データベース同期管理機能部１２または２２は、該
更新方法にしたがって、サービスデータＤＢ１６または
２６に記憶されているデータの更新を行う。該更新方法
としては、常に一致化、差分管理で一致化、差分管理不
要の３方法がある。差分反映管理機能部１３または２３
は前記差分管理で一致化の処理を行う。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は複数データベース
一致化更新方法および装置に関し、特に複数データベー
スの同期更新を、更新するデータの特徴、更新する種別
等と関連させて可能とする交換網を実現できるようにし
た複数データベース一致化更新方法および装置に関す
る。

【０００２】

【従来の技術】図１０を参照して、従来の交換網のイン
テリジェントネットワークにおいて、同一サービスを複
数のサービス制御ノード（ＳＣＰ）に負荷分散すること
により、信頼性を確保するようにした方式の一例を説明
する。従来の交換網のインテリジェントネットワーク
は、図示されているように、複数個のインテリジェント
ネットワーク対応交換機５１、５２と、該インテリジェ
ントネットワーク対応交換機５１、５２から高機能サー
ビス要求ｑを受ける複数個のＳＣＰ５３、５４と、該Ｓ
ＣＰを管理するサービス管理システム（ＳＭＰ）５５と
から構成されている。

【０００３】前記インテリジェントネットワーク対応交
換機５１とＳＣＰ５３は、信号リンクで接続されてお
り、該ＳＣＰ５３とＳＭＰ５５とはＬＡＮまたはＷＡＮ
等からなるデータ回線ａで接続されている。同様に、イ
ンテリジェントネットワーク対応交換機５２とＳＣＰ５
４は、信号リンクで接続されており、該ＳＣＰ５４とＳ
ＭＰ５５ともそれぞれデータ回線ａで接続されている。
前記ＳＣＰ５３、５４は、それぞれサービス処理部５３
ａ、５４ａと、データベース５３ｂ、５４ｂを有してい
る。また、前記ＳＭＰ５５は、データを管理する処理を
実行する。

【０００４】さて、インテリジェントネットワークの信
頼性を確保するためには、複数のＳＣＰ内データベース
において、時々刻々と変化するデータ内容をリアルタイ
ムに一致化しておく必要がある。従来、データベース更
新を要するサービスの場合には、データの更新を行った
ＳＣＰから、前記データ回線ａに更新要求通知ｂを乗せ
てＳＭＰ５５に通知し、該ＳＭＰ５５から他方のＳＣＰ
に更新指令ｃを送ることによりデータベース更新を要求
することにより、複数のＳＣＰ５３、５４のデータベー
スを一致化させるのが一般的であった。

【０００５】しかし、災害あるいは設備障害等によりＳ
ＭＰ５５が稼動不可能な状態に陥った場合には、全ての
ＳＣＰ５３、５４のデータベースに対して同時に更新す
ることができず、サービスが提供不可能な状態となる。

【０００６】この問題を解決するために、本発明者等は
図１１のような方式を考えた。この方式は、複数のＳＣ
Ｐ間をデータ回線ａで結び、複数のＳＣＰ６３、６４が
有しているデータベースのデータ内容を更新する場合、
ＳＭＰ６５を経由せず、同一サービスを提供している複
数のＳＣＰ６３、６４のデータベースの間で直接、同期
的に更新するようにしたものである。この方式によれ
ば、ＳＭＰ６５が稼動していない状態においてもサービ
スの提供を継続することが可能となり、ＳＭＰ５５が災
害および設備障害により稼動不可能な状態に陥っても、
全てのＳＣＰ６３、６４のデータベースに対して同時に
更新することができるようになる。

【０００７】

【発明が解決しようとする課題】しかしながら、前記し
た後者の方式には、次のような問題があると考えられ
る。すなわち、データベースを参照/ 更新しながら、処
理を実行するＳＣＰを、負荷分散および災害/ 障害に備
えた危険分散を目的として分散させ、それぞれのＳＣＰ
で同一処理を提供するためには、各ＳＣＰ内での処理で
発生するデータベース更新の内容を、分散されたデータ
ベースに対してリアルタイムに一致化する必要がある。
従来、分散されたデータベースを一致化する一般的な技
術としては、２フェーズコミットによる方式があるが、
この方式は常に分散された複数のデータベースの同期を
完全に保証するために、いずれか一つのデータベースの
障害により更新ができなかった場合には、全てのデータ
ベースへの更新を不可能とする。このため、ある一箇所
のＳＣＰまたはデータベースに障害が発生すると、全Ｓ
ＣＰの処理が実施不可能となってしまい、災害/ 障害に
備えた危険分散という目的では、本方式は適さないとい
う問題があった。

【０００８】また、一箇所のＳＣＰで発生したデータベ
ース更新内容を一定周期で他のＳＣＰのデータベースへ
コピーする方式もあるが、複数のデータベース間でデー
タが一致化されるまでに時間差があるため、データ更新
のリアルタイム性が厳しく要求される交換網における処
理では、本方式は適さないという問題があった。なお、
本発明は交換網に限定されないので、以降ではＳＣＰに
代えて、サーバと呼ぶことにする。

【０００９】この発明の目的は、前記した従来技術の問
題点を除去し、更新するデータの特徴および更新する種
別等に応じて、適切なデータベースの更新方法を動的に
選択することのできる複数データベース一致化更新方法
および装置を提供することにある。また、他の目的は、
複数のサーバのうちの一つのサーバに障害が発生して
も、データベースの更新が可能となる複数データベース
一致化更新方法および装置を提供することにある。ま
た、さらに他の目的は、複数のデータベース間でデータ
が一致化されるまでに要する時間差を極力低減した複数
データベース一致化更新方法および装置を提供すること
にある。

【００１０】

【課題を解決するための手段】前記した目的を達成する
ために、この発明は、データベースを有する複数のサー
バをネットワークで接続し、それぞれのサーバがローカ
ルーＤＢとリモートーＤＢを直接更新することにより、
前記複数のサーバ内のデータベース内容をリアルタイム
に一致化させるようにした複数データベース一致化更新
方法において、少なくとも、更新するデータの特徴およ
び更新する種別により、予めデータベースの更新方法を
決定しておき、該データベースの更新方法を、該更新す
るデータの特徴および更新する種別に応じて、動的に選
択するようにした点に、第１の特徴がある。

【００１１】この特徴によれば、データベースの更新方
法を、更新するデータの特徴および更新する種別に応じ
て、動的に選択するようにしたので、サービスの提供に
支障をきたさない、かつ信頼性の高い複数サーバ間のデ
ータベースの一致化を達成することができる。

【００１２】また、本発明は、前記データベースの更新
方法の決定に、他のサーバとの通信状態の条件を加えた
点に、第２の特徴がある。この特徴によれば、システム
に障害が起きても、安定的にサービスの提供を続行する
ことができる。

【００１３】また、本発明は、複数のサーバをネットワ
ークで接続された複数のサーバのデータベースの内容を
リアルタイムに一致化させるようにした複数データベー
ス一致化更新装置において、更新するデータの特徴およ
び更新する種別に応じて、データベースの更新方法を動
的に選択し送出するサービス処理機能部と、該サービス
処理機能部から受取ったデータベースの更新方法に従っ
て、ローカルーＤＢとリモートーＤＢの同期管理を実行
するデータベース同期管理機能部と、前記データベース
の更新方法の一つである差分管理による更新方法を実行
するために使用される差分反映管理機能部と、前記更新
されるデータを格納するデータベースとを具備した点に
第３の特徴がある。

【００１４】この特徴によれば、データベースの更新方
法を、更新するデータの特徴および更新する種別に応じ
て、動的に選択し、ローカルーＤＢとリモートーＤＢの
同期管理を行うことができる装置を提供することができ
る。

【００１５】

【発明の実施の形態】以下に、図面を参照して、本発明
を詳細に説明する。図１は本発明の複数データベース一
致化更新装置の一実施形態を示すブロツク図である。図
において、サーバ１、２は、図１０または図１１のサー
ビス制御ノード（ＳＣＰ１，２）に相当するものであ
り、それぞれは図示されていないインテリジェントネッ
トワーク対応交換機に接続されている。また、サーバ
１、２は、ＬＡＮまたはＷＡＮ３により、互いに接続さ
れている。

【００１６】前記サーバ１は、サービスデータの更新の
要求元であるサービス処理機能部１１と、データベース
の同期管理を実行するデータベース同期管理機能部１２
と、差分反映管理機能部１３と、データベース管理シス
テム１５と、前記サービスデータを蓄積するサービスデ
ータデータベース（ＤＢ）１６と、差分管理データベー
ス（ＤＢ）１７とから構成されている。前記データベー
ス同期管理機能部１２と差分反映管理機能部１３とは、
データベース管理機能部を構成している。なお、サーバ
２はサーバ１と同構成であるので説明を省略する。

【００１７】次に、前記サーバ１、２の動作を、図２〜
図９を参照して説明する。なお、サーバ１、２は同じ動
作をするので、サーバ１を代表として説明する。

【００１８】図２のステップＳ１では、サービス処理機
能部１１はデータベース同期管理機能部１２にデータベ
ースの更新要求をする。この時、サービス処理機能部１
１は、更新要求するデータの特徴（例えば、クレジット
カード通話サービスにおける暗証番号、プリペイドカー
ド通話サービスにおける残度数等）、更新の種別（登
録、書き換え、削除等）および更新するデータの内容、
ならびに他のサーバとの通信状態（正常、他のサーバ障
害中、および他サーバ間データ回線障害中）により決定
されるオプション番号を、該データベース同期管理機能
部１２に提供する。このオプション番号は、後述される
ように、データベースを常に一致化させる、差分管理レ
ベルで一致化させる、および差分管理不要の３つからな
り、それぞれ、オプション番号、、およびと呼ぶ
ことにする。

【００１９】ステップＳ２では、データベース同期管理
機能部１２は、他のサーバとの通信状態は正常であるか
否か、正常でない場合には、他のサーバが障害中である
かあるいは他のサーバとの間のデータ回線が障害中であ
るか否かの判断をする。そして、正常であればステップ
Ｓ３に進む。また、他のサーバが障害中であればステッ
プＳ４へ進む。さらに、他のサーバとの間のデータ回線
が障害中であれば、ステップＳ５に進む。図１のシステ
ムの場合、サーバ２が正常であればステップＳ３に進
み、サーバ２が障害中であればステップＳ４へ進み、Ｌ
ＡＮまたはＷＡＮ３が障害中であれば、ステップＳ５に
進む。これらのステップＳ３、Ｓ４およびＳ５では、前
記ステップＳ１でサービス処理機能部から、他のサーバ
との通信状態と関連させて提供されたオプション番号に
より、以降の処理手順を選択する。ここで、該サービス
処理機能部１１から、他のサーバとの通信状態と関連さ
せて提供されるオプション番号の一例を、図８を参照し
て説明する。図８に示されているように、例えば、デー
タがクレジットカード通話サービスにおける暗証番号
で、更新する種別が書き換えの場合であって、他サーバ
が正常の時にはオプション番号、他のサーバが障害中
の時にはオプション番号、他サーバ間データ回線障害
中の時にはオプション番号が提供される。また、デー
タがプリペイドカード通話サービスにおけるカード使用
中状態で、更新する種別が書き換え、更新するデータの
内容が未使用中→使用中の場合であって、他サーバが正
常の時および他のサーバが障害中の時にはオプション番
号、他サーバ間データ回線障害中の時にはオプション
番号が提供される。さらに、データがクレジットカー
ド通話サービスにおける短縮ダイヤル番号で、更新する
種別が登録の場合であって、他サーバが正常の時および
他のサーバが障害中の時にはオプション番号、他サー
バ間データ回線障害中の時にはオプション番号が提供
される。なお、図８中の「更新するデータの内容」の欄
の“―”は、更新するデータの内容は何でもよいことを
示している。

【００２０】さて、図２の前記ステップＳ３では、前記
ステップＳ１で指定された、他のサーバとの通信状態が
正常である場合のオプション番号が〜のいずれであ
るかの判断がなされる。該オプション番号がの場合に
は図３の処理に進み、の場合には図４の処理に進み、
の場合には図５の処理に進む。ステップＳ４、ステッ
プＳ５でも、前記と同様の処理がなされ、それぞれ、図
６、図７の処理に進む。

【００２１】次に、他のサーバとの通信状態が正常な場
合の処理を図３〜図５を参照して説明する。図３では、
データベースを常に一致化させる処理が行われる。な
お、以降の説明において、自サーバ内にあるサービスデ
ータＤＢをローカルーＤＢと呼び、他のサーバ内にある
サービスデータＤＢをリモートーＤＢと呼ぶことにす
る。 ステップＳ１１では、データベースの更新処理を
開始する前に、これから更新するデータを、自サーバの
同一サービス処理機能部１１、および他サーバの同一サ
ービス処理機能２１が同時に使用できないようにするた
め、ローカルーＤＢの該当データに対してロックを掛け
る。次に、ステップＳ１２に進み、更新内容をローカル
ーＤＢに対して更新する。この時はまだ更新することを
決定しない。すなわち、まだコミットしない。ステップ
Ｓ１３では、ステップＳ１２の更新が成功したか否かの
判断がなされる。この判断が成功した場合には、ステッ
プＳ１４に進み、リモートーＤＢに対して更新を行う。
このリモートーＤＢの更新は、データベース管理システ
ム１５と２５の働きにより行われる。

【００２２】次いで、ステップＳ１５にて、リモートー
ＤＢの更新が成功したか否かの判断をする。この判断が
成功した場合にはステップＳ１６に進み、両データベー
スの更新をコミット（決定）する。この時のＤＢのコミ
ット方式は、従来から行われている２フェーズコミット
方式を用い、コミット処理時において障害に遭遇するこ
とによって、ＤＢの不一致が発生することを防止する。
このように、コミットに成功した場合には、ローカルー
ＤＢ側に掛けられたロックが解除される。その後、ステ
ップＳ１７に進み、更新要求元のサービス処理機能部１
１へＤＢ更新成功を返送する。

【００２３】一方、ステップＳ１３でローカルーＤＢの
更新が失敗したと判断された場合には、ステップＳ１８
に進んで、サービス処理機能部１１へＤＢの更新失敗を
通知する。また、前記ステップＳ１５でリモートーＤＢ
の更新が失敗したと判断された場合には、ステップＳ１
９に進んで、ローカルーＤＢの更新を取り消す（すなわ
ち、ロールバックする。）。そして、ローカルーＤＢの
更新データのロックを解除する。ステップＳ２０では、
サービス処理機能部１１へ、ＤＢの更新失敗を通知す
る。上記の各々の場合、サービス処理機能部１１は図示
されていないインテリジェントネットワーク対応交換機
に、サービスの提供の中止等の指示を送出する。

【００２４】以上の処理は、例えばクレジットカード通
話サービスにおける暗証番号、短縮ダイヤル番号等の書
き換えに用いると好適である。一般に、利用者がクレジ
ットカード通話サービスを利用する場合、利用者からの
アクセスがサーバ１にされるか、サーバ２にされるかは
状況によってきまることになり、不定である。したがっ
て、これらの番号に関するデータは、サーバ１と２の両
方のサービスデータＤＢ１６と２６において常に一致し
ていないと、利用者に迷惑をかけることになるからであ
る。

【００２５】次に、図４を参照して、差分管理レベルで
一致化させる処理について説明する。この処理は、何等
かの原因により、リモートーＤＢを更新することができ
なかった場合には、ローカルーＤＢに対しての更新を完
了し、リモートーＤＢに対する更新内容は、自サーバ内
の差分管理ＤＢ１７で更新内容を保持し、原因が排除さ
れた時点で自動的にリモートーＤＢを更新し、一致化す
るようにしたものである。 ステップＳ２１、Ｓ２２で
は、更新処理を開始する前に、これから更新するデータ
が自サーバの同一サービス処理機能部１１および他サー
バの同一サービス処理機能部２１が使用できないように
するために、ローカルーＤＢとリモートーＤＢの該当デ
ータに対してロックを掛ける。この時、リモートーＤＢ
に対するロックは、既に他の同一サービス処理機能部２
１によりロックが掛けられている場合には、そのロック
が解除されるのを待ち合わせずエラーとするロック獲得
方法を用いる（従来のデータベース管理システムで有し
ている機能）。これにより、他のサーバの処理から同時
に同一データに対する更新要求が発生した場合に、双方
でロック解除を待ち合わせるデッドロック現象を回避す
る。

【００２６】ステップＳ２３では、ローカルーＤＢを更
新する。なお、この時にはまだコミットしない。ステッ
プＳ２４では、該ローカルーＤＢの更新が成功したか否
かの判断をする。成功した場合には、ステップＳ２５に
進み、リモートーＤＢを更新する。ステップＳ２６で
は、この更新が成功したか否かの判断をする。成功した
場合には、ステップＳ２７に進み、まず、ローカルーＤ
Ｂに対してコミットする。その後、リモートーＤＢに対
してコミットする。またコミットすることにより両ＤＢ
に掛けられたロックが解除される。ここでは、２フェー
ズコミット方式は処理が重いため用いない。次にステッ
プＳ２９に進み、更新要求元のサービス処理機能部１１
へＤＢ更新成功を返送する。

【００２７】次に、前記ステップＳ２４の判断が否定の
時、すなわちローカルーＤＢの更新に失敗した時には、
ステップＳ３０に進んで、サービス処理機能部１１へＤ
Ｂ更新失敗を通知する。また、前記ステップＳ２６の判
断が否定の時、すなわちリモートーＤＢに対する更新が
失敗した場合にはステップＳ３１に進み、データベース
管理システム１５の働きにより、自サーバ内の差分管理
ＤＢ１７に更新できなかったデータ内容を格納する。次
いで、ステップＳ３２に進み、ローカルーＤＢの更新に
対してはコミットする。そして、ステップＳ２９に進
み、更新要求元のサービス処理機能部１１に対しては，
ＤＢ更新成功を返送する。

【００２８】以上の処理は、例えばプリペイドカードの
残度数の管理に用いると好適である。すなわち、プリペ
イドカードの残度数の管理をサービスデータＤＢで管理
してサービスを実現する場合には、通話終了後に、元の
通話料金から今回の通話料金を減算するように、サービ
スーＤＢ更新を行う必要がある。そこで、他のサーバの
サービスーＤＢが障害中等の理由で更新できなかった場
合には、自サーバのＤＢに対しては減算を行い、他のサ
ーバのＤＢに対しては、自サーバ内でＤＢ間の更新差分
としてその更新内容を保存する。そして、障害回復後
に、他サーバに対して更新処理を行うことにより、障害
回復時には両サーバのＤＢ内容を一致化させる。このよ
うに通話終了後に後処理的に更新するような特徴をもっ
たデータに対しては、本方式を採用することによりサー
ビス品質を保証する。

【００２９】次に、図５を参照して、差分管理不要とし
た処理について説明する。この処理は、通常は二式のサ
ービスデータＤＢを同期的に更新するが、何等かの原因
により、リモートーＤＢを更新することができなかった
場合には、ローカルーＤＢに対しての更新を完了し、リ
モートーＤＢに対しては、その更新内容を反映しない方
式であり、以下の処理手順により実現する。

【００３０】ステップＳ４１〜Ｓ５０は図４のステップ
Ｓ２１〜Ｓ３０と同じ処理であるので、説明を省略す
る。次に、ステップＳ４６にてリモートーＤＢに対する
更新結果の判断が否定になった時、すなわちリモートー
ＤＢに対する更新が失敗した場合には、ローカルーＤＢ
に対する更新に対してコミットし、更新要求元のサービ
ス処理機能部１１に対してはＤＢ更新成功を返送する。

【００３１】以上の処理は、例えばプリペイドカード通
話サービスにおけるカード使用中状態を未使用中から使
用中に書き換える時のような、何らかの状態を管理する
データで、通話が終了することにより、初期値に戻るよ
うな特徴をもったデータに適用すると好適である。プリ
ペイドカードの情報をサーバのサービスデータＤＢで管
理して実現する場合には、顧客がプッシュボタンにより
カード番号等を入力し、受信されたカード番号をサーバ
のサービス処理機能部１１または２１によりサービスデ
ータＤＢを照合して認証を行う方式となる。この場合、
顧客の不正な利用方法により、同時に複数の電話機から
同一カード番号による通話要求が発生する可能性が有
り、この場合には、同時に一通話のみ許容し、他の通話
要求は拒否できるような機能が必要となる。この機能の
実現方法として、サービスデータＤＢで管理されている
のプリペイドカード番号毎にカードが使用中か否のデー
タを管理する。そして、通話開始要求時に使用中状態に
ＤＢを更新し、通話終了時に未使用状態に更新し、この
情報を照合することにより通話の許容/ 拒否の判断を行
う。

【００３２】このサービスを負荷分散および災害/ 障害
対策として危険分散のために図１のような構成とした場
合には、どちらのサーバにサービス要求が送られるか特
定できないため、リアルタイムに両サーバのＤＢを一致
化させる必要がある。ここで、通話開始要求時にカード
使用中データを使用中状態に更新するが、この場合の更
新方式として、常に二式のデータベースを一致化させる
更新方式、すなわち前記２フェーズコミット方式を用い
ると、他サーバが障害の場合には自サーバのＤＢも更新
することができないため、サービスの提供が不可能にな
るという不具合が生ずる。

【００３３】また、差分管理で一致化させる方式を用い
た場合には次のような問題が発生する。通話開始要求時
に、他サーバが障害等により他サーバのＤＢを更新でき
なかった場合には、自サーバ内で更新内容を差分データ
として管理するが、該当通話が通話中に障害が復旧し、
差分データを自動的に他サーバへ反映する前に通話が終
了した場合には、自サーバのＤＢのカード使用中データ
は未使用状態となるが、他サーバのＤＢのカード使用中
データは、(1) 未使用状態に更新、(2) 差分データから
使用中状態に更新、の順序で更新されることになる（更
新が発生した時刻順と逆転して更新される）。このた
め、最終的に両ＤＢ間で不一致な状態となってしまい、
以降、ＤＢの内容が使用中状態となっている他サーバに
対してサービス要求が行われると、実際は未使用中にも
かかわらず、通話が規制されるという不具合が生ずる。

【００３４】一方、通話終了時に未使用状態に更新する
場合には、差分管理で一致化させる方式により更新を行
うことにより、障害が発生しても、差分データとして管
理することにより、障害復旧後の最終的には未使用状態
になることを保証する。

【００３５】このように何らかの状態を管理するデータ
で、通話が終了することにより、初期値に戻るような特
徴をもったデータに対しては、状態の値を変える場合に
は差分管理を行わない方式を採用し、状態を初期値に戻
す場合には差分管理で一致化させる方式を採用すること
によりサービス品質を保証する。

【００３６】次に、図２のステップＳ２において、他の
サーバが障害中と判断されステップＳ４に進んだ時の動
作を、図６を参照して説明する。該ステップＳ４では、
前記ステップＳ１において、サービス処理機能部１１か
ら、他のサーバが障害中である場合のオプション番号の
選択がなされる。オプション番号がと指定されていた
場合には、ステップＳ６０に進み、該サービス処理機能
部１１へＤＢ更新失敗を通知して処理を終了する。ま
た、オプション番号と指定されていた場合には、ステ
ップＳ６１に進み、ローカルーＤＢの更新データをロッ
クし、該更新データを使用できないようにする。その
後、ステップＳ６２にて、該ローカルーＤＢを更新す
る。ステップＳ６３では、更新結果が成功したか否かの
判断をする。この判断が肯定の時には、ステップＳ６４
に進んで、リモートーＤＢ反映用のデータを、自サーバ
の差分管理ＤＢに格納する。ステップＳ６５では、ロー
カルーＤＢをコミットし、該ローカルーＤＢの更新デー
タのロックを解除する。ステップＳ６６では、サービス
処理機能部１１へＤＢ更新成功を通知する。なお、前記
ステップＳ６３の判断が否定の時には、ステップＳ６７
に進んで、サービス処理機能部１１へＤＢ更新不成功を
通知する。

【００３７】次に、サービス処理機能部１１からオプシ
ョン番号と指定されていた場合には、ステップＳ７１
に進む。ステップＳ７１では、ローカルーＤＢの更新デ
ータをロックし、ステップＳ７２では、該ローカルーＤ
Ｂを更新する。ステップＳ７３では、この更新結果が成
功したか否かの判断がなされ、この判断が肯定の時に
は、ステップＳ７４に進んで、該ローカルーＤＢをコミ
ットする。そして、該ローカルーＤＢの更新データのロ
ックを解除する。ステップＳ７５では、サービス処理機
能部１１へＤＢ更新成功を通知する。なお、前記ステッ
プＳ７３の判断が否定の時には、ステップＳ７６に進ん
で、サービス処理機能部１１へＤＢ更新不成功を通知す
る。以上のように、他方のサーバが障害中の場合には、
前記図３〜図５に比べて、処理の簡略化を行う。

【００３８】次に、図２のステップＳ２において、他の
サーバとの間のデータ回線が障害中と判断されステップ
Ｓ５に進んだ時の処理を、図７に示す。ステップＳ５で
は、前記ステップＳ１において、サービス処理機能部１
１から、他サーバ間データ回線が障害中である場合のオ
プション番号の選択がなされる。なお、図７の処理は、
図６の処理と同じであるので、説明を省略する。

【００３９】上記したように、図６の処理と図７の処理
とは同じであるが、これらの処理の適用の違いについ
て、クレジットカード通話サービスの短縮ダイヤル番号
登録を例として説明する。

【００４０】他のサーバが障害中は、サービスを提供で
きるのは自サーバのみである。一方、サーバ間データ回
線が障害中は、互いに相手サーバのＤＢは更新できない
が、双方のサーバが共にサービスを提供している状態で
あり、この違いにより、データ一致化のための更新方式
が異なることになる。

【００４１】クレジットカード通話サービスの短縮ダイ
ヤル番号を登録する場合、装置状態が全て正常時に、何
らかの理由で、他サーバのＤＢ更新を失敗した場合は、
差分管理で一致化させる方式を選択しても、サービス品
質上問題ない。また、更新する際に予め、他サーバが障
害中と分かっている場合には、他サーバではサービスが
提供されていないため、差分管理で一致化させる方式を
選択することにより、自サーバによるサービス提供を継
続でき、障害復旧後に両サーバのＤＢの内容が一致化さ
れる。

【００４２】しかしながら、予めサーバ間データ回線が
障害中と分かっている場合には、双方のＳＣＰでサービ
スが提供されているため、差分管理で一致化させる方式
を選択すると、同じ短縮ダイヤル番号に対して、それぞ
れのサーバで異なった相手先番号が登録される可能性が
あり、障害復旧後に差分反映された後も、双方で不一致
となる可能性がある。従ってサーバ間データ回線が障害
中は、常に二式のデータベースを一致化させる更新方式
を選択し、該登録を受け付けないようにすることにより
サービス品質を保証する。

【００４３】次に、前記オプション番号の処理によ
り、更新データを差分管理ＤＢ１７に保存した後（前記
ステップＳ３１、Ｓ６４等参照）、これを他のサーバの
サービスデータＤＢ２６に転送して書き換える動作は、
差分反映管理機能部１３が行う。該差分反映管理機能部
１３の動作を、図９を参照して説明する。

【００４４】差分反映管理機能部１３は、ステップＳ１
０１にて、任意の周期で差分管理ＤＢ１７をアクセス
し、該差分管理ＤＢにデータが格納されているか監視す
る。ステップＳ１０２の判断が否定の時、すなわち該差
分管理ＤＢにデータが存在しないと判断された時には、
ステップＳ１１３に進む。該ステップＳ１１３では、次
の周期の監視タイマを設定して、処理を終了する。その
後、該監視タイマがタイムアップすると、前記ステップ
Ｓ１０１の監視が再度行われる。このように、差分管理
ＤＢにデータが格納されていない場合には、次の起動タ
イミングがセットされる。

【００４５】一方、差分管理ＤＢにデータが格納されて
いる場合は、ステップＳ１０３に進む。ステップＳ１０
３では、差分データが格納された時刻順（ローカルーＤ
Ｂに対して更新された時刻順）に抽出される。ステップ
Ｓ１０４では、後述する再試行カウンタの値を確認す
る。そして、ステップＳ１０５では、該再試行カウンタ
の値により、再試行を行うか否かの判断がなされる。こ
の判断が肯定の場合には、ステップＳ１０６に進んで、
リモートーＤＢに対して、抽出した差分データを更新す
る。ステップＳ１０７では、該更新が成功したか否かの
判断がなされる。この判断が肯定の場合には、ステップ
Ｓ１０８に進んで、抽出した差分データを差分管理ＤＢ
１７から削除する。そして、前記ステップＳ１０１に戻
って、次の差分データの探索に移行する。これによりロ
ーカルーＤＢとリモートーＤＢのデータ内容が一致化さ
れる。

【００４６】前記ステップＳ１０７の判断が否定の時に
は、ステップＳ１０９に進んで、更新を失敗した差分デ
ータが更新する再試行カウンタをカウントアップする。
ステップＳ１１０では、更新失敗した差分データが更新
するテーブル以外を更新対象とする差分データが存在し
ているかの照合をする。ステップＳ１１２では、該差分
データが存在しているか否かの判断がなされ、この判断
が肯定の時には、ステップＳ１０３に戻って、次の差分
データを管理部ＤＢから抽出する処理に移行する。

【００４７】上記の処理により再試行が所定の回数行わ
れると、ステップＳ１０５の判断は否定となり、ステッ
プＳ１１１へ進む。ステップＳ１１１では、再試行オー
バのテーブル以外を更新対象とする差分データが存在し
ているか否かの探索が行われ、ステップＳ１１２で該差
分データが存在していると判断されると、前記ステップ
Ｓ１０３に戻る。

【００４８】なお、再試行カウンタを設けた理由は、リ
モートーＤＢに対する同一データの一致化処理が永遠に
継続することがないようにしたものである。これによ
り、予め定めた任意の回数の一致化処理を行っても、一
致化できない場合には再試行オーバとして、一致化処理
の対象外とする。

【００４９】また、前記の処理によれば、同一データに
対する更新順序を保証することができる。サービスデー
タＤＢの同一データに対する更新データが複数件、差分
管理ＤＢに格納されている可能性があるため、これらに
ついては、格納された時刻順（ローカルーＤＢに対して
更新された時刻順）にリモートーＤＢへ更新しなけれ
ば、差分データ反映後、ローカルーＤＢとリモートーＤ
Ｂは不一致な状態となる。そこで、差分管理ＤＢの差分
データにはそれぞれ格納された時刻を記録し、リモート
ーＤＢへは、この時刻順に抽出し一致化する。リモート
ーＤＢに対しての一致化処理が失敗となった場合には、
失敗したデータと同じテーブルの以降の差分データに対
しては、今周期の一致化処理を行わなず、他のテーブル
に対する一致化処理を行うことにより同一データに対す
る更新順序性を保証する。また、失敗したデータと同じ
テーブルの以降の差分データは同じ原因で更新失敗する
可能性が高いため、今周期の反映処理を行わないことに
より、差分反映管理機能の無効な処理とサーバ間のデー
タ回線の無効なトラヒック発生を防ぐ。

【００５０】

【発明の効果】この発明によれば、少なくとも、更新す
るデータの特徴および更新する種別により、データベー
スの更新方法が決定されるので、サービスの提供に支障
をきたさない、かつ信頼性の高い複数サーバ間のデータ
ベースの一致化を達成することができる。

【００５１】また、前記データベースの更新方法の決定
に、他のサーバとの通信状態を加味することにより、シ
ステムに障害が起きても、安定的にサービスの提供を続
行することができる。

【００５２】さらに、交換網のインテリジェントネット
ワークにおいて、ＳＭＰが稼働不可能な状態に陥って
も、全てのＳＣＰに対してデータの更新をすることがで
きるようになり、システムの信頼性を大幅に向上させる
ことができる。

【図面の簡単な説明】

【図１】 本発明の一実施形態のシステム構成を示すブ
ロック図である。

【図２】 本発明の複数データベース一致化更新方法を
説明するためのフローチャートである。

【図３】 他サーバが正常な時の第１の処理を説明する
ためのフローチャートである。

【図４】 他サーバが正常な時の第２の処理を説明する
ためのフローチャートである。

【図５】 他サーバが正常な時の第３の処理を説明する
ためのフローチャートである。

【図６】 他サーバが障害中の時の処理を説明するため
のフローチャートである。

【図７】 他サーバ間データ回線障害中の時の処理を説
明するためのフローチャートである。

【図８】 複数データベース一致化更新方法の動的選択
例を示す図である。

【図９】 図１の差分反映管理機能部の処理を説明する
ためのフローチャートである。

【図１０】 従来の交換網のインテリジェントネットワ
ークの一システムのブロック図である。

【図１１】 交換網のインテリジェントネットワークの
他のシステムのブロック図である。

【符号の説明】

１，２…サーバ、３…ＬＡＮまたはＷＡＮ、１１，２１
…サービス処理機能部、１２，２２…データベース同期
管理機能部、１３，２３…差分反映管理機能部、１４，
２４…データベース管理機能部、１５，２５…データベ
ース管理システム、１６，２６…サービスデータＤＢ、
１７，２７…差分管理ＤＢ。

Claims (8)

【特許請求の範囲】
1. 【請求項１】 データベースを有する複数のサーバをネ
   ットワークで接続し、それぞれのサーバがローカルーＤ
   ＢとリモートーＤＢを直接更新することにより、前記複
   数のサーバ内のデータベース内容をリアルタイムに一致
   化させるようにした複数データベース一致化更新方法に
   おいて、 少なくとも、更新するデータの特徴および更新する種別
   により、予めデータベースの更新方法を決定しておき、
   該データベースの更新方法を、該更新するデータの特徴
   および更新する種別に応じて、動的に選択するようにし
   たことを特徴とする複数データベース一致化更新方法。
2. 【請求項２】 請求項１の複数データベース一致化更新
   方法において、前記データベースの更新方法の決定に、
   更新するデータの内容の条件を加えたことを特徴とする
   複数データベース一致化更新方法。
3. 【請求項３】 請求項１または２の複数データベース一
   致化更新方法において、 前記データベースの更新方法の決定に、他のサーバとの
   通信状態の条件を加えたことを特徴とする複数データベ
   ース一致化更新方法。
4. 【請求項４】 請求項１〜３のいずれかの複数データベ
   ース一致化更新方法において、 前記データベースの更新方法が、複数のデータベースを
   同期的に更新するが、何等かの原因により、複数のデー
   タベースの内のいずれか一つでも更新することができな
   かった場合には、全てのデータベースの更新を行わない
   方法であることを特徴とする複数データベース一致化更
   新方法。
5. 【請求項５】 請求項１〜３のいずれかの複数データベ
   ース一致化更新方法において、 前記データベースの更新方法が、複数のデータベースを
   同期的に更新するが、何等かの原因により、更新するこ
   とができなかったデータベースに対しては、自サーバ内
   で更新内容を保持し、原因が排除された時点で自動的に
   更新する方法であることを特徴とする複数データベース
   一致化更新方法。
6. 【請求項６】 請求項１〜３のいずれかの複数データベ
   ース一致化更新方法において、 前記データベースの更新方法が、複数のデータベースを
   同期的に更新するが、何等かの原因により、更新するこ
   とができなかったデータベースに対しては、当該の更新
   内容は反映しない方法であることを特徴とする複数デー
   タベース一致化更新方法。
7. 【請求項７】 請求項１〜６のいずれかの複数データベ
   ース一致化更新方法において、 前記複数のサーバが交換網のインテリジェントネットワ
   ークにおけるサービス制御ノード（ＳＣＰ）であり、サ
   ービス管理システム（ＳＭＰ）が障害等により稼働しな
   い状態になった場合でも、ＳＣＰのデータベース間で、
   直接データベース更新することにより、サービスの提供
   を可能としたことを特徴とする複数データベース一致化
   更新方法。
8. 【請求項８】 複数のサーバをネットワークで接続され
   た複数のサーバのデータベースの内容をリアルタイムに
   一致化させるようにした複数データベース一致化更新装
   置において、 更新するデータの特徴および更新する種別に応じて、デ
   ータベースの更新方法を動的に選択し送出するサービス
   処理機能部と、 該サービス処理機能部から受取ったデータベースの更新
   方法に従って、ローカルーＤＢとリモートーＤＢの同期
   管理を実行するデータベース同期管理機能部と、 前記
   データベースの更新方法の一つである差分管理による更
   新方法を実行するために使用される差分反映管理機能部
   と、 前記更新されるデータを格納するデータベースとを具備
   したことを特徴とする複数データベース一致化更新装
   置。