JP4638905B2 - データベースのデータ復旧システムおよびその方法 - Google Patents

Description

本発明は、一般にデータベースに関し、より詳細にはデータベース復元技術に関する。

データベースシステムが、今日の世界において非常に普及している。データベースは、迅速な照会を実行し簡単に使用できるような方法で、大量の情報を記憶する。例えば、従来のリレーショナルデータベース（ｒｅｌａｔｉｏｎａｌ ｄａｔａｂａｓｅ）においては、情報は、レコード、テーブル、インデックスなどのオブジェクトとして構成することができる。データベースエンジンは、ユーザによるクエリ（ｑｕｅｒｙ）の仕様に応じてデータベーステーブルからデータを検索し操作するメカニズムを提供する。クエリは、一般的にＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ Ｑｕｅｒｙ Ｌａｎｇｕａｇｅ構造化照会言語）などの何らかの照会言語によって表される。クエリは、１つもしくは複数のテーブル、ならびに、検索し、また他の方法で操作すべきそのテーブル中の行および列を指定することができる。適切なクエリの仕様に応じて、データベースエンジンは、データを検索し、指定された任意のオペレーションを実施し、結果テーブルを生成する。データベースは、少なくとも部分的にはその大量のデータを記憶する機能のために人気があり、有用であり、このデータは、単にクエリの仕様を決めることによって効率的に検索し、操作することができる。

残念ながら、ユーザエラーは、データベースシステムにおける共通の問題になっている。通常、このようなエラーは、データベースアプリケーションもしくはユーザが誤ってデータを変更または削除するときに発生し、このデータベースシステムは、このコマンドに正確に従い、即座にデータを変更または削除してしまう。これについては、当技術分野においてクイックフィンガ削除問題（ｑｕｉｃｋ ｆｉｎｇｅｒ ｄｅｌｅｔｅ ｐｒｏｂｌｅｍ）と呼ばれている。例えば、ユーザが、テーブルを削除するコマンドを発行し、「ＷＨＥＲＥ」節を指定するのを忘れて、意図した以上に多くのデータを削除してしまう可能性がある。さらに、ユーザが、このユーザの気が付かない内にデータベースを修正する新しいアプリケーションをインストールしてしまうこともある。従来、この問題には、いくつかの解決方法が存在する。一般に、最も一般的な解決方法は、ユーザエラーの発生に先立つポイントインタイム（ｐｏｉｎｔ ｉｎ ｔｉｍｅ）までデータベース全体を復元することである。復元された後に、このデータベースは、オンラインになり、このユーザエラーを含めてすべての変更が失われる可能性がある。しかしながら、データベース全体の復元には長時間かかり、時には、完了するのに数日かかってしまうこともある。

代わりに、うっかりと修正されてしまったデータは、復元データベースから関連情報を抽出し、この情報を元のデータベースに戻してマージすることによって修復することもできる。この仕組みの変形は、ログシッピング（ｌｏｇ ｓｈｉｐｐｉｎｇ）と呼ばれる。

ログシッピングとは、他の二次サーバ上のデータベースのコピーを復元状態に保つものであるが、元のサーバからある一定の遅延が存在する。ログバックアップは、ある遅延（例えば、２４時間）後に初めてこの二次データベースに適用される。ユーザエラーが元のデータベース上で発生し、データベース管理者が、この遅延時間内にこのエラーに気付く場合には、二次サーバが、すでにこのエラーに先立つポイントインタイムにおけるこのデータベースを含んでいるので、このデータベース管理者は、この二次サーバ上へと復帰させる（ｒｅｖｅｒｔ ｔｏ）ことができる。残念ながら、ログシッピングは、複雑であり、多くの追加のリソースおよびスペースを必要とする。

従来のシステムおよび方法を利用したデータベースの復元は、かなり大きな遅延時間を必要としている。したがって一般的には、最後の手段としてのオプションである。さらに、ログシッピングでは、追加のハードウェアが必要になり、データベースシステムが複雑になってしまう。エラーを緩和することは、データベースシステムにおける大きな重要な課題である。したがって、とりわけ、高速でありしかも簡単でもあるデータベースを復元する新しいシステムおよび方法が、当技術分野において必要になっている。

本発明の一部態様についての基本的な理解をもたらすために、本発明の簡略化された概要を以下に示している。この概要は、本発明の広範囲にわたる概説ではない。ここで、本発明の主要／クリティカルな要素を特定し、あるいは、本発明の範囲を示す意図はない。その唯一の目的は、以降に提示されるより詳細な説明に対する前置きとして、簡略化した形式で本発明の一部の概念を示すことにある。

本発明は、データベーススナップショット（ｄａｔａｂａｓｅ ｓｎａｐｓｈｏｔ）の作成および使用に関する。本発明は、データベースを復元することに関連する問題を軽減する。データベースを復元することは、一般的に追加のハードウェアを必要としデータベースシステムを複雑にしてしまうログシッピングと同様に、時間がかかり、また一般に最後の手段としての選択肢になっている。データベーススナップショットへと復帰させることにより、これらの問題の一部が軽減される。本発明の一態様によれば、ＤＢＳＳ（ｄａｔａｂａｓｅ ｓｎａｐｓｈｏｔデータベーススナップショット）は、別の（ソース）データベースの読取り専用ポイントインタイムコピー（ｒｅａｄ ｏｎｌｙ， ｐｏｉｎｔ ｉｎ ｔｉｍｅ ｃｏｐｙ）のように見えるデータベースである。ＤＢＳＳは、必ずしもソースデータベースの完全なコピーであるとは限らない。すなわち、これら２つのデータベースは、両者に共通のデータを共有しており、これによって、ＤＢＳＳを高速に作成できるようになり、スペースが効率的になっている。ソースデータベースが修正されるときに、この元のデータは、ＤＢＳＳが使用するためのスペース効率の良いストレージにコピーされて、ソースデータベースのポイントインタイムビュー（ｐｏｉｎｔ ｉｎ ｔｉｍｅ ｖｉｅｗ）が保持される。ユーザエラーが、ソースデータベース上で発生し、このエラー以前にＤＢＳＳが作成されている場合には、データベース管理者は、ＤＢＳＳへデータベース全体を復帰させるオプションを有し、このＤＢＳＳは、このユーザエラー以前の時点（ポイントインタイム）におけるものである。ユーザエラーを含めて、ソースデータベースに対するすべての変更が、失われる。さらに、この復帰は、一般に通常の復元に比べてずっと高速であり、ログシッピングが必要とする二重のリソースを必要とはしない。

本発明の一態様によれば、データベーススナップショットへの復帰は、ソースデータベースすなわち一次データベース上でデータベーススナップショットファイルページをコピーすること、一次データベースを切り取ること、このデータベースにオープンなコミットされていないトランザクションを適用すること、並びに、データベースログを利用してユーザエラーなどのイベントに集束させることを含むことが可能である。

本発明の一態様によれば、ユーザまたはデータベース管理者は、様々な時点における１つまたは複数のデータベーススナップショットを作成することができる。例えば、ユーザがテストを実施しようとしている場合、このユーザは、データベーススナップショットを作成して、以前のデータベース状態またはデータベースビューへの復帰を可能にすることができる。しかし、本発明の別の態様によれば、モニタコンポーネント（ｍｏｎｉｔｏｒ ｃｏｍｐｏｎｅｎｔ）を使用して一次データベースを監視し、ある種の出来事に応じてすぐに、データベーススナップショットを自動的に作成することができる。例えば、このモニタが、新しいアプリケーションがインストールされようとしていることを検出し、または推測することができる場合に、このモニタは、データベーススナップショットの作成を開始して、この新しいアプリケーションによる変更に先立ってこのデータベースの状態を保存することができる。

本発明のさらに他の態様によれば、ミラーデータベース（ｍｉｒｒｏｒ ｄａｔａｂａｓｅ）を自動的にアップデートして、復帰に応じてすぐに一次データベースに対してなされた変更を反映することができる。したがって、従来行われているような非常に長い全体の復元を利用することなく、ミラーデータベースをアップデートして同期させることができる。

前述の目的および関連した目的を達成するために、以下の説明および添付図面とともに、本発明のある種の例示の態様について本明細書中において説明している。これらの態様は、本発明を実行することができる様々な方法を示しており、これらのすべてが本発明によって包含されることを意図している。これらの図面と併せ考えるときに本発明の以下の詳細なる説明から、本発明の他の利点および新規性のある特徴が明らかとなろう。

本発明の前述および他の態様については、以下の詳細なる説明および以下に簡単に説明している添付図面から明らかになるはずである。
尚、本発明は、参照により本明細書に組み込まれている、２００４年２月２５日に出願した「DATABASE DATA RECOVERY SYSTEM AND METHOD」という名称の米国仮出願第６０／５４７，６４１号と、２００４年４月２８日に出願した「DATABASE DATA RECOVERY SYSTEM AND METHOD」という名称の米国非仮出願第１０／８３３，５４１号の恩典を請求している。さらに、本発明は、やはり参照により本明細書に組み込まれている、２００３年６月３０日に出願した「TRANSACTION CONSISTENT COPY-ON-WRITE DATABASES」という名称の米国特許出願第１０／６１１，７７４号の部分継続出願である。

次に本発明について添付図面を参照しながら説明する。図面中で、同一の番号は、全体を通して同一の要素を示している。しかし、これらの図面、およびこれらの図面に対する詳細な説明は、開示の特定の形態に本発明を限定することを意図してはいない。そうではなくて、本発明は、本発明の趣旨および範囲内に含まれるすべての変更形態、等価形態、および代替形態を包含することを意図している。

本出願において使用しているように、用語「コンポーネント」および「システム」は、コンピュータ関連エンティティ、すなわちハードウェア、ハードウェアとソフトウェアの組合せ、ソフトウェア、もしくは実行中のソフトウェアを意味することが意図されている。例えば、コンポーネントは、それだけには限定されないが、プロセッサ上で実行されるプロセス、プロセッサ、オブジェクト、実行可能ファイル、実行スレッド、プログラム、および／またはコンピュータであってもよい。例としては、サーバ上で実行されるアプリケーションもサーバも共に、コンポーネントとすることができる。１つまたは複数のコンポーネントは、プロセスおよび／または実行スレッド内に存在することができ、１つのコンポーネントは、１台のコンピュータ上に配置することができ、または複数台のコンピュータ間に分散することができ、あるいはその両方を行うことができる。

さらに、本発明は、方法、装置、あるいはソフトウェア、ファームウェア、ハードウェア、またはその任意の組合せを生成する標準のプログラミング技法および／またはエンジニアリング技法を使用した製品として実装することができる。本明細書中において使用される用語「製品」（または、代替的に「コンピュータプログラム製品」）は、任意のコンピュータ読取り可能デバイス、コンピュータ読取り可能キャリア、またはコンピュータ読取り可能媒体からアクセス可能なコンピュータプログラムを包含することが意図されている。例えば、コンピュータ読取り可能媒体は、それだけには限定されないが、磁気ストレージデバイス（例えば、ハードディスク、フロッピー（登録商標）ディスク、磁気ストリップ．．．）、光ディスク（例えば、ＣＤ（コンパクトディスク）、ＤＶＤ（デジタル多用途ディスク）．．．）、スマートカード、およびフラッシュメモリデバイス（例えば、カード、スティック）を含むことができる。もちろん、本発明の範囲または趣旨を逸脱することなく、多くの変更をこの構成に対して行うことができることが、当業者には理解されよう。

復元システム
最初に図１を参照すると、データ復元システム１００が示されている。データ復元システム１００は、ソースデータベース１１０、スナップショットコンポーネント１２０、スナップショットデータベース１３０、および復元コンポーネント１４０を含んでいる。（以降において、一次データベースとも呼ばれる）ソースデータベース１１０は、クエリおよび他の使用を実施することができるように系統的な方法で大量のデータを格納する。ソースデータベース１１０は、それだけには限定されないが、リレーショナルデータベースまたは多次元データベースを含めてどのような種類のデータベースともすることが可能である。スナップショットコンポーネント１２０は、このソースデータベース１１０に部分的に基づいて、（またデータベーススナップショットの代わりにＤＢＳＳと本明細書中で呼ばれている）１つ（または複数）のスナップショットデータベース１３０を生成する。この１つ（または複数）のスナップショットデータベース１３０により、ユーザは、その完全コピーを作成することなく、既存のソースデータベース１１０のトランザクションと矛盾しないビューを作成することができるようになる。ソースデータベース１１０が、スナップショットデータベース１３０とは異なったものになるときに、スナップショットコンポーネント１２０は、スナップショットデータベース１３０が、例えばページ単位で修正される以前にデータのコピーを取得するようにする。換言すれば、ソースデータベースページが文字「Ａ」を含んでおり、「Ａ」を「Ｂ」に変更するトランザクションが実行された場合には、この対応するスナップショットデータベースページが書き込まれることになり、したがってこの文字「Ａ」を記憶する。本発明の一態様によれば、スナップショットデータベース１３０は、ソースデータベース１１０の読取り専用ポイントインタイムコピーとすることができる。ＤＢＳＳは、必ずしもソースデータベース１１０の完全なコピーであるとは限らない。これら２つのデータベースは、両者に共通のデータを共有することができ、これにより、ＤＢＳＳは、作成するのに高速となり、またスペース効率も良くなる。ソースデータベース１１０が修正されるときに、元のデータをこのＤＢＳＳで使用するために、スペース効率の良いストレージにコピーしてソースデータベース１１０のそのポイントインタイムビューを保持することができる。さらに、複数の復帰ポイントを提供できるようにするために、ソースに関連する複数のスナップショットデータベース１３０が存在しうることを理解されたい。さらに、スナップショットデータベース１３０は、一時的または永続的なものとすることが可能である。一時的なスナップショットは、クラッシュ、障害、またはシャットダウンの後に破壊される内部揮発性コピーである。永続的なスナップショットは、他のアプリケーションによって使用するための、ストレージデバイス上により安全に保持することができるパブリックコピーである。

復元コンポーネント１４０は、スナップショットデータベース１３０を利用して、このソースデータベース１１０をイベントに先立つ時点まで復元する。本発明の一態様によれば、このイベントは、クイックフィンガ削除などのユーザエラーに対応する可能性があり、ここでは、ユーザは、うっかりとこのソーステーブルからデータを削除してしまう。代わりに、イベントは、システムクラッシュ、ロックアップ、あるいはデータがその他の方法で失われ、または操作される他の任意の状況もしくはシナリオに対応する可能性もある。あるイベントがソースデータベース１１０上で発生し、スナップショットデータベース１３０がこのエラー以前に作成されている場合には、データベース管理者は、復元コンポーネント１４０を使用して、このイベント以前の時点におけるスナップショットデータベース１３０まで全体のソースデータベース１１０を復帰させるというオプションを有する。復元コンポーネント１４０は、スナップショットデータベース１３０中に存在するデータを利用して、このイベント以前の前回の時点までソースデータベース１１０を復元することができる。例えば、対応するロケーションにある現在のソースデータベース値に、このスナップショットデータベースデータを上書きすることができる。代わりに、スナップショットデータベース１３０に、共有データを用いて入力し、スナップショットデータベース１３０が、新しいソースデータベースになることも可能である。全体を復元するのでなくて、スパースファイル（ｓｐａｒｓｅ ｆｉｌｅ）だけをこのソースデータベースにコピーする必要しかないので、この復元プロセスは、一般的に従来の復元技術に比べてずっと高速であることを理解されたい。さらに、この復元プロセスは、例えばログシッピングが必要とする二重のリソースを必要としていない点で、より効率的でもある。

図２は、本発明の一態様による復元コンポーネント１４０を示している。詳細には、復元コンポーネントは、復帰コンポーネント（ｒｅｖｅｒｔ ｃｏｍｐｏｎｅｎｔ）２１０およびアンドゥコンポーネント（ｕｎｄｏ ｃｏｍｐｏｎｅｎｔ）２２０を含んでいる。復帰コンポーネント２１０は、本発明による復元における主要機能を提供するが、アンドゥコンポーネント２２０は、エラーなどのイベントに集束させるきめ細かく細分化された復元を実施する。データベーススナップショットが、イベントの発生に先立って作成されている場合には、復帰コンポーネント２１０は、このデータベーススナップショット中のスパースファイルを利用して、このイベントに先立つ時刻までソースデータベースを復元することができる。スナップショットの作成後に変更されているデータファイルまたはページは、スナップショットデータベースに記憶された古い値をソースデータベースにコピーすることにより、このスナップショットの時刻におけるそれらの状態まで戻すことができる。これにより、例えばこのスナップショットが作成された時刻からこの復帰オペレーションまでのエラーを含めたデータ損失が発生する結果となる。例えば、スナップショットデータベースが作成された時刻にソースデータベースが、「Ａ」、「Ｂ」および「Ｃ」を含んでおり、次いで「Ｂ」が「Ｄ」に変更された場合、スナップショットデータベースは、「Ｂ」を含むはずであり、ソースデータベースは、「Ａ」、「Ｄ」、「Ｃ」を含むはずである。次いで、復帰コンポーネントは、単に「Ｂ」を「Ｄ」上にコピーすることにより、スナップショットの時刻におけるその値までデータベースを復元することができる。しかし、データベーススナップショットが作成された時刻において、まだコミットされていない進行中のトランザクションが存在することもある。これらのトランザクションは、データベーススナップショットによっては捕捉されない。したがって、ソースデータベースがデータベーススナップショットに復帰させられた後に、これらのトランザクションは、失われ、このトランザクションの結果として行われるオペレーション（例えば、挿入、アップデート、削除）は、実行されないことになる。

とりわけ、このアンドゥコンポーネント２２０を使用して、復帰するとすぐに、この不正確な表現を補償することができる。例えば、アンドゥコンポーネント２２０は、スナップショットデータベースの作成の時刻におけるすべてのオープンなトランザクションを記憶することができ、このトランザクションは、このスナップショットの作成以前に開始され、それ以降に終了されるすべてのトランザクションを含んでいる。これらの記憶済みのトランザクションをその後に利用して、この復元される一次データベースをロールフォワード（ｒｏｌｌ ｆｏｒｗａｒｄ）してこれらのオープンなトランザクションを捕捉し、復元イベントに集束させる。さらにアンドゥコンポーネント２２０は、定期的な周期で、または管理者のコマンドに応じてデータベースの変化を捕捉する従来のデータベースログを利用して、エラーなどのイベントにさらに近く集束させる。それによって「良好な」トランザクションの損失を最小にすることができる。したがって、本発明では、従来において達成することができるのと少なくとも同様にデータベースの復旧を実施するが、より少ないシステムリソースを利用してずっと高速に実行している。

図３を参照すると、さらに明快にするために、本発明の態様によるデータベース復元オペレーションに関して、時系列３００が示されている。時間は、この時系列３００上で左から右へと進む。換言すれば、より右側に配置されたイベントは、より左側にあるイベントよりも時間的に後になって発生する。３１０において、このデータベーススナップショット（ＤＢＳＳ）が作成される。ある期間（数分、数時間、数日．．．）が経過し、あるイベントが３２０において発生する。例えば、このイベントは、ユーザが、うっかりあるテーブル一式を削除してしまうか、もしくは、ページデータを修正してしまうことに対応することができる。その後、例えば、復元オペレーションを、データベース管理者によって開始することが可能である。その結果、本発明の復帰コンポーネント２１０（図２）を使用して、データベーススナップショットが作成された時点３１０までデータベースを復元することができる。本発明の一態様によれば、これは、ソースデータベース中の対応するデータ上にスナップショットデータベースからのスパースファイルデータをコピーし、それによりこのソースデータベースを３２０におけるイベントの影響がない一貫した安定状態にすることによって、達成することができる。次いで、アンドゥコンポーネント２２０（図２）を使用してソースデータベースをイベント３２０に向かって進めて、このイベントによって引き起こされたデータを取り除きながら、もしくは変更しながら、「良好な」データを保持することができるようになる。これについては、アンドゥファイルに記憶されたオープントランザクションを、復元されたデータベースおよび／またはデータベースログファイルに適用することによって達成することができる。

図４は、本発明の一態様によるデータベーススナップショットシステム４００を示している。このＤＢＳＳシステム４００は、スナップショットコンポーネント１２０、ソースデータベース１１０、スナップショットデータベース１３０、カタログコンポーネント（ｃａｔａｌｏｇ ｃｏｍｐｏｎｅｎｔ）４１０、およびモニタコンポーネント４２０を含んでいる。前述したように、ソースデータベース１１０は、復元しようとすることができる主要なデータベースまたは一次データベースである。スナップショットコンポーネント１２０は、ソースデータベース１１０を利用してデータベーススナップショット１３０を生成する。データベーススナップショット（ＤＢＳＳ）１３０は、読取り専用のポイントインタイムデータベースとすることが可能である。このＤＢＳＳは、ソースデータベース１３０とスペースを共有するので、スペース効率が良い。この共有されたスペースは、２つのデータベースにおいて同一であるすべてのデータページである。例示の一実装形態によれば、このＤＢＳＳは、以下のシンタックスを用いて作成することができる。

ソースデータベース１１０中のデータファイルごとに、ＤＢＳＳ１３０用の別のファイルが作成される。これらの新しいファイルは、スパースファイルである。ページがソースデータベース１１０中で変更されると、これらのページは、まずスパースファイルにコピーされる。カタログコンポーネント４１０を使用して、ＤＢＳＳ１３０中のページが、ソースデータベース１１０と共有されているかどうか、もしくは、このページがそのスパースファイルにコピーされているかどうかを追跡するログ、もしくはログファイルを生成する。本発明の一態様によれば、ログはソースデータベース１１０中に記憶されて、このログに対する簡単なアクセスがスムーズに実行される。

復元は、それを読み出し可能になる以前にＤＢＳＳ１３０上において実行して、この復元を一貫した状態にすることができることを理解されたい。最新の（ｃｕｒｒｅｎｔ）オープントランザクションは、ロールバック（ｒｏｌｌ ｂａｃｋ）されて、一部のこの元のページが、このロールバックのためにこれらのスパースファイルにおそらくコピーされる。本発明の一態様によれば、ＤＢＳＳは、ログを有していない。作成された後に、ＤＢＳＳ１３０は、永続的な場合、そのデータベース管理者によって削除されるまで存在し続けることが可能であり、永続的でない場合には、エラーまたはシステムシャットダウンに応じてすぐに削除することができる。

１つのソースデータベース１１０について、複数のＤＢＳＳ１３０が、異なるポイントインタイムにおいて存在することができる。本発明の一態様によれば、復帰され、または復元されるスナップショット以外のすべてのスナップショットを、消去することができる。あるいは、復帰される対象のスナップショットよりも後の時点に存在するすべてのスナップショットを消去することもできるが、それより前の時点に発生しているスナップショットは、保存することができる。復帰すべきまたは復帰しようとしている対象のスナップショットの後に取られたソースデータベースのスナップショットは、あまり価値のあるものではない。さらに、例えばデータベーススナップショットを利用して復元された後に、新しいスナップショットをこのソースから取ることができる。復元のために使用されるスナップショット以前に取られたスナップショットは、以前のスナップショットによって捕捉された特定のポイントインタイムまで、依然として復帰させることができるので、より高い価値があることになる。

ＤＢＳＳ１３０は、ユーザが、そこへの復帰を可能にする１つの「安全な」ポイントインタイムを望む場合、定期的または臨機応変に作成し、削除することができる。例えば、ユーザは、新しいアプリケーションのインストレーションのすぐ後で、またはテスト中にスナップショットを作成したいと望むこともある。ＤＢＳＳ１３０への復帰は、以下のコマンドを利用して発行することができる。

スナップショットコンポーネント１２０がモニタコンポーネント４２０を利用して、このソースデータベースに関してトランザクションを観察し、データベーススナップショットの自動生成を開始することもできる。例えば、モニタコンポーネント４２０が、このソースデータベースをかなり変更する可能性のある新しいアプリケーションのインストレーションを検出または推測する場合、このモニタコンポーネントは、データベーススナップショットの作成を開始することができる。このような機能をスムーズに実施するために、本発明は、それだけには限定されないが、ルールベースのエキスパートシステム、ベイジアンネットワーク（Ｂａｙｅｓｉａｎ ｎｅｔｗｏｒｋ）、およびニューラルネットワークを含めて、人工知能システムおよび人工知能の方法を使用することができることを理解されたい。

データベースを復元するために、ソースデータベースが閉じられ、このソースデータベースに対するすべての接続が閉じられる。その結果、ソースは、このプロセス中においてトランザクションに対して使用可能ではないことになる。データベースに、ＲＥＳＴＯＲＥ（復元中）とマークを付けて、外部の観察者（ｖｉｅｗｅｒ）にこのデータベースが使用できないことを通知することができる。次いで、サーバは、ソースデータベースファイル中の（このＤＢＳＳが作成されたときの）元の位置にこのスパースファイル中のページをコピーするように進むことができる。ほとんどの場合、変更されたページをコピーすることは、バックアップからの復元に比べてかなり高速である。これらのページがコピーされた後に、データベースについてのログを再構築することができる。ソースデータベースは、今度はこのＤＢＳＳが作成された時点に戻っている。ＤＢＳＳが作成されて以来のすべての変更は、除去されている。アンドゥファイルが作成されている場合には、このログチェーンは中断されておらず、ソースデータベースから取られたデータログバックアップ（ｄａｔａ ｌｏｇ ｂａｃｋｕｐ）を適用してソースデータベースをロールフォワードすることができる。

アンドゥファイルを使用してこの復元後のロールフォワードをサポートする仕組みについては、以下のように要約することができる。このＤＢＳＳを作成するとすぐ、ＤＢＳＳが作成されたときに、このＤＢＳＳの復旧により影響を受けるすべてのページの元の値は、別々のアンドゥファイル中に「プリイメージ（ｐｒｅ−ｉｍａｇｅ）」として保存することができる。復帰するとすぐ、前述のようにこのソースデータベースにＤＢＳＳページをコピーすることができる。これらのプリイメージは、別々のアンドゥファイルからコピーすることができる。このポイントにおいて、このデータベースはまさしく、このＤＢＳＳが作成されたときの状態になっている。その後、データベースログを使用して、このユーザエラーが発生する直前のポイントインタイムまで、この復元済みのＤＢＳＳをロールフォワードすることにより、失われたデータ量を最小にすることができる。

図５を参照すると、本発明の一態様による例示的なデータベース復元５００が示されている。ソースデータベース１１０は、２つのデータベースファイル５１０および５２０を含んでいる。データベースファイル５１０もデータベースファイル５２０も共に、それぞれ８ページの様々なデータを含んでいる。このソースデータベースのスナップショットが、生成される。これに応じて、データベーススナップショット１３０が作成される。このスナップショットデータベース１３０は、それぞれファイル５１０および５２０に対応する２つのスナップショットデータベーススパースファイル５３０およびスナップショットデータベーススパースファイル５４０を有することができる。このスナップショットが作成される時刻においては、これらのソースファイルは、これらがソースファイル５１０およびソースファイル５２０とすべてのデータを共有することができるので、単にシェル（ｓｈｅｌｌ）であり得る。スナップショットの作成後のあるポイントにおいて、ソースデータベース中の値を変更することができる。ここで、変更された値は、ファイル５１０中のページ３およびページ７と、ファイル２のページ４に存在している。具体的には、ページ３は、「Ｃ」から「Ｚ」に変更されており、ページ７は、「Ｇ」から「Ｙ」に変更されており、ページ４は、「Ｌ」から「Ｚ」に変更されている。したがって、この変更に先立つ元の値は、スパースファイル５３０およびスパースファイル５４０に保存されており、ここでは、「Ｃ」、「Ｇ」、および「Ｌ」となっている。復元するとすぐ、スパースファイル中のページ、ここではファイル５３０からのページ３およびページ７と、ファイル５４０からのページ３は、このソースデータベースすなわち一次データベース１１０中のアップデートされたページ上にコピーバックをすることができる。

これらのページをコピーすることは、単にこの修正されたページをコピーバックすること、あるいはファイルを追加または削除すること、一次データベースファイルをスパースファイルのサイズにへ拡大または縮小すること、これらのページを追加または削除すること（すなわち、この一次データベースに追加されたページを追跡し、その結果、復元する際にそれらを取り除くことができるようにする）等のような、より複雑なシナリオを含むいくつかのシナリオを含んでいる。ファイルの追加および削除では、ソースデータベースと、データベーススナップショットの両者のファイルリストを比較し、これらを同期させることができる。ページの追加では、ソースが、スナップショットまたはレプリカ（ｒｅｐｌｉｃａ）よりも大きい場合、追加されたページは、本発明の一態様に従ってこのソースの末尾に追加されるので、このソースは、このレプリカのサイズに合わせていくぶん末尾を切り落とし、または切り取ることができる。レプリカの方が大きい場合には、これは、ページが、一次ソースから削除されたことを意味する。したがって、ソースのサイズを増大させることができ、この範囲では、すべてのページがすでにこのスナップ中にあることになり、したがってこれらのページを通常のコピー操作によってその上にコピーすることになる。

これらのページをコピーバックする素朴なアルゴリズムは、これらのページを１ページごとにコピーすることである。しかし、本発明の一態様によれば、非同期コピーオペレーション実装形態を使用することができる。例えば、１つのスレッドおよび３つのキュー、読取りキュー、書込みキュー、ならびに空のバッファキューを利用することができる。コピーバックする際に、そのページがそのソース中に存在する（例えば、そのページが変更されていることを意味する）か、または、そのページがそこに存在しない（例えば、そのページが削除されたことを意味する）場合、そのページを単にそのソースにコピーすることが可能である。しかし、この一次ソース中に過剰なページが存在する場合には、これらのページは、そのファイルの末尾に追加されているはずであり、このファイルについては、そのレプリカのサイズに合わせてこのファイルを切り取ることによって修復することができる。最後に、このソースをアンロックしてこの復元を完了することができる。

本発明の他の態様によれば、ソースデータベースに関連するログバックアップは、復元の後に消去することができる。したがって、ログバックアップは、完全バックアップまたはファイルバックアップが行われるまで、この復帰データベース上で失敗することになる。この復帰データベースは、それが作成されたときと同じ復旧モデルを保持することができる。したがって、本発明のシステムでは、（１）この復帰を開始すること、（２）データを操作すること、（３）このログを再構築すること、および（４）このデータベースを再開することをサポートすることができる。

本発明のさらに他の態様によれば、新しいソースデータベースは、この元のソースデータベースからのデータをコピーすることにより、このスナップショットデータベースから作成することができる。このデータベース作成中のどのようなエラーも、例えばこのサーバが使用可能になった後に、ＤＢＡ（ｄａｔａｂａｓｅ ａｄｍｉｎｉｓｔｒａｔｏｒデータベース管理者）が、このオペレーションを再開することを必要とすることもある。このデータベースが作成された後に、このＤＢＡは、このソースデータベースを削除し、この復帰データベースにリネームすることができる。例えばデータミラーリングに関して、このようなシステムを使用することができる。

図６を参照すると、本発明の一態様に従って例示的なデータミラーリングシステム６００が示されている。システム６００は、２つのデータベース、すなわちソースデータベース１１０およびミラーデータベース６１０と、１つ（または複数）のデータベーススナップショット１３０と、復元コンポーネント１４０を含んでいる。ソースデータベース１１０は、一次データベースである。ミラーデータベース６１０は、ソースデータベース１１０のほとんどビットごとのレプリカを含む別個のデータベースである。したがって、ソースデータベース１１０に対して変更が行われるときに、これらの変更はネットワーク上で例えばミラーデータベース６１０に送信することができる。ミラーリングの背後にあるアイデアは、この一次ソースデータベース１１０が、例えば電源故障に起因して故障するか、または使用できなくなる場合に、ミラーデータベース６１０がトランザクションに関しての新しいソースデータベースになることが可能であり、それによって冗長性を介してのデータの高い可用性を容易とすることができる。前述の本発明の一態様によれば、ソースデータベース６１０は、それに関連する、ポイントインタイム復帰をスムーズに実施する１つ（または複数）のスナップショットデータベーススナップショット１３０を有することができる。したがって、データベース管理者は、データベーススナップショット１３０および復元コンポーネント１４０を利用して、ソースデータベース１１０を以前のポイントインタイムまで復帰させることができる。復帰が、ソースデータベース１１０上で実施される場合、このミラーデータベース６１０もまた、この変更を反映すべきである。従来においては、時間のかかるバックアップおよび完全復元が、このミラーデータベース６１０をアップデートし再同期させるために必要とされた。本発明の一態様によれば、ミラーデータベース６１０は、このソースを用いて自動的にアップデートし同期化することができる。このソースに対する変更が自動的にこのミラーデータベース中で反映されるので、この復元中のこのソースに対する変更は、この復元がこのソース上で完了された後に、同時にまたは非同期式にこのミラーに対してこの復元を渡すこともできる。

図７を参照すると、本発明の一態様に従って、スナップショットを用いてデータベースをミラーリングするための例示的なシステム７００が示されている。図７に示すように、システム７００は、ＤＢ１＿ＬＳと名前のつけられたベースデータベースまたは宛先データベース７１０を含んでいる。アプリケーション７２０は、データベース７１０からデータを閲覧しようとする。特に、アプリケーション７２０は、ＤＢ１＿００１、ＤＢ１＿００２およびＤＢ１＿００３と名前のつけられたスナップショット７３０と対話することができる。第１のスナップショットＤＢ１＿００１を作成し、例えばＤＢ１を参照することができる。

続いて、第２のスナップショットＤＢ１＿００２を作成することができる。依然としてＤＢ１＿００１を使用しているユーザは、これを使用し続ける。

その後、第３のスナップショットを作成し、ＤＢ１を参照することができる。依然としてＤＢ１＿００１またはＤＢ１＿００２を使用しているユーザは、これらを使用し続ける。

さらに、本発明の一態様によれば、データベース上で一貫性チェックを行うためにデータベーススナップショットを利用することができる。例えば、ＤＢＣＣ ＣＨＥＣＫＤＢ（）コマンドをデータベース上で実行することができる。結果として、バッキングストレージ（ｂａｃｋｉｎｇ ｓｔｏｒａｇｅ）をもつデータベースの内部スナップショットを既存のデータベースファイルの副次ストリーム中で作成することができる。次いでこれらのページをこの一貫性チェックのために読み取ることができ、このシステムは、これらのページが修正されていない場合、このベースデータベースから、あるいはこれらのページが修正されている場合には、副次ストリームからこれらのページを読み取ることができる。

図示してはいないが、本発明は１つまたは複数のＧＵＩ（ｇｒａｐｈｉｃａｌ ｕｓｅｒ ｉｎｔｅｒｆａｃｅグラフィックユーザインターフェース）を使用することができることも理解されたい。これらのＧＵＩを利用して、スナップショットの管理をサポートすることができる。例えば、それだけには限定されないが、テキストボックス、ボタン、タブ、ドロップダウンメニュー、およびスクロールバーを含めて、複数のテキストコンポーネントおよびグラフィックコンポーネントを使用してスナップショットを作成し、その後、そのスナップショットにデータベースを復帰させることができる。

さらに、このデータベーススナップショットも、これに関連するソースデータベースも従来の意味でバックアップすることができる。例えば、管理者は、このスナップショットから個々のファイルまたはファイルグループをバックアップすることができる。これらのバックアップは、復元されるときに、普通のデータベースとして復元される。このソースのバックアップオペレーションに際して、このユーザは、このバックアップと共にどのスナップショットを取るべきかを指定することができる。復元に際して、ユーザは同様に、どのスナップショットを復元すべきかを指定することができる。

（コピーオンライト（Ｃｏｐｙ−Ｏｎ−Ｗｒｉｔｅ）データベースとしても知られている）データベーススナップショット
一般的に、データベースは、２種類のファイル、すなわちデータファイルおよびログファイルから構成される。ログファイルは、一連のログレコードを含んでいる。ログレコードは、ＬＳＮ（ｌｏｇ ｓｅｑｕｅｎｃｅ ｎｕｍｂｅｒログシーケンス番号）を用いて識別することができる。図８に示すように、本発明の一態様によれば、一次データベース８００は、１組のデータファイル８０２およびログファイル８１０を含んでいる。データファイル８０２は、ページと呼ばれるストレージのブロックまたはユニットに分割することができる。

以前のポイントインタイムにおける既存のデータベースのトランザクションの一貫したビューを提供する、データベースについてのデータベーススナップショットは、このデータベースの完全なコピーを作成することなく作成することができる。このデータベースに関するデータベーススナップショットは、以前の時刻におけるこのデータベースのコピーを作成するために必要なすべての情報を含んでいる。しかし、データベーススナップショットは、それ自体の内部にすべての情報を含んではおらず、したがってフルコピーよりもサイズを小さくすることができる。さらに、修正はこのデータベースに対して行われるので、スナップショットを実行中に作成することができ、これにより、そのコスト（時間コストおよび処理コスト）を時間軸上で分散することができるようになる。コピーが、以前の時刻におけるデータベーススナップショットからなる場合には、時間コストおよび処理コストは、一時に集中されるはずである。さらに、データベーススナップショットは、アップデートアクティビティが、このデータベース上で継続される間、作成することができる点で有利である。この一次データベースは、使用され、１つまたは複数のデータベーススナップショットが作成されるデータベースである。

前述のように、データベーススナップショットは、一次データベースとともに、以前の時刻における一次データベースの内容を決定するために必要とされるすべての情報を含んでいる。データベーススナップショットは、一次データベース中の各ファイルに対応するサイドファイルを含むことができる。サイドファイルは、対応するデータファイルからのすべてのデータのコピーを含んでおり、この対応するデータファイルは、データベーススナップショットが作成されてから変更されている。本発明の一態様によれば、サイドファイル中のページから一次ファイル中のページへのマッピングテーブルに対する必要性を回避するために、これらのサイドファイルは、スパースファイル中に記憶される。スパースファイルにおいては、実際に書込みが行われるファイルの一部分だけしかストレージスペースを必要としない。このファイルの他のすべての領域は、非割当て領域とすることが可能である。しかし、スパースファイル中にサイドファイルを記憶することは、本発明の要件ではなく、他のストレージシステムおよび他のストレージ方法も、本発明の範囲内に含まれると考えられることに留意されたい。

本発明の他の態様によれば、このスパースファイルメカニズムは、標準の領域サイズと共に動作する。１つの域内のデータがこのスパースファイルに書き込まれる場合には、たとえこのデータが全体領域を満たさないとしても、この全体領域に対してスペースを割り当てることができる。このスペースは、割り当てられかつ読み取ることができるので、有効なデータで満たされた領域の区域と、スパースファイルの細分性のために、この領域内にいくらかのストレージが必要とされた場合に、割り当てられるべきある種のサイズの領域が要請されるという理由で存在しているこの領域の区域との間で、区別を行うことができる。

データベーススナップショットは、このデータベーススナップショットが作成されて以来、一次データベース中で変更されたすべてのデータの元の値を含んでいるので、データベーススナップショットの作成の時刻におけるデータベースデータをこのスナップショットから読み取ることができる。このデータベーススナップショットからのデータを求める要求に応答するために、これらのサイドファイルがこの要求からのデータを含んでいる場合には、これらのデータベーススナップショットのサイドファイルからデータを読み取ることができる。サイドファイルの中に存在してない読み取られるべきファイルはデータバーススナップショットが作成されてから変更されておらず、一次データベースから読み取ることができる。

本発明のさらに他の態様によれば、これらのサイドファイルは、一次データベースからのデータのページを含んでいる。一次データベースのいずれかのページ上のいずれかのデータが変更される場合、このデータのページは、サイドファイルの中に記憶される。本発明は、一次データベース中のデータ単位として、ページを参照しながら説明をしている。しかし、一次データベースからのデータの他の単位を利用することもできることが企図されている。

どのデータがこのサイドファイルに書き込まれており、どのデータをこの一次データベースへと読み取るべきかを決定するためには、このサイドファイル中の有効なデータの存在を確認すべきである。ある場合においては、有効なデータが存在するかどうかを直接に確認するために読み取ることが可能である。本発明の他の態様によれば、所与のページが存在し有効であるかどうかに関するデータを記憶するサイドページテーブルを作成することができる。

一次データベース中のページごとに、サイドページテーブルは、ページが変化していないことを示していて一次データベースからこのページを読み取るべきかどうかに関する情報、または、ページが変化してしまっていてサイドファイルからこのページを読み取るべきかどうかに関する情報を記憶することができる。サイドページテーブルにより、所与のページがサイドファイル中に存在するかどうかについての速やかな決定が可能になる。

本発明の他の態様によれば、このサイドファイルおよびこのスパースファイルメカニズムは共に、同じページ／領域サイズを使用する。すなわち、このサイドファイルがこの一次データベースから記憶するページは、任意のメモリがこのスパースファイルに書き込まれるときにこのスパースファイルが記憶するこれらの領域と同じサイズである。例えば、このスパースファイル領域が８ＫＢであり、この一次データベースから記憶されるページもまた８ＫＢである場合に、このページサイズとこの領域サイズは等しい。この場合には、満たされるどの領域も一次データベースから読み取られたページによって完全に満たされることになり、無効なデータがこの領域に記憶される可能性はない。

本発明の他の態様によれば、いくつかのサイドファイル領域は、まさしく各ページに対応することができる。例えば、これらのスパースファイル領域が８ＫＢ（キロバイト）であり、この一次データベースから記憶されるページが１６ＫＢである場合には、このサイドファイルに記憶される各ページが２つの領域を満たすことになる。この場合には、同様に満たされるどの領域も、この一次データベースから読み取られるページからの内容によって完全に満たされることになる。この場合にもまた、無効データがこの領域に含まれる可能性はない。

本発明のこれらの態様では、このサイドページテーブルは、このサイドファイル中のページごとに情報の１ビットを保持する、メモリ中のビットマップを含んでいる。このサイドファイル中のページごとに、この対応するビットは、このページがこのサイドファイル中に存在するかどうかを示す。

本発明の他の態様によれば、このサイドファイル領域中の細分性は、この一次データベースから記憶されるページの細分性よりも大きい。例えば、このサイドファイルの各領域が６４ＫＢであり、これらのページのサイズが８ＫＢである場合には、このサイドファイル中の領域の存在が、必ずしもこの領域中のすべての情報がこの一次データベースからの有効データであることを示すとは限らない。この実施例において、たった１ページしかこのサイドファイルにコピーされない場合には、この割り当てられた領域中において、６４ＫＢのうちの８ＫＢしか有効データを含まないことになる。他の実施形態においては、一部のサイドファイルページは、これらの領域にまたがって分散される。

これらの態様では、このサイドページテーブルは、２つのメモリ中のビットマップを含んでおり、これらのビットマップは、このサイドファイル中のページごとに、発明者らがビット１およびビット２と呼ぶことにする２ビットの情報を保持する。このサイドファイル中のページごとに、これらの対応するビットは、このページがこのサイドファイル中に確実に存在するかどうか（ビット１）を示し、またこのページがこのサイドファイル中にもしかすると存在する可能性があるかどうか（ビット２）を示す。ビット２は、このページがこのサイドファイル中に記憶されるはずである領域が割り当てられていることを示すものと考えることもできる。しかし、以下で説明するように、一実施形態においては、このビット２は、このサイドページテーブルが再構築されるときにのみ設定される。

これらのビットマップは、メモリ中に保持され、したがって永続的でないこともある。これらが消去される場合、これらのビットマップは、このスパースファイル情報から再構築される。このスパースファイルは調べられ、ページごとにこのサイドファイルには、このページが配置される領域用のスペースが割り当てられる場合に、ビット２は、このページがこのサイドファイル中に存在する可能性があることを示すために設定される。ページごとに、ビット１は、このページがこのサイドファイル中に存在することが確実ではないことを示すために最初に設定される。

このサイドページテーブルが、永続的であるようにして保持される場合には、これらの領域およびこれらのページの細分性は、無視することができ、この１ビットサイドページテーブルを使用することができる。しかし、一実施形態においては、データベースサーバが再起動した後に永続的なデータベースビューをサポートするために、この２ビットページテーブルが使用される。

本発明の一態様によれば、これらのサイドファイルでは、ページテーブルが作成されない。この場合には、このデータベーススナップショット中のページについてのコピーが行われているかどうかを判定する必要がある場合にはいつでも、このデータベーススナップショットが調べられる。本発明では、１ビットまたは２ビットのページテーブルが存在する本発明の一態様に関して以下で説明することにするが、ページテーブルが存在せず、データベースビューがこの一次データベースからコピーされたページを含むかどうかを判定するために、このデータベースビューを調べる必要がある、本発明の他の実施形態についてもまた企図している。

図９に示すように、一次データベース８００についてのデータベーススナップショット９２０は、サイドファイル９２５から構成されている。一次データベース８００中の各データファイル８０２は、データベーススナップショット９２０中の対応するサイドファイル９２５を有している。さらに、サイドページテーブルデータ９３０は、データベーススナップショット９２０用のメモリに記憶される。本発明の一態様によれば、サイドページテーブルデータ９３０は、１つのサイドページテーブルであり、このサイドページテーブルは、すべてのサイドファイル９２５をカバーする。本発明の他の態様によれば、別のサイドページテーブルが、サイドファイル９２５ごとに存在することができる。

データベースにおいて、このトランザクションログは最後にバックアップされているので、このトランザクションログは、このデータベースに対して実施されているすべてのトランザクションのシリアルレコードである。このトランザクションログを使用して失敗のポイントまでこのデータベースを復旧する。本発明の一態様によれば、このトランザクションログは、巡回キュー（ｃｉｒｃｕｌａｒ ｑｕｅｕｅ）としてモデル化される。トランザクションログは、このログの非アクティブ部分を削除することによって切り取ることができる。この非アクティブ部分は、少なくともこれらのトランザクションが反映する変化がこれらのデータファイルに持続して残っているので復旧する必要がない完了したトランザクションを含んでいる。逆に、このトランザクションログのアクティブ部分は、完了したトランザクションも、依然として実行されつつありまだ完了していないトランザクション（アクティブトランザクション）も共に含んでいる。切り取りを行って、トランザクションログが継続して、大きくなり、より多くのスペースを使うことを可能にする代わりに、このトランザクションログ中の非アクティブなスペースを最小にすることができる。

アクティブトランザクションが、トランザクションの非一貫性を引き起こすこともある。アクティブトランザクションでは、データファイルの一部修正がそのバッファキャッシュからそのデータファイルに書き込まれていないこともあり、またこのデータファイル中の未完了のトランザクションからの一部の修正が存在することもあり得る。このログファイル８１０を使用して、このデータベースの復旧がトランザクションと一貫しているようにすることができる。これは、ＡＲＩＥＳ（Algorithms for Recovery and Isolation Exploiting Semantics復旧および分離活用セマンティックスのアルゴリズム）スタイルの復旧を使用して行うことができる。このデータファイルに書き込まれていないこともあるログ中に記録されたすべての修正が、このデータベースに対する修正を実施することによってロールフォワードされる。このデータベースの保全性を確保するために、このトランザクションログ中で見出されたすべての未完了のトランザクションは、このデータベースに対する修正を元に戻すことによってロールバックされる。

データベーススナップショットを作成するために、データベースビューの物理構造（サイドファイルおよびページテーブル）を初期化する必要がある。第１に、サイドファイル９２５は、この一次データベース８００中のデータファイル８０２ごとに作成される。前述のように、サイドファイルは、スパースファイルであってもよく、または他の実施形態においては、データファイル８０２と同じサイズの非スパースファイルであってもよい。サイドファイル９２５は、この一次データベース８００中のデータファイル８０２に関連連づけられる。

トランザクションが連続的に発生しつつあり、このデータベースビューがトランザクションと一貫しているので、このトランザクションログは、データベーススナップショットの作成中に使用されるべきである。このデータベースビューについて使用すべきトランザクションに関する情報が廃棄されないようにするために、ログトランザクションは（それが存在する場合に）一次データベース８００上で無効にされる。

本発明の一態様によれば、サイドページテーブル９３０は、このデータベーススナップショットについて初期化される。最初に、サイドページテーブル９３０は、サイドファイル９２５中にページが存在しないことを示すために、また２ビットサイドページテーブルの場合には、サイドファイル９２５中にページが、もしかすると存在しない可能性があるか、あるいは確実に存在しないことを示すために設定される。

この初期化が完了するときに、このデータベーススナップショットは、「オンライン」に進む準備が整う。このデータベーススナップショットは、今や一次データベース８００に並行して実行されていることになり、修正が実施されるときに、この修正されたページの元の値（すなわち、このアップデートが実施される以前のこのページの内容）のコピーがこのデータベーススナップショットに記憶されることになる。データベースのトランザクションに一貫したスナップショットを実装するための例示的な方法は、このトランザクションログ上のスプリットポイント（ｓｐｌｉｔ ｐｏｉｎｔ）を決定する工程を含むことができる。このスプリットは、このデータベーススナップショットが表すポイントインタイムに対応することになる。一次データベース８００上のこのログの終わりのＬＳＮは、このデータベーススナップショットが作成されるときに取得することができる。このＬＳＮは、一次データベース８００とデータベーススナップショット８２０が、分岐を開始することになる「スプリットポイント」である。次いで一次データベース８００にマークを付け、その結果データベーススナップショット処理が必要とされるようにすることができる。以下に説明するように、一次データベース８００において、データベーススナップショットサポートが開始される。

このデータベーススナップショットを一貫したものにするために、このスプリットポイントに先立つ一次データベース８００のログを解析してどのトランザクションがこのスプリットの時刻においてアクティブであったかを判定する必要がある。このログ中の（このスプリットポイントの時点における）最も古いアクティブトランザクションが識別される。ログの切取りは、この最も古いアクティブトランザクション以前で有効にされる。

ＡＲＩＥＳ（Algorithms for Recovery and Isolation Exploiting Semantics）スタイルの復旧と同様な方法によって、このスプリットポイントに先立つ最も古いアクティブトランザクションからの一次データベース８００のログにおけるすべてのオペレーションが、このデータベーススナップショットに対して実施される。図１０は、本発明の一態様による一実施例のトランザクションログ、すなわちログファイル８１０のブロック図である。ログファイル８１０中のログエントリは、ログエントリ１０００、１０１０、１０２０、１０３０、１０４０、１０５０、１０６０、１０７０、１０８０、１０９０、および１０９９を含んでいる。スプリットポイント１０７５が決定される。トランザクションは、このログに書き込まれ続けるが、切取りは無効にされる。このログファイル８１０が調べられ、この最も古いアクティブトランザクションからこのスプリットポイントまで（図１０の実施例においてはログエントリｎ １０００からログエントリｎ＋７まで）のトランザクションの結果、このデータベースに対する任意の修正が、サイドファイル９２５に対して実施される。これらの各トランザクションにおける修正の結果が、サイドファイル９２５に記憶される。次いで、これらのトランザクションが検査される。ログエントリｎ １０００、ログエントリｎ＋２ １０２０、ログエントリｎ＋６など、このログ中の任意のアクティブトランザクションによってこのログファイルに書き込まれた修正は、サイドファイル９２５中で元に戻される。

しかし、一部のトランザクションが、まだコミットされていないこともある。したがって、このログ中におけるこのスプリットポイントまでのアクティブトランザクションについては、その所在を突き止め、元に戻すべきである。本発明の一態様によれば、未完了のトランザクションが、このデータベース中のあるロケーションについての値を変更する場合に、以上でこのサイドファイルに追加されている変更が、このサイドファイルから取り除かれる。代わりに、トランザクションのアンドゥ（ｕｎｄｏｉｎｇ）は、このデータベーススナップショットを修正することにより、すなわち以下で詳述するように、このサイドファイル中のデータを設定してこのスプリットポイントの時点におけるこのデータベース中のデータにマッチングさせることによって、実現することもできる。

このようにして、このログからのこの完了済みのトランザクションだけが、このデータベーススナップショット中に反映される。このログに対するトランザクションがこのデータベーススナップショット中において反映されるときに、このスプリットポイントが発生したときにアクティブな、元に戻されているトランザクションを除いて、ログの切取りが、一次データベース８００上で有効にされる。データベーススナップショット処理が、有効にされているので、変更が一次データベース８００に対して行われるときにこのデータベーススナップショットは、アップデートされることになり、したがってこのデータベーススナップショットを使用して、このスプリットポイントの時刻における一次データベース８００の内容を決定することができる。

データベースサーバが、（正常または異常に）遮断された後に再起動するときに、このデータベーススナップショットは、再初期化されるべきである。それを行うためには、メモリ中に記憶されているサイドページテーブルが、再初期化される必要がある。

２ビットのサイドページテーブル実装形態においては、割り当てられているサイドページテーブル中における領域ごとにこのサイドページテーブルを再初期化するためには、割り当てられている領域中におけるページごとにこのサイドページテーブル中のデータ（ビット２）を設定して、このページが、もしかするとサイドファイル９２５に書き込まれている可能性があることを示す。他のすべてのページについては、このサイドページテーブル中のデータを設定して、このページがサイドファイル９２５に書き込まれている可能性がないことを示す。しかし、このページがサイドファイル９２５に書き込まれたことは確実ではなく、したがってビット１は、最初に設定されてはいない。

代わりに、２ビットのサイドページテーブル実装形態において、または１ビットのサイドページテーブル実装形態において、サイドファイル９２５を検査して、前述のように、ページごとに、サイドファイル９２５中のページが有効であるかどうかを判定することもできる。このページテーブルを設定して、存在するページごとに、このページがサイドファイル９２５中に実際に存在することを示す。他のすべてのページを設定して、このページが、サイドファイル９２５中に存在しないことを示す。

このデータが上書きされる前に、このデータベーススナップショットが一次データベース８００からの情報を記憶するために、一次データベース８００は、データベーススナップショットの作成をサポートする必要がある。この一次データベース８００が修正を行うページごとに、このページがこのデータベーススナップショット中に存在するかどうかについての判定を行う必要がある。このページがこのデータベーススナップショット中に存在する場合には、このページは、正しいバージョンのページである。例えば、以前の修正が一次データベース８００中のページに対して行われているときに、このようになることもある。このページが一次データベース８００中で再び変更される場合には、このデータベースビュー中のバージョンは、変化しないはずである。

ページが変更されつつあるという情報が一次データベース８００から受け取られたときに、このページがサイドファイル９２５中に存在する場合、何も行われないはずである。このページがサイドファイル９２５中に存在しない場合には、このページは、サイドファイル９２５に書き込まれるはずであり、この正しいビットがこのサイドページテーブル中に設定されるはずである。２ビットのページテーブルが存在する場合には、以下の表１によって示されるように、このページのビット１およびビット２について、３つの可能性が存在する。

本発明の一態様によれば、ビット１が、このページが確実にサイドファイル９２５中に存在することを示すときに、ビット２は、無視される。したがって、表１に示すように、ビット１が、このページが確実にサイドファイル９２５中に存在することを示す場合には、このページは、たとえビット２が何を示しているとしても、サイドファイル９２５中に存在するものと想定される。代替的な実施形態においては、ビット１が、このページが確実にサイドファイル９２５中に存在することを示すように設定されるときに、ビット２は、このページがもしかするとサイドファイル９２５中に存在する可能性があることを示すように設定され、またこの代替的な実施形態においては、ビット１が、このページが確実にサイドファイル９２５中に存在することを示すが、ビット２が、このページが確実にサイドファイル９２５中に存在しないことを示すときには、このケースは無効であり、エラーに遭遇している。

一次データベース８００が、ページが変更されつつあることを示すとき、２ビットページテーブルでは、以上でリストアップしたケースについて取るべきアクションは、以下のようである。

ケース１：何もしない。

ケース２：このページがサイドファイル９２５中に存在するかどうかを判定し、存在していない場合には、このページをサイドファイル９２５に書き込む。

ケース３：このページをサイドファイル９２５に書き込む。

このページがサイドファイル９２５に書き込まれるときに、ケース１またはケース２のいずれかにおいて、一次データベース８００中のこの古いバージョン（一次データベース８００によって今や修正されつつあるバージョン）のページが、サイドファイル９２５に書き込まれる。さらに、このページテーブルは、このページが今やサイドファイル９２５中にあって、その結果、このページに対する後続するどのような書込みも、ケース１に従って処理されることになり、またこのデータベースビューについての正しいページがサイドファイル９２５中に記憶されたままになることを示すように設定される。

ケース２において、このページが、サイドファイル９２５中に存在するかどうかを判定するためには、このページに対応するデータがサイドファイル９２５から読み取られる。このデータが有効である場合には、このページの以前のバージョンは、サイドファイル９２５中に存在し、この場合には、このページは、上書きされているはずがない。一実施形態においては、このページに対応するページテーブルビット１は、このページが確実にサイドファイル９２５中に存在し、したがってこのページに対する将来の書込みが、ケース１の下で処理されることを示すように設定される。

データの無効性を、新しく割り当てられた領域中に配置されたデータによって示して、有効なデータがまだこの領域に書き込まれていないことを示すことができる。例えば、このデータベースのページが、絶対にオールゼロを含むことにはならないことが知られている場合には、オールゼロを新しく割り当てられた領域に書き込むことができる。このケースに該当する場合には、サイドファイル９２５中におけるこのページの存在は、割り当てられた領域の一部分であり、ある非ゼロデータを含んでいる、サイドファイル９２５中における対応するページによって示される。

表１中に詳述したケースはまた、データベーススナップショットに記憶されたデータの読取りを実施するためにも有用である。ページ中のデータが、データベースビューから読み取られつつあるときに、このページがサイドファイル９２５中に存在する場合には、このページは、サイドファイル９２５から読み取られるべきである。存在しない場合には、このページは、一次データベース８００から読み取られるべきである。２ビットページテーブルシステムにおいては、これらの３つのケースについて取るべきアクションは、以下のようである。

ケース１：サイドファイル９２５からこのページを読み取る。

ケース２：このページがサイドファイル９２５中に存在するかどうかを判定し、存在する場合、このページをサイドファイル９２５から読み取り、存在していない場合には、このページを一次データベース８００から読み取る。

ケース３：一次データベース８００からこのページを読み取る。

このデータベーススナップショットは、以前のポイントインタイムにおけるデータベースの状態を表す。ユーザは、データベーススナップショットをデータベースとして使用するように選択することができる。例えば、このユーザは、このデータベーススナップショット上でアクションを実施するように選択して、まるでこのアクションが、この以前のポイントインタイムにおけるデータベーススナップショット上で実施されているかのようにこのデータベースのデータベーススナップショットを作成することができる。さらに、初期化中には、以上で詳述したようにトランザクションをこのデータベーススナップショット上で実施し、元に戻すことができる。

このデータベーススナップショットを修正するためには、この修正は、このデータベーススナップショット中のデータに基づいているべきであり、この結果ページは、このデータベーススナップショットに記憶されるべきである。このページについてのデータベーススナップショット中にデータが存在しない場合には、この修正は、一次データベース８００中のデータに基づいているべきであり、この結果ページは、このデータベーススナップショットに記憶されるべきである。

２ビットページテーブルシステムにおいては、これらの３つのケースについて取るべきアクションは、以下のようである。

ケース１：サイドファイル９２５からこのページを読み取り、修正を実施し、このページをサイドファイル９２５に書き込む。

ケース２：このページがサイドファイル９２５中に存在するかどうかを判定し、存在する場合、ケース１のように進み、存在していない場合には、ケース３のように進む。

ケース３：一次データベース８００からこのページを読み取り、サイドファイル９２５にこのページを書き込み、このページがサイドファイル９２５中に存在することを示すようにこのページテーブルを設定する。このページに対する修正を実施し、適切な場合には、この修正済みのページをサイドファイル９２５に書き込む。

前述の１つ（または複数）の例示のシステムを考慮することにより、本発明に従って実装することができる方法は、図１１〜図１３のフローチャートを参照すればさらに良く理解されよう。説明を簡単にするために、この方法は、一連のブロックとして示し、説明しているが、本発明によれば、一部のブロックが本明細書中に示し説明している順序と異なる順序で、または他のブロックと同時に、あるいはその両方で行うことができるように、本発明は、これらのブロックの順序によって限定されることがないことを理解し認識されたい。さらに、本発明による方法を実装するためには、必ずしもすべての図示されたブロックが必要とされるとは限らないこともある。

追加して、これ以降および本明細書の全体を通して開示されるこれらの方法は、製造業者の製品上に記憶してかかる方法のコンピュータへの移植および転送を実施することが可能であることをさらに理解されたい。使用される用語、すなわち製造業者の製品は、どのようなコンピュータ読取り可能デバイス、コンピュータ読取り可能キャリア、またはコンピュータ読取り可能媒体からもアクセスすることが可能なコンピュータプログラムを包含することが意図されている。例示的で非限定的なものとして、この製造業者の製品は、コンピュータ読取り可能命令、データ構造、スキーマ、プログラムモジュールなどを実施することができる。

図１１は、本発明の一態様による、スナップショットデータベースを確立するための方法１１００を示している。スナップショットデータベースは、その作成の時点からのソースデータベースに対する変更に関するデータを保持している。１１１０において、このソースデータベースまたは一次データベース中のデータを改変する要求を受け取る。例えば、要求を行って１ページのデータを変更または改変することができる。１１２０において、この新しいデータによって置き換えることになるソースデータベース中のデータのコピーは、このソースデータベースの修正に対応するこのスナップショットデータベースのファイルおよびページにコピーされる。１１３０において、この新しいデータは、このソースデータベース中の古いデータ上にコピーされ、古いデータと置き換えられる。最終的には、１１４０において、カタログをアップデートして、このデータベースに対する変更およびこのスナップショットデータベースへのエントリについて記録することができる。

図１２は、本発明の一態様によるデータ復元方法１２００を示している。１２１０において、このスナップショットデータベースに記憶された各ページのデータは、この一次データベース中の対応するロケーション中のデータに上書きすることができる。さらに、このデータベース中の一次ファイルを必要に応じて拡大してスナップショットデータの受け取りを可能にすることができることを理解されたい。１２２０において、スナップショットデータベースまたはその中のファイルのサイズを識別し、この一次データベースまたはその中の対応するファイルのサイズと比較することができる。このスナップショットデータベースまたはその中のファイルが、この一次データベースまたはその中のファイルよりも小さくて、これらのファイルがこの復元済みのデータベース中に存在するはずがないことを示す場合には、この一次データベースを切り取って、この追加されたデータページを取り除くことができる。本発明の一態様によれば、新しく追加されたデータは、ファイルの末尾に追加されるので、これは、ファイル中の最後のページのデータを取り除くことに対応する。１２３０において、このスナップショットが作成された時刻にコミットされていないオープンなトランザクションをストレージから検索し、復元されつつあるこの一次データベースに適用することができる。その後に、１２４０において、データベースログを検索し、この復元済みのデータベースに適用して、このイベントが発生するまで、しかも発生する以前に多数の「良好な」トランザクションとして保存することができるようにこの復元を必要とするイベントにこのデータベースをさらに近づけて進めることができる。

図１３を参照すると、本発明の一態様に従って、データ復元方法１３００が示されている。１３１０において、データベーススナップショットが作成され、保持される。このデータベーススナップショットは、いつでもユーザが作成することができる。さらに、複数のスナップショットを作成して、長い間に複数の復帰ポイントを提供することができるようになる。このスナップショットデータベースは、自動的に作成することもできる。例えば、モニタコンポーネントは、このソースデータベースまたは一次データベースに関してアクションを観察し、このデータベースを著しく改変し得るアクションを検出および／または推測することができる。例えば、新しいアプリケーションのインストレーションを検出するとすぐに、スナップショットを自動的に作成することができる。本発明の一態様によれば、このデータベーススナップショットは、このソースデータベースに対する変更を記憶することができる。したがって、このデータベーススナップショットを保持することは、それに対する変更をコピーすることに対応する。本発明の他の態様によれば、このスナップショットは、スパースファイルを含むことができ、それによって対応するページに対する変更のみを記憶し、この一次データベースと他のすべてのデータを共有することができる。１３２０において、それだけには限定されないがユーザエラー（例えば、クイックフィンガ削除）を含めてイベントが発生するとすぐに、スナップショットによってマーク付けされた以前のポイントインタイムまでこのデータベースを復帰させることができる。復帰または復元は、とりわけこのスナップショットデータベースからのページをこの一次データベース中のページにコピーすること、この一次データベースを切り取ること、スナップショット作成の時刻におけるコミットされていないオープンなトランザクションをこのデータベースに対して適用すること、および、データベースログ情報をこの一次データベースに適用してこのイベントに集束させることを含むことができる。

例示の動作環境
本発明の様々な態様についての環境を提供するために、図１４ならびに以下の説明では、本発明の様々な態様を実施することができる適切なコンピューティング環境の簡潔な一般的な説明を行うことを意図している。本発明は、以上では１台のコンピュータおよび／または複数台のコンピュータ上で実行されるコンピュータプログラムのコンピュータ実行可能命令の一般的な文脈で説明してきたが、本発明は、他のプログラムモジュールと組み合わせて実装することもできることが当業者には理解されよう。一般に、プログラムモジュールは、個々のタスクを実施し、または個々の抽象データ型を実装し、あるいはその両方を行うルーチン、プログラム、コンポーネント、データ構造などを含んでいる。さらに、本発明の方法は、シングルプロセッサまたはマルチプロセッサのコンピュータシステム、ミニコンピューティングデバイス、メインフレームコンピュータ、ならびにパーソナルコンピュータ、ハンドヘルドコンピューティングデバイス、マイクロプロセッサベースのまたはプログラマブルなコンシューマ電子製品などを含めて、他のコンピュータシステム構成を用いて実行することができることが当業者には理解されよう。本発明の例示の態様はまた、分散コンピューティング環境中で実行することもでき、この分散コンピューティング環境中では、タスクは、通信ネットワークを介してリンクされるリモート処理デバイスによって実施される。しかし、本発明の全部ではなくても一部の態様は、スタンドアローンコンピュータ上で実行することができる。分散コンピューティング環境においては、プログラムモジュールは、ローカルメモリストレージデバイス中にもリモートメモリストレージデバイス中にも配置することができる。

図１４を参照すると、本発明の様々な態様を実施するための例示の環境１４１０は、コンピュータ１４１２を含んでいる。コンピュータ１４１２は、処理装置１４１４、システムメモリ１４１６、およびシステムバス１４１８を含んでいる。このシステムバス１４１８は、それだけには限定されないがシステムメモリ１４１６を含めてシステムコンポーネントを処理装置１４１４に結合する。処理装置１４１４は、使用可能な様々なプロセッサのうちのどれにすることも可能である。デュアルマイクロプロセッサおよび他のマルチプロセッサアーキテクチャもまた処理装置１４１４として使用することができる。

システムバス１４１８は、メモリバスまたはメモリコントローラ、ペリフェラルバスまたは外部バス、および／またはそれだけには限定されないが、１１−ビットバス、ＩＳＡ、ＭＣＡ、ＥＩＳＡ、ＩＤＥ、ＶＬＢ、ＰＣＩ、ＵＳＢ、ＡＧＰ、ＰＣＭＣＩＡバス、およびＳＣＳＩを含めて使用可能な様々な任意のバスアーキテクチャを使用したローカルバスを含む、様々なタイプの１つ（または複数）のバス構造のうちのどれにもすることが可能である。

システムメモリ１４１６は、揮発性メモリ１４２０および不揮発性メモリ１４２２を含んでいる。起動中などコンピュータ１４１２内のエレメント間で情報を転送する基本ルーチンを含むＢＩＯＳ（ｂａｓｉｃ ｉｎｐｕｔ／ｏｕｔｐｕｔ ｓｙｓｔｅｍ基本入出力システム）は、不揮発性メモリ１４２２に記憶される。例証として限定するものではないが、不揮発性メモリ１４２２は、ＲＯＭ（ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ読取り専用メモリ）、ＰＲＯＭ（ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭプログラム可能ＲＯＭ）、ＥＰＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙ ｐｒｏｇｒａｍｍａｂｌｅ ＲＯＭ電気的プログラム可能ＲＯＭ）、ＥＥＰＲＯＭ（ｅｌｅｃｔｒｉｃａｌｌｙ ｅｒａｓａｂｌｅ ＲＯＭ電気的に消去可能ＲＯＭ）またはフラッシュメモリを含むことが可能である。揮発性メモリ１４２０は、ＲＡＭを含んでおり、このＲＡＭは外部キャッシュメモリとしての役割を果たす。例証として限定するものではないが、ＲＡＭは、ＳＲＡＭ、ＤＲＡＭ、ＳＤＲＡＭ、ＤＤＲ ＳＤＲＡＭ、ＥＳＤＲＡＭ、ＳＬＤＲＡＭ、ＤＲＲＡＭなど多くの形態で使用可能である。

コンピュータ１４１２はまた、着脱可能／着脱不能な、揮発性／不揮発性のコンピュータストレージ媒体も含んでいる。図１４は、例えばディスクストレージ１４２４を示している。ディスクストレージ１４２４は、それだけには限定されないが、磁気ディスクドライブ、フロッピー（登録商標）ディスクドライブ、テープドライブ、Ｊａｚドライブ、Ｚｉｐドライブ、ＬＳ−１００ドライブ、フラッシュメモリカード、またはメモリスティックのようなデバイスを含んでいる。さらにディスクストレージ１４２４は、それだけには限定されないが、ＣＤ−ＲＯＭデバイス、ＣＤ−Ｒドライブ、ＣＤ−ＲＷドライブ、またはＤＶＤ−ＲＯＭドライブなどの光ディスクドライブを含めて他のストレージ媒体と別々の、または組み合わせたストレージ媒体を含むことができる。ディスクストレージデバイス１４２４のシステムバス１４１８に対する接続をスムーズに実施するために、インターフェース１４２６など着脱可能または着脱不能なインターフェースが、一般的に使用される。

図１４は、適切な動作環境１４１０中に記述されたユーザと基本的なコンピュータリソースとの間の仲介手段としての役割を果たすソフトウェアを記述していることを理解されたい。かかるソフトウェアは、オペレーティングシステム１４２８を含んでいる。ディスクストレージ１４２４上に記憶することができるオペレーティングシステム１４２８は、コンピュータシステム１４１２のリソースを制御し割り付ける機能を果たす。システムアプリケーション１４３０は、プログラムモジュール１４３２を介したオペレーティングシステム１４２８によるリソースの管理と、システムメモリ１４１６またはディスクストレージ１４２４に記憶されるプログラムデータ１４３４とを利用している。さらに、本発明は、様々なオペレーティングシステムまたはオペレーティングシステムの組合せを用いて実装することができることを理解されたい。

ユーザは、１つ（または複数）の入力デバイス１４３６を介してコンピュータ１４１２にコマンドまたは情報を入力する。入力デバイス１４３６は、それだけには限定されないが、マウス、トラックボール、スタイラス、タッチパッド、タッチスクリーンなどのポインティングデバイス、キーボード、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナ、ＴＶチューナカード、デジタルカメラ、デジタルビデオカメラ、ウェブカメラなどを含んでいる。これらおよび他の入力デバイスは、システムバス１４１８を介して１つ（または複数）のインターフェースポート１４３８を経由して処理装置１４１４に接続される。１つ（または複数）のインターフェースポート１４３８は、例えばシリアルポート、パラレルポート、ゲームポート、およびＵＳＢを含んでいる。１つ（または複数）の出力デバイス１４４０は、１つ（または複数）の入力デバイス１４３６と同じタイプのポートのうちの一部のポートを使用している。したがって、例えば、ＵＳＢポートを使用して、コンピュータ１４１２に対する入力を提供し、コンピュータ１４１２から出力デバイス１４４０へと情報を出力することができる。出力アダプタ１４４２は、専用のアダプタを必要とする他の出力デバイス１４４０のうちに、モニタ、スピーカ、およびプリンタのような一部の出力デバイス１４４０が存在することを示すように提供される。出力アダプタ１４４２は、例として限定するものではないが、出力デバイス１４４０とシステムバス１４１８の間の接続の手段を提供するビデオカードおよびサウンドカードを含んでいる。１台（または複数台）のリモートコンピュータ１４４４など、他のデバイスおよび／またはデバイスのシステムは、入力機能も出力機能も共に提供することに留意されたい。

コンピュータ１４１２は、１台（または複数台）のリモートコンピュータ１４４４など、１台または複数台のリモートコンピュータに対する論理接続を使用して、ネットワーク環境中で動作することができる。この１台（または複数台）のリモートコンピュータ１４４４は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ワークステーション、マイクロプロセッサベースの家庭電気製品、ピアデバイス、または他の共通ネットワークノードなどとすることが可能であり、一般的にコンピュータ１４１２に対して説明したエレメントのうちの多くまたはすべてを含んでいる。簡潔に示すために、メモリストレージデバイス１４４６だけしか、１台（または複数台）のリモートコンピュータ１４４４と共に示していない。１台（または複数台）のリモートコンピュータ１４４４は、ネットワークインターフェース１４４８を介してコンピュータ１４１２に論理的に接続され、次いで通信接続１４５０を経由して物理的に接続される。ネットワークインターフェース１４４８は、ＬＡＮやＷＡＮなどの通信ネットワークを包含している。ＬＡＮ技術は、ＦＤＤＩ、ＣＤＤＩ（Ｃｏｐｐｅｒ Ｄｉｓｔｒｉｂｕｔｅｄ Ｄａｔａ Ｉｎｔｅｒｆａｃｅ銅配線分散データインターフェース）、イーサネット（登録商標）／ＩＥＥＥ８０２．３、トークンリング／ＩＥＥＥ８０２．５などを含んでいる。ＷＡＮ技術は、それだけには限定されないが、ポイントツーポイントリンク、ＩＳＤＮおよびその変形のような回路交換網、パケット交換網、およびＤＳＬを含んでいる。

１つ（または複数）の通信接続１４５０は、ネットワークインターフェース１４４８をバス１４１８に接続するために使用されるハードウェア／ソフトウェアを意味する。通信接続１４５０は、分かりやすく図示するためにコンピュータ１４１２の内部に示しているが、コンピュータ１４１２の外部に存在することも可能である。このネットワークインターフェース１４４８に接続するために必要なハードウェア／ソフトウェアは、例示の目的にすぎないが、通常の電話品質のモデム、ケーブルモデム、ＤＳＬモデム、パワーモデム（ｐｏｗｅｒ ｍｏｄｅｍ）、ＩＳＤＮアダプタ、およびイーサネット（登録商標）カードを含むモデムなど内蔵または外付けの技術を含んでいる。

図１５は、本発明が相互作用することができるコンピューティング環境の一例１５００の概略ブロック図である。このシステム１５００は、１つまたは複数のクライアント１５１０を含んでいる。１つ（または複数）のクライアント１５１０は、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）とすることができる。システム１５００はまた、１つ（または複数）のサーバ１５３０も含んでいる。１つ（または複数）のサーバ１５３０もまた、ハードウェアおよび／またはソフトウェア（例えば、スレッド、プロセス、コンピューティングデバイス）とすることができる。サーバ１５３０は、スレッドを格納して、例えば本発明を使用することによって変換を実施することができる。クライアント１５１０とサーバ１５３０の間の可能な通信は、複数のコンピュータプロセス間で伝送されるようになっているデータパケットの形態とすることができる。システム１５００は、１つ（または複数）のクライアント１５１０と１つ（または複数）のサーバ１５３０との間の通信を実施するために使用することができる通信フレームワーク１５５０を含んでいる。１つ（または複数）のクライアント１５１０は、この１つ（または複数）のクライアント１５１０にローカルな情報を記憶するために使用することができる１つ（または複数）のクライアントデータ記憶域１５６０に動作可能に接続される。同様に、１つ（または複数）のサーバ１５３０は、このサーバ１５３０にローカルな情報を記憶するために使用することができる１つ（または複数）のサーバデータ記憶域１５４０に動作可能に接続される。

以上で説明してきた内容は、本発明の実施例を含んでいる。本発明を説明するためにコンポーネントおよび方法のあらゆる考え得る組合せについて説明することは、もちろん可能ではないが、本発明のさらに多くの組合せおよび置換が可能であることが当業者には理解されよう。したがって、本発明では、添付の特許請求の範囲の趣旨および範囲内に含まれるかかるすべての変更形態、修正形態、および変形形態を包含することが意図されている。さらに、用語「含む（ｉｎｃｌｕｄｅｓ）または有する（ｈａｖｉｎｇ）」が、この詳細なる説明または特許請求の範囲において使用される限りでは、「含む（ｃｏｍｐｒｉｓｉｎｇ）」が、使用される際に特許請求項中における移行語として解釈されるので、かかる用語は、この用語「含む（ｃｏｍｐｒｉｓｉｎｇ）」と同様にして包含することを意図している。

本発明の一態様によるデータ復元システムの概略ブロック図である。 本発明の一態様による復元コンポーネントの概略ブロック図である。 本発明の様々な態様を示す時系列図である。 本発明の一態様によるデータベーススナップショットシステムの概略ブロック図である。 本発明の一態様によるデータベース復元の一例を示す図である。 本発明の一態様によるデータベースミラーリングシステムの一例の概略ブロック図である。 本発明の一態様によるミラーリングシステムの一例の概略ブロック図である。 本発明の一態様による一次データベースの概略ブロック図である。 本発明の一態様によるデータベーススナップショットシステムの概略ブロック図である。 本発明の一態様によるトランザクションログの一例の概略ブロック図である。 本発明の一態様によるスナップショットデータベースを確立する方法を示すフローチャート図である。 本発明の一態様による復元方法を示すフローチャート図である。 本発明の一態様によるデータ復元方法のフローチャート図である。 本発明の一態様による適切な動作環境を示す概略ブロック図である。 本発明が相互作用するサンプルコンピューティング環境の概略ブロック図である。

Claims (20)

1. ソースデータベースからある時点におけるスナップショットデータベースを生成するよう構成されたスナップショットコンポーネントであって、前記スナップショットデータベースは、トランザクションによる前記ソースデータベースへの修正の結果として、置き換えられたデータを記憶するスパースファイルを格納しており、前記トランザクションは前記スナップショットの生成後に前記ソースデータベースの前記スパースファイルをコミットしており、前記スナップショットデータベースは前記ソースデータベースとスペースを共有し、前記共有されたスペースは前記スナップショットデータベースおよび前記ソースデータベースにおいて同一なすべてのデータページであるスナップショットコンポーネントと、
   前記スナップショットデータベース中のページが、前記ソースデータベースと共有されているかどうか、および、前記ソースデータベース中のページが前記スナップショットデータベースへコピーされているかどうかを追跡するよう構成されたカタログコンポーネントと、
   スナップショットデータベースファイルを関連付けられたソースデータファイル上にコピーすることによって、前記スナップショットデータベースを利用して、前記ソースデータベースをイベントに先立つ時点まで復元する復元コンポーネントと
   を備えたことを特徴とするデータ復元システム。
2. 前記イベントは、ユーザエラーに対応することを特徴とする請求項１に記載のシステム。
3. 前記復元コンポーネントは、スナップショットデータベースデータを前記ソースデータベースへコピーする復帰コンポーネントを含むことを特徴とする請求項２に記載のシステム。
4. 前記復元コンポーネントは、スナップショットデータベースの作成中にオープンなトランザクションを記憶し、前記オープンなトランザクションを復元されたソースデータベースに追加するアンドゥコンポーネントを含むことを特徴とする請求項３に記載のシステム。
5. 前記アンドゥコンポーネントは、データベースログファイルを利用して前記エラーに集束させることを特徴とする請求項４に記載のシステム。
6. 前記スナップショットコンポーネントは、前記ソースデータベースを観察し、前記ソースデータベースを特定の程度まで修正する可能性のあるイベントが発生するとすぐにスナップショットの作成を開始するモニタコンポーネントを含むことを特徴とする請求項１に記載のシステム。
7. 前記復元コンポーネントは、自動的にかつ前記ソースデータベースの復元と同時に、１つ以上のミラーデータベースをアップデートし、および同期させることを特徴とする請求項１に記載のシステム。
8. 前記スナップショットデータベースの前記スパースファイルは、変更される前の前記ソースデータベースの元の値を表していることを特徴とする請求項１に記載のシステム。
9. 前記スナップショットデータベースおよび前記ソースデータベースは、前記スナップショットデータベースの作成以来、変更されていないデータを共有していることを特徴とする請求項８に記載のシステム。
10. 中央処理装置（ＣＰＵ）、メモリおよび入出力装置を少なくとも含むコンピュータによって実行されるデータ復元方法において、前記コンピュータは、データベースを記憶した少なくとも１つの記憶媒体と関連付けられており、前記入出力装置を経由してデータベースを修正するトランザクションが実行され、前記方法は、前記ＣＰＵによって実行される、
    前記少なくとも１つの記憶媒体上に、ある時点における、ソースデータベースに対するスナップショットデータベースを作成するステップであって、前記スナップショットデータベースは、トランザクションによる前記ソースデータベースへの修正の結果として、置き換えられたデータを記憶するスパースファイルを格納しており、前記トランザクションは前記スナップショットの生成後に前記ソースデータベースの前記スパースファイルをコミットしているステップと、
    前記入出力装置を経由した入力に関連付けられたイヴェントが発生した場合に、スパースデータベースファイルからのページを対応するソースデータベースページ上にコピーすることによって、前記スナップショットが作成された前記時点における前記データベースの状態まで復帰させるステップであって、カタログコンポーネントが、前記スナップショットデータベース中のページが前記ソースデータベースと前記スナップショットデータベースとの間で共有されているかどうか、および、前記ソースデータベース中のページが前記スナップショットデータベースへコピーされているかどうかを追跡するのに利用されるステップと
    を備えることを特徴とするデータ復元方法。
11. 前記イベントは、ユーザエラーに対応することを特徴とする請求項１０に記載の方法。
12. スナップショットが作成された前記時点における前記データベースの状態に復帰させる前記ステップは、グラフィックユーザインターフェースを利用してデータベースアドミニストレータによって開始されることを特徴とする請求項１１に記載の方法。
13. スナップショットが作成された時間におけるコミットされていないトランザクションを捕捉するステップをさらに含むことを特徴とする請求項１０に記載の方法。
14. 前記コミットされていないトランザクションを前記ソースデータベースに適用するステップをさらに備えることを特徴とする請求項１３に記載の方法。
15. 前記イベントの発生の直前における前記データベースへの変更を反映するために、データベースログを検索し、および前記データベースを時間的にロールフォワードして前記ログを前記データベースに適用するステップをさらに備えることを特徴とする請求項１４に記載の方法。
16. 前記ソースデータベースの復帰後すぐに、１つ以上のミラーデータベースを自動的にアップデートするステップをさらに備えることを特徴とする請求項１０に記載の方法。
17. 前記スナップショットは、データベースを大幅に変更する可能性があるイベントを検出するとすぐに自動的に作成されることを特徴とする請求項１０に記載の方法。
18. 前記イベントは、新しいアプリケーションのインストレーションに対応することを特徴とする請求項１７に記載の方法。
19. 前記スナップショットデータベースの前記スパースファイルは、前記スナップショットが作成された時間における前記データベースの構造を表すことを特徴とする請求項１０に記載の方法。
20. 請求項１０乃至１９いずれかに記載の方法を実行するためのコンピュータ実行可能命令をその上に記憶していることを特徴とするコンピュータ読取り可能記憶媒体。

Images