JP2008226088A - ディザスタリカバリシステムおよび方法 - Google Patents

Abstract

【課題】機器コストの削減と運用の容易化を実現することができるＤＲ技術を提供する。
【解決手段】ＤＲシステムにおいて、機器コストの面では、検索を行わない場合には、安価なＤＢアプライアンスサーバ４００でのログ回復が可能な物理適用を採用する。さらに、副サイトでのローカルミラー運用は行わないことにする。また、運用の面では、ログ適用機能部１４１でログ適用や業務の傾向をモニタリングしておき、検索処理はログ適用の進捗状況に応じて受け付ける。副サイトのログ適用が十分に追いついていない場合には検索を受け付けないことにする。さらに、副ＤＢの整合性保証を行う場合には、検索指示時点で仕掛かり中となっているＴｒをｕｎｄｏするのではなく、検索指示時点で仕掛かり中のＴｒだけを対象にｒｅｄｏする。
【選択図】図１

Description

本発明は、ディザスタリカバリ（ＤＲ：Ｄｉｓａｓｔｅｒ Ｒｅｃｏｖｅｒｙ）技術に関し、特に、副サイトのログ適用機能と検索機能に適用して有効な技術に関する。

本発明者が検討したところによれば、ＤＲ技術に関しては、以下のような技術が考えられる。ＤＲは遠隔バックアップシステムであり、正サイトで更新した情報を、遠隔地に設置された副サイトに複製する。ＤＲ方式としては、ストレージのリモートコピー機能を用いた方式が知られている。この方式では、正サイトでストレージに書き込まれたデータは、サーバリソースを使うことなくリモートコピー機能により副ストレージに複製される。地震などの広域災害を想定した都市間のＤＲシステムの場合は、正ストレージはＷＡＮを介して数百ｋｍ離れた遠隔地に設置される副ストレージに接続する必要がある。

正サイトの計算機では、ＤＢＭＳ（Ｄａｔａｂａｓｅ Ｍａｎａｇｅｍｅｎｔ Ｓｙｓｔｅｍ）が稼動する。ＤＢＭＳはクライアント上のユーザＡＰ（Ａｐｐｌｉｃａｔｉｏｎ）からの問い合わせに応じて、ストレージ内のＤＢに格納されるデータを参照、あるいは、更新する。ここで、ＤＢＭＳでは性能向上を実現するために、更新はメモリ上のバッファで行い、ストレージへは別のタイミングで書き出す。ただし、信頼性向上のために、更新差分であるログについては、コミットのタイミングでストレージのログＶＯＬへ同期で書き込みを行う。

サイト間が数百ｋｍ以上となるＤＲシステムでは、回線部（ネットワーク部）の構築、維持コストが大きくなる。特に、数百ｋｍに及ぶ広帯域幅回線の維持には、非常に多くのコストを要するため、コスト削減を行うためには、狭帯域幅回線でＤＲを実現することが必要となる。そこで、ＤＢＭＳのログだけを転送し、ＤＢ本体は、副サイトでログ適用することで複製を行うログベースのＤＲ方式が知られている。ログベースのＤＲ方式では、副サイトの計算機では、リモートコピーで転送されたログを読み込んで、読み込んだログをＤＢに適用するログ適用部が動作する。

ところで、前記のようなＤＲシステムに関して、本発明者が検討した結果、以下のようなことが明らかとなった。ＤＲシステムでは、将来の災害に備えて、平常時から副サイトの機器・運用コストを負担しなければならない。そのため、ＲＯＩ（Ｒｅｔｕｒｎ ｏｆ Ｉｎｖｅｓｔｍｅｎｔ）向上のために、副サイトのリソースをバックアップ専用ではなく、平常時から有効利用したいという要望が生じてきている。有効利用法としては、例えば、副ＤＢを検索・分析業務に利用することが考えられる。あるいは、副ＤＢの参照を可能とすることで、正サイトでのオペレーションミスへの対応（正サイトで誤って消してしまったデータを副サイトから復帰させる）も考えられる。

副サイトで行うログ適用の方式としては、物理適用と論理適用が知られている。物理適用では、通常のクラッシュリカバリで用いられる方式であり、読み込んだログをそのまま適用する。一方、論理適用では、読み込んだログをＳＱＬに変換した後、そのＳＱＬを実行することでＤＢを回復する。以下において、図１４および図１５を用いて、ログ適用の方式とその問題点を説明する。図１４（ａ）は従来方式１（物理適用＋ローカルミラー運用）、図１４（ｂ）は従来方式２（論理適用）をそれぞれ示す。図１５（ａ）、（ｂ）は検索実行のための副ＤＢの整合性保証処理（開始時、終了時）、図１５（ｃ）はログ適用再開時の処理をそれぞれ示す。

（１）従来方式１とその問題点
図１４（ａ）に示す従来方式１は、物理適用でＤＢを回復し、副ストレージではローカルミラー運用を実施する。すなわち、ログ適用を実施中は、副ＤＢ１２３と副ＤＢ’２０１を同期状態にしておき、検索を行う時だけ副ＤＢ１２３（副ＤＢ’２０１）をＴｒ（トランザクション）整合性のとれる状態にした後、両者を切断状態にする。検索実行時は、検索機能部２００は副ＤＢ’２０１を使うため、副ＤＢ１２３を用いるログ適用機能部１４１は停止することなく処理を続けることができる。

副ＤＢ１２３（副ＤＢ’２０１）を整合性のとれた状態にする時の処理方法について、図１５を用いて説明する。図１５（ａ）の状態で整合性のとれた状態にするように指示があった場合（検索実施の要求があった場合）には、まず、仕掛かり中のＴｒ３０３，３０４に関するログについてキャンセル処理（ｕｎｄｏ）を行って、図１５（ｂ）の状態にする必要がある。ｕｎｄｏ実施後の状態は、Ｔｒ（３１３，３１４）で示す。このｕｎｄｏ処理自身も、副ＤＢへの更新とみなされるため、別途、ログを生成して記録しておかなければならない。この処理は、正サイトでは行わなかった、副サイト独自の処理となる。また、図１５（ｃ）に示すように、検索処理を停止してログ適用を再開するためには、ｕｎｄｏした処理をやり直さなければならず、処理・運用が煩雑となってしまう。すなわち、整合性保証処理の開始時点ｔ１（３０６）ではなく、仕掛かり中のＴｒ３０３と３０４の中で、最も古いＴｒ３０４の開始時点ｔ０（３０５）からやり直す必要がある。また、従来方式１は、検索実行時にはローカルミラー運用が必要となるため、処理・運用が煩雑となる。さらに、副ストレージの容量が２倍だけ必要となり、機器コストが上昇してしまうという問題点もある。

（２）従来方式２とその問題点
図１４（ｂ）の従来方式２では、論理適用により副ＤＢ１２３を回復する。論理適用が用いられる場合には、ログ回復、検索ともＳＱＬ発行となるため、両者は同時並行的に実行できる。しかし、論理適用は、ＳＱＬ変換・発行コストが加わるため、物理適用に比べると適用速度が劣り、また、ＣＰＵ負荷も高くなってしまう。そのため、常時的に検索を行わない場合にも、処理能力の高い高価なハード（副ＤＢサーバ／検索サーバ）を備えておく必要がある。また、物理適用に比べるとログ適用のスピードも劣るため、副サイトで未適用なログが正サイトのログ出力で上書きされてしまう（ラップラウンドする）可能性も高くなる。ラップラウンドが生じた場合は、アーカイブログの転送・適用といった新たな運用を行う必要があり、正サイトの運用にも問題が生じる可能性がある。

以上から、従来方式１，２には次のような問題点がある。

（１）機器コスト
（１−１）論理適用は、物理適用に比べるとＣＰＵ負荷が高くなるため、検索を行わない場合にも、ログ回復のために処理速度の速い高価なサーバを用意しておく必要がある。（１−２）物理適用でローカルミラー運用を行う場合には、副ストレージに２倍の容量のドライブを用意しておく必要があり、機器コストが上昇する。

（２）運用コスト
（２−１）論理適用は適用速度が遅いため、副サイトで未適用なログがラップラウンドされてしまう可能性が高くなる。（２−２）副サイトで検索を行うためには、副ＤＢをＴｒ整合性のとれた状態にする必要がある。整合性のとれた状態にするためには、未決着Ｔｒをｕｎｄｏするが、このｕｎｄｏで生じた更新に対しても、更新ログの記録が必要となる。また、検索を終了し、ログ適用を再開する場合には、ログ適用を停止したポイントではなく、未決着Ｔｒの中で最も古いＴｒが発行された時点からやり直さなければならず、処理が煩雑となってしまう。

そこで、本発明の目的は、これらの問題点を解決して、機器コストの削減と運用の容易化を実現することができるＤＲ技術を提供することにある。

本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。

本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、次のとおりである。

本発明では、前記目的を達成するために、以下の方針でＤＲ技術を実現する。

（１）機器コスト削減
（１−１）サーバコスト削減のために、検索を行わない場合には、安価なアプライアンスサーバでのログ回復が可能な物理適用を採用する。（１−２）ストレージコスト削減のために、副サイトでのローカルミラー運用は行わないことで、副ストレージの容量を削減する。

（２）運用容易化
（２−１）ログ適用や業務の傾向をモニタリングしておき、検索処理はログ適用の進捗状況に応じて受け付ける。副サイトのログ適用が十分に追いついていない場合には検索を受け付けないことで、ログがラップラウンドする可能性を低減する。（２−２）副ＤＢの整合性保証を行う場合には、検索指示時点で仕掛かり中となっているＴｒをｕｎｄｏするのではなく、検索指示時点で仕掛かり中のＴｒだけを対象にｒｅｄｏする。これにより、ｕｎｄｏによる更新ログの生成・管理が不要となり、さらに、ログ適用再開時には検索指示時点からやり直せばよいので運用が容易になる。

すなわち、本発明は、正サイトのＤＢＭＳのログをストレージのリモートコピーで副サイトに転送し、副サイトでログ適用を行うログベースのＤＲシステムに適用され、副サイトでは、ログ適用処理を行うログ適用機能部と、検索処理を行う検索機能部が副ストレージに接続されており、ログ適用機能部は、ログ適用の進捗を監視しており、検索機能部からの検索要求があった場合には、監視しているログ適用の進捗に応じて検索機能部への切替えを行うＤＲ方法を特徴とするものである。特に、このＤＲシステムにおいて、ログ適用機能部はアプライアンスサーバに構築され、検索機能部は検索サーバに構築されている。

本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。

本発明によれば、機器コストの削減と運用の容易化を実現することができるＤＲ技術を提供することができる。

＜実施の形態の概要＞
本発明の実施の形態におけるＤＲシステムは、処理が高速な物理適用を採用し、ログ適用機能は安価なアプライアンスサーバで動作させる。検索機能は、別途、サーバを用意する。ログ適用とはサーバリソースを分けることで、検索処理がログ回復に与える影響を最小限にすることができる。ここで、副サイトでの検索向けのサーバは、実行する検索処理の負荷に応じたものを用意すればよく、定常的に重い検索を行うのでなければ、他の業務サーバとサーバを共有することも可能である。あるいは、検索処理の負荷が低いことが予め分かっているならば、ログ適用機能は、検索サーバで動作させることもできる。

副ストレージでは、容量削減のために、ローカルミラー運用は行わない。そのため、検索を行う場合には、ログ適用機能が副ＤＢをＴｒ整合性のとれた状態にした後、ログ適用を中断し、検索機能に副ＤＢを引き継ぐ。ログ適用中は検索を実施することはできないが、ログ適用処理が並列化などによって高速化が図られており、正サイトの業務に対して十分に高速であるならば、検索処理に多くの時間を割り当てることができる。検索を行う場合には、まず、ログ適用機能で検索可否を判定する。すなわち、平常時から正サイトの業務、副サイトのログ適用の性能をモニタリングしておき、ログ適用が十分に追いついている時にのみ、検索業務を受け付けることとする。

以下において、前記実施の形態の概要に基づいた、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一の部材には原則として同一の符号を付し、その繰り返しの説明は省略する。

＜実施の形態１＞
図１により、本発明の実施の形態１におけるＤＲシステムの構成の一例を説明する。図１は、ＤＲシステムの構成を示す図である。

本実施の形態のＤＲシステムは、正サイトと、副サイトから構成される。正サイトは、ＤＢＭＳが稼動する計算機からなる正ＤＢサーバ１００と、この正ＤＢサーバ１００に接続され、ＤＢＭＳのログファイルとＤＢファイルが保存される正ストレージ１１０から構成される。副サイトは、ログ適用機能が稼動する計算機からなるＤＢアプライアンスサーバ４００と、検索機能が稼働する計算機からなる検索サーバ４１０と、これらのＤＢアプライアンスサーバ４００および検索サーバ４１０に接続され、ＤＢＭＳのログファイルとＤＢファイルが保存される副ストレージ１２０から構成される。

正サイトの正ストレージ１１０と副サイトの副ストレージ１２０とはネットワーク（ＷＡＮ）１６０を通じて接続され、正サイトのＤＢＭＳのログがストレージのリモートコピーで副サイトに転送され、副サイトでログ適用が行われ、このログ適用で複製されたデータが副ストレージ１２０に格納される。また、正サイトの正ＤＢサーバ１００および副サイトの検索サーバ４１０は、ネットワーク１６０を通じてクライアント１５０に接続されている。

正サイトにおいて、正ＤＢサーバ１００では、ＤＢＭＳ１０１が稼働し、このＤＢＭＳ１０１には、ログ管理部１０２、Ｔｒ制御部１０３、ＤＢ管理部１０４が設けられている。正サイトの正ストレージ１１０には、ディスク制御処理部１１１、ログＶＯＬ（Ｌｏｇ）１１２、正ＤＢ（ＤＢ）１１３が設けられている。

副サイトにおいて、ＤＢアプライアンスサーバ４００では、ログ適用処理を行うログ適用機能部１４１が稼働し、このログ適用機能部１４１には、判定部４０１、ログ入力部４０２、Ｔｒ管理部４０３、適用部４０４が設けられている。副サイトの検索サーバ４１０では、検索処理を行う検索機能部１５１が稼働し、この検索機能部１５１には、制御部４１１、検索部４１２が設けられている。副サイトの副ストレージ１２０には、ディスク制御処理部１２１、ログＶＯＬ（Ｌｏｇ）１２２、副ＤＢ（ＤＢ）１２３が設けられている。

以上のように構成されるＤＲシステムにおいて、特に、ＤＢアプライアンスサーバ４００のログ適用機能部１４１、検索サーバ４１０の検索機能部１５１は、以下のような特徴を有している。

（ログ適用機能部）
ログ適用機能部１４１は、ログ入力部４０２、Ｔｒ管理部４０３、適用部４０４、および判定部４０１からなる。

ログ入力部４０２は、ログＶＯＬ１２２を監視し、正サイトから転送されるログを連続的に受信し、適用部４０４に適用を指示する。適用部４０４はログの適用を行い、Ｔｒ管理部４０３は適用部４０４と連携してＴｒの実行状態を管理する。判定部４０１は、ログ適用と検索処理の切替えをコントロールする部位であり、平常時から正サイトの業務やログ適用をモニタリングし、ログ適用の進捗に応じて、検索処理の実行可否を判定する。すなわち、判定部４０１は、検索機能部１５１からの検索要求に対して、検索実行の可否を決定し、ログ適用が十分に追いついており、問題がなければ副ＤＢ１２３の制御権を検索機能部１５１へ切替える。

検索処理の実行を許可する場合には、副ＤＢ１２３を整合性のとれる状態にした後、副ＤＢ１２３の制御権を検索機能部１５１に切替える。本方式での副ＤＢ１２３の整合性保証方式を図２を用いて説明する。従来方式（図２（ａ））では、時点ｔ１（３０６）に検索開始指示を受けると、最初にその時点ｔ１（３０６）で未決着なＴｒ５００，５０１を把握し、そのＴｒをｕｎｄｏすることで副ＤＢ１２３を整合性のとれる状態にしていた。検索処理が終了してログ適用を再開する場合には、ｕｎｄｏしたＴｒを再実行しなければならず、ｕｎｄｏしたＴｒの中で最も古いＴｒ５０１から、すなわち、時点ｔ０（３０５）からやり直さなければならなかった。なお、３００〜３０２は決着したＴｒである。

それに対して、本方式（図２（ｂ））では、検索開始指示時点ｔ１（３０６）で未決着なＴｔだけをｒｅｄｏする。すなわち、時点ｔ１（３０６）で検索開始指示を受けると、未決着Ｔｒ５００，５０１を把握し、そのＴｒに関するログのみをｒｅｄｏする。ｒｅｄｏを行って決着した状態は、Ｔｒ（５１０，５１１）で示す。検索処理を終了して、ログ適用を再開する場合には、時点ｔ１（３０６）からログ適用をやり直せばよい。本方式は、従来方式に比べると、ｕｎｄｏ処理を行わないため、ｕｎｄｏによって加えた更新に対する更新ログを記憶しておく必要がない、及び、適用停止ポイントと適用再開ポイントが同一となるため処理や運用が容易になるというメリットがある。

（検索機能部）
検索サーバ４１０では検索機能部１５１が動作し、検索機能部１５１は、制御部４１１と検索部４１２から構成される。制御部４１１は、ユーザやＡＰからの検索要求を受け付け、要求があった場合には、ログ適用機能部１４１の判定部４０１に検索要求を発行する。そして、検索要求が許可された時にのみ、検索部４１２に検索処理の実行を指示する。

以下において、ログ適用機能部１４１のログ入力部４０２、Ｔｒ管理部４０３、適用部４０４、および判定部４０１、検索サーバ４１０の制御部４１１および検索部４１２を詳細に説明する。

（ログ入力部）
ログ入力部４０２は、判定部４０１から開始指示／中断指示を受け付ける。開始指示を受けた以降は、ログを読み込み、読み込んだログの適用を適用部４０４に指示する。一方、中断指示を受けた場合には、副ＤＢ１２３を整合性のとれる状態にした後、再び開始指示が入力されるまで待機する。

ログ入力部４０２の動作フローを図３に示す。ログ入力部４０２は、ステップ６０１にて判定部４０１からの指示を解析し、それが開始指示であった場合（Ｙ）には、ログＶＯＬ１２２からログを入力し（ステップ６０２）、入力したログの適用を適用部４０４に指示する（ステップ６０３）。ログ入力部４０２は、ステップ６０４にて判定部４０１からの指示を解析し、指示が中断要求であった場合（Ｙ）には、副ＤＢ１２３を整合性のとれた状態にした後、次の開始指示が発せられるまで待機状態に入る。

すなわち、ログ入力部４０２は、最初にログを入力し（ステップ６０５）、次にＴｒ管理部４０３に問い合わせを行い、現在、仕掛かり中の未決着のＴｒに関するリスト（ＴｒのＩＤ）を取得する（ステップ６０６）。続いて、ログ入力部４０２は、未決着のＴｒのＩＤを元に、ログバッファから該Ｔｒに関する更新ログのみを抽出し（ステップ６０７）、その更新ログの適用を適用部４０４に指示する（ステップ６０８）。ログ入力部４０２は、適用が完了したら、次の開始要求が来るまで待機状態となる。

（Ｔｒ管理部）
Ｔｒ管理部４０３はＴｒの実行状況、すなわち、決着したか否かを管理する。これは、例えば、管理テーブルを用意し、あるＴｒのログを初めて読み込んだ時に、そのＴｒの状態を管理テーブルに挿入し、そのＴｒをコミットするログを入力した時に以前に挿入した行を削除すればよい。その結果、管理テーブルにはその時点で未決着なＴｒの情報を記録しておくことができる。

（適用部）
適用部４０４は、ログ入力部４０２が読み込んだログを適用する。

（判定部）
判定部４０１は、検索機能部１５１からの要求を受けると、ログ適用の進捗状況に応じて検索処理の実行可否を判定し、検索実行可の場合には副ＤＢ１２３を整合性のとれた状態にした後、検索機能部１５１への切替えを行う。さらに、予め、ログ適用を停止可能な時間、あるいは、検索処理を実行可能な時間である中断時間の計算を行い、その時間が経過した時、あるいは、検索機能部１５１から検索完了が通知された時には、検索処理を停止させ、中断していたログ適用を再開させる。

判定部４０１の動作フローを図４に示す。判定部４０１は、ログ入力部４０２に開始を指示した後（ステップ８００）、ステップ８０２にて制御部４１１からの指示を解析し、それが副サイトの検索機能部１５１からの検索要求があった場合（Ｙ）には、ステップ８０３にて最初にログ適用の進捗状況を計算し、受け付け可否を判定する（ステップ８０４）。

この検索可否の判定は、例えば、適用遅延率を計算することで行う。図５（ａ）に検索可否判定のイメージ図を示す。図中央のｂｏｘはログファイル７００を表し、Ｐ_ＤＢは、正サイトのＤＢＭＳ１０１が生成した最新ログへのポインタ７０１を表し、Ｐ_ｌｏｇは副サイトのログ適用機能部１４１が適用した最新ログへのポインタ７０２を表す。このログファイル７００のサイズがＬＳＺである時に、遅延率（Ｒｄｅｌａｙ）を例えば以下の式で計算する。

Ｒｄｅｌａｙ＝（Ｐ_ＤＢ−Ｐ_ｌｏｇ）／ＬＳＺ
判定部４０１は、この遅延率が、事前に設定しておいた閾値（Ｃ１）より小さかった時（Ｙ）にのみ、十分に追いついているとし、検索を受け付けることとする。遅延率がＣ１を超過した場合（Ｎ）には、副サイトの制御部４１１に拒否通知を送信する（ステップ８０５）。

ＤＢ管理者はこのＣ１の値を変更することで、検索可否の条件をコントロールすることができる。このコントロール方法としては、時間で与えておくこともできる。例えば、遅れがＤ時間以内であるＤＢを検索対象としたい条件を与えたければ、ログの遅れ（Ｐ_ＤＢ−Ｐ_ｌｏｇ）を正サイトのログ出力速度（Ｖ_ＤＢ）で除した値がＤ以下であることを検索受け付けの条件とすればよい。

判定部４０１は、検索を受け付ける場合には、最初に、ログ入力部４０２に中断を指示する（ステップ８０７）。ログ入力部４０２は中断指示を受けて、副ＤＢ１２３を整合性のとれる状態に回復する。判定部４０１は、副ＤＢ１２３の回復が完了したら、副ＤＢ１２３をｕｎｍｏｕｎｔし（ステップ８０８）、副サイトの制御部４１１に検索要求に対する許可通知を通信する（ステップ８０９）。

次に、判定部４０１は、ステップ８１０にてログ適用の中断時間（Ｔｓｕｓｐｅｎｄ）を計算する。中断時間の計算例の考え方を図５（ｂ）に示す。図５（ａ）の状態で検索要求が受け付けられているとする。この間（検索処理の実行中）、正サイトでは業務が進んで、ポインタ７１１はＰ_ＤＢ’となる。この時、Ｐ_ＤＢ’−Ｐ_ｌｏｇがログ適用の遅れとなる。この遅れに対して、許容量を事前に定めておき、遅れが許容量に達する時にログ適用を中断する。

Ｐ_ＤＢ’−Ｐ_ｌｏｇ＜＝Ｃｍａｘ×ＬＳＺ
（Ｐ_ＤＢ＋Ｖ_ＤＢ×Ｔｓｕｓｐｅｎｄ−Ｐ_ｌｏｇ）＜＝Ｃｍａｘ×ＬＳＺ
Ｔｓｕｓｐｅｎｄ＜＝（Ｃｍａｘ×ＬＳＺ＋Ｐ_ｌｏｇ−Ｐ_ＤＢ）／Ｖ_ＤＢ
但し、Ｃｍａｘ：最大許容遅延率、Ｖ_ＤＢ：正サイトの業務のログ生成速度。

中断時間だけｓｌｅｅｐ後、判定部４０１は、ステップ８１１にて制御部４１１に中断完を通知後、検索処理の停止が確認後にログ入力部４０２に開始を指示し、ログ適用処理を再開する。

なお、図４に記載していないが、制御部４１１から検索完了通知が発行された場合には、中断時間を経過していなくても、ログ適用を再開する。

（制御部）
制御部４１１は、ユーザ／ＡＰからの検索要求を受け付け、判定部４０１に対して検索要求を発行する。判定部４０１が検索許可通知を発行した時には、検索部４１２に検索処理の実行を指示する。

制御部４１１の動作フローを図６に示す。制御部４１１は、検索／停止モードを有することとする。制御部４１１は、停止モードへ変更後（ステップ９００）、ステップ９０２にて判定部４０１から停止指示を受け取った場合（Ｙ）には、もし検索処理の実行中であったら、検索部４１２に停止のための実行打ち切りを指示する（ステップ９０３）。続いて、制御部４１１は、副ＤＢ１２３をｕｎｍｏｕｎｔした後（ステップ９０４）、判定部４０１に停止終了を通知し（ステップ９０５）、最後にモードを停止モードに変更する（ステップ９０６）。

一方、制御部４１１は、ステップ９０８にてユーザ／ＡＰからの検索要求を受けた時（Ｙ）には、最初に検索モードか確認する（ステップ９１０）。既に、検索モードであるならば（Ｙ）、そのまま、検索部４１２に次の検索要求に対する検索実行を指示する（ステップ９１１）。ステップ９１０にて停止モードであった場合（Ｎ）は、最初に判定部４０１に検索可否の問い合わせを行う（ステップ９１３）。

そして、制御部４１１は、ステップ９１４にて判定部４０１から許可通知が得られた場合（Ｙ）には、副ＤＢ１２３をｍｏｕｎｔし（ステップ９１７）、モードを検索モードに変更し（ステップ９１８）、最後に検索部４１２に検索実行を指示する（ステップ９１９）。一方、ステップ９１４にて許可通知が得られなかった場合（Ｎ）は、ユーザ／ＡＰにエラーを通知する（ステップ９１５）。

（検索部）
検索部４１２は、制御部４１１の指示に従って検索処理の実行を行う。これは、例えば通常のＤＢＭＳで検索処理のみを実行させることで実現できる。

以上説明したように、本実施の形態のＤＲシステムによれば、副サイトでは、ログ適用機能部１４１が稼働するＤＢアプライアンスサーバ４００と、検索機能部１５１が稼働する検索サーバ４１０が副ストレージ１２０に接続されていることで、以下のような効果を得ることができる。

（１）検索を行わない場合には、安価なＤＢアプラアンスサーバ４００でのログ回復が可能な物理適用を採用することで、サーバコストを削減することができる。また、副サイトでのローカルミラー運用は行わないことで、副ストレージ１２０の容量を削減でき、ストレージコストを削減することができる。これらの結果により、機器コストを削減することができる。

（２）ログ適用機能部１４１でログ適用や業務の傾向をモニタリングしておき、検索処理はログ適用の進捗状況に応じて受け付けるようにして、副サイトのログ適用が十分に追いついていない場合には検索を受け付けないことで、ログがラップラウンドする可能性を低減することができる。また、副ＤＢ１２３の整合性保証を行う場合には、検索指示時点で仕掛かり中となっているＴｒをｕｎｄｏするのではなく、検索指示時点で仕掛かり中のＴｒだけを対象にｒｅｄｏすることで、ｕｎｄｏによる更新ログの生成・管理が不要となり、さらに、ログ適用再開時には検索指示時点からやり直せばよいので運用が容易になる。これらの結果により、運用を容易化することができる。

＜実施の形態２＞
前記実施の形態１では、検索要求があった場合であっても、ログ適用進捗が十分でなければ、要求を拒否していた。それに対し、実施の形態２では、ログ適用進捗が十分でない場合であっても、検索を受け付けておき、ログ適用が追いついた時に実施する。この時（ログ適用進捗が十分でなく、検索要求時以降に検索を実行する場合には）、要求を行ったユーザやＡＰには、検索実行の予定時刻を返しておくこととする。

以下において、本実施の形態のＤＲシステムについて、前記実施の形態１と異なる各部位を詳細に説明する。なお、本実施の形態におけるＤＲシステムは図１と同様の構成であり、各部位の符号は図１と同様の符号を用いる。

（判定部）
判定部４０１は、ログ適用進捗が十分でないと判定された場合の処理のみが、前記実施の形態１と異なる。判定部４０１の動作フローを図７に示す。判定部４０１は、ステップ８０４にて、ログ適用進捗が十分でなく、すぐには検索を実行できないと判定された場合（Ｎ）には、検索が可能になると予測される待ち時間（Ｔ２）を計算する（ステップ１００２）。

これは、例えば、検索が可能となる時刻をＴ２とすると、正サイトのログ出力と副サイトのログ適用の状況はそれぞれ、
Ｐ_ＤＢ’’＝Ｐ_ＤＢ＋Ｖ_ＤＢ×Ｔ２
Ｐ_{ｌｏｇ’’}＝Ｐ_ｌｏｇ＋Ｖ_ｌｏｇ×Ｔ２
となるので、その時に
Ｐ_{ｌｏｇ’’}−Ｐ_ＤＢ’’＜Ｃ１（閾値）
が満たされればよいので、
Ｔ２＞（Ｃ１−（Ｐ_ｌｏｇ−Ｐ_ＤＢ））／（Ｖ_ｌｏｇ−Ｖ_ＤＢ）
となる。

さらに、判定部４０１は、ステップ１００３にて制御部４１１に拒否通知と予測待ち時間（Ｔ２）を返す。そして、Ｔ２だけｓｌｅｅｐ後（ステップ１００４）、判定部４０１は、ステップ８０３にて再び追いつき状況を計算し、ステップ８０４にて十分に追いついていれば（Ｙ）、ステップ８０７以降で副ＤＢ１２３を整合性のとれる状態にした後、検索機能部１５１に副ＤＢ１２３の制御権を切替える。

（制御部）
制御部４１１についても、前記実施の形態１と異なる部分を中心に説明する。制御部４１１の動作フローを図８に示す。制御部４１１では、要求がすぐには受け付けられなかったクエリに対応するために、クエリをキューイングしておくこととする。すなわち、制御部４１１は、ステップ９０８にてユーザ／ＡＰから検索要求があった場合（Ｙ）には、最初にそのクエリ（検索内容）をキューへ登録する（ステップ１１０１）。

次に、制御部４１１は、ステップ９１０にて検索モードであるかをチェックし、既に検索モードで副ＤＢ１２３の制御権を有している場合（Ｙ）には、キューからクエリを取り出し（ステップ１１０２）、検索部４１２にそのクエリの検索実行を指示する（ステップ９１１）。

一方、制御部４１１は、ステップ９１０の判定で、検索モードでない場合（Ｎ）は、判定部４０１に検索可否の判定を依頼する（ステップ９１４）。制御部４１１は、ステップ９１４の判定で、検索実行が許可された場合（Ｙ）には、副ＤＢ１２３をｍｏｕｎｔし（ステップ９１７）、検索モードへの変更を行った後（ステップ９１８）、ステップ１１０４にてキューからクエリを取り出し、検索部４１２にクエリの検索実行を指示する（ステップ９１９）。逆に、制御部４１１は、ステップ９１４の判定にて、判定部４０１が検索を許可しない場合（Ｎ）には、ユーザ／ＡＰには判定部４０１が計算した予定実行時刻を提示する（ステップ１１０３）。

また、制御部４１１は、ステップ９０２の判定にて判定部４０１から停止指示があった場合（Ｙ）で、かつ、その時にクエリを実行していた場合には、検索部４１２にそのクエリの実行停止を指示した後（ステップ９０３）、打ち切ったクエリをキューに再び登録しておく（ステップ１１００）。

検索機能部１５１は、図９に示すようなＩ／Ｆをユーザに提供できることとする。図９（ａ）に示す画面（Ｑｕｅｒｙ）１２００はクエリの実行結果と実行状況を示す。

例えば、実行まで完了したクエリであれば、そのクエリの内容（１２０１）、クエリが登録された時刻（１２０２）、判定部が予想した実行時刻（１２０３）、実際に実行された時刻（１２０４）、副ＤＢの時刻（１２０５：ログ適用を中断した時の時間、ログ中に記録されている正ＤＢサーバでのタイムスタンプを基にした値）、実行結果へのリンク（１２０６）を有する。このリンク（１２０６）を選択した場合には、図９（ｂ）に示す実行結果を表す画面（Ｒｅｓｕｌｔ）１２２０の参照が可能となる。

また、キューに登録されただけで実行が未済みの場合には、クエリの内容（１２０７）、登録時刻（１２０８）、判定部が予想した実行時刻（１２０９）のみが表示され、実行時刻（１２１０）、ＤＢ時刻（１２１１）、実行結果（１２１２）については、実際に実行が行われた時にアップデートされる。

以上説明したように、本実施の形態のＤＲシステムによれば、前記実施の形態１と同様の効果を得ることができるとともに、ログ適用進捗が十分でない場合であっても、検索を受け付けておき、要求を行ったユーザやＡＰには検索実行の予定時刻を返しておき、ログ適用が追いついた時に検索を実行することができる。

＜実施の形態３＞
前記実施の形態１，２では、ユーザやＡＰからの要求をトリガにして副ＤＢの整合性保証処理と検索処理を実施した。実施の形態３では、正サイトの処理に基づいて、自動的に副ＤＢの整合性保証を行い、検索機能部に整合性のとれた副ＤＢを提供する。具体的には、正サイトで行うチェックポイント処理をトリガにする。

以下において、本実施の形態のＤＲシステムについて、前記実施の形態１，２と異なる各部位を詳細に説明する。なお、本実施の形態におけるＤＲシステムは図１と同様の構成であり、各部位の符号は図１と同様の符号を用いる。

チェックポイント（ＣＰ）処理を図１０に示す。チェックポイントでは、最初にＣＰ取得要求を出す。ここで他のオンライン処理を止めてその時に未決着なＴｒ１３０３，１３０４を決着させる方法（図１０（ａ））もあるが、オンライン処理への影響を最小限にするためには、図１０（ｂ）に示すようにそのまま処理を継続していき、ＣＰ取得時点ｔ１（１３１０）で未決着なＴｒが全て完了した時点ｔ２（１３１１）でＣＰ完了したものとする。本実施の形態では、ＣＰ所得要求、ＣＰ完了時にそれぞれログを出力しておくこととする。すなわち、ＣＰ取得要求時点ｔ１（１３１０）で未決着だったＴｒ１３０３，１３０４をｒｅｄｏして決着状態とする。この場合、Ｔｒ１３０３はＣＰ完了時点ｔ２（１３１１）に終了する。ここで、正サイトでは、ｔ１以降に開始されるＴｒも存在し、１３０５〜１３０７はこの例を示す。ただし、副サイトでは、これらのＴｒもｒｅｄｏしてしまうと、不整合な状態となりうる（例えばＴｒ１３０６はＣＰ完了時点ｔ２では決着しない）ため、Ｔｒ１３０５〜１３０７はｒｅｄｏしないこととする。

（ログ入力部）
ログ入力部４０２の動作フローを図１１に示す。ログ入力部４０２は、ステップ６０２にてログを入力し、ＣＰログの有無を判定する（ステップ１４００）。読み込んだログの中にＣＰログがない場合（Ｎ）には、ステップ１４０１にて適用部４０４に読み込んだログの適用を指示する。ＣＰログがあった場合（Ｙ）には、まずＣＰ取得ログまでのログの適用を指示する（ステップ１４０３）。

次に、ログ入力部４０２は、Ｔｒ管理部４０３から未決着なＴｒのリストを取得し（ステップ６０６）、読み込んだログの中からその未決着なＴｒに関するログのみを抽出し（ステップ１４０４）、適用部４０４に抽出したログの適用を指示し（ステップ６０８）、適用が完了すると判定部４０１に検索要求が可能であることを通知する（ステップ１４０５）。

さらに、ステップ１４０６にて判定部４０１はログ適用進捗に基づいて検索可否判定を行い、検索可である場合（Ｙ）は、ログ適用を中断し、判定部４０１からの開始要求があるまで停止状態となる（ステップ１４０９）。一方、許可が得られなければ（Ｎ）、ＣＰ取得ログ以降もログ適用を指示し（ステップ１４０７）、そのままログ適用を実行していく。

（判定部）
判定部４０１の動作フローを図１２に示す。判定部４０１では、ステップ１５００にて検索機能部１５１からではなく、ログ入力部４０２から検索要求を受け付ける。検索要求があった場合（Ｙ）には、ログ適用進捗状況に応じて検索可否判定を行う。

判定部４０１は、例えばログ適用遅延率（Ｒｄｅｌａｙ）を計算し（ステップ８０３）、予め定めた閾値（Ｃ１）と比較することで判定を行う（ステップ８０４）。ログ適用の追いつきが十分でない時（Ｎ）は、ステップ１５０１にて検索ができないことの拒否通知をログ入力部４０２に発信する。追いつきが十分で検索が行えると判定された時（Ｙ）には、副ＤＢ１２３をｕｎｍｏｕｎｔした後（ステップ８０８）、制御部４１１とログ入力部４０２に検索が実行できることの許可通知を発行する（ステップ１５０３）。続いて、判定部４０１は、中断時間（Ｔ）を計算した後（ステップ８１０）、その時間だけｓｌｅｅｐを行い、制御部４１１に検索停止を通知し、ログ入力部４０２には開始指示を通信する（ステップ８１１）。

（制御部）
制御部４１１は、検索実行が可能な時だけユーザからの要求を受け付ける。制御部４１１の動作フローを図１３に示す。制御部４１１は、ステップ１６００にて判定部４０１からの通知を受信し、検索が許可された時（Ｙ）には、副ＤＢ１２３をｍｏｕｎｔし（ステップ１６０６）、検索モードへ変更し（ステップ１６０７）、ユーザ／ＡＰから検索要求を受信し（ステップ１６０８）、検索部４１２に検索実行を指示する（ステップ１６０９）。ステップ１６００の判定で許可通知がない場合（Ｎ）には、最初にすでに検索モードであるかをチェックし（ステップ１６０１）、検索モードであるならば（Ｙ）、ユーザ／ＡＰからの検索要求を受け付け（ステップ１６０２）、その検索を検索部４１２に指示する（ステップ１６０３）。

以上説明したように、本実施の形態のＤＲシステムによれば、前記実施の形態１，２と同様の効果を得ることができるとともに、正サイトで行うチェックポイント処理をトリガにして、自動的に副ＤＢ１２３の整合性保証を行い、検索機能部１５１に整合性のとれた副ＤＢ１２３を提供することができる。

以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。

本発明のＤＲ技術は、副サイトのログ適用機能と検索機能に適用することができ、Ｔｒ処理システムや、ＤＲ構成を取る銀行などの金融業・大企業、および一般企業などに利用可能である。

本発明の実施の形態１におけるＤＲシステムの構成を示す図である。 本発明の実施の形態１におけるＤＲシステムと従来方式との比較において、副ＤＢの整合性保証方式（（ａ）従来方式、（ｂ）本方式）を示す図である。 本発明の実施の形態１におけるＤＲシステムにおいて、適用部の動作フローを示す図である。 本発明の実施の形態１におけるＤＲシステムにおいて、判定部の動作フローを示す図である。 本発明の実施の形態１におけるＤＲシステムにおいて、検索可否の判定方法（ａ）と中断時間の計算方法（ｂ）を示す図である。 本発明の実施の形態１におけるＤＲシステムにおいて、制御部の動作フローを示す図である。 本発明の実施の形態２におけるＤＲシステムにおいて、判定部の動作フローを示す図である。 本発明の実施の形態２におけるＤＲシステムにおいて、制御部の動作フローを示す図である。 本発明の実施の形態２におけるＤＲシステムにおいて、検索機能部が提供する画面（（ａ）クエリの実行結果と実行状況、（ｂ）クエリの実行結果）を示す図である。 本発明の実施の形態３におけるＤＲシステムにおいて、チェックポイント処理（（ａ）チェックポイント取得要求時、（ｂ）チェックポイント完了時）を示す図である。 本発明の実施の形態３におけるＤＲシステムにおいて、ログ入力部の動作フローを示す図である。 本発明の実施の形態３におけるＤＲシステムにおいて、判定部の動作フローを示す図である。 本発明の実施の形態３におけるＤＲシステムにおいて、制御部の動作フローを示す図である。 本発明に対する従来方式（（ａ）物理適用＋ローカルミラー運用、（ｂ）論理適用）におけるＤＲシステムの構成を示す図である。 本発明に対する従来方式におけるＤＲシステムにおいて、検索実行のための副ＤＢの整合性保証処理（（ａ）開始時、（ｂ）終了時）、ログ適用再開時の処理（ｃ）を示す図である。

符号の説明

１００…正ＤＢサーバ、１０１…ＤＢＭＳ、１０２…ログ管理部、１０３…Ｔｒ制御部、１０４…ＤＢ管理部、
１１０…正ストレージ、１１１…ディスク制御処理部、１１２…ログＶＯＬ、１１３…正ＤＢ、
１２０…副ストレージ、１２１…ディスク制御処理部、１２２…ログＶＯＬ、１２３…副ＤＢ、
１４０…副ＤＢサーバ、１４１…ログ適用機能部、１５０…クライアント、１５１…検索機能部、１６０…ネットワーク、２００…検索機能部、
４００…ＤＢアプライアンスサーバ、４０１…判定部、４０２…ログ入力部、４０３…Ｔｒ管理部、４０４…適用部、
４１０…検索サーバ、４１１…制御部、４１２…検索部。

Claims (16)

1. 正サイトのＤＢＭＳのログをストレージのリモートコピーで副サイトに転送し、前記副サイトでログ適用を行うログベースのディザスタリカバリシステムであって、
   前記副サイトには、前記ログ適用で複製されたデータを格納する副ストレージと、前記副ストレージに接続されたログ適用処理を行うログ適用機能部と、前記副ストレージに接続された検索処理を行う検索機能部を有し、
   前記ログ適用機能部は、ログ適用の進捗を監視しており、前記検索機能部からの検索要求があった場合には、監視しているログ適用の進捗に応じて前記検索機能部への切替えを行うことを特徴とするディザスタリカバリシステム。
2. 請求項１記載のディザスタリカバリシステムにおいて、
   前記ログ適用機能部は、アプライアンスサーバに構築され、
   前記検索機能部は、検索サーバに構築されていることを特徴とするディザスタリカバリシステム。
3. 正サイトのＤＢＭＳのログをストレージのリモートコピーで副サイトに転送し、前記副サイトでログ適用を行うログベースのディザスタリカバリ方法であって、
   前記副サイトでは、ログ適用処理を行うログ適用機能部と、検索処理を行う検索機能部が副ストレージに接続されており、
   前記ログ適用機能部は、ログ適用の進捗を監視しており、前記検索機能部からの検索要求があった場合には、監視しているログ適用の進捗に応じて前記検索機能部への切替えを行うことを特徴とするディザスタリカバリ方法。
4. 請求項３記載のディザスタリカバリ方法において、
   前記ログ適用機能部は、前記検索機能部からの検索要求を受けた場合、監視していたログ適用の進捗状況に応じて検索可否の判定を行い、検索が可能な場合は副ＤＢを整合性のとれた状態にし、ログ適用を中断可能な時間を計算し、その計算した時間内での検索処理を実行した後、ログ適用を再開することを特徴とするディザスタリカバリ方法。
5. 請求項４記載のディザスタリカバリ方法において、
   前記ログ適用機能部は、検索可否の判定を行う判定部を有しており、
   前記判定部は、正サイトのＤＢＭＳと副サイトのログ適用機能部の性能情報を監視しておき、前記検索機能部からの検索要求を受け付けた場合には、監視していた性能情報を用いてログ適用の正サイトからの遅れを計算し、その計算した遅れが事前に定めた閾値以下であったら前記検索機能部への切替えを許可することを特徴とするディザスタリカバリ方法。
6. 請求項４記載のディザスタリカバリ方法において、
   前記ログ適用機能部は、副サイトの検索の受け付けが決定された場合には、その時点で未決着なトランザクションを決定し、続いてその決定したトランザクションに関する更新ログのみを抽出し、ログ適用して、副ＤＢを整合性のとれた状態に回復することを特徴とするディザスタリカバリ方法。
7. 請求項４記載のディザスタリカバリ方法において、
   前記検索機能部は、制御部を有しており、
   前記制御部は、ユーザやＡＰからの検索要求を受け付けると、最初に前記ログ適用機能部に検索要求を出し、副ＤＢが整合性のとれた状態になるのを待ってから、受け付けた検索要求を実施することを特徴とするディザスタリカバリ方法。
8. 請求項４記載のディザスタリカバリ方法において、
   前記ログ適用機能部は、正サイトのログ出力、副サイトのログ適用の性能情報を監視しておき、前記検索機能部からの検索要求を受け付けた場合には、予め定めておいたログ適用の遅れの許容量と正サイトのログ出力速度から、ラップラウンドをすることなくログ適用を停止することが可能な時間を求め、その求めた時間だけログ適用処理を中断後、ログ適用を再開することを特徴とするディザスタリカバリ方法。
9. 請求項４記載のディザスタリカバリ方法において、
   前記検索機能部は、前記ログ適用機能部からの要求を監視し、前記ログ適用機能部から検索停止要求を受けた場合には、検索処理を停止し、前記検索機能部が利用していた副ＤＢをアンマウントし、前記ログ適用機能部に副ＤＢの制御を切替えることを特徴とするディザスタリカバリ方法。
10. 請求項３記載のディザスタリカバリ方法において、
    前記ログ適用機能部は、前記検索機能部からの検索要求を受けた場合、監視していたログ適用の進捗状況をもとに検索受け付けの判定を行い、ログ適用が十分に追いついていない場合には追いつくようになると予想される時間を計算し、その計算した時間を前記検索機能部に検索実行が可能となる予測時刻として返し、ログ適用が十分に追いついている場合には検索を許可するとし、副ＤＢを整合性のとれた状態にし、ログ適用を中断可能な時間を計算し、その計算した時間内での検索処理を実行した後、ログ適用を再開することを特徴とするディザスタリカバリ方法。
11. 請求項１０記載のディザスタリカバリ方法において、
    前記ログ適用機能部は、検索受け付け可能かどうかの判定を行う判定部を有しており、
    前記判定部は、正サイトのＤＢＭＳと副サイトのログ適用機能部の性能情報を監視しておき、前記検索機能部からの検索要求を受け付けた場合には、監視していた性能情報を用いてログ適用の正サイトからの遅れを計算し、その計算した遅れが事前に定めた閾値以下であったら前記検索機能部への切替えを許可し、閾値を超過している場合には閾値以下となる時刻を計算し、その計算した時刻を前記検索機能部に検索実行が可能となる予測時間として返すことを特徴とするディザスタリカバリ方法。
12. 請求項１０記載のディザスタリカバリ方法において、
    前記検索機能部は、制御部を有しており、
    前記制御部は、ユーザやＡＰからの検索要求を受け付けると、最初に前記ログ適用機能部に検索要求を出し、検索が許可された場合には副ＤＢが整合性のとれた状態になるのを待ってから、受け付けた検索要求を実施し、検索が許可されなかった場合にはクエリをキューに格納すると共に、ユーザやＡＰには前記ログ適用機能部が計算した予測時刻を通知し、この予測時刻になった時には、再度、前記ログ適用機能部にキューに格納したクエリの検索要求を送信することを特徴とするディザスタリカバリ方法。
13. 請求項３記載のディザスタリカバリ方法において、
    前記ログ適用機能部は、正サイトで行われるチェックポイントログを監視し、チェックポイントログが発行されている場合には、副ＤＢを整合性のとれた状態にした上で、前記検索機能部へ副ＤＢの制御権を切替えることで、チェックポイント毎の検索実行を許可することを特徴とするディザスタリカバリ方法。
14. 請求項１３記載のディザスタリカバリ方法において、
    前記ログ適用機能部は、ログ入力部を有しており、
    前記ログ入力部は、チェックポイントを行ったことを示すログを監視し、チェックポイントログが発行されていた場合には、その時点で未決着なトランザクションを決定し、その決定したトランザクションに関する更新ログのみを抽出し、ログ適用することで整合性のとれたＤＢを回復することを特徴とするディザスタリカバリ方法。
15. 請求項１３記載のディザスタリカバリ方法において、
    前記ログ適用機能部は、判定部を有しており、
    前記判定部は、ログ入力部から検索要求を受信した場合には、ログ適用の遅れを計算し、遅れが事前に定めた閾値以下であれば、副ＤＢをアンマウントし、前記検索機能部に対して検索実行が可能であることを通知し、副ＤＢの制御権を前記検索機能部に切替えることを特徴とするディザスタリカバリ方法。
16. 請求項１３記載のディザスタリカバリ方法において、
    前記検索機能部は、制御部を有しており、
    前記制御部は、前記ログ適用機能部からの検索要求、あるいは停止要求を監視し、検索要求を受信した場合には、副ＤＢをマウントし、副ＤＢの制御権を前記ログ適用機能部から前記検索機能部に切替え、ユーザやＡＰからの検索要求を受信して実行し、前記ログ適用機能部から停止要求があった場合には、検索処理を停止し、副ＤＢをアンマウントし、副ＤＢの制御権を前記ログ適用機能部に切替えることを特徴とするディザスタリカバリ方法。

Images