JP2006048103A - ディザスタリカバリシステム、プログラム及びデータの複製方法 - Google Patents

ディザスタリカバリシステム、プログラム及びデータの複製方法 Download PDF

Info

Publication number
JP2006048103A
JP2006048103A JP2004223776A JP2004223776A JP2006048103A JP 2006048103 A JP2006048103 A JP 2006048103A JP 2004223776 A JP2004223776 A JP 2004223776A JP 2004223776 A JP2004223776 A JP 2004223776A JP 2006048103 A JP2006048103 A JP 2006048103A
Authority
JP
Japan
Prior art keywords
command
log
database
storage
primary
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Granted
Application number
JP2004223776A
Other languages
English (en)
Other versions
JP4484618B2 (ja
Inventor
Yoshio Suzuki
芳生 鈴木
Nobuo Kawamura
信男 河村
Kota Yamaguchi
浩太 山口
Satoshi Watanabe
聡 渡辺
Shinji Fujiwara
真二 藤原
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Hitachi Ltd
Original Assignee
Hitachi Ltd
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by Hitachi Ltd filed Critical Hitachi Ltd
Priority to JP2004223776A priority Critical patent/JP4484618B2/ja
Priority to US10/930,832 priority patent/US7529964B2/en
Publication of JP2006048103A publication Critical patent/JP2006048103A/ja
Application granted granted Critical
Publication of JP4484618B2 publication Critical patent/JP4484618B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/16—Error detection or correction of the data by redundancy in hardware
    • G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
    • G06F11/2097—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements maintaining the standby controller/processing unit updated
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14—Error detection or correction of the data by redundancy in operation
    • G06F11/1402—Saving, restoring, recovering or retrying
    • G06F11/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)

Abstract

【課題】トランザクションレベルで整合性の取れたバックアップを作成し、副サイトで業務を提供することでＤＲシステムの付加価値を高め、副サイトの運用を宵にする。
【解決手段】正ＤＢ１０７の更新差分を含むログ１０６により副ＤＢ１１７の回復を行い、また、ログ１０６にコマンドを加えて、副サイト２でログを解析してコマンドを実行する。ログ経由で運用コマンドを転送実行することで、副サイト２での運用コマンド実行をトランザクション整合性のとれたＤＢに対して、正サイト１と同一または意図したタイミングで実施する。コマンドがスナップショットの作成指示の場合、副ストレージ装置１１３を構成するミラーセット３５０の複数のボリュームをペア状態として各ボリュームに副ＤＢ１１７を書き込んで同期させ、この同期完了後に、ミラーセット３５０をスプリット状態とすることで副ＤＢ１１８を保存する。
【選択図】図１

Description

本発明は、ディザスタリカバリシステムの改良に関し、特に、データベースに適したディザスタリカバリシステムに関する。
近年、ＩＴシステム（Information Technology）システムはビジネスにとって欠かせなくなっており、障害や災害であってもビジネスを継続することはますます重要になっている。ＩＴシステム停止に伴う機会損失は莫大なものになり、例えば、金融業や大企業では数百万ドルにもなるといわれている。このような背景から、データベースを可動可能な正／副の２つのサイトを用意し、平常時から副サイトへ業務データをバックアップし、災害時には副サイトで業務を継続するディザスタリカバリ（以下、ＤＲ）システムが注目を集めている。
ＤＲシステムでは、平常時から正サイトと副サイトにそれぞれデータベース（以下、ＤＢ）サーバとストレージ装置を備える。このため、正副サイトの構築並びに管理コスト、回線コストなど、ＤＲシステムを構築し、維持するには非常に多くの費用を要する。しかし、実際に災害が生じる確立は全障害のうち数％とも言われており、業務の効率化やコストの削減が望まれる近年では、ＤＲシステムにも付加価値が求められている。
このような付加価値の一例としては、ＤＲシステムを高度化したRolling Disasterに対応するバックアップシステムがある。
Rolling Disasterは、災害発生時にシステム構成要素が同時に破壊されるのではなく、各構成要素がそれぞれ異なるタイミングで徐々に破壊されていくことを示す。したがって、災害発生時点以降もデータの更新が正サイトから副サイトへ転送されてしまい、バックアップされた副サイトのデータに整合性の取れない可能性が生じる。
このようなRolling Disasterに対処するため、データベースの最新のＰｉＴ（Point in Time）イメージに加えて、災害が生じる前のＰｉＴイメージを保存するものが知られている（例えば、非特許文献１）。
これは、副サイトに第１ボリュームと第２ボリュームを設け、正サイトがタイマによりリモートコピーの中断／復帰を繰り返し、副サイトはリモートコピーを受信すると第１ボリュームに記録し、リモートコピーの中断時には副サイトが正サイトに障害がないことを確認してから第１ボリュームから第２ボリュームへデータをコピーして、その時点のＰｉＴイメージを作成する。そして、正サイトがリモートコピーを復帰すると、副サイトは第１ボリュームへデータを書き込む。これにより、副サイトには必ず、最新の世代のバックアップ（第１ボリューム）と、１世代前のバックアップ（第２ボリューム）が保存され、万一、Rolling Disasterにより第１ボリュームに書き込みが行われたとしても、第２ボリュームに保存された１世代前のバックアップで復旧することができる。
ＤＲシステムの付加価値を与える他の一例としては、正サイトに比して負荷の低い副サイトで、バックアップに加えてＤＢの検索処理を行うものが知られている（例えば、非特許文献２）。
これは、正サイトと副サイトにそれぞれＤＢＭＳ（Data Base Management System）とストレージ装置を設け、正副サイト間をサーバ間ネットワークのみで接続する。そして、正サイトのＤＢＭＳは、ストレージ装置にデータを書き込むのと同時に、副サイトのＤＢＭＳにログを転送する。副サイトのＤＢＭＳは、受信したログをストレージ装置に書き込む。そして、副サイトでは、検索処理等の業務を行っていないときに、ストレージ装置に書き込んだログを副サイトのＤＢに適用し、ＤＢを更新する。
Claus Mikkelsen、「The Hitachi NanoCopy Advantage」、第９頁〜第１１頁、[online]、「平成１６年７月１６日検索」、インターネット＜http://www.hds.com/pdf/wp134_nanocopy.pdf＞ 「Oracle Data Guard」、「Overview of Oracle Data Guard Functional Components」、[online]、「平成１６年７月１６日検索」、インターネット＜http://otn.oracle.com/deploy/availability/htdocs/DataGuardOverview.html＞
しかしながら、前者の従来例（非特許文献１）では、所定の時間間隔で１世代前のバックアップを取得するため、災害発生の直前のデータをバックアップするのが難しい、という問題がある。さらに、副サイトでは第１及び第２ボリュームでボリュームベースのコピーを行うため、保存されたバックアップは、トランザクションレベルでの整合性は保証されていない。このため、副サイトのバックアップでＤＢを稼動させるには、トランザクションの整合性を回復する処理が必要となって、ＤＢの復旧に時間を要するという問題がある。
また、後者の従来例では、平常時から副サイトでＤＢＭＳを稼動させておき、正サイトからのログを副サイトのＤＢへ適用することで、ＤＢの回復を行い、さらに、検索処理を実行することで、ＤＲシステムの付加価値を高めようとしている。しかし、ログ適用を行う場合には検索処理を中断する必要があり、常時業務を提供することはできない、という問題がある。これは、ログ適用によってＤＢを回復しても、上述のようにトランザクションレベルでの整合性を保証しているわけではないからである。トランザクションレベルでの整合性を確保するには、ログをトランザクションレベルで解析する処理が必要になり、上記ログ適用と平行して実行することはできない。
そこで本発明は、上記問題点に鑑みてなされたもので、トランザクションレベルで整合性の取れたバックアップを作成して、データの欠損なしでデータベースの回復を行うことを目的とし、さらに、副サイトの運用を容易にし、副サイトで業務を提供することでＤＲシステムの付加価値を向上することを目的とする。
本発明は、第１の系で実行する第１のデータベースを、第２の系に設けた第２のストレージに格納される第２のデータベースに複写するデータの複製方法であって、前記第１のデータベースの更新差分のログを第１のストレージに記録する処理と、前記第１のデータベースの更新差分を第１のストレージに書き込む処理と、前記第１または第２の系に対する運用コマンドを前記ログに追加する処理と、前記更新差分及びコマンドを含むログを前記第２の系へ転送する処理と、前記転送された前記ログを前記第２のストレージに格納する処理と、前記第２のストレージのログを読み込んで、前記更新差分のログに基づいて第２のデータベースを回復する処理と、前記第２のストレージのログから前記コマンドを抽出する処理と、前記抽出したコマンドを実行する処理と、を含んで、ログを介して第２系を制御する。
また、前記コマンドをログに追加する処理は、第２の系でスナップショットの作成を指示するスナップショット作成コマンドをログに追加する処理を含み、前記抽出したコマンドを実行する処理は、前記抽出したコマンドがスナップショット作成コマンドであるときには、前記第２のストレージを構成するミラーセットの複数のボリュームをペア状態として各ボリュームに前記第２のデータベースを書き込んで同期させる処理と、前記同期が完了した後に、前記ミラーセットをスプリット状態として第２のデータベースを保存する。
また、スナップショットの作成時には、第１及び第２のデータベースの静止化を行う。
なお、運用コマンドは、スナップショットだけでなく、ＤＢＭＳやＯＳ、アプリケーションのコマンドでもよい。
したがって、本発明は、第１のデータベースの更新差分を含むログにより第２のデータベースの回復を行い、欠損なしでデータベースの回復を実現しながら、ログにコマンドを加えることで、第１の系から第２の系を制御することができる。
また、ログ適用で運用コマンドの転送・実施を行うため、データベースに対して正副サイト（第１の系及び第２系）でトランザクション整合性の取れた同一状態のデータベースに対して同一のタイミングで運用コマンドを実行できる。
スナップショット生成に用いた場合、スナップショットの作成指示があると、第２のストレージを構成するミラーセットの複数のボリュームをペア状態として各ボリュームに第２のデータベースを書き込んで同期させ、この同期完了後に、ミラーセットをスプリット状態とすることで第２のデータベースを保存することができる。このように保存した第２のデータベースは、第１の系とは独立して第２の系で利用することができるので、構築及び運用にコストのかかるディザスタリカバリシステムの付加価値を高めることができる。
特に、第１及び第２のデータベースを静止化することで、トランザクションレベルで整合性の取れたバックアップ（スナップショット）を容易に作成することができる。
以下、本発明の一実施形態を添付図面に基づいて説明する。
図１は、本発明で用いられる典型的なシステム図を示し、２つのサイト（系）でディザスタリカバリを行う一例を示す。
図１において、正サイト（第１の系）１は、正ＤＢＭＳ（DataBase Management System）１０１が稼動する正サーバ１００と、正ＤＢＭＳ１０１に管理される正データベース１０７を格納する正ストレージ装置１０３を主体に構成される。
副サイト（第２の系）２は、副ＤＢＭＳ１１１が稼動する副サーバ１１０と、副ＤＢＭＳ１１１に管理される副データベース１１７、１１８を格納する副ストレージ装置１１３と、副ＤＢＭＳ１１１のＤＢＭＳ機能の一部（ログ適用＝データベース回復機能）をオフロード（分割）したサブセットとしてのＤＢ・ストレージ管理部３００を実行する専用装置（中間装置）４００を主体に構成される。なお、専用装置４００は、副サーバ１１０と副ストレージ装置１１３の間に配置され、図示しないＣＰＵ及びメモリを備える。
そして、正サイト１と副サイト２は、正サーバ１００と副サーバ１１０を接続するサーバ間ネットワーク１２１と、正ストレージ装置１０３と副ストレージ装置１１３を接続するストレージ間ネットワーク１２０とを介して、サーバとストレージ装置が独立して接続される。そして、正ストレージ装置１０３は、更新のあったデータ（正ＤＢ１０７のログ）を副ストレージ装置１１３へ転送し、副サイト２では、副ストレージ装置１１３が正サイト１の正データベース（ＤＢ）１０７のバックアップを保存する。
サーバ間ネットワーク１２１には、正副サイト１、２を管理する管理装置２００と、正ＤＢＭＳ１０１または副ＤＢＭＳ１０１にアクセスするクライアントコンピュータ２５０が接続される。
管理装置２００は、例えば、監視プログラム（図中Ｍｏｎｉｔｏｒ）５０１が実行されるサーバなどの計算機で構成され、正サーバ１００のハートビートの検出や、正ストレージ装置１０３の障害情報などから正サイト１の障害を検出し、障害検出時には副サイト２のＤＢ・ストレージ管理部３００や副サーバ１１０へフェイルオーバを指令し、副サイト２へ業務を引き継ぐ。
クライアントコンピュータ２５０は、例えば、業務プログラム（図中ＵＡＰ＝ユーザアプリケーション）５００が実行される計算機で構成される。クライアントコンピュータ２５０の業務プログラム５００は、平常時には正ＤＢ１０７の参照・更新処理について正ＤＢＭＳ１０１にアクセスする。また、正ＤＢ１０７の検索・参照業務については副ＤＢＭＳ１１１にアクセスすることもできる。
正サイト１に障害が発生した場合には、クライアントコンピュータ２５０の業務プログラム５００は、正ＤＢ１０７の更新処理及び検索・参照業務等全ての処理について副ＤＢＭＳ１１１にアクセスする。
正サイト１は、正サーバ１００と正ストレージ装置１０３から構成される。正サーバ１００には、図示しないＣＰＵ、メモリを備えており、正ＤＢ１０７の正ＤＢＭＳ１０１がインストールされており、この正ＤＢＭＳ１０１がクライアントコンピュータ２５０、管理装置２００から業務を受け付ける。
正ＤＢＭＳ１０１は、正サーバ１００のメモリ上にあるＤＢバッファ１０２と正ストレージ装置１０３を用いて正データベース（ＤＢ）１０７を管理する。
正ＤＢ１０７は正ストレージ装置１０３のディスク装置１３０に格納されるが、更新がある度に正ストレージ装置１０３にアクセスすると正ＤＢＭＳ１０１の処理速度が低下するため、通常はＤＢバッファ１０２上で更新処理を行う。
正ＤＢＭＳ１０１は、正ＤＢ１０７のトランザクション（Ｔｒ）がコミットされた場合、あるいは、ＤＢバッファ１０２があふれた場合など、予め設定したタイミングで正ＤＢ１０７の更新を正ストレージ装置１０３に反映する。
正ストレージ装置１０３は、キャッシュ１０５、ディスク制御プログラム１０４、制御装置（図示省略）、複数のディスク装置１３０、１３１、これらディスク装置に設定された複数のボリュームより構成される。それぞれのボリュームには、正ＤＢ１０７のデータ本体が格納され、また、データ（正ＤＢ１０７）への更新差分の情報を有するログ１０６が格納される。なお、正ストレージ装置１０３の制御装置は、図示しないＣＰＵ、メモリを備える。
正ストレージ装置１０３の制御装置で実行されるディスク制御プログラム１０４は、ストレージ間ネットワーク１２０を介して副サイト２の副ストレージ装置１１３との間でリモートコピーを制御する。ここでは、ログ１０６のみを同期リモートコピー、あるいは、非同期リモートコピーで転送する。
つまり、正ＤＢＭＳ１０１は、ＤＢバッファ１０２の内容を正ストレージ装置１０３の正ＤＢ１０７に書き込む（更新する）前に、書き込んだデータの更新差分を示すログ１０６を生成して正ストレージ装置１０３に書き込む。ディスク制御プログラム１０４は、新たに追加されたログ１０６を、上記のような所定のタイミングで副ストレージ装置１１３へストレージ間ネットワーク１２０を介して転送する。
副サイト２は、副サーバ１１０、副ストレージ装置１１３、および、副ＤＢＭＳ１１１の一部分の機能（例えば、ログ適用機能）を含むＤＢ・ストレージ管理部３００を実行する専用装置４００から構成される。
ここで、専用装置４００は、ＤＢ・ストレージ管理部３００を実行可能な処理能力を備えた計算機であればよく、副ＤＢＭＳ１１１を実行可能な処理能力を必要とせず、副サーバ１１０に比して処理能力の低い計算機で構成することができる。
副サーバ１１０の副ＤＢＭＳ１１１は、後述するように、平常時には副ストレージ装置１１３にバックアップ（スナップショット）された副ＤＢ１１８を用いて、クライアントコンピュータ２５０に検索・参照業務を提供する。そして、正サイト１に障害が発生した場合には副ＤＢＭＳ１１１が正ＤＢＭＳ１０１を引き継いで業務を行う。
副ストレージ装置１１３は、リモートコピー機能を有するディスク制御プログラム１１４、キャッシュ１１５、複数のディスク装置で構成されたローカルミラーセット３５０を備える。
副ストレージ装置１１３は複数のディスク装置３０１、３０２、３０３を備え、ディスク装置３０３に形成されたボリュームにはリモートコピーにより保存された正ＤＢＭＳ１０１が管理するログ１１６が保存される。
ディスク装置３０２、３０３はローカルミラーセット３５０を構成しており、ディスク装置３０２、３０３に設定された複数のボリュームには、最新の正ＤＢ１０７のバックアップ１１７（図中ｉ世代）と、直前の正ＤＢ１０７のバックアップ１１８（図中ｉ−１世代）がそれぞれ保存される。なお、ここでは、ディスク装置３０２、３０３がそれぞれ一つのボリューム３１０、３２０を有するものとする。なお、本実施形態ではボリューム３１０がプライマリボリュームであり、ボリューム３２０がセカンダリボリュームとする。
このローカルミラーセット３５０は、ＤＢ・ストレージ管理部３００からの指令に基づいてディスク制御プログラム１１４がミラーリングのペア関係をスプリット（分割）し、ボリューム間の同期を停止した状態で、単独のボリューム３１０、３２０としてそれぞれ書き込み／読み込み制御を行うことができ、また、スプリットを終了してペア状態にすれば、プライマリのボリューム３１０からセカンダリのボリューム３２０へミラーリングが行われる。
正サイト１の正ＤＢ１０７のバックアップは、通常、ボリューム３１０、３２０をスプリットした状態にしておき、ボリューム３１０のみに最新のバックアップ１１７を保存する。
そして、所定のタイミング（管理者や管理装置２００の監視プログラム５０１からの要求など）になると、ＤＢ・ストレージ管理部３００は、ローカルミラーセット３５０をペア状態に復帰させ、ボリューム３１０の内容をボリューム３２０にコピーして２つのボリューム３１０、３２０の同期を取る。この同期により、ボリューム３２０のバックアップ１１８は、最新の内容（世代）に更新される。このとき、ＤＢ・ストレージ管理部３００は、バックアップされたログ１１６を読み込んで、バックアップされた副ＤＢ１１７の全てのＴｒを決着させておく。この後、ミラーリングを行うことにより、コピーされるボリューム３２０の内容（副ＤＢ１１８）は、トランザクションの整合性の取れた正ＤＢ１０７のスナップショットとなり、副ＤＢＭＳ１１１で実行される検索・参照業務の内容を保証することができる。なお、本実施形態では、管理装置２００の監視プログラム５０１が、所定の周期で正サイト１にスナップショットの作成を要求する場合を示す。
その後、ＤＢ・ストレージ管理部３００は、ボリューム３１０、３２０を再びミラーリングをスプリットした状態にしておき、ボリューム３１０のみへ最新のバックアップ１１７を保存する。したがって、次回のミラーリング時まで、ボリューム３２０の内容はリモートコピーによって更新されることはなく、トランザクションレベルで整合性のとれた直前のスナップショットとしての副ＤＢ１１８を維持することができる。
正ストレージ装置１０３からリモートコピーは、正ＤＢ１０７の更新差分の情報と正ＤＢＭＳ１０１からのコマンドを含むログ１１６のみが、正ストレージ装置１０３から副ストレージ装置１１３へリモートコピー機能により転送される。
上述したようにリモートコピーは、同期リモートコピーであっても、非同期リモートコピーであってもよい。同期リモートコピーの場合は、副ストレージ装置１１３への書き込みが完了して初めて正ストレージ装置１０３への正ＤＢ１０７のデータの書き込みが完了するために、災害や障害が生じても欠損なくデータがコピーされることが保証される。
しかし、書き込みの度にサーバ間ネットワーク１２１の回線遅延が付加されるため、正ＤＢＭＳ１０１で行う業務への影響が無視できない。一方、非同期リモートコピーを用いた場合は、副ストレージ装置１１３への転送が行われる前に正ストレージ装置１０３へのデータの書き込みが完了したとみなして処理を継続するため、正ＤＢＭＳ１０１への影響は最小減に抑えられる。ただし、副ストレージ装置１１３への書き込みが完了する前に災害が生じた場合には、欠損が生じてしまう。
リカバリの開始時以降は、副ＤＢ１１７はリモートコピーではなく、ログ適用により回復される。このログ適用は、副ストレージ装置１１３と副サーバ１１０の間に配置される専用装置４００により実行される。
この専用装置４００には、副ＤＢＭＳ１１１の一機能であるログ適用機能が副ＤＢＭＳ１１１のサブセットとしてＤＢ・ストレージ管理部３００としてオフロードされている。専用装置４００は、ログ適用だけを行えばよいため、処理能力が低く、安価な計算機で実現可能となる。従って、平常時は、この専用装置４００のみあればよく、検索・参照業務を行わない場合では副サーバ１１０を設置する必要がないことから、より安価なコストでＤＲシステムを構築することが可能となる。
また、サブセットとしてのＤＢ・ストレージ管理部３００は、機能が限定されているため、フル機能を持つ副ＤＢＭＳ１１１の場合に比べて複雑な管理を行う必要がなく、運用管理面でも低コスト化が可能となる。
また、上記図１では、副サイト２にのみ専用装置４００があるが、正サイト１にも専用装置を配置してもよい。例えば、系（サイト）の切り替え処理は、災害時だけでなく、計画的に行う場合もある。その場合は、正サイト１と副サイト２の役割を入れ替え、副サイトで業務を行うとともに、正サイトで回復処理を行う必要がある。その場合は、ログ１０６、１０７のリモートコピーのコピー元とコピー先を入れ替えると共に、正サイトの専用装置で正ＤＢ１０７を回復する必要がある。
＜正ＤＢＭＳ１０１のソフトウェア構成＞
正サイト１の正ＤＢＭＳ１０１のソフトウェア構成を図２に示す。
正ＤＢＭＳ１０１は、クライアントコンピュータ２５０の業務プログラム５００からの要求を受け付けるトランザクション受付部５０２と、処理するトランザクションの整合性を確認し、実行するトランザクション管理部５０３と、ＤＢバッファ１０２または正ストレージ装置１０３への更新、参照を行うＤＢ管理部５０５と、ＤＢ管理部５０５が実行する更新差分をログとして生成するとともに、ＤＢ１０７や副サイト２の副ＤＢ１１７、１１８を制御するための運用コマンドをログとして生成する管理部５０４と、管理装置２００の監視プログラム５０１等からの要求をコマンドとして受け付けて、正ストレージ装置１０３または副サイト２の副ストレージ装置１１３を制御する運用コマンド実行管理部５０６とから構成される。
運用コマンド実行管理部５０６は、管理装置２００等からスナップショット作成などの要求を受け付ける運用コマンド受付部５０７と、受け付けた運用コマンドの実行を制御する運用コマンド管理部５０８と、運用コマンドに基づいて正ストレージ装置１０３における制御指令をディスク制御プログラム１０４に送信する運用コマンド発行部５０９とから構成される。なお、運用コマンドは、ＤＢＭＳ、ＯＳ、アプリケーションのコマンドでも良く、この場合はＤＢＭＳ、ＯＳ、アプリケーションに対してコマンドを発行する。
運用コマンド管理部５０８は、受け付ける運用コマンドの実行時期を制御するため、トランザクション管理部５０３にトランザクションの決着状態を問い合わせ、運用コマンドの実行に必要な指令を運用コマンド発行部５０９に送る。そして、運用コマンド管理部５０８は、受け付けた運用コマンドが正サイト１だけではなく、副サイト２でも行う必要がある場合には、当該運用コマンドをログ１０６に含めるようにトランザクション管理部５０３に指令し、トランザクション管理部５０３はこの運用コマンドをログ管理部５０４に送って、ログ１０６に運用コマンドを書き込む。
例えば、受け付けた運用コマンドがスナップショット作成である場合、運用コマンド管理部５０８は、トランザクション管理部５０３に対して全てのトランザクションが決着しているか否かを問い合わせる。
決着していないトランザクションがあれば、運用コマンド管理部５０８は、全てのトランザクションを強制的に決着させる静止化を実施する。
静止化が完了すると、運用コマンド管理部５０８は、静止化コマンドの後に、スナップショット作成コマンドをログ１０６に書き込むよう、トランザクション管理部５０３に指令する。
トランザクション管理部５０３はログ管理部５０４に指令して、静止化コマンド、スナップショット作成の順にログ１０６を作成し、ディスク制御プログラム１０４に書き込みを依頼する。
ディスク制御プログラム１０４は、所定のタイミング（周期またはログ１０６の更新時）でリモートコピーを行っており、正ＤＢ１０７の更新差分の情報と、運用コマンドを含むログ１０６は、副サイト２の副ストレージ装置１１３へ転送され、副サイト２では、バックアップされたログ１１６を解析することで、正ＤＢ１０７のバックアップと、正ＤＢＭＳ１０１からの運用コマンドを実行する。
＜副サイト２のＤＢ・ストレージ管理部のソフトウェア構成＞
図３に、副サイト２のＤＢ・ストレージ管理部３００を主体とするソフトウェアの構成を示す。
ＤＢ・ストレージ管理部３００は、正サイト１からバックアップされたログ１１６を読み込んで監視を行うログ監視部３６０と、ログ監視部３６０が読み込んだログ１１６が、正ＤＢ１０７の更新差分を示すログであれば、このログをボリューム３１０の副ＤＢ１１７に適用するようにＤＢ管理部３６２へ指示し、また、読み込んだログ１１６が運用コマンドであれば、運用コマンド実行管理部６００に送るトランザクション管理部３６１と、ログ１１６をボリューム３１０の副ＤＢ１１７に適用して副ＤＢ１１７を更新するＤＢ管理部３６２とを備える。なお、トランザクション管理部３６１は、クライアントコンピュータ２５０の業務プログラム５００や管理装置２００の監視プログラム５０１からの要求を受け付けることも可能である。
運用コマンド実行管理部６００は、トランザクション管理部３６１が解析した運用コマンドの実行を制御する運用コマンド管理部６０１と、運用コマンドに基づいて副ストレージ装置１１３への制御指令をディスク制御プログラム１１４に送信する運用コマンド発行部６０２とから構成される。
運用コマンド管理部６０１は、受け付ける運用コマンドの実行時期を制御するため、トランザクション管理部３６１にトランザクションの決着状態を問い合わせ、運用コマンドの実行に必要な指令を運用コマンド発行部６０２に送る。そして、運用コマンド管理部６０１は、運用コマンドの実行の実行結果をトランザクション管理部３６１に問い合わせ、異常があれば管理装置２００の監視プログラム５０１へ送信し、異常を報知する。
例えば、ログ１１６に静止化コマンドに続いて、スナップショット作成の運用コマンドが含まれていた場合、運用コマンド管理部６０１は、運用コマンド発行部６０２へ、静止化が行われているか（トランザクションの整合性が取れているか）を確認する。
運用コマンド管理部６０１は、トランザクション管理部３６１に全てのトランザクションが決着したか（静止化が完了したか）を問い合わせ、完了していれば、運用コマンド発行部６０２へスナップショット作成コマンドを指令する。
運用コマンド発行部６０２は、ディスク制御プログラム１１４にミラーセット３５０のスプリットを終了し、ペア状態としてミラーリングを行うように指令する。これにより、トランザクションが完全に決着した状態の副ＤＢ１１７が副ＤＢ１１８としてボリューム３２０へバックアップされ、正ＤＢＭＳ１０１が静止化コマンドをログ１０６に書き込んだ時点のスナップショットが副ＤＢ１１７、ＤＢ１１８に作成される。
スナップショットの作成が完了すると、運用コマンド管理部６０１は、ローカルミラーセット３５０のペア状態を終了して、スプリットするように運用コマンド発行部６０２を介してディスク制御プログラム１１４に指令し、ある時点（ＰｉＴ）のスナップショットをボリューム３２０に保存する一方、ボリューム３１０の副ＤＢ１１７の更新を再開する。
＜正サイト１の処理＞
図４は正サイト１の正ＤＢＭＳ１０１で行われる処理の一例を示すフローチャートである。正サイト１では、正ＤＢＭＳ１０１が主体となって、正ＤＢ１０７の管理を行う。なお、正ストレージ装置１０３のリモートコピーは、上述のようにディスク制御プログラム１０４が所定のタイミングで行うものとする。
まず、Ｓ３では、正ＤＢＭＳ１０１は、クライアントコンピュータ２５０の業務プログラム５００等からの要求（正ＤＢ１０７への更新要求）を受け付ける。
次に、管理装置２００の監視プログラム５０１から正ＤＢＭＳ１０１に運用コマンドが入力されたか否かを判定する。
運用コマンドが入力されていない場合には、Ｓ５に進み、正ＤＢ１０７の更新内容に対応するログを生成し、Ｓ６でディスク装置１３１のログ１０６に書き込む。その後、Ｓ７でＤＢバッファ１０２または正ストレージ装置１０３の正ＤＢ１０７に書き込みを行い、再びＳ１に戻る。
上記Ｓ５からＳ７の通常の更新処理では、ログ１０６が生成された後に、実際の書き込みが行われ正ＤＢ１０７が更新される。そして、生成されたログ１０６は、上述したように、ディスク制御プログラム１０４によって所定のタイミングで副ストレージ装置１１３にリモートコピーされる。
一方、上記Ｓ４の判定で、運用コマンドが入力されていない場合には、Ｓ８に進んで運用コマンドの内容を解析する。
運用コマンドには、正サイト１、副サイト２のＤＢへ共に適用するものと、正サイト１のみに適用するもの、副サイト２のみに適用するものに分けられる。
正サイト１及び副サイト２で共に適用する運用コマンドとしては、ＤＢＭＳのパラメータ変更、正ＤＢ１０７と副ＤＢ１０８のファイルの拡張コマンドなどである。
正サイト１のみに適用する運用コマンドとしては、正ＤＢＭＳ１０１の性能測定コマンドなどがあり、また、副サイト２のみに適用する運用コマンドとしては、副ＤＢＭＳ１１１の性能測定コマンドやスナップショット生成コマンドなどがある。
次に、Ｓ９では、上記Ｓ８で解析した運用コマンドの種別に基づいて、処理フラグを設定する。処理フラグは、例えば、０＝正副共通、１＝正サイトのみ、２＝副サイトのみ、等に設定すればよい。そして、運用コマンドにこの処理フラグを付加する。
次に、正ＤＢＭＳ１０１は、運用コマンドを実行するに当たって、トランザクションを決着する必要があるか否かを判定する。例えば、スナップショット作成コマンドやファイルサイズの変更など、正ＤＢ１０７の内容にクリティカルなコマンドは、トランザクションを決着する必要がありと判定し、性能測定など、正ＤＢ１０７の内容に係わらないコマンドは、トランザクションの決着は不要と判定する。
トランザクションの決着が不要な場合には、Ｓ２からＳ１１ヘ進み、運用コマンドを実行する。運用コマンドの実行後、Ｓ１２では、運用コマンドを適用した処理が正常に終了したか否かを判定する。
運用コマンドが正常に終了した場合には、Ｓ１３に進んで運用コマンドの処理フラグが正サイト１のみ（処理フラグ＝１）であるかを判定し、正サイト１のみに適用する運用コマンドの場合には、ログ１０６に書き込まず、運用コマンドを破棄して、そのままＳ１に戻る。あるいは、副サイト２で実施不要との情報を加えた上で、ログに書き込んでも良い。
一方、運用コマンドの処理フラグが共通または副サイト２のみに適用する場合では、ログ１０６を介して副サイト２へ伝達する必要があるので、Ｓ１４に進んで運用コマンドに対応するログを生成し、Ｓ１５でログ１０６をディスク装置１３１に書き込んだ後、Ｓ１へ戻る。ログ１０６に書き込まれた運用コマンドは、リモートコピーによって副サイト２の副ストレージ装置１１３に転送され、副サイト２のＤＢ・ストレージ管理部３００により解釈され、実行される。
上位機Ｓ１２の判定で、運用コマンドが正常に終了しなかった場合には、Ｓ１６に進んでエラーを出力する。このエラーは、運用コマンド実行管理部５０６から管理装置２００へ通知することができる。また、このエラーをログ１０６に書き込んで、副サイト２へ伝達するようにしても良い。エラーを出力した後にはＳ１に戻る。
次に、上記Ｓ１０の判定で、運用コマンドの実行に際してトランザクションの決着が必要な場合には、Ｓ１８に進んで正ＤＢ１０７の静止化を行う。静止化によりすべてのトランザクションが決着した後に、Ｓ２へ進んで運用コマンドを実行する。
なお、上記Ｓ１７で未決着のトランザクションがない場合には、Ｓ２へ進み運用コマンドを実行する。
以上の処理により、運用コマンドが入力されていない場合には、正ＤＢ１０７の更新要求に応じてログ１０６を生成した後に、ＤＢバッファ１０２または正ストレージ装置１０３へ書き込みを行う。運用コマンドが入力された場合には、運用コマンドの内容に応じてトランザクションを決着する必要性を判定し、必要な場合には静止化を行ってから運用コマンドを実行する。
そして、運用コマンドの実行後は、正サイト１のみに適用する運用コマンドを除いてログ１０６に書き込み、ログ１０６を介して副サイト２へ運用コマンドを伝達する。
＜副サイトの処理＞
図５は副サイト２のＤＢ・ストレージ管理部３００で行われる処理の一例を示すフローチャートである。副サイト２では、ＤＢ・ストレージ管理部３００が主体となって、副ＤＢ１１７の更新と、スナップショットの作成を行う。なお、副ＤＢＭＳ１１１は、クライアントコンピュータ２５０の業務プログラム５００からの検索・参照要求を受け付けるが、これについては周知の処理であるので、ここでは詳述しない。
副サイト２のＤＢ・ストレージ管理部３００は、まず、Ｓ２０で初期化処理を行う。この初期化処理は、副サイト２にバックアップされたログ１１６をどこから読み込むか、読み込み位置の設定などを行う。なお、読み込み位置は前回の終了位置などに応じて決定する。
次に、Ｓ２１、Ｓ２２では、管理装置２００の監視プログラム５０１やクライアントコンピュータ２５０の業務プログラム５００からバックアップの終了指示を受け付けたか否かを判定する。終了指示があった場合には、Ｓ２３で所定の後処理（変数やバッファのクリアなど）を行ってから終了する。
終了指示がなければ、Ｓ２４からＳ２５へ進んで、ログ１１６の終端まで読み込んだか否かを判定する。終端まで読み込んでいる場合には、Ｓ２１へ戻ってログ１１６が追加されるまでループを繰り返す。
一方、ログ１１６の終端まで読み込んでいない場合には、Ｓ２６に進んでログ１１６を読み込む。そして、Ｓ２７では、読み込んだログ１１６を解析し、正ＤＢ１０７の更新差分のログと、運用コマンドのログに分ける。
Ｓ２８では、解析したログ１１６が運用コマンドであるか否かを判定する。運用コマンドでない場合、つまり、更新差分のログの場合には、Ｓ２９へ進んで、プライマリボリューム３１０の副ＤＢ１１７にログ１１６の適用を行って更新し、Ｓ３０では更新したトランザクションの決着状態を管理する。そして、Ｓ２４へ戻って、ログ１１６の終端に達するまでログ１１６の読み込みを繰り返す。
一方、Ｓ２８の判定で、読み込んだログ１１６が運用コマンドの場合には、Ｓ３１に進んで、運用コマンドを実行する。運用コマンドが正常に終了すれば、Ｓ３２からＳ２４へ進んで次のログ１１６を読み込み、運用コマンドの実行で異常が発生した場合には、Ｓ３３に進んでエラーを出力して処理を中断する。なお、エラーの出力は、管理装置２００やクライアントコンピュータ２５０にエラーが生じたことを通知すればよい。また、中断後は、管理者により処理の復旧を行う。
＜スナップショットの作成＞
以上のように、正サイト１の正ＤＢＭＳ１０１と副サイト２のＤＢ・ストレージ管理部３００により、管理装置２００の監視プログラム５０１からスナップショット作成要求があると、まず、正サイト１の正ＤＢ１０７を静止化して、全てのトランザクションを決着させる。
そして、静止化の完了後に、静止化コマンドとスナップショット作成コマンドをログ１０６に書き込む。ログ１０６は、ディスク制御プログラム１０４により副サイト２の副ストレージ装置１１３へリモートコピーされる。
副サイト２ではＤＢ・ストレージ管理部３００が、バックアップされたログ１１６を読み込んで、副ＤＢ１１７にログ適用を行って正ＤＢ１０７と同期を取る。
ログ１１６に書き込まれた静止化コマンド及びスナップショット作成コマンドは順次、ＤＢ・ストレージ管理部３００で解釈され、静止化コマンドの場合は、副ＤＢ１１７の静止化を確認する。その後、スナップショット作成コマンドにより、ローカルミラーセット３５０をペア状態にして、プライマリボリューム３１０の副ＤＢ１１７を、セカンダリーボリューム３２０に書き込んで、副ＤＢ１１８とする。
この時点で、副ＤＢ１１８は、正ＤＢＭＳ１０１が静止化コマンドを発行した時点の正ＤＢ１０７の内容となり、さらに、全てのトランザクションは決着状態となっているので、副ＤＢ１１８を用いて副ＤＢＭＳ１１１が提供する検索・参照業務の内容は保証される。そして、正サイト１に障害が発生してフェイルオーバにより副サイト２へ業務を引き継ぐ際には、全てのトランザクションが決着した副ＤＢ１１８を用いることで、特別な回復処理を行うことなく、副ＤＢＭＳ１１１による業務の再開を迅速に行うことができる。すなわち、前記従来例のようにブロックレベルのバックアップのように、トランザクションの整合性を回復する必要がなく、即座に正サイト１から副サイト２へ切り換えを行うことができるのである。
そして、スナップショットの作成が完了した後には、ローカルミラーセット３５０を再びスプリット状態とし、プライマリボリューム３１０の副ＤＢ１１７でログ適用によるバックアップを継続することができる。
なお、副ＤＢＭＳ１１１では、検索・参照機能を提供する例を示したが、副ストレージ装置１１３のローカルミラーセット３５０は、スナップショットの作成時以外はスプリット状態としているため、ログ１１６を適用するプライマリのボリューム３１０とセカンダリーのボリューム３２０は独立しているため、セカンダリーボリューム３２０の副ＤＢ１１８を用いて、更新業務を提供することも可能である。この場合、正サイト１の正ＤＢ１０７との整合性は取れなくなってしまうが、例えば、副サイト２でＤＢＭＳのバージョンアップのテストなどを行うことが可能となって、実データを用いた開発支援を行うことができ、コストのかかるＤＲシステムの付加価値を向上することができる。
あるいは、正サイト１に障害が発生し、管理装置２００の監視プログラム５０１からフェイルオーバの指示がＤＢ・ストレージ管理部３００にあると、プライマリボリューム３１０の副ＤＢ１１７にログ１１６を適用し、副ＤＢ１１７を回復する。その後、プライマリボリューム３１０を副ＤＢＭＳ１１１にマウントして、正サイト１から副サイト２へ切り換えるようにしても良い。
なお、上記実施形態では、ミラーセット３５０のミラー機能を用いた例を示したが、差分スナップショットを用いることも可能である。差分スナップショットは、対象とするボリュームに更新が加えられた場合には、別のディスク領域に更新前のデータを保存してから、実際の更新を反映する。したがって、スナップショット領域は、プライマリボリューム３１０全体ではなく、更新部分のみを保存すればよいため、スナップショット用に確保する副ストレージ装置１１３の容量を低減できる。また、複数のスナップショットを作成し、異なる領域に保存しておくことで、複数の世代のスナップショットを管理することが可能となる。
また、上記実施形態では、静止化コマンドとスナップショット作成コマンドを分けてログ１０６に書き込んだが、いずれか一方のコマンドをログ１０６に書き込むことで、副サイト２のＤＢ・ストレージ管理部３００が、静止化確認とミラーを行うようにすることができる。
また、本発明では、正サイト１と副サイト２でログ１０６のリモートコピーを行い、ログ１０６には正ＤＢ１０７の更新差分のログに加えて、運用コマンドを書き込み、副サイト２でバックアップされたログ１１６を解釈してログ適用と運用コマンドを実行するようにしたので、サーバ間ネットワーク１２１を用いることなく、副サイト２へスナップショットの作成指令を行うことができ、通信に要する負荷や待ち時間をなくして正サイト１及び副サイト２の負荷を低減できる。
また、本発明によれば、既存のＤＲシステムに、運用コマンドをログに書き込む機能と、ログを解析して更新差分のログ適用と運用コマンドをする機能を追加するだけ良いので、ＤＢＭＳの大幅な改修を必要とせず、容易に実現できる。
＜第２実施形態＞
図６は、第２の実施形態を示し、前記第１実施形態の副サイト２のＤＢ・ストレージ管理部３００にログ１１６を読み込むバッファ３７０を設けたもので、その他の構成は前記第１実施形態と同様である。
本第２実施形態では、ＤＢ・ストレージ管理部３００がトランザクションの解析を行いながらログ適用を行って、決着したトランザクションをＲＥＤＯ（再生）する。
なお、本第２実施形態では、正サイト１は、静止化に関係なく、任意の時点でスナップショット作成コマンドをログ１０６に書き込むものとする。
次に、図７に基づいて、副サイト２のＤＢ・ストレージ管理部３００で行われる処理の一例について説明する。
まず、Ｓ４０では、副サイト２の副ストレージ装置１１３のローカルミラーセット３５０をペア状態として、プライマリボリューム３１０とセカンダリボリューム３２０を同期させ、副ＤＢ１１８を開始時点のスナップショット（シャドウイメージ＝Shadow Image）とする。そして、同期が完了すると、同期状態を示す状態変数に同期が完了したことを示す所定の値を設定する。そして、ローカルミラーセット３５０をペア状態としたまま、Ｓ４１以降の処理を行う。
Ｓ４１では、副サイト２の副ストレージ装置１１３のログ１１６の読み込み位置を、前記第１実施形態と同様にして前回の状態などに基づいて決定し、Ｓ４２以降の処理へ進む。
Ｓ４３では、管理装置２００の監視プログラム５０１やクライアントコンピュータ２５０の業務プログラム５００からバックアップの終了指示を受け付けたか否かを判定する。終了指示があった場合には、Ｓ４４で所定の後処理（変数やバッファのクリアなど）を行ってから終了する。
終了指示がなければ、Ｓ４５へ進んで、ログ１１６の終端まで読み込んだか否かを判定する。終端まで読み込んでいる場合には、Ｓ４２へ戻ってログ１１６が追加されるまでループを繰り返す。
一方、ログ１１６の終端まで読み込んでいない場合には、Ｓ４６に進んでログ１１６をバッファ３７０に読み込む。そして、Ｓ４７では、読み込んだログ１１６を解析し、正ＤＢ１０７の更新差分のログと、運用コマンドのログに分け、解析したログ１１６が運用コマンドであるか否かを判定する。運用コマンドでない場合、つまり、更新差分のログの場合には、Ｓ４８へ進んで、プライマリボリューム３１０の副ＤＢ１１７にログ１１６を適用を行い、トランザクションが決着した場合にはＲＥＤＯ（再生）して、副ＤＢ１１７を更新する。
この結果、ローカルミラーセット３５０はペア状態であるので、セカンダリボリューム３２０の副ＤＢ１１８も同時に更新され、最新のスナップショットなる。
ログ１１６の適用後には、Ｓ４２へ戻って、ログ１１６の終端に達するまでログ１１６の読み込みを繰り返す。
一方、Ｓ４７の判定で、読み込んだログ１１６がスナップショット作成コマンドの場合には、Ｓ４９に進んで、状態変数が同期状態を示す所定の値であることを確認してから、Ｓ５０でローカルミラーセット３５０をスプリット状態とし、プライマリボリューム３２０の副ＤＢ１１７と、セカンダリボリューム３２０の副ＤＢ１１８を同期状態で切り離す。
スナップショット作成コマンドが正常に終了すれば、Ｓ５１へ進んで正常に終了したか否かを判定し、スナップショット作成コマンドの実行で異常が発生した場合には、Ｓ５２に進んでエラーを出力して処理を中断する。なお、エラーの出力は、管理装置２００やクライアントコンピュータ２５０にエラーが生じたことを通知すればよい。また、中断後は、管理者により処理の復旧を行う。
以上の処理により、副サイト２のＤＢ・ストレージ管理部３００は、常時、バッファ３７０へ読み込んだログ１１６を副ＤＢ１１７に適用し、決着したトランザクションをＲＥＤＯすることで、正ＤＢ１０７のバックアップを回復する。そして、ログ１１６の適用の際には、ローカルミラーセット３５０をペア状態としておき、プライマリボリューム３１０とセカンダリボリューム３２０の同期を取っておく。
そして、ログ１１６にスナップショット作成コマンドが含まれているときには、ローカルミラーセット３５０をスプリット状態に変更することで、セカンダリボリューム３２０の副ＤＢ１１８はログ適用を終了して切り離される。
セカンダリボリューム３２０の副ＤＢ１１８は、正サイト１側でスナップショット作成コマンドを発行時点に決着していたトランザクションが反映された整合性のあるスナップショットとなる。
このように、静止化を行わない場合では、常時、決着したトランザクションをＲＥＤＯしておき、スナップショット作成コマンドが副サイト２へ来たときに、ローカルミラーセット３５０をスプリット状態とすることで、セカンダリボリューム３２０にトランザクションの整合性の取れたスナップショットを作成することができるのである。
そして、正サイト１では、静止化を行うことなくスナップショット作成コマンドをログ１０６に書き込むだけでよいので、スナップショット作成の処理に要する負荷を極めて小さくすることができる。なお、スナップショット作成コマンドは、前記第１実施形態と同様に管理装置２００の監視プログラム５０１から正サイト１へ入力しても良いし、正ＤＢＭＳ１０１が所定の周期でスナップショット作成コマンドを発行（ログ１０６へ書き込み）してもよい。
＜変形例１＞
図８は、前記第２実施形態のＤＢ・ストレージ管理部３００の処理と、副サイト２の副ＤＢＭＳ１１１の検索・参照業務の開始処理を連携させる場合の一例を示す。
図８のＳ４０〜Ｓ５２は前記第２実施形態と同一であり、Ｓ５０の処理の後に、副ＤＢＭＳ１１１へスナップショットが作成されたことを通知する処理（Ｓ６１）を加えた点が異なる。
図８のＳ７０〜Ｓ７３は、副ＤＢＭＳ１１１の検索・参照業務の開始処理の一例を示す。
Ｓ７０は、副ＤＢＭＳ１１１が検索・参照業務を開始するための初期化処理を行って、Ｓ７１では、ＤＢ・ストレージ管理部３００からの通知が到着するまで待機する。
そして、ＤＢ・ストレージ管理部３００からスナップショットの作成が完了した通知を副ＤＢＭＳ１１１が受信すると、副ＤＢＭＳ１１１はＳ７２で、スプリットされたセカンダリボリューム３２０の副ＤＢ１１８をマウントする。その後、Ｓ７３では、マウントした副ＤＢ１１８を用いて所定の業務の提供を開始する。
ＤＢ・ストレージ管理部３００と副ＤＢＭＳ１１１を連携させ、スナップショットの作成完了後に副ＤＢＭＳ１１１がスナップショットを作成したボリュームをマウントすることで、トランザクションの整合性の取れたＤＢにより副ＤＢＭＳ１１１は検索・参照業務を行うことができる。
なお、副ＤＢＭＳ１１１の業務は、上述したように参照業務に限定されるものではなく、更新を行うものであっても良い。例えば、月次処理や期末処理などの処理負荷の高いバッチ処理をスナップショットを用いて副ＤＢＭＳ１１１で行うようにしても良い。これにより、本来正ＤＢＭＳ１０１で行っていたバッチ処理を、副ＤＢＭＳ１１１へ分散させることが可能となって、正サイト１のレスポンスの低下を防ぎながら、処理負荷の高いバッチ処理を副サイト２で実行できる。
＜変形例２＞
図９は、前記第１実施形態の副サイト２の副ストレージ装置をＮＡＳ１１３Ａに置き換えたもので、その他の構成は前記第１実施形態と同様である。
ＮＡＳ１１３Ａは、前記第１実施形態の副ストレージ装置１１３と同様に、ディスク制御プログラム１１４、キャッシュ１１５、ディスク装置３０２、３０３からなるローカルミラーセット３５０及びディスク装置３０１を備え、さらにＮＡＳ１１３Ａの制御部（図示省略）では、ディスク制御プログラム１１４に加えて、ＤＢ・ストレージ管理部３００が実行される。
この例では、前記第１実施形態で示したＤＢ・ストレージ管理部３００を実行する専用装置３０１が不要となって、ＤＲシステムの構築及び維持に要するコストを低減することができる。
＜変形例３＞
図１０は、前記変形例２のＮＡＳ１１３ＡをＳＡＮサーバ１１３Ｂに置き換えたもので、その他の構成は前記変形例２と同様である。
ＳＡＮサーバ１１３Ｂは、ディスク制御プログラム１１４、キャッシュ１１５、ＤＢ・ストレージ管理部３００を備え、ストレージ間ネットワーク１２０を介して正サイト１の正ストレージ装置１０３に接続され、また、ＳＡＮ（Storage Area Networ）を介してディスク装置３０１、３０２、３０３と接続される。
ディスク装置３０２、３０３は、ＳＡＮサーバ１１３Ｂによりミラーセット３５０を構成しても良いし、一つのディスク装置の中でミラーセット３５０を構成するようにしても良い。
なお、上記第１及び第２の実施形態では、管理装置２００の監視プログラム５０１が、所定の周期で正サイト１にスナップショットの作成を要求する場合を示したが、正ＤＢＭＳ１０１が、所定のタイミング（周期やＤＢ１０７の状態が所定の条件を満たしたとき等）でスナップショットの作成を指示（ログ１０６の生成）しても良い。
＜変形例４＞
これまで、運用コマンドとしてスナップショットコマンドを用いて説明を行ってきたが、運用コマンドとしては、ＤＢＭＳ／ストレージ／ＡＰなどのコマンドでもよい。
以下では、図１１を参照しながらＤＢファイルを拡張する例を用いて説明する。
ここで主サイト１でログ、ＤＢが格納されるディスク装置１３１、ディスク装置１３０にはそれぞれログファイル１０６、ＤＢファイル１０７が存在するとする。
副サイト２でも同様に副ログファイル１１６、副ＤＢファイル１１７が存在するとする。
挿入が繰り返し行われた場合などは、ＤＢファイル１０７のサイズを拡張する必要がある。具体的には、最初にディスク装置の領域の拡張を行った後、続いてファイルの拡張を行うとする。
図１１（ａ）は、ディスク装置／ファイル拡張前の初期状態を表す。前記第１実施形態に示したクライアントコンピュータや管理装置などからＤＢＡ（データベースアプリケーション）／ＵＡＰ（ユーザアプリケーション）がディスク装置拡張、ファイル拡張の順で運用コマンド１１００を正ＤＢＭＳ１０１に投入する。
図１１（ｂ）は、運用コマンド実行後の状態を表す。
正ＤＢＭＳ１０１では、運用コマンドを受け取ると、その運用コマンドを実行すると共に、ログに運用コマンドをパックしてログファイル１０６に書き込む。
このとき、正副サイトで同じＤＢ状態で運用コマンドを実行するために、運用コマンド実行前に正サイトで上述したような静止化を行ってもよい。
運用コマンドの実行では、正ストレージ１０３において、最初に別なディスク装置１３２を確保し、続いて、ディスク装置１３０、１３２をまたがるようにＤＢファイル１０７１を拡張する。なお、ＤＢファイル１０７を拡張したものがＤＢファイル１０７１である。
図１１（ｃ）は、副サイト２で運用コマンドが実行された状態を表す。
副サイト２では、ＤＢ・ストレージ管理部３００がログファイル１１６を監視し、ログ適用を実施してＤＢファイル１１７を更新している。
ログファイル１１６はリモートコピー１４０により更新されていくが、その更新の結果、図１１（ｂ）でログにパックした運用コマンドを読み込んだら、ログを解析し、その運用コマンドを実行する。
この場合、ディスク装置拡張とファイル拡張の２つのコマンドがパックされている。
最初に、副ストレージ１１３において、別なディスク装置３０３を確保し、続いて、ディスク装置３０２、３０３をまたがるようにＤＢファイル１１７１を拡張する。なお、ＤＢファイル１０７を拡張したものがＤＢファイル１０７１である。
正／副サイトで運用コマンド実行のタイミングがずれた場合、例えば、副サイト２でのＤＢファイル１１７１の拡張が本来のタイミング（正サイト１での拡張タイミング）と異なる場合、副サイト２では、拡張後に実行されるべき挿入が、拡張前のＤＢファイル１１７に実施される可能性があり、その場合は、エラーが生じる。
しかし、本発明のように静止化連携を行う場合には、同一状態のＤＢファイルに同一タイミング・順序で運用コマンドを実施することを保証できるため、上記のようなエラーは生じない。
以上のように、本発明によれば、副サイトを有効に利用して、金融業や大企業などに採用されるディザスタリカバリシステムに適用することができる。
本発明の一実施形態を示し、２つのサイトでディザスタリカバリを行う場合のシステム構成図。 正サイトの正ＤＢＭＳのソフトウェア構成を示すブロック図。 副サイトのＤＢ・ストレージ管理部のソフトウェア構成を示すブロック図。 正サイトの正ＤＢＭＳで行われる処理の一例を示すフローチャート。 副サイトのＤＢ・ストレージ管理部で行われる処理の一例を示すフローチャート。 第２の実施形態を示し、副サイトの専用装置の構成を示すブロック図。 第２の実施形態を示し、副サイトのＤＢ・ストレージ管理部で行われる処理の一例を示すフローチャート。 第１の変形例を示し、副サイトのＤＢ・ストレージ管理部と副ＤＢＭＳで行われる処理の一例を示すフローチャート。 第２の変形例を示し、２つのサイトでディザスタリカバリを行う場合のシステム構成図。 第３の変形例を示し、２つのサイトでディザスタリカバリを行う場合のシステム構成図。 第３の変形例を示し、２つのサイトで運用コマンドを実行する場合のシステム構成図で、（ａ）は初期状態を示し、（ｂ）は正サイトでの運用コマンドの実行状態を示し、（ｃ）は副サイトでの運用コマンドの実行状態を示す。
符号の説明
１ 正サイト
２ 副サイト
１００ 正サーバ
１０１ 正ＤＢＭＳ
１０３ 正ストレージ装置
１０６、１１６ ログ
１０７ 正ＤＢ
１１０ 副サーバ
１１１ 副ＤＢＭＳ
１１３ 副ストレージ装置
１１７、１１８ 副ＤＢ
３００ ＤＢ・ストレージ管理部
３０１ 専用装置
３５０ ローカルミラーセット
４００ 専用装置

Claims (18)

  1. 第１の系と第２の系とを遠隔地に配置してバックアップを行うディザスタリカバリシステムであって、
    前記第１の系は、
    前記第１のデータベースを提供する第１のＤＢＭＳを実行する第１の計算機と、
    トランザクション毎に前記第１のデータベースの更新差分が出力されるログと第１のデータベースとを格納する第１のストレージと、
    前記ログにコマンドを加えるコマンド追加部と、
    前記ログを第２系へ転送するリモートコピー部と、
    を含み、
    前記第２の系は、
    前記第１の系から受信したログと第２のデータベースを格納する第２のストレージと、 前記第１の系から受信した前記ログに基づいて前記第２のデータベースを回復するデータベース回復部と、を含み、
    前記データベース回復部は、前記ログに含まれるコマンドを抽出するコマンド抽出部と、
    前記抽出したコマンドを実行するコマンド実行部と、
    を含むことを特徴とするディザスタリカバリシステム。
  2. 前記コマンド追加部は、第２の系に対する指令としてスナップショットの作成を指示するスナップショット作成コマンドを前記ログに追加し、
    前記第２のストレージは、複数のボリュームをペア状態とスプリット状態に変更可能なミラーセットを有し、
    前記コマンド実行部は、前記抽出したコマンドがスナップショット作成コマンドの場合には、前記第２のストレージにスナップショットの作成を指示し、
    前記第２のストレージは、前記スナップショットの作成指示に基づいて、前記ミラーセットをペア状態として複数のボリュームに前記第２のデータベースを書き込んで同期させた後に、前記ミラーセットをスプリット状態として第２のデータベースを保存することを特徴とする請求項１に記載のディザスタリカバリシステム。
  3. 前記コマンド追加部は、前記第１のＤＢＭＳに含まれて、前記スナップショット作成コマンドをログに追加する際には、前記第１のデータベースの静止化を行った後に、当該スナップショット作成コマンドを前記ログに追加し、
    前記コマンド実行部は、前記抽出したコマンドがスナップショット作成コマンドの場合には、前記第２のデータベースを静止化した後に、前記第２のストレージにスナップショットの作成指示を行うことを特徴とする請求項２に記載のディザスタリカバリシステム。
  4. 前記コマンド追加部は、第２の系に対する指令としてスナップショットの作成を指示するスナップショット作成コマンドを前記ログに追加し、
    前記第２のストレージは、複数のボリュームをペア状態とスプリット状態に変更可能なミラーセットを有し、
    前記データベース回復部は、前記第２のストレージからログを読み込んで、第２のデータベースの未決着トランザクションを決着するトランザクション管理部を有し、
    前記コマンド実行部は、前記抽出したコマンドがスナップショット作成コマンドの場合には、前記第２のストレージにスナップショットの作成を指示し、
    前記第２のストレージは、前記スナップショットの作成指示に基づいて、前記ミラーセットをペア状態からスプリット状態に切り換えて、前記トランザクションを決着した第２のデータベースを保存することを特徴とする請求項１に記載のディザスタリカバリシステム。
  5. 前記第２の系は、前記第２のストレージに格納された第２のデータベースを提供する第２のＤＢＭＳを実行する第２の計算機を含み、
    前記第２のＤＢＭＳは、前記スプリット状態の前記ミラーセットのボリュームをマウントし、前記保存された第２のデータベースを提供することを特徴とする請求項２ないし請求項４のいずれかひとつに記載のディザスタリカバリシステム。
  6. 前記第２のストレージがＮＡＳで構成され、当該ＮＡＳは前記データベース回復部を含むことを特徴とする請求項１に記載のディザスタリカバリシステム。
  7. 前記第２のストレージがＳＡＮを備え、当該ＳＡＮに接続されて前記データベース回復部を実行し、かつ、前記第１の系から受信したログを前記第２のストレージに書き込むサーバを備えたことを特徴とする請求項１に記載のディザスタリカバリシステム。
  8. 第１の系で実行する第１のデータベースから、第２の系に設けた第２のストレージへ複写される第２のデータベースに対するデータの複製方法であって、
    前記第１のデータベースの更新差分のログを第１のストレージに記録する処理と、
    前記第１のデータベースの更新差分を第１のストレージに書き込む処理と、
    前記第１または第２の系に対するコマンドを前記ログに追加する処理と、
    前記更新差分及びコマンドを含むログを前記第２の系へ転送する処理と、
    前記転送された前記ログを前記第２のストレージに格納する処理と、
    前記第２のストレージのログを読み込んで、前記更新差分のログに基づいて第２のデータベースを回復する処理と、
    前記第２のストレージのログから前記コマンドを抽出する処理と、
    前記抽出したコマンドを実行する処理と、
    を含むことを特徴とするデータの複製方法。
  9. 前記コマンドをログに追加する処理は、第２の系でスナップショットの作成を指示するスナップショット作成コマンドをログに追加する処理を含み、
    前記抽出したコマンドを実行する処理は、
    前記抽出したコマンドがスナップショット作成コマンドであるときには、前記第２のストレージを構成するミラーセットの複数のボリュームをペア状態として各ボリュームに前記第２のデータベースを書き込んで同期させる処理と、
    前記同期が完了した後に、前記ミラーセットをスプリット状態として第２のデータベースを保存する処理と、
    を含むことを特徴とする請求項８に記載のデータの複製方法。
  10. 前記スナップショット作成コマンドをログに追加する処理は、前記第１のデータベースを静止化する処理と、当該静止化の完了後に前記スナップショット作成コマンドをログに追加する処理と、を含み、
    前記第２のデータベースを書き込んで同期させる処理は、前記第２のデータベースを静止化する処理と、当該静止化の完了後にミラーセットの複数のボリュームをペア状態として各ボリュームに前記第２のデータベースを書き込む処理と、
    を含むことを特徴とする請求項９に記載のデータの複製方法。
  11. 前記コマンドをログに追加する処理は、第２の系でスナップショットの作成を指示するスナップショット作成コマンドをログに追加する処理を含み、
    前記第２のデータベースを回復する処理は、前記第２のストレージからログを読み込んで、第２のデータベースの未決着トランザクションを決着する処理と、前記第２のストレージを構成するミラーセットの複数のボリュームをペア状態として各ボリュームに前記第２のデータベースを書き込んで同期させる処理と、を含み、
    前記抽出したコマンドを実行する処理は、前記抽出したコマンドがスナップショット作成コマンドであるときには、前記第２のストレージを構成するミラーセットの複数のボリュームをペア状態からスプリット状態に切り換えて、第２のデータベースを保存する処理と、
    を含むことを特徴とする請求項９に記載のデータの複製方法。
  12. 前記第２のデータベースを保存した前記ミラーセットのボリュームをマウントする処理と、
    前記マウントしたボリュームの第２のデータベースを提供する処理と、
    を含むことを特徴とする請求項９ないし請求項１１のいずれかひとつに記載のデータの複製方法。
  13. 前記第１の系でコマンドを受け付ける処理と、
    前記コマンドを解析する処理と、
    前記コマンドが第１の系のみに対する指示である場合には、当該指示を第１の系で実行する処理と、
    前記実行したコマンドを破棄する処理と、
    を含むことを特徴とする請求項８に記載のデータの複製方法。
  14. 前記第１の系でコマンドを受け付ける処理と、
    前記コマンドを解析する処理と、
    前記コマンドが第１の系と第２の系で実行可能な指示である場合には、当該指示を第１の系で実行する処理と、
    前記実行したコマンドをログに書き込む処理と、
    を含むことを特徴とする請求項８に記載のデータの複製方法。
  15. 前記第１の系でコマンドを受け付ける処理と、
    前記コマンドを解析する処理と、
    前記コマンドが第１の系のみに対する指示である場合には、当該指示を第１の系で実行する処理と、
    前記実行したコマンドを破棄する処理と、
    を含むことを特徴とする請求項８に記載のデータの複製方法。
  16. 前記第１または第２の系に対するコマンドを前記ログに追加する処理は、
    当該コマンドを実行するに当たってトランザクションの整合性を取る必要があるか否かを判定する処理と、
    前記整合性を取る必要がある場合には、前記コマンドの前にトランザクションの整合性を取るコマンドを追加する処理と、
    前記第１の系でトランザクションの整合性を取る処理と、
    を含むことを特徴とする請求項８に記載のデータの複製方法。
  17. 第１の系で第１のデータベースを提供する処理をコンピュータに機能させるプログラムであって、
    前記第１のデータベースの更新差分のログを第１のストレージに記録する処理と、
    前記第１のデータベースの更新差分を第１のストレージに書き込む処理と、
    前記第１または第２の系に対するコマンドを受け付ける処理と、
    当該コマンドを実行するに当たってトランザクションの整合性を取る必要があるか否かを判定する処理と、
    前記整合性を取る必要がある場合には、前記コマンドの前にトランザクションの整合性を取るコマンドを追加する処理と、
    前記第１の系でトランザクションの整合性を取る処理と、
    前記更新差分及びコマンドを含むログを前記第２の系へ転送する処理と、
    をコンピュータに機能させることを特徴とするプログラム。
  18. 第２の系で受信したログを監視する処理をコンピュータに機能させるプログラムであって、
    前記受信したログを解析して、当該ログがデータベースの更新差分の情報とコマンドのいずれであるかを判定する処理と、
    前記ログがデータベースの更新差分の場合には、当該更新差分に基づいて第２のデータベースを回復する処理と、
    前記ログがコマンドの場合には、当該コマンドを実行する処理と、
    をコンピュータに機能させることを特徴とするプログラム。
JP2004223776A 2004-07-30 2004-07-30 ディザスタリカバリシステム、プログラム及びデータの複製方法 Expired - Fee Related JP4484618B2 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
JP2004223776A JP4484618B2 (ja) 2004-07-30 2004-07-30 ディザスタリカバリシステム、プログラム及びデータの複製方法
US10/930,832 US7529964B2 (en) 2004-07-30 2004-09-01 Data duplication method in a disaster recovery system

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004223776A JP4484618B2 (ja) 2004-07-30 2004-07-30 ディザスタリカバリシステム、プログラム及びデータの複製方法

Publications (2)

Publication Number Publication Date
JP2006048103A true JP2006048103A (ja) 2006-02-16
JP4484618B2 JP4484618B2 (ja) 2010-06-16

Family

ID=35733783

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004223776A Expired - Fee Related JP4484618B2 (ja) 2004-07-30 2004-07-30 ディザスタリカバリシステム、プログラム及びデータの複製方法

Country Status (2)

Country Link
US (1) US7529964B2 (ja)
JP (1) JP4484618B2 (ja)

Cited By (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008209966A (ja) * 2007-02-23 2008-09-11 Hitachi Ltd 一以上のセカンダリストレージシステムで複数のバックアップを取得するバックアップ制御方法
JP2008225699A (ja) * 2007-03-09 2008-09-25 Fujitsu Ltd 複製作成装置および複製作成方法
JP2008226088A (ja) * 2007-03-15 2008-09-25 Hitachi Ltd ディザスタリカバリシステムおよび方法
JP2009146389A (ja) * 2007-11-22 2009-07-02 Hitachi Ltd バックアップシステム及び方法
JP2009151637A (ja) * 2007-12-21 2009-07-09 Nomura Research Institute Ltd 業務継続システム
JP2009151636A (ja) * 2007-12-21 2009-07-09 Nomura Research Institute Ltd 業務継続システム
US7587430B2 (en) 2006-02-28 2009-09-08 Hitachi, Ltd. Backup system for data base
JP2009282791A (ja) * 2008-05-22 2009-12-03 Nomura Research Institute Ltd 耐障害業務情報システム
US8131679B2 (en) 2007-05-18 2012-03-06 Hitachi, Ltd. Exclusive control method for database and program
JP2012252653A (ja) * 2011-06-06 2012-12-20 Canon Inc 情報処理装置及びその制御方法
JP5504452B1 (ja) * 2013-09-04 2014-05-28 株式会社Ｇｒｏｏｎｙ 営業情報同期システム
US9032144B2 (en) 2007-09-28 2015-05-12 Fujitsu Limited Virtual tape device, virtual library system, and virtual tape control method
US9268650B2 (en) 2011-11-30 2016-02-23 Fujitsu Limited Storage device, controller, and non-transitory computer-readable recording medium for backing up data without lowering I/O capabilities
JP2016103115A (ja) * 2014-11-27 2016-06-02 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ データベースを管理するシステム及び方法
JP2016522514A (ja) * 2013-06-25 2016-07-28 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ オンライン・ホット・スタンバイ・データベースのためのレプリケーション方法、プログラム、および装置
US9715522B2 (en) 2014-03-28 2017-07-25 Fujitsu Limited Information processing apparatus and control method
JP2021124889A (ja) * 2020-02-04 2021-08-30 株式会社日立製作所 リモートコピーシステム及びリモートコピー管理方法

Families Citing this family (18)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7650369B2 (en) * 2006-03-30 2010-01-19 Fujitsu Limited Database system management method and database system
JP2009093378A (ja) * 2007-10-05 2009-04-30 Hitachi Ltd ストレージシステム
US8285953B2 (en) 2007-10-24 2012-10-09 Hitachi, Ltd. Storage system group
US20090125692A1 (en) * 2007-10-24 2009-05-14 Masayuki Yamamoto Backup system and method
US7908514B2 (en) * 2008-06-26 2011-03-15 Microsoft Corporation Minimizing data loss in asynchronous replication solution using distributed redundancy
US11449394B2 (en) 2010-06-04 2022-09-20 Commvault Systems, Inc. Failover systems and methods for performing backup operations, including heterogeneous indexing and load balancing of backup and indexing resources
US8504526B2 (en) 2010-06-04 2013-08-06 Commvault Systems, Inc. Failover systems and methods for performing backup operations
US9483364B2 (en) 2013-05-08 2016-11-01 Commvault Systems, Inc. Synchronization of local secondary copies with a remote storage management component
US9152340B2 (en) 2013-05-28 2015-10-06 Netapp, Inc. System and method for managing and producing a dataset image across multiple storage systems
US9152327B2 (en) * 2013-05-28 2015-10-06 Netapp, Inc. System and method for detecting failure of storage object images on a storage system and initiating a cleanup procedure
CN105793382B (zh) * 2013-11-29 2018-03-16 井上株式会社 阻燃性密封材料
US9811427B2 (en) 2014-04-02 2017-11-07 Commvault Systems, Inc. Information management by a media agent in the absence of communications with a storage manager
US9575849B2 (en) * 2014-11-25 2017-02-21 Sap Se Synchronized backup and recovery of database systems
US10474548B2 (en) 2016-09-30 2019-11-12 Commvault Systems, Inc. Heartbeat monitoring of virtual machines for initiating failover operations in a data storage management system, using ping monitoring of target virtual machines
US11200124B2 (en) 2018-12-06 2021-12-14 Commvault Systems, Inc. Assigning backup resources based on failover of partnered data storage servers in a data storage management system
US11099956B1 (en) 2020-03-26 2021-08-24 Commvault Systems, Inc. Snapshot-based disaster recovery orchestration of virtual machine failover and failback operations
US11645175B2 (en) 2021-02-12 2023-05-09 Commvault Systems, Inc. Automatic failover of a storage manager
CN117874145B (zh) * 2024-03-13 2024-05-28 连连（杭州）信息技术有限公司 一种主从数据库的强一致方法、装置、设备及存储介质

Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04124743A (ja) * 1990-09-17 1992-04-24 Toshiba Corp データ２重化方式
JP2003099306A (ja) * 2001-09-25 2003-04-04 Hitachi Ltd 計算機システムおよび計算機システムにおけるバックアップ方法
JP2003233518A (ja) * 2001-12-27 2003-08-22 Hitachi Ltd バックアップと回復処理システムの方法と手段
JP2003242011A (ja) * 2002-01-10 2003-08-29 Hitachi Ltd 多世代リモートバックアップと高速リストアの為の装置と方法
JP2004094710A (ja) * 2002-09-02 2004-03-25 Hitachi Ltd 記憶サブシステムのデータ二重化方法およびシステム

Family Cites Families (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5796934A (en) * 1996-05-31 1998-08-18 Oracle Corporation Fault tolerant client server system
US6449622B1 (en) 1999-03-08 2002-09-10 Starfish Software, Inc. System and methods for synchronizing datasets when dataset changes may be received out of order
JP4282030B2 (ja) 1999-06-03 2009-06-17 株式会社日立製作所 データ二重化制御方法および二重化した記憶サブシステム
US6408310B1 (en) * 1999-10-08 2002-06-18 Unisys Corporation System and method for expediting transfer of sectioned audit files from a primary host to a secondary host
JP2001356945A (ja) * 2000-04-12 2001-12-26 Anetsukusu Syst Kk データバックアップ・リカバリー方式
US6925476B1 (en) 2000-08-17 2005-08-02 Fusionone, Inc. Updating application data including adding first change log to aggreagate change log comprising summary of changes
US6718348B1 (en) 2000-08-25 2004-04-06 Telefonaktiebolaget Lm Ericsson (Publ) Non-time dependent synchronization of databases
US6832330B1 (en) * 2001-09-05 2004-12-14 Emc Corporation Reversible mirrored restore of an enterprise level primary disk
US6934725B1 (en) * 2001-12-28 2005-08-23 Emc Corporation Management of file extent mapping to hasten mirror breaking in file level mirrored backups
US7082446B1 (en) * 2002-04-15 2006-07-25 Steel Eye Technology, Inc. Hybrid transaction/intent log for data replication
US20030208511A1 (en) 2002-05-02 2003-11-06 Earl Leroy D. Database replication system
US8121978B2 (en) 2002-11-15 2012-02-21 Sybase, Inc. Database system providing improved methods for data replication
JP4651913B2 (ja) * 2003-02-17 2011-03-16 株式会社日立製作所 記憶装置システム
US7210061B2 (en) * 2003-04-17 2007-04-24 Hewlett-Packard Development, L.P. Data redundancy for writes using remote storage system cache memory
US7275185B2 (en) * 2003-11-20 2007-09-25 International Business Machines Corporation Method and apparatus for device error log persistence in a logical partitioned data processing system
JP2005346610A (ja) * 2004-06-07 2005-12-15 Hitachi Ltd スナップショットの取得および利用のための記憶システムおよび方法

Patent Citations (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH04124743A (ja) * 1990-09-17 1992-04-24 Toshiba Corp データ２重化方式
JP2003099306A (ja) * 2001-09-25 2003-04-04 Hitachi Ltd 計算機システムおよび計算機システムにおけるバックアップ方法
JP2003233518A (ja) * 2001-12-27 2003-08-22 Hitachi Ltd バックアップと回復処理システムの方法と手段
JP2003242011A (ja) * 2002-01-10 2003-08-29 Hitachi Ltd 多世代リモートバックアップと高速リストアの為の装置と方法
JP2004094710A (ja) * 2002-09-02 2004-03-25 Hitachi Ltd 記憶サブシステムのデータ二重化方法およびシステム

Cited By (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7587430B2 (en) 2006-02-28 2009-09-08 Hitachi, Ltd. Backup system for data base
JP2008209966A (ja) * 2007-02-23 2008-09-11 Hitachi Ltd 一以上のセカンダリストレージシステムで複数のバックアップを取得するバックアップ制御方法
JP2008225699A (ja) * 2007-03-09 2008-09-25 Fujitsu Ltd 複製作成装置および複製作成方法
JP2008226088A (ja) * 2007-03-15 2008-09-25 Hitachi Ltd ディザスタリカバリシステムおよび方法
US8131679B2 (en) 2007-05-18 2012-03-06 Hitachi, Ltd. Exclusive control method for database and program
US9032144B2 (en) 2007-09-28 2015-05-12 Fujitsu Limited Virtual tape device, virtual library system, and virtual tape control method
JP2009146389A (ja) * 2007-11-22 2009-07-02 Hitachi Ltd バックアップシステム及び方法
JP2009151637A (ja) * 2007-12-21 2009-07-09 Nomura Research Institute Ltd 業務継続システム
JP2009151636A (ja) * 2007-12-21 2009-07-09 Nomura Research Institute Ltd 業務継続システム
JP2009282791A (ja) * 2008-05-22 2009-12-03 Nomura Research Institute Ltd 耐障害業務情報システム
JP2012252653A (ja) * 2011-06-06 2012-12-20 Canon Inc 情報処理装置及びその制御方法
US9268650B2 (en) 2011-11-30 2016-02-23 Fujitsu Limited Storage device, controller, and non-transitory computer-readable recording medium for backing up data without lowering I/O capabilities
JP2016522514A (ja) * 2013-06-25 2016-07-28 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ オンライン・ホット・スタンバイ・データベースのためのレプリケーション方法、プログラム、および装置
JP5504452B1 (ja) * 2013-09-04 2014-05-28 株式会社Ｇｒｏｏｎｙ 営業情報同期システム
US9715522B2 (en) 2014-03-28 2017-07-25 Fujitsu Limited Information processing apparatus and control method
JP2016103115A (ja) * 2014-11-27 2016-06-02 インターナショナル・ビジネス・マシーンズ・コーポレーションＩｎｔｅｒｎａｔｉｏｎａｌ Ｂｕｓｉｎｅｓｓ Ｍａｃｈｉｎｅｓ Ｃｏｒｐｏｒａｔｉｏｎ データベースを管理するシステム及び方法
US11144574B2 (en) 2014-11-27 2021-10-12 International Business Machines Corporation System and method for managing database
JP2021124889A (ja) * 2020-02-04 2021-08-30 株式会社日立製作所 リモートコピーシステム及びリモートコピー管理方法
JP7117338B2 (ja) 2020-02-04 2022-08-12 株式会社日立製作所 リモートコピーシステム及びリモートコピー管理方法

Also Published As

Publication number Publication date
JP4484618B2 (ja) 2010-06-16
US7529964B2 (en) 2009-05-05
US20060026452A1 (en) 2006-02-02

Similar Documents

Publication Publication Date Title
JP4484618B2 (ja) ディザスタリカバリシステム、プログラム及びデータの複製方法
JP4581500B2 (ja) ディザスタリカバリシステム、プログラム及びデータベースのリカバリ方法
JP4405509B2 (ja) データ管理方法、システム、およびプログラム（リモート記憶位置にフェイルオーバを行うための方法、システム、およびプログラム）
JP4833734B2 (ja) データベースシステム、ストレージ装置、初期コピー方法及びログ適用方法
US7657718B1 (en) Storage automated replication processing
US7032089B1 (en) Replica synchronization using copy-on-read technique
JP4477950B2 (ja) リモートコピーシステム及び記憶装置システム
US7607037B1 (en) SAR restart and going home procedures
JP4668763B2 (ja) ストレージ装置のリストア方法及びストレージ装置
US8060714B1 (en) Initializing volumes in a replication system
US7383264B2 (en) Data control method for duplicating data between computer systems
US7031986B2 (en) Database system with backup and recovery mechanisms
US8027952B2 (en) System and article of manufacture for mirroring data at storage locations
US7457830B1 (en) Method and system of replicating data using a recovery data change log
JP5521595B2 (ja) ストレージシステム及びストレージ制御方法
US8688939B2 (en) Storage system and storage subsystem
JP4998010B2 (ja) データベースシステム管理、データベースシステム、プログラム及び処理装置
CN111984474A (zh) 一种双控集群故障恢复的方法、系统及设备
US20210240351A1 (en) Remote copy system and remote copy management method
JP5209293B2 (ja) 業務継続システム
JP7007017B2 (ja) ストレージシステム、制御方法、及びプログラム
JP2009205568A (ja) クラスタシステム及びその動作方法
JPWO2016117322A1 (ja) 処理要求装置、処理装置、データベースシステム、データベース更新方法およびプログラム
JP2009151635A (ja) 業務継続システム

Legal Events

Date Code Title Description
A621 Written request for application examination

Free format text: JAPANESE INTERMEDIATE CODE: A621

Effective date: 20070320

A977 Report on retrieval

Free format text: JAPANESE INTERMEDIATE CODE: A971007

Effective date: 20091119

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20091201

A521 Written amendment

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20100201

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20100316

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20100323

R150 Certificate of patent or registration of utility model

Ref document number: 4484618

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130402

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140402

Year of fee payment: 4

LAPS Cancellation because of no payment of annual fees