JP3572928B2 - バックアップ機能付オンラインデータベース情報処理システム - Google Patents
バックアップ機能付オンラインデータベース情報処理システム Download PDFInfo
- Publication number
- JP3572928B2 JP3572928B2 JP06843998A JP6843998A JP3572928B2 JP 3572928 B2 JP3572928 B2 JP 3572928B2 JP 06843998 A JP06843998 A JP 06843998A JP 6843998 A JP6843998 A JP 6843998A JP 3572928 B2 JP3572928 B2 JP 3572928B2
- Authority
- JP
- Japan
- Prior art keywords
- log
- database
- information processing
- access
- transaction
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Landscapes
- Techniques For Improving Reliability Of Storages (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
Description
【発明の属する技術分野】
本発明はオンラインデータベース情報処理システムにかかわり、特に、サービスの中断が社会的に大きな影響を及ぼす金融システムや医療システムなどの社会システムのバックアップ機能に関する。
【0002】
【従来の技術】
銀行や病院など社会生活の場にオンラインデータ端末群をもち、大規模なオンラインデータベース情報処理システムによって市民にサービスを行う、いわゆる社会システムではサービスの予期せぬ中断が大きな影響を与えるばかりでなく、サービス時間の延長によるサービス向上が常に求められている。このため、これらのシステムでは運用中のシステムの思わぬ障害や災害時のサービス中断を速やかに回復するため、スタンバイ中のシステムをもち、これへの切り替えができる体制をとっている。以下、主として運用に供せられるシステムを主システムと呼び、バックアップのため常時スタンバイ中のシステムを副システムと呼ぶと、主システムの故障停止時に副システムに運用を切り替えることとなる。また、このほかシステム機器の保守点検も重要であり、主システムを予定に従って一定期間停止させ、その間は副システムに切り替えサービス業務を継続することも副システムの重要な役目である。
【0003】
このような副システムへの切り替え方法として、デュアルシステムとデュプレックスシステムの2つの方法がある。デュアルシステムは主システムと副システムを完全対等とした完全二重化システムであり、システム構成機器がすべて二重にあり且つそのどちらも同時に同じ動作をする。それゆえ、オンラインデータ端末群からのトランザクションは二つのシステムで同時に同様に処理される。一方デュプレックスシステムは主システムと代替しうる副システムを別々にもち、オンラインデータ端末群は常時は主システムに接続され、副システムに切り替える時にはオンラインデータ端末群も副システム側に接続が切り替えられる。
【0004】
デュアルシステムの特性はシステム切り替えが速やかな利点がある反面、1トランザクションを主側と副側に渡す仕組みや同期方法が複雑であり、レスポンスを重視するシステムでは非常に高価高性能な機器が要求される欠点をもつ。一方デュプレックスシステムはシングルシステム時とほぼ変わらぬレスポンス性能を維持できる利点があるが、運用中のシステムのある時点の状況をスタンバイ中のシステムに反映し終えるまでの時間が必要で、速やかな切り替えができない欠点をもつ。このため、従来からデュプレックスシステムのシステム切り替え時間の短縮に関しての技術開発がなされてきた。
【0005】
例えば、文献特開平03−250257号、特開平09−259023号では主システムのオンライン動作中のデータベースアクセスの記録をアクセスログとしてジャーナルに落とし、これを適宜ホットスタンバイ中の副システムに反映させることによりわずかな時間遅れで副システムが主システムに追いつく技術が開示されている。しかし、このようなシステムであっても切り替え時間をゼロとすることはできない。なぜなら、優先度レベルの低いバックアップ反映処理は最優先度レベルのオンライントランザクション処理の隙間時間に行われ、反映処理待ち行列が生ずるからである。このため、現状の銀行システムなどでは数十分程度の切り替え時間を要するのが普通である。
【0006】
災害等予期せぬ事故によって主システムを副システムに切り替える場合は、その他の人的な対応体制を取る時間も必要であり、上記のような切り替え時間も許容されるが、機器の保守などのための予定に従った主システムの副システムへの切り替えの場合は、たとえわずかな時間であってもオンラインサービスが停止することは許されない。それゆえ、現状ではサービス終了の夜間に主システムから副システムへの切り替えを行い、主システムの保守点検後もまた夜間のサービス終了後、副システムから主システムへの戻し切り替えを行っている。
【0007】
【発明が解決しようとする課題】
上述のように、従来の技術ではバックアップ機能付オンラインデータベース情報処理システムの主システムと副システムとの予定的な切り替えは夜間のサービス終了後にせざるを得なかった。しかし、近年24時間サービスを理想とする夜間サービス時間の延長への要望が高まり、また、バッチ処理業務のバックログの増大から、サービス時間内のシステム切り替えを可能とすることが望まれてきた。本発明はこのような課題を解決するバックアップ機能付オンラインデータベース情報処理システムを提供することを目的とする。
【0008】
【課題を解決するための手段】
バックアップ機能付オンラインデータベース情報処理システムにおいて、主システムと副システムとの予定的な切り替えをサービス停止時間を設けることなく行うことができない、という上記の課題は図1に示す如く、
第1のデータベースDB1 をもつ主システム1と第2のデータベースDB2 をもつ副システム2とを接続し、第1のデータベースDB1 の内容をある時間遅れ(T)でデータベースDB2 に反映させるオンラインデータベース情報処理システムにおいて、
主システム1および副システム2の両者から書き込み参照可能なアクセスキーサーバ5と、
トランザクション内容の少なくともキー部分を前記アクセスキーサーバ5に記録するトランザクション処理部121 と、
オンラインデータ端末群4からのアクセス要求内容を前記アクセスキーサーバ5の内容と照合し、同一キーを有するアクセス要求に対しては限定的処理を行うログ受信反映処理部222 と、
を有するバックアップ機能付オンラインデータベース情報処理システムを提供することによって解決される。
【0009】
すなわち、図2に示す主システムから副システムへのシステム切替タイムチャート例によってこれを示すと、主システム1によるサービスは時刻t2において切り替えられ、以降は副システム2によるサービスとなり、この間にサービス停止時間を設けることがない。このことを可能ならしめるために、時刻t1において切替準備を始める。この意味で時刻t1から時刻t2の間の時間を図2では切替準備期間T12と名付けているが、オンラインサービスは通常サービス期間と同様に行っている。ここで時刻t1は、この時点の主システム1の第1のデータベースDB1 の内容DB1(1)が少なくとも切替予定時刻t2以前に副システム2の第2のデータベースDB2 に反映され終えているように選ばれている。このことを図2では副システム2の第2のデータベースDB2 の時刻t2における内容DB2(2)= DB1(1)とあらわしている。
【0010】
しかし時刻t2時点では第1のデータベースDB1 の内容DB1(2)は既に変化しておりDB1(1)のままではない。ここに、DB1(2)とDB1(1)とを比較すると、多くのレコードは不変であるが、切替準備期間T12中のオンラインデータ端末群4からのアクセス▲1▼〜▲4▼によって一部のレコードが変更、すなわち更新または追加削除されている。ここでは切替準備期間T12中のトランザクションにより変更されたレコードをC であらわし、切替準備期間T12中に無変更のレコードをR であらわすと、DB1(2)はC とR の和集合となる。図2ではこれをDB1(2)=C+Rと表現した。
【0011】
さて、主システム1は切替準備期間T12の初期時刻t1においてアクセスキーサーバ5の内容AS(1) をリセットし、以降のトランザクションに関し、その都度少なくともそのキー情報を格納する。キー情報とは、例えば銀行システムでは取引営業店番号と預金口座番号のように第1のデータベースDB1 上のどのレコードが変更されたかを判別するための情報である。図2ではこれを<C> であらわし、時刻t2におけるアクセスキーサーバ5の内容AS(2)=<C> とした。
【0012】
時刻t2において切り替えられた時点の副システム2の第2のデータベースDB2 の内容DB2(2)には時刻t1時点の第1のデータベースDB1 の内容DB1(1)しか反映されておらず、切替準備期間T12中のトランザクションにより変更されたレコードC を第2のデータベースDB2 に反映する必要があるが、それには時刻t3までかかる。そこで、時刻t2から時刻t3までの時間は限定サービス期間T23として、副システム2はC に含まれるレコードを参照すべきアクセス要求に対しては限定処理、例えば取引抑止の処置をとる。この処置判断はアクセスキーサーバ5の内容AS(2) を利用して行うことができる。
【0013】
すなわち、図2において、副システム2は限定サービス期間T23中のオンラインデータ端末群4からのアクセス要求▲5▼〜▲7▼のそれぞれに含まれるキー情報をアクセスキーサーバ5の内容AS(2) のもつC に関するキー情報<C> と照合して、該当アクセス要求がC にかかわるかどうかを判定する。そしてC にかかわる取引要求である場合この取引を抑止し、そうでない場合にはDB2(2)の内容に含まれるR を参照して取引トランザクションを成立させる。このようにして、副システム2は限定サービス期間T23中もサービス停止することなく、第2のデータベースDB2 のDB2(2)およびアクセスキーサーバ5のAS(2) を参照して限定したオンラインサービスを行うことができる。時刻t3は切替準備期間T12および限定サービス期間T23中のすべてのトランザクションを第2のデータベースDB2 に反映し終えた時点である。時刻t3以降のオンラインサービスは副システム2によって通常のサービス形態に復帰する。また、主システム1の保守点検を終えて副システム2から主システム1に切替を戻す場合には、上記説明の逆を行えるよう、両システムは互いの機能を等しく備えておればよい。
【0014】
【発明の実施の形態】
バックアップ機能付オンラインデータベース情報処理システムの実施例を図1〜図9により説明する。なお、本発明におけるコンピュータ処理は、コンピュータプログラムにより当該コンピュータの主記憶装置上で実行されるが、このコンピュータプログラムの提供形態は、当該コンピュータに接続された補助記憶装置をはじめ、フロッピーディスクやCD−ROM等の可搬型記憶装置やネットワーク接続された他のコンピュータの主記憶装置及び補助記憶装置等の各記録媒体に格納されて提供されるもので、このコンピュータプログラムの実行に際しては、当該コンピュータの主記憶装置上にローディングされ実行されるものである。
【0015】
図1〜図9に基づいて、銀行システムを例にとり本発明の実施例を説明する。図1はバックアップ機能付オンラインデータベース情報処理システムの構成例である。オンラインデータ端末群4は主システム1および副システム2の切替制御手段11によって主システム1側に切り替えられており、主システム1がオンラインサービスを実施している通常のサービス期間では、オンラインデータ端末群4からのアクセス要求は主システム1の第1の情報処理手段12に伝えられる。
【0016】
図3には第1の情報処理手段12および第2の情報処理手段22の機能のうち、本発明にかかわる部分のみを取り出した構成例を示す。図示の如く、第1の情報処理手段12はトランザクション処理部121 およびログ出力送信処理部122 を有している。トランザクション処理部121 は通常サービス期間および切替準備期間T12中のオンラインデータ端末群4からの電文到着によって起動され、これらのトランザクション処理を行う。一方、ログ出力送信処理部122 はトランザクション処理部121 からの要求によって起動され、これら動作の履歴を主システム1のアクセスログ15に格納し、システムタイマによる定時割り込みにより、これを反映用ログとして副システム2に送出する。また時刻t1、t2におけるシステム切替関連の制御も行う。
【0017】
一方、副システム2の第2の情報処理手段22はトランザクション処理部221 およびログ受信反映処理部222 を有する。主システム1による通常サービス期間中はトランザクション処理部221 は動作せず、専らログ受信反映処理部222 が主システム1からのログを受信して第2のデータベースDB2 への反映を行う。時刻t2にシステム切替が行われ、限定サービス期間T23中およびその後の通常サービス期間では、オンラインデータ端末群4からの電文が副システム2の第2の情報処理手段22に入るので、これによってトランザクション処理部221 が起動され必要な処理をする。
【0018】
このように本実施例では、ログ出力送信処理部122 はトランザクション処理部121 が一件処理をする毎にログ出力要求を受け起動され、主システム1のアクセスログ15に蓄積されるが、これを副システム2に送出するタイミングとして、システムタイマによる定時割り込みを使用した。すなわち、アクセスログの容量に十分余裕のある一定時間毎にログ出力送信処理部122 を呼び、副システム2に対するログ送信を行わせる。一方、第2の情報処理手段22のログ受信反映処理部222 はこれに対応して通信制御手段14より受信通知を受け、受信内容を第2のデータベースDB2 に反映させるので、この定時割り込みの時間間隔で定まる時間遅れをもって、副システム2へのデータ反映が維持されていることになる。また、限定サービス期間T23終了後の副システム2による通常サービス期間中は、相手の主システム1をシステム停止させるので、別途主システム1を回復スタンバイ中にするまでは定時割り込みを発生させないものとする。
【0019】
以上の時間遅れによるバックアップ法は従来技術における手法と同様である。本発明では以上の動作のうち、切替準備期間T12におけるトランザクション処理部121 および限定サービス期間T23におけるトランザクション処理部221 でアクセスキーサーバ5を使用してサービス無停止切替を行うところに主眼点がある。
以下に図4〜7によりこの動作を詳細に述べる。
【0020】
図4はトランザクション処理部の動作フローであり、通常サービス期間および切替準備期間T12のトランザクション処理を行う。まずステップS401でオンラインデータ端末群4より切替制御手段11を経てアクセス要求電文が伝えられる。ステップS402では第1のデータベースDB1 の元帳を参照しつつ、無条件にこれらのトランザクションを実行し、実行結果は第1のデータベースDB1 に記入され元帳更新が行われる。すなわち、すべてのトランザクションに対応しうる完全な元帳によるサービスが行われている。
【0021】
次にステップS403でログ出力送信処理部122 がログ送信中でないのを確かめて、ステップS404でこの元帳アクセスの履歴を主システム1のアクセスログ15に記録すべくログ出力送信処理部122 を起動する。図の☆印はログ出力送信処理部122 への起動トリガを意味する。主システム1のアクセスログ15への出力情報としては、元帳アクセス履歴、アクセス時刻に対応する論理時刻、フェーズフラグphの内容、などがある。元帳アクセス履歴とはステップS402での第1のデータベースDB1 の変更内容を再現できるための記録であって、例えばステップS402において発行されたデータベースアクセスマクロ(レコード更新、生成、削除)そのものであってもよい。これにアクセスの順序を保証する通番である論理時刻を付して、副システム2における反映時の順序を確保する。またフェーズフラグphは該当トランザクションが切替準備期間T12や限定サービス期間T23のフェーズにあることを示すフラグであって、後に述べるログ出力送信処理部122 が第1の情報処理手段12内およびアクセスキーサーバ5上にセットするものである。
【0022】
次いで、ステップS405ではフェーズフラグphをみて現在が切替準備期間T12中であるかどうかを判定し、通常サービス時であれば処理を終わるが、切替準備期間T12中であればステップS406に進み、アクセスキーサーバ5に当該アクセスキーを書き込む。すなわち、ステップS402での第1のデータベースDB1 への変更内容のうち、少なくとも変更されたレコードに対応するキー情報を記録し、将来の副システム2からのアクセスに備える。
【0023】
第1のデータベースDB1 の構造例と対応するキー情報を含むアクセスキーの設定例を図8に示す。第1のデータベースDB1 の元帳には、図8(a) に示す如く、顧客管理レコードのもとに各金融商品の口座毎の管理レコードがあり、さらに各々のもとに取引明細のレコードがリンクしている。図8(b) にはこのうちの預金管理レコードのデータ形式例を示した。オンラインデータ端末群4からのアクセス要求は少なくとも店番号、口座番号、科目を含んでおり、ステップS402ではこれをもとに第1のデータベースDB1 中の該当管理レコードを検索し、取引内容に応じた明細レコードの更新作成が行われたのち、管理レコードの残高などサマリ情報が書き換えられる。
【0024】
このように一つの取引で変更をうけたレコードは必ず対応するユニークな店番号、口座番号、科目の組をもつので、これを口座idとして管理し、これをキー情報とする。アクセスキーの最小限の役目は、切替準備期間T12で第1のデータベースDB1 に変更を生じさせた口座idを知ることである。すなわち、口座idをキー情報としてアクセスキーサーバ5に逐一記録しておけば、アクセスキーサーバ5を検索して見つからない口座idに対応するレコードは切替準備期間T12中に変更を受けなかったことが保証される。
【0025】
一件のトランザクションが二つ以上のキー情報を発生する場合もある。例えばAの普通預金から引き落としBの当座預金口座に振り込むトランザクションでは図8(c) のように引落元の口座idと預入先の口座idの二つのキー情報が記録される。なお、図8(c) ではキー情報のほかに残高もアクセスキーとして記録したが、これは後に図6のステップS605で説明する限定トランザクション処理の内容によって必要となるものの一例である。
【0026】
次に図5によってログ出力送信処理部のログ送信およびシステム切替動作を説明する。ログ出力送信処理部122 は既に説明したトランザクション処理部121 のアクセスログ出力要求(図4のステップS404の☆印)によって起動されるログ出力部分(ステップS501〜ステップS504)、およびシステムタイマの定時割り込みによる動作部分(ステップS521〜ステップS530)からなっている。
【0027】
ログ出力部分はステップS501によって通信制御手段14がログ送信中かどうかを調べ、送信中でなければステップS502でログ出力中フラグloをセットした後、ステップS503で主システム1のアクセスログ15にトランザクション処理部121 から託されたログ内容を書き出す。そしてステップS504でログ出力中フラグloをリセットし処理を終える。
【0028】
システムタイマからの定時割り込みには通常サービス時の定時割り込みと切替準備を指示する定時割り込みと切替実行を指示する定時割り込みの3種類が含まれる。これらは図示省略の初期モードスケジュール設定部でシステム管理者の操作卓からの操作により主システム1に指示される。すなわち、主システム1を保守点検などのためにシステム停止したい日時を入力すると、第1の情報処理手段12はこれに最も近い定時割り込みを切替実行割り込みに、その一つ前の定時割り込みを切替準備割り込みにスケジュールする。その他の定時割り込みは通常割り込みである。
【0029】
これらの定時割り込みを受けると、ログ出力送信処理部122 はステップS521でログ出力が完了したことを見届け、ステップS522でログ送信中フラグlsをセットしたのち、ステップS523で通信制御手段14に対して主システム1のアクセスログ15の内容を副システム2に送信することを命ずる。通信制御手段14からログ送信が成功終了したことを受け、ステップS524でログ出力送信処理部122 は主システム1のアクセスログ15をリセットし、次のログ蓄積に備える。以上が完了するとステップS525でログ送信中フラグlsをリセットする。
【0030】
次にステップS526で割り込みの種類を調べ、通常定時の割り込みであった場合には処理を終える。切替準備要求であった場合には、以降のトランザクションのキー部分をアクセスキーサーバ5に記録するための準備として、ステップS527でアクセスキーサーバ5のバッファ内容をリセットするとともにフェーズフラグphを切替準備値にセットして、トランザクション処理部121 に切替準備期間T12にはいったことを知らせる。
【0031】
ステップS526で切替実行要求の割り込みであった場合は、ログ出力送信処理部122 はステップS528でシステム切替を実行する。すなわち、切替制御手段11のスイッチを副システム2側に切り替える指示を出す。これによってオンラインデータ端末群4は副システム2に接続され、以後のアクセス要求は第2の情報処理手段22にはいることとなる。そして、限定サービス期間T23にはいったことを第2の情報処理手段22に知らせるため、ステップS529でアクセスキーサーバ5内の所定位置のフェーズフラグphをセットする。こののち、主システム1はもはや停止可能となったのでステップS530で主システム1を自動停止させる。なお、主システム1の再立ち上げの場合は図示省略の初期モードスケジュール設定部でフラグ類の初期値設定がなされるものとする。
【0032】
以上の第1の情報処理手段12の動作に対応する第2の情報処理手段22の動作について、次に図6〜7によって説明する。既に述べた如く、第2の情報処理手段22は限定サービス期間T23およびその後の通常サービス期間のトランザクションを処理するトランザクション処理部221 と、限定サービス期間T23中の限定処理ログおよびそれ以前の時期のログ受信分の反映を行うログ受信反映処理部222 とから成る。
【0033】
図6は第2の情報処理手段のトランザクション処理部の動作フローである。オンラインデータ端末群4からの電文を受信した時点でトランザクション処理部221 が起動され、最初にステップS601でもし限定処理ログ反映中であればこれの終了まで電文処理を待たせる。この意味については後に図7の限定処理ログの説明でふれる。次いでステップS602で現在のフェーズを確認する。すなわち、アクセスキーサーバ5を読みフェーズフラグphの値を調べ限定サービス期間T23中かどうかを知る。なお、本実施例では簡単のためフェーズフラグphをアクセスキーサーバ5上にもち、限定サービス期間T23終了後の副システム2による通常サービス期間も、このステップS602で毎回電文受信の都度、アクセスキーサーバ5をアクセスする例を示したが、後に第2の実施例で示す如く、限定サービス期間T23終了後のある時点でシステム管理者が介入しモードスケジュール設定することにより、アクセスキーサーバ5へのアクセスを不要とさせることができる。
【0034】
現在フェーズが限定サービス期間T23中でなかった場合は、トランザクション処理部221 はステップS606に進み第2のデータベースDB2 の副元帳を参照しつつ通常のトランザクション処理を行い、その結果を第2のデータベースDB2 に書き込む。また、ステップS607でトランザクション処理部221 がログ送信中でないことを確かめてからステップS608にてこのアクセス履歴をアクセスログ25に出力するよう要求を出す。このステップS606〜ステップS608は既に説明した図4のステップS402〜ステップS404を主システム1と副システム2が立場を変えて行っている。
【0035】
ステップS602で限定サービス期間T23中であった場合は、トランザクション処理部221 はステップS603でアクセスキーサーバ5を検索し、ステップS604で電文の含むキー情報がアクセスキーサーバ5の中に登録されているかを判断する。もしも登録されていないならば電文のアクセス要求は第2のデータベースDB2 の副元帳を使用して処理可能であるからステップS606の既に説明した通常トランザクション処理を行う。
【0036】
ステップS604でアクセスキーが一致した場合はステップS605であらかじめ定められた限定トランザクション処理を行い、その結果を限定処理ログに書き出す。ここで限定トランザクション処理とは、電文の取引要求がアクセスキーサーバ5の内容をもとに取引可能な処理のみを行い、そうでない場合はこの取引要求を抑止するような処理をさす。最も単純にはアクセスキーサーバ5に登録されたキー情報の口座idを含む電文に対してはすべて取引抑止し、例えば、「ただいま混み合っておりますので受け付けられません。」というメッセージをアクセス元のオンラインデータ端末に回答する。
【0037】
図8(c) に示すように、アクセスキーサーバ5がアクセスキーとして口座idとその残高を常に記録している場合は、限定トランザクション処理としてある程度のサービスが可能である。例えば、預金の入金や支払いサービスはアクセスキーサーバ5の残高を参照して可能であるが、明細レコードの参照が必要な記帳サービスはできない。このように、限定トランザクション処理が実行するサービスと抑止するサービスはアクセスキーサーバ5に記録するアクセスキー情報の種類範囲と取引サービスの必要とする情報の種類範囲を比較して決定されるので、システム設計時にこれらを考慮してアクセスキーが設計される。
【0038】
このようにしてなされた限定トランザクション処理の内容は、暫定的に限定処理ログに蓄積される。なぜなら、この時点では副元帳である副システム2の第2のデータベースDB2 には該当口座idの切替準備期間T12中での変更内容が反映され終えていない可能性があるので、限定サービス期間T23中の限定トランザクション処理についてはこれを副元帳に書き込むことができないためである。なお、限定処理ログに記録される限定取引履歴は、取引明細に関して後に元帳の明細レコードに反映すべきすべての情報を含むものであり、これが論理時刻とともに蓄積される。
【0039】
最後に、上記限定処理ログを含むログ反映動作について図7により説明する。第2の情報処理手段22のログ受信反映処理部222 は通信制御手段14からのログ受信通知によって起動される。ステップS701でログ受信反映処理部222 は通信制御手段14から受け取ったログをアクセスログ25に格納する。全部の格納が終わると、今度はステップS702においてこの内容を第2のデータベースDB2 の副元帳に反映させる。すなわち、ログ内容が論理時刻に従った順序のデータベースアクセスマクロ列である場合は、この順序でマクロ実行し第2のデータベースDB2 にアクセスしていくことにより、あたかもトランザクション処理が順次になされたかのように第2のデータベースDB2 のレコードを変更して行く。このようにして副元帳は時間遅れで正元帳である第1のデータベースDB1 の内容を反映し終える。ステップS702での反映処理を終えるとログ受信反映処理部222 はステップS703でアクセスログ25の内容をリセットし、次のログ受信に備える。
【0040】
次いでログ受信反映処理部222 はステップS704でフェーズフラグphを調べ、現在が限定サービス期間T23中であるかどうかを調べる。限定サービス期間T23中のログ受信の場合は、そのログ内容は切替準備期間T12中の変更分であることがわかっているので、現時点で第2のデータベースDB2 の内容は切替直前の第1のデータベースDB1 の状態をすべて反映し終えたことになり、ステップS705からステップS707の限定処理ログの反映を行うことが可能となった。
【0041】
ステップS706は限定サービス期間T23中の限定トランザクション処理の記録である限定処理ログを第2のデータベースDB2 の副元帳に反映する処理であって、すべて反映し終わると限定処理ログの領域はリセットされ、この時点で第2のデータベースDB2 は完全な元帳となり、以降の通常トランザクションサービスに対処できる態勢が整った。なお、このステップS706の処理中に新たな限定トランザクション処理が発生すると反映漏れが生ずるので、この処理の前後にステップS705で限定ログ反映中フラグglをセットし、ステップS707でこのフラグをリセットする。既に説明した図6のトランザクション処理部221 のステップS601はこのフラグによって限定トランザクション処理とステップS706の限定処理ログ反映の競合を避けている。
【0042】
ステップS707では限定ログ反映中フラグglのリセットとフェーズフラグphの通常サービスフェーズ値へのセットは同時に行われる。これによってシステム切替の処理がすべて終わり、副システム2がオンライントランザクションを受け持ち、主システム1はシステム停止をしている態勢となった。そして、最後にステップS708で第2の情報処理手段22の割り込み機構(図示されていない)に対して割り込みのマスクを指示し、以降のアクセスログ25の主システム1への転送が起こらないようにする。
【0043】
以上の説明では、本発明の主眼点を見やすくするために、主システム1が通常サービスを行いながら副システム2が時間遅れで追随している通常サービスのフェーズから切替準備期間T12を経て副システム2によるオンラインサービスに切り替わり、限定サービス期間T23中の限定サービスを経て副システム2による通常サービス態勢を確立する過程のみを説明した。
【0044】
実際の実施システムでは、しかしながら、この後主システム1が保守点検を終えて復帰し、副システム2からトランザクション接続を戻す過程が必要である。すなわち、副システム2の通常処理中のアクセスログを主システム1が復帰前に受ける戻し切替準備期間T12’ 、更に切替時に主システム1による限定トランザクション処理を行う戻し限定サービス期間T23’を経て主システム1に復帰するであろう。これらのことは、上記本発明の実施例に示す第1の情報処理手段12の動作を副システム2にさせ、第2の情報処理手段22の動作を主システム1にさせることにより容易に実現できるので、ここではごく簡単に説明を補充するにとどめる。
【0045】
すなわち、主システム1と副システム2の両方向の切り替えを実現するためには、上記実施例の第1の情報処理手段12および第2の情報処理手段22の機能を併せ持つ共通の情報処理手段を有する主システム1および副システム2からなるバックアップ機能付オンラインデータベース情報処理システムを実施すればよい。図9にはこのような第2の実施例を示した。
【0046】
図9(a) に示す如く、本実施例の場合には主システム1、副システム2の双方に共通の情報処理手段32があり、その本発明関連部分の構成は図9(b) に示される。ここに初期モードスケジュール設定部はシステム管理者によってシステムの初期起動時または運転中の随時にモードの変更を行うために起動されるものである。ここでモード設定のために入力されるパラメータは、例えば、
・自己id:G(主システム1へのロード)
B(副システム2へのロード)
・初期id:1(主システム1を運用中システムとし、副システム2をスタンバイ中のシステムの状態、すなわち、切替制御手段11を主システム1側に切り替えた状態から開始する。)
2(主システム1をスタンバイ中のシステムとし、副システム2を運用中のシステムの状態、すなわち、切替制御手段11を副システム2側に切り替えた状態から開始する。)
である。これらの設定により主システム1の共通の情報処理手段32は、現用側となるG1、スタンバイ側にまわるG2、のいずれかのモードとなり、同様に副システム2の共通の情報処理手段32は現用側となるB2、スタンバイ側にまわるB1、のいずれかのモードとなる。またスケジュール設定のための入力パラメータは、
・定時割り込み間隔値:999min. (分単位で三桁で入力)
・自己停止日時:mm.dd.hh(G1 またはB2選択時入力要求がなされる。)
などがある。以上のパラメータ設定によって初期モードスケジュール設定部は配下のトランザクション処理部、ログ出力送信処理部、ログ受信反映処理部をリセットスタンバイさせる。すなわち、フラグ類のリセットを行い、限定サービス期間T23後の定時割り込み禁止を解除し、モードに従って切替制御手段11を主システム1側または副システム2に切り替える。これ以降は電文受信や定時割り込みなどの既に説明した要因で、既に説明した図4〜図7の機能が動作する。ただし共通の情報処理手段32の動作モードG1,G2,B1,B2に応じて図9(b) に示すパラメータの読み替えが生じる。例えばログ送信中フラグはG1モードで使用するlsとB2モードで使用するls’ の二つの独立した領域で設定管理される。このような実施例では副システム2から主システム1への復帰に際して、システム管理者が初期モードスケジュール設定部を起動して復帰の指示ができる。また、限定サービス期間T23後の通常処理では副システム2のアクセスログ25にどんどんログが蓄積するので、システム管理者は準備完了を見計らって初期モードスケジュール設定部によって介入する。これによりフラグ管理が切替準備期間T12以前の通常処理に移行するので、再びアクセスログの定時転送が復活する。
【0047】
以上によって本発明の骨子は明らかになったと思われるが、以下には実施に当たっての若干の補足を行う。本実施例では主システム1、副システム2、アクセスキーサーバ5の場所的な関係を規定していない。災害対策を考慮してこれらが互いに遠隔地にあって通信回線で結ばれていてもよく、また、すべてが一つの室内に設置されていてもよい。また、本実施例のようにフェーズフラグphをアクセスキーサーバ5上にとらず、主システム1と副システム2がフェーズフラグphを通信回線によって通知し合う設計とすれば、最低限アクセスキーサーバ5はシステム切り替え時のみに動作可能であればよく、その他の時点ではシステム停止状態であってもよい。
【0048】
また第1の情報処理手段12やアクセスログ15などがロードシェアのために複数個で構成されていてもよい。この場合の第1の情報処理手段12には、これら複数の情報処理手段の間の統一が保たれて、共通の第1のデータベースDB1 に排他的にアクセスするマネージャの存在が必要であり、この配下にある複数個のトランザクション処理部121 は当該マネージャに依頼してデータベースアクセスし、このアクセス順序に従った論理時刻を受け取る必要がある。このように構成された場合には通信回線3も多重化されアクセスログの転送効率をあげることが可能である。そして、論理時刻はこのような並行転送される複数個のアクセスログの全体にわたって履歴の時間順序を保証するので、ログ受信反映処理部222 ではこれら複数のアクセスログ25の内容をマージし、論理時刻によってソートしたのち、ステップS702で説明した反映処理を行うこととなる。
【0049】
【発明の効果】
以上の説明から明らかなように本発明によれば、バックアップ機能付オンラインデータベース情報処理システムにおいて、主システムと副システムとのシステム切り替え時に、オンラインデータ端末群からのアクセス要求の一部を限定処理するだけで、その他のアクセス要求には通常サービスを行うことができ、システム停止を許されない時間帯においてもシステム切り替えができる、という著しい効果がある。
【図面の簡単な説明】
【図1】バックアップ機能付オンラインデータベース情報処理システム構成例
【図2】主システムから副システムへのシステム切り替えタイムチャート
【図3】第1の情報処理手段および第2の情報処理手段の構成例
【図4】第1の情報処理手段のトランザクション処理部の動作フロー
【図5】第1の情報処理手段のログ出力送信処理部の動作フロー
【図6】第2の情報処理手段のトランザクション処理部の動作フロー
【図7】第2の情報処理手段のログ受信反映処理部の動作フロー
【図8】元帳データベースの構造例とアクセスキーの設定例
【図9】共通の情報処理手段を有するバックアップ機能付オンラインデータベース情報処理システムの実施例
【符号の説明】
DB1 第1のデータベース
DB2 第2のデータベース
1 主システム
2 副システム
5 アクセスキーサーバ
12 第1の情報処理手段
15 主システムのアクセスログ
22 第2の情報処理手段
25 副システムのアクセスログ
32 共通の情報処理手段
121 第1の情報処理手段のトランザクション処理部
122 第1の情報処理手段のログ出力送信処理部
221 第2の情報処理手段のトランザクション処理部
222 第2の情報処理手段のログ受信反映処理部
Claims (2)
- 第1のデータベースをもつ運用中のシステムと第2のデータベースをもつスタンバイ中のシステムとを接続し、第1のデータベースの内容をある時間遅れで第2のデータベースに反映させるオンラインデータベース情報処理システムにおいて、
運用中のシステムおよびスタンバイ中のシステムの両者から書き込み参照可能なアクセスキーサーバと、
前記運用中のシステムは、該運用中のシステムから前記スタンバイ中のシステムへの切り替えの実施前の所定期間(T12)内に発生したトランザクション内容の少なくともキー部分を前記アクセスキーサーバに記録するトランザクション処理部を有し、
前記スタンバイ中のシステムは、該スタンバイ中のシステムへの切り替えの実施後の所定期間(T23) 内に発生したオンラインデータ端末群からのアクセス要求内容を前記アクセスキーサーバの内容と照合し、同一キーを有するアクセス要求に対しては限定的処理を行うログ受信反映処理部を有する
ことを特徴とするバックアップ機能付オンラインデータベース情報処理システム。 - 前記限定的処理として、要求の取引サービスを抑止することを特徴とする請求項1記載のバックアップ機能付オンラインデータベース情報処理システム。
Priority Applications (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP06843998A JP3572928B2 (ja) | 1998-03-18 | 1998-03-18 | バックアップ機能付オンラインデータベース情報処理システム |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP06843998A JP3572928B2 (ja) | 1998-03-18 | 1998-03-18 | バックアップ機能付オンラインデータベース情報処理システム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH11265322A JPH11265322A (ja) | 1999-09-28 |
| JP3572928B2 true JP3572928B2 (ja) | 2004-10-06 |
Family
ID=13373749
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP06843998A Expired - Fee Related JP3572928B2 (ja) | 1998-03-18 | 1998-03-18 | バックアップ機能付オンラインデータベース情報処理システム |
Country Status (1)
| Country | Link |
|---|---|
| JP (1) | JP3572928B2 (ja) |
Families Citing this family (9)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2001142762A (ja) * | 1999-11-12 | 2001-05-25 | Nec Corp | 二重化データベースのデータ連携装置 |
| JP4010749B2 (ja) * | 2000-07-04 | 2007-11-21 | 本田技研工業株式会社 | 共有データベースを備えた電子ファイル管理システム |
| JP4593750B2 (ja) * | 2000-09-28 | 2010-12-08 | 株式会社ビジュアルジャパン | Posサーバ、店端末、posシステム及び記録媒体 |
| JP2004013271A (ja) * | 2002-06-04 | 2004-01-15 | Aiful Corp | バックアップサービサーシステム、バックアップサービシング方法、これらに用いて好適なバックアップサービサー装置、オリジネーター装置 |
| JP3908739B2 (ja) * | 2004-01-30 | 2007-04-25 | 株式会社オーク情報システム | ネットワーク監視システム、ネットワーク監視方法、ネットワーク監視プログラム、および記録媒体 |
| JP4581500B2 (ja) * | 2004-06-17 | 2010-11-17 | 株式会社日立製作所 | ディザスタリカバリシステム、プログラム及びデータベースのリカバリ方法 |
| JP6248747B2 (ja) * | 2014-03-28 | 2017-12-20 | 富士通株式会社 | 情報処理装置、制御方法および制御プログラム |
| CN107066480B (zh) * | 2016-12-20 | 2020-08-11 | 创新先进技术有限公司 | 主备数据库的管理方法、系统及其设备 |
| US10761926B2 (en) * | 2018-08-13 | 2020-09-01 | Quanta Computer Inc. | Server hardware fault analysis and recovery |
-
1998
- 1998-03-18 JP JP06843998A patent/JP3572928B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JPH11265322A (ja) | 1999-09-28 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7925633B2 (en) | Disaster recovery system suitable for database system | |
| US7685387B2 (en) | Storage system for multi-site remote copy | |
| JP2894676B2 (ja) | 非同期式遠隔コピー・システム及び非同期式遠隔コピー方法 | |
| US7415589B2 (en) | Data processing system with multiple storage systems | |
| US7328373B2 (en) | Data processing system | |
| EP1569120B1 (en) | Computer system for recovering data based on priority of the data | |
| JP4301849B2 (ja) | 情報処理方法及びその実施システム並びにその処理プログラム並びにディザスタリカバリ方法およびシステム並びにその処理を実施する記憶装置およびその制御処理方法 | |
| JP4282030B2 (ja) | データ二重化制御方法および二重化した記憶サブシステム | |
| CN100478902C (zh) | 地理分布式集群 | |
| US7650369B2 (en) | Database system management method and database system | |
| US7330861B2 (en) | Remote copying system and method of controlling remote copying | |
| CN113396407A (zh) | 用于利用区块链技术扩充数据库应用的系统和方法 | |
| EP1349085A2 (en) | Collision avoidance in database replication systems | |
| JP2001356945A (ja) | データバックアップ・リカバリー方式 | |
| US7293194B2 (en) | Method and device for switching database access part from for-standby to currently in use | |
| JP3572928B2 (ja) | バックアップ機能付オンラインデータベース情報処理システム | |
| JP4998010B2 (ja) | データベースシステム管理、データベースシステム、プログラム及び処理装置 | |
| JP3020539B2 (ja) | 並列動作型データベース管理方式 | |
| JP2005149043A (ja) | トランザクション処理システムおよび方法ならびにプログラム | |
| JP2005128811A (ja) | 無停止型取引システム、取引端末およびバックアップ地区システム | |
| JP3598202B2 (ja) | オンラインシステム | |
| JP3341637B2 (ja) | トランザクション処理システムにおける端末状態管理方法及びコンピュータ読み取り可能な記録媒体 | |
| JP2024014546A (ja) | データ管理システム、データ管理方法及びデータ管理プログラム | |
| US7302604B2 (en) | Remote management commands in a mass storage system | |
| JPH11345139A (ja) | 無停止型2重化システム |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20040316 |
|
| A521 | Written amendment |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040512 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040608 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040621 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080709 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090709 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100709 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100709 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110709 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110709 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120709 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120709 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130709 Year of fee payment: 9 |
|
| LAPS | Cancellation because of no payment of annual fees |