JP2005322246A - データモデル内のエンティティの自動的な保守および修復のためのシステムおよび方法 - Google Patents

Abstract

【課題】 ハードウェア／ソフトウェアインタフェースシステムのデータベースファイルシステムのための、単独で動作、または物理的一貫性チェッカ（ＰＣＣ）および／またはデータ信頼性システム（ＤＲＳ）とともに動作する論理的一貫性チェッカ（ＬＣＣ）を提供する。
【解決手段】 論理的データ訂正は、エンティティ（例えば、アイテムベースのオペレーティングシステムにおけるアイテム、拡張、および／またはリレーションシップ。アイテムベースのオペレーティングシステムは、アイテムベースのハードウェア／ソフトウェアインタフェースシステムの一例である）に対する論理的データ破壊を対象とする。この関連で、ＬＣＣは、データストアに典型的に記憶されるエンティティに対する論理的損傷を分析して訂正する。これは、当該データストア内のこのようなすべてのエンティティが一貫性を持つとともに、データモデル規則に準拠することを保証する。
【選択図】 図４

Description

本発明は、包括的にはファイルシステム管理に関し、より詳細には、データモデルに関するデータの信頼性および一貫性を保証するための自動的なファイルシステムの保守および修復に関する。本発明の種々の態様は、他の下位レベル（子）のデータエンティティを失うことなく、あるデータエンティティレベルでの論理的データエラーに応答してそれを訂正することに関する。特に、本発明の種々の態様は、具体的には、アイテムベースのハードウェア／ソフトウェアインタフェースシステムにおける論理的データの保守に関する。

クライアントデータベースプラットフォーム（すなわち、家庭用および業務用のデスクトップコンピュータ）はサーバプラットフォームよりもはるかに低い品質のハードウェアを用いているが、サーバ級のハードウェア（コントローラ、ドライバ、ディスク等）でも、データベースアプリケーションがデータストアに書き込んだものが読み出し操作で返されないというような「物理的」データ破壊（data corruption）が起こり得る。もちろん、このことは明らかに、クライアントデータベースプラットフォームの場合のほうが（サーバデータベースプラットフォームと対比して）多くの問題を生じる。それには種々の理由があるが、例えば、クライアントマシンは不測の停電により書き込み操作の途中で勝手に電源が切れる（ひいては、ちぎれたページや潜在的なデータベース破壊につながる）確率が高いのに対して、サーバデータベースシステムは、停電による障害を軽減するために無停電電源を利用するのがより一般的だということがある。もう１つの「物理的」データ破壊の原因に媒体老朽化がある。この場合、物理的記憶媒体が文字通り時間とともに摩耗する。さらに、信頼性に関する懸念のもう１つの原因として、ソフトウェアエラーにより引き起こされる「論理的」破壊の検出および回復がある。そうしたエラーが不注意によるもの（例えばバグ）か、悪意によるもの（例えばウィルス）かは問わない。

従来、データベース（およびデータベースファイルシステム）の保守および修復は、データベースシステムについて高度の技術と深い知識を有するデータベースマネージャ（管理者）等、あるいは少なくとも、データベースシステムに精通し日頃使用している人、すなわち、概してデータベース技術に関して比較的熟練した人に委ねられてきた。他方、オペレーティングシステムおよびアプリケーションプログラムの通常の家庭および業務のエンドユーザは、データベースを扱うことはまれであり、データベースの保守および修復の問題を扱う能力を備えていないことが多い。

これまでは、これらの２つのグループの間で技術レベルが全く異なることは、大して重要ではなかった。しかし、ハードウェア／ソフトウェアインタフェースシステムのためのデータベース実装ファイルシステムが現れたことで、このようなあまり技術を持たないエンドユーザが、普通は解決できないデータベースの保守および修復の問題に直面する状況が生じている。このため、業務用／家庭用のデータベース実装オペレーティングシステムファイルシステム（略して「データベースファイルシステム」（ＤＢＦＳ））は、破壊を検出し、そのデータベースをトランザクション的に一貫性のある状態に回復できなければならず、回復不能なデータ喪失の場合には、ＤＢＦＳは、当該データへのアトミック変更単位(atomic change units)が維持されるレベルで（すなわち、アイテムベースのＤＢＦＳの場合には「アイテム」レベルで）論理的なデータの一貫性を保証しなければならない。さらに、デフォルトでレイジー(lazy;非同期遅延)コミットモードで動作するＤＢＦＳの場合、異常シャットダウンの直前にコミットされたトランザクションの持続性は保証されず、詳細を明らかにして訂正しなければならない。

さらに、業務／家庭のエンドユーザは、ＤＢＦＳの保守および回復を自動化することから多大な利益を受けるが、データベースマネージャおよび高いデータベース技術を有する人々もまた、一般的なデータベースの保守および修復のための技術的解決法から利益を受けるであろう。データベースアドミニストレータ（データベースシステム管理者）がデータベースツール（例えば、ＳＱＬ Ｓｅｒｖｅｒ ２０００とともに提供されるデータベースチューニングアドバイザ）を利用することは当技術分野において一般的であるが、このようなツールは、信頼性に直接対処するのではなく、データベースのバックアップを運営管理するための手段を提供するものである。そして、このようなツールはあまり自動化されておらず、特にデータベースバックアップが入手できない場合やその他の修復上の問題が生じた場合には、データベースアドミニストレータの実質的関与を必要とする。したがって、データベース信頼性に対処するための自動化された解決手段があれば、データベースアドミニストレータおよびその他の熟練したデータベースユーザにとっても有益であろう。

ＤＢＦＳのためのデータ信頼性システム（ＤＲＳ）は、自動的に、そしてエンドユーザによる直接の関与をほとんどまたは全く伴わずに（したがって当該エンドユーザにとって実質上透過的である）、データベース管理（ＤＢＡ）タスクを実行するためのフレームワーク（枠組み）とポリシー（指針）のセットとを備える。いくつかの実施形態では、ＤＲＳフレームワークは、エラーおよびイベント（事象）の通知、ポリシー、ならびにエラー／イベント処理アルゴリズムをＤＲＳに組み込むためのメカニズム（機構）を実装する。より詳細には、これらの実施形態では、ＤＲＳは、バックグラウンドにおいてＤＢＦＳの保守および修復を担当するバックグラウンドスレッドであるので、ＤＲＳは、最高のレベルで、ＤＢＦＳの全般的健全性を保護し維持する。いくつかの実施形態では、ＤＲＳは、物理的データ破壊に対する以下の特徴、すなわち、（１）すべてのページタイプに対してページレベルでデータ破壊に応答して訂正し、（２）インデックスページ破壊（クラスタ化および非クラスタ化）、データページ破壊、およびログファイル内のページ破壊に対する第２レベルの回復（リビルド（修正）またはリストア（復旧））を試みる、という特徴を備える。したがって、いくつかの実施形態では、ＤＲＳは以下の機能、すなわち、（ｉ）データ破壊の修復／リストアの事例を扱い、（ｉｉ）システムの信頼性および可用性を向上させ、（ｉｉｉ）必要であれば熟練した第三者がデータベースやストレージエンジンの障害をトラブルシューティングするためのＤＲＳエラー／イベント履歴テーブルを管理する、という機能を備える。

これら諸実施形態は物理的データ破壊に対処する（すなわち、物理的記憶媒体に記憶されたデータベース内の破壊されたデータを訂正する）ことが可能であるが、頑強なＤＲＳは、データストアに典型的に記憶されるエンティティ（例えば、アイテム、拡張、および／またはリレーションシップ）に対する論理的データ破壊にも対処することにより、当該データストア内のこのようなすべてのエンティティが一貫性を持つとともにデータモデル規則に準拠することを保証するべきである。

本発明の種々の実施形態は、ＤＢＦＳ（データベースファイルシステム）のためのデータ信頼性システム（ＤＲＳ）に関する。当該ＤＢＦＳは、データベース（物理的データ）内に維持管理されるファイルシステム（論理的データ）を備える。あるいは換言すれば、ＤＢＦＳは、ファイルシステム（論理的データ）を表すデータベース（物理的データ）を備える。ＤＲＳは、自動的に、そしてエンドユーザによる直接の関与をほとんどまたは全く伴わずに（したがって当該エンドユーザにとって実質上透過的である）、データベース管理（ＤＢＡ）タスクを実行するためのフレームワークとポリシーのセットとを備え得る。ＤＲＳフレームワークは、エラーおよびイベントの通知、ポリシー、ならびにエラー／イベント処理アルゴリズムをＤＲＳに組み込むためのメカニズムを実装する。より詳細には、これらの実施形態では、ＤＲＳは、バックグラウンドでＤＢＦＳの保守および修復を担当するバックグラウンドスレッド（background thread）であるので、ＤＲＳは、最高のレベルで、ＤＢＦＳの全体的健全性を保護し維持する。

本発明の種々の実施形態では、ＤＲＳは以下の特徴を備える。
・物理的データ訂正： すべてのページタイプに対してページレベルで物理的データ破壊に応答して訂正し、インデックスページ破壊（クラスタ化および非クラスタ化）、データページ破壊、およびログファイル内のページ破壊に対するリビルドまたはリストアを試みることを含み得る。
・論理的データ訂正： 「エンティティ（実体）」、例えば、アイテムベースのオペレーティングシステムにおけるアイテム、拡張、および／またはリレーションシップ（関係）、に対する論理的データ破壊に応答して訂正する（アイテムベースのオペレーティングシステムは、アイテムベースのハードウェア／ソフトウェアインタフェースシステムの一例である）。

２番目の事項に関して、本発明のいくつかの実施形態は、具体的には、データストアに典型的に記憶されるエンティティ（例えば、アイテム、拡張、および／またはリレーションシップ）に対する論理的「損傷」を分析して訂正する論理的一貫性チェッカ（ＬＣＣ）に関する。これは、当該データストア内のこのようなすべてのエンティティが一貫性を持つとともにデータモデル規則に準拠することを保証するためのものである。ＬＣＣは、いくつかの実施形態では自律的（autonomous）であり得るが、他の実施形態では、物理的データ破壊を検出し訂正する物理的一貫性チェッカ（ＰＣＣ）と結合してもよく、さらに他の実施形態では、ＬＣＣはＤＲＳのコンポーネントを備えてもよい。

上記の概要と、以下の好ましい実施形態の詳細な説明は、添付図面と併せて読むとより良く理解される。本発明を説明する目的上、図面には本発明の例示的構成が示されるが、本発明は、開示された特定の方法や手段には限定されない。

本発明の構成は、法定の要件を満たすように具体的に説明されている。しかし、その説明自体は、本発明の範囲を限定することを意図していない。むしろ、本発明者は、別の異なるステップや、本明細書に記載のものに類似したステップの組合せを、現在または将来の他の技術とともに含むようにして、特許請求の範囲に記載の構成を他の方法で実施することも可能であると考えている。さらに、「ステップ」という用語は、本明細書で用いる場合には、使用される方法のさまざまな要素を含意するために用いられることがあるが、この用語は、個々のステップの順序が明示的に記載されない限り、本明細書に開示されている種々のステップの間のいかなる特定の順序を意味するものとも解釈されてはならない。

上記の概要は、本発明の特徴の概観を提供するものである。以下、本発明の一実施形態を詳細に説明する。以下に記載される種々の実施形態について、本発明の特徴は、ＭＩＣＲＯＳＯＦＴ（登録商標）ＳＱＬ ＳＥＲＶＥＲデータベースシステム（本明細書では単に「ＳＱＬ」と呼ぶこともある）において、単独で、または次世代パーソナルコンピュータ用オペレーティングシステム（一般に「Ｗｉｎｄｏｗｓ Ｌｏｎｇｈｏｒｎ」あるいは略して「Ｌｏｎｇｈｏｒｎ（ロングホーン）」と呼ばれる）のためのＭＩＣＲＯＳＯＦＴ ＷｉｎＦＳファイルシステムに組み込まれて、実施されるものとして説明される。上記のように、ＳＱＬ ＳＥＲＶＥＲ（サーバー）は、ＭＩＣＲＯＳＯＦＴ ．ＮＥＴ共通言語ランタイム（ＣＬＲ）を組み込むことにより、ＳＱＬ ＳＥＲＶＥＲデータベースのデータストアに作用するようなマネージドコードの書き込みおよび実行が可能となる。下記の実施形態はこの状況で動作するが、本発明は、ＳＱＬ ＳＥＲＶＥＲ製品における実施には全く限定されないことはいうまでもない。むしろ、本発明は、オブジェクト指向データベースシステムやオブジェクト関係拡張を備えたリレーショナル（関係型）データベースシステムのようなデータベースストアに作用するためのオブジェクト指向プログラミングコードの実行をサポートするいかなるデータベースシステムでも実施可能である。したがって、本発明は下記の特定の実施形態に限定されず、特許請求の範囲によって規定される本発明の精神および範囲内にあるすべての変更形態を網羅することを意図するものと理解されたい。

［コンピュータ環境］
本発明の多くの実施形態がコンピュータ上で実行できる。図１および以下の説明は、本発明が実施され得る好適なコンピューティング環境の簡単な概説を行うことを意図している。必須ではないが、本発明は、クライアントワークステーションやサーバ等のコンピュータによって実行されるプログラムモジュール等のコンピュータ実行可能命令との一般的関連で説明される。一般的に、プログラムモジュールは、特定のタスクを実行し、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、コンポーネント、データ構造等を含む。さらに、当業者には理解されるように、本発明は、ハンドヘルド装置、マルチプロセッサシステム、マイクロプロセッサ方式の電子機器またはプログラム可能な消費者電子機器、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ等の他のコンピュータシステム構成を用いて実施してもよい。また、本発明は、通信ネットワークを通じてリンクされたリモート処理装置によってタスクが実行されるような分散コンピューティング環境で実施してもよい。分散コンピューティング環境では、プログラムモジュールはローカルおよびリモートの両方のメモリ記憶装置に配置され得る。

図１に示すように、例示的な汎用コンピューティングシステムは従来型のパーソナルコンピュータ２０等を含み、これは処理ユニット２１、システムメモリ２２、およびシステムメモリを含む種々のシステムコンポーネントを処理ユニット２１に結合するシステムバス２３を含む。システムバス２３は、さまざまなバスアーキテクチャのいずれかを用いたメモリバスまたはメモリコントローラ、ペリフェラル（周辺）バス、およびローカルバスを含む、数種のバス構成のいずれでもよい。システムメモリは読み出し専用メモリ（ＲＯＭ）２４およびランダムアクセスメモリ（ＲＡＭ）２５を含む。起動中等にパーソナルコンピュータ２０内の要素間で情報を転送するのに役立つ基本ルーチンを含む基本入出力システム２６（ＢＩＯＳ）がＲＯＭ２４に記憶されている。また、パーソナルコンピュータ２０は、ハードディスク（図示せず）を読み書きするためのハードディスクドライブ２７、リムーバブル磁気ディスク２９を読み書きするための磁気ディスクドライブ２８、およびＣＤ−ＲＯＭ等の光媒体のようなリムーバブル（取り外し可能な）光ディスク３１を読み書きするための光ディスクドライブ３０も含み得る。ハードディスクドライブ２７、磁気ディスクドライブ２８、および光ディスクドライブ３０はそれぞれハードディスクドライブインタフェース３２、磁気ディスクドライブインタフェース３３、および光ドライブインタフェース３４によってシステムバス２３に接続される。ドライブおよびそれらに関連するコンピュータ可読媒体は、パーソナルコンピュータ２０のためのコンピュータ可読命令、データ構造、プログラムモジュールおよびその他のデータの不揮発性ストレージを提供する。本明細書に記載される例示的環境はハードディスク、リムーバブル磁気ディスク２９およびリムーバブル光ディスク３１を使用しているが、当業者には理解されるように、磁気カセット、フラッシュメモリカード、ディジタルビデオディスク、ベルヌーイカートリッジ、ランダムアクセスメモリ（ＲＡＭ）、読み出し専用メモリ（ＲＯＭ）等のような、コンピュータがアクセス可能なデータを記憶できる他の種類のコンピュータ可読媒体もまた、例示的オペレーティング環境において使用可能である。

オペレーティングシステム３５、１つまたは複数のアプリケーションプログラム３６、他のプログラムモジュール３７およびプログラムデータ３８を含めて、複数のプログラムモジュールが、ハードディスク、磁気ディスク２９、光ディスク３１、ＲＯＭ２４またはＲＡＭ２５に記憶され得る。ユーザは、キーボード４０およびポインティングデバイス４２等の入力装置を通じてパーソナルコンピュータ２０にコマンドおよび情報を入力できる。他の入力装置（図示せず）としては、マイクロフォン、ジョイスティック、ゲームパッド、サテライトディッシュ、スキャナ等が挙げられる。これらおよびその他の入力装置は、システムバスに結合したシリアルポートインタフェース４６を通じて処理ユニット２１に接続されることが多いが、パラレルポート、ゲームポートまたはユニバーサルシリアルバス（ＵＳＢ）のような他のインタフェースで接続されてもよい。モニタ４７または他の種類の表示装置もまた、ビデオアダプタ４８のようなインタフェース経由でシステムバス２３に接続される。モニタ４７に加えて、パーソナルコンピュータは通常、スピーカおよびプリンタのような他の周辺出力装置（図示せず）を含む。また、図１の例示的システムは、ホストアダプタ５５、ＳＣＳＩ（Small Computer System Interface：小型コンピュータ用周辺機器インターフェース）バス５６、およびＳＣＳＩバス５６に接続された外部記憶装置６２も含む。

パーソナルコンピュータ２０は、リモートコンピュータ４９のような１つまたは複数のリモートコンピュータへの論理コネクション（論理結合）を用いたネットワーク環境で動作し得る。リモートコンピュータ４９は、別のパーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア（peer）デバイスまたは他の一般的なネットワークノードであってよく、通常、パーソナルコンピュータ２０に関連して上記で説明した要素の多くまたはすべてを含む。ただし、図１にはメモリ記憶装置５０のみが例示されている。図１に示されている論理コネクションは、ローカルエリアネットワーク（ＬＡＮ）５１および広域ネットワーク（ＷＡＮ）５２を含む。このようなネットワーキング環境は、事務所、企業規模のコンピュータネットワーク、イントラネット（企業内ネットワーク）およびインターネットで一般的である。

ＬＡＮネットワーキング環境で使用される場合、パーソナルコンピュータ２０は、ネットワークインタフェース（アダプタ）５３を通じてＬＡＮ５１に接続される。ＷＡＮネットワーキング環境で使用される場合、パーソナルコンピュータ２０は通常、インターネットのような広域ネットワーク５２を通じて通信を確立するためのモデム５４等の手段を含む。モデム５４は、内蔵でも外付けでもよいが、シリアルポートインタフェース４６経由でシステムバス２３に接続される。ネットワーク環境では、パーソナルコンピュータ２０に関して図示されているプログラムモジュールまたはその一部が、リモート（遠隔の）メモリ記憶装置に記憶されてもよい。理解されるように、図示されているネットワーク接続は例示であり、コンピュータ間で通信リンクを確立する他の手段を使用してもよい。

本発明の多くの実施形態は、コンピュータ化されたシステムに特に適していると考えられるが、本明細書には、本発明をそのような実施形態に限定する意図は全くない。逆に、本明細書で用いられる場合、「コンピュータシステム」という用語は、情報を記憶および処理することが可能な、および／または記憶された情報を用いて装置（デバイス）自体の動作または実行を制御することが可能なあらゆる装置を包含することを意図しており、そのような装置が実際に電子的、機械的、論理的、または仮想的のいずれであるかを問わない。

［データ信頼性システム（ＤＲＳ）の概要］
本発明のいくつかの実施形態では、データ信頼性システム（ＤＲＳ）は、バックグラウンドでデータベースを保守し修復することによりデータベースファイルシステム（ＤＢＦＳ）の全般的健全性を保護するスレッドである。図２は、ＤＢＦＳ内のＤＲＳの構成を示すブロック図である。図中、複数のアプリケーション（ＡＰＰ）２１２、２１４、および２１６にオペレーティングシステムレベルのサービスを提供するオペレーティングシステム（ＯＳ）２０２は、永続的データストア２３２に論理的に結合したＤＢＦＳ２２２を備える。オペレーティングシステム２０２は、ＤＲＳ２４２をさらに備える。ＤＲＳ２４２は、例えば、永続的データストア２３２内の複数のページ２３４、２３６、および２３８の内からページエラー２４０が発見された時に、必ずＤＢＦＳ２２２によって呼び出される（２４４）。するとＤＲＳ２４２は、ページエラー２４０に応答して修復動作を実行する。

本発明のいくつかの実施形態では、ＤＢＦＳが解放された後に回復ポリシーおよび検出メカニズムが更新されるようにＤＲＳが拡張される。いくつかの実施形態は、ＤＢＦＳデータベースがオンラインのままである間に修復を実行するＤＲＳに関する。さらに他の実施形態では、ＤＢＦＳストアへのフルアクセス（すなわちsysadmin(システム管理者)特権）で動作する。さらに他の実施形態は、リアルタイムで障害を検出しそれに対処する能力を有する。

いくつかの実施形態では、ＤＲＳ修復は、当該データへの変更単位が維持されるレベルで（すなわち、アイテムベースのＤＢＦＳの場合には「アイテム」レベルで）トランザクションを行う。種々の実施形態では、修復は、アイテムを完全に回復するか、または、その変更をバックアウト（取り消す）するか（したがってエラーを部分的に訂正することはない）のいずれかであり、ＤＲＳは、プロセスの途中でリブート（再起動）が起きても回復／リストア作業を継続する能力を有してもよい。本発明のいくつかの実施形態では、ＤＲＳは、ＳＱＬイベントにサブスクライブ（申し込み）することにより、ＳＱＬが一般イベントを発火させた場合にＤＲＳがそれをインターセプト（迎撃）して反応できる（限定ではないが、８２３／８２４イベントを含む）。さらに、本発明のいくつかの実施形態は、ＤＲＳが具体的に処理すべきエラー条件に対するＤＲＳ固有のイベントを送出するように修正可能なデータベースエンジンに関する。

本発明の種々の実施形態では、物理的および／または論理的破壊は、ＤＢＦＳがディスクのページの読み書きをする時に検出される。その場合、ＳＱＬは、その破壊がどのような種類のものかに応じて多数のエラーのうちの１つを発生するとともに、特定のＤＲＳイベントを発火させることにより、その特定のエラー状況を通知する。そして、ＤＲＳは、それらのエラーを受信して、処理のために到着キューに入れる。

本発明のいくつかの実施形態では、ページが物理的に破壊されているかどうかを確認することが種々の手段によって達成できる。そのような手段としては、限定ではないが、（ａ）ページのチェックサムを調べ、チェックサムが不正（invalid;正しくない）である場合、ページが破壊されているとみなすもの、あるいは（ｂ）ログシリアル番号（ＬＳＮ）を調べ、それがログファイルの終端を超えているかどうかを確かめるもの（ここで、ＬＳＮは、各トランザクションごとにインクリメントされる整数であるので、ログ内の最終トランザクションがＬＳＮ４３２であるときに、それより大きいＬＳＮを有するページが見つかった場合には、アウトオブオーダー（順序が乱れた）書き込みエラーが発生したはずである）がある。これに関して、ＤＢＦＳの動作に影響し得るページ破壊として（バグ等の他の原因に加えて）４つの主要なタイプがある。それらの４つのタイプは、ちぎれたページ、媒体老朽化、ハードウェア障害、およびアウトオブオーダー書き込みである。ちぎれたページは、データのページがアトミック的（原子的）に正しく書き込まれない時に起こる。その場合、書き込み中に、障害イベント、例えば停電やセクタ書き込み障害の前にはページの一部のセクタしかディスクに書き込まれないので、そのページのどの部分も破壊され得る。媒体老朽化は、データページビットが物理的な媒体老朽化によって破壊された場合に起こる。ハードウェア障害は、バス、コントローラ、あるいはハードディスク装置に関連するさまざまな理由で起こり得る。アウトオブオーダー書き込みについては、このようなエラーはＩＤＥドライブがディスクへの書き込み順序を保証できないこと、特にＩＤＥドライブのライトキャッシュが有効に（オンに）なっているためにデータストアへの書き込みの順序が入れ替わる（アウトオブオーダー）ことに起因する。一連のアウトオブオーダー書き込みが途中まで行われたが例えば停電で中断した場合、いくつかのエラー、例えば、関連するログエントリが書き込まれる前にデータページがディスクに書き込まれるというようなことが起こり得る。アウトオブオーダーエラーは、データページに関するログシーケンス番号（ＬＳＮ）をチェックすることで検出できるが、あらゆるページを読み出す以外にこれを行う容易な方法はない。

［論理的一貫性チェッカ］
本発明の種々の実施形態は、具体的には、データストアに典型的に記憶されるエンティティ（例えば、アイテム、拡張、および／またはリレーションシップ）に対する論理的「損傷」を分析し訂正する論理的一貫性チェッカ（ＬＣＣ）に関する。これは、当該データストア内のこのようなすべてのエンティティが一貫性を持つとともにデータモデル規則に準拠することを保証するためのものである。ＬＣＣは、いくつかの実施形態では自律的であり得るが、他の実施形態では、物理的データ破壊を検出し訂正する物理的一貫性チェッカ（ＰＣＣ）と結合してもよく、さらに他の実施形態では、ＬＣＣはＤＲＳのコンポーネントを備えてもよい。

データベース技術を用いて構築されるファイルシステム（データベースファイルシステム）の場合、論理的一貫性は、次の意味で物理的一貫性とは別個独立である。すなわち、後者（物理的一貫性）は、データベース構造自体および記憶媒体上のそのデータベースの物理的ストレージに関係するのに対して、前者（論理的一貫性）は、当該データベースに記憶されるデータによって表現されハードウェア／ソフトウェアインタフェースシステムのファイルシステムを表す論理的データスキーマに関係する。

物理的一貫性はいくつかの点（以下で説明する）で論理的一貫性と関連するが、本発明のいくつかの実施形態は主として論理的一貫性を保証することに関する。もちろん、物理的非一貫性（例えば、当該データベース構造の一部を含むディスクセクタが不良になる場合）を引き起こす物理的損傷は、論理的一貫性も損傷する（例えば、当該不良ディスクセクタにおいて当該データベースに記憶されているエンティティに対するデータの損失）ことがあるが、必ずしもすべての論理的損傷が物理的損傷に対応するわけではない（例えば、データモデル規則に違反するソフトウェアバグから生じる論理的エラー）。したがって、論理的非一貫性は次の２つのタイプに分けることができる：（ｉ）物理的損傷に起因する論理的非一貫性、および（ｉｉ）少なくとも１つのデータモデル規則（例えば、すべてのエンティティプロパティ値（属性値）は規則で指定された範囲内になければならず、エンティティはそのすべての構成部分を有していなければならず、アイテムは少なくとも１つの保有リレーションシップを有していなければならない等々）の違反に起因する論理的非一貫性。

一般に、論理的エラーを「修復(repairing)」することは、エラーが生じたデータを「リストア（restoring:復元、回復）」することよりも本質的に劣る。というのは、そのデータのバックアップ(控え)は、損傷または損失したデータの良好なコピーである可能性が高い（または良好なコピーを再構成するために使用できる）からである。したがって、リストア技法のほうが修復技法よりも好ましい。

本発明のいくつかの実施形態では、ページ上のエンティティ（実体）が論理的に破壊されているかどうかを確認することが図３に示す手法を用いて達成できる。この手法では、ステップ３０２で、ＬＣＣが、データベーステーブルについて、ＤＢＦＳ内に存在するエンティティの参照整合性（referential integrity）（「エンティティ外部条件（entity externals）」）をチェックする。次に、ステップ３０４で、ＬＣＣは、データモデル規則違反がないことを保証するために、各エンティティの構造整合性(structural integrity)（「エンティティ内部条件（entity internals）」、例えば、制約およびリレーションシップ）をチェックする。（いくつかの実施形態では、ＬＣＣはデータベース内のあらゆるエンティティをチェックする。）ステップ３０６で、いくつかの実施形態の場合、ＬＣＣは、サイクル（例えば、エンティティＡがエンティティＢへの保有リレーションシップを有し、エンティティＢがエンティティＡへの保有リレーションシップを有する場合）をチェックしてもよい。上記のチェックが完了した後、ステップ３０８で、ＬＣＣは、識別された論理的非一貫性(logical inconsistence)を解決する。

本発明のいくつかの実施形態では、ＬＣＣは、論理的エラーを解決するために、図４に示すような３本脚手法（three-prong approach）を利用する。まず、ステップ４０２で、ＬＣＣは、ページの最新のスナップショットとトランザクションログを用いてページレベルのリストア(inconsistence:復元)（ＰＬＲ）を実行することにより、エラーのあるページを完全にリストアしようと試みる。これに対して、ステップ４０４で、ＰＬＲが不可能であるか、またはエラーを訂正できない場合、ステップ４０６で、ＬＣＣは、まずどのエンティティが損傷したかを判定して、そのエンティティを（バックアップやｓｙｎｃ(同期)レプリカのような）別のソースからリストアすることにより、エンティティレベルのリストア（ＥＬＲ）を試みる。４０８で、ＰＬＲおよびＥＬＲが両方とも不可能であるか、またはエラーを訂正できない場合には、ステップ４１０で、ＬＣＣは、以下で説明するようにファイルシステムストアの一貫性のあるビューを保証するために、ストア内の損傷したエンティティをダミーエンティティ（ＤＥ）と置換する。

損傷エンティティをＤＥと置換することにより、ＬＣＣは、当該損傷エンティティの除去が当該損傷エンティティの子エンティティを破壊しないことを保証する。すなわち、ＬＣＣは、破壊されたエンティティからその子へと下位レベルへ破壊が連鎖することを防ぐ。これを達成するため、ＤＥは基本的に損傷エンティティを置換するが、損傷エンティティからの情報をできるだけ保持する。例えば、損傷エンティティがアイテムである場合、それを置換するＤＥは、プロパティデータをできるだけ保持するとともに、他のアイテムへのすべてのリレーションシップを保持する。これに対して、損傷エンティティがリレーションシップである場合、それを置換するＤＥは、そのリレーションシップが関係づけているアイテムを引き続き連結する。その一方で、損傷エンティティは破損アイテムフォルダ（ＢＩＦ）に移動（アイテムの場合）またはログ記録（リレーションシップの場合）される。損傷エンティティがアイテムである場合、ＢＩＦは損傷エンティティとのリレーションシップ（例えば保有リレーションシップ）を有する。

図５Ａおよび図５Ｂは、本発明のいくつかの実施形態について、アイテムに関する置換方法を示すブロック図である。図５Ａは、アイテムおよびリレーションシップのセットを示している。図５Ａにおいて、Ｉ１は親アイテムであり、Ｉ２はリレーションシップＲ１２を通じてＩ１の子アイテムであり、Ｉ３はリレーションシップＲ２３を通じてＩ２の子アイテムであり、Ｉ４およびＩ５はそれぞれリレーションシップＲ３４およびＲ３５を通じてＩ３の子アイテムである。この例において、アイテムＩ２が、例えばバグのあるアプリケーションによって破壊され、結果として、アイテムＩ２は現在、データモデル規則に違反している。図５Ｂにおいて、ＬＣＣは、Ｉ２を破壊されたアイテムとして識別すると、まずＤＥ Ｉ２’を作成し、ＤＥ Ｉ２’とその親Ｉ１との間の第１のリレーションシップＲ１２’、およびＤＥ Ｉ２’とその子Ｉ３との間の第２のリレーションシップＲ２３’を設定する。いくつかの実施形態では、ＤＥには、破壊されたアイテムと同じアイテム識別番号（ＩｔｅｍＩＤ）が与えられる。そして、破壊されたアイテムＩ２はＢＩＦに移動され、ＢＩＦアイテムと損傷アイテムＩ２の間に保有リレーションシップＲｈが設けられる。

いくつかの実施形態では、新たなリレーションシップＲ１２’およびＲ２３’は実際には、元のリレーションシップＲ１２およびＲ２３においてＩ２の代わりにＩ２’に関連づけられるように更新したものとしてもよい。他の実施形態では、Ｒ１２’およびＲ２３’は全く新しいリレーションシップであってもよく、そのようないくつかの実施形態では、Ｒ１２およびＲ２３は、ＢＩＦ内の損傷アイテムＩ２との懸垂（dangling:ぶらさげ）リレーションシップとして保持されてもよい。いずれにしても、ＤＥはデータセットに対する親子構造を実質的に保存し、それにより、さもなければＩ１から到達不可能となってしまうＩ３、Ｉ４、およびＩ５内のエラーとしてＩ２へのエラーが連鎖することを防ぐ。

図６Ａおよび図６Ｂは、本発明のいくつかの実施形態について、リレーションシップに関する置換方法を示すブロック図である。図６Ａは、アイテムおよびリレーションシップのセットの一部を示している。図６Ａにおいて、Ｉ１は親アイテムであり、Ｉ２はリレーションシップＲ１２を通じてＩ１の子アイテムである。この例では、リレーションシップＲ１２が、例えばウィルスによって破壊され、結果として、リレーションシップＲ１２が、データモデルにおける所定の許容範囲外のプロパティ値（例えばセキュリティプロパティ値）を有している。図６Ｂにおいて、ＬＣＣは、Ｒ１２を破壊されたリレーションシップとして識別すると、まずＩ２とその親Ｉ１との間にＤＥ Ｒ１２’を作成し、破壊されたリレーションシップＲ１２は削除され（そして、リレーションシップは単独ではＢＩＦ内に存在できないのでＢＩＦへは移動されない）、リレーションシップＲ１２を所有していたアイテムＩ１はＢＩＦにログ記録される（ＢＩＦはこの目的のための特別のログを有し、ここでは例えばログアイテムとして示されている）。

同期に関しては、破壊されたエンティティが他のエンティティとの間で誤って同期する（それにより破壊が広がる）ことを避けるため、本発明のいくつかの実施形態では、特別の「無権威（non authoritative）」フラグ（例えば１ビット）でＤＥをマークすることによって、識別されたおよび／または破損した、破壊を仕分けする。このフラグは実質的に、このエンティティの良好なコピーを有するｓｙｎｃレプリカに対して、このエンティティを上書きするように通知する（上書きされた時点で無権威ビットはクリアされる）。また、ＤＥがその後（例えばエンドユーザによって）修正された場合、いくつかの実施形態では、そのＤＥを「無権威・修正有り」とマークすることにより、修正されたＤＥとレプリカ上の元のアイテムの良好なコピーとの間でコンフリクト（不一致）解消手続きが確実に使用されるようにする。そして、コンフリクトが解消されればすぐに無権限・修正有りマークは除去される。

［その他の機能］
・本明細書で説明したように、アイテム拡張は、それを所有しているアイテム（所有アイテム）の一部とみなされるので、いかなる拡張破壊もアイテム破壊とみなされる。しかし、いくつかの代替実施形態では、拡張は、それらの所有アイテムとは別個独立に扱ってもよい。
・本発明のいくつかの実施形態では、ＬＣＣは、物理的破壊を訂正するために実行されたリストア動作の後にエンティティに対して実行される。
・いくつかの実施形態では、ＬＣＣは、アイテムに依存するリレーションシップが訂正される前にそのアイテムが訂正されない場合に起こり得る「実体のない（phantom）」破壊の検出を避けるために、破壊されたリレーションシップを訂正しようとする前に、まず破壊されたアイテムを修復しようと試みる。
・いくつかの実施形態では、ＢＩＦは、それがＤＢＦＳにまだ存在しない場合にＬＣＣによって作成され得るフォルダアイテムである。このフォルダは、ＤＢＦＳ内のいかなるタイプのアイテムも保有でき（ただし、いくつかの実施形態では、リレーションシップを保有することはできない）、フォルダは、（アクセスおよび検索を容易にするために）デフォルトデータベースストアのルートから離れて配置され得る。
・いくつかの実施形態では、バッキングファイルのないアイテムはＢＩＦに入れられ、対応するアイテムのないファイルもＢＩＦに入れられる。
・いくつかの実施形態では、損傷アイテムがＢＩＦに移動されると、ＢＩＦは、その損傷アイテムがＢＩＦに移動された理由に関する情報も記憶する。

［結論］
本明細書に記載の種々のシステム、方法、および技法は、ハードウェアまたはソフトウェアを用いて、あるいは適当であればその両方の組合せを用いて実施できる。したがって、本発明の方法および装置、またはそのいくつかの態様もしくは部分は、フロッピー（登録商標）ディスク、ＣＤ−ＲＯＭ、ハードドライブ、または任意の他のマシン可読記憶媒体のような有形媒体内に具現化されたプログラムコード（すなわち命令）の形態を取り得る。その場合、プログラムコードは、コンピュータ等のマシンにロードされて実行され、そのマシンが本発明を実施する装置となる。プログラム可能コンピュータ上でのプログラムコード実行の場合、コンピュータは一般に、プロセッサ、プロセッサによって読み出し可能な記憶媒体（揮発性および不揮発性のメモリおよび／または記憶素子を含む）、少なくとも１つの入力装置、および少なくとも１つの出力装置を含む。好ましくは、１つまたは複数のプログラムが、コンピュータシステムと通信するための高水準の手続き型またはオブジェクト指向プログラミング言語で実装される。しかし、プログラム（複数可）は、必要であれば、アセンブリ言語または機械語で実装されてもよい。いずれの場合でも、言語は、コンパイラでコンパイルされる言語またはインタープリタで解釈される言語であってよく、ハードウェア実装と組み合わされてもよい。

本発明の方法および装置は、電気配線、ケーブル、光ファイバ、または任意の他の伝送形態のような何らかの伝送媒体を通じて伝送されるプログラムコードの形態で実施してもよい。この場合、プログラムコードがＥＰＲＯＭ、ゲートアレイ、プログラマブルロジックデバイス（ＰＬＤ）、クライアントコンピュータ、ビデオレコーダ等のマシンによって受信され、ロードされて実行される時に、そのマシンが本発明を実施する装置となる。汎用プロセッサ上で実施される場合、プログラムコードは、本発明のインデクシング機能を実行するように動作する固有の装置を提供するためのプロセッサと組み合わされる。

以上、本発明を種々の図面の好ましい実施形態との関連で説明したが、他の類似の実施形態も使用可能であり、本発明から逸脱することなく本発明と同じ機能を実行するために、説明した実施形態に対して変更および追加をなし得ると理解すべきである。例えば、本発明の例示的実施形態は、パーソナルコンピュータの機能をエミュレートするディジタル装置との関連で説明されているが、当業者には認識されるように、本発明はそのようなディジタル装置に限定されず、本明細書に記載されているように、ゲームコンソール、ハンドヘルドコンピュータ、ポータブルコンピュータ等、有線または無線のいずれかを問わず、現在または将来のさまざまなコンピューティング装置または環境に適用可能であり、また、通信ネットワーク経由で接続されネットワーク越しに相互作用する任意個数のそのようなコンピューティング装置にも適用可能である。さらに、強調しておくが、特に無線ネットワーク接続された装置がますます普及するにつれて、ハンドヘルド装置用オペレーティングシステムやその他の特定用途向けハードウェア／ソフトウェアインタフェースシステム等のさまざまなコンピュータプラットフォームが本発明において考えられる。したがって、本発明は、いかなる単一の実施形態にも限定されず、特許請求の範囲による広がりと範囲において解釈されなければならない。

本発明の諸態様を組み込み得るコンピュータシステムを表すブロック図である。 本発明のいくつかの実施形態を表すデータベースファイルシステム（ＤＢＦＳ）内のデータ信頼性システム（ＤＲＳ）の構成を示すブロック図である。 本発明のいくつかの実施形態について、論理的に破壊されたエンティティを確認するための手法を示すプロセス流れ図である。 本発明のいくつかの実施形態について、エンティティにおける論理的エラーを解決するＬＣＣのための３本脚手法を示すプロセス流れ図である。 本発明のいくつかの実施形態について、アイテムエンティティに関する置換方法を示すブロック図である。 本発明のいくつかの実施形態について、アイテムエンティティに関する置換方法を示すブロック図である。 本発明のいくつかの実施形態について、リレーションシップエンティティに関する置換方法を示すブロック図である。 本発明のいくつかの実施形態について、リレーションシップエンティティに関する置換方法を示すブロック図である。

符号の説明

２０ パーソナルコンピュータ
２１ 処理ユニット
２２ システムメモリ
２３ システムバス
２４ 読み出し専用メモリ（ＲＯＭ）
２５ ランダムアクセスメモリ（ＲＡＭ）
２６ 基本入出力システム（ＢＩＯＳ）
２７ ハードディスクドライブ
２８ 磁気ディスクドライブ
２９ リムーバブル磁気ディスク
３０ 光ディスクドライブ
３１ リムーバブル光ディスク
３２ ハードディスクドライブインタフェース
３３ 磁気ディスクドライブインタフェース
３４ 光ドライブインタフェース
３５ オペレーティングシステム
３６ アプリケーションプログラム
３７ 他のプログラムモジュール
３８ プログラムデータ
４０ キーボード
４２ ポインティングデバイス
４６ シリアルポートインタフェース
４７ モニタ
４８ ビデオアダプタ
４９ リモートコンピュータ
５０ メモリ記憶装置
５１ ローカルエリアネットワーク（ＬＡＮ）
５２ 広域ネットワーク（ＷＡＮ）
５３ ネットワークインタフェース（アダプタ）
５４ モデム
５５ ホストアダプタ
５６ ＳＣＳＩバス
６２ 外部記憶装置
２０２ オペレーティングシステム
２１２，２１４，２１６ アプリケーション
２２２ データベースファイルシステム（ＤＢＦＳ）
２３２ 永続的データストア
２３４，２３６，２３８ ページ
２４０ ページエラー
２４２ データ信頼性システム（ＤＲＳ）

Claims (40)

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. エンティティレベルで論理的非一貫性を解決するための、データベースファイルシステム（ＤＢＦＳ）用の論理的一貫性チェッカ（ＬＣＣ）のためのコンピュータ可読命令を備えたコンピュータ可読媒体において、該コンピュータ可読命令が、
    少なくとも１つの論理的非一貫性について前記ＤＢＦＳに対応するデータベース内のテーブルのセットの参照整合性をチェックする命令と、
    少なくとも１つの論理的非一貫性について前記ＤＢＦＳにおいて表現されるエンティティのセットの構造整合性をチェックする命令と
    を含むことを特徴とするコンピュータ可読媒体。
28. 論理的非一貫性を構成する少なくとも１つのサイクルをチェックする命令をさらに含むことを特徴とする請求項２７に記載のコンピュータ可読命令。
29. 少なくとも１つの論理的非一貫性を解決する命令をさらに含むことを特徴とする請求項２７に記載のコンピュータ可読命令。
30. 前記少なくとも１つの論理的非一貫性を解決する要素が、以下の解決法のグループ、すなわちページレベルのリストア、エンティティレベルのリストア、および損傷エンティティをダミーエンティティと置換すること、のうちの少なくとも１つの解決法を試みることを含むための命令をさらに含むことを特徴とする請求項２９に記載のコンピュータ可読命令。
31. 前記少なくとも１つの論理的非一貫性を解決する要素が、
    ページレベルのリストアを試み、
    ページレベルのリストアの前記試みが成功しない場合、エンティティレベルのリストアを試み、
    エンティティレベルのリストアの前記試みが成功しない場合、前記少なくとも１つの論理的非一貫性に対応する少なくとも１つの損傷エンティティをダミーエンティティと置換する
    ことを含むための命令をさらに含むことを特徴とする請求項３０に記載のコンピュータ可読命令。
32. 前記エンティティがアイテムである場合、損傷エンティティをダミーエンティティと置換する前記解決法が、
    前記ダミーエンティティを作成し、前記損傷エンティティに属する少なくとも１つのリレーションシップを該ダミーエンティティに出力先を変更し、
    前記損傷エンティティを破損アイテムフォルダに移動する
    ことをさらに含むための命令をさらに含むことを特徴とする請求項３０に記載のコンピュータ可読命令。
33. 前記エンティティがリレーションシップである場合、損傷エンティティをダミーエンティティと置換する前記解決法が、
    前記損傷エンティティのリレーションシップに対応するリレーションシップとして前記ダミーエンティティを作成し、
    前記損傷エンティティを破損アイテムフォルダにログ記録する
    ことを含むための命令をさらに含むことを特徴とする請求項３０に記載のコンピュータ可読命令。
34. エンティティレベルで論理的非一貫性を解決するための、データベースファイルシステム（ＤＢＦＳ）用の自動化されたデータ信頼性システム（ＤＲＳ）のためのコンピュータ可読命令を備えたコンピュータ可読媒体において、該コンピュータ可読命令が、
    データベース管理（ＤＢＡ）タスクを実行するためにポリシーのセットを利用する命令と、
    ページレベルで物理的データ破壊のセットを解決する命令と、
    エンティティレベルで論理的データ破壊のセットを解決する命令と
    を含むことを特徴とするコンピュータ可読媒体。
35. 前記ＤＢＦＳがアイテムベースのハードウェア／ソフトウェアインタフェースシステムのコンポーネントであるための命令をさらに含むことを特徴とする請求項３４に記載のコンピュータ可読命令。
36. 以下の機能のグループ、すなわちエラーおよびイベントの通知、ポリシー、ならびにエラー／イベント処理アルゴリズム、のうちの少なくとも１つの機能を追加、削除、および修正するためのインタフェースのための命令をさらに含むことを特徴とする請求項３４に記載のコンピュータ可読命令。
37. 前記ＤＲＳがバックグラウンドスレッドとして動作するための命令をさらに含むことを特徴とする請求項３４に記載のコンピュータ可読命令。
38. ページレベルで物理的データ破壊のセットを解決する前記サブシステムの実行後に、エンティティレベルで論理的データ破壊のセットを解決する前記要素が実行されるための命令をさらに含むことを特徴とする請求項３４に記載のコンピュータ可読命令。
39. エンティティレベルで論理的データ破壊のセットを解決する前記要素が、破壊されたアイテムに対応する破壊されたリレーションシップを訂正しようと試みる前に、該破壊されたアイテムを修復しようと試みることをさらに含むための命令をさらに含むことを特徴とする請求項３４に記載のコンピュータ可読命令。
40. エンティティレベルで論理的非一貫性を解決するための、データベースファイルシステム（ＤＢＦＳ）用の自動化されたデータ信頼性システム（ＤＲＳ）のためのハードウェア制御装置において、
    データベース管理（ＤＢＡ）タスクを実行するためにポリシーのセットを利用する手段と、
    ページレベルで物理的データ破壊のセットを解決する手段と、
    少なくとも１つの論理的非一貫性について前記ＤＢＦＳに対応するデータベース内のテーブルのセットの参照整合性をチェックし、
    少なくとも１つの論理的非一貫性について前記ＤＢＦＳにおいて表現されるエンティティのセットの構造整合性をチェックする
    ことによりエンティティレベルで論理的データ破壊のセットを解決する手段と
    を備えたことを特徴とするハードウェア制御装置。
    

Images