JP5259388B2

JP5259388B2 - データベースとファイルシステムとの間でのリンクレベル整合性の維持

Info

Publication number: JP5259388B2
Application number: JP2008509997A
Authority: JP
Inventors: セスラマンバラン; ヤンカンロン; ビー．ラジャンラジーブ
Original assignee: Microsoft Corp
Current assignee: Microsoft Corp
Priority date: 2005-05-06
Filing date: 2006-03-09
Publication date: 2013-08-07
Anticipated expiration: 2026-03-09
Also published as: EP1877906B1; US20060253502A1; KR20080005501A; JP2008541225A; EP1877906A2; KR101255392B1; EP1877906A4; CN101460930B; WO2006121500A2; US8145686B2; WO2006121500A3; CN101460930A

Description

本発明は、一般に、データベース管理の分野に関する。より具体的に言えば、本発明は、データベースと対応するファイルシステムとの間でのリンクレベル整合性の維持に関する。

近年、写真、ビデオ、およびムービーなどの、大規模な非構造化データタイプの使用が著しく増加してきており、それに伴って、これらの大規模なデータストリームを効率良く格納する必要がある。従来、データは、ファイルシステムなどの構造体またはデータベースに格納されてきた。

ファイルシステムとは、ハードディスクなどの記憶媒体上でファイルがフォルダ内に格納される、データの階層構造のことである。一部のオペレーションシステムは、ファイルシステムを維持し、ファイルシステム内のファイルへのアクセスを制御する。ファイルシステムは、大量の非構造化データをファイルの内外へストリーミングするには優れている。現在知られているファイルシステムに伴う問題の１つが、ファイルを手動でグループ（フォルダおよびサブフォルダ）化しなければならないことであり、ユーザが特定のファイルを格納した場所を忘れてしまった場合、ファイルを再度見つけ出すことは困難であろう。この問題は、ますます大規模化されるハードディスクの開発に見られるディスク技術の躍進などの、技術の促進によって悪化する。単一のディスク上に莫大な量のデータが格納できることによって、ファイルシステム内でのファイルの追跡を極端に困難なタスクにしてしまう可能性がある。

幅広く使用されている他のデータ編成方法が、データベースである。データベースシステムは、データを、テーブルの各行がエンティティに関する関連データ要素のグループと、行の主題であるエンティティに関する有用な情報部片を表す列とを有する、１つまたは複数のテーブルとして格納する。たとえば、人材データベースの各行が従業員を表し、人材データベースの各列が、従業員の名前、従業員の社会保障番号、および従業員の賃金率などのデータ要素を表す、人材情報のデータベースを維持することができる。

データベースは、データのファイルシステム編成を介していくつかの有用な利点を提供する。データベース管理システムは、構造化データの小規模な部片の格納、発見、および取り出しに優れている。さらに典型的には、データベースに格納されたデータの指定部分を検索し、これにアクセスする、高度にフレキシブルな手段がある。しかしながら、データベースは、ＢＬＯＢ（Binary Large Object：バイナリラージオブジェクト）と呼ばれる、非構造化データの大規模な部片の格納およびアクセスに、特に適切には対処していない。

具体的に言えば、データベースがＢＬＯＢ列を含む場合、典型的には、ＢＬＯＢはディスク全体にわたって分散された小規模な部片にばらばらにされる。データベース列内のエントリは、ＢＬＯＢそれ自体を含むのではなく、ＢＬＯＢの第１の部片を指すポインタを含む。この状況は、ＢＬＯＢの異なる部片を発見し、再アセンブルしなければならないため、ＢＬＯＢ内のデータを取り出す際の非効率性につながる。典型的には、これらの非効率性の影響を減らすために、ＢＬＯＢの第１の部片を指すポインタは、ＢＬＯＢそれ自体を即時に取り出す代わりに、戻される（return）ことになる。

たとえば、従業員情報のデータベースが、従業員写真に関するＢＬＯＢ列を含むと想定する。ユーザが特定の従業員の写真を要求し、その写真へのポインタを戻されるとする。このポインタは物理位置、たとえば、写真の第１の部片が格納されている、ディスクのセクタの実際のディスクアドレスを表す１６バイトの１６進値を表す。この状況では、いくつかの問題が生じる可能性がある。ディスクアドレスがユーザにとってわかりにくいことに加えて、オペレーティングシステムがディスク上のデータを再編成した場合、この写真はもはやその場所に存在しない可能性があり、このケースでは「ｎｏｔｆｏｕｎｄ（見つかりません）」というメッセージがユーザに戻されることになる。

近年、ＢＬＯＢを格納する別の方法が開発されてきており、この方法ではＢＬＯＢが連続ファイルまたは「ＦＩＬＥＳＴＲＥＡＭ」としてファイルシステムに格納される。関係テーブル内の列にタグを付ける際に使用可能な、ＦＩＬＥＳＴＲＥＡＭデータストレージ属性が提供される。ＦＩＬＥＳＴＲＥＡＭ属性は、その列に関するデータが、オペレーティングシステム（ＯＳ）のファイルシステム内にファイルとして格納されることになることを示す。データベース管理システムは、ファイルシステム内のファイルの作成および削除を管理する。ファイルシステム内のファイルとセル（行と列との交差部分）との間には、１：１の基準（reference）がある。ＦＩＬＥＳＴＲＥＡＭ列内のデータは、ＳＱＬまたはＭＩＣＲＯＳＯＦＴ（登録商標）のＴ−ＳＱＬなどのプログラミング言語を使用する他の列内のデータと同じ方法で操作することができる。

米国特許出願公開第２００４／１４８３０８号明細書米国特許出願公開第２００４／１４８２７２号明細書

したがって、ＦＩＬＥＳＴＲＥＡＭ列は、大規模な非構造化データに関するデータベースで使用される。ＦＩＬＥＳＴＲＥＡＭデータストレージ属性の使用によって、引き続きデータベースへのアクセスを可能としながら、大規模な非構造化データを連続するファイルとしてファイルシステムに格納することができる。こうしたデータベース管理システムは、データのインテグリティを保証するため、およびデータベースの破損を避けるために、ＦＩＬＥＳＴＲＥＡＭ属性を有するデータベースの行とその対応するＦＩＬＥＳＴＲＥＡＭデータとの間の、リンクの整合性（すなわち「リンクレベル整合性」）を維持する必要がある。たとえば、ディスクに変更がコミットされる時点より以前に、電力障害またはシステムクラッシュなどの障害が発生した場合（すなわちフラッシュ）、結果としていくつかの問題が生じる可能性がある。たとえば、データベースが、ファイルシステム内に存在するファイルまたはディレクトリの存在を反映しないか、あるいはデータベースが、ファイルシステム内に存在しないファイルまたはディレクトリの存在を反映する可能性がある。このようにして、データベースとファイルとの間のリンクが破損すると、データベースユーザは、データベースが、データベース列内のＦＩＬＥＳＴＲＥＡＭセルによって表される現在のデータの状態を正確に反映するものであることが保証されないため、データベースのインテグリティが損なわれる。

通常、リンクレベル整合性の維持は、整合性のチェックおよび修復、ならびにロギング（Logging）およびリカバリという、２つの異なる手法によって達成されてきた。整合性のチェックおよび修復では、クローリング（巡回：crawling）タスクが非整合性をチェックするためにデータベースおよびファイルシステムを検索し、潜在的にはこれらを修復する。こうした手法は時間がかかり、目標が定まらず、システムリソースを過度に消費する。

従来のロギング方法およびリカバリ方法は、データベースログ内でロギングを使用するか、またはトランザクテッドファイルシステム（Transacted File System）を利用して調整することができる。前者の方法では、ファイルシステムオペレーションが、データベースのデータ更新と共にデータベースログ内でロギングされる。こうした手法では、データベース管理システムがデータベースをリカバリした場合、ロギング済みのファイルシステムオペレーションに関して、ならびに、ファイルシステムデータを同じデータベースリカバリフレームワーク内のデータベースデータと整合させるために、やり直し（ＲＥＤＯ）および取り消し（ＵＮＤＯ）オペレーションをトリガすることができる。こうした手法の欠点は、データベース管理システムが通常はファイルシステムと緊密に統合されていないため、ファイルシステムのディスクに対するデータフラッシュの知識（ナレッジ）がないことである。データフラッシュを調整する機能がないため、データベース管理システムは、クラッシュリカバリ時にトランザクションのリンクレベル整合性を維持するために役立つ、適切な先書きロギング（Write-Ahead-Logging）を達成するために、ファイルシステムオペレーションごとに、ログにログ記録（log record）をフラッシュさせなければならない。このようにログにフラッシュさせることで、結果として、１つのファイルシステムオペレーションにつき１つのディスクＩ／Ｏオペレーションが発生し、これは通常、許容できない量の性能オーバヘッドである。

後者の方法は、トランザクテッドファイルシステムを利用した調整を含み、ここではファイルシステム自体がトランザクションであり、リカバリが可能である。データベース管理システムは、優れたトランザクションマネージャ（「ＴＭ」）によって調整される分散トランザクションに関与する。クラッシュリカバリ時に、優れたＴＭは、疑わしいトランザクションを解決し、データベースとファイルシステムリソースマネージャとの間の整合性を確実にする。この手法の短所は、トランザクテッドファイルシステムが市販のオペレーティングシステムでは使用できないことである。したがって、多くのＯＳプラットフォーム上の多くのデータベース管理システムには、この手法は使用不可能である。加えて、この方法には、実装する際に複雑さおよび性能コストが加えられるという短所がある。

したがって、前述の短所に対処しながら、データベース列とファイルシステム内のそれらの対応するＦＩＬＥＳＴＲＥＡＭデータとの間のリンクレベル整合性を維持するメカニズムが求められている。

前述の短所および欠点に鑑み、本明細書では、データベースとファイルシステムとの間でトランザクションのリンクレベル整合性を維持するための方法およびコンピュータ読み取り可能媒体が開示される。一方法では、ファイルシステムの変更がデータベースログの記録にロギングされ、このファイルシステムの変更に対応するファイルが、ファイルシステムフォルダ内に作成される。リカバリプロセス再始動時に、データベースログに基づいて分析オペレーションおよび条件付きやり直しオペレーションが実行され、ファイルシステムフォルダ内のファイルに基づいて条件付きやり直しオペレーションおよび取り消しオペレーションが実行される。その後、データベースログに基づいて取り消しオペレーションが実行される。

本発明の主題について、法的要件を満たすための特定性と共に説明する。しかしながら、この説明それ自体は、本件特許の範囲を限定することを意図するものではない。むしろ本発明者等は、特許請求の範囲に記載された主題が、他の現在または将来の技術と共に、本明細書に記載されたものと同様の様々なステップまたは要素を含むように、他の方法でも具体化可能であることを企図してきた。さらに本明細書では、「ステップ」という用語は、採用される方法の様々な態様を示唆するために使用可能であるが、この用語は、個々のステップの順序が明示的に記載されていない限り、および記載されている場合を除き、本明細書に開示された様々なステップ中、またはステップ間の、任意の特定の順序を示唆するものと解釈すべきではない。

コンピューティング環境の例
図１は、本発明が実施可能な好適なコンピューティングシステム環境１００の一例を示す。コンピューティングシステム環境１００は、好適なコンピューティング環境の単なる一例であり、本発明の用途または機能性の範囲に関して、いかなる制限も示唆することは意図していない。さらに、コンピューティング環境１００は、オペレーティング環境１００の例に示された構成要素のうちのいずれか１つまたはそれらの組み合わせに関する、任意の依存性または要件を有するものと解釈されるべきでもない。

本発明は、多数の他の汎用または特定用途向けコンピューティングシステムの環境または構成において、動作可能である。本発明で使用するのに好適な、良く知られたコンピューティングシステム、環境、および／または構成の例には、パーソナルコンピュータ、サーバコンピュータ、ハンドヘルドまたはラップトップデバイス、マルチプロセッサシステム、マイクロプロセッサベースシステム、セットトップボックス、プログラム可能家庭用電化製品、ネットワークＰＣ、ミニコンピュータ、メインフレームコンピュータ、前述のシステムまたはデバイスのいずれかを含む分散コンピューティング環境、その他が含まれるが、これらに限定されるものではない。

本発明については、コンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な背景事情（context）の中で説明することが可能である。一般に、プログラムモジュールは、特定のタスクを実行するか、または特定の抽象データ型を実施する、ルーチン、プログラム、オブジェクト、コンポーネント、データ構造などを含む。典型的には、プログラムモジュールの機能は、様々な実施形態で望ましいように組み合わせまたは分散することができる。本発明は、通信ネットワークを介してリンクされたリモート処理デバイスによってタスクが実行される、分散コンピューティング環境でも実施可能である。分散コンピューティング環境では、プログラムモジュールは、メモリ記憶デバイスを含むローカルとリモートの両方のコンピュータ記憶媒体に配置することができる。

図１を参照すると、本発明を実施するためのシステムの例には、コンピュータ１１０の形の汎用コンピューティングデバイスが含まれる。コンピュータ１１０の構成要素は、処理ユニット１２０、システムメモリ１３０、および、システムメモリを含む様々なシステム構成要素を処理ユニット１２０に結合するシステムバス１２１を含むことができるが、それらに限定されるものではない。システムバス１２１は、メモリバスまたはメモリコントローラ、周辺バス、および様々なバスアーキテクチャのうちのいずれかを使用するローカルバスを含む、いくつかのタイプのバス構造のうちのいずれかとすることができる。例を挙げると、こうしたアーキテクチャは、業界標準アーキテクチャ（ＩＳＡ：Industry Standard Architecture）バス、マイクロ・チャネル・アーキテクチャ（ＭＣＡ：Micro Channel Architecture）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ＶＥＳＡ（Video Electronics Standards Association）ローカルバス、およびメザニンバスとしても知られるＰＣＩ（Peripheral Component Interconnect）バスを含むが、これらに限定されるものではない。

コンピュータ１１０は、通常、様々なコンピュータ読み取り可能媒体を含む。コンピュータ読み取り可能媒体は、コンピュータ１１０がアクセス可能であり、揮発性および不揮発性媒体、取り外し可能および取り外し不能媒体の、両方を含む、任意の使用可能媒体とすることができる。例を挙げると、コンピュータ読み取り可能媒体は、コンピュータ記憶媒体および通信媒体を含むことができるが、これらに限定されるものではない。コンピュータ記憶媒体は、コンピュータ読み取り可能命令、データ構造、プログラムモジュール、または他のデータなどの情報を記憶するための、任意の方法または技術で実施される、揮発性および不揮発性媒体、取り外し可能および取り外し不能媒体の、両方を含む。コンピュータ記憶媒体は、ＲＡＭ、ＲＯＭ、ＥＥＰＲＯＭ、フラッシュメモリまたは他のメモリ技術、ＣＤ−ＲＯＭ、デジタル多用途ディスク（ＤＶＤ）または他の光ディスクストレージ、磁気カセット、磁気テープ、磁気ディスクストレージ、または他の磁気記憶デバイス、あるいは、所望の情報を格納するために使用可能であり、コンピュータ１１０がアクセス可能な、任意の他の媒体を含むが、これらに限定されるものではない。通信媒体は、通常、搬送波または他の移送メカニズムなどの変調データ信号内で、コンピュータ読み取り可能命令、データ構造、プログラムモジュール、または他のデータを具体化し、任意の情報配信媒体を含む。「変調データ信号」という用語は、信号内の情報を符号化するような方法で設定または変更されたその特徴のうちの１つまたは複数を有する信号を意味する。例を挙げると、通信媒体は、有線ネットワークまたは直接有線接続などの有線媒体、ならびに音響、ＲＦ、赤外線、および他の無線媒体などの無線媒体を含むが、これらに限定されるものではない。前述のいずれかの組み合わせも、コンピュータ読み取り可能媒体の範囲に含まれるものとする。

システムメモリ１３０は、読み取り専用メモリ（ＲＯＭ）１３１およびランダムアクセスメモリ（ＲＡＭ）１３２などの、揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を含む。始動時などに、コンピュータ１１０内の要素間で情報を転送するのに役立つ基本ルーチンを含む、基本入力／出力システム１３３（ＢＩＯＳ）は、通常ＲＯＭ１３１に格納される。ＲＡＭ１３２は、通常、処理ユニット１２０によって、即時アクセス可能および／または現在動作中の、データおよび／またはプログラムモジュールを含む。例を挙げると、図１は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７を示す。

コンピュータ１１０は、他の取り外し可能／取り外し不能、揮発性／不揮発性のコンピュータ記憶媒体も含むことができる。単なる例を挙げると、図１は、取り外し不能の不揮発性磁気媒体に対して読み取りまたは書き込みをするハードディスクドライブ１４１と、取り外し可能の不揮発性磁気ディスク１５２に対して読み取りまたは書き込みをする磁気ディスクドライブ１５１と、ＣＤ−ＲＯＭまたは他の光媒体などの取り外し可能の不揮発性光ディスク１５６に対して読み取りまたは書き込みをする光ディスクドライブ１５５とを示す。オペレーティング環境例において使用可能な他の取り外し可能／取り外し不能、揮発性／不揮発性コンピュータ記憶媒体は、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、ソリッドステートＲＡＭ、ソリッドステートＲＯＭ、などを含むが、これらに限定されるものではない。ハードディスクドライブ１４１は、通常、インターフェース１４０などの取り外し不能メモリインターフェースを介してシステムバス１２１に接続され、磁気ディスクドライブ１５１および光ディスクドライブ１５５は、通常、インターフェース１５０などの取り外し可能メモリインターフェースによって、システムバス１２１に接続される。

前述の、および図１に示された、ドライブおよびそれらの関連付けられたコンピュータ記憶媒体は、コンピュータ読み取り可能命令、データ構造、プログラムモジュール、およびコンピュータ１１０に関する他のデータのストレージを提供する。たとえば図１では、ハードディスクドライブ１４１はオペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７を格納するものとして示される。これらの構成要素は、オペレーティングシステム１３４、アプリケーションプログラム１３５、他のプログラムモジュール１３６、およびプログラムデータ１３７と同じであるか、またはこれらとは異なる可能性があることに留意されたい。オペレーティングシステム１４４、アプリケーションプログラム１４５、他のプログラムモジュール１４６、およびプログラムデータ１４７には、少なくとも異なるコピーであることを示すために、ここでは異なる番号が与えられる。ユーザは、キーボード１６２、および、一般にマウス、トラックボール、またはタッチパッドと呼ばれるポインティングデバイス１６１などの入力デバイスを介して、コマンドおよび情報をコンピュータ１１０に入力することができる。他の入力デバイス（図示せず）には、マイクロフォン、ジョイスティック、ゲームパッド、衛星放送用パラボラアンテナ、スキャナなどが含まれる場合がある。これらおよび他の入力デバイスは、しばしば、システムバスに結合されたユーザ入力インターフェース１６０を介して処理ユニット１２０に接続されるが、パラレルポート、ゲームポート、またはユニバーサルシリアルバス（ＵＳＢ）などの、他のインターフェースおよびバス構造によって接続することも可能である。モニタ１９１または他のタイプのディスプレイデバイスも、ビデオインターフェース１９０などのインターフェースを介してシステムバス１２１に接続される。コンピュータは、モニタに加えて、出力周辺インターフェース１９５を介して接続可能な、スピーカ１９７およびプリンタ１９６などの他の周辺出力デバイスも含むことができる。

コンピュータ１１０は、リモートコンピュータ１８０などの１つまたは複数のリモートコンピュータへの論理接続を使用するネットワーク化環境において動作可能である。リモートコンピュータ１８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピアデバイス、または他の共通ネットワークノードとすることが可能であり、図１ではメモリ記憶デバイス１８１のみが示されているが、通常は、コンピュータ１１０に関して前述した要素の多くまたはすべてを含む。図１に示された論理接続は、ローカルエリアネットワーク（ＬＡＮ）１７１およびワイドエリアネットワーク（ＷＡＮ）１７３を含むが、他のネットワークも含むことができる。こうしたネットワーキング環境は、オフィス、企業規模コンピュータネットワーク、イントラネット、およびインターネットでよく見られる。

ＬＡＮネットワーキング環境において使用される場合、コンピュータ１１０は、ネットワークインターフェースまたはアダプタ１７０を介してＬＡＮ１７１に接続される。ＷＡＮネットワーキング環境において使用される場合、コンピュータ１１０は、通常、インターネットなどのＷＡＮ１７３を介した通信を確立するためのモデム１７２または他の手段を含む。内蔵型または外付けとすることが可能なモデム１７２は、ユーザ入力インターフェース１６０または他の適切なメカニズムを介してシステムバス１２１に接続することができる。ネットワーク化環境では、コンピュータ１１０に関して示されたプログラムモジュールまたはその一部を、リモートメモリ記憶デバイスに格納することができる。例を挙げると、図１は、メモリデバイス１８１上に常駐するものとしてリモートアプリケーションプログラム１８５を示すが、これに限定されるものではない。図示されたネットワーク接続は例示的なものであり、コンピュータ間の通信リンクを確立する他の手段が使用可能であることを理解されよう。

分散コンピューティングフレームワークまたはアーキテクチャの例
パーソナルコンピューティングおよびインターネットの集中に鑑みて、様々な分散コンピューティングフレームワークがこれまでに開発され、さらに現在開発中である。個人およびビジネスユーザには同様に、コンピューティング活動をますますウェブブラウザまたはネットワーク指向にする、アプリケーションおよびコンピューティングデバイス用のシームレスに相互運用可能なウェブ実行可能インターフェースが提供される。

たとえば、ＭＩＣＲＯＳＯＦＴ（登録商標）の．ＮＥＴプラットフォームは、サーバ、ウェブベースのデータストレージなどのビルディングブロックサービス、およびダウンロード可能なデバイスソフトウェアを含む。概して言えば、．ＮＥＴプラットフォームは、（１）コンピューティングデバイスの全範囲を協働させるため、ならびにそれらにおいてユーザ情報を自動的に更新および同期化させるための機能、（２）ＨＴＭＬではなくＸＭＬをより多く使用することによって実行可能な、ウェブサイトに関する対話機能の増加、（３）たとえば電子メールなどの様々なアプリケーションまたはＯｆｆｉｃｅ．ＮＥＴなどのソフトウェアの管理のための、中央の起点からユーザへの製品およびサービスのカスタマイズされたアクセスおよびデリバリーを特徴とするオンラインサービス、（４）情報へのアクセスの効率および容易さを向上させることになる、集中データストレージ、ならびにユーザおよびデバイス間での情報の同期化、（５）電子メール、ファックス、および電話などの様々な通信媒体を統合するための機能、（６）それによって生産性が向上し、プログラミングエラーの数を減少させる、開発者にとっての再使用可能モジュールを作成するための機能、ならびに、（７）多くの他のクロスプラットフォーム統合機能、を提供する。

本明細書では、諸実施形態の例について、コンピューティングデバイス上に常駐するソフトウェアに関連して説明するが、本発明の１つまたは複数の部分は、サービスがすべての．ＮＥＴの言語およびサービスによって実行され、これらにおいてサポートされ、またはこれらを介してアクセスされるように、オペレーティングシステム、ＡＰＩ、またはコプロセッサと要求オブジェクトとの間のミドルウェアソフトウェアを介して、さらに他の分散コンピューティングフレームワークにおいても同様に、実施することもできる。

データベース環境
以下の考察では、当業者が、データベースに関連したＦＩＬＥＳＴＲＥＡＭデータストレージ属性の実施に精通していると想定される。こうした状況は、参照によりそれら全体が本明細書に組み込まれた米国特許出願（特許文献１および特許文献２）で論じられている。したがって本明細書では、わかりやすくするために、こうした状況の詳細は省略される。

しかしながら、追加の背景情報を提供して、以下の諸実施形態の考察を本明細書に入れるため、図２は、本発明の諸態様が実施可能なデータベース構成の例を示す。次に図２を参照すると、（１）関連情報の位置を特定し、操作するために、データベース２１０に対するクエリの開始元であるクライアントマシン２８０、（２）データベース２１０をホストするデータベースサーバ２００、および（３）所与のデータベース２１０に関連付けられたＦＩＬＥＳＴＲＥＡＭ値（またはファイル）を格納することが可能なファイルシステムボリューム２２５を管理し、データベース２１０に対する帯域外更新をサポートする、ＦＩＬＥＳＴＲＥＡＭサーバ２４０の、３つの異なる役割を果たすための３つのマシンが実施可能である。ＦＩＬＥＳＴＲＥＡＭファイルが、データベース列に格納されているＢＬＯＢに対応可能であることを理解されよう。各データベースは、１つまたは複数のＦＩＬＥＳＴＲＥＡＭグループ２１５を有することが可能であり、各ＦＩＬＥＳＴＲＥＡＭグループ２１５は１つまたは複数のボリューム２２５を含むことが可能である。このボリュームは、ＦＩＬＥＳＴＲＥＡＭサーバ２４０上に常駐可能である。データベースインストールの例では、何千ものクライアントマシン、何十ものＦＩＬＥＳＴＲＥＡＭサーバ、および１つのデータベースサーバが存在可能である。ＦＩＬＥＳＴＲＥＡＭデータが格納されたボリュームがデータベースと一緒に置かれた場合、特殊な構成が生じる。

ＦＩＬＥＳＴＲＥＡＭ値を含むすべてのファイルシステムボリューム２２５に関連付けられた識別子（たとえばＧＵＩＤ）が、クライアントマシン２８０がＦＩＬＥＳＴＲＥＡＭサーバ２４０とのネットワーク接続を確立することを可能にするロケータサービスに登録されることによって、登録メカニズムを提供することが可能である。さらに、データベースサーバ２００は、それらによってホストされるデータベース２１０の識別子（たとえばＧＵＩＤ）を登録する。こうしたロケータサービスの可能な実施の１つが、ボリュームＧＵＩＤおよびデータベースＧＵＩＤをＩＰアドレスにマッピングすることができる、ＤＮＳ（Domain Name System）サービスである。

ＳＱＬデータベースサーバ２００とＦＩＬＥＳＴＲＥＡＭサーバ２４０との間で、ＳＱＬメタデータおよびＦＩＬＥＳＴＲＥＡＭ値データのコヒーレンス（coherency）を維持するために、ＦＩＬＥＳＴＲＥＡＭサーバ２４０およびクライアントリダイレクタを、プロトコル上に構築することができる。クライアント側では、プロトコル拡張によって、クライアントマシン２８０が、データベースサーバ２００からＦＩＬＥＳＴＲＥＡＭサーバ２４０へとリダイレクトされた要求を処理できるようになる。データベースサーバ２００から様々なＦＩＬＥＳＴＲＥＡＭサーバ２４０へのアクティビティの最適なオフロードを容易にするために、プロトコル拡張は、たとえば、制約、トリガ、または列の追加、およびトリガ、制約、または列の削除など、様々なテーブルのメタデータにおける変更に関する通知を交換する機能を含むことができる。ＦＩＬＥＳＴＲＥＡＭアクセスモジュール、またはＳＱＬスタックの一部として実施される同様のものは、ＦＩＬＥＳＴＲＥＡＭサーバ２４０上でキャッシュされたメタデータの伝搬／無効化を開始するため、および、それらがデータベースサーバ２００上でのメタデータ変更と同期されることを保証するために必要なコールアウトを含むことができる。

図２に示された３つのマシン構成をより少ないマシンに縮小できる、いくつかのケースがある。たとえば１つのシナリオでは、ＦＩＬＥＳＴＲＥＡＭデータを含むファイルシステムボリュームを、データベース（たとえばＳＱＬ）サーバと同じマシン上でホストすることができる。他のシナリオ例では、ＳＱＬサーバをホストしているマシンから、テーブルにアクセスすることができる。基礎となるアーキテクチャの見地からすると、これは、ネットワークをまたがったリソースへのアクセス、またはローカルリソースへのアクセスの、いずれかになる可能性がある。

実施形態の例
ある実施形態は、ファイルシステム内のデータベース列（たとえば構造化データ）と、対応するＦＩＬＥＳＴＲＥＡＭデータ（たとえば非構造化データ）との間での、トランザクションのリンクレベル整合性を維持するためのメカニズムを提供する。本明細書で使用される場合、トランザクションのリンクレベル整合性とは、たとえばＳＱＬデータベースなどのデータベースが、ファイル名およびディレクトリ名、ロケーションなどに関して、ファイルおよびディレクトリの正確な状況を有する状態に対応する。たとえば、データベースが、ファイルまたはディレクトリが所与の名前と共に存在すると考える場合、ファイルまたはディレクトリはその所与の名前と共にファイルシステム内に存在しなければならない。同様に、データベースが、ファイルまたはディレクトリが存在しないと考える場合、ファイルまたはディレクトリはファイルシステム内に存在してはならない。ある実施形態において、トランザクション的に整合性を維持することのできるファイルおよび／またはディレクトリのオペレーションのタイプには、たとえば、作成、削除、および／または名前変更が含まれる。前述のように、トランザクションのリンクレベル整合性が損失すると、こうした状態の結果として生じるデータの非整合性により、エラー、データ破損、またはシステムクラッシュさえも生じる可能性がある。システムクラッシュが発生した場合、リンクレベル整合性が失われる可能性がある。したがって、クラッシュまたは他のシステム障害後に、データベースオペレーションが再開されることになる場合、リンクレベル整合性を再確立する機能が非常に重要である。

トランザクションのリンクレベル整合性の維持を実行可能にするために、ある実施形態では、ファイルシステムオペレーションが実行される前に、情報の取り消しおよびやり直しの両方をログに記録することができる。こうした実施形態では、ファイルシステムにおける論理オペレーションがべき等（idempotent）でないため、ログシーケンス番号（「ＬＳＮ」）の更新時にリカバリやり直しオペレーションを条件付けることができる。さらにある実施形態では、リカバリ時にデータベーストランザクションがロールバックされる必要がある場合、ファイルシステム効果のロールバックを容易にするために、ファイルシステムメタデータがディスクに保存される前に、ログ記録をフラッシュさせるように動作することができる。最終的に、ログを切り捨てられるように、ある時点において、ファイルシステム効果をディスクにフラッシュすることができるはずであり、それによって記憶スペースが節約される。

したがって、ある実施形態では、データベースログおよびファイルシステムディレクトリの両方において、ファイルシステムオペレーション（たとえば、ファイルまたはディレクトリ上で実行されるオペレーション）をロギングするためのメカニズムを提供する。ある実施形態のメカニズムは、たとえばＮＴＦＳなどの、一般的なファイルシステムに存在する「順序付け特性（ordering property）」を活用することによって、前述のロギング技法を効率的に（たとえば、データベースログへの強制的なフラッシュを必要とせずに）使用する、先書きロギング（Write-Ahead-Logging）を達成することができる。「順序付け特性」とは、ファイルシステムがあるファイルまたはディレクトリに対して変更Ａを実行した後、あるファイルまたはディレクトリに変更Ｂを実行した場合、クラッシュ再始動時に、ファイルシステムが変更Ａなしに変更Ｂを有することは決してないことを示す。言い換えれば、システムがクラッシュした時点（「クラッシュポイント」）では、クラッシュの理由にかかわらず、ファイルシステムそれ自体が破損しない限り、変更なし、変更Ａのみ、または変更ＡおよびＢの両方、のいずれかが結果として発生するが、変更Ａなしの変更Ｂは発生しない。加えて、ある実施形態では、外部コーディネータまたはトランザクテッドファイルシステムの必要なしに、データベースリカバリフレームワークの既存の構成要素を使用することができる。結果として、その比較的単純かつ効率的なオペレーションにより、ある実施形態を幅広く展開することができる。

前述のデータベース環境では、ＦＩＬＥＳＴＲＥＡＭデータファイルを、所与のデータベースに関する特定のディレクトリに編成することができる。ある実施形態では、あらゆるＦＩＬＥＳＴＲＥＡＭファイルが、行（ファイル名によって表すことができる）、列、テーブル、および、ファイルの発生が可能なデータベースを符号化するパス名を有することができる。たとえば、ファイルストリームグループのルートに対するＦＩＬＥＳＴＲＥＡＭファイルのパス名の例は、\FILESTREAM-data-container\table\column\rowguidとすることができる。ディレクトリ構造は、たとえば列の削除または追加、テーブルの名前変更などの、テーブル構造を変更するオペレーション中に変更することができる。各状況において、任意のこうしたテーブル構造オペレーション中に、テーブル内の行を操作するオペレーションを除外するための、適切なロックを取得することができる。言い換えれば、データベース管理システムは、ファイルシステム階層内の同じ上位チェーンに沿った、ファイルシステムオブジェクト（ファイルおよびディレクトリ）上で実行される同時ファイルシステムオペレーションを、直列化（serialize）することができる。

ある実施形態は、トランザクションのリンクレベル整合性を維持するために、こうしたディレクトリ規則の知識（ナレッジ）を活用することが理解されよう。加えて、ある実施形態は、ファイルシステムログベースのリカバリおよび分離用アルゴリズム活用セマンティクス（ＡＲＩＥＳ：Algorithms for Recovery and Isolation Exploiting Semantics）リカバリメソッドと、データベース管理システムのＡＲＩＥＳリカバリメソッドとを組み合わせる。こうした様式では、各システムのリカバリは互いに独立しており、ある実施形態によって組み合わせられた場合であっても、リカバリは、データベースデータおよびファイルシステムデータをトランザクションのリンクレベル整合性状態にする。ＡＲＩＥＳリカバリシステムは、当業者に知られているはずであるため、わかりやすくするために、これに関する実施の詳細は本明細書に含まない。

データベース管理システムのＡＲＩＥＳリカバリとファイルシステムのＡＲＩＥＳリカバリとのこうした組み合わせは、ある実施形態が、たとえばファイルシステム内でのロギング目的でファイル名を使用することによって実行可能とすることができる。こうした実施形態では、特定オペレーションのＬＳＮをファイルの名前に符号化することができる。ファイルの同じ名前は、ファイルシステムの変更を経験するファイルシステムオブジェクト（ファイルまたはディレクトリ）の名前でも符号化されることになる。ファイルＩＤは、データベース復元時にファイルシステムによって再割り当てされる可能性があり、ロギングについては十分に安定していないため、こうしたファイル名ベースのロギング（すなわち、ＬＳＮとファイルシステムオブジェクト名との連結）により、ファイルＩＤベースのロギングに関連付けられた問題が回避されることを理解されよう。

したがって、ある実施形態は、ＢＬＯＢを格納するためにＦＩＬＥＳＴＲＥＡＭデータ属性を使用するデータベースと共に実施することができる。こうしたデータベースでは、ファイルシステムオペレーション（たとえばＢＬＯＢの作成、名前変更、または削除）がデータベースログとファイルシステムログの両方にロギングされる。オペレーションをファイルシステムログにロギングする場合、オペレーションはゼロバイトファイル（こうしたゼロバイトファイルは、本明細書では「ファイルシステムログエントリ」と呼ばれる）として記録することができる。各データベースログ記録にＬＳＮを割り当てることができる。ファイルシステムログエントリの場合、対応するデータベースログ記録のＬＳＮを使用して、ファイル名に符号化することができる。ファイル名は、ロギングされるオペレーションについて記載した他の符号化情報を含むこともできる。こうした符号化は、以下で論じるように、いかなる追加のプロセスもなしに、ＬＳＮおよび他のオペレーション記述子（descriptor）情報を単にファイル名の中に配置することができるか、あるいは、ＬＳＮおよび任意の他の情報を、たとえばアルゴリズムを使用した暗号化などの任意のタイプのフォーマットで格納することができることを理解されよう。

オペレーションでは、ある実施形態は、ファイルシステムオペレーションが実行される予定の場合、オペレーションは第１にデータベースログをロギングし、次にファイルシステムログをロギングし、ついで、ファイルシステムオペレーションが実行される。実際のファイルシステムオペレーションに先立って、ログエントリが入力されるとすると、オペレーションそれ自体が発生し、ロールバックされる必要がある場合は必ず、オペレーションのファイルシステムログエントリが存在することになるため、リカバリ方法で任意のオペレーションをどのようにやり直すかを決定できるはずである。

ファイルシステムフォルダを使用して、先書きロギングを達成するためにファイルシステムオペレーションをロギングすることができる。たとえば、フォルダＸの下にファイルＡが作成される前に、LOG\X〜A.LSN.Xact-ID.Createと呼ばれるファイルが、LOGと呼ばれるファイルシステムフォルダに作成される。このファイル名は、実行中のアクションを表すために、その内部に符号化された十分な情報を有する（LSN、Xact-ID、A、およびCreateは、それぞれ、ＬＳＮ、トランザクションＩＤ、ファイル名、および作成オペレーションを表す記述子である）。ある実施形態では、作成オペレーションの実行に先立って、このファイル名が格納される。したがって、前述の順序付け特性は、Aが存在する場合、LOG\X〜A.LSN.Xact-ID.Createログエントリも存在しなければならないことを示す。オペレーションがロールバックされることになる場合、実施形態はこの知識（ナレッジ）を使用することができる。ある実施形態では、ＮＴＦＳの場合のように、前述の「順序付け特性」が同じボリューム内でのみ適用可能である場合、ファイルシステムログフォルダをファイルシステムデータと同じボリューム上に一緒に置く必要があることに留意されたい。

ディレクトリおよび／またはファイルのいずれかの削除の場合、ある実施形態は、ロールバックの場合にそのアイテムが復元可能なように、削除されることになるアイテムの名前変更を提供する。理解されるように、削除されることになるアイテムが名前変更の代わりに実際に削除された場合、アイテムを復元する元になるデータがなくなるため、削除オペレーションのロールバックは不可能となる。ある実施形態は、このために、たとえばDELETEDと命名されたファイルシステムフォルダを使用することができる。

ここまでファイルロギングオペレーションの例について論じてきたが、次にクラッシュリカバリに関する実施形態について論じる。システムクラッシュの場合、クラッシュポイントで、ログエントリおよび／またはファイルシステムオペレーションのうちの１つまたは複数が実行不可能であることを理解されよう。データベースが再始動されることになる場合、クラッシュの結果として、ログは様々な構成である可能性がある。図３Ａ〜Ｃは、クラッシュなどのシステム障害の結果として生じる可能性のある、３つのログシナリオの例を示す。

図３Ａは、内部にログエントリが記録された、データベースログ３０２およびファイルシステムログ３０４を示す。クラッシュポイント３１０は、システムクラッシュ、エラー、その他により、システムがオペレーションを停止した時点を表す。図３Ａでは、ログ３０２および３０４がタイムラインとして表され、ログ３０２および３０４の左側がより以前の時間であり、右側がより最近の時間であることがわかる。オペレーションＡおよびＢは、適切なＬＳＮを有するログエントリを表す。したがって図３Ａでは、データベースログ３０２に変更ＡおよびＢが記録され、ファイルシステムログ３０４は変更Ａのみを有する、シナリオが見られる。ファイルシステムログ３０４に記録されたようなオペレーションＡは、前述のファイル名とすることができる。図４に関して以下で論じるように、ある実施形態は、データベースログ３０２の方がファイルシステムログ３０４よりも多くの情報を取り込んでいるため、全面的にデータベースログ３０２に基づいて、ＡＲＩＥＳリカバリを実行することができる。

図３Ｂは、データベースログ３０２およびファイルシステムログ３０４の両方が、クラッシュポイント３１０に先立って、変更ＡおよびＢをフラッシュしたシナリオを表す。こうしたシナリオでは、ある実施形態は、ファイルシステムログ３０４が取り込んだ情報と少なくとも同じ量をデータベースログが取り込んでいるため、全面的にデータベースログ３０２に基づいて、ＡＲＩＥＳリカバリを実行することもできる。

図３Ｃは、一般にデータベースログに関するいくつかの実際の問題を考慮の対象とするシナリオを表す。前述のように、ある実施形態は、ファイルシステムログ３０４に先立ってデータベースログ３０２を更新できるものと定めているが、ファイルシステムログエントリがファイルシステムログ３０４にコミットされるのに先立って、ログ記録をデータベースログ３０２にコミットするのに十分な頻度で、データベースログ記録をフラッシュすることができない。ログのフラッシュには、コストのかかるシステムＩ／Ｏオペレーションが必要であることを理解されよう。したがって、データベースが、そのログ記録／エントリを、より速い処理速度に対するトレードオフとして、より低い頻度でフラッシュするように構成される場合、いくつかの状況が生じる可能性がある。したがって、図３Ｃは、変更Ｂがデータベースログ３０２およびファイルシステムログ３０４の両方にロギングされたが、ファイルシステムログ３０４でのみコミットされたため、システムクラッシュ後、変更Ｂはファイルシステムログ３０４にのみ残存することを表す。したがって、たとえログ記録が最初にデータベースログ３０２に対して作成された場合であっても、クラッシュの再始動時に、変更Ｂはファイルシステムログ３０４内にのみロギングされている。図４に関して以下で論じるように、こうしたシナリオでは、ある実施形態は、ファイルシステムログ３０４をデータベースログ３０２への論理拡張として扱うことが可能であり、データベースログ３０２によって取り込まれなかったファイルシステムオペレーションに関する追加の情報が、データベースログ３０２のクラッシュポイントと一致する状態に、ファイルシステムをロールバックするために使用される。

次に図４を参照すると、システムクラッシュなどの後に、データベースをリカバリする方法例４００を表す、流れ図が提供される。方法例４００は、ＡＲＩＥＳアルゴリズムを組み込むことを理解されよう。加えて方法例４００は、前述のように、図３Ａ〜Ｃに関連してデータベースおよびファイルシステムログを再検討できることを理解されたい。

したがって、図３Ａ〜Ｃに関連して上記で論じたように、最新のＬＳＮを有するログ記録を含む、チェックポイント以降などに累積されたすべてのログ記録を見つけるために、ステップ４０１で、データベースログ３０２などのデータベースログが分析される。ある実施形態では、ステップ４０１は、ロールバック時に、ロールバックする必要のあるトランザクションが識別されるように、実施形態がアクティブなトランザクションを収集する、典型的なＡＲＩＥＳ分析段階と同じように実行できることを理解されたい。

ステップ４０３で、ログ記録に格納された情報に従って、条件付きでファイルシステムの変更を再適用することによって、図３Ａ〜Ｃに関連して上記で論じたようなデータベースログ３０２などのデータベースログを、ロールフォワード（roll forward）することができる。あらゆるログ記録について、２つのＬＳＮ間、すなわち、ログ記録それ自体のＬＳＮ（例示の目的で、たとえば「ＬＳＮ１」）と、やり直し情報に対応するファイルまたはディレクトリ名について、または任意の上位ディレクトリについて、ファイルシステムログフォルダにロギングされてきた最大のＬＳＮ（例示の目的で、たとえば「ＬＳＮ２」）との間の比較で、やり直しオペレーションに条件付けすることができる。ＬＳＮ１の方がＬＳＮ２よりも大きい場合、これは、前述の「順序付け特性」に基づいて、ファイルシステム変更に関するファイルシステムログエントリが、ディスクにコミットされていないことを示す。加えてこれは、前述のように、実際のファイルシステム変更は常にファイルシステムログエントリの作成後に実行されるため、実際のファイルシステム変更がディスクにコミットされていないことも示す。この場合、データベースログ記録に記述されたファイルシステム変更のやり直しが実行される。

ＬＳＮ１の方がＬＳＮ２よりも小さい場合、実際のファイルシステム変更がディスクにコミットされている。これは、前述のように、ＦＩＬＥＳＴＲＥＡＭデータを保持するデータベース内で、同じファイル／ディレクトリ名およびその上位に対して実行された変更が直列化されるからである。言い換えれば、ＬＳＮ１に対応するファイルシステム変更が最初に完了するまで、ＬＳＮ２を備えたファイルシステムログエントリは作成されない。「順序付け特性」は、ＬＳＮ２を備えたファイルシステムログエントリがディスクにコミットされている場合、ＬＳＮ１に対応するファイルシステム変更も同様にディスクにコミットされていなければならないことを保証する。したがって、この場合、やり直しがスキップされる。

ＬＳＮ１がＬＳＮ２に等しい場合、実際のファイルシステム変更は、ディスクにコミットされているかまたはされていない可能性がある。この場合、ある実施形態は、ファイルシステムの実際の状態に基づいて、変更を再適用する必要があるかどうかを判別することができる。たとえば、ログ記録／エントリに「ファイルＡの作成（Create File A）」と記述されている場合、ファイルシステムをチェックして、ファイル「Ａ」がすでに存在するかどうかを調べる。ファイル「Ａ」が存在する場合、変更を再適用する必要はない。ファイル「Ａ」が存在しない場合、ファイル「Ａ」が再作成されることになる。ある実施形態では、ステップ４０３は、典型的なＡＲＩＥＳやり直しフェーズと同じように実行できることを理解されたい。

ステップ４０５で、データベースおよびファイルシステムログの状態に応じて、必要なリカバリのタイプが決定される。加えて、ステップ４０５に関連して、リカバリの準備ステップを実行することができる。たとえば、ログは、ステップ４０３および図３Ａ〜Ｃに関連して前述した状況のいずれかとすることができる。ある実施形態では、対応するデータベースログの終端ＬＳＮを超えたファイルシステムログフォルダ内の各ファイルをスキャンし、そのファイル名をメモリ内に記録することができる。その後、ロールフォワードおよびロールバックの両方のために、ＬＳＮに従って、順次または逆などのスキャン順序を可能にするために、ファイル名をたとえばＬＳＮ順に格納することができる。ある実施形態が、データベースログの終わりによって反映される状態にファイルシステムをリカバリする必要があるため、データベースログの終端ＬＳＮを超えるＬＳＮを有するログエントリのロールバックが必要な可能性がある。ある実施形態は、ステップ４０５で、データベースログの終端ＬＳＮよりも大きいＬＳＮを備えるログエントリがファイルシステムログ内にないことがわかった場合、以下で論じるステップ４０７および４０９をスキップすることができる。こうした状況は、図３Ａ〜Ｂに関連して上記で説明している。

ステップ４０７で、ロールフォワードプロセスは、ＬＳＮに基づく昇順で、ステップ４０５によって、メモリ内に記録されたあらゆるファイルシステムログエントリに基づいて、やり直しオペレーションを条件付きで実行する。実際の条件付きやり直しアルゴリズムは、一実施形態で、ステップ４０３に関連して上記で説明したものと同一とすることができる。ステップ４０９で、ＬＳＮに基づく降順で、ステップ４０５によって、メモリ内に記録されたファイルシステムログエントリに基づいて、ロールバックプロセスを実行することができる。当業者であれば知っているはずであるように、ファイルシステムのログフォルダにおける取り消しオペレーションの実行により、補正ログ記録（「ＣＬＲ：Compensation Log Record）」）を生成することができる。こうしたＣＬＲは、データベースログ内ではなく、ファイルシステムログフォルダ内での適用が必要な可能性がある。ファイルシステム内でロールバックプロセスが完了すると、データベースログの終端ＬＳＮより大きいＬＳＮを備えたファイルシステムログエントリを削除できるように、すべてのファイルシステム効果をフラッシュすることができる。

後続の任意のデータベースログロールバックが開始されると、ロールバックプロセスは、データベースログとファイルシステムログの両方で、ＣＬＲのロギングを開始できるため、こうしたオペレーションが重要である可能性があることを理解されよう。結果として、ファイルシステムログが、データベースログの終端ＬＳＮを超えて消去されなかった場合、データベースログのロールバックＣＬＲロギングアクティビティによってＬＳＮの衝突が生じる可能性がある。ファイルシステムをフラッシュするために、ある実施形態は、ステップ４０９の終わりまでに影響を与えたすべてのファイルを追跡し、それらのファイルを１つずつフラッシュすることができる。ある実施形態は、単に新しい一時ファイルを作成し、この一時ファイルをフラッシュし、続いてこれを削除するために、ファイルシステムの「順序付け特性」を活用することもできる。この新しいファイルの作成およびフラッシュにより、すべての以前のファイルシステム変更（たとえば、作成、削除、名前変更）も同様にフラッシュされるか、またはそうでなければ「順序付け特性」を保持できない。ステップ４０９が完了すると、ファイルシステムは、データベースログの終わりによって反映される状態にロールバックされる。

ある実施形態では、取り消しオペレーションが特別なディスクスペースを占有しない。たとえば、ファイル作成の取り消しは、ディスクリソースを解放するだけである。ファイル削除の取り消しは、ディスクスペースの使用率を上げることなく、単に、既存のファイルを名前変更するだけの場合がある。こうした特徴は、ディスクスペースがほぼ完全に消費された状況において重要である可能性があることを理解されよう。

ステップ４１１で、ロールバックは、データベースログの終わりから、最も古いアクティブＬＳＮまで実行することができる。ある実施形態で、ステップ４１１は、典型的なＡＲＩＥＳ取り消し段階と同じように実行できることを理解されたい。ステップ４１１が完了すると、データベースおよびファイルシステムが相互に一致する状態に戻されている。

したがってステップ４１３で、任意の新しいファイルシステムオペレーションを受け入れるのに先立ち、チェックポイントオペレーションを実行することができる。このような場合、クラッシュなどのシステムエラーが将来発生しても、前述のステップ４０１〜４１１で実行されたリカバリプロセスを、同じオペレーションに対して繰り返す必要はない。

図４の方法４００は、ＡＲＩＥＳ方法論を、ある実施形態のデータベースおよびファイルシステムリカバリ方法に組み込むことによって実施されることを理解されよう。しかしながら、ある実施形態は、ＡＲＩＥＳとは異なる動作をする要素を組み込むことができることも理解されたい。たとえば、次に図５を見ると、ＣＬＲを有するファイルシステムログをロールバックする方法例５００が示される。方法５００は、図４に関連して上記で論じた方法４００に関連して実施することができる。典型的なＡＲＩＥＳリカバリでは、ＣＬＲは取り消されない。以下の考察でわかるように、ある実施形態は、こうした取り消しオペレーションをＣＬＲに対して実行することができる。

したがって、ステップ５０１で、ログ記録が非ＣＬＲログ記録であるかどうかが判別される。非ＣＬＲログ記録である場合、さらにステップ５０５で、ＣＬＲによって補正されたログ記録であるかどうかが判別される。補正されていない場合、ステップ５０９で、取り消しオペレーションが実行される。補正されている場合、ステップ５０７で、取り消しオペレーションはスキップされる。ステップ５０１での判別の結果、ログ記録が非ＣＬＲログ記録でない（すなわち、ログ記録がＣＬＲ記録である）場合、ステップ５０３で、ログ記録が、（ＬＳＮなどによって決定された）データベースログの終わりより前のログ記録を補正するＣＬＲであるかどうかが判別される。そうしたＣＬＲである場合、ステップ５０９で、その記録に関する取り消しオペレーションが実行される。そうしたＣＬＲでない場合、ログ記録は、データベースログの終わりより後のログ記録を補正するＣＬＲである。こうした場合、ステップ５０７で、取り消しオペレーションがスキップされる。理解されるように、ＣＬＲの取り消しによって、他のＣＬＲがロギングされる可能性がある（以前のＣＬＲの取り消しを示す）。しかしながら、ある実施形態は、特定ファイルシステムオペレーションに対するリカバリオペレーションが、結果としてファイルシステムログ内に最大２つのＣＬＲを生成できることから、ファイルシステムログスペースの予約によって、たとえば、２つの別々のＣＬＲを表す２つのファイルを作成するために十分なスペースが予約されることが保証されるはずである。

ＣＬＲの取り扱いについて前述した手順は、各ロールバックプロセスが互いに独立するように、ファイルシステムログのロールバックおよびデータベースログのロールバックにまたがって、いかなる持続状態も格納しないことを理解されたい。他の諸実施形態は、ＣＬＲに関するＵＮＤＯオペレーションをスキップするためにＡＲＩＥＳアルゴリズムに固執しながら、データベースログ内のどのログ記録が、ファイルシステムログ内のＣＬＲによって補正されたかに関するような状態を、一貫して記憶しておくことができる。

ある実施形態は、データベースログ内でのロギングが重複することなく、ファイルシステムログフォルダのみに従って、前述のロギングおよびリカバリを実施するように選択できることも理解されよう。しかしながら、ある実施形態は、データベースロギング機能の実施が典型的にはファイルシステムフォルダベースのログの実施よりもかなり優れていることを企図している。したがって、ある実施形態は、データベースログに基づいてリカバリオペレーションを実行し、ファイルシステムログを、データベースログによって取り込まれたのではないそれらのオペレーションに対する拡張としてのみ使用する。結果として、ファイルシステムログのみを使用するのに比べて、全体的なリカバリパフォーマンスが向上する。

以上、本発明について、様々な図面の諸実施形態に関連して説明してきたが、他の同様の実施形態が使用可能であるか、または、本発明から逸脱することなく、本発明の同じ機能を実行するために、記載された実施形態への修正および追加が実行可能であることを理解されよう。したがって本発明は、いかなる単一の実施形態にも限定されるものではなく、添付の特許請求の範囲に従った幅および範囲内にあるものと理解されたい。

本発明の諸態様が実施可能なコンピューティング環境の例を示す図である。本発明の諸態様が実施可能なデータベース構成の例を示す図である。本発明の諸態様が実施可能なログの例を示す図である。本発明の諸態様が実施可能なログの例を示す図である。本発明の諸態様が実施可能なログの例を示す図である。本発明の諸実施形態に従った方法の例を示す流れ図である。本発明の諸実施形態に従った方法の例を示す流れ図である。

Claims

データベースとファイルシステムとの間でのトランザクションのリンクレベル整合性を維持する方法であって、前記方法は、データベースおよびファイルシステムに関連付けられるコンピュータによって実行され、
バイナリラージオブジェクトについてのファイルシステム変更要求を受信するステップであって、前記バイナリラージオブジェクトへの参照は、データベースのセルに格納され、前記バイナリラージオブジェクトは、前記データベースの外部にファイルシステムのファイルとして格納される、ステップと、
前記データベースのデータベースログの最大ログシーケンス番号と前記ファイルシステムのファイルシステムログの最大ログシーケンス番号を比較するステップと、
前記データベースログの最大ログシーケンス番号が前記ファイルシステムログの最大ログシーケンス番号以上である場合、前記データベースに関連付けられるコンピュータが、前記ファイルシステム変更要求に関連付けられるファイルシステム変更を前記データベースログにロギングするステップと、
前記ファイルシステムに関連付けられるコンピュータが、前記ファイルシステム変更をファイルシステムログファイルのファイル名にロギングするステップであって、前記ファイルシステムログファイルは、前記ファイルシステムのファイルとして格納され、前記ファイルシステム変更を表す情報は、前記ファイルシステムログファイルのファイル名に符号化される、ステップと、
前記ファイルシステムに関連付けられるコンピュータが、前記バイナリラージオブジェクトについての前記ファイルシステム変更を実行するステップと
を含むことを特徴とする方法。
前記ファイルシステム変更をファイルシステムログファイルにロギングするステップは、前記ファイルシステム変更要求が前記バイナリラージオブジェクトをセーブするための要求であることを識別する情報を前記ファイルシステムログファイルのファイル名に符号化するステップをさらに含むことを特徴とする請求項１に記載の方法。
前記ファイルシステム変更をファイルシステムログファイルにロギングするステップは、前記ファイルシステム変更に対応する、ファイルシステムオブジェクト名、ログシーケンス番号、トランザクション識別子、およびオペレーション記述子を識別する情報を前記ファイルシステムログファイルのファイル名に符号化するステップをさらに含むことを特徴とする請求項１に記載の方法。
前記ファイルシステム変更をファイルシステムログファイルにロギングするステップは、前記データベースログのログシーケンス番号を識別する情報を前記ファイルシステムログファイルのファイル名に符号化するステップをさらに含むことを特徴とする請求項１に記載の方法。
前記ファイルシステム変更をデータベースログにロギングするステップおよび前記ファイルシステム変更をファイルシステムログファイルにロギングするステップは、前記ファイルシステム変更を実行するステップに先立って実行されることを特徴とする請求項１に記載の方法。
前記ファイルシステム変更は、前記バイナリラージオブジェクトを変更することを含むことを特徴とする請求項１に記載の方法。
データベースとファイルシステムとの間でのトランザクションのリンクレベル整合性を維持するように構成されたコンピュータシステムであって、
前記コンピュータシステムは、コンピュータ読み取り可能な記憶媒体に結合されたプロセッサを備え、
前記コンピュータ読み取り可能な記憶媒体は、コンピュータ実行可能命令を格納し、該コンピュータ実行可能命令は、前記プロセッサによって実行されるときに、前記コンピュータシステムに、
バイナリラージオブジェクトへの参照をデータベースのセルに格納するステップと、
前記バイナリラージオブジェクトを前記データベースの外部にファイルシステムのファイルとして格納するステップと、
前記バイナリラージオブジェクトに対する変更が失敗したことを、データベースログに格納される最大ログシーケンス番号とファイルシステムログに格納される最大ログシーケンス番号とを比較することによって判定するステップであって、前記ファイルシステムログに格納される最大ログシーケンス番号は、前記ファイルシステムに格納されるファイルシステムログファイルのファイル名に符号化され、前記データベースログは、前記データベースに格納され、前記ファイルシステムログは、前記ファイルシステムにファイルとして格納される、ステップと、
前記ファイルシステムによって前記ファイルシステムにおける変更をロギングし、前記ファイルシステムによって前記バイナリラージオブジェクトについての変更を実行することによって、前記変更をやり直すステップと
を実行させることを特徴とするコンピュータシステム。
前記ファイルシステムログファイルのファイル名は、前記ファイルシステムの変更に対応する、ファイルシステムオブジェクト名、トランザクション識別子、およびオペレーション記述子をさらに備えることを特徴とする請求項７に記載のコンピュータシステム。
それぞれのファイルシステムログは、別々のファイルに格納されることを特徴とする請求項７に記載のコンピュータシステム。
データベースとファイルシステムとの間でのトランザクションのリンクレベル整合性を維持する方法を実行するコンピュータ実行可能命令を有するコンピュータ読み取り可能な記録媒体であって、
前記コンピュータ実行可能命令は、コンピュータによって実行されるとき、該コンピュータに、
前記データベースのデータベースログの最大ログシーケンス番号と前記ファイルシステムのファイルシステムログの最大ログシーケンス番号を比較するステップと、
前記データベースログの最大ログシーケンス番号が前記ファイルシステムログの最大ログシーケンス番号以上である場合、バイナリラージオブジェクトに対する変更をデータベースログのレコードにロギングするステップであって、前記バイナリラージオブジェクトへの参照は、前記データベースのセルに格納され、前記バイナリラージオブジェクトは、前記データベースの外部にファイルシステムのファイルとして格納され、前記データベースログは、前記データベースに格納される、ステップと、
前記ファイルシステムによって、前記バイナリラージオブジェクトへのファイルシステム変更をファイルシステムログファイルにロギングするステップと、
前記ファイルシステム変更に対応する、ファイルシステムオブジェクト名、ログシーケンス番号、トランザクション識別子、およびオペレーション記述子を識別する情報を前記ファイルシステムログファイルのファイル名に符号化するステップと
を含む方法を実行させることを特徴とするコンピュータ読み取り可能な記録媒体。