JP4028820B2 - コンピュータ・システムでのトランザクションの選択的キャッシングの方法および装置 - Google Patents

Description

【０００１】
【発明の属する技術分野】
本発明は、全般的にはディジタル・データ処理に関し、具体的には、ディジタル・コンピュータ・システムでのデータベース管理に関する。
【０００２】
【従来の技術】
近代のコンピュータ・システムには、通常は、中央処理装置（ＣＰＵ）と、通信バスおよびメモリなど、情報の保管、検索、および転送に必要なサポートするハードウェアが含まれる。近代のコンピュータ・システムには、入出力コントローラまたはストレージ・コントローラなど、外部の世界と通信するのに必要なハードウェア、キーボード、モニタ、磁気テープ・ドライブ、ディスク・ドライブ、ネットワークに接続された通信信号線など、外部と通信するハードウェアに接続された装置も含まれる。ＣＰＵは、システムの心臓部である。ＣＰＵは、コンピュータ・プログラムを含む命令を実行し、他のシステム構成要素の動作を指示する。
【０００３】
コンピュータのハードウェアの観点からは、ほとんどのシステムが、基本的に同一の形で動作する。プロセッサは、算術演算、論理比較、ある位置から別の位置へのデータの移動など、非常に単純な動作の限られた組を実行することができる。しかし、動作のそれぞれが、非常にすばやく実行される。膨大な数のこれらの単純な動作を実行するようにコンピュータに指示するプログラムによって、コンピュータが何か洗練されたことを行っているという幻想がもたらされる。コンピュータ・システムの新しい能力または改善された能力としてユーザが知覚するものは、基本的には非常に単純な動作の同一の組を、非常に高速に実行することによって可能になる。したがって、コンピュータ・システムに対する改善を継続することは、これらのシステムをさらに高速にすることを必要とする。
【０００４】
コンピュータ・システムは、互いに相互作用する多数の構成要素を有する非常に複雑な機械である。ＣＰＵは、推進機関であるが、システムの総合的速度またはスループットは、ＣＰＵを待たせるかＣＰＵに追加の作業負荷を課すさまざまな他の構成要素によって影響される可能性がある。たとえば、ＣＰＵがメモリからのデータを必要とする場合に、ＣＰＵは、メモリにアクセスするために数サイクル待たなければならない場合がある。ＣＰＵが、メモリ内ではなく、ハード・ディスクなどのストレージ・デバイスに保管されたデータを必要とする場合には、ＣＰＵは、オペレーティング・システム機能を実行して、ストレージ内のデータにアクセスし、オペレーティング・システムは、しばしば、ストレージからのデータを待っている間に、実行を別のタスクまたはスレッドに切り替える。これらの動作は、必ずしもＣＰＵをアイドルにさせるのではないが、システム性能に影響する可能性がある追加の作業負荷をＣＰＵに課す。これらの動作によって、遅延も導入され、これによって、コンピュータと対話する人間が長時間応答を待つことになる可能性がある。
【０００５】
多くのより大きいコンピュータ・システムが、主にまたは大体はデータベース・アプリケーションをサポートするのに使用される。データベース・アプリケーションは、大量のデータを編成し、アクセスし、保守するプログラムである。通常、データベース・アプリケーションは、複数のユーザからの要求をサービスして、読み取りまたは更新のいずれかのためにデータベース内の少量の情報にアクセスする。これらのアクセスは、必ずしも順次の順序で行われるのではなく、データベースのランダムな部分に巻き散らされたように見える場合がある。データベースは、通常は非常に大きいので、データベース全体またはその大部分でさえ、常時メイン・メモリ内に保持することは、一般に実行不能である。したがって、データベース・アプリケーションは、通常は、多数のストレージ・アクセス動作という特徴があり、そのほとんどが、個別には小さく、システムのストレージ・アドレスにまたがって分散される。これらの条件の下で、コンピュータ・システムの性能は、ストレージ・デバイスの集合としての性能に大きく依存する。
【０００６】
より高速のストレージ・ハードウェアによって、多くの場合に、大規模データベースのサービスに使用されるコンピュータ・システムの性能が改善されるが、ストレージ・ハードウェア特性の所与の組について、ストレージ・アクセス動作の数を減らすこと、ストレージ・ハードウェアが忙しくない時にいくつかの動作を実行すること、または使用可能なストレージ・ハードウェアをより効率的に使用することのいずれかによって、性能を改善することが、さらに可能である。
【０００７】
データベース変更をサポートする周知の方法の１つが、ジャーナリングである。ジャーナリングには、１つまたは複数の特殊なストレージ・デバイスまたはストレージ・デバイスの特殊な部分に、変更動作を順次書き込むことが含まれる。ジャーナリングは、実行されるストレージ動作の数を減らすのではなく、ストレージ・ハードウェアをより効率的に使用するという原理に基づいて動作する。具体的に言うと、通常のストレージ・デバイスは、回転式磁気ディスク・ドライブである。ディスク・ドライブへの少量のランダム・アクセスについて、データにアクセスするのに必要な時間のほとんどが、トラックへのシーク動作（シーク）および所望の角度位置までディスクが回転するのを待つこと（待ち時間）に費やされる。しかし、データが、必ず順次（次のセクタまたはトラックに）書き込まれる場合に、これらのシーク時間および待ち時間が、事実上除去され、同一の量のデータを、はるかに短い時間間隔で書き込むことができる。残念ながら、順次書込は、ジャーナル内のデータが、データベースの編成構造に従って編成されていないことを意味する。したがって、ジャーナリングは、データを不揮発性ストレージ・デバイスに一時的に保管するに過ぎない。最終的に、同一のデータ更新を、ストレージ内の編成されたデータ（オリジナル・コピー）に対して実行しなければならず、これは、一般に、多数の少量の書込動作を意味する。変更されたデータは、通常は、不揮発性ストレージのオリジナル・コピーに対する更新が結果として起こるまで、メモリ内で保持される。この更新は、ジャーナリングされたデータが異なる形で編成されるので、メモリ内のデータから実行される。ジャーナル・データをより長くメモリ内に保持することによって、ディスク上のジャーナル・データのオリジナル・コピーへの書込アクセスの総数が減る。というのは、連続的なジャーナル・データを収容したメモリ・ページが、最終的なストレージへの書込が実行される前に、複数回更新される可能性があるからである。他の場合には、この遅延されたバッファリングによって、ストレージ・デバイスがより忙しくない時にストレージ書込動作を実行できるようになるか、複数の書込動作を組み合わせられるようになるか、ストレージ書込動作に対する効率的な改善の他の形が可能になる。
【０００８】
多数の大規模近代コンピュータ・システムの設計目標の１つが、データ保存または冗長性すなわち、システム誤動作（停電などの外部の原因または構成要素故障などの内部の原因のいずれかに起因する）の結果としてデータが失われてはならないことである。もう１つの設計目標が、可用性すなわち、システムをできる限りユーザにとって使用可能にすることである。いくつかの場合に、一定の可用性の必要がある、すなわち、システムを、何が起ころうとも、常に使用可能になるように設計しなければならない。他のシステムでは、ある長さのダウン・タイム、またはシステムが低い性能で動作するある長さの時間が、許容可能である場合がある。
【０００９】
【発明が解決しようとする課題】
一般に、一方ではデータ保存と可用性の間、もう一方ではデータ保存と生産的な作業に関するハードウェア・リソースの最大限の利用の間に、なんらかのトレードオフがある。ジャーナリングは、この原理の１例である。ジャーナルでは、データを不揮発性位置に保管し、構造化された不揮発性ストレージへの変更されたデータの書込を保留することによってデータ保存および可用性を機能強化するが、ジャーナリング自体は、ストレージ・デバイスおよびサポートするハードウェアの形のハードウェア・リソースを必要とし、バス、チャネル、およびプロセッサなどの他のリソースの使用可能帯域幅の一部を消費する可能性がある。この原理のもう１つの例として、「ＲＡＩＤ」（redundant array of independent disksを意味する）と称するさまざまな方式のどれかで複数のストレージ・デバイスに冗長な形でデータを保管することが周知であるが、このような方式のすべてが、冗長性を達成するために、ディスクの記憶容量の一部を犠牲にし、いくつかの場合に、非冗長記憶方式と比較した時にストレージ・アクセス時間に悪影響を及ぼす可能性がある。
【００１０】
ジャーナルを実施する形にも、さらなる設計トレードオフがある。すべてのデータベース変更項目が、即座にジャーナル・ディスクに書き込まれる場合に、ジャーナルは、多数の少量の書込動作という重荷を負う。通常、いくつかのジャーナル変更項目が、メモリ内でバッファリングまたはキャッシングされ、その結果、複数の項目が、一時にジャーナルに書き込まれるようになる。ジャーナルへの書込の前にキャッシングされる項目の数が多いほど、書込の回数と、その結果のシステム性能への影響が減る。しかし、ジャーナル項目を不揮発性ストレージに書き込む前に待つ時間が長くなるほど、ジャーナルの有益な効果が減る、すなわち、より多くのデータが露出される。
【００１１】
必ずしも認められてはいないが、これらの競合する考慮事項を管理し、その結果、システムが、適度なレベルの性能、可用性、およびデータ保存を達成するようにする手段の必要が存在する。
【００１２】
【課題を解決するための手段】
データベース・マネージャが、動的に変化するシステムの状態変数である動的選択判断基準に基づいて、あるデータベース変更に関するジャーナル項目を選択的にキャッシングする。少なくとも１つの選択判断基準が、システム・クラッシュの場合の回復の推定時間である。更に選択判断基準としてシステムまたはそのいくつかの構成要素の現在の性能を含めてもよい。一般に、システムが忙しいほど、より多くのデータがキャッシングされ、逆も同様である。したがって、ジャーナルへの書込動作の性能的重荷は、削減が最も必要な時に減らされ、システムがそれに最もよく耐えられる時に増やされる。
【００１３】
好ましい実施形態では、データベースに対する変更を保管するジャーナル・ディスク・ストレージ・デバイスが提供される。データベース変更項目は、順次形式でメイン・メモリ・ジャーナル・バッファにキャッシングされ、ジャーナル書込を待つ。ジャーナル・バッファが満杯になる時に、バッファ内容が、ジャーナル・ディスクに書き込まれる。しかし、ある種の変更動作によって、バッファの内容が、バッファが充てんされるのを待たずに、即座にジャーナル・ディスクに書き込まれる。いくつかの場合に、データベース変更項目のタイプによって、自動的にバッファがジャーナルに書き込まれるようになる。他のデータベース変更項目では、動的選択判断基準に応じて、選択的にバッファが書き込まれる。これらの選択判断基準で、システム・クラッシュの場合の回復の推定時間と、システムでのアクティビティの現在のレベルの両方を考慮に入れることが好ましい。
【００１４】
ジャーナル・バッファを空にする時を選択的に決定することによって、このシステムは、忙しくない時により頻繁にバッファを空にし（したがって、回復時間露出が減る）、より忙しい時に、より低い頻度でバッファを空にする（したがって、性能が最もクリティカルである時の追加書込動作の性能上の重荷が減る）。
【００１５】
【発明の実施の形態】
本発明の詳細は、その構造および動作の両方に関して、添付図面に関して最もよく理解することができ、図面では、同様の符号が同様の部分を指す。
【００１６】
図面を参照すると、同様の符号は複数の図面を通じて同様の部分を示すが、図１に、好ましい実施形態との一貫性を有する、データベース情報のリポジトリとして働くコンピュータ・システム１００の高水準ブロック図が示されている。コンピュータ・システム１００には、１つまたは複数の中央処理装置（ＣＰＵ）１０１、メモリ１０２、データ・ストレージ・インターフェース１０３、端末インターフェース１０４、入出力装置インターフェース１０５、および外部ネットワーク・インターフェース１０６が含まれる。さまざまな装置は、内部通信バス１１０を介して互いに通信する。ＣＰＵ１０１は、汎用プログラマブル・プロセッサであり、メモリ１０２に保管された命令を実行する。図１には単一のＣＰＵが示されているが、複数のＣＰＵを有するコンピュータ・システムを使用できることを理解されたい。メモリ１０２は、データおよびプログラムが保管される、ランダム・アクセス揮発性メモリであり、メモリは、概念的に単一のモノリシックなエンティティとして図示されているが、メモリが、しばしば、キャッシュおよび他のメモリ・デバイスの階層として配置されることと、異なるキャッシュを複数ＣＰＵシステムの異なるＣＰＵに関連付けることができることを理解されたい。データ・ストレージ・インターフェース１０３は、１つまたは複数のデータ・ストレージ・デバイスへの接続を提供し、これらのデータ・ストレージ・デバイスは、他のタイプのデータ・ストレージを使用することができるが、回転式磁気ハード・ディスク・ユニットであるジャーナル・ディスク１１１およびデータ・ストレージ１１２から１１５であることが好ましい。端末インターフェース１０４は、１つまたは複数の接続された端末またはワークステーションとの間でデータを伝送するための接続を提供する。これは、さまざまな形で実施することができる。多くの大型コンピュータ・システム（メインフレーム）が、通常は１つまたは複数の電子回路カードである端末インターフェース入出力プロセッサを介する複数の端末の直接接続をサポートする。その代わりに、端末インターフェース１０４が、ローカル・エリア・ネットワークへの接続を提供することができる。さまざまな他の代替案が可能である。入出力装置インターフェース１０５は、１つまたは複数の入出力装置（ストレージ、端末、および外部ネットワーク以外）への接続を提供する。入出力装置は、考えられるところでは、コンピュータ・システムに接続された任意のタイプの装置とすることができる。そのような装置の例が、プリンタ、スキャナ、磁気ストライプ・リーダー、特殊目的センサ、サーボ・コントローラ、スイッチ、などである。外部ネットワーク・インターフェース１０６は、インターネットなどの外部ネットワークとの間のデータの伝送の物理接続を提供し、任意のさまざまな使用可能な技術を使用することができる。データベース動作を実行するクライアントを、インターネットまたは他のリモート・ネットワーク接続を介してリモートに接続することが可能である。内部通信バス１１０は、異なる装置の間でのデータ、コマンド、および他の情報の転送をサポートし、簡略化された形で単一のバスとして図示されているが、通常は、複数のバスとして構成され、階層的な形または他の形で配置することができる。図１に示されたコンピュータ・システムは、例示のための簡略化された表現であることを意図され、上で具体的に述べたものに加えて、システム構成の多数の変形形態が可能であることを理解されたい。具体的に言うと、装置の数およびタイプを変更することができ、データ・ストレージ・インターフェース１０３、端末インターフェース１０４、入出力装置インターフェース１０５、および外部ネットワーク・インターフェース１０６を、それぞれ複数の機能ハードウェア・ユニットで実施するか、統合された複数機能ユニットに組み合わせられることを理解されたい。コンピュータ・システム１００のリソースは、論理的に区分することができるが、そうする必要はない。コンピュータ・システム１００は、考えられるところでは、単一ユーザのパーソナル・コンピュータ・システムとすることができるが、大規模データベースは、より一般的に、より大型のマルチユーザ・コンピュータ・システムでサポートされる。好ましい実施形態では、コンピュータ・システム１００が、IBM AS/400またはe-Server I/Seriesアーキテクチャであるが、本発明を他のコンピュータ・システムでも実施できることを理解されたい。
【００１７】
図１の図および以下の説明において、ジャーナル・ディスク１１１は、ジャーナル・ドライブを表し、データ・ストレージ１１２から１１５は、具体的には構造化された形での１つまたは複数のデータベースの保管を含む、一般的なデータ・ストレージに使用されるドライブを表す。「構造化された形」とは、データがあるタイプの編成された構造を有し、これによって、既知のレコードが見つかるまでレコードの順序付けられない集合を読み取るのではなく、既知のデータベース・レコードに直接にアクセスできることを意味する。データベースの編成構造は、大幅に異なる可能性があり、一部のデータベースが、複数の異なるパラメータ値によるデータベース・レコードの判定を可能にする複数の索引を有する場合がある。単一のジャーナル・ディスク１１１および４つのデータ・ストレージ１１２から１１５が図１に示されているが、ドライブの実際の数を変更できること、特に複数のジャーナル・ドライブを設けることができることを理解されたい。さらに、一般に「ＲＡＩＤ」と称するさまざまな冗長ストレージ技法に従ってパリティまたは他の冗長データを保管するために、またはドライブ障害の場合に使用される「ホット・スペア」ドライブとして、追加ドライブを設けることができる。１つまたは複数のドライブが二重機能を有し、そのような二重機能ドライブのストレージ域の一部を、ジャーナルに使用し、別の部分を、一般的なデータまたはホット・スペア・ストレージ・デバイスなどの他の機能に使用することも可能である。
【００１８】
図２は、メモリ１０２内のコンピュータ・システム１００の主要なソフトウェア構成要素の概念図である。オペレーティング・システム２０１が、当技術分野で周知のように、装置インターフェース、メモリ・ページの管理、複数タスクの管理など、さまざまな低水準ソフトウェア機能を提供する。データベース２０２に、データが含まれ、このデータは、コンピュータ・システム１００によって維持され、このシステムが、このデータに関して、１つまたは複数のユーザにアクセスを提供し、ユーザは、コンピュータ・システム１００に直接に接続されるか、クライアント／サーバ・アクセス・プロトコルを使用してネットワークを介してコンピュータ・システム１００にアクセスするリモート・クライアントとすることができる。当技術分野で周知のように、データベース２０２には、複数のレコードが含まれ、各レコードに、少なくとも１つ（通常は多数）のフィールドが含まれる。データベース２０２には、コンピュータ・システムのユーザに提供される、ほとんどすべてのタイプのデータを含めることができる。データベース２０２に関連するのが、複数のデータベース索引２０３および２０４であり、各索引が、ある指定された判断基準によるデータベース２０２内のレコードの順序付けを表す。ユーザの一部によるデータへのアクセスを、読取専用とすることができるが、データベース内のデータを更新する少なくともいくつかの機能がある。図２には、１つのデータベース２０２および２つのデータベース索引２０３および２０４だけが図示されているが、コンピュータ・システムに、複数のデータベースを含めることができ、索引の数を変更することができる（通常ははるかに多い）。代替案では、コンピュータ・システム１００のデータベース２０２を、論理的に、複数のコンピュータ・システムに保管されるより大きい分散データベースの一部とすることができる。
【００１９】
データベース管理システム２１１は、データベース２０２の管理の基本機能を提供する。データベース管理システム２１１は、理論的には、任意の数のデータベースをサポートすることができるが、図２には１つだけが示されている。データベース管理システム２１１は、データベースの定義、データベースの定義の変更、データベース内のレコードの作成、編集、および除去、データベース内のレコードの表示、データベース索引の定義などの基本的なデータベース動作をユーザが実行できるようにすることが好ましい。データベース管理システム２１１に、さらに、さまざまなより高度なデータベース機能を含めることができる。データベース管理システム２１１は、オペレーティング・システム２０１内に完全に含めることができ、あるいは、オペレーティング・システム２０１から分離することができ、あるいは、その一部をオペレーティング・システム２０１内、それ以外の部分を別にすることができる。
【００２０】
データベース管理システム２１１に加えて、ＣＰＵ１０１で実行される１つまたは複数のユーザ・アプリケーション２１２および２１３が、データベース２０２のデータにアクセスして、１つまたは複数のユーザの代わりにタスクを実行することができる。そのような他のユーザ・アプリケーションには、たとえば、ワード・プロセッシング、会計、コード開発およびコンパイル、メール、予定管理、または膨大な数のユーザ・アプリケーションのどれでも含めることができる。これらのアプリケーションの一部は、読取専用の形でデータベースにアクセスでき、他のアプリケーションは、データを更新する能力を有する。多数異なるタイプの読取または書込のデータベース・アクセス・タスクがあり、これらのタスクそれぞれが、異なるデータにアクセスするか、データに対する異なる動作を要求する。たとえば、１つのタスクが、特定の既知のレコードからのデータにアクセスし、任意選択としてそれを更新することができ、もう１つのタスクが、照会の性質を持つことができ、この場合に、データベース内のすべてのレコードが、指定された検索判断基準と突き合わされ、一致したレコードからのデータが返され、任意選択として更新される。さらに、データを、データベース２０２から直接に読み取るか直接に書き込むことができ、あるいは、操作されるかユーザによって供給される、別のデータベースまたは他の何らかのソースから得られる他のデータと組み合わされることを必要とする場合がある。２つのユーザ・アプリケーション２１２および２１３だけが例示のために図２に示されているが、そのようなアプリケーションの数は、変更することができる。データベース２０２にアクセスするユーザ・アプリケーション２１２および２１３は、オペレーティング・システム機能呼出しを使用してデータベース２０２内のデータにアクセスすることができ、あるいは、データベース２０２内のデータに独立にアクセスすることができる。
【００２１】
好ましい実施形態では、データベース管理システム２１１に、ジャーナル・マネージャ機能２１５が含まれ、このジャーナル・マネージャ機能２１５が、データベース変更動作のジャーナリングを処理する。ジャーナリングを意図されたデータベース変更項目は、メモリ内で１つまたは複数のジャーナル・バッファ（ブロック）２０６および２０７内でディスク書込のために組み立てられ、このバッファから、ディスク・ストレージに書き込まれる。２つのジャーナル・バッファ・ブロック２０６および２０７が図２に示されているが、そのようなバッファの数は、変更することができる。ジャーナル・マネージャは、ジャーナル・バッファ２０６および２０７へのデータベース変更の書込を処理し、バッファ内のデータのジャーナル・ディスク１１１への最終的な書込を処理する。ジャーナル・マネージャ機能２１５の挙動を、本明細書で詳細に説明する。
【００２２】
図２のソフトウェア構成要素は、概念的にメモリに常駐するものとして図示されているが、一般に、コンピュータ・システムのメモリは、すべてのプログラムおよびデータを同時に保持するには小さすぎ、情報が、通常は、回転式磁気ディスク・ドライブなどの１つまたは複数の大容量記憶装置を含むデータ・ストレージ１１２から１１５に保管され、情報が、必要に応じてオペレーティング・システムによってメモリにページングされることを理解されたい。具体的に言うと、データベース２０２は、通常は、メモリにロードするには大きすぎ、通常は、データベース・レコードの総数のごくわずかな部分だけが、一時にメモリにロードされる。完全なデータベース２０２は、通常は、データ・ストレージ１１２から１１５に記録される。
【００２３】
本発明の好ましい実施形態によれば、ジャーナル・バッファ２０６および２０７の使用は、動的に管理され、その結果、バッファが、コンピュータ・システムの現在の状態およびバッファに記録されたあるトランザクションの消失からの回復の潜在的な回復時間に応じて、選択的に空にされるようになる。具体的に言うと、データベース２０２に対する変更は、ジャーナル・バッファ２０６および２０７内の項目として配置され、最終的に、データ・ストレージ１１２から１１５内のデータベースへの書込の前に、ジャーナル・ディスク１１１に書き込まれる。ジャーナル・バッファ２０６および２０７は、選択されたイベントの発生時に空にされる。これらのイベントの一部は、ユーザ・アプリケーションによって指示することができ、現在のシステムまたはジャーナル・バッファの状態に関連しない。他のイベントは、ジャーナル・マネージャ機能２１５の制御下にあり、ジャーナル・マネージャ機能２１５は、システム状態およびジャーナル状態を考慮に入れて、システム性能、回復時間、データ露出などの競合する要因の間での動的な平衡を達成することができる。一般に、ジャーナル・マネージャは、システムが忙しくない場合に直ちにバッファを空にし、システムがより忙しい場合にはバッファを空にすることを延期する傾向を有する。この動作のモードを、図３から５を参照して本明細書で詳細に説明する。
【００２４】
図３は、好ましい実施形態による、データベースに対する変更を引き起こすデータベース・トランザクションを入力する一般化された処理を示す高水準流れ図である。通常のそのようなデータベース・トランザクションは、データベース内の１つまたは複数の新規レコードの作成、データベース内の１つまたは複数の既存レコードの１つまたは複数のフィールドの変更、またはデータベース内の１つまたは複数のレコードの削除になる可能性がある。データベース変更は、ユーザ・アプリケーション２１２および２１３を介して、またはデータベース管理システム２１１を介して入力することができる。データベース変更を他の形で、たとえば、新しいフィールドの定義、新しい索引の定義などによって引き起こすことも可能であるが、これらの変更は、より一般的でない。
【００２５】
図３からわかるように、データベース・トランザクションは、一般に、影響される１つまたは複数のデータベース・レコードが識別され、アクセスされることを必要とする（ステップ３０１）。新規レコードが作成される場合に、これは、ユーザ・アプリケーション２１２および２１３またはデータベース管理システム２１１から入力されるデータを受け取る空白のレコード・テンプレートの生成だけを意味する場合がある。１つまたは複数のレコードが修正される、より一般的な場合に、これは、一般に、ディスク・ストレージからレコードにアクセスし、それらをデータベース２０２のうちのメモリ１０２内の部分にロードすることを意味する。当技術分野で既知のように、レコードの識別には、レコードの表示されるリストからレコードまたはレコードの選択範囲を一意に識別するフィールド値のユーザ入力だけが含まれる場合がある。その一方で、１つまたは複数のレコードの識別が、たとえば、論理照会が、定式化され、照会の検索判断基準と一致するレコードを見つけるためにデータベース内の複数の（おそらくはすべての）レコードと比較される、はるかに複雑な操作になる場合がある。ステップ３０１は、現在既知であるか将来に開発されるそのような技法のすべてを表すことが意図されている。影響されるレコードの数は少ないが、処理のためにすべてのレコードがメモリ１０２にロードされることが期待される。しかし、一部のトランザクションは、非常に広範囲または複雑なので、影響されるレコードのごく一部が、一時にメモリにロードされる。
【００２６】
１つまたは複数のデータベース・レコードを識別した後に、識別されたレコードが、ユーザの要求に応じて変更される（ステップ３０２）。変更は、１つまたは複数のフィールドのマニュアルの編集になる場合があり、あるいは、複数のレコードの複数のフィールドがあるグローバル判断基準に従って訂正される自動化された処理になる場合、あるいは、データがなんらかの他のソースからレコードにインポートされる処理になる場合がある。
【００２７】
ユーザは、任意選択として、図３で破線の輪郭内のステップ３０３として表されるように、１つまたは複数のデータベース・レコードに対する１つまたは複数の変更が、即座に「コミット」されなければならないトランザクションを構成することを指定することができる。そのような変更のグループを、「明示コミット」または「ハード・コミット」と称する。そのような指定の効果は、本明細書でさらに説明するが、グループのすべての変更が、永久的データベースに一緒にコミットされ、グループの最後の変更の入力または作成の際に、すべての変更が、メモリ常駐ジャーナル・バッファの現在の状態に無関係に、ジャーナルを収容するディスクに即座に書き込まれることである。ユーザが、ある変更の組ができる限り早く永久的データベースの一部になることを保証するか、データ消失の確率およびデータ再入力の必要を減らすために、明示コミットを指定することを望む場合があり、または、特定の組の変更がアトミック・オペレーションにされる（すなわち、変更のすべてが永久的データベースの一部になる、または変更のどれもが永久的データベースの一部にならないのいずれか）ことを保証することを望む場合、あるいはその両方の場合がある。
【００２８】
ユーザが、ステップ３０３で明示コミット指定を行わない場合に、データベース・オペレーティング・システム機能が、任意選択として、図３の破線の輪郭内のステップ３０４に示されているように、１つまたは複数のデータベース・レコードに対する１つまたは複数の変更を、「暗黙コミット」グループまたは「ソフト・コミット」グループとして指定することができる。「暗黙コミット」指定は、グループのすべての変更がアトミックにされる点で「明示コミット」に似るが、明示コミットと異なって、暗黙コミットは、延期することができる（必ずしも即座にジャーナルに書き込まれない）。好ましい実施形態では、変更を「暗黙コミット」と指定できる少なくとも２つの理由があるが、アプリケーションに応じて、「暗黙コミット」技法を使用する他の理由が存在する場合があることを理解されたい。データベース変更を、明示コミット・グループまたは暗黙コミット・グループの一部にする必要はない、すなわち、データベースに対する分離された書込にすることができる。
【００２９】
暗黙コミットを使用する主な理由は、参照保全すなわち、データベース内の異なるフィールドに対するある変更が、互いに関連し、変更の一方が永久的データベースの一部にされるが他方がそうでない場合に、データベース内のデータが、破壊されることである。このタイプの参照保全の例を、図６に示す。参照保全状態に、複数の表で参照される特定の項目の識別番号が含まれる場合がある。特定の項目がマスタ項目表（たとえば親表６０１）から削除される時に、データベース表の間の参照保全を維持するために、その項目が他の表６０２および６０３から自動的に削除されるように、制約をセット・アップすることができる。結果の削除が、別の表での削除を引き起こすことが可能であり、複数の動作がもたらされる。これらの動作は、動作の組を、それらが部分的にのみコミットされた場合にロール・バックできるようにするために、暗黙コミット・サイクルの下で実行される。これによって、データベースの保全性を保証するために、削除の組を原子的に行うことが可能になる。
【００３０】
暗黙コミットを使用する追加の理由は、「ＳＱＬ［構造化照会言語］原子性」と称する、変更が、多数の異なるレコードに対する処置を必要とする複雑な照会関数の結果である可能性があることである。その例が、データベース内の５０００行に影響するが、そのうちの５０行だけが処理が終了した時に完了している、セット削除動作である。この場合に、データは、変更の一部を行い、それ以外を行わないことによって必ず破壊されるのではなく、特定のグローバル変更が行われたと信じるユーザの代わりに混乱がある可能性がある。ライト・アヘッド・ジャーナリングと提携する暗黙コミットによって提供される原子性によって、この危険性が除去される。
【００３１】
ステップ３０６および３０７（下で説明する）とほぼ並行に、ある変更によって、任意選択として、１つまたは複数のデータベース索引２０３および２０４も暫定的に更新される場合がある（ステップ３０５）。索引は、メイン・メモリ内で更新されるが、索引更新は、必ずしもジャーナル・ディスク１１１への書込のためにジャーナル・バッファに追加されない。索引が、データベース自体から導出されるかコンパイルされるデータを表すことが観察される。データベース・レコード（索引を除く）の保全性が維持される限り、必ず索引を導出することが可能であり、したがって、索引更新のジャーナリングは、必要ではない。しかし、すべての索引の導出は、かなりの時間を要する可能性があり、米国特許第５５７４８９７号および米国特許第５６２５８２０号に記載されているように、いくつかの状況で、システム障害からの回復に必要な時間を減らすために、索引更新をジャーナリングすることが望ましい場合がある。同一の理由から、ステップ３０５の正確なタイミングは、必ずしもクリティカルではなく、図３に示された他の動作の前、後、またはそれらと並行に実行することができる。
【００３２】
その後、変更が、揮発性メモリ内のジャーナル・バッファ２０６および２０７の１つに追加される（ステップ３０６）。変更項目は、それらが最終的にジャーナル・ディスク１１１に書き込まれるのと同一のフォーマットで、これらのジャーナル・バッファに順次書き込まれる。実際には、ジャーナル・バッファ２０６および２０７は、通常は、交代する形で使用される、すなわち、連続的な変更が、バッファを空にさせるイベントが発生するまでバッファの１つに書き込まれ、そのイベントの後に、すべての変更が他方のバッファに書き込まれる。３つ以上のバッファを割り振り、たとえば、ラウンド・ロビン式にそれらに書き込むことが可能である。環状バッファなど、単一のバッファだけを割り振ることも可能である。
【００３３】
ほぼ同時に、変更が、メモリ１０２内のデータベース２０２に対して行われる（ステップ３０７）。好ましい実施形態では、変更が、メイン・メモリ内のデータベースに対して行われる前に、ジャーナル・バッファに記録される。しかし、このメイン・メモリ変更シーケンスは、必ずしもデータベース保全性に必要ではない。どの場合にも、ジャーナル・バッファへの変更レコードの追加およびデータベース２０２内のレコードへの変更の追加の両方が、メモリ１０２への書込を伴い、比較的すばやく行われる。
【００３４】
メイン・メモリ更新の少し後に、変更項目が、ジャーナル・バッファ２０６および２０７からジャーナル・ディスク１１１に書き込まれる（ステップ３０８）。この書込が開始される前にかなりのタイム・ラグがある場合があり、あるいは、ジャーナル・ストレージへの書込が、ほぼ即座に開始される場合がある（ディスク・ストレージへの物理的な書込は、ＣＰＵサイクル・タイムの観点からは比較的長い動作であり、したがって、ジャーナル書込の完了の前に多少タイム・ラグがあるが）。このタイム・ラグは、多くの要因に依存して変化する可能性があるが、そのタイム・ラグの判定を、本明細書でより詳細に説明する。ジャーナル書込動作の完了の後に、ジャーナル・バッファが再利用され、ジャーナル・バッファ内の変更レコードが、最終的に、関連しない変更データと共に書き込まれる。
【００３５】
ジャーナル・ディスク１１１への書込の完了の後に、データベース２０２内の変更が、データ・ストレージ１１２から１１５の対応するアドレスに書き出される（ステップ３０９）。やはり、さまざまな要因に依存して、この書込が開始される前にかなりのタイム・ラグが生じる場合がある。しばしば、データベース・レコードは、さまざまな周知のページング方式のどれかを使用してページ・アウトされるまで、メイン・メモリにとどまる。レコードが、頻繁にアクセスされるメモリ・ページ内にある場合には、そのレコードは、ディスク・ストレージに書き込まれずに非常に長い時間にわたってメイン・メモリにとどまる可能性がある。この場合に、レコードに対する変更が、同一レコードへの後続の変更によって上書きされることもめずらしくない。レコードをディスク・ストレージに書き込んだ後に、そのレコードが、メイン・メモリから削除される（通常は、レコードを含むページのページ・アウトと、ストレージの異なるページによるメモリの上書きの結果として）。
【００３６】
データ保全性のために、変更がジャーナル・ディスク１１１に書き出されるまでは、データベース・レコードをデータ・ストレージ１１２から１１５に書き出すことができない。変更が、メイン・メモリ内でデータベース２０２のレコード（行）に対して行われる（ステップ３０７で）時に、その行が、ディスク・ストレージへの書込（ページ・アウト）を一時的に妨げるために、「固定」される。変更の対応するジャーナル項目がジャーナル・ディスクに書き込まれた（ステップ３０８で）後に、その行が「固定解除」され、その後にページ・アウトできるようになる。行の固定解除は、必ずしもその行を含むページの即座のページ・アウトを引き起こさず、ページ・アウトに対する一時的保持を解放するだけである。
【００３７】
図３が、通常のデータベース・トランザクションに含まれるある種の有効なイベントのシーケンスの単純化された図として意図され、他の処理（図３に示されていない）も発生することを理解されたい。データベース・トランザクションは、データベースおよび他のソースからのデータを処理するより大きいユーザ・アプリケーションの一部とすることができ、データベースに対する変更が、アプリケーションの機能の派生的な部分にすぎない場合がある。さらに、ある種の記帳アクティビティが、メモリ、ジャーナル・ストレージ、および一般ディスク・ストレージへの書込が正しいシーケンスで行われることと、状態変数が維持され、この状態変数から、変更が一般ディスク・ストレージに書き込まれる前のシステム障害の場合にジャーナル・ストレージからデータベース内容を回復することが可能になることとを保証するために行われる。
【００３８】
上で説明したように、ジャーナル書込（ステップ３０８）のタイミングは、さまざまな要因に依存する可能性があるが、ジャーナル書込は、必ず一般ディスク・ストレージへのデータベース・レコードの書込（ステップ３０９）に先行すると言うことができる。ジャーナル・バッファ２０６および２０７は、ジャーナル・ディスク１１１への物理的書込を保留されているジャーナル書込項目を累積するために存在する。ジャーナル・マネージャ機能２１５は、ジャーナル・ディスク１１１への書込のタイミングを管理する。一般に、ジャーナル・マネージャは、ある条件が満たされるまで書込データをバッファに蓄積できるようにし、条件が満たされた時点で、ジャーナル・ディスクに書き込むことによってバッファが空にされる。
【００３９】
図４は、ジャーナル・マネージャ機能の動作を示す高水準流れ図である。上で図３に関して説明したように、データベースに対する変更は、ユーザ・アプリケーションまたはデータベース・マネージャによって生成される時に、ジャーナル・バッファに書き込まれる。ジャーナル・バッファの一方が、現在アクティブなバッファであり、すべての現在の変更を受け取る。各個々の変更項目は、現在アクティブなバッファの末尾に付加され（ステップ４０１）、バッファ・ポインタが、次の変更項目が書き込まれるバッファ位置を指すように増分される（ステップ４０２）。
【００４０】
変更項目が、コンピュータ・システム１００で実行されるタスクによって生成された順序でバッファに付加されることに留意されたい。複数のタスクが、データベースに対する変更を同時に行うことができるので、特定のユーザによってまたは特定のコミット・グループ（明示コミットであれ暗黙コミットであれ）から行われたすべての変更が、バッファに連続して書き込まれるという保証はない。実際に、単一のユーザによって生成された複数の変更が、非常にしばしば、他のユーザの変更項目とインターリーブされる。すべての個々の変更項目が、バッファを空にさせる可能性があるので、単一のユーザによってまたは特定のコミット・グループから生成されたすべての変更項目が、バッファ内で一緒になり、同一の書込動作でジャーナル・ディスクに書き込まれるという保証もないことになる。たとえば、ユーザＡが、バッファに書き込まれるコミット・グループの一部としていくつかの変更を生成するが、Ａがコミット・グループのすべの変更の生成を完了する前に、ユーザＢが、バッファを空にさせる変更項目を生成し、ユーザＡの変更項目の残りが、ユーザＡの早期の変更がすでにジャーナル・ディスクに書き込まれた後にバッファに書き込まれることが、頻繁に発生する。
【００４１】
変更項目を付加した後に、現在アクティブなバッファが満杯である場合には、ステップ４０３からの「Ｙ」分岐に進む。各バッファが、最大サイズ限界を有する。好ましい実施形態では、この最大サイズが、約１２８Ｋバイトであり、これは、ディスク・ストレージ・デバイスの単一トラックの１回転ごとに書き込まれるデータの量にほぼ対応するサイズであるが、最大サイズを変更できることを理解されたい。したがって、最大サイズは、効率的なジャーナル書込動作に対応するように選択されることが好ましい。バッファがこのサイズに達した場合に、バッファを空にする前にバッファ・サイズをさらに増やすことは、必ずしも感知できる性能改善をもたらさず、したがって、バッファ内のあるトランザクションをコミットし、メイン・メモリのページを解放するためには、バッファを空にしなければならない（ジャーナル・ディスクに書き込む）。
【００４２】
バッファが満杯でない（ステップ４０３からの「Ｎ」分岐）が、最も最近に付加された変更項目が、ユーザによって「明示コミット」グループとして指定された変更のグループの最後の変更項目である場合には、ステップ４０４からの「Ｙ」分岐に進む。この場合には、ユーザの明示コミット指定に従うために、追加の変更でバッファが満たされるのを待たずに、バッファを即座に空にしなければならない。バッファを空にすることによって、明示コミット・グループの以前に付加された変更項目のすべてが、まだジャーナルに書き込まれていない場合にジャーナルに書き込まれる。
【００４３】
最も最近に付加された変更項目が、明示コミット・グループの最後の変更項目でない場合には、ジャーナル・マネージャは、それが暗黙コミット・グループの最後の変更項目であるかどうかを検討する。そうでない場合には、ステップ４０５からの「Ｎ」分岐に進み、ジャーナル・マネージャは、ステップ４０１で、次の変更項目がジャーナル・バッファに追加されるのを待つ。変更項目が、暗黙コミット・グループの最後の変更である場合には、ステップ４０５からの「Ｙ」分岐に進む。この場合には、ジャーナル・マネージャは、追加の動的要因を検討して、バッファを空にするか否かを決定する。３つの追加の動的要因の検討が、図４ではステップ４０６として示されており、下で説明する図５に詳細に示されている。ステップ４０６での追加要因の判定が否定である場合には、ジャーナル・マネージャは、ステップ４０１で次の変更項目がジャーナルに追加されるのを待つ。判定が肯定である場合には、ジャーナル・マネージャは、ステップ４１０でバッファを空にする。
【００４４】
バッファを空にすることにトリガをかけるさまざまな条件のどれかが存在する場合に、ジャーナル・マネージャは、ジャーナル・ディスクに書込コマンドを発行し、メモリ内のアクティブ・ジャーナル・バッファの内容全体のジャーナル・ディスク１１１への直接メモリ転送動作を引き起こす（ステップ４１０）。ジャーナル・マネージャは、アクティブ・ジャーナル・バッファの指定も変更する（ステップ４１１）。異なる数のバッファが可能であるが、２つのジャーナル・バッファが交代する形で使用されることが好ましい。ジャーナル・マネージャは、その後、ステップ４０１で次の変更項目がアクティブ・バッファに追加されるのを待つが、このアクティブ・バッファは、空にされたばかりのバッファでないバッファである。
【００４５】
ジャーナル・ディスク１１１への物理的な書込（ステップ４１０の実行時に開始される）が、ある時間を要し、その間に、新しいデータベース変更項目が、新しいアクティブ・バッファに書き込まれることに留意されたい。ジャーナル・ディスクへの物理的な書込が完了した後に、メイン・メモリ内のデータベース２０２の対応するデータベース行が、「固定解除」され、ディスク・ストレージへの書込の適格性が示される。
【００４６】
図５は、暗黙コミット・グループの最後の変更項目がバッファに付加された時にバッファを空にするかどうかの、ジャーナル・マネージャによって行われる判定を詳細に示す流れ図である。この判定は、ある動的判断基準すなわち、動的に変化するシステム状態変数に基づく。具体的に言うと、この判定では、推定回復時間ならびにジャーナル・ディスクへの書込アクティビティの現在のレベルを考慮に入れる。
【００４７】
ジャーナル・マネージャは、まず、暗黙コミット・グループの最初の変更項目が、現在、そのグループの最後の変更項目と同一のジャーナル・バッファ・ブロックにあるかどうかを判定する（ステップ５０１）。そうである場合には、ジャーナル・バッファが最終的に空にされる時に、必ず、暗黙コミット・グループのすべての変更項目が、同一の書込コマンドでジャーナル・ディスクに書き込まれる。この場合には、トランザクションをジャーナル・ディスクに即座にコミットしないことが経過ＩＰＬ回復時間持続時間に及ぼす影響が、小さい可能性が高く、バッファは、空にされない（「Ｙ」分岐に進む）。最初の変更項目が異なるバッファ・ブロックにある場合には、この暗黙トランザクションからの変更項目の少なくとも一部が、おそらくは既にジャーナル・ディスク上にある。この事実は、回復時間露出を示す。すなわち、この暗黙コミット・グループの最後の変更項目をジャーナル・ディスクに書き込むことができる前に、システム障害が発生する場合に、このグループのいくつかの項目が、ジャーナル・ディスクに書き込まれているが、それ以外の項目が書き込まれていない状態になる。書き込まれていない項目が、失われることになる。したがって、暗黙コミット・グループの原子性を保つためには、障害からの回復時に、ジャーナルに前に書き込まれたデータをデータベースから「バック・アウト」して、暗黙コミット・グループのすべての変更項目を見つけ、暗黙コミット・グループによって行われた変更が一切ない状態にデータベースを復元することが必要になる。この暗黙コミット・グループに関連する最初のジャーナル項目と、同一グループの最後のジャーナル項目の間の距離のスパンが大きい場合には、この処理が、回復時にかなりの時間を要する可能性がある。したがって、ジャーナル・マネージャは、「Ｎ」分岐に進んで、回復時間露出を減らすためにバッファを即座に空にするかどうかを検討する。
【００４８】
ステップ５０１からの「Ｎ」分岐に進む場合に、ジャーナル・マネージャは、回復時間増分関数を呼び出して、暗黙コミット・グループの変更項目によって表されるトランザクションの追加を伴うシステム全体の総回復時間を推定する（ステップ５０２）。Inc_Recovery_Time関数には、システム初期化時間並列サーバ・タスク（使用可能なプロセッサごとに１つ）のそれぞれが、部分的に完了した（部分的にジャーナルに書き込まれた）暗黙コミット・トランザクションのコミット・バックアウト回復を実行するのに要する推定時間を表す「バケット」の組に保管された推定値を更新することが含まれる。そのような回復中に、現在の暗黙コミット・トランザクションの一部であるジャーナル項目のすべてが、ジャーナル・ディスクから走査される。これを行うために、システムは、「前」のイメージを表すジャーナル項目をリンクするバックチェーン・ポインタをたどる。これらの項目は、ジャーナル・ディスク内のランダムな位置にあるので、そのような項目のそれぞれについて１回のディスク・アクセスが必要であると仮定する。したがって、現在の暗黙コミット・トランザクションからバック・アウトするのに必要な総時間は、次式によって推定される。
Num_entries×Avg_Jnl_IO_Time
ここで、Num_entriesは、このトランザクションの項目数（トランザクションに関連するコミット・ブロック・データ構造のフィールドに保管される）であり、Avg_Jnl_IO_Timeは、ジャーナル・ディスクでの入出力（ディスク読取）動作の平均時間である。実際の回復時間には、構造化データベース内のレコードに対する変更を元に戻す時間も含まれるが、一般に、この時間よりも、逆方向ジャーナル走査に必要な時間が重要であると仮定する。
【００４９】
システム全体の回復時間を計算する時に、バッファを空にさせなかった他の未解決の暗黙コミット・トランザクションを検討することも必要になる。類似する計算が、これらのトランザクションのそれぞれについて使用される。これらのトランザクションは、システム初期化時に異なる初期化サーバ・タスクによって並列に回復される可能性があるので、バケットの組を作成して、各タスクの回復時間を維持する。未解決のトランザクションは、さまざまなバケットに連続して割り振られ、各連続するトランザクションが、現在最小の総回復時間を含むバケットに割り振られる。完了時に、推定されるシステム全体の回復時間は、その構成要素の最大の総回復時間を有するバケットの回復時間である。
【００５０】
図７に、このバケット割振処理の例を示す。図７の例では、３つのバケット７０１から７０３（初期化時の３つの並列ＣＰＵタスクに対応する）がある。Inc_Recovery_Timeが呼び出された時に、さまざまなバケットに割り振られたトランザクションの総回復時間は、それぞれ２８０、２５５、および２６２秒であり、これは、総システム回復時間が、最大のバケットの推定時間に対応する２８０秒と考えられることを意味する。それぞれ８、３、１２、４２、６、５、１５、および３秒の回復時間を有する８つの追加のトランザクションが、バケットに割り振られる。８秒の回復時間を有する最初のトランザクションが、最低の総回復時間を有するバケットすなわち、２５５秒の回復時間を有するバケット７０２に割り振られ、その総計が２６３秒になる。ここで、最低の総回復時間は、バケット７０３（２６２秒）になり、したがって、３秒の回復時間を有する２番目のトランザクションは、バケット７０３に割り振られる。この処理が継続され、３番目のトランザクション（１２秒）がバケット７０２に、４番目（４２秒）がバケット７０３に、５番目（６秒）がバケット７０２に、６番目（５秒）がバケット７０１に、７番目（１５秒）がバケット７０２に、８番目（３秒）がバケット７０１に追加される。バケット総計は、この割振りの終りに、それぞれ２８８、２９６、および３０７秒になる。したがって、総回復時間は、最長のバケットの時間である３０７秒と考えられる。この割振り方式は、必ずしも完全に平衡ではないが、単純であり、リソースの近似平衡を達成することが観察される。
【００５１】
更新されたシステム全体の総回復時間が、ある所定の閾値未満である場合に、ステップ５０３から「Ｙ」分岐に進み、バッファを空にしない。この場合には、回復時間露出が、バッファを空にすることを正当化するには短すぎると考えられる。好ましい実施形態では、閾値が、１０分の固定された時間枠であるが、異なる期間を使用することができ、閾値を、システム管理者によって指定される変数にすることができる。システム全体の総回復時間が閾値を越える場合には、バッファを空にすることが望ましい可能性があり、したがって、ステップ５０３からの「Ｎ」分岐に進む。
【００５２】
その後、ジャーナル・マネージャは、ジャーナル・ディスク作業負荷の計算を行う（ステップ５０４）。好ましい実施形態では、ジャーナル・ディスク作業負荷が、下記の比として計算される。
Avg_Jrn_IO/Spec_Jrn_IO
ここで、Avg_Jrn_IOは、ジャーナル項目を含むディスク（ジャーナル・ディスク１１１）の毎秒のディスク入出力動作の平均値であり、最後の測定以降に発生した入出力動作の数を最後の測定以降の時間で割ることによって計算され、Spec_Jrn_IOは、ジャーナル項目を含むディスクの仕様ディスク帯域幅すなわち、ディスク仕様に従って処理することができる毎秒の入出力動作の数である。
【００５３】
ステップ５０４で計算された比が、事前に指定された限度（８０％であることが好ましい）より大きい場合には、ステップ５０５の「Ｙ」分岐に進み、バッファを空にしない。この場合には、ジャーナル・ディスクが、現在、最も重要な作業のサービスで非常に忙しい。まだ満杯でないバッファを空にすることが、性能に悪影響を及ぼす可能性がある。この比が８０％未満の場合には、ステップ５０５の「Ｎ」分岐に進んで、バッファを空にする。
【００５４】
ステップ５０５から「Ｎ」分岐に進む（バッファを空にする）場合には、ジャーナル・マネージャは、回復時間減分関数を呼び出してシステム全体の回復時間を減分し、その結果、未解決の暗黙コミット・グループ（および、現在アクティブなバッファを空にすることによって最終的にジャーナルにコミットされる他の未解決のグループのすべて）の一部であった変更が、もはや推定回復時間の一部とみなされないようにする（ステップ５０６）。
【００５５】
上の、システム全体の回復時間の推定値を増分する手順を参照すると、この推定値は、まず、現在アクティブなジャーナル・バッファ・ブロックを空にすることによって完了する暗黙コミット・トランザクションを各バケットから除去することによって減分される。これによって、バケットが、非平衡になる。バケットの平衡を取り直すために、一から回復時間を再割り振りすることが可能である。しかし、好ましい実施形態では、より単純でより高速な手順が使用される。最大の回復時間を含むバケットから開始して、最小の回復時間を有する（宛先）バケットが、転送の後に転送前のこの（ドナー）バケットの回復時間より短い総回復時間を有する場合に、ドナー・パケットから宛先パケットへ、最小のトランザクション時間を転送する。この処理を、転送の条件が満足されなくなるまで繰り返す。新しいシステム全体の回復時間は、最大の総回復時間を有するバケットの総回復時間である。
【００５６】
ジャーナル・バッファを空にすることに選択的にトリガをかけるための、上で説明したアルゴリズムは、バッファに到着するジャーナル項目の持続速度が比較的高い環境に対処することが意図されている。データベース更新アクティビティのレベルが非常に低い環境では、ジャーナル・バッファ・ブロックを満たすのに長時間を要する可能性があり、したがって、いくつかの項目が、ユーザ・アプリケーションによって生成された後に、ジャーナル・ディスクに長時間コミットされないままになることが可能である。この低アクティビティ環境に対処し、バッファ内容が過度に古くならないことを保証するために、ジャーナル・マネージャに、周期的に覚醒し、スイープ・タスクが前に実行されて以来フラッシュされていないバッファの内容をフラッシュするスイープ・タスクが含まれることが好ましい。代替のアルゴリズムまたは技法を使用して、同一の目的を達成できることを諒解されたい。
【００５７】
ジャーナル・バッファを空にする時を判定するために動的要因を使用することに関して上で説明したステップおよび式において、多数の変形形態が可能であることを理解されたい。好ましい実施形態では、システムのアクティビティが、指定された容量に対する実際のジャーナル入出力の比として測定されるが、異なるパラメータまたは式あるいはその両方を、その代わりに使用することができる。たとえば、その代わりに、ジャーナル・ディスクに対する保留中の入出力動作のバックログまたはキューの長さを測定することができ、「固定された」データベース・ページによって消費されるメイン・メモリの総量を考慮に入れることを選択することができる。同様に、好ましい実施形態では、総システム回復時間の推定を、初期閾値照会としてバケットを使用して行うことができる。しかし、総システム回復時間の推定を必要としない異なる判定を行うことができる。たとえば、現在の暗黙コミット・トランザクションに適用可能な回復時間を推定することができ、あるいは、現在の暗黙コミット・トランザクションのジャーナル項目の数（一般に、回復時間の直接の測定値ではないが、回復時間に関連する）を閾値として使用することができる。さらに、総システム回復時間またはトランザクションのあるサブセットに適用可能な回復時間のいずれかを推定するか、何らかの形で回復時間に関連する他のパラメータを使用する、多数の代替方法を使用することができる。最後に、これらの要因を比較する形を変更することができる。たとえば、回復時間を固定された閾値と順次比較し、その後にディスク入出力を固定された閾値と比較するのではなく、これらの要因の両方あるいは他の要因または追加の要因を、バッファを空にすることの望ましさの単一の定量的測定値をもたらす数学的評価関数に含めることができる。
【００５８】
一般に、本発明の説明された実施形態を実施するために実行されるルーチンは、オペレーティング・システムの一部として、あるいは特定のアプリケーション、プログラム、オブジェクト、モジュール、または命令のシーケンスのどれとして実施されるものでも、本明細書では「コンピュータ・プログラム」または単に「プログラム」と称する。コンピュータ・プログラムには、通常は、命令が含まれ、この命令は、本発明との整合性を有するコンピュータ・システムのデバイスまたはシステム内の１つまたは複数のプロセッサによって読み取られ、実行される時に、これらのデバイスまたはシステムに、本発明のさまざまな態様を実施するステップを実行するかそれを実施する要素を生成するのに必要なステップを実行させる。さらに、本発明を、完全に機能するコンピュータ・システムに関して説明したが、本発明のさまざまな実施形態は、さまざまな形でプログラム製品として配布することができ、本発明は、配布を実際に実行するのに使用される信号担持媒体の特定のタイプに無関係に同等に適用される。信号担持媒体の例には、揮発性および不揮発性のメモリ・デバイス、フロッピ・ディスク、ハード・ディスク、ＣＤ−ＲＯＭ、ＤＶＤ、磁気テープなどの記録可能型媒体と、無線通信リンクを含むディジタルおよびアナログの通信リンクなどの伝送型媒体が含まれるが、これに制限はされない。信号担持媒体の例が、図１に、メモリ１０２、ジャーナル・ディスク１１１、およびデータ・ストレージ１１２から１１５として示されている。
【００５９】
上の説明で、ジャーナリングの対称であるデータを、構造化「データベース」内で維持されるものとして説明した。この用語の使用は、データの特性または構造に対する制限を暗示することを意図されたものではなく、本発明は、データを「データベース」と称するか否かにかかわりなく、すべての形のデータに適用することができる。
【００６０】
上で説明した好ましい実施形態では、コンピュータ・システムが、IBM AS/400アーキテクチャまたはI/Seriesアーキテクチャを使用する。上で説明したある実施形態の詳細が、このアーキテクチャに固有であることと、本発明によるデータベース管理機構を、異なるアーキテクチャ上で実施することができ、ある実施形態の詳細を変更できることを理解されたい。
【００６１】
現在最も実用的で好ましい実施形態とみなされるものに関して本発明を説明したが、本発明が、開示された実施形態に制限されるのではなく、請求項の趣旨および範囲に含まれるさまざまな修正形態および同等の配置を含むことが意図されていることを理解されたい。
【００６２】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００６３】
（１）コンピュータ・システムでデータを管理する方法であって、
データ変更をジャーナル・バッファに入力するステップであって、前記ジャーナル・バッファが、前記コンピュータ・システムの揮発性メモリ内である、ステップと、
前記ジャーナル・バッファの内容を不揮発性ジャーナル・ストレージに書き込むかどうかを選択的に判定するステップであって、前記選択的に判定するステップが、前記ジャーナル・バッファが最大容量まで充てんされていない時に前記ジャーナル・バッファの内容を前記ジャーナル・ストレージ・デバイスに書き込むかどうかを選択的に判定するために少なくとも１つの動的選択判断基準を使用する、ステップと、
前記選択的に判定するステップの結果に応答して前記ジャーナル・バッファの内容を前記不揮発性ジャーナル・ストレージ・デバイスに書き込むステップと
を含む方法。
（２）前記不揮発性ジャーナル・ストレージが、少なくとも１つの回転式磁気ハード・ディスク・ストレージ・デバイスを含む、上記（１）に記載のデータを管理する方法。
（３）前記少なくとも１つの動的選択判断基準が、前記コンピュータ・システムの少なくとも１つの構成要素の現在のアクティビティ・レベルの測定を含む、上記（１）に記載のデータを管理する方法。
（４）前記少なくとも１つの動的選択判断基準が、前記不揮発性ジャーナル・ストレージの現在のアクティビティ・レベルの測定を含む、上記（３）に記載のデータを管理する方法。
（５）前記少なくとも１つの動的選択判断基準が、不完全なジャーナル・トランザクションを回復する時間の推定を含む、上記（１）に記載のデータを管理する方法。
（６）不完全なジャーナル・トランザクションを回復する時間の前記推定が、バケットごとにそれぞれの回復時間を判定するために、平衡化アルゴリズムに従って、回復タスクに対応する複数のバケットに不完全なジャーナル・トランザクションを割り振るステップと、前記複数のバケットのうちで最大の回復時間を有する個々のバケットの回復時間として前記コンピュータ・システムの回復の時間を推定するステップとを含む、上記（５）に記載のデータを管理する方法。
（７）前記選択的に判定するステップが、
複数のコミット・トランザクションを識別するステップであって、各コミット・トランザクションが、前記ジャーナル・バッファに入力される前記データ変更のそれぞれの別個の組を含む、ステップと、
複数のコミット・トランザクションのそれぞれの最後のデータ変更を識別するステップと、
複数のコミット・トランザクションのそれぞれの最後のデータ変更を識別するステップに応答して、前記ジャーナル・バッファの内容を不揮発性ジャーナル・ストレージに書き込むかどうかの前記選択的判定にトリガをかけるステップと
を含む、上記（１）に記載のデータを管理する方法。
（８）前記コミット・トランザクションの一部が、ユーザによってコミット・トランザクションとして明示的に識別され、前記コミット・トランザクションの一部が、前記コンピュータ・システムで実行される管理機能によってコミット・トランザクションとして暗黙のうちに識別され、前記ジャーナル・バッファの内容を不揮発性ジャーナル・ストレージに書き込むかどうかの前記選択的判定にトリガをかける前記ステップが、暗黙のうちに識別されたコミット・トランザクションのそれぞれの最後のデータ変更を識別するステップに応答して実行される、上記（７）に記載のデータを管理する方法。
（９）コンピュータ・システムでデータを管理するプログラム製品であって、前記プログラム製品が、信号担持媒体に記録された複数のプロセッサ実行可能命令を含み、前記命令が、前記コンピュータ・システムの少なくとも１つの中央プロセッサによって実行される時に、前記システムに、
データ変更をジャーナル・バッファに入力するステップであって、前記ジャーナル・バッファが、前記コンピュータ・システムの揮発性メモリ内である、ステップと、
前記ジャーナル・バッファの内容を不揮発性ジャーナル・ストレージに書き込むかどうかを選択的に判定するステップであって、前記選択的に判定するステップが、前記ジャーナル・バッファが最大容量まで充てんされていない時に前記ジャーナル・バッファの内容を前記ジャーナル・ストレージ・デバイスに書き込むかどうかを選択的に判定するために少なくとも１つの動的選択判断基準を使用する、ステップと、
前記選択的に判定するステップの結果に応答して前記ジャーナル・バッファの内容を前記不揮発性ジャーナル・ストレージ・デバイスに書き込むステップと
を実行させる、プログラム製品。
（１０）前記不揮発性ジャーナル・ストレージが、少なくとも１つの回転式磁気ハード・ディスク・ストレージ・デバイスを含む、上記（９）に記載のプログラム製品。
（１１）前記少なくとも１つの動的選択判断基準が、前記コンピュータ・システムの少なくとも１つの構成要素の現在のアクティビティ・レベルの測定を含む、上記（９）に記載のプログラム製品。
（１２）前記少なくとも１つの動的選択判断基準が、前記不揮発性ジャーナル・ストレージの現在のアクティビティ・レベルの測定を含む、上記（１１）に記載のプログラム製品。
（１３）前記少なくとも１つの動的選択判断基準が、不完全なジャーナル・トランザクションを回復する時間の推定を含む、上記（９）に記載のプログラム製品。
（１４）不完全なジャーナル・トランザクションを回復する時間の前記推定が、バケットごとにそれぞれの回復時間を判定するために、平衡化アルゴリズムに従って、回復タスクに対応する複数のバケットに不完全なジャーナル・トランザクションを割り振るステップと、前記複数のバケットのうちで最大の回復時間を有する個々のバケットの回復時間として前記コンピュータ・システムの回復の時間を推定するステップとを含む、上記（１３）に記載のプログラム製品。
（１５）前記選択的に判定するステップが、
複数のコミット・トランザクションを識別するステップであって、各コミット・トランザクションが、前記ジャーナル・バッファに入力される前記データ変更のそれぞれの別個の組を含む、ステップと、
複数のコミット・トランザクションのそれぞれの最後のデータ変更を識別するステップと、
複数のコミット・トランザクションのそれぞれの最後のデータ変更を識別するステップに応答して、前記ジャーナル・バッファの内容を不揮発性ジャーナル・ストレージに書き込むかどうかの前記選択的判定にトリガをかけるステップと
を含む、上記（９）に記載のプログラム製品。
（１６）前記コミット・トランザクションの一部が、ユーザによってコミット・トランザクションとして明示的に識別され、前記コミット・トランザクションの一部が、前記コンピュータ・システムで実行される管理機能によってコミット・トランザクションとして暗黙のうちに識別され、前記ジャーナル・バッファの内容を不揮発性ジャーナル・ストレージに書き込むかどうかの前記選択的判定にトリガをかける前記ステップが、暗黙のうちに識別されたコミット・トランザクションのそれぞれの最後のデータ変更を識別するステップに応答して実行される、上記（１５）に記載のデータをプログラム製品。
（１７）コンピュータ・システムであって、
少なくとも１つの処理ユニットと、
少なくとも１つの不揮発性データ・ストレージ・デバイスを含む不揮発性データ・ストレージであって、前記不揮発性データ・ストレージの一部が、ジャーナルとして使用される、不揮発性データ・ストレージと、
前記少なくとも１つの処理ユニットで実行可能な命令を保管し、前記不揮発性データ・ストレージに保管されたデータに対する変更を含むジャーナル・バッファを保管する、揮発性メモリと、
前記ジャーナル・バッファの内容を前記不揮発性データ・ストレージの前記ジャーナル部分に書き込むかどうかを選択的に判断するマネージャであって、前記マネージャが、前記ジャーナル・バッファが最大容量まで充てんされていない時に前記ジャーナル・バッファの内容を前記ジャーナルに書き込むかどうかを選択的に判定するのに少なくとも１つの動的選択判断基準を使用し、前記選択的な判定の結果に応答して、ジャーナル・バッファ内容を前記不揮発性データ・ストレージの前記ジャーナル部分に書き込ませる、マネージャと
を含む、コンピュータ・システム。
（１８）前記不揮発性データ・ストレージが、複数の独立にアクセス可能なデータ・ストレージ・デバイスを含み、前記不揮発性データ・ストレージの前記ジャーナル部分が、前記複数の独立にアクセス可能なデータ・ストレージ・デバイスのサブセットである、上記（１７）に記載のコンピュータ・システム。
【図面の簡単な説明】
【図１】本明細書に記載の発明の好ましい実施形態による、データベース動作をサポートするコンピュータ・システムの主要なハードウェア構成要素の高水準ブロック図である。
【図２】好ましい実施形態による、データベース動作をサポートするコンピュータ・システムのメイン・メモリに保管される主要なエンティティの概念図である。
【図３】好ましい実施形態による、データベースに対する変更を引き起こすデータベース・トランザクションを入力する一般化された処理を示す高水準流れ図である。
【図４】好ましい実施形態による、ジャーナル・ストレージへの書込に関するジャーナル・バッファの管理を示す高水準流れ図である。
【図５】好ましい実施形態による、ある種の動的考慮事項に基づいてジャーナル・バッファを空にするかどうかに関してジャーナル・マネージャによって行われる判定を詳細に示す流れ図である。
【図６】データベース更新時の参照保全問題の例を示す図である。
【図７】好ましい実施形態による、初期化時に総システム回復時間を推定するバケット割振処理の例を示す図である。
【符号の説明】
１００ コンピュータ・システム
１０１ 中央処理装置
１０２ メモリ
１０３ データ・ストレージ・インターフェース
１０４ 端末インターフェース
１０５ 入出力インターフェース
１０６ 外部ネットワーク・インターフェース
１１０ 内部通信バス

Claims (8)

1. コンピュータ・システムでデータを管理する方法であって、
   前記コンピュータ・システムの揮発性メモリ内にあるジャーナル・バッファにデータ変更を入力するステップと、
   前記ジャーナル・バッファの内容を不揮発性ジャーナル・ストレージに書き込むかどうかを、その構成要素である複数のデータ変更の一部のみが前記不揮発性ジャーナル・ストレージに既に書き込まれている不完全な、前記ジャーナル・バッファに現在含まれるコミット処理すべきコミット・トランザクションについて、少なくとも前記不揮発性ジャーナル・ストレージを前記コミット・トランザクションが一切なかった状態に回復させるための回復時間を推定し当該回復時間が所定の許容時間内であるか否かを判断することにより、選択的に判定するステップと、
   前記所定の許容時間内でないとの前記選択的に判定するステップの結果に応答して前記ジャーナル・バッファの内容を前記不揮発性ジャーナル・ストレージに書き込むステップと
   を含む方法。
2. 前記選択的に判定するステップが、平衡化アルゴリズムに従って、前記コンピュータ・システムの初期化時に並列に実行される複数の回復タスクにそれぞれ対応する各バケットに前記不完全なコミット・トランザクションの前記回復時間を割り振るステップと、前記複数のバケットのうちで最大の回復時間を有するバケットの回復時間として前記コンピュータ・システムの回復の時間を推定するステップとを含む、請求項１に記載のデータを管理する方法。
3. 各々が前記ジャーナル・バッファに入力される前記データ変更の別個の組を含む、複数の前記コミット・トランザクションを識別するステップと、前記複数のコミット・トランザクションのそれぞれの最後の前記データ変更を識別するステップとを更に含み、前記選択的に判定するステップが、前記複数のコミット・トランザクションのそれぞれの前記最後のデータ変更を識別するステップに応答して実行される、請求項１に記載のデータを管理する方法。
4. 前記コミット・トランザクションの一部が、ユーザによってコミット・トランザクションとして明示的に識別され、前記コミット・トランザクションの一部が、前記コンピュータ・システムで実行される管理機能によってコミット・トランザクションとして暗黙のうちに識別され、前記選択的に判定するステップは、暗黙のうちに識別された前記コミット・トランザクションのそれぞれの前記最後のデータ変更を識別するステップに応答して実行される、請求項３に記載のデータを管理する方法。
5. コンピュータ・システムでデータを管理するコンピュータ・プログラムであって、前記コンピュータプログラムは前記コンピュータ・システムに、
   前記コンピュータ・システムの揮発性メモリ内にあるジャーナル・バッファにデータ変更を入力するステップと、
   前記ジャーナル・バッファの内容を不揮発性ジャーナル・ストレージに書き込むかどうかを、その構成要素である複数のデータ変更の一部のみが前記不揮発性ジャーナル・ストレージに既に書き込まれている不完全な、前記ジャーナル・バッファに現在含まれるコミット処理すべきコミット・トランザクションについて、少なくとも前記不揮発性ジャーナル・ストレージを前記コミット・トランザクションが一切なかった状態に回復させるための回復時間を推定し当該回復時間が所定の許容時間内であるか否かを判断することにより、選択的に判定するステップと、
   前記所定の許容時間内でないとの前記選択的に判定するステップの結果に応答して前記ジャーナル・バッファの内容を前記不揮発性ジャーナル・ストレージに書き込むステップと
   を実行させる、コンピュータ・プログラム。
6. 各々が前記ジャーナル・バッファに入力される前記データ変更の別個の組を含む、コミット処理すべき複数のコミット・トランザクションを識別するステップと、前記複数のコミット・トランザクションのそれぞれの最後の前記データ変更を識別するステップとを更に前記コンピュータ・システムに実行させ、前記選択的に判定するステップが、前記複数のコミット・トランザクションのそれぞれの前記最後のデータ変更を識別するステップに応答して実行される、請求項５に記載のデータを管理するコンピュータ・プログラム。
7. コンピュータ・システムであって、
   少なくとも１つの処理ユニットと、
   少なくとも１つの不揮発性データ・ストレージ・デバイスを含む不揮発性データ・ストレージであって、前記不揮発性データ・ストレージの一部が、ジャーナルとして使用される、不揮発性データ・ストレージと、
   前記少なくとも１つの処理ユニットで実行可能な命令を保管し、前記不揮発性データ・ストレージに保管されたデータに対する変更を含むジャーナル・バッファを保管する、揮発性メモリと、
   前記ジャーナル・バッファの内容を前記不揮発性データ・ストレージの前記ジャーナル部分に書き込むかどうかを、その構成要素である複数のデータ変更の一部のみが前記不揮発性ジャーナル・ストレージに既に書き込まれている不完全な、前記ジャーナル・バッファに現在含まれるコミット処理すべきコミット・トランザクションについて、少なくとも前記不揮発性ジャーナル・ストレージを前記コミット・トランザクションが一切なかった状態に回復させるための回復時間を推定し当該回復時間が所定の許容時間内であるか否かを判断することにより選択的に判断し、前記所定の許容時間内でないと判定した場合にジャーナル・バッファ内容を前記不揮発性データ・ストレージの前記ジャーナル部分に書き込ませるマネージャと
   を含む、コンピュータ・システム。
8. 前記不揮発性データ・ストレージが、複数の独立にアクセス可能なデータ・ストレージ・デバイスを含み、前記不揮発性データ・ストレージの前記ジャーナル部分が、前記複数の独立にアクセス可能なデータ・ストレージ・デバイスのサブセットである、請求項７に記載のコンピュータ・システム。

Images