JP2004145827A

JP2004145827A - Base database device, database cooperation system, database program, data synchronization method, and data restoration method

Info

Publication number: JP2004145827A
Application number: JP2002312782A
Authority: JP
Inventors: Masayasu Ito; 伊藤　正泰; Yoshiko Ito; 伊藤　誉子; Yoshihiro Fujino; 藤野　良弘
Original assignee: Nikon Corp
Current assignee: Nikon Corp
Priority date: 2002-10-28
Filing date: 2002-10-28
Publication date: 2004-05-20

Abstract

<P>PROBLEM TO BE SOLVED: To provide a cooperation technique between a plurality of databases particularly excellent in the extension property or flexibility of a system. <P>SOLUTION: This base database device is arranged in a plurality of bases and mutually connected through a communication line, whereby a database cooperation system is constituted as a whole. This device has a database, an own station-log accumulation part, an other station-log collection part, a control part and another station-log storage part. This database performs registration and management of data in its own base (own station). The own station-log accumulation part accumulates such a data operation in the own station as log data. The other station-log collection part acquires log data of the other station from the other base (other station). The control part reflects the data operation performed in the other station to the database of the own station by following the log data of the other station. The other station-log storage part stores the log data of the other station in which such a reflection is completed by the control part. <P>COPYRIGHT: (C)2004,JPO

Description

【０００１】
【発明の属する技術分野】
本発明は、複数拠点にそれぞれ配置され、通信回線を介して相互接続されることにより、全体でデータベース連携システムを構成する拠点データベース装置に関する。
本発明は、拠点データベース装置を相互接続して構成されるデータベース連携システムに関する。
本発明は、コンピュータを拠点データベース装置として機能させるデータベースプログラムに関する。
本発明は、データベースのデータ同期方法、およびデータ復旧方法に関する。
【従来の技術】
従来、データベース製品の一機能として、遠隔地に配置された複数のデータベース間で差分更新を行う更新同期機能（いわゆるレプリケーション）が知られている。この更新同期機能を定期的に使用することにより、複数のデータベースの内容を同一に維持することができる。
【０００２】
（１）特許文献１の従来技術
このような更新同期機能の従来技術として、特許文献１が知られている。この従来技術では、システムを、基幹ホストと複数のオープンサーバーとから構成する。複数のオープンサーバー側には、独立したデータベースが一つずつ配置される。一方、基幹ホスト側には、これらデータベースのレプリカが一対一に準備される。
データベースの更新処理は、オープンサーバー側においてローカルに実施される。このとき、オープンサーバー側の更新履歴記憶手段は、実行された更新処理の履歴（ログデータ）を個別に蓄積する。
このようなローカルな更新処理により、基幹ホストとオープンサーバーの間には差異が生じる。そこで、基幹ホスト側では、定期的に更新同期機能を起動する。すなわち、基幹ホストは、全てのオープンサーバーに蓄積されるログデータを、基幹ホスト側の更新履歴情報格納手段に一旦収集する。基幹ホストは、このように集まったログデータに基づいて、基幹ホストの各データベースを逐次に更新する。
【０００３】
（２）特許文献２の従来技術
上述した前者の従来技術では、基幹ホストのデータベースが、オープンサーバーの単位に分断される。そのため、基幹ホストに全てのデータベースが集まりながら、そのままではデータベース間にまたがる縦断的なデータ検索などが困難である。このような要望に対処するためには、基幹ホスト側において、データベースを新たに結合する必要が生じる。しかしながら、上述した前者の従来技術では、更新同期のたびにデータベースの内容が逐次変化する。そのため、基幹ホストでは、更新同期のたびに、データベースの結合を一からやり直すなどの必要があった。通常、一つ一つのデータベースのデータ量が膨大になることを考えると、頻繁に繰り返されるデータベースの結合処理は負荷が重く、基幹ホスト側の処理コストが極めて高くなってしまう。
このような問題点を踏まえて、特許文献２には、複数のデータベースの更新履歴を、１つのデータベースにまとめて反映するシステムが開示されている。
このようなシステムでは、更新同期の実施と同時に、複数のデータベースの更新内容が、一つのデータベースに反映される。そのため、データベースを結合するなどの負荷が少なく、基幹ホスト側の処理コストを下げることが可能になる。
【０００４】
【特許文献１】
特開２０００−２０３７４号公報
【特許文献２】
特開２００２−１０８６８１号公報
【０００５】
【発明が解決しようとする課題】
ところで、特許文献２では、基幹ホストのデータベース内に、複数のデータベースが混在する。そのため、基幹ホストのデータベースと、各オープンサーバーのデータベースとは、一対一に対応しない。そのため、オープンサーバー側でデータベースが破損した場合、基幹ホストのデータベースをそのまま使ってデータベースを復旧することが難しかった。
【０００６】
さらに、上述した特許文献１および特許文献２では、更新同期の方向が、オープンサーバーから基幹ホストへの一方向だけであった。そのため、緊急時などにおいて、オープンサーバーを基幹ホストとして一時的に機能させるなどの柔軟な動作が不可能であった。
【０００７】
また、基幹ホストとオープンサーバーとは、通常時の動作が大きく異なるため、同一のシステム構成で構成することが困難であった。そのため、基幹ホストとオープンサーバーそれぞれについて、システムを独自に構築しなければならず、システムのメンテナンスなどが複雑かつ高コストになるといった問題点もあった。
【０００８】
そこで、本発明は、上述した問題点に鑑みて、システムの拡張性や柔軟性に特に優れた、複数データベース間の連携技術を提供することを目的とする。
【０００９】
【課題を解決するための手段】
以下、本発明について説明する。
【００１０】
《請求項１》
請求項１に記載の発明は、複数拠点にそれぞれ配置され、通信回線を介して相互接続されることにより、全体でデータベース連携システムを構成する拠点データベース装置であって、データベースと、自局ログ蓄積部と、他局ログ収集部と、制御部と、他局ログ保管部とを備える。
このデータベースは、自らの拠点（以下『自局』という）においてデータの登録および管理を行う。
自局ログ蓄積部は、自局内におけるデータベースのデータ操作をログデータとして蓄積する。
他局ログ収集部は、他の拠点（以下『他局』という）に蓄積されるログデータを取得する。
制御部は、他局ログ収集部に取得されたログデータを辿ることによって、他局でなされたデータ操作を自局のデータベースに反映する。
他局ログ保管部は、制御部によって反映を完了した他局のログデータを保管する。
【００１１】
《請求項２》
請求項２に記載の発明は、請求項１に記載の拠点データベース装置において、自局ログ蓄積部は、自局で蓄積したログデータを他局に伝送し、他局での反映を確認した後に、そのログデータを削除する。
【００１２】
《請求項３》
請求項３に記載の発明は、請求項１または請求項２に記載の拠点データベース装置において、他局ログ保管部は、他局のデータベース破損に際して、保管する他局のログデータを他局に返還する。
【００１３】
《請求項４》
請求項４に記載の発明は、請求項１ないし請求項３のいずれか１項に記載の拠点データベース装置において、制御部は、自局のデータベース破損に際して、他局の他局ログ保管部から自局のログデータの返還を受け、返還されたログデータを辿って他局のデータベースから自局のデータを選択取得して、自局のデータベースを復旧する。
【００１４】
《請求項５》
請求項５に記載の発明は、請求項１または請求項２に記載の拠点データベース装置において、他局ログ保管部が、他局のデータベース破損に際して、保管する他局のログデータを自局ログ蓄積部に移動する。
【００１５】
《請求項６》
請求項６に記載の発明は、請求項１，２，５のいずれか１項に記載の拠点データベース装置において、制御部が、自局のデータベース破損に際して、他局の他局ログ保管部に保管される自局のログデータを、他局の自局ログ蓄積部に移動させることで更新同期の対象に擬制し、他局から自局へデータ操作を反映する処理を実行することにより、自局のデータベースを復旧する。
【００１６】
《請求項７》
請求項７に記載のデータベース連携システムは、請求項１ないし請求項６のいずれか１項に記載の拠点データベース装置を複数拠点にそれぞれ配置し、通信回線を介して接続することにより構成される。
【００１７】
《請求項８》
請求項８に記載のデータベースプログラムは、コンピュータを、請求項１ないし請求項６のいずれか１項に記載のデータベース、自局ログ蓄積部、他局ログ収集部、制御部、および他局ログ保管部として機能させることを特徴とする。
【００１８】
《請求項９》
請求項９に記載のデータ同期方法は、複数拠点にそれぞれ配置されるデータベース間において、更新同期を行う方法であって、自局内において、データベースに対するデータ操作をログデータとして蓄積するステップと、他局に蓄積されたログデータを取得するステップと、他局から取得したログデータを辿ることにより、他局でなされたデータ操作を自局のデータベースに反映するステップと、反映を完了した他局のログデータを自局に保管するステップとを含む。
【００１９】
《請求項１０》
請求項１０に記載のデータ復旧方法は、複数拠点にそれぞれ配置されるデータベース間において、破損したデータベースを復旧する方法であって、通常時、他局の更新同期に際して、自局のログデータを他局に移管するステップと、データ破損時、他局に移管されている自局のログデータを取得するステップと、他局から取得したログデータに基づいて、他局のデータベースから自局のデータを選択取得し、自局のデータベースを復旧するステップとを含む。
【００２０】
《請求項１１》
請求項１１に記載のデータ復旧方法は、複数拠点にそれぞれ配置されるデータベース間において、破損したデータベースを復旧するデータ復旧方法であって、通常時、他局の更新同期に際して、自局のログデータを他局に移管するステップと、データ破損時、他局に移管されている自局のログデータを、更新同期の対象に擬制した上で、前記他局から前記自局へデータ操作を反映する処理を実行することにより、前記自局の前記データベースを復旧するステップとを含む。
【００２１】
【発明の実施の形態】
《第１の実施形態》
第１の実施形態は、請求項１〜４，７〜１０に対応する実施形態である。
【００２２】
［第１の実施形態のシステム構成］
図１は、データベース連携システム２０の構成を示す図である。このデータベース連携システム２０は、複数の拠点Ｎ，Ｋ，Ｍ・・に配置された拠点データベース装置１１ｎ，１１ｋ，１１ｍ・・から構成される。これらの拠点データベース装置１１ｎ，１１ｋ，１１ｍ・・は、通信回線２１によって相互に接続される。
図１に示すように、拠点Ｎの拠点データベース装置１１ｎは、下記のようなオブジェクトから構成される。（なお、その他の拠点データベース装置１１ｋ，１１ｍも、データベースの記憶容量が異なるなどの量的な差異を除いて原則的に同一構成である。）
【００２３】
（１）データベース１２ｎ・・拠点Ｎには不図示のスキャナーやＣＡＤマシンが配置され、これらを介して図面データが入力される。データベース１２ｎは、入力される図面データの登録管理を行う。図１には、このデータベース１２ｎの一例として、３つのテーブルＡ〜Ｃを用いて図面の登録管理を行うリレーショナルデータベースを示す。
【００２４】
（２）自局ログ蓄積部１３ｎ・・拠点Ｎにおいてデータベース１２ｎに為されるローカルなデータ操作をログデータとして蓄積する。
【００２５】
（３）他局ログ収集部１４ｎ・・他の拠点Ｋ，Ｍ・・で蓄積されるログデータを通信回線２１を介して取得して一時記憶する。
【００２６】
（４）制御部１５ｎ・・他の拠点Ｋ，Ｍ・・から取得したログデータを辿ることによって、他の拠点Ｋ，Ｍで為されたデータ操作を、拠点Ｎのデータベース１２ｎに反映する。
【００２７】
（５）他局ログ保管部１６ｎ・・他の拠点Ｋ，Ｍ・・から収集したログデータの内、データベース１２ｎへの反映が完了したものを選択して保管する。
なお、これらのオブジェクトをプログラムコード化することにより、データベースプログラムを作成してもよい。このデータベースプログラムをコンピュータで実行することによって、コンピュータを、上述した拠点データベース装置として機能させることが可能になる。
次に、第１の実施形態で扱うデータ構造について順番に説明する。
【００２８】
［テーブルＡのデータ構造］
図２は、テーブルＡの列定義を示す図である。このテーブルＡは、図面の付随情報を格納するためのテーブルである。
図２に示すように、テーブルＡの各レコードは、下記のように列定義されたデータから構成される。
▲１▼ＯＩＤ（基本オブジェクト識別子）・・テーブルＡの主キーである。
▲２▼ＵＳＲＫＥＹ・・図面を特定するためのキーである。図面の実データまたは付随情報のいずれかが更新されるたびに変化する。そのため、図面の更新履歴を辿る際に利用できる。
▲３▼ＤＷＧＩＤ・・図面の図番・巻。
▲４▼ＰＡＧＥＮＯ・・図面のページ番号。
▲５▼ＷＡＰＮＵＭ・・図面の入れ替え回数。
▲６▼ＲＥＬＴＳ・・出図済みのタイムスタンプ。
▲７▼Ｒ１ＯＩＤ・・図面実体を指定するＯＩＤである。テーブルＣのＲ１ＯＩＤと結合するためのキーである。
【００２９】
［テーブルＢのデータ構造］
図３は、テーブルＢの列定義を示す図である。このテーブルＢは、テーブルＡと分担して、図面の付随情報を管理する。
図３に示すように、テーブルＢの各レコードは、下記のように列定義されたデータから構成される。
▲１▼ＯＩＤ（基本オブジェクト識別子）・・テーブルＡのＯＩＤと結合するためのキーである。
▲２▼ＷＡＰＮＯ・・図面入れ替えの通し番号。
▲３▼ＷＡＰＤＡＴＥ・・図面入れ替えの日時。
▲４▼ＩＰＡＤＤＲＥＳＳ・・ＣＡＤサーバーのＩＰアドレス。
▲５▼ＤＩＲＮＡＭＥ・・格納場所。
▲６▼ＣＡＤＫＩＮＤ・・ＣＡＤの種類。
【００３０】
［テーブルＣのデータ構造］
図４は、テーブルＣの列定義を示す図である。このテーブルＣは、図面の実体データを直接的に管理するテーブルである。
図４に示すように、テーブルＣの各レコードは、下記のように列定義されたデータから構成される。
▲１▼Ｒ１ＯＩＤ・・テーブルＣの主キーである。テーブルＡのＲ１ＯＩＤと結合するためのキーである。
▲２▼ＵＳＲＫＥＹ・・テーブルＡのＵＳＲＫＥＹと同じ値が格納される。
▲３▼ＦＩＬＥＮＡＭＥ・・図面のファイル名。
▲４▼ＤＷＧＩＭＧ・・図面の実データである。データ形式はラージオブジェクト（ＬＯＢ）である。そのため、図面などの他、音声データなどを格納することも可能である。
【００３１】
［ログデータのデータ構造］
図５は、ログデータの列定義を示した図である。自局ログ蓄積部１３ｎおよび他局ログ保管部１６ｎでは、ここで定義される同一構造のログデータを扱う。
図５に示すように、ログデータは、下記のように列定義されたデータから構成される。
▲１▼ＮＯＷＵＳＲＫＥＹ・・データ操作後のＵＳＲＫＥＹ。
▲２▼ＯＬＤＵＳＲＫＥＹ・・データ操作前のＵＳＲＫＥＹ。
▲３▼Ｔ−Ａ・・テーブルＡのイベントフラグ。
▲４▼Ｔ−Ｂ・・テーブルＢのイベントフラグ。
▲５▼Ｔ−Ｃ・・テーブルＣのイベントフラグ。
▲６▼ＥＲＲＯＲＦＬＧ・・データ操作のエラーフラグ。
▲７▼ＣＲＥＴＳ・・データ操作の日時
▲８▼ＬＯＣＡＴＩＯＮ・・拠点（データ操作の場所を示す）
▲９▼ＳＹＯＲＩＴＳ・・他局にデータ操作を反映した日時（他局ログ保管時に追加）
なお、全てのログデータにおいて、ＮＯＷＵＳＲＫＥＹとＯＬＤＵＳＲＫＥＹとのセットはユニークであり、このセットから特定のログデータを一義的に決定することができる。
【００３２】
［自局ログ蓄積部１３ｎの動作説明］
図６および図７は、自局ログ蓄積部１３ｎに蓄積されるログデータの一例を示す図である。以下、この例に従って、自局ログ蓄積部１３ｎの動作について説明する。
まず、拠点ＮのテーブルＡ〜Ｃには、ＵＳＲＫＥＹ＝”ＡＡＡ”に該当する図面データが予め登録されている。
【００３３】
２００２年５月３０日１０時に、拠点Ｎにおいてこの図面データに対するデータ操作が行われ、テーブルＡおよびテーブルＣのレコードが正常に更新される。
このとき、図面データまたは付随情報の変更に伴って、図面データのＵＳＲＫＥＹが”ＡＡＡ”から”ＢＢＢ”に変更される。自局ログ蓄積部１３ｎは、このようなデータ操作を記録するため、図６の一行目に示すログデータを作成して蓄積する。
【００３４】
続いて、同日の１２時に、再び拠点Ｎにおいて、この図面データに対するデータ操作が行われ、テーブルＡおよびテーブルＣのレコードが正常に更新される。
このようなデータ操作に伴って、図面データのＵＳＲＫＥＹは”ＢＢＢ”から”ＣＣＣ”に変更される。自局ログ蓄積部１３ｎは、このようなデータ操作を記録するため、図６の二行目に示すログデータを作成して蓄積する。
【００３５】
さらに、同日の１３時に、この図面データに対する削除操作が拠点Ｎで行われ、テーブルＡ〜Ｃから、この図面データに関するレコードが削除される。自局ログ蓄積部１３ｎは、このようなデータ操作を記録するため、図６の三行目に示すログデータを作成して蓄積する。
続いて、同日の１４時に、一旦削除された図面データの新規登録が拠点Ｎで行われる。この図面データのＵＳＲＫＥＹには、削除された時点の”ＣＣＣ”が付与される。自局ログ蓄積部１３ｎは、このようなデータ操作に応じて、図６の三行目に示すログデータを、図７の三行目に示すログデータに書き換える。
【００３６】
このような書き換えは、前回のイベントフラグと、今回のイベント内容との組み合わせに従って決定される。図８は、このログデータの書き換えルールを示した図である。この書き換えルールにより、図面データの無意味な迂回操作を、ログデータの記録上から排除することが可能になる。その結果、ログデータの蓄積数を低減し、他局における更新同期（後述）を高速化することが可能になる。
なお、図８に示す数字は、『０』は変更なしであり、『１』は削除イベントであり、『２』は新規登録イベントであり、『３』は更新イベントであり、『４』は削除後挿入イベントであり、『×』は、該当するイベントが論理的に存在しないことを意味する。
【００３７】
［更新同期の動作説明］
上述したような拠点ごとのローカルなデータ操作により、拠点間のデータベースに差異が生じる。そこで、中央の拠点（例えば本社所在地）などでは、その他の拠点との間で定期的に更新同期を実行し、データベースの内容を最新状態に維持する。
【００３８】
図９は、この更新同期におけるデータフローを示す図である。図１０は、この更新同期の動作手順を説明する流れ図である。これらの図では、拠点Ｎ（請求項記載の自局に対応）のデータベース１２ｎに、拠点Ｋ（請求項記載の他局に対応）のデータベース１２ｋのデータ操作を反映するケースについて図示している。
以下、図９および図１０を用いて、この更新同期の動作について説明する。
【００３９】
ステップＳ１：　制御部１５ｎは、夜間などの予め定められたタイミングにおいて、更新同期プログラムを起動する（図９▲１▼参照）。この更新同期プログラムの起動により、拠点Ｎの他局ログ収集部１４ｎは、拠点Ｋとの間で通信接続を確立する（図９▲２▼参照）。
【００４０】
ステップＳ２：　拠点Ｎの他局ログ収集部１４ｎは、拠点Ｋの自局ログ蓄積部１３ｋに対して、ログデータの伝送を要求する。拠点Ｋの自局ログ蓄積部１３ｋは、この伝送要求に応えて、拠点Ｎで未処理分のログデータを順次に伝送する。拠点Ｎの他局ログ収集部１４ｎは、このように伝送されるログデータを一時記憶する（図９▲３▼参照）。
【００４１】
ステップＳ３：　拠点Ｎの制御部１５ｎは、他局ログ収集部１４ｎに収集された拠点Ｋのログデータについてエラーフラグ（ＥＲＲＯＲＦＬＧ）をチェックし、正常終了したログデータのみを抽出する。この動作により、異常終了したデータ操作や、更新途中のデータ操作については、更新同期の対象から除外される。
【００４２】
ステップＳ４：　拠点Ｎの制御部１５ｎは、他局ログ収集部１４ｎに収集された拠点Ｋのログデータについて、更新同期の処理対象となる未処理のログデータが存在するか否かを判定する。
ここで、未処理のログデータが存在すれば、拠点Ｎの制御部１５ｎは、更新同期を継続するため、ステップＳ５に動作を移行する。
一方、ログデータが全て反映済みであり、更新同期の処理対象とするログデータが存在しなければ、拠点Ｎの制御部１５ｎは更新同期の動作を終了する。
【００４３】
ステップＳ５：　拠点Ｎの制御部１５ｎは、他局ログ収集部１４ｎに収集された未処理のログデータから、データ操作日時（ＣＲＥＴＳ）の一番古いものを読み出す。
【００４４】
ステップＳ６：　拠点Ｎの制御部１５ｎは、読み出したログデータのイベントフラグを判定する。
ここで、イベントフラグが図面の新規登録や更新や削除後挿入の場合、更新同期に際して拠点Ｋの最新データが必要になる。この場合、拠点Ｎの制御部１５ｎは動作をステップＳ７に移行する。
一方、イベントフラグが図面の削除の場合、拠点Ｎのデータベース１２ｎから対応データを削除するのみでよく、拠点Ｋの最新データは必要ない。この場合、拠点Ｎの制御部１５ｎは動作をステップＳ９に移行する。
【００４５】
ステップＳ７：　拠点Ｎの制御部１５ｎは、ログデータのＮＯＷＵＳＲＫＥＹを拠点Ｋのデータベース１２ｋに照会し、操作対象の新レコードを要求する。
拠点Ｋのデータベース１２ｋは、テーブルＡからＮＯＷＵＳＲＫＥＹと同じ値をＵＳＲＫＥＹに有する操作対象の新レコードを検索する。さらに、データベース１２ｋは、検索されたテーブルＡのレコードから結合キーを辿ることにより、レコードＢ，Ｃの操作対象の新レコードも必要に応じて検索する。
拠点Ｋのデータベース１２ｋは、このような検索された操作対象となる新レコードを拠点Ｎの制御部１５ｎに伝送する（図９▲４▼参照）。
なお、拠点Ｋのデータベース１２ｋは、操作対象の新レコードが見つからない場合、レコード取得に失敗した旨を、拠点Ｎの制御部１５ｎに通知する。
【００４６】
ステップＳ８：　拠点Ｎの制御部１５ｎは、操作対象の新レコードの取得に成功したか否かを判定する。
ここで、新レコードの取得に成功した場合、拠点Ｎの制御部１５ｎは、そのレコードの更新同期を実施するため、ステップＳ９に動作を移行する。
一方、新レコードの取得に失敗した場合、拠点Ｎの制御部１５ｎは、ステップＳ１１の対処動作に移行する。
【００４７】
ステップＳ９：　拠点Ｎの制御部１５ｎは、ログデータのＮＯＷＵＳＲＫＥＹを拠点Ｎのデータベース１２ｎに照会し、ＮＯＷＵＳＲＫＥＹと同じ値をＵＳＲＫＥＹに持つ旧レコードを検索する。
なお、ログデータが新規登録イベントの場合は、操作対象の旧レコードがデータベース１２ｎ内には存在しないため、この動作は省略される。ちなみに、このような新規登録イベントの場合、代わりにＮＯＷＵＳＲＫＥＹをデータベース１２ｎに照会し、該当する新レコードが存在しないことを確認することが好ましい。このような動作において、該当する新レコードがデータベース１２ｎに存在すれば、多重に更新同期を行うなどの異常状況にあることを事前に知ることができる。
【００４８】
ステップＳ１０：　拠点Ｎの制御部１５ｎは、自局内のデータベース１２ｎに対してイベントを適用する（図９▲５▼参照）。
ここで、ログデータが削除イベントであれば、操作対象の旧レコードは、データベース１２ｎから削除される。
また、ログデータが更新や削除後挿入のイベントであれば、操作対象の旧レコードを、拠点Ｋから取得した新レコードに変更する。
一方、ログデータが新規登録イベントであれば、拠点Ｋから取得した新レコードをデータベース１２ｎに新規登録する。
このようなイベント適用の後、拠点Ｎの制御部１５ｎは、ステップＳ１４に動作を移行する。
【００４９】
ステップＳ１１：　ここでの処理は、拠点Ｋに操作対象の新レコードが見あたらない場合の対処動作である。
このようなケースでは、操作対象の新レコードが、別のデータ操作によって、既に別のＵＳＲＫＥＹに変更されていることが考えられる。そこで、拠点Ｎの制御部１５ｎは、ログデータをデータ操作日時の古い順番に辿り、ＵＳＲＫＥＹの変更操作を検索する。
【００５０】
ステップＳ１２：　ステップＳ１１の検索処理において、該当するＵＳＲＫＥＹの変更操作が検出されると、拠点Ｎの制御部１５ｎは、ステップＳ１３に動作を移行する。
一方、該当するＵＳＲＫＥＹの変更操作が検出されない場合、拠点Ｎの制御部１５ｎは、ログデータの整合性に問題があると判断し、ステップＳ１５のエラー処理に動作を移行する。
【００５１】
ステップＳ１３：　ここでは、拠点Ｋにおいて、操作対象の新レコードが既に変更されていて入手不可能であると想像される。
この場合、制御部１５ｎは、拠点Ｋのログデータについて、ＵＳＲＫＥＹの変遷を辿る。
以下、具体例を示して説明する。

上記のようなＵＳＲＫＥＹの変遷が存在する場合、制御部１５ｎは、ＵＳＲＫＥＹをＣＲＥＴＳ（データ操作の日時）の順に『Ａ→Ｂ→Ｃ→Ｄ』と辿って、その起点と終点を連結し、『Ａ→Ｄ』のログデータを生成する。
このようにＵＳＲＫＥＹの変遷を集約した後、制御部１５ｎは、ステップＳ７に動作を戻し、新たな集約済みログデータによるイベント反映に再チャレンジする。
【００５２】
ステップＳ１４：　拠点Ｎの制御部１５ｎは、データベース１２ｎの登録動作が成功したか否かを判断する。
万一、登録に失敗した場合、制御部１５ｎはステップＳ１５のエラー処理に動作を移行する。
一方、登録に成功した場合、制御部１５ｎはステップＳ１６に動作を移行する。
【００５３】
ステップＳ１５：　ここでは、ログデータの反映に失敗したので、制御部１５ｎは、今回のログデータに基づいてデータベース１２ｎに行った処理をロールバックする。このようなエラー処理の後、制御部１５ｎはステップＳ４に動作を戻し、次のログデータの処理に移る。
【００５４】
ステップＳ１６：　ここでは、ログデータの反映に成功したので、他局ログ保管部１６ｎは、反映済みのログデータを他局ログ収集部１４ｎから取得して保管する（図９▲６▼参照）。このとき、他局ログ保管部１６ｎは、ログデータのＳＹＯＲＩＴＳ（反映終了日時）に、現時点の日時データを上書きする。
【００５５】
ステップＳ１７：　拠点Ｎの制御部１５ｎは、反映済みのログデータを拠点Ｋが削除するか否かを判定する。
例えば、その他の拠点（図１に示す拠点Ｍなど）での更新同期が予定されていれば、拠点Ｋはこのログデータを削除できない。このような場合、拠点Ｎの制御部１５ｎは、反映済みログデータの削除を拠点Ｋに要求せず、ステップＳ４に動作を戻す。
一方、その他の拠点での更新同期の予定がない場合には、拠点Ｋでは、このログデータを削除することができる。この場合、拠点Ｎの制御部１５ｎは、ステップＳ１８に動作を移行する。
【００５６】
ステップＳ１８：　拠点Ｎの制御部１５ｎは、拠点Ｋの自局ログ蓄積部１３ｋに対して、ログデータの反映済みを通知する。この通知の後、拠点Ｎの制御部１５ｎは、ステップＳ４に動作を戻す。
一方、拠点Ｋの自局ログ蓄積部１３ｋでは、拠点Ｎ側から反映済みの通知を確認すると、この反映済みのログデータを拠点Ｋから削除する（図９▲７▼参照）。
以上述べた一連の動作を、ログデータごとに繰り返すことにより、更新同期の動作が完了する。
【００５７】
［復旧処理の動作説明］
続いて、拠点Ｋの障害発生などに対処して、データベース１２ｋを復旧する動作について図１１を用いて説明する。
【００５８】
ステップＳ３１：　拠点Ｋの制御部１５ｋは、データベース１２ｋの破損に対処して、復旧プログラムを起動する。この復旧プログラムの起動により、拠点ｋの制御部１５ｋは、拠点Ｎとの間で通信接続を確立する。
【００５９】
ステップＳ３２：　拠点Ｋの制御部１５ｋは、拠点Ｎの他局ログ保管部１６ｎに対してデータベース１２ｋの破損を情報伝達する。拠点Ｎの他局ログ保管部１６ｎは、この情報に対応して、保管するログデータの中から拠点Ｋの分を選別して拠点Ｋに返還する。拠点Ｋの制御部１５ｋは、返還されるログデータを取得して一時記憶する。
【００６０】
ステップＳ３３：　拠点Ｋの制御部１５ｋは、拠点Ｎから返還を受けたログデータについて、復旧処理の対象となる未処理のログデータが存在するか否かを判定する。
ここで、未処理のログデータが存在すれば、拠点Ｋの制御部１５ｋは、復旧処理を継続するため、ステップＳ３４に動作を移行する。
一方、ログデータが全て復旧処理済みであれば、拠点Ｋの制御部１５ｋは復旧処理の動作を終了する。
【００６１】
ステップＳ３４：　拠点Ｋの制御部１５ｋは、未処理のログデータの中から、反映終了日時（ＳＹＯＲＩＴＳ）の一番古いものを読み出す。
【００６２】
ステップＳ３５：　拠点Ｋの制御部１５ｋは、読み出したログデータを起点として、未処理ログデータの中においてＵＳＲＫＥＹの変遷を辿り、そのＵＳＲＫＥＹに関する最新のログデータを得る。
（具体的には、起点のログデータからＮＯＷＵＳＲＫＥＹの値を得て、この値をＯＬＤＵＳＲＫＥＹに有するログデータを反映終了日時の古い順に探索する。新しいログデータが見つかった場合は、このログデータを起点にして、同様の探索を再び繰り返す。このような探索の繰り返しにおいて、新しいログデータが見つからなければ、最終的に見つけたログデータが最新のログデータである。）
ステップＳ３６：　拠点Ｋの制御部１５ｋは、最新のログデータのイベントフラグを判定する。
ここで、イベントフラグが図面の新規登録や更新や削除後挿入の場合、復旧に際して拠点Ｎの最新データが必要になる。この場合、拠点Ｋの制御部１５ｋは動作をステップＳ３７に移行する。
一方、イベントフラグが図面の削除の場合、破損前のデータベース１２ｋにおいても削除済みであったので、データ復旧の対象外と判断できる。この場合、拠点Ｋの制御部１５ｋは動作をステップＳ３３に移行し、次のログデータの処理に移行する。
【００６３】
ステップＳ３７：　拠点Ｋの制御部１５ｋは、最新のログデータのＮＯＷＵＳＲＫＥＹを拠点Ｎのデータベース１２ｎに照会し、操作対象の新レコードを要求する。
なお、拠点Ｎにおいて、操作対象の新レコードが見つからない場合、レコード取得に失敗した旨を、拠点Ｋの制御部１５ｋに通知する。
【００６４】
ステップＳ３８：　拠点Ｋの制御部１５ｋは、操作対象の新レコードの取得に成功したか否かを判定する。
ここで、新レコードの取得に成功した場合、拠点Ｋの制御部１５ｋは、そのレコードの更新同期を実施するため、ステップＳ３９に動作を移行する。
一方、新レコードの取得に失敗した場合、拠点Ｋの制御部１５ｋは、ステップＳ４１のエラー処理に移行する。
【００６５】
ステップＳ３９：　拠点Ｋの制御部１５ｋは、取得した新レコードをデータベース１２ｋに登録する。
【００６６】
ステップＳ４０：　拠点Ｋの制御部１５ｋは、データベース１２ｋの登録動作が成功したか否かを判断する。
万一、登録に失敗した場合、制御部１５ｋはステップＳ４１のエラー処理に動作を移行する。
一方、登録に成功した場合、制御部１５ｋはステップＳ３３に動作を戻し、次のログデータの処理に移行する。
【００６７】
ステップＳ４１：　ここでは、ログデータによる復旧に失敗したので、制御部１５ｋは、今回のログデータに基づくデータベース１２ｋの操作をロールバックする。その後、次のログデータの処理に移るため、制御部１５ｋはステップＳ３３に動作を戻す。
以上述べた動作を、一連のログデータに対して実行することにより、復旧処理が完了する。
【００６８】
［第１の実施形態の効果など］
上述したように、第１の実施形態では、更新同期元（上記説明では拠点Ｋ）は、更新同期先（上記説明では拠点Ｎ）に反映済みログデータを保管してもらう。
そのため、更新同期元においてデータ破損が万一生じても、反映済みログデータは更新同期先に保管されており安全である。
【００６９】
さらに、更新同期先では、更新同期元のデータベース破損に際して、保管しているログデータを更新同期元に返還する。更新同期元では、このログデータと自局の破損したデータベースとを照合することによって、自局のデータベースの破損状況（消滅レコードの特定など）を正確に判断することが可能になる。また、更新同期元では、上述した復旧処理を実行することにより、自局で消滅したレコードを更新同期先から適切に取得して、破損したデータベータを復旧することができる。
【００７０】
さらに、第１の実施形態では、更新同期先におけるログデータの反映を確認すると、反映済みログデータを更新同期元から削除する。このような削除動作により、同一のログデータについて多重に更新同期を行ってしまうなどの不具合を回避することができる。
【００７１】
また、上述した第１の実施形態では、複数の拠点データベース装置１１ｎ，１１ｋ，１１ｍを同一構成で構築する。したがって、拠点ごとに独自のシステムを構築する必要がなく、システムの構築コストやメンテナンスコストを低減することができる。また、同一構成の拠点データベース装置１１ｎ，１１ｋ，１１ｍを連結するため、拠点の数を増やすなどの拡張性も非常に優れている。
【００７２】
その上、上述した第１の実施形態では、下記のような柔軟なシステム動作が可能になる。
【００７３】
（ケース１）
拠点Ｎを基幹拠点として、拠点Ｋおよび拠点Ｍの内容を拠点Ｎに反映する。この場合、基幹拠点Ｎには、拠点Ｋおよび拠点Ｍの内容を包含したデータベース１２ｎを構築することが可能になる。したがって、基幹拠点Ｎでは、拠点Ｋおよび拠点Ｋで登録された図面を取得できるので、マイクロフィルム化するなどの一極集中処理が容易になる。さらに、拠点Ｋ（または拠点Ｍ）では、自局分の反映済みログデータを辿ることによって、データベース１２ｎのサブセットであるデータベース１２ｋを適切に復旧することができる。
【００７４】
（ケース２）
複数の拠点データベース装置１１ｎ，１１ｋ，１１ｍは同一構成である。したがって、普段は拠点Ｎを基幹拠点として運営し、拠点Ｎに支障が生じる場合（故障時やメンテナンス時など）、その他の拠点Ｋ（または拠点Ｍ）を基幹拠点として一時的に運営することが容易にできる。
次に、別の実施形態について説明する。
【００７５】
《第２の実施形態》
第２の実施形態は、請求項１，２，５〜１０に対応する実施形態であり、第１の実施形態とは、データ復旧時の動作が異なる。なお、その他については、第１の実施形態と同一であるため、ここでの説明を省略する。
図１２は、第２の実施形態における復旧処理を示す流れ図である。
以下、図１２に示すステップ番号の順に説明する。
【００７６】
ステップＳ５１：　拠点Ｋの制御部１５ｋは、データベース１２ｋの破損に対処して、拠点Ｎとの間で通信接続を確立する。この拠点Ｎは、通常時、拠点Ｋのデーターベース更新を追跡して更新同期を実行していた拠点である。そのため、拠点Ｎには、前回の更新同期の時点における拠点Ｋのデータベースの内容が保持されている。
【００７７】
ステップＳ５２：　拠点Ｋの制御部１５ｋは、拠点Ｎに指令して、拠点Ｎの他局ログ保管部１６ｎが保管する自局分（つまり拠点Ｋ）のログデータを、拠点Ｎの自局ログ蓄積部１３ｎに移動させる。
この移動処理により、拠点Ｋのログデータが、拠点Ｋから見て、更新同期の対象に擬制される。
【００７８】
ステップＳ５３：　上述した準備の完了後、拠点Ｋの制御部１５ｋは、更新同期プログラム（例えば、図１０）を実行する。
ここで、拠点Ｋのログデータが拠点Ｎに全て残っていれば、拠点Ｋ内のデータベースが完全破損によって初期化されていても、更新同期プログラムによるデータ復旧に問題は生じない。
【００７９】
なお、拠点Ｋのログデータの内、最近のものしか残っていない場合、拠点Ｋ内に存在しないレコードを探索したり削除しようとして、エラーが発生する。この場合、更新同期プログラムは、エラーを無視して、可能な範囲でイベント反映を実行することにより、拠点Ｋのデータベースを最近の状態まで復旧できる。
このような動作において、拠点Ｋのログデータに限って更新同期を実行すれば、拠点Ｎのデータベース内から拠点Ｋのデータを選択抽出し、拠点Ｋのデータベースを適切に復旧することが可能になる。このような動作は、例えば、拠点ＮのログデータのＥＲＲＯＲＦＬＧを一時的に立てるなどの動作により可能となる。
この場合、拠点Ｎ本来のログデータは、更新同期の対象外となるため、拠点Ｋのデータベースに反映されない。そのため、拠点Ｎ本来のログデータが、自局ログ蓄積部１３ｎから削除されることもない。なお、この場合、一時的に立てたＥＲＲＯＲＦＬＧは、拠点Ｋのデータ復旧の後、元に戻される。
一方、拠点Ｎのログデータも合わせて更新同期した場合には、拠点Ｋのデータベース復旧と、拠点Ｎの更新同期とを一度に行うこともできる。
【００８０】
［第２の実施形態の効果など］
以上説明したように、第２の実施形態においても、第１の実施形態と同様の効果を得ることができる。
【００８１】
特に、第２の実施形態では、他局内に保管される自局分のログデータを更新同期の対象に擬制する。このような擬制により、更新同期プログラムとほぼ同一の手順で、破損したデータベースを復旧させることが可能になる。
【００８２】
さらに、上述した復旧動作を応用することにより、その他の拠点（ここでは、図１に示す拠点Ｍとする）のログデータを更新同期の対象に擬制することにより、拠点Ｎと拠点Ｋとの間だけで、拠点Ｍのデータベースを拠点Ｎから抽出することが可能である。この抽出動作では、拠点Ｍのデータベースに直接アクセスする必要がない。そのため、拠点Ｍのデータ転送速度が遅い場合などに、有用な複製またはバックアップの手段となる。
【００８３】
また、上述した抽出動作を何度か行うことにより、通常の更新同期動作によって拠点Ｎにまとめておいた複数拠点分のデータを、拠点単位のデータベースに分割することが可能になる。
【００８４】
《実施形態の補足事項》
以下、第１および第２の実施形態の補足事項について説明する。
さらに、上述した実施形態では、図１に示すバックアップ処理部３１を使用して、更新同期先のバックアップ処理を行うことが好ましい。この更新同期先のバックアップ処理により、更新同期先の復旧を確実にすると共に、他局ログ保管部１６ｎに保管する反映済みログデータの消滅を防ぐことが可能になる。その結果、更新同期元の復旧可能性を更に一段と確実にすることができる。
【００８５】
また、上述した実施形態では、図面データを管理する場合について具体的に説明している。しかしながら、本発明が管理するデータの種類は、図面データに限定されるものではない。
【００８６】
なお、上述した実施形態では、全ての拠点データベース装置に他局ログ保管部を設けている。しかしながら、更新同期先にならない一部の拠点データベース装置については、他局ログ保管部を省略しても勿論かまわない。
【００８７】
また、上述した実施形態では、更新同期元のデータ操作を、一括して更新同期先に反映している。しかしながら、本発明はこれに限定されるものではない。例えば、他局ログ収集部１４ｎにおいて、ログデータを選別することにより、一部のデータ操作のみを更新同期先に反映することも可能である。
【００８８】
なお、上述した実施形態では、更新同期においては拠点Ｎが主体となって殆どの動作を行い、復旧動作においては拠点Ｋが主体となって殆どの動作を行う場合について説明した。しかしながら、どちらかの拠点が動作の全てを管轄して実行する必要はない。例えば、相手側の拠点にこれら動作の全部または一部を委任することも本発明の範囲内である。もちろん、拠点Ｋおよび拠点Ｎのどちらが、更新同期や復旧動作を起動してもかまわない。また、その他の拠点が、リモートによって、上述した更新同期や復旧動作を起動してもかまわない。
【００８９】
【発明の効果】
本発明の拠点データベース装置は、他局との更新同期に際して、他局の反映済みログデータを保管する。そのため、他局でデータ破損が生じても、他局のデータ復旧の必要となる反映済みログデータは自局側で保管されており安全である。
さらに、この保管されている他局の反映済みログデータと、破損した他局のデータベースとを照合することにより、他局のデータベースの破損状況を適切に診断することも容易になる。
【００９０】
さらに、本発明のデータベース連携システムは、同一構成の拠点データベース装置を複数含む。したがって、これらの拠点データベース装置間において、更新同期元と更新同期先の役割を柔軟に交換したり、更新同期可能な拠点データベース装置の数を柔軟に増減することが容易になる。
【図面の簡単な説明】
【図１】データベース連携システム２０の構成を示す図である。
【図２】テーブルＡの列定義を示す図である。
【図３】テーブルＢの列定義を示す図である。
【図４】テーブルＣの列定義を示す図である。
【図５】ログデータの列定義を示した図である。
【図６】自局ログ蓄積部１３ｎに蓄積されるログデータの一例を示す図である。
【図７】自局ログ蓄積部１３ｎに蓄積されるログデータの一例を示す図である。
【図８】ログデータの書き換えルールを示した図である。
【図９】更新同期におけるデータフローを示す図である。
【図１０】更新同期の動作手順を説明する流れ図である。
【図１１】復旧処理の動作手順を説明する流れ図である。
【図１２】復旧処理の動作手順を説明する流れ図である。
【符号の説明】
１１ｎ，１１ｋ，１１ｍ　拠点データベース装置
１２ｎ，１２ｋ　データベース
１３ｎ，１３ｋ　自局ログ蓄積部
１４ｎ　他局ログ収集部
１５ｎ，１５ｋ　制御部
１６ｎ，１６ｋ　他局ログ保管部
２０　データベース連携システム
２１　通信回線
３１　バックアップ処理部[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a site database device which is arranged at each of a plurality of sites and interconnected via a communication line, thereby constituting a database cooperation system as a whole.
The present invention relates to a database cooperation system configured by interconnecting base database devices.
The present invention relates to a database program that causes a computer to function as a base database device.
The present invention relates to a data synchronization method for a database and a data recovery method.
[Prior art]
2. Description of the Related Art Conventionally, as one function of a database product, an update synchronization function (so-called replication) for performing a difference update between a plurality of databases arranged at remote locations is known. By using this update synchronization function regularly, the contents of a plurality of databases can be maintained the same.
[0002]
(1) Prior art of Patent Document 1
Patent Document 1 is known as a conventional technique of such an update synchronization function. In this conventional technique, a system is configured by a main host and a plurality of open servers. On the plurality of open servers, independent databases are arranged one by one. On the other hand, replicas of these databases are prepared one-to-one on the main host side.
The database update process is performed locally on the open server side. At this time, the update history storage means on the open server side individually accumulates the history (log data) of the executed update processing.
Such a local update process causes a difference between the core host and the open server. Therefore, the update synchronization function is periodically activated on the backbone host. That is, the core host temporarily collects the log data accumulated in all the open servers in the update history information storage means on the key host side. The core host sequentially updates each database of the core host based on the collected log data.
[0003]
(2) Prior art of Patent Document 2
In the former conventional technique described above, the database of the main host is divided into open server units. For this reason, while all databases are gathered on the main host, it is difficult to perform a longitudinal data search across the databases as it is. In order to cope with such a demand, it is necessary to newly join a database on the main host side. However, in the former conventional technique described above, the contents of the database change sequentially each time the update is synchronized. For this reason, in the core host, it was necessary to start over from the beginning every time the update was synchronized. Normally, considering that the data amount of each database becomes enormous, the frequently repeated database combining process is heavy and the processing cost on the main host becomes extremely high.
In view of such a problem, Patent Literature 2 discloses a system in which update histories of a plurality of databases are collectively reflected in one database.
In such a system, the update contents of a plurality of databases are reflected on one database simultaneously with the execution of the update synchronization. For this reason, the load such as combining the databases is small, and the processing cost on the main host can be reduced.
[0004]
[Patent Document 1]
JP 2000-20374 A
[Patent Document 2]
JP 2002-108681 A
[0005]
[Problems to be solved by the invention]
By the way, in Patent Document 2, a plurality of databases are mixed in the database of the backbone host. Therefore, the database of the backbone host and the database of each open server do not correspond one-to-one. Therefore, when the database is damaged on the open server side, it has been difficult to recover the database using the database of the main host as it is.
[0006]
Further, in

Patent Documents

1 and 2 described above, the direction of update synchronization is only one direction from the open server to the main host. Therefore, in an emergency or the like, a flexible operation such as temporarily making an open server function as a main host is impossible.
[0007]
In addition, since the core host and the open server have significantly different operations at normal times, it has been difficult to configure them with the same system configuration. Therefore, a system must be independently constructed for each of the core host and the open server, and there has been a problem that maintenance of the system is complicated and costly.
[0008]
In view of the above problems, an object of the present invention is to provide a technology for linking a plurality of databases, which is particularly excellent in system expandability and flexibility.
[0009]
[Means for Solving the Problems]
Hereinafter, the present invention will be described.
[0010]
<< Claim 1 >>
The invention according to claim 1 is a site database device which is arranged at a plurality of sites and interconnected via a communication line, thereby constituting a database cooperation system as a whole, wherein the database and the local station log storage are provided. , A remote station log collection unit, a control unit, and a remote station log storage unit.
This database registers and manages data at its own base (hereinafter referred to as “own station”).
The own station log accumulating unit accumulates data manipulation of the database in the own station as log data.
The other station log collection unit acquires log data accumulated at another base (hereinafter, referred to as “other station”).
The control unit reflects the data manipulation performed by the other station in its own database by tracing the log data acquired by the other station log collection unit.
The other station log storage unit stores log data of another station that has been reflected by the control unit.
[0011]
<< Claim 2 >>
According to a second aspect of the present invention, in the base database device according to the first aspect, the own station log accumulation unit transmits the log data accumulated in the own station to another station, and after confirming reflection in the other station. , Delete the log data.
[0012]
<< Claim 3 >>
According to a third aspect of the present invention, in the base database apparatus according to the first or second aspect, the other station log storage unit returns log data of the other station to be stored to the other station when the database of the other station is damaged. I do.
[0013]
<< Claim 4 >>
According to a fourth aspect of the present invention, in the base database device according to any one of the first to third aspects, when the database of the own station is damaged, the control unit transmits the information to the other station log storage unit of the other station. Receiving the return of the log data of the station, tracing the returned log data, selectively obtaining the data of the own station from the database of the other station, and restoring the database of the own station.
[0014]
<< Claim 5 >>
According to a fifth aspect of the present invention, in the base database device according to the first or second aspect, the other station log storage unit stores the log data of the other station to be stored when the database of the other station is damaged. Move to department.
[0015]
<< Claim 6 >>
According to a sixth aspect of the present invention, in the base database device according to any one of the first, second, and fifth aspects, when the database of the own station is damaged, the control section stores the information in the other station log storage section of the other station. By migrating the log data of the own station to the own station log accumulation unit of the other station, it simulates an update synchronization target, and executes a process of reflecting the data operation from the other station to the own station. Recover the database.
[0016]
<< Claim 7 >>
A database cooperation system according to a seventh aspect is configured by arranging the site database device according to any one of the first to sixth aspects at a plurality of sites and connecting them via a communication line.
[0017]
<< Claim 8 >>
The database program according to claim 8 controls the computer to store the database according to any one of claims 1 to 6, a local station log accumulation unit, another station log collection unit, a control unit, and another station log storage. It is characterized by functioning as a unit.
[0018]
<< Claim 9 >>
10. The data synchronization method according to claim 9, wherein update synchronization is performed between databases respectively arranged at a plurality of bases, wherein a step of accumulating data operations on the database as log data in the own station, Acquiring the log data accumulated in the other station, tracing the log data acquired from the other station to reflect the data operation performed by the other station in the database of the own station, and the log of the other station that has completed the reflection. Storing the data at its own station.
[0019]
<< Claim 10 >>
The data recovery method according to claim 10 is a method for recovering a damaged database between databases respectively located at a plurality of bases. Normally, at the time of update synchronization of another station, the log data of the own station is replaced by another. Transferring the data of the own station from the database of the other station based on the log data obtained from the other station; and transferring the log data of the own station transferred to the other station when the data is damaged. Selectively acquiring and restoring its own database.
[0020]
<< Claim 11 >>
The data recovery method according to claim 11, which is a data recovery method for recovering a damaged database between databases respectively located at a plurality of bases. And transferring the log data of the own station transferred to the other station to the target of update synchronization when the data is damaged, and reflecting the data operation from the other station to the own station. Performing a process to restore the database of the own station.
[0021]
BEST MODE FOR CARRYING OUT THE INVENTION
<< 1st Embodiment >>
The first embodiment is an embodiment corresponding to claims 1 to 4, 7 to 10.
[0022]
[System Configuration of First Embodiment]
FIG. 1 is a diagram showing the configuration of the database cooperation system 20. The database linking system 20 includes base database devices 11n, 11k, 11m,... Arranged at a plurality of bases N, K, M,. These base database devices 11n, 11k, 11m,... Are mutually connected by a communication line 21.
As shown in FIG. 1, the base database device 11n of the base N is composed of the following objects. (Note that the other base database devices 11k and 11m have basically the same configuration except for quantitative differences such as different storage capacities of the databases.)
[0023]
(1) A scanner and a CAD machine (not shown) are arranged at the database 12n and the base N, and drawing data is inputted through these. The database 12n performs registration management of input drawing data. FIG. 1 shows, as an example of the database 12n, a relational database that performs registration management of drawings by using three tables A to C.
[0024]
(2) Local data operation performed on the database 12n at the own station log accumulation unit 13n... Base N is accumulated as log data.
[0025]
(3) The log data accumulated in the other station log collection unit 14n,..., Other bases K, M,.
[0026]
(4) The controller 15n... Tracing the log data acquired from the other bases K, M... Reflects the data operation performed at the other bases K and M in the database 12n of the base N.
[0027]
(5) Other station log storage unit 16n... Of the log data collected from other bases K, M,...
A database program may be created by converting these objects into program codes. Executing this database program on a computer allows the computer to function as the above-described base database device.
Next, the data structure handled in the first embodiment will be described in order.
[0028]
[Data Structure of Table A]
FIG. 2 is a diagram showing the column definition of the table A. This table A is a table for storing the accompanying information of the drawing.
As shown in FIG. 2, each record of the table A is composed of data defined as columns as described below.
{Circle around (1)} OID (basic object identifier): This is the primary key of table A.
{Circle around (2)} USRKEY: A key for specifying a drawing. It changes each time either the actual data of the drawing or the accompanying information is updated. Therefore, it can be used when tracing the update history of the drawing.
(3) DWGID-The figure number of the drawing-Volume.
(4) PAGENO ... The page number of the drawing.
(5) WAPNUM ... The number of times the drawings are replaced.
(6) RELTS: Time stamp already issued.
{Circle around (7)} R1OID: An OID for designating a drawing entity. This is a key for combining with the R1OID in Table C.
[0029]
[Data Structure of Table B]
FIG. 3 is a diagram showing a column definition of the table B. The table B is shared with the table A to manage accompanying information of the drawing.
As shown in FIG. 3, each record of the table B includes data defined in columns as described below.
{Circle around (1)} OID (Basic Object Identifier) A key for combining with the OID of the table A.
(2) WAPNO: The serial number for replacing the drawing.
(3) WAPDATE: The date and time of drawing replacement.
(4) IP ADDRESS-The IP address of the CAD server.
(5) DIRNAME ... storage location.
(6) CADKIND ... The type of CAD.
[0030]
[Data Structure of Table C]
FIG. 4 is a diagram showing the column definition of the table C. This table C is a table for directly managing the entity data of the drawing.
As shown in FIG. 4, each record of the table C is composed of data defined in columns as described below.
{Circle around (1)} R1OID is the primary key of table C. This is a key for combining with the R1OID of Table A.
(2) USRKEY: The same value as USRKEY in table A is stored.
(3) FILENAME ... The file name of the drawing.
{Circle around (4)} DWGIMG ... Actual data of the drawing. The data format is a large object (LOB). Therefore, it is possible to store audio data and the like in addition to drawings and the like.
[0031]
[Data structure of log data]
FIG. 5 is a diagram showing a column definition of log data. The own station log storage unit 13n and the other station log storage unit 16n handle log data having the same structure defined here.
As shown in FIG. 5, the log data includes data defined in columns as described below.
(1) NOWRKEY: USRKEY after data operation.
(2) OLDUSRKEY: USRKEY before data operation.
{Circle around (3)} TA-Table A event flag.
{Circle around (4)} TB—Event flag of table B.
{Circle around (5)} TC-table C event flag.
(6) ERRORFLG: Data operation error flag
7) CRETS: Date and time of data operation
{Circle around (8)} LOCATION ... base (indicates the location of data operation)
(9) SYORITS ... Date and time when data operation was reflected in other stations (added when saving logs of other stations)
In all log data, the set of NOWRUSKEY and OLDUSRKEY is unique, and specific log data can be uniquely determined from this set.
[0032]
[Description of Operation of Own Station Log Accumulator 13n]
6 and 7 are diagrams illustrating an example of log data stored in the local station log storage unit 13n. Hereinafter, the operation of the local station log accumulation unit 13n will be described according to this example.
First, drawing data corresponding to USRKEY = “AAA” is registered in advance in tables A to C of the base N.
[0033]
At 10:00 on May 30, 2002, a data operation is performed on the drawing data at the site N, and the records of the tables A and C are updated normally.
At this time, the USRKEY of the drawing data is changed from "AAA" to "BBB" with the change of the drawing data or the accompanying information. The local station log accumulation unit 13n creates and accumulates the log data shown in the first line of FIG. 6 in order to record such a data operation.
[0034]
Subsequently, at 12:00 on the same day, the data operation on the drawing data is performed again at the base N, and the records of the tables A and C are updated normally.
With such data manipulation, USRKEY of the drawing data is changed from "BBB" to "CCC". The own station log accumulation unit 13n creates and accumulates the log data shown in the second line of FIG. 6 in order to record such a data operation.
[0035]
Further, at 13:00 on the same day, a delete operation on the drawing data is performed at the base N, and a record related to the drawing data is deleted from the tables A to C. The local station log accumulation unit 13n creates and accumulates the log data shown in the third line of FIG. 6 in order to record such a data operation.
Subsequently, at 14:00 on the same day, a new registration of the once deleted drawing data is performed at the base N. “CCC” at the time of deletion is added to USRKEY of this drawing data. The own-station log storage unit 13n rewrites the log data shown in the third line in FIG. 6 to the log data shown in the third line in FIG.
[0036]
Such rewriting is determined according to a combination of the previous event flag and the content of the current event. FIG. 8 is a diagram showing a rule for rewriting the log data. According to this rewriting rule, it is possible to eliminate the meaningless detour operation of the drawing data from the recording of the log data. As a result, the number of accumulated log data can be reduced, and update synchronization (described later) in another station can be speeded up.
In the numbers shown in FIG. 8, “0” indicates no change, “1” indicates a delete event, “2” indicates a newly registered event, “3” indicates an update event, and “4” indicates an update event. This is an insertion event after deletion, and “x” means that the corresponding event does not exist logically.
[0037]
[Operation of update synchronization]
The local data manipulation for each site as described above causes a difference in the database between the sites. Therefore, at a central location (for example, the location of the head office), update synchronization is periodically performed with other locations to maintain the contents of the database in the latest state.
[0038]
FIG. 9 is a diagram showing a data flow in the update synchronization. FIG. 10 is a flowchart illustrating the operation procedure of the update synchronization. These figures show the case where the data operation of the database 12k of the base K (corresponding to another station of the claim) is reflected in the database 12n of the base N (corresponding to the own station described in the claims).
The operation of the update synchronization will be described below with reference to FIGS.
[0039]
Step S1: The control unit 15n starts the update synchronization program at a predetermined timing such as at night (see (1) in FIG. 9). By starting the update synchronization program, the other station log collection unit 14n of the base N establishes a communication connection with the base K (see (2) in FIG. 9).
[0040]
Step S2: The other station log collection unit 14n of the base N requests the own station log accumulation unit 13k of the base K to transmit log data. In response to this transmission request, the own station log accumulation unit 13k of the site K sequentially transmits unprocessed log data at the site N. The other station log collection unit 14n of the base N temporarily stores the log data transmitted in this manner (see (3) in FIG. 9).
[0041]
Step S3: The control unit 15n of the base N checks the error flag (ERRORFLG) for the log data of the base K collected by the other-station log collection unit 14n, and extracts only the log data that ends normally. By this operation, a data operation that has ended abnormally or a data operation that is being updated is excluded from the update synchronization.
[0042]
Step S4: The control unit 15n of the base N determines whether there is unprocessed log data to be subjected to update synchronization processing for the log data of the base K collected by the other-station log collection unit 14n.
Here, if there is unprocessed log data, the control unit 15n of the base N shifts the operation to step S5 in order to continue the update synchronization.
On the other hand, if all the log data has been reflected and there is no log data to be subjected to update synchronization processing, the control unit 15n of the base N ends the update synchronization operation.
[0043]
Step S5: The control unit 15n of the site N reads the oldest data operation date and time (CRETS) from the unprocessed log data collected by the other-station log collection unit 14n.
[0044]
Step S6: The control unit 15n of the base N determines the event flag of the read log data.
Here, when the event flag is a new registration, update, or insertion after deletion of a drawing, the latest data of the site K is required for update synchronization. In this case, the control unit 15n of the base N shifts the operation to Step S7.
On the other hand, when the event flag is to delete the drawing, it is only necessary to delete the corresponding data from the database 12n of the site N, and the latest data of the site K is not required. In this case, the control unit 15n of the base N shifts the operation to Step S9.
[0045]
Step S7: The control unit 15n of the base N refers to the NOWRKEY of the log data to the database 12k of the base K, and requests a new record to be operated.
The database 12k of the base K searches the table A for a new record to be operated having the same value as the NOWRKEY in the USRKEY. Further, the database 12k searches for a new record to be operated on the records B and C as necessary by tracing the join key from the searched record of the table A.
The database 12k of the site K transmits such a searched new record to be operated to the control unit 15n of the site N (see (4) in FIG. 9).
When the new record to be operated is not found, the database 12k of the site K notifies the control unit 15n of the site N that the record acquisition has failed.
[0046]
Step S8: The control unit 15n of the base N determines whether the acquisition of the new record to be operated has succeeded.
Here, when the acquisition of the new record is successful, the control unit 15n of the base N shifts the operation to step S9 in order to perform update synchronization of the record.
On the other hand, if the acquisition of the new record has failed, the control unit 15n of the base N shifts to the coping operation of step S11.
[0047]
Step S9: The control unit 15n of the base N refers to the database 12n of the base N for the NOWRKEY of the log data, and searches for an old record having the same value as the NOWRKEY in the USRKEY.
When the log data is a newly registered event, the operation is omitted because the old record to be operated does not exist in the database 12n. By the way, in the case of such a new registration event, it is preferable to query NOWRKEY to the database 12n instead to confirm that there is no corresponding new record. In such an operation, if a corresponding new record exists in the database 12n, it is possible to know in advance that an abnormal situation such as multiplex update synchronization is occurring.
[0048]
Step S10: The control unit 15n of the base N applies the event to the database 12n in its own station (see (5) in FIG. 9).
Here, if the log data is a delete event, the old record to be operated is deleted from the database 12n.
If the log data is an event of update or insertion after deletion, the old record to be operated is changed to a new record acquired from the base K.
On the other hand, if the log data is a newly registered event, a new record acquired from the base K is newly registered in the database 12n.
After applying such an event, the control unit 15n of the base N shifts the operation to Step S14.
[0049]
Step S11: The processing here is a coping operation when a new record to be operated is not found at the base K.
In such a case, it is conceivable that the new record to be operated has already been changed to another USRKEY by another data operation. Therefore, the control unit 15n of the base N traces the log data in the order of the oldest data operation date and time, and searches for a USRKEY change operation.
[0050]
Step S12: In the search process of step S11, when a corresponding USRKEY change operation is detected, the control unit 15n of the base N shifts the operation to step S13.
On the other hand, when the corresponding USRKEY change operation is not detected, the control unit 15n of the site N determines that there is a problem in the consistency of the log data, and shifts the operation to the error processing in step S15.
[0051]
Step S13: Here, it is imagined that the new record to be operated has already been changed and cannot be obtained at the base K.
In this case, the control unit 15n traces the transition of USRKEY for the log data of the site K.
Hereinafter, a specific example will be described.

If there is a transition of the USRKEY as described above, the control unit 15n traces the USRKEY in the order of CRETS (date and time of data operation) as “A → B → C → D”, connects the start point and the end point, and “ A → D ”log data is generated.
After consolidating the transition of USRKEY in this way, the control unit 15n returns the operation to step S7, and re-attempts to reflect the event with the new consolidated log data.
[0052]
Step S14: The control unit 15n of the base N determines whether the registration operation of the database 12n is successful.
If the registration fails, the control unit 15n shifts the operation to the error processing in step S15.
On the other hand, when the registration is successful, the control unit 15n shifts the operation to Step S16.
[0053]
Step S15: Here, since the reflection of the log data has failed, the control unit 15n rolls back the processing performed on the database 12n based on the current log data. After such error processing, the control unit 15n returns the operation to step S4, and shifts to processing of the next log data.
[0054]
Step S16: Here, since the log data has been successfully reflected, the other-station log storage unit 16n acquires and stores the reflected log data from the other-station log collection unit 14n (see FIG. 9-6). At this time, the other-station log storage unit 16n overwrites SYORITS (reflection end date and time) of the log data with the current date and time data.
[0055]
Step S17: The control unit 15n of the site N determines whether the site K deletes the reflected log data.
For example, if update synchronization is scheduled at another site (such as the site M shown in FIG. 1), the site K cannot delete this log data. In such a case, the control unit 15n of the site N does not request the site K to delete the reflected log data, and returns the operation to step S4.
On the other hand, if there is no schedule for update synchronization at another site, the site K can delete this log data. In this case, the control unit 15n of the base N shifts the operation to Step S18.
[0056]
Step S18: The control unit 15n of the base N notifies the own station log accumulation unit 13k of the base K that log data has been reflected. After this notification, the control unit 15n of the base N returns the operation to Step S4.
On the other hand, the own station log accumulation unit 13k of the site K deletes the reflected log data from the site K when confirming the reflected notification from the site N (see FIG. 9 {circle around (7)}).
By repeating the series of operations described above for each log data, the update synchronization operation is completed.
[0057]
[Description of operation of recovery processing]
Next, an operation of recovering the database 12k in response to the occurrence of a failure at the site K will be described with reference to FIG.
[0058]
Step S31: The control unit 15k of the base K starts a recovery program in response to the damage of the database 12k. By starting the recovery program, the control unit 15k of the site k establishes a communication connection with the site N.
[0059]
Step S32: The control unit 15k of the site K informs the other station log storage unit 16n of the site N of the damage of the database 12k. The other-station log storage unit 16n of the base N selects the base K from the stored log data and returns it to the base K according to this information. The control unit 15k of the base K acquires and temporarily stores the returned log data.
[0060]
Step S33: The control unit 15k of the site K determines whether there is unprocessed log data to be subjected to the recovery process for the log data returned from the site N.
Here, if there is unprocessed log data, the control unit 15k of the base K shifts the operation to step S34 in order to continue the recovery processing.
On the other hand, if all the log data has been restored, the control unit 15k of the site K ends the operation of the restoration process.
[0061]
Step S34: The control unit 15k of the base K reads out the oldest log end date and time (SYORITS) from the unprocessed log data.
[0062]
Step S35: Starting from the read log data, the control unit 15k of the base K traces the transition of USRKEY in the unprocessed log data, and obtains the latest log data related to the USRKEY.
(Specifically, the value of NOWRUSKEY is obtained from the log data of the starting point, and the log data having this value in OLDUSRKEY is searched in the order of the reflection end date and time. When new log data is found, the log data is used as the starting point. , And the same search is repeated again. If no new log data is found in such a repeated search, finally found log data is the latest log data.)
Step S36: The control unit 15k of the base K determines the event flag of the latest log data.
Here, when the event flag is a new registration, update, or insertion after deletion of a drawing, the latest data of the base N is required for restoration. In this case, the control unit 15k of the base K shifts the operation to Step S37.
On the other hand, when the event flag indicates that the drawing has been deleted, it has been deleted even in the database 12k before the damage, so that it can be determined that the data is not to be recovered. In this case, the control unit 15k of the base K shifts the operation to step S33, and shifts to processing of the next log data.
[0063]
Step S37: The control unit 15k of the base K queries the NOWRKEY of the latest log data to the database 12n of the base N, and requests a new record to be operated.
If a new record to be operated is not found at the site N, the control unit 15k of the site K is notified that the record acquisition has failed.
[0064]
Step S38: The control unit 15k of the base K determines whether the acquisition of the new record to be operated has succeeded.
Here, when the acquisition of the new record is successful, the control unit 15k of the base K shifts the operation to step S39 in order to perform update synchronization of the record.
On the other hand, if acquisition of a new record has failed, the control unit 15k of the base K shifts to error processing in step S41.
[0065]
Step S39: The control unit 15k of the base K registers the acquired new record in the database 12k.
[0066]
Step S40: The control unit 15k of the base K determines whether the registration operation of the database 12k is successful.
If the registration fails, the control unit 15k shifts the operation to the error processing in step S41.
On the other hand, if the registration is successful, the control unit 15k returns the operation to step S33, and shifts to the processing of the next log data.
[0067]
Step S41: Here, since the recovery using the log data has failed, the control unit 15k rolls back the operation of the database 12k based on the current log data. After that, the control unit 15k returns the operation to Step S33 in order to proceed to the processing of the next log data.
The recovery process is completed by performing the above-described operation on a series of log data.
[0068]
[Effects of the First Embodiment]
As described above, in the first embodiment, the update synchronization source (the site K in the above description) has the updated log data stored in the update synchronization destination (the site N in the above description).
Therefore, even if data corruption occurs in the update synchronization source, the reflected log data is stored in the update synchronization destination and is safe.
[0069]
Further, at the update synchronization destination, when the database of the update synchronization source is damaged, the stored log data is returned to the update synchronization source. By comparing the log data with the damaged database of the own station, the update synchronization source can accurately determine the state of damage to the database of the own station (identification of a lost record, etc.). In addition, the update synchronization source performs the above-described recovery processing, thereby appropriately acquiring the record that has been deleted by the local station from the update synchronization destination, and recovering the damaged data beta.
[0070]
Furthermore, in the first embodiment, when the reflection of log data at the update synchronization destination is confirmed, the reflected log data is deleted from the update synchronization source. With such a deletion operation, it is possible to avoid problems such as multiplex update synchronization of the same log data.
[0071]
In the first embodiment described above, a plurality of base database devices 11n, 11k, and 11m are constructed with the same configuration. Therefore, there is no need to build a unique system for each site, and system construction costs and maintenance costs can be reduced. Further, since the base database devices 11n, 11k, and 11m having the same configuration are connected, the expandability such as increasing the number of bases is very excellent.
[0072]
In addition, in the above-described first embodiment, the following flexible system operation becomes possible.
[0073]
(Case 1)
With the base N as a key base, the contents of the base K and the base M are reflected on the base N. In this case, a database 12n including the contents of the base K and the base M can be constructed in the core base N. Accordingly, since the base K can obtain the base K and the drawings registered at the base K, the centralized processing such as the formation of a microfilm becomes easy. Further, at the site K (or the site M), the database 12k, which is a subset of the database 12n, can be appropriately restored by tracing the reflected log data of the own station.
[0074]
(Case 2)
The plurality of base database devices 11n, 11k, 11m have the same configuration. Therefore, it is usually easy to operate the base N as a core base and temporarily operate the other base K (or the base M) as a core base when the base N is troubled (for example, at the time of failure or maintenance). Can be.
Next, another embodiment will be described.
[0075]
<< 2nd Embodiment >>
The second embodiment is an embodiment corresponding to

claims

1, 2, 5 to 10, and differs from the first embodiment in the operation at the time of data recovery. The rest is the same as the first embodiment, and the description is omitted here.
FIG. 12 is a flowchart illustrating the recovery processing according to the second embodiment.
Hereinafter, description will be made in the order of step numbers shown in FIG.
[0076]
Step S51: The control unit 15k of the base K establishes a communication connection with the base N in response to the damage of the database 12k. The base N is a base that normally performs update synchronization by tracking the database update of the base K. Therefore, the site N holds the contents of the database of the site K at the time of the previous update synchronization.
[0077]
Step S52: The control unit 15k of the base K instructs the base N to store the log data of the own station (that is, the base K) stored in the other station log storage unit 16n of the base N in the own station log of the base N. Move to section 13n.
By this movement processing, the log data of the site K is simulated as an update synchronization target when viewed from the site K.
[0078]
Step S53: After completion of the preparation described above, the control unit 15k of the base K executes the update synchronization program (for example, FIG. 10).
Here, if all the log data of the site K remains in the site N, no problem occurs in the data recovery by the update synchronization program even if the database in the site K is initialized due to complete damage.
[0079]
If only recent log data remains in the base K, an error occurs when a record that does not exist in the base K is searched or deleted. In this case, the update synchronization program can restore the database at the site K to a recent state by ignoring the error and executing event reflection as much as possible.
In such an operation, if the update synchronization is executed only for the log data of the site K, the data of the site K can be selectively extracted from the database of the site N, and the database of the site K can be appropriately restored. . Such an operation is possible by, for example, an operation of temporarily setting ERRORFLG of the log data at the site N.
In this case, the log data inherent to the site N is not reflected in the database of the site K because the log data is not subject to update synchronization. Therefore, the log data inherent in the base N is not deleted from the own station log accumulation unit 13n. In this case, the ERRORFLG that has been temporarily set is returned to the original position after the data at the site K is restored.
On the other hand, if the log data of the site N is also updated and synchronized, the database recovery of the site K and the update synchronization of the site N can be performed at the same time.
[0080]
[Effects of Second Embodiment, etc.]
As described above, also in the second embodiment, the same effect as in the first embodiment can be obtained.
[0081]
In particular, in the second embodiment, the log data of the own station stored in another station is simulated as an update synchronization target. With such a simulation, it is possible to recover a damaged database by almost the same procedure as that of the update synchronization program.
[0082]
Further, by applying the above-described recovery operation, the log data of another site (here, the site M shown in FIG. 1) is simulated as an update synchronization target, so that the location between the site N and the site K can be changed. With only this, it is possible to extract the database of the site M from the site N. In this extraction operation, there is no need to directly access the database of the site M. Therefore, when the data transfer speed of the site M is low, it becomes a useful duplication or backup means.
[0083]
In addition, by performing the above-described extraction operation several times, it is possible to divide the data of a plurality of sites that have been collected at the site N by the normal update synchronization operation into a database for each site.
[0084]
<< Supplementary information of the embodiment >>
Hereinafter, supplementary items of the first and second embodiments will be described.
Further, in the above-described embodiment, it is preferable that the backup processing unit 31 shown in FIG. 1 is used to perform the backup processing of the update synchronization destination. This backup processing of the update synchronization destination makes it possible to reliably restore the update synchronization destination and to prevent the disappearance of the reflected log data stored in the other-station log storage unit 16n. As a result, the restoration possibility of the update synchronization source can be further ensured.
[0085]
In the above-described embodiment, the case where the drawing data is managed is specifically described. However, the type of data managed by the present invention is not limited to drawing data.
[0086]
In the above-described embodiment, the other-station log storage units are provided in all the base database devices. However, for some base database devices that are not update synchronization destinations, the other-station log storage unit may be omitted.
[0087]
In the above-described embodiment, the data operation of the update synchronization source is collectively reflected on the update synchronization destination. However, the present invention is not limited to this. For example, by selecting log data in the other station log collection unit 14n, it is also possible to reflect only a part of the data operation on the update synchronization destination.
[0088]
In the above-described embodiment, the case has been described in which the base N performs most of the operations in the update synchronization, and the base K performs most of the operations in the recovery operation. However, it is not necessary for either site to take over and execute all of the operations. For example, it is also within the scope of the present invention to delegate all or part of these operations to a partner site. Of course, either the base K or the base N may start the update synchronization or the recovery operation. Further, another base may remotely start the above-described update synchronization or recovery operation.
[0089]
【The invention's effect】
The base database apparatus of the present invention stores reflected log data of another station when updating and synchronizing with another station. Therefore, even if data corruption occurs in another station, the reflected log data that requires data recovery in the other station is stored in the own station and is safe.
Further, by collating the stored reflected log data of the other station with the damaged database of the other station, it is easy to appropriately diagnose the damage situation of the database of the other station.
[0090]
Further, the database cooperation system of the present invention includes a plurality of base database devices having the same configuration. Therefore, it is easy to flexibly exchange the roles of the update synchronization source and the update synchronization destination between these base database apparatuses, and to flexibly increase or decrease the number of base database apparatuses that can perform update synchronization.
[Brief description of the drawings]
FIG. 1 is a diagram showing a configuration of a database cooperation system 20.
FIG. 2 is a diagram showing column definitions of a table A.
FIG. 3 is a diagram showing column definitions of a table B;
FIG. 4 is a diagram showing column definitions of a table C;
FIG. 5 is a diagram showing a column definition of log data.
FIG. 6 is a diagram illustrating an example of log data stored in a local station log storage unit 13n.
FIG. 7 is a diagram illustrating an example of log data stored in a local station log storage unit 13n.
FIG. 8 is a diagram showing a log data rewriting rule.
FIG. 9 is a diagram showing a data flow in update synchronization.
FIG. 10 is a flowchart illustrating an operation procedure of update synchronization.
FIG. 11 is a flowchart illustrating an operation procedure of a recovery process.
FIG. 12 is a flowchart illustrating an operation procedure of a recovery process.
[Explanation of symbols]
11n, 11k, 11m Base database device
12n, 12k database
13n, 13k Own station log storage unit
14n Other station log collection unit
15n, 15k control unit
16n, 16k Other station log storage unit
20 Database Linkage System
21 Communication line
31 Backup processing unit

Claims

A base database device that is arranged at each of a plurality of bases and interconnected via a communication line, thereby constituting a database cooperative system as a whole,
A database that registers and manages data at its own base (hereinafter referred to as “own station”);
Own station log accumulation unit for accumulating data operations of the database in the own station as log data,
Another station log collection unit for acquiring log data accumulated at another base (hereinafter referred to as “other station”);
By tracing the log data obtained by the other station log collection unit, a control unit that reflects the data operation performed by the other station in the database of the own station,
A base station log storage unit for storing the log data of the other station which has been reflected by the control unit;

The base database device according to claim 1,
The own station log accumulation unit,
The base database device, wherein the log data accumulated in the own station is transmitted to the other station, and the log data is deleted after confirming reflection in the other station.

The base database device according to claim 1 or 2,
The other station log storage unit,
The base database apparatus, wherein when the database of the other station is damaged, the log data of the other station to be stored is returned to the other station.

The base database device according to any one of claims 1 to 3,
The control unit includes:
When the database of the own station is damaged, the log data of the own station is returned from the log storage unit of the other station, and the log data of the own station is traced back from the database of the other station. Characterized in that the base station apparatus selectively obtains the data of the base station and restores the database of the own station.

The base database device according to claim 1 or 2,
The other station log storage unit,
The base database device, wherein when the database of the other station is damaged, the log data of the other station to be stored is moved to the own station log storage unit.

The base database device according to any one of claims 1, 2, and 5,
The control unit includes:
When the database of the own station is damaged, the log data of the own station stored in the other station log storage unit of the other station is moved to the own station log storage unit of the other station, so that the log data of the other station is obtained. A base database apparatus for restoring the database of the own station by simulating and executing a process of reflecting a data operation from the other station to the own station.

7. A database cooperation system comprising a plurality of the base database devices according to claim 1 arranged at a plurality of bases and connected via a communication line.

A computer for functioning as the database according to any one of claims 1 to 6, the own station log accumulation unit, the other station log collection unit, the control unit, and the other station log storage unit. Database program.

A data synchronization method for performing update synchronization between databases respectively arranged at a plurality of bases,
Accumulating data operations on the database as log data in the own station;
Obtaining the log data accumulated in another station;
By tracing the log data obtained from the other station, reflecting the data operation performed by the other station in the database of the own station,
Storing the log data of the other station that has been reflected in the own station.

A data recovery method for recovering a damaged database between databases located at multiple sites,
Normally, at the time of update synchronization of another station, transferring the log data of the own station to the other station,
When data is damaged, acquiring log data of the own station being transferred to the other station;
Selecting and acquiring data of the own station from the database of the other station based on the log data acquired from the other station, and restoring the database of the own station. Method.

A data recovery method for recovering a damaged database between databases located at multiple sites,
Normally, at the time of update synchronization of another station, transferring the log data of the own station to another station,
At the time of data corruption, by simulating the log data of the own station being transferred to another station to the log data of the other station, by executing a process of reflecting the data operation from the other station to the own station, Restoring the database of the own station.