JP4638908B2 - データベースまたはファイルシステムを自動的に保守および修復するシステムおよび方法 - Google Patents

Description

本発明は、一般には、データベースおよびファイルシステムに関し、より詳細には、データベースおよびファイルシステムを自動的に保守および修復することでデータの信頼性を保証する方法に関する。

（本発明のさまざまな態様は、あらゆる型のデータページについてデータページレベルのデータ破損に対応し、訂正する方法、およびインデックスページの破損（クラスタ化されているかどうかを問わない）、データページの破損、ログファイルのページ破損を含むがそれらに限定されないさまざまなシナリオでの回復（再作成または復元の操作を含む）に関する。）

（関連出願）
（本出願は、参照によりその開示全体が本明細書に組み込まれている2004年5月3日に出願された米国特許出願第10/837,932号の優先権を主張するものである。）
（本出願は、参照によりその開示全体が本明細書に組み込まれている同一出願人による出願、すなわち2003年8月21日に出願された米国特許出願第10/647,058号(米国弁護士側管理番号MSFT-1748)、"SYSTEMS AND METHODS FOR REPRESENTING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM BUT INDEPENDENT OF PHYSICAL REPRESENTATION"、2003年8月21日に出願された米国特許出願第10/646,941号(米国弁護士側管理番号MSFT-1749)、"SYSTEMS AND METHODS FOR SEPARATING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM FROM THEIR PHYSICAL ORGANIZATION"、2003年8月21日に出願された米国特許出願第10/646,940号(米国弁護士側管理番号MSFT-1750)、"SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A BASE SCHEMA FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"、2003年8月21日に出願された米国特許出願第10/646,632号(米国弁護士側管理番号MSFT-1751)、"SYSTEMS AND METHODS FOR THE IMPLEMENTATION OF A CORE SCHEMA FOR PROVIDING A TOP-LEVEL STRUCTURE FOR ORGANIZING UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"、2003年8月21日に出願された米国特許出願第10/646,645号(米国弁護士側管理番号MSFT-1752)、"SYSTEMS AND METHOD FOR REPRESENTING RELATIONSHIPS BETWEEN UNITS OF INFORMATION MANAGEABLE BY A HARDWARE/SOFTWARE INTERFACE SYSTEM"、2003年8月21日に出願された米国特許出願第10/646,575号(米国弁護士側管理番号MSFT-2733)、"SYSTEMS AND METHODS FOR INTERFACING APPLICATION PROGRAMS WITH AN ITEM-BASED STORAGE PLATFORM"、2003年8月21日に出願された米国特許出願第10/646,646号(米国弁護士側管理番号MSFT-2734)、"STORAGE PLATFORM FOR ORGANIZING, SEARCHING, AND SHARING DATA"、2003年8月21日に出願された米国特許出願第10/646,580号(米国弁護士側管理番号MSFT-2735)、"SYSTEMS AND METHODS FOR DATA MODELING IN AN ITEM-BASED STORAGE PLATFORM"に、主題によって関連付けられる。）

クライアントデータベースのプラットフォーム（すなわち、家庭や企業のデスクトップコンピュータ）ではサーバーのプラットフォームよりはるかに低品質のハードウェアを使用しているが、サーバークラスのハードウェア（コントローラ、ドライバ、ディスクなど）でも、データが破損したために、アプリケーションでデータストアに書き込んだデータを読み出し操作によって取り出せない場合がある。もちろん、これはクライアントデータベースのプラットフォームにとって大きな問題であるのは明らかである（サーバーデータベースのプラットフォームとは対称的に）。こうした状況の原因として、クライアントマシンは予期しない停電によって書き込み操作中に突然電源が切れ、結果として、ページの断裂やデータベースの破損を招く確率が高いことが挙げられるが、限定はされないさまざまな原因がある（サーバーのデータベースシステムでは、無停電電源装置（ＵＰＳ）を使用して停電による問題を軽減するのがきわめて一般的である）。媒体の老朽化はデータベース破損のもう１つの原因である。物理記憶媒体は、時間の経過に伴って実際に摩耗する。信頼性に関する問題のさらにもう１つの原因は、不注意（たとえばバグ）と悪意（たとえばウィルス）の両方によるソフトウェアエラーから発生した破損の検出と回復である。

従来、データベースの保守と修復はデータベースマネージャなど、データベースシステムに関する熟練したスキルセットと十分な知識のある者、あるいは少なくともデータベースシステムになじみが深く、日常的にこれを使用しており、多くはデータベース技術についてある程度のスキルを備えている者に任されている。他方で、オペレーティングシステムやアプリケーションプログラムを利用する家庭や企業の一般的なエンドユーザーは、滅多にデータベースを操作せず、データベースの保守や修復の問題を処理するには不適切である。

これまで、こうした２つのグループ間にスキルレベルの差があることは大きな問題であったが、本明細書の「相互参照」の項にすでに示した米国特許出願に関連して開示されたオペレーティングシステムなどのオペレーティングシステムのデータベースを実装するファイルシステムでは、このようにスキルの不十分なエンドユーザーは自分ではほとんど解決できないデータベースの保守や修復の問題に直面する状況が発生する。このように、企業用／家庭用のデータベースを実装するオペレーティングシステムのファイルシステム、すなわち短縮して「データベースファイルシステム」（ＤＢＦＳ）は、破損を検出し、データベースをトランザクション的に整合性がある状態に回復できなければならない。また、失われたデータを回復できない場合、ＤＢＦＳは前記データへの変更の極小の単位が維持されるレベル（つまり、アイテムベースのデータベースでは「アイテム」レベル）でデータの整合性を保証する必要がある。さらに、デフォルトでレイジーコミットモード（ｌａｚｙ ｃｏｍｍｉｔ ｍｏｄｅ）で動作するＤＢＦＳの場合は、異常なシャットダウンの直前にコミットされたトランザクションの持続性は保証されないので、これを考慮に入れて訂正する必要がある。

さらに、企業／家庭のエンドユーザーはＤＢＦＳの保守と回復を自動化することで多大な恩恵を被るが、データベースマネージャやデータベースに関するスキルの高い者にとっても一般的なデータベース保守および修復の技術的なソリューションによるメリットがある。データベース管理者がデータベースツール（たとえば、ＳＱＬ Ｓｅｒｖｅｒ ２０００が提供するＤａｔａｂａｓｅ Ｔｕｎｉｎｇ Ａｄｖｉｓｏｒ）を利用するのはこの領域では一般的であるが、こうしたツールは信頼性の問題には直接対応せず、データベースのバックアップを管理する手段を提供する。また、自動ではなく、データベース管理者が大いに介入する必要がある（特に、データベースバックアップを利用できない場合や、他の修復の問題が発生する場合）。したがって、データベースの信頼性の問題に対応する自動のソリューションは、データベース管理者や他のスキルのあるデータベースユーザーにとっても有益である。本発明は、まさにこうしたソリューションを提供する。

本発明のさまざまな実施形態は、ＤＢＦＳのデータ信頼性システム（ＤＲＳ：ｄａｔａ ｒｅｌｉａｂｉｌｉｔｙ ｓｙｓｔｅｍ）を目的としており、ＤＲＳはエンドユーザーの直接的な介入をほとんどまたは一切必要とせずにデータベース管理（ＤＢＡ：ｄａｔａｂａｓｅ ａｄｍｉｎｉｓｔｒａｔｉｏｎ）タスクを自動的に実行するためのフレームワークとポリシーセットを備えている（したがって、本質的に前記エンドユーザーには透過である）。いくつかの実施形態において、ＤＲＳフレームワークは、エラーやイベントの通知を差し込むメカニズム、ポリシー、エラー／イベントを処理するアルゴリズムを実装している。より詳細には、こうした実施形態では、ＤＲＳはＤＢＦＳの保守と修復をバックグラウンドで実行するバックグラウンドスレッドである。したがって、ＤＲＳはＤＢＦＳの全体的な状態を最高のレベルで保護し、保守している。

本発明のさまざまな実施形態において、ＤＲＳは、（１）あらゆるページ型についてページレベルのデータの破損に応答し、これを訂正する機能、（２）（ａ）インデックスページの破損（クラスタリングの有無を問わない）、（ｂ）データページの破損、（ｃ）ログファイルページの破損に対して第２レベルの回復（再作成または復元）を試みる機能を備えている。

本発明の特定の実施形態は、（ｉ）データ破損ケースの修復／復元を行う機能、（ｉｉ）（ｉｉｉ）システムの信頼性と可用性を向上する機能、（ｉｖ）スキルのあるサードパーティーがデータベースエンジンまたはストレージエンジンの問題をトラブルシューティングするためのＤＲＳのエラー／イベント履歴テーブルを維持する機能を含むがそれらに限定されないＤＲＳ専用の機能をさらに備えている。

以上の課題を解決するための手段と後述の発明を実施するための最良の形態を、添付の図面を参照しながら読むことにより、本発明をより深く理解できる。本発明を説明するために本発明の例示的な構成を図示するが、本発明は開示されたこの特定の方法および手段には限定されない。

本主題について、法に定める要件を満たすために具体的に説明する。ただし、説明自体に本特許の範囲を限定する意図はない。むしろ、発明者は、特許請求の範囲に示す主題が、本明細書で説明するステップと同様の別のステップまたはステップの組み合わせを含めた別の方法によっても、現在または将来の他の技術と組み合わせても実施できることを意図している。さらに、本明細書において「ステップ」という用語は採用された方法のさまざまな要素を示しており、個々のステップの順序が明示的に示された場合を除き、この用語がここに開示するさまざまなステップ間の順序を示していると解釈してはならない。

前述の解決手段では、本発明の機能の概要を示している。本発明の１つの実施形態に関する詳細な説明を以下に示す。以下で説明するさまざまな実施形態では、ＭＩＣＲＯＳＯＦＴ ＳＱＬ ＳＥＲＶＥＲデータベースシステム（本明細書では簡単に「ＳＱＬ」と呼ぶこともある）に単独で実装された本発明の機能、あるいは次世代パーソナルコンピュータオペレーティングシステム（一般に「Ｗｉｎｄｏｗｓ（登録商標）Ｌｏｎｇｈｏｒｎ」、または簡単に「Ｌｏｎｇｈｏｒｎ」と呼ぶ）のＭＩＣＲＯＳＯＦＴ ＷｉｎＦＳファイルシステムに組み込みの形で実装された本発明の機能について説明する。後者は、前述の相互参照に示す特許出願の多くの最も重要な主題である。前述のように、ＳＱＬ ＳＥＲＶＥＲにはＭＩＣＲＯＳＯＦＴ ．ＮＥＴ Ｃｏｍｍｏｎ Ｌａｎｇｕａｇｅ Ｒｕｎｔｉｍｅ（ＣＬＲ）が組み込まれているので、管理されたコードを記述して実行し、ＳＱＬ ＳＥＲＶＥＲデータベースのデータストアを操作することができる。以下で説明する実施形態はこのコンテクストで動作するが、本発明がＳＱＬ ＳＥＲＶＥＲ製品への実装には決して限定されないことは言うまでもない。むしろ、本発明は、オブジェクト指向のデータベースシステムやオブジェクトリレーショナル拡張を伴うリレーショナルデータベースシステムなど、データベースストア上で動作するオブジェクト指向のプログラミングコードの実行をサポートする任意のデータベースシステムに実装できる。したがって、本発明が以下で説明する特定の実施形態に限定されず、前述の請求項で定義する本発明の精神と範囲を逸脱しないすべての変更を対象とすることは言うまでもない。

（コンピュータ環境）
本発明の多くの実施形態は、コンピュータ上で実行できる。図１と以下の説明は、本発明を実装できる適切なコンピューティング環境を簡単かつ一般的に説明することを目的としている。必須ではないが、本発明について、プログラムモジュールのようなコンピュータ実行可能命令がクライアントワークステーションやサーバーなどのコンピュータで実行されるという一般的なコンテクストで説明する。一般に、プログラムモジュールには、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などがあり、特定のタスクを実行するものや、特定の抽象データ型を実装するものがある。さらに、本発明が、ハンドヘルドデバイス、マルチプロセッサシステム、マイクロプロセッサベースまたはプログラム可能な家庭用電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータなどを含むその他のコンピュータシステム構成でも実施できることは言うまでもない。本発明は、通信ネットワークを介してリンクするリモート処理装置でタスクを実行する分散コンピューティング環境でも実施できる。分散コンピューティング環境では、プログラムモジュールはローカルとリモートの両方のメモリ記憶装置内に配置できる。

図１に示すように、例示的な汎用コンピューティングシステムには、処理ユニット２１、システムメモリ２２、およびシステムメモリからプロセッサユニット２１までのさまざまなシステムコンポーネントを接続するシステムバス２３を含む従来のパーソナルコンピュータ２０または同等のものが含まれる。システムバス２３は、さまざまなバスアーキテクチャの任意の１つを使用したメモリバスまたはメモリコントローラ、周辺バス、ローカルバスを含む各種バス構造のいずれでもよい。システムメモリには、読み取り専用メモリ（ＲＯＭ：ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）２４とランダムアクセスメモリ（ＲＡＭ：ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）２５が含まれる。起動時などにコンピュータ２０内のエレメント間の情報転送を支援する基本ルーチンを含む基本入出力システム２６（ＢＩＯＳ：ｂａｓｉｃ ｉｎｐｕｔ／ｏｕｔｐｕｔ ｓｙｓｔｅｍ）は、ＲＯＭ ２４に格納される。パーソナルコンピュータ２０には、さらにハードディスク（図示せず）に対する読み出しまたは書き込みを行うハードディスクドライブ２７、取り外し可能な磁気ディスク２９に対する読み出しまたは書き込みを行う磁気ディスクドライブ２８、ＣＤ−ＲＯＭ、または他の光媒体のような取り外し可能な光ディスク３１に対する読み出しまたは書き込みを行う光ディスクドライブ３０が含まれる。ハードディスクドライブ２７、磁気ディスクドライブ２８、および光ディスクドライブ３０は、それぞれハードディスクドライブインターフェース３２、磁気ディスクドライブインターフェース３３、および光ディスクドライブインターフェース３４を介してシステムバス２３に接続する。ドライブと各ドライブに接続するコンピュータ可読媒体は、コンピュータ可読命令、データ構造、プログラムモジュールなど、パーソナルコンピュータ２０のデータを保存する不揮発性記憶装置として利用できる。ここに記載する例示的な環境では、ハードディスク、取り外し可能な磁気ディスク２９、および取り外し可能な光ディスク３１を使用しているが、磁気カセット、フラッシュメモリカード、デジタルビデオディスク（ＤＶＤ：ｄｉｇｉｔａｌ ｖｉｄｅｏ ｄｉｓｋ）、ベルヌーイカートリッジ（Ｂｅｒｎｏｕｌｌｉ ｃａｒｔｒｉｄｇｅｓ）、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）などのように、コンピュータからアクセス可能なデータを保存できる他の種類のコンピュータ可読媒体も例示的な動作環境に使用できることは言うまでもない。

オペレーティングシステム３５、１つまたは複数のアプリケーションプログラム３６、その他のプログラムモジュール３７、およびプログラムデータ３８を含む多くのプログラムモジュールは、ハードディスク、磁気ディスク２９、光ディスク３１、ＲＯＭ ２４、またはＲＡＭ ２５に保存できる。ユーザーは、キーボード４０やポインティングデバイス４２などの入力装置を使用してコンピュータ２０にコマンドや情報を入力できる。他の入力装置（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディスク、スキャナなどを含めてもよい。これらの入力装置および他の入力装置は、多くの場合、システムバスに接続するシリアルポートインターフェース４６を介して処理ユニット２１に接続するが、パラレルポート、ゲームポート、ＵＳＢ（ｕｎｉｖｅｒｓａｌ ｓｅｒｉａｌ ｂｕｓ）のような他のインターフェースで接続してもよい。モニター４７または他の種類の表示装置も、ビデオアダプタ４８のようなインターフェースを介してシステムバス２３に接続される。パーソナルコンピュータには、一般にモニター４７以外にもスピーカーやプリンタなどの周辺出力装置（図示せず）が接続されている。図１に示す例示的なシステムには、ホストアダプタ５５、ＳＣＳＩ（Ｓｍａｌｌ Ｃｏｍｐｕｔｅｒ Ｓｙｓｔｅｍ Ｉｎｔｅｒｆａｃｅ）バス５６、およびＳＣＳＩバス５６に接続する外付けの記憶装置６２も含まれている。

パーソナルコンピュータ２０は、リモートコンピュータ４９のような１台または複数台のリモートコンピュータへの論理接続を使用してネットワーク環境で動作できる。リモートコンピュータ４９は、もう１台のパーソナルコンピュータ、サーバー、ルータ、ネットワークＰＣ、ピアデバイス、または他の一般のネットワークノードでよい。通常は、パーソナルコンピュータ２０に関連して上で説明したエレメントの多くまたはすべてが含まれるが、図１にはメモリ記憶装置５０のみを示す。図１に示す論理接続には、ローカルエリアネットワーク（ＬＡＮ：ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）５１とワイドエリアネットワーク（ＷＡＮ：ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）５２を含めてもよい。このようなネットワーキング環境は、職場、企業規模のコンピュータネットワーク、イントラネット、およびインターネットではごく一般的である。

ＬＡＮネットワーキング環境で使用した場合、パーソナルコンピュータ２０はネットワークインターフェースまたはアダプタ５３を介してＬＡＮ ５１に接続する。ＷＡＮネットワーキング環境で使用する場合、コンピュータ２０は一般にインターネットなどのワイドエリアネットワーク（ＷＡＮ）５２を介して通信を確立するためのモデム５４またはその他の手段を備えている。モデム５４（内蔵または外付け）は、シリアルポートインターフェース４６を介してシステムバス２３に接続できる。ネットワーク環境では、パーソナルコンピュータ２０またはその一部に関連して説明したプログラムモジュールをリモートメモリ記憶装置に格納できる。図示されたネットワーク接続が例示的なものであり、コンピュータ間の通信リンクを確立する他の手段を使用してもよいことは言うまでもない。

本発明の多くの実施形態はコンピュータシステムに特に適していると考えられるが、本明細書のいかなる部分にも、本発明をこうした実施形態に限定する意図はない。逆に、ここで使用する「コンピュータシステム」という用語は、装置の特性が電子的、機械的、論理的、仮想的のいずれかにかかわらず、情報を格納および処理できる、かつ／または格納された情報を使用して装置自体の動作または実行を制御できる任意かつすべての装置を含むものとする。

（データ信頼性システム（ＤＲＳ）の概要）
本発明の複数の実施形態において、データ信頼性システム（ＤＲＳ）はバックグラウンドでデータベースを保守および修復するスレッドであり、データベースファイルシステム（ＤＢＦＳ）の全般的な状態を監視する。図２は、ＤＢＦＳ内のＤＲＳの構造を示すブロック図である。この図で、複数のアプリケーション２１２、２１４、２１６にオペレーティングシステムレベルのサービスを提供するオペレーティングシステム２０２は、持続性のデータストア２３２に論理的に接続するＤＢＦＳ ２２２を備えている。オペレーティングシステム２０２は、持続性のデータストア２３２の複数のページ２３４、２３６、２３８の中にページエラー２４０が検出され、ＤＲＳ ２４２がページエラー２４０に応答して修復操作を行う場合に必ずＤＢＦＳ ２２２から呼び出される２４４ ＤＲＳ ２４２をさらに備えている。

本発明のさまざまな実施形態では、ＤＲＳは、（１）あらゆるページ型についてページレベルのデータの破損に応答し、これを修復する機能、（２）（ａ）インデックスページの破損（クラスタリングの有無を問わない）、（ｂ）データページの破損、（ｃ）ログファイルページの破損に対して第２レベルの回復（再作成または復元）を試みる機能を備えていてもよい。本発明の特定の実施形態は、（ｉ）データ破損ケースの修復／復元を行う機能、（ｉｉ）システムの信頼性と可用性を向上する機能、（ｉｉｉ）スキルのあるサードパーティーがデータベースエンジンまたはストレージエンジンの問題をトラブルシューティングするためのＤＲＳのエラー／イベント履歴テーブルを維持する機能を含むがそれらに限定されないＤＲＳ専用の機能をさらに備えている。

本発明の特定の実施形態では、ＤＢＦＳがリリースされた後に回復ポリシーや検出メカニズムが更新される場合があるので、拡張可能なＤＲＳが提供される。いくつかの実施形態では、ＤＢＦＳデータベースがオンラインに維持されている間に修復を実行するＤＲＳを目的としている。他の実施形態は、ＤＢＦＳストアへの完全なアクセス権（すなわちシステム管理者権限）で実行することを意図している。さらに他の実施形態では、リアルタイムで障害を検出し、これに対処する機能を備えている。いくつかの実施形態では、ＤＲＳの修復は前記データへの変更の単位が維持されるレベル（つまり、アイテムベースのＤＢＦＳでは「アイテム」レベル）でトランザクション的に適切である。最後に、さまざまな実施形では、修復によってアイテム完全に回復するか、その変更が取り消される。ＤＲＳでは、プロセスの途中で再起動が発生しても、回復／復元作業を継続する機能を備えている。

本発明のいくつかの実施形態では、ＤＲＳはＳＱＬイベントに登録しているので、ＳＱＬが一般的なイベントを起動すると、ＤＲＳはこれを中断し、対処することができる（８２３／８２４のイベントを含むがこれに限定されない）。さらに、本発明の別の態様により、データベースエンジンはＤＲＳが特に処理するエラー状態について、ＤＲＳに固有のイベントを送信するように変更できる。

本発明のさまざまな実施形態では、ＤＢＦＳがディスクページの読み出しと書き込みを行うたびに破損を検出する。この場合は、ＳＱＬが破損の種類によってエラーのホストの１つを生成し、固有のＤＲＳイベントを起動し、固有のエラー状態について通知する。ＤＲＳはこうしたエラーを受信し、入力キューに入れて処理する。

本発明のいくつかの実施形態では、ページが破損しているかどうかの確認を、（ａ）ページのチェックサムを調べてチェックサムが無効な場合はページが破損していると見なす方法、または（ｂ）ログシリアル番号（ＬＳＮ）を調べてこれがログファイルの終わりを超えているかを確認する方法（ＬＳＮはトランザクションごとに増分される整数なので、ログの最後のトランザクションはＬＳＮ ４３２の場合に、これを上回るＬＳＮが検出されるページは、書き込みエラーが発生している）を含むがこれらに限定されないさまざまな方法で実行する。この点に関して、ＤＢＦＳの動作に影響を及ぼし得る主要な４種類のページ破損がある（バグなど、その他の原因以外に）。こうした４種類には、ページの断裂、媒体の老朽化、ハードウェア障害、不適切な順序による書き込みが含まれる。ページの断裂は、データページへの極小の書き込みが適切でなかった場合に発生する。すなわち、書き込み中にページの一部のセクターのみがディスクに作成され、その後にたとえば電源障害やセクター書き込みエラーのような障害イベントが発生すると、ページに破損した部分が存在する可能性がある。媒体の老朽化は、物理的な媒体の老朽化によってデータページのビットが破損する場合に発生する。ハードウェア障害は、バス、コントローラ、ハードディスク装置に関連するさまざまな原因で発生する。不適切な順序による書き込みに関して、ＩＤＥドライブではディスクに書き込む順序を保証できないという事実によってこうしたエラーが発生する。特にＩＤＥドライブではライトキャッシュが有効化されており、このためにデータストアへの書き込みは不適切な順序で発生する恐れがある。たとえば、不適切な順序による書き込みの一部が行われたが、電源障害によって中断された場合は、たとえば関連のログエントリが書き込まれる前にデータページがディスクに書き込まれるなど、いくつかのエラーが発生する可能性がある。不適切な順序エラーはログシーケンス番号（ＬＳＮ）を調べることで検出できるが、各ページを読み出す以外にこれを簡単に実行する方法はない。

（ページの分類）
本発明の目的に関して、すべてのページは以下に示すページのいずれかのクラスに分類される。
・データページ：データページはユーザーデータを記載するページであり、クラスタ化されたインデックスリーフページが含まれる。
・インデックスページ：このページには、インデックス情報のみが記載されており、クラスタ化されていないインデックスページと、クラスタ化されたインデックスページの非リーフページの両方が含まれる。
・システムページ：このページには、ＧＡＭ、ＳＧＡＭ、起動ページが含まれ、ＤＲＳがこうしたページに固有の復元サポートを提供しなくても、ＤＲＳはこうしたページに対してページレベルの復元を試みることができる。イベントが発生した場合に、ページレベルの復元がエラーになると、ＤＲＳは緊急修復（ｅｍｅｒｇｅｎｃｙ ｒｅｐａｉｒ）（本明細書で後述）を試みる。
・回復不可能なページ：ＰＦＳ（Ｐａｇｅ Ｆｒｅｅ Ｓｐａｃｅ）ページまたは５つのシステムテーブル（Ｓｙｓｒｏｗｓｅｔｃｏｌｕｍｎｓ、Ｓｙｓｒｏｗｓｅｔｓ、Ｓｙｓａｌｌｏｃｕｎｉｔｓ、Ｓｙｓｈｏｂｔｃｏｌｕｍｎｓ、Ｓｙｓｈｏｂｔｓ）のページは、このクラスのページを含み、この場合、ＤＲＳはデータベース全体を復元する。
・ログページ：このページはトランザクションログに含まれており、このページが破損している場合にＤＲＳは緊急修復を試みる（本明細書で後述）。

（破損の分類）
本発明のいくつかの実施形態では、ＤＲＳは破損が検出されるタイミングによって定義された３つの異なるカテゴリ、すなわち、（１）データベース接続中、（２）標準のオンライン操作中、（３）トランザクションロールバック中のデータページ破損を解決するように設計されている。

（データベース接続中の破損検出：）
図３Ａは、データベースＦＰＭによるデータストアのＤＢＦＳへの接続を示すブロック図である。図３Ｂは、データベース接続操作の間に破損したページを検出し、訂正するプロセスを示すフロー図である。一般に、ＤＢＦＰＭ（ｄａｔａｂａｓｅ ｆｉｌｅ ｐｒｏｐｅｒｔｙ ｍａｎａｇｅｒ）３０２は、ＤＢＦＳストア３０４、３０６、３０８の接続と切断を管理する。ステップ３５２で、ＤＢＦＰＭ ３０２がストア、たとえばＤＢＦＳストア３０４に接続すると、ステップ３５４でＳＱＬはクラッシュ回復を実行し、ステップ３５６でトランザクションログ３１４内にクラッシュ時のアクティブトランザクション３２４（たとえば未完のトランザクション）があるかどうかを確認する。トランザクションがある場合、ステップ３５８でＳＱＬはデータベースのクラッシュ回復を実行し、処理を継続する。クラッシュ回復中に、ＳＱＬは一般に、（ａ）トランザクションログの最終チェックポイントより後の部分を分析し、（ｂ）ディスクへの書き込みが検出されない操作がログ内にあればこれを再実行し、（ｃ）完了していないトランザクションがあれば取り消す。ステップ３６０で回復中にエラーが検出されない場合は、ステップ３６２でデータベースは正常に接続する。しかし、ステップ３６０でクラッシュ回復中にエラーが検出された場合は、ステップ３６４でＳＱＬはデータベース接続に失敗する。

この「データベース接続」のシナリオはストアを接続するたびに呼び出されるので重要である。オペレーティングシステム（たとえば、Ｗｉｎｄｏｗオペレーティングシステム）が起動するたび、および外付けのドライブ（たとえば、Ｆｉｒｅｗｉｒｅ、ＵＳＢなど）をコンピュータに接続またはコンピュータから切断するたびに、ストアが接続される。データベース接続のシナリオでは、クラッシュ回復と、ひいてはページの断裂（未完の書き込み）の検出が呼び出される。ユーザーはハードウェアを物理的に取り外す可能性があるので、ＤＲＳでこうしたケースを処理するのが望ましい。

しかし、本発明のさまざまな実施形態によるＤＲＳを利用する場合に、動作は図４Ａのフロー図に示すものとは若干異なる。まず、ステップ４０２でＤＢＦＰＭはＤＢＦＳデータベースを接続し、ステップ４０４でＳＱＬはクラッシュ回復を実行し、ステップ４０８でさらにデータベースをオンラインに戻そうとする。ステップ４１０でクラッシュ回復のエラーが発生せずにデータベースが接続する場合は、ＳＱＬが正常に戻り、ステップ４５２でデータベースが接続する（オンラインになる）。しかし、エラーが発生する場合は、ステップ４１２でＤＲＳはデータベースを評価し、データベースにトランザクションの整合性があるかどうかを確認する。

データベースに整合性がないのは、トランザクションロールバック中のエラー、つまり物理的または論理的な取り消しエラーが発生する場合、またはクラッシュ回復中に不明なエラーが発生する場合のみである。ステップ４１２でデータベースにトランザクションの整合性がある場合は、ステップ４１４でＤＲＳは回復操作が完了するまで修復を遅延する。換言すれば、ＤＲＳはデータベースの状態をデータベース接続のための整合性がある（「ｓｕｃｃｅｓｓ」）と宣言し、回復が完了した後の破損の検出まで修復の開始を遅らせる。ステップ４５２でデータベースを接続し、クラッシュ回復との競合を回避する。

回復が完了し、ステップ４５２で接続が成功すると、ステップ４７８で遅延された修復がある場合はステップ４８０でＤＲＳが修復を開始し、ステップ４８２で破損に対してまずページレベルの復元の呼び出しを試みる。ステップ４８４でページレベルの復元に失敗した場合、またはページレベルの復元が不可能な場合は、ステップ４８６でＤＲＳはその原因がインデックスページのエラーであるかどうかを確認し、そうである場合はステップ４８８でＤＲＳはインデックスを再作成する。他方で、ステップ４９０でデータページにエラーがある場合は、ステップ４９２でＤＲＳはデータページの復元を試みる。しかし、ステップ４９０でデータベースに整合性がないこと、すなわち不明なエラー／サポートしないエラーがあることをＤＲＳが確認した場合は、ＤＲＳは直ちにデータベースをオフラインにし（これで回復操作を終了する）、ステップ４９４でデータベースを「ｓｕｓｐｅｃｔ」とマークし、ステップ４９６で緊急修復を試みる。

図４Ｂは、データベース接続中にＤＲＳで処理するエラーを示すテーブルである。

（オンライン操作中の破損検出：）
図５Ａは、クエリーエンジンが本発明のさまざまな実施形態のエラーを検出するオンライン操作におけるＤＲＳの利用を示すフロー図である。このシナリオは、たとえばエンドユーザーがオペレーティングシステムシェルを使用してＤＢＦＳに対する比較的複雑なクエリーを実行し、このクエリー実行中にクエリーエンジンはエラーを報告する場合のように、ＤＢＦＳの通常の実行時利用におけるものである。こうしたオンライン操作の状況において、エラーが発生する場合は、ステップ５０２でＤＲＳがトランザクションを中止してエラーを修正しようとする。ステップ５０４で、ＤＲＳはまずページレベルの復元を試みる。しかし、ステップ５０６でデータページレベルの復元が不可能な場合または失敗した場合は、ステップ５０８でＤＲＳは失敗したページの型を決定する。ステップ５１０でインデックスページエラーの場合は、ステップ５１２でＤＲＳはインデックスの回復を試みる。ステップ５１４でデータページのエラーの場合は、ステップ５１６でＤＲＳはデータページの復元を試みる。ステップ５１８でシステムまたはログページエラーの場合は、ステップ５２０でＤＲＳは緊急修復を試みる。ステップ５１８で回復不可能なエラー（５つのシステムテーブルまたはＰＦＳページ）の場合は、ステップ５２２でＤＦＳは自動的にデータベース全体を復元するか、あるいはエンドユーザーがデータベース全体を復元するようにプロンプトを表示する。

図５Ｂは、オンライン操作中にＤＲＳで処理するエラーを示すテーブルである。

（トランザクションロールバック中の破損検出：）
トランザクションロールバック中にエラーが発生する場合、ＤＲＳはデータベースをオフラインにし、ｓｕｓｐｅｃｔとしてマークし、データベースを再起動してクラッシュ回復を呼び出す。このプロセスでは、本明細書で前述したクラッシュ回復中の破損検出が再び呼び出される。

（回復技術）
当事業者には周知であり、すでに明らかなように、トランザクションの整合性はコミットされたデータのみを表示する（または使用可能にする）ことと、正しいデータのみをコミットする（持続性のストアに書き込んでトランザクションログを記録する）ことに関連する。この点に関して、クラッシュ回復中のやり直しと取り消しのすべての要求が適切に実行される限り、データベースはトランザクションに関して整合性がある。したがって、データページおよびインデックスページにはさまざまな破損が存在し得るが、依然としてトランザクション的には整合性がある。

本発明のさまざまな実施形態では、こうしたトランザクションの多くをオンラインで実行するのは望ましくないこと認識しているので、こうした実施形態ではデータベースがオフラインの間にすべての修復を実行しようとする。

ＳＱＬエラーが発生すると、ＤＲＳはページＩＤとデータベースＩＤのみを受け取る。この情報から、ＤＲＳはページに問い合わせてページの型を正確に特定する。こうした実施形態は、データページとインデックスの破損の回復メカニズムを備えており、ＤＲＳはこのメカニズムを使用して該当する破損によって失われたＤＢＦＳアイテムを回復しようとする。しかし、ＧＡＭ、ＳＧＡＭ、ＰＦＳ、起動ページなどを含めて、データベース内で失われる可能性のあるページは他にも多くの型がある。このような型のページについて、一般的なＤＢＦＳは専用のバックアップと回復のメカニズムを備えていないが、ＤＲＳはページレベルの復元を呼び出そうとする。

破損したページに対して、ＤＲＳはページレベルの復元を試みる。ページレベルの復元は音声を伴わない。失われたデータはコミットされていないことをユーザーに対して保証できるためである。任意のテーブルのページに対して同じ技術が適用される。本方法は、復元するページまたはテーブルの型によって変化しない。ページレベルの復元は、ページが最新のスナップショット内に存在する場合にのみ実行できる。有効なトランザクションログも入手できる必要がある。ページが最新のスナップショット内にない場合は、当事業者には周知のアイテムレベルの復元技術（たとえばバックアップ操作からの復元）を使用してページを回復する必要がある。

ページが最新のスナップショット内に存在し、有効なトランザクションログがある場合、ＤＲＳは図６に示す操作を実行してページを復元する。つまり、（１）ステップ６０２で、破損したページのＰａｇｅｌＤを決定し、（２）ステップ６０４で、ＤＢＦＳストアの最新のスナップショットで破損したページを検出してコピーし、（３）ステップ６０６で、ページに適用するトランザクションをロールフォワードしてオンディスクのトランザクションログ（ｏｎ−ｄｉｓｋ ｔｒａｎｓａｃｔｉｏｎ ｌｏｇ）をページに適用し、（４）ステップ６０８で、復元されたページをオンラインデータベースに適用し、さらに、（５）ステップ６１０で、復元するページに関する延期されたトランザクションがある場合は、ステップ６１２でデータベースを再起動する必要がある（クラッシュ回復を実行し、延期されたトランザクションをクリアする）。ない場合はステップ６１４に進む。

前述のスナップショットに関して、当事業者には周知のとおり、ＶＳＳ（Ｖｏｌｕｍｅ Ｓｈａｄｏｗｃｏｐｙ Ｓｅｒｖｉｃｅ）は特定のボリューム（たとえばＮＴＦＳボリューム）のタイムスナップショット内のポイントを保守する方法を提供する。ＶＳＳスナップショットは、書き込みのコピーを使用してボリュームのシャドウコピーを保守する。つまり、ディスクページが変更されるたびに、そのページのプリイメージ（ｐｒｅ−ｉｍａｇｅ）が最新のスナップショットのスナップショット記憶領域に書き込まれる。マシン上でＴｉｍｅＷａｒｐが有効な場合（これは特定のＤＢＦＳと対応するオペレーティングシステムのデフォルトである）、スナップショットはデフォルトの１日２度の頻度で作成され、最大６３スナップショットが保持される。スナップショットに格納されたプリイメージを利用するために、最新のスナップショットが作成された時刻からログが保持され、ログトランザクションはＴｉｍｅＷａｒｐスナップショットでのみ作成されるので、いつでも使用可能な最終のスナップショット以降のログが存在する。ページの破損が存在し、最新のスナップショット内のページが使用できる場合、スナップショットからそのページの現在の時点までのログを再生することでページを復元できる。

ＴｉｍｅＷａｒｐスナップショット処理中に、スナップショット上のＤＢＦＳストアが回復される。これで、スナップショットデータベースの回復によって影響を受けたページについては、ページレベルの復元が不可能になる。この問題を回避するために、ＳＱＬ Ｓｅｒｖｅｒの視点はスナップショットボリューム上のデータベースにとられ、次いでこのデータベースが回復される。つまり、ＤＲＳはスナップショットボリューム内のデータベース上に回復されていない視点を有し、ページレベルの復元のために常にその視点内のページを使用することができる。

システム、ログ、不明なページを修復する場合、つまりログの破損が発生した場合、またはＤＲＳで訂正できない障害がある場合は（たとえばデータまたはインデックス）、ＤＲＳはユーザーに対して、（ａ）データベース（ストア）全体の復元オプションと、（ｂ）緊急モードによるデータベースの回復オプションを提供する。

データベースを緊急モードで修復するには、まずトランザクションログの破損や回復不可能なデータベースの状況から回復するＤＢＣＣの新しい機能を理解することが重要である。そのとき、データベースが回復できず、利用できるバックアップがない場合は、図７に示す以下の一連の操作が、本発明のいくつかのＤＲＳ実施形態に対してデータベースをオンラインに戻す。つまり（ａ）ステップ７０２でデータベースを緊急モードに設定し、（ｂ）ステップ７０４で‘ＤＢＣＣ ＣＨＥＣＫＤＢ（ｄａｔａｂａｓｅ，ＲＥＰＡＩＲ＿ＡＬＬＯＷ＿ＤＡＴＡ＿ＬＯＳＳ）’を実行し、（ｃ）これでデータベースは物理的に整合性がとれており、ステップ７０６でＤＳＲはストア全体のＣＣを実行する。ただし、操作（ｂ）は緊急モードでは特殊な意味をもつ。つまり、（ｉ）エラーが発生してもデータベースの回復を強制的に進める（ログからできるだけ多くの情報を取得するが、データベースはトランザクション的に不整合なままである）。（ｉｉ）破損したログファイルを破棄して新しいログファイルを作成する。（ｉｉｉ）データベース全体の修復を実行し、構造的に整合性のある状態にする。これは、ロールバックまたは取り消しができない「極小」で一方向の操作であり、こうした状況でファイルを手作業で編集せずにデータベースを回復する唯一の方法である。以上のステップが正常に実行されると、データ（アイテムベースのＤＢＦＳではアイテム）に整合性があることが保証されるが、特定のアプリケーションではトランザクション的に整合性がない場合もあることを意味する。

インデックスページの型は、クラスタ化されていないページとクラスタ化された非リーフページの２つがある。データを伴うインデックスページ（クラスタ化されたインデックスリーフページ）はデータページと見なされる。このことを考慮して、回復可能なインデックス障害が発生した場合に、ＤＲＳはオフラインのインデックス再作成を使用してインデックスを修復しようとする（この修復中にデータベースがオンラインの場合は、インデックスのみがオフラインになる）。修復に失敗した場合、ＤＲＳはインデックスを破棄し、インデックスの再作成を試みる。ここで、再作成にも失敗した場合、ＤＲＳはインデックス全体を廃棄するか、またはインデックスを無効にして後で再作成を試みる（恐らく成功するまで無期限に実行する）。

データページの回復に関して、ＤＲＳは処理されたエラーの１つを受け取り、このページがデータページであることを確認した場合は、その回復を試みる。これは、ＳＱＬサーバーの任意の動作状態（ＤＢ接続、オンライン操作、ロールバック）で発生する可能性がある。図８に示すように、ステップ８０２でＤＲＳがデータページのエラーを検出し、ステップ８０４でページレベルの復元を試み、ステップ８０６でこれが失敗した場合に、ＤＲＳは、（ａ）ステップ８０８で破損したページのＰａｇｅｌＤを受け取り、前述のようにページの型を決定することで、破損したページの型を確認し（データページの破損が発生した場合に、ＤＲＳはこのページにアクセスしようとする他のトランザクションに対処する必要はない）、（ｂ）ステップ８１０で、失われたＩｔｅｍＩＤの範囲を取得し（Ｔｘを起動してＤＢＣＣ ＣＨＥＣＫＴａｂｌｅ（ｔａｂｌｅ，ＲＥＰＡＩＲ ＡＬＬＯＷ ＤＡＴＡ＿ＬＯＳＳ）を実行する。これは、ＩｔｅｍＩｄを含む、クラスタ化されたキーに一致しないクラスタ化されていないインデックスのすべてのインデックスキーと、クラスタ化されていないインデックスキーを返すので、ＤＲＳはこれらを抽出し、これらを内部テーブルに書き込む）、さらに（ｃ）ステップ８１２で、ＩｔｅｍＩｄとテーブル名のリストをＷＣＣに渡す（ここで、ＷＣＣはこうしたＩｔｅｍＩＤを修復し、さらにストアの他の部分をチェックして、ＤＢＦＳの整合性を保証し、ＴｘをコミットしてＤＲＳがこうした回復を中止したり再試行したりできるようにする）。複数のページが破損している場合は、ＤＲＳは破損したすべてのページのすべてのＩｔｅｍＩＤを特定し、それを次の処理（たとえば、バックアップから前記ページを復元する）に渡す。

ＤＲＳでは、ページレベルの復元が動作する場合はユーザーデータが失われないことを保証できるので、ＤＲＳに要求されるのは名目的なユーザーへの通知のみである。これは、ページレベルの復元が行われている場合は、ユーザーが予想より応答に時間がかかることに気付く可能性が高いためである。特定の実施形態において、ユーザーは一切通知を受け取らない（これには最大で数秒かかるので）。しかし、他の実施形態では、ＤＲＳがページを復元した事実を把握するために、ＤＲＳは「イベント」ログエントリを作成する。ページの復元を妨げるアクティブトランザクションが存在する最悪のシナリオでは、データベースを切断して再起動する必要があるので（クラッシュ回復を実行するために）、データベースへの接続はすべて終了する。アプリケーションは、このような可能性をあらかじめ考慮した上で設計する必要がある。ただし、設計が不適切な場合は、アプリケーションが「ハング」する可能性がある。したがって、本発明の特定の実施形態ではまさにこうしたイベントが発生する可能性があるという状況についてユーザーに通知し、ユーザーがこうしたアプリケーションをすべて閉じて望ましくない結果を回避できるようにしている。

（エンドユーザーの体験の例）
ＤＲＳの動作を説明するために、ユーザーの体験とユーザーの目に見えないところでＤＲＳが実行している操作について、概要を明らかにするいくつかの状況を以下に示す。

（インデックスの破損：）
Ａｂｂｅｙは、ＷｉｎＦＳクエリーを実行して先週自分が変更したすべての文書を検索しようとしている。このクエリー実行中に、ＷｉｎＦＳはこれには通常より若干時間がかかることを通知する。事実、後続のいくつかクエリーも若干時間がかかっている。ここで、Ａｂｂｅｙはタスクバー上に表示された小さなバルーンに気付く。このバルーンは、Ａｂｂｅｙのマシンで信頼性の問題が検出されたので、Ｗｉｎｄｏｗｓ（登録商標）がこのエラーを修復するために時間がかかることを伝えている。まもなく別のバルーンが表示され、インデックスが正常に再作成されたことをＡｂｂｅｙに通知する。これで、Ａｂｂｅｙはコンピュータの動作が改善されたことを知って安心する。

Ａｂｂｅｙの目に見えないところで、ＤＲＳはインデックスの破損を検出し、修復していた。このためには、インデックスをオフラインにし（したがってパフォーマンスが低下した）、インデックスを再作成し、さらにインデックスをオンラインに戻すという操作が必要であった。

（断裂したページの書き込み：）
Ｔｏｂｙは雷雨の最中に宿題のＡｄａｍ Ｓｍｉｔｈ（アダムスミス）に関するエッセイを書いており、定期的に保存している。エッセイの約９０％を書いたところで、Ｔｏｂｙの家全体が停電した。Ｔｏｂｙが使用しているのはラップトップではないので、バッテリのバックアップはない。Ｔｏｂｙにとって幸いなことに、約３０分後に電力は復旧する。Ｔｏｂｙはコンピュータにログオンし、エッセイを開こうとする。Ｔｏｂｙは普段より時間がかかるような気がして困惑する。

Ｔｏｂｙの目に見えないところで起こっていたのはＴｏｂｙのエッセイの文書アイテムの破損であり、停電が発生したときのハードディスクドライブの書き込みによるページの断裂によるものである。ＤＢＦＳが再起動すると、ＤＲＳはこのデータページの破損を検出し、データを回復しようとした。ＤＲＳは自動のスナップショットから自動的にデータページの復元を試みた。Ｔｏｂｙは自分の作業を定期的に保存していたので、最新のスナップショットにエッセイのコピーが存在していた。したがって、ＤＢＦＳは破損したページを自動的に復元できた。

（ビットの故障）とセクターの破損：
Ｓｕｓａｎはこれまでデジタルカメラを愛用しており、最近の２年間には自分の子供たちの写真５８００枚を撮っていた。Ｓｕｓａｎは、この５８００枚の中から３０００枚を超える写真を自分のコンピュータのＷｉｎＦＳに保存していた。Ｓｕｓａｎにとって残念なことに、こうした大切な写真を保存するハードディスクドライブでディスクの一部のセクターが破損したこの破損したセクターには、Ｓｕｓａｎの破損した写真１０枚が保存されている。Ｓｕｓａｎがこうした写真を表示しようとするとオペレーティングシステムのエラーが発生し、バックアップから写真を復元するようにというプロンプトが表示される。Ｓｕｓａｎはプロンプトに従ってバックアップ媒体（ｚｉｐドライブ）を検索し、ディスクからアイテムを復元する。

Ｓｕｓａｎの目に見えないところでＤＢＦＳはページレベルの復元を試みている。しかし、こうした写真は変更されていないので（これまでに）、最新のスナップショット内には存在しない。したがって、この特定の実施形態ではＳｕｓａｎに独自のバックアップ（こうしたアイテムのみ）を取り込むように指示するプロンプトを表示する必要がある。

（結論）
本明細書で説明するさまざまなシステム、方法、技術は、ハードウェアまたはソフトウェア、あるいは必要に応じて両者の組み合わせによって実装できる。したがって、本発明の方法および装置、あるいは本発明の特定の態様または部分は、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ、ハードドライブ、または他の任意のマシン可読の記憶媒体などの物理的な媒体内に実装されたプログラムコード（すなわち命令）の形をとってもよい。この場合、プログラムコードがコンピュータなどのマシンにロードされて実行されると、このマシンは本発明を実施する装置となる。プログラム可能なコンピュータでプログラムコードを実行する場合に、コンピュータは一般にプロセッサ、プロセッサ可読の記憶媒体（揮発性と不揮発性のメモリおよび／またはストレージエレメントを含む）、少なくとも１つの入力装置、少なくとも１つの出力装置を備えている。１つまたは複数のプログラムは、コンピュータシステムと通信するハイレベルの手続き的またはオブジェクト指向のプログラミング言語で実装されるのが好ましい。ただし、プログラム（１つ以上）は必要に応じてアセンブリ言語や機械語で実装してもよい。いずれの場合も、言語はコンパイラ言語でもインタープリタ言語でもよく、ハードウェアによる実装と組み合わせてもよい。

本発明の方法および装置は、電気的な配線またはケーブル、光ファイバ、あるいは他の形の送信など、送信媒体を介して送信されるプログラムコードの形で実装してもよい。この場合、プログラムコードが受信され、ＥＰＲＯＭ、ゲートアレイ、プログラム可能な論理デバイス（ＰＬＤ）、クライアントコンピュータ、ビデオレコーダなどのマシンにロードされて実行されると、このマシンは本発明を実施する装置となる。汎用プロセッサに実装する場合に、プログラムコードはプロセッサとの組み合わせにより、本発明のインデックス作成機能を実施する独自の装置を提供する。

本発明について、さまざまな図面に示す好ましい実施形態に関連付けながら説明してきたが、本発明の同じ機能を実行し、本発明の範囲を逸脱しない限り、本発明の他の同様の実施形態を利用できること、あるいは説明した実施形態への変更や追加が可能であることを理解されたい。たとえば、本発明の例示的な実施形態について、パーソナルコンピュータの機能をエミュレーシするデジタルデバイスのコンテクストで説明するが、本発明が本出願で説明するこうしたデジタルデバイスに限定されず、ゲームコンソール、ハンドヘルドコンピュータ、ポータブルコンピュータなど、無線か有線かを問わず、任意の数の既存のまたは新しいまたはコンピューティング環境に適用でき、さらに通信ネットワーキングを介して接続された任意の数のこうしたコンピューティングデバイスに適用でき、ネットワークを介して対話できることは、当事業者には言うまでもない。さらに、特に無線ネットワーク用のデバイスの数が増大を続けているので、本明細書では、ハンドヘルドデバイス向けのオペレーティングシステムおよび他のアプリケーションに固有のハードウェア／ソフトウェアインターフェースシステムを含むさまざまなコンピュータプラットフォームを対象としていることを強調する必要がある。したがって、本発明は特定の実施形態に限定されず、添付の特許請求の範囲に従うものとする。

本発明の態様を組み込むことができるコンピュータシステムの例を示すブロック図である。 本発明のいくつかの実施形態を代表するデータベースファイルシステム（ＤＢＦＳ）のデータ信頼性システム（ＤＲＳ）の構造を示すブロック図である。 データベースＦＰＭによるデータストアのＤＢＦＳへの接続を示すブロック図である。 本発明のいくつかの実施形態による、データベース接続操作の間に破損したページを検出し、訂正するプロセスを示すフロー図である。 本発明のさまざまな実施形態による、起動／クラッシュ回復のコンテクストにおけるＤＲＳの利用を示すフロー図である。 データベース接続中にＤＲＳで処理するエラーを示す図である。 本発明のさまざまな実施形態による、クエリーエンジンがエラーを検出するオンライン操作におけるＤＲＳの利用を示すフロー図である。 オンライン操作中にＤＲＳで処理するエラーを示す図である。 最新のスナップショット内にページが存在せず、有効なトランザクションログが存在する場合に、復元を実行するＤＲＳを示すフロー図である。 本発明による特定のＤＲＳの実施形態でデータベースを回復できず、利用可能なバックアップが存在しない場合に、データベースをオンラインに戻す方法を示すフロー図である。 本発明の１つの態様に従ってＤＲＳでデータページを回復しようとする方法を示すフロー図である。

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