(57)【特許請求の範囲】
【請求項１】
データベースを備え、該データベースに含まれるデータの変更要求に応じて該データベースの更新処理を行なう運用系ノード、および前記運用系ノードのデータベースに対応して設けられたデータベースを備える待機系ノードを含み、当該運用系ノードが停止した場合には、当該待機系ノードを新運用系ノードとして切り替えて前記更新処理を再開する二重化システムであって、
前記新運用系ノードは、
前記更新処理が再開されるまでの前記運用系ノードである旧運用系ノードのデータベースに対する変更の履歴を、前記更新処理の再開時点の状態に補正する処理に用いる補正情報を記憶する補正情報記憶手段
を備え、
前記旧運用系ノードは、
前記更新処理が再開されるまでの前記旧運用系ノードのデータベースに対する変更の履歴を記憶する変更履歴記憶手段と、
前記補正情報記憶手段に記憶された前記補正情報に基づいて、前記更新処理の再開時点の状態に、前記変更履歴記憶手段に記憶された変更の履歴を補正する補正手段と、
補正された前記変更の履歴に基づいて、前記旧運用系ノードのデータベースを、前記更新処理の再開時点の状態に復元する復元手段と、
前記旧運用系ノードのデータベースを復元後、前記旧運用系ノードを新待機系ノードとして前記二重化システムに組み込む制御手段と、
を備え
たことを特徴とする二重化システム。
【請求項２】
前記補正手段は、前記変更履歴記憶手段により記憶された変更の履歴と、前記補正情報記憶手段により記憶された前記補正情報とを比較した結果、当該変更の履歴が先行している場合には、当該変更の履歴において先行している箇所を無効化することにより当該変更の履歴を補正する
ことを特徴とする請求項１に記載の二重化システム。
【請求項３】
前記補正手段は、前記変更履歴記憶手段により記憶された変更の履歴と、前記補正情報記憶手段により記憶された前記補正情報とを比較した結果、当該補正情報が先行している場合には、当該補正情報において先行している箇所を当該変更の履歴に補完することにより補正する
ことを特徴とする請求項１に記載の二重化システム。
【請求項４】
前記旧運用系ノードは、
前記復元手段によりデータベースが復元された前記旧運用系ノードを新待機系ノードとして組み込みこんでシステムを再構築する場合に、前記更新処理の再開後システムを再構築するまでに発生した前記新運用系ノードのデータベースに対する変更を前記新待機系ノードのデータベースに反映する反映手段
をさらに備えたことを特徴とする請求項１に記載の二重化システム。
【請求項５】
データベースを備え、該データベースに含まれるデータの変更要求に応じて該データベースの更新処理を行なう運用系ノード、および前記運用系ノードのデータベースに対応して設けられたデータベースを備える待機系ノードを含み、当該運用系ノードが停止した場合には、当該待機系ノードを新運用系ノードとして切り替えて前記更新処理を再開する二重化システムの制御方法であって、
前記運用系ノードである旧運用系ノードが、
前記更新処理が再開されるまでの前記旧運用系ノードのデータベースに対する変更の履歴を、前記更新処理の再開時点の状態に補正する処理に用いる補正情報を前記新運用系ノードが備える補正情報記憶部に記憶させ、
前記更新処理が再開されるまでの前記旧運用系ノードのデータベースに対する変更の履歴を自ノードが備える変更履歴記憶部に記憶させ、
前記補正情報記憶部に記憶された前記補正情報に基づいて、前記更新処理の再開時点の状態に、前記変更履歴記憶部に記憶された変更の履歴を補正し、
前記補正された変更の履歴に基づいて、前記旧運用系ノードのデータベースを、前記更新処理の再開時点の状態に復元し、
前記旧運用系ノードのデータベースを復元後、前記旧運用系ノードを新待機系ノードとして前記二重化システムに組み込む
各処理を実行することを特徴とする制御方法。
【請求項６】
さらに、
前記旧運用系ノードが、
前記変更の履歴を補正する場合に、前記変更履歴記憶部に記憶された変更の履歴と、前記補正情報記憶部に記憶された前記補正情報とを比較した結果、当該変更の履歴が先行している場合には、当該変更の履歴において先行している箇所を無効化することにより当該変更の履歴を補正する
ことを特徴とする請求項５に記載の制御方法。
【請求項７】
さらに、
前記旧運用系ノードが、
前記変更の履歴を補正する場合に、前記変更履歴記憶部に記憶された変更の履歴と、前記補正情報記憶部に記憶された前記補正情報とを比較した結果、当該補正情報が先行している場合には、当該補正情報において先行している箇所を当該変更の履歴に補完することにより補正する
ことを特徴とする請求項５に記載の制御方法。
【請求項８】
さらに、
前記旧運用系ノードが、
データベースが復元された前記旧運用系ノードを新待機系ノードとして組み込みこんでシステムを再構築する場合に、前記新待機系ノードとして、前記更新処理の再開後システムを再構築するまでに発生した前記新運用系ノードのデータベースに対する変更を前記新待機系ノードのデータベースに反映する
ことを特徴とする請求項５に記載の制御方法。
【請求項９】
データベースを備え、該データベースに含まれるデータの変更要求に応じて該データベースの更新処理を行なう運用系ノード、および前記運用系ノードのデータベースに対応して設けられたデータベースを備える待機系ノードを含み、当該運用系ノードが停止した場合には、当該待機系ノードを新運用系ノードとして切り替えて前記更新処理を再開する二重化システムの各ノードとしてのコンピュータに実行させる制御プログラムであって、
前記コンピュータに、
前記新運用系ノードとして、前記更新処理が再開されるまでの前記運用系ノードである旧運用系ノードのデータベースに対する変更の履歴を、前記更新処理の再開時点の状態に補正する処理に用いる補正情報を自ノードが備える補正情報記憶部に記憶させ、
前記旧運用系ノードとして、前記更新処理が再開されるまでの前記旧運用系ノードのデータベースに対する変更の履歴を自ノードが備える変更履歴記憶部に記憶させ、
前記旧運用系ノードとして、前記補正情報記憶部に記憶された前記補正情報に基づいて、前記更新処理の再開時点の状態に、前記変更履歴記憶部に記憶された変更の履歴を補正し、
前記旧運用系ノードとして、前記補正された変更の履歴に基づいて、前記旧運用系ノードのデータベースを、前記更新処理の再開時点の状態に復元し、
前記旧運用系ノードとして、前記旧運用系ノードのデータベースを復元後、前記旧運用系ノードを新待機系ノードとして前記二重化システムに組み込む
各処理を実行させるための制御プログラム。
【請求項１０】
さらに、
前記コンピュータに、
前記変更の履歴を補正する場合に、前記変更履歴記憶部に記憶された変更の履歴と、前記補正情報記憶部に記憶された前記補正情報とを比較した結果、当該変更の履歴が先行している場合には、当該変更の履歴において先行している箇所を無効化することにより当該変更の履歴を補正する
処理を実行させるための請求項９に記載の制御プログラム。
【請求項１１】
さらに、
前記コンピュータに、
前記変更の履歴を補正する場合に、前記変更履歴記記憶部に記憶された変更の履歴と、前記補正情報記憶部に記憶された前記補正情報とを比較した結果、当該補正情報が先行している場合には、当該補正情報において先行している箇所を当該変更の履歴に補完することにより補正する
処理を実行させるための請求項９に記載の制御プログラム。
【請求項１２】
さらに、
前記コンピュータに、
データベースが復元された前記旧運用系ノードを新待機系ノードとして組み込みこんでシステムを再構築する場合に、前記新待機系ノードとして、前記更新処理の再開後システムを再構築するまでに発生した前記新運用系ノードのデータベースに対する変更を前記新待機系ノードのデータベースに反映する
処理を実行させるための請求項９に記載の制御プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
この発明は、二重化システムなどに関する。
【背景技術】
【０００２】
従来より、データベースの絶対的な安定稼動の維持を目的として、ストレージなどの共用部分を持たない完全二重化システムが企業などにより利用されている（例えば、特許文献１参照）。すなわち、この完全二重化システムは、運用ノードと待機ノードとの間でストレージなどの共用部分を持たないので、運用ノードでどのような機器の障害が発生したとしても待機ノードへ切り替えてシステムを再構築することが可能となる。
【０００３】
ところで、この完全二重化システムでは、運用ノードと待機ノードとの間でストレージなどの機器を共有していないため、各ノード内に備えられたデータベースの整合性を合わせた状態で保持している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２００１−３１８８０１号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、上記した従来の完全二重化システムは、システムを再構築する場合にオンライン業務の停止時間が長くなる恐れがあるという問題点があった。
【０００６】
すなわち、完全二重化システムは、障害の発生により一時切り離された旧運用ノードを新待機ノードとして組み込んでシステムを再構築する場合には、新待機ノード内のデータベースと、新運用ノード内のデータベースとの整合性が取れていない恐れがあるので、新運用ノード内のディスクに記録されている全てのデータを、新待機系ノードとしてシステム内に組み込まれる旧運用ノード内のディスクにあらかじめ複写していた。そのため、複写されるデータの規模に比例してオンライン業務の停止時間が長くなる恐れがあるという問題点があった。
【０００７】
また、このようにしてシステムを再構築する場合には、新運用ノード内のディスクに記録されている全てのデータを複写するための退避領域を、待機系ノードとしてシステム内に組み込まれる旧運用ノード内のディスクに確保する必要があるとともに、搬送コストを考慮しなければならない。
【０００８】
そこで、開示の技術は、上述した従来技術の課題を解決するためになされたものであり、障害の発生により一時切り離された旧運用ノードを新待機ノードとして組み込んでシステムを再構築する場合に、オンライン業務の停止時間を無くすことが可能な二重化システムなどを提供することを目的とする。
【課題を解決するための手段】
【０００９】
上述した課題を解決し、目的を達成するため、開示の技術は、データベースを備え、該データベースに含まれるデータの変更要求に応じて該データベースの更新処理を行なう運用系ノード、および前記運用系ノードのデータベースに対応して設けられたデータベースを備える待機系ノードを含み、当該運用系ノードが停止した場合には、当該待機系ノードを新運用系ノードとして切り替えて前記更新処理を再開する二重化システムであって、前記新運用系ノードは、前記更新処理が再開されるまでの前記運用系ノードである旧運用系ノードのデータベースに対する変更の履歴を、前記更新処理の再開時点の状態に補正する処理に用いる補正情報を記憶する補正情報記憶手段を備え、前記旧運用系ノードは、前記更新処理が再開されるまでの前記旧運用系ノードのデータベースに対する変更の履歴を記憶する変更履歴記憶手段と、前記補正情報記憶手段に記憶された前記補正情報に基づいて、前記更新処理の再開時点の状態に、前記変更履歴記憶手段に記憶された変更の履歴を補正する補正手段と、補正された前記変更の履歴に基づいて、前記旧運用系ノードのデータベースを、前記更新処理の再開時点の状態に復元する復元手段と、前記旧運用系ノードのデータベースを復元後、前記旧運用系ノードを新待機系ノードとして前記二重化システムに組み込む制御手段と、を備えたことを特徴とする。
【発明の効果】
【００２１】
開示の技術によれば、オンライン業務が再開されるまでの旧運用系ノード内のデータベースに対する変更の履歴を記憶し（例えば、ユーザからの指示内容やコミットされたデータベースへの変更など、ユーザの要求に応じて実行したオンラインの業務に関する情報をトランザクションごとに記憶する）、記憶されている変更の履歴をオンライン業務の再開時点の状態にまで補正するために用いる変更履歴補正情報を記憶し、変更履歴補正情報を用いて、オンライン業務の再開時点の状態にまで変更の履歴を補正し、補正された変更の履歴に基づいて、オンライン業務の再開時点の状態にまで、旧運用系ノード内のデータベースを復元するので、業務を引き続いて処理する新運用系ノードによるオンライン業務の再開時点の状態まで、旧運用系ノードに備えられたデータベースを簡易な方法で新運用系ノード内のデータベースと等価にする（データの整合性を取る）ことが可能である。また、オンライン業務の再開時点の状態にまでデータベースを簡易な方法で等価にすることが可能である結果、運用系ノードにおける障害の発生に起因したシステムの再構築を実行する場合に、オンライン業務の停止時間を無くすことが可能である。
【００２２】
また、開示の技術によれば、記憶されている変更の履歴と変更履歴補正情報とを比較した結果、変更の履歴に記憶されている情報が先行している場合には、先行している情報を無効化することにより変更の履歴を補正し、変更履歴補正情報に記憶されている情報が先行している場合には、先行している情報を変更の履歴に補完することにより補正するので、変更履歴補正情報を基準とすることで、オンライン業務再開時点の状態にまで、変更の履歴を簡易な方法で補正することが可能である。
【００２３】
また、開示の技術によれば、オンライン業務の再開時点の状態にまでデータベースが復元された旧運用系ノードを新待機系ノードとして組み込みこんでシステムを再構築し、オンライン業務の再開後、システムが再構築されるまでに発生した新運用系ノード内のデータベースに対する変更を新待機系ノード内のデータベースに反映するので、オンライン業務の再開後、システム再構築以前までに新運用系ノード内のデータベースに発生した変更について、漏らさずに新運用形ノード内のデータベースに反映することができ、データベースの冗長化を担保することが可能である。
【図面の簡単な説明】
【００２４】
【図１】図１は、実施例１に係る完全二重化システムの概要および特徴を説明するための図である。
【図２】図２は、実施例１に係る完全二重化システムの概要および特徴を説明するための図である。
【図３】図３は、実施例１に係る完全二重化システムの概要および特徴を説明するための図である。
【図４】図４は、実施例１に係る完全二重化システムの概要および特徴を説明するための図である。
【図５】図５は、実施例１に係る完全二重化システムの概要および特徴を説明するための図である。
【図６】図６は、実施例１に係る完全二重化システムの概要および特徴を説明するための図である。
【図７】図７は、実施例１に係る各ノード構成を示すブロック図である。
【図８】図８は、実施例１に係るリカバリログファイルの補正例を示す図である。
【図９】図９は、実施例１に係るリカバリログファイルの補正例を示す図である。
【図１０】図１０は、実施例１に係る差分ログファイル読込処理の流れを示すフローチャートである。
【図１１】図１１は、実施例１に係るリカバリログファイル読込処理の流れを示すフローチャートである。
【図１２】図１２は、実施例１に係るリカバリログファイル補正処理の流れを示すフローチャートである。
【図１３】図１３は、実施例１に係るシステム再構築処理の流れを示すフローチャートである。
【図１４】図１４は、システム制御プログラムを実行するコンピュータを示す図である。
【発明を実施するための形態】
【００２５】
以下に添付図面を参照して、開示の技術に係る完全二重化システム、システム制御方法およびシステム制御プログラムの実施例を詳細に説明する。なお、以下では、開示の技術に係る完全二重化システムについて実施例１として説明した後に、開示の技術に係る他の実施例を説明する。
【実施例１】
【００２６】
以下の実施例１では、実施例１に係る完全二重化システムの概要および特徴、完全二重化システムを構成する各ノード構成および処理を順に説明し、最後に実施例１による効果を説明する。
【００２７】
［完全二重化システムの概要および特徴（実施例１）］
まず最初に、図１〜図６を用いて、実施例１に係る完全二重化システムの概要および特徴を説明する。図１〜図６は、実施例１に係る完全二重化システムの概要および特徴を説明するための図である。
【００２８】
実施例１に係る完全二重化システムは、ユーザからの要求に応じたオンライン業務を実行する運用ノード、および当該運用ノードをリカバリするための待機ノードを含んで構成され、当該運用ノードに障害が発生した場合には、当該待機ノードを新運用ノードとして切り替えてからオンライン業務を再開することを概要とする。そして、本発明に係る完全二重化システムは、障害の発生により一時切り離された旧運用ノードを新待機ノードとして組み込んでシステムを再構築する場合に、オンライン業務の停止時間を無くすことが可能である点に主たる特徴がある。
【００２９】
まず、実施例１に係る完全二重化システムの通常の運用状態時における処理について説明する。図１に示すように、実施例１に係る完全二重化システムは、ＡＰサーバ１０からの要求に応じたオンライン業務に関する処理を実行する運用ノード２０、および運用ノード２０をリカバリするための待機ノード３０で二重化され、ＡＰサーバ１０とネットワークなどにより通信可能に接続される。
【００３０】
ＡＰサーバ１０には、オンライン業務に対応した業務アプリケーション１１および接続装置１２が含まれる。そして、ＡＰサーバ１０は、ユーザからの操作を受け付けて、その操作内容に応じたオンライン業務に関する要求（例えば、一連の処理単位であるトランザクションの処理要求）を接続装置１２から運用ノード２０に通知する。
【００３１】
運用ノード２０は、ＤＢ（データベース）サーバ２１およびストレージ２２を含んで構成される。このうち、ＤＢサーバ２１は、ストレージ２２に対するアクセス等を管理制御するＤＢＭＳ（ＤａｔａＢａｓｅ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）２１ａと、各ノード（運用ノード２０および待機ノード３０）に備えられたデータベース間の整合性を合わせる（同値性を保証する）ための複製制御装置２１ｂとから構成される。
【００３２】
ストレージ２２は、オンライン業務に関する処理データを記憶するＤＢ（データベース）２２ａと、ユーザからの要求に応じたオンライン業務に関する処理の履歴（例えば、ユーザからの指示内容やコミットされたデータベースへの変更など、ユーザの要求に応じて実行したオンラインの業務に関するトランザクションごとの情報、以下、「リカバリログ」と記す）をファイル形式で記憶するリカバリログ記憶部２２ｂと、運用ノード２０が異常となり、待機ノード３０でオンライン業務を再開した以降にＤＢ３２ａの更新結果をＤＢ２２ａに反映するためのログ（以下、「差分ログ」と記す）をファイル形式で記憶する差分ログ記憶部２２ｃとから構成される。
【００３３】
また、ストレージ３２に配置されている差分ログ記憶部３２ｃは、差分ログ記憶部２２ｃと同様に、通常はＤＢ２２ａの更新結果をＤＢ３２ａに反映するために利用される。さらに、差分ログ記憶部３２ｃは、異常となった運用ノード２０を新たな待機ノードとして組み込むときには、リカバリログ記憶部２２ｂに記憶されているリカバリログを補正するためのログとしても利用される。なお、差分ログには、各ノードに備えられたデータベース間の整合性（同値性）を保証するための情報と、自己のデータベースをリカバリするための情報とを含んで構成されている。
【００３４】
待機ノード３０は、運用ノード２０と同様の構成であり、ＤＢサーバ３１およびストレージ３２から構成される。同様に、ＤＢサーバ３１は、ＤＢＭＳ３１ａおよび複製制御装置３１ｂから構成され、ストレージ３２は、ＤＢ３２ａ、リカバリログ記憶部３２ｂおよび差分ログ記憶部３２ｃとから構成される。
【００３５】
このような構成のもと、通常の運用時において、運用ノード２０のＤＢサーバ２１は、ＡＰサーバ１０から通知されるユーザからの要求に応じたオンライン業務に関する処理を実行するとともに、その処理内容に関するログを取得して、リカバリログ記憶部２２ｂにリカバリログとして格納する（図１の（１）参照）。また、ＤＢサーバ２１は、取得したログを差分ログとして、複製制御装置２１ｂを介して、待機ノード３０における差分ログ記憶部３２ｃに格納する（図１の（２）参照）。さらに、待機ノード３０のＤＢサーバ３１は、差分ログ記憶部３２ｃに記憶されている差分ログの内容についてＤＢＭＳ３１ａに更新依頼を行う。この延長でＤＢＭＳ３１ａおよび複製制御装置３１ｂは、リカバリログ記憶部３２ｂに記憶されているリカバリログに差分ログの内容を反映させるとともに、ＤＢＭＳ３１ａは、リカバリログ記憶部３２ｂに記憶されているリカバリログに基づいてＤＢ３２ａを更新する（図１の（３）参照）。
【００３６】
次に、運用ノードに障害が発生した場合の運用状態について説明する。図２に示すように、運用ノード２０に障害が発生すると、運用ノード２０をシステムから切り離すとともに、待機ノード３０を新運用ノードに切り替える処理を実行する。この場合において、待機ノード３０のＤＢサーバ３１は、差分ログ記憶部３２ｃに記憶されている差分ログの中から、コミットされている（トランザクションの処理が確定している）差分ログの内容についてＤＢＭＳ３１ａに更新依頼を行う。この延長でＤＢＭＳ３１ａおよび複製制御装置３１ｂは、リカバリログ記憶部３２ｂ内のリカバリログに差分ログの内容を反映させるとともに、ＤＢＭＳ３１ａは、リカバリログ記憶部３２ｂに記憶されているリカバリログに基づいてＤＢ３２ａを更新する。
【００３７】
そして、新運用ノード３０’のＤＢサーバ３１’は、図３に示すように、ＡＰサーバ１０から通知されるユーザからの要求に応じたオンライン業務に関する処理を引き継いで実行する前に、その処理内容に関するログを取得した場合には、旧運用ノード２０’のストレージ２２’の差分ログ記憶部２２ｃ’に差分ログとして格納する準備を整える（図３の（１）参照）。その後、新運用ノード３０’のＤＢサーバ３１’は、オンライン業務に関する処理を再開する（図３の（２）参照）。
【００３８】
このようにして、実施例１に係る完全二重化システムは、通常の運用状態および障害発生時の運用状態の処理を実行するが、以下に説明するように、旧運用ノード２０’を新待機ノードとして組み込んでシステムを再構築する場合の処理に主たる特徴がある。
【００３９】
すなわち、図４に示すように、旧運用ノード２０’のＤＢサーバ２１’は、差分ログ記憶部３２ｃ’に記憶されている差分ログを用いて、リカバリログ記憶部２２ｂ’に記憶されているリカバリログを補正する。具体的に説明すると、複製制御装置２１ｂ’およびＤＢＭＳ２１ａ’は、差分ログ記憶部３２ｃ’に記憶されている差分ログファイルの最終通番（以下、「最終差分ログ通番」と記す）と、リカバリログ記憶部２２ｂ’に記憶されているリカバリログファイルの最終通番（以下、「最終リカバリログ通番」と記す）との比較結果に応じて、リカバリログファイルの内容を補正する。
【００４０】
ここで、補正の内容について具体的に説明する。複製制御装置２１ｂ’およびＤＢＭＳ２１ａ’は、最終差分ログ通番と最終リカバリログ通番とを比較した結果、最終差分ログ通番が先行している場合には、リカバリログファイルに記憶されていないログの内容を差分ログファイルから補完することにより、リカバリログファイルの内容を補正する。一方、最終差分ログ通番と最終リカバリログ通番とを比較した結果、最終リカバリログ通番が先行している場合には、リカバリログファイルに記憶されているリカバリログの内、最終差分ログ通番より新しいものを全て無効化する（リカバリログファイルの中から削除する）。なお、最終差分ログ通番と最終リカバリログ通番とが一致する場合には特に補正は行わない。
【００４１】
複製制御装置２１ｂ’およびＤＢＭＳ２１ａ’によりリカバリログファイルの内容が補正された後、旧運用ノード２０’のＤＢＭＳ２１ａ’は、図５に示すように、リカバリログ記憶部２２ｂ’に記憶されている補正されたリカバリログに基づいてＤＢ２２ａ’を更新する。このようにして、旧運用ノード２２’のＤＢ２２ａ’は、障害の発生により、待機ノード３０を新運用ノード３０’に切替えてオンライン業務を再開した場合、ノードを切替えた時点でＤＢ２２ａ‘とＤＢ３２ａ’の内容が不整合な状態になったとしても、オンライン業務再開時の新運用ノード３０’のＤＢ３２ａ’の状態にまで復元される。
【００４２】
そして、実施例１に係る完全二重化システムは、旧運用ノード２０’を新待機ノードとして組み込んでシステムを再構築する。この場合において、ＤＢサーバ２１’は、図６に示すように、新運用ノード３０’によるオンライン業務の再開後システムを再構築するまでに、差分ログ記憶部２２ｃ’に格納された差分ログの内容（業務の再開により新たに発生したＤＢ変更等の処理内容）についてＤＢＭＳ２１ａ’に更新依頼を行う。この延長でＤＢＭＳ２１ａ’および複製制御装置２１ｂ’は、リカバリログ記憶部２２ｂ’に記憶されているリカバリログに差分ログの内容を反映させるとともに、ＤＢＭＳ２１ａ’は、差分ログの内容が反映されたリカバリログ記憶部２２’に記憶されているリカバリログに基づいてＤＢ２２ａ’の更新を開始する。つまり、新運用ノード３０’および旧運用ノード２０’にそれぞれ備えられたＤＢ３２ａとＤＢ２２ａ’との間の整合性を合わせた上で（同値性を保証した上で）、システムを再構築する趣旨である。
【００４３】
このようなことから、実施例１に係る完全二重化システムは、障害の発生により一時切り離された旧運用ノードを新待機ノードとして組み込んでシステムを再構築する場合に、オンライン業務の停止時間を無くすことが可能である。
【００４４】
［各ノードの構成（実施例１）］
次に、図７を用いて、実施例１に係る完全二重化システムを構成する各ノードの構成を説明する。図７は、実施例１に係る各ノード構成を示すブロック図である。なお、同図では、実施例１に係る各ノードを説明する上で密接に関連する処理構成部のみを記載し、その他の処理構成部については記載を省略する。
【００４５】
同図に示すように、実施例１に係る各ノード（運用ノードおよび待機ノード）は、ＤＢサーバおよびストレージを含んで構成される。
【００４６】
このうち、ストレージは、オンライン業務に関するデータおよびプログラムを記憶する。そして、このストレージは、特に本発明に密接に関連するものとして、オンライン業務に関する処理データを記憶するＤＢ（データベース）と、ユーザからの要求に応じたオンライン業務に関する処理の履歴（以下、「リカバリログ」と記す）をファイル形式で記憶するリカバリログ記憶部と、リカバリログ記憶部に記憶されているリカバリログを補正するためのログ（以下、「差分ログ」と記す）をファイル形式で記憶する差分ログ記憶部とを含んで構成される。
【００４７】
ＤＢサーバは、所定の制御プログラム、各種の処理手順などを規定したプログラムおよび所要データを格納するための内部メモリを有し、これらによって種々の処理を実行する。そして、このＤＢサーバは、特に本発明に密接に関連するものとして、ストレージに対するアクセス等を管理制御するＤＢＭＳ（ＤａｔａＢａｓｅ  Ｍａｎａｇｅｍｅｎｔ  Ｓｙｓｔｅｍ）と、各ノード（運用ノードおよび待機ノード）に備えられたデータベース間の整合性を合わせる（同値性を保証する）ための複製制御装置とを含んで構成される。
【００４８】
このうち、複製制御装置は、本発明に密接に関連するものとして、差分ログ読込処理部と、リカバリログ読込処理部と、リカバリログ補正処理部と、差分ログ反映処理部とから構成される。なお、以下では、旧運用ノードを新待機ノードとして組み込む処理において必要とされるリカバリログの補正処理を中心に説明する。
【００４９】
旧運用ノードの差分ログ読込処理部は、新運用ノードの差分ログ記憶部に記憶されている差分ログファイルを順に一つずつ最後まで読み込んだ後、最後の差分ログファイルに付与されている差分ログ通番を最終差分ログ通番として設定して、旧運用ノードのリカバリログ補正処理部に通知する。また、旧運用ノードの差分ログ読込処理部は、旧運用ノードのリカバリログ読込処理部から最終リカバリログ通番を受け付けると、最終リカバリログ通番以降の差分ログファイルを新運用ノードの差分ログ記憶部から順に一つずつ最後まで読み込む。
【００５０】
旧運用ノードのリカバリログ読込処理部は、旧運用ノードのリカバリログ記憶部に記憶されているリカバリログファイルを順に一つずつ最後まで読み込んだ後、最後のリカバリログファイルに付与されているリカバリログ通番を最終リカバリログ通番として設定して、旧運用ノードの差分ログ読込処理部、および旧運用ノードのリカバリログ補正処理部に通知する。
【００５１】
旧運用ノードのリカバリログ補正処理部およびＤＢＭＳは、旧運用ノードの差分ログ読込処理部から受け付けた最終差分ログ通番と、旧運用ノードのリカバリログ読込処理部から受け付けた最終リカバリログ通番とを用いて、旧運用ノードのリカバリログ記憶部に記憶されているリカバリログを補正する。
【００５２】
具体的に説明すると、旧運用ノードのリカバリログ補正処理部およびＤＢＭＳは、最終差分ログ通番および最終リカバリログ通番をそれぞれ受け付けると、最終差分ログ通番と最終リカバリログ通番とを比較して、最終差分ログ通番が先行しているか否か検証する。
【００５３】
検証の結果、最終差分ログ通番が先行している場合には、旧運用ノードのリカバリログ補正処理部およびＤＢＭＳは、先行している差分ログファイルを順に一つずつ読み込む。次に、旧運用ノードのリカバリログ補正処理部およびＤＢＭＳは、読み込んだ差分ログファイルをリカバリログファイルに補完して、リカバリログファイルの内容を補正する（図８参照）。
【００５４】
そして、旧運用ノードのリカバリログ補正処理部およびＤＢＭＳは、読み込んだ差分ログファイルの差分ログ通番が最終差分ログ通番であるか否か判定する。判定の結果、最終差分ログ通番である場合には、旧運用ノードのリカバリログ補正処理部およびＤＢＭＳは、リカバリログファイル補正処理を終了する。これとは反対に、読み込んだ差分ログファイルの差分ログ通番が最終差分ログ通番ではない場合には、旧運用ノードのリカバリログ補正処理部およびＤＢＭＳは、次の差分ログファイルを読み込む。
【００５５】
旧運用ノードのリカバリログ補正処理部およびＤＢＭＳは、最終差分ログ通番と最終リカバリログ通番とを比較した結果、最終リカバリログ通番が先行していない場合には、最終リカバリログ通番が先行しているか否か検証する。検証の結果、最終リカバリログ通番が先行している場合には、旧運用ノードのリカバリログ補正処理部およびＤＢＭＳは、リカバリログファイルに記憶されているリカバリログの内、最終差分ログ通番より新しいものを全て無効化する（リカバリログファイルの中から削除する、図９参照）。これとは反対に、検証の結果、最終リカバリログ通番が先行していない場合（すなわち、最終差分ログ通番と最終リカバリログ通番とが一致する場合）には、旧運用ノードのリカバリログ補正処理部およびＤＢＭＳは、リカバリログファイル補正処理を終了する。
【００５６】
旧運用ノードのＤＢＭＳは、旧運用ノードのリカバリログ補正処理部およびＤＢＭＳによりリカバリログファイルの内容が補正された後、旧運用ノードのリカバリログ記憶部に記憶されている補正されたリカバリログに基づいて、旧運用ノードのＤＢを更新する（図５参照）。このようにして、旧運用ノードのＤＢは、障害の発生により、待機ノードを新運用ノードに切替えてオンライン業務を再開した場合、ノードを切替えた時点でＤＢ間の内容が不整合な状態になったとしても、オンライン業務再開時の新運用ノードのＤＢの状態にまで復元される。
【００５７】
そして、ＤＢサーバからの更新依頼を受け付けて、旧運用ノードの差分ログ反映処理部およびＤＢＭＳは、新運用ノードによるオンライン業務の再開後システムを再構築するまでに、差分ログ記憶部に格納された差分ログの内容（業務の再開により新たに発生したＤＢ変更等の処理内容）をリカバリログ記憶部に記憶されているリカバリログに反映させる。その後、旧運用ノードのＤＢＭＳは、差分ログの内容が反映されたリカバリログに基づいて、旧運用ノードのＤＢの更新を開始する。このようにして、業務の再開により新たに発生した新運用ノードにおけるＤＢ変更等の処理内容を旧運用ノードのＤＢに反映させる。つまり、新運用ノードおよび新待機ノードにそれぞれ備えられたＤＢ間の整合性を合わせた上で（同値性を保証した上で）、システムを再構築する趣旨である。
【００５８】
このようにして、新運用ノードのＤＢと整合性を合わせたＤＢを備える旧運用ノードを新待機ノードとして組み込んでシステムの再構築を完了する。
【００５９】
なお、上述してきた差分ログ読込処理部、リカバリログ読込処理部、リカバリログ補正処理部、およびリカバリログ反映処理部における処理は、効率的に処理が行えるように、それぞれが非同期に行われる。
【００６０】
［各ノードによる処理（実施例１）］
続いて、図１０〜図１４を用いて、実施例１に係る各ノードによる処理を説明する。図１０は、実施例１に係る差分ログファイル読込処理の流れを示すフローチャートであり、図１１は、実施例１に係るリカバリログファイル読込処理の流れを示すフローチャートであり、図１２は、実施例１に係るリカバリログファイル補正処理の流れを示すフローチャートであり、図１３は、実施例１に係るシステム再構築処理の流れを示すフローチャートである。
【００６１】
［ログファイル読込処理（実施例１）］
まず、図１０を用いて、実施例１に係るログファイル読込処理の流れを説明する。
【００６２】
同図に示すように、旧運用ノードの差分ログ読込処理部は、新運用ノードの差分ログ記憶部に記憶されている差分ログファイルを順に一つずつ読み込み（ステップＳ１００１）、読み込んだファイルが最後の差分ログファイルであるか否か確認する（ステップＳ１００２）。確認の結果、読み込んだファイルが最後の差分ログファイルである場合には（ステップＳ１００２肯定）、旧運用ノードの差分ログ読込処理部は、最後の差分ログファイルに付与されている差分ログ通番を最終差分ログ通番として設定して、旧運用ノードのリカバリログ補正処理部に通知する（ステップＳ１００３）。一方、読み込んだファイルが最後の差分ログファイルではない場合には（ステップＳ１００２否定）、旧運用ノードの差分ログ読込処理部は、差分ログ記憶部から次の差分ログファイルを読み込む。
【００６３】
［リカバリログファイル読込処理（実施例１）］
次に、図１１を用いて、実施例１に係るリカバリログファイル読込処理の流れを説明する。
【００６４】
同図に示すように、旧運用ノードのリカバリログ読込処理部は、リカバリログ記憶部に記憶されているリカバリログファイルを順に一つずつ読み込み（ステップＳ１１０１）、読み込んだファイルが最後のリカバリログファイルであるか否か確認する（ステップＳ１１０２）。確認の結果、読み込んだファイルが最後のリカバリログファイルである場合には（ステップＳ１１０２肯定）、旧運用ノードのリカバリログ読込処理部は、最後のリカバリログファイルに付与されているリカバリログ通番を最終リカバリログ通番として設定して、旧運用ノードのリカバリログ補正処理部に通知する（ステップＳ１１０３）。一方、読み込んだファイルが最後のリカバリログファイルではない場合には（ステップＳ１１０２否定）、旧運用ノードのリカバリログ読込処理部は、リカバリログ記憶部から次のリカバリログファイルを読み込む。
【００６５】
［リカバリログファイル補正処理（実施例１）］
続いて、図１２を用いて、実施例１に係るリカバリログファイル補正処理の流れを説明する。
【００６６】
旧運用ノードのリカバリログ補正処理部およびＤＢＭＳは、旧運用ノードの差分ログ読込処理部から受け付けた最終差分ログ通番と、旧運用ノードのリカバリログ読込処理部から受け付けた最終リカバリログ通番とを用いて、旧運用ノードのリカバリログ記憶部に記憶されているリカバリログを補正する。
【００６７】
すなわち、同図に示すように、旧運用ノードのリカバリログ補正処理部およびＤＢＭＳは、最終差分ログ通番および最終リカバリログ通番をそれぞれ受け付けると（ステップＳ１２０１肯定）、最終差分ログ通番と最終リカバリログ通番とを比較して（ステップＳ１２０２）、最終差分ログ通番が先行しているか否か検証する（ステップＳ１２０３）。
【００６８】
検証の結果、最終差分ログ通番が先行している場合には（ステップＳ１２０３肯定）、旧運用ノードのリカバリログ補正処理部およびＤＢＭＳは、先行している差分ログファイルを順に一つずつ読み込む（ステップＳ１２０４）。次に、旧運用ノードのリカバリログ補正処理部およびＤＢＭＳは、読み込んだ差分ログファイルをリカバリログファイルに補完して（ステップＳ１２０５）、リカバリログファイルの内容を補正する（図８参照）。
【００６９】
そして、旧運用ノードのリカバリログ補正処理部およびＤＢＭＳは、読み込んだ差分ログファイルの差分ログ通番が最終差分ログ通番であるか否か判定する（ステップＳ１２０６）。判定の結果、最終差分ログ通番である場合には（ステップＳ１２０６肯定）、旧運用ノードのリカバリログ補正処理部およびＤＢＭＳは、リカバリログファイル補正処理を終了する。これとは反対に、読み込んだ差分ログファイルの差分ログ通番が最終差分ログ通番ではない場合には（ステップＳ１２０６否定）、旧運用ノードのリカバリログ補正処理部およびＤＢＭＳは、次の差分ログファイルを読み込む。
【００７０】
再び、ステップＳ１２０３の説明に戻ると、旧運用ノードのリカバリログ補正処理部およびＤＢＭＳは、最終差分ログ通番と最終リカバリログ通番とを比較した結果、最終リカバリログ通番が先行していない場合には（ステップＳ１２０３否定）、最終リカバリログ通番が先行しているか否か検証する（ステップＳ１２０７）。検証の結果、最終リカバリログ通番が先行している場合には（ステップＳ１２０７肯定）、旧運用ノードのリカバリログ補正処理部およびＤＢＭＳは、リカバリログファイルに記憶されているリカバリログの内、最終差分ログ通番より新しいものを全て無効化する（リカバリログファイルの中から削除する、図９参照）（ステップＳ１２０８）。これとは反対に、検証の結果、最終リカバリログ通番が先行していない場合（すなわち、最終差分ログ通番と最終リカバリログ通番とが一致する場合）には（ステップＳ１２０７否定）、旧運用ノードのリカバリログ補正処理部およびＤＢＭＳは、リカバリログファイル補正処理を終了する。
【００７１】
［システム再構築処理（実施例１）］
最後に、図１３を用いて、実施例１に係るシステム再構築処理の流れを説明する。
【００７２】
同図に示すように、旧運用ノードのＤＢＭＳは、旧運用ノードのリカバリログ補正処理部およびＤＢＭＳによりリカバリログファイルの内容が補正された後、旧運用ノードのリカバリログ記憶部に記憶されている補正されたリカバリログに基づいて、旧運用ノードのＤＢを更新する（ステップＳ１３０１）。このようにして、旧運用ノードのＤＢは、障害の発生により、待機ノードを新運用ノードに切替えてオンライン業務を再開した場合、ノードを切替えた時点でＤＢ２２ａ‘とＤＢ３２ａ’の内容が不整合な状態になったとしても、オンライン業務再開時の新待機ノードのＤＢの状態にまで復元される。
【００７３】
そして、ＤＢサーバからの更新依頼を受け付けて、旧運用ノードの差分ログ反映処理部およびＤＢＭＳは、新運用ノードによるオンライン業務の再開後システムを再構築するまでに、差分ログ記憶部に格納された差分ログの内容（業務の再開により新たに発生したＤＢ変更等の処理内容）をリカバリログ記憶部に記憶されているリカバリログに反映させる。その後、旧運用ノードのＤＢＭＳは、差分ログの内容が反映されたリカバリログに基づいて、旧運用ノードのＤＢの更新を開始する。このようにして、業務の再開により新たに発生した新運用ノードにおけるＤＢ変更等の処理内容を旧運用ノードのＤＢに反映させる。（ステップＳ１３０２）。つまり、新運用ノードおよび旧運用ノードにそれぞれ備えられたＤＢ間の整合性を合わせた上で（同値性を保証した上で）、システムを再構築する趣旨である。
【００７４】
このようにして、新運用ノードのＤＢと整合性を合わせたＤＢを備える旧運用ノードを新待機ノードとして組み込んでシステムの再構築を完了する。
【００７５】
［実施例１による効果］
上述してきたように、実施例１によれば、オンライン業務が再開されるまでの旧運用ノード内のデータベースに対する変更の履歴であるリカバリログを記憶し（例えば、ユーザからの指示内容やコミットされたデータベースへの変更など、ユーザの要求に応じて実行したオンラインの業務に関する情報をトランザクションごとに記憶する）、記憶されているリカバリログをオンライン業務の再開時点の状態にまで補正するために用いる差分ログを記憶し、記憶されている差分ログを用いて、オンライン業務の再開時点の状態にまで、リカバリログを補正し、補正されたリカバリログに基づいて、オンライン業務の再開時点の状態にまで、旧運用系ノード内のデータベースを復元するので、業務を引き続いて処理する新運用系ノードによるオンライン業務の再開時点の状態まで、旧運用系ノードに備えられたデータベースを簡易な方法で新運用系ノード内のデータベースと等価にする（データの整合性を取る）ことが可能である。また、オンライン業務の再開時点の状態にまでデータベースを簡易な方法で等価にすることが可能である結果、運用系ノードにおける障害の発生に起因したシステムの再構築を実行する場合に、オンライン業務の停止時間を無くすことが可能である。
【００７６】
また、実施例１によれば、記憶されているリカバリログと差分ログとを比較した結果、リカバリログに記憶されている情報が先行している場合には、先行している情報を無効化することによりリカバリログを補正し、差分ログに記憶されている情報が先行している場合には、先行している情報をリカバリログに補完することにより補正するので、差分ログを基準とすることで、オンライン業務再開時点の状態にまで、リカバリログを簡易な方法で補正することが可能である。
【００７７】
また、実施例１によれば、オンライン業務の再開時点の状態にまでデータベースが復元された旧運用系ノードを新待機系ノードとして組み込みこんでシステムを再構築する場合に、オンライン業務の再開後、システムが再構築されるまでに発生した新運用系ノード内のデータベースに対する変更を新待機系ノード内のデータベースに反映するので、オンライン業務の再開後、システム再構築以前までに新運用系ノード内のデータベースに発生した変更について、漏らさずに新運用形ノード内のデータベースに反映することができ、データベースの冗長化を担保することが可能である。
【００７８】
また、上記の実施例１では、運用ノードにおいて記憶されているリカバリログを補正するための差分ログを待機ノードにおいて保存する場合を説明したが、本発明はこれに限定されるものではなく、運用ノードにおいて差分ログを保存して待機ノード側に転送するとともに、転送されてきた差分ログを待機ノード側でさらに保存するようにしてもよい。
【００７９】
また、上記の実施例１において、運用ノードでコミット処理を実行した場合に、リカバリログおよび差分ログの書き込みが完了した旨の書き込み確認通知のやり取りや、書き込み完了情報の参照などにより、リカバリログおよび差分ログの書き込み保証を行うようにしてもよく、ノード間の差分転送を同期モードで転送しても、非同期モードで転送してもよい。
【実施例２】
【００８０】
さて、これまで本発明の実施例について説明したが、本発明は上述した実施例以外にも、種々の異なる形態にて実施されてよいものである。そこで、以下では、本発明の含まれる他の実施例を説明する。
【００８１】
（１）装置構成等
図７に示した複製制御装置の各構成要素は機能概念的なものであり、必ずしも物理的に図示の如く構成されていることを要しない。すなわち、各装置の分散・統合の具体的形態は図示のものに限られず、例えば、リカバリログ補正処理部と差分ログ反映処理部とを統合するなど、その全部または一部を、各種の負荷や使用状況などに応じて、任意の単位で機能的または物理的に分散・統合して構成することができる。さらに、複製制御装置にて行なわれる各処理機能は、その全部または任意の一部が、ＣＰＵおよび当該ＣＰＵにて解析実行されるプログラムにて実現され、あるいは、ワイヤードロジックによるハードウェアとして実現され得る。
【００８２】
（２）システム制御プログラム
ところで、上記の実施例で説明した各種の処理（例えば、図１３および図１４参照）は、あらかじめ用意されたプログラムをパーソナルコンピュータやワークステーションなどのコンピュータシステムで実行することによって実現することができる。そこで、以下では、図１５を用いて、上記の実施例と同様の機能を有するシステム制御プログラムを実行するコンピュータの一例を説明する。図１５は、システム制御プログラムを実行するコンピュータを示す図である。
【００８３】
同図に示すように、複製制御装置としてコンピュータ４０は、通信制御Ｉ／Ｆ部４１、ＨＤＤ４２、ＲＡＭ４３、ＲＯＭ４４およびＣＰＵ４５をバス５０で接続して構成される。
【００８４】
そして、ＲＯＭ４４には、上記の実施例に示した複製制御装置と同様の機能を発揮するシステム制御プログラム、つまり、図１５に示すように、リカバリログファイル読込処理プログラム４４ａ、差分ログファイル読込処理プログラム４４ｂ、リカバリログファイル補正処理プログラム４４ｃおよび差分ログファイル反映処理プログラム４４ｄがあらかじめ記憶されている。なお、これらのプログラム４４ａ、４４ｂ、４４ｃおよび４４ｄについては、図７に示した複製制御装置の各構成要素と同様、適宜統合または分散してもよい。なお、ＲＯＭ４４は、不揮発性の「ＲＡＭ」でもよい。
【００８５】
そして、ＣＰＵ４５が、これらのプログラム４４ａ、４４ｂ、４４ｃおよび４４ｄをＲＯＭ４４から読み出して実行することで、図１５に示すように、各プログラム４４ａ、４４ｂ、４４ｃおよび４４ｄは、リカバリログファイル読込処理プロセス４５ａ、差分ログファイル読込処理プロセス４５ｂ、リカバリログファイル補正処理プロセス４５ｃおよび差分ログファイル反映処理プロセス４５ｄとして機能するようになる。なお、各プロセス４５ａ、４５ｂ、４５ｃおよび４５ｄは、図７に示した複製制御装置のリカバリログ読込処理部、差分ログ読込処理部、リカバリログ補正処理部および差分ログ反映処理部にそれぞれ対応する。
【００８６】
また、ＨＤＤ４２には、図１５に示すように、リカバリログファイルデータテーブル４２ａ、差分ログファイルデータテーブル４２ｂおよびデータベースデータテーブル４２ｃがそれぞれ設けられる。なお、リカバリログファイルデータテーブル４２ａ、差分ログファイルデータテーブル４２ｂおよびデータベースデータテーブル４２ｃは、図７に示したリカバリログ記憶部、差分ログ記憶部およびＤＢにそれぞれ対応する。そして、ＣＰＵ４５は、リカバリログファイルデータテーブル４２ａ、差分ログファイルデータテーブル４２ｂおよびデータベースデータテーブル４２ｃから、リカバリログファイルデータ４３ａ、差分ログファイルデータ４３ｂおよびデータベースデータ４３ｃをそれぞれ読み出してＲＡＭ４３に格納し、ＲＡＭ４３に格納されたリカバリログファイルデータ４３ａ、差分ログファイルデータ４３ｂおよびデータベースデータ４３ｃに基づいて処理を実行する。
【００８７】
なお、上記した各プログラム４４ａ、４４ｂ、４４ｃおよび４４ｄについては、必ずしも最初からＲＯＭ４４に記憶させておく必要はなく、例えば、コンピュータ４０に挿入されるフレキシブルディスク（ＦＤ）、ＣＤ−ＲＯＭ、ＤＶＤディスク、光磁気ディスク、ＩＣカードなどの「可搬用の物理媒体」、または、コンピュータ４０の内外に備えられるＨＤＤなどの「固定用の物理媒体」、さらには、公衆回線、インターネット、ＬＡＮ、ＷＡＮなどを介してコンピュータ４０に接続される「他のコンピュータ（またはサーバ）」などに各プログラムを記憶させておき、コンピュータ４０がこれらから各プログラムを読み出して実行するようにしてもよい。
【産業上の利用可能性】
【００８８】
以上のように、開示の技術に係る完全二重化システム、システム制御方法およびシステム制御プログラムは、ユーザからの要求に応じたオンライン業務を実行する運用ノード、および当該運用ノードをリカバリするための待機ノードを含んで構成され、当該運用ノードに障害が発生した場合には、当該待機ノードを新運用ノードとして切り替えてからオンライン業務を再開する場合に有用であり、特に、障害の発生により一時切り離された旧運用ノードを新待機ノードとして組み込んでシステムを再構築する場合に、オンライン業務の停止時間を短くすることに適する。
【符号の説明】
【００８９】
１０  ＡＰサーバ
１１  業務アプリケーション
１２  接続装置
２０  運用ノード
２１  ＤＢサーバ
２１ａ  ＤＢＭＳ
２１ｂ  複製制御装置
２２  ストレージ
２２ａ  ＤＢ
２２ｂ  リカバリログ記憶部
２２ｃ  差分ログ記憶部
３０  待機ノード
３１  ＤＢサーバ
３１ａ  ＤＢＭＳ
３１ｂ  複製制御装置
３２  ストレージ
３２ａ  ＤＢ
３２ｂ  リカバリログ記憶部
３２ｃ  差分ログ記憶部
４０  コンピュータ
４１  通信制御Ｉ／Ｆ部
４２  ＨＤＤ（Hard  Disk  Drive）
４３  ＲＡＭ（Random  Access  Memory）
４４  ＲＯＭ（Read  Only  Memory）
４５  ＣＰＵ（Central  Processing  Unit）
５０  バス  
【図１】
0005488681.tif 000002
【図２】
0005488681.tif 000003
【図３】
0005488681.tif 000004
【図４】
0005488681.tif 000005
【図５】
0005488681.tif 000006
【図６】
0005488681.tif 000007
【図７】
0005488681.tif 000008
【図８】
0005488681.tif 000009
【図９】
0005488681.tif 000010
【図１０】
0005488681.tif 000011
【図１１】
0005488681.tif 000012
【図１２】
0005488681.tif 000013
【図１３】
0005488681.tif 000014
【図１４】
0005488681.tif 000015