JP2024512335A - データベース・アクセラレータにおける複製データ変更の非同期的永続性 - Google Patents

Abstract

リンクド・データベースに対するクラッシュ回復のためのコンピュータ実施方法が提供される。リンクド・データベースは、ソースと、関連ターゲット・データベースとを含む。ソース・データベースの選択されたクエリが、ターゲット・データベースに移される。この方法は、ソース・データベースの選択された部分をターゲット・データベースのメモリ内部分のテーブルと同期させることと、メモリ内ターゲット・データベース部分に対する永続的に適用される変更を非同期的かつ永続的に記憶することとを含む。この方法は、ターゲット・データベース・システムのデータベース・クラッシュの際に、利用可能な最新のスナップショットによってメモリ内ターゲット・データベース部分を復元することと、永続ターゲット・データベース・ストレージにおいて利用可能な最新のスナップショットよりも後のタイムスタンプを有するソース・データベース回復ログ・ファイルからの変更をメモリ内ターゲット・データベース部分に適用することとをさらに含む。

Description

本発明は、一般的にデータベースに対するクラッシュ回復に関し、より具体的には、リンクド・データベースに対するクラッシュ回復のためのコンピュータ実施方法に関する。本発明はさらに、リンクド・データベースに対するクラッシュ回復を有するリンクド・データベース・システムと、コンピュータ・プログラム製品とに関する。

大量のデータを管理することは、エンタープライズＩＴ（ｉｎｆｏｒｍａｔｉｏｎ ｔｅｃｈｎｏｌｏｇｙ）組織にとって継続する課題であり続けている。これは（ｉ）ますます増加するデータ量によるものであり、かつ（ｉｉ）多様なデータに対する観点でもある。エンタープライズＩＴシステムには、従来の構造化データに加えて、半構造化データおよびいわゆる非構造化データも大量に記憶される。さらに、より多くなったデータ分析に対する産業要件を満たすために、従来のトランザクション指向データベースに加えて、分析処理に対して最適化された特殊なデータベース・システムが導入されている。他方で、従来のトランザクション・データベースにおいてすべての分析処理を行うことが試みられてきた。しかし、分析処理は、オンライン・トランザクション処理のパフォーマンスに対してあまりにも強力で予測不可能な影響を与えることが明らかになった。

結果として、トランザクション指向データベース管理システムと、分析最適化データベース管理システムとの巧みな組み合わせが導入されてきた。こうした組み合わせ製品の一例は、ＩＢＭ ＤＢ２（ＩＢＭ社の登録商標）分析アクセラレータ（ＩＤＡＡ：ＩＢＭ ＤＢ２ Ａｎａｌｙｔｉｃｓ Ａｃｃｅｌｅｒａｔｏｒ）アーキテクチャに基づくものである。

一方側で、本格的な行ベースのデータベース管理システム（ＤＢＭＳ：ｄａｔａｂａｓｅ ｍａｎａｇｅｍｅｎｔ ｓｙｓｔｅｍ）が、データ操作言語（ＤＭＬ：ｄａｔａ ｍａｎｉｐｕｌａｔｉｏｎ ｌａｎｇｕａｇｅ）動作およびクエリ実行に対するアプリケーション・エンドポイントの働きをしてもよい。ヒューリスティックな決定基準および規則を用いて、クエリ・オプティマイザは、クエリをソースＤＢＭＳにおいて、特にオンライン・トランザクション処理にて実行すべきか、または特にオンライン分析処理のためにターゲットＤＢＭＳにオフロードすべきかを透過的に決定してもよい。

ターゲットＤＢＭＳは、ソースＤＢＭＳテーブルの選択されたセットのシャドウ・コピーを保持する本格的な列ベースのデータベース管理システムであってもよい。ターゲットＤＢＭＳのシャドウ・コピーを作成するための戦略は、ソースＤＢＭＳの１つ以上のテーブルに記憶されたデータを、所与の時点でターゲットＤＢＭＳに移すことを含んでもよい。しかし、ロードがいくらか前に行われ、その間に対応するソース・テーブルが修正されているとき、ターゲットＤＢＭＳ内のクエリ・データが期限切れになるかもしれない。したがって、テーブルの内容は通常、対応するソース・データベース・テーブルにおいて変更が記録される際に増分的に適合される。

どちらのデータベース・システムも、それぞれのデータベースのＡＣＩＤ（原子性、一貫性、独立性、耐久性（ａｔｏｍｉｃ、ｃｏｎｓｉｓｔｅｎｔ、ｉｓｏｌａｔｉｏｎ、ｄｕｒａｂｌｅ））特性を保証するためのトランザクション機構を実装する。すなわち、同時修正はロッキング技術によって適切に分離され、一貫性チェックによってデータベースの状態が１つの一貫した状態から別の状態に移ることが保証されてもよく、トランザクション変更に対する原子性および耐久性を保証するためにたとえばログ先行書込みなどのロギング技術が実装されてもよい。

しかし、ソース・データベースが現在のトランザクションによって修正されるとき、ＡＣＩＤ特性を保証することは顕著なオーバーヘッドをもたらすことがある。特に、ロギングは挿入／更新／削除（ＩＵＤ：ｉｎｓｅｒｔ／ｕｐｄａｔｅ／ｄｅｌｅｔｅ）ステートメントの処理を減速させる。なぜなら、トランザクションを継続し得る前に変更記録を永続記憶媒体に書込む必要があるからである。データベース・テーブルの内容に対する変更の頻繁に使用されるメモリ内処理と比較して、トランザクション・ログを用いてこの持続性レイヤを追加することは比較的低速である。他方で、故障の場合にそれぞれのデータベースの最新の一貫した状態を復元するために、クラッシュ回復が必要とされる。

ＩＤＡＡなどのデータベース・アクセラレータの状況において、ターゲット・アクセラレータ・データベースは、ソース・データベースのスナップショットを単純にミラーリングする。すなわち、ソース・データベースがデータのマスタの役割をしてもよいし、またはＩＵＤを介したデータ操作がソース・データベース管理システムによって処理されて、更新技術を介してターゲット・データベースに変更が複製されてもよい。したがってアクセラレータ・データベースは、高速の分析動作を必要とし得るソース・データベースのパーティションを記憶するためのキャッシュの役割をしてもよい。

この文脈ですでにいくつかの開示が存在する。特許文献１の文書は、クリーン・シャットダウン状態でデータベース・データを複製し、複製データの読取り専用コピーを生成するための方法を記載する。関連するシステムは、データベース・アプリケーションからソース・ストレージ・デバイスへの第１のトランザクションを監視して、そのアプリケーションの既知の良好な状態を示す少なくとも１つのマーカを有するログ・エントリを生成する追跡モジュールを含み得る。このシステムは、データベースおよびログ・ファイルを含むターゲット・ストレージ・デバイスに結合されたコンピュータをさらに含む。このコンピュータはログ・エントリに基づいてトランザクションを処理して、データをターゲット・ストレージ・デバイスに複製し、第１のスナップショットを行って、ログ・ファイルに記憶されたデータをデータベース内に再現する。

加えて特許文献２の文書は、高速のクラッシュ回復を実現する分散型データベース・システムを記載する。データベース・ヘッド・ノード故障からの回復の際に、そのデータベース・ヘッド・ノードによって実装されるデータベースに対するデータを記憶する分散型ストレージ・システムの１つ以上のストレージ・ノードとの接続が確立されてもよい。ストレージ・ノードとの接続の確立の際に、そのデータベースはたとえばさまざまなアクセス要求などに対するアクセスのために利用可能にされてもよい。

しかし、一方側ではトランザクションに対して最適化され、他方側では分析処理に対して最適化される従来の結合データベースはすべて、永続的な回復ログを維持するための公知のオーバーヘッドを必要とすることがあり、それによって、ターゲット・データベースにおけるソース・データベースからの変更の最適化されていない使用に加えて、組み合わされたデータベースの処理が顕著に減速することがある。したがって、組み合わされたトランザクション／分析データベース管理システムに対するより高いパフォーマンス値を達成し、同時にターゲット・データベースの回復の課題をエレガントに解決するために、必要とされるオーバーヘッドを低減させる必要があり得る。

米国特許出願公開第２０１５／０ ２０５ ８５３（Ａ１）号 米国特許出願公開第２０１４／０ ２７９ ９３０（Ａ１）号

本発明の１つの態様によると、リンクド・データベースに対するクラッシュ回復のためのコンピュータ実施方法が提供されてもよい。リンクド・データベースはソース・データベースと、関連ターゲット・データベースとを含んでもよく、ソース・データベースを含むデータベース管理システムに対する選択されたクエリが、処理のためにターゲット・データベースを含むデータベース管理システムに移されてもよい。この方法は、ソース・データベースのテーブルの内容の選択された部分を、ターゲット・データベースのテーブルの内容のそれぞれの部分と同期させることと、同期中に、ソース・データベースの回復ログ・ファイルを用いてターゲット・データベースを含むデータベース管理システムのメモリ内ターゲット・データベース部分にソース・データベースに対する変更を適用することと、メモリ内ターゲット・データベース部分に対する永続的に適用される変更を永続ターゲット・データベース・ストレージに非同期的に記憶することとを含んでもよい。

この方法は、ターゲット・データベース・システムのデータベース・クラッシュの際に、永続ターゲット・データベース・ストレージにおいて利用可能な最新のスナップショットによってメモリ内ターゲット・データベース部分を復元することと、ターゲット・データベース・システムのデータベース・クラッシュの際に、永続ターゲット・データベース・ストレージにおいて利用可能な最新のスナップショットよりも後のタイムスタンプを有するソース・データベース回復ログ・ファイルからの変更をメモリ内ターゲット・データベース部分に適用することとを含んでもよい。

本発明の別の態様によると、リンクド・データベースに対するクラッシュ回復を有するリンクド・データベース・システムが提供されてもよい。リンクド・データベースはソース・データベースと、関連ターゲット・データベースとを含んでもよく、ソース・データベースのテーブルの内容の選択された部分が、ターゲット・データベースのテーブルの内容のそれぞれの部分と同期されてもよい。リンクド・データベース・システムはプロセッサと、プロセッサに通信的に結合されたメモリとを含んでもよく、メモリはプログラム・コード部分を記憶してもよく、このプログラム・コード部分は実行されたときに、プロセッサが、ソース・データベースのテーブルの内容の選択された部分を、ターゲット・データベースのテーブルの内容のそれぞれの部分と同期させることと、同期中に、ソース・データベースの回復ログ・ファイルを用いてターゲット・データベースを含むデータベース管理システムのメモリ内ターゲット・データベース部分にソース・データベースに対する変更を適用することと、メモリ内ターゲット・データベース部分に対する永続的に適用される変更を永続ターゲット・データベース・ストレージに非同期的に記憶することとを可能にする。

加えてメモリは、実行されたときに、プロセッサが、ターゲット・データベース・システムのデータベース・クラッシュの際に、永続ターゲット・データベース・ストレージにおいて利用可能な最新のスナップショットによってメモリ内ターゲット・データベース部分を復元することと、ターゲット・データベース・システムのデータベース・クラッシュの際に、永続ターゲット・データベース・ストレージにおいて利用可能な最新のスナップショットよりも後のタイムスタンプを有するソース・データベース回復ログ・ファイルからの変更をメモリ内ターゲット・データベース部分に適用することとを可能にするプログラム・コード部分を記憶してもよい。

リンクド・データベースに対するクラッシュ回復のための提案されるコンピュータ実施方法は、多数の利点、技術効果、寄与、もしくは改善、またはその組み合わせを提供してもよい。

メモリ内部分に対する更新および変更ならびにクエリは、変更をターゲット・データベースにも永続的に記憶することによる任意の減速を伴わずに継続されてもよい。よって、物理データベース・データ構造のロギングおよび状態記憶は、データベース・トランザクション内のＩＵＤ処理から分離されてもよい。このことは、ターゲット・データベース、特にメモリ内部分に対する変更が行われるときに永続性フェーズがスキップされ、更新動作が付加的な遅延なしに続き得ることを意味する。したがって、ターゲット・データベースのクラッシュ回復のために必要とされ得る記録は、専用の非同期的データ永続性サービスによって非同期的に書込まれてもよい。ＩＵＤトランザクションによって行われた変更はデータのメモリ内表現のみに適用され、そこでそれらの変更は、永続的媒体にすでに記憶されたか否かにかかわらず、ターゲット・データベース、すなわちアクセラレータにオフロードされるデータベース・クエリによって直ちに処理されてもよい。このことは、データベースのＡＣＩＤ特性の耐久性の制約を引き上げることとも解釈されてもよい。

メモリ内データ構造からそれらの永続的対応物に関連する変更が非同期的に書込まれるため、データベース・クラッシュの場合には変更のいくつかがターゲット・データベース・システムにおいて紛失されることがある。したがってクラッシュ回復では、紛失した変更を再現することによって、不完全な可能性のあるスナップショットをソース・データベース・システムと同期させる必要があるかもしれない。他のソリューションではオフロードされたテーブルがバルク・ロード機構によって完全にリロードされないのとは異なり、紛失部分が増分的に回復されてもよい。すなわち、ターゲット・データベースの最新の非同期的に永続的なスナップショットからターゲット・データベース状態が回復されてもよく、回復メタデータの助けによって、どの付加的変更がなおも紛失している可能性があるかが決定される。すなわち、ターゲット・データベースの現在の一貫した状態を最終的に復元するために、ソース・データベースからのどの変更をソース・データベース・システムのトランザクションまたは回復ログ・ファイルからターゲット・データベースによって再現する必要があるかである。

このことによって、ターゲット・データベースのメモリ内部分に一貫した更新状態が再確立されるまで回復プロセスがアクティブである間は、ターゲット・データベースにおける入来クエリを遅延させることが可能になる。回復によって引き起こされる遅延は公知のソリューションと比較するとかなり低いかもしれないが、ターゲット・データベース・システムにおいてデータベース・スナップショットを非同期的に維持するための処理およびストレージのコストはそれより少し高いかもしれない。しかし、これはターゲット・データベース・システムのより高い可用性および短期の回復時間に対しては低価格にすぎない。

ターゲット・データベースに対する変更の非同期の永続ストレージは、ロギングをより効率的に実行することも助けてもよく、たとえばバッチ・プロセスなどによってＩ／Ｏ動作がより効率的に実行されてもよく、または自己相殺される変更が共に削除されてもよい。すなわち、ターゲット・データベースの変更の次の永続ストレージ・ステップの前に回復され得るやり方で変更されたターゲット記録は、ターゲット・データベースと永続記憶媒体との間のバッファにおいて削除され得る。

以下において、方法およびシステムに適用可能な本発明の概念の追加の実施形態が説明されることとなる。

この方法の１つの興味深い実施形態によると、同期させることは、ソース・データベースに関係する回復ログ・ファイルのエントリを読取ることと、読取ったエントリをターゲット・データベースに適用することとを含んでもよい。これは、ターゲット・データベース管理システムの管理部分によって行われてもよい。しかし、同期のための他の技術も用いられてもよく、それはたとえばＳＱＬ（構造化クエリ言語（ｓｔｒｕｃｔｕｒｅｄ ｑｕｅｒｙ ｌａｎｇｕａｇｅ））またはＱ、すなわち列ベースのデータベースに対して最適化されたクエリ（ｑｕｅｒｙ）言語に基づくものなどである。

この方法の１つの有用な実施形態によると、トランザクション、すなわちオンライン・トランザクション処理（ＯＬＴＰ：ｏｎｌｉｎｅ ｔｒａｎｓａｃｔｉｏｎ ｐｒｏｃｅｓｓｉｎｇ）に対してソース・データベースが最適化されてもよく、もしくはソース・データベースは行指向のリレーショナルＤＢＭＳであり、またはその両方である。これは、エンタープライズＩＴ（情報技術）動作の動作バックボーンを表して効率的にサポートしてもよい。行指向データベースは、データベース内のデータに対するバランスの取れた高速の読取り、書込み、および変更動作に対して最適化されてもよい。行指向データベースは、報告を生成するためにも有効であってもよい。しかし、このタイプのデータベースはしばしば、分析タイプの動作にとって最適ではない。

この方法の１つの許容される実施形態によると、分析動作、すなわちオンライン分析処理（ＯＬＡＰ：ｏｎｌｉｎｅ ａｎａｌｙｔｉｃａｌ ｐｒｏｃｅｓｓｉｎｇ）に対してターゲット・データベースが最適化されてもよく、もしくはターゲット・データベースは列指向データベースであってもよく、またはその両方であってもよい。さらなる実施形態によると、このタイプのデータベースは列指向データベースであってもよい。このデータベースは、ＯＬＴＰ最適化データベース・システムよりもかなり良好に、多くの依存性および相互相関を有するクエリをサポートしてもよい。

有利な実施形態によると、この方法は、ターゲット・データベースのクラッシュの場合に、ターゲット・データベースの回復が終了し得るまでターゲット・データベースに対するクエリを遅延させることも含んでもよい。よって、回復プロセスはユーザにとって透過的であってもよい。ユーザは最終的に、自身の分析クエリのわずかな遅延を経験するかもしれない。しかし、複雑な分析クエリに対する応答時間はいずれにしても比較的長いため、ユーザはその遅延にまったく気付かないかもしれない。

任意選択で、ターゲット・データベースの回復プロセスの間に、ソース・データベースによってターゲット・データベースをターゲットとするクエリが実行されてもよい。これはトランザクション中にソース・データベースを少し減速させるかもしれないが、全体的なユーザの満足度に対してこれは許容可能な妥協であろう。

この方法の好ましい実施形態によると、選択されたテーブルを定義するメタデータは、回復ログ・ファイルの一部であってもよい。このやり方で、メモリ内ターゲット・データベースの一般的アーキテクチャが、ソース・データベースの回復ログ・ファイルにおいてすでに定義されていてもよい。このことは、ソース・データベースにミラーリングされるべきテーブルのデータの部分にも当てはまることがある。よって、コンフリクトの状況が起こり得ないように、データ定義に対する単一のソースが用いられてもよい。

この方法の進歩した実施形態によると、永続的に適用される変更の記憶は、メモリ内ターゲット・データベース部分において予め定められた数の変更が完了し得るまで待機することを含んでもよい。予め定められた数は、データベースのセットアップの際に構成可能であってもよく、もしくはデータベース管理システムの動作中にも変更されてもよく、またはその両方であってもよい。しかし、このアプローチの利点は、ターゲット・データベースの分析動作を減速させないことであってもよい。よって、ターゲット・データベースに対する更新のグループが、１回で抽出されて永続的に記憶されてもよい。ターゲット・データベースに対する予め定められた数の変更を用いることに加えて、ターゲット・データベースに対するロードを監視して、ターゲット・データベースに対する分析ロードが比較的低い期間中にターゲット・データベースに対する変更の永続ストレージを実行することも考えられてもよい。

この特徴は、メモリ内部分において予め定められた数の変更が完了するまで待機し得る別個のスレッドまたはプロセス内に実装されてもよい。最後の実行以後に完了した変更のセット内の各変更について、それらの変更がターゲット・データベースの永続データベース部分に持続される。加えて、回復フェーズ中に変更再現点を識別可能にするために、最近持続された変更（たとえばソース・データベース・システム内の最後の対応するブロック記録シーケンス番号など）を記述する関連メタデータも永続的に記憶される。これによって、記憶された最後の一貫して変更されたセットの時点が可能であってもよい。この時点は、ターゲット・データベースの永続的部分からターゲット・データベースのメモリ内部分を回復させて、ソース・データベースの回復ログ・ファイルからターゲット・データベースのメモリ内部分の残りのＩＵＤを増分的に回復させるために有用であってもよい。これらの追加のデータは、ターゲット・データベースの回復が要求される場合に、ソース・データベースまたは増分更新プロセスから要求される。回復プロセスの終わりに、クエリ・プロセッサは「再アクティブ」信号によって、以後クエリがターゲット・データベースから処理され得ることを通知されてもよい。

この方法の別の有利な実施形態によると、メモリ内ターゲット・データベース部分のテーブルまたはそのパーティションを復元することは、データ使用、クエリ優先順位、およびデータ優先順位からなる群より選択される１つによって、回復させることまたは回復を優先順位付けすることまたはその優先順位付けを含んでもよい。

これらのオプションは、以下の段落で詳述される。しかし一般的な概念は、ターゲット・データベースが「再構築中」、すなわち回復モードであってもクエリの実行を可能にするために、回復プロセス中に異なる最適化方法を可能にすることである。これらの最適化オプションは構成可能であってもよく、かつ一般的に１つの実装に組み合わせ可能であってもよい。

この方法の１つの任意選択の実施形態によると、データ使用によって回復を優先順位付けすることは、ターゲット・データベースにおける各テーブルに対するカウンタ、またはそのパーティションに対するカウンタを維持することを含んでもよい。カウンタのカウンタ値は、関連テーブルをいくつのクエリが待機している可能性があるかを示してもよく、最初に最高カウンタ値を有するデータベース・テーブルが１番に復元される。その後、その他のテーブルが続いて回復されてもよい。このオプションは、需要が高いターゲット・データベースのテーブルの迅速な回復を可能にしてもよい。よってユーザには、データベースの完全に回復された部分、すなわち需要が高いテーブルができる限り早くプロビジョニングされてもよい。このオプションは、需要またはデータ使用最適化回復として示されてもよい。

よって、回復プロセスを制御して回復時間を最小化するために、待機クエリのリストが考慮されてもよい。回復が進行している間にターゲット・データベースに新たなデータベース・クエリが到着したときは、そのデータ・アクセスが分析されてもよい。もしそのデータベース・クエリが非回復データにアクセスしなければ、それは直ちに処理されてもよい。そうでないときは、そのクエリは回復状態の一部として待機クエリのリストに登録される。実際にクエリを妨げているテーブルもしくはテーブル・パーティションまたはその両方を優先させた一連の回復動作を導出するために、回復スケジュールによって回復段階が評価される。回復の完了の際に利用可能な回復戦略のうちの１つを介して最も有益な回復動作がスケジュールされてもよく、回復状態が更新されてもよく、回復したテーブルもしくはパーティションまたはその両方に対する待機クエリは、もはや遮断される必要がないときには通知されてもよい。

より詳細な観点において、ターゲット・データベースに対するクラッシュ回復は次のとおりに記載され得る。第１に、ターゲット・データベースにおける既知の回復メタデータを用いることによって回復させる必要のあるテーブルまたはテーブル・パーティションのリスト。第２に、回復させるべきテーブルまたはテーブル・パーティションのリストが回復状態の中に記憶される。第３に、回復させるべきもののリストが空でないときは、以下が実行されてもよい。
（ｉ）リストから次の回復させるべきテーブルもしくはテーブル・パーティションまたはその両方を決定すること、
（ｉｉ）ターゲット・データベースに対して構成された回復戦略を介して回復動作をスケジュールすること、
（ｉｉｉ）回復動作が完了するまで待機すること、
（ｉｖ）回復状態を更新すること、すなわち、回復させるべきテーブル／パーティションをマーク付けし、そのテーブルもしくはテーブル・パーティションまたはその両方を待機しているすべてのクエリの遮断データ・リストからそのテーブル／パーティションを除去すること、および
（ｖ）遮断データ・リストが空になったクエリのリストを決定し、現在そのクエリを処理可能であることをクエリ・プロセッサに通知すること。

それによって、次の回復サイクルに対する次の回復アイテムを動的に算出するための以下に記載されるアルゴリズムを用いて、回復させるべきテーブルもしくはテーブル・パーティションまたはその両方のリストが優先順位キューによって実装されてもよい。回復プロセスを加速させるために、（ｉｉｉ）で言及されるステップが複数のテーブルもしくはテーブル・パーティションまたはその両方に対して並行して実行されてもよい。

回復させるべきテーブルもしくはテーブル・パーティションまたはその両方の決定は、次のとおりに実行されてもよい。
（ｉ）クラッシュ回復プロセスが開始されるとき、遮断テーブルもしくはテーブル・パーティションまたはその両方の空のヒストグラムを作成すること、
（ｉｉ）回復状態において遮断クエリが登録されるとき、そのクエリの遮断エリア・リストにおける各テーブルもしくはテーブル・パーティションまたはその両方に対する使用カウンタを１増加させること、
（ｉｉｉ）次の回復させるべきテーブル／テーブル・パーティションを決定する必要があるとき、最大使用カウンタを有するテーブル／テーブル・パーティションを選択すること、および
（ｉｖ）テーブル／テーブル・パーティション回復動作が終了したとき、対応するヒストグラム・データを除去すること。

この方法の別の任意選択の実施形態によると、クエリ優先順位によって回復を優先順位付けすることは、最高優先順位を有するクエリを受信するデータベース・テーブルを最初に復元することを含んでもよい。こうした優先順位値は、たとえば生産データベース対テスト・データベースなど、データベース・システムに割り当てられてもよいし、個々のクエリに基づいて割り当てられてもよい。このオプションは、クエリ優先順位または単純にデータ優先順位最適化回復として示されてもよい。

この方法のさらなる任意選択の実施形態によると、データ優先順位によって回復を優先順位付けすることは、（少なくとも）２グループのデータベース・テーブルを維持することであって、各グループはユーザの別個のグループに関係する、維持することと、より高い構成グループ優先順位を有するグループのデータベース・テーブルを最初に復元することとを含んでもよい。こうした状況はマルチユーザ／複数グループ／マルチテナント環境において起こってもよく、ここで１つのユーザまたはグループまたはテナントに、クエリに対するより高い優先順位が割り当てられてもよい。たとえば、１つのテナントがデータベース・システムの可用性をより高く保証されていてもよい。こうした場合に、このテナントにはより高い優先順位が割り当てられてもよい。こうしたシナリオは、マルチテナント・データベースがクラウド・コンピューティング・データ・センタにおいて動作されるときに最も良好に機能してもよい。このオプションは、顧客優先順位最適化回復として示されてもよい。

別の興味深い実施形態によると、この方法は、次の回復させるべきテーブルのために回復させるべきデータ・ボリュームを決定することと、回復させるべきボリュームに依存する回復戦略を用いてそのテーブル（単数または複数）を回復させることとをさらに含んでもよい。それによって、回復戦略は増分更新戦略またはバルク更新戦略である。よって、ターゲット・データベースの合計回復時間を最小化するために、どの更新戦略を用いるかがデータベース・テーブル（またはデータベース・テーブルのグループ）ごとに決定されてもよい。このオプションは、時間最適化回復として示されてもよい。

さらに実施形態は、コンピュータもしくは任意の命令実行システムによる使用、またはそれに関連した使用のためのプログラム・コードを提供するコンピュータ使用可能媒体もしくはコンピュータ可読媒体からアクセス可能な、関連コンピュータ・プログラム製品の形態を取ってもよい。この記載の目的のためのコンピュータ使用可能媒体またはコンピュータ可読媒体は、命令実行システム、装置、もしくはデバイスによる使用、またはそれに関連した使用のためのプログラムの記憶、通信、伝播、または移送のための手段を含み得る任意の装置であってもよい。

なお、本発明の実施形態は、異なる主題を参照して記載される。特に、いくつかの実施形態は方法タイプの請求項を参照して記載されるのに対し、他の実施形態は装置タイプの請求項を参照して記載される。しかし、当業者は上記および下記の記載から、別様のことが示されない限り、１つのタイプの主題に属する特徴の任意の組み合わせに加えて、異なる主題に関する特徴の任意の組み合わせ、特に方法タイプの請求項の特徴と装置タイプの請求項の特徴との任意の組み合わせもこの文書に開示されるものとみなされることを推測するだろう。

上記に定義される態様および本発明のさらなる態様は、以後説明される実施形態の例から明らかであり、実施形態の例を参照して説明されるが、本発明はそれに限定されない。

以下の図面を参照して、単なる例として、本発明の好ましい実施形態を説明する。

リンクド・データベースに対するクラッシュ回復のための本発明のコンピュータ実施方法の実施形態を示すブロック図である。 リンクド・データベースの実施形態を示すブロック図である。 ターゲット・データベースがどのように同期されてもよいかの実施形態を示すブロック図である。 より実装に近い形態の提案される概念の実施形態を示すブロック図である。 顧客優先順位最適化回復戦略のためのコンポーネントを含むリンクド・データベース・システムの実施形態を示すブロック図である。 ボリューム最適化回復戦略のためのコンポーネントを含むリンクド・データベース・システムの実施形態を示すブロック図である。 リンクド・データベースに対するクラッシュ回復のためのリンクド・データベース・システムの実施形態を示すブロック図である。 リンクド・データベース・システムを含むコンピュータ・システムの実施形態を示す図である。

この記載の文脈において、以下の慣例、用語、もしくは表現、またはその組み合わせが用いられてもよい。

「クラッシュ回復」という用語は、クラッシュが起こる前のデータベースの状態を再構築するプロセスを示してもよい。クラッシュが起こったとき、データは利用可能でないか、または非一貫性であってもよい。

「リンクド・データベース」という用語は、互いに密接に関係する少なくとも２つのデータベースを示してもよい。この文書の文脈において、リンクド・データベースは、同一のデータを少なくとも部分的に記憶することがあるデータベースとして示されてもよい。他方で、こうした対におけるプライマリ・データベースは、セカンダリ・データベースとは異なるタスクに対して最適化されてもよい。

「ソース・データベース」または「プライマリ・データベース」という用語は、たとえば高速のトランザクション、すなわちオンライン・トランザクション処理などに対して最適化されたデータベースを示してもよい。しかし、こうしたやり方で、すなわちデータに対する高速の読取り、書込み、更新動作に対して最適化されたデータベースは、たとえばオンライン分析処理の場合などにおける多数のテーブルまたは多数のデータを伴う複雑なクエリの実行が低速のことがある。加えて、オンライン分析処理はオンライン・トランザクション処理を減速させることがある。したがって、今言及したタイプのデータベースの高度に最適化されたデータベース管理システムは、タンデムとして正常に機能してもよい。

「ターゲット・データベース」または「セカンダリ・データベース」という用語は、異なるタスクに対して最適化されたデータベースのこうしたタンデムにおける第２のデータベースを示してもよい。本明細書に記載される概念の文脈において、ターゲット・データベースは、オンライン分析処理に対して最適化されてもよい。ターゲット・データベースは、ソース・データベースのテーブルの少なくとも一部およびテーブルのデータの一部を記憶してもよい。加えて、ターゲット・データベースは次の２つの部分を含んでもよい。複雑な多次元のクエリの高速実行のためのメモリ内部分、およびたとえばハード・ディスクまたはフラッシュ・メモリなどのより長期的ストレージにターゲット・データベースのメモリ内部分のテーブルおよびデータを記憶し得る永続的部分である。このやり方で、ターゲット・データベースは、ターゲット・データベースのクラッシュの場合に永続ストレージからその内容のほとんどを回復できるようにされてもよい。

「テーブルの内容の選択された部分」という用語は、ターゲット・データベースにおいて同期してコピーおよび保存され得る、プライマリ・データベースのテーブルの部分のデータの、今言及した部分またはパーティションを示してもよい。

「選択されたクエリ」という用語は、クエリの性質に基づいて、２つのデータベースのうちの一方、特にターゲット・データベースによって実行された方が良いと考えられる、リンクド・データベースに向けられた特定のタイプのクエリを示してもよい。たとえば、クエリ・タイプがオンライン分析処理に関係するとき、そのクエリはターゲット・データベースに転送されてもよく、ソース・データベースによって実行されなくてもよい。

「データベース管理システム」という用語は、通常はハードウェアおよびソフトウェアの組み合わせと、データを記憶する少なくとも１つの関連データベースとにおいて実装される運営／管理システムの組み合わせを示してもよい。

「メモリ内ターゲット・データベース部分」という用語は、コンピュータ・システムのメイン・メモリにデータのほぼすべてを保持し得るターゲット・データベースの部分を示してもよい。ターゲット・データベースのデータベース管理システムは、ターゲット・データベースのメモリ内部分および永続的部分を含んでもよく、この永続的部分は、メモリ内への最後の変更は別として、メモリ内部分の永続的に記憶されたコピーであってもよい。

「永続ターゲット・データベース・ストレージ」という用語は、ターゲット・データベースのデータを永続的に、すなわちメモリ内ストレージの代わりにハード・ディスクまたはフラッシュ・メモリを用いて記憶できるようにされたターゲット・データベース管理システムの部分を記述してもよい。

「最新のスナップショット」という用語は、ターゲット・データベースの最後の一貫して記憶された状態を示してもよい。

「より後のタイムスタンプ」、特により後のタイムスタンプを有する変更という用語は、たとえばターゲット・データベースの永続的部分に記憶された最新のスナップショットよりも時間的に後に作成された可能性のある時間インジケータを含むソース・データベースの回復ログ・ファイルの記録などを示してもよい。

「回復ログ・ファイル」という用語は、データベースにおいて行われる一連のファイル・プロトコル動作、特にデータを修正するすべての動作、すなわち挿入、更新、および削除動作を示してもよい。回復ログ・ファイルは、データベースの完全な再構築を可能にするように設計されてもよい。したがって、データベースのテーブル定義も回復ログ・ファイルの一部であってもよい。

「メタデータ」という用語は、データに関するデータ、特にデータベース中のテーブルのデータの定義と、潜在的にそれらの間の関係とを示してもよい。

以下に、図面の詳細な説明を与えることとする。図面中のすべての命令は概略である。最初に、リンクド・データベースに対するクラッシュ回復のための本発明のコンピュータ実施方法の実施形態のブロック図が与えられる。その後、さらなる実施形態、およびリンクド・データベースに対するクラッシュ回復を有するリンクド・データベース・システムの実施形態が説明されることとなる。

図１は、特にＩＤＡＡアーキテクチャによる、リンクド・データベースに対するクラッシュ回復のためのコンピュータ実施方法１００の好ましい実施形態のブロック図を示し、ここで提供される（１０２）リンクド・データベースは、ソースまたはプライマリ・データベース、特にトランザクションに対して最適化された、たとえば役割ベースのデータベースなど、および関連するターゲットまたはセカンダリ・データベースを含む。このデータベースはオンライン分析処理動作（ＯＬＡＰ）に対して最適化されてもよく、有利には列ベースで組織化されてもよい。

ソース・データベースを含むデータベース管理システムに対する選択されたクエリ、特に分析動作に向けられたクエリが、処理のためにターゲット・データベースを含むデータベース管理システムに移され、すなわちオフロードされる。

加えて方法１００は、ソース・データベースのテーブルの内容の選択された部分（いくつかのデータベースにおいてはテーブルの部分のデータの一部のみ、他の実装においては完全なコピー）を、ターゲット・データベースのテーブルの内容のそれぞれの部分と同期させる（１０４）ことを含み、それは同期中に、ソース・データベースの回復ログ・ファイルを用いて、ターゲット・データベースを含むデータベース管理システムのメモリ内ターゲット・データベース部分にソース・データベースに対する変更を適用する（１０６）ことによって行われる。

加えて方法１００は、メモリ内ターゲット・データベース部分に対する永続的に適用される変更を永続ターゲット・データベース・ストレージ部分に非同期的に記憶する（１０８）ことと、ターゲット・データベース・システムのデータベース・クラッシュの際に、永続ターゲット・データベース・ストレージにおいて利用可能な最新のスナップショットによってメモリ内ターゲット・データベース部分を復元する（１１０）ことと、ターゲット・データベース・システムのデータベース・クラッシュの際に、永続ターゲット・データベース・ストレージにおいて利用可能な最新のスナップショットよりも後のタイムスタンプを有するソース・データベース回復ログ・ファイルからの変更をメモリ内ターゲット・データベース部分に適用する（１１２）こととを含む。

任意選択で、ターゲット・データベースの永続的部分も並行して更新されてもよい。しかしこのためには、ターゲット・データベースのメモリ内部分の変更を永続的に記憶するために、永続ストレージ・プロセスまたはストレージ・プロセッサもアクティブである必要があるだろう。

加えて、特に初期化プロセスの間に、ソース・データベースからターゲット・データベースをバルク・ロードすることが有利な場合がある。これは同等により低速の増分更新または同期プロセスを回避することを助け得る。なぜなら、ソース・データベースはすでにより多数のエントリを有し、よって自身の回復ログ・ファイル内により多数のエントリを有することがあるからである。この初期化は、選択されたテーブルまたはそのパーティションのみに対して有効であってもよい。

図２は、リンクド・データベースの実施形態２００のブロック図を示す。プライマリまたはソース・データベース２０２は、ＯＬＴＰクエリ２１０およびＯＬＡＰクエリ２１４を受信する。ＯＬＡＰクエリ２１４として識別されたクエリは、セカンダリまたはターゲット・データベース２０６に移行またはオフロード２２２される。ソース・データベース２０２は、複数のテーブル２０４と、関連する記憶データとを含む。ターゲット・データベース２０６も、ソース・データベース２０２のデータベース・テーブル２０４の少なくともサブセットを表すテーブルと、そのデータの少なくともサブセットとをデータベース・テーブル２０８中に含む。

ターゲット・データベース２０６によってＯＬＡＰ動作が実行された後、データは返送２２４され、要求するプログラムまたはプロセスにＯＬＡＰ出力２２０が返送される。ＯＬＴＰクエリ２１０はソース・データベース２０２において直接実行され、要求するプログラムまたはプロセスにＯＬＴＰ出力２１２として返送される。よって、ＯＬＴＰまたはソース・データベース２０２は、任意のリソース集約的なＯＬＡＰクエリによって減速されないため、自身の最高パフォーマンスで動作してもよい。

ターゲット・データベース２０６におけるデータ組織が、たとえばソースまたはＯＬＴＰデータベース２０２における行指向の代わりに列指向であるなどして異なる可能性があるため、ターゲット・データベースは、ソース・データベース２０２よりもかなり高速でＯＬＡＰ結果を返送２２４してもよい。

図３は、ターゲット・データベースがどのように同期され得るかの実施形態３００のブロック図を示す。ソース・データベース管理システム３０２は、ソース・データベース２０２およびその関連テーブル２０４の動作を制御する（図２と比較されたい）。ターゲット・データベース管理システム３０８もターゲット・データベース２０６および関連テーブル２０８について同じことが当てはまる。

ソース・データベース管理システム３０２は、ソース・データベース２０２に対する回復ログ・ファイル３０６も維持する。回復ログ・ファイル３０６を読取るログ・リーダーまたはログ・ファイル・リーダー３１４は、これらのデータを適用ユニット３１６に提供し、適用ユニット３１６は、ソース・データベースに対して行われた変更（すなわち挿入、更新、削除）を、ターゲット・データベース２０６の選択されたテーブルおよびデータの選択されたセットに対しても適用する。選択されたテーブルおよびデータの選択されたセットは、予め定義されたとおりのソース・データベース２０２における関連テーブルおよびデータのサブセットであってもよい。適用ユニット３１６は、実行されるＯＬＡＰクエリに依存してターゲット・データベース２０６に対する変更の適用を最適化できる。このためにログ・バッファ３１８が有益であり得る。

ターゲット・データベース２０６の初期化のために、パフォーマンスの理由から、ソース・データベース２０２からターゲット・データベース２０６へのバルク・ロード動作３１２が行われ得る。

なお、本発明の概念を明瞭にする理由から、図３は、ターゲット・データベース管理システムをターゲット・データベース２０６およびそのテーブル２０８のメモリ内部分および永続的部分に分割することをまだ示していない。このことは次の図面で示されることとなる。

なお、この同期機構は多くの同期技術のうちの１つを表すものであってもよい。他の同期技術も適用可能であってもよい。

図４は、より実装に近い形態４００の提案される概念の実施形態のブロック図を示す。ソース・データベースをターゲット・データベースと同期させるために任意選択で使用されるソース・データベース管理システムのエレメント（主に図４の上側の部分）は、再び説明されない。

ターゲット・データベース管理システム３０８は、ターゲット・データベースのメモリ内部分４０２と、ターゲット・データベースの永続的部分４０４とを含む。永続性サービス４０６は、動作中にメモリ内ターゲット・データベース部分４０２の状態を永続データベース４０４に書込む。たとえばメモリ内データベース４０２に予め定められた回数の更新が行われた後などの、こうした規則的な動作の間に、クエリ・プロセッサ４０８は入来するクエリをターゲット・データベースのメモリ内部分４０２に向かわせる。

しかし、ターゲットＤＢＭＳが現在クラッシュ回復を行っているとき、特に要求またはデータ使用最適化回復を行っている場合は、動作が次のとおり異なってくる。
（ｉ）クエリ・プロセッサ４０８は、回復プロセッサ４１０と共にクエリ・データ・アクセスを分析して、ビュー分解技術を解析する最新のクエリを用いて、そのクエリに対して利用可能にする必要があるターゲット・テーブルのリストもしくはテーブル・パーティションのリストまたはその両方を決定する；
（ｉｉ）まだ回復していないと判定された回復状態中の前のステップからのデータ・アクセス・リストのテーブルもしくはテーブル・パーティションまたはその両方のすべてを見ることによって、遮断データ・リストが決定される；
（ｉｉｉ）前のステップからのリストが空でないとき、クエリおよびその遮断データ・リストは待機クエリに追加され、クエリ・プロセスは回復が終了する（遮断データ・リストが空になる）まで待機し、次いでクエリを継続できる；および
（ｉｖ）回復プロセッサ４１０からクエリ・プロセッサ４０８に完了通知が送信された後、ターゲット・データベースのクエリは通常どおりに処理される。

回復プロセッサ４１０が制御する動作の間、関連テーブルもしくはテーブル・パーティションまたはその両方の永続データベース４０４において利用可能な最新の一貫したスナップショットが、ターゲット・データベースのメモリ内部分４０２にロード４１２され、永続データベース４０４のスナップショットよりも後のタイムスタンプを有するソース・データベース２０２の回復ログ・ファイル３０６のエントリがメモリ内データベース４０２に再現される。これらは回復プロセッサ４１０からクエリ・プロセッサ４０８を介して要求され、ソースＤＢＭＳ３０２から、たとえば回復ログ・ファイル３０６からログ・リーダー３１４および適用ユニット３１６を介して提供される。

図５は、顧客優先順位最適化回復戦略のためのコンポーネントを含むリンクド・データベース・システムの実施形態５００のブロック図を示す。ソースＤＢＭＳ５０２は例示的に、（例、クラウド・コンピューティング環境における）第１のユーザまたはテナントの第１のソース・データベース５０４と、第２のユーザまたはテナントの第２のソース・データベース５０６とを有する。加えて、他のユーザまたはテナントに対する別個のソース・データベース・システムが利用可能であってもよい。

ソース・データベース５０４、５０６をメモリ内ターゲット・データベース５１６のそれぞれのメモリ内部分５１８、５２０と同期させるために、データ同期システム５０８内に別個のデータ同期サブシステム５１０、５１２が実装される。クエリ・プロセス５２２は、ターゲット・データベース（単数または複数）５１６のメモリ内部分における実行のためのデータベース・クエリを受信する。これらのクエリは通常、ソース・データベース（単数または複数）５０４、５０６からオフロードされたＯＬＡＰクエリである。

ターゲットＤＢＭＳ５１４の回復プロセスまたはプロセッサ５２４も、データ・アクセス・アナライザ５２６において登録および分析されるべきクエリに関するデータをクエリ・プロセッサから受信する。ターゲット・データベースの回復プロセスの間に、クエリ・アナライザは回復状態管理システム５２８内の待機クエリ５３０およびすでに回復したテーブル・パーティション５３２を決定することによって、特定のユーザのクエリの優先順位に基づいて、どのテーブルを最初に回復させるべきかを決定する。これは最終的に回復スケジュール５３４によって判定および決定される。このタスクを行うために、回復スケジュール５３４は実際の回復状態をチェックするために回復状態管理システム５２８と常時データ交換を行い、ワークロード管理システム構成ストレージから構成データを受信する。さらに回復スケジュール５３４は、データ同期システム５０８ともデータを交換することによって、ソース・データベース管理システム５０２からのターゲット・データベース管理システム回復データベース・ロードを引き起こす。

このやり方で、構成されたより高い優先順位を有するユーザまたは顧客が、回復したデータベース・テーブルに早期にアクセスすることとなることを確実にでき、特定のテーブルのアクセス使用に依存してその回復時間も最適化できる。

詳細には、このことは以下の手順によって達成されてもよい。ターゲット・データベースに対するクラッシュ回復プロセスが初期化されるとき、各テナントに対する遮断されたテーブル／テーブル・パーティションの空のヒストグラムが作成される。回復状態において新たな遮断クエリが登録されるとき、そのクエリの遮断データ・リストにおける各テーブル／パーティションに対する使用カウンタが１増加する。次いで、次の回復させるべきテーブル／パーティションを決定する必要があるとき、遮断されたクエリ使用のカウンタ数と、現在のテナントのＷＬＭ（ワークロード管理システム（ｗｏｒｋｌｏａｄ ｍａｎａｇｅｍｅｎｔ ｓｙｓｔｅｍ））構成（すなわち、その優先順位または重要性）とに基づいてテーブルの回復優先順位が決定され、最高の優先順位を有する回復アイテムが選択される。最後に、テーブル／パーティション回復動作が終了したときに、対応するヒストグラム・エントリも除去される。

ユーザまたはテナントの特定的な回復優先順位の算出は、例示的に以下のとおりに実装され得る。たとえば、生産システムはテスト・システムより重要であること（単純な構成テキストによって指定されてもよい）など、テナントの対の間に厳密な優先順位が存在するとき、回復させるべきテーブル／パーティションのリストはユーザ／テナントによってグループ化され、グループのリストはユーザ／テナント優先順位の低下によって順序付けられ、次のテーブル／パーティションはクエリ使用カウンタ選択アルゴリズムによって、第１の空でないグループから選択される。

しかし、ＷＬＭ構成における各テナントに対する相対的なリソース共有位置（例、テナント１ ５０％、テナント２ ３０％、テナント３ ２０％）が存在するとき、各回復アイテムに対する優先順位は以下のとおりに算出される。（ｉ）回復アイテムに対するクエリ使用カウンタｑを決定する；（ｉｉ）次いで、回復アイテムが属するテナントｔを決定する；（ｉｉｉ）次に、テナントｔに対するリソース共有位置ｒ（ｔ）を決定する；（ｉｖ）それに基づいて優先順位をａ＊ｑ＊ｂ＊ｒ（ｔ）として決定し、ここでａおよびｂは特に［０...１］の範囲の静的構成パラメータであり、ここでパラメータの数を減らすために、ｂはａに基づいて、たとえばｂ＝１－ａとして算出され得る。最後に、（ｖ）たとえば優先順位キューなどにおいて、回復アイテムのリストを優先順位によって順序付けできる。

図６は、ボリューム最適化回復戦略のためのコンポーネントを含むリンクド・データベース・システムの実施形態６００のブロック図を示す。図５によってすでに紹介されたエレメントは、同じ参照番号で示される。左上側に、ソースＤＢＭＳ５０２がソース・データベース５０４および関連する回復ログ・ファイル６０４と共に示される。最初に、ターゲットＤＢＭＳ５１４のメモリ内データベース部分５１６（永続的部分は示されていない）はバルク・ローダー６０２を介してバルクでロードされてもよい。

ターゲットＤＢＭＳ５１４のメモリ内部分５１６に加えて、ここでは他のメタデータ６０８および回復プロセスまたは回復プロセッサ６１４に焦点を合わせてもよい。回復プロセスは、回復アイテム選択ユニット６１６と、変更推定ユニット６１８と、回復スケジュール６２０との少なくとも３つのコンポーネントを含む。回復プロセッサ６１４は、ターゲットＤＢＭＳ５１４のメモリ内データベース部分５１６のテーブルに関する状態情報を収集するために、メモリ内データベース５１６とデータ交換を行う。

すでに上述したとおり、ターゲットＤＢＭＳ側でデータベース・クラッシュが起こった場合、バルク・ロード機構を介して、または増分的に、ソース・データベース５０４からターゲット・データベース５１６を復元する必要がある。加えてここでは、回復させるべきテーブル／テーブル・パーティションが回復プロセス６１４によって動的に選択される。ここで提案される概念は、クラッシュ回復の際に復元する必要があるデータの量を推定または決定することを担う変更推定コンポーネント６１８によって拡張される。したがって、この変更推定コンポーネント６１８は、回復ベースライン・タイムスタンプ以後にソース・データベースにどれほどのデータ変更が蓄積したかを推定するために、データ変更統計を評価する。この情報に基づいて、回復スケジューラ６２０は、回復させるべきテーブル／テーブル・パーティションのデータを復元するために最も効率的なデータ同期方法を選択する。データ変更統計は、ターゲット・データベース（すなわち、メモリ内データベース部分５１６）の増分的またはバルク・ロードを介する規則的な更新処理の間に維持される。変更推定６１８は、回復アイテム選択コンポーネント６１６によって引き起こされてもよい。

回復スケジューラ６２０は、メモリ内データベース部分５１６の回復プロセスを管理するために、バルク・ローダー６０２および増分更新プロセス６０６の細部ともデータ交換を行う。たとえば、メモリ内データベース部分５１６の回復が完了したとき、バルク・ローダー６０２からの回復完了通知が受信される。他方側では、回復スケジューラ６２０がメモリ内データベース部分５１６の特定のテーブルに対する変更再現を要求する。バルク・ローダー６０２からの信号と同様に、回復スケジューラ６２０は増分更新プロセス（プロセッサ）６０６からの回復完了通知も受信する。図３の文脈ですでに説明されたとおり、増分更新プロセス６０６は、回復ログ・ファイル６０４から回復ログ・ファイル・エントリを読取るために適合されたログ・リーダー（ここには示されない）と、ソース・データベース５０４からのそれぞれの回復ログ・ファイル・エントリを用いてメモリ・データベース部分５１６を増分的に更新するために適合された回復ログ・ファイル適用ユニット（ここには示されない）とを含む。詳細については図３に戻って参照されたい。

本明細書に記載される実施形態のプロセスを正常に管理するために、データ変更統計は、ターゲット・データベース・システム５１４のメタデータ６０８に含まれる永続メタデータ・カタログに記憶されるべきであり、かつターゲット・データベース・システム５１４が更新されるとき、すなわち増分更新またはバルク・ロード戦略を介して更新されるときに維持されるべきである。データ変更統計は、以下の情報を記憶してもよい。（ｉ）更新が処理されたときのタイムスタンプ、（ｉｉ）データベース・テーブルのスキーマ情報、たとえば列タイプ、列幅、...、（ｉｉｉ）更新による影響を受けたテーブル／テーブル・パーティション当たりのデータ変更の量、すなわち挿入された記録、および削除された記録、更新された記録；ならびに集約されたメトリック、たとえば変更された記録の総数、適用された合計データ・ボリューム、更新の合計実行時間など。

統計データは、たとえば最後のｘ日間などの時間間隔とリンクされ得る。加えて統計データは、各更新サイクルの一部として増分的に管理されてもよい。

さらに、回復ベースライン６１０は、ターゲット・データベース・システム５１４の永続メタデータ６０８（例、メタデータ・カタログ）でも維持される。回復ベースライン６１０は、復元される必要があるデータ・ボリュームを決定するための推定に必要とされる。したがって、正確なタイムスタンプを決定する必要はなく、その値を推定することで十分であり、たとえば、それは規則的な時間間隔でターゲット・データベース・システムによって更新されるハートビート・タイムスタンプとして維持されてもよいし、それはクラッシュ後の回復プロセスの出発点として維持されてもよいし、それは最後に正常に持続されたターゲット・データベース・スナップショットの時間として維持されてもよい。それによって、タイムスタンプはターゲット・データベースのテーブルごとに維持されてもよい。

ターゲット・データベースに対するクラッシュ回復は、以下のとおりに実行され得る。（ｉ）最初に、次の回復させるべきテーブル／パーティションが決定される；（ｉｉ）回復ベースライン以後の回復させる必要があるデータ・ボリュームが推定される；（ｉｉｉ）推定されたデータ・ボリュームに基づいて最良の回復戦略が選択され、回復時間が推定される；（ｉｖ）次いで、選択された戦略によるテーブルの回復がスケジュールされる；および（ｖ）すべてのデータが回復されるまで、これらのステップがループで繰り返される。

回復させるべきデータ・ボリュームの推定は、以下のとおりに実行されてもよい。（ｉ）回復させるべきテーブル／パーティションに対して、対応するデータ変更統計６１２が探索される；（ｉｉ）そのテーブル／パーティションに対する回復ベースラインが決定される；および（ｉｉｉ）その間隔［回復ベースライン、現在の回復時間］における増分更新プロセスを介して複製する必要がある変更の数が推定される。

図７は、リンクド・データベースに対するクラッシュ回復のためのリンクド・データベース・システム７００の実施形態のブロック図を示す。リンクド・データベース７００はソース・データベース７０６と、関連ターゲット・データベース７０８とを含み、ソース・データベースのテーブルの内容の選択された部分が、ターゲット・データベースのテーブルの内容のそれぞれの部分と同期される。

リンクド・データベース・システム７００はプロセッサ７０２と、プロセッサ７０２に通信的に結合されたメモリ７０４とを含み、メモリ７０４はプログラム・コード部分を記憶しており、このプログラム・コード部分は実行されたときに、プロセッサが、たとえば同期ユニット７１４などを用いて、ソース・データベース７０６のテーブルの内容の選択された部分を、ターゲット・データベース７０８のテーブルの内容のそれぞれの部分と同期させることを可能にする。

記憶されるプログラム・コード部分は実行されたときに、プロセッサ７０２が同期中に適用ユニット７１６を用いて、ソース・データベース７０６に対する変更を、ターゲット・データベースを含むデータベース管理システムのメモリ内ターゲット・データベース部分７１０に適用することと、たとえばストレージ・プロセッサ７１８などによって、メモリ内ターゲット・データベース部分７１２に対して適用された変更を非同期的に永続ターゲット・データベース・ストレージに永続的に記憶することとを可能にする。

さらに、記憶されるプログラム・コード部分は実行されたときに、プロセッサ７０２が、たとえば復元ユニット７２０などによって、ターゲット・データベース・システムのデータベース・クラッシュの際に、永続ターゲット・データベース・ストレージ部分７１２において利用可能な最新のスナップショットによってメモリ内ターゲット・データベース部分７１０を復元することと、たとえば第２の適用ユニット７２２などによって、ターゲット・データベース・システムのデータベース・クラッシュの際に、永続ターゲット・データベース・ストレージ部分７１２において利用可能な最新のスナップショットよりも後のタイムスタンプを有するソース・データベース回復ログ・ファイルからの変更をメモリ内ターゲット・データベース部分７１０に適用することとを可能にする。

なお加えて、リンクド・データベース・システム７００のすべてのモジュールおよびユニットは、信号もしくはデータまたはその両方を交換するために電気的に相互接続されてもよい。このことはプロセッサ７０２、メモリ７０４、ソース・データベース・システム７０６、メモリ内部分７１０および永続的部分７１２を含むターゲット・データベース・システム７０８、同期ユニット７１４、適用ユニット７１６、ストレージ・プロセッサ７１８、復元ユニット７２０、ならびに第２の適用ユニット７２２に適用されてもよい。これらのモジュールおよびユニット間の１：１接続の代わりに、これらは信号伝達データ交換のためのリンクド・データベース・システム内部バス・システム７２４に接続されてもよい。

本発明の実施形態は、プラットフォームがプログラム・コードの記憶もしくは実行またはその両方に適しているかどうかにかかわらず、実質的に任意のタイプのコンピュータと共に実装されてもよい。図８は例として、提案される方法に関するプログラム・コードを実行するために好適なコンピュータ・システム８００を示す。

コンピュータ・システム８００は、好適なコンピュータ・システムの単なる一例であり、コンピュータ・システム８００が上記に示された機能のいずれかの実装もしくは実行またはその両方が可能であるかどうかにかかわらず、本明細書に記載される本発明の実施形態の使用または機能の範囲に関する任意の限定を示唆することは意図されていない。コンピュータ・システム８００には、多数の他の汎用目的または特定目的のコンピュータ・システム環境または構成と共に動作するコンポーネントが存在する。コンピュータ・システム／サーバ８００と共に使用するために好適であり得る周知のコンピュータ・システム、環境、もしくは構成、またはその組み合わせの例は、パーソナル・コンピュータ・システム、サーバ・コンピュータ・システム、シン・クライアント、シック・クライアント、ハンドヘルドまたはラップトップ・デバイス、マルチプロセッサ・システム、マイクロプロセッサ・ベースのシステム、セット・トップ・ボックス、プログラマブル家電機器、ネットワークＰＣ、ミニコンピュータ・システム、メインフレーム・コンピュータ・システム、および上記のシステムまたはデバイスのいずれかを含む分散型クラウド・コンピューティング環境などを含むが、それに限定されない。コンピュータ・システム／サーバ８００は、コンピュータ・システム８００によって実行されるたとえばプログラム・モジュールなどのコンピュータ・システム実行可能命令の一般的な文脈で記載されてもよい。一般的に、プログラム・モジュールは、特定のタスクを実行するか、または特定の抽象データ・タイプを実装するルーチン、プログラム、オブジェクト、コンポーネント、ロジック、およびデータ構造などを含んでもよい。コンピュータ・システム／サーバ８００は、通信ネットワークを通じてリンクされたリモート処理デバイスによってタスクが実行される分散型クラウド・コンピューティング環境において実施されてもよい。分散型クラウド・コンピューティング環境において、プログラム・モジュールは、メモリ・ストレージ・デバイスを含むローカルおよびリモート・コンピュータ・システム記憶媒体の両方に位置してもよい。

図面に示されるとおり、コンピュータ・システム／サーバ８００は汎用目的のコンピュータ・デバイスの形態で示されている。コンピュータ・システム／サーバ８００のコンポーネントは、１つ以上のプロセッサまたは処理ユニット８０２、システム・メモリ８０４、およびシステム・メモリ８０４を含むさまざまなシステム・コンポーネントをプロセッサ８０２に結合するバス８０６を含んでもよいが、それに限定されない。バス８０６は、メモリ・バスまたはメモリ・コントローラ、ペリフェラル・バス、アクセラレーテッド・グラフィクス・ポート、およびさまざまなバス・アーキテクチャのいずれかを用いるプロセッサまたはローカル・バスを含むいくつかのタイプのバス構造のいずれか１つ以上を表す。限定ではなく例として、こうしたアーキテクチャは、インダストリ・スタンダード・アーキテクチャ（ＩＳＡ：Ｉｎｄｕｓｔｒｙ Ｓｔａｎｄａｒｄ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、マイクロ・チャネル・アーキテクチャ（ＭＣＡ：Ｍｉｃｒｏ Ｃｈａｎｎｅｌ Ａｒｃｈｉｔｅｃｔｕｒｅ）バス、拡張ＩＳＡ（ＥＩＳＡ：Ｅｎｈａｎｃｅｄ ＩＳＡ）バス、ビデオ・エレクトロニクス・スタンダーズ・アソシエーション（ＶＥＳＡ：Ｖｉｄｅｏ Ｅｌｅｃｔｒｏｎｉｃｓ Ｓｔａｎｄａｒｄｓ Ａｓｓｏｃｉａｔｉｏｎ）ローカル・バス、およびペリフェラル・コンポーネント・インターコネクト（ＰＣＩ：Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔｓ）バスを含む。コンピュータ・システム／サーバ８００は通常、さまざまなコンピュータ・システム可読媒体を含む。こうした媒体は、コンピュータ・システム／サーバ８００によってアクセス可能な任意の利用可能な媒体であってもよく、それは揮発性および不揮発性媒体、取り外し可能および取り外し不可能媒体の両方を含む。

システム・メモリ８０４は、たとえばランダム・アクセス・メモリ（ＲＡＭ：ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）８０８もしくはキャッシュ・メモリ８１０またはその両方などの、揮発性メモリの形のコンピュータ・システム可読媒体を含んでもよい。コンピュータ・システム／サーバ８００はさらに、他の取り外し可能／取り外し不可能な揮発性／不揮発性コンピュータ・システム記憶媒体を含んでもよい。単なる例として、取り外し不可能な不揮発性磁気媒体（示されておらず、通常は「ハード・ドライブ」と呼ばれる）からの読取りおよびそこへの書込みのために、ストレージ・システム８１２が提供されてもよい。示されていないが、取り外し可能な不揮発性磁気ディスク（例、「フレキシブル・ディスク」）からの読取りおよびそこへの書込みのための磁気ディスク・ドライブ、ならびにたとえばＣＤ－ＲＯＭ、ＤＶＤ－ＲＯＭ、またはその他の光媒体などの取り外し可能な不揮発性光ディスクからの読取りまたはそこへの書込みのための光ディスク・ドライブが提供されてもよい。こうした場合に、各々は１つ以上のデータ媒体インターフェースによってバス８０６に接続され得る。以下にさらに示されて説明されることとなるとおり、メモリ８０４は、本発明の実施形態の機能を実行するように構成されたプログラム・モジュールのセット（例、少なくとも１つ）を有する少なくとも１つのプログラム製品を含んでもよい。

限定ではなく例として、プログラム・モジュール８１６のセット（少なくとも１つ）を有するプログラム／ユーティリティ、ならびにオペレーティング・システム、１つ以上のアプリケーション・プログラム、その他のプログラム・モジュール、およびプログラム・データがメモリ８０４に記憶されてもよい。オペレーティング・システム、１つ以上のアプリケーション・プログラム、その他のプログラム・モジュール、およびプログラム・データ、またはその何らかの組み合わせの各々は、ネットワーク形成環境の実装を含んでもよい。プログラム・モジュール８１６は一般的に、本明細書に記載される本発明の実施形態の機能もしくは方法またはその両方を実行する。

コンピュータ・システム／サーバ８００は、たとえばキーボード、ポインティング・デバイス、ディスプレイ８２０などの１つ以上の外部デバイス８１８；ユーザがコンピュータ・システム／サーバ８００と対話することを可能にする１つ以上のデバイス；もしくはコンピュータ・システム／サーバ８００が１つ以上の他のコンピュータ・デバイスと通信することを可能にする任意のデバイス（例、ネットワーク・カード、モデムなど）；またはその組み合わせとも通信してもよい。こうした通信は、入力／出力（Ｉ／Ｏ：Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）インターフェース８１４を介して生じ得る。さらに、コンピュータ・システム／サーバ８００は、ネットワーク・アダプタ８２２を介して、たとえばローカル・エリア・ネットワーク（ＬＡＮ：ｌｏｃａｌ ａｒｅａ ｎｅｔｗｏｒｋ）、一般的な広域ネットワーク（ＷＡＮ：ｗｉｄｅ ａｒｅａ ｎｅｔｗｏｒｋ）、もしくはパブリック・ネットワーク（例、インターネット）、またはその組み合わせなどの１つ以上のネットワークと通信してもよい。示されるとおり、ネットワーク・アダプタ８２２は、バス８０６を介してコンピュータ・システム／サーバ８００のその他のコンポーネントと通信してもよい。示されていないが、他のハードウェアもしくはソフトウェア・コンポーネントまたはその両方が、コンピュータ・システム／サーバ８００と共に使用され得ることが理解されるべきである。その例は、マイクロコード、デバイス・ドライバ、冗長処理ユニット、外部ディスク・ドライブ・アレイ、ＲＡＩＤシステム、テープ・ドライブ、およびデータ・アーカイバル・ストレージ・システムなどを含むが、それに限定されない。

加えて、リンクド・データベースに対するクラッシュ回復を有するリンクド・データベース・システム７００がバス・システム８０６に取り付けられてもよい。

本発明のさまざまな実施形態の説明は例示の目的のために提供されたものであるが、開示される実施形態に対して網羅的または限定的になることは意図されていない。記載される実施形態の範囲から逸脱することなく、当業者には多くの修正および変更が明らかになるだろう。本明細書で使用される用語は、実施形態の原理、実際の適用、または市場で見出される技術に対する技術的改善を最もよく説明するため、または他の当業者が本明細書で開示される実施形態を理解できるようにするために選択されたものである。

本発明はシステム、方法、もしくはコンピュータ・プログラム製品、またはその組み合わせとして具現化されてもよい。コンピュータ・プログラム製品は、プロセッサに本発明の態様を実行させるためのコンピュータ可読プログラム命令を有するコンピュータ可読記憶媒体（または複数の媒体）を含んでもよい。

媒体は、伝播媒体のための電子、磁気、光学、電磁気、赤外、または半導体のシステムであってもよい。コンピュータ可読媒体の例は半導体または固体メモリ、磁気テープ、取り外し可能コンピュータ・ディスケット、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリ・メモリ（ＲＯＭ：ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ）、剛性磁気ディスク、および光ディスクを含んでもよい。光ディスクの現在の例は、コンパクト・ディスク・リード・オンリ・メモリ（ＣＤ－ＲＯＭ：ｃｏｍｐａｃｔ ｄｉｓｋ－ｒｅａｄ ｏｎｌｙ ｍｅｍｏｒｙ）、コンパクト・ディスク読取り／書込み（ＣＤ－Ｒ／Ｗ：ｃｏｍｐａｃｔ ｄｉｓｋ－ｒｅａｄ／ｗｒｉｔｅ）、ＤＶＤ、およびＢｌｕ－Ｒａｙ（Ｒ）ディスクを含む。

コンピュータ可読記憶媒体は、命令実行デバイスによって使用するための命令を保持および記憶できる有形デバイスであり得る。コンピュータ可読記憶媒体は、たとえば電子ストレージ・デバイス、磁気ストレージ・デバイス、光ストレージ・デバイス、電磁気ストレージ・デバイス、半導体ストレージ・デバイス、または前述の任意の好適な組み合わせなどであってもよいが、それに限定されない。コンピュータ可読記憶媒体のより具体的な例の非網羅的なリストは以下を含む。ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、リード・オンリ・メモリ（ＲＯＭ）、消去可能プログラマブル・リード・オンリ・メモリ（ｅｒａｓａｂｌｅ ｐｒｏｇｒａｍｍａｂｌｅ ｒｅａｄ－ｏｎｌｙ ｍｅｍｏｒｙ）（ＥＰＲＯＭまたはフラッシュ・メモリ）、スタティック・ランダム・アクセス・メモリ（ＳＲＡＭ：ｓｔａｔｉｃ ｒａｎｄｏｍ ａｃｃｅｓｓ ｍｅｍｏｒｙ）、ポータブル・コンパクト・ディスク・リード・オンリ・メモリ（ＣＤ－ＲＯＭ）、デジタル多用途ディスク（ＤＶＤ：ｄｉｇｉｔａｌ ｖｅｒｓａｔｉｌｅ ｄｉｓｋ）、メモリ・スティック、フレキシブル・ディスク、機械的にコード化されたデバイス、たとえばパンチ・カードまたは記録された命令を有する溝の中の隆起構造体など、および前述の任意の好適な組み合わせ。本明細書において用いられるコンピュータ可読記憶媒体は、たとえば電波もしくはその他の自由に伝播する電磁波、導波路もしくはその他の伝送媒体を通じて伝播する電磁波（例、光ファイバ・ケーブルを通過する光パルス）、またはワイヤを通じて伝送される電気信号など、それ自体が一時的な信号であると解釈されるべきではない。

本明細書に記載されるコンピュータ可読プログラム命令は、コンピュータ可読記憶媒体からそれぞれのコンピューティング／処理デバイスにダウンロードされ得るか、あるいはたとえばインターネット、ローカル・エリア・ネットワーク、広域ネットワーク、もしくはワイヤレス・ネットワーク、またはその組み合わせなどのネットワークを介して外部コンピュータまたは外部ストレージ・デバイスにダウンロードされ得る。ネットワークは銅伝送ケーブル、光伝送ファイバ、ワイヤレス伝送、ルータ、ファイアウォール、スイッチ、ゲートウェイ・コンピュータ、もしくはエッジ・サーバ、またはその組み合わせを含んでもよい。各コンピューティング／処理デバイス内のネットワーク・アダプタ・カードまたはネットワーク・インターフェースは、ネットワークからコンピュータ可読プログラム命令を受信して、そのコンピュータ可読プログラム命令をそれぞれのコンピューティング／処理デバイス内のコンピュータ可読記憶媒体に記憶するために転送する。

本発明の動作を実行するためのコンピュータ可読プログラム命令はアセンブラ命令、命令セット・アーキテクチャ（ＩＳＡ：ｉｎｓｔｒｕｃｔｉｏｎ－ｓｅｔ－ａｒｃｈｉｔｅｃｔｕｒｅ）命令、マシン命令、マシン依存命令、マイクロコード、ファームウェア命令、状態設定データ、または１つ以上のプログラミング言語の任意の組み合わせで書かれたソース・コードもしくはオブジェクト・コードであってもよく、このプログラミング言語はオブジェクト指向プログラミング言語、たとえばＳｍａｌｌｔａｌｋ、またはＣ＋＋など、および従来の手続き型プログラミング言語、たとえば「Ｃ」プログラミング言語または類似のプログラミング言語などを含む。コンピュータ可読プログラム命令は、すべてがユーザのコンピュータで実行されてもよいし、スタンドアロン・ソフトウェア・パッケージとして部分的にユーザのコンピュータで実行されてもよいし、一部がユーザのコンピュータで、一部がリモート・コンピュータで実行されてもよいし、すべてがリモート・コンピュータまたはサーバで実行されてもよい。後者のシナリオにおいて、リモート・コンピュータは、ローカル・エリア・ネットワーク（ＬＡＮ）または広域ネットワーク（ＷＡＮ）を含む任意のタイプのネットワークを通じてユーザのコンピュータに接続されてもよいし、（たとえば、インターネット・サービス・プロバイダを用いてインターネットを通じて）外部コンピュータへの接続が行われてもよい。いくつかの実施形態において、たとえばプログラマブル・ロジック回路、フィールド・プログラマブル・ゲート・アレイ（ＦＰＧＡ：ｆｉｅｌｄ－ｐｒｏｇｒａｍｍａｂｌｅ ｇａｔｅ ａｒｒａｙｓ）、またはプログラマブル・ロジック・アレイ（ＰＬＡ：ｐｒｏｇｒａｍｍａｂｌｅ ｌｏｇｉｃ ａｒｒａｙｓ）などを含む電子回路は、本発明の態様を行うために電子回路をパーソナライズするためのコンピュータ可読プログラム命令の状態情報を使用することによって、コンピュータ可読プログラム命令を実行してもよい。

本明細書においては、本発明の実施形態による方法、装置（システム）、およびコンピュータ・プログラム製品のフローチャート図もしくはブロック図またはその両方を参照して、本発明の態様を説明している。フローチャート図もしくはブロック図またはその両方の各ブロック、およびフローチャート図もしくはブロック図またはその両方におけるブロックの組み合わせは、コンピュータ可読プログラム命令によって実装され得ることが理解されるだろう。

これらのコンピュータ可読プログラム命令は、汎用目的のコンピュータか、特定目的のコンピュータか、またはマシンを生成するためのその他のプログラマブル・データ処理装置のプロセッサに提供されることによって、そのコンピュータまたはその他のプログラマブル・データ処理装置のプロセッサを介して実行される命令が、フローチャートもしくはブロック図またはその両方の単数または複数のブロックにおいて指定される機能／動作を実装するための手段を生じてもよい。これらのコンピュータ可読プログラム命令は、コンピュータ、プログラマブル・データ処理装置、もしくはその他のデバイス、またはその組み合わせに特定の方式で機能するように指示できるコンピュータ可読記憶媒体にも記憶されることによって、命令が記憶されたコンピュータ可読記憶媒体が、フローチャートもしくはブロック図またはその両方の単数または複数のブロックにおいて指定される機能／動作の態様を実装する命令を含む製造物を含んでもよい。

コンピュータ可読プログラム命令は、コンピュータ、他のプログラマブル・データ処理装置、または別のデバイスにもロードされて、コンピュータに実装されるプロセスを生成するためにコンピュータ、他のプログラマブル装置、または他のデバイスにおいて一連の動作ステップを行わせることによって、そのコンピュータ、他のプログラマブル装置、または別のデバイスにおいて実行される命令が、フローチャートもしくはブロック図またはその両方の単数または複数のブロックにおいて指定される機能／動作を実装してもよい。

図面におけるフローチャートもしくはブロック図またはその両方は、本発明のさまざまな実施形態によるシステム、方法、およびコンピュータ・プログラム製品の可能な実装のアーキテクチャ、機能、および動作を示すものである。これに関して、フローチャートまたはブロック図の各ブロックは、命令のモジュール、セグメント、または一部分を表してもよく、これは指定される論理機能（単数または複数）を実装するための１つ以上の実行可能命令を含む。いくつかの代替的実装において、ブロック内に示される機能は、図面に示されるものとは異なる順序で起こってもよい。たとえば、連続して示される２つのブロックは、実際には実質的に同時に実行されてもよく、または関与する機能に依存して、これらのブロックがときには逆の順序で実行されてもよい。加えて、ブロック図もしくはフローチャート図またはその両方の各ブロック、およびブロック図もしくはフローチャート図またはその両方のブロックの組み合わせは、指定された機能もしくは動作を行うか、または特定目的のハードウェアおよびコンピュータ命令の組み合わせを実行する特定目的のハードウェア・ベースのシステムによって実装され得ることが注目されるだろう。

本明細書において用いられる用語は、単に特定の実施形態を説明する目的のためのものであり、本発明を限定することは意図されていない。本明細書において用いられる単数形「ａ」、「ａｎ」、および「ｔｈｅ」は、文脈が別様を明確に示さない限り複数形も含むことが意図される。この明細書において用いられるときの「含む（ｃｏｍｐｒｉｓｅｓ）」もしくは「含んでいる（ｃｏｍｐｒｉｓｉｎｇ）」またはその両方の用語は、記述される特徴、整数、ステップ、動作、エレメント、もしくはコンポーネント、またはその組み合わせの存在を特定するが、１つ以上の他の特徴、整数、ステップ、動作、エレメント、コンポーネント、もしくはそのグループ、またはその組み合わせの存在または付加を除外しないことがさらに理解されるだろう。

以下の請求項におけるすべての手段またはステップ・プラス機能要素に対応する構造、材料、動作、および均等物は、特定的に請求される他の請求要素と組み合わせてその機能を行うための任意の構造、材料、または動作を含むことが意図される。本発明の説明は例示および説明の目的のために提供されているが、開示される形の本発明に対して網羅的または限定的になることは意図されていない。本発明の範囲から逸脱することなく、当業者には多くの修正および変更が明らかになるだろう。実施形態は、本発明の原理および実際の適用を最もよく説明し、かつ他の当業者が予期される特定の使用に好適であるようなさまざまな修正を伴うさまざまな実施形態に対して本発明を理解できるようにするために、選択されて記載されたものである。

簡潔には、本発明の概念が以下の項目に要約されてもよい。

１．リンクド・データベースに対するクラッシュ回復のためのコンピュータ実施方法であって、リンクド・データベースがソース・データベースと、関連ターゲット・データベースとを含み、ソース・データベースを含むデータベース管理システムに対する選択されたクエリが、処理のためにターゲット・データベースを含むデータベース管理システムに移される、この方法が、
－ ソース・データベースのテーブルの内容の選択された部分を、ターゲット・データベースのテーブルの内容のそれぞれの部分と同期させることと、
－ 同期中に、ターゲット・データベースを含むデータベース管理システムのメモリ内ターゲット・データベース部分にソース・データベースに対する変更を適用することと、
－ メモリ内ターゲット・データベース部分に対する永続的に適用される変更を永続ターゲット・データベース・ストレージに非同期的に記憶することと、
－ ターゲット・データベース・システムのデータベース・クラッシュの際に、永続ターゲット・データベース・ストレージにおいて利用可能な最新のスナップショットによってメモリ内ターゲット・データベース部分を復元することと、
－ ターゲット・データベース・システムのデータベース・クラッシュの際に、永続ターゲット・データベース・ストレージにおいて利用可能な最新のスナップショットよりも後のタイムスタンプを有するソース・データベース回復ログ・ファイルからの変更をメモリ内ターゲット・データベース部分に適用することとを含むもの。

２．項目１による方法であって、同期させることが、
－ ソース・データベースに関係する回復ログ・ファイルのエントリを読取ることと、読取ったエントリをターゲット・データベースに適用することとを含むもの。

３．項目１または２による方法であって、ソース・データベースがトランザクションに対して最適化されるか、もしくはソース・データベースが行指向リレーショナル・データベース管理システムであるか、またはその両方であるもの。

４．先行する項目のいずれかによる方法であって、ターゲット・データベースが分析動作に対して最適化されるか、もしくはターゲット・データベースが列指向データベースであるか、またはその両方であるもの。

５．先行する項目のいずれかによる方法であって、
－ ターゲット・データベースのクラッシュの場合に、ターゲット・データベースの回復が終了するまでターゲット・データベースに対するクエリを遅延させることをさらに含むもの。

６．先行する項目のいずれかによる方法であって、選択されたテーブルを定義するメタデータが、回復ログ・ファイルの一部であるもの。

７．先行する項目のいずれかによる方法であって、永続的に適用される変更を記憶することが、
－ メモリ内ターゲット・データベース部分において予め定められた数の変更が完了するまで待機することを含むもの。

８．先行する項目のいずれかによる方法であって、メモリ内ターゲット・データベース部分のテーブルを復元することが、データ使用、クエリ優先順位、およびデータ優先順位からなる群より選択される１つによって、回復を優先順位付けすることを含むもの。

９．項目８による方法であって、データ使用によって回復を優先順位付けすることが、
－ ターゲット・データベースにおける各テーブルに対するカウンタを維持することであって、カウンタのカウンタ値は関連テーブルをいくつのクエリが待機しているかを示す、維持することと、
－ 最初に最高カウンタ値を有するデータベース・テーブルを１番に復元することとを含むもの。

１０．項目８または９による方法であって、クエリ優先順位によって回復を優先順位付けすることが、
－ 最高優先順位を有するクエリを受信するデータベース・テーブルを最初に復元することを含むもの。

１１．項目８～１０のいずれかによる方法であって、データ優先順位によって回復を優先順位付けすることが、
－ ２グループのデータベース・テーブルを維持することであって、各グループはユーザの別個のグループに関係する、維持することと、
－ より高い構成グループ優先順位を有するグループのデータベース・テーブルを最初に復元することとを含むもの。

１２．先行する項目のいずれかによる方法であって、
－ 次の回復させるべきテーブルのために回復させるべきデータ・ボリュームを決定することと、
－ 回復させるべきボリュームに依存する回復戦略を用いてそのテーブルを回復させることであって、回復戦略は増分更新戦略またはバルク更新戦略である、回復させることとをさらに含むもの。

１３．リンクド・データベースに対するクラッシュ回復を有するリンクド・データベース・システムであって、リンクド・データベースはソース・データベースと、関連ターゲット・データベースとを含み、ソース・データベースのテーブルの内容の選択された部分が、ターゲット・データベースのテーブルの内容のそれぞれの部分と同期され、このリンクド・データベース・システムが、
－ プロセッサと、プロセッサに通信的に結合されたメモリとを含み、メモリはプログラム・コード部分を記憶しており、このプログラム・コード部分は実行されたときに、プロセッサが
－ ソース・データベースのテーブルの内容の選択された部分を、ターゲット・データベースのテーブルの内容のそれぞれの部分と同期させることと、
－ 同期中に、ターゲット・データベースを含むデータベース管理システムのメモリ内ターゲット・データベース部分にソース・データベースに対する変更を適用することと、
－ メモリ内ターゲット・データベース部分に対する永続的に適用される変更を永続ターゲット・データベース・ストレージに非同期的に記憶することと、
－ ターゲット・データベース・システムのデータベース・クラッシュの際に、永続ターゲット・データベース・ストレージにおいて利用可能な最新のスナップショットによってメモリ内ターゲット・データベース部分を復元することと、
－ ターゲット・データベース・システムのデータベース・クラッシュの際に、永続ターゲット・データベース・ストレージにおいて利用可能な最新のスナップショットよりも後のタイムスタンプを有するソース・データベース回復ログ・ファイルからの変更をメモリ内ターゲット・データベース部分に適用することとを可能にするもの。

１４．項目１３によるリンクド・データベース・システムであって、プログラム・コード部分は、プロセッサが
－ 同期のために、ソース・データベースに関係する回復ログ・ファイルのエントリを読取ることと、読取ったエントリをターゲット・データベースに適用することとをさらに可能にするもの。

１５．項目１３または１４によるリンクド・データベース・システムであって、ソース・データベースがトランザクションに対して最適化されるか、もしくはソース・データベースが行指向リレーショナル・データベース管理システムであるか、またはその両方であるもの。

１６．項目１３～１５のいずれかによるリンクド・データベース・システムであって、ターゲット・データベースが分析動作に対して最適化されるか、もしくはターゲット・データベースが列指向データベースであるか、またはその両方であるもの。

１７．項目１３～１６のいずれかによるリンクド・データベース・システムであって、プログラム・コード部分は、プロセッサが
－ ターゲット・データベースのクラッシュの場合に、ターゲット・データベースの回復が終了するまでターゲット・データベースに対するクエリを遅延させることをさらに可能にするもの。

１８．項目１３～１７のいずれかによるリンクド・データベース・システムであって、選択されたテーブルを定義するメタデータが、回復ログ・ファイルの一部であるもの。

１９．項目１３～１８のいずれかによるリンクド・データベース・システムであって、プログラム・コード部分は、プロセッサが
－ 永続的に適用される変更を記憶するために、メモリ内ターゲット・データベース部分において予め定められた数の変更が完了するまで待機することをさらに可能にするもの。

２０．項目１３～１９のいずれかによるリンクド・データベース・システムであって、メモリ内ターゲット・データベース部分のテーブルを復元することが、データ使用、クエリ優先順位、およびデータ優先順位からなる群より選択される１つによって、回復を優先順位付けすることを含むもの。

２１．項目２０によるリンクド・データベース・システムであって、プログラム・コード部分は、データ使用によって回復を優先順位付けすることに対して、プロセッサが
－ ターゲット・データベースにおける各テーブルに対するカウンタを維持することであって、カウンタのカウンタ値は関連テーブルをいくつのクエリが待機しているかを示す、維持することと、
－ 最初に最高カウンタ値を有するデータベース・テーブルを１番に復元することとをさらに可能にするもの。

２２．項目２０または２１によるリンクド・データベース・システムであって、プログラム・コード部分は、クエリ優先順位によって回復を優先順位付けすることに対して、プロセッサが
－ 最高優先順位を有するクエリを受信するデータベース・テーブルを最初に復元することをさらに可能にするもの。

２３．項目２０～２２のいずれかによるリンクド・データベース・システムであって、プログラム・コード部分は、データ優先順位によって回復を優先順位付けすることに対して、プロセッサが
－ ２グループのデータベース・テーブルを維持することであって、各グループはユーザの別個のグループに関係する、維持することと、
－ より高い構成グループ優先順位を有するグループのデータベース・テーブルを最初に復元することとをさらに可能にするもの。

２４．項目１３～１５のいずれかによるリンクド・データベース・システムであって、プログラム・コード部分は、プロセッサが
－ 次の回復させるべきテーブルのために回復させるべきデータ・ボリュームを決定することと、
－ 回復させるべきボリュームに依存する回復戦略を用いてそのテーブルを回復させることであって、回復戦略は増分更新戦略またはバルク更新戦略である、回復させることとをさらに可能にするもの。

２５．リンクド・データベースに対するクラッシュ回復を有するリンクド・データベース・システムに対するコンピュータ・プログラム製品であって、リンクド・データベースはソース・データベースと、関連ターゲット・データベースとを含み、ソース・データベースのテーブルの内容の選択された部分が、ターゲット・データベースのテーブルの内容のそれぞれの部分と同期され、前記コンピュータ・プログラム製品が、具現化されるプログラム命令を有するコンピュータ可読記憶媒体を含み、前記プログラム命令が１つ以上のコンピュータ・システムまたはコントローラによって実行可能であることによって、前記１つ以上のコンピュータ・システムに、
－ ソース・データベースのテーブルの内容の選択された部分を、ターゲット・データベースのテーブルの内容のそれぞれの部分と同期させることと、
－ 同期中に、ターゲット・データベースを含むデータベース管理システムのメモリ内ターゲット・データベース部分にソース・データベースに対する変更を適用することと、
－ メモリ内ターゲット・データベース部分に対する永続的に適用される変更を永続ターゲット・データベース・ストレージに非同期的に記憶することと、
－ ターゲット・データベース・システムのデータベース・クラッシュの際に、永続ターゲット・データベース・ストレージにおいて利用可能な最新のスナップショットによってメモリ内ターゲット・データベース部分を復元することと、
－ ターゲット・データベース・システムのデータベース・クラッシュの際に、永続ターゲット・データベース・ストレージにおいて利用可能な最新のスナップショットよりも後のタイムスタンプを有するソース・データベース回復ログ・ファイルからの変更をメモリ内ターゲット・データベース部分に適用することとを行わせるもの。

Claims (25)

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. リンクド・データベースに対するクラッシュ回復を有するリンクド・データベース・システムに対するコンピュータ・プログラム製品であって、前記リンクド・データベースはソース・データベースと、関連ターゲット・データベースとを含み、前記ソース・データベースのテーブルの内容の選択された部分が、前記ターゲット・データベースのテーブルの前記内容のそれぞれの部分と同期され、前記コンピュータ・プログラム製品が、具現化されるプログラム命令を有するコンピュータ可読記憶媒体を含み、前記プログラム命令が１つ以上のコンピュータ・システムまたはコントローラによって実行可能であることによって、前記１つ以上のコンピュータ・システムに、
    前記ソース・データベースのテーブルの内容の選択された部分を、前記ターゲット・データベースのテーブルの内容のそれぞれの部分と同期させることと、
    前記同期中に、前記ターゲット・データベースを含むデータベース管理システムのメモリ内ターゲット・データベース部分に前記ソース・データベースに対する変更を適用することと、
    前記メモリ内ターゲット・データベース部分に対する永続的に適用される変更を永続ターゲット・データベース・ストレージに非同期的に記憶することと、
    前記ターゲット・データベース・システムのデータベース・クラッシュの際に、前記永続ターゲット・データベース・ストレージにおいて利用可能な最新のスナップショットによって前記メモリ内ターゲット・データベース部分を復元することと、
    前記ターゲット・データベース・システムの前記データベース・クラッシュの際に、前記永続ターゲット・データベース・ストレージにおいて利用可能な最新のスナップショットよりも後のタイムスタンプを有する前記ソース・データベース回復ログ・ファイルからの変更を前記メモリ内ターゲット・データベース部分に適用することと
    を行わせる、コンピュータ・プログラム製品。

Images