JP6047472B2

JP6047472B2 - Database management method and database management system

Info

Publication number: JP6047472B2
Application number: JP2013192644A
Authority: JP
Inventors: 仁宮繁; 俊一長瀬
Original assignee: Hitachi Ltd
Current assignee: Hitachi Ltd
Priority date: 2013-09-18
Filing date: 2013-09-18
Publication date: 2016-12-21
Anticipated expiration: 2033-09-18
Also published as: JP2015060343A

Description

本発明は、データベース管理方法およびデータベース管理システムに関するものであり、具体的には、クリティカルな運用形態となる現用系システムとその待機系システムの間において、高精度の整合性が確保された引継ぎ処理を実行し、無停止運転を達成する技術に関する。 The present invention relates to a database management method and a database management system, and more specifically, a takeover process in which high-precision consistency is ensured between an active system that is a critical operation mode and its standby system. This technology relates to a technology that achieves non-stop operation.

金融機関における勘定系システムなど、広く社会基盤となっているシステムについては、その重要性から無停止運転が求められており、対応する各種技術が提案されている。例えば、現用系システムとこれに同期する待機系システムとを合わせて運用し、現用系システムのメンテナンス時等にはシームレスに待機系システムが処理を引き継ぎ、利用者から見た無停止状態達成を目指す技術がある。 Non-stop operation is required for systems that are widely used as social infrastructure, such as accounting systems in financial institutions, because of their importance, and various corresponding technologies have been proposed. For example, the active system and a standby system that synchronizes with this system are operated together, and the standby system seamlessly takes over processing during maintenance of the active system, aiming to achieve a non-stop state as seen by the user There is technology.

このような技術としては、例えば、本番システムで処理されたトランザクションについての少なくとも１の更新データを含むデータが格納されている前記本番システムの記憶部から、静止点前であってトランザクションがコミットされた最後の時点における、前記少なくとも１の更新データを含む前記データを取得し、該取得したデータを前記代行システムの記憶部にコピーする復元部と、前記更新データと該更新データのそれぞれに関連付けられ且つ前記静止点を識別可能にする情報とを蓄積するメッセージ・キューから、前記静止点を識別可能にする情報を用いて選択され且つ前記静止点以降にコミットされたところの更新データを前記代行システムの記憶部にコピーするコピー部と、前記選択された更新データのコピーが終了することに応じて、トランザクションの処理を受け付ける受付キューから少なくとも１のトランザクションを取得し、そして該取得したトランザクションの処理を開始するトランザクション処理部とからなる代行システム（特許文献１参照）などが提案されている。 As such a technique, for example, the transaction is committed before the quiesce point from the storage unit of the production system in which data including at least one update data for the transaction processed in the production system is stored. Acquiring the data including the at least one update data at the last time, copying the acquired data to the storage unit of the surrogate system, and each of the update data and the update data, and Update data selected from the message queue that stores the information that makes the quiesce point identifiable and information that makes the quiesce point identifiable and committed after the quiesce point is stored in the proxy system. The copy unit to be copied to the storage unit and the copy of the selected update data are completed. In response, obtains at least one transaction from the reception queue that receives the transaction processing, and the like agent system comprising a transaction processing unit for starting the processing of the acquired transaction (see Patent Document 1) has been proposed.

特開２０１０−３３３９８号公報JP 2010-33398 A

しかしながら実際の現場においては、膨大な頻度で実行される各種処理によるフラグメントの解消や、金融機関における店舗統廃合によるＤＢ構成変更、ハード・ソフトの不良対策など、システム停止が回避しにくい様々な状況を考慮せざるを得ず、システム停止日を設ける措置がとられることも多い。このことは、従来技術が示すような処理の引継ぎ対応を行うとしても、現用系システムで扱っているデータについて、トランザクションにおける順序等も含めて確かな整合性を確保した上で、待機系システムに引き継ぐことが実際には困難であることに起因している。 However, in the actual field, there are various situations where it is difficult to avoid a system outage, such as fragment elimination by various processes executed at enormous frequency, DB configuration change by consolidation of stores in financial institutions, and countermeasures for hardware and software defects. In many cases, measures are taken to set a system shutdown date. This means that even if the processing takeover corresponding to the prior art is performed, the data handled by the active system is secured to the standby system after ensuring certain consistency including the order in the transaction. This is due to the fact that it is actually difficult to take over.

そこで本発明の目的は、クリティカルな運用形態となる現用系システムとその待機系システムの間において、高精度の整合性が確保された引継ぎ処理を実行し、無停止運転を達成する技術を提供することにある。 Accordingly, an object of the present invention is to provide a technique for performing a non-stop operation by executing a takeover process ensuring high-precision consistency between an active system that is a critical operation mode and its standby system. There is.

上記課題を解決する本発明のデータベース管理方法は、非同期で待機系システムと接続された現用系システムが、所定トランザクションを実行中のアプリケーションからデータベースの更新要求を受けた際、当該更新要求に応じてデータベースの更新処理を実行すると共に、前記更新要求が示す更新情報のヘッダにトランザクション中の通番を設定し、前記トランザクションに関する更新要求を受ける毎に前記通番をインクリメントして、以降の更新情報のヘッダに設定し、各更新情報を記憶装置に格納する第１処理と、前記記憶装置に格納した前記更新情報を、所定タイミングで待機系システムに送信する第２処理を実行し、前記待機系システムが、前記現用系システムから前記更新情報を受信して、当該更新情報をキューに登録する第３処理と、前記キューに登録された更新情報のうち、同じトランザクションに関するものを抽出し、当該抽出した更新情報を、ヘッダが示す前記通番に基づいてソートして、トランザクション中の処理順序に整合させた更新情報群を生成する第４処理と、前記生成した更新情報群に基づいて、当該待機系システムにおけるデータベースを更新する第５処理を実行することを特徴とする。 The database management method of the present invention that solves the above problem is that when the active system asynchronously connected to the standby system receives a database update request from an application that is executing a predetermined transaction, the database management method responds to the update request. A database update process is executed, a serial number in the transaction is set in the header of the update information indicated by the update request, and the serial number is incremented every time an update request related to the transaction is received, and the header of the subsequent update information A first process for setting and storing each update information in the storage device, and a second process for transmitting the update information stored in the storage device to the standby system at a predetermined timing. Receiving the update information from the active system and registering the update information in a queue; And the update information registered in the queue is extracted for the same transaction, and the extracted update information is sorted based on the serial number indicated by the header to match the processing order in the transaction. A fourth process for generating an update information group and a fifth process for updating a database in the standby system are executed based on the generated update information group.

また、本発明のデータベース管理システムは、非同期で互いに接続された現用系システム及び待機系システムを含むシステムであり、前記現用系システムが、所定トランザクションを実行中のアプリケーションからデータベースの更新要求を受けた際、当該更新要求に応じてデータベースの更新処理を実行すると共に、前記更新要求が示す更新情報のヘッダにトランザクション中の通番を設定し、前記トランザクションに関する更新要求を受ける毎に前記通番をインクリメントして、以降の更新情報のヘッダに設定し、各更新情報を記憶装置に格納する第１処理と、前記記憶装置に格納した前記更新情報を、所定タイミングで待機系システムに送信する第２処理を実行するものであり、前記待機系システムが、前記現用系システムから前記更新情報を受信して、当該更新情報をキューに登録する第３処理と、前記キューに登録された更新情報のうち、同じトランザクションに関するものを抽出し、当該抽出した更新情報を、ヘッダが示す前記通番に基づいてソートして、トランザクション中の処理順序に整合させた更新情報群を生成する第４処理と、前記生成した更新情報群に基づいて、当該待機系システムにおけるデータベースを更新する第５処理を実行するものであることを特徴とする。 The database management system of the present invention is a system including an active system and a standby system that are asynchronously connected to each other, and the active system receives a database update request from an application that is executing a predetermined transaction. At this time, the database update process is executed in response to the update request, the serial number in the transaction is set in the header of the update information indicated by the update request, and the serial number is incremented each time an update request related to the transaction is received. , Set in the header of subsequent update information, and execute a first process for storing each update information in the storage device and a second process for transmitting the update information stored in the storage device to the standby system at a predetermined timing The standby system is changed from the active system to the update system. Receiving the information and registering the update information in the queue and the update information registered in the queue, the information related to the same transaction is extracted, and the extracted update information is indicated by the serial number indicated by the header. And a fifth process for updating the database in the standby system based on the generated update information group based on the generated update information group. It is what is executed.

本発明によれば、クリティカルな運用形態となる現用系システムとその待機系システムの間において、高精度の整合性が確保された引継ぎ処理を実行し、無停止運転を達成できる。 According to the present invention, it is possible to perform non-stop operation by executing a takeover process in which high-precision consistency is ensured between an active system that is a critical operation mode and its standby system.

本実施形態のデータベース管理システムを含むネットワーク構成図である。It is a network block diagram containing the database management system of this embodiment. 本実施形態のデータベース管理システムにおけるプライマリセンタの構成例を示すブロック図である。It is a block diagram which shows the structural example of the primary center in the database management system of this embodiment. 本実施形態のデータベース管理システムにおけるセカンダリセンタの構成例を示すブロック図である。It is a block diagram which shows the structural example of the secondary center in the database management system of this embodiment. 本実施形態における更新情報テーブルのデータ構造例を示す図である。It is a figure which shows the example of a data structure of the update information table in this embodiment. 本実施形態におけるＤＢ定義テーブルのデータ構造例を示す図である。It is a figure which shows the data structure example of the DB definition table in this embodiment. 本実施形態におけるユーザ定義テーブルのデータ構造例を示す図である。It is a figure which shows the example of a data structure of the user definition table in this embodiment. 本実施形態におけるＡＰＰ定義テーブルのデータ構造例を示す図である。It is a figure which shows the example of a data structure of the APP definition table in this embodiment. 本実施形態における製品情報テーブルのデータ構造例を示す図である。It is a figure which shows the example of a data structure of the product information table in this embodiment. 本実施形態におけるＡＰＰ定義テーブル（セカンダリセンタ側）のデータ構造例を示す図である。It is a figure which shows the example of a data structure of the APP definition table (secondary center side) in this embodiment. 本実施形態におけるＤＢキュー情報テーブルのデータ構造例を示す図である。It is a figure which shows the example of a data structure of the DB queue information table in this embodiment. 本実施形態におけるユーザ定義テーブル（セカンダリセンタ側）のデータ構造例を示す図である。It is a figure which shows the example of a data structure of the user definition table (secondary center side) in this embodiment. 本実施形態におけるデータベース管理方法の処理手順例１を示すフロー図である。It is a flowchart which shows process sequence example 1 of the database management method in this embodiment. 本実施形態におけるデータベース管理方法の処理手順例２を示すフロー図である。It is a flowchart which shows process sequence example 2 of the database management method in this embodiment. 本実施形態におけるデータベース管理方法の処理手順例３を示すフロー図である。It is a flowchart which shows process sequence example 3 of the database management method in this embodiment.

−−−システム構成−−−
以下に本発明の実施形態について図面を用いて詳細に説明する。図１は、本実施形態のデータベース管理システム１０を含むネットワーク構成図である。図１に示すデータベース管理システム１０は、クリティカルな運用形態となる現用系システムとその待機系システムの間において、高精度の整合性が確保された引継ぎ処理を実行し、無停止運転を達成するコンピュータシステムである。本実施形態におけるデータベース管理システム１０は、図１にて示すように、現用系システムたるプライマリセンタ１５と、その待機系システムたるセカンダリセンタ２０とを含む構成となっている。 --- System configuration ---
Embodiments of the present invention will be described below in detail with reference to the drawings. FIG. 1 is a network configuration diagram including a database management system 10 of the present embodiment. A database management system 10 shown in FIG. 1 is a computer that achieves non-stop operation by executing a takeover process that ensures high-precision consistency between an active system that is a critical operation mode and its standby system. System. As shown in FIG. 1, the database management system 10 in the present embodiment includes a primary center 15 that is an active system and a secondary center 20 that is a standby system.

こうしたデータベース管理システム１０は、一例として金融機関における勘定系システムに適用された状況を想定できる。その場合、プライマリセンタ１５は、勘定系の処理に伴うトランザクションに応じて、例えば預金残高等の各種顧客情報を管理しているデータベース１１６のデータ更新を行うこととなる。プライマリセンタ１５においてこうした処理を実行するのは送信側サーバ１００である。この送信側サーバ１００は、ＤＫＣ（ディスクコントローラ）１１５の配下にある上述のデータベース１１６にアクセスし、そのデータ更新を行うと共に、当該更新情報を送信側ジャーナル１１７に格納する処理を実行するものとなる。 As an example, such a database management system 10 can be assumed to be applied to a billing system in a financial institution. In this case, the primary center 15 updates the data in the database 116 that manages various customer information such as deposit balances, for example, according to the transaction associated with the accounting process. It is the transmitting server 100 that executes such processing in the primary center 15. The transmission side server 100 accesses the above-described database 116 under the control of the DKC (disk controller) 115, updates the data thereof, and executes processing for storing the update information in the transmission side journal 117. .

一方、プライマリセンタ１５とネットワーク５０を介して接続され、待機系システムとして稼働するのがセカンダリセンタ２０である。このセカンダリセンタ２０は、プライマリセンタ１５における送信側サーバ１００で生じた更新情報を非同期（例：バッチ処理等）で取得して、データベース２２６をプライマリセンタ１５のデータベース１１６と同内容とすべくデータ更新を行うこととなる。セカンダリセンタ２０においてこうした処理を実行するのは受信側サーバ群２００であり、第１の受信側サーバ２１０および第２の受信側サーバ２５０で構成される。この受信側サーバ群２００は、ＤＫＣ（ディスクコントローラ）２２５の配下にある受信側ジャーナル２２７から更新情報（送信側ジャーナル１１７から送られたもの）を取得して適宜な処理を施した上で、ＤＢキュー２２８に登録し、更には、このＤＢキュー２２８に登録した情報に基づいて上述のデータベース２２６のデータ更新を行うものとなる。 On the other hand, the secondary center 20 is connected to the primary center 15 via the network 50 and operates as a standby system. The secondary center 20 acquires update information generated in the transmission side server 100 in the primary center 15 asynchronously (for example, batch processing or the like), and updates the data so that the database 226 has the same contents as the database 116 of the primary center 15. Will be performed. The secondary center 20 executes such processing by the receiving server group 200, which includes a first receiving server 210 and a second receiving server 250. The receiving-side server group 200 acquires update information (from the sending-side journal 117) from the receiving-side journal 227 under the control of the DKC (disk controller) 225, performs appropriate processing, and then executes the DB. The data is registered in the queue 228, and further, the data in the database 226 is updated based on the information registered in the DB queue 228.

図２は本実施形態のデータベース管理システム１０におけるプライマリセンタ１５の構成例を示すブロック図である。データベース管理システム１０を構成する各装置のうち、プライマリセンタ１５を構成する送信側サーバ１００のハードウェア構成は以下の如くとなる。送信側サーバ１００は、主記憶装置１０１、ハードディスクドライブなどで構成される補助記憶装置を含むＤＫＣ１１５、主記憶装置１０１に保持されるプログラム１０２のうちＯＳ１０８に基づいてアプリケーション１１０を読み出すなどして実行し装置自体の統括制御を行なうとともに各種判定、演算及び制御処理を行なうＣＰＵ（演算装置）１０４、ユーザからのキー入力や音声入力を受け付ける入力装置１０５、処理データの表示を行うディスプレイ等の出力装置１０６、ネットワーク５０と接続しＤＫＣ１１５を介してセカンダリセンタ２０との通信処理を担う通信装置１０７、を備える。勿論、入力装置１０５、出力装置１０６は必要に応じて備えるとすれば良く、最少構成としては具備しない形態であってもよい。また、送信側サーバ１００がデータベース１１６の更新や送信側ジャーナル１１７への更新情報の格納を行う際には、ＤＫＣ１１５への指示を行って該当処理を行うものとする。 FIG. 2 is a block diagram showing a configuration example of the primary center 15 in the database management system 10 of the present embodiment. Of the devices constituting the database management system 10, the hardware configuration of the transmitting server 100 constituting the primary center 15 is as follows. The transmission-side server 100 executes the main storage device 101, the DKC 115 including an auxiliary storage device configured by a hard disk drive, and the application 110 based on the OS 108 among the programs 102 held in the main storage device 101. A CPU (arithmetic unit) 104 that performs overall control of the apparatus itself and performs various determinations, calculations, and control processes, an input unit 105 that receives key input and voice input from a user, and an output unit 106 such as a display that displays processing data And a communication device 107 connected to the network 50 and responsible for communication processing with the secondary center 20 via the DKC 115. Needless to say, the input device 105 and the output device 106 may be provided as necessary, and the minimum configuration may not be provided. Further, when the transmission side server 100 updates the database 116 or stores the update information in the transmission side journal 117, the DKC 115 is instructed to perform the corresponding process.

なお、主記憶装置１０１内（補助記憶装置たるＤＫＣ配下の記憶装置であっても勿論よい）には、本実施形態のデータベース管理システムとして必要な機能を実装する為のＯＳ１０８やアプリケーション１１０を含むプログラム１０２に他に、ＤＢ定義テーブル１２６、ユーザ定義テーブル１２７、ＡＰＰ定義テーブル１２８、及び製品情報テーブル１２９が少なくとも記憶されている。また、ＤＫＣ配下の送信側ジャーナル１１７には更新情報テーブル１２５が格納されている。これらのテーブル１２５〜１２９の詳細については後述する。また、上述のアプリケーション１１０は、ユーザ部１１１、ＡＰＰ１１２、製品１１３から構成されている。製品１１３は、ＯｐｅｎＴＰ１（登録商標）などの、オープンシステム上でオンライントランザクション処理を実行するミドルウェアであり、この製品１１３をベースに勘定系処理に必要な機能を付与するプログラムがＡＰＰ１１２（アプリケーションパッケージ）であり、更に、このＡＰＰ１１２を金融機関（すなわちユーザ）ごとの仕様、機能に応じてカスタマイズした部分がユーザ部１１１となる。 In the main storage device 101 (which may of course be a storage device under the DKC as an auxiliary storage device), a program including an OS 108 and an application 110 for implementing functions necessary for the database management system of this embodiment. In addition, at least a DB definition table 126, a user definition table 127, an APP definition table 128, and a product information table 129 are stored. An update information table 125 is stored in the transmission side journal 117 under the DKC. Details of these tables 125 to 129 will be described later. The application 110 described above includes a user unit 111, an APP 112, and a product 113. The product 113 is middleware such as OpenTP1 (registered trademark) that executes online transaction processing on an open system. A program that provides functions necessary for account processing based on the product 113 is APP112 (application package). In addition, a portion obtained by customizing the APP 112 according to the specifications and functions of each financial institution (that is, user) is the user unit 111.

他方、セカンダリセンタ２０の構成は以下のとおりである。図３は本実施形態のデータベース管理システム１０におけるセカンダリセンタ２０の構成例を示すブロック図である。セカンダリセンタ２０は、第１の受信側サーバ２００および第２の受信側サーバ２５０で構成されている。セカンダリセンタ２０における第１および第２の各受信側サーバ２１０、２５０とも、プライマリセンタ１５の待機系システムとして稼働するものである為、上述した送信側サーバ１００の構成と同様の構成を備えている。そこでここでは、送信側サーバ１００と異なる構成についてのみ説明する。 On the other hand, the configuration of the secondary center 20 is as follows. FIG. 3 is a block diagram showing a configuration example of the secondary center 20 in the database management system 10 of the present embodiment. The secondary center 20 includes a first receiving server 200 and a second receiving server 250. Since each of the first and second receiving servers 210 and 250 in the secondary center 20 operates as a standby system of the primary center 15, it has the same configuration as the configuration of the transmitting server 100 described above. . Therefore, only the configuration different from that of the transmitting server 100 will be described here.

この場合、第１の受信側サーバ２１０は、プライマリセンタ１５における送信側サーバ１００とは異なるＡＰＰ定義テーブル２３５およびＤＢキュー情報テーブル２３６を主記憶装置２１１にて備えている（いずれも詳細は後述）。また、第２の受信側サーバ２５０は、送信側サーバ１００とは異なるユーザ定義テーブル２６５を主記憶装置２５１にて備えている。また、これら第１および第２の受信側サーバ２１０、２５０は、それぞれ補助記憶装置のＤＫＣ２２５に命じて、受信側ジャーナル２２７、ＤＢキュー２２８、およびデータベース２２６にアクセスすることが可能である。 In this case, the first receiving server 210 includes an APP definition table 235 and a DB queue information table 236 different from the transmitting server 100 in the primary center 15 in the main storage device 211 (both will be described later in detail). . In addition, the second receiving server 250 includes a user definition table 265 different from the transmitting server 100 in the main storage device 251. The first and second receiving servers 210 and 250 can access the receiving journal 227, the DB queue 228, and the database 226 by instructing the DKC 225 of the auxiliary storage device, respectively.

続いて、本実施形態のデータベース管理システム１０における上述の各サーバらが備える機能について説明する。上述したように、以下に説明する機能は、例えばデータベース管理システム１０を構成する各サーバ１００、２１０、２５０らがそれぞれ備えるプログラムを各々実行することで実装される機能と言える。 Next, functions provided by the above-described servers in the database management system 10 of this embodiment will be described. As described above, the functions described below can be said to be functions that are implemented, for example, by executing each of the programs included in each of the servers 100, 210, and 250 that configure the database management system 10.

プライマリセンタ１５の送信側サーバ１００は、所定トランザクションを実行中のアプリケーション１１０からデータベース１１６の更新要求を受けた際、当該更新要求に応じてＤＫＣ１１５配下のデータベース１１６の更新処理を実行すると共に、更新要求が示す更新情報のヘッダにトランザクション中の通番を設定し、トランザクションに関する更新要求を受ける毎に通番をインクリメントして、以降の更新情報のヘッダに設定し、各更新情報を更新情報テーブル１２５（送信側ジャーナル１１７が保持）に格納する機能を備えている。 When the transmitting server 100 of the primary center 15 receives an update request for the database 116 from the application 110 that is executing a predetermined transaction, the transmitting server 100 executes an update process for the database 116 under the DKC 115 in response to the update request, and Is set in the header of the update information indicated by, and the serial number is incremented every time an update request related to the transaction is received, and set in the header of the subsequent update information. A function of storing in the journal 117).

なお、上述の送信側サーバ１００は、上述の通番のインクリメントに際し、更新情報のヘッダに設定した最新の通番を、該当トランザクションに関して主記憶装置１０１のＡＰＰ定義テーブル１２８にて格納する処理を更に実行し、インクリメントに際して、このＡＰＰ定義テーブル１２８に格納した最新の通番からインクリメントを行うものとする。 Note that, when the above-described serial number is incremented, the transmitting server 100 described above further executes a process of storing the latest serial number set in the header of the update information in the APP definition table 128 of the main storage device 101 with respect to the transaction. When incrementing, the latest serial number stored in the APP definition table 128 is incremented.

また、上述の送信側サーバ１００は、送信側ジャーナル１１７における更新情報テーブル１２５に保持する更新情報を、所定タイミングでセカンダリセンタ２０に送信する機能を備えている。 The transmission server 100 described above has a function of transmitting update information held in the update information table 125 in the transmission side journal 117 to the secondary center 20 at a predetermined timing.

一方、セカンダリセンタ２０の第１の受信側サーバ２１０は、プライマリセンタ１５の送信側サーバ１００から上述の更新情報を受信して受信側ジャーナル２２７に格納すると共に、当該更新情報をＤＢキュー２２８に登録する機能を備えている。 On the other hand, the first receiving server 210 of the secondary center 20 receives the update information from the transmitting server 100 of the primary center 15 and stores it in the receiving journal 227 and registers the update information in the DB queue 228. It has a function to do.

また、セカンダリセンタ２０の第２の受信側サーバ２５０は、上述のＤＢキュー２２８に登録された更新情報のうち、同じトランザクションに関するものをトランザクションＩＤ等に基づいて抽出し、当該抽出した更新情報を、ヘッダが示す通番に基づいてソートして、トランザクション中の処理順序に整合させた更新情報群を生成する機能を備えている。また、上述の第２の受信側サーバ２５０は、生成した更新情報群に基づいて、当該セカンダリセンタ２０におけるデータベース２２６を更新する機能を備えている。 The second receiving server 250 of the secondary center 20 extracts the update information registered in the DB queue 228 described above on the same transaction based on the transaction ID or the like, and extracts the extracted update information. It has a function of generating an update information group that is sorted based on the serial number indicated by the header and matched with the processing order in the transaction. The second receiving server 250 described above has a function of updating the database 226 in the secondary center 20 based on the generated update information group.

なお、送信側サーバ１００が、上述した更新要求に応じた処理において、アプリケーション１１０からの更新要求が示す更新情報のユーザ定義領域に、ユーザ定義の通番を設定し、トランザクションに関する更新要求を受ける毎にユーザ定義の通番をインクリメントして、以降の更新情報のユーザ定義領域に設定する機能を更に備える場合、セカンダリセンタ２０の第２の受信側サーバ２５０は、以下の機能を備えている。 Each time the sending server 100 sets a user-defined serial number in the user-defined area of the update information indicated by the update request from the application 110 in the processing in response to the update request described above, and receives an update request related to a transaction. In the case of further providing a function for incrementing the user-defined serial number and setting it in the user-defined area for subsequent update information, the second receiving server 250 of the secondary center 20 has the following functions.

すなわち第２の受信側サーバ２５０は、送信側サーバ１００から第１の受信側サーバ２１０が受信してＤＢキュー２２８に格納した更新情報より、ユーザ定義の通番を参照し、これを主記憶装置２５１のユーザ定義テーブル２６５に格納する機能を備えている。 That is, the second receiving server 250 refers to the user-defined serial number from the update information received by the first receiving server 210 from the transmitting server 100 and stored in the DB queue 228, and uses this as the main storage device 251. In the user definition table 265.

また、第２の受信側サーバ２５０は、ＤＢキュー２２８に登録された更新情報のうち、同じトランザクションに関するものをトランザクションＩＤ等をキーに抽出し、当該抽出した更新情報における最新のユーザ定義の通番が、ユーザ定義テーブル２６５に格納してあるユーザ定義の通番より１つ大きいとの条件を満たすか判定する機能を更に備えている。この処理を実行した第２の受信側サーバ２５０は、上述の条件が満たされなかった場合、所定時間待機して、第１の受信側サーバ２１０による上述の処理（更新情報をＤＢキュー２２８に登録する処理）の実行を待ち、上述した処理（更新情報を、ヘッダが示す通番に基づいてソートして、トランザクション中の処理順序に整合させた更新情報群を生成する処理）を再実行する。 Also, the second receiving server 250 extracts the update information registered in the DB queue 228 with respect to the same transaction using the transaction ID or the like as a key, and the latest user-defined serial number in the extracted update information is And a function for determining whether or not the condition of one greater than the user-defined serial number stored in the user-defined table 265 is satisfied. If the above condition is not satisfied, the second receiving server 250 that has executed this process waits for a predetermined time, and registers the update information in the DB queue 228 by the first receiving server 210. The processing described above (processing for generating update information group in which update information is sorted based on the serial number indicated by the header and matched with the processing order in the transaction) is re-executed.

また、第２の受信側サーバ２５０は、上述の更新情報群に基づいてデータベース２２６を更新する際に、プライマリセンタ１５におけるデータベース１１６の構成変更処理に対応した、当該セカンダリセンタ２０におけるデータベース２２６の構成変更処理の完了通知を、入力装置２５５ないし通信可能に結ばれた外部端末から受け付け済みである場合に、構成変更処理後のデータベース２２６の構成に対応する形式に、更新情報群の各更新情報を修正して、当該修正した更新情報群に基づいてデータベース２２６を更新する機能を更に備えている。 Further, when the second receiving server 250 updates the database 226 based on the above-described update information group, the configuration of the database 226 in the secondary center 20 corresponding to the configuration change processing of the database 116 in the primary center 15. When the notification of completion of the change process has been received from the input device 255 or an external terminal connected to be communicable, each update information of the update information group is converted into a format corresponding to the configuration of the database 226 after the configuration change process. A function of correcting and updating the database 226 based on the corrected update information group is further provided.

−−−データ構造例−−−
次に、本実施形態のデータベース管理システム１０が用いるテーブルにおけるデータ構造例について説明する。図４は本実施形態における更新情報テーブル１２５のデータ構造例を示す図である。更新情報テーブル１２５は、送信側ジャーナル１１７に格納されているテーブルであり、プライマリセンタ１５におけるデータベース１１６の更新情報を格納したテーブルである。更新情報テーブル１２５におけるレコードすなわち１つの更新情報は、データベース１１６に対する更新が発生する毎に格納される、すなわちアプリケーション１１０によるトランザクションの１つ１つに対応している。 --- Data structure example ---
Next, an example of the data structure in the table used by the database management system 10 of this embodiment will be described. FIG. 4 is a diagram showing an example of the data structure of the update information table 125 in the present embodiment. The update information table 125 is a table stored in the transmission side journal 117 and is a table storing update information of the database 116 in the primary center 15. A record in the update information table 125, that is, one update information, is stored every time an update to the database 116 occurs, that is, corresponds to each transaction by the application 110.

こうしたレコードは、ＡＰＰヘッダ、更新レコード情報、およびユーザ情報から構成されている。更新情報のヘッダたるＡＰＰヘッダには、ＡＰＰ通番（トランザクション中の通番）、トランザクション最終フラグ（一連のトランザクション中の最終のものに付与されるフラグ）、およびトランザクションＩＤ（不図示）の各データが少なくとも含まれている。また、更新レコード情報は、データベース１１６の更新情報の実体部分であり、更新対象となるＤＢ名称およびレコード名称の各データが少なくとも含まれている。また、ユーザ情報は、例えばプライマリセンタ１５におけるユーザ部１１１で更新情報に関して定義した、ユーザ定義領域（ユーザが任意に値を設定できる予備的な領域）に、更新情報毎に付与される通番、すなわちファイル通番の値を少なくとも含んでいる。 Such a record includes an APP header, update record information, and user information. The APP header, which is the header of the update information, includes at least each data of an APP sequence number (sequence number in a transaction), a transaction end flag (a flag given to the last in a series of transactions), and a transaction ID (not shown). include. The update record information is an actual part of the update information in the database 116, and includes at least the DB name and record name data to be updated. The user information is, for example, a serial number assigned to each update information in a user-defined area (a preliminary area in which the user can arbitrarily set a value) defined for the update information in the user unit 111 in the primary center 15, Contains at least the file serial number value.

図４で示す例においては、プライマリセンタ１５の送信側サーバ１００による処理が進む毎に、この更新情報テーブル１２５の所定レコードの、ＡＰＰ通番、トランザクション最終フラグ、およびファイル通番が書き換えられていく様子を表している。アプリケーション１１０から更新要求を受けただけの時点では、更新情報テーブル１２５に格納された更新情報は、図４における「第１段階」にて示すように、ＡＰＰ通番、トランザクション最終フラグ、およびファイル通番はいずれも「ＮＵＬＬ」となっている。また、ユーザ定義テーブル１２７のファイル通番（例：“７”）からインクリメントさせた値“８”を得た処理の後においては、「第２段階」にて示すように、ファイル通番は「８」となっている。また、ＡＰＰ定義１２８のＡＰＰ通番（例：“１”）からインクリメントさせた値“２”を得た処理の後においては、「第３段階」にて示すように、ＡＰＰ通番は「２」となっている。また、製品情報テーブル１２９の最終フラグから値“１”（一連のトランザクション中で最終のものを示す値）を得た処理の後においては、「第４段階」にて示すように、トランザクション最終フラグは「１」となっている。 In the example shown in FIG. 4, every time processing by the transmitting server 100 of the primary center 15 proceeds, the APP serial number, the transaction final flag, and the file serial number of the predetermined record of the update information table 125 are rewritten. Represents. At the time of receiving an update request from the application 110, the update information stored in the update information table 125 includes the APP sequence number, the transaction final flag, and the file sequence number as shown in “first stage” in FIG. Both are “NULL”. After the process of obtaining the incremented value “8” from the file sequence number (eg, “7”) in the user definition table 127, the file sequence number is “8” as shown in “second stage”. It has become. After the process of obtaining the incremented value “2” from the APP sequence number (eg, “1”) in the APP definition 128, the APP sequence number is “2” as shown in “third stage”. It has become. After the process of obtaining the value “1” (the value indicating the last in a series of transactions) from the final flag of the product information table 129, as shown in “fourth stage”, the transaction final flag Is “1”.

また、図５は本実施形態におけるＤＢ定義テーブル１２６のデータ構造例を示す図である。このＤＢ定義テーブル１２６は、プライマリセンタ１５におけるデータベース１１６を構成するデータベースの情報を定義したテーブルである。ＤＢ定義テーブル１２６は、ＤＢ名称、その構成情報（ＤＢが格納するデータの実体）、ユーザ保有領域の各データを少なくとも含んだレコードの集合体となっている。このうちユーザ保有領域は、該当データベースにおいて上述したユーザ定義領域が設定されているか否かを示すフラグを格納する領域であり、ユーザ定義領域が設定されている場合、“１”のフラグが格納されている。このＤＢ定義テーブル１２６は、適宜な管理者等が予め生成して格納したものである。 FIG. 5 is a diagram showing an example of the data structure of the DB definition table 126 in this embodiment. The DB definition table 126 is a table that defines database information that constitutes the database 116 in the primary center 15. The DB definition table 126 is a collection of records including at least each data of the DB name, its configuration information (substance of data stored in the DB), and the user holding area. Among these, the user holding area is an area for storing a flag indicating whether or not the above-described user-defined area is set in the corresponding database. When the user-defined area is set, a flag “1” is stored. ing. This DB definition table 126 is generated and stored in advance by an appropriate administrator or the like.

また、図６は本実施形態におけるユーザ定義テーブル１２７のデータ構造例を示す図である。ユーザ定義テーブル１２７は、上述した更新情報におけるユーザ定義領域に設定されたファイル通番がデータベース毎に格納されたテーブルである。 FIG. 6 is a diagram showing an example of the data structure of the user definition table 127 in this embodiment. The user definition table 127 is a table in which file serial numbers set in the user definition area in the update information described above are stored for each database.

また、図７は本実施形態におけるＡＰＰ定義テーブル１２８のデータ構造例を示す図である。ＡＰＰ定義テーブル１２８は、データベース１１６に含まれている各ＤＢについて、その構成情報、リモートＤＢのフラグ（セカンダリセンタ２０への更新反映対象か否かを示す値）、およびＡＰＰ通番の各データを少なくとも含んだレコードの集合体となっている。 FIG. 7 is a diagram showing an example of the data structure of the APP definition table 128 in this embodiment. For each DB included in the database 116, the APP definition table 128 includes at least the configuration information, the flag of the remote DB (a value indicating whether or not the update is to be reflected in the secondary center 20), and each data of the APP serial number. It is a collection of included records.

また、図８は本実施形態における製品情報テーブル１２９のデータ構造例を示す図である。製品情報テーブル１２９は、アプリケーション１１０の処理で生じたトランザクションに関する情報を格納したテーブルであり、トランザクション番号（トランザクションＩＤ）、トランザクション種別（例：入金、出金、振込、など）、最終フラグ（トランザクション最終フラグ）の各データを少なくとも含んだレコードの集合体となっている。 FIG. 8 is a diagram showing an example of the data structure of the product information table 129 in this embodiment. The product information table 129 is a table that stores information related to transactions generated by the processing of the application 110, and includes a transaction number (transaction ID), a transaction type (eg, deposit, withdrawal, transfer, etc.), a final flag (transaction last). Flag) is a set of records including at least each data.

また、図９は本実施形態におけるＡＰＰ定義テーブル２３５（セカンダリセンタ側）のデータ構造例を示す図である。セカンダリセンタ２０における第１の受信側サーバ２１０が備えるＡＰＰ定義テーブル２３５は、データベース１１６に含まれている各ＤＢ（セカンダリセンタ２０で更新反映するもの）について、そのＤＢ名称、レコード情報（構成情報）、およびサービス名（トランザクション種別と同様）の各データを少なくとも含んだレコードの集合体となっている。 FIG. 9 is a diagram showing an example of the data structure of the APP definition table 235 (secondary center side) in the present embodiment. The APP definition table 235 provided in the first receiving server 210 in the secondary center 20 is the DB name and record information (configuration information) of each DB (what is updated and reflected in the secondary center 20) included in the database 116. , And a service name (similar to the transaction type).

また、図１０は本実施形態におけるＤＢキュー情報テーブル２３６のデータ構造例を示す図である。ＤＢキュー情報テーブル２３６は、ＤＢキュー２２８に格納された、プライマリセンタ１５由来の更新情報に関する情報を格納したテーブルである。このＤＢキュー情報テーブル２３６は、更新情報が含んでいるＡＰＰヘッダ、更新レコード情報、およびユーザ情報に加えて、ＤＢキューヘッダを備えたレコードの集合体となっている。このＤＢキューヘッダは、本実施形態のデータベース管理方法の処理対象、すなわち、プライマリセンタ１５におけるデータベース１１６からセカンダリセンタ２０におけるデータベース２２６更新反映処理の対象となっているトランザクションかを示すフラグを格納する領域となる。更新反映処理の対象となっている場合、フラグ「１」が格納されている。 FIG. 10 is a diagram showing an example of the data structure of the DB queue information table 236 in this embodiment. The DB queue information table 236 is a table that stores information related to update information derived from the primary center 15 and stored in the DB queue 228. The DB queue information table 236 is an aggregate of records having a DB queue header in addition to the APP header, update record information, and user information included in the update information. This DB queue header is an area for storing a flag indicating a processing target of the database management method of the present embodiment, that is, a transaction that is a target of database 226 update reflection processing in the secondary center 20 from the database 116 in the primary center 15. It becomes. When it is a target of update reflection processing, a flag “1” is stored.

また、図１１は本実施形態におけるユーザ定義テーブル２６５（セカンダリセンタ側）のデータ構造例を示す図である。このユーザ定義テーブル２６５は、プライマリセンタ１５由来の更新情報におけるユーザ定義領域に設定されたファイル通番と、構成変更後フラグ（セカンダリセンタ２０におけるデータベース２２６での構成変更処理の完了未済を示すフラグ）が、データベース毎に格納されたテーブルである。 FIG. 11 is a diagram showing an example of the data structure of the user definition table 265 (secondary center side) in the present embodiment. This user definition table 265 includes a file serial number set in the user definition area in the update information derived from the primary center 15 and a post-configuration change flag (a flag indicating that configuration change processing in the database 226 in the secondary center 20 has not been completed). A table stored for each database.

−−−処理手順例１−−−
以下、本実施形態におけるデータベース管理方法の実際手順について図に基づき説明する。以下で説明するデータベース管理方法に対応する各種動作は、データベース管理システム１０を構成するプライマリセンタ１５の送信側サーバ１００、セカンダリセンタ２０を構成する第１の受信側サーバ２１０、および第２の受信側サーバ２５０が実行するプログラムによって実現される。そして、このプログラムは、以下に説明される各種の動作を行うためのコードから構成されている。 --- Example of processing procedure 1 ---
Hereinafter, an actual procedure of the database management method in the present embodiment will be described with reference to the drawings. Various operations corresponding to the database management method described below are performed by the transmission side server 100 of the primary center 15 constituting the database management system 10, the first reception side server 210 constituting the secondary center 20, and the second reception side. This is realized by a program executed by the server 250. And this program is comprised from the code | cord | chord for performing the various operation | movement demonstrated below.

図１２は、本実施形態におけるデータベース管理方法の処理手順例１を示すフロー図である。ここではまず、プライマリセンタ１５の送信側サーバ１００における処理について説明する。この場合、送信側サーバ１００のアプリケーション１１０におけるユーザ部１１１は、所定サービスの実行に応じてデータベース１１６の更新をＡＰＰ１１２に対して要求する（ｓ１００）。 FIG. 12 is a flowchart showing a processing procedure example 1 of the database management method in the present embodiment. Here, first, processing in the transmission side server 100 of the primary center 15 will be described. In this case, the user unit 111 in the application 110 of the transmission-side server 100 requests the APP 112 to update the database 116 in accordance with execution of a predetermined service (s100).

ＡＰＰ１１２は、この要求を受けて、上述の要求が含む更新情報を一旦、主記憶装置１０１にて１レコードとして格納する（後に、送信側ジャーナル１１７の更新情報テーブル１２５に格納する）と共に、ＤＢ定義テーブル１２６において該当要求が示すＤＢに関するレコードを参照し、該当レコードにおけるユーザ保有領域フラグの有無を判定する（ｓ１０１）。つまり、上述の要求の対象となったＤＢの各レコードにユーザ定義領域が設定されているか判定することになる。なお、このステップｓ１０１の処理により更新情報テーブル１２５に格納されたレコードの状態は、図４にて「第１段階」として示した通りである。 In response to this request, the APP 112 temporarily stores the update information included in the above-described request as one record in the main storage device 101 (later stored in the update information table 125 of the transmission side journal 117) and the DB definition. The record relating to the DB indicated by the corresponding request in the table 126 is referred to, and the presence / absence of the user possession area flag in the corresponding record is determined (s101). That is, it is determined whether a user-defined area is set in each record of the DB that is the target of the above request. Note that the state of the record stored in the update information table 125 by the process of step s101 is as shown as “first stage” in FIG.

上述のステップｓ１０１での判定により、該当レコードにてユーザ保有領域フラグ“１”が設定されていた場合、すなわち該当ＤＢのレコードにユーザ定義領域が設定されていたことが判明した場合（ｓ１０１：ＹＥＳ）、ＡＰＰ１１２はこの旨をユーザ部１１１に返す。他方、該当レコードにてユーザ保有領域フラグ“１”が設定されていなかった場合、すなわち該当ＤＢのレコードにユーザ定義領域が設定されていないことが判明した場合（ｓ１０１：ＮＯ）、ＡＰＰ１１２は処理をステップｓ１０３に進める。 As a result of the determination in step s101 described above, it is found that the user-owned area flag “1” is set in the corresponding record, that is, the user-defined area is set in the record of the corresponding DB (s101: YES) ) APP 112 returns this to the user unit 111. On the other hand, if the user-owned area flag “1” is not set in the corresponding record, that is, if it is found that the user-defined area is not set in the corresponding DB record (s101: NO), the APP 112 performs the process. Proceed to step s103.

一方、ユーザ部１１１は、ステップｓ１０１の結果として、該当ＤＢのレコードにユーザ定義領域が設定されていた旨をＡＰＰ１１２から受けたならば、ユーザ定義テーブル１２７におけるファイル通番の値を参照し、この値をインクリメントして更新した上で、主記憶装置１０１に一旦格納してある該当レコード（ステップｓ１０１で格納したもの）のファイル通番を同値で更新する（ｓ１０２）。このステップｓ１０２の処理後における該当レコードの状態は、図４にて「第２段階」として示した通りである。 On the other hand, when the user unit 111 receives from the APP 112 that the user-defined area is set in the record of the corresponding DB as a result of step s101, the user unit 111 refers to the value of the file sequence number in the user-defined table 127, And the file sequence number of the corresponding record (stored in step s101) once stored in the main storage device 101 is updated with the same value (s102). The state of the corresponding record after the processing of step s102 is as shown as "second stage" in FIG.

ユーザ部１１１における上述のステップｓ１０２の処理完了を受けたＡＰＰ１１２は、ユーザ部１１０からの更新要求が示す更新情報に応じて、データベース１１６における該当ＤＢの更新処理を製品１１３に対して要求する（ｓ１０３）。製品１１３は、この要求を受けて、該当更新情報に基づいてＤＫＣ１１５に更新要求を指示することで、データベース１１６における該当ＤＢの更新を行う（ｓ１０４）。こうした更新処理は、アプリケーション１１０で処理データが生じ、データベース１１６における対応データを更新する必要が生じるごとに発生する。 Upon receiving the completion of the above-described step s102 in the user unit 111, the APP 112 requests the product 113 to update the corresponding DB in the database 116 in accordance with the update information indicated by the update request from the user unit 110 (s103). ). Upon receiving this request, the product 113 instructs the DKC 115 to make an update request based on the corresponding update information, thereby updating the corresponding DB in the database 116 (s104). Such update processing occurs every time processing data is generated in the application 110 and corresponding data in the database 116 needs to be updated.

一方、製品１１３による更新処理を受けたＡＰＰ１１２は、ＡＰＰ定義テーブル１２８における該当ＤＢのレコードを参照し、リモートＤＢフラグとして“１”が設定されているか判定する（ｓ１０５）。この判定の結果、該当ＤＢに関してリモートＤＢフラグとして“１”が設定されていなかった場合（ｓ１０５：ＮＯ）、ＡＰＰ１１２はその旨をユーザ部１１１に返し、ユーザ部１１１は当該トランザクションを終了する。すなわち、上述のステップｓ１０４でデータベースの更新処理を行ったトランザクションは、セカンダリセンタ２０におけるデータベース２２６の反映更新を必要としないものであったと認識して処理を終了するのである。 On the other hand, the APP 112 that has received the update process by the product 113 refers to the record of the corresponding DB in the APP definition table 128 and determines whether “1” is set as the remote DB flag (s105). As a result of this determination, if “1” is not set as the remote DB flag for the corresponding DB (s105: NO), the APP 112 returns to that effect to the user unit 111, and the user unit 111 ends the transaction. That is, the transaction that has been subjected to the database update process in step s104 described above recognizes that the reflection update of the database 226 in the secondary center 20 is not necessary and ends the process.

他方、上述のステップｓ１０５の判定の結果、該当ＤＢに関してリモートＤＢフラグとして“１”が設定されていた場合（ｓ１０５：ＹＥＳ）、ＡＰＰ１１２は、ＡＰＰ定義テーブル１２８における該当ＤＢのレコードを参照して、ＡＰＰ通番の値を抽出してインクリメントして更新した上で、この値を、主記憶装置１０１に格納してある該当レコードのＡＰＰ通番に設定する（ｓ１０６）。このステップｓ１０６の処理後における該当レコードの状態は、図４にて「第３段階」として示した通りである。 On the other hand, if “1” is set as the remote DB flag for the corresponding DB as a result of the determination in the above step s105 (s105: YES), the APP 112 refers to the record of the corresponding DB in the APP definition table 128, After the APP sequence number value is extracted and incremented and updated, this value is set to the APP sequence number of the corresponding record stored in the main storage device 101 (s106). The state of the corresponding record after the processing of step s106 is as shown as “third stage” in FIG.

また、ＡＰＰ１１２は、製品情報テーブル１２９におけるレコードがトランザクション最終フラグ“１”を保有しているか判定する（ｓ１０７）。該当レコードが、トランザクション最終フラグ“１”を保有していなかった場合（ｓ１０７：ＮＯ）、ＡＰＰ１１２は、その旨を製品１１３に通知して処理をステップｓ１０９に進める。他方、該当レコードが、トランザクション最終フラグ“１”を保有していた場合（ｓ１０７：ＹＥＳ）、ＡＰＰ１１２は、このトランザクション最終フラグ“１”を主記憶装置１０１に格納してある該当レコードのＡＰＰヘッダのうちトランザクション最終フラグ欄に格納する（ｓ１０８）。 Further, the APP 112 determines whether the record in the product information table 129 has the transaction final flag “1” (s107). If the record does not have the transaction final flag “1” (s107: NO), the APP 112 notifies the product 113 of the fact and advances the process to step s109. On the other hand, when the corresponding record has the transaction final flag “1” (s107: YES), the APP 112 stores the transaction final flag “1” in the APP header of the corresponding record stored in the main storage device 101. Of these, it is stored in the transaction final flag column (s108).

上述のステップｓ１０７で、該当レコードが、トランザクション最終フラグ“１”を保有していなかった場合（ｓ１０７：ＮＯ）、および、上述のステップｓ１０８の処理を受けた製品１１３は、主記憶装置１０１に一旦格納していた上述のレコードを、送信側ジャーナル１１７における更新情報テーブル１２５のレコードとして登録する（ｓ１０９）。 When the corresponding record does not have the transaction final flag “1” in step s107 described above (s107: NO), and the product 113 that has received the process in step s108 described above is temporarily stored in the main storage device 101. The above-mentioned stored record is registered as a record of the update information table 125 in the transmission side journal 117 (s109).

なお、上述の各ステップを例えば１時間、或いは１日などの所定期間繰り返し実行し、所定時刻が到来した時点で、製品１１３は、送信側ジャーナル１１７に蓄積された更新情報テーブル１２５のデータを、セカンダリセンタ２０における第１の受信側サーバ２１０に送信するものとする。この時、送信側ジャーナル１１７のデータを受信した第１の受信側サーバ２１０は、ＤＫＣ２２５に命じて、その配下にある受信側ジャーナル２２７に該当データの格納を行う。こうして、非同期にて、送信側ジャーナル１１７のデータによって受信側ジャーナル２２７の格納データが更新される。 The above steps are repeatedly executed for a predetermined period of time such as 1 hour or 1 day, and when the predetermined time has arrived, the product 113 stores the data in the update information table 125 accumulated in the transmission side journal 117. It is assumed that the data is transmitted to the first receiving server 210 in the secondary center 20. At this time, the first receiving server 210 that has received the data in the transmitting journal 117 instructs the DKC 225 to store the corresponding data in the receiving journal 227 under its control. In this way, the data stored in the receiving journal 227 is updated asynchronously with the data in the transmitting journal 117.

−−−処理手順例２−−−
次に、セカンダリセンタ２０の第１の受信側サーバ２１０における、ＤＢキュー２２８へのデータ登録処理について図に基づき説明する。図１３は、本実施形態におけるデータベース管理方法の処理手順例２を示すフロー図である。 --- Processing procedure example 2 ---
Next, data registration processing in the DB queue 228 in the first receiving server 210 of the secondary center 20 will be described with reference to the drawings. FIG. 13 is a flowchart showing a processing procedure example 2 of the database management method in the present embodiment.

この場合、セカンダリセンタ２０の第１の受信側サーバ２１０における製品２２３は、受信側ジャーナル２２７にデータが格納されているか判定し（ｓ２００）、データが格納されていなかった場合（ｓ２００：ＮＯ）、例えば１０秒間スリープして、再びステップｓ２００を実行する。一方、受信側ジャーナル２２７にデータが格納されていた場合（ｓ２００：ＹＥＳ）、製品２２３は、受信側ジャーナル２２７よりデータを取得し（ｓ２０１）、該当データをＡＰＰ２２２に引き渡す。 In this case, the product 223 in the first receiving server 210 of the secondary center 20 determines whether data is stored in the receiving journal 227 (s200). If no data is stored (s200: NO), For example, after sleeping for 10 seconds, step s200 is executed again. On the other hand, when the data is stored in the receiving side journal 227 (s200: YES), the product 223 acquires the data from the receiving side journal 227 (s201) and delivers the corresponding data to the APP 222.

ＡＰＰ２２２は、製品２２３から引き渡された受信側ジャーナル２２７のデータ、すなわち更新情報を受けて、当該更新情報が含むＤＢ名称及びレコード名称の値を、ＡＰＰ定義テーブル２３５に照合して該当サービスを決定し、ここで決定したサービスに対応して主記憶装置２１１にて設けた処理キューへ登録する（ｓ２０２）。 The APP 222 receives the data of the receiving-side journal 227 delivered from the product 223, that is, update information, and compares the DB name and record name values included in the update information with the APP definition table 235 to determine the corresponding service. Then, it registers in the processing queue provided in the main storage device 211 corresponding to the service determined here (s202).

一方、製品２２３は、ＡＰＰ２２２による上述のステップ２０２の処理を受けて、該当処理キューより更新情報のデータを引きだし（ｓ２０３）、ＡＰＰ２２２に引き渡す。ＡＰＰ２２２は、これを受けて、ＤＢキュー情報テーブル２３６に生成したレコード（該当更新情報を含むレコード）に反映トランザクションフラグ“１”を設定し、ＤＢキュー２２８に登録する（ｓ２０４）。 On the other hand, the product 223 receives the processing of the above-described step 202 by the APP 222, extracts the update information data from the corresponding processing queue (s203), and transfers it to the APP 222. In response to this, the APP 222 sets the reflection transaction flag “1” in the record generated in the DB queue information table 236 (record including the relevant update information) and registers it in the DB queue 228 (s204).

−−−処理手順例３−−−
次に、セカンダリセンタ２０の第２の受信側サーバ２５０が実行する処理について図に基づき説明する。図１４は、本実施形態におけるデータベース管理方法の処理手順例３を示すフロー図である。この場合、第２の受信側サーバ２５０における製品２６３は、上述のステップｓ２０４にて登録されているデータを、ＤＢキュー２２８より取り出し（ｓ３００）、該当データをＡＰＰ２６２に引き渡す。 --- Processing procedure example 3 ---
Next, processing executed by the second receiving server 250 of the secondary center 20 will be described with reference to the drawings. FIG. 14 is a flowchart showing a processing procedure example 3 of the database management method in the present embodiment. In this case, the product 263 in the second receiving server 250 retrieves the data registered in the above step s204 from the DB queue 228 (s300), and delivers the corresponding data to the APP 262.

一方、ＡＰＰ２６２は、製品２６３から引き渡されたデータ、すなわちＤＢキュー２２８に登録されていた更新情報に関して、ＤＢキュー情報テーブル２３６の該当レコードに反映トランザクションフラグ“１”が設定されているか判定する（ｓ３０１）。該当レコードに反映トランザクションフラグ“１”が設定されていなかった場合（ｓ３０１：ＮＯ）、ＡＰＰ２６２は、ＤＢキュー２２８より取り出した更新情報はセカンダリセンタ２０におけるデータベース２２６に反映させる必要のないものであると認識して、通常トランザクションとして起動し、以降のフローを終了する。他方、上述のステップｓ３０１の結果、該当レコードに反映トランザクションフラグ“１”が設定されていた場合（ｓ３０１：ＹＥＳ）、ＡＰＰ２６２は、ＤＢキュー２２８から更新情報によるデータベース２２６の更新、すなわち、反映トランザクションを起動する（ｓ３０２）。 On the other hand, the APP 262 determines whether the reflected transaction flag “1” is set in the corresponding record of the DB queue information table 236 for the data delivered from the product 263, that is, the update information registered in the DB queue 228 (s301). ). When the reflection transaction flag “1” is not set in the corresponding record (s301: NO), the APP 262 does not need to reflect the update information extracted from the DB queue 228 in the database 226 in the secondary center 20. Recognize and start as a normal transaction, and end the subsequent flow. On the other hand, if the reflection transaction flag “1” is set in the corresponding record as a result of the above-described step s301 (s301: YES), the APP 262 updates the database 226 with the update information from the DB queue 228, that is, reflects the reflection transaction. Start (s302).

ステップｓ３０２に続いてＡＰＰ２６２は、該当更新情報におけるＡＰＰヘッダにトランザクション最終フラグ“１”が含まれているか判定する（ｓ３０３）。該当更新情報におけるＡＰＰヘッダにトランザクション最終フラグ“１”が含まれていなかった場合（ｓ３０３：ＮＯ）、ＡＰＰ２６２は、主記憶装置２１１に設けた所定のバッファへ、該当更新情報のデータを退避させ、次トランザクションを待つ（ｓ３０４）。これを受けた製品２６３はトランザクションを終了する（ｓ３０５）。 Subsequent to step s302, the APP 262 determines whether the transaction final flag “1” is included in the APP header in the update information (s303). When the transaction final flag “1” is not included in the APP header in the relevant update information (s303: NO), the APP 262 saves the data of the relevant update information in a predetermined buffer provided in the main storage device 211, Wait for the next transaction (s304). Receiving this, the product 263 ends the transaction (s305).

他方、ステップｓ３０３の判定の結果、該当更新情報におけるＡＰＰヘッダにトランザクション最終フラグ“１”が含まれていた場合（ｓ３０３：ＹＥＳ）、ＡＰＰ２６２は、バッファ（これより前のいずれかのタイミングで主記憶装置２１１に設けられているもの）へ退避した更新情報のデータがあるか判定する（ｓ３０６）。この判定の結果、バッファへ退避した更新情報のデータが無かった場合（ｓ３０６：ＮＯ）、ＡＰＰ２６２はその旨をユーザ部２６１に通知し、処理をステップ３０８に進める。 On the other hand, if the transaction final flag “1” is included in the APP header in the update information as a result of the determination in step s303 (s303: YES), the APP 262 stores the buffer (main memory at any timing before this). It is determined whether there is update information data saved in the device 211 (s306). As a result of the determination, if there is no update information data saved in the buffer (s306: NO), the APP 262 notifies the user unit 261 to that effect, and the process proceeds to step 308.

他方、ステップｓ３０６の結果、バッファへ退避した更新情報のデータがあった場合（ｓ３０６：ＹＥＳ）、ＡＰＰ２６２は、同じトランザクションＩＤが付与されている更新情報（ｓ３００で取り出したもの由来）に関し、各更新情報が含むＡＰＰ通番の値に基づいて更新情報のソート処理を実行し、トランザクション中の処理順序に整合させた更新情報群を生成し（ｓ３０７）、ユーザ部２６１に引き渡す。 On the other hand, if there is update information data saved in the buffer as a result of step s306 (s306: YES), the APP 262 updates each update information with the same transaction ID (derived from that extracted in s300). Based on the value of the APP serial number included in the information, update information sorting processing is executed to generate a group of update information matched with the processing order in the transaction (s307) and handed over to the user unit 261.

ステップｓ３０７の処理結果を受けたユーザ部２６１は、ＡＰＰ２６２から引き渡された更新情報より、例えば値が最も大きいファイル通番の値を参照し、該当値が、ユーザ定義テーブル２６５の該当ＤＢに関するレコードのファイル通番の値の次の値、すなわち１つインクリメントされた値になっているか判定する（ｓ３０８）。 The user unit 261 that has received the processing result of step s307 refers to, for example, the value of the file sequence number having the largest value from the update information delivered from the APP 262, and the corresponding value is the file of the record related to the corresponding DB in the user definition table 265. It is determined whether the next value of the serial number value, that is, a value incremented by one (s308).

この判定の結果、ＡＰＰ２６２から引き渡された更新情報におけるファイル通番の値が、ユーザ定義テーブル２６５の該当ＤＢに関するレコードのファイル通番の値の次の値でなかった場合（ｓ３０８：ＮＯ）、ユーザ部２６１は、該当更新情報のデータをバッファへ退避させ、次トランザクションを待つ（ｓ３０９）。これを受けた製品２６３はトランザクション終了する（ｓ３１０）。 As a result of this determination, if the file sequence number value in the update information delivered from the APP 262 is not the next value of the file sequence number value of the record related to the corresponding DB in the user definition table 265 (s308: NO), the user part 261 Saves the data of the relevant update information to the buffer and waits for the next transaction (s309). The product 263 that has received this terminates the transaction (s310).

他方、ステップｓ３０８の判定の結果、ＡＰＰ２６２から引き渡された更新情報におけるファイル通番の値が、ユーザ定義テーブル２６５の該当ＤＢに関するレコードのファイル通番の値の次の値であった場合（ｓ３０８：ＹＥＳ）、ユーザ部２６１は、上述のバッファへ退避した更新情報のデータがあるか判定する（ｓ３１１）。 On the other hand, as a result of the determination in step s308, if the file sequence number value in the update information delivered from the APP 262 is the next value of the file sequence number value of the record related to the corresponding DB in the user definition table 265 (s308: YES). The user unit 261 determines whether there is update information data saved in the buffer (s311).

この判定の結果、バッファへ退避した更新情報のデータがあった場合（ｓ３１１：ＹＥＳ）、ユーザ部２６１は、バッファに退避してあった更新情報（ステップｓ３０７で生成した更新情報群）に関し、各更新情報が含むファイル通番の値に基づいて更新情報のソート処理をあらためて実行し、トランザクション中の処理順序に整合させる、すなわちファイル通番に基づく通番補正処理を実行する（ｓ３１２）。 As a result of the determination, if there is update information data saved in the buffer (s311: YES), the user unit 261 relates to the update information saved in the buffer (update information group generated in step s307). Based on the value of the file sequence number included in the update information, the update information is sorted again to match the processing order in the transaction, that is, the sequence number correction processing based on the file sequence number is executed (s312).

上述のステップｓ３１２に続いて、或いは、ステップｓ３１１の判定結果がバッファへ退避した更新情報のデータがなかった場合（ｓ３１１：ＮＯ）、ユーザ部２６１は、ユーザ定義テーブル２６５における該当ＤＢのレコードを参照し、構成変更後フラグに“１”が設定されているか、すなわち、データベース２２６における該当ＤＢに関して構成変更が完了しているか判定する（ｓ３１３）。 Subsequent to step s312 described above or when the determination result in step s311 indicates that there is no update information data saved in the buffer (s311: NO), the user unit 261 refers to the record of the corresponding DB in the user definition table 265. Then, it is determined whether “1” is set in the post-configuration change flag, that is, whether the configuration change has been completed for the corresponding DB in the database 226 (s313).

この判定の結果、データベース２２６における該当ＤＢに関して構成変更が完了していた場合（ｓ３１３：ＹＥＳ）、ユーザ部２６１は、ＤＢの構成変更によるデータ構造の変化、例えば所定データのデータ長変化（例えば、構成変更前は４バイトであったのが、６バイトに変化）に対応すべく、ここまでのステップで得ている更新情報群の該当データのデータ長を修正する（例：２バイトの領域を付加）といった対応処理を実行する（ｓ３１４）。 As a result of this determination, when the configuration change has been completed for the corresponding DB in the database 226 (s313: YES), the user unit 261 changes the data structure due to the DB configuration change, for example, the data length change of the predetermined data (for example, Modify the data length of the relevant data in the update information group obtained in the previous steps so that it corresponds to 4 bytes before the configuration change (changed to 6 bytes). Addition) is executed (s314).

上述のステップｓ３１４に続いて、或いは、ステップｓ３１３の判定結果が該当ＤＢに関して構成変更が完了していなかった場合（ｓ３１３：ＮＯ）、ユーザ部２６１は、上述の更新情報群の各更新情報のレコードにて、データベース更新には不要な項目（ＡＰＰヘッダやユーザ情報）を削除する処理、すなわちレコード編集処理を実行する（ｓ３１５）。 Subsequent to step s314 described above or when the determination result in step s313 indicates that the configuration change has not been completed for the corresponding DB (s313: NO), the user unit 261 records each update information in the update information group described above. Then, a process for deleting items (APP header and user information) unnecessary for database update, that is, a record editing process is executed (s315).

また、上述のステップｓ３１５の処理完了を受けて、ユーザ部２６１は、ＡＰＰ２６２に対してＤＢ更新要求を行う（ｓ３１６）。これを受けたＡＰＰ２６２は、ＤＢ更新要求を製品２６３に実行し（ｓ３１７）、これを受けた製品２６３は、要求が示す更新情報に基づいてデータベース２２６における該当ＤＢの更新を実行する（ｓ３１８）。 In response to the completion of the processing in step s315, the user unit 261 makes a DB update request to the APP 262 (s316). Receiving this, the APP 262 executes a DB update request to the product 263 (s317), and the product 263 receiving this updates the corresponding DB in the database 226 based on the update information indicated by the request (s318).

このように、セカンダリセンタ２０におけるデータベース２２６に関し、プライマリセンタ１５のデータベース１１６に対してなされる構成変更と同様の構成変更を施し、なおかつ、データベース１１６の更新に由来する更新情報によって更新した上で、プライマリセンタ１５での処理を引き継いでオンラインシステムとして稼働開始させた後、プライマリセンタ１５の停止と構成変更を実行し、その後の所定のタイミングにて、セカンダリセンタ２０のデータベース２２６を、プライマリセンタ１５のデータベース１１６にコピーしてプライマリセンタ１５のオンライン復帰を行う。こうした処理は、すなわち、現用系システムたるプライマリセンタ１５と、その待機系システムたるセカンダリセンタ２０の間において、高精度の整合性が確保された引継ぎ処理を実行し、無停止運転を達成することとなる。 As described above, the database 226 in the secondary center 20 is subjected to the same configuration change as the configuration change made to the database 116 in the primary center 15 and updated with update information derived from the update of the database 116. After taking over the processing at the primary center 15 and starting operation as an online system, the primary center 15 is stopped and the configuration is changed, and the database 226 of the secondary center 20 is stored in the primary center 15 at a predetermined timing thereafter. The data is copied to the database 116 and the primary center 15 is returned online. In other words, such a process executes a takeover process in which high-precision consistency is ensured between the primary center 15 that is the active system and the secondary center 20 that is the standby system, thereby achieving non-stop operation. Become.

以上、本発明を実施するための最良の形態などについて具体的に説明したが、本発明はこれに限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能である。 Although the best mode for carrying out the present invention has been specifically described above, the present invention is not limited to this, and various modifications can be made without departing from the scope of the invention.

こうした本実施形態によれば、クリティカルな運用形態となる現用系システムとその待機系システムの間において、高精度の整合性が確保された引継ぎ処理を実行し、無停止運転を達成することが出来る。 According to the present embodiment, it is possible to perform non-stop operation by executing a takeover process in which high-precision consistency is ensured between the active system that is a critical operation mode and the standby system. .

本明細書の記載により、少なくとも次のことが明らかにされる。すなわち、本実施形態のデータベース管理方法において、前記現用系システムが、前記第１処理において、前記更新情報のヘッダに設定した最新の通番を該当トランザクションに関して記憶装置に格納する処理を更に実行し、前記インクリメントに際して、前記記憶装置に格納した最新の通番からインクリメントを行うとしてもよい。 At least the following will be clarified by the description of the present specification. That is, in the database management method of the present embodiment, the active system further executes a process of storing the latest serial number set in the header of the update information in the storage device in the first process in the storage device, When incrementing, the increment may be performed from the latest serial number stored in the storage device.

これによれば、上述の通番のインクリメントに際しベースとなる通番の値を確実に管理することが可能となる。 According to this, it is possible to reliably manage the base serial number value when the serial number is incremented.

また、本実施形態のデータベース管理方法において、前記現用系システムが、前記第１処理において、前記更新要求が示す更新情報のユーザ定義領域に、ユーザ定義の通番を設定し、前記トランザクションに関する更新要求を受ける毎に前記ユーザ定義の通番をインクリメントして、以降の更新情報のユーザ定義領域に設定する処理を更に実行し、前記待機系システムが、前記第３処理において、前記現用系システムから前記更新情報を受信した際、当該更新情報が示すユーザ定義の通番を記憶装置に格納する処理を更に実行し、前記第４処理において、前記キューに登録された更新情報のうち、同じトランザクションに関するものを抽出し、当該抽出した更新情報における最新のユーザ定義の通番が、前記第３処理にて前記記憶装置に格納してあるユーザ定義の通番より１つ大きいとの条件を満たすか判定する処理を更に実行し、前記条件を満たさなかった場合、所定時間待機して前記第３処理及び第４処理を再実行するとしてもよい。 Further, in the database management method of the present embodiment, in the first process, the active system sets a user-defined serial number in the user-defined area of the update information indicated by the update request, and issues an update request related to the transaction. Each time it is received, the user-defined serial number is incremented to further execute a process of setting it in the user-defined area of the subsequent update information, and the standby system receives the update information from the active system in the third process. Is received, a process for storing the user-defined serial number indicated by the update information in the storage device is further executed, and in the fourth process, the update information registered in the queue is extracted for the same transaction. The latest user-defined serial number in the extracted update information is stored in the storage device in the third process. If the condition that the condition is one larger than the user-defined serial number is further executed, and if the condition is not satisfied, the third process and the fourth process are re-executed after waiting for a predetermined time. Also good.

これによれば、ヘッダに設定した通番に基づいて、更新情報をトランザクション中の処理順序に整合させる処理に加えて、ユーザ定義領域に設定したユーザ定義の通番に基づく更新情報の順序性を確保することも可能となり、更に高精度の整合性が確保された引継ぎ処理を実行することが出来る。 According to this, based on the serial number set in the header, in addition to the process of matching the update information with the processing order in the transaction, the order of the update information based on the user-defined serial number set in the user-defined area is ensured. In addition, it is possible to execute a takeover process in which high-precision consistency is ensured.

また、本実施形態のデータベース管理方法において、前記待機系システムが、前記第５処理において、前記現用系システムにおけるデータベースの構成変更処理に対応した、当該待機系システムにおけるデータベースの構成変更処理の完了通知を、入力装置ないし通信可能に結ばれた外部端末から受け付け済みである場合に、前記構成変更処理後のデータベースの構成に対応する形式に、前記更新情報群の各更新情報を修正して、当該修正した更新情報群に基づいて、当該待機系システムにおけるデータベースを更新するとしてもよい。 Further, in the database management method of the present embodiment, the standby system responds to the database configuration change process in the active system in the fifth process, and the completion notification of the database configuration change process in the standby system. In the format corresponding to the configuration of the database after the configuration change process, the update information in the update information group is corrected to the format corresponding to the configuration of the database after the configuration change processing, The database in the standby system may be updated based on the corrected update information group.

これによれば、現用系システムでのデータベースの構成変更処理に先立ち、該当構成変更処理の内容に応じて待機系システムのデータベースの構成変更処理を行い、その上で現用系システムから処理の引継ぎを行うことが可能である。その場合、現用系システムでのデータベースの構成変更処理が完了した時点で、オンラインシステムを待機系システムから現用系システムへ復帰させることも、トランザクション中での更新情報の順序性を高精度に確保しつつ、円滑かつ確実に実行できる。 According to this, prior to the database configuration change processing in the active system, the database configuration change processing of the standby system is performed according to the contents of the corresponding configuration change processing, and then the processing is taken over from the active system. Is possible. In that case, returning the online system from the standby system to the active system when the database configuration change processing in the active system is completed also ensures the order of the update information in the transaction with high accuracy. However, it can be executed smoothly and reliably.

１０データベース管理システム
１５プライマリセンタ
２０セカンダリセンタ
５０ネットワーク
１００送信側サーバ（現用系システム）
１０１記憶装置
１０２プログラム
１０３主記憶装置
１０４演算装置
１０５入力装置
１０６出力装置
１０７通信装置
１０８ＯＳ
１１０アプリケーション
１１１ユーザ部
１１２ＡＰＰ
１１３製品
１１５ＤＫＣ
１１６データベース
１１７送信側ジャーナル
１２５更新情報テーブル
１２６ＤＢ定義テーブル
１２７ユーザ定義テーブル
１２８ＡＰＰ定義テーブル
１２９製品情報テーブル
２００受信側サーバ群（待機系システム）
２１０第１の受信側サーバ
２１１記憶装置
２１２プログラム
２１３主記憶装置
２１４演算装置
２１５入力装置
２１６出力装置
２１７通信装置
２１８ＯＳ
２１０アプリケーション
２２１ユーザ部
２２２ＡＰＰ
２２３製品
２２５ＤＫＣ
２２６データベース
２２７受信側ジャーナル
２２８ＤＢキュー
２３５ＡＰＰ定義テーブル
２３６ＤＢキュー情報テーブル
２５０第２の受信側サーバ
２５１記憶装置
２５２プログラム
２５３主記憶装置
２５４演算装置
２５５入力装置
２５６出力装置
２５７通信装置
２５８ＯＳ
２６０アプリケーション
２６１ユーザ部
２６２ＡＰＰ
２６３製品
２６５ユーザ定義テーブル 10 Database management system 15 Primary center 20 Secondary center 50 Network 100 Transmission side server (active system)
101 Storage Device 102 Program 103 Main Storage Device 104 Arithmetic Device 105 Input Device 106 Output Device 107 Communication Device 108 OS
110 Application 111 User part 112 APP
113 Products 115 DKC
116 Database 117 Transmission side journal 125 Update information table 126 DB definition table 127 User definition table 128 APP definition table 129 Product information table 200 Receiving side server group (standby system)
210 First receiving server 211 Storage device 212 Program 213 Main storage device 214 Computing device 215 Input device 216 Output device 217 Communication device 218 OS
210 Application 221 User part 222 APP
223 Products 225 DKC
226 Database 227 Reception side journal 228 DB queue 235 APP definition table 236 DB queue information table 250 Second reception side server 251 Storage device 252 Program 253 Main storage device 254 Arithmetic device 255 Input device 256 Output device 257 Communication device 258 OS
260 Application 261 User part 262 APP
263 Product 265 User-defined table

Claims

The active system connected asynchronously with the standby system
When a database update request is received from an application that is executing a predetermined transaction, the database update process is executed in response to the update request, and the transaction serial number is set in the header of the update information indicated by the update request. Each time an update request related to the transaction is received, the serial number is incremented, set in a header of subsequent update information, and each update information is stored in a storage device;
Executing the second process of transmitting the update information stored in the storage device to the standby system at a predetermined timing;
The standby system is
A third process for receiving the update information from the active system and registering the update information in a queue;
Update information group in which the information related to the same transaction is extracted from the update information registered in the queue, the extracted update information is sorted based on the serial number indicated by the header, and matched to the processing order in the transaction A fourth process for generating
Based on the generated update information group, execute a fifth process for updating the database in the standby system.
A database management method characterized by the above.

The working system is
In the first process, a process of storing the latest serial number set in the header of the update information in the storage device with respect to the corresponding transaction is further executed, and at the time of the increment, the latest serial number stored in the storage apparatus is incremented.
The database management method according to claim 1, wherein:

The working system is
In the first process, a user-defined serial number is set in the user-defined area of the update information indicated by the update request, and the user-defined serial number is incremented each time an update request related to the transaction is received. Execute the process to set in the user-defined area of
The standby system is
In the third process, when the update information is received from the active system, a process of storing a user-defined serial number indicated by the update information in a storage device is further executed.
In the fourth process, the update information registered in the queue is extracted for the same transaction, and the latest user-defined serial number in the extracted update information is stored in the storage device in the third process. In addition, a process for determining whether or not the condition of one greater than a user-defined serial number is satisfied is executed. If the condition is not satisfied, the third process and the fourth process are re-executed after waiting for a predetermined time. ,
The database management method according to claim 2, wherein:

The standby system is
In the fifth process, the completion notification of the database configuration change process in the standby system corresponding to the database configuration change process in the active system has been received from the input device or the external terminal connected to be communicable. In some cases, each update information of the update information group is corrected to a format corresponding to the configuration of the database after the configuration change process, and the database in the standby system is updated based on the corrected update information group The database management method according to claim 3, wherein:

A system including an active system and a standby system that are asynchronously connected to each other;
The working system is
When a database update request is received from an application that is executing a predetermined transaction, the database update process is executed in response to the update request, and the transaction serial number is set in the header of the update information indicated by the update request. Each time an update request related to the transaction is received, the serial number is incremented, set in a header of subsequent update information, and each update information is stored in a storage device;
Executing the second process of transmitting the update information stored in the storage device to the standby system at a predetermined timing;
The standby system is
A third process for receiving the update information from the active system and registering the update information in a queue;
Update information group in which the information related to the same transaction is extracted from the update information registered in the queue, the extracted update information is sorted based on the serial number indicated by the header, and matched to the processing order in the transaction A fourth process for generating
Based on the generated update information group, the fifth process of updating the database in the standby system is executed.
A database management system characterized by that.