"正サイトのデータベース処理システムのデータを副サイトにコピーするストレージシステムにおけるデータベース管理方法であって、前記正サイトは、データベース処理システムが稼動する第1の計算機と、データベースを記録するボリューム及び前記データベースへの更新履歴であるログを記録するボリュームを含む正ストレージとを有し、前記副サイトは、ログ適用処理を行うプログラムと、前記プログラムが稼動する第2の計算機と、データベース記録するボリューム及びログを記録するボリュームを含む副ストレージとを有し、前記正サイトと前記副サイトとはネットワークで結合され、前記正ストレージ及び前記副ストレージはリモートコピー機能を有し、前記正サイトでは前記正ストレージのリモートコピーでログを転送し、前記副サイトでは転送されるログを前記副ストレージのデータベースに適用するログ適用処理において、前記正サイトで複数のログレコードからなるログブロック単位で書き込みを行い、前記副サイトでログ適用を行う際には、前記副ストレージは、前記正ストレージの1つの転送元ボリュームに対して第1のボリュームと第2のボリュームとを有し、前記正ストレージに書き込まれたログはリモートコピーを表す第1のコピーにより前記副ストレージの前記第1のボリュームに更新順で追記され、前記第2のボリュームへのコピーは前記第1のボリュームへの書き込みとは別のタイミングで第2のコピーで反映され、前記副サイトでログ適用を行う際には、前記第2のコピーを中断するステップと、前記第2のボリュームからログブロックを読み込むステップと、前記読み込んだログブロックを適用するステップと、読み込めるログがなくなった場合には前記ログ適用処理を中断した後に前記第2のコピーを再開するステップとを有することを特徴とするデータベース管理方法。請求項1記載のデータベース管理方法において、前記中断した第2のコピーを再開する際には、一定時間が経過した後に前記第2のコピーを再開することを特徴とするデータベース管理方法。請求項1記載のデータベース管理方法において、前記中断した第2のコピーを再開する際には、前記第1のボリュームに前記第2のコピーの中断後に加えられた書き込みに関する情報を問い合わせ、書き込み量が事前に定めた定数値を超えていた場合に前記第2のコピーを再開することを特徴とするデータベース管理方法。請求項1記載のデータベース管理方法において、管理者やアプリケーションからの切り替え指示を受けた場合には、最初にリモートコピーを表す第1のコピーの状態を変更し、新たな書き込みが生じないようにするステップを有し、前記第1のコピーの状態変更後は、前記第2のコピーを中断するステップと、前記ログを読み込み、適用するステップと、前記第1のボリュームに反映すべき更新があるかを問い合わせるステップとを有し、前記反映すべき更新がある場合には、前記第2のコピーを再開させてログ読み込み、適用を行うステップを有し、前記反映すべき更新がない場合には、読み込み可能なログを全て適用した後に未決着なトランザクションをキャンセルするステップを有し、前記データベースをトランザクション整合性のとれた状態とすることを特徴とするデータベース管理方法。正サイトのデータベース処理システムのデータを副サイトにコピーするストレージシステムであって、前記正サイトは、データベース処理システムが稼動する第1の計算機と、データベースを記録するボリューム及び前記データベースへの更新履歴であるログを記録するボリュームを含む第1のストレージとを有し、前記副サイトは、ログ適用処理を行うプログラムと、前記プログラムが稼動する第2の計算機と、データベースを記録するボリューム及びログを記録するボリュームを含む第2のストレージとを有し、前記正サイトと前記副サイトとはネットワークで結合され、前記第1及び第2のストレージはリモートコピー機能を有し、前記第1のストレージに記録されるログはリモートコピー機能により前記第2のストレージに転送され、転送先の前記第2のストレージは、前記第1のストレージで転送対象となっているボリュームの1つに対して第1のボリュームと第2のボリュームとを有し、前記第1のストレージからの転送は前記第1のボリュームに追記され、前記第1のボリュームから前記第2のボリュームへの第2のコピーは第1のコピーであるリモートコピーとは別のタイミングで実施され、前記副サイトのログ適用処理においては、前記第2のボリュームからログを読み込み、ログを読み込む時には前記第2のコピーを中断状態としてからログの読み込み適用を実施し、読み込んだログの適用が終了したら前記第2のコピーを再開状態とすることを特徴とするストレージシステム。正サイトのデータベース処理システムのデータを副サイトにコピーするストレージシステムにおけるデータベース管理方法であって、前記正サイトは、データベース処理システムが稼動する第1の計算機と、データベースを記録するボリューム及び前記データベースへの更新履歴であるログを記録するボリュームを含む第1のストレージとを有し、前記副サイトは、ログ適用処理を行うプログラムと、前記プログラムが稼動する第2の計算機と、データベースを記録するボリューム及びログを記録するボリュームを含む第2のストレージとを有し、前記正サイトと前記副サイトとはネットワークで結合され、前記第1のストレージに加えられた更新を前記第2のストレージに反映する処理において、転送先の前記第2のストレージは、前記第1のストレージで転送対象となっているボリュームの1つに対して第1のボリュームと第2のボリュームとを有し、前記第1のストレージからの転送は前記第1のボリュームに追記され、前記第1のボリュームから前記第2のボリュームへの第2のコピーはリモートコピーとは別のタイミングで実施され、前記第2のコピーの実行状態をユーザやアプリケーションから制御可能とし、前記ユーザやアプリケーションから前記第2のコピーを中断/再開することを特徴とするデータベース管理方法。請求項6記載のデータベース管理方法において、前記第2のコピーを中断状態とした場合には、前記第2のコピーを中断状態としてから前記第1のボリュームに転送された更新量を問い合わせることを特徴とするデータベース管理方法。正サイトのデータベース処理システムのデータを副サイトにコピーするストレージシステムであって、前記正サイトは、データベース処理システムが稼動する第1の計算機と、データベースを記録するボリューム及び前記データベースへの更新履歴であるログを記録するボリュームを含む第1のストレージとを有し、前記副サイトは、ログ適用処理を行うプログラムと、前記プログラムが稼動する第2の計算機と、データベースを記録するボリューム及びログを記録するボリュームを含む第2のストレージとを有し、前記正サイトと前記副サイトとはネットワークで結合され、前記第1のストレージに加えられた更新を前記第2のストレージに反映する処理において、転送先の前記第2のストレージは、前記第1のストレージで転送対象となっているボリュームの1つに対して第1のボリュームと第2のボリュームとを有し、前記第1のストレージからの転送は前記第1のボリュームに追記され、前記第1のボリュームから前記第2のボリュームへの第2のコピーはリモートコピーとは別のタイミングで実施され、前記第2のコピーの実行状態をユーザやアプリケーションから制御可能とするためのインターフェースを有し、前記ユーザやアプリケーションから前記第2のコピーを中断/再開することを特徴とするストレージシステム。請求項8記載のストレージシステムにおいて、前記第2のコピーを中断状態とした場合には、前記第2のコピーを中断状態としてから前記第1のボリュームに転送された更新量を問い合わせるインターフェースを有することを特徴とするストレージシステム。ところで、前記のような従来方式では、正サイトで書き込み中の最新のログファイルではなく、1世代以上前のログをファイル単位で適用している。これは、リモートコピーで書き込み中のVOLをそのまま読むと、読み込んだ内容の整合性が保障されないためである。これらの方式には、以下のような課題が考えられる。課題1:迅速なFOfailover:サイト間切り替えが困難一般に、運用を容易化する観点から、頻繁にログファイルのアーカイブを行う運用は好まれず、ログファイルのサイズは拡大する傾向がある。そのため、ファイル単位で回復を行う方式は、災害/計画FO時にも、サイズの大きいファイルの先頭からログ適用を開始しなければならず、FO完了までに多くの処理時間を要し、迅速なサービス再開が行えない。課題2:正サイトのオンライン性能維持とDB整合性保証の両立FO時間を高速化するためには、ログファイル単位ではなく、正サイトが使用中のログファイルを読み込み対象として、ファイルより細かい粒度でログの読み込み適用を実施すればよい。ここで、DBを正しく回復するには、ログが正しく読まれている事が保証されていなければならない。しかし、リモートコピーで書き込みが行われている最中に、そのログファイルを読むと、不正にログを読み込んでしまう場合がある。以下に、ログファイルの構造を説明した後、不正にログを読み込む場合について説明する。最初に、ログファイルの構造と読み込み/書き込み方式について説明する。ここで、行への更新差分情報そのものはログレコードと呼ぶものとする。正サイトのDBMSでは、更新を行う時には必ずログレコードを生成する。しかし、ログレコードを生成する度に、ストレージに出力するとオンライン性能への影響が大きいため、内部でバッファリングしておき、複数のレコードからなるログブロック単位で出力を行う。ログブロックには、ヘッダとトレイラが付加されており、両者とも正常に書かれていることにより、ブロックの整合性が保障できる。そのためには、副サイトでログを読み込む場合も、ブロック単位で読み込み、そのヘッダとトレイラにより整合性を検証することができる。しかし、広域災害を考慮したDRシステムに適用する場合には、上記の処理だけでは整合性が検証できないケースが生じる。サイト間が長距離で転送遅延が大きい場合には、転送遅延の影響を最小限にするために、ブロックのサイズは大きく、転送回数を少なくすることが望ましい。しかし、このブロックサイズがストレージのキャッシュ管理単位読み込み単位より大きくなると、ログブロックの整合性検証が正しく行えないケースが生じる。このような不正な整合性検証は、ログ適用が正サイトのオンライン処理に完全に追いついており、正サイトでまさに書き込みを行っている領域を、副サイトのログ適用機能が読もうとしている場合に生じる。図17に例を示す。図17は、ログ読み込みが正常に行えない場合の一例を説明する図である。図17において、1500はログブロック、1501は書き込み1領域、1502は読み込み1領域、1503は書き込み2領域、1504は読み込み2領域、1505はログ適用部に読み込まれたログブロックをそれぞれ示す。正サイトのDBMSはログブロック全体を書き込むが、OS層で複数のIOに分割される場合がある。図17では2個のIOに分割されており、それぞれがリモートコピーで転送される。副サイトでは、ログ適用機能を持つログ適用部が正サイトのIOとは独立に読み込み処理を行う。このとき、ストレージ内ではキャッシュ管理単位でデータ管理を行っており、読み込みもこのキャッシュ管理単位で行われる。図17では、正サイトのDBMSの1回の書き込みがOS層で2回の書き込みに分割されており、1回目の書き込みだけが完了している時に、ログ適用の1度目の読み込みが行われているt→t2。続いて、2回目の書き込みが終わり、ブロック全体の書き込みが完了した後、ログ適用部が2回目の読み込みを行っているt3→t4。その結果、ログ適用部が読み込んだログブロック1505は図17のように、中抜けの状態となる。この場合、先頭/後尾ヘッダ/トレイラは正しく読み込まれているため、ログブロックは正しいと判断され、ログ適用が行われる。その結果、副サイトのDBが破壊されてしまう。以上のように、回線コスト削減のためにログをリモートコピーで転送し、DBはログ適用で回復するDR方式においては、1ログファイル単位で読み込み適用を行う場合には迅速なFOが行えない、2迅速なFOを行うために、ファイルより細かい粒度で適用を行うと、不正なログを読み込み適用してしまうことでDBを破壊してしまうことがある、という問題が生じる。そこで、本発明の目的は、ファイルより細かい粒度でログの読み込み適用を行うことでFOの高速化を実現し、かつ、ログの読み込み適用処理の中で、ログの再読み込み、あるいは、リモートコピーと連携した読み込みを行うことで、正サイトのログ書き込み単位が大きい場合でも正しくログ読み込みを行うことができるDR技術を提供することにある。本発明の前記ならびにその他の目的と新規な特徴は、本明細書の記述および添付図面から明らかになるであろう。本願において開示される発明のうち、代表的なものの概要を簡単に説明すれば、次のとおりである。本発明は、FOの高速化のために、ファイルより細かい粒度でログの読み込み適用を行い、かつ、正サイトのログ書き込み単位が大きい場合でも正しくログ読み込みを行うために、ログの読み込み適用処理の中で、ログの再読み込み、あるいは、リモートコピーと連携した読み込みを行うものである。すなわち、本発明において、正サイトのDBMSのデータを遠隔地に配置された副サイトにコピーするDR方法およびDRシステム、第1のストレージ正ストレージに加えられた更新を遠隔地に配置された第2のストレージ副ストレージに反映するリモートコピー方法およびストレージシステムにおいては、以下のような特徴を有するものである。1正サイトでは正ストレージのリモートコピーでログを転送し、副サイトでは転送されるログを適用して副ストレージのDBを回復するログ適用処理において、正サイトで複数のログレコードからなるログブロック単位で書き込みを行い、副サイトでログ適用を行う際には、以下の処理を行う。副ストレージからログブロックを読み込み、整合性を検証する。ログブロックの読み込み時に、読み込み処理とリモートコピーによる書き込み処理とが競合していないかを判定する。判定により、競合がないと判定されたログブロックのみをDBに適用する。2ログの再読み込みを行う方式において、副サイトでログ適用を行う際には、副ストレージからログブロックを読み込み、整合性を検証する。読み込んだログブロックの内、最後の1つを除いたログブロックについては読み込み処理とリモートコピーによる書き込み処理とが競合していないと判定する。最後のログブロックを除いたログブロックについては再読み込みを行った上で適用する。これにより、読み込みが正しく行えたかを確認しながらログ適用を行い、正サイトから読み込むべきログを指定するための通信や処理を行うことなく、副サイトで独立してログ適用してDBを回復することができる。3リモートコピーと連携した読み込みを行う方式において、副サイトでログ適用を行う際には、第2のコピーを中断する。第2のボリュームからログブロックを読み込む。読み込んだログブロックを適用する。読み込めるログがなくなった場合にはログ適用処理を中断した後に第2のコピーを再開する。これにより、ログ読み込み時には第2のコピーを中断状態とすることで、ログ読み込みとリモートコピーによる書き込みが競合することを回避し、正サイトから読み込むべきログを指定するための通信や処理を行うことなく、副サイトで独立してログ適用してDBを回復することができる。本願において開示される発明のうち、代表的なものによって得られる効果を簡単に説明すれば以下のとおりである。1ログを同期転送する場合には欠損がないことが保証可能である。また、リモートコピー利用により、サーバリソースを消費することなく転送が可能なので、正サイトのオンライン性能への影響が小さい。2更新量の多いDBファイルの転送が不要なため、狭帯域幅回線でも実現でき、回線コストの削減が可能となる。3ファイルより細かい単位で適用を行うため、切り替え時にも迅速にサービスを再開することが可能となる。4正サイトのオンライン性能維持のため、ログのIO単位が大きい場合であっても、再読み込み処理/リモートコピー連携処理により、不正読み込みによるDB破壊を防止することが可能となる。従って、広域災害を考慮して副サイトが数百km以上離れた構成にも対応可能となる。5正サイトに、ログの読み込み位置を決定するための処理、あるいは、通信を新たに加えることなく、副サイトのログ適用部だけで独立してログ適用処理を行い、DBを回復することが可能となる。以下、本発明の実施の形態を図面に基づいて詳細に説明する。なお、実施の形態を説明するための全図において、同一の構成要素には原則として同一の符号を付し、その繰り返しの説明は省略する。実施の形態1本発明の実施の形態1におけるDRシステムを、図1~図6を用いて説明する。まず、図1により、本実施の形態におけるDRシステムの構成の一例を説明する。図1はDRシステムの構成の一例を示す図である。本実施の形態のDRシステムは、ログの再読み込みを行う方式を適用し、正サイトと、副サイトから構成される。正サイトは、DBMSが稼動する計算機からなるサーバ100と、DBMSのログファイルとDBファイルが保存されるストレージ120から構成される。副サイトは、ログ適用処理を行う副DBMS、あるいは、ログ適用に特化された機能ログ適用機能が稼動する計算機からなるサーバ110と、ストレージ130から構成される。正サイトのストレージ120と副サイトのストレージ130とは、ネットワーク150を通じて接続されている。正サイトにおいて、サーバ100では、DBMS101が稼働し、このDBMS101には、DBバッファ102、ログバッファ103、DBアクセス制御部104、ログ管理部105が設けられている。正サイトのストレージ120には、ストレージ制御処理部121、キャッシュ126、ディスクアクセス制御部127、ログ用VOLLog128、DB用VOLDB129が設けられている。ストレージ制御処理部121には、コマンド処理部122、コピー処理制御部123、リモートコピー処理部124が設けられている。副サイトにおいて、サーバ110では、ログ適用部111が動作し、このログ適用部111には、DBバッファ112、ログバッファ113、ログ適用制御部114、ログ読み込み整合性検証部115、適用部116が設けられている。副サイトのストレージ130には、ストレージ制御処理部131、キャッシュ136、ディスクアクセス制御部137、ログ用VOLLog138、DB用VOLDB139が設けられている。ストレージ制御処理部131には、コマンド処理部132、コピー処理制御部133、リモートコピー処理部134が設けられている。正サイトのサーバ100では、DBMS101が稼働する。DBMS101はUAPユーザアプリケーションからの指示に従い、ストレージ120内のDB用VOL129に格納されるデータを参照、あるいは、更新する。DBMS101は、DB用VOL129に対して更新を行う場合には、まず、更新差分をログとして、ストレージ120内のログ用VOL128へ格納する。なお、DBMS101は、ログ管理部105とDBアクセス制御部104を有し、それぞれがDBバッファ102、ログバッファ103を介してストレージ120内のデータをアクセスする。正サイトのストレージ120は、リモートコピー機能を有する。同様に、副サイトのストレージ130も、リモートコピー機能を有し、内に併記して説明する。サーバ100110からのIO要求があった場合、コマンド処理部122132が要求を受け付ける。要求が書き込み要求であった場合は、キャッシュ126136上にデータがあれば、キャッシュ126136上でデータを更新する。キャッシュ126136にない場合は、ディスクアクセス制御部127137に該当データを依頼し、VOLを構成するディスクからキャッシュ126136にコピーしてから書き込みを行う。また、書き込んだデータは、ディスクアクセス制御部127137により非同期でディスクへ書き戻される。ここでは、リモートコピーの対象となっているVOLへの書き込みが行われた場合は、キャッシュ126136への書き込みに続いて、リモートコピー処理部124134が副サイトのストレージ120の対応する領域キャッシュ136にも書き込みを行うものとする。また、コピー処理制御部123133へ指示を行うことで、コピーの開始/停止切断/中断といったリモートコピーの状態制御が可能であるものとする。なお、本実施の形態では、正/副サイトのストレージ120130のログ用VOL128138がリモートコピーの対象になっているものとする。副サイトのサーバ110では、ログ適用部111が動作する。ログ適用部111は、リモートコピーで転送されるログ用VOL138を読み込み、DB用VOL139に含まれるデータを更新する。ログ読み込み整合性検証部115は、ログ用VOL138からログを読み込み、読み込んだログの整合性を検証する。ログ適用部111は、読み込んだログを適用し、DB用VOL139上のデータを更新する。ログ適用制御部114は、ログ読み込み整合性検証部115、適用部116を制御することでDBを回復する。なお、ログ適用部111も、DBMS101と同様に、DBバッファ112、ログバッファ113を介してVOL上のデータをアクセスする。本実施の形態のDRシステムにおいて、ログ適用を行うために副DBMSではなく、ログ適用機能を利用する場合は、切り替え後にサービスを継続する副DBMSは、この副サイトのサーバで動作してもよいし、別のサーバで動作してもよい。以下では、ログ適用機能を用いる場合について説明する。正サイトのストレージ120と副サイトのストレージ130は、ストレージ間ネットワーク150で結合されており、ログファイルのみがリモートコピーで転送される設定になっている。副サイトのログ適用機能は、図2に示すような、リモートコピーにより転送が行われるログ用VOL200上に存在するログファイル201を直接読んで適用する。図2は、ログファイルの構造の一例を示す図である。このログファイル201は、ログレコード203を束ねたブロック単位で読み書きされる。すなわち、正サイトのDBMSは、ブロック単位でログファイルに書き込みを行い、一方、ログ適用機能はブロック単位で読み込みを行う。このログブロック202には、先頭にヘッダ204、後尾にトレイラ205が付加されており、それぞれに含まれるマジックワードにより、ブロック全体の整合性検証が行える。ただし、前述のように、ログブロック202のサイズが大きく、かつ、ログ適用が正サイトのログ書き出しに追いついている場合、リモートコピーによる書き込みとログ適用機能の読み込みが競合する場合には、このヘッダ/トレイラによる整合性検証だけでは整合性が保証できないので、図3に示すようなスケジュールで読み込み適用を行う。図3は、ログブロックの読み込み適用スケジュールの一例を示す図である。すなわち、あるログブロックblockiの読み込み適用を行う際300には、そのブロックblockiに対して読み込みと書き込みが競合しないことを保証するために、次のログロックblocki1が読めるかどうかを最初に確認する301。次のブロックblocki1が読み込める場合には、先のログブロックblockiを再読み込みした上で、適用を行う302。ログはシーケンシャルに追記されるため、ログブロックblocki1が書かれていれば、ログブロックblockiの書き込みは正常に完了していることが判断でき、ログブロックの整合性を保証することが可能となる。次に、図4~図6により、本実施の形態のDRシステムにおいて、ログ読み込み適用処理のフローの一例を説明する。それぞれ、図4は平常時、図5は切り替え時、図6は平常時SZサイズ判定有りのフローの一例を示す図である。なお、本実施の形態においては、ブロックを1個ごとに読んでいるが、1度に複数のブロックを読み込んでもよい。複数のブロックを読み込んだ場合は、最後のブロック以前のブロックを適用対象とし、再読み込みを行った上で、適用を行う。図4において、ログ読み込み適用処理平常時では、最初に、ログの読み込み位置を決定するS401。ここで、DBMSは、チェックポイント等のタイミングで、適用が完了しているログの通番LSNやその時に使用しているログファイルやDBファイルなどの内部情報をDBMS状態ファイルに出力する。ログの読み込み位置決定では、DBMS状態ファイルからLSNや使用しているログファイルを読み込み、最初に読み込むべきブロックを決定するS402。ここでは、ポインタptrが指すブロックから読み込みを開始する。読み込み位置を決定したら、以降は、管理者やアプリケーションからのFO/停止指示があるか否かを判定しS403、FO/停止指示がある場合Yは停止/FO処理に移行し、FO/停止指示がない場合Nには、FO/停止指示があるまで、ログ読み込み適用処理を繰り返す。初めに、ptrが指すブロック以降、ブロックptrとするを読み込みS404、続いて、ヘッダとトレイラによりブロックptrの整合性検証を行う。ここでは、ブロックptrは整合性があるか否かを判定しS405、整合性がない場合NはS1へ戻り、整合性がある場合Y、すなわち正しく読み込めた場合にはS2へ移行する。そして、再び、FO/停止指示があるか否かを判定しS406、FO/停止指示がある場合Yは停止/FO処理に移行し、FO/停止指示がない場合Nには、次のブロックptr1の読み込みと整合性検証を行う。まず、次のブロックptr1を読み込みS407、続いて、ブロックptr1は整合性があるか否かを判定しS408、整合性がない場合NはS2へ戻り、整合性がある場合Y、すなわち整合性が検証されたら、ブロックptrの再読み込みを行った上で適用を行いS409,S410、ptrを1つ進めてS411、S2へ戻る。以降、ptr1が指すブロックの読み込み検証を行い、問題がなければ、ptrが指すブロックの再読み込み適用を実施する。図5において、管理者から、FO/停止指示を受けた場合の処理を説明する。このログ読み込み適用処理切り替え時では、最初に、停止指示かFO指示かを判定しS501、停止指示であった場合停止は、ログ適用の進捗情報としてptr情報をDB状態ファイルに書き出して処理を終了するS502。一方、FO指示であった場合FOには、最初にリモートコピーの状態制御を行うS503。例えば、災害時のFOであれば、リモートコピーを切断状態とし、以降に正サイトからの書き込みが行われる事を抑止する。一方、計画的なFOであれば、コピーの向きを逆向きに設定する。次に、ブロックptrの読み込みと整合性検証を行い、以降は終端と判定されるまでログの読み込み、適用処理を繰り返す。すなわち、ブロックptfの読み込みを行った上で適用を行いS504,S505、終端か否かを判定するS506。なお、ここではリモートコピーの状態制御実施後であり、リモートコピーと読み込みが競合することがないため、ログの再読み込み処理は不要となる。そして、終端でない場合Nはptrを1つ進めてS507、S3へ戻り、終端と判定された場合Y、すなわち読み込むべきブロックがなくなったら、未決着トランザクションのキャンセル処理undo処理を実施するS508。ここで、ログ適用処理内で決着トランザクションだけを適用するような場合は、キャンセル処理は不要となる。続いて、状態ファイルにDBファイルが整合性のとれた状態になっていることを書き出しS509、副DBMSを起動してS510、処理を終了する。図6において、平常時にSZ判定有りの場合の処理を説明する。ブロックがキャッシュ管理サイズより小さく、かつ、一括して書かれる場合は、中抜け状態で読まれることはない。したがって、本処理では、ブロックのサイズがキャッシュ管理サイズより大きい場合にのみ、再読み込みを行う。このログ読み込み適用処理平常時、SZ判定有りでは、前記図4の処理にSZ判定処理を追加した例であり、ここでは追加部分を主に説明する。最初に、前記図4と同様に、ログの読み込み位置の決定処理S601、ブロックptrのログ読み込み位置決定S602、FO/停止指示があるか否かの判定S603、ブロックptrの読み込みS604、ブロックptrは整合性があるか否かの判定S605、を行った後、整合性がある場合Yには、ブロックptrのサイズがキャッシュ管理サイズSZより大きいか否かを判定するS606。ブロックptrのサイズがSZより大きい場合YはS2へ移行し、大きくない場合Nには、ブロックptrの適用を行いS607、ptrを1つ進めてS608、S1へ戻る。S2へ移行したら、前記図4と同様に、FO/停止指示があるか否かの判定S609、ブロックptr1の読み込みS610、ブロックptr1は整合性があるか否かの判定S611、ブロックptrの再読み込みと適用S612,S613、を行った後、次のブロックptr1のサイズがキャッシュ管理サイズSZより大きいか否かを判定するS614。ブロックptr1のサイズがSZより大きい場合Yはptrを1つ進めてS615、S2へ戻り、大きくない場合Nには、ブロックptr1の適用を行いS616、ptrを2つ進めてS617、S1へ戻る。以上説明したように、本実施の形態のDRシステムによれば、以下のような効果を得ることができる。1ログの再読み込みを行う方式を適用し、ログを同期転送する場合には、欠損がないことを保証することが可能となる。また、リモートコピー利用により、サーバリソースを消費することなく転送を行うことができるので、正サイトのオンライン性能への影響を小さくすることが可能となる。2ログの再読み込みを行う方式を適用することで、更新量の多いDBファイルの転送が不要なため、狭帯域幅回線でも実現することができるので、回線コストの削減が可能となる。3ファイルより細かいブロック単位で適用を行うため、切り替え時にも迅速にサービスを再開することが可能となる。4正サイトに、ログの読み込み位置を決定するための処理、あるいは、通信を新たに加えることなく、副サイトのログ適用部だけで独立してログ適用処理を行い、DBを回復することが可能となる。実施の形態2本発明の実施の形態2におけるDRシステムを、図7~図13を用いて説明する。まず、図7により、本実施の形態におけるDRシステムの構成の一例を説明する。図7はDRシステムの構成の一例を示す図である。本実施の形態のDRシステムは、リモートコピーと連携した読み込みを行う方式を適用する。例えば、不正な読み込みが行われるのは、read/writeが競合する場合である。そのため、本実施の形態のように、リモートコピーと連携した読み込みを行う方式では、ログ適用機能が読み込みを行う時には、リモートコピーによるwriteが生じないようにすることで、read/write競合を回避する。本実施の形態のDRシステムは、前記実施の形態1に対して、正サイトのストレージ120にPull型コピー処理部125が追加され、副サイトのストレージ130にPull型コピー処理部135およびJNLVOLJNL140が追加されて構成される。副サイトのストレージ130に、図8に示すようなJNLVOL140を配置する。図8は、JNLVOLと格納されるデータの構造の一例を示す図である。JNLVOL140には、データ800、シーケンスNO、反映先アドレスおよびサイズからなるメタデータ801、、データ802、メタデータ803が格納され、ポインタ1hptr804がメタデータ801のシーケンスNOを指し、ポインタ2tptr805がメタデータ803のシーケンスNOを指す。このJNLVOL140を副サイトのストレージ130に配置することで、正サイトのログ用VOL128の情報が副サイトのストレージ130のログ用VOL138に2段階のコピーで伝わるようにする。すなわち、1段目のコピーは、正サイトのログ用VOL128から、副サイトのJNLVOL140にコピーする。このとき、JNLVOL140には、データに通し番号やタイムスタンプなどの情報を付加した上で追記されていく。JNLVOL140からログ用VOL138へのコピーPull型コピーは、非同期に行う。また、本実施の形態においては、副サイトのストレージ130の制御プログラムが、このJNLVOL140からのコピーを制御中断/再開するインターフェースを有している。ログ適用機能は、ログを読み込もうとするときには、まず、Pull型コピーを停止状態とする。その結果、ログ用VOL138へのwriteを抑止することができるので、通常の手順で再読み込みをすることなく、ログの読み込み適用を行うことができる。ブロックの読み込みに失敗した場合には、Pull型コピーを再開し、新たな情報をログ用VOL138に反映する。一定時間の経過後、あるいは、Pull型コピーのコピー量がある閾値を超えたら、再びPull型コピーを停止し、ログの読み込み適用を再開する。次に、図9~図11により、本実施の形態のDRシステムにおいて、ログ読み込み適用処理のフローの一例を説明する。それぞれ、図9は平常時一定時間経過、図10は平常時更新量超過、図11は切り替え時のフローの一例を示す図である。図9の説明においては、前記実施の形態1の図4に示したログ読み込み適用処理と異なる部分を主に説明する。このログ読み込み適用処理平常時、一定時間経過では、最初に、Pull型コピーを開始するS901。そして、再読み込みを行う場合と同様に、ログの読み込み位置の決定処理S902、ブロックptrのログ読み込み位置決定S903、を行った後、Pull型コピーを中断してS904、S11へ移行する。Pull型コピーの中断後は、ログの読み込みに成功する限りヘッダ/トレイラ検証に成功する限り、繰り返し適用を行う。S11へ移行したら、FO/停止指示があるか否かの判定S905、ブロックptrの読み込みS906、ブロックptrは整合性があるか否かの判定S907、を行い、整合性がない場合N、すなわち、読み込みに失敗し、これまでに反映済みの部分を読み込み適用済みとなった場合はPull型コピーを再開状態に変更するS908。続いて、一定時間の経過、あるいは、Pull型コピーの反映量が一定量を超過したら、再び、Pull型リモートコピーを中断状態とし、ログ読み込み適用処理を実施する。すなわち、Pull型コピーを再開後、時間ΔtだけsleepしてS909、S10へ戻り、整合性がある場合Yには、ブロックptr-1は未適用か否かを判定するS910。この判定の結果、未適用でない場合Nはptrを1つ進めてS911、S11へ戻り、未適用である場合Yには、ブロックptr-1の適用を行いS912、ptrを1つ進めてS913、S11へ戻る。図10において、ログ読み込み適用処理平常時、更新量超過では、最初に、図9と同様の処理を行いS1001~S1007,S1013~S1016、S1007の判定の結果、ブロックptrは整合性がない場合Nには、時間Tを0にしてS1008、S12へ移行する。S12へ移行したら、ストレージに更新量を問い合わせS1009、更新量が予め定めた定数Pより多いか、あるいは、時間Tが一定時間T1を経過したか否かを判定するS1010。この判定の結果、更新量が定数超過、あるいは、時間が一定時間経過した場合YはPull型コピーを再開してS1011、S10へ戻り、それ以外の場合Nには、時間T2だけsleepしてS1012、S12へ戻る。なお、時間T2に関しては、ストレージへの問い合わせ回数が多くなり過ぎることを防ぐために、2回目以降の問い合わせは、T2<T1時間経過した後に行う。図11において、管理者から、FO/停止指示を受けた場合の処理を説明する。このログ読み込み適用処理切り替え時では、最初に、停止指示かFO指示かを判定しS1101、停止指示であった場合停止は、ログ適用の進捗情報としてptr情報をDB状態ファイルに書き出して処理を終了するS1102。一方、FO指示であった場合FOには、災害FOであるならばリモートコピーの状態を切断状態とし、計画FOであるならば中断状態とする。すなわち、まずリモートコピーの状態制御split時を行うS1103。続いて、ログ適用処理を行う。最初に、Pull型コピーを停止しS1104、ブロックptrを読み込みS1105、整合性があるか否かを判定しS1106、整合性がある限りは適用処理を繰り返す。すなわち、ブロックptr-1は未適用か否かを判定しS1107、未適用でない場合Nはptrを1つ進めてS1108、S13へ戻り、未適用の場合Yには、ブロックptr-1の適用を行いS1109、ptrを1つ進めてS1110、S13へ戻る。一方、整合性がなかった場合Nは、まずJNLVOLに反映すべきデータがあるか否かを判定するS1111。反映すべきデータが残っている場合Yには、Pull型コピーを再開状態にしS1112、ΔtだけsleepしてS1113、S12へ戻り、ログ適用処理を繰り返す。反映するデータがなくなった場合Nには、終端までログ適用したことを確認するS1114。ここで、計画FOである場合には、逆向きのリモートコピーの設定を行う。そして、リモートコピーの状態制御takeover時の実施後S1115、未決着なトランザクションのキャンセル処理を実施するS1116。なお、ログ適用処理で、決着トランザクションだけを適用している場合には、この処理は不要となる。全てのトランザクションが決着した状態になったら、DBMS状態ファイルに情報を書き出しS1117、続いて副DBMSを起動してS1118、処理を終了する。なお、ここでは、ブロックを1個ごとに読み込んでいるが、1度に複数のブロックを読み込んでもよい。複数のブロックを読み込んだ場合は、最後のブロック以前のブロックを適用対象として適用を行う。次に、図12,図13により、本実施の形態のDRシステムにおいて、副ストレージのコピー処理のフローの一例を説明する。それぞれ、図12はリモートコピー、図13はJNLVOLからの反映処理のフローの一例を示す図である。図12において、副ストレージのコピー処理リモートコピーでは、最初に、ポインタ1hptr、ポインタ2tptrを初期化しS1201、反映処理を開始してS1202、S1に移行する。そして、正ストレージから転送があるか否かを判定しS1203、転送がない場合NはS1へ戻り、転送がある場合Yには、追記可能か否かを判定するS1204。この判定の結果、不可能な場合Nはエラー処理/警告処理を行いS1205、可能な場合には、メタデータとデータを登録しS1206、tptrを更新してS1207、S1へ戻る。図13において、副ストレージのコピー処理JNLVOLからの反映処理では、最初に、S1を経て、中断指示があるか否かを判定しS1301、中断指示がない場合NはS2へ移行し、ある場合Yは続いて再開指示があるか否かを判定するS1302。この判定の結果、再開指示がない場合NはS1へ戻り、ある場合YにはS2へ移行する。S2へ移行したら、JNLVOLからポインタ1hptrが指すデータを被更新VOLへ反映しS1303、hptrを更新してS1304、S1へ戻る。以上説明したように、本実施の形態のDRシステムによれば、前記実施の形態1と同様の効果1~4が得られると共に、リモートコピーと連携した読み込みを行う方式を適用することで、ログのIO単位が大きい場合であっても、再読み込み処理/リモートコピー連携処理により、不正読み込みによるDB破壊を防止することが可能となる。従って、広域災害を考慮して副サイトが数百km以上離れた構成にも対応することが可能となる。実施の形態3本発明の実施の形態3におけるDRシステムを、図14を用いて説明する。図14により、本実施の形態におけるDRシステムの構成の一例を説明する。図14はDRシステムの構成の一例を示す図である。本実施の形態のDRシステムは、正サイトと、副サイトと、正サイトと副サイトの間を中継する中継サイトから構成される。正サイトのサーバ100およびストレージ120、副サイトのサーバ110およびストレージ130は、前記実施の形態1の図1、あるいは、前記実施の形態2の図7と同様である。中継サイトは、ストレージ1300から構成され、ストレージ制御処理部1301、ログ用VOL1302、JNLVOL1303が設けられている。正サイトのストレージ120と中継サイトのストレージ1300との間、中継サイトのストレージ1300と副サイトのストレージ130との間は、ネットワーク1304を通じて接続されている。正サイトのストレージ120内のログ用VOL128から中継サイトのストレージ1300内のログ用VOL1302へは第1のコピーであるリモートコピー1305が行われ、副サイトのストレージ130内のログ用VOL138と中継サイトのストレージ1300内のJNLVOL1303との間では第2のコピーであるリモートコピー1306が行われる。本実施の形態のDRシステムにおいても、前記実施の形態1,2と同様の効果を得ることができる。以上、本発明者によってなされた発明を実施の形態に基づき具体的に説明したが、本発明は前記実施の形態に限定されるものではなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。"