JP2008525914A - 動的なデータバックアップのためのシステムおよび方法 - Google Patents

Abstract

データベースミラーリング工程を備えるコンピュータネットワークであって、第１のデータベースサーバにロケーションされた第１のデータベースと、第２のデータベースサーバにロケーションされた第２のデータベースと、任意であるウィットネスデータベースサーバとを備える。第１のデータベースおよび第２のデータベースのうちの一方はライブデータベースであり、他方のデータベースはミラーデータベースである。プロセスは、第１のデータベースサーバ、第２のデータベースサーバ、またはウィットネスデータベースサーバとの通信を開始し、第１のデータベースおよび第２のデータベースのうちのいずれがライブデータベースであるかを判定する。ライブデータベースのロケーションは、ライブデータベースがバックアップされている第１のデータベースサーバ、第２のデータベースサーバ、およびウィットネスデータベースサーバのうちのいずれのシステムデータベース内のテーブルエントリから情報が読み出されるかにより判別される。

Description

本発明はデータをバックアップするためのシステムおよび方法に関する。より詳細には、本発明の実施形態は、データベースミラーリング環境においてデータをバックアップするためのシステムおよび方法に関する。

コンピュータネットワークは居住環境および商用環境の両方において遍在的（ユビキタス；ｕｂｉｑｕｉｔｏｕｓ）である。広範なインターネットの使用に加えて、ローカルエリアネットワーク（ＬＡＮ）によってユーザがコンピュータサービスを共有することが可能である。多くの企業体はその組織内でＬＡＮを用いるとともに、消費者にはインターネットを通じてデータへのアクセスを提供している。

コンピュータおよびコンピュータネットワークによって、データの可用性および信頼性の改良の必要が生じている。多くの営利団体はコンピュータネットワーク上にほとんど全ての業務データを格納しており、ネットワークユーザはいかなる時にもデータへのアクセスが中断されないことを期待している。データへのアクセスが中断されないというこの要求を支えるには、高性能のソフトウェアおよびハードウェアが必要である。ネットワーク上に格納されたデータの量や、ネットワーク上のデータへのアクセス性の要求が増大するにつれ、システム障害、ファイル破損、およびウィルスなど、不測の事態からデータを保護することは次第に困難となっている。

潜在的な壊滅的な事態からデータを保護することは、データをバックアップするためのソフトウェアと、バックアップされたデータを格納するためのセキュアなハードウェアとの組み合わせによって通常は行われる。保存されるデータの量が増大するにつれ、データをバックアップする処理はより複雑になる。例えば、数ギガバイトのデータを迅速にプライマリロケーションからバックアップロケーションに移動させることは不可能である。加えて、バックアップの実行中にデータを利用不能とすることは、データへの連続的なアクセスが必須である環境においては実行可能な選択肢ではない。

大量のデータをバックアップすることは問題であるが、典型的なデータバックアップシステムに関連する問題はそれだけではない。ネットワークユーザおよび管理者が様々なタイプのデータをバックアップすることを所望する場合がある。ファイルをバックアップすることに加えて、ネットワークユーザもアプリケーションおよびサービスをバックアップすることを所望する場合がある。アプリケーションおよびサービスをバックアップすることは難題である。例えば、バックアップが開始されるとき、アプリケーションおよびサービスがファイルを開いていることがしばしばあるが、開かれているファイルを有効にまたは信頼性を有してバックアップすることは一般に不可能であるため、バックアップ操作中、そうしたファイルはスキップされることが多い。結果として、最初のファイルシステムバックアップ中にファイルがスキップされたアプリケーションおよびサービスの管理バックアップ操作を支援するために、追加のバックアップアプリケーションが必要となることがしばしばある。

データのバックアップに関連する別の問題は、バックアップされたデータを、そのデータがバックアップロケーションに移動されるときにトラッキングする手法に関する。詳細には、データがバックアップされるとき、バックアップコピーは新たなロケーションに移動されるため、格納されたデータへのアクセスを実行するには、データがどのように格納されているかに関する記録を有する必要がある。典型的には、バックアップシステムは、
バックアップされる各々のファイルまたはアプリケーションの正確なロケーションを記録するデータベースを備える。ユーザがバックアップシステムからファイルを特定することまたは読み出すことを所望するとき、データベースはバックアップメディアにおけるそのファイルの格納されたロケーションにてファイルを特定する。

バックアップされたデータのロケーションのトラッキング中、典型的なバックアップソフトウェアシステムは、単にバックアップロケーションにデータを配置し、インデックスによってロケーションをトラッキングする。より知的なデータベースソフトウェアシステムは、データが知的に格納されるように、データがバックアップされるときにデータをソートする性能を備える。例えば、より高度なデータベースソフトウェアシステムは、類似のファイルのバックアップを同一メディア上に格納することが可能である。データをこのようにソートし格納することによって、より有効なデータ格納および読出が可能となる。

典型的なバックアップソフトウェアシステムの別の欠点は、ネットワーク内のデータの再ロケーションが不可能であること、即ち、ネットワーク内で利用可能なデータについて１より多くのコピーを有することが不可能なことである。バックアップソフトウェアシステムはネットワーク上の全てのユーザからデータを収集するが、データそれ自体はネットワーク上のある１つのロケーションに存在するものとして見られ、他のロケーションに対して相互参照されない。ネットワーク上のデータはバックアップされるが、この冗長性および相互参照は取り扱われない。

本発明の実施態様の上記の例および他の態様を一層明確にするため、本発明の
説明を、本発明の実施態様の図面に示す具体的な例を用いて行う。これらの図面は本発明の実施態様の例を示すものであって、本発明の範囲を限定することを意図するものではない。図面の寸法は正確ではない。

Ｉ．代表的なデータベース操作システム
本発明の実施態様に適切な１つの操作環境を、図１に示す。図１には、代表的なファイルシステムデータバックアップおよび回復システム（ＤＢＲＳ）１００を示す。このシステムは、一般に格納ロケーションのオンラインファイルシステムデータを複製するように機能し、データについてのロケーションおよび旧トラッキング情報を維持する。オンラインバージョンのデータが失われたり破損したりする場合、ＤＢＲＳ１００はデータを再作成することが可能である。ＤＢＲＳ１００が動作するネットワークが災害を経験する場合、ＤＢＲＳ１００は、記憶装置へ書き込まれたときにファイルシステムが存在していた通りに、元のそれぞれの構造へＤＢＲＳ１００のファイルシステム全てを再作成することが可能である。

ＤＢＲＳ１００の代表的な実施態様は、３つの基本構成要素、即ち、バックアップサーバ１０２と、１つ以上のクライアント１０４，１０５，１０６，１０７，１０８と、データのバックアップボリューム１１０とを備える。バックアップサーバ１０２およびクライアント１０４，１０５，１０６，１０７，１０８は、ＤＢＲＳ１００の操作を動作させるのに必要なソフトウェアを有するエンティティである。バックアップサーバ１０２は、ＤＢＲＳ１００の機能を組織化・管理するプログラムおよびサービスを備える。クライアント１０４，１０５，１０６，１０７，１０８は、ＤＢＲＳ１００の機能を実行するプログラムおよびサービスを備える。

バックアップサーバ１０２は、例えば、クライアント１０４，１０５，１０６，１０７，１０８など、そのクライアントのセットのデータを管理する。クライアント１０４，１０５，１０６，１０７，１０８は、バックアップされるファイルを配信するネットワーク
上の機器を表す。バックアップサーバ１０２は、クライアント／データを組織化するために、それぞれのバックアップグループ１１２，１１４，１１６の使用を組み込むこともできる。バックアップグループとは、グループとして共にバックアップされるクライアント、データ、またはその両方のセットである。バックアップグループ１１２およびバックアップグループ１１４によって示すように、１つのクライアントが複数のバックアップグループに含まれることが可能である。

クライアント１０４，１０５，１０６，１０７，１０８からバックアップされるデータを管理するために、ＤＢＲＳ１００はデータトラッキング情報を用いる。データトラッキング情報は、図１に示すように、バックアップサーバ１０２のファイルインデックス１１８およびメディアデータベース１２０である。ファイルインデックス１１８およびメディアデータベース１２０におけるエントリは、ＤＢＲＳ１００の環境においてバックアップされている、全てのデータ、クライアントマシンおよびファイルの両方を記述するコンテンツおよびロケーション情報を維持する。

バックアップサーバ１０２のファイルインデックス１１８では、各クライアントによって組織化された、バックアップされたファイルのリストが閲覧され得る。バックアップされるネットワークにおける各クライアント上の各々のファイルは、ファイルインデックスにおいてリスト化される。ファイルインデックス１１８におけるエントリは、ファイルタイプ、ファイルがバックアップされた時刻や、元のファイルをホストするクライアントマシンなどファイルに関する他の情報など、ファイルについての情報を含む。１つのファイルが複数回バックアップされて、バックアップコピーが複数のロケーションに格納されてもよいので、ファイルインデックス１１８におけるファイルへのエントリは、ファイルの各バックアップについて、バックアップロケーションおよびバックアップ時刻に関する情報を格納する場合がある。特定のファイルについての複数のバックアップロケーションおよびバックアップ時刻に関するファイルインデックス１１８における情報によって、読出用のファイルの特定のバージョンをユーザが識別することが可能である。ファイルの複数のバックアップに関するエントリ情報を、管理者によって決定される任意の時間に渡ってファイルインデックス１１８に残すことが可能である。

ファイルインデックス１１８は個々のファイルをトラッキングし、メディアデータベース１２０はファイルが格納されるロケーションをトラッキングする。換言すると、メディアデータベース１２０は、メディア格納ロケーションへの参照を格納している。操作時には、バックアップグループ１１２，１１４または１１６がＤＢＲＳ１００の上の格納ボリュームにバックアップされる毎に、メディアデータベース１２０がエントリを受信する。ファイルインデックス１１８におけるエントリと同じように、管理者がエントリを削除するまで、エントリはメディアデータベース１２０に残る。該当データが上書きされる場合、メディアデータベース１２０におけるエントリも削除され得る。

データに関するロケーション情報が分かると、異なった手法によりデータを格納することが可能である。例えば、図１に示すようにバックアップサーバ１０２からアクセス可能であったり、リモートサーバ経由でアクセス可能であったりするテープドライブ、ハードディスク、またはリムーバブルディスクなどのデバイス上のメディアボリュームに、データを格納することが可能である。データをバックアップするための代表的なシステムでは、バックアップボリューム１１０およびバックアップデバイス１２６，１２８，１３０，１３２によって示されるように、データはデバイス上のボリュームに格納される。デバイスおよびボリュームによるデータ格納工程の一例は、ディスクアレイ上にデータを格納することであり、この場合、データ格納はディスクにサブグループ化される。デバイスおよびボリュームによるデータの格納の別の例は、テープドライブ上にデータを格納することであり、データ格納は特定のテープボリュームにサブグループ化される。デバイスおよび
ボリュームによるデータの格納の最後の例は、リモートサーバ上にデータを格納することであり、データ格納はサーバ上のハードディスクにサブグループ化される。これらの例はデバイスおよびボリュームの可能な構成を理解する際に有用であるが、ＤＢＲＳ１００がデバイスおよびボリュームによりデータを格納する性能は、ここに示した例に限定されない。最も一般的な意味では、バックアップデバイス１２６，１２８，１３０，１３２は、特定のシステムまたはデバイスに限定されない、データを格納するための手法の概念的なモデルを表す。

ＤＢＲＳ１００内のバックアップデバイス１２６，１２８，１３０，１３２の有用性は、バックアップデバイス１２６，１２８，１３０，１３２が様々なタイプのデータを格納する性能によってさらに強化される。詳細には、バックアップデバイス１２６，１２８，１３０，１３２は、あらゆるファイルタイプのデータを格納することが可能である。例えば、バックアップデバイス１２６，１２８，１３０，１３２に、画像ファイル、プログラム実行ファイル、および文書ファイルのバックアップコピーを一緒に格納することが可能である。

バックアップデバイス１２６，１２８，１３０，１３２の基礎をなす一態様は、バックアップデバイス１２６，１２８，１３０，１３２がＤＢＲＳ１００においてバックアップされたファイルを高速読出する性能である。例えば、ユーザがバックアップされたファイルの復元をリクエストするとき、そのファイルのファイルインデックスおよびメディアデータベースのエントリが、例えばテープ、ＣＤ、ＤＶＤ、またはファイルを格納するために用いられた他のメディアなど、バックアップデバイス１２６，１２８，１３０，１３２、および用いられた特定のメディアへの参照を含む非常に特定的なロケーション情報を格納している場合、ＤＢＲＳ１００は迅速にファイルを読み出すことが可能である。

バックアップデバイス１２６，１２８，１３０，１３２にバックアップすることを含む多くの機能に関して、初期的には、ＤＢＲＳ１００は機能を独立して実行するように構成される。しかしながら、管理者はＤＢＲＳ１００の機能を制御するための多くの権限を有する。したがって、管理者は異なるクライアント特性および／またはファイル特性によって格納用のファイルを分離することが可能であり、かつバックアップボリュームが旧くなり、削除されるべき時を定義することが可能である。例えば、管理者は、バックアップが作成されてから所定時間の経過した後に、メディアデータベース１２０からバックアップボリュームを削除するようにＤＢＲＳ１００を構成することが可能である。管理者は、１つ以上のクライアントおよびそのファイル、ディレクトリ、もしくはファイルシステム、またはクライアントマシン上の全てのファイルを含むことの可能な、バックアップグループ１１２，１１４，１１６を定義することも可能である。

クライアント１０４，１０５，１０６，１０７，１０８にアクセスするとき、管理者は管理者ＧＵＩ（図示せず）内で作業することが可能である。管理者ＧＵＩは任意のＤＢＲＳ１００マシン上に表示されて、クライアントプラットフォームが何であるかにかかわらず、管理者が任意のクライアント１０４，１０５，１０６，１０７，１０８とインタフェースし、それらのクライアントのためのサービスを調停することを可能とする。管理者の権限の別の重要な態様には、アプリケーション環境を指定する能力が含まれる。例えば、管理者は、ＤＢＲＳ１００が用いるバックアップデバイスおよび定義されるクライアントの数などの命令を指定するレコードを作成することが可能である。管理者は、バックアップスケジュールおよびリサイクルされるまでにデータが保護される期間を含め、バックアップ・回復環境においてアプリケーションが実施する規則を指定することも可能である。

管理者権限に加えて、ＤＢＲＳ１００は失われたデータの回復用のシステムも組み込んでいる。クライアントデータが失われたときまたは破損したとき、ユーザまたは管理者は
ファイルインデックス１１８により回復可能なファイルを閲覧し、次いで、失われたデータの状態、またはメディアデータベース１２０によってトラッキングされた、バックアップデバイス１２６，１２８，１３０，１３２上のボリュームにおけるコンテンツのロケーションを記述するために、レポートを作成することが可能である。次いで、ユーザはユーザが指定した時点に、失われたデータを回復させることが可能である。失われたデータを回復させるためにリクエストが行われると、ＤＢＲＳ１００はリクエストされたデータを特定し、１つまたは複数のファイルの回復を指示する。データは、データの出所であるクライアント１０４，１０５，１０６，１０７，１０８、または別の指定のクライアントに対し回復させることが可能である。

さらに、ＤＢＲＳ１００は異種環境において実行する性能を有し、様々な異なるプラットフォーム上で動作することが可能である。例えば、ＵＮＩＸ（登録商標）サーバ上のバックアップソフトウェアはＷｉｎｄｏｗｓ（登録商標）クライアントをサポートすることが可能であり、或いは反対に、Ｗｉｎｄｏｗｓサーバ上のバックアップソフトウェアはＵＮＩＸクライアントをサポートすることが可能である。サーバプラットフォームが何であるかにかかわらず、クライアントに関連する任意のデバイスまたはボリュームのバックアップデータを読み取ることが可能であり、任意のＤＢＲＳ１００サーバによって、ユーザ指定の時点に対しデバイスまたはボリュームのデータを再作成することが可能である。クライアント１０４，１０５，１０６，１０７，または１０８のプラットフォームが何であるかにかかわらず、任意のシステムクライアント１０４，１０５，１０６，１０７，１０８からのバックアップデータが１つのバックアップデバイスまたは１つのメディアセット上に共存することが可能である。

ＩＩ．動的バックアップのためのシステムおよび方法
Ａ．代表的なミラーリングシステムの構成要素
上述の代表的なＤＢＲＳ１００は、ネットワーク上に知的にファイルを格納し、読み出す。代表的なシステムは、上述の代表的なシステムの性能に加え、様々な追加のアプリケーションおよび機能をサポートすることが可能である。そのような１つのアプリケーションは、データベースミラーリングを担うデータベースバックアップ機能を組み込んでいる。

代表的なデータベースミラーリングシステム２００を、図２に示す。データベースミラーリングシステム２００は、データベースサーバ２０２およびデータベースサーバ２０４を備える。データベースサーバ２０２およびデータベースサーバ２０４のうちの一方はプライマリサーバとして指定されており、他方はセカンダリサーバとして指定されている。データベースサーバ２０２がプライマリサーバとして指定されるとき、サーバ２０２上にロケーションされたユーザデータベース２０６がライブデータベースである。同様に、セカンダリサーバとしてデータベースサーバ２０４を指定すると、ユーザデータベース２０８がミラーデータベースである。

ユーザデータベース２０６，２０８に加えて、データベースサーバ２０２およびデータベースサーバ２０４は、それぞれシステムデータベース２１０，２１２を備える。システムデータベース２１０，２１２は、ユーザデータベース２０６，２０８の役割を「ライブ」または「ミラー」のいずれかとして確定するために用いられる情報を格納している。ユーザデータベース２０６，２０８がデータベースミラーリングに参加するように構成されるとき、サーバアプリケーション２１４，２１６は、ユーザデータベース２０６，２０８の状態に関する情報を「ライブ」または「ミラー」のいずれかとして格納するために、それぞれ、データベースサーバ２０２およびデータベースサーバ２０４にインストールされたシステムデータベース２１０，２１２を更新する。この初期の設定に続いて、ユーザデータベース２０６，２０８の状態に関して「ライブ」または「ミラー」のいずれかとして
システムデータベース２１０，２１２上に格納されている全ての情報は、サーバアプリケーション２１４，２１６によって維持される。サーバアプリケーション２１４，２１６の各々は、ユーザデータベース２０６やユーザデータベース２０８の状態を監視し、サーバアプリケーションに関連したシステムデータベースにおいて、ユーザデータベース２０６およびユーザデータベース２０８の各々の状態を記録する。例えば、ユーザデータベース２０６の状態が「ライブ」から「ミラー」へ変化するとき、ユーザデータベース２０６の状態の変化はサーバアプリケーション２１４によって監視され、システムデータベース２１０に記録される。また、同時の「ミラー」から「ライブ」へのユーザデータベース２０８の状態の変化も、サーバアプリケーション２１４によって監視され、システムデータベース２１０に記録される。同様に、ユーザデータベース２０８の状態が「ミラー」から「ライブ」へ変化するとき、ユーザデータベース２０８の状態の変化はサーバアプリケーション２１６によって監視され、システムデータベース２１２に記録される。同時の「ライブ」から「ミラー」へのユーザデータベース２０６の状態の変化は、サーバアプリケーション２１６によって監視され、システムデータベース２１２に記録される。

サーバアプリケーション２１４，２１６がユーザデータベース２０６，２０８の状態変化を監視している間、サーバアプリケーションモジュール２１８，２２０はデータベースミラーリングシステム２００内のユーザデータベース２０６，２０８の状態情報を管理する。サーバアプリケーションモジュール２１８，２２０などのモジュールは、ユーザデータベースのバックアップおよび／または復元などの機能を実行することの可能な１つのコードである。例えば、モジュールによって実行される機能は、Ｍｉｃｒｏｓｏｆｔ（登録商標）ＳＱＬ Ｓｅｒｖｅｒデータベースのバックアップおよび／または復元であり、この場合、ユーザデータベース２０６，２０８は、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒデータベースであり、サーバアプリケーション２１４，２１６は、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒアプリケーションである。本発明は、Ｍｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒと共に用いられてもよいが、本発明の範囲はＭｉｃｒｏｓｏｆｔ ＳＱＬ Ｓｅｒｖｅｒと共に使用することに限定されない。

各々のサーバアプリケーション２１４，２１６は、特定のサーバアプリケーションモジュールに関連する。サーバアプリケーションモジュール２１８はサーバアプリケーション２１４に関連し、サーバアプリケーションモジュール２２０はサーバアプリケーション２１６に関連する。データベースサーバ２０２上では、サーバアプリケーションモジュール２１８がシステムデータベース２１０に状態情報を問い合わせ、ユーザデータベース２０６がライブユーザデータベースであるか、ミラーユーザデータベースであるかを見出す。同様に、データベースサーバ２０４上では、サーバアプリケーションモジュール２２０がシステムデータベース２１２に状態情報を問い合わせ、ユーザデータベース２０８がライブユーザデータベースであるか、ミラーユーザデータベースであるかを見出す。データベースミラーリングシステム２００におけるライブユーザデータベースのバックアップに先立って、サーバアプリケーションモジュール２１８，２２０のうちの一方は現行のライブユーザデータベースを識別する。ユーザデータベースバックアップ操作に関連するライブユーザデータベースの識別は、図４を用いて以下においてさらに詳細に検討する。

サーバアプリケーションモジュール２１８，２２０はバックアップ操作中にライブユーザデータベースを識別するのみならず、バックアップおよび復元操作中にミラー関係を調停および管理するために、サーバアプリケーションモジュール２１８，２２０は互いに通信も行う。サーバアプリケーションモジュール２１８，２２０が、図１に示すバックアップサーバ１０２に相当するバックアップサーバ２２１によって呼び出されるとき、サーバアプリケーションモジュール２１８，２２０はユーザデータベース２０６，２０８の指定における変化を検出することが可能である。ユーザデータベース２０６，２０８の指定における変化が検知されると、サーバアプリケーションモジュール２１８，２２０は、ユー
ザデータベース２０６，２０８の指定における変化に関して、互いに通信を行う。サーバアプリケーションモジュール２１８，２２０が互いに通信を行った後、サーバアプリケーションモジュール２１８，２２０はバックアップサーバ２２１にユーザデータベース２０６，２０８の指定における変化を伝達する。次いでバックアップサーバ２２１は、バックアップされるデータベースサーバのためのセーブセットにおいてユーザデータベース２０６，２０８の指定に関する情報を更新するとともに、ライブデータベースに相当するサーバアプリケーションモジュール２１８または２２０を呼び出し、バックアップを完了することが可能である。

バックアップおよび復元操作を完了するためにサーバアプリケーションモジュール２１８，２２０が互いと、また続いてバックアップサーバ２２１とどのように通信を行うかに関する一例として、フェイルオーバが発生し、ユーザデータベース２０６の状態を「ライブ」から「ミラー」へ変化させると仮定する。フェイルオーバの発生後、サーバアプリケーションモジュール２１８が呼び出されるとき、サーバアプリケーションモジュール２１８はユーザデータベース２０６の状態に関し、サーバアプリケーションモジュール２２０と通信を行う。サーバアプリケーションモジュール２１８はサーバアプリケーションモジュール２２０から、ユーザデータベース２０８が現在はライブデータベースであることを学習する。サーバアプリケーションモジュール２１８はまた、サーバアプリケーションモジュール２２０に、ユーザデータベース２０６が現在はミラーデータベースであることを通知する。サーバアプリケーションモジュール２２０との通信後、サーバアプリケーションモジュール２１８はバックアップサーバ２２１と通信を行い、バックアップサーバ２２１にユーザデータベース２０６およびユーザデータベース２０８の状態の変化を通知する。次いで、バックアップサーバ２２１は、データベースミラーリングシステム２００においてバックアップされるデータベースサーバのセーブセット情報として、変更された状態情報を記録する。この処理はプロービングと呼ばれ、ライブデータベースをロケーションするために用いられる。

データベースサーバ２０２，２０４内でサーバアプリケーションモジュール２１８，２２０により実行される機能は、データベースミラーリングシステム２００内のバックアップ操作に必要な一部である。データベースミラーリングシステム２００内でバックアップ操作が実行可能となる前に、最初にライブデータベースのロケーションが確認される必要がある。バックアップ操作が開始されるとき、データベースサーバ２０２上にロケーションされたサーバアプリケーション２１４およびデータベースサーバ２０４上にロケーションされたサーバアプリケーション２１６のうちのいずれかは、ライブユーザデータベースをロケーションするためにコンタクトされ得る。バックアップ操作は、ユーザまたはバックアップサーバ２２１により開始され得る。バックアップサーバ２２１がサーバアプリケーションモジュール２１８，２２０にコンタクトし、それらは順次サーバアプリケーション２１４，２１６と順次コンタクトし、ユーザデータベース２０６，２０８の状態を知る。ライブユーザデータベース２０６，２０８に相当するサーバアプリケーションモジュール２１８，２２０は、バックアップ操作を実行する。ユーザデータベース２０６，２０８の状態は、システムデータベース２１０，２１２から情報を読み取ることによって決定される。例えば、バックアップサーバ２２１がサーバアプリケーションモジュール２１８とコンタクトする場合、サーバアプリケーションモジュール２１８は、サーバアプリケーション２１４とコンタクトすることによってシステムデータベース２１０におけるテーブルエントリを読み取る機能を実行する。同様に、バックアップサーバ２２１がサーバアプリケーションモジュール２２０とコンタクトする場合、サーバアプリケーションモジュール２２０は、サーバアプリケーション２１６とコンタクトすることによってシステムデータベース２１２におけるテーブルエントリを読み取る機能を実行する。システムデータベース２１０，２１２に格納されたテーブルエントリは、ユーザデータベース２０６，２０８の状態に関する情報を格納している。各システムデータベース２１０，２１２は、データ
ベースミラーリングシステム２００における各ユーザデータベース２０６，２０８の状態に関する情報を格納している。例えば、システムデータベース２１０は、ユーザデータベース２０６の状態についての情報を「ライブ」として格納しており、またユーザデータベース２０８の状態についての情報を「ミラー」として格納している。各ユーザデータベース２０６，２０８に関しシステムデータベース２１０，２１２に格納されている情報により、バックアップサーバがデータベースサーバ２０２，２０４にロケーションされたサーバアプリケーションモジュール２１８，２２０のうちの一方のみとコンタクトすることによって、ライブデータベースのロケーションに関する情報を取得することが可能となる。

バックアップ操作中にデータベースミラーリングシステム２００において実行される機能の一例として、ユーザデータベース２０６が現在はライブユーザデータベースであり、ユーザデータベース２０８が現在はミラーデータベースであると仮定する。バックアップが開始されるとき、バックアップサーバ２２１は、データベースサーバ２０４上にロケーションされたサーバアプリケーションモジュール２２０にコンタクトする。次いで、サーバアプリケーションモジュール２２０は、サーバアプリケーション２１６とコンタクトすることによってシステムデータベース２１２に格納されているテーブルエントリを読み取る機能を実行する。システムデータベース２１２におけるテーブルエントリは、ユーザデータベース２０８がミラーデータベースであることと、ユーザデータベース２０６がライブデータベースであることとを示す。サーバアプリケーションモジュール２２０は、この情報をバックアップサーバ１０２に返す。次いで、ユーザデータベース２０６が現在はライブデータベースであるので、バックアップサーバ２２１はユーザデータベース２０６をバックアップする。

ここで図１を参照すると、ライブユーザデータベースがバックアップされるとき、ライブユーザデータベースの存在するデータベースサーバの名称は、バックアップサーバ１０２上にロケーションされたファイルインデックス１１８に記録される。ライブユーザデータベースについてファイルインデックス１１８に作成されたエントリは、ライブエントリである。また、ミラーデータベースが存在するデータベースサーバの名称も、ファイルインデックス１１８に記録される。ミラーユーザデータベースについてファイルインデックス１１８に作成されるエントリは、別名エントリと呼ばれる。特定のバックアップの時刻に各ユーザデータベースの状態を記録することによって、ファイルインデックス１１８におけるエントリは、一連のバックアップを再構築し、ライブユーザデータベースの復元がリクエストされる場合にライブユーザデータベースのロケーションを容易に識別するための手法を提供することを可能にする。

ここで図２に戻ると、バックアップサーバ１０２がライブユーザデータベースをバックアップすることを可能とするために、ユーザデータベース２０６，２０８の状態がデータベースミラーリングシステム２００内にトラッキングされることは、先に説明した。データベースサーバ２０２，２０４は、それぞれ、ユーザデータベース２０６，２０８の状態をトラッキングするシステムデータベース２１０，２１２を備え、またユーザデータベース２０６，２０８の状態をトラッキングするために、ウィットネス２２２もデータベースミラーリングシステム２００に組み込まれ得る。例えば、ユーザデータベース２０６が「ライブ」データベースから「ミラー」データベースへ状態を変化させるとき、ウィットネス２２２は、ユーザデータベース２０６の現行の状態をシステムデータベース２２４に記録することによって、この変化をトラッキングする。同様に、ユーザデータベース２０８が「ミラー」データベースから「ライブ」データベースへ状態を変化させるとき、ウィットネス２２２は、ユーザデータベース２０８の状態の変化もシステムデータベース２２４に記録する。このようにして、システムデータベース２２４は、それぞれデータベースサーバ２０２，２０４上にロケーションされたシステムデータベース２１０，２１２によって実行されるのと同様の機能を実行する。

ウィットネス２２２とデータベースサーバ２０２，２０４との間のさらなる類似点は、データベースサーバ２０２，２０４と同様に、ウィットネス２２２がサーバアプリケーション２２６およびサーバアプリケーションモジュール２２８を備えることである。サーバアプリケーション２２６は、サーバアプリケーション２１４，２１６によって実行される機能と均等な機能を実行する。すなわち、サーバアプリケーション２２６は、ユーザデータベース２０６，２０８の状態に関してサーバアプリケーション２１４，２１６によって更新され、システムデータベース２２４内にこの情報の記録を維持する。サーバアプリケーションモジュール２１８，２２０と同様に、サーバアプリケーションモジュール２２８は、ユーザデータベース２０６，２０８の状態情報を学習するために、サーバアプリケーションモジュール２１８，２２０と通信を行う。また、サーバアプリケーションモジュール２２８はサーバアプリケーション２２６とコンタクトすることによって、システムデータベース２２４からこの情報を読み出してもよい。

ウィットネス２２２は、ユーザデータベース２０６，２０８における状態変化をトラッキングすることに加え、他の機能を実行してもよい。例えば、ウィットネス２２２はデータベースミラーリングシステム２００における役割の割当に参加する。詳細には、ウィットネス２２２は、ユーザデータベース２０６に対するライブデータベースの役割の割当と、ユーザデータベース２０８に対するミラーデータベースの役割の割当とに参加してもよい。この役割の割当は、データベースサーバ２０２，２０４、およびウィットネスデータベースサーバ２２２の間の多数決に基づく。より詳細には、ウィットネス２２２はユーザデータベース２０６およびユーザデータベース２０８のそれぞれの役割における変化を調停することができる。ウィットネス２２２は、データベースミラーリングシステム２００内の自動的なフェイルオーバと、それに伴うユーザデータベース２０６，２０８の状態の変化とを推進してもよい。例えば、ユーザデータベース２０６がライブデータベースであるときにフェイルオーバが発生する場合、ウィットネス２２２は即座にユーザデータベース２０８にライブデータベースの役割を割り当て、ユーザデータベース２０６の役割をミラーデータベースへ変化させる。ユーザデータベース２０６，２０８の役割の変化を調停することによって、ウィットネス２２２はフェイルオーバの発生時にデータが失われないことを確実にする。データベースミラーリングシステム２００にウィットネス２２２が存在しない場合、ユーザがフェイルオーバを推進し、ユーザデータベース２０８にライブデータベースの役割を割り当て、ユーザデータベース２０６にミラーデータベースの役割を割り当てることを選択してもよい。

図２には、データベースミラーリングシステムが主サーバ２０２、第２のサーバ２０４、およびウィットネス２２２のみを備える場合を示すが、データベースをミラーリングする多数の他の構成が可能である。図３に示すように、どれだけ多くの異なるデータベースがミラーリングされるかに関する制限は存在せず、ミラーデータベースをホストするデータベースサーバ間の関係に関するいかなる制限も存在しない。例えば、第１のデータベースサーバ３０２は、ライブデータベース「Ａ」３０４やミラーデータベースｎ’３０６をホストする。第２のデータベースサーバ３０８は、ライブデータベース「Ｂ」３１０およびミラーデータベースＡ’３１２をホストする。この例では、第２のデータベースサーバ３０８上に存在するミラーデータベースＡ’３１２は、第１のデータベースサーバ３０２上に存在するライブデータベースＡ３０４に関連する。しかしながら、ライブデータベースＢ３１０に関連するミラーデータベースＢ’３１４は、第１のデータベースサーバ３０２上には存在せず、代りに第３のデータベースサーバ３１６上に存在する。第３のデータベースサーバ３１６は、ミラーデータベースＢ’３１４をホストすることに加え、ライブデータベースＣ３１８をホストする。最後に、第ｎ番目のデータベースサーバ３２０は、データベースｎ３２２およびミラーデータベース（ｎ−１）’３２４をホストする。図３には、複数のデータベースサーバ上のライブデータベースおよびミラーデータベースの構
成の代表的な実施形態を示す。加えて、任意のデータベースサーバ３０２，３０８，３１６，３２０は、任意のデータベースのウィットネスとして機能し得る。しかしながら、任意数のデータベースサーバ上のライブデータベースおよびミラーデータベースについて、任意数の異なる構成が可能であり、また本発明の実施形態によって想定される。本発明の範囲は、特定のサーバ上に存在するライブデータベースおよびミラーデータベースについての任意の特定の構成と共に使用することに限定されない。

Ｂ． ミラーリング機能
再び図２を見ると、モジュール２１８，２２０，２２８、およびユーザデータベース２０６，２０８は、データベースミラーリングシステム２００の構成要素の例である。モジュール２１８，２２０，２２８、およびユーザデータベース２０６，２０８は、データがデータベースミラーリングシステム２００において、データベース２０６，２０８からバックアップされるように協働するように構成されている。

前述したように、代表的なデータベースミラーリングシステム２００は、少なくとも２つのデータベースサーバ２０２，２０４、ライブユーザデータベース２０６、およびミラーユーザデータベース２０８を備える。２つ以上のデータベースサーバ２０２，２０４を備えるネットワークにおいて、ユーザデータベース２０６，２０８のそれぞれはライブユーザデータベース、またはミラーユーザデータベースの役割を割り当てられていてよい。ライブユーザデータベース２０６およびミラーユーザデータベース２０８は初期には「ライブ」または「ミラー」として指定されているが、具体的なデータベースの指定は随時変更できる。したがって、「ライブ」または「ミラー」の役割は動的に再分担される。例えば、データベースサーバ２０２に存在するユーザデータベース２０６は、当初ライブユーザデータベースとして指定されたものであってよい。ライブユーザデータベースとして指定された、データベースサーバ２０２に存在するユーザデータベース２０６に対し、データベースサーバ２０４に存在するユーザデータベース２０８は、ミラーユーザデータベースとして指定され得る。その後、ユーザデータベース２０６，２０８の役割は変更され得、ユーザデータベース２０６の呼称は「ライブ」から「ミラー」へ、さらにユーザデータベース２０８の呼称は「ミラー」から「ライブ」へ変更されよう。ユーザデータベース２０６，２０８の役割は、例えば、ユーザデータベース２０６が存在するデータベースサーバ２０２の故障、各ユーザデータベースの役割スケジュールの変更、またはネットワーク内のウィットネス２２２などの付加的なデータベースサーバまたは他のシステムデバイスによる調停などの、いかなる理由によっても変更され得る。

ユーザデータベース２０６，２０８のライブまたはミラーの役割は、データベースミラーリングシステム２００内において時間の経過に伴い動的に変化するだけではなく、役割は不特定ではなく、具体的にそれぞれのユーザデータベース２０６，２０８により実行される機能を意味する。詳細には、データベースミラーリングシステム２００は、ライブユーザデータベース２０６がシステム内における活動データベースなので、ユーザデータベース２０６を「ライブ」であると指定する。バックアップ操作において、ライブユーザデータベース２０６は、データベースミラーリングシステム２００内においてバックアップされるデータベースである。一方、ミラーユーザデータベース２０８は非活動データベースであり、ミラーユーザデータベースとして機能している限り、バックアップ操作には直接的には関与しない。

ミラーユーザデータベース２０８はバックアップ操作には直接的には関与しないが、データベースミラーリングシステム２００は、ミラーユーザデータベース２０８に対して任意のときにライブユーザデータベースに切り替わるように要求することができる。このため、同期ミラーリングにおいて、ミラーユーザデータベース２０８は、ライブユーザデータベースのテーブルが改変される度に、データベース更新に関する情報を受信し、格納す
る。すなわち、ミラーユーザデータベース２０８は、ライブユーザデータベース２０６の更新記録を保持するために、ライブユーザデータベース２０６の中に作成されたエントリのミラーリングを行う。このようにして、データベースミラーリングシステム２００がミラーユーザデータベース２０８に対してライブユーザデータベースに切り替わるように要求した場合に、ユーザデータベース情報が消失したりアクセス不可能になったりすることはない。それは、ライブユーザデータベース２０６に存在した全ての情報は、ミラーユーザデータベース２０８もまた存在するからである。

ライブユーザデータベースとミラーユーザデータベースとの役割分担は、ベットワークのバックアップ操作において、特に重要である。バックアップ操作は様々な方法で開始され得る。ユーザデータベースをバックアップする一方法は、システムの個人ユーザが自分で選択した任意のときに、指定したユーザデータベースのバックアップを開始することである。データベースをバックアップする他の方法は、管理者がシステム内のいずれのユーザデータベースを自動的にバックアップするのかというシステム内スケジュールを明示することである。管理者はシステム内の全てのユーザデータベースを指定してもよいし、バックアップ操作によりバックアップされるシステム内のユーザデータベースのみを指定してもよい。データベースミラーリング環境におけるバックアップ操作は、後掲の項目Ｄにおいてさらに詳細に検討する。

本明細書に開示されたようなデータベースミラーリングプロセスを実行するための代表的な標準規格としては、マイクロソフトＳＱＬサーバ２００５（コード名 ユーコン（Ｙｕｋｏｎ））がある。本発明の実施態様の一例において、マイクロソフトＳＱＬサーバ２００５（ユーコン）データベースが用いられ得る。しかし、他の使用法、およびアプリケーションもまた本発明において適合し、かつ好ましい。本発明の範囲はマイクロソフトＳＱＬサーバ２００５（ユーコン）を用いることに限定されるものではない。

Ｃ． ミラーリング環境におけるプロービングプロセスの実行
データベースミラーリングバックアップシステムの一例は、データベースミラーリングシステム２００内において重要な機能を実行するアプリケーションおよびモジュールを組み込んでいる。モジュール２１８，２２０，２２８により実行される機能は、データベースミラーリングシステム２００の機能の一部である。データベースミラーリングシステム２００の１つ以上のユーザデータベースのバックアップが開始されるときには、プロービングプロセスが実施され、ライブユーザデータベースをデータベースミラーリングシステム２００内にロケーションする。プロービングプロセスは、システムデータベース２１０，２１２に関連するモジュール２１８，２２０，２２８により実行される特定の機能を備える。プロービングプロセスの目的はライブユーザデータベースのロケーションを判定することであり、これにより、システム内のライブユーザデータベースは、バックアップ操作においてバックアップされ得る。

ライブユーザデータベースのバックアップが開始されるときに実施されるプロービングプロセス４００の代表的な態様を図４に示す。上記のように、プロービングプロセス４００は、ライブユーザデータベースをデータベースミラーリングシステム２００内に配置するプロセスである。プロービングプロセス４００は、バックアップサーバが、工程４０２においてデータベースサーバと称するクライアントとコンタクトしたときに開始し、クライアントに対してクライアントにロケーションされたデータベースの状態に関するリクエストをする。バックアップサーバとクライアントとのコンタクトは、ライブデータベースのバックアップが実行されるときを特定したシステムスケジュールによったり、様々な他の方法によったりして、ライブデータベースをバックアップするリクエストにより開始され得る。バックアップサーバが指名されたクライアントとコンタクトした後、クライアントに配置されたサーバアプリケーションモジュールは、工程４０４に示すように、ライブ
データベースのロケーションに関する情報リクエストを受信する。その後サーバアプリケーションモジュールは、質問されたクライアントのデータベースサーバにロケーションされたシステムデータベースとコンタクトし、ライブユーザデータベースのロケーションを判定する。

工程４０６に示すように、サーバアプリケーションモジュールが、クライアントにロケーションされたシステムデータベースに含まれるテーブルエントリを読み出すと、ライブデータベースのロケーションが判定される。テーブルエントリは、データベースミラーリングシステム内のデータベースの状態に関する情報を含んでいる。工程４０８において、サーバアプリケーションモジュールは、テーブルエントリに対して質問し、質問をうけているクライアントがライブデータベースであるか否かを判定する。工程４１０に示すように、テーブルエントリが、ライブデータベースは質問をうけているクライアントにロケーションされていると特定した場合には、ライブデータベースがロケーションされているので、バックアップが進行できる。

しかし、工程４１２に示すように、テーブルエントリが別のクライアントにロケーションされた別のデータベースをライブデータベースとして特定すると、サーバアプリケーションモジュールは、質問を受けているクライアント上のデータベースはライブデータベースではないと認識する。その後工程４１４に示すように、サーバアプリケーションモジュールは、ライブデータベースの存在するクライアントの名称を、バックアップサーバに返送する。次にプロービングプロセス４００は工程４０２を再開し、バックアップサーバが、ライブデータベースをホストし、かつ工程４１４においてサーバアプリケーションモジュールにより指名されたクライアントにコンタクトする。プロービングプロセス４００のこの時点において、ライブデータベースをホストするクライアントは特定されているので、工程４０２〜４０８は順調に進行し、工程４１０まで続行する。しかし、ライブデータベースの配置されているクライアントが特定され、それまでバックアップサーバがライブクライアントにコンタクトするまでにフェイルオーバが生じた場合、ライブクライアントはミラークライアントになる。この場合には、工程４０２，４０６，４０８，４１２，４１４がもう一度繰り返される。多くの場合、１回または２回の繰り返しにより、ライブデータベースの配置およびファイルのバックアップを充分にプロービングできる。３回繰り返すことはあまりないが、極めて短時間のうちに２つのフェイルオーバが生じたので、データベースサーバ内が相当に不安定であることを示している。

工程４１０に戻ると、システムテーブルエントリが、質問を受けているクライアントはライブデータベースをホストしていると特定するなら、プロセスは工程４１６に続いており、バックアップされるデータベースファイル（すなわち「当該ファイル」）が特定される。データベースファイルが特定されると、ファイルはバックアップされ、プロービングプロセス４００は工程４１８に示すように完了する。このバックアップ操作に関する詳細に関しては、図５を検討しつつ、以下に示す。

Ｄ． ミラーリング環境におけるデータベースバックアップ操作
バックアッププロセス５００は、データベースミラーリング環境におけるデータベースの動的な役割変更が何であるかにかかわらず、データベースのバックアップを行うプロセスの一例である。データベースが初めにバックアップされると、同データベースのエントリが、データベースミラーリングシステムにおけるバックアップサーバのファイルインデックス内に作成される。ファイルインデックス内のエントリは同データベースに関する情報を含んでおり、同データベースの状態を「ライブ」または「ミラー」として有する。データベースミラーリング環境内においてデータベースがバックアップされるたびに、付加的なエントリがデータベースのファイルインデックスに追加される。バックアップ時にバックアップエントリに含まれる情報は、データベースの状態に関する初期のエントリに含
まれる情報と類似している。例えば、バックアップ時に作成されるエントリは、バックアップが実行された日、バックアップが実行された時間、およびバックアップが実行された時のデータベースの状態などの情報を含むことができる。

バックアップが実行された時にデータベースの状態に関する情報を含むことに加えて、データベース用のファイルインデックスのエントリは、システム内のミラーデータベースとの相互参照をも備える。より詳細には、当該データベースはバックアップ時にはライブデータベースであるので、ファイルインデックスの当該データベースのエントリは、バックアップ時にはミラーデータベースを有するデータベースサーバを相互参照する。ファイルインデックス中のライブおよびミラーデータベースのクライアントマシンを相互参照することにより、複数のバックアップが実行されている期間を通した当該データベースの状態を追跡することができるとともに、ライブおよびミラーデータベースが同一のデータベースであることを判定できる。単一のデータベースのための１つのエントリを検索することにより、システム内の他のクライアントマシンの身元に関する情報が得られる。

データベースミラーリングシステム内のデータベースをバックアップするには、先ずバックアップ対象データベースが特定されねばならない。バックアップサーバはバックアッププロセスを開始する固有のクライアントを特定する。これを図５の工程５０２に示す。システム管理者は、特定のバックアップ操作中にシステム内の全データベースがバックアップされると決定してもよいし、システム管理者は１つのバックアップ操作中に、選定されたデータベースのみがバックアップされると決定してもよい。別の可能性としては、システムユーザが、バックアップ操作に含めたいと思う特定のデータベースを指定してもよい。これに替えて、バックアップシステムは、特定のスケジュールにしたがって、特定のデータベースの全体または一部を自動的にバックアップするように構成してもよい。

バックアップ対象のデータベースが管理者またはユーザにより指定されていても、他の方法であっても、バックアップサーバは特定のクライアントマシンにコンタクトし、プロービングプロセス（図４参照）を開始する、すなわち、バックアップサーバは、工程５０４に示すように、ライブデータが存在するクライアントマシンの名称について特定のクライアントマシンに対して質問する。次に、バックアップサーバは、工程５０６に示すように、ライブデータベースが存在するクライアントマシンにコンタクトする。バックアップサーバは、ライブデータベースがクライアントマシンにコンタクトした後、工程５０８に示すように、ライブデータベースがバックアップされる。次に、ライブデータベースが存在するクライアントマシンの名称は、工程５１０に示すように、バックアップサーバのファイルインデックスにライブエントリとして書き込まれる。ミラーデータベースが存在するクライアントマシンの名称はまた、ファイルインデックスに書き込まれるが、工程５１２に示すように別名エントリとして書き込まれる。別名エントリは、ライブデータベースのために作成されたエントリとの相互対照を含む。

データベースミラーリングシステム内で生じ得るユーザのバックアップへのアクセス容易性の一例として、データベースサーバＡがデータベースのホストであるときに、最初の一連のバックアップが行われ得る。データベースサーバＡにホストされるデータベースはライブデータベースである。最初の一連のバックアップが行われた後でデータベースサーバＡがクラッシュし、ライブデータベースの役割が自動的にデータベースサーバＢにホストされるデータベースに切り替わるなどのフェイルオーバが生じた場合、後続の一連のバックアップは、データベースがデータベースサーバＢにホストされている間に実行される。換言すれば、データベースサーバＢがライブデータベースである間に、後続の一連のバックアップが実行される。バックアップは、データベースサーバＡがライブデータベースである間でも、データベースサーバＢがライブデータベースである間でも実行されるが、一連のバックアップは、バックアップサーバのファイルインデックスに含まれるエントリ
中のデータベース同士の相互参照を用いて、再構築され得る。

本明細書において開示した方法によりバックアップされたデータは、任意の多様な用途に用いられ得る。例えば、バックアップされたデータは、オリジナルデータが喪失することとなるシステム障害または他の事態において、オリジナルデータベースを回復することに用いることができる。例えば、図１のユーザデータベース２０６，２０８においてデータの喪失が生じた場合には、データのバックアップされたコピーを用いて、ユーザデータベース２０６，２０８を回復することができる。喪失されたデータを、本明細書において開示した方法により生成されたバックアップデータを用いて回復する方法の事例は、本願と同日付にて出願した「データを回復するためのシステムおよび方法（Ｓｙｓｔｅｍｓ ａｎｄ Ｍｅｔｈｏｄｓ ｆｏｒ Ｒｅｓｔｏｒｉｎｇ Ｄａｔａ）」と題する米国特許出願第１１／０８０，０４７号に記載されている。

本発明は本発明の精神または本質的な特性から逸脱することなく、他の具体的な形態で実施することができる。上記の説明した実施態様は単に例示するためのものであり、限定しようとするものではない。したがって本発明の範囲は、上記の説明ではなく、添付の請求の範囲により示される。前記請求の範囲の意義および等価物の範囲に属する全ての改変は、前記請求の範囲の中に入るものとみなされる。

ネットワーク内におけるファイルシステムデータをバックアップするためのシステムの一例を示す概略図。 データベースミラーリング環境におけるデータベースをロケーションするためのシステムの一例を示す概略図。 データベースミラーリング環境における複数データベース間のミラーリング関係を構成するためのシステムの一例を示す概略図。 データベースミラーリング環境におけるライブデータベースを判別し、データベースをバックアップするためのプロセスの一例を示す概略図。 データベースミラーリング環境におけるデータベースをバックアップするためのプロセスの一例を示す概略図。

Claims (27)

1. ライブデータベース、ミラーデータベースおよび複数のクライアントマシンを備えるデータベースミラーリングネットワークにおいて、データベースをバックアップする方法であって、
   前記複数のクライアントマシンのうちの１つに対してリクエストを送信し、そのリクエストの対象となるクライアントマシンと関連するデータベースの状態情報を得る工程と、
   前記クライアントマシンから、前記ライブデータベースのロケーションを識別する前記状態情報を受信する工程と、
   前記ライブデータベースの指定の変更が進行中であっても、前記ライブデータベースのロケーションを識別する前記状態情報を用いて、前記ライブデータベースをバックアップする工程と
   を備える方法。
2. 前記ライブデータベースのロケーションを識別する前記状態情報は、前記リクエストの対象となるクライアントマシンのシステムデータベースにロケーションされる、請求項１に記載の方法。
3. 前記関連するデータベースの状態情報が、前記関連するデータベースはミラーデータベースであることを特定する場合、システムデータベース内の情報は、前記ライブデータベースをホストするクライアントマシンを識別する、請求項１に記載の方法。
4. 前記複数のクライアントマシンのうちの１つに対してリクエストを送信する工程は、前記ライブデータベースを自動的にバックアップする時間を特定するスケジュールにしたがって実行される、請求項１に記載の方法。
5. 前記複数のクライアントマシンのうちの１つに対してリクエストを送信する工程は、ユーザが前記ライブデータベースのバックアップを開始することに応答して実行される、請求項１に記載の方法。
6. 前記ライブデータベース内の該当ファイルを識別する工程をさらに備え、それにより前記ライブデータベースをバックアップする工程は前記該当ファイルをバックアップする工程を含む、請求項１に記載の方法。
7. 前記ライブデータベースをバックアップする工程は、
   バックアップ時に、バックアップサーバにロケーションされたファイルインデックスに、前記ライブデータベースのロケーションに関するエントリを作成する工程と、
   バックアップ時に、バックアップサーバにロケーションされたファイルインデックスに、前記ミラーデータベースのロケーションに関する別名エントリを作成する工程と
   をさらに含む請求項１に記載の方法。
8. 前記ライブデータベース内の該当ファイルの格納ロケーションを受信する工程と、
   前記ミラーデータベース内の前記該当ファイルの前記格納ロケーションを記録する工程と
   をさらに備える請求項７に記載の方法。
9. 前記ライブデータベース内の前記該当ファイルの格納ロケーションを記録する工程は、前記クライアントマシンにロケーションされたシステムデータベースにテーブルエントリを作成する工程を含む、請求項８に記載の方法。
10. 前記ミラーデータベース内の前記該当ファイルの格納ロケーションを記録する工程は、前記クライアントマシンにロケーションされたシステムデータベースにテーブルエントリを作成する工程を含む、請求項８に記載の方法。
11. 第１のデータベースサーバ、第２のデータベースサーバおよびバックアップサーバを備えるデータベースミラーリングネットワークにおいて、バックアップされるデータベースをロケーションする方法であって、
    バックアップサーバからデータベース状態リクエストを受信する工程と、
    第１のデータベースサーバおよび第２のデータベースサーバのうちの１つと関連するデータベースに関するテーブルエントリをロケーションすることにより、前記データベース状態リクエストに応答する工程と、
    前記テーブルエントリを用いて、前記関連するデータベースの状態情報を識別する工程と、
    前記バックアップサーバに対して、前記関連するデータベースの状態情報を送信する工程とを備え、
    前記状態情報は少なくとも前記データベースがライブデータベースであるか、ミラーデータベースであるかを特定し、前記方法は、ライブデータベースおよびミラーデータベースの指定の変更が進行中であっても実行される方法。
12. 前記データベース状態リクエストは、前記ライブデータベースを自動的にバックアップする時間を特定するスケジュールにしたがって受信される、請求項１１に記載の方法。
13. 前記データベース状態リクエストは、ユーザが前記ライブデータベースのバックアップを開始することに応答して受信される、請求項１１に記載の方法。
14. 前記関連するデータベースの状態情報が、前記関連するデータベースはミラーデータベースであることを特定する場合、前記状態情報は前記ライブデータベースをホストするデータベースサーバを識別する、請求項１１に記載の方法。
15. 前記関連するデータベースの状態情報が、前記関連するデータベースはライブデータベースであることを特定する場合、前記テーブルエントリに記載される前記データベースサーバは前記ライブデータベースをホストする、請求項１１に記載の方法。
16. 前記テーブルエントリは、第１のデータベースサーバおよび第２のデータベースサーバのうちの１つと関連するシステムデータベース内にロケーションされる、請求項１１に記載の方法。
17. ライブデータベース、ミラーデータベースおよび複数のクライアントマシンを備えるネットワーク内のデータベースをバックアップする方法を実行するコンピュータプログラム製品であって、
    前記複数のクライアントマシンのうちの１つに対してリクエストを送信し、そのリクエストの対象となるクライアントマシンと関連するデータベースの状態情報を得る工程と、
    前記クライアントマシンから、前記ライブデータベースのロケーションを識別する前記状態情報を受信する工程と、
    前記ライブデータベースの指定の変更が進行中であっても、前記ライブデータベースのロケーションを識別する前記状態情報を用いて、前記ライブデータベースをバックアップする工程と
    を含む方法を実行するためのコンピュータ実行可能命令を有するコンピュータ可読媒体を備えるコンピュータプログラム製品。
18. 前記状態情報が、前記データベースはライブデータベースであることを特定する場合、前記テーブルエントリに記載されるクライアントマシンは、前記ライブデータベースをホストするクライアントマシンを識別する、請求項１７に記載のコンピュータプログラム製品。
19. 前記関連するデータベースの状態情報が、前記関連するデータベースはミラーデータベースであることを特定する場合、前記状態情報は、前記ライブデータベースをホストするクライアントマシンを識別する、請求項１７に記載のコンピュータプログラム製品。
20. 前記複数のクライアントマシンのうちの１つに対してリクエストを送信する工程は、前記ライブデータベースを自動的にバックアップする時間を特定するスケジュールにしたがって実行される、請求項１７に記載のコンピュータプログラム製品。
21. 前記複数のクライアントマシンのうちの１つに対してリクエストを送信する工程は、ユーザが前記ライブデータベースのバックアップを開始することに応答して実行される、請求項１７に記載のコンピュータプログラム製品。
22. 前記テーブルエントリはシステムデータベースにロケーションされる請求項１７に記載のコンピュータプログラム製品。
23. 前記ライブデータベース内の該当ファイルを識別する工程をさらに備え、それにより、前記ライブデータベースをバックアップする工程は前記該当ファイルをバックアップする工程を含む、請求項１７に記載のコンピュータプログラム製品。
24. 前記ライブデータベースをバックアップする工程は、
    バックアップ時に、バックアップサーバにロケーションされたファイルインデックスに、前記ライブデータベースのロケーションに関するエントリを作成する工程と、
    バックアップ時に、バックアップサーバにロケーションされたファイルインデックスに、前記ミラーデータベースのロケーションに関する別名エントリを作成する工程と
    をさらに含む請求項１７に記載のコンピュータプログラム製品。
25. 前記ライブデータベース内の前記該当ファイルの格納ロケーションを受信する工程と、
    前記ミラーデータベース内の前記該当ファイルの前記格納ロケーションを記録する工程と
    をさらに備える請求項２４に記載のコンピュータプログラム製品。
26. 前記ライブデータベース内の前記該当ファイルの格納ロケーションを記録する工程は、前記クライアントマシンにロケーションされたシステムデータベースにテーブルエントリを作成する工程を含む、請求項２５に記載のコンピュータプログラム製品。
27. 前記ミラーデータベース内の前記該当ファイルの格納ロケーションを記録する工程は、前記クライアントマシンにロケーションされたシステムデータベースにテーブルエントリを作成する工程を含む、請求項２５に記載のコンピュータプログラム製品。

Images