JP3600293B2 - データベース・アクセス効率の向上方法及びシステム - Google Patents
データベース・アクセス効率の向上方法及びシステム Download PDFInfo
- Publication number
- JP3600293B2 JP3600293B2 JP02314395A JP2314395A JP3600293B2 JP 3600293 B2 JP3600293 B2 JP 3600293B2 JP 02314395 A JP02314395 A JP 02314395A JP 2314395 A JP2314395 A JP 2314395A JP 3600293 B2 JP3600293 B2 JP 3600293B2
- Authority
- JP
- Japan
- Prior art keywords
- database
- consistency
- level
- record
- replica
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/2097—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements maintaining the standby controller/processing unit updated
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2365—Ensuring data consistency and integrity
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
- G06F11/16—Error detection or correction of the data by redundancy in hardware
- G06F11/20—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements
- G06F11/2053—Error detection or correction of the data by redundancy in hardware using active fault-masking, e.g. by switching out faulty elements or by switching in spare elements where persistent mass storage functionality or persistent mass storage control functionality is redundant
- G06F11/2094—Redundant storage or storage space
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
- G06F2201/80—Database-specific techniques
-
- Y—GENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10—TECHNICAL SUBJECTS COVERED BY FORMER USPC
- Y10S—TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
- Y10S707/00—Data processing: database and file management or data structures
- Y10S707/99951—File or database maintenance
- Y10S707/99952—Coherency, e.g. same view to multiple users
- Y10S707/99953—Recoverability
Description
【０００１】
【産業上の利用分野】
本発明は、改善されたデータベース・アクセス制御の方法に関し、具体的には、プライマリ・データベースと１つまたは複数のレプリカ・データベースとの間の整合性を保つ改善された方法とシステムに関する。より具体的には、本発明は、回復力のある（ｒｅｓｉｌｉｅｎｔ）データベース・システムにおいて、ユーザが、複数のレプリカ・データベースに付ける多様な整合性レベルを選択出来る、改善された方法とシステムに関する。
【０００２】
【従来の技術】
多目的のマルチプロセッシング・コンピューティング・システムは、典型的には、通信網によって相互接続された複数のノードを含む。そのようなシステムでは、各ノードは、データ処理装置、データ記憶装置、および、複数の通信ポートを含むことができる。データ処理装置は、複数のオペレーテイングシステムの要素の制御の下でのマルチプログラミング・モードで実行している場合があり、この場合、データ処理装置は、複数のノードとみなされる。典型的には、データ記憶装置は、データファイル、オペレーティング・システムとその情報管理要素、および、ユーザのアプリケーション・プログラムをストアしている。
【０００３】
データは、企業にとっての重要な側面からビジネスを抽出した情報である。そのようなシステムでのチャレンジは、ビジネスニーズに合った使用可能性、パフォーマンスおよび費用でエンドユーザがデータにアクセスできる方法で、システムのデータ記憶と通信資源を使用することである。データへのアクセスは、データの整合性と完全性を確実にするために制御されなければならない。分散データ処理システム環境でのデータアクセスの付加的な特徴は、地理的および時間的親和性である。
【０００４】
分散されたデータの構造の基礎は地理的親和性である。或るデータ項目へのアクセスは、地理的にまとまる傾向がある。データのダイナミックな複製方法の基礎は時間的親和性である。最近アクセスされたデータ項目は、最近アクセスされなかったデータ項目よりも、近い将来においてアクセスされる可能性が高い。或るデータ項目に対するアクセスがまとまる傾向があるノードは、親和性ノードと呼ばれる。或るデータ項目に対する親和性ノードは前もってわからず、また、そのノードは時間によって変化する。
【０００５】
分散データ技術は、データのある場所（データロケーション）、データ共有（データシェアリング）の度合い、通信網全体にわたって提供されるデータベース制御の度合い、および、データアクセスの型の属性にしたがって分類することができる。データロケーションは、集中管理、分割化、または、複製化に分けられる。データシェアリングの度合いは、集中化、非集中化、または、分散化に分けられる。データベース管理の制御は、ユーザ提供のもの（分散データ）、または、システム提供のもの（分散データベース）に分けられる。データアクセスは、トランザクション処理型、機能処理型、または、データ処理型に分けられる。
【０００６】
歴史的には、集中管理型がデータベース記憶とアクセスを管理するために使用されてきた。そのような処理手法においては、データ管理とアプリケーション処理が集中管理される。単一のデータベース・マネージャーが使用され、ユーザを中央システムに接続するためにテレプロセッシング通信網が使用される。集中処理手法の変形として、処理の或るものが、通信網の中のノードに分散される。しかし、データは集中管理される。
【０００７】
データベースの集中管理手法の利点は、以下の通りである。（１）データベースの整合性が単一のデータベース・マネージャーによって確実にできること、 （２）すべてのアプリケーション・プログラムが単一のアプリケーション・プログラミング・インターフェースにしたがって作成することができ、すべてのデータが１つのロケーションにストアされているので、アプリケーション・プログラムはデータロケーションを承知していなくてもよいこと、（３）集中データ処理環境でのデータ管理の問題を解決できる多くの有効なツールがあること、（４）単一システムは、操作し、維持し、制御するのがより容易であること。
【０００８】
しかし、データベースの集中処理手法には、いくつかの不利な点がある。すなわち、（１）ある企業にとっては通信コストが高くつき、アプリケーション・プログラムの性能が通信遅延のためにさがること、（２）データ使用可能性が通信網あるいは中央システムの不安定性によって悪くなることがあり、これらの問題はバックアップ・システムや通信網に冗長度を持たせることによって解決されねばならないこと、（３）ある企業にとっては、単一の中央処理システムの処理能力がすでに限界に達していること。
【０００９】
分散データ処理システムのノードにデータを分散するには、一般的に２つの手法がある。これらの手法とは、分割化と静的複製化である。分割データ手法にはデータベースのプライマリ・コピーがないが、複製化手法にはデータベースのプライマリ・コピーがある。
【００１０】
分割データベース手法は、データベースを明確な区画に分割し、これらが、ノードに分散される。したがって、あるデータ項目は、１つのノードにだけ存在する。各ロケーションは、そのロケーションでデータを管理するデータベース・マネージャーを持つ。データ分散マネジャーはアプリケーション・プログラムのデータ・リクエストを受け、データがそのロケーションすなわちローカルに存在する場合はそのリクエストをローカルリクエストにマップし、データが別のロケーションにある場合は、そのリクエストをリモートリクエストにマップする。
【００１１】
分割された分散データベースでは、リクエストされたデータがローカルに存在する場合には、良いデータ使用可能性とアクセス性能が得られる。さらに、各データ項目が単一のデータベース・マネージャーによって管理されるので、データベースの整合性が容易に得られる。よい分割アルゴリズムが前もってわかり、それが存在し、且つ、安定したものであるならば、これらの結果を得ることができる。
【００１２】
上述した分割されたデータベースでは、複数のロケーションでデータを変更するプログラムのために、システムが、通信網全体にわたる回復処理を提供しなければならない。
【００１３】
分割されたデータベース・システムには、また、以下の不利な点がある。（１）分割アルゴリズムがデータアクセス・パターンに一致しない場合には、データの使用可能性と性能が落ちること、（２）アプリケーション・プログラムが、データロケーション、あるいは、少くともデータ分割アルゴリズムを承知していなければならず、また、データロケーションによってデータベースを異なった方法でアクセスしなければならないこと、（３）データベース分割アルゴリズムを変更することは、データロケーションが各ノードのアプリケーション・プログラムの中、エクシット、または、デクラレーションに反映されているので、非常に難しいこと、（４）各ノードにおける既存データの再配置とアルゴリズムの変更は通信網全体にわたって同期して行われねばならず、したがって、最適な性能とデータの使用可能性を維持するのに必要な分割アルゴリズムを調整することができない場合があること、（５）分割されたデータベース全体にわたって或るデータ項目を均一にアクセスするか、または、全データベースをアクセスしなければならないプログラムは性能とデータ使用可能性の低下を蒙ること。
【００１４】
データを分散するための静的複製手法は、中央ノードを含むか、または、含まない手法を含む。前者の場合、中央ロケーションはデータベースのプライマリ・コピーをストアし、各ロケーションはデータベース・マネジャーとデータベースのコピーを持つ。静的複製手法の典型的な使用方法では、プライマリ・データベースがコピーされて各レプリカ・ロケーションすなわちノードに送られ、各ノードでのローカル処理のためにデータが使用できるようになる。各レプリカ・ロケーションで行われたデータ変更は、プライマリ・データベースに対して後で処理を行うために集められる。アプリケーション・プログラムが処理を行う間をぬって、ローカルで行われたデータ変更が中央ロケーションに送られ、プライマリ・データベースに対してアップデートが行われる。レプリカ・データベースを管理するこの手法は複数回のアップデートを防ぐ手法を何も持たないので、プライマリ・データベースに対する各アップデートを手作業で発見して解決するか、あるいは、そのような複数回のアップデートが起こらないようにアプリケーション・プログラムを何らかの方法で制限しなければならない。プライマリ・データベースがレプリカ・コピーのアップデートに一致するようにした後、新しいコピーがレプリカ・ロケーションに送られ、全プロセスが再び開始される。
【００１５】
プライマリ・コピーを中央ロケーションに持つ静的複製の主要な利点は、すべてのデータがローカルにアクセス可能であるので、高いデータ使用可能性と良い応答時間が得られる。しかし、この方法には以下の不利な点がある。（１）システムが複数回のアップデートを防ぐことができないのでデータベースの整合性を保つことが難しく、静的レプリカのために実行可能なデータベース処理が厳しく制限されること、（２）システムが、アプリケーション・プログラムのアクセスが必要とする最新データを保証できないこと、（３）オペレーション上の特別なプロシージャが、レプリカ・データの変更を集めプライマリ・データベースをアップデートするために必要になり、このプロシージャを実行することは高くつき、また、エラーを起こし易いこと、（４）データのアップデートの間にはデータ伝送のために不必要に大きいバンド幅を必要とし、確認のための十分大きなウィンドウを提供することは多くのアプリケーションでは実行不可能であり、レプリカがオペレーションの合間の狭いウィンドウの中だけで送られるので、確認プロシージャの間は、データベースが使用できなくなる可能性が大きいこと。さらに、１つあるいは複数のノードが動作不可能になった場合、予定されたウィンドウの中で確認プロシージャが行えなくなる。
【００１６】
上述した静的複製の基本的な手法に関して、多くのさまざまな手法が文献に記載されている。たとえば、複数回のアップデートが起こらないようにアプリケーション・プログラムを設計することができるし、あるいは、レプリカは読み取りアクセスだけに制限することもできる。あるいは、アプリケーション・プログラム自身が、後でプライマリ・ロケーションに送るためにアップデートを集め、プライマリ・ロケーションにおいて、データベース・マネージャのログからこの情報を探り出すようにすることもできる。レプリカ・ロケーションでは、全面的なレプリカまたは部分的なレプリカだけを形成することもできる。レプリカ・データベース全体あるいは、保持されているデータへの変更のみを送るようにすることができる。トランザクションによって行われた変更を種々のノードに送り、トランザクション終了処理の１部としてアクノレッジメントを受領することによって、レプリカの同期性を常に保つようにすることができる。そのような同期手法によって静的複製の整合性の問題を解決するができる。しかし、これらの手法では、そのようなシステムの性能と使用可能性の利益の多くを失う。
【００１７】
米国特許４，００７，４５０号には、各ノードが他のノードと或る種のデータセットを共有し、中央ロケーションには絶えず同期されるレプリカだけがあるがプライマリ・コピーがない、分散データ制御システムが記載されている。各ノードは、他のノードのいずれかがアップデートしようとしていないかぎり、共有されたどのデータセットをもアップデートするように作動し、複数のノードがアップデートしようとしているときには、高いプライオリティーを持つノードがアップデートを行う。各ノードはそのメモリに、共有された各データセットのノードロケーションと、共有された各データセットに対して各ノードが持つアップデート・プライオリティーをストアしている。或るノードでデータセットがアップデートされるとき、レプリカを持っているすべてのノードにそのアップデートが送られる。上記のような手法は、静的複製の整合性問題を解決することはできるが、性能と使用可能性の利益の多くが失われる。
【００１８】
米国特許４，４３２，０５７号には、分散マルチプロセシング・データベース・システムにおける資源の活用を制御するための分散システム制御の下での、データのダイナミックな複製方法が記載されている。このシステムでは、指定された現在性（ｃｕｒｒｅｎｃｙ）を持つデータへのアクセスリクエストが許され、アップデートされたデータの確認が、各ノードにおいて実行される制御プロシージャを使用することによって選択的に行われる。この場合、各ノードは、他ノードにおける共有データ項目のステータスに関するそのノードの見方をあらわし各ノードにファイルされているステータス・アンド・コントロール（ｓｔａｔｕｓ ａｎｄ ｃｏｎｔｒｏｌ ｍｅｓｓａｇｅ： ＳＡＣ）メッセージを使用する。このシステムでは、各データベース・リクエストはインターセプトされ、ローカル・コピーが現在性に対する要求を満たすかどうかが判断される。現在性が満たされない場合、そのリクエストを実行する前に、関連するノードと交渉を行うことが必要である。したがって、レプリカ・データベースの現在性は、アクセス・パターンに従ってダイナミックに変わる。
【００１９】
上記のことから、データ処理システムの１つまたは複数のロケーションにおいて複製されるジャーナルされたデータベースを含む回復力のあるデータベース・システムで使用し、それにより、各レプリカ・データベース内で維持される整合性レベルを、任意に且つ選択的に割り当てることができる方法とシステムの必要性があることがわかる。
【００２０】
【発明が解決しようとする課題】
本発明の目的は、分散データ処理システム内のデータベース・アクセス制御のための改善された方法を提供することである。
【００２１】
さらに、本発明の目的は、分散データ処理システム内のプライマリ・データベースと１つまたは複数のレプリカ・データベースとの間の整合性を維持するための改善された方法とシステムを提供することである。
【００２２】
さらに、本発明の目的は、分散データ処理システム内の回復可能なデータベース内部の複数のレプリカ・データベースに付す多様な整合性レベルをユーザが選ぶことができる、改善された方法とシステムを提供することである。
【００２３】
【課題を解決するための手段】
上述の課題を達成する方法を以下に述べる。分散データ処理システム内の１つまたは複数のロケーションで実施されるジャーナルされたデータベースを含む回復可能なデータベース・システムにおいて、プライマリ・データベースとレプリカ・データベースとの間で維持される整合性レベルをそれぞれ記述する複数の多様な整合性レベルが指定される。ユーザは、各レプリカ・データベースのための具体的な整合性レベルを選択することができる。その後、プライマリ・データベースの中のレコードをアップデートすると、そのアップデートを使って、各レプリカ・データベース内の対応するレコードに対して、そのレプリカ・データベースに選択された整合性レベルと整合のとれる方法でアップデートが始まる。このようにして、プライマリ・データベースが故障した場合にもスムーズに切り替えが行えるように、プライマリ・データベースと完全に整合性のあるレプリカ・データベースを提供することもできるし、また、完全に整合性のあるデータを必要としないアプリケーションの照会に応答するためには第２のレプリカ・データベースを提供し、これにより、そのデータベースに対するアクセスの効率を大きく向上させることもできる。
【００２４】
【実施例】
図１に、本発明の方法とシステムを実施するのに使用できる、分散データ処理システム８の概略図を示す。分散データ処理システム８は、ローカルエリア・ネットワーク（以下ＬＡＮという）１０および３２のような複数のＬＡＮを持ち、各ＬＡＮはコンピュータ１２および３０のような複数の個々のコンピュータを持つことが望ましい。もちろん、当業者には明らかなように、各ネットワークには、ホストプロセサに接続された複数のインテリジェント・ワークステーションを使用することもできる。
【００２５】
このようなデータ処理システムによく見られるように、各コンピューターは記憶装置１４および印刷出力装置１６を接続することができる。記憶装置１４は、本発明の方法とシステムにしたがい、分散データ処理システム８のユーザによって定期的にアクセスされ処理されるプライマリ・データベースまたはそのレプリカをストアするために使用される。公知の方法によって、そのようなプライマリ・データベースまたはそのレプリカは記憶装置１４にストアされ、データベースを維持しアップデートする責任を持つリソース・マネジャーまたはライブラリ・サービスと関連づけられる。
【００２６】
図１はさらに、分散データ処理システム８が、メインフレーム・コンピュータ１８のような複数のメインフレーム・コンピュータを含み、それらが通信リンク２２によってＬＡＮ１０に接続されていることを示す。また、メインフレーム・コンピュータ１８は、ＬＡＮ１０の遠隔記憶装置としてはたらく記憶装置２０に接続されている。第２のＬＡＮ３２が、ゲートウェイ・サーバ２８への通信制御装置２６および通信リンク３４を介して、ＬＡＮ１０に接続されている。ゲートウェイ・サーバ２８は、ＬＡＮ３２をＬＡＮ１０につなげる役割をする別個のコンピュータあるいはインテリジェント・ワークステーションであることが望ましい。
【００２７】
ＬＡＮ３２およびＬＡＮ１０に関連して述べたように、プライマリ・データベースまたはそのレプリカは記憶装置２０内にストアされ、そのようにストアされたプライマリ・データベースおよびそのレプリカに対するリソース・マネジャーまたはライブラリ・サービスの役割をするメインフレーム・コンピュータ１８によって制御される。
【００２８】
もちろん、当業者には明らかなように、メインフレーム・コンピュータ１８はＬＡＮ１０から地理的に遠い距離に設置することができ、同様に、ＬＡＮ１０は、ＬＡＮ３２から相当な距離離れていてもよい。たとえば、ＬＡＮ３２がカリフォルニア州にあり、ＬＡＮ１０がテキサス州にあり、メインフレーム・コンピュータがニューヨークにあってもよい。
【００２９】
上述したことからわかるように、分散データ処理ネットワーク８の或る１つの部分にいるユーザが、データ処理ネットワーク８の別の部分にストアされているデータベースにアクセスしたいことがしばしばある。そのようなクライアント／サーバ・システム環境では、データベース内にストアされたデータへのアクセスは、いわゆる「回復可能な（ｒｅｓｉｌｉｅｎｔ）データベース・システム」を提供することによって増やすことができる。回復可能なデータベース・システムとは、分散データ処理システム内の１つまたは複数のロケーションにおいて複製化されている、ジャーナルされたデータベースである。そのようなデータベースでは、１つのデータベースがプライマリ・データベースとして、他の全てのデータベースはバックアップ・レプリカとして指定される。回復可能なデータベース・システムは、故障が起こったとき１つ前のポイントに回復する。すなわち、ここでいう故障とは、データベース・レプリカの１つが在るコンピュータの故障、あるいは、レプリカの１つを破壊するような媒体故障によって引き起こされる故障のことである。クラスター管理を行うことによって、アプリケーション・プログラマおよびエンドユーザに透明で、プライマリ・レプリカが故障したときにバックアップ・レプリカにスムーズに切り替えられる回復処理を提供することができる。
【００３０】
高い使用可能性を持つデータベースを提供するためにデータベースが複製化されているシステムにおいては、そのようなシステムの自然な延長は、プライマリ・サーバのワークロードを軽減するために、ユーザがバックアップ・レプリカに照会できるようにすることである。しかし、或る整合性が強制されていない限り、レプリカ・データベースに対する照会トランザクションは、コミットしていないトランザクションによってセットされた値、あるいは、古い値を読んでしまう。あまり重要でないアプリケーションではこれでも良いかも知れないが、通常多くのアプリケーションは、プライマリ・データベースとの最低レベルの整合性を必要とする。
【００３１】
このアプリケーションについて説明する目的で、ここでは、「アプリケーション」という用語は、ユーザによって始動されデータベース・オペレーションを呼び出すアプリケーション・コードのことをいう。データベース・オペレーションを呼び出すために使用される多くの多様なアプリケーションが現在使用可能であり、そのようなアプリケーションは本発明の方法とシステムにとって修正する必要はない。典型的には、そのようなアプリケーションがデータベース・オペレーションを呼び出すときはいつでも使える「アプリケーション・スタブ」も提供される。アプリケーション・スタブは呼び出しをトラップし、その呼び出しを特別ルーチンにまわす。このアプリケーション・スタブは一般的にクラスター管理によって提供され、その後、リクエストを、プライマリ・データベースを制御する機械にわたす。故障を回復するために必要などの回復ステップも、アプリケーション・スタブによってアプリケーションから隠されている。
【００３２】
本発明の明細書で記述される「プライマリ・エージェント」はプライマリ・データベースを制御する機械の上にあり、データベース・オペレーションを実行するプロセスである。アプリケーション・プロセス１つにつき、１つのプライマリ・エージェントがある。本発明の方法とシステムで使用される「バックアップ・レシーバ」は、レプリカ・データベースへのアクセスを管理する機械の上にあり、プライマリ・データベースにほどこされた変更を記述するジャーナル・エントリを受け取り、それらのジャーナル・エントリをジャーナルのローカル・レプリカに記録するプロセスである。データベースのレプリカを制御する各機械の上の１つのデータベースに対して１つのバックアップ・レシーバ・プロセスがある。「バックアップ・アプライア」は、レプリカ・データベースを制御する機械の上にあり、データベースのローカル・レプリカにジャーナル・エントリを付すプロセスである。バックアップ・レプリカを制御する各機械の上の１つのデータベースに対して１つのバックアップ・アプライア・プロセスがある。
【００３３】
図２に、本発明の方法とシステムにしたがい実施された回復可能なデータベース・システム内の、典型的な書き込みオペレーションの制御フローの概略を示す。図に示すように、ユーザ４０はアプリケーション４２を使用し、スタブ・ルーチン４４を呼び出し、プライマリ・データベース４６内でオペレーションを実行する。プライマリ・データベース４６を制御する機械の中のプライマリ・エージェント４８がこのオペレーションを実行する。この修正によって必要になったジャーナル・エントリがジャーナル５０内に挿入され、レプリカ・データベース５２内のバックアップ・レシーバ５４、および、レプリカ・データベース６０のような他のレプリカ・データベースに広げられる。
【００３４】
バックアップ・レシーバ５４はそれらのジャーナル・エントリを受け取ったというアクノレッジメントを返し、その後、それらのジャーナル・エントリをそのジャーナルのローカルレプリカ（符号５８に示すような）内に、随時非同期的に入れる。バックアップ・アプライア５６は、ジャーナル５８内にあるそれらのジャーナル・エントリをレプリカ・データベース５２内の対応するレコードに付ける。これは、そのレコードをロックし、アップデートし、その後、アンロックすることによって行われる。この方法によって、レプリカ・データベース５２とプライマリ・データベース４６との間の整合性を保つことができる。
【００３５】
したがって、バックアップ・アプライア５６により、ユーザが直接レプリカ・データベース５２からレコードを読んだ場合には部分的にしかアップデートされていないレコードを読むのを防ぐことによって、最低レベルの整合性を提供することができる。もちろん、データベース読取りオペレーションに対する制御フローは、図２に示したものに似ている。しかし、ジャーナル・エントリは生成されず、したがって、バクアップ・レシーバとバックアップ・アプライアは使用されない。図２に示した環境は、たとえば、ＩＢＭ ＡＳ／４００のようなコンピュータ・システムを使用して実施することができる。
【００３６】
次に、本発明の重要な特徴として、選択されたレプリカ・データベースをユーザが使用する際にユーザが選択する複数の多様な整合性レベルが提供される。回復可能なデータベース・システム内の同時実行については、「同時実行制御とデータベース・システムの回復」（”Ｃｏｎｃｕｒｒｅｎｃｅ Ｃｏｎｔｒｏｌ ａｎｄ Ｒｅｃｏｖｅｒｙ ｉｎ Ｄａｔａｂａｓｅ Ｓｙｓｔｅｍｓ” Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ Ｐｕｂｌｉｓｈｉｎｇ Ｃｏｍｐａｎｙ， １９８７）に記載があり、複数バージョンの同時実行制御モデルが記述されている。このシステムにおいては、バックアップ・レプリカ・データベースは常にプライマリ・データベースより遅れ、したがって、データベースのバージョンが２つできる。上記文献のシステムに対比して、本発明の方法とシステムは、考慮するべき２つの異なる整合性属性を提供する。
【００３７】
具体的には、これらの２つの属性は、データベース・システム内のトランザクションの順序付け（ｏｒｄｅｒｉｎｇ）と、これらのトランザクションの直列化可能性（ｓｅｒｉａｌｉｚａｂｉｌｉｔｙ）を含む。これらの２つの属性はいくつかの方法で組み合わせることができ、その結果６つの異なる整合性レベルができる。したがって、本発明の重要な特徴にしたがい、レプリカ・データベースから読み込む照会に対し、トランザクションの順序付けに関して３つの異なる整合性レベルが考慮される。もちろん、当業者には明らかなように、レコード・アップデートの後の整合性維持のために、最大時間遅れの値を指定することができる。「レベル０」整合性レベルは、レプリカ・データベース内の古い値を使って照会することを許す。「レベル１」整合性レベルは、レプリカ・データベースから最新のコミットされた値だけを使って照会できるという整合性を課す。最後に、「レベル２」整合性レベルは、その値がコミットに達したか否かに拘わらず、レプリカ・データベースからの最新の値だけを使って照会するという整合性を課す。
【００３８】
次に、上述したように、所望の整合性レベルを割り当てるために、本発明の回復可能なデータベース・システム内のトランザクションの直列化可能性について考慮しなければならない。この属性によって、現実には同時にインターリーブして実行されたトランザクションが、或る直列順序で実行されたのと論理的には等しい効果を持たせることを保証する。回復可能なデータベース・システムは、コミットメント制御の下で動くアプリケーションが、コミットメント制御の下にない他のアプリケーションと同時に同じデータベースに対して動くことを許す。したがって、異なるアプリケーションは、直列化可能性を必要としてもしなくても良いことが考えられる。したがって、本発明の回復可能なデータベース・システム内のレプリカ・データベースにユーザまたはシステム管理者が異なる多様な整合性レベルをセットすることを許すとき、整合性レベルを制御するために２つの異なる変数がセットされなければならない。順序付けは、「レベル０」、「レベル１」、あるいは「レベル２」にセットされる。さらに、直列化可能性は「必要」あるいは「不要」にセットされる。
【００３９】
図３に、本発明の方法とシステムによる回復可能なデータベース内での複数の多様な整合性レベルのセットを説明する論理フローの概略図を示す。図示したように、このプロセスは、ブロック７０で始まり、ブロック７２に進む。ブロック７２で、整合性レベルの選択が行われたかどうかが判断される。Ｎｏの場合、このプロセスは、ユーザまたはシステム管理者が回復可能なデータベース・システム内のレプリカ・データベースの整合性レベルをセットしたいという意志表示を示すまで、繰り返される。
【００４０】
ブロック７２で整合性レベルの選択が行われた場合、プロセスはブロック７４に進む。ブロック７４は、本発明の回復可能なデータベース・システム内の最初のレプリカ・データベースに対するプロセスを示す。次にプロセスはブロック７６に進む。ブロック７６で、プロセスは、ユーザあるいはシステム・オペレータが所望の整合性レベルをセットすることを促す。次に、プロセスはブロック７８に進む。ブロック７８で、所望の整合性レベルが入れられたかどうかが判断され、Ｎｏの場合は、プロセスは繰り返しブロック７６に戻り、再度所望の整合性レベルを入れるように促す。
【００４１】
ブロック７８で所望の整合性レベルが入れられたと判断されれば、プロセスはブロック８０に進む。ブロック８０で、直列化可能性の要求があるかどうかをユーザあるいはシステム・オペレータに促す。すなわち、インターリーブされて実行されたトランザクションが、或る直列順序で実行されたのと論理的に等しいものとしたいかどうかを、ユーザあるいはシステム・オペレータに意志表示してもらう。次に、プロセスはブロック８２に進む。ブロック８２で、ユーザが直列化可能性要求を入れたかどうかを判断し、Ｎｏの場合は繰り返しブロック８０に戻り、再度、このデータベースに対する直列化可能性要求があるか否かを入れるようにユーザに促す。ユーザが直列化可能性要求を入れた後、プロセスはブロック８２からブロック８４に進む。ブロック８４で、整合性レベルを付けるべきレプリカ・データベースがまだあるかどうかを判断し、以上のプロセスで整合性レベルを付けたレプリカ・データベースが最後のレプリカでない場合には、プロセスは繰り返しブロック７６に戻り、再度上述したプロセスを実行する。ブロック８４がＹｅｓの場合、すなわち、最後のレプリカ・データベースに所望の整合性レベルが付けられた場合は、プロセスはブロック８６に進みリターンする。
【００４２】
図４から図１０に、本発明の方法とシステムによる回復可能なデータベース・システム内で、レコード・アップデートが行われた後の、複数の多様な整合性レベルを実行する方法を示すフローチャートの概略図を示す。図４に示すように、プロセスはブロック９０から始まる。次に、プロセスはブロック９２に進み、レコード・アップデートが起こったかどうかを判断する。レコード・アップデートがまだ起こっていない場合、このプロセスは、プライマリ・データベースにレコード・アップデートが起こるまで繰り返される。次に、レコード・アップデートが起こったときに、プロセスはブロック９２からブロック９４に進む。
【００４３】
ブロック９４は、本発明の回復可能なデータベース・システム内の各レプリカ・データベースに対して繰り返して行われるプロセスの始まりを示す。プロセスはブロック９４からブロック９６に進む。ブロック９６で、所望の整合性レベルが「レベル０」にセットされたかどうかが判断される。Ｙｅｓであれば、プロセスはブロック９８に進む。ブロック９８で直列化可能性が要求されているかどうかが判断され、Ｙｅｓの場合、プロセスは、図４のコネクタ１００を介して図５の論理フローに進む。そうでない場合、すなわち、直列化可能性が不要であった場合、プロセスは、図４のコネクタ１０２を介して図６の論理フローに進む。
【００４４】
再びブロック９６に戻り、所望の整合性レベルが「レベル０」にセットされなかった場合は、プロセスはブロック１０４に進む。ブロック１０４で、所望の整合性レベルが「レベル１」にセットされたかどうかが判断される。Ｙｅｓであれば、プロセスはブロック１０４からブロック１０６に進み、再度、直列化可能性が要求されているかどうかが判断される。直列化可能性が要求されている場合には、プロセスは、図４のコネクタ１０８を介して図７の論理フローに進む。そうでない場合、すなわち、直列化可能性が不要であった場合、コネクタ１１０を介して図８の論理フローに進む。
【００４５】
再びブロック１０４に戻り、所望の整合性レベルが「レベル１」でない場合、プロセスはブロック１０４からブロック１１２に進む。ブロック１１２で、このレプリカ・データベースに対する所望の整合性レベルが「レベル２」にセットされたかどうかが判断され、もしＹｅｓであれば、プロセスはブロック１１２からブロック１１４に進む。前と同じように、ブロック１１４で直列化可能性が要求されたかどうかが判断され、Ｙｅｓの場合、プロセスはコネクタ１１６を介して図９の論理フローに進む。Ｎｏの場合、すなわち、直列化可能性が不要であった場合、プロセスはブロック１１４からコネクタ１１８を介して図１０の論理フローに進む。最後に、再びブロック１１２で、所望の整合性レベルが「レベル２」でない場合、プロセスはブロック１２０に進みリターンする。
【００４６】
図５に、レプリカ・データベース内で整合性「レベル０」が選択され直列化可能性が要求されたレコードに対応するレコードにレコード・アップデートが行われた場合に起こる論理フローの順序を示す。図５から図１０のそれぞれには、番号１３０、１３２、１３４、および、１３６を付けた４つのカラムがある。それぞれの場合において、カラム１３０はプライマリ・データベ ースに起こるアクティビティを示す。カラム１３２はジャーナル・エントリのフローを示し、カラム１３４は考慮対象の特定のレプリカ・データベース内のバックアップ・レシーバに起こるアクティビティを示す。最後に、カラム１３６は、レプリカ・データベース内のバックアップ・アプライア（図２を参照）のアクティビティを示す。
【００４７】
したがって、図５のカラム１３０を見ると、ブロック１５０に、レコードＲ１に対するアップデートＵ１を含むトランザクションＴ１が示されている。この結果ジャーナル・エントリ（ＪＥ１）が作られ、これがバックアップ・レシーバに送られる。次に、バックアップ・レシーバはアクノレッジメントをプライマリ・データベースに送り、ジャーナル・エントリ（ＪＥ１）を、レプリカ・データベースにあるローカルジャーナルに入れる。次に、バックアップ・アプライアはレコードＲ１をロックし、ジャーナル・エントリ（ＪＥ１）を付ける。
【００４８】
次に、ブロック１５２に、レコードＲ２に対するアップデートＵ２を含むトランザクションＴ２が示されている。この結果ジャーナル・エントリ（ＪＥ２）が作られ、これがバックアップ・レシーバに送られる。次に、バックアップ・レシーバはアクノレッジメントをプライマリ・データベースに送り、ジャーナル・エントリ（ＪＥ２）をローカル・ジャーナルに入れる。その後、バックアップ・アプライアはレコードＲ２をロックし、ジャーナル・エントリ（ＪＥ２）を付ける。
【００４９】
次に、ブロック１５４に、レコードＲ３に対するアップデートＵ３を含むトランザクションＴ１を示す。このトランザクションの結果第３のジャーナル・エントリ（ＪＥ３）が作られ、これがバックアップ・レシーバに送られる。バックアップ・レシーバは再度アクノレッジメントを送り、このジャーナル・エントリをローカルジャーナルに入れる。次に、バックアップ・アプライアはレコードＲ３をロックし、ジャーナル・エントリ（ＪＥ３）を付ける。
【００５０】
最後に、ブロック１５６に、トランザクションＴ１のためのコミット・オペレーションを示す。このトランザクションの結果、ジャーナル・エントリ（ＪＥ４）が作られ、バックアップ・レシーバに送られる。バックアップ・レシーバはアクノレッジメントをプライマリ・データベースに送り、ジャーナル・エントリ（ＪＥ４）をローカルジャーナルに入れる。次に、バックアップ・アプライアはレコードＲ１とＲ３に対するロックをリリースする。
【００５１】
図６は、整合性レベルを「レベル０」にセットし直列化可能性を不要にしたレプリカ・データベース内のレコードにアップデートをした結果起こる論理フローを示す。説明を簡単にするために、図６から図１０のカラムおよびトランザクションは、図５に使ったものと同じ番号を使用している。上述したのと同じように、プロセスは、レコードＲ１に対するアップデートＵ１を含むトランザクションＴ１を示すブロック１５０から始まる。このトランザクションの結果、ジャーナル・エントリ（ＪＥ１）が作られ、これがバックアップ・レシーバに結合される。アクノレッジメントがバックアップ・レシーバからプライマリ・データベースに送られ、ジャーナル・エントリ（ＪＥ１）がローカル・ジャーナルに入れられる。次に、バックアップ・アプライアはレコードＲ１をロックし、ジャーナル・エントリ（ＪＥ１）を付ける。その後、直列化可能性が不要なので、バックアップ・アプライアはレコードＲ１をリリースする。
【００５２】
ブロック１５２に、レコードＲ２に対するアップデートＵ２を含むトランザクションＴ２を示す。このトランザクションの結果ジャーナル・エントリ（ＪＥ２）が作られ、これがバックアップ・レシーバに送られる。バックアップ・レシーバはアクノレッジメントをプライマリ・データベースに送り、ジャーナル・エントリ（ＪＥ２）をローカルジャーナルに入れる。次に、バックアップ・アプライアはレコードＲ２をロックし、ジャーナル・エントリ（ＪＥ２）を付け、その後、レコードＲ２をリリースする。
【００５３】
ブロック１５４に、レコードＲ３に対するアップデートＵ３を含むトランザクションＴ１の追加部分を示す。このトランザクションの結果ジャーナル・エントリ（ＪＥ３）が作られ、バックアップ・レシーバに送られる。バックアップ・レシーバはアクノレッジメントをプライマリ・データベースに送り、ジャーナル・エントリ（ＪＥ３）をローカルジャーナルに入れる。次に、バックアップ・アプライアはレコードＲ３をロックし、ジャーナル・エントリ（ＪＥ３）を付け、その後、レコードＲ３をリリースする。
【００５４】
最後に、ブロック１５６に、トランザクションＴ１に対するコミット・オペレーションを示す。このコミット・オペレーションの結果、ジャーナル・エントリ（ＪＥ４）が作られ、バックアップ・レシーバに送られる。アクノレッジメントがバックアップ・レシーバによりプライマリ・データベース送られ、ジャーナル・エントリ（ＪＥ４）がローカルジャーナルに入れられる。直列化可能性が不要であるので、このコミット・オペレーションの結果、バックアップ・アプライアによるアクティビティは起こらない。
【００５５】
次に、図７に、レプリカ・データベースに対して整合性「レベル１」が選択され直列化可能性が要求されている場合のプライマリ・データベース内のレコードに対するアップデートへの応答の方法を示す論理フローを示す。前と同じように、ブロック１５０は、レコードＲ１に対するアップデートＵ１を含むトランザクションＴ１を示す。このトランザクションの結果ジャーナル・エントリ（ＪＥ１）が作られ、バックアップ・レシーバに送られる。アクノレッジメントがバックアップ・レシーバによってプライマリ・データベースに送られ、ジャーナル・エントリ（ＪＥ１）がローカルジャーナルに入れられる。次に、バックアップ・アプライアはこのジャーナル・エントリ（ＪＥ１）をバッファにストアする。上述したように、整合性「レベル１」は、照会がコミットされた最新の値のみを読むことを課しているので、当業者には明らかなように、レコードＲ１に対するアップデートは、コミット・トランザクションが起こるまでの間、必ずバッファにストアされなければならない。
【００５６】
次に、ブロック１５２に示すように、レコードＲ２に対するアップデートＵ２を含むトランザクションＴ２が起こる。この結果ジャーナル・エントリ（ＪＥ２）が作られ、バックアップ・レシーバに結合される。バックアップ・レシーバは、アクノレッジメントをプライマリ・データベースに送り、ジャーナル・エントリ（ＪＥ２）をローカルジャーナルに入れる。前と同じように、次に、バックアップ・アプライアはこのジャーナル・エントリ（ＪＥ２）をバッファにストアする。
【００５７】
次に、ブロック１５４に示すように、レコードＲ３に対するアップデートＵ３を含むトランザクションＴ１が起こる。この結果ジャーナル・エントリ（ＪＥ３）が作られ、バックアップ・レシーバに結合される。前と同じように、アクノレッジメントがバックアップ・レシーバからプライマリ・データベースに送られ、ジャーナル・エントリ（ＪＥ３）がローカルジャーナルに入れられる。バックアップ・アプライアはこのジャーナル・エントリ（ＪＥ３）をバッファ内にストアする。
【００５８】
最後に、ブロック１５６に示すように、トランザクションＴ１のためのコミット・オペレーションが起こる。この結果、ジャーナル・エントリ（ＪＥ４）が作られ、バックアップ・レシーバに送られる。バックアップ・レシーバはレコードＲ１とＲ３をロックし、アクノレッジメントをプライマリ・データベースに送る。その後、バックアップ・アプライアはトランザクションＴ１からジャーナル・エントリを取り出し、該当するジャーナル・エントリ、すなわち、トランザクションＴ１に関連しているジャーナル・エントリ（ＪＥ１およびＪＥ３）を付ける。その後、レコードＲ１およびＲ３はリリースされる。したがって、レコードＲ１およびＲ３に対するアップデートは、そのトランザクションのためのコミット・オペレーションが起こるまで、バックアップ・アプライアによって適用されない。
【００５９】
図８に、整合性レベルを「レベル１」に、直列化可能性を不要にセットしたレプリカ・データベース内でアップデートされたレコードに対する応答方法を記述した論理フローを示す。前と同じように、ブロック１５０は、レコードＲ１に対するアップデートＵ１を含むトランザクションＴ１を示す。この結果、ジャーナル・エントリ（ＪＥ１）が作られ、バックアップ・レシーバに結合される。バックアップ・レシーバはアクノレッジメントをプライマリ・データベースに送り、このジャーナル・エントリ（ＪＥ１）をローカルジャーナルに入れる。次に、ジャーナル・エントリ（ＪＥ１）は、バックアップ・アプライアによってバッファにストアされる。
【００６０】
次に、ブロック１５２に示すように、レコードＲ２に対するアップデートＵ２を含むトランザクションＴ２が起こる。この結果、ジャーナル・エントリ（ＪＥ２）が作られ、バックアップ・レシーバに結合される。次に、バックアップ・レシーバはアクノレッジメントをプライマリ・データベースに送り、このジャーナル・エントリ（ＪＥ２）をローカルジャーナルに入れる。次に、前と同じように、このジャーナル・エントリはバックアップ・アプライアによってバッファにストアされる。
【００６１】
ブロック１５４で、レコードＲ３に対するアップデートＵ３を含むトランザクションＴ１が起こる。この結果ジャーナル・エントリ（ＪＥ３）が作られ、バックアップ・レシーバに結合される。アクノレッジメントがバックアップ・レシーバからプライマリ・データベースに送られ、ジャーナル・エントリ（ＪＥ３）がローカルジャーナル内にストアされる。次に、前と同じように、ジャーナル・エントリ（ＪＥ３）がバックアップ・アプライアによってバッファにストアされる。
【００６２】
最後に、ブロック１５６に示すように、トランザクションＴ１のためのコミット・オペレーションが起こる。この結果ジャーナル・エントリ（ＪＥ４）が作られ、バックアップ・レシーバに結合される。次に、バックアップ・レシーバはレコードＲ１とＲ３をロックし、アクノレッジメントをプライマリ・データベースに送る。その後、バックアップ・アプライアはトランザクションＴ１に対するジャーナル・エントリを取り出し、第１のジャーナル・エントリ（ＪＥ１）を適用する。次に、レコードＲ１がリリースされる。次に、トランザクションＴ１に対する第２のジャーナル・エントリ（ＪＥ３）がレコードＲ３に適用され、そのレコードはリリースされる。図７の論理フローとは対照的に、図８の論理フローでは直列化可能性の要求がないので、各レコードはそのアップデートが適用された後でリリースされる点に留意する必要がある。
【００６３】
次に、図９に、整合性レベルを「レベル２」にセットし直列化可能性を必要とするプライマリ・データベース内の対応するレコードのアップデートに対する、レプリカ・データベースの応答方法を記述した論理フローを示す。前と同じように、ブロック１５０で、レコードＲ１に対するアップデートＵ１を含むトランザクションＴ１が起こる。このトランザクションの結果、ジャーナル・エントリ（ＪＥ１）が作られ、バックアップ・レシーバに送られる。次に、バックアップ・レシーバはＲ１をロックし、アクノレッジメントをプライマリ・データベースに送る。次に、ジャーナル・エントリ（ＪＥ１）がローカルジャーナルに入れられ、バックアップ・アプライアは直ちにジャーナル・エントリ（ＪＥ１）を適用する。当業者には明らかなように、整合性「レベル２」は、 照会は最新の値（コミットが起こったかどうかに拘わらず）のみを読むことによって行うことを課している。したがって、レコードＲ１に対するアップデートは、バックアップ・アプライアによって直ちに適用される。
【００６４】
ブロック１５２で、レコードＲ２に対するアップデートＵ２を含むトランザクションＴ２が起こる。この結果、ジャーナル・エントリ（ＪＥ２）が作られ、バックアップ・レシーバに結合される。次に、バックアップ・レシーバはレコードＲ２をロックし、アクノレッジメントをプライマリ・データベースに送り、ジャーナル・エントリ（ＪＥ２）をローカルジャーナルに入れる。次に、バックアップ・アプライアは直ちにジャーナル・エントリ（ＪＥ２）を適用し、レコードＲ２を最新の値にアップデートする。
【００６５】
ブロック１５４で、レコードＲ３に対するアップデートＵ３を含むトランザクションＴ１の第２部分が起こる。この結果、ジャーナル・エントリ（ＪＥ３）が作られてバックアップ・レシーバに結合される。次に、バックアップ・レシーバはレコードＲ３をロックし、アクノレッジメントをプライマリ・データベースに送る。次に、ジャーナル・エントリ（ＪＥ３）がローカルジャーナルに入れられ、バックアップ・アプライアはこのジャーナル・エントリ（ＪＥ３）をレコードＲ３に適用する。
【００６６】
最後に、ブロック１５６で、トランザクションＴ１に対するコミット・オペレーションが起こる。この結果、ジャーナル・エントリ（ＪＥ４）が作られ、バックアップ・レシーバに結合される。次に、バックアップ・レシーバはアクノレッジメントをプライマリ・データベースに送り、このジャーナル・エントリ（ＪＥ４）をローカルジャーナルに入れる。次に、バックアップ・アプライアはレコードＲ１とＲ３をリリースし、必要に応じて、このトランザクション部分の直列化可能性を維持する。
【００６７】
最後に、図１０に、整合性「レベル２」をセットし直列化可能性を要求しないレプリカ・データベースの中のプライマリ・データベース内のレコードに対するアップデートに応答して起こる論理フローを示す。前と同様に、ブロック１５０で、レコードＲ１に対するアップデートＵ１を含むトランザクションＴ１が起こる。この結果、ジャーナル・エントリ（ＪＥ１）が作られバックアップ・レシーバに結合される。次に、バックアップ・レシーバはレコードＲ１をロックし、アクノレッジメントをプライマリ・データベースに送る。次に、ジャーナル・エントリ（ＪＥ１）がローカルジャーナルに入れられる。次に、バックアップ・アプライアはジャーナル・エントリ（ＪＥ１）を適用し、直列化可能性が要求されていないので、直ちにレコードＲ１をリリースする。
【００６８】
次に、ブロック１５２に示すように、レコードＲ２に対するアップデートＵ２を含むトランザクションＴ２が起こる。この結果、ジャーナル・エントリ（ＪＥ２）が作られバックアップ・レシーバに結合される。次に、バックアップ・レシーバはレコードＲ２をロックし、アクノレッジメントをプライマリ・データベースに送る。次に、ジャーナル・エントリ（ＪＥ２）がローカルジャーナルに入れられる。次に、バックアップ・アプライアはジャーナル・エントリ（ＪＥ２）を適用し、レコードＲ２をリリースする。
【００６９】
次に、ブロック１５４に示すように、レコードＲ３に対するアップデートＵ３を含むトランザクションＴ１の次の部分が起こる。この結果、ジャーナル・エントリ（ＪＥ３）が作られ、バックアップ・レシーバに結合される。次に、バックアップ・レシーバはレコードＲ３をロックし、アクノレッジメントをプライマリ・データベースに送る。次に、ジャーナル・エントリ（ＪＥ３）がローカルジャーナルに入れられ、バックアップ・アプライアはジャーナル・エントリ（ＪＥ３）を適用し、レコードＲ３をリリースする。以上の記述から当業者には明らかなように、この整合性レベルでは直列化可能性が要求されていないので、レコードＲ１およびＲ３に対するアップデートが行われ、各レコードは、そのアップデートが行われた後直ちにリリースされる。
【００７０】
最後に、ブロック１５６で、トランザクションＴ１に対するコミット・オペレーションが起こる。この結果、ジャーナル・エントリ（ＪＥ４）が作られ、バックアップ・レシーバに結合される。次に、バックアップ・レシーバはこのジャーナル・エントリのアクノレッジメントを送り、ジャーナル・エントリ（ＪＥ４）をローカルジャーナルに入れる。
【００７１】
まとめとして、本発明の構成に関して以下の事項を開示する。
（１）分散データ処理システム内でのデータベース・アクセス効率を向上させる方法であって、前記分散データ処理システム内において、ストアされた複数のレコードを持つ１つのデータベースを選択しプライマリ・データベースとして指定するステップと、前記分散データ処理システム内の第２の物理的ロケーションにおいて前記プライマリ・データベースを複製するステップと、前記プライマリ・データベースと前記の複製されたレプリカ・データベースとの間に維持される複数の多様な整合性レベルを指定するステップと、ユーザに前記の複数の多様な整合性レベルから１つを指定させるステップと、を有し、前記プライマリ・データベース内のレコードに対するアップデートに応答して、前記プライマリ・データベースと前記レプリカ・データベースとの間に前記の複数の多様な整合性レベルの前記の指定された１つを自動的に維持する前記方法。
（２）前記分散データ処理システム内の第３の物理的ロケーションにおいて前記プライマリ・データベースを複製するステップをさらに有する、前記（１）に記載の方法。
（３）ユーザに前記の複数の多様な整合性レベルから１つを指定させる前記ステップが、前記プライマリ・データベースとそのそれぞれのレプリカとの間に維持される前記の複数の多様な整合性レベルから別の１つを指定させるステップを有する、前記（２）に記載の方法。
（４）分散データ処理システム内でのデータベース・アクセス効率を向上させるシステムであって、前記分散データ処理システム内において、ストアされた複数のレコードを持つプライマリ・データベースと、前記分散データ処理システム内の第２の物理的ロケーションにおいてストアされている前記プライマリ・データベースのレプリカと、前記プライマリ・データベースと前記レプリカ・データベースとの間に維持される複数の多様な整合性レベルを指定する手段と、ユーザに前記の複数の多様な整合性レベルから１つを指定させる手段と、前記プライマリ・データベース内のレコードに対するアップデートに応答して、前記プライマリ・データベースと前記レプリカ・データベースとの間に前記の複数の多様な整合性レベルの前記の指定された１つを自動的に維持する手段と、を有するシステム。
（５）前記分散データ処理システム内の第３の物理的ロケーションにおいてストアされている前記プライマリ・データベースの第２のレプリカをさらに有する、前記（４）に記載のシステム。
（６）ユーザに前記の複数の多様な整合性レベルから１つを指定させる前記手段が、前記プライマリ・データベースとそのそれぞれのレプリカとの間に維持される前記の複数の多様な整合性レベルから別の１つを指定させる手段を有する、前記（５）に記載のシステム。
（７）分散データ処理システム内でのデータベース・アクセス効率を向上させる方法であって、前記分散データ処理システム内において、ストアされた複数のレコードを持つ１つのデータベースを選択しプライマリ・データベースとして指定するステップと、前記分散データ処理システム内の第２の物理的ロケーションにおいて前記プライマリ・データベースを複製するステップと、前記プライマリ・データベース内の１つの選択されたレコードに対するアップデートに応答して、前記の複製されたデータベース内の対応する選択されたレコードへのアクセスを自動的にロックするステップと、前記の複製されたデータベース内の前記の選択されたレコードをアップデートするステップと、前記アップデートの後で、前記の選択されたレコードへのアクセスをリリースするステップと、前記分散データ処理システム内のユーザに、前記プライマリ・データベースおよび前記の複製されたデータベースの中のレコードを照会させるステップと、を有し、データの絶対的な整合性を維持するとともにデータアクセスの使用可能性を向上させる方法。
（８）前記プライマリ・データベース内のレコードに対する各アップデートが、コミット・オペレーションを行う前の１つの整合性時点に戻り、前記の選択されたレコードへのアクセスを前記アップデートの後でリリースする前記ステップが、前記アップデートに続くコミット・オペレーションの後でのみ前記の選択されたレコードへのアクセスをリリースするステップを有する、前記（７）に記載の方法。
（９）分散データ処理システム内でのデータベース・アクセス効率を向上させるシステムであって、前記分散データ処理システム内において、ストアされた複数のレコードを持つプライマリ・データベースと、前記分散データ処理システム内の第２の物理的ロケーションにおいてストアされている前記プライマリ・データベースのレプリカと、前記プライマリ・データベース内の１つの選択されたレコードに対するアップデートに応答して、前記の複製されたデータベース内の対応する選択されたレコードへのアクセスを自動的にロックする手段と、前記の複製されたデータベース内の前記の選択されたレコードをアップデートする手段と、前記アップデートの後で、前記の選択されたレコードへのアクセスをリリースする手段と、前記分散データ処理システム内のユーザに、前記プライマリ・データベースおよび前記の複製されたデータベースの中のレコードを照会させる手段と、を有し、データの絶対的な整合性を維持するとともにデータアクセスの使用可能性を向上させるシステム。
（１０）前記プライマリ・データベースを、いかなる時点でも、コミット・オペレーションを行う前の整合性時点に戻す手段をさらに有する、前記（９）に記載のシステム。
（１１）前記アップデートの後で前記の選択されたレコードへのアクセスをリリースする前記手段が、前記アップデートに続くコミット・オペレーションの後でのみ前記の選択されたレコードへのアクセスをリリースする手段を有する、前記（１０）に記載のシステム。
【００７２】
【発明の効果】
本発明の方法とシステムによって、ユーザあるいはシステム・オペレータは、バックアップ・サーバ内のレプリカ・データベースに適する任意の整合性レベルを広範な整合性レベルから選択できるようになる（この選択には、整合性と性能との間のトレードオフが含まれる）。この方法とシステムにより、最低限の整合性レベルでは、１つのレプリカ・データベースにおいて、古い、コミットされていない値を読むことができる一方、他方では、プライマリ・データベースの第２のレプリカ内で、あたかも、照会がプライマリ・データベースから読み込みを行ったのと同じ結果を返すことができる最大レベルの整合性を提供することもできる。このようにして、上述した回復可能なデータベース・システム内において、データベースへのアクセスの効率を大いに改善することができる。
【図面の簡単な説明】
【図１】本発明の方法およびシステムを実施するのに使用できる分散データ処理システムの概略図である。
【図２】本発明の方法およびシステムにしたがって実施される回復可能なデータベース・システム内での、典型的な書き込みオペレーションの概略制御フローを示す。
【図３】本発明の方法およびシステムによる回復可能なデータベース内での複数の多様な整合性レベルの設定を図示する概略論理フローチャートである。
【図４】本発明による複数の多様な整合性レベルの実施を図示する概略論理フローチャートであり、図５に続く。
【図５】図４に続く論理フローチャート。
【図６】図５に続く論理フローチャート。
【図７】図６に続く論理フローチャート。
【図８】図７に続く論理フローチャート。
【図９】図８に続く論理フローチャート。
【図１０】図９に続く論理フローチャート。
【符号の説明】
８ 分散データ処理システム
１０、３２ ローカルエリア・ネットワーク（ＬＡＮ）
１２、３０ コンピュータ
１４、２０ 記憶装置
１６ 印刷出力装置
１８ メインフレーム・コンピュータ
２２、２４、３４ 通信リンク
２６ 通信制御装置
２８ ゲートウェイ・サーバ
４０ ユーザ
４２ アプリケーション
４４ スタブ・ルーチン
４６ プライマリ・データベース
４８ プライマリ・エージェント
５０、５８ ジャーナル
５２ レプリカ・データベース
５４、６０ バックアップ・レシーバ
５６ バックアップ・アプライア
【産業上の利用分野】
本発明は、改善されたデータベース・アクセス制御の方法に関し、具体的には、プライマリ・データベースと１つまたは複数のレプリカ・データベースとの間の整合性を保つ改善された方法とシステムに関する。より具体的には、本発明は、回復力のある（ｒｅｓｉｌｉｅｎｔ）データベース・システムにおいて、ユーザが、複数のレプリカ・データベースに付ける多様な整合性レベルを選択出来る、改善された方法とシステムに関する。
【０００２】
【従来の技術】
多目的のマルチプロセッシング・コンピューティング・システムは、典型的には、通信網によって相互接続された複数のノードを含む。そのようなシステムでは、各ノードは、データ処理装置、データ記憶装置、および、複数の通信ポートを含むことができる。データ処理装置は、複数のオペレーテイングシステムの要素の制御の下でのマルチプログラミング・モードで実行している場合があり、この場合、データ処理装置は、複数のノードとみなされる。典型的には、データ記憶装置は、データファイル、オペレーティング・システムとその情報管理要素、および、ユーザのアプリケーション・プログラムをストアしている。
【０００３】
データは、企業にとっての重要な側面からビジネスを抽出した情報である。そのようなシステムでのチャレンジは、ビジネスニーズに合った使用可能性、パフォーマンスおよび費用でエンドユーザがデータにアクセスできる方法で、システムのデータ記憶と通信資源を使用することである。データへのアクセスは、データの整合性と完全性を確実にするために制御されなければならない。分散データ処理システム環境でのデータアクセスの付加的な特徴は、地理的および時間的親和性である。
【０００４】
分散されたデータの構造の基礎は地理的親和性である。或るデータ項目へのアクセスは、地理的にまとまる傾向がある。データのダイナミックな複製方法の基礎は時間的親和性である。最近アクセスされたデータ項目は、最近アクセスされなかったデータ項目よりも、近い将来においてアクセスされる可能性が高い。或るデータ項目に対するアクセスがまとまる傾向があるノードは、親和性ノードと呼ばれる。或るデータ項目に対する親和性ノードは前もってわからず、また、そのノードは時間によって変化する。
【０００５】
分散データ技術は、データのある場所（データロケーション）、データ共有（データシェアリング）の度合い、通信網全体にわたって提供されるデータベース制御の度合い、および、データアクセスの型の属性にしたがって分類することができる。データロケーションは、集中管理、分割化、または、複製化に分けられる。データシェアリングの度合いは、集中化、非集中化、または、分散化に分けられる。データベース管理の制御は、ユーザ提供のもの（分散データ）、または、システム提供のもの（分散データベース）に分けられる。データアクセスは、トランザクション処理型、機能処理型、または、データ処理型に分けられる。
【０００６】
歴史的には、集中管理型がデータベース記憶とアクセスを管理するために使用されてきた。そのような処理手法においては、データ管理とアプリケーション処理が集中管理される。単一のデータベース・マネージャーが使用され、ユーザを中央システムに接続するためにテレプロセッシング通信網が使用される。集中処理手法の変形として、処理の或るものが、通信網の中のノードに分散される。しかし、データは集中管理される。
【０００７】
データベースの集中管理手法の利点は、以下の通りである。（１）データベースの整合性が単一のデータベース・マネージャーによって確実にできること、 （２）すべてのアプリケーション・プログラムが単一のアプリケーション・プログラミング・インターフェースにしたがって作成することができ、すべてのデータが１つのロケーションにストアされているので、アプリケーション・プログラムはデータロケーションを承知していなくてもよいこと、（３）集中データ処理環境でのデータ管理の問題を解決できる多くの有効なツールがあること、（４）単一システムは、操作し、維持し、制御するのがより容易であること。
【０００８】
しかし、データベースの集中処理手法には、いくつかの不利な点がある。すなわち、（１）ある企業にとっては通信コストが高くつき、アプリケーション・プログラムの性能が通信遅延のためにさがること、（２）データ使用可能性が通信網あるいは中央システムの不安定性によって悪くなることがあり、これらの問題はバックアップ・システムや通信網に冗長度を持たせることによって解決されねばならないこと、（３）ある企業にとっては、単一の中央処理システムの処理能力がすでに限界に達していること。
【０００９】
分散データ処理システムのノードにデータを分散するには、一般的に２つの手法がある。これらの手法とは、分割化と静的複製化である。分割データ手法にはデータベースのプライマリ・コピーがないが、複製化手法にはデータベースのプライマリ・コピーがある。
【００１０】
分割データベース手法は、データベースを明確な区画に分割し、これらが、ノードに分散される。したがって、あるデータ項目は、１つのノードにだけ存在する。各ロケーションは、そのロケーションでデータを管理するデータベース・マネージャーを持つ。データ分散マネジャーはアプリケーション・プログラムのデータ・リクエストを受け、データがそのロケーションすなわちローカルに存在する場合はそのリクエストをローカルリクエストにマップし、データが別のロケーションにある場合は、そのリクエストをリモートリクエストにマップする。
【００１１】
分割された分散データベースでは、リクエストされたデータがローカルに存在する場合には、良いデータ使用可能性とアクセス性能が得られる。さらに、各データ項目が単一のデータベース・マネージャーによって管理されるので、データベースの整合性が容易に得られる。よい分割アルゴリズムが前もってわかり、それが存在し、且つ、安定したものであるならば、これらの結果を得ることができる。
【００１２】
上述した分割されたデータベースでは、複数のロケーションでデータを変更するプログラムのために、システムが、通信網全体にわたる回復処理を提供しなければならない。
【００１３】
分割されたデータベース・システムには、また、以下の不利な点がある。（１）分割アルゴリズムがデータアクセス・パターンに一致しない場合には、データの使用可能性と性能が落ちること、（２）アプリケーション・プログラムが、データロケーション、あるいは、少くともデータ分割アルゴリズムを承知していなければならず、また、データロケーションによってデータベースを異なった方法でアクセスしなければならないこと、（３）データベース分割アルゴリズムを変更することは、データロケーションが各ノードのアプリケーション・プログラムの中、エクシット、または、デクラレーションに反映されているので、非常に難しいこと、（４）各ノードにおける既存データの再配置とアルゴリズムの変更は通信網全体にわたって同期して行われねばならず、したがって、最適な性能とデータの使用可能性を維持するのに必要な分割アルゴリズムを調整することができない場合があること、（５）分割されたデータベース全体にわたって或るデータ項目を均一にアクセスするか、または、全データベースをアクセスしなければならないプログラムは性能とデータ使用可能性の低下を蒙ること。
【００１４】
データを分散するための静的複製手法は、中央ノードを含むか、または、含まない手法を含む。前者の場合、中央ロケーションはデータベースのプライマリ・コピーをストアし、各ロケーションはデータベース・マネジャーとデータベースのコピーを持つ。静的複製手法の典型的な使用方法では、プライマリ・データベースがコピーされて各レプリカ・ロケーションすなわちノードに送られ、各ノードでのローカル処理のためにデータが使用できるようになる。各レプリカ・ロケーションで行われたデータ変更は、プライマリ・データベースに対して後で処理を行うために集められる。アプリケーション・プログラムが処理を行う間をぬって、ローカルで行われたデータ変更が中央ロケーションに送られ、プライマリ・データベースに対してアップデートが行われる。レプリカ・データベースを管理するこの手法は複数回のアップデートを防ぐ手法を何も持たないので、プライマリ・データベースに対する各アップデートを手作業で発見して解決するか、あるいは、そのような複数回のアップデートが起こらないようにアプリケーション・プログラムを何らかの方法で制限しなければならない。プライマリ・データベースがレプリカ・コピーのアップデートに一致するようにした後、新しいコピーがレプリカ・ロケーションに送られ、全プロセスが再び開始される。
【００１５】
プライマリ・コピーを中央ロケーションに持つ静的複製の主要な利点は、すべてのデータがローカルにアクセス可能であるので、高いデータ使用可能性と良い応答時間が得られる。しかし、この方法には以下の不利な点がある。（１）システムが複数回のアップデートを防ぐことができないのでデータベースの整合性を保つことが難しく、静的レプリカのために実行可能なデータベース処理が厳しく制限されること、（２）システムが、アプリケーション・プログラムのアクセスが必要とする最新データを保証できないこと、（３）オペレーション上の特別なプロシージャが、レプリカ・データの変更を集めプライマリ・データベースをアップデートするために必要になり、このプロシージャを実行することは高くつき、また、エラーを起こし易いこと、（４）データのアップデートの間にはデータ伝送のために不必要に大きいバンド幅を必要とし、確認のための十分大きなウィンドウを提供することは多くのアプリケーションでは実行不可能であり、レプリカがオペレーションの合間の狭いウィンドウの中だけで送られるので、確認プロシージャの間は、データベースが使用できなくなる可能性が大きいこと。さらに、１つあるいは複数のノードが動作不可能になった場合、予定されたウィンドウの中で確認プロシージャが行えなくなる。
【００１６】
上述した静的複製の基本的な手法に関して、多くのさまざまな手法が文献に記載されている。たとえば、複数回のアップデートが起こらないようにアプリケーション・プログラムを設計することができるし、あるいは、レプリカは読み取りアクセスだけに制限することもできる。あるいは、アプリケーション・プログラム自身が、後でプライマリ・ロケーションに送るためにアップデートを集め、プライマリ・ロケーションにおいて、データベース・マネージャのログからこの情報を探り出すようにすることもできる。レプリカ・ロケーションでは、全面的なレプリカまたは部分的なレプリカだけを形成することもできる。レプリカ・データベース全体あるいは、保持されているデータへの変更のみを送るようにすることができる。トランザクションによって行われた変更を種々のノードに送り、トランザクション終了処理の１部としてアクノレッジメントを受領することによって、レプリカの同期性を常に保つようにすることができる。そのような同期手法によって静的複製の整合性の問題を解決するができる。しかし、これらの手法では、そのようなシステムの性能と使用可能性の利益の多くを失う。
【００１７】
米国特許４，００７，４５０号には、各ノードが他のノードと或る種のデータセットを共有し、中央ロケーションには絶えず同期されるレプリカだけがあるがプライマリ・コピーがない、分散データ制御システムが記載されている。各ノードは、他のノードのいずれかがアップデートしようとしていないかぎり、共有されたどのデータセットをもアップデートするように作動し、複数のノードがアップデートしようとしているときには、高いプライオリティーを持つノードがアップデートを行う。各ノードはそのメモリに、共有された各データセットのノードロケーションと、共有された各データセットに対して各ノードが持つアップデート・プライオリティーをストアしている。或るノードでデータセットがアップデートされるとき、レプリカを持っているすべてのノードにそのアップデートが送られる。上記のような手法は、静的複製の整合性問題を解決することはできるが、性能と使用可能性の利益の多くが失われる。
【００１８】
米国特許４，４３２，０５７号には、分散マルチプロセシング・データベース・システムにおける資源の活用を制御するための分散システム制御の下での、データのダイナミックな複製方法が記載されている。このシステムでは、指定された現在性（ｃｕｒｒｅｎｃｙ）を持つデータへのアクセスリクエストが許され、アップデートされたデータの確認が、各ノードにおいて実行される制御プロシージャを使用することによって選択的に行われる。この場合、各ノードは、他ノードにおける共有データ項目のステータスに関するそのノードの見方をあらわし各ノードにファイルされているステータス・アンド・コントロール（ｓｔａｔｕｓ ａｎｄ ｃｏｎｔｒｏｌ ｍｅｓｓａｇｅ： ＳＡＣ）メッセージを使用する。このシステムでは、各データベース・リクエストはインターセプトされ、ローカル・コピーが現在性に対する要求を満たすかどうかが判断される。現在性が満たされない場合、そのリクエストを実行する前に、関連するノードと交渉を行うことが必要である。したがって、レプリカ・データベースの現在性は、アクセス・パターンに従ってダイナミックに変わる。
【００１９】
上記のことから、データ処理システムの１つまたは複数のロケーションにおいて複製されるジャーナルされたデータベースを含む回復力のあるデータベース・システムで使用し、それにより、各レプリカ・データベース内で維持される整合性レベルを、任意に且つ選択的に割り当てることができる方法とシステムの必要性があることがわかる。
【００２０】
【発明が解決しようとする課題】
本発明の目的は、分散データ処理システム内のデータベース・アクセス制御のための改善された方法を提供することである。
【００２１】
さらに、本発明の目的は、分散データ処理システム内のプライマリ・データベースと１つまたは複数のレプリカ・データベースとの間の整合性を維持するための改善された方法とシステムを提供することである。
【００２２】
さらに、本発明の目的は、分散データ処理システム内の回復可能なデータベース内部の複数のレプリカ・データベースに付す多様な整合性レベルをユーザが選ぶことができる、改善された方法とシステムを提供することである。
【００２３】
【課題を解決するための手段】
上述の課題を達成する方法を以下に述べる。分散データ処理システム内の１つまたは複数のロケーションで実施されるジャーナルされたデータベースを含む回復可能なデータベース・システムにおいて、プライマリ・データベースとレプリカ・データベースとの間で維持される整合性レベルをそれぞれ記述する複数の多様な整合性レベルが指定される。ユーザは、各レプリカ・データベースのための具体的な整合性レベルを選択することができる。その後、プライマリ・データベースの中のレコードをアップデートすると、そのアップデートを使って、各レプリカ・データベース内の対応するレコードに対して、そのレプリカ・データベースに選択された整合性レベルと整合のとれる方法でアップデートが始まる。このようにして、プライマリ・データベースが故障した場合にもスムーズに切り替えが行えるように、プライマリ・データベースと完全に整合性のあるレプリカ・データベースを提供することもできるし、また、完全に整合性のあるデータを必要としないアプリケーションの照会に応答するためには第２のレプリカ・データベースを提供し、これにより、そのデータベースに対するアクセスの効率を大きく向上させることもできる。
【００２４】
【実施例】
図１に、本発明の方法とシステムを実施するのに使用できる、分散データ処理システム８の概略図を示す。分散データ処理システム８は、ローカルエリア・ネットワーク（以下ＬＡＮという）１０および３２のような複数のＬＡＮを持ち、各ＬＡＮはコンピュータ１２および３０のような複数の個々のコンピュータを持つことが望ましい。もちろん、当業者には明らかなように、各ネットワークには、ホストプロセサに接続された複数のインテリジェント・ワークステーションを使用することもできる。
【００２５】
このようなデータ処理システムによく見られるように、各コンピューターは記憶装置１４および印刷出力装置１６を接続することができる。記憶装置１４は、本発明の方法とシステムにしたがい、分散データ処理システム８のユーザによって定期的にアクセスされ処理されるプライマリ・データベースまたはそのレプリカをストアするために使用される。公知の方法によって、そのようなプライマリ・データベースまたはそのレプリカは記憶装置１４にストアされ、データベースを維持しアップデートする責任を持つリソース・マネジャーまたはライブラリ・サービスと関連づけられる。
【００２６】
図１はさらに、分散データ処理システム８が、メインフレーム・コンピュータ１８のような複数のメインフレーム・コンピュータを含み、それらが通信リンク２２によってＬＡＮ１０に接続されていることを示す。また、メインフレーム・コンピュータ１８は、ＬＡＮ１０の遠隔記憶装置としてはたらく記憶装置２０に接続されている。第２のＬＡＮ３２が、ゲートウェイ・サーバ２８への通信制御装置２６および通信リンク３４を介して、ＬＡＮ１０に接続されている。ゲートウェイ・サーバ２８は、ＬＡＮ３２をＬＡＮ１０につなげる役割をする別個のコンピュータあるいはインテリジェント・ワークステーションであることが望ましい。
【００２７】
ＬＡＮ３２およびＬＡＮ１０に関連して述べたように、プライマリ・データベースまたはそのレプリカは記憶装置２０内にストアされ、そのようにストアされたプライマリ・データベースおよびそのレプリカに対するリソース・マネジャーまたはライブラリ・サービスの役割をするメインフレーム・コンピュータ１８によって制御される。
【００２８】
もちろん、当業者には明らかなように、メインフレーム・コンピュータ１８はＬＡＮ１０から地理的に遠い距離に設置することができ、同様に、ＬＡＮ１０は、ＬＡＮ３２から相当な距離離れていてもよい。たとえば、ＬＡＮ３２がカリフォルニア州にあり、ＬＡＮ１０がテキサス州にあり、メインフレーム・コンピュータがニューヨークにあってもよい。
【００２９】
上述したことからわかるように、分散データ処理ネットワーク８の或る１つの部分にいるユーザが、データ処理ネットワーク８の別の部分にストアされているデータベースにアクセスしたいことがしばしばある。そのようなクライアント／サーバ・システム環境では、データベース内にストアされたデータへのアクセスは、いわゆる「回復可能な（ｒｅｓｉｌｉｅｎｔ）データベース・システム」を提供することによって増やすことができる。回復可能なデータベース・システムとは、分散データ処理システム内の１つまたは複数のロケーションにおいて複製化されている、ジャーナルされたデータベースである。そのようなデータベースでは、１つのデータベースがプライマリ・データベースとして、他の全てのデータベースはバックアップ・レプリカとして指定される。回復可能なデータベース・システムは、故障が起こったとき１つ前のポイントに回復する。すなわち、ここでいう故障とは、データベース・レプリカの１つが在るコンピュータの故障、あるいは、レプリカの１つを破壊するような媒体故障によって引き起こされる故障のことである。クラスター管理を行うことによって、アプリケーション・プログラマおよびエンドユーザに透明で、プライマリ・レプリカが故障したときにバックアップ・レプリカにスムーズに切り替えられる回復処理を提供することができる。
【００３０】
高い使用可能性を持つデータベースを提供するためにデータベースが複製化されているシステムにおいては、そのようなシステムの自然な延長は、プライマリ・サーバのワークロードを軽減するために、ユーザがバックアップ・レプリカに照会できるようにすることである。しかし、或る整合性が強制されていない限り、レプリカ・データベースに対する照会トランザクションは、コミットしていないトランザクションによってセットされた値、あるいは、古い値を読んでしまう。あまり重要でないアプリケーションではこれでも良いかも知れないが、通常多くのアプリケーションは、プライマリ・データベースとの最低レベルの整合性を必要とする。
【００３１】
このアプリケーションについて説明する目的で、ここでは、「アプリケーション」という用語は、ユーザによって始動されデータベース・オペレーションを呼び出すアプリケーション・コードのことをいう。データベース・オペレーションを呼び出すために使用される多くの多様なアプリケーションが現在使用可能であり、そのようなアプリケーションは本発明の方法とシステムにとって修正する必要はない。典型的には、そのようなアプリケーションがデータベース・オペレーションを呼び出すときはいつでも使える「アプリケーション・スタブ」も提供される。アプリケーション・スタブは呼び出しをトラップし、その呼び出しを特別ルーチンにまわす。このアプリケーション・スタブは一般的にクラスター管理によって提供され、その後、リクエストを、プライマリ・データベースを制御する機械にわたす。故障を回復するために必要などの回復ステップも、アプリケーション・スタブによってアプリケーションから隠されている。
【００３２】
本発明の明細書で記述される「プライマリ・エージェント」はプライマリ・データベースを制御する機械の上にあり、データベース・オペレーションを実行するプロセスである。アプリケーション・プロセス１つにつき、１つのプライマリ・エージェントがある。本発明の方法とシステムで使用される「バックアップ・レシーバ」は、レプリカ・データベースへのアクセスを管理する機械の上にあり、プライマリ・データベースにほどこされた変更を記述するジャーナル・エントリを受け取り、それらのジャーナル・エントリをジャーナルのローカル・レプリカに記録するプロセスである。データベースのレプリカを制御する各機械の上の１つのデータベースに対して１つのバックアップ・レシーバ・プロセスがある。「バックアップ・アプライア」は、レプリカ・データベースを制御する機械の上にあり、データベースのローカル・レプリカにジャーナル・エントリを付すプロセスである。バックアップ・レプリカを制御する各機械の上の１つのデータベースに対して１つのバックアップ・アプライア・プロセスがある。
【００３３】
図２に、本発明の方法とシステムにしたがい実施された回復可能なデータベース・システム内の、典型的な書き込みオペレーションの制御フローの概略を示す。図に示すように、ユーザ４０はアプリケーション４２を使用し、スタブ・ルーチン４４を呼び出し、プライマリ・データベース４６内でオペレーションを実行する。プライマリ・データベース４６を制御する機械の中のプライマリ・エージェント４８がこのオペレーションを実行する。この修正によって必要になったジャーナル・エントリがジャーナル５０内に挿入され、レプリカ・データベース５２内のバックアップ・レシーバ５４、および、レプリカ・データベース６０のような他のレプリカ・データベースに広げられる。
【００３４】
バックアップ・レシーバ５４はそれらのジャーナル・エントリを受け取ったというアクノレッジメントを返し、その後、それらのジャーナル・エントリをそのジャーナルのローカルレプリカ（符号５８に示すような）内に、随時非同期的に入れる。バックアップ・アプライア５６は、ジャーナル５８内にあるそれらのジャーナル・エントリをレプリカ・データベース５２内の対応するレコードに付ける。これは、そのレコードをロックし、アップデートし、その後、アンロックすることによって行われる。この方法によって、レプリカ・データベース５２とプライマリ・データベース４６との間の整合性を保つことができる。
【００３５】
したがって、バックアップ・アプライア５６により、ユーザが直接レプリカ・データベース５２からレコードを読んだ場合には部分的にしかアップデートされていないレコードを読むのを防ぐことによって、最低レベルの整合性を提供することができる。もちろん、データベース読取りオペレーションに対する制御フローは、図２に示したものに似ている。しかし、ジャーナル・エントリは生成されず、したがって、バクアップ・レシーバとバックアップ・アプライアは使用されない。図２に示した環境は、たとえば、ＩＢＭ ＡＳ／４００のようなコンピュータ・システムを使用して実施することができる。
【００３６】
次に、本発明の重要な特徴として、選択されたレプリカ・データベースをユーザが使用する際にユーザが選択する複数の多様な整合性レベルが提供される。回復可能なデータベース・システム内の同時実行については、「同時実行制御とデータベース・システムの回復」（”Ｃｏｎｃｕｒｒｅｎｃｅ Ｃｏｎｔｒｏｌ ａｎｄ Ｒｅｃｏｖｅｒｙ ｉｎ Ｄａｔａｂａｓｅ Ｓｙｓｔｅｍｓ” Ａｄｄｉｓｏｎ−Ｗｅｓｌｅｙ Ｐｕｂｌｉｓｈｉｎｇ Ｃｏｍｐａｎｙ， １９８７）に記載があり、複数バージョンの同時実行制御モデルが記述されている。このシステムにおいては、バックアップ・レプリカ・データベースは常にプライマリ・データベースより遅れ、したがって、データベースのバージョンが２つできる。上記文献のシステムに対比して、本発明の方法とシステムは、考慮するべき２つの異なる整合性属性を提供する。
【００３７】
具体的には、これらの２つの属性は、データベース・システム内のトランザクションの順序付け（ｏｒｄｅｒｉｎｇ）と、これらのトランザクションの直列化可能性（ｓｅｒｉａｌｉｚａｂｉｌｉｔｙ）を含む。これらの２つの属性はいくつかの方法で組み合わせることができ、その結果６つの異なる整合性レベルができる。したがって、本発明の重要な特徴にしたがい、レプリカ・データベースから読み込む照会に対し、トランザクションの順序付けに関して３つの異なる整合性レベルが考慮される。もちろん、当業者には明らかなように、レコード・アップデートの後の整合性維持のために、最大時間遅れの値を指定することができる。「レベル０」整合性レベルは、レプリカ・データベース内の古い値を使って照会することを許す。「レベル１」整合性レベルは、レプリカ・データベースから最新のコミットされた値だけを使って照会できるという整合性を課す。最後に、「レベル２」整合性レベルは、その値がコミットに達したか否かに拘わらず、レプリカ・データベースからの最新の値だけを使って照会するという整合性を課す。
【００３８】
次に、上述したように、所望の整合性レベルを割り当てるために、本発明の回復可能なデータベース・システム内のトランザクションの直列化可能性について考慮しなければならない。この属性によって、現実には同時にインターリーブして実行されたトランザクションが、或る直列順序で実行されたのと論理的には等しい効果を持たせることを保証する。回復可能なデータベース・システムは、コミットメント制御の下で動くアプリケーションが、コミットメント制御の下にない他のアプリケーションと同時に同じデータベースに対して動くことを許す。したがって、異なるアプリケーションは、直列化可能性を必要としてもしなくても良いことが考えられる。したがって、本発明の回復可能なデータベース・システム内のレプリカ・データベースにユーザまたはシステム管理者が異なる多様な整合性レベルをセットすることを許すとき、整合性レベルを制御するために２つの異なる変数がセットされなければならない。順序付けは、「レベル０」、「レベル１」、あるいは「レベル２」にセットされる。さらに、直列化可能性は「必要」あるいは「不要」にセットされる。
【００３９】
図３に、本発明の方法とシステムによる回復可能なデータベース内での複数の多様な整合性レベルのセットを説明する論理フローの概略図を示す。図示したように、このプロセスは、ブロック７０で始まり、ブロック７２に進む。ブロック７２で、整合性レベルの選択が行われたかどうかが判断される。Ｎｏの場合、このプロセスは、ユーザまたはシステム管理者が回復可能なデータベース・システム内のレプリカ・データベースの整合性レベルをセットしたいという意志表示を示すまで、繰り返される。
【００４０】
ブロック７２で整合性レベルの選択が行われた場合、プロセスはブロック７４に進む。ブロック７４は、本発明の回復可能なデータベース・システム内の最初のレプリカ・データベースに対するプロセスを示す。次にプロセスはブロック７６に進む。ブロック７６で、プロセスは、ユーザあるいはシステム・オペレータが所望の整合性レベルをセットすることを促す。次に、プロセスはブロック７８に進む。ブロック７８で、所望の整合性レベルが入れられたかどうかが判断され、Ｎｏの場合は、プロセスは繰り返しブロック７６に戻り、再度所望の整合性レベルを入れるように促す。
【００４１】
ブロック７８で所望の整合性レベルが入れられたと判断されれば、プロセスはブロック８０に進む。ブロック８０で、直列化可能性の要求があるかどうかをユーザあるいはシステム・オペレータに促す。すなわち、インターリーブされて実行されたトランザクションが、或る直列順序で実行されたのと論理的に等しいものとしたいかどうかを、ユーザあるいはシステム・オペレータに意志表示してもらう。次に、プロセスはブロック８２に進む。ブロック８２で、ユーザが直列化可能性要求を入れたかどうかを判断し、Ｎｏの場合は繰り返しブロック８０に戻り、再度、このデータベースに対する直列化可能性要求があるか否かを入れるようにユーザに促す。ユーザが直列化可能性要求を入れた後、プロセスはブロック８２からブロック８４に進む。ブロック８４で、整合性レベルを付けるべきレプリカ・データベースがまだあるかどうかを判断し、以上のプロセスで整合性レベルを付けたレプリカ・データベースが最後のレプリカでない場合には、プロセスは繰り返しブロック７６に戻り、再度上述したプロセスを実行する。ブロック８４がＹｅｓの場合、すなわち、最後のレプリカ・データベースに所望の整合性レベルが付けられた場合は、プロセスはブロック８６に進みリターンする。
【００４２】
図４から図１０に、本発明の方法とシステムによる回復可能なデータベース・システム内で、レコード・アップデートが行われた後の、複数の多様な整合性レベルを実行する方法を示すフローチャートの概略図を示す。図４に示すように、プロセスはブロック９０から始まる。次に、プロセスはブロック９２に進み、レコード・アップデートが起こったかどうかを判断する。レコード・アップデートがまだ起こっていない場合、このプロセスは、プライマリ・データベースにレコード・アップデートが起こるまで繰り返される。次に、レコード・アップデートが起こったときに、プロセスはブロック９２からブロック９４に進む。
【００４３】
ブロック９４は、本発明の回復可能なデータベース・システム内の各レプリカ・データベースに対して繰り返して行われるプロセスの始まりを示す。プロセスはブロック９４からブロック９６に進む。ブロック９６で、所望の整合性レベルが「レベル０」にセットされたかどうかが判断される。Ｙｅｓであれば、プロセスはブロック９８に進む。ブロック９８で直列化可能性が要求されているかどうかが判断され、Ｙｅｓの場合、プロセスは、図４のコネクタ１００を介して図５の論理フローに進む。そうでない場合、すなわち、直列化可能性が不要であった場合、プロセスは、図４のコネクタ１０２を介して図６の論理フローに進む。
【００４４】
再びブロック９６に戻り、所望の整合性レベルが「レベル０」にセットされなかった場合は、プロセスはブロック１０４に進む。ブロック１０４で、所望の整合性レベルが「レベル１」にセットされたかどうかが判断される。Ｙｅｓであれば、プロセスはブロック１０４からブロック１０６に進み、再度、直列化可能性が要求されているかどうかが判断される。直列化可能性が要求されている場合には、プロセスは、図４のコネクタ１０８を介して図７の論理フローに進む。そうでない場合、すなわち、直列化可能性が不要であった場合、コネクタ１１０を介して図８の論理フローに進む。
【００４５】
再びブロック１０４に戻り、所望の整合性レベルが「レベル１」でない場合、プロセスはブロック１０４からブロック１１２に進む。ブロック１１２で、このレプリカ・データベースに対する所望の整合性レベルが「レベル２」にセットされたかどうかが判断され、もしＹｅｓであれば、プロセスはブロック１１２からブロック１１４に進む。前と同じように、ブロック１１４で直列化可能性が要求されたかどうかが判断され、Ｙｅｓの場合、プロセスはコネクタ１１６を介して図９の論理フローに進む。Ｎｏの場合、すなわち、直列化可能性が不要であった場合、プロセスはブロック１１４からコネクタ１１８を介して図１０の論理フローに進む。最後に、再びブロック１１２で、所望の整合性レベルが「レベル２」でない場合、プロセスはブロック１２０に進みリターンする。
【００４６】
図５に、レプリカ・データベース内で整合性「レベル０」が選択され直列化可能性が要求されたレコードに対応するレコードにレコード・アップデートが行われた場合に起こる論理フローの順序を示す。図５から図１０のそれぞれには、番号１３０、１３２、１３４、および、１３６を付けた４つのカラムがある。それぞれの場合において、カラム１３０はプライマリ・データベ ースに起こるアクティビティを示す。カラム１３２はジャーナル・エントリのフローを示し、カラム１３４は考慮対象の特定のレプリカ・データベース内のバックアップ・レシーバに起こるアクティビティを示す。最後に、カラム１３６は、レプリカ・データベース内のバックアップ・アプライア（図２を参照）のアクティビティを示す。
【００４７】
したがって、図５のカラム１３０を見ると、ブロック１５０に、レコードＲ１に対するアップデートＵ１を含むトランザクションＴ１が示されている。この結果ジャーナル・エントリ（ＪＥ１）が作られ、これがバックアップ・レシーバに送られる。次に、バックアップ・レシーバはアクノレッジメントをプライマリ・データベースに送り、ジャーナル・エントリ（ＪＥ１）を、レプリカ・データベースにあるローカルジャーナルに入れる。次に、バックアップ・アプライアはレコードＲ１をロックし、ジャーナル・エントリ（ＪＥ１）を付ける。
【００４８】
次に、ブロック１５２に、レコードＲ２に対するアップデートＵ２を含むトランザクションＴ２が示されている。この結果ジャーナル・エントリ（ＪＥ２）が作られ、これがバックアップ・レシーバに送られる。次に、バックアップ・レシーバはアクノレッジメントをプライマリ・データベースに送り、ジャーナル・エントリ（ＪＥ２）をローカル・ジャーナルに入れる。その後、バックアップ・アプライアはレコードＲ２をロックし、ジャーナル・エントリ（ＪＥ２）を付ける。
【００４９】
次に、ブロック１５４に、レコードＲ３に対するアップデートＵ３を含むトランザクションＴ１を示す。このトランザクションの結果第３のジャーナル・エントリ（ＪＥ３）が作られ、これがバックアップ・レシーバに送られる。バックアップ・レシーバは再度アクノレッジメントを送り、このジャーナル・エントリをローカルジャーナルに入れる。次に、バックアップ・アプライアはレコードＲ３をロックし、ジャーナル・エントリ（ＪＥ３）を付ける。
【００５０】
最後に、ブロック１５６に、トランザクションＴ１のためのコミット・オペレーションを示す。このトランザクションの結果、ジャーナル・エントリ（ＪＥ４）が作られ、バックアップ・レシーバに送られる。バックアップ・レシーバはアクノレッジメントをプライマリ・データベースに送り、ジャーナル・エントリ（ＪＥ４）をローカルジャーナルに入れる。次に、バックアップ・アプライアはレコードＲ１とＲ３に対するロックをリリースする。
【００５１】
図６は、整合性レベルを「レベル０」にセットし直列化可能性を不要にしたレプリカ・データベース内のレコードにアップデートをした結果起こる論理フローを示す。説明を簡単にするために、図６から図１０のカラムおよびトランザクションは、図５に使ったものと同じ番号を使用している。上述したのと同じように、プロセスは、レコードＲ１に対するアップデートＵ１を含むトランザクションＴ１を示すブロック１５０から始まる。このトランザクションの結果、ジャーナル・エントリ（ＪＥ１）が作られ、これがバックアップ・レシーバに結合される。アクノレッジメントがバックアップ・レシーバからプライマリ・データベースに送られ、ジャーナル・エントリ（ＪＥ１）がローカル・ジャーナルに入れられる。次に、バックアップ・アプライアはレコードＲ１をロックし、ジャーナル・エントリ（ＪＥ１）を付ける。その後、直列化可能性が不要なので、バックアップ・アプライアはレコードＲ１をリリースする。
【００５２】
ブロック１５２に、レコードＲ２に対するアップデートＵ２を含むトランザクションＴ２を示す。このトランザクションの結果ジャーナル・エントリ（ＪＥ２）が作られ、これがバックアップ・レシーバに送られる。バックアップ・レシーバはアクノレッジメントをプライマリ・データベースに送り、ジャーナル・エントリ（ＪＥ２）をローカルジャーナルに入れる。次に、バックアップ・アプライアはレコードＲ２をロックし、ジャーナル・エントリ（ＪＥ２）を付け、その後、レコードＲ２をリリースする。
【００５３】
ブロック１５４に、レコードＲ３に対するアップデートＵ３を含むトランザクションＴ１の追加部分を示す。このトランザクションの結果ジャーナル・エントリ（ＪＥ３）が作られ、バックアップ・レシーバに送られる。バックアップ・レシーバはアクノレッジメントをプライマリ・データベースに送り、ジャーナル・エントリ（ＪＥ３）をローカルジャーナルに入れる。次に、バックアップ・アプライアはレコードＲ３をロックし、ジャーナル・エントリ（ＪＥ３）を付け、その後、レコードＲ３をリリースする。
【００５４】
最後に、ブロック１５６に、トランザクションＴ１に対するコミット・オペレーションを示す。このコミット・オペレーションの結果、ジャーナル・エントリ（ＪＥ４）が作られ、バックアップ・レシーバに送られる。アクノレッジメントがバックアップ・レシーバによりプライマリ・データベース送られ、ジャーナル・エントリ（ＪＥ４）がローカルジャーナルに入れられる。直列化可能性が不要であるので、このコミット・オペレーションの結果、バックアップ・アプライアによるアクティビティは起こらない。
【００５５】
次に、図７に、レプリカ・データベースに対して整合性「レベル１」が選択され直列化可能性が要求されている場合のプライマリ・データベース内のレコードに対するアップデートへの応答の方法を示す論理フローを示す。前と同じように、ブロック１５０は、レコードＲ１に対するアップデートＵ１を含むトランザクションＴ１を示す。このトランザクションの結果ジャーナル・エントリ（ＪＥ１）が作られ、バックアップ・レシーバに送られる。アクノレッジメントがバックアップ・レシーバによってプライマリ・データベースに送られ、ジャーナル・エントリ（ＪＥ１）がローカルジャーナルに入れられる。次に、バックアップ・アプライアはこのジャーナル・エントリ（ＪＥ１）をバッファにストアする。上述したように、整合性「レベル１」は、照会がコミットされた最新の値のみを読むことを課しているので、当業者には明らかなように、レコードＲ１に対するアップデートは、コミット・トランザクションが起こるまでの間、必ずバッファにストアされなければならない。
【００５６】
次に、ブロック１５２に示すように、レコードＲ２に対するアップデートＵ２を含むトランザクションＴ２が起こる。この結果ジャーナル・エントリ（ＪＥ２）が作られ、バックアップ・レシーバに結合される。バックアップ・レシーバは、アクノレッジメントをプライマリ・データベースに送り、ジャーナル・エントリ（ＪＥ２）をローカルジャーナルに入れる。前と同じように、次に、バックアップ・アプライアはこのジャーナル・エントリ（ＪＥ２）をバッファにストアする。
【００５７】
次に、ブロック１５４に示すように、レコードＲ３に対するアップデートＵ３を含むトランザクションＴ１が起こる。この結果ジャーナル・エントリ（ＪＥ３）が作られ、バックアップ・レシーバに結合される。前と同じように、アクノレッジメントがバックアップ・レシーバからプライマリ・データベースに送られ、ジャーナル・エントリ（ＪＥ３）がローカルジャーナルに入れられる。バックアップ・アプライアはこのジャーナル・エントリ（ＪＥ３）をバッファ内にストアする。
【００５８】
最後に、ブロック１５６に示すように、トランザクションＴ１のためのコミット・オペレーションが起こる。この結果、ジャーナル・エントリ（ＪＥ４）が作られ、バックアップ・レシーバに送られる。バックアップ・レシーバはレコードＲ１とＲ３をロックし、アクノレッジメントをプライマリ・データベースに送る。その後、バックアップ・アプライアはトランザクションＴ１からジャーナル・エントリを取り出し、該当するジャーナル・エントリ、すなわち、トランザクションＴ１に関連しているジャーナル・エントリ（ＪＥ１およびＪＥ３）を付ける。その後、レコードＲ１およびＲ３はリリースされる。したがって、レコードＲ１およびＲ３に対するアップデートは、そのトランザクションのためのコミット・オペレーションが起こるまで、バックアップ・アプライアによって適用されない。
【００５９】
図８に、整合性レベルを「レベル１」に、直列化可能性を不要にセットしたレプリカ・データベース内でアップデートされたレコードに対する応答方法を記述した論理フローを示す。前と同じように、ブロック１５０は、レコードＲ１に対するアップデートＵ１を含むトランザクションＴ１を示す。この結果、ジャーナル・エントリ（ＪＥ１）が作られ、バックアップ・レシーバに結合される。バックアップ・レシーバはアクノレッジメントをプライマリ・データベースに送り、このジャーナル・エントリ（ＪＥ１）をローカルジャーナルに入れる。次に、ジャーナル・エントリ（ＪＥ１）は、バックアップ・アプライアによってバッファにストアされる。
【００６０】
次に、ブロック１５２に示すように、レコードＲ２に対するアップデートＵ２を含むトランザクションＴ２が起こる。この結果、ジャーナル・エントリ（ＪＥ２）が作られ、バックアップ・レシーバに結合される。次に、バックアップ・レシーバはアクノレッジメントをプライマリ・データベースに送り、このジャーナル・エントリ（ＪＥ２）をローカルジャーナルに入れる。次に、前と同じように、このジャーナル・エントリはバックアップ・アプライアによってバッファにストアされる。
【００６１】
ブロック１５４で、レコードＲ３に対するアップデートＵ３を含むトランザクションＴ１が起こる。この結果ジャーナル・エントリ（ＪＥ３）が作られ、バックアップ・レシーバに結合される。アクノレッジメントがバックアップ・レシーバからプライマリ・データベースに送られ、ジャーナル・エントリ（ＪＥ３）がローカルジャーナル内にストアされる。次に、前と同じように、ジャーナル・エントリ（ＪＥ３）がバックアップ・アプライアによってバッファにストアされる。
【００６２】
最後に、ブロック１５６に示すように、トランザクションＴ１のためのコミット・オペレーションが起こる。この結果ジャーナル・エントリ（ＪＥ４）が作られ、バックアップ・レシーバに結合される。次に、バックアップ・レシーバはレコードＲ１とＲ３をロックし、アクノレッジメントをプライマリ・データベースに送る。その後、バックアップ・アプライアはトランザクションＴ１に対するジャーナル・エントリを取り出し、第１のジャーナル・エントリ（ＪＥ１）を適用する。次に、レコードＲ１がリリースされる。次に、トランザクションＴ１に対する第２のジャーナル・エントリ（ＪＥ３）がレコードＲ３に適用され、そのレコードはリリースされる。図７の論理フローとは対照的に、図８の論理フローでは直列化可能性の要求がないので、各レコードはそのアップデートが適用された後でリリースされる点に留意する必要がある。
【００６３】
次に、図９に、整合性レベルを「レベル２」にセットし直列化可能性を必要とするプライマリ・データベース内の対応するレコードのアップデートに対する、レプリカ・データベースの応答方法を記述した論理フローを示す。前と同じように、ブロック１５０で、レコードＲ１に対するアップデートＵ１を含むトランザクションＴ１が起こる。このトランザクションの結果、ジャーナル・エントリ（ＪＥ１）が作られ、バックアップ・レシーバに送られる。次に、バックアップ・レシーバはＲ１をロックし、アクノレッジメントをプライマリ・データベースに送る。次に、ジャーナル・エントリ（ＪＥ１）がローカルジャーナルに入れられ、バックアップ・アプライアは直ちにジャーナル・エントリ（ＪＥ１）を適用する。当業者には明らかなように、整合性「レベル２」は、 照会は最新の値（コミットが起こったかどうかに拘わらず）のみを読むことによって行うことを課している。したがって、レコードＲ１に対するアップデートは、バックアップ・アプライアによって直ちに適用される。
【００６４】
ブロック１５２で、レコードＲ２に対するアップデートＵ２を含むトランザクションＴ２が起こる。この結果、ジャーナル・エントリ（ＪＥ２）が作られ、バックアップ・レシーバに結合される。次に、バックアップ・レシーバはレコードＲ２をロックし、アクノレッジメントをプライマリ・データベースに送り、ジャーナル・エントリ（ＪＥ２）をローカルジャーナルに入れる。次に、バックアップ・アプライアは直ちにジャーナル・エントリ（ＪＥ２）を適用し、レコードＲ２を最新の値にアップデートする。
【００６５】
ブロック１５４で、レコードＲ３に対するアップデートＵ３を含むトランザクションＴ１の第２部分が起こる。この結果、ジャーナル・エントリ（ＪＥ３）が作られてバックアップ・レシーバに結合される。次に、バックアップ・レシーバはレコードＲ３をロックし、アクノレッジメントをプライマリ・データベースに送る。次に、ジャーナル・エントリ（ＪＥ３）がローカルジャーナルに入れられ、バックアップ・アプライアはこのジャーナル・エントリ（ＪＥ３）をレコードＲ３に適用する。
【００６６】
最後に、ブロック１５６で、トランザクションＴ１に対するコミット・オペレーションが起こる。この結果、ジャーナル・エントリ（ＪＥ４）が作られ、バックアップ・レシーバに結合される。次に、バックアップ・レシーバはアクノレッジメントをプライマリ・データベースに送り、このジャーナル・エントリ（ＪＥ４）をローカルジャーナルに入れる。次に、バックアップ・アプライアはレコードＲ１とＲ３をリリースし、必要に応じて、このトランザクション部分の直列化可能性を維持する。
【００６７】
最後に、図１０に、整合性「レベル２」をセットし直列化可能性を要求しないレプリカ・データベースの中のプライマリ・データベース内のレコードに対するアップデートに応答して起こる論理フローを示す。前と同様に、ブロック１５０で、レコードＲ１に対するアップデートＵ１を含むトランザクションＴ１が起こる。この結果、ジャーナル・エントリ（ＪＥ１）が作られバックアップ・レシーバに結合される。次に、バックアップ・レシーバはレコードＲ１をロックし、アクノレッジメントをプライマリ・データベースに送る。次に、ジャーナル・エントリ（ＪＥ１）がローカルジャーナルに入れられる。次に、バックアップ・アプライアはジャーナル・エントリ（ＪＥ１）を適用し、直列化可能性が要求されていないので、直ちにレコードＲ１をリリースする。
【００６８】
次に、ブロック１５２に示すように、レコードＲ２に対するアップデートＵ２を含むトランザクションＴ２が起こる。この結果、ジャーナル・エントリ（ＪＥ２）が作られバックアップ・レシーバに結合される。次に、バックアップ・レシーバはレコードＲ２をロックし、アクノレッジメントをプライマリ・データベースに送る。次に、ジャーナル・エントリ（ＪＥ２）がローカルジャーナルに入れられる。次に、バックアップ・アプライアはジャーナル・エントリ（ＪＥ２）を適用し、レコードＲ２をリリースする。
【００６９】
次に、ブロック１５４に示すように、レコードＲ３に対するアップデートＵ３を含むトランザクションＴ１の次の部分が起こる。この結果、ジャーナル・エントリ（ＪＥ３）が作られ、バックアップ・レシーバに結合される。次に、バックアップ・レシーバはレコードＲ３をロックし、アクノレッジメントをプライマリ・データベースに送る。次に、ジャーナル・エントリ（ＪＥ３）がローカルジャーナルに入れられ、バックアップ・アプライアはジャーナル・エントリ（ＪＥ３）を適用し、レコードＲ３をリリースする。以上の記述から当業者には明らかなように、この整合性レベルでは直列化可能性が要求されていないので、レコードＲ１およびＲ３に対するアップデートが行われ、各レコードは、そのアップデートが行われた後直ちにリリースされる。
【００７０】
最後に、ブロック１５６で、トランザクションＴ１に対するコミット・オペレーションが起こる。この結果、ジャーナル・エントリ（ＪＥ４）が作られ、バックアップ・レシーバに結合される。次に、バックアップ・レシーバはこのジャーナル・エントリのアクノレッジメントを送り、ジャーナル・エントリ（ＪＥ４）をローカルジャーナルに入れる。
【００７１】
まとめとして、本発明の構成に関して以下の事項を開示する。
（１）分散データ処理システム内でのデータベース・アクセス効率を向上させる方法であって、前記分散データ処理システム内において、ストアされた複数のレコードを持つ１つのデータベースを選択しプライマリ・データベースとして指定するステップと、前記分散データ処理システム内の第２の物理的ロケーションにおいて前記プライマリ・データベースを複製するステップと、前記プライマリ・データベースと前記の複製されたレプリカ・データベースとの間に維持される複数の多様な整合性レベルを指定するステップと、ユーザに前記の複数の多様な整合性レベルから１つを指定させるステップと、を有し、前記プライマリ・データベース内のレコードに対するアップデートに応答して、前記プライマリ・データベースと前記レプリカ・データベースとの間に前記の複数の多様な整合性レベルの前記の指定された１つを自動的に維持する前記方法。
（２）前記分散データ処理システム内の第３の物理的ロケーションにおいて前記プライマリ・データベースを複製するステップをさらに有する、前記（１）に記載の方法。
（３）ユーザに前記の複数の多様な整合性レベルから１つを指定させる前記ステップが、前記プライマリ・データベースとそのそれぞれのレプリカとの間に維持される前記の複数の多様な整合性レベルから別の１つを指定させるステップを有する、前記（２）に記載の方法。
（４）分散データ処理システム内でのデータベース・アクセス効率を向上させるシステムであって、前記分散データ処理システム内において、ストアされた複数のレコードを持つプライマリ・データベースと、前記分散データ処理システム内の第２の物理的ロケーションにおいてストアされている前記プライマリ・データベースのレプリカと、前記プライマリ・データベースと前記レプリカ・データベースとの間に維持される複数の多様な整合性レベルを指定する手段と、ユーザに前記の複数の多様な整合性レベルから１つを指定させる手段と、前記プライマリ・データベース内のレコードに対するアップデートに応答して、前記プライマリ・データベースと前記レプリカ・データベースとの間に前記の複数の多様な整合性レベルの前記の指定された１つを自動的に維持する手段と、を有するシステム。
（５）前記分散データ処理システム内の第３の物理的ロケーションにおいてストアされている前記プライマリ・データベースの第２のレプリカをさらに有する、前記（４）に記載のシステム。
（６）ユーザに前記の複数の多様な整合性レベルから１つを指定させる前記手段が、前記プライマリ・データベースとそのそれぞれのレプリカとの間に維持される前記の複数の多様な整合性レベルから別の１つを指定させる手段を有する、前記（５）に記載のシステム。
（７）分散データ処理システム内でのデータベース・アクセス効率を向上させる方法であって、前記分散データ処理システム内において、ストアされた複数のレコードを持つ１つのデータベースを選択しプライマリ・データベースとして指定するステップと、前記分散データ処理システム内の第２の物理的ロケーションにおいて前記プライマリ・データベースを複製するステップと、前記プライマリ・データベース内の１つの選択されたレコードに対するアップデートに応答して、前記の複製されたデータベース内の対応する選択されたレコードへのアクセスを自動的にロックするステップと、前記の複製されたデータベース内の前記の選択されたレコードをアップデートするステップと、前記アップデートの後で、前記の選択されたレコードへのアクセスをリリースするステップと、前記分散データ処理システム内のユーザに、前記プライマリ・データベースおよび前記の複製されたデータベースの中のレコードを照会させるステップと、を有し、データの絶対的な整合性を維持するとともにデータアクセスの使用可能性を向上させる方法。
（８）前記プライマリ・データベース内のレコードに対する各アップデートが、コミット・オペレーションを行う前の１つの整合性時点に戻り、前記の選択されたレコードへのアクセスを前記アップデートの後でリリースする前記ステップが、前記アップデートに続くコミット・オペレーションの後でのみ前記の選択されたレコードへのアクセスをリリースするステップを有する、前記（７）に記載の方法。
（９）分散データ処理システム内でのデータベース・アクセス効率を向上させるシステムであって、前記分散データ処理システム内において、ストアされた複数のレコードを持つプライマリ・データベースと、前記分散データ処理システム内の第２の物理的ロケーションにおいてストアされている前記プライマリ・データベースのレプリカと、前記プライマリ・データベース内の１つの選択されたレコードに対するアップデートに応答して、前記の複製されたデータベース内の対応する選択されたレコードへのアクセスを自動的にロックする手段と、前記の複製されたデータベース内の前記の選択されたレコードをアップデートする手段と、前記アップデートの後で、前記の選択されたレコードへのアクセスをリリースする手段と、前記分散データ処理システム内のユーザに、前記プライマリ・データベースおよび前記の複製されたデータベースの中のレコードを照会させる手段と、を有し、データの絶対的な整合性を維持するとともにデータアクセスの使用可能性を向上させるシステム。
（１０）前記プライマリ・データベースを、いかなる時点でも、コミット・オペレーションを行う前の整合性時点に戻す手段をさらに有する、前記（９）に記載のシステム。
（１１）前記アップデートの後で前記の選択されたレコードへのアクセスをリリースする前記手段が、前記アップデートに続くコミット・オペレーションの後でのみ前記の選択されたレコードへのアクセスをリリースする手段を有する、前記（１０）に記載のシステム。
【００７２】
【発明の効果】
本発明の方法とシステムによって、ユーザあるいはシステム・オペレータは、バックアップ・サーバ内のレプリカ・データベースに適する任意の整合性レベルを広範な整合性レベルから選択できるようになる（この選択には、整合性と性能との間のトレードオフが含まれる）。この方法とシステムにより、最低限の整合性レベルでは、１つのレプリカ・データベースにおいて、古い、コミットされていない値を読むことができる一方、他方では、プライマリ・データベースの第２のレプリカ内で、あたかも、照会がプライマリ・データベースから読み込みを行ったのと同じ結果を返すことができる最大レベルの整合性を提供することもできる。このようにして、上述した回復可能なデータベース・システム内において、データベースへのアクセスの効率を大いに改善することができる。
【図面の簡単な説明】
【図１】本発明の方法およびシステムを実施するのに使用できる分散データ処理システムの概略図である。
【図２】本発明の方法およびシステムにしたがって実施される回復可能なデータベース・システム内での、典型的な書き込みオペレーションの概略制御フローを示す。
【図３】本発明の方法およびシステムによる回復可能なデータベース内での複数の多様な整合性レベルの設定を図示する概略論理フローチャートである。
【図４】本発明による複数の多様な整合性レベルの実施を図示する概略論理フローチャートであり、図５に続く。
【図５】図４に続く論理フローチャート。
【図６】図５に続く論理フローチャート。
【図７】図６に続く論理フローチャート。
【図８】図７に続く論理フローチャート。
【図９】図８に続く論理フローチャート。
【図１０】図９に続く論理フローチャート。
【符号の説明】
８ 分散データ処理システム
１０、３２ ローカルエリア・ネットワーク（ＬＡＮ）
１２、３０ コンピュータ
１４、２０ 記憶装置
１６ 印刷出力装置
１８ メインフレーム・コンピュータ
２２、２４、３４ 通信リンク
２６ 通信制御装置
２８ ゲートウェイ・サーバ
４０ ユーザ
４２ アプリケーション
４４ スタブ・ルーチン
４６ プライマリ・データベース
４８ プライマリ・エージェント
５０、５８ ジャーナル
５２ レプリカ・データベース
５４、６０ バックアップ・レシーバ
５６ バックアップ・アプライア
Claims (11)
- 分散データ処理システム内でのデータベース・アクセス効率を向上させる方法であって、
前記分散データ処理システム内において、ストアされた複数のレコードを持つ１つのデータベースを選択しプライマリ・データベースとして指定するステップと、
前記分散データ処理システム内の第２の物理的ロケーションにおいて前記プライマリ・データベースを複製するステップと、
前記分散データ処理システムが、それぞれが前記プライマリ・データベースと前記の複製されたレプリカ・データベースとの間で維持される１つの整合性を記述する複数の整合性レベルであって、前記レプリカ・データベースのレコードへの照会を、前記プライマリ・データベースのアップデートに起因する前記照会されるレコードに対するアップデートがコミットされている場合にのみ許すレベルと、前記照会を、前記プライマリ・データベースのアップデートに起因する前記照会されるレコードに対するアップデートがコミットされたか否かに関わらず許すレベルを含む整合性レベルを提供するステップと、
前記レプリカ・データベースの各々に対する照会トランザクションのために、ユーザに前記整合性レベルから前記各レプリカ・データベース毎に整合性レベルを選択させるステップと、
前記プライマリ・データベース内のレコードに対するアップデートに応答して、前記レプリカ・データベース内の対応するレコードに対して、該レプリカ・データベースに選択された前記整合性レベルに応じた手順にしたがってアップデートすることにより、前記プライマリ・データベースと前記レプリカ・データベースとの間に前記選択された１つの整合性レベルによって記述される整合性を自動的に維持するステップと、
を含む方法。 - 前記分散データ処理システム内の第３の物理的ロケーションにおいて前記プライマリ・データベースを複製するステップをさらに有する、請求項１に記載の方法。
- 前記整合性レベルは２つの異なる整合性の組み合わせからなり、ユーザに前記複数の整合性レベルを選択させる前記ステップが、ユーザに前記２つの異なる整合性をそれぞれ選択させるステップを有する、請求項２に記載の方法。
- 分散データ処理システム内でのデータベース・アクセス効率を向上させるシステムであって、
前記分散データ処理システム内において、記憶された複数のレコードを持つプライマリ・データベースと、
前記分散データ処理システム内の第２の物理的ロケーションにおいて記憶されている前記プライマリ・データベースのレプリカと、
それぞれが前記プライマリ・データベースと前記の複製されたレプリカ・データベースとの間で維持される１つの整合性を記述する複数の整合性レベルであって、前記レプリカ・データベースのレコードへの照会を、前記プライマリ・データベースのアップデートに起因する前記照会されるレコードに対するアップデートがコミットされている場合にのみ許すレベルと、前記照会を、前記プライマリ・データベースのアップデートに起因する前記照会されるレコードに対するアップデートがコミットされたか否かに関わらず許すレベルを含む整合性レベルを提供する手段と、
前記レプリカ・データベースの各々に対する照会トランザクションのために、ユーザに前記整合性レベルから前記各レプリカ・データベース毎に整合性レベルを選択させる手段と、
前記プライマリ・データベース内のレコードに対するアップデートに応答して、前記レプリカ・データベース内の対応するレコードに対して、該レプリカ・データベースに選択された前記整合性レベルに応じた手順にしたがってアップデートすることにより、前記プライマリ・データベースと前記レプリカ・データベースとの間に前記選択された１つの整合性レベルによって記述される整合性を自動的に維持する手段と、を有するシステム。 - 前記分散データ処理システム内の第３の物理的ロケーションにおいて記憶されている前記プライマリ・データベースの第２のレプリカをさらに有する、請求項４に記載のシステム。
- 前記整合性レベルは２つの異なる整合性の組み合わせからなり、ユーザに前記複数の整合性レベルを選択させる前記手段が、ユーザに前記２つの異なる整合性をそれぞれ選択させる手段を有する、請求項５に記載のシステム。
- 分散データ処理システム内でのデータベース・アクセス効率を向上させる方法であって、
前記分散データ処理システム内において、記憶された複数のレコードを持つ１つのデータベースを選択しプライマリ・データベースとして指定するステップと、
前記分散データ処理システム内の第２の物理的ロケーションにおいて前記プライマリ・データベースを複製するステップと、
前記分散データ処理システムが、それぞれが前記プライマリ・データベースと前記の複製されたレプリカ・データベース毎に維持される１つの整合性を記述する複数の整合性レベルであって、前記レプリカ・データベースのレコードへの照会を、前記プライマリ・データベースのアップデートに起因する前記照会されるレコードに対するアップデートがコミットされている場合にのみ許すレベルと、前記照会を、前記プライマリ・データベースのアップデートに起因する前記照会されるレコードに対するアップデートがコミットされたか否かに関わらず許すレベルを含む整合性レベルを提供するステップと、
前記レプリカ・データベースの各々に対する照会トランザクションのために、ユーザに前記整合性レベルから前記各レプリカ・データベース毎に整合性レベルを選択させるステップと、
前記プライマリ・データベース内のレコードに対するアップデートに応答して、前記レプリカ・データベース内の対応するレコードに対して、該レプリカ・データベースに選択された前記整合性レベルに応じた手順にしたがってアップデートするステップとを含み、
該アップデートするステップが、
前記プライマリ・データベース内の１つの選択されたレコードに対するアップデートに応答して、前記の複製されたデータベース内の対応する選択されたレコードへのアクセスを自動的にロックするステップと、
前記の複製されたデータベース内の前記の選択されたレコードをアップデートするステップと、
前記アップデートの後で、前記の選択されたレコードへのアクセスをリリースするステップと、
前記分散データ処理システム内のユーザに、前記プライマリ・データベースおよび前記の複製されたデータベースの中のレコードを照会させるステップと、
を含み、前記選択された整合性レベルを維持させ、データの絶対的な整合性を維持するとともにデータアクセスの使用可能性を向上させる、方法。 - 前記プライマリ・データベース内のレコードに対する各アップデートが、コミット・オペレーションを行う前の１つの整合性時点にまで戻すステップを含み、前記の選択されたレコードへのアクセスを前記アップデートの後でリリースする前記ステップが、前記アップデートに続くコミット・オペレーションの後でのみ前記の選択されたレコードへのアクセスをリリースするステップを有する、請求項７に記載の方法。
- 分散データ処理システム内でのデータベース・アクセス効率を向上させるシステムであって、
前記分散データ処理システム内において、記憶された複数のレコードを持つ１つのデータベースを選択しプライマリ・データベースとして指定する手段と、
前記分散データ処理システム内の第２の物理的ロケーションにおいて前記プライマリ・データベースを複製する手段と、
前記分散データ処理システムが、それぞれが前記プライマリ・データベースと前記の複製されたレプリカ・データベース毎に維持される１つの整合性を記述する複数の整合性レベルであって、前記レプリカ・データベースのレコードへの照会を、前記プライマリ・データベースのアップデートに起因する前記照会されるレコードに対するアップデートがコミットされている場合にのみ許すレベルと、前記照会を、前記プライマリ・データベースのアップデートに起因する前記照会されるレコードに対するアップデートがコミットされたか否かに関わらず許すレベルを含む整合性レベルを提供する手段と、
前記レプリカ・データベースの各々に対する照会トランザクションのために、ユーザに前記整合性レベルから前記各レプリカ・データベース毎に整合性レベルを選択させる手段と、
前記プライマリ・データベース内のレコードに対するアップデートに応答して、前記レプリカ・データベース内の対応するレコードに対して、該レプリカ・データベースに選択された前記整合性レベルに応じた手順にしたがってアップデートする手段とを含み、
該アップデートする手段が、
前記プライマリ・データベース内の１つの選択されたレコードに対するアップデートに応答して、前記の複製されたデータベース内の対応する選択されたレコードへのアクセスを自動的にロックする手段と、
前記の複製されたデータベース内の前記の選択されたレコードをアップデートする手段と、
前記アップデートの後で、前記の選択されたレコードへのアクセスをリリースする手段と、
前記分散データ処理システム内のユーザに、前記プライマリ・データベースおよび前記の複製されたデータベースの中のレコードを照会させる手段と、
を含み、前記選択された整合性レベルを維持させ、データの絶対的な整合性を維持するとともにデータアクセスの使用可能性を向上させる、システム。 - 前記プライマリ・データベースを、いかなる時点でも、コミット・オペレーションを行う前の整合性時点に戻す手段をさらに有する、請求項９に記載のシステム。
- 前記アップデートの後で前記の選択されたレコードへのアクセスをリリースする前記手段が、前記アップデートに続くコミット・オペレーションの後でのみ前記の選択されたレコードへのアクセスをリリースする手段を有する、請求項１０に記載のシステム。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US08/228,319 US5796999A (en) | 1994-04-15 | 1994-04-15 | Method and system for selectable consistency level maintenance in a resilent database system |
| US228319 | 1994-04-15 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH07295871A JPH07295871A (ja) | 1995-11-10 |
| JP3600293B2 true JP3600293B2 (ja) | 2004-12-15 |
Family
ID=22856690
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP02314395A Expired - Fee Related JP3600293B2 (ja) | 1994-04-15 | 1995-02-10 | データベース・アクセス効率の向上方法及びシステム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US5796999A (ja) |
| JP (1) | JP3600293B2 (ja) |
Families Citing this family (60)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6412017B1 (en) * | 1996-07-01 | 2002-06-25 | Microsoft Corporation | Urgent replication facility |
| US5951697A (en) * | 1997-05-29 | 1999-09-14 | Advanced Micro Devices, Inc. | Testing the sharing of stored computer information |
| US6490610B1 (en) | 1997-05-30 | 2002-12-03 | Oracle Corporation | Automatic failover for clients accessing a resource through a server |
| US6199110B1 (en) * | 1997-05-30 | 2001-03-06 | Oracle Corporation | Planned session termination for clients accessing a resource through a server |
| US6012059A (en) * | 1997-08-21 | 2000-01-04 | Dataxel Corporation | Method and apparatus for replicated transaction consistency |
| US5924096A (en) * | 1997-10-15 | 1999-07-13 | Novell, Inc. | Distributed database using indexed into tags to tracks events according to type, update cache, create virtual update log on demand |
| US6173420B1 (en) | 1997-10-31 | 2001-01-09 | Oracle Corporation | Method and apparatus for fail safe configuration |
| EP0952510A4 (en) * | 1997-11-14 | 2006-05-31 | Mitsubishi Electric Corp | SCHEME AND METHOD FOR DATA UPDATE |
| US6023709A (en) * | 1997-12-15 | 2000-02-08 | International Business Machines Corporation | Automated file error classification and correction in a hierarchical storage management system |
| AU2331099A (en) * | 1998-01-22 | 1999-08-09 | Intelogis, Inc. | Method and apparatus for universal data exchange gateway |
| US6233585B1 (en) * | 1998-03-12 | 2001-05-15 | Crossworlds Software, Inc. | Isolation levels and compensating transactions in an information system |
| US6205449B1 (en) * | 1998-03-20 | 2001-03-20 | Lucent Technologies, Inc. | System and method for providing hot spare redundancy and recovery for a very large database management system |
| US7401114B1 (en) * | 1998-04-20 | 2008-07-15 | Sun Microsystems, Inc. | Method and apparatus for making a computational service highly available |
| JP3578385B2 (ja) * | 1998-10-22 | 2004-10-20 | インターナショナル・ビジネス・マシーンズ・コーポレーション | コンピュータ、及びレプリカ同一性保持方法 |
| US6347322B1 (en) * | 1998-11-09 | 2002-02-12 | Lucent Technologies Inc. | Transaction state data replication by transaction forwarding in replicated database systems |
| US6516327B1 (en) * | 1998-12-24 | 2003-02-04 | International Business Machines Corporation | System and method for synchronizing data in multiple databases |
| US6314453B1 (en) * | 1999-02-17 | 2001-11-06 | Hewlett-Packard Company | Method for sharing and executing inaccessible dynamic processes for replica consistency among a plurality of existing applications |
| US7756830B1 (en) | 1999-03-31 | 2010-07-13 | International Business Machines Corporation | Error detection protocol |
| US6587860B1 (en) * | 1999-03-31 | 2003-07-01 | International Business Machines Corporation | Apparatus and method for tracking access to data resources in a cluster environment |
| JP4158297B2 (ja) * | 1999-11-12 | 2008-10-01 | 株式会社日立製作所 | 分散システムにおける属性データの一致化方法および分散システム |
| US7310670B1 (en) | 2000-04-25 | 2007-12-18 | Thomson Licensing S.A. | Multi-channel power line exchange protocol |
| US6708188B1 (en) | 2000-09-19 | 2004-03-16 | Bocada, Inc. | Extensible method for obtaining an historical record of data backup activity (and errors) and converting same into a canonical format |
| US6640217B1 (en) | 2000-09-19 | 2003-10-28 | Bocada, Inc, | Method for extracting and storing records of data backup activity from a plurality of backup devices |
| WO2002025499A1 (en) * | 2000-09-19 | 2002-03-28 | Bocada, Inc. | Method for extracting and storing records of data backup activity from a plurality of backup devices |
| US6745210B1 (en) | 2000-09-19 | 2004-06-01 | Bocada, Inc. | Method for visualizing data backup activity from a plurality of backup devices |
| WO2002031696A1 (en) * | 2000-10-09 | 2002-04-18 | Maximum Availability Limited | Method and apparatus for data processing |
| US7013312B2 (en) * | 2001-06-21 | 2006-03-14 | International Business Machines Corporation | Web-based strategic client planning system for end-user creation of queries, reports and database updates |
| US9659292B1 (en) * | 2001-08-30 | 2017-05-23 | EMC IP Holding Company LLC | Storage-based replication of e-commerce transactions in real time |
| US7065541B2 (en) * | 2001-10-10 | 2006-06-20 | International Business Machines Corporation | Database migration |
| US6889333B2 (en) * | 2001-11-01 | 2005-05-03 | Microsoft Corporation | System and method for replicating data in a distributed system |
| JP2003167815A (ja) * | 2001-11-30 | 2003-06-13 | Hitachi Ltd | データアクセス制御方法 |
| US7127475B2 (en) * | 2002-08-15 | 2006-10-24 | Sap Aktiengesellschaft | Managing data integrity |
| AU2003255438A1 (en) | 2002-08-15 | 2004-03-11 | Sap Aktiengesellschaft | Managing data integrity |
| US20050108274A1 (en) * | 2003-02-26 | 2005-05-19 | Daniel Selman | System and method for web server synchronization |
| US7243088B2 (en) * | 2003-08-06 | 2007-07-10 | Oracle International Corporation | Database management system with efficient version control |
| US7269588B1 (en) | 2003-09-24 | 2007-09-11 | Oracle International Corporation | Neighborhood locking technique for increasing concurrency among transactions |
| US7555481B1 (en) | 2003-10-28 | 2009-06-30 | Oracle Corporation | Method and apparatus for increasing transaction concurrency by early release of locks in groups |
| US7415470B2 (en) * | 2004-08-12 | 2008-08-19 | Oracle International Corporation | Capturing and re-creating the state of a queue when migrating a session |
| US7743333B2 (en) * | 2004-08-12 | 2010-06-22 | Oracle International Corporation | Suspending a result set and continuing from a suspended result set for scrollable cursors |
| US7587400B2 (en) * | 2004-08-12 | 2009-09-08 | Oracle International Corporation | Suspending a result set and continuing from a suspended result set for transparent session migration |
| US7502824B2 (en) * | 2004-08-12 | 2009-03-10 | Oracle International Corporation | Database shutdown with session migration |
| US7613710B2 (en) * | 2004-08-12 | 2009-11-03 | Oracle International Corporation | Suspending a result set and continuing from a suspended result set |
| DE102004047146A1 (de) * | 2004-09-29 | 2006-03-30 | Bayer Business Services Gmbh | Rechteverwaltung |
| US7739244B2 (en) * | 2004-10-14 | 2010-06-15 | Oracle International Corporation | Operating logging for online recovery in shared memory information systems |
| US9176772B2 (en) * | 2005-02-11 | 2015-11-03 | Oracle International Corporation | Suspending and resuming of sessions |
| US8176022B1 (en) * | 2006-08-26 | 2012-05-08 | Radames Garcia | Locking protocol using dynamic locks and dynamic shared memory |
| US8275907B2 (en) * | 2008-06-26 | 2012-09-25 | Microsoft Corporation | Adding individual database failover/switchover to an existing storage component with limited impact |
| US8364710B2 (en) * | 2008-07-10 | 2013-01-29 | Juniper Networks, Inc. | Model-based resource allocation |
| EP2330511B1 (en) * | 2008-09-17 | 2016-07-20 | Fujitsu Limited | Data update synchronization method and system by two-phase commit |
| EP2184688A1 (en) * | 2008-11-06 | 2010-05-12 | Amadeus s.a.s | Method of integrating in real time large volumes of updates in a database |
| US8589359B2 (en) * | 2009-10-12 | 2013-11-19 | Motorola Solutions, Inc. | Method and apparatus for automatically ensuring consistency among multiple spectrum databases |
| US20110178984A1 (en) * | 2010-01-18 | 2011-07-21 | Microsoft Corporation | Replication protocol for database systems |
| US8825601B2 (en) * | 2010-02-01 | 2014-09-02 | Microsoft Corporation | Logical data backup and rollback using incremental capture in a distributed database |
| US8589360B2 (en) * | 2011-12-12 | 2013-11-19 | Hewlett-Packard Development Company, L.P. | Verifying consistency levels |
| US9990372B2 (en) * | 2014-09-10 | 2018-06-05 | Panzura, Inc. | Managing the level of consistency for a file in a distributed filesystem |
| US10235407B1 (en) * | 2015-08-21 | 2019-03-19 | Amazon Technologies, Inc. | Distributed storage system journal forking |
| US10379961B2 (en) | 2017-04-11 | 2019-08-13 | International Business Machines Corporation | Ensuring metadata and index consistency using write intents |
| US10776344B2 (en) * | 2018-03-16 | 2020-09-15 | Microsoft Technology Licensing, Llc | Index management in a multi-process environment |
| US11301462B1 (en) * | 2020-03-31 | 2022-04-12 | Amazon Technologies, Inc. | Real-time data validation using lagging replica databases |
| CN112612422B (zh) * | 2020-12-29 | 2022-08-23 | 重庆邮电大学 | 移动边缘计算中副本的动态一致性维护方法 |
Family Cites Families (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4432057A (en) * | 1981-11-27 | 1984-02-14 | International Business Machines Corporation | Method for the dynamic replication of data under distributed system control to control utilization of resources in a multiprocessing, distributed data base system |
| US4769772A (en) * | 1985-02-28 | 1988-09-06 | Honeywell Bull, Inc. | Automated query optimization method using both global and parallel local optimizations for materialization access planning for distributed databases |
| US4714996A (en) * | 1985-11-26 | 1987-12-22 | International Business Machines Corporation | Impact calculation for version management in a distributed information service |
| GB2203573A (en) * | 1987-04-02 | 1988-10-19 | Ibm | Data processing network with upgrading of files |
| US4881166A (en) * | 1987-07-24 | 1989-11-14 | Amoco Corporation | Method for consistent multidatabase transaction processing |
| US5005122A (en) * | 1987-09-08 | 1991-04-02 | Digital Equipment Corporation | Arrangement with cooperating management server node and network service node |
| US5008853A (en) * | 1987-12-02 | 1991-04-16 | Xerox Corporation | Representation of collaborative multi-user activities relative to shared structured data objects in a networked workstation environment |
| US4853843A (en) * | 1987-12-18 | 1989-08-01 | Tektronix, Inc. | System for merging virtual partitions of a distributed database |
| US5155847A (en) * | 1988-08-03 | 1992-10-13 | Minicom Data Corporation | Method and apparatus for updating software at remote locations |
| US5222217A (en) * | 1989-01-18 | 1993-06-22 | International Business Machines Corporation | System and method for implementing operating system message queues with recoverable shared virtual storage |
| US5170480A (en) * | 1989-09-25 | 1992-12-08 | International Business Machines Corporation | Concurrently applying redo records to backup database in a log sequence using single queue server per queue at a time |
| US5261069A (en) * | 1990-08-13 | 1993-11-09 | Hewlett-Packard Company | Method of maintaining consistency of cached data in a database system |
| JPH0498434A (ja) * | 1990-08-13 | 1992-03-31 | Nec Corp | 分散型ファイル管理方式 |
| JPH04107654A (ja) * | 1990-08-28 | 1992-04-09 | Nec Corp | 分散データ制御方式 |
| JP3516344B2 (ja) * | 1990-10-22 | 2004-04-05 | 株式会社日立製作所 | 分散処理システムの多重データ処理方法 |
| US5440727A (en) * | 1991-12-18 | 1995-08-08 | International Business Machines Corporation | Asynchronous replica management in shared nothing architectures |
| US5423037A (en) * | 1992-03-17 | 1995-06-06 | Teleserve Transaction Technology As | Continuously available database server having multiple groups of nodes, each group maintaining a database copy with fragments stored on multiple nodes |
-
1994
- 1994-04-15 US US08/228,319 patent/US5796999A/en not_active Expired - Lifetime
-
1995
- 1995-02-10 JP JP02314395A patent/JP3600293B2/ja not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| US5796999A (en) | 1998-08-18 |
| JPH07295871A (ja) | 1995-11-10 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP3600293B2 (ja) | データベース・アクセス効率の向上方法及びシステム | |
| Goel et al. | Data replication strategies in wide-area distributed systems | |
| JP2948496B2 (ja) | データ処理システム内で複写データ一貫性を維持するためのシステムおよび方法 | |
| US7487228B1 (en) | Metadata structures and related locking techniques to improve performance and scalability in a cluster file system | |
| US6081826A (en) | System using environment manager with resource table in each computer for managing distributed computing resources managed for each application | |
| US7191357B2 (en) | Hybrid quorum/primary-backup fault-tolerance model | |
| US7937377B2 (en) | Dynamic cluster database architecture | |
| US5781910A (en) | Preforming concurrent transactions in a replicated database environment | |
| US9652346B2 (en) | Data consistency control method and software for a distributed replicated database system | |
| US11442961B2 (en) | Active transaction list synchronization method and apparatus | |
| US6247103B1 (en) | Host storage management control of outboard data movement using push-pull operations | |
| Lahiri et al. | Cache fusion: Extending shared-disk clusters with shared caches | |
| US7389313B1 (en) | System and method for creating a snapshot copy of a database | |
| US6393537B1 (en) | Host storage management control of outboard data movement | |
| US7702757B2 (en) | Method, apparatus and program storage device for providing control to a networked storage architecture | |
| JP4746838B2 (ja) | データベースへのアクセスを制御するための異なったデータベースサーバ間のデータベースのオーナーシップのパーティション化 | |
| JPH06318164A (ja) | 分布トランザクションを実行する方法および装置 | |
| US20080288498A1 (en) | Network-attached storage devices | |
| US7281014B2 (en) | Method and apparatus for moving data between storage devices | |
| Cecchet | C-JDBC: a Middleware Framework for Database Clustering. | |
| Casanova¹ et al. | Optimization of relational schemas containing inclusion dependencies | |
| CA2618938C (en) | Data consistency control method and software for a distributed replicated database system | |
| KR20050026306A (ko) | 비공유 구조의 데이터베이스 클러스터 서버 시스템과온라인 확장 방법 | |
| Wedde et al. | Transparent distributed object management under completely decentralized control | |
| Kaur | Transaction processing in distributed databases |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A601 | Written request for extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A601 Effective date: 20031222 |
|
| A602 | Written permission of extension of time |
Free format text: JAPANESE INTERMEDIATE CODE: A602 Effective date: 20040109 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040322 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040816 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20040914 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040916 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080924 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |