JP2006514374A - 障害からデータ・リポジトリを回復するための方法、データ処理システム、回復コンポーネント、記録媒体およびコンピュータ・プログラム - Google Patents

Abstract

【課題】 データ・リポジトリに影響するストレージ障害から回復するための方法、データ処理システム、回復コンポーネント、およびコンピュータ・プログラムを提供することにある。
【解決手段】 その回復処理の少なくとも一部は、データ・リポジトリが新しいデータを受信でき、新しいデータの取出しを許可できる間に実行される。新しいデータ項目は回復処理中にリポジトリ内で受信され、そこから取り出すことができるが、障害前に実行され、その後、回復処理によってリポジトリに復元される、データ・リポジトリに対する更新は、回復作業単位内で復元され、回復作業単位の正常終了まで、回復プロセス以外のプロセスにとってアクセス不能なものになる。この回復処理は、回復されたリポジトリが障害の時点のリポジトリの状態と整合性のあるものであるが、回復処理の完了前に新しいデータ項目の追加および取出しに使用可能であることを保証する。

Description

本発明は、データ処理システム内の障害からの回復に関し、特に、コンピュータ・プログラムおよびデータ処理システム内で実現された回復コンポーネントおよび方法に関する。

非常に信頼性の高いデータ処理システムでも、結果的に１次ストレージ内のデータの紛失または破壊をもたらす、ディスク障害および誤動作またはソフトウェア誤動作などのストレージ障害の影響を受けやすい可能性がある。結果的にデータの永続的紛失をもたらすこのような障害を回避するために、保管データのバックアップ・コピーの作成と、最新バックアップ以降の保管データに対する更新を記述するログ・レコードの作成を含む、回復機能を提供することが知られている。

ＩＢＭ社のＭＱＳｅｒｉｅｓ（商標）およびＷｅｂＳｐｈｅｒｅ（商標）ＭＱファミリのメッセージング・プログラム（messaging product）を含む、いくつかの通信マネージャ・ソフトウェア（software product）は、センダ（sender）とレシーバ（receiver）との間のメッセージの転送中にメッセージ・キューまたはデータベース・テーブルなどのデータ・リポジトリにメッセージを保管するための機能を提供する。他のデータ処理システムおよびコンピュータ・プログラムの場合のように、重大メッセージの紛失を回避し、アプリケーション・プログラム・タスクが正常に完了できることを保証するために、潜在的なシステムまたはプログラム障害から回復するための解決策が必要である。

キュー・マネージャ・プログラムがキュー間のメッセージの転送を処理するメッセージ・キューイング・システムでは、そのメッセージを保持するために使用される１次ストレージが障害を起こしたときに、キュー・マネージャ・プログラム内の回復機能がキューおよびそのメッセージ内容を回復することが知られている。この回復機能は、キューの最終状態がストレージ障害の時点と同じになるように、キューにメッセージを復元する。これらの回復機能は、キューのバックアップ・コピーからメッセージ・キューとその内容のスナップショットを再作成し、次に、キュー・マネージャのログ・レコードを参照してそのキューに対する変更を再適用する。このような既知の解決策では、キュー・マネージャは、任意のメッセージがキューから取り出される前に、しかも任意の新しいメッセージがキューに追加される前に、回復処理を完了しなければならない。これにより、回復後のキューの状態が障害の時点のキューの状態と同じになることと、障害の結果としてメッセージの順序付けが失われないことが保証される。

しかし、このような解決策について残っている問題は、回復処理が進行中である間、メッセージング機能とメッセージ・リポジトリが使用不能になることである。多くのアプリケーションでは、最適メッセージ可用性を必要とするが、メッセージング・システムが保証された１回のみのメッセージ送達を提供するという競合する諸要件がある。あるアプリケーションが回復処理中にキューにアクセスすることが許可されている場合、そのアプリケーションによって単一メッセージが２回処理される可能性があるという危険性がある。単一資金転送命令に応答して自分の口座から資金が引き落とされた銀行の顧客は、非常に不満になるであろう。

２００２年４月２３日にＣａｒｌｓｏｎに対して公布された米国特許第６３７７９５９号（特許文献１）には、２つの重複データベースのいずれか一方の障害および回復中に着信トランザクションを処理し続けるトランザクション処理システムが記載されている。２つの重複データベースの一方には「アクティブ」状況が割り当てられ、もう一方は「冗長」状況で維持される。すべての着信照会はアクティブ・データベースのみに送信され、すべての着信更新はアクティブ・データベースと冗長データベースの両方に送信される。一方のデータベースが障害を起こすと、もう一方はアクティブ状況が割り当てられ（すでにアクティブになっていない場合）、障害を起こしたデータベースの修復および再始動中に着信照会および更新を処理し続ける。障害を起こしたデータベースの修復および再始動は、アクティブ・データベースの単一パススルーの際にインターリーブされたコピーおよび更新操作の使用を伴う。着信更新およびコピー操作のインターリービングはキューしきい値処理方法により実行されるが、この方法は着信トランザクション更新の数に応答してコピー操作を制御する。トランザクション処理システムは、障害活動および回復活動のいずれでも相変わらず動作可能である。完全レプリカが維持されているので、ログ・レコードはデータベースの一方が障害を起こしたときにのみ作成され、そのデータベースが修復中である間、障害を起こしたデータベースへのアクセスは不要である。連続可用性は大いに望ましいものであるが、この解決策は、２つのデータベース・システムのそれぞれの動作状況（アクティブまたは冗長）の交換可能性を備えた２つの完全なデータベース・レプリカを維持するという相当な処理および記憶のオーバヘッドを有する。さらに、複製は一般にソフトウェア破壊に対する保護を行わず、したがって、情況によっては複製に加えて回復操作が必要になる。

米国特許出願公報第２００２／００４９７７６号（Ａｒｏｎｏｆｆ他のために２００２年４月２５日に公開、特許文献２）も、高可用性のために複製されたデータベースに関する。この文書には、ターゲット・データベースの回復後に複製を再開し、回復中にすでにターゲット・データベースに適用された失効トランザクションをパージすることにより、障害後にソース・データベースとターゲット・データベースを再同期するための方法が記載されている。

代替手法は、２００２年３月５日にＷｏｎｇ他に対して公布された米国特許第６３５３８３４号（特許文献３）に記載されており、同特許では、メッセージ・キューイング・システムは、単一ディスク上の単一ファイル内にまとめてクラスタ化された、メッセージとそのメッセージに関する状態情報を保管する。このシステムは、３つの異なるディスク（データ・ディスク、索引構造ディスク、およびログ・ディスク）への更新の書込みを回避することにより、効率の良いデータの書込みを達成することが意図されている。制御情報、メッセージ・ブロック、およびログ・レコードを入力するために、キュー項目マップ・テーブルが使用される。米国特許第６３５３８３４号（特許文献３）は既存のＲＡＩＤ技術およびデータの重複書込みの使用に言及しており、それがない場合、記載されたシステムは、結果的に単一ディスク上に保持されたデータの紛失をもたらすストレージ障害に対する保護をまったく行わない。
米国特許第６３７７９５９号 米国特許出願公報第２００２／００４９７７６号 米国特許第６３５３８３４号 国際特許出願公報第ＷＯ９５／１０８０５号 米国特許第５４６５３２８号 米国特許出願第０９／６０５５８９号 米国特許出願第０９／９１２２７９号 米国特許出願第１０／２２８６１５号 米国特許出願第１０／２２８６３６号 米国特許出願第１０／２５６０９３号 米国特許出願第０９／６７７３３９号 米国特許出願第０９／６７７３４１号 １９９４年にＭｃＧｒａｗ−Ｈｉｌｌから発行されたＢ．Ｂｌａｋｅｌｅｙ、Ｈ．Ｈａｒｒｉｓ、およびＲ．Ｌｅｗｉｓによる「Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｑｕｅｕｉｎｇ Ｕｓｉｎｇ ｔｈｅ ＭＱＩ」 「Ａｎ Ｉｎｔｒｏｄｕｃｔｉｏｎ ｔｏ Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｑｕｅｕｉｎｇ」（ＩＢＭ社の文書番号ＧＣ３３−０８０５−００） 「ＭＱＳｅｒｉｅｓ − Ｍｅｓｓａｇｅ Ｑｕｅｕｅ Ｉｎｔｅｒｆａｃｅ Ｔｅｃｈｎｉｃａｌ Ｒｅｆｅｒｅｎｃｅ」（ＩＢＭ社の文書番号ＳＣ３３−０８５０−０１）

本発明の諸態様は、データ・リポジトリに影響する障害から回復するための方法、データ処理システム、回復コンポーネント、およびコンピュータ・プログラムを提供し、その回復処理の少なくとも一部は、データ・リポジトリが新しいデータを受信でき、このような新しいデータの取出しを許可できる間に実行される。この障害は、結果的に１次ストレージ・メディア上のデータ・リポジトリ内のデータの紛失または破壊をもたらす、ハードウェア障害あるいは誤動作またはソフトウェア誤動作である可能性がある。

新しいデータ項目（すなわち、障害後に受信したもの）は回復処理中にリポジトリ内に受信し、そこから取り出すことができるが、障害前に実行され、その後、回復処理によってリポジトリに復元される、データ・リポジトリに対する更新は、回復処理の完了までアクセス不能なものになる。この回復処理は、回復されたリポジトリが障害の時点のリポジトリの状態と整合性のあるものであることも保証しながら、データ・リポジトリの高速可用性を達成することができる。

第１の態様では、本発明は、データ・リポジトリの１次コピーに影響する障害からデータ・リポジトリを回復するための方法であって、データ・リポジトリの１次コピーとそれに保持されたデータ項目を再作成するために十分なデータの２次コピーを維持するステップと、データ・リポジトリの１次コピーに影響する障害に応答して、２次データ・コピーからデータ・リポジトリの１次コピーを再作成するステップと、復元プロセスを使用して回復作業単位内で２次コピーから１次コピーにデータ項目を復元するステップであって、回復作業単位のコミットまで、回復作業単位内でデータ・リポジトリの１次コピーに復元されたデータ項目が復元プロセス以外のプロセスにとってアクセス不能である、復元するステップと、回復作業単位のコミット前に、前記復元ステップから独立してデータ・リポジトリへのデータ項目の追加を可能にし、復元プロセス以外のプロセスが前記独立して追加されたデータ項目にアクセスすることを可能にするように、データ・リポジトリの１次コピーを構成するステップと、復元ステップの正常終了に応答して、復元データの前記アクセス不能性を解除することを含む、回復作業単位をコミットするステップとを含む方法を提供する。

本発明の好ましい一実施形態によれば、メッセージング・システムの通常転送処理中のメッセージ・リポジトリに対する更新は、リポジトリにメッセージを追加するメッセージ送信操作と、メッセージを削除するメッセージ取出し操作とを含む。これに関連する「メッセージ・リポジトリ」は、メッセージ・キュー、データベース・テーブル、またはメッセージあるいはメッセージ・キューを保持する任意のその他のデータ構造にすることができる。メッセージ・リポジトリに影響する障害後に、メッセージ・リポジトリが空状態で再作成され、次に、好ましくはリポジトリのバックアップ・コピーおよびログ・レコードを参照することにより、送信および取出し操作がリポジトリに再適用される。メッセージ・リポジトリは予備回復ステップとして再作成され、メッセージング機能は回復の完了前にメッセージ・リポジトリとの間で新しいメッセージを転送することができる。バックアップ・ストレージおよびログ・レコードからの再適用操作を伴うメッセージ・リポジトリに対する更新は、回復作業単位のコミットされていない操作として処理され、回復作業単位の完了時にのみコミットされる（すなわち、整合性検査が実行され、更新が最終的なものになり、他のプログラムにとってアクセス可能なものになる）。回復作業単位は、メッセージ・リポジトリの内容を障害の時点のリポジトリの状態と整合性のある状態に復元するために（メッセージ・リポジトリの再作成後に）必要な１組の操作を含む。メッセージ・リポジトリは、それが再作成され次第、新しいメッセージの受信に使用可能になり、回復作業単位内でキューに復元される任意のメッセージは、回復作業単位の完了までターゲット・アプリケーション・プログラムによってリポジトリから取り出すことができない。

本発明は、データ項目がデータ・リポジトリに追加されたのと同じ順序でデータ項目を処理することが不可欠ではないアプリケーションに有用である。第１のアプリケーション例では、各データ項目またはメッセージは、特定のタスクの実行に関する要求である。タスクを実行する順序が重大ではない場合、前の要求がすべて回復されるのを待たずに、新しい要求をリポジトリ上に受信し、処理することができる。

本発明の一実施形態は、センダとレシーバとの間でメッセージを転送するためのデータ通信システムであって、メッセージがメッセージ送信操作後にメッセージ・リポジトリ内に保持され、その後、レシーバに送達するためにリポジトリから取り出される、データ通信システムを提供する。リポジトリのバックアップ・コピーは、作成され、定期的にまたは事前定義イベントに応答して更新され、ログ・レコードは、最新バックアップ操作以降に発生したイベントを含め、メッセージのトランザクション状態に対する更新を含むメッセージ送信およびメッセージ取出しイベントを記録するために作成される。このシステムは、メッセージ・リポジトリの１次コピーに影響するストレージ障害に応答して、データ・リポジトリの１次コピーを再作成する操作ステップと、リポジトリのバックアップ・コピーおよびログ・レコードを参照することにより１次コピーにデータ項目を復元する操作ステップとを実行するようにデータ通信システムを制御するように適合された回復コンポーネントを含む。バックアップ・コピーおよびログ・レコードは、障害前に通常転送処理中に作成されている。このシステムは、回復処理の完了を待たずに、新しいメッセージをリポジトリに追加し、そこから取り出すことを可能にするように構成される。バックアップ・コピーまたはログ・レコードを参照することによりリポジトリに復元されたメッセージおよびリポジトリに適用された更新は、障害前に実行された送信および取出し操作に対応するすべてのメッセージ・リポジトリ更新がメッセージ・リポジトリに再適用されるまで、リトリーバ（retriever）にとってアクセス不能なものになる。これに関連する「新しいメッセージ」は、障害後に初めてリポジトリに追加されるメッセージである。障害前にキューに追加され、その後、障害後にキューに復元されたメッセージは、以下では「古いメッセージ」と呼ばれる。

多くの既知の通信解決策に関するもう１つの問題は、回復処理が実行されている間にデータがリポジトリに蓄積し、おそらく結果的にリポジトリ（またはリポジトリ内の構造）が「満杯」条件に到達する傾向である。その結果として、これを防止するために重大な追加処理が行われない限り、何らかのデータ通信がセンダに返されるかまたは中間ネットワーク・ロケーションに蓄積することになる可能性がある。上述の解決策による可用性の改善はこの問題に対処するために役に立つが、さらに追加の改善を達成することができる。

本発明の他の諸実施形態は、データ・リポジトリに影響するストレージ障害からの回復の方法を実行するための方法、データ処理システム、コンピュータ・プログラムおよび回復コンポーネントであって、通常転送処理においてリポジトリに適用されたデータ更新がトランザクション作業単位内で適用されるシステムで使用するための方法、データ処理システム、コンピュータ・プログラムおよび回復コンポーネントを提供する。データ・リポジトリの１次コピーに影響するストレージ障害後に、データ・リポジトリの１次コピーにデータ項目を復元するために必要な操作は、２次ストレージに関して識別されるが、各識別済み操作に関する対応する元の作業単位の障害の時点での状態について決定が行われるまで据え置かれる。次に復元操作は、元の作業単位の決定された状態に応じて適宜、実行または廃棄される。

さらに、メッセージ・リポジトリに対する１対の更新がメッセージの追加および同じメッセージの取出しに対応し、その１対の更新が障害前に完了している場合、リポジトリを不整合状態で放置するというリスクなしに、その１対の操作を回復処理内でまとめて実行することができる。本発明の好ましい一実施形態では、このような「追加／取出し」操作対は、ログ・レコードが適用されるときに識別される。これらの操作対は復元処理から省略される（すなわち、キューに対するそれらの影響は相互に打ち消し合うので、１対として実行されたものと見なされる）か、または回復作業単位の範囲外で実行されコミットされる。これらのオプションのそれぞれは、不必要な処理を回避し、潜在的なメッセージの蓄積を低減する。

本発明の好ましい諸実施形態は、キューのバックアップ・コピーおよびログ・レコードから共用キューへの古いメッセージ（キュー障害前からのメッセージ）の回復を含む、共用キュー・メッセージング・システム内の１次ストレージ障害からの回復を可能にする。共用キューは、古いメッセージ・リポジトリ更新がログ・レコードから復元されている間に新しいメッセージ（障害後にキューに送信されたメッセージ）を処理する１つまたは複数のアプリケーション・プログラムによって使用中である可能性がある。このメッセージ回復は、復元処理全体を単一作業単位として処理することにより、保証された１回のみのメッセージ送達も提供しながら、実行することができる。

キューへのメッセージの復元中にメッセージをキューに追加し、キューから取り出すことを可能にすることにより、本発明は、ストレージ障害後にメッセージング機能の可用性の改善を達成することができる。

本発明の他の一態様は、データ・リポジトリの１次コピーを保管するためのデータ・ストレージと、データ・リポジトリを表すデータの２次コピーを保管するための２次データ・ストレージであって、その２次データがデータ・リポジトリの１次コピーとそれに保持されたデータを回復するために十分である２次データ・ストレージと、データ・リポジトリの１次コピーに影響するストレージ障害から回復するようにデータ通信システムの動作を制御するための回復コンポーネントであって、回復コンポーネントが、２次データ・コピーからデータ・リポジトリの１次コピーを再作成するステップと、復元プロセスを使用して１次コピーにデータ項目を復元するステップであって、復元ステップが回復作業単位内で実行され、回復作業単位のコミットまで、回復作業単位内でデータ・リポジトリの１次コピーに復元されたデータ項目が復元プロセス以外のプロセスにとってアクセス不能なものになるステップと、回復作業単位のコミット前に、前記復元ステップから独立してデータ項目の追加を可能にし、回復コンポーネント以外のコンポーネントが前記独立して追加されたデータ項目にアクセスすることを可能にするように、データ・リポジトリの１次コピーを構成するステップと、復元ステップの正常終了に応答して、復元データの前記アクセス不能性を解除することを含む回復作業単位をコミットするステップとを実行するようにデータ通信システムを制御するように動作可能である回復コンポーネントとを含む、データ通信システムを提供する。

上述の方法および回復コンポーネントは、そこでプログラム・コードが実行されるデータ処理装置の実行を制御するためのコンピュータ・プログラム内で実現することができる。このプログラム・コードは、記録媒体上に記録されたプログラム・コードとして市販可能なものにするか、またはインターネットなどのネットワークを介してダウンロード可能なものにすることができる。

一例として、添付図面に関して、本発明の諸実施形態について以下に詳細に説明する。

センダ・プログラムがメッセージを送信するステップと、リトリーバ・プログラムがメッセージを取り出すステップとの間でメッセージがメッセージ・リポジトリにキューイングされる非同期メッセージ通信システムに関して、本発明の第１の実施形態について以下に説明する。キューを再作成し、キュー上にメッセージを回復するために回復機能が使用可能でないかぎり、１次ストレージの障害は、メッセージ・データの紛失または破壊を引き起こす可能性がある。その他のデータ・リポジトリに適用可能であるが、本発明はメッセージ・キューに特に適用可能である。というのは、メッセージ・キューは概して、メッセージが追加され、その内容が更新され、その後、最終的に削除されるのではなく、追加され、その後、削除される別個の独立項目（メッセージ）を収容するからである。

当業者にとって明らかになるように、本発明の特定の諸実施形態は、障害の結果、データベース・テーブル内のデータの紛失または破壊をもたらし、したがって、データベース・テーブルの再作成およびそのテーブルへのデータ項目の復元を必要とする可能性がある、データベース環境で等しく適用可能である。また、本発明の諸実施形態は、ハードウェアまたはソフトウェア障害が、たとえば、バックアップ・ストレージおよびログ・レコードからのデータ・リポジトリの回復を必要とし、回復処理が実行されている間にデータ・リポジトリの可用性の喪失を最小限にする必要がある、その他のデータ処理環境でも適用可能である。

１次ストレージ・メディア上のデータの紛失または破壊は、ハードウェア障害あるいは誤動作、ソフトウェア誤動作、または人間のエラー（キューおよびそのすべてのメッセージの偶発的な削除など）によって発生する可能性がある。参照しやすくするため、データ・リポジトリに影響するこれらの種々のタイプの障害のすべては以後、「ストレージ障害」と呼ぶことにする。紛失または破壊が単一キューまたはデータベース・テーブルまたはファイルのみに影響する場合もあれば、障害が単一結合機能リスト構造内に保持された複数のキューなどの２つ以上のキュー（またはテーブルなど）に影響する場合もある（以下のＣＦリスト構造の説明を参照されたい）。典型的なケースでは、ＣＦリスト構造に影響する障害は、単一キューではなく、ＣＦリスト構造上のすべてのキューに影響することになる。

メッセージング環境
ＩＢＭ社のＭＱＳｅｒｉｅｓ（商標）およびＷｅｂＳｐｈｅｒｅ（商標）ＭＱファミリのメッセージング・プログラムは、分散異機種環境内の種々のシステム上で実行可能な複数アプリケーション・プログラム間の相互協調処理をサポートするためにメッセージ・キューイングを使用する既知のプログラムの例である。

メッセージ・キューイングおよび市販のメッセージ・キューイング・プログラムについては、１９９４年にＭｃＧｒａｗ−Ｈｉｌｌから発行されたＢ．Ｂｌａｋｅｌｅｙ、Ｈ．Ｈａｒｒｉｓ、およびＲ．Ｌｅｗｉｓによる「Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｑｕｅｕｉｎｇ Ｕｓｉｎｇ ｔｈｅ ＭＱＩ」（非特許文献１）ならびに「Ａｎ Ｉｎｔｒｏｄｕｃｔｉｏｎ ｔｏ Ｍｅｓｓａｇｉｎｇ ａｎｄ Ｑｕｅｕｉｎｇ」（ＩＢＭ社の文書番号ＧＣ３３−０８０５−００、非特許文献２）および「ＭＱＳｅｒｉｅｓ − Ｍｅｓｓａｇｅ Ｑｕｅｕｅ Ｉｎｔｅｒｆａｃｅ Ｔｅｃｈｎｉｃａｌ Ｒｅｆｅｒｅｎｃｅ」（ＩＢＭ社の文書番号ＳＣ３３−０８５０−０１、非特許文献３）というＩＢＭ社から入手可能な資料に記載されている。それを介して複数コンピュータがメッセージ・キューイングを使用して通信するネットワークは、インターネット、イントラネット、または任意のコンピュータ・ネットワークにすることができる。ＭＱＳｅｒｉｅｓおよびＷｅｂＳｐｈｅｒｅはＩＢＭ社の商標である。

トランザクション処理システムにおいて周知の通り、「作業単位」は、データ保全性が失われないことを保証するために、まとめて正常に実行しなければならない１組の処理操作であるか、またはその１組の操作全体を完了できない場合にすべてがバックアウトされる１組の処理操作である。１つの作業単位内のすべての操作は、その作業単位全体の解決によってすべての更新をコミットする（すべてをファイナライズし、アクセス可能なものにする）ことができるまで、更新を当てにする可能性のある他のプロセスからアクセス不能状態に保持される。

ＩＢＭ社のＭＱＳｅｒｉｅｓおよびＷｅｂｓｈｅｒｅ ＭＱメッセージング・プログラムは、システムまたは通信障害の場合にも保証された１回のみのメッセージ送達を行うメッセージング・プロトコルにより作業論理単位内でメッセージを同期化して、トランザクション・メッセージング・サポートを提供する。この保証された送達は、メッセージがレシーバ・システムによって安全に保管されたものとして確認されるまで最終的にセンダ・システム上のストレージからメッセージを削除しないことにより、そして精巧な回復機能の使用により、達成される。正常な保管を確認次第、メッセージの転送のコミットメント前に、センダ・システムのストレージからのメッセージの削除と、レシーバ・システムのストレージへの挿入の両方には、コミットされていない（「未完了（in-flight）」または「未確定（in-doubt）」操作としてのフラグが立てられ、障害の場合にアトミックにバックアウトすることができる。このメッセージ伝送プロトコルと、関連のトランザクション概念および回復機能については、国際特許出願公報第ＷＯ９５／１０８０５号（特許文献４）および米国特許第５４６５３２８号（特許文献５）に記載されている。

ＩＢＭ社のＭＱＳｅｒｉｅｓおよびＷｅｂｓｈｅｒｅ ＭＱプログラムのプログラム間通信機能は各アプリケーション・プログラムが任意の他のターゲット・アプリケーション・プログラムの入力キューにメッセージを送信することを可能にし、各ターゲット・アプリケーションは処理のためにその入力キューからこれらのメッセージを非同期に取ることができる。これは、アプリケーション・プログラム間の専用論理エンドツーエンド・コネクションを必要とせずに、分散異機種コンピュータ・ネットワーク間に分散可能なアプリケーション・プログラム間でメッセージの送達を達成する。

ＯＳ／３９０キュー・マネージャ・ソフトウェア用のＩＢＭ社のＭＱＳｅｒｉｅｓの最新バージョンは、共用キュー用の１次ストレージとしてＯＳ／３９０結合機能（ＣＦ）リスト構造を使用して、共用キューのためのサポートを提供する。共用キュー上のメッセージは、ＣＦリスト構造内のリスト項目として保管される。並列シスプレックス内のどこかで同じキュー共用グループ内の複数キュー・マネージャ上で実行される複数アプリケーションはこれらの共用キュー・メッセージにアクセスすることができ、メッセージは割り振られた基本キー（primary key）の順序でアクセスされる。結合機能の観点から見ると、基本キーの割振りはキュー・マネージャによって任意に決定され、各メッセージに関連付けられる。全体的な順序が取出しのために正しい順序になるように、キュー・マネージャは各メッセージごとにキーを設定する（以下に記載する通り、例外を除いてＦＩＦＯ順序付けを適用する）。

メッセージは次に使用可能なアプリケーションによって取り出されるので、特定のキューへのこのような共用アクセスは、冗長性（そのグループ内の１つまたは複数のキュー・マネージャに影響する障害に対する耐性）による高可用性および自動ワークロード・バランシングというメリットを有する。これは、高いメッセージ・スループットに適した高スケーラブル・アーキテクチャをもたらす。

この実施形態は上述のシステム・アーキテクチャに適用可能であり、この環境で実行される多くのアプリケーションは高可用性を必要とするので実際に有益であるが、代替ストレージ構造が使用される場合、本発明の諸実施形態も適用可能である。以後、メッセージ・リポジトリという用語は、ＣＦリスト構造、データベース・テーブル、またはその他の既知の構造のいずれで実現されるかにかかわらず、メッセージを保持することができるメッセージ・キューおよびその他のデータ構造を指すために使用する。

上記の通り、ＯＳ／３９０オペレーティング・システム環境内のメッセージ・キューイング・システムは、ＣＦリスト構造を介して複数キュー・マネージャのキュー共用グループにとって使用可能なものにすることができる共用キューに関するサポートを提供する。このようなシステム内での使用に適したいくつかの回復機能を含む、このようなシステムに適用可能なシステム・コンポーネント、データ構造、および方法については、以下に示す同時係属で本出願人に譲渡された特許出願の明細書に記載されており、その特許出願のそれぞれは参照により本明細書に組み込まれる。
●米国特許出願第０９／６０５５８９号（英国特許出願第０００９９８９．５号に対応、代理人参考文献ＧＢ９２０００００３１、特許文献６）
●米国特許出願第０９／９１２２７９号（代理人参考文献ＧＢ９２０００００３２、特許文献７）
●米国特許出願第１０／２２８６１５号（英国特許出願第０２０７９６９．７号に対応、代理人参考文献ＧＢ９２００１０１０１、特許文献８）
●米国特許出願第１０／２２８６３６号（英国特許出願第０２０７９６７．１号に対応、代理人参考文献ＧＢ９２００２０００１、特許文献９）
●米国特許出願第１０／２５６０９３号（英国特許出願第０２０８１４３．８号に対応、代理人参考文献ＧＢ９２００２００１５、特許文献１０）

以下に記載する本発明の実施形態は、上記でリストされ、本明細書に組み込まれる参考文献に記載された回復機能と互換性のあるものである。

リスト構造内でメッセージ・キューを実現し、リスト構造を処理するための方法および装置、ならびに独特のキーを使用して操作状態間を差異化するための解決策については、２０００年１０月２日に出願され、「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｐｒｏｃｅｓｓｉｎｇ ａ Ｌｉｓｔ Ｓｔｒｕｃｔｕｒｅ」という発明の名称の米国特許出願第０９／６７７３３９号（代理人参考文献ＰＯＵ９２０００００４３、特許文献１１）および２０００年１０月２日に出願され、「Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｉｍｐｌｅｍｅｎｔｉｎｇ ａ Ｓｈａｒｅｄ Ｍｅｓｓａｇｅ Ｑｕｅｕｅ Ｕｓｉｎｇ ａ Ｌｉｓｔ Ｓｔｒｕｃｔｕｒｅ」という発明の名称の米国特許出願第０９／６７７３４１号（代理人参考文献ＰＯＵ９２０００００４２、特許文献１２）という同時係属で本出願人に譲渡された特許出願の明細書に記載されており、その特許出願のそれぞれは参照により本明細書に組み込まれる。

図１は、複数コンピュータ８０の分散ネットワーク内のキュー・マネージャ・プログラム３０の制御下でメッセージがキュー２０間で転送されるメッセージング・ネットワーク１０を概略的に示している。センダ・アプリケーション・プログラム４０はそのローカル・キューにメッセージを書き込み、ターゲット・アプリケーション・プログラム５０はその入力キューからメッセージを取り出し、永続メッセージの紛失なしにネットワークを越えてターゲット・アプリケーション・プログラムの入力キューにメッセージを転送するという作業のすべては、キュー・マネージャ３０によって処理される。各キュー・マネージャは、そのローカル・キューのバックアップ・コピー６０を維持し、メッセージが追加あるいは削除されるかまたはその状態が変更されたときに必ず更新を反映するようにログ・レコード７０を作成する。

図２は、結合機能（ＣＦ）リスト構造１１０内に保持されたキュー１００に共用アクセス可能な複数キュー・マネージャ３０のグループを示している。ＣＦリスト構造は両方向に、すなわち、キュー共用グループへおよびキュー共用グループから、メッセージをキューイングするために使用する。共用キューの１次コピーに加えて、２次バックアップ・コピー６０がディスク１２０上に保持される。そのキューのバックアップ・コピーは、キュー定義情報と、バックアップの時点でそのキュー上に保持されているすべてのメッセージに関する情報とを有し、そのディスクに定期的に保管される。ログ・レコード７０は、ＣＦリスト構造内のキューに対する更新ごとにディスク１２０に書き込まれる。最後のバックアップ以降のすべての更新を反映するバックアップ・コピーとログ・レコードとの組合せは、メディア障害に応答してキューの１次コピーの再作成を可能にする。

ログ・レコードは、実行された操作（挿入、削除、または更新状態）の表示と関連メッセージ用の固有キーとを収容し、そのキーはメッセージがＣＦに追加される時点で生成される。挿入操作の場合（および、ある実現例では更新操作の場合）、ログ・レコードは、メッセージの完全な内容も収容する。削除操作用のログ・レコードは、データベース・レコードの内容を収容しない。ある実現例では、更新操作の場合、変更を追跡するために必要な情報のみがログ記録される。

可用性の改善を伴う回復
あるコンピュータ・システムおよびアプリケーションは、データ・リポジトリに対する「順不同（out-of-sequence）」更新を許容することができる。すなわち、システムは、リポジトリ内の更新の順序が更新が追加された順序を正確に反映していない場合でも、正しく機能する。これは、アプリケーション・プログラム間のメッセージ送達を処理するときに、キューとの間でメッセージを転送するためにメッセージ・キュー・マネージャを使用する、あるシステムおよびアプリケーションに当てはまる。

本発明の発明者は、障害後にキュー上のデータの回復の完了前に新しいメッセージをキューに追加し、キューから取り出すことを可能にすることにより、このようなシステムおよびアプリケーションが可用性の改善の恩恵を受ける可能性があることを認識していた。しかし、これを達成する前に、いくつかの問題を克服しなければならない。

アプリケーションがログ・レコードの再生によりキューに復元されている古いメッセージに並行して新たに作成されたキューにアクセスすることが可能になっている場合、同じメッセージがそのアプリケーションによって２回処理される可能性があるという危険性がある。たとえば、メッセージがキューに追加され、その追加操作がコミットされ、次にそのメッセージがキューから取り出される場合がある。ほとんどのケースでは、取出し操作がコミットされると、メッセージはキューから削除される。キュー・ストレージ障害が発生した場合、そのキューはバックアップ・ストレージから再作成することができ、続いてログ・レコードからのキューに対する更新を再適用することができる。ログ再生中に、メッセージはキューに復元され、追加操作のコミットが再生されるとリトリーバ・アプリケーションにとって使用可能なものになり、メッセージ取出し操作が再生されると消失する。しかし、アプリケーション・プログラムが回復中にキューにアクセスできる場合、アプリケーション・プログラムは、それが使用可能なものになり次第（すなわち、メッセージ取出しログ・レコードの再生前に）、メッセージを取り出すことができ、すでに以前に処理されたメッセージを処理することができる。

上記の一連のイベントおよびその他の例の結果、保証された１回のみのメッセージ送達から受諾不能な逸脱が発生する可能性がある。

この問題に対する解決策については以下に記載するが、これは、保証された１回のみのメッセージ送達から逸脱せずに、新しいメッセージを処理しているアプリケーションによって共用キューが使用中である間に共用キューにメッセージを回復することにより、１次ストレージ障害から回復することができる。これに関連する「新しいメッセージ」は、障害後に初めてキューに追加されるメッセージである。「古いメッセージ」は、障害前にキューに追加され、障害後にキューに復元されるメッセージである。

回復作業単位内の回復処理
この実施形態では、復元プロセスは回復作業単位として実行される。すなわち、キューにメッセージを復元するステップと、ログを再生することによりバックアップ・ストレージからキュー上のメッセージの状態を更新するステップからなるシーケンスは、新たに定義された作業単位の範囲内で実行されコミットされる。

たとえば、同期点外（out-of-syncpoint）メッセージ「Ｐｕｔ」操作（キューにメッセージを追加すること）または「Ｇｅｔ」操作（キューからメッセージを取り出すこと）を再生するアクションまたは同期点内（in-syncpoint）ＰｕｔまたはＧｅｔのコミットを再生するアクションは、その回復作業単位内で同期点内ＰｕｔおよびＧｅｔとして実行される。その回復作業単位は、キューにメッセージを復元し、これらのメッセージの状態を変更する操作を再生するプロセス全体をカバーする。

作業単位は、１組の操作によって影響されるデータがその１組の操作の実行終了時に整合状態で放置される場合にまとめて実行しなければならない（またはまったく実行してはならない）１組の操作である。同期点は、データが整合状態になっている処理内の識別可能な点であり、同期点は、この整合性の点を記録するための各作業単位の終了時に記録される。記録された同期点の参照により、データ整合性の点に戻るために、どのくらいの長さの時間の間、処理をロールバックするかに関する決定を行うことができる。単一トランザクションは、単一作業単位として処理されるいくつかのＰｕｔ＿Ｍｅｓｓａｇｅ操作およびＧｅｔ＿Ｍｅｓｓａｇｅ操作を含むことができる。そのトランザクションがコミットされると、キュー上にＰｕｔされたメッセージが取出し可能メッセージとしてキュー上に現れ、それに関してＧｅｔ操作が実行されたメッセージが最終的に削除されるように、作業単位内のすべてのＰｕｔおよびＧｅｔ操作がファイナライズされる。しかし、あるトランザクション・システムでは、トランザクションの最終解決を待たずに直ちに効力を生じるように特定のＰｕｔ＿Ｍｅｓｓａｇｅ操作およびＧｅｔ＿Ｍｅｓｓａｇｅ操作を行うことができ、これらは「同期点外」ＰｕｔおよびＧｅｔ操作と呼ばれる。

上記の通り、障害は単一キューに影響する場合もあれば、複数キュー（たとえば、特定のＣＦリスト構造内のすべてのキュー）に影響する場合もある。複数キューを回復しなければならない場合、回復プロセスの単一呼出しによって影響を受けたすべてのキューの回復を開始することが望ましい。処理効率の改善は、１組の影響を受けたキューを再作成し、次に１組の影響を受けたキュー全体に関するメッセージおよびメッセージ更新の復元を包含する単一回復作業単位を実行することによって達成することができる。

回復プロセスは、１つまたは複数のどのようなログが回復中の１つまたは複数のキューに対する変更に関する情報を収容していても、その１つまたは複数のログにアクセスでき、それを使用する。共用キュー環境では、各キュー・マネージャはそれ自体の物理的に分離したログを維持していることになりそうであり、各ログは１組のファイルを有することができる。回復プロセスは、すべてのログを並行して読み取り、単一統合ログを論理的に構築することができる。単一統合ログ（一般に、単一物理ファイルとして存在しないもの）は、回復中の１つまたは複数のキューに対する変更ならびに障害によって影響を受けていない他のキューに対する変更のすべてを収容する。復元プロセスは、現行回復処理に不要なキューに対する変更を無視する。

特定の一連の回復処理操作については、図３に関連して以下に詳細に説明する。参照しやすくするため、以下の回復処理の説明では、単一キューを回復する例について記載する。

この方法の第１のステップ２００は、ストレージ障害の識別である。多くのケースでは、データ・リポジトリを使用するソフトウェアは、ハードウェア（たとえば、アクセス不能である可能性があるもの）またはオペレーティング・システムあるいはＪａｖａ（登録商標）仮想マシン（アクセスが試行されるとエラー表示を返す可能性のあるもの）などのその他のランタイム環境によって、データが紛失または破壊されていることを認識させられることになる。好ましい実施形態では、データ・リポジトリを使用するソフトウェアは、ソフトウェアが問題を認識すると、２００で回復処理を自動的に開始する。特に、障害を起こした１つまたは複数のキューを使用するキュー・マネージャ・プログラムは、キュー・マネージャの１つのコンポーネントである回復プロセスを始動することにより、特定の１組のエラー条件に応答する。

代替諸実施形態では、障害に応答して適切なエラー通知を提示するように、すなわち、回復処理を手動で開始するために人間の介入を促すように、ソフトウェアを作成することができる。さらに、偶発的なまたは悪意のあるデータの削除のためにストレージ障害が発生した場合に回復を開始するためには一般にオペレータ・アクションが必要になる。

障害の識別に応答して開始されると、回復プロセスは、２次ストレージにアクセスし、２１０で障害を起こしたキュー（複数も可）に対応するキュー定義のバックアップ・コピーを取り出し、取り出した定義を使用して２１０で１次ストレージ内にそのキューの空のコピーを再作成する。

好ましい実施形態では、キュー（またはその他のデータ・リポジトリ）の定義は、キューの内容とは別にバックアップ２次ストレージ内に保持される。それは内容が復元される前の個別のステップとして空状態のキューの再作成を容易にするので、キューの内容のスナップショットのバックアップから独立ステップとしてキュー定義をバックアップすることは有益である。そのキューは、そのキュー定義から１次ストレージ内に再作成され次第、新しいメッセージを受信するために使用可能なものにすることができる。

従来の回復解決策では、リポジトリが再作成されたときから回復処理が完了するまで、新たに再作成されたデータ・リポジトリにロックがかけられ、ロックはメッセージの複製を防止するために必要であると考えられている。この実施形態ではこのようなロックは一切不要であり、したがって、データ・リポジトリ（すなわち、キューまたはデータベース・テーブルであるが、回復作業単位内の任意の更新ではない）は、そのデータ・リポジトリが再作成され次第、アプリケーションによる使用のために使用可能である。

キュー（空状態）を再作成すると、２３０でメッセージおよびメッセージ更新をキューに復元するために回復作業単位が始動される。その空状態のキューの再作成に必要なキュー定義に加えて、２次ストレージは、バックアップが取られた時点のキュー上のメッセージのスナップショットに対応するキューの内容のバックアップ・コピーを収容する。それらがコミットされていない回復作業単位の一部であることを示すために各メッセージにマークを付けるステップとともにコピー操作を使用して、２４０でバックアップ・コピー内のメッセージが関連キューの１次コピーに復元される。このマーク付けは、さもなければキューから復元メッセージを取り出すことができるアプリケーションにとってアクセス不能なものにする。

好ましい実施形態では、各メッセージに作業単位ＩＤと独特の基本キーとを割り振ることにより、メッセージのマーク付けが実現され、そのキーの１バイトの値はメッセージの状態を示す。次にキュー・マネージャは、基本キーのバイト値を解釈して、アプリケーション・プログラムによってメッセージを取り出すことができるかどうかを決定することができる。コミットされていない回復作業単位内の任意のメッセージ更新は、この段階でアプリケーションによってアクセスすることができない（回復作業単位のコミットでバイト値が変更されるまでアクセスできない）。これについては、「独特のキー」というタイトルの項で以下にさらに詳細に説明する。回復作業単位内で実行されたすべての操作の容易な削除を可能にするので、回復処理が打ち切られる場合（回復処理の途中でキュー・マネージャが障害を起こした場合など）に作業単位ＩＤは有用である。ＩＢＭ社のＭＱＳｅｒｉｅｓキュー・マネージャ・プログラムは、このような情況でキュー回復処理を引き継ぐことを可能にする対等回復機能を備えていることが分かっている。

復元処理が進行するにつれて、回復キュー・マネージャは、それに関する操作が回復作業単位内で実行されるすべてのメッセージのリストも生成する。このリストは後でコミット処理中に使用される。

次に、障害の結果として失われたキューに対するすべての更新に関する情報を提供するために、バックアップ・コピーの時点からストレージ障害の時点まで間に作成されたログ・レコードが２５０で再生される。各ログ・レコードは、メッセージ追加操作（Ｐｕｔ＿Ｍｅｓｓａｇｅ操作など）、メッセージ削除操作（破壊的なＧｅｔ＿Ｍｅｓｓａｇｅ操作など）、または状況更新（コミットまたはバックアウトなど）に対応する。各ログ・レコードが再生されるにつれて、キューは対応する操作によって更新され、メッセージは、回復作業単位の作業単位ＩＤによって、ならびに上述の通り、バイト値の「回復中」範囲内のバイト値を含む基本キーを割り当てることにより、マークが付けられる。これは、障害の時点に対応するログ・レコード内の点まで続行される。

復元処理がストレージ障害の時点に対応するログ・レコード内の点に到達すると、復元プロセスから独立してメッセージが追加され取り出されることを条件として、メッセージ・リポジトリは、それが障害の時点になっていた状態にすでに復元されている。

この時点で、２６０で回復作業単位をコミットすることにより、復元処理は完了する。キュー・データの整合状態を記録するために同期点が取られ、すべてのメッセージはアプリケーションにとって使用可能なものになる。特に、作業単位をコミットすることは、回復作業単位のための復元操作の実行中に追加、削除、または更新されたメッセージのリストを参照することにより、すべての関連更新を識別することと、次に、リスト内の各メッセージごとに、独特の基本キー内の状態表示バイト値をそのメッセージの新しい状態を表す値に更新することを含む。キー値は所望のメッセージ取出し順序を示すとともにメッセージ状態を示すので、高位バイト値を変更すると、コミットされたメッセージがキュー内の新しい位置に移動する。

「古い」メッセージおよびメッセージ更新をキューに復元するステップが失敗した場合、回復処理の復元ステップが再試行される間に、個別に実行されたキューの再作成により、「新しい」メッセージ用のキューの継続使用を可能にしなければならない。したがって、第１の再作成ステップを実行し、その後、ログ・レコードを参照することにより更新を再適用するという一連の操作は、早期段階でそのキューを新しいメッセージに使用可能なものにするだけでなく、復元処理に影響する任意の問題からキューの再作成および新しいメッセージの処理をシールドする。これらの特徴の組合せの結果、メッセージング機能の可用性が相当改善されるとともに、「キュー満杯」条件に応答して要求される例外処理を回避することができる。

この点以降、回復が成功したと想定すると、キュー上のすべてのメッセージについて通常のメッセージ処理操作を続行することができる。復元されたキューを使用するキュー・マネージャが次にメッセージの状態表示バイト値をチェックする場合、メッセージの新しい状態によって、それを取り出すことができるかどうかを決定することになる。

回復作業単位内の同期点内Ｇｅｔ操作は、ログからの操作を正しい順序で再生するために、その操作がどのメッセージを取り出すかを新しいＧｅｔ操作が指定するという点で、従来のアプリケーションのＧｅｔ操作とは異なる。従来のＧｅｔ操作は概して第１の使用可能メッセージを取り出すが、回復処理中のＧｅｔ操作では、元のＧｅｔ操作によって取り出されたものとは異なるメッセージを取り出すことができるので、回復処理中にこのような手法を取ると、障害の時点のキューと回復されたキューとの間に不整合が発生する可能性がある。したがって、アプリケーションよってはメッセージがキュー上に置かれたのと同じ順序でそのメッセージを処理する必要がないが、それにもかかわらず、ログ・レコードから再生されたメッセージ更新は、障害前に実行された操作の順序との整合性を保証するように適用される。

Ｇｅｔ＿Ｍｅｓｓａｇｅ操作によって取り出すべき特定のメッセージを指定するための適当な技法は、当技術分野ではすでに知られており、したがって、本明細書では詳細に説明しない。１つの実現例としては、各メッセージが共用キューに追加されるときにそのメッセージに割り振られる固有キー（シスプレックス内のすべてのメッセージについて固有のもの）をＧｅｔ＿Ｍｅｓｓａｇｅ操作が使用する。

復元操作の据え置き
本発明のこの実施形態では、回復によって、ログを処理するときに同期点内ＧｅｔおよびＰｕｔ操作が直ちに再生されるわけではない。その代わりに、図４および図５に示す通り、ログの再生によって２５２で対応する作業単位の状態に関する決定を行うことが可能になるまで、２５１でＧｅｔおよびＰｕｔ操作がキャッシュされる。ログが再生され、回復中の１つまたは複数のメッセージ・キューに関する操作が識別される。識別されたログ・レコードはキャッシュにコピーされる。復元処理が障害の時点に対応するログ・レコード内の点に到達すると、キャッシュされたログ・レコードが２５２で分析され、対応する（元の）各作業単位の障害の時点での状態を決定する。

２５２でこの決定が実行されると、以下のアクションの１つが行われる。
１．作業単位がコミットされた場合、回復処理の一部として２５６でＰｕｔまたはＧｅｔが実行される（上述の通り）。
２．作業単位が回復作業単位の終了時に相変わらず未確定である場合、回復処理はＰｕｔまたはＧｅｔを実行するが、さらに、調整する同期点マネージャによる作業単位の究極的解決に要求されるように、２５７で操作に未確定としてならびに元の作業単位の一部としてマークを付ける。
３．すべての残りのケース（バックアウト、打切り、または推定／打切り（presume-abort））の場合、キャッシュされたＧｅｔおよびＰｕｔ操作が２５５で廃棄される。

次に回復作業単位は、前述の通り、コミットされる。

上述の回復処理方法は、保証された１回のみのメッセージ送達を犠牲にせずに、新たに再作成されたキューの使用と並行して復元プロセスが実行できるようにする。

対更新の最適化処理
本発明の発明者は、回復作業単位内のコミットされたＧｅｔ操作の同期点内再生が必然的に同じ回復作業単位内のキューにＰｕｔされたメッセージを取得することであると認識していた。この再生は、Ｇｅｔ＿Ｍｅｓｓａｇｅ操作の再生と、それに続く元の作業単位のコミットの再生を含むことができる。特定のメッセージは、復元プロセスの終了時に回復作業単位のコミットを待たずに、コミットされたＧｅｔ＿Ｍｅｓｓａｇｅ操作に応答して削除することができる。この実施形態では、２５３で回復作業単位内のＰｕｔおよびＧｅｔ対が識別され、キューを更新し、次にその更新を削除する必要なしに、２５４で対応するキャッシュされたログ・レコードがキャッシュから削除される。この実施形態のこの特徴は、不必要な処理を回避するため、ならびに復元中のキュー・マネージャがキュー上のメッセージの蓄積を低減できるようにするために、上述の「解決までキャッシュ（cache-until-resolution）」という特徴を企図している。これは潜在的に、キューまたはリポジトリの不必要な「満杯」条件を回避するものである。

独特のキー
独特の基本キーを使用して、種々の状態にある結合機能（ＣＦ）内のメッセージ間を差異化することは、既存のキュー・マネージャの共用キュー・サポート・メカニズム内で知られていることである。概して、その状態は、コミット、未完了、および未確定である。状態間を差異化するためのこのような独特のキーの使用については、たとえば、本出願人に譲渡された同時係属の米国特許出願第０９／６７７３３９号（特許文献１１）および第０９／６７７３４１号（特許文献１２）の明細書に記載されており、その特許出願は参照により本明細書に組み込まれる。

この実施形態では、回復作業単位内で未完了であるメッセージに独特の基本キー値を使用する。「未完了」は、コミットまたはバックアウトに関する要求が行われる前（または２フェーズ・コミットのケースの「コミット準備」命令の前）のトランザクションの状態である。トランザクションが未完了である間に障害が発生した場合、メッセージ状態はバックアウトするよう解決される。これは、「推定打切り」手法として周知のものである。「未確定」は、外部トランザクション・コーディネータを伴う２フェーズ・コミットのトランザクションに適用される状態である。コーディネータは、利権を有する各リソース・マネージャに対してトランザクションに関する「準備」要求を発行する。準備ステップの完了後、トランザクションはもはや「未完了」ではなくなるが、「未確定」であると言われる。トランザクション・コーディネータからのその後の呼出しに応答して、未確定からコミットまたは打切りへの解決が実行される。ログ・レコードは、未完了トランザクションによって実行されたＧｅｔおよびＰｕｔ操作に関して作成されている場合もあれば、作成されていない場合もある。

基本キーの特殊性は、基本キー内の１バイトに明確な範囲の値を使用することによって達成される。たとえば、Ｐｕｔリスト（すなわち、キューにＰｕｔされたメッセージを表すリスト）上のメッセージの基本キーの１バイト目は、そのメッセージがコミットされた場合にＸ「００」〜Ｘ「０９」という範囲内の値を含み、メッセージがコミットされていない場合にＸ「Ｆ４」〜Ｘ「Ｆ６」という範囲内の値を含む。値の状態表示範囲内のバイト値の特定の割振りは、ＦＩＦＯ順序付けを達成するための範囲内の一連の値に従う。独特のキーを割り振るためのその他の方式も等しく可能である。

アプリケーション・プログラムがＧｅｔ＿Ｍｅｓｓａｇｅ呼出しを発行すると、キュー内のメッセージの基本キー値が調査され、キー範囲のリストと比較され、メッセージの状態を決定する。基本キー値によって反映されるメッセージの状態はアプリケーションがメッセージを取り出すことができるかどうかを決定するが、キー値はまた、キュー内のメッセージの順序付けも決定し、したがって、その取出しが可能ではないメッセージはキューの最後部に対応するキー値を有する。これは、取出し可能メッセージがキュー内で使用可能であるときには単純な数値順によって取出し不能メッセージを回避することを意味する。

このように独特のキーを使用すると、キュー・マネージャは特定の状態のメッセージに選択的にアクセスすることができ、キュー内のコミットされたメッセージの数に基づくトリガなど、その他の機能の単純な実現が可能になる。キーの高位バイトに特殊値を入れることにより、キューに追加（Ｐｕｔ）されたがまだコミットされていないメッセージはリストの最後部に位置決めされ、これにより、キュー・マネージャがアプリケーションのためにＧｅｔ＿Ｍｅｓｓａｇｅ操作を実行しているときにそれらを無視しやすいものにする。

Ｐｕｔ＿Ｍｅｓｓａｇｅ操作の呼出し後のメッセージのいくつかの種々の状態間を差異化するために、明確な高位バイト値を使用することができる。たとえば、第１の範囲のバイト値は、それに関して２フェーズ・コミットの第１の「準備」フェーズとともにＰｕｔが実行されたがＰｕｔがまだコミットされていないメッセージを示すことができ、第２の範囲の値は、それに関してＰｕｔ後にコミットの準備フェーズがまだ実行されていないメッセージを示す。

この実施形態では、各操作およびメッセージ用の対応する明確なキーにより、２つの新しい操作状態が定義され、各キーの１バイトはその状態を識別する値の範囲内の極めて特徴的な値を収容する。この新しい状態は、復元プロセスの一部としてメッセージ・リポジトリ（このケースではＣＦ共用キュー）内に置かれたメッセージにのみ適用可能である。一方の状態は元の作業単位（再生中のＵＯＷ）および回復作業単位内の非コミット状態に対応し、第２の状態は元の作業単位内ではコミット状態に対応するが、回復作業単位内ではまだ非コミット状態である。

これらの新しいメッセージ状態および独特のキー値は以下の恩恵をもたらす。
●同期点内Ｐｕｔ操作は、独特のキーとともにＣＦ上にメッセージを保管することによって再生することができる。この独特のキーは、キューに関するアクションを実行する他のプロセスによってメッセージが処理されるのを防止し、特に、メッセージがキュー項目数計算に含まれるのを防止する。これは、復元プロセスがこれらのＰｕｔ操作をメモリにキャッシュする必要がないことを意味し、これにより、復元プロセスのコードの複雑さおよびストレージ占有率が大幅に低減される。
●同期点外Ｐｕｔ操作と、同期点内Ｐｕｔ操作のコミットは、通常の同期点外活動とは異なるキー値を設定することによって再生することができる。これは、回復作業単位のメモリ内またはＣＦ管理構造モデルを必要とせずに、基本キー値を更新する（第１の値の範囲内の値を異なる状態に対応する第２の範囲からの値で置き換える）ことにより、回復作業単位のコミットを実行できることを意味する。このような構造は、典型的な代替実現例では必要である。

この開示内容を考慮すると、記載した特定の諸実施形態の様々な変更は本発明の利点を達成することができ、特許請求の範囲に示した本発明の範囲内にあることは、当業者にとって明らかになるであろう。

たとえば、好ましい諸実施形態の上記の説明では、データ・リポジトリを再作成することと、データをリポジトリに復元することに言及している。本発明の範囲内のいくつかの解決策は障害の時点でリポジトリ内にあったすべてのデータの復元を伴うことは、当業者にとって明らかになるであろう。その他の解決策は、永続メッセージのみの回復および非永続メッセージの除外など、特定のクラスのデータの回復のみを必要とする。後者では、情報専用データ・ブロードキャストなどの非永続メッセージについてログ・レコードが作成されない可能性がある。たとえば、定期的に更新された天気予報または株価を収容するメッセージは次の更新がまもなく使用可能になる場合に回復する必要がない可能性があり、航空便の予約または株式の売却の取消しを指示するメッセージは保証された１回のみの送達を可能にするために回復可能でなければならない。

第２に、上記の説明では、単一回復作業単位の範囲内でデータ項目を複数のキューに復元することにより処理効率を達成できることに留意したが、代替実現例ではそれ自体の個別作業単位内で各キューを回復することになる。これは、回復処理中の特定のタイプの障害の影響を減少させることになる。

第３に、上記の説明では、回復作業単位のコミットメントまでアプリケーション・プログラムによる取出しのためにそれらを使用不能なものにするためにメッセージにマークを付けるための特定の方法に言及している。回復期間全体の間、リポジトリをロックすることを回避しながら、復元されたメッセージが使用不可であることを制御するためのその他のメカニズムも可能である。このような例の１つは、作業単位ＩＤを設定することと、独特の基本キーとは別に各復元メッセージごとに未確定フラグを設定することである。

本発明の好ましい実施形態の上記の説明では、キューの定義およびキューの内容について独立して保管されたバックアップ・コピーを使用する。代替諸実施形態では、バックアップの時点でデータ・リポジトリを定義する情報とリポジトリの内容の両方を単一２次コピーに維持する。それにもかかわらず、回復処理は、２次（バックアップ）ストレージから保管データを取り出し、リポジトリの高速再作成を可能にするためにある順番でそのデータを処理し、それを新しいデータ項目のために使用可能なものにし、続いて、リポジトリの内容を復元する個別のステップを実行することができる。

本発明の他の諸実施形態は、データベース・ソリューションに適用可能である。データベース・テーブルでは、古い行（障害前にデータが格納されていたもの）を回復する前に新しい行をテーブルに挿入し処理することができる。回復中に、アプリケーションは、回復が完了するなどの時点まで、新しい行のみを収容するものとしてテーブルを見ることになる。

好ましい一実施形態の上記の説明では、（ｉ）高速可用性のために空状態のデータ・リポジトリを再構築し、次に回復作業単位として復元操作を処理することと、（ｉｉ）効率の良い復元処理のために、対応する元の作業単位の決定された状態に依存して復元操作を実行することと、（ｉｉｉ）効率の良い処理のために、またデータ・リポジトリ内の蓄積を回避するために、対更新を最適化処理することと、（ｉｖ）データ項目の特定の回復中状態とデータ項目に対する更新を示すために独特の基本キーを使用することを包含する回復方法および装置を開示している。当業者にとって明らかになるように、（ｉ）〜（ｉｖ）の特徴は補完的なものであるが、これらの特徴（ｉ）〜（ｉｖ）のすべてがまとめて実現されることは、これらの特徴（ｉ）〜（ｉｖ）のいずれか１つの操作にとって不可欠なものではない。

メッセージがターゲット・アプリケーション・プログラムまでの途中でキュー間で転送されるメッセージ通信ネットワークを示す図である。 結合機能リスト構造内のキューに共用アクセス可能な１組のキュー・マネージャを表す図である。 本発明の一実施形態による回復方法の一連のステップを示す図である。 本発明の一実施形態による回復作業単位の一連のステップを示す図である。 本発明の一実施形態による回復作業単位の一連のステップを示す図である。

Claims (17)

1. データ・リポジトリの１次コピーに影響する障害から前記データ・リポジトリを回復するための方法であって、
   前記データ・リポジトリの前記１次コピーおよびそれに保持されたデータ項目を回復するために十分なデータの２次コピーを維持するステップと、
   前記データ・リポジトリの前記１次コピーに影響する障害に応答して、前記２次コピーから前記データ・リポジトリの１次コピーを再作成するステップと、
   復元プロセスを使用して回復作業単位内で前記２次コピーから前記１次コピーにデータ項目を復元するステップとを含み、
   前記回復作業単位のコミットまで、前記回復作業単位内で前記データ・リポジトリの前記１次コピーに復元されたデータ項目は前記復元プロセス以外のプロセスにとってアクセス不能であり、前記方法は更に、
   前記回復作業単位のコミット前に、前記復元ステップから独立して前記データ・リポジトリへのデータ項目の追加を可能にし、前記復元プロセス以外のプロセスが前記独立して追加されたデータ項目にアクセスすることを可能にするように、前記データ・リポジトリの前記１次コピーを構成するステップと、
   前記復元ステップの正常終了に応答して、前記復元データの前記アクセス不能性を解除することを含む、前記回復作業単位をコミットするステップと、
   を含む方法。
2. 前記２次データ・コピーを維持する前記ステップが、前記データ・リポジトリのバックアップ・コピーを保管することと、前記バックアップ・コピーが保管されてから実行された前記１次コピーに対する更新を記述するログ・レコードを保管することを有し、前記データ・リポジトリの前記１次コピーを再作成する前記ステップが、前記バックアップ・コピーからデータ・リポジトリ定義をコピーし、前記定義を適用して前記１次コピーを再作成するステップを有し、前記１次コピーにデータ項目を復元する前記ステップが、前記バップアップ・コピーからデータ項目をコピーすることと、前記ログ・レコードを適用して前記１次コピーに対する更新を識別し再適用することを有する、請求項１に記載の方法。
3. 前記２次データ・コピーを維持する前記ステップが、前記１次コピーに対する更新を記述するログ・レコードを保管することを含み、前記リポジトリの前記１次コピーを復元する前記ステップが、
   前記データ・リポジトリの前記１次コピー内のデータ項目に対して実行された操作の前記ログ・レコードを適用するステップと、
   元の作業単位内で同期点制御下で実行された操作に関するログ・レコードをキャッシュするステップと、
   キャッシュされた前記ログ・レコードから、前記障害の時点の前記元の作業単位の状態を決定するステップと、
   前記元の作業単位の決定された前記状態に基づいて、前記同期点制御操作のうちのどの操作を前記回復作業単位内で実行すべきかを決定するステップと、
   を含む、請求項１に記載の方法。
4. 前記障害前に前記元の作業単位がコミットされた場合に、コミットされた前記作業単位の関連操作を実行し、
   前記障害が発生したときに前記元の作業単位が未確定であった場合に、前記未確定作業単位の前記関連操作を実行しかつ、前記操作に未確定のマークを付け、
   前記元の作業単位がコミットされず未確定でもない場合に、キャッシュされた前記操作を廃棄する
   という手続きに従って前記回復作業単位内で操作を実行することを含む、請求項３に記載の方法。
5. 前記データ・リポジトリの前記１次コピーへのデータ項目の追加と前記データ・リポジトリの前記１次コピーからの前記同じデータ項目の削除とを有する追加および削除操作が前記障害前に実行されコミットされたという条件で、前記追加および削除操作の任意の対を前記回復作業単位から廃棄することを含む、請求項３に記載の方法。
6. 前記データ・リポジトリがメッセージ・リポジトリであり、前記データ・リポジトリの前記１次コピーにデータを復元する前記ステップが、前記メッセージ・リポジトリに対してメッセージ追加、更新、および削除操作を実行することを有する、請求項１ないし５のいずれか１項に記載の方法。
7. 前記２次データ・コピーを維持する前記ステップが、前記１次コピーに対する更新を記述するためのログ・レコードを保管することを含み、前記リポジトリの前記１次コピーにデータを復元する前記ステップが、元の作業単位内で同期点制御下で実行されたメッセージ追加、更新、および削除操作に関するログ・レコードをキャッシュするステップと、前記ログ・レコードから、前記障害の時点の前記元の作業単位の前記状態を決定するステップと、前記元の作業単位の決定された前記状態に基づいて、
   前記元の作業単位がコミットされる場合に、前記関連メッセージ追加、更新、および削除操作を実行し、
   前記元の作業単位が未確定である場合に、前記関連メッセージ追加、更新、および削除操作を実行しかつ、前記操作に未確定のマークを付け、
   前記元の作業単位がコミットされず未確定でもない場合に、キャッシュされた前記操作を廃棄する
   ように、前記回復作業単位内で実行すべき前記操作を決定するステップとを含む、メッセージング通信システム内で実行するための、請求項６に記載の方法。
8. 前記データ・リポジトリに復元された各データ項目ごとにフラグを設定することにより、前記回復作業単位内で前記リポジトリの前記１次コピーに復元されたデータがアクセス不能なものになり、前記データ項目がアクセス不能であることを前記フラグが示す、請求項１ないし７のいずれか１項に記載の方法。
9. 前記フラグが前記データ項目のトランザクション状態を示し、前記リポジトリからのデータ項目にアクセスするためのプロセスが、１つまたは複数の事前定義トランザクション状態をアクセス不能として識別するように適合される、請求項８に記載の方法。
10. 前記フラグが、前記データ項目が前記データ・リポジトリに復元されるときに前記データ項目に割り振られた独特の基本キーのバイト値を有し、前記バイト値が、前記データ項目の前記トランザクション状態を示す値の範囲から選択される、請求項８または請求項９に記載の方法。
11. フラグを設定する前記ステップが、
    そのデータ項目に関しては、前記障害前に当該データ項目について実行された最新操作がコミットされた追加操作であり、前記回復作業単位内で前記データ・リポジトリに復元される任意のデータ項目に関する第１のフラグを設定することと、
    そのデータ項目に関しては、前記障害前に当該データ項目について実行された最新操作が未確定追加または削除操作であり、前記回復作業単位内で前記データ・リポジトリに復元される任意のデータ項目に関する第２のフラグを設定すること
    を有する、請求項８ないし１０のいずれか１項に記載の方法。
12. 前記第１のフラグが第１のトランザクション状態を表す第１の範囲のバイト値から選択されたデータ項目キーのバイト値を有し、前記第２のフラグが第２のトランザクション状態を表す第２の範囲のバイト値から選択されたデータ項目キーのバイト値を有する、請求項１１に記載の方法。
13. データ・リポジトリの１次コピーを保管するためのデータ・ストレージと、
    前記データ・リポジトリを表すデータの２次コピーであって、２次データが前記データ・リポジトリの前記１次コピーとそれに保持されたデータを回復するために十分である前記２次コピーを保管する２次データ・ストレージと、
    前記データ・リポジトリの前記１次コピーに影響する障害から回復するようにデータ通信システムの動作を制御するための回復コンポーネントであって、前記回復コンポーネントが、
    前記２次コピーから前記データ・リポジトリの１次コピーを再作成するステップと、
    復元プロセスを使用して回復作業単位内で前記２次コピーから前記１次コピーにデータ項目を復元するステップであって、前記回復作業単位のコミットまで、前記回復作業単位内で前記データ・リポジトリの前記１次コピーに復元されたデータ項目は前記復元プロセス以外のプロセスにとってアクセス不能である、前記復元するステップと、
    前記回復作業単位のコミット前に、前記復元ステップから独立して前記データ・リポジトリへのデータ項目の追加を可能にし、前記回復プロセス以外のプロセスが前記独立して追加されたデータ項目にアクセスすることを可能にするように、前記データ・リポジトリの前記１次コピーを構成するステップと、
    前記復元ステップの正常終了に応答して、前記復元データの前記アクセス不能性を解除することを含む、前記回復作業単位をコミットするステップと、
    を実行するように前記データシステムを制御するように動作可能である回復コンポーネントと、
    を含むデータ通信システム。
14. センダとレシーバとの間でメッセージを転送するためのデータ通信システムであって、メッセージがメッセージ送信操作後にメッセージ・リポジトリ内に保持され、その後、前記レシーバに送達するために前記リポジトリから取り出され、前記リポジトリのバックアップ・コピーが作成され、前記バックアップ・コピーの作成以降のメッセージ送信およびメッセージ取出しイベントを記録するためにログ・レコードが作成され、前記システムが、
    前記メッセージ・リポジトリに影響する障害に応答して、前記障害前に作成された、前記リポジトリの前記バックアップ・コピーを参照することにより前記リポジトリにメッセージを復元するステップと、
    前記回復処理の完了前に、前記回復処理の完了を待たずに、新しいメッセージを前記リポジトリに追加し、そこから取り出すことを可能にするように前記リポジトリを構成するステップと、
    前記障害前に作成されたログ・レコードを参照することにより、前記障害前に実行されたメッセージ送信およびメッセージ取出し操作に対応する前記メッセージ・リポジトリに対する更新を再適用するステップと、
    を実行するように前記データ通信システムを制御するように適合された回復コンポーネントを含み、
    前記リポジトリにメッセージを復元する前記ステップと前記バックアップ・コピーおよびログ・レコードを参照することにより前記リポジトリに対する更新を再適用する前記ステップが回復作業単位内で実行され、前記障害前に実行された送信および取出し操作に対応するすべてのメッセージ・リポジトリ更新が前記メッセージ・リポジトリに再適用されるまで前記復元されたメッセージと再適用された更新がアクセス不能になる、データ通信システム。
15. データ・リポジトリの１次コピーに影響する障害から前記データ・リポジトリを回復するための方法を実行するためにプログラム・コードが実行されるデータ処理装置の動作を制御するための前記プログラム・コードを記録する記録媒体であって、当該記録媒体は、２次データ・ストレージおよび、前記データ・リポジトリの前記１次コピーとそれに保持されたデータ項目を回復するために十分であるデータの２次コピーを前記２次データ・ストレージに維持するためのコンポーネントとを有するデータ処理装置で使用され、前記方法が、
    前記データ・リポジトリの前記１次コピーに影響する障害に応答して、前記２次コピーから前記データ・リポジトリの１次コピーを再作成するステップと、
    復元プロセスを使用して回復作業単位内で前記２次コピーから前記１次コピーにデータ項目を復元するステップとを含み、前記回復作業単位のコミットまで、前記回復作業単位内で前記データ・リポジトリの前記１次コピーに復元されたデータ項目は前記復元プロセス以外のプロセスにとってアクセス不能であり、前記方法は更に、
    前記回復作業単位のコミット前に、前記復元ステップから独立して前記データ・リポジトリへのデータ項目の追加を可能にし、前記復元プロセス以外のプロセスが前記独立して追加されたデータ項目にアクセスすることを可能にするように、前記データ・リポジトリの前記１次コピーを構成するステップと、
    前記復元ステップの正常終了に応答して、前記復元データの前記アクセス不能性を解除することを含む、前記回復作業単位をコミットするステップと、
    を含む、記録媒体。
16. データ・リポジトリの１次コピーに影響する障害から前記データ・リポジトリを回復するための方法を実行するためにプログラムが実行されるデータ処理装置の動作を制御するためのコンピュータ・プログラムであって、前記データ処理装置が２次データ・ストレージ・エリアを有し、前記コンピュータ・プログラムが、データの２次コピーを前記２次データ・ストレージ・エリアに維持するためのコンポーネントであって、その２次コピーが前記データ・リポジトリの前記１次コピーとそれに保持されたデータ項目を回復するために十分であるコンポーネントを含み、前記方法が、
    前記データ・リポジトリの前記１次コピーに影響する障害に応答して、前記２次コピーから前記データ・リポジトリの１次コピーを再作成するステップと、
    復元プロセスを使用して回復作業単位内で前記２次コピーから前記１次コピーにデータ項目を復元するステップであって、前記回復作業単位のコミットまで、前記回復作業単位内で前記データ・リポジトリの前記１次コピーに復元されたデータ項目が前記復元プロセス以外のプロセスにとってアクセス不能なものになるステップと、
    前記回復作業単位のコミット前に、前記復元ステップから独立して前記データ・リポジトリへのデータ項目の追加を可能にし、前記復元プロセス以外のプロセスが前記独立して追加されたデータ項目にアクセスすることを可能にするように、前記データ・リポジトリの前記１次コピーを構成するステップと、
    前記復元ステップの正常終了に応答して、前記復元データの前記アクセス不能性を解除することを含む、前記回復作業単位をコミットするステップと、
    を含む、コンピュータ・プログラム。
17. データ・リポジトリの１次コピーに影響する障害から前記データ・リポジトリを回復するための回復コンポーネントであって、１次および２次データ・ストレージを有し、データの２次コピーを前記２次データ・ストレージに維持するためのコンポーネントであって、その２次コピーが前記データ・リポジトリの前記１次コピーとそれに保持されたデータ項目を回復するために十分であるコンポーネントを有するデータ処理システムで使用するための回復コンポーネントであって、
    前記データ・リポジトリの前記１次コピーに影響する障害に応答して、前記２次コピーから前記データ・リポジトリの１次コピーを再作成するステップと、
    復元プロセスを使用して回復作業単位内で前記２次コピーから前記１次コピーにデータ項目を復元するステップであって、前記回復作業単位のコミットまで、前記回復作業単位内で前記データ・リポジトリの前記１次コピーに復元されたデータ項目が前記復元プロセス以外のプロセスにとってアクセス不能なものになるステップと、
    前記回復作業単位のコミット前に、前記復元ステップから独立して前記データ・リポジトリへのデータ項目の追加を可能にし、前記復元プロセス以外のプロセスが前記独立して追加されたデータ項目にアクセスすることを可能にするように、前記データ・リポジトリの前記１次コピーを構成するステップと、
    前記復元ステップの正常終了に応答して、前記復元データの前記アクセス不能性を解除することを含む、前記回復作業単位をコミットするステップと、
    を含む方法を実行するように適合された回復コンポーネント。
    

Images