JP4762972B2 - データベース内の回復ユニット（ｒｅｃｏｖｅｒｙｕｎｉｔ）のためのシステムおよび方法 - Google Patents

Description

本出願は、参照によりその開示を完全に本明細書に組み込む、２００４年２月２７日に出願した米国特許出願第１０／７８９，２４４号明細書の優先権を主張するものである。

本発明は一般にコンピュータデータベースの分野に関する。より詳細には、本発明は、データベース構造での独立した複数の回復可能ユニットの使用に関する。

現代のほとんどのデータベースは、完全に使用可能、または完全に使用不可であるという特徴を示す。メンテナンス方式または障害回復方式では、メンテナンス時または回復時の間、データベースが使用不可になる。こうした方式での可用性の単位は、データベース全体である。図１は、それぞれテーブルＡ１０１、テーブルＢ１０２、テーブルＣ１０３にパーティション分割されている従来技術のデータベース１００を示している。各テーブルは、単一のログストリーム１０５を使用して行および他のデータの変更を記録して、データベースをトランザクション上整合状態に保つ。データベースのサイズが増加し、より多くのテーブルがデータベースに追加されるにつれて、より多くのデータ量がログストリーム１０５に書き込まれるはずである。ログストリームは、次第にデータベースが存在するハードウェアの限界を超えるようになる、かなりの管理性および性能の問題をもたらす障害となる。最終的には、単一のログストリーム、およびデータベース情報の回復に関するそのアクセス可能性および速度の限界がデータベースの障害となる。

従来技術のこの問題に対する選択肢は、単一のログを複数のログストリームに分割することによってログストリームをよりよく管理することである。図２は、それぞれテーブルＤ２０１、テーブルＥ２０２、テーブルＦ２０３、および共有の、しかし個別のログストリームデータセット２０７、２０８、２０９にパーティション分割されているデータベース２００を示している。ログストリームデータセットを追跡し、管理するために、調整機構２０５が導入されている。しかし、これは、ログストリームデータの障害の問題を解決するが、データベースのサイズが大きくなるにつれて結局調整機構２０５が遅くなるという別の問題をもたらす。また、単一テーブル、例えばテーブルＤ２０１のみの回復は、テーブルＤのデータログストリームがすべてのデータログストリームに分散されているため、複数のデータログストリーム２０７、２０８、および２０９の使用を必要とし得る。図２のアーキテクチャは、図１のアーキテクチャの改良であるが、調整機構２０５の障害のため、依然として速度性能の制限があり、ログデータストリームを含む回復操作中、依然としてデータベース全体が使用不可である。

したがって、性能の障害に関して速度を向上できるアーキテクチャが必要であり、回復動作中にデータベースを少なくとも部分的に使用可能にすることが望ましい。本発明は、本明細書に記載する追加の利点で上記の必要性に対処し、それらを解決する。

データベース内の回復ユニットと呼ばれる回復可能な複数のデータベースパーティションの構築は、他の部分をアクセス可能にしながら、データベースの一部分のみにおいてメンテナンスまたは障害の回復を実行する能力を追加するのに有用である。これは特に、単一のログストリームまたはログストリーム調整機構の障害が回復操作の速度を低下させ得る非常に大きいデータベースで有用である。この方法は、データベースを複数の回復ユニットにパーティション分割し、メタデータの１次および２次カタログを作成するステップを伴う。

１次カタログは、データベース、テーブル、インデックス、ファイルグループ、データ型、制約、ストアドプロシージャ、トリガ、および他の識別可能なデータベース構造への参照を含む、回復ユニットの論理要素を含み得る。２次カタログは、各回復ユニットに関連付けられ、ファイル、ページ、Ｂツリー、ヒープ、回復ユニット、およびログストリームデータを含む、回復ユニットの物理要素に関するメタデータを含み得る。

１次カタログおよび２次カタログが定義された後、１次カタログと２次カタログとはリンクされ、ある回復ユニットは、他の回復ユニットがデータベースのユーザからアクセス可能である間に、データベースの一部分のみまたは回復ユニットのみでメンテナンスまたは回復操作を行うよう働くことができる。本発明の一実施形態では、回復ユニットを使用して、データベースの一部分を別の部分にコピーし、それによって回復の目的以上にその実用性を拡大することができる。

上記の要約、および以下の好ましい実施形態の詳細な説明は、添付の図面と併せ読めばよりよく理解できる。本発明の実施形態の説明上、図面には本発明の構造例を示しているが、本発明は開示した特定の方法および手段に限定されない。

概要
本発明の一実施形態は、従来技術の障害の問題に対処することができるデータベース内の複数の回復ユニットを提供し、さらに全体的なデータベースの可用性を向上させる機能を提供する。これは、メンテナンスまたは障害の回復のシナリオ中にデータベースの一部分のみを使用不可にすることによって達成することができる。本発明の一態様は、データベースの論理要素と物理要素との間のメタデータの分割を提供する。論理要素は、ユーザが閲覧するデータベース、テーブル、インデックス、テーブルおよびインデックスのパーティション、データ型、制約、ストアドプロシージャ、トリガ、およびファイルグループを含む。物理要素は、エンドユーザからは見えないページ、ファイル、Ｂツリー、ヒープ、回復ユニット、およびログを含む。データベースの論理要素を表すメタデータは、「１次」回復ユニットに格納され、データベースの物理要素のメタデータは、それぞれの「２次」回復ユニットに格納される。この論理メタデータ対物理メタデータ手法を整合状態に維持することによって、本発明の一実施形態は、単一の論理テーブルまたはインデックスへの更新を個別の物理ログストリームに別々に記録できるようにする。

図３を使用して構成例を説明した後、方法および実施形態を図４〜７との関連で説明する。コンピューティング環境例についても図８との関連で説明する。

本発明の実施形態例
図３は、本発明の一実施形態の機能図を示している。この実施形態は、データが複数のテーブルにパーティション分割されているデータベース３００を含む。図３はこうした４つのテーブルを示しているが、本発明をそのように限定する必要はない。このアーキテクチャは、テーブル３０２、３０４、３０６、および３０８が１つのログデータストリームのみと関連しているところを示している。また、ログストリーム３０３、３０５、および３０７は、互いに独立して機能し得る。したがって、例えばテーブル１（３０２）は、ログデータストリーム３０３のみと関連する。テーブル２（３０４）は、ログデータストリーム３０５のみと関連する。テーブル３（３０６）は、ログデータストリーム３０７のみと関連する。テーブル４（３０８）は、ログデータストリーム３０７のみと関連する。図４のテーブル３０２、３０４、および３０６は、データベース３００の任意のパーティションでよいことに留意されたい。これらのパーティションは、データベース内の任意のデータのテーブル、テーブルの断片部分、またはインデックスとすることができる。

図３のアーキテクチャは、複数のデータストリームログがデータベース３００の回復操作をサポートできるようにする。このアーキテクチャは、個々のテーブルを単一のログのみに関連付けることができるようにする。つまり、単一のテーブルは、１つのログデータストリームのみを使用する。このアーキテクチャは、データベースの他のテーブルをアクセス可能にしたまま、回復を１つのテーブルのみで達成できるようにログデータを使用することによって、単一のテーブルまたはデータベースのパーティションの回復を可能にする。ログストリームの独立性およびそのパーティションまたはテーブルとの密接な関連によって、従来技術にある障害が無くなる。したがって、通常の操作および回復操作の両方で速度が向上する利点がある。さらに、本明細書に詳述するように、図３のアーキテクチャによって、１つまたは複数のデータベースパーティションを別のデータベースに転送することができる。

本発明の一態様は、単一のデータベースを、回復ユニットと呼ばれる複数のデータベースにパーティション分割することである。各回復ユニットは、データファイルおよびログストリームのそれ自体の組を有し、それぞれデータベース内の他の回復ユニットとは無関係に回復することができる。回復ユニットは、同じログを共有するため、トランザクション上整合状態にあるファイルグループ、ファイル、およびログの集まりである。データベースごとの複数のログストリーム間で作業負荷を分けるように、データベース内のテーブルおよびインデックスを異なる回復ユニットに割り当て、またはパーティション分割することができる。データベースがこうした個別の回復ユニットに分割されると、データベースの残りから切り離して個々の回復ユニットを復元し回復する能力によって、データベースの全体的な可用性および性能を向上させることができる。回復中、復元される回復ユニットに存在するデータベース部分のみが使用不可である。データベースの残りは依然として使用可能である。

一実施形態では、回復ユニットの構築の方法は、データベースの論理要素と物理要素との間のメタデータの分離である。論理要素の例は、ユーザが閲覧するデータベース、テーブル、インデックス、データ型、制約、ストアドプロシージャ、トリガ、ファイルグループ、および他のデータベース構造である。物理要素の例は、エンドユーザからは見えないページ、ファイル、Ｂツリー、ヒープ、回復ユニット、およびログである。一実施形態では、データベースの論理要素を表すメタデータは、「１次」カタログに格納することができ、データベースの物理要素のメタデータはそれぞれ、それ自体の回復ユニットに格納することができる。この論理メタデータ対物理メタデータ手法を整合状態に維持することによって、少なくとも一実施形態は、単一の論理テーブルまたはインデックスへの更新を個別の物理ログストリームに別々に記録することができる。

図４は、本発明の一実施形態内での論理メタデータおよび物理メタデータの分離を示している。実施形態４００は、この方式に関連付けられたメタデータをそれぞれ有する論理部分４５０および物理部分４６０を有するデータベースを示している。論理層４５０では、データベース内のすべてのデータベース、インデックス、およびパーティションのファイルおよびファイルグループに関するメタデータを含む１次カタログ４０２を構成することができる。メタデータは、ファイルおよびファイルグループと対応する回復ユニット識別子との間の関連も含む。例えば、１次カタログは、データベースのテーブルデータ４０６のテーブルおよびインデックス４０３に関するメタデータを含み得る。テーブルデータ４０６は、複数のデータベースパーティション４０８、４１０に分割することができ、各データベースパーティションは、テーブル、インデックス、または他の任意のデータまたはメタデータの組とすることができる。１次カタログは、メタデータの形式の中でも、データベースに含まれるデータに関する情報のインデックス４０４の他の任意の形式を含むこともできる。

１次カタログ４０２は、データベースパーティション４０８、４１０などのデータ構造と、関連の回復ユニットおよびそれぞれの識別子との連係に関するメタデータを含み得る。例えば、データベースパーティション４０８と対応する回復ユニット１（４１４）との間の連係４０９は、１次カタログメタデータ内にあり得る。同様に、本実施形態の論理層４５０を物理層４６０の物理回復ユニット４１６および４１８にそれぞれ関連付けるための連係４１１および４０５も１次カタログメタデータに含まれ得る。

物理層４６０は、物理的な回復ユニットを含み得る。図４の例では、３つの回復ユニットがあるが、任意の数の回復ユニットを設定することができる。図４の例では、回復ユニット１（４１４）は、データベースパーティションＡ４０８に関連付けられ、回復ユニット２（４１６）はデータベースパーティションＢ４１０に関連付けられ、回復ユニット３は、１次カタログ４５０の他のインデックス４０４に関連付けられている。回復ユニット１（４１４）は、それが参照するデータベースの物理要素のメタデータを含む２次カタログ４２０を含み得る。例えば、２次カタログは、Ｂツリー、ファイル、ページ、ヒープ、またはログデータへの参照を含み得る。図４の実施形態例で、２次カタログ４２０は、Ｂツリー１（４２２）およびＢツリーを構成するページ４２４への参照を含む。また、２次カタログは、データベースのデータベースパーティションＡ４０８を参照する回復ユニット１のデータへの変更に特に関連付けられているログ１ストリームデータ４２６への参照メタデータを有する。特定の例として、行セット識別子および回復ユニット識別子は、行セットがデータベース内で開かれると、２次カタログに渡される。１次カタログおよび２次カタログでのこの一意の専用の連係は、データベースの他の回復ユニットとは無関係にファイル、テーブル、インデックス、および他のデータベースデータを回復させるように回復ユニットを働かせることができるものである。

回復ユニットは、データベースの他の部分と対話する必要なく回復操作のＲＥＤＯ部分を行うことができる。例えば、回復ユニット１（４１４）がデータベースのその部分の側面の回復に使用されている場合、回復ユニット２（４１６）および回復ユニット３（４１８）は、回復ユニット１の操作中、オンラインでアクティブのままであり得る。回復ユニットは、対話なしに論理ＵＮＤＯ回復操作のほとんどの部分を行うこともできるが、準備されたトランザクションがコミットされるか、中止されるかを決定するために、他の回復ユニットまたはデータベースに連絡する必要がある。これによって、一部の物理回復ユニットが存在していない、または回復していない場合でさえ、複数の物理回復ユニットから成るデータベースを使用可能にすることができる。他の物理回復ユニットは、データベースがオンラインである間に復元され、回復され得る。

図４に示した実施形態例のアーキテクチャは、データベース間のデータベースパーティションの移動を可能にするフレームワークを提供する。よく知られているように、前および次のページの識別子など、ほとんどのページ上のファイル識別子、およびヒープ行識別子ポインタ（ｈｅａｐ ｒｏｗ ｉｄｅｎｔｉｆｉｅｒ ｐｏｉｎｔｅｒ）およびＢツリートラバースポインタ（Ｂ−Ｔｒｅｅ ｔｒａｖｅｒｓａｌ ｐｏｉｎｔｅｒ）などの多くの行への参照結合のため、ファイルまたはファイルグループをあるデータベースから別のデータベースに移動させることは現在は非現実的である。しかし、本発明の態様によれば、ファイル識別子は、回復ユニット内で一意であればよい。結果として、回復ユニットは、あるデータベースから別のデータベースにコピーまたは移動することができる。図５は、この特徴の例を示している。

データベースｘ５００の回復ユニットｂ（５０４）は、図５のデータベースｘの多くの回復ユニット５０２、５０６のうちの１つである。データ内容を図５のデータベースｙ５１０にコピーし、回復ユニット５０４の要素をデータベースｙの一部にすることが望ましい。転送前にデータベースｘにはＮ個の回復ユニットがあり、データベースｙには２つしかないため、各データベース内の回復ユニットの数は要因ではないことに留意されたい。つまり、回復ユニットｐ５１２およびｑ５１４Ｕは、データベースｙ５１０にあらかじめ存在している可能性がある。

本発明の態様を使用して、回復ユニットを転送可能ユニットとして使用することによって、回復ユニット５０４のデータをデータベースｘ５００からデータベースｙ５１０にコピーすることができる。回復ユニット５０４がデータベースｘからデータベースｙにコピーされると、その内容は保持されるが、新しいデータベースと互換性がある命名規則を採用し得る。したがって、古い回復ユニットｂ（５０４）は、データベースｙにいったんコピーされると、その名前がデータベースｙと互換性のある回復ユニットｒ５０４’となり得る。データベースｙ内の新しく追加された回復ユニット５０４’は、その仲間の回復ユニット５１２および５１４のものとは異なる名前空間を有する。新しい名前空間は、データベースｘ内の元の回復ユニット５０４とも異なり得る。

図６は、本発明の一実施形態の一般の方法のフロー図を示している。ステップ６０５で、データベースを、回復ユニットとして使用する複数のユニットにパーティション分割することができる。ステップ６１０で、上述したような１次カタログが作成される。１次カタログは、回復ユニットの論理メタデータ要素を含み得る。１つのログストリームのみが特定の回復ユニットに関連付けられ、しかし複数の回復ユニットは単一のログストリームファイルを共有し得るように、ステップ６１５で複数のログストリームファイルが作成され得る。一実施形態では、回復ユニットが存在するのと同じだけログストリームファイルが存在するのが好ましい。ステップ６２０で、２次カタログが作成され得る。作成された２次カタログは、それぞれの回復ユニットの物理メタデータ要素を含み得る。ステップ６２５で、２つのタイプのカタログが別個の回復ユニットを参照するように、それらをリンクすることができる。したがって回復ユニットのフレームワークを確立することができる。次いでシステムのユーザは、回復ユニットを働かせる必要がある場合、残りの回復ユニットの可用性に影響を与えることなくオフラインで実行することができるように、２次カタログを維持することができる。

このように作成されると、回復ユニットをうまく利用して、同じデータベース内の他の回復ユニットからオフラインでデータベースの部分を維持し、または回復することができる。さらに、回復ユニットのフレームワークは、あるデータベースから別のデータベースへの１つまたは複数の回復ユニットの転送を可能にする。図７は、回復ユニットとして構築されたデータベースの１つまたは複数の部分をあるデータベースから別のデータベースにコピーする方法のフロー図を示している。

最初に、ステップ７０５で、図６の方法に従って第１のデータベースにおいて１つまたは複数の回復ユニットを作成することができる。次いで、ステップ７１０で、第２のデータベースにおいて１つまたは複数の回復ユニットを作成することができる。転送を行うために、ステップ７１５で、どの回復ユニットが第１のデータベースから第２のデータベースに転送されることが求められるかに関する選択を行う必要がある。次いでステップ７２０で、選択された回復ユニットがコピーされ、したがって第２のデータベースに転送され得る。したがって、第２のデータベースの構造が第１のデータベースのものと一致することを前提に、転送された回復ユニットは、新しいデータベースに結合され、第２のデータベースによるアクセスが可能である。

単一のデータベース内での操作の説明に戻ると、本発明の異なる一実施形態では、複数のファイルグループを同じログに結合することができる。例えば、ユーザは、回復ユニットごとに１つのファイルグループを有し得る。各回復ユニットは、その物理メタデータカタログを含む主要ファイルグループを有し得る。この主要ファイルグループは、回復ユニットおよびファイル管理にアクセスする方法のためのカタログとすることができる。例えば、各データベースは、データベースおよび他の回復ユニットのブートストラップのために使用される１次回復ユニットを有し得る。１次回復ユニットは、すべての物理メタデータ、および起動時に２次回復ユニットを見つけ、起動させるのに十分な物理メタデータを含み得る。２次回復ユニットは、論理メタデータのカタログを含む。一実施形態では、各回復ユニットは、１つの主要ファイルグループを含み、データベースの１次ファイルグループは、主要ファイルグループである。１次ファイルグループは、データベースの単一の論理カタログ、および物理メタデータが２次回復ユニットをブートストラップするのに十分な情報を含み得る。１次ファイルグループは、１次回復ユニット内のみに存在し得る。さらに、１次回復ユニットは、１次ではない、またはより低い層の回復ユニットを見つけるのに必要な新しいカタログエントリを有し得る。主要ファイルグループの名前は、ＣＲＥＡＴＥ／ＡＬＴＥＲ ＤＡＴＡＢＡＳＥ構文のアクセスポイントとすることができる。

一実施形態では、本発明を、ワシントン州レドモンドのＭｉｃｒｏｓｏｆｔ社から入手可能な構造化照会言語（ＳＱＬ）環境で使用することができる。その環境で、回復ユニットの状態は、データベースの状態を映すことができ、全体的なデータベースの状態を１次回復ユニットの状態に結合することができる。回復ユニットのロックスペースは、回復ユニットがオンラインのとき、データベースのものと同じであり得る。他の何らかの状態に移動するとき、ロックスペースに移行することが望ましい。この移行は、回復ユニットをオンラインから除くためにデータベース全体の最初の簡単な排他的ロックを必要とする可能性があるが、後でそれをオンラインに戻す必要はない。ほとんどの場合、最初の状態はオンラインではない可能性が高いため、実際にはユーザに見える移行期間はない。一実施形態で、既存のデータベース管理状態から移行フレームワークを利用することはできるが、それをデータベース全体の代わりに回復ユニットに適用することができる。一実施形態では、以下のデータベース状態をデータベースおよび回復ユニットに適用することができる。

ＳＱＬ環境では、状態の多くはデフォルトまたは移行状態である。ＲＥＳＴＯＲＩＮＧ状態には、回復ユニット内の任意のファイルまたはファイルグループの復元を試みることによって到達する。ＯＦＦＬＩＮＥ状態およびＥＭＥＲＧＥＮＣＹ状態の場合、管理者が強制的に状態を変更させることができるための構文を決定する必要があることが好ましい。また、これらが回復ユニットに有用な状態であるかどうかを決定する必要があることも好ましい。「回復ユニット」を参照する構文を一切公開しないことが理想的である。

ＳＱＬ環境で、長期の回復シナリオ中、データベースは、１次回復ユニットが使用可能になるとすぐに使用可能になる。長期回復が行われている回復ユニットは「Ｒｅｃｏｖｅｒｉｎｇ」であり、そのすべてのファイルグループはユーザから使用できない。しかし、データベースの残りが使用可能である間、１次以外の他の回復ユニットは回復し得る。

やり直し／元に戻すの回復は、回復ユニットごとに行うことができ、現在の呼出がデータベースから回復ユニットにリダイレクトされることを必要とすることが好ましい。特殊なケースはなく、一般に回復は、回復ユニットのみと働けばよく、データベースとともに働く必要はない。回復は、異なる回復ユニットおよびチェックポイントでマルチスレッド化される。

ＳＱＬ環境で、データベースの回復モード（ＦＵＬＬ、ＳＩＭＰＬＥ、ＢＵＬＫ＿ＬＯＧＧＥＤ）は、すべての回復ユニットに適用され得る。さらに、回復ユニットは、現在のデータベース構成要素へのオーバーヘッドがほとんどない、またはまったくない状態で、データベースごとに複数のログを有する機会を提供し得る。

本発明の一態様では、基本的なフレームワークを活用して、テーブルまたはデータベースのパーティションをあるデータベースまたはサーバから別のデータベースまたはサーバに容易に移動／マージできるようにすることができる。これは、ファイルのコピー／添付または論理メタデータおよび物理メタデータの復元によって達成することができる。この機能を使用して、異なる回復ユニットは、データベース内で一意ではなく回復ユニット内で一意の同じファイル識別子を有し得る。

一実施形態では、データベースへの１つの内部インターフェース、ＤＢＴＡＢＬＥは、核の物理メタデータ以外のほとんどの構成要素について同じままであり得る。物理メタデータの構成要素は、ＤＢＴＡＢＬＥの代わりに回復ユニットを参照し得る。

一実施形態では、ファイル、ファイルグループ、およびログファイルの集まりを回復ユニットで使用することができる。回復ユニットは、ＣＲＥＡＴＥ ＤＡＴＡＢＡＳＥステートメントまたはＡＬＴＥＲ ＤＡＴＡＢＡＳＥステートメントで主要ファイルグループを指定することによって作成することができる。ＣＲＥＡＴＥ ＤＡＴＡＢＡＳＥの場合、新しい主要ファイルグループはそれぞれ、前の回復ユニットが指定されたログの後にくることが好ましい。ログファイルは主要ファイルグループごとに指定することができることが好ましい。この実施形態では、ＣＲＥＡＴＥ ＤＡＴＡＢＡＳＥ構文図を次のように表すことができる。

この実施形態では、回復ユニットの作成には、ファイルグループ名の後にファイルリストを添付できるようにするＡＬＴＥＲ ＤＡＴＡＢＡＳＥ命令の新しい構文が必要である。回復ユニット全体を追加するステートメントは、次のように示される。

データファイルの場合、ファイルを既存の回復ユニットに追加することは、ファイルをファイルグループに追加することと同じである。ログファイルの場合、ＡＤＤ ＬＯＧ ＦＩＬＥがファイルグループ名を指定することもできるように、ＡＬＴＥＲ ＤＡＴＡＢＡＳＥ構文への拡張が望まれ得る。そのファイルグループ名は、回復ユニット内の主要ファイルグループとすべきである。

同様に、ファイルグループを回復ユニットに追加するために、その回復ユニットの主要ファイルグループを示す文節を追加することができる。

回復ユニットの状態の変更は、ＭＯＤＩＦＹ ＦＩＬＥＧＲＯＵＰ文節を主要ファイルグループ名とともに使用することを除いて、データベースの状態の変更とほぼ同じである。

ＲＥＳＴＯＲＥ ＤＡＴＡＢＡＳＥ構文は、一般に、ファイルまたはファイルグループのオプションをすでに含んでいる。本発明の一態様として、その回復ユニットのログのみが影響を受けるように、ファイルまたはファイルグループのオプションを、ＲＥＳＴＯＲＥ ＬＯＧステートメントに拡張することもできる。

回復ユニット内のファイルグループおよびファイルに割り当てられた数字識別子（ＩＤ）は、回復ユニット間で重複することに留意されたい。つまり、各回復ユニットは、その１次データのファイル１およびファイル２およびログファイルを有している。各回復ユニットは、そのシステムテーブルのファイルグループ１を有している。この原理には複数の面がある。

（ａ）この特徴は、データベースごとに３２，７６７個のファイルの一般に使用可能な限界を拡大する。

（ｂ）現在使用可能なシステムでは、一般の限界は、データベースごとに３２，７６７個のファイルグループである。回復ユニットを使用すると、ファイルグループの最大数×許容される回復ユニット数にすることができる。

（ｃ）回復ユニットは、単独とすることができ、別のデータベースに容易に移動することができる。この移動は、テーブルまたはデータベースのパーティション全体の新しいデータベースまたはサーバへの移動とすることができる。

上記の重複の結果として、行識別子は、もはやデータベース内で一意ではなく、回復ユニットで一意である。ヒープ上の非クラスタ化インデックスは、回復ユニットのインデックスに存在しない行識別子を含み得る。

一実施形態では、２つの回復ユニットを含むデータベースの作成は、次の例のように実施され得る。

回復ユニット１は、１つのファイルグループ、１次回復ユニットのみを有している。回復ユニット２は、２つのファイルグループ、１次（ＳａｌｅｓＧｒｏｕｐ１）および２次（ＳａｌｅｓＧｒｏｕｐ２）を有している。

一実施形態では、テーブルの異なる回復ユニットへの追加は、次の例のように実施され得る。テーブルまたはインデックスを異なるファイルグループに追加するには、ユーザは、ＣＲＥＡＴＥ ＴＡＢＬＥステートメントまたはＣＲＥＡＴＥ ＩＮＤＥＸステートメントへの「ＯＮ」文節の追加を指定することができる。例えば、上記で作成された追加データベースで、ＳａｌｅｓＧｒｏｕｐ１回復ユニット上にＰｕｒｃｈａｓｅＯｒｄｅｒＤｅｔａｉｌテーブルがあり、しかし１次回復ユニット上に顧客テーブルがあるかもしれない。

一実施形態では、新しいＡＬＴＥＲ ＤＡＴＡＢＡＳＥ構文を使用して、新しい回復ユニットを既存のデータベースに追加することができる。

一実施形態では、ファイルグループの可用性および回復を示す本発明の一態様の例は、次のシナリオから理解できる。データベースＦＯＯは、主要ファイルグループＡ（１次）、Ｂ、Ｃ、Ｄ、およびＥを有する。Ｃのファイルグループ内にデータファイルを含むドライブが故障したと仮定する。さらに、Ｅのファイルグループが所有するファイルの物理的なファイル破損がある。データベースの起動時、ファイルグループＡは応答しており、したがって最初のデータベース状態はＯＮＬＩＮＥである。しかし、Ｃの状態は、ファイルが欠けているため「Ｒｅｃｏｖｅｒｙ Ｐｅｎｄｉｎｇ」であり、Ｅは、破損のために回復できず、「Ｓｕｓｐｅｃｔ」とマークされている。起動後の状態は、次のように表示される。

Ｃドライブの問題は、プラグが抜かれた電源ケーブルとして解決される。これは訂正され、ファイルは現在使用可能である。ユーザは、Ｃをオンラインに設定するためにＡＬＴＥＲ ＤＡＴＡＢＡＳＥステートメントを使用することができる。

ALTER DATABASE FOO MODIFY FILEGROUP C SET ONLINE
Ｃドライブは回復し、現在使用可能である。現在、状態は次の通りである。

ファイルグループＡ、Ｂ、およびＤ内のデータへのユーザのアクセスは、ＣドライブのＯＮＬＩＮＥへの移行によって影響を受けた。ドライブＤのデータファイルは、物理的に損害を受け、回復する必要がある。ファイルグループはＯＮＬＩＮＥではないため、ＲＥＳＴＯＲＩＮＧへの移行は、他のファイルグループのユーザに影響を与えることなく行われる。ドライブＣのログの後部を含めて、データベース全体のログがバックアップされる。

BACKUP LOG foo TO DISK='e:＼logtail.dmp'
ドライブＣのデータファイルは、最後のデータベースバックアップから復元される。これによってドライブＣは、ＲＥＳＴＯＲＩＮＧ状態に移行する。

RESTORE DATABASE FOO C FROM DISK = 'e: ＼fulldbbackup.dmp' WITH NORECOVERY

ドライブＣのログは、障害ポイントまで復元され、ドライブＣは回復し、使用可能になる。

コンピューティング装置例
図８および以下の説明は、本発明の実施形態を実施できる適したコンピューティング環境の簡単な概説を提供するためのものである。以下では汎用コンピュータについて説明するが、これは一例にすぎず、本発明の実施形態は、ネットワーク／バスの相互運用性および対話を有するクライアントなど、他のコンピューティング装置により実施することができる。したがって、本発明の実施形態は、例えば機器、他のコンピューティング装置およびオブジェクトなどに配置されているオブジェクトなど、クライアント装置が単にネットワーク／バスへのインターフェースとして働くネットワーク式環境など、非常に小さいまたは最小のクライアントリソースが関与するネットワーク式ホストサービスの環境で実施することができる。本質的に、データを格納できる、またはデータを取り出すことができる場所ならどこでも操作に望ましく、または適した環境である。

必須ではないが、本発明の実施形態は、装置またはオブジェクトのサービスの開発者が使用するように、オペレーティングシステムを介して実施することができ、かつ／またはアプリケーションソフトウェア内に含めることもできる。ソフトウェアは、クライアントワークステーション、サーバ、または他の装置など、１つまたは複数のコンピュータによって実行されるプログラムモジュールなどのコンピュータ実行可能命令の一般的な文脈で説明することができる。一般にプログラムモジュールは、特定のタスクを実行する、または特定の抽象データ型を実装するルーチン、プログラム、オブジェクト、構成要素、データ構造などを含む。一般に、プログラムモジュールの機能を、様々な実施形態で望まれるように結合し、または分散することができる。さらに、本発明の様々な実施形態を他のコンピュータ構成で実施できることを当業者は理解されよう。使用に適したよく知られている他のコンピューティングシステム、環境、および／または構成には、それだけには限定されないが、パーソナルコンピュータ（ＰＣ）、現金自動預け払い機、サーバコンピュータ、ハンドヘルドまたはラップトップ装置、マルチプロセッサシステム、マイクロプロセッサベースのシステム、プログラム可能家庭用電化製品、ネットワークＰＣ、機器、電灯、環境制御要素、ミニコンピュータ、メインフレームコンピュータなどがある。また、本発明の実施形態は、タスクが通信ネットワーク／バスまたは他のデータ通信媒体によってリンクされているリモート処理装置によって実行される分散コンピューティング環境でも実施することができる。分散コンピューティング環境では、プログラムモジュールを、メモリ記憶装置を含むローカルおよびリモートのコンピュータ記憶媒体に置くことができ、クライアントノードはサーバノードとして働くことができる。

したがって図８は、本発明の実施形態を実施に適したコンピューティングシステム環境例８００を示しているが、上記で明らかになったように、コンピューティングシステム環境８００は、適したコンピューティング環境の一例にすぎず、本発明の実施形態の使用または機能の範囲に関する任意の制限を示唆するものではない。また、コンピューティング環境８００を、動作環境８００の例に示した構成要素のいずれか１つ、またはその組合せに関連する任意の依存性または必要条件を有しているものと解釈すべきではない。

図８を参照すると、本発明の実施形態を実施するシステムの例は、汎用コンピューティング装置をコンピュータ８１０の形で含んでいる。コンピュータ８１０の構成要素は、それだけには限定されないが、処理ユニット８２０、システムメモリ８３０、およびシステムメモリを含む様々なシステム構成要素を処理ユニット８２１に結合するシステムバス８２０を含む。システムバス８２１は、様々なバスアーキテクチャのうちの任意のものを使用するメモリバスまたはメモリコントローラ、周辺バス、およびローカルバスを含むいくつかのタイプのバス構造のうちどんなものでもよい。こうしたアーキテクチャには、それだけには限定されないが一例として、業界標準アーキテクチャ（ＩＳＡ）バス、マイクロチャネルアーキテクチャ（ＭＣＡ）バス、拡張ＩＳＡ（ＥＩＳＡ）バス、ビデオ電子装置規格化協会（ＶＥＳＡ）ローカルバス、および（メザニンバスとしても知られている）周辺部品相互接続（ＰＣＩ）バスなどがある。

コンピュータシステム８１０は、一般に様々なコンピュータ可読媒体を含む。コンピュータ可読媒体は、コンピュータシステム８１０からアクセスできる使用可能な任意の媒体とすることができ、揮発性および不揮発性媒体、取外式および固定式媒体を含む。コンピュータ可読媒体は、それだけには限定されないが一例として、コンピュータ記憶媒体および通信媒体を含み得る。コンピュータ記憶媒体には、コンピュータ可読命令、データ構造、プログラムモジュール、他のデータなど、情報を格納するための任意の方法または技術で実施される揮発性および不揮発性の取外式および固定式の媒体がある。コンピュータ記憶媒体には、それだけには限定されないが、ランダムアクセスメモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、電気的消去可能プログラマブル読み取り専用メモリ（ＥＥＰＲＯＭ）、フラッシュメモリまたは他のメモリ技術、コンパクトディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、書き換え可能なコンパクトディスク（ＣＤ−ＲＷ）、デジタル多用途ディスク（ＤＶＤ）または他の光ディスク記憶装置、磁気カセット、磁気テープ、磁気ディスク記憶装置または他の磁気記憶装置、または所望の情報の格納に使用でき、コンピュータシステム８１０からアクセスできる他の任意の媒体などがある。通信媒体は一般に、コンピュータ可読命令、データ構造、プログラムモジュール、または他のデータを搬送波または他の移送機構などの変調されたデータ信号に組み込む。これには任意の情報配送媒体がある。「変調されたデータ信号」という用語は、信号に情報を符号化するように１つまたは複数のその特性が設定または変更された信号を意味する。通信媒体には、それだけには限定されないが一例として、有線ネットワーク、直接配線された接続などの有線媒体、および音響、ＲＦ、赤外線、その他の無線媒体などの無線媒体がある。また、上記のどんな組合せでもコンピュータ可読媒体の範囲内に含まれるものとする。

システムメモリ８３０は、読み取り専用メモリ（ＲＯＭ）８３１やランダムアクセスメモリ（ＲＡＭ）８３２など、揮発性および／または不揮発性メモリの形のコンピュータ記憶媒体を含む。基本入出力システム８３３（ＢＩＯＳ）は、例えば起動中など、コンピュータシステム８１０内の要素間での情報の転送を助ける基本ルーチンを含み、一般にＲＯＭ８３１に格納されている。ＲＡＭ８３２は一般に、処理ユニット８２０から直接アクセス可能な、かつ／または処理ユニット１２０が現在処理しているデータおよび／またはプログラムモジュールを含む。図８は、それだけには限定されないが一例として、オペレーティングシステム８３４、アプリケーションプログラム８３５、他のプログラムモジュール８３６、およびプログラムデータ８３７を示している。

コンピュータシステム８１０は、他の取外式／固定式、揮発性／不揮発性コンピュータ記憶媒体を含むこともできる。一例にすぎないが、図８は、固定式不揮発性磁気媒体から読み取り、あるいはそこに書き込むハードディスクドライブ８４１、取外式不揮発性磁気ディスク８５２から読み取り、あるいはそこに書き込む磁気ディスクドライブ８５１、およびＣＤ−ＲＯＭ、ＣＤ−ＲＷ、ＤＶＤや他の光媒体など、取外式不揮発性光ディスク８５６から読み取り、あるいはそこに書き込む光ディスクドライブ８５５を示している。動作環境の例で使用できる他の取外式／固定式、揮発性／不揮発性コンピュータ記憶媒体には、それだけには限定されないが、磁気テープカセット、フラッシュメモリカード、デジタル多用途ディスク、デジタルビデオテープ、半導体ＲＡＭ、半導体ＲＯＭなどがある。ハードディスクドライブ８４１は一般に、インターフェース８４０などの固定式メモリインターフェースを介してシステムバス８２１に接続され、磁気ディスクドライブ８５１および光ディスクドライブ８５５は一般に、インターフェース８５０などの取外式メモリインターフェースによってシステムバス８２１に接続される。

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

コンピュータシステム８１０は、リモートコンピュータ８８０など１つまたは複数のリモートコンピュータへの論理接続を使用してネットワーク式環境または分散環境で動作することができる。リモートコンピュータ８８０は、パーソナルコンピュータ、サーバ、ルータ、ネットワークＰＣ、ピア装置、または他の一般のネットワークノードでよく、一般にコンピュータシステム８１０に関連して上述した多くまたはすべての要素を含むが、図８にはメモリ記憶装置８８１のみを示している。図８に示した論理接続は、ローカルエリアネットワーク（ＬＡＮ）８７１および広域ネットワーク（ＷＡＮ）８７３を含むが、他のネットワーク／バスを含んでいてもよい。こうしたネットワーキング環境は、家、オフィス、全社規模のコンピュータネットワーク、イントラネット、およびインターネットではごく一般的である。

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

パーソナルコンピューティングおよびインターネットの集合を考慮して、様々な分散コンピューティングフレームワークが開発されており、また開発されつつある。個人および企業のユーザに一様に、アプリケーションおよびコンピューティング装置用のシームレスに相互運用可能なＷｅｂ対応インターフェースが提供され、コンピューティングアクティビティは徐々にＷｅｂブラウザまたはネットワーク指向になる。

例えば、Ｍｉｃｒｏｓｏｆｔ社から入手可能なＭＩＣＲＯＳＯＦＴ（登録商標）の．ＮＥＴ（商標）プラットフォームは、サーバ、Ｗｅｂ対応データ記憶などのビルディングブロックサービス、およびダウンロード可能の装置ソフトウェアを含む。本明細書の実施形態例は、コンピューティング装置に存在するソフトウェアに関して記載しているが、本発明の一実施形態の１つまたは複数の部分は、オペレーティングシステム、アプリケーションプログラミングインターフェース（ＡＰＩ）、またはコプロセッサ、表示装置、および要求側オブジェクトのいずれかの間の「仲介」オブジェクトを介して実施することもでき、したがって操作は、すべての．ＮＥＴ（商標）の言語およびサービスによって実行され、サポートされ、またはそれを介してアクセスされ、また他の分散コンピューティングフレーワームでも実行され得る。

上述したように、本発明の実施形態例は、様々なコンピューティング装置およびネットワークアーキテクチャとの関連で記載しているが、基礎を成す概念は、データベースのパーティション分割された回復システムを実施することが望ましい任意のコンピューティング装置またはシステムに適用することができる。したがって、本発明の実施形態との関連で記載した方法およびシステムは、様々なアプリケーションおよび装置に適用することができる。本明細書ではプログラミング言語例、名前、および例を様々な選択の代表として選択しているが、これらの言語、名前、および例は制限的なものではない。本発明の実施形態によって達成される同じ、類似の、または同等のシステムおよび方法を達成するオブジェクトコードを提供する様々な方法があることを当業者であれば理解されよう。

本明細書に記載した様々な技術を、ハードウェア、ソフトウェア、または必要に応じてその組合せとともに実装することができる。したがって、本発明の方法および装置、またはそのいくつかの態様または部分は、フロッピー（登録商標）ディスク、ＣＲ−ＲＯＭ、ハードドライブ、または他の任意のマシン可読記憶媒体など、有形の媒体に組み込まれるプログラムコード（すなわち命令）の形をとることができ、プログラムコードがコンピュータなどのマシンにロードされ、それによって実行されると、そのマシンは本発明を実施する装置となる。プログラム可能コンピュータ上でプログラムコードを実行する場合、コンピューティング装置は一般に、プロセッサ、プロセッサによって読み取り可能な記憶媒体（揮発性および不揮発性メモリおよび／または記憶要素を含む）、少なくとも１つの入力装置、および少なくとも１つの出力装置を含む。例えば、データ処理ＡＰＩなどの使用を介して本発明の一実施形態の信号処理サービスを使用し得る１つまたは複数のプログラムは、コンピュータと通信するための高レベル手続き型またはオブジェクト指向型のプログラミング言語で実施されることが好ましい。しかし、必要に応じて、プログラムは、アセンブリ言語またはマシン言語で実施することができる。どんな場合でも、言語はコンパイル型またはインタプリタ型言語とすることができ、ハードウェア実装と組み合わせることができる。

本発明の態様を様々な図の好ましい実施形態との関連で説明してきたが、本発明から逸脱することなく本発明の同じ機能を実行するために、他の同様の実施形態を使用したり、記載した実施形態に変更および追加を加えたりすることができることを理解されたい。さらに、特に無線ネットワーク装置の数が増え続けるため、ハンドヘルド装置オペレーティングシステムおよび他のアプリケーション固有のオペレーティングシステムを含む様々なコンピュータプラットフォームが企図されることを強調すべきである。したがって、主張した本発明は、任意の単一の実施形態に限定されるべきではなく、むしろ添付の特許請求の範囲による幅および範囲で解釈すべきである。

パーティション分割された従来技術のデータベースを示すブロック図である。 パーティション分割された従来技術のデータベースを示す別のブロック図である。 本発明のログストリームの態様を示すブロック図である。 本発明のメタデータ構成を示すブロック図である。 本発明の回復ユニットの転送の態様を示すブロック図である。 本発明で具体化される回復ユニットの作成を示すフロー図例である。 データベース間での回復ユニットの転送に使用される本発明の実施形態のフロー図例である。 本発明の態様を実施できるコンピューティング環境例を示すブロック図である。

Claims (6)

1. データベース内に回復可能ユニットを生成する方法であって、
   コンピュータが、前記データベースを第１のユニットおよび第２のユニットにパーティション分割するステップと、
   コンピュータが、前記第１のユニットおよび第２のユニットの論理要素のメタデータを含む１次カタログを作成するステップと、
   コンピュータが、前記第１のユニットおよび第２のユニットにそれぞれ１つのログのみが関連付けられるようにログを作成するステップと、
   コンピュータが、前記第１のユニットの物理要素のメタデータを含む第１の２次カタログと、前記第２のユニットの物理要素のメタデータを含む第２の２次カタログとを作成するステップであって、前記第１のユニットの物理要素は前記第１のユニットに関連づけられたログを含み、前記第２のユニットの物理要素は前記第２のユニットに関連づけられたログを含む、ステップと、
   コンピュータが、前記第１の２次カタログおよび前記第２の２次カタログをそれぞれ特定する情報を前記１次カタログ中のメタデータに含ませることによって、前記１次カタログを前記第１の２次カタログおよび第２の２次カタログにリンクするステップと、
   前記第１のユニットに回復の必要が生じた場合に、コンピュータが、前記第１の２次カタログおよび前記第２の２次カタログをそれぞれ特定する前記情報に基づいて当該第１のユニットの前記第１の２次カタログを特定し、当該第１の２次カタログに対応する前記ログに基づいて、前記第２のユニットとは無関係に前記第１のユニットを回復するステップと
   を含むことを特徴とする方法。
2. １次カタログを作成するステップは、前記データベース、テーブル、インデックス、データ型、制約、ストアドプロシージャ、トリガ、およびファイルグループの中の少なくとも１つのメタデータを含むカタログを作成するステップを含むことを特徴とする請求項１に記載の方法。
3. 前記第１の２次カタログおよび第２の２次カタログを作成するステップは、ページ、ファイル、Ｂツリー、ヒープ、およびログデータのうちの少なくとも１つのメタデータを含むカタログを作成するステップを含むことを特徴とする請求項１に記載の方法。
4. コンピュータに、データベース内に回復可能ユニットを生成させるプログラムを記録したコンピュータ可読記録媒体であって、前記プログラムは、前記コンピュータに、
   データベースを第１のユニットおよび第２のユニットにパーティション分割するステップと、
   前記第１のユニットおよび第２のユニットの論理要素のメタデータを含む１次カタログを作成するステップと、
   前記第１のユニットおよび第２のユニットにそれぞれ１つのログのみが関連付けられるようにログを作成するステップと、
   前記第１のユニットの物理要素のメタデータを含む第１の２次カタログと、前記第２のユニットの物理要素のメタデータを含む第２の２次カタログとを作成するステップであって、前記第１のユニットの物理要素は前記第１のユニットに関連づけられたログを含み、前記第２のユニットの物理要素は前記第２のユニットに関連づけられたログを含む、ステップと、
   前記第１の２次カタログおよび前記第２の２次カタログをそれぞれ特定する情報を前記１次カタログ中のメタデータに含ませることによって、前記１次カタログを前記第１の２次カタログおよび第２の２次カタログにリンクするステップと、
   前記第１のユニットに回復の必要が生じた場合に、前記第１の２次カタログおよび前記第２の２次カタログをそれぞれ特定する前記情報に基づいて当該第１のユニットの前記第１の２次カタログを特定し、当該第１の２次カタログに対応する前記ログに基づいて、前記第２のユニットとは無関係に前記第１のユニットを回復するステップと
   を実行させることを特徴とするコンピュータ可読記録媒体。
5. 前記１次カタログを作成するステップは、前記データベース、テーブル、インデックス、データ型、制約、ストアドプロシージャ、トリガ、およびファイルグループの中の少なくとも１つのメタデータを含むカタログを作成するステップを含むことを特徴とする請求項４に記載のコンピュータ可読記録媒体。
6. 前記第１の２次カタログおよび第２の２次カタログを作成するステップは、ページ、ファイル、Ｂツリー、ヒープ、およびログデータのうちの少なくとも１つのメタデータを含むカタログを作成するステップを含むことを特徴とする請求項４に記載のコンピュータ可読記録媒体。

Images