JP2015060343A - データベース管理方法およびデータベース管理システム - Google Patents

Abstract

【課題】現用系システムと待機系システムの間において、高精度の整合性が確保された引継ぎ処理を実行し、無停止運転を達成する。【解決手段】現用系システム１００が、データベース１１６の更新要求が示す更新情報のヘッダにトランザクション中の通番を設定し、更新要求毎に通番をインクリメントして以降の更新情報のヘッダに設定し、各更新情報を記憶装置に格納する第１処理と、記憶装置に格納した更新情報を所定タイミングで待機系システム２００に送信する第２処理を実行し、待機系システム２００が、現用系システム１００から更新情報を受信しキュー２２８に登録する第３処理と、登録された更新情報のうち同トランザクションに関するものを抽出し、ヘッダが示す通番に基づいてソートしてトランザクション中の処理順序に整合させた更新情報群を生成する第４処理と、更新情報群に基づいてデータベース２２６を更新する第５処理を実行する。【選択図】図１

Description

本発明は、データベース管理方法およびデータベース管理システムに関するものであり、具体的には、クリティカルな運用形態となる現用系システムとその待機系システムの間において、高精度の整合性が確保された引継ぎ処理を実行し、無停止運転を達成する技術に関する。

金融機関における勘定系システムなど、広く社会基盤となっているシステムについては、その重要性から無停止運転が求められており、対応する各種技術が提案されている。例えば、現用系システムとこれに同期する待機系システムとを合わせて運用し、現用系システムのメンテナンス時等にはシームレスに待機系システムが処理を引き継ぎ、利用者から見た無停止状態達成を目指す技術がある。

このような技術としては、例えば、本番システムで処理されたトランザクションについての少なくとも１の更新データを含むデータが格納されている前記本番システムの記憶部から、静止点前であってトランザクションがコミットされた最後の時点における、前記少なくとも１の更新データを含む前記データを取得し、該取得したデータを前記代行システムの記憶部にコピーする復元部と、前記更新データと該更新データのそれぞれに関連付けられ且つ前記静止点を識別可能にする情報とを蓄積するメッセージ・キューから、前記静止点を識別可能にする情報を用いて選択され且つ前記静止点以降にコミットされたところの更新データを前記代行システムの記憶部にコピーするコピー部と、前記選択された更新データのコピーが終了することに応じて、トランザクションの処理を受け付ける受付キューから少なくとも１のトランザクションを取得し、そして該取得したトランザクションの処理を開始するトランザクション処理部とからなる代行システム（特許文献１参照）などが提案されている。

特開２０１０−３３３９８号公報

しかしながら実際の現場においては、膨大な頻度で実行される各種処理によるフラグメントの解消や、金融機関における店舗統廃合によるＤＢ構成変更、ハード・ソフトの不良対策など、システム停止が回避しにくい様々な状況を考慮せざるを得ず、システム停止日を設ける措置がとられることも多い。このことは、従来技術が示すような処理の引継ぎ対応を行うとしても、現用系システムで扱っているデータについて、トランザクションにおける順序等も含めて確かな整合性を確保した上で、待機系システムに引き継ぐことが実際には困難であることに起因している。

そこで本発明の目的は、クリティカルな運用形態となる現用系システムとその待機系システムの間において、高精度の整合性が確保された引継ぎ処理を実行し、無停止運転を達成する技術を提供することにある。

上記課題を解決する本発明のデータベース管理方法は、非同期で待機系システムと接続された現用系システムが、所定トランザクションを実行中のアプリケーションからデータベースの更新要求を受けた際、当該更新要求に応じてデータベースの更新処理を実行すると共に、前記更新要求が示す更新情報のヘッダにトランザクション中の通番を設定し、前記トランザクションに関する更新要求を受ける毎に前記通番をインクリメントして、以降の更新情報のヘッダに設定し、各更新情報を記憶装置に格納する第１処理と、前記記憶装置に格納した前記更新情報を、所定タイミングで待機系システムに送信する第２処理を実行し、前記待機系システムが、前記現用系システムから前記更新情報を受信して、当該更新情報をキューに登録する第３処理と、前記キューに登録された更新情報のうち、同じトランザクションに関するものを抽出し、当該抽出した更新情報を、ヘッダが示す前記通番に基づいてソートして、トランザクション中の処理順序に整合させた更新情報群を生成する第４処理と、前記生成した更新情報群に基づいて、当該待機系システムにおけるデータベースを更新する第５処理を実行することを特徴とする。

また、本発明のデータベース管理システムは、非同期で互いに接続された現用系システム及び待機系システムを含むシステムであり、前記現用系システムが、所定トランザクションを実行中のアプリケーションからデータベースの更新要求を受けた際、当該更新要求に応じてデータベースの更新処理を実行すると共に、前記更新要求が示す更新情報のヘッダにトランザクション中の通番を設定し、前記トランザクションに関する更新要求を受ける毎に前記通番をインクリメントして、以降の更新情報のヘッダに設定し、各更新情報を記憶装置に格納する第１処理と、前記記憶装置に格納した前記更新情報を、所定タイミングで待機系システムに送信する第２処理を実行するものであり、前記待機系システムが、前記現用系システムから前記更新情報を受信して、当該更新情報をキューに登録する第３処理と、前記キューに登録された更新情報のうち、同じトランザクションに関するものを抽出し、当該抽出した更新情報を、ヘッダが示す前記通番に基づいてソートして、トランザクション中の処理順序に整合させた更新情報群を生成する第４処理と、前記生成した更新情報群に基づいて、当該待機系システムにおけるデータベースを更新する第５処理を実行するものであることを特徴とする。

本発明によれば、クリティカルな運用形態となる現用系システムとその待機系システムの間において、高精度の整合性が確保された引継ぎ処理を実行し、無停止運転を達成できる。

本実施形態のデータベース管理システムを含むネットワーク構成図である。 本実施形態のデータベース管理システムにおけるプライマリセンタの構成例を示すブロック図である。 本実施形態のデータベース管理システムにおけるセカンダリセンタの構成例を示すブロック図である。 本実施形態における更新情報テーブルのデータ構造例を示す図である。 本実施形態におけるＤＢ定義テーブルのデータ構造例を示す図である。 本実施形態におけるユーザ定義テーブルのデータ構造例を示す図である。 本実施形態におけるＡＰＰ定義テーブルのデータ構造例を示す図である。 本実施形態における製品情報テーブルのデータ構造例を示す図である。 本実施形態におけるＡＰＰ定義テーブル（セカンダリセンタ側）のデータ構造例を示す図である。 本実施形態におけるＤＢキュー情報テーブルのデータ構造例を示す図である。 本実施形態におけるユーザ定義テーブル（セカンダリセンタ側）のデータ構造例を示す図である。 本実施形態におけるデータベース管理方法の処理手順例１を示すフロー図である。 本実施形態におけるデータベース管理方法の処理手順例２を示すフロー図である。 本実施形態におけるデータベース管理方法の処理手順例３を示すフロー図である。

−−−システム構成−−−
以下に本発明の実施形態について図面を用いて詳細に説明する。図１は、本実施形態のデータベース管理システム１０を含むネットワーク構成図である。図１に示すデータベース管理システム１０は、クリティカルな運用形態となる現用系システムとその待機系システムの間において、高精度の整合性が確保された引継ぎ処理を実行し、無停止運転を達成するコンピュータシステムである。本実施形態におけるデータベース管理システム１０は、図１にて示すように、現用系システムたるプライマリセンタ１５と、その待機系システムたるセカンダリセンタ２０とを含む構成となっている。

こうしたデータベース管理システム１０は、一例として金融機関における勘定系システムに適用された状況を想定できる。その場合、プライマリセンタ１５は、勘定系の処理に伴うトランザクションに応じて、例えば預金残高等の各種顧客情報を管理しているデータベース１１６のデータ更新を行うこととなる。プライマリセンタ１５においてこうした処理を実行するのは送信側サーバ１００である。この送信側サーバ１００は、ＤＫＣ（ディスクコントローラ）１１５の配下にある上述のデータベース１１６にアクセスし、そのデータ更新を行うと共に、当該更新情報を送信側ジャーナル１１７に格納する処理を実行するものとなる。

一方、プライマリセンタ１５とネットワーク５０を介して接続され、待機系システムとして稼働するのがセカンダリセンタ２０である。このセカンダリセンタ２０は、プライマリセンタ１５における送信側サーバ１００で生じた更新情報を非同期（例：バッチ処理等）で取得して、データベース２２６をプライマリセンタ１５のデータベース１１６と同内容とすべくデータ更新を行うこととなる。セカンダリセンタ２０においてこうした処理を実行するのは受信側サーバ群２００であり、第１の受信側サーバ２１０および第２の受信側サーバ２５０で構成される。この受信側サーバ群２００は、ＤＫＣ（ディスクコントローラ）２２５の配下にある受信側ジャーナル２２７から更新情報（送信側ジャーナル１１７から送られたもの）を取得して適宜な処理を施した上で、ＤＢキュー２２８に登録し、更には、このＤＢキュー２２８に登録した情報に基づいて上述のデータベース２２６のデータ更新を行うものとなる。

図２は本実施形態のデータベース管理システム１０におけるプライマリセンタ１５の構成例を示すブロック図である。データベース管理システム１０を構成する各装置のうち、プライマリセンタ１５を構成する送信側サーバ１００のハードウェア構成は以下の如くとなる。送信側サーバ１００は、主記憶装置１０１、ハードディスクドライブなどで構成される補助記憶装置を含むＤＫＣ１１５、主記憶装置１０１に保持されるプログラム１０２のうちＯＳ１０８に基づいてアプリケーション１１０を読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵ（演算装置）１０４、ユーザからのキー入力や音声入力を受け付ける入力装置１０５、処理データの表示を行うディスプレイ等の出力装置１０６、ネットワーク５０と接続しＤＫＣ１１５を介してセカンダリセンタ２０との通信処理を担う通信装置１０７、を備える。勿論、入力装置１０５、出力装置１０６は必要に応じて備えるとすれば良く、最少構成としては具備しない形態であってもよい。また、送信側サーバ１００がデータベース１１６の更新や送信側ジャーナル１１７への更新情報の格納を行う際には、ＤＫＣ１１５への指示を行って該当処理を行うものとする。

なお、主記憶装置１０１内（補助記憶装置たるＤＫＣ配下の記憶装置であっても勿論よい）には、本実施形態のデータベース管理システムとして必要な機能を実装する為のＯＳ１０８やアプリケーション１１０を含むプログラム１０２に他に、ＤＢ定義テーブル１２６、ユーザ定義テーブル１２７、ＡＰＰ定義テーブル１２８、及び製品情報テーブル１２９が少なくとも記憶されている。また、ＤＫＣ配下の送信側ジャーナル１１７には更新情報テーブル１２５が格納されている。これらのテーブル１２５〜１２９の詳細については後述する。また、上述のアプリケーション１１０は、ユーザ部１１１、ＡＰＰ１１２、製品１１３から構成されている。製品１１３は、ＯｐｅｎＴＰ１（登録商標）などの、オープンシステム上でオンライントランザクション処理を実行するミドルウェアであり、この製品１１３をベースに勘定系処理に必要な機能を付与するプログラムがＡＰＰ１１２（アプリケーションパッケージ）であり、更に、このＡＰＰ１１２を金融機関（すなわちユーザ）ごとの仕様、機能に応じてカスタマイズした部分がユーザ部１１１となる。

他方、セカンダリセンタ２０の構成は以下のとおりである。図３は本実施形態のデータベース管理システム１０におけるセカンダリセンタ２０の構成例を示すブロック図である。セカンダリセンタ２０は、第１の受信側サーバ２００および第２の受信側サーバ２５０で構成されている。セカンダリセンタ２０における第１および第２の各受信側サーバ２１０、２５０とも、プライマリセンタ１５の待機系システムとして稼働するものである為、上述した送信側サーバ１００の構成と同様の構成を備えている。そこでここでは、送信側サーバ１００と異なる構成についてのみ説明する。

この場合、第１の受信側サーバ２１０は、プライマリセンタ１５における送信側サーバ１００とは異なるＡＰＰ定義テーブル２３５およびＤＢキュー情報テーブル２３６を主記憶装置２１１にて備えている（いずれも詳細は後述）。また、第２の受信側サーバ２５０は、送信側サーバ１００とは異なるユーザ定義テーブル２６５を主記憶装置２５１にて備えている。また、これら第１および第２の受信側サーバ２１０、２５０は、それぞれ補助記憶装置のＤＫＣ２２５に命じて、受信側ジャーナル２２７、ＤＢキュー２２８、およびデータベース２２６にアクセスすることが可能である。

続いて、本実施形態のデータベース管理システム１０における上述の各サーバらが備える機能について説明する。上述したように、以下に説明する機能は、例えばデータベース管理システム１０を構成する各サーバ１００、２１０、２５０らがそれぞれ備えるプログラムを各々実行することで実装される機能と言える。

プライマリセンタ１５の送信側サーバ１００は、所定トランザクションを実行中のアプリケーション１１０からデータベース１１６の更新要求を受けた際、当該更新要求に応じてＤＫＣ１１５配下のデータベース１１６の更新処理を実行すると共に、更新要求が示す更新情報のヘッダにトランザクション中の通番を設定し、トランザクションに関する更新要求を受ける毎に通番をインクリメントして、以降の更新情報のヘッダに設定し、各更新情報を更新情報テーブル１２５（送信側ジャーナル１１７が保持）に格納する機能を備えている。

なお、上述の送信側サーバ１００は、上述の通番のインクリメントに際し、更新情報のヘッダに設定した最新の通番を、該当トランザクションに関して主記憶装置１０１のＡＰＰ定義テーブル１２８にて格納する処理を更に実行し、インクリメントに際して、このＡＰＰ定義テーブル１２８に格納した最新の通番からインクリメントを行うものとする。

また、上述の送信側サーバ１００は、送信側ジャーナル１１７における更新情報テーブル１２５に保持する更新情報を、所定タイミングでセカンダリセンタ２０に送信する機能を備えている。

一方、セカンダリセンタ２０の第１の受信側サーバ２１０は、プライマリセンタ１５の送信側サーバ１００から上述の更新情報を受信して受信側ジャーナル２２７に格納すると共に、当該更新情報をＤＢキュー２２８に登録する機能を備えている。

また、セカンダリセンタ２０の第２の受信側サーバ２５０は、上述のＤＢキュー２２８に登録された更新情報のうち、同じトランザクションに関するものをトランザクションＩＤ等に基づいて抽出し、当該抽出した更新情報を、ヘッダが示す通番に基づいてソートして、トランザクション中の処理順序に整合させた更新情報群を生成する機能を備えている。 また、上述の第２の受信側サーバ２５０は、生成した更新情報群に基づいて、当該セカンダリセンタ２０におけるデータベース２２６を更新する機能を備えている。

なお、送信側サーバ１００が、上述した更新要求に応じた処理において、アプリケーション１１０からの更新要求が示す更新情報のユーザ定義領域に、ユーザ定義の通番を設定し、トランザクションに関する更新要求を受ける毎にユーザ定義の通番をインクリメントして、以降の更新情報のユーザ定義領域に設定する機能を更に備える場合、セカンダリセンタ２０の第２の受信側サーバ２５０は、以下の機能を備えている。

すなわち第２の受信側サーバ２５０は、送信側サーバ１００から第１の受信側サーバ２１０が受信してＤＢキュー２２８に格納した更新情報より、ユーザ定義の通番を参照し、これを主記憶装置２５１のユーザ定義テーブル２６５に格納する機能を備えている。

また、第２の受信側サーバ２５０は、ＤＢキュー２２８に登録された更新情報のうち、同じトランザクションに関するものをトランザクションＩＤ等をキーに抽出し、当該抽出した更新情報における最新のユーザ定義の通番が、ユーザ定義テーブル２６５に格納してあるユーザ定義の通番より１つ大きいとの条件を満たすか判定する機能を更に備えている。この処理を実行した第２の受信側サーバ２５０は、上述の条件が満たされなかった場合、所定時間待機して、第１の受信側サーバ２１０による上述の処理（更新情報をＤＢキュー２２８に登録する処理）の実行を待ち、上述した処理（更新情報を、ヘッダが示す通番に基づいてソートして、トランザクション中の処理順序に整合させた更新情報群を生成する処理）を再実行する。

また、第２の受信側サーバ２５０は、上述の更新情報群に基づいてデータベース２２６を更新する際に、プライマリセンタ１５におけるデータベース１１６の構成変更処理に対応した、当該セカンダリセンタ２０におけるデータベース２２６の構成変更処理の完了通知を、入力装置２５５ないし通信可能に結ばれた外部端末から受け付け済みである場合に、構成変更処理後のデータベース２２６の構成に対応する形式に、更新情報群の各更新情報を修正して、当該修正した更新情報群に基づいてデータベース２２６を更新する機能を更に備えている。

−−−データ構造例−−−
次に、本実施形態のデータベース管理システム１０が用いるテーブルにおけるデータ構造例について説明する。図４は本実施形態における更新情報テーブル１２５のデータ構造例を示す図である。更新情報テーブル１２５は、送信側ジャーナル１１７に格納されているテーブルであり、プライマリセンタ１５におけるデータベース１１６の更新情報を格納したテーブルである。更新情報テーブル１２５におけるレコードすなわち１つの更新情報は、データベース１１６に対する更新が発生する毎に格納される、すなわちアプリケーション１１０によるトランザクションの１つ１つに対応している。

こうしたレコードは、ＡＰＰヘッダ、更新レコード情報、およびユーザ情報から構成されている。更新情報のヘッダたるＡＰＰヘッダには、ＡＰＰ通番（トランザクション中の通番）、トランザクション最終フラグ（一連のトランザクション中の最終のものに付与されるフラグ）、およびトランザクションＩＤ（不図示）の各データが少なくとも含まれている。また、更新レコード情報は、データベース１１６の更新情報の実体部分であり、更新対象となるＤＢ名称およびレコード名称の各データが少なくとも含まれている。また、ユーザ情報は、例えばプライマリセンタ１５におけるユーザ部１１１で更新情報に関して定義した、ユーザ定義領域（ユーザが任意に値を設定できる予備的な領域）に、更新情報毎に付与される通番、すなわちファイル通番の値を少なくとも含んでいる。

図４で示す例においては、プライマリセンタ１５の送信側サーバ１００による処理が進む毎に、この更新情報テーブル１２５の所定レコードの、ＡＰＰ通番、トランザクション最終フラグ、およびファイル通番が書き換えられていく様子を表している。アプリケーション１１０から更新要求を受けただけの時点では、更新情報テーブル１２５に格納された更新情報は、図４における「第１段階」にて示すように、ＡＰＰ通番、トランザクション最終フラグ、およびファイル通番はいずれも「ＮＵＬＬ」となっている。また、ユーザ定義テーブル１２７のファイル通番（例：“７”）からインクリメントさせた値“８”を得た処理の後においては、「第２段階」にて示すように、ファイル通番は「８」となっている。また、ＡＰＰ定義１２８のＡＰＰ通番（例：“１”）からインクリメントさせた値“２”を得た処理の後においては、「第３段階」にて示すように、ＡＰＰ通番は「２」となっている。また、製品情報テーブル１２９の最終フラグから値“１”（一連のトランザクション中で最終のものを示す値）を得た処理の後においては、「第４段階」にて示すように、トランザクション最終フラグは「１」となっている。

また、図５は本実施形態におけるＤＢ定義テーブル１２６のデータ構造例を示す図である。このＤＢ定義テーブル１２６は、プライマリセンタ１５におけるデータベース１１６を構成するデータベースの情報を定義したテーブルである。ＤＢ定義テーブル１２６は、ＤＢ名称、その構成情報（ＤＢが格納するデータの実体）、ユーザ保有領域の各データを少なくとも含んだレコードの集合体となっている。このうちユーザ保有領域は、該当データベースにおいて上述したユーザ定義領域が設定されているか否かを示すフラグを格納する領域であり、ユーザ定義領域が設定されている場合、“１”のフラグが格納されている。このＤＢ定義テーブル１２６は、適宜な管理者等が予め生成して格納したものである。

また、図６は本実施形態におけるユーザ定義テーブル１２７のデータ構造例を示す図である。ユーザ定義テーブル１２７は、上述した更新情報におけるユーザ定義領域に設定されたファイル通番がデータベース毎に格納されたテーブルである。

また、図７は本実施形態におけるＡＰＰ定義テーブル１２８のデータ構造例を示す図である。ＡＰＰ定義テーブル１２８は、データベース１１６に含まれている各ＤＢについて、その構成情報、リモートＤＢのフラグ（セカンダリセンタ２０への更新反映対象か否かを示す値）、およびＡＰＰ通番の各データを少なくとも含んだレコードの集合体となっている。

また、図８は本実施形態における製品情報テーブル１２９のデータ構造例を示す図である。製品情報テーブル１２９は、アプリケーション１１０の処理で生じたトランザクションに関する情報を格納したテーブルであり、トランザクション番号（トランザクションＩＤ）、トランザクション種別（例：入金、出金、振込、など）、最終フラグ（トランザクション最終フラグ）の各データを少なくとも含んだレコードの集合体となっている。

また、図９は本実施形態におけるＡＰＰ定義テーブル２３５（セカンダリセンタ側）のデータ構造例を示す図である。セカンダリセンタ２０における第１の受信側サーバ２１０が備えるＡＰＰ定義テーブル２３５は、データベース１１６に含まれている各ＤＢ（セカンダリセンタ２０で更新反映するもの）について、そのＤＢ名称、レコード情報（構成情報）、およびサービス名（トランザクション種別と同様）の各データを少なくとも含んだレコードの集合体となっている。

また、図１０は本実施形態におけるＤＢキュー情報テーブル２３６のデータ構造例を示す図である。ＤＢキュー情報テーブル２３６は、ＤＢキュー２２８に格納された、プライマリセンタ１５由来の更新情報に関する情報を格納したテーブルである。このＤＢキュー情報テーブル２３６は、更新情報が含んでいるＡＰＰヘッダ、更新レコード情報、およびユーザ情報に加えて、ＤＢキューヘッダを備えたレコードの集合体となっている。このＤＢキューヘッダは、本実施形態のデータベース管理方法の処理対象、すなわち、プライマリセンタ１５におけるデータベース１１６からセカンダリセンタ２０におけるデータベース２２６更新反映処理の対象となっているトランザクションかを示すフラグを格納する領域となる。更新反映処理の対象となっている場合、フラグ「１」が格納されている。

また、図１１は本実施形態におけるユーザ定義テーブル２６５（セカンダリセンタ側）のデータ構造例を示す図である。このユーザ定義テーブル２６５は、プライマリセンタ１５由来の更新情報におけるユーザ定義領域に設定されたファイル通番と、構成変更後フラグ（セカンダリセンタ２０におけるデータベース２２６での構成変更処理の完了未済を示すフラグ）が、データベース毎に格納されたテーブルである。

−−−処理手順例１−−−
以下、本実施形態におけるデータベース管理方法の実際手順について図に基づき説明する。以下で説明するデータベース管理方法に対応する各種動作は、データベース管理システム１０を構成するプライマリセンタ１５の送信側サーバ１００、セカンダリセンタ２０を構成する第１の受信側サーバ２１０、および第２の受信側サーバ２５０が実行するプログラムによって実現される。そして、このプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。

図１２は、本実施形態におけるデータベース管理方法の処理手順例１を示すフロー図である。ここではまず、プライマリセンタ１５の送信側サーバ１００における処理について説明する。この場合、送信側サーバ１００のアプリケーション１１０におけるユーザ部１１１は、所定サービスの実行に応じてデータベース１１６の更新をＡＰＰ１１２に対して要求する（ｓ１００）。

ＡＰＰ１１２は、この要求を受けて、上述の要求が含む更新情報を一旦、主記憶装置１０１にて１レコードとして格納する（後に、送信側ジャーナル１１７の更新情報テーブル１２５に格納する）と共に、ＤＢ定義テーブル１２６において該当要求が示すＤＢに関するレコードを参照し、該当レコードにおけるユーザ保有領域フラグの有無を判定する（ｓ１０１）。つまり、上述の要求の対象となったＤＢの各レコードにユーザ定義領域が設定されているか判定することになる。なお、このステップｓ１０１の処理により更新情報テーブル１２５に格納されたレコードの状態は、図４にて「第１段階」として示した通りである。

上述のステップｓ１０１での判定により、該当レコードにてユーザ保有領域フラグ“１”が設定されていた場合、すなわち該当ＤＢのレコードにユーザ定義領域が設定されていたことが判明した場合（ｓ１０１：ＹＥＳ）、ＡＰＰ１１２はこの旨をユーザ部１１１に返す。他方、該当レコードにてユーザ保有領域フラグ“１”が設定されていなかった場合、すなわち該当ＤＢのレコードにユーザ定義領域が設定されていないことが判明した場合（ｓ１０１：ＮＯ）、ＡＰＰ１１２は処理をステップｓ１０３に進める。

一方、ユーザ部１１１は、ステップｓ１０１の結果として、該当ＤＢのレコードにユーザ定義領域が設定されていた旨をＡＰＰ１１２から受けたならば、ユーザ定義テーブル１２７におけるファイル通番の値を参照し、この値をインクリメントして更新した上で、主記憶装置１０１に一旦格納してある該当レコード（ステップｓ１０１で格納したもの）のファイル通番を同値で更新する（ｓ１０２）。このステップｓ１０２の処理後における該当レコードの状態は、図４にて「第２段階」として示した通りである。

ユーザ部１１１における上述のステップｓ１０２の処理完了を受けたＡＰＰ１１２は、ユーザ部１１０からの更新要求が示す更新情報に応じて、データベース１１６における該当ＤＢの更新処理を製品１１３に対して要求する（ｓ１０３）。製品１１３は、この要求を受けて、該当更新情報に基づいてＤＫＣ１１５に更新要求を指示することで、データベース１１６における該当ＤＢの更新を行う（ｓ１０４）。こうした更新処理は、アプリケーション１１０で処理データが生じ、データベース１１６における対応データを更新する必要が生じるごとに発生する。

一方、製品１１３による更新処理を受けたＡＰＰ１１２は、ＡＰＰ定義テーブル１２８における該当ＤＢのレコードを参照し、リモートＤＢフラグとして“１”が設定されているか判定する（ｓ１０５）。この判定の結果、該当ＤＢに関してリモートＤＢフラグとして“１”が設定されていなかった場合（ｓ１０５：ＮＯ）、ＡＰＰ１１２はその旨をユーザ部１１１に返し、ユーザ部１１１は当該トランザクションを終了する。すなわち、上述のステップｓ１０４でデータベースの更新処理を行ったトランザクションは、セカンダリセンタ２０におけるデータベース２２６の反映更新を必要としないものであったと認識して処理を終了するのである。

他方、上述のステップｓ１０５の判定の結果、該当ＤＢに関してリモートＤＢフラグとして“１”が設定されていた場合（ｓ１０５：ＹＥＳ）、ＡＰＰ１１２は、ＡＰＰ定義テーブル１２８における該当ＤＢのレコードを参照して、ＡＰＰ通番の値を抽出してインクリメントして更新した上で、この値を、主記憶装置１０１に格納してある該当レコードのＡＰＰ通番に設定する（ｓ１０６）。このステップｓ１０６の処理後における該当レコードの状態は、図４にて「第３段階」として示した通りである。

また、ＡＰＰ１１２は、製品情報テーブル１２９におけるレコードがトランザクション最終フラグ“１”を保有しているか判定する（ｓ１０７）。該当レコードが、トランザクション最終フラグ“１”を保有していなかった場合（ｓ１０７：ＮＯ）、ＡＰＰ１１２は、その旨を製品１１３に通知して処理をステップｓ１０９に進める。他方、該当レコードが、トランザクション最終フラグ“１”を保有していた場合（ｓ１０７：ＹＥＳ）、ＡＰＰ１１２は、このトランザクション最終フラグ“１”を主記憶装置１０１に格納してある該当レコードのＡＰＰヘッダのうちトランザクション最終フラグ欄に格納する（ｓ１０８）。

上述のステップｓ１０７で、該当レコードが、トランザクション最終フラグ“１”を保有していなかった場合（ｓ１０７：ＮＯ）、および、上述のステップｓ１０８の処理を受けた製品１１３は、主記憶装置１０１に一旦格納していた上述のレコードを、送信側ジャーナル１１７における更新情報テーブル１２５のレコードとして登録する（ｓ１０９）。

なお、上述の各ステップを例えば１時間、或いは１日などの所定期間繰り返し実行し、所定時刻が到来した時点で、製品１１３は、送信側ジャーナル１１７に蓄積された更新情報テーブル１２５のデータを、セカンダリセンタ２０における第１の受信側サーバ２１０に送信するものとする。この時、送信側ジャーナル１１７のデータを受信した第１の受信側サーバ２１０は、ＤＫＣ２２５に命じて、その配下にある受信側ジャーナル２２７に該当データの格納を行う。こうして、非同期にて、送信側ジャーナル１１７のデータによって受信側ジャーナル２２７の格納データが更新される。

−−−処理手順例２−−−
次に、セカンダリセンタ２０の第１の受信側サーバ２１０における、ＤＢキュー２２８へのデータ登録処理について図に基づき説明する。図１３は、本実施形態におけるデータベース管理方法の処理手順例２を示すフロー図である。

この場合、セカンダリセンタ２０の第１の受信側サーバ２１０における製品２２３は、受信側ジャーナル２２７にデータが格納されているか判定し（ｓ２００）、データが格納されていなかった場合（ｓ２００：ＮＯ）、例えば１０秒間スリープして、再びステップｓ２００を実行する。一方、受信側ジャーナル２２７にデータが格納されていた場合（ｓ２００：ＹＥＳ）、製品２２３は、受信側ジャーナル２２７よりデータを取得し（ｓ２０１）、該当データをＡＰＰ２２２に引き渡す。

ＡＰＰ２２２は、製品２２３から引き渡された受信側ジャーナル２２７のデータ、すなわち更新情報を受けて、当該更新情報が含むＤＢ名称及びレコード名称の値を、ＡＰＰ定義テーブル２３５に照合して該当サービスを決定し、ここで決定したサービスに対応して主記憶装置２１１にて設けた処理キューへ登録する（ｓ２０２）。

一方、製品２２３は、ＡＰＰ２２２による上述のステップ２０２の処理を受けて、該当処理キューより更新情報のデータを引きだし（ｓ２０３）、ＡＰＰ２２２に引き渡す。ＡＰＰ２２２は、これを受けて、ＤＢキュー情報テーブル２３６に生成したレコード（該当更新情報を含むレコード）に反映トランザクションフラグ“１”を設定し、ＤＢキュー２２８に登録する（ｓ２０４）。

−−−処理手順例３−−−
次に、セカンダリセンタ２０の第２の受信側サーバ２５０が実行する処理について図に基づき説明する。図１４は、本実施形態におけるデータベース管理方法の処理手順例３を示すフロー図である。この場合、第２の受信側サーバ２５０における製品２６３は、上述のステップｓ２０４にて登録されているデータを、ＤＢキュー２２８より取り出し（ｓ３００）、該当データをＡＰＰ２６２に引き渡す。

一方、ＡＰＰ２６２は、製品２６３から引き渡されたデータ、すなわちＤＢキュー２２８に登録されていた更新情報に関して、ＤＢキュー情報テーブル２３６の該当レコードに反映トランザクションフラグ“１”が設定されているか判定する（ｓ３０１）。該当レコードに反映トランザクションフラグ“１”が設定されていなかった場合（ｓ３０１：ＮＯ）、ＡＰＰ２６２は、ＤＢキュー２２８より取り出した更新情報はセカンダリセンタ２０におけるデータベース２２６に反映させる必要のないものであると認識して、通常トランザクションとして起動し、以降のフローを終了する。他方、上述のステップｓ３０１の結果、該当レコードに反映トランザクションフラグ“１”が設定されていた場合（ｓ３０１：ＹＥＳ）、ＡＰＰ２６２は、ＤＢキュー２２８から更新情報によるデータベース２２６の更新、すなわち、反映トランザクションを起動する（ｓ３０２）。

ステップｓ３０２に続いてＡＰＰ２６２は、該当更新情報におけるＡＰＰヘッダにトランザクション最終フラグ“１”が含まれているか判定する（ｓ３０３）。該当更新情報におけるＡＰＰヘッダにトランザクション最終フラグ“１”が含まれていなかった場合（ｓ３０３：ＮＯ）、ＡＰＰ２６２は、主記憶装置２１１に設けた所定のバッファへ、該当更新情報のデータを退避させ、次トランザクションを待つ（ｓ３０４）。これを受けた製品２６３はトランザクションを終了する（ｓ３０５）。

他方、ステップｓ３０３の判定の結果、該当更新情報におけるＡＰＰヘッダにトランザクション最終フラグ“１”が含まれていた場合（ｓ３０３：ＹＥＳ）、ＡＰＰ２６２は、バッファ（これより前のいずれかのタイミングで主記憶装置２１１に設けられているもの）へ退避した更新情報のデータがあるか判定する（ｓ３０６）。この判定の結果、バッファへ退避した更新情報のデータが無かった場合（ｓ３０６：ＮＯ）、ＡＰＰ２６２はその旨をユーザ部２６１に通知し、処理をステップ３０８に進める。

他方、ステップｓ３０６の結果、バッファへ退避した更新情報のデータがあった場合（ｓ３０６：ＹＥＳ）、ＡＰＰ２６２は、同じトランザクションＩＤが付与されている更新情報（ｓ３００で取り出したもの由来）に関し、各更新情報が含むＡＰＰ通番の値に基づいて更新情報のソート処理を実行し、トランザクション中の処理順序に整合させた更新情報群を生成し（ｓ３０７）、ユーザ部２６１に引き渡す。

ステップｓ３０７の処理結果を受けたユーザ部２６１は、ＡＰＰ２６２から引き渡された更新情報より、例えば値が最も大きいファイル通番の値を参照し、該当値が、ユーザ定義テーブル２６５の該当ＤＢに関するレコードのファイル通番の値の次の値、すなわち１つインクリメントされた値になっているか判定する（ｓ３０８）。

この判定の結果、ＡＰＰ２６２から引き渡された更新情報におけるファイル通番の値が、ユーザ定義テーブル２６５の該当ＤＢに関するレコードのファイル通番の値の次の値でなかった場合（ｓ３０８：ＮＯ）、ユーザ部２６１は、該当更新情報のデータをバッファへ退避させ、次トランザクションを待つ（ｓ３０９）。これを受けた製品２６３はトランザクション終了する（ｓ３１０）。

他方、ステップｓ３０８の判定の結果、ＡＰＰ２６２から引き渡された更新情報におけるファイル通番の値が、ユーザ定義テーブル２６５の該当ＤＢに関するレコードのファイル通番の値の次の値であった場合（ｓ３０８：ＹＥＳ）、ユーザ部２６１は、上述のバッファへ退避した更新情報のデータがあるか判定する（ｓ３１１）。

この判定の結果、バッファへ退避した更新情報のデータがあった場合（ｓ３１１：ＹＥＳ）、ユーザ部２６１は、バッファに退避してあった更新情報（ステップｓ３０７で生成した更新情報群）に関し、各更新情報が含むファイル通番の値に基づいて更新情報のソート処理をあらためて実行し、トランザクション中の処理順序に整合させる、すなわちファイル通番に基づく通番補正処理を実行する（ｓ３１２）。

上述のステップｓ３１２に続いて、或いは、ステップｓ３１１の判定結果がバッファへ退避した更新情報のデータがなかった場合（ｓ３１１：ＮＯ）、ユーザ部２６１は、ユーザ定義テーブル２６５における該当ＤＢのレコードを参照し、構成変更後フラグに“１”が設定されているか、すなわち、データベース２２６における該当ＤＢに関して構成変更が完了しているか判定する（ｓ３１３）。

この判定の結果、データベース２２６における該当ＤＢに関して構成変更が完了していた場合（ｓ３１３：ＹＥＳ）、ユーザ部２６１は、ＤＢの構成変更によるデータ構造の変化、例えば所定データのデータ長変化（例えば、構成変更前は４バイトであったのが、６バイトに変化）に対応すべく、ここまでのステップで得ている更新情報群の該当データのデータ長を修正する（例：２バイトの領域を付加）といった対応処理を実行する（ｓ３１４）。

上述のステップｓ３１４に続いて、或いは、ステップｓ３１３の判定結果が該当ＤＢに関して構成変更が完了していなかった場合（ｓ３１３：ＮＯ）、ユーザ部２６１は、上述の更新情報群の各更新情報のレコードにて、データベース更新には不要な項目（ＡＰＰヘッダやユーザ情報）を削除する処理、すなわちレコード編集処理を実行する（ｓ３１５）。

また、上述のステップｓ３１５の処理完了を受けて、ユーザ部２６１は、ＡＰＰ２６２に対してＤＢ更新要求を行う（ｓ３１６）。これを受けたＡＰＰ２６２は、ＤＢ更新要求を製品２６３に実行し（ｓ３１７）、これを受けた製品２６３は、要求が示す更新情報に基づいてデータベース２２６における該当ＤＢの更新を実行する（ｓ３１８）。

このように、セカンダリセンタ２０におけるデータベース２２６に関し、プライマリセンタ１５のデータベース１１６に対してなされる構成変更と同様の構成変更を施し、なおかつ、データベース１１６の更新に由来する更新情報によって更新した上で、プライマリセンタ１５での処理を引き継いでオンラインシステムとして稼働開始させた後、プライマリセンタ１５の停止と構成変更を実行し、その後の所定のタイミングにて、セカンダリセンタ２０のデータベース２２６を、プライマリセンタ１５のデータベース１１６にコピーしてプライマリセンタ１５のオンライン復帰を行う。こうした処理は、すなわち、現用系システムたるプライマリセンタ１５と、その待機系システムたるセカンダリセンタ２０の間において、高精度の整合性が確保された引継ぎ処理を実行し、無停止運転を達成することとなる。

以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。

こうした本実施形態によれば、クリティカルな運用形態となる現用系システムとその待機系システムの間において、高精度の整合性が確保された引継ぎ処理を実行し、無停止運転を達成することが出来る。

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態のデータベース管理方法において、前記現用系システムが、前記第１処理において、前記更新情報のヘッダに設定した最新の通番を該当トランザクションに関して記憶装置に格納する処理を更に実行し、前記インクリメントに際して、前記記憶装置に格納した最新の通番からインクリメントを行うとしてもよい。

これによれば、上述の通番のインクリメントに際しベースとなる通番の値を確実に管理することが可能となる。

また、本実施形態のデータベース管理方法において、前記現用系システムが、前記第１処理において、前記更新要求が示す更新情報のユーザ定義領域に、ユーザ定義の通番を設定し、前記トランザクションに関する更新要求を受ける毎に前記ユーザ定義の通番をインクリメントして、以降の更新情報のユーザ定義領域に設定する処理を更に実行し、前記待機系システムが、前記第３処理において、前記現用系システムから前記更新情報を受信した際、当該更新情報が示すユーザ定義の通番を記憶装置に格納する処理を更に実行し、前記第４処理において、前記キューに登録された更新情報のうち、同じトランザクションに関するものを抽出し、当該抽出した更新情報における最新のユーザ定義の通番が、前記第３処理にて前記記憶装置に格納してあるユーザ定義の通番より１つ大きいとの条件を満たすか判定する処理を更に実行し、前記条件を満たさなかった場合、所定時間待機して前記第３処理及び第４処理を再実行するとしてもよい。

これによれば、ヘッダに設定した通番に基づいて、更新情報をトランザクション中の処理順序に整合させる処理に加えて、ユーザ定義領域に設定したユーザ定義の通番に基づく更新情報の順序性を確保することも可能となり、更に高精度の整合性が確保された引継ぎ処理を実行することが出来る。

また、本実施形態のデータベース管理方法において、前記待機系システムが、前記第５処理において、前記現用系システムにおけるデータベースの構成変更処理に対応した、当該待機系システムにおけるデータベースの構成変更処理の完了通知を、入力装置ないし通信可能に結ばれた外部端末から受け付け済みである場合に、前記構成変更処理後のデータベースの構成に対応する形式に、前記更新情報群の各更新情報を修正して、当該修正した更新情報群に基づいて、当該待機系システムにおけるデータベースを更新するとしてもよい。

これによれば、現用系システムでのデータベースの構成変更処理に先立ち、該当構成変更処理の内容に応じて待機系システムのデータベースの構成変更処理を行い、その上で現用系システムから処理の引継ぎを行うことが可能である。その場合、現用系システムでのデータベースの構成変更処理が完了した時点で、オンラインシステムを待機系システムから現用系システムへ復帰させることも、トランザクション中での更新情報の順序性を高精度に確保しつつ、円滑かつ確実に実行できる。

１０ データベース管理システム
１５ プライマリセンタ
２０ セカンダリセンタ
５０ ネットワーク
１００ 送信側サーバ（現用系システム）
１０１ 記憶装置
１０２ プログラム
１０３ 主記憶装置
１０４ 演算装置
１０５ 入力装置
１０６ 出力装置
１０７ 通信装置
１０８ ＯＳ
１１０ アプリケーション
１１１ ユーザ部
１１２ ＡＰＰ
１１３ 製品
１１５ ＤＫＣ
１１６ データベース
１１７ 送信側ジャーナル
１２５ 更新情報テーブル
１２６ ＤＢ定義テーブル
１２７ ユーザ定義テーブル
１２８ ＡＰＰ定義テーブル
１２９ 製品情報テーブル
２００ 受信側サーバ群（待機系システム）
２１０ 第１の受信側サーバ
２１１ 記憶装置
２１２ プログラム
２１３ 主記憶装置
２１４ 演算装置
２１５ 入力装置
２１６ 出力装置
２１７ 通信装置
２１８ ＯＳ
２１０ アプリケーション
２２１ ユーザ部
２２２ ＡＰＰ
２２３ 製品
２２５ ＤＫＣ
２２６ データベース
２２７ 受信側ジャーナル
２２８ ＤＢキュー
２３５ ＡＰＰ定義テーブル
２３６ ＤＢキュー情報テーブル
２５０ 第２の受信側サーバ
２５１ 記憶装置
２５２ プログラム
２５３ 主記憶装置
２５４ 演算装置
２５５ 入力装置
２５６ 出力装置
２５７ 通信装置
２５８ ＯＳ
２６０ アプリケーション
２６１ ユーザ部
２６２ ＡＰＰ
２６３ 製品
２６５ ユーザ定義テーブル

Claims (5)

1. 非同期で待機系システムと接続された現用系システムが、
   所定トランザクションを実行中のアプリケーションからデータベースの更新要求を受けた際、当該更新要求に応じてデータベースの更新処理を実行すると共に、前記更新要求が示す更新情報のヘッダにトランザクション中の通番を設定し、前記トランザクションに関する更新要求を受ける毎に前記通番をインクリメントして、以降の更新情報のヘッダに設定し、各更新情報を記憶装置に格納する第１処理と、
   前記記憶装置に格納した前記更新情報を、所定タイミングで待機系システムに送信する第２処理を実行し、
   前記待機系システムが、
   前記現用系システムから前記更新情報を受信して、当該更新情報をキューに登録する第３処理と、
   前記キューに登録された更新情報のうち、同じトランザクションに関するものを抽出し、当該抽出した更新情報を、ヘッダが示す前記通番に基づいてソートして、トランザクション中の処理順序に整合させた更新情報群を生成する第４処理と、
   前記生成した更新情報群に基づいて、当該待機系システムにおけるデータベースを更新する第５処理を実行する、
   ことを特徴とするデータベース管理方法。
2. 前記現用系システムが、
   前記第１処理において、前記更新情報のヘッダに設定した最新の通番を該当トランザクションに関して記憶装置に格納する処理を更に実行し、前記インクリメントに際して、前記記憶装置に格納した最新の通番からインクリメントを行う、
   ことを特徴とする請求項１に記載のデータベース管理方法。
3. 前記現用系システムが、
   前記第１処理において、前記更新要求が示す更新情報のユーザ定義領域に、ユーザ定義の通番を設定し、前記トランザクションに関する更新要求を受ける毎に前記ユーザ定義の通番をインクリメントして、以降の更新情報のユーザ定義領域に設定する処理を更に実行し、
   前記待機系システムが、
   前記第３処理において、前記現用系システムから前記更新情報を受信した際、当該更新情報が示すユーザ定義の通番を記憶装置に格納する処理を更に実行し、
   前記第４処理において、前記キューに登録された更新情報のうち、同じトランザクションに関するものを抽出し、当該抽出した更新情報における最新のユーザ定義の通番が、前記第３処理にて前記記憶装置に格納してあるユーザ定義の通番より１つ大きいとの条件を満たすか判定する処理を更に実行し、前記条件を満たさなかった場合、所定時間待機して前記第３処理及び第４処理を再実行する、
   ことを特徴とする請求項２に記載のデータベース管理方法。
4. 前記待機系システムが、
   前記第５処理において、前記現用系システムにおけるデータベースの構成変更処理に対応した、当該待機系システムにおけるデータベースの構成変更処理の完了通知を、入力装置ないし通信可能に結ばれた外部端末から受け付け済みである場合に、前記構成変更処理後のデータベースの構成に対応する形式に、前記更新情報群の各更新情報を修正して、当該修正した更新情報群に基づいて、当該待機系システムにおけるデータベースを更新することを特徴とする請求項３に記載のデータベース管理方法。
5. 非同期で互いに接続された現用系システム及び待機系システムを含むシステムであり、
   前記現用系システムが、
   所定トランザクションを実行中のアプリケーションからデータベースの更新要求を受けた際、当該更新要求に応じてデータベースの更新処理を実行すると共に、前記更新要求が示す更新情報のヘッダにトランザクション中の通番を設定し、前記トランザクションに関する更新要求を受ける毎に前記通番をインクリメントして、以降の更新情報のヘッダに設定し、各更新情報を記憶装置に格納する第１処理と、
   前記記憶装置に格納した前記更新情報を、所定タイミングで待機系システムに送信する第２処理を実行するものであり、
   前記待機系システムが、
   前記現用系システムから前記更新情報を受信して、当該更新情報をキューに登録する第３処理と、
   前記キューに登録された更新情報のうち、同じトランザクションに関するものを抽出し、当該抽出した更新情報を、ヘッダが示す前記通番に基づいてソートして、トランザクション中の処理順序に整合させた更新情報群を生成する第４処理と、
   前記生成した更新情報群に基づいて、当該待機系システムにおけるデータベースを更新する第５処理を実行するものである、
   ことを特徴とするデータベース管理システム。

Images