JP2644188B2 - フォールト・トレラント・トランザクション指向データ処理システムおよび方法 - Google Patents
フォールト・トレラント・トランザクション指向データ処理システムおよび方法Info
- Publication number
- JP2644188B2 JP2644188B2 JP6163804A JP16380494A JP2644188B2 JP 2644188 B2 JP2644188 B2 JP 2644188B2 JP 6163804 A JP6163804 A JP 6163804A JP 16380494 A JP16380494 A JP 16380494A JP 2644188 B2 JP2644188 B2 JP 2644188B2
- Authority
- JP
- Japan
- Prior art keywords
- transaction
- log
- recovery
- message
- queue
- 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
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/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1474—Saving, restoring, recovering or retrying in transactions
-
- 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/14—Error detection or correction of the data by redundancy in operation
- G06F11/1402—Saving, restoring, recovering or retrying
- G06F11/1471—Saving, restoring, recovering or retrying involving logging of persistent data for recovery
-
- 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
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Quality & Reliability (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
- Retry When Errors Occur (AREA)
Description
【０００１】
【産業上の利用分野】本発明はフォールト・トレラント
・トランザクション指向データ処理に関し、具体的には
トランザクション指向のメッセージ伝達システム、ファ
イル・システム、データベース・システムなどのトラン
ザクション内で回復可能資源の更新をサポートするため
の効率的な方法及びシステムに関する。
・トランザクション指向データ処理に関し、具体的には
トランザクション指向のメッセージ伝達システム、ファ
イル・システム、データベース・システムなどのトラン
ザクション内で回復可能資源の更新をサポートするため
の効率的な方法及びシステムに関する。
【０００２】
【従来の技術】アプリケーション指向のコンピュータ・
プログラムを使用するトランザクション処理によって多
くのビジネス機能を実施できる。アプリケーション指向
プログラムの大半がなんらかの形のコンピュータ・シス
テム機能(プロセッサ、データベース、ファイル、入出
力装置、他のアプリケーション・プログラムなどの機
能)へのアクセスを必要とするが、これらの機能を一般
に資源と称する。これらの資源を制御するシステム・ソ
フトウェアを一般に資源管理プログラムと称する。一般
的な処理要件は1つ又は複数の資源(具体的にはデータ・
オブジェクトの集まり)に1組のコーディネートされた変
更を加えて変更のすべてが有効となって資源が新しい一
貫性のある状態に移されるか、それらが全く行われない
かのいずれかにすることができることである。すべてか
無というこの処理の特性を「アトミック性」と称する。
プログラムを使用するトランザクション処理によって多
くのビジネス機能を実施できる。アプリケーション指向
プログラムの大半がなんらかの形のコンピュータ・シス
テム機能(プロセッサ、データベース、ファイル、入出
力装置、他のアプリケーション・プログラムなどの機
能)へのアクセスを必要とするが、これらの機能を一般
に資源と称する。これらの資源を制御するシステム・ソ
フトウェアを一般に資源管理プログラムと称する。一般
的な処理要件は1つ又は複数の資源(具体的にはデータ・
オブジェクトの集まり)に1組のコーディネートされた変
更を加えて変更のすべてが有効となって資源が新しい一
貫性のある状態に移されるか、それらが全く行われない
かのいずれかにすることができることである。すべてか
無というこの処理の特性を「アトミック性」と称する。
【０００３】C.J.Date著"An Introduction to Data Bas
e Systems", Vol. 1, 4th Edition,Addison-Wesley Pub
lishing Co., 1986, Ch.18に指摘されているように「ト
ランザクション」とは1つ又は複数の回復可能資源の一
貫性のある状態を別の一貫性のある状態に変換する(す
べての中間点で一貫性を維持する必要はない)関連動作
のシーケンスを指す作業の論理単位である。トランザク
ション処理とは共用データをアクセスし更新する別々の
作業単位を管理することである。
e Systems", Vol. 1, 4th Edition,Addison-Wesley Pub
lishing Co., 1986, Ch.18に指摘されているように「ト
ランザクション」とは1つ又は複数の回復可能資源の一
貫性のある状態を別の一貫性のある状態に変換する(す
べての中間点で一貫性を維持する必要はない)関連動作
のシーケンスを指す作業の論理単位である。トランザク
ション処理とは共用データをアクセスし更新する別々の
作業単位を管理することである。
【０００４】システム、媒体及びトランザクションの障
害(後者の1例はアプリケーションによって検出され、ト
ランザクションの完了不能につながるエラー状態であ
る)に対してデータ一貫性及びトランザクションのアト
ミック性を維持できるフォールト・トレラント・トラン
ザクション処理システムが知られている。障害の後に資
源を一貫性のある状態に回復できるようにするために
は、システムが障害の時点でのシステム資源の状態の記
録を保持する必要があり、これには完了したトランザク
ションをもう一度実行できるようにどのトランザクショ
ンが完了していたかを知り、未完了のトランザクション
内の動作を取り消せるようにどのトランザクションが進
行中であったかを知ることが含まれる。従って、トラン
ザクションによって作業の単位ならびに回復の単位が定
義される。
害(後者の1例はアプリケーションによって検出され、ト
ランザクションの完了不能につながるエラー状態であ
る)に対してデータ一貫性及びトランザクションのアト
ミック性を維持できるフォールト・トレラント・トラン
ザクション処理システムが知られている。障害の後に資
源を一貫性のある状態に回復できるようにするために
は、システムが障害の時点でのシステム資源の状態の記
録を保持する必要があり、これには完了したトランザク
ションをもう一度実行できるようにどのトランザクショ
ンが完了していたかを知り、未完了のトランザクション
内の動作を取り消せるようにどのトランザクションが進
行中であったかを知ることが含まれる。従って、トラン
ザクションによって作業の単位ならびに回復の単位が定
義される。
【０００５】しばしば更新を行う前のトランザクション
を成功裡に完了できるかどうかの検証の遅延なしで1ト
ランザクション内で資源更新を行うことが処理要件にな
る。従って、このようなシステムでは、アトミック性及
び一貫性のためにトランザクションが成功裡に完了でき
ない時のための逆方向回復機能を設け、部分的実行中に
資源に加えられたすべての変更を除去できるようにする
必要がある。
を成功裡に完了できるかどうかの検証の遅延なしで1ト
ランザクション内で資源更新を行うことが処理要件にな
る。従って、このようなシステムでは、アトミック性及
び一貫性のためにトランザクションが成功裡に完了でき
ない時のための逆方向回復機能を設け、部分的実行中に
資源に加えられたすべての変更を除去できるようにする
必要がある。
【０００６】あるトランザクションの開始の前に存在し
た一貫性のある状態への資源の回復をトランザクション
のROLLBACK(ロールバック、BACKOUT(バックアウト)と同
義語、1トランザクション全体のROLLBACKをABORT(打切)
と称する)と称し、一般に変更は元々それが行われた時
間的な順序と逆の順序で除去される。
た一貫性のある状態への資源の回復をトランザクション
のROLLBACK(ロールバック、BACKOUT(バックアウト)と同
義語、1トランザクション全体のROLLBACKをABORT(打切)
と称する)と称し、一般に変更は元々それが行われた時
間的な順序と逆の順序で除去される。
【０００７】トランザクション性技法を使用できるシス
テムの1例が文書"IBM Messaging and Queuing Series -
Technical Reference" (SC33-0850-01, 1993)に記載の
メッセージ伝達及び待合せシステムである。メッセージ
伝達及び待合せは高水準のプログラム間通信用の複数の
機能を提供する。これには下記が含まれる。 ・メッセージ伝達: 通信プロトコルを隠蔽するプログ
ラム間通信の簡単な手段 ・待合せ: メッセージの遅延配布。これを用いると同
時に活動状態にならないかそれらのためのデータ・リン
クが活動状態でないプロセスの間での非同期通信が可能
になる。メッセージ伝達及び待合せサービスによって目
標アプリケーションへの後の配布を保証できる ・メッセージ駆動処理: 分散システム内の複数のプロ
セスへのメッセージの流れによるアプリケーション・タ
スクの達成。諸プロセスはアプリケーション・タスクが
達成されるまで待ち行列内のメッセージをアクセスし、
新メッセージを生成することによって一緒に作業する。
テムの1例が文書"IBM Messaging and Queuing Series -
Technical Reference" (SC33-0850-01, 1993)に記載の
メッセージ伝達及び待合せシステムである。メッセージ
伝達及び待合せは高水準のプログラム間通信用の複数の
機能を提供する。これには下記が含まれる。 ・メッセージ伝達: 通信プロトコルを隠蔽するプログ
ラム間通信の簡単な手段 ・待合せ: メッセージの遅延配布。これを用いると同
時に活動状態にならないかそれらのためのデータ・リン
クが活動状態でないプロセスの間での非同期通信が可能
になる。メッセージ伝達及び待合せサービスによって目
標アプリケーションへの後の配布を保証できる ・メッセージ駆動処理: 分散システム内の複数のプロ
セスへのメッセージの流れによるアプリケーション・タ
スクの達成。諸プロセスはアプリケーション・タスクが
達成されるまで待ち行列内のメッセージをアクセスし、
新メッセージを生成することによって一緒に作業する。
【０００８】ほとんどのアプリケーションはいくつかの
形式の資源をアクセスすることを必要とし、一般に2つ
以上の資源への1組のコーディネートされた変更を行え
ることが必要である。「コーディネートされた」とは資
源に対する変更のすべてが実施されるか1つも実施され
ないかのいずれかであることを意味する。待ち行列もこ
れに関しては例外でない。アプリケーションはメッセー
ジをプットし、ゲットする(及びおそらくはデータベー
スなど他の資源を更新する)ことができ、動作のすべて
が実施されるか1つも実施されないかを知ることができ
る必要がある。これに含まれる動作のセットをトランザ
クション又は作業の単位と称する。下記の例でこれを示
す。
形式の資源をアクセスすることを必要とし、一般に2つ
以上の資源への1組のコーディネートされた変更を行え
ることが必要である。「コーディネートされた」とは資
源に対する変更のすべてが実施されるか1つも実施され
ないかのいずれかであることを意味する。待ち行列もこ
れに関しては例外でない。アプリケーションはメッセー
ジをプットし、ゲットする(及びおそらくはデータベー
スなど他の資源を更新する)ことができ、動作のすべて
が実施されるか1つも実施されないかを知ることができ
る必要がある。これに含まれる動作のセットをトランザ
クション又は作業の単位と称する。下記の例でこれを示
す。
【０００９】ある口座から同じ場所にある別の口座への
送金を行う金融アプリケーションでは2つの基本動作を
行う必要がある。即ち一方の口座の借方記入及び他方の
口座の貸方記入である。通常はこの両方の動作が成功す
るが、一方で障害が発生する場合には、両方をエラーに
しなければならない。この障害は動作上の理由(例えば
一方の待ち行列が一時的に使用不能)である場合があ
り、この場合このトランザクションを後にもう一度提示
できる。またこの障害が借り方口座の資金不足が原因の
場合があるが、この場合には適当な応答をトランザクシ
ョンの開始プログラムに返さなければならない。
送金を行う金融アプリケーションでは2つの基本動作を
行う必要がある。即ち一方の口座の借方記入及び他方の
口座の貸方記入である。通常はこの両方の動作が成功す
るが、一方で障害が発生する場合には、両方をエラーに
しなければならない。この障害は動作上の理由(例えば
一方の待ち行列が一時的に使用不能)である場合があ
り、この場合このトランザクションを後にもう一度提示
できる。またこの障害が借り方口座の資金不足が原因の
場合があるが、この場合には適当な応答をトランザクシ
ョンの開始プログラムに返さなければならない。
【００１０】一方の口座の貸方記入及び他方の口座の借
方記入が作業の単位を構成する。作業の単位は最初の回
復可能資源が影響を受ける時に始まる。メッセージ待合
せの場合、これはメッセージが作業の単位の一部として
ゲット又はプットされる時を意味する。この作業の単位
はそのアプリケーションが終了する時又はそのアプリケ
ーションがシンクポイント(下記を参照されたい)を宣言
する時に終了する。アプリケーションがシンクポイント
を宣言することによって作業が終了する場合、もう1つ
の作業の単位を開始でき、その結果あるアプリケーショ
ンの1つのインスタンスが複数の順次的作業の単位にか
かわることが出来る。
方記入が作業の単位を構成する。作業の単位は最初の回
復可能資源が影響を受ける時に始まる。メッセージ待合
せの場合、これはメッセージが作業の単位の一部として
ゲット又はプットされる時を意味する。この作業の単位
はそのアプリケーションが終了する時又はそのアプリケ
ーションがシンクポイント(下記を参照されたい)を宣言
する時に終了する。アプリケーションがシンクポイント
を宣言することによって作業が終了する場合、もう1つ
の作業の単位を開始でき、その結果あるアプリケーショ
ンの1つのインスタンスが複数の順次的作業の単位にか
かわることが出来る。
【００１１】ゲット動作又はプット動作はそれぞれ現在
の作業の単位に別々に参加することができる。アプリケ
ーションはMQGET、MQPUT及びMQPUT1の呼出し時に適当な
「シンクポイント」又は「非シンクポイント」のオプシ
ョンを指定することによってどの動作が参加するかを選
択する。どちらのオプションも指定されない場合、現在
の作業の単位内での呼出しの参加は環境によって決定さ
れる。
の作業の単位に別々に参加することができる。アプリケ
ーションはMQGET、MQPUT及びMQPUT1の呼出し時に適当な
「シンクポイント」又は「非シンクポイント」のオプシ
ョンを指定することによってどの動作が参加するかを選
択する。どちらのオプションも指定されない場合、現在
の作業の単位内での呼出しの参加は環境によって決定さ
れる。
【００１２】アプリケーションはシンクポイントを宣言
することによって作業の単位を終える。シンクポイント
が宣言される時、その作業の単位に関心を有するもの
は"no"を投票し、従ってその作業の単位をバックアウト
させることができる。これにはその作業の単位の一部と
して行われた変更のすべてを取り消すという効果があ
る。参加するすべてのものが"yes"を投票する場合、そ
の作業の単位がコミットされ、その作業の一部として行
われた変更が永続的になる。作業の単位に関心を有する
ものとは下記のいずれかである。 ・アプリケーション ・待ち行列管理プログラム ・他の資源管理プログラム アプリケーションは適当な環境依存の呼出しを発行する
ことによってシンクポイントを宣言し投票を登録する。
することによって作業の単位を終える。シンクポイント
が宣言される時、その作業の単位に関心を有するもの
は"no"を投票し、従ってその作業の単位をバックアウト
させることができる。これにはその作業の単位の一部と
して行われた変更のすべてを取り消すという効果があ
る。参加するすべてのものが"yes"を投票する場合、そ
の作業の単位がコミットされ、その作業の一部として行
われた変更が永続的になる。作業の単位に関心を有する
ものとは下記のいずれかである。 ・アプリケーション ・待ち行列管理プログラム ・他の資源管理プログラム アプリケーションは適当な環境依存の呼出しを発行する
ことによってシンクポイントを宣言し投票を登録する。
【００１３】作業の単位の一部としてメッセージがプッ
トされる場合、そのメッセージはその作業の単位が成功
裡にコミットされない限り通常はアプリケーションによ
る検索のために使用可能にはならない。これに対する1
つの例外がそのメッセージをプットしたアプリケーショ
ンである。このアプリケーションは元の作業の単位がコ
ミットされる前にその作業の単位の一部として宛先待ち
行列からメッセージを検索できる。ただし、これを可能
にするためには宛先待ち行列がローカル待ち行列でなけ
ればならない。
トされる場合、そのメッセージはその作業の単位が成功
裡にコミットされない限り通常はアプリケーションによ
る検索のために使用可能にはならない。これに対する1
つの例外がそのメッセージをプットしたアプリケーショ
ンである。このアプリケーションは元の作業の単位がコ
ミットされる前にその作業の単位の一部として宛先待ち
行列からメッセージを検索できる。ただし、これを可能
にするためには宛先待ち行列がローカル待ち行列でなけ
ればならない。
【００１４】宛先待ち行列が遠隔待ち行列管理プログラ
ムに属する場合、そのメッセージはその作業の単位がコ
ミットされない限りローカル待ち行列管理プログラムか
ら送るのに使用できない。これは要求メッセージの送出
及びその要求に対する応答の受取りを同一の作業の単位
の一部として行うことができないことを意味する。要求
メッセージを含む作業の単位をコミットした後でなけれ
ば応答を受け取ることはできない。
ムに属する場合、そのメッセージはその作業の単位がコ
ミットされない限りローカル待ち行列管理プログラムか
ら送るのに使用できない。これは要求メッセージの送出
及びその要求に対する応答の受取りを同一の作業の単位
の一部として行うことができないことを意味する。要求
メッセージを含む作業の単位をコミットした後でなけれ
ば応答を受け取ることはできない。
【００１５】メッセージがプットされる時に待ち行列管
理プログラムによって検出されたエラーは完了コード・
パラメータ及び理由コード・パラメータによって即座に
アプリケーションに返される。この形で検出できるエラ
ーには下記のものが含まれる。 ・メッセージが大きすぎて待ち行列に入らない ・待ち行列が満杯 ・待ち行列に関して禁止されている要求をプットした メッセージのプットで障害が発生してもその作業の単位
の状況には影響しない(そのメッセージは作業の単位の
一部ではないので)。従ってアプリケーションは必要に
応じてその作業の単位をコミット又はバックアウトでき
る。
理プログラムによって検出されたエラーは完了コード・
パラメータ及び理由コード・パラメータによって即座に
アプリケーションに返される。この形で検出できるエラ
ーには下記のものが含まれる。 ・メッセージが大きすぎて待ち行列に入らない ・待ち行列が満杯 ・待ち行列に関して禁止されている要求をプットした メッセージのプットで障害が発生してもその作業の単位
の状況には影響しない(そのメッセージは作業の単位の
一部ではないので)。従ってアプリケーションは必要に
応じてその作業の単位をコミット又はバックアウトでき
る。
【００１６】しかし作業の単位の一部として成功裡にプ
ットされたメッセージがアプリケーションが作業の単位
をコミットしようとした時にエラーを引き起こす場合に
は、その作業の単位がバックアウトされる。
ットされたメッセージがアプリケーションが作業の単位
をコミットしようとした時にエラーを引き起こす場合に
は、その作業の単位がバックアウトされる。
【００１７】作業の単位の一部としてメッセージを検索
する場合、そのメッセージは待ち行列から除去され、他
のアプリケーションからは使用不能になる。しかし、そ
のメッセージは破棄されず、作業の単位がコミット又は
バックアウトされるまで待ち行列管理プログラムによっ
て保存される。
する場合、そのメッセージは待ち行列から除去され、他
のアプリケーションからは使用不能になる。しかし、そ
のメッセージは破棄されず、作業の単位がコミット又は
バックアウトされるまで待ち行列管理プログラムによっ
て保存される。
【００１８】作業の単位が成功裡にコミットされる場
合、待ち行列管理プログラムがメッセージを破棄する。
しかし、作業の単位がバックアウトされる場合、そのメ
ッセージは待ち行列の元の位置に復元され、従って同一
のアプリケーション又は別のアプリケーションによる走
査検索又は検索にもう一度使用可能になる。
合、待ち行列管理プログラムがメッセージを破棄する。
しかし、作業の単位がバックアウトされる場合、そのメ
ッセージは待ち行列の元の位置に復元され、従って同一
のアプリケーション又は別のアプリケーションによる走
査検索又は検索にもう一度使用可能になる。
【００１９】作業の単位を持続性と称するメッセージの
特性と混同してはならない。メッセージの持続性とはメ
ッセージが障害及び待ち行列管理プログラムの再開の後
でも残っているかどうかである。
特性と混同してはならない。メッセージの持続性とはメ
ッセージが障害及び待ち行列管理プログラムの再開の後
でも残っているかどうかである。
【００２０】作業の単位を使用してアプリケーションの
障害又は同一の作業の単位内で動作する他の資源管理プ
ログラムの障害に対する保護を行うことができる。この
「障害」には、プログラムが宣言する障害ならびにエラ
ー状況を含めることができる。その一方で、メッセージ
の持続性によって待ち行列管理プログラムの障害に対す
る保護が行われる。
障害又は同一の作業の単位内で動作する他の資源管理プ
ログラムの障害に対する保護を行うことができる。この
「障害」には、プログラムが宣言する障害ならびにエラ
ー状況を含めることができる。その一方で、メッセージ
の持続性によって待ち行列管理プログラムの障害に対す
る保護が行われる。
【００２１】作業の単位を使用する多くのアプリケーシ
ョンが持続性メッセージも使用しようとする。しかし、
このどちらか一方だけを使用することが有利な情況が存
在する。例えば、待ち行列管理プログラムの障害の後に
回復を行う論理がアプリケーションに含まれる場合、非
持続性メッセージと共に作業の単位を使用すると、通常
の障害のない場合に性能の利益が得られる。この組合せ
を使用して作業の単位がシンクポイントに達する前にバ
ックアウトされる場合に、最終(非持続性)メッセージを
送らないようにすることもできる。
ョンが持続性メッセージも使用しようとする。しかし、
このどちらか一方だけを使用することが有利な情況が存
在する。例えば、待ち行列管理プログラムの障害の後に
回復を行う論理がアプリケーションに含まれる場合、非
持続性メッセージと共に作業の単位を使用すると、通常
の障害のない場合に性能の利益が得られる。この組合せ
を使用して作業の単位がシンクポイントに達する前にバ
ックアウトされる場合に、最終(非持続性)メッセージを
送らないようにすることもできる。
【００２２】一般的な議論に戻ると、システム障害及び
トランザクション障害からの回復に必要な情報を提供す
るために回復可能データに対して行われるすべての処置
が通常は回復ログに記録される。このログは可変長レコ
ードのための持続性(不揮発性)記憶域であり、書込みは
その末尾でのみ可能であるが、読取りはどのような順序
でも可能である。通常資源更新動作ごとにUNDO(非実行)
ログ・レコード及びREDO(再実行)ログ・レコードが書き
込まれるが、前者は資源の前の状態を示し、後者は資源
の新しい状態を示す。障害の場合、作業の単位の進行状
態によってどのレコードを回復に使用するかが決定され
る。UNDOログ・レコードは障害の時点でトランザクショ
ンが未完了であった場合に、トランザクション開始の前
に存在した状態にシステム資源を復元できるようにする
ために読み取られるが、REDOレコードはトランザクショ
ンが完了していた場合に、そのトランザクションの更新
が行われた後に存在した状態に資源を戻すために読み取
られる。しかし、「遷移ロギング」を使用することも既
知である。この場合、資源更新ごとに1つのログ項目(前
の状態及び後の状態の間の相違)だけが必要である。す
べての資源を回復可能にする必要はなく、従って資源を
「持続性」(不揮発性)又は「非持続性」(揮発性)のいず
れかとして定義できることが既知である。
トランザクション障害からの回復に必要な情報を提供す
るために回復可能データに対して行われるすべての処置
が通常は回復ログに記録される。このログは可変長レコ
ードのための持続性(不揮発性)記憶域であり、書込みは
その末尾でのみ可能であるが、読取りはどのような順序
でも可能である。通常資源更新動作ごとにUNDO(非実行)
ログ・レコード及びREDO(再実行)ログ・レコードが書き
込まれるが、前者は資源の前の状態を示し、後者は資源
の新しい状態を示す。障害の場合、作業の単位の進行状
態によってどのレコードを回復に使用するかが決定され
る。UNDOログ・レコードは障害の時点でトランザクショ
ンが未完了であった場合に、トランザクション開始の前
に存在した状態にシステム資源を復元できるようにする
ために読み取られるが、REDOレコードはトランザクショ
ンが完了していた場合に、そのトランザクションの更新
が行われた後に存在した状態に資源を戻すために読み取
られる。しかし、「遷移ロギング」を使用することも既
知である。この場合、資源更新ごとに1つのログ項目(前
の状態及び後の状態の間の相違)だけが必要である。す
べての資源を回復可能にする必要はなく、従って資源を
「持続性」(不揮発性)又は「非持続性」(揮発性)のいず
れかとして定義できることが既知である。
【００２３】既知のシステムの多くでは、トランザクシ
ョンの成功裡の完了時にもログ・レコードを読み取って
そのトランザクション内でどの動作が実行されたかを判
定し、従って現在どの資源更新を永続的として確認でき
るかを判定する。資源を更新するアプリケーションはCO
MMIT(コミット)動作を実行して成功裡に完了したトラン
ザクション内のすべての更新を確認する。
ョンの成功裡の完了時にもログ・レコードを読み取って
そのトランザクション内でどの動作が実行されたかを判
定し、従って現在どの資源更新を永続的として確認でき
るかを判定する。資源を更新するアプリケーションはCO
MMIT(コミット)動作を実行して成功裡に完了したトラン
ザクション内のすべての更新を確認する。
【００２４】資源(例えばデータベース)の内容が媒体障
害のために失われた場合、その資源が作成されて以来の
すべてのREDOログ・レコードがセーブされており、使用
可能であるならば、その資源を再作成できるはずであ
る。しかし、障害の後のシステム再始動時に読み取り、
処理しなければならないログ情報の量を制限する(従っ
てコストを削減し、回復の速度を向上させる)ために、
資源の不揮発性のコピーを周期的に(一定の時間間隔で
又は所定の量のシステム活動の後に)作成しセーブする
ことができ、そのコピーを作成する時点でのログ位置を
記録することができる。これをチェックポイントをとる
と称する。その後、障害が発生した場合、記録された位
置から回復ログを処理するが、この時最も最近のコピー
の時点の資源の状態が資源を回復するための初期設定情
報として役立つ。その資源に対する後続のすべての処置
を表すそのポイントからのREDOレコードを資源のセーブ
されたコピーに対して再処理する。
害のために失われた場合、その資源が作成されて以来の
すべてのREDOログ・レコードがセーブされており、使用
可能であるならば、その資源を再作成できるはずであ
る。しかし、障害の後のシステム再始動時に読み取り、
処理しなければならないログ情報の量を制限する(従っ
てコストを削減し、回復の速度を向上させる)ために、
資源の不揮発性のコピーを周期的に(一定の時間間隔で
又は所定の量のシステム活動の後に)作成しセーブする
ことができ、そのコピーを作成する時点でのログ位置を
記録することができる。これをチェックポイントをとる
と称する。その後、障害が発生した場合、記録された位
置から回復ログを処理するが、この時最も最近のコピー
の時点の資源の状態が資源を回復するための初期設定情
報として役立つ。その資源に対する後続のすべての処置
を表すそのポイントからのREDOレコードを資源のセーブ
されたコピーに対して再処理する。
【００２５】ロギングのオーバーヘッドを減らすための
方法がC.Mohan他著"ARIES: A Transaction Recovery Me
thod Supporting Fine Granularity Locking and Parti
al Rollbacks Using Write-Ahead Logging", IBM Resea
rch Report RJ6649 (Computer Science),1989年1月19日
に記載されている。ARIES回復方法では、ログを使用し
て資源に対して行われる変更を記録する。トランザクシ
ョンの順方向処理の間に行われる更新活動のロギングの
他に通常処理及び再始動処理の両方の間のトランザクシ
ョンの全体的又は部分的なロールバックの間に実行され
る資源変更についてもログを書き込む。トランザクショ
ン内の中間チェックポイントへの部分的なロールバック
がサポートされる。
方法がC.Mohan他著"ARIES: A Transaction Recovery Me
thod Supporting Fine Granularity Locking and Parti
al Rollbacks Using Write-Ahead Logging", IBM Resea
rch Report RJ6649 (Computer Science),1989年1月19日
に記載されている。ARIES回復方法では、ログを使用し
て資源に対して行われる変更を記録する。トランザクシ
ョンの順方向処理の間に行われる更新活動のロギングの
他に通常処理及び再始動処理の両方の間のトランザクシ
ョンの全体的又は部分的なロールバックの間に実行され
る資源変更についてもログを書き込む。トランザクショ
ン内の中間チェックポイントへの部分的なロールバック
がサポートされる。
【００２６】ある動作のバックアウトに関して書き込ま
れるログ・レコードを補償ログ・レコード(Compensatin
g Log Records、CLR)と称する。ARIESでは、各CLRに補
償処置の記述の他にそのCLRが補償するログ・レコード
の前のそのトランザクションのログ・レコードを指すポ
インタが含まれる。このポインタを用いると、それまで
に取り消されていないトランザクションがどれだけある
かを正確に判定できる。CLRはUNDOの間にどの処置を使
用可能であるかを記述するのに使用できるので、UNDO処
置は補償されつつある処置を正確に逆転したものである
必要はない(即ち論理的なUNDOが可能である)。
れるログ・レコードを補償ログ・レコード(Compensatin
g Log Records、CLR)と称する。ARIESでは、各CLRに補
償処置の記述の他にそのCLRが補償するログ・レコード
の前のそのトランザクションのログ・レコードを指すポ
インタが含まれる。このポインタを用いると、それまで
に取り消されていないトランザクションがどれだけある
かを正確に判定できる。CLRはUNDOの間にどの処置を使
用可能であるかを記述するのに使用できるので、UNDO処
置は補償されつつある処置を正確に逆転したものである
必要はない(即ち論理的なUNDOが可能である)。
【００２７】トランザクションの異常終了の後(例えば
システム障害の後)の再始動の間に最後の完了したチェ
ックポイントの最初のレコードから始めてログの末尾ま
でログを走査する。この最初の「分析」パスの間にデー
タ資源の永続版に含まれるものより新しい可能性のある
緩衝記憶域内のページ及び中断の時点で進行中であった
トランザクションに関する情報を集める。その後、中断
の前に不揮発性記憶域に書き込まれなかった更新をクラ
ッシュの時点で進行中であったトランザクションを含む
すべてのトランザクションについて繰り返す。
システム障害の後)の再始動の間に最後の完了したチェ
ックポイントの最初のレコードから始めてログの末尾ま
でログを走査する。この最初の「分析」パスの間にデー
タ資源の永続版に含まれるものより新しい可能性のある
緩衝記憶域内のページ及び中断の時点で進行中であった
トランザクションに関する情報を集める。その後、中断
の前に不揮発性記憶域に書き込まれなかった更新をクラ
ッシュの時点で進行中であったトランザクションを含む
すべてのトランザクションについて繰り返す。
【００２８】これによって、クラッシュの時点でのログ
に表現された処置に関する限りクラッシュの時点の資源
の状態が基本的に再確立される。このREDOパスの間に再
実行される更新についてはロギングは行われない。
に表現された処置に関する限りクラッシュの時点の資源
の状態が基本的に再確立される。このREDOパスの間に再
実行される更新についてはロギングは行われない。
【００２９】次のパスはUNDOパスであり、このパスの間
に進行中のすべてのトランザクションの更新がログの単
一の掃引によって時間的に逆の順序でロールバックされ
る。クラッシュの時点で既にロールバック中であったト
ランザクションについては取り消されていなかった処置
だけをロールバックする。これはCLRに記録された処置
が絶対に取り消されない(即ちCLRは補償されない)こと
を意味する。これが可能であるのはそのようなトランザ
クションが再実行されるからであり、各トランザクショ
ンについて書き込まれた最後のCLRが取り消す必要のあ
る次の非CLRレコードを指しているからである。
に進行中のすべてのトランザクションの更新がログの単
一の掃引によって時間的に逆の順序でロールバックされ
る。クラッシュの時点で既にロールバック中であったト
ランザクションについては取り消されていなかった処置
だけをロールバックする。これはCLRに記録された処置
が絶対に取り消されない(即ちCLRは補償されない)こと
を意味する。これが可能であるのはそのようなトランザ
クションが再実行されるからであり、各トランザクショ
ンについて書き込まれた最後のCLRが取り消す必要のあ
る次の非CLRレコードを指しているからである。
【００３０】ARIESでは、この処理のいずれの間にも修
正されたページを不揮発性記憶域に置く必要がない。ま
た回復の間にチェックポイントをとることも可能であ
る。トランザクション・ロールバックの間にロックを取
得する必要はなく、従ってロールバックしつつあるトラ
ンザクションはデッドロックに巻き込まれないようにな
っている。
正されたページを不揮発性記憶域に置く必要がない。ま
た回復の間にチェックポイントをとることも可能であ
る。トランザクション・ロールバックの間にロックを取
得する必要はなく、従ってロールバックしつつあるトラ
ンザクションはデッドロックに巻き込まれないようにな
っている。
【００３１】一部のオペレーティング・システムでは、
アプリケーションにオペレーティング・システム特権が
与えられない。そのような場合には、ログ・レコードの
選択的走査及びおそらくはディスクへのログの書込みが
トランザクション処理の比較的非効率的な側面となり、
従ってロギング及びログからの読み取りに既知の方法を
用いてデータ一貫性をサポートする場合には、BACKOUT
動作が非効率的になる。同じことが既知のシステムの一
部のCOMMIT動作にもあてはまるが、そうでない既知のシ
ステムではCOMMITがトランザクションの解決の時点で発
生すると仮定して処理が実行され(Mohan, Lindsay, Obe
rmarck著"Transaction Management in the R* Distribu
ted Database Management System", ACM Transactions
on Database Systems", Vol. 11, No. 4, 1986年12月を
参照されたい)、その場合、COMMIT処理のためにログ・
レコードを走査する必要はなく障害の後のBACKOUTとい
う例外的な場合についてのみログ・レコードを走査する
必要がある。
アプリケーションにオペレーティング・システム特権が
与えられない。そのような場合には、ログ・レコードの
選択的走査及びおそらくはディスクへのログの書込みが
トランザクション処理の比較的非効率的な側面となり、
従ってロギング及びログからの読み取りに既知の方法を
用いてデータ一貫性をサポートする場合には、BACKOUT
動作が非効率的になる。同じことが既知のシステムの一
部のCOMMIT動作にもあてはまるが、そうでない既知のシ
ステムではCOMMITがトランザクションの解決の時点で発
生すると仮定して処理が実行され(Mohan, Lindsay, Obe
rmarck著"Transaction Management in the R* Distribu
ted Database Management System", ACM Transactions
on Database Systems", Vol. 11, No. 4, 1986年12月を
参照されたい)、その場合、COMMIT処理のためにログ・
レコードを走査する必要はなく障害の後のBACKOUTとい
う例外的な場合についてのみログ・レコードを走査する
必要がある。
【００３２】
【発明が解決しようとする課題】特定のオペレーティン
グ・システムのために効率的なフォールト・トレラント
・データ処理をサポートしなければならない場合にその
オペレーティング・システムの非効率的なログ走査とい
う制約の被害を受けない回復機能を提供する必要がます
ます高まっている。
グ・システムのために効率的なフォールト・トレラント
・データ処理をサポートしなければならない場合にその
オペレーティング・システムの非効率的なログ走査とい
う制約の被害を受けない回復機能を提供する必要がます
ます高まっている。
【００３３】
【課題を解決するための手段】従って本発明は、高速の
揮発性記憶域及び低速の不揮発性記憶域を有し、トラン
ザクションをロールバックするか又はシステムを再始動
する必要がある場合に回復を可能にするためにシステム
動作に関連するレコードがシステム内に記憶されている
トランザクション処理システムにおいて、前記システム
動作を持続性又は非持続性として及びトランザクション
性又は非トランザクション性として定義する手段と、持
続性であると定義されたすべてのシステム動作に関連し
かつシステムの再始動に必要な完全な情報を含むレコー
ドを前記不揮発性記憶域に回復ログとして記憶し、トラ
ンザクション性であると定義されたすべてのシステム動
作に関連しかつデータを含まずデータを見つけだすため
の命令のみを含むレコードを、持続性動作か非持続性動
作かを問わず、前記揮発性記憶域に回復リストとして記
憶する手段と、個々のトランザクションのロールバック
を前記回復リストの参照によって行う手段と、システム
の再始動を前記回復ログの参照によって行う手段と、を
具備することを特徴とするトランザクション処理システ
ムを提供する。
揮発性記憶域及び低速の不揮発性記憶域を有し、トラン
ザクションをロールバックするか又はシステムを再始動
する必要がある場合に回復を可能にするためにシステム
動作に関連するレコードがシステム内に記憶されている
トランザクション処理システムにおいて、前記システム
動作を持続性又は非持続性として及びトランザクション
性又は非トランザクション性として定義する手段と、持
続性であると定義されたすべてのシステム動作に関連し
かつシステムの再始動に必要な完全な情報を含むレコー
ドを前記不揮発性記憶域に回復ログとして記憶し、トラ
ンザクション性であると定義されたすべてのシステム動
作に関連しかつデータを含まずデータを見つけだすため
の命令のみを含むレコードを、持続性動作か非持続性動
作かを問わず、前記揮発性記憶域に回復リストとして記
憶する手段と、個々のトランザクションのロールバック
を前記回復リストの参照によって行う手段と、システム
の再始動を前記回復ログの参照によって行う手段と、を
具備することを特徴とするトランザクション処理システ
ムを提供する。
【００３４】本発明はまた、高速の揮発性記憶域及び低
速の不揮発性記憶域を有し、トランザクションをロール
バックするか又はシステムを再始動する必要がある場合
に回復を可能にするためにシステム動作に関連するレコ
ードがシステム内に記憶されているトランザクション処
理システムでフォールト・トレラント・トランザクショ
ン処理を行う方法において、システム動作を持続性又は
非持続性として及びトランザクション性又は非トランザ
クション性として定義するステップと、持続性として定
義されたすべてのシステム動作に関連しかつシステムの
再始動に必要な完全な情報を含むレコードを前記不揮発
性記憶域に回復ログとして記憶し、トランザクション性
として定義されたすべてにシステム動作に関連しかつデ
ータを含まずデータを見つけだすための命令のみを含む
レコードを、持続性であるか非持続性であるかを問わ
ず、前記揮発性記憶域に回復リストとして記憶するステ
ップと、前記回復リストを参照して個々のトランザクシ
ョンのロールバックを行うステップと、前記回復ログを
参照してシステムの再始動を行うステップと、を含むこ
とを特徴とする方法を提供する。
速の不揮発性記憶域を有し、トランザクションをロール
バックするか又はシステムを再始動する必要がある場合
に回復を可能にするためにシステム動作に関連するレコ
ードがシステム内に記憶されているトランザクション処
理システムでフォールト・トレラント・トランザクショ
ン処理を行う方法において、システム動作を持続性又は
非持続性として及びトランザクション性又は非トランザ
クション性として定義するステップと、持続性として定
義されたすべてのシステム動作に関連しかつシステムの
再始動に必要な完全な情報を含むレコードを前記不揮発
性記憶域に回復ログとして記憶し、トランザクション性
として定義されたすべてにシステム動作に関連しかつデ
ータを含まずデータを見つけだすための命令のみを含む
レコードを、持続性であるか非持続性であるかを問わ
ず、前記揮発性記憶域に回復リストとして記憶するステ
ップと、前記回復リストを参照して個々のトランザクシ
ョンのロールバックを行うステップと、前記回復ログを
参照してシステムの再始動を行うステップと、を含むこ
とを特徴とする方法を提供する。
【００３５】揮発性メモリ・リストはトランザクション
障害が発生した時にトランザクションをバックアウトす
るのに必要なすべての情報を提供し、その結果そのよう
なバックアウトを実行するためにログ・レコードを読み
取る必要がなくなる。提供される回復機能は揮発性メモ
リ・リストの他にログ・レコードを含むことが好まし
く、その場合本発明によれば通常処理の間はログ・レコ
ードを書込み専用レコードにし、ログはシステム障害の
後の再始動処理のためにのみ読み取られるようにするこ
とによってログ・レコードの使用が最適化される。揮発
メモリ・リストはログ・レコードの完全なコピーである
必要はなく、通常の順方向処理及びバックアウト処理の
実行の際に、即ちトランザクション障害に応答したロー
ルバック動作の実行及び好ましくはコミット動作(又は
コミットの確認。下を参照されたい)の実行のためにそ
こになければログからアクセスする必要があるはずの情
報を保持するだけでよい。
障害が発生した時にトランザクションをバックアウトす
るのに必要なすべての情報を提供し、その結果そのよう
なバックアウトを実行するためにログ・レコードを読み
取る必要がなくなる。提供される回復機能は揮発性メモ
リ・リストの他にログ・レコードを含むことが好まし
く、その場合本発明によれば通常処理の間はログ・レコ
ードを書込み専用レコードにし、ログはシステム障害の
後の再始動処理のためにのみ読み取られるようにするこ
とによってログ・レコードの使用が最適化される。揮発
メモリ・リストはログ・レコードの完全なコピーである
必要はなく、通常の順方向処理及びバックアウト処理の
実行の際に、即ちトランザクション障害に応答したロー
ルバック動作の実行及び好ましくはコミット動作(又は
コミットの確認。下を参照されたい)の実行のためにそ
こになければログからアクセスする必要があるはずの情
報を保持するだけでよい。
【００３６】従ってこの両方の機能が設けられるシステ
ムでは不揮発性メモリ・リストはログ・レコードの部分
的な複製であることが好ましいが、これら2つの間には
区別がある。即ち揮発性メモリ・リストはデータを含ま
ずデータを見つけだす方法に関する命令(ログ・レコー
ドの識別及びおそらくは動作をUNDOする方法に関する情
報などの追加情報)のみを含む。これに対してログ・レ
コードは更新される資源を完全に再構成するのに必要な
完全な情報を含む。回復可能資源を更新しない動作(従
ってログ・レコードを書き込む必要のない動作)を含め
て1トランザクション内で実行される動作ごとに揮発性
メモリ・リストに1項目を追加することが好ましい。ト
ランザクション内の動作のすべてを参照できる単一のリ
ストを設けることで処理の他の態様が単純になる。
ムでは不揮発性メモリ・リストはログ・レコードの部分
的な複製であることが好ましいが、これら2つの間には
区別がある。即ち揮発性メモリ・リストはデータを含ま
ずデータを見つけだす方法に関する命令(ログ・レコー
ドの識別及びおそらくは動作をUNDOする方法に関する情
報などの追加情報)のみを含む。これに対してログ・レ
コードは更新される資源を完全に再構成するのに必要な
完全な情報を含む。回復可能資源を更新しない動作(従
ってログ・レコードを書き込む必要のない動作)を含め
て1トランザクション内で実行される動作ごとに揮発性
メモリ・リストに1項目を追加することが好ましい。ト
ランザクション内の動作のすべてを参照できる単一のリ
ストを設けることで処理の他の態様が単純になる。
【００３７】トランザクションのコミットは正常処理を
前提とすることが好ましく、従ってトランザクションが
成功裡に完了する際の更新のコミットには仮定されたコ
ミットの確認が含まれる。
前提とすることが好ましく、従ってトランザクションが
成功裡に完了する際の更新のコミットには仮定されたコ
ミットの確認が含まれる。
【００３８】ある動作に関して書き込まれる1つ又は複
数のログ・レコードにその動作のUNDOのための情報を追
加的に含めることができるがあるタイプのUNDOはその動
作自体から暗示することができ、従って特定のログ・レ
コードを書き込む必要はない。1つのログ・レコードが
複数の動作を組み合わせた影響を表現でき、従って複数
のREDO及びオプションとしてUNDOのための情報を提供で
きる。
数のログ・レコードにその動作のUNDOのための情報を追
加的に含めることができるがあるタイプのUNDOはその動
作自体から暗示することができ、従って特定のログ・レ
コードを書き込む必要はない。1つのログ・レコードが
複数の動作を組み合わせた影響を表現でき、従って複数
のREDO及びオプションとしてUNDOのための情報を提供で
きる。
【００３９】本発明の動作の揮発性メモリ・リストは当
初にログ・レコードを仮想記憶域に書き込んだ後にログ
をディスクに書き込むという従来技術の方法と比較して
従来技術の方法ではトランザクションの状態とは無関係
に周期的に又は仮想記憶域の情報が所定のサイズに達し
た時のいずれかにログをディスクに書き込むという点で
区別される。本発明の揮発性メモリ・リストはまだコミ
ットされていないトランザクションごとのそれまでに実
行されたトランザクションの全体の記録である。既知の
システムによるディスクへのログ・レコードの書き込み
はその周期に関してはオペレーティング・システム依存
であるが、これに対して本発明はトランザクションに関
する更新の完全な1組の別々のリストである。
初にログ・レコードを仮想記憶域に書き込んだ後にログ
をディスクに書き込むという従来技術の方法と比較して
従来技術の方法ではトランザクションの状態とは無関係
に周期的に又は仮想記憶域の情報が所定のサイズに達し
た時のいずれかにログをディスクに書き込むという点で
区別される。本発明の揮発性メモリ・リストはまだコミ
ットされていないトランザクションごとのそれまでに実
行されたトランザクションの全体の記録である。既知の
システムによるディスクへのログ・レコードの書き込み
はその周期に関してはオペレーティング・システム依存
であるが、これに対して本発明はトランザクションに関
する更新の完全な1組の別々のリストである。
【００４０】バックアウトの間に個々の動作のバックア
ウトのロギングが通常通りに実行される。従って、バッ
クアウト中に書き込まれたログ・レコードはバックアウ
トしなければならない動作に関する情報を提供するため
にログを読み取る場合に従来のバックアウト処理によっ
て書き込まれたのと全く同様になる。これによる利益は
回復の効率が全般的に改良されることに加えて元々コミ
ット動作又はバックアウト動作を実行していた制御のス
レッドがユーザによって停止された場合に、その動作を
継続できることである。コミット処理又はバックアウト
処理は例えば実行のインスタンスを停止させることによ
って中断でき、別の実行のインスタンスによって後で再
開できる。というのは、揮発性メモリ・リストがすべて
のアプリケーションから使用可能だからである。制御の
スレッドが失われた時の回復の継続を提供できる既知の
システムには通常のコミット又はロールバックが実際に
は実行されず、「架空の(pretend)」コミット又はロー
ルバックが実施される障害後の起動がある。制御のスレ
ッドが停止された時に通常の実行を継続する能力がある
と、より堅牢な回復がもたらされ既知の方法より高い使
用可能性がもたらされる。
ウトのロギングが通常通りに実行される。従って、バッ
クアウト中に書き込まれたログ・レコードはバックアウ
トしなければならない動作に関する情報を提供するため
にログを読み取る場合に従来のバックアウト処理によっ
て書き込まれたのと全く同様になる。これによる利益は
回復の効率が全般的に改良されることに加えて元々コミ
ット動作又はバックアウト動作を実行していた制御のス
レッドがユーザによって停止された場合に、その動作を
継続できることである。コミット処理又はバックアウト
処理は例えば実行のインスタンスを停止させることによ
って中断でき、別の実行のインスタンスによって後で再
開できる。というのは、揮発性メモリ・リストがすべて
のアプリケーションから使用可能だからである。制御の
スレッドが失われた時の回復の継続を提供できる既知の
システムには通常のコミット又はロールバックが実際に
は実行されず、「架空の(pretend)」コミット又はロー
ルバックが実施される障害後の起動がある。制御のスレ
ッドが停止された時に通常の実行を継続する能力がある
と、より堅牢な回復がもたらされ既知の方法より高い使
用可能性がもたらされる。
【００４１】非持続性資源に対する操作はロギングされ
ない。というのは、障害の後の再始動の間にすべて削除
される資源に対する動作を固める必要がないからであ
る。
ない。というのは、障害の後の再始動の間にすべて削除
される資源に対する動作を固める必要がないからであ
る。
【００４２】複数の同時に走行するトランザクションが
単一のデータ資源管理プログラムの制御下にある異なる
レコードを更新する場合がしばしばある。このデータ資
源管理プログラムは資源を共用するための効率的な手段
をサポートしなければならず、それと同時に2つのトラ
ンザクションが同一のレコードを同時にアクセスしない
ようにしなければならない。このような並行性制御を達
成するのに最も一般的に使用される方法がロックであ
り、この場合所与の資源(例えばメッセージやファイル
内のレコード)が一時に1つのトランザクション・インス
タンスに予約される。COMMIT期間ロック(即ちトランザ
クションがコミットされるまで残存するロック)を資源
更新の前にその資源に対して獲得する。他のトランザク
ションは作業の単位が完了するまでこのロックされた資
源をアクセスできない。COMMIT期間ロックはすべて一般
にCOMMIT動作又はBACKOUT動作の最終ステップとして作
業の単位の終了時に解放される。
単一のデータ資源管理プログラムの制御下にある異なる
レコードを更新する場合がしばしばある。このデータ資
源管理プログラムは資源を共用するための効率的な手段
をサポートしなければならず、それと同時に2つのトラ
ンザクションが同一のレコードを同時にアクセスしない
ようにしなければならない。このような並行性制御を達
成するのに最も一般的に使用される方法がロックであ
り、この場合所与の資源(例えばメッセージやファイル
内のレコード)が一時に1つのトランザクション・インス
タンスに予約される。COMMIT期間ロック(即ちトランザ
クションがコミットされるまで残存するロック)を資源
更新の前にその資源に対して獲得する。他のトランザク
ションは作業の単位が完了するまでこのロックされた資
源をアクセスできない。COMMIT期間ロックはすべて一般
にCOMMIT動作又はBACKOUT動作の最終ステップとして作
業の単位の終了時に解放される。
【００４３】トランザクションの解決までオブジェクト
をロックする既知の方法には、ロックの取得に大きなオ
ーバーヘッドが伴う可能性があるという点に問題があ
る。これは微細ロック粒度を使用する場合(例えばロッ
クされるオブジェクトがレコードを含むファイルやファ
イルがその一部であるデータベースではなく、個々のレ
コードである場合)に特に重要である。一部のオペレー
ティング・システムは又はロックのための良好なサポー
トを提供せず、その結果ロックの取得が低速であるか又
はロックの維持にかなりのアプリケーション制御が必要
になっている。また一部のオペレーティング・システム
は相互排他(mutex)ロックを提供せず、その結果どの時
点でも一つのプロセスしかロックされた資源をアクセス
できなくなっている。
をロックする既知の方法には、ロックの取得に大きなオ
ーバーヘッドが伴う可能性があるという点に問題があ
る。これは微細ロック粒度を使用する場合(例えばロッ
クされるオブジェクトがレコードを含むファイルやファ
イルがその一部であるデータベースではなく、個々のレ
コードである場合)に特に重要である。一部のオペレー
ティング・システムは又はロックのための良好なサポー
トを提供せず、その結果ロックの取得が低速であるか又
はロックの維持にかなりのアプリケーション制御が必要
になっている。また一部のオペレーティング・システム
は相互排他(mutex)ロックを提供せず、その結果どの時
点でも一つのプロセスしかロックされた資源をアクセス
できなくなっている。
【００４４】並行トランザクション処理を備えることが
システム応答及びシステム利用の改良に望ましく、共用
ロックもサポートするシステム(個々のプロセスが排他
的ロック自体を取得するのではなく、他のプロセスが排
他的ロックを取得できなくするロックを取得するシステ
ム)と比較して相互排他ロックだけがサポートされる場
合は、明らかに並行性が低下する。しかし、資源アクセ
スの並列性を設けること及び並行性制御手順のオーバー
ヘッド(ロックを維持するコスト)の間にトレードオフが
存在する。相互排他ロックは共用ロックと比較して取得
が高速であり、異なるオペレーティング・システムの間
で広範囲にサポートされている。
システム応答及びシステム利用の改良に望ましく、共用
ロックもサポートするシステム(個々のプロセスが排他
的ロック自体を取得するのではなく、他のプロセスが排
他的ロックを取得できなくするロックを取得するシステ
ム)と比較して相互排他ロックだけがサポートされる場
合は、明らかに並行性が低下する。しかし、資源アクセ
スの並列性を設けること及び並行性制御手順のオーバー
ヘッド(ロックを維持するコスト)の間にトレードオフが
存在する。相互排他ロックは共用ロックと比較して取得
が高速であり、異なるオペレーティング・システムの間
で広範囲にサポートされている。
【００４５】本発明の第2の態様では、トランザクショ
ン内のプロセスによって実行される資源更新がトランザ
クションの解決の前に且つ障害発生の後にアトミック的
にバックアウトされるか又はトランザクションの成功裡
の完了時にコミットされるフォールト・トレラント・ト
ランザクション指向データ処理の方法において、トラン
ザクション内で実行される資源更新動作ごとに更新され
る資源に関する相互排他セマフォ・ロックを取得するス
テップと、動作要求に応答してトランザクション内で更
新動作を実行するステップと、動作がトランザクション
内で実行されたことを示す標識をセットすることによっ
て動作要求を前記プロセスに対してアクセス不能にする
ステップと、相互排他セマフォ・ロックを解放するステ
ップと、トランザクションの成功裡の完了時に標識がセ
ットされているトランザクション内のすべての動作をコ
ミットするステップと、トランザクションの解決の前の
障害発生に応答して標識がセットされているトランザク
ション内のすべての動作をバックアウトするステップ
と、を含むことを特徴とする方法が提供される。
ン内のプロセスによって実行される資源更新がトランザ
クションの解決の前に且つ障害発生の後にアトミック的
にバックアウトされるか又はトランザクションの成功裡
の完了時にコミットされるフォールト・トレラント・ト
ランザクション指向データ処理の方法において、トラン
ザクション内で実行される資源更新動作ごとに更新され
る資源に関する相互排他セマフォ・ロックを取得するス
テップと、動作要求に応答してトランザクション内で更
新動作を実行するステップと、動作がトランザクション
内で実行されたことを示す標識をセットすることによっ
て動作要求を前記プロセスに対してアクセス不能にする
ステップと、相互排他セマフォ・ロックを解放するステ
ップと、トランザクションの成功裡の完了時に標識がセ
ットされているトランザクション内のすべての動作をコ
ミットするステップと、トランザクションの解決の前の
障害発生に応答して標識がセットされているトランザク
ション内のすべての動作をバックアウトするステップ
と、を含むことを特徴とする方法が提供される。
【００４６】相互排他セマフォ・ロックを一時に1プロ
セスによって資源に対して獲得して、そうでなければそ
の資源を同時にアクセスする可能性のあるプロセスが互
いに干渉しないようにする。これはトランザクションの
解決まで資源更新が永続的にされない場合にデータ保全
性を保護するために重要である。相互排他ロックは異な
るプラットホームの間で広範囲にサポートされ、従って
本発明によって提供される機能は異なるプラットホーム
間(例えばREFERENCE、OS/2、OS/400)で移植可能であ
る。
セスによって資源に対して獲得して、そうでなければそ
の資源を同時にアクセスする可能性のあるプロセスが互
いに干渉しないようにする。これはトランザクションの
解決まで資源更新が永続的にされない場合にデータ保全
性を保護するために重要である。相互排他ロックは異な
るプラットホームの間で広範囲にサポートされ、従って
本発明によって提供される機能は異なるプラットホーム
間(例えばREFERENCE、OS/2、OS/400)で移植可能であ
る。
【００４７】1トランザクション内で資源を更新する動
作は標識をセットさせて、それらがトランザクションの
一部として実行されたことを示すことが好ましい。この
標識は動作要求上のフラグ(待ち行列上のメッセージに
フラグを立てるなど)の形にすることができる。この標
識は動作に対して保持されるロックとして現れる。従っ
て標識がセットされている動作はトランザクションの解
決まで論理的にロックされ、この論理ロックは古典的な
ロック管理プログラムのオーバーヘッドなしに物理的な
ロックと同一の目的(即ち他のプロセスが特定の動作を
実行しないようにすること)を達成する。本発明のこの
ような実施態様ではある資源の更新のコミットにフラッ
グの解放だけが必要である。
作は標識をセットさせて、それらがトランザクションの
一部として実行されたことを示すことが好ましい。この
標識は動作要求上のフラグ(待ち行列上のメッセージに
フラグを立てるなど)の形にすることができる。この標
識は動作に対して保持されるロックとして現れる。従っ
て標識がセットされている動作はトランザクションの解
決まで論理的にロックされ、この論理ロックは古典的な
ロック管理プログラムのオーバーヘッドなしに物理的な
ロックと同一の目的(即ち他のプロセスが特定の動作を
実行しないようにすること)を達成する。本発明のこの
ような実施態様ではある資源の更新のコミットにフラッ
グの解放だけが必要である。
【００４８】フラグからどの動作が論理的にロックされ
ているかが明白なので、本発明によれば従来技術の方法
に見られるアプリケーションが既にロックされているオ
ブジェクトに対するロックを取得しようとした後にその
オブジェクトが使用不能であることを発見するという情
況が回避される。バックアウト処理及び好ましくはコミ
ット処理は揮発性メモリ・リストの走査及び項目のそれ
ぞれのそれ相応の処理を含む。これによってログ・レコ
ードの読み取りがうまくサポートされていないオペレー
ティング・システムでのかなりの効率改善が示される。
ているかが明白なので、本発明によれば従来技術の方法
に見られるアプリケーションが既にロックされているオ
ブジェクトに対するロックを取得しようとした後にその
オブジェクトが使用不能であることを発見するという情
況が回避される。バックアウト処理及び好ましくはコミ
ット処理は揮発性メモリ・リストの走査及び項目のそれ
ぞれのそれ相応の処理を含む。これによってログ・レコ
ードの読み取りがうまくサポートされていないオペレー
ティング・システムでのかなりの効率改善が示される。
【００４９】本発明の第2の態様による方法は回復可能
資源を更新するトランザクション内の動作のそれぞれに
ついて少なくとも1つのログ・レコードを書き込むステ
ップを含み、前記少なくとも1つのログ・レコードがそ
の動作のREDOに十分な情報を含むことが好ましい。動作
のUNDOのために別のログ・レコードがあってもよく、ま
た特定の動作のREDO及びUNDOの両方に使用できる単一の
動作ログ・レコードがあってもよい。各ログ・レコード
は複数の動作の組合せた結果を表すことができる。
資源を更新するトランザクション内の動作のそれぞれに
ついて少なくとも1つのログ・レコードを書き込むステ
ップを含み、前記少なくとも1つのログ・レコードがそ
の動作のREDOに十分な情報を含むことが好ましい。動作
のUNDOのために別のログ・レコードがあってもよく、ま
た特定の動作のREDO及びUNDOの両方に使用できる単一の
動作ログ・レコードがあってもよい。各ログ・レコード
は複数の動作の組合せた結果を表すことができる。
【００５０】
【実施例】これから説明する本発明の1実施態様はトラ
ンザクションが成功裡に完了できない場合に資源更新の
BACKOUTを行う能力を提供するメッセージ待合せのシス
テム及び方法である。メッセージ待合せを用いると、プ
ログラムがプログラム間の直接接続なしでアプリケーシ
ョン固有のデータを送受できるようになる。1つ又は複
数のアプリケーション・プログラムにとって意味のある
ビット又はバイトの列であるメッセージは記憶域内の待
ち行列に置かれ、その結果目標アプリケーションは目標
アプリケーションが選択した時(送出元のアプリケーシ
ョンが選択した時ではなく)にメッセージ待ち行列から
これらのメッセージを取り、処理できるようになる。こ
の場合、プログラムは互いに独立に異なる速度で異なる
時間に走行できる。送出元プログラムはメッセージを送
る前にトランザクションが成功裡に完了するかどうかを
チェックする必要がなく、目標アプリケーションは同様
に事前にチェックを行わずに入力待ち行列からメッセー
ジを取ることができるので、逆方向回復機能がしばしば
必要になる。送出元アプリケーションは一般にメッセー
ジを送った後にそのメッセージの処理の結果を待たずに
次の処理タスクに進むことができる。
ンザクションが成功裡に完了できない場合に資源更新の
BACKOUTを行う能力を提供するメッセージ待合せのシス
テム及び方法である。メッセージ待合せを用いると、プ
ログラムがプログラム間の直接接続なしでアプリケーシ
ョン固有のデータを送受できるようになる。1つ又は複
数のアプリケーション・プログラムにとって意味のある
ビット又はバイトの列であるメッセージは記憶域内の待
ち行列に置かれ、その結果目標アプリケーションは目標
アプリケーションが選択した時(送出元のアプリケーシ
ョンが選択した時ではなく)にメッセージ待ち行列から
これらのメッセージを取り、処理できるようになる。こ
の場合、プログラムは互いに独立に異なる速度で異なる
時間に走行できる。送出元プログラムはメッセージを送
る前にトランザクションが成功裡に完了するかどうかを
チェックする必要がなく、目標アプリケーションは同様
に事前にチェックを行わずに入力待ち行列からメッセー
ジを取ることができるので、逆方向回復機能がしばしば
必要になる。送出元アプリケーションは一般にメッセー
ジを送った後にそのメッセージの処理の結果を待たずに
次の処理タスクに進むことができる。
【００５１】メッセージは持続性又は非持続性として定
義できる。前者は障害の発生の後に回復しなければなら
ないことを意味し、後者は回復の必要がないことを意味
する。
義できる。前者は障害の発生の後に回復しなければなら
ないことを意味し、後者は回復の必要がないことを意味
する。
【００５２】トランザクション内でのメッセージ待ち行
列に対する更新はGET(ゲット：待ち行列からメッセージ
を取得する)動作及びPUT(プット：待ち行列にメッセー
ジを置く)動作のシーケンスであり、これらの動作はト
ランザクションがコミットされる時(成功裡の完了時)に
アトミック的に発生するか又はトランザクションがロー
ルバックする時にアトミック的に取り消される。持続性
メッセージに関するこれらのGET及びPUTのそれぞれにつ
いてログ・レコードを書き込む。本発明のこの実施態様
によれば、トランザクション内で実行される各メッセー
ジ動作のレコードも揮発性記憶域のリストに追加され
る。動作はコミットされたかのように実行される(即ち
トランザクションの成功裡の完了、従ってそれに含まれ
るすべての動作のCOMMITが仮定される。というのは、こ
れがトランザクション解決時の通常動作だからである)
がその結果の資源更新はトランザクションの解決まで資
源をアクセスする他のアプリケーションからアクセス不
能になるようにマークされる。
列に対する更新はGET(ゲット：待ち行列からメッセージ
を取得する)動作及びPUT(プット：待ち行列にメッセー
ジを置く)動作のシーケンスであり、これらの動作はト
ランザクションがコミットされる時(成功裡の完了時)に
アトミック的に発生するか又はトランザクションがロー
ルバックする時にアトミック的に取り消される。持続性
メッセージに関するこれらのGET及びPUTのそれぞれにつ
いてログ・レコードを書き込む。本発明のこの実施態様
によれば、トランザクション内で実行される各メッセー
ジ動作のレコードも揮発性記憶域のリストに追加され
る。動作はコミットされたかのように実行される(即ち
トランザクションの成功裡の完了、従ってそれに含まれ
るすべての動作のCOMMITが仮定される。というのは、こ
れがトランザクション解決時の通常動作だからである)
がその結果の資源更新はトランザクションの解決まで資
源をアクセスする他のアプリケーションからアクセス不
能になるようにマークされる。
【００５３】このようなシステム内の回復可能なデータ
構造が待ち行列である。待ち行列を安定状態に戻せるよ
うにするために、待ち行列のコピーを定期的に作成す
る。作成される待ち行列のコピーの間で待ち行列上の持
続性メッセージに対して行われるすべての変更に関して
ログ・レコードを書き込む。
構造が待ち行列である。待ち行列を安定状態に戻せるよ
うにするために、待ち行列のコピーを定期的に作成す
る。作成される待ち行列のコピーの間で待ち行列上の持
続性メッセージに対して行われるすべての変更に関して
ログ・レコードを書き込む。
【００５４】図1は1対1通信の簡単な例でのそのような
トランザクション性メッセージ待合せシステムの2つの
通信するプログラムの間の通常処理の間のメッセージの
流れを示す図である。2つのプログラム10及び20は待ち
行列30及び40を介して互いにメッセージを送る。メッセ
ージ待ち行列とはメッセージがそこに蓄積され、後でそ
こから取り除かれる名前付きオブジェクトである。メッ
セージ待ち行列は単なるスタックではない。メッセージ
は追加時には末尾に追加され、通常は先頭から取り除か
れる(ただし待ち行列上のメッセージの順序と異なる順
序でメッセージを読み取るための機能が存在する)。各
待ち行列はそれぞれの待ち行列管理プログラム50及び60
(アプリケーションが使用するメッセージ待合せ機能を
提供するシステム・サービス)の管理制御の下にある
が、その管理の詳細はアプリケーション・プログラムに
は明らかにされない。メッセージ待合せサービスを使用
可能にするためには、システム上に少なくとも1つの待
ち行列管理プログラムが必要である。1つの待ち行列管
理プログラムが複数の待ち行列を所有できる。異なる待
ち行列管理プログラムのインスタンスはそれぞれその名
前によって区別され、この名前は相互接続された待ち行
列管理プログラムのネットワーク内で一義的であり、そ
の結果ある待ち行列管理プログラムが所与のメッセージ
を送らなければならない目標待ち行列管理プログラムを
明確に識別できなければならない。
トランザクション性メッセージ待合せシステムの2つの
通信するプログラムの間の通常処理の間のメッセージの
流れを示す図である。2つのプログラム10及び20は待ち
行列30及び40を介して互いにメッセージを送る。メッセ
ージ待ち行列とはメッセージがそこに蓄積され、後でそ
こから取り除かれる名前付きオブジェクトである。メッ
セージ待ち行列は単なるスタックではない。メッセージ
は追加時には末尾に追加され、通常は先頭から取り除か
れる(ただし待ち行列上のメッセージの順序と異なる順
序でメッセージを読み取るための機能が存在する)。各
待ち行列はそれぞれの待ち行列管理プログラム50及び60
(アプリケーションが使用するメッセージ待合せ機能を
提供するシステム・サービス)の管理制御の下にある
が、その管理の詳細はアプリケーション・プログラムに
は明らかにされない。メッセージ待合せサービスを使用
可能にするためには、システム上に少なくとも1つの待
ち行列管理プログラムが必要である。1つの待ち行列管
理プログラムが複数の待ち行列を所有できる。異なる待
ち行列管理プログラムのインスタンスはそれぞれその名
前によって区別され、この名前は相互接続された待ち行
列管理プログラムのネットワーク内で一義的であり、そ
の結果ある待ち行列管理プログラムが所与のメッセージ
を送らなければならない目標待ち行列管理プログラムを
明確に識別できなければならない。
【００５５】アプリケーションは特定の名前付きメッセ
ージ待ち行列を使用することに同意することによって通
信し、特定の目標プログラムがそこからの読み取りに同
意した特定の待ち行列にメッセージを送る。これらの待
ち行列の位置はメッセージを送るアプリケーションには
明らかでない。各アプリケーションはそのローカル待ち
行列管理プログラムとだけ相互作用するのであって、メ
ッセージを所期の待ち行列に移動する責任を負うのは相
互接続された待ち行列管理プログラムのネットワークで
ある。
ージ待ち行列を使用することに同意することによって通
信し、特定の目標プログラムがそこからの読み取りに同
意した特定の待ち行列にメッセージを送る。これらの待
ち行列の位置はメッセージを送るアプリケーションには
明らかでない。各アプリケーションはそのローカル待ち
行列管理プログラムとだけ相互作用するのであって、メ
ッセージを所期の待ち行列に移動する責任を負うのは相
互接続された待ち行列管理プログラムのネットワークで
ある。
【００５６】図1を参照すると、第1のプログラム10は第
2のプログラムの待ち行列30にメッセージをプットする
が、専用の論理接続をこれらのプログラムの間で確立す
る必要はない。このメッセージの流れを図1の矢印f1、f
2、f3及びf4によって表す。待ち行列管理プログラム50
及び60はメッセージがネットワーク間で移動されること
を保証してプログラム自体がネットワークの変動や複雑
さから遮蔽されるようにする。これを図1のネットワー
ク・リンク70によって表す。プログラム20は送出元のプ
ログラム10が選択した時ではなくプログラム20側で準備
ができた時に、待ち行列30からメッセージを取ってこれ
を処理する。メッセージの転送及び後続の処理によって
回復可能資源に対して行われる変更は後続の障害の場合
に使用するため不揮発性記憶域内の回復ログ80及び90に
記録される。これらのログはジャーナルと称する場合も
あるが、基礎となるオペレーティング・システムが提供
する機能であり、IBM社出版物"AS/400 Programming : B
ackup and Recovery Guide" (SC21-8079)に詳しく記載
されている。
2のプログラムの待ち行列30にメッセージをプットする
が、専用の論理接続をこれらのプログラムの間で確立す
る必要はない。このメッセージの流れを図1の矢印f1、f
2、f3及びf4によって表す。待ち行列管理プログラム50
及び60はメッセージがネットワーク間で移動されること
を保証してプログラム自体がネットワークの変動や複雑
さから遮蔽されるようにする。これを図1のネットワー
ク・リンク70によって表す。プログラム20は送出元のプ
ログラム10が選択した時ではなくプログラム20側で準備
ができた時に、待ち行列30からメッセージを取ってこれ
を処理する。メッセージの転送及び後続の処理によって
回復可能資源に対して行われる変更は後続の障害の場合
に使用するため不揮発性記憶域内の回復ログ80及び90に
記録される。これらのログはジャーナルと称する場合も
あるが、基礎となるオペレーティング・システムが提供
する機能であり、IBM社出版物"AS/400 Programming : B
ackup and Recovery Guide" (SC21-8079)に詳しく記載
されている。
【００５７】メッセージ待ち行列の維持、メッセージ及
び待ち行列の間の関係の維持、ネットワークの障害及び
再始動の処理並びにネットワーク内でのメッセージの移
動に伴う作業はすべて待ち行列管理プログラムによって
処理される。ネットワークを横切る通信セッションは個
々のプログラム間ではなく待ち行列管理プログラム間で
確立されるので、プログラムは他のいくつかのタイプの
プログラム間通信の場合よりもネットワーク障害に対し
て堅牢である。プロセッサ間のリンクに障害が発生する
場合、その障害からの回復は待ち行列管理プログラムの
仕事である。影響されるプロセッサ上のプログラムはそ
のような事象によって停止状態にはされない。実際には
これらのプログラムはそれが発生したことを知る必要が
ない。
び待ち行列の間の関係の維持、ネットワークの障害及び
再始動の処理並びにネットワーク内でのメッセージの移
動に伴う作業はすべて待ち行列管理プログラムによって
処理される。ネットワークを横切る通信セッションは個
々のプログラム間ではなく待ち行列管理プログラム間で
確立されるので、プログラムは他のいくつかのタイプの
プログラム間通信の場合よりもネットワーク障害に対し
て堅牢である。プロセッサ間のリンクに障害が発生する
場合、その障害からの回復は待ち行列管理プログラムの
仕事である。影響されるプロセッサ上のプログラムはそ
のような事象によって停止状態にはされない。実際には
これらのプログラムはそれが発生したことを知る必要が
ない。
【００５８】メッセージ伝達及び待合せでは、アプリケ
ーションの構造に対する制約がない。図1に示されるよ
うに両方向相互通信ならびに1方向メッセージ・フロー
が可能である。別々の待ち行列30及び40がプログラム10
及び20のそれぞれのメッセージの受取りのために存在す
る。さらにこの通信は1対多(単一プログラムの3つのコ
ピーが負荷平衡のため並行に走行しており、同一の待ち
行列からメッセージを取ってよい場合など)又は多対1
(単一のサーバにメッセージを送るクライアントが複数
存在する場合など)もしくはこれらの関係のすべての組
み合わせとすることができる。
ーションの構造に対する制約がない。図1に示されるよ
うに両方向相互通信ならびに1方向メッセージ・フロー
が可能である。別々の待ち行列30及び40がプログラム10
及び20のそれぞれのメッセージの受取りのために存在す
る。さらにこの通信は1対多(単一プログラムの3つのコ
ピーが負荷平衡のため並行に走行しており、同一の待ち
行列からメッセージを取ってよい場合など)又は多対1
(単一のサーバにメッセージを送るクライアントが複数
存在する場合など)もしくはこれらの関係のすべての組
み合わせとすることができる。
【００５９】平常の(即ち再始動でない)処理の際には、
トランザクションは順方向進行、部分的ロールバック又
は全体的ロールバック(打切り)である可能性がある。ロ
ールバックはシステム又はアプリケーションが開始する
可能性がある。ロールバックの原因はエラー状態、保全
性制約の侵害、予期されないデータベース状態その他の
理由があり得る。下記のデータ構造を図1のシステムに
設けて回復を援助する。
トランザクションは順方向進行、部分的ロールバック又
は全体的ロールバック(打切り)である可能性がある。ロ
ールバックはシステム又はアプリケーションが開始する
可能性がある。ロールバックの原因はエラー状態、保全
性制約の侵害、予期されないデータベース状態その他の
理由があり得る。下記のデータ構造を図1のシステムに
設けて回復を援助する。
【００６０】ロギング 資源に対する変更は回復ログ80及び90を使用して記憶さ
れる。ログ・レコードには下記の情報が含まれ、いくつ
かのタイプのログ・レコードには他の情報も追加され
る。 ・Owner(オーナー) そのログ・レコードを所有するシ
ステム・サブコンポーネントの名前 ・Type(タイプ): ログ・レコードのタイプ(例えば補
償、正常更新又はコミット ・プロトコル関連のレコード) ・TranID: そのログ・レコードを書き込んだ関連トラ
ンザクションが存在するならばその識別(下記を参照さ
れたい) ・PrevLSN: このトランザクション内の前のログ・レコ
ードのログ・シーケンス番号(LSN)(各トランザクション
の最初のログ・レコードではこのフィールドの値が0に
なる)。ログ・シーケンス番号はログ上の1レコードの独
自の識別子である ・Data(データ): 変更の前及び後のイメージなどタイ
プ依存の情報を含む区域。通常はメッセージ待ち行列識
別子が含まれる。
れる。ログ・レコードには下記の情報が含まれ、いくつ
かのタイプのログ・レコードには他の情報も追加され
る。 ・Owner(オーナー) そのログ・レコードを所有するシ
ステム・サブコンポーネントの名前 ・Type(タイプ): ログ・レコードのタイプ(例えば補
償、正常更新又はコミット ・プロトコル関連のレコード) ・TranID: そのログ・レコードを書き込んだ関連トラ
ンザクションが存在するならばその識別(下記を参照さ
れたい) ・PrevLSN: このトランザクション内の前のログ・レコ
ードのログ・シーケンス番号(LSN)(各トランザクション
の最初のログ・レコードではこのフィールドの値が0に
なる)。ログ・シーケンス番号はログ上の1レコードの独
自の識別子である ・Data(データ): 変更の前及び後のイメージなどタイ
プ依存の情報を含む区域。通常はメッセージ待ち行列識
別子が含まれる。
【００６１】レコード・タイプ固有データの1例として
補償ログ・レコード(CLR)は"UndoNextLSN"と称するもう
1つのLSNを有する。これはトランザクション・ロールバ
ック中に取り消しを必要とする次のログ・レコードのLS
Nである。
補償ログ・レコード(CLR)は"UndoNextLSN"と称するもう
1つのLSNを有する。これはトランザクション・ロールバ
ック中に取り消しを必要とする次のログ・レコードのLS
Nである。
【００６２】一部のログ・レコードは更新を記述するた
めオブジェクト・カタログへ書き込まれる。オブジェク
ト・カタログとはメッセージ待ち行列を含むシステムに
定義されたすべてのオブジェクトのリストである。一部
のログ・レコードはシンクポイント制御の外部にある持
続性メッセージ対する動作を記述するために書き込まれ
る。これらの更新はトランザクションの内部では発生し
ない。このような更新のすべてがそれが表す論理動作で
はなく、値によってロギングされる。
めオブジェクト・カタログへ書き込まれる。オブジェク
ト・カタログとはメッセージ待ち行列を含むシステムに
定義されたすべてのオブジェクトのリストである。一部
のログ・レコードはシンクポイント制御の外部にある持
続性メッセージ対する動作を記述するために書き込まれ
る。これらの更新はトランザクションの内部では発生し
ない。このような更新のすべてがそれが表す論理動作で
はなく、値によってロギングされる。
【００６３】ログ・レコードには下記のタイプがある。 MSGPUT: 持続性メッセージを待ち行列にプットする時
に、このログ・レコードのうちの1つが書き込まれる。
これはUNDO/REDOレコードであり、変更を再適用又は除
去するのに十分な情報が含まれる。メッセージ・プット
動作を取り消すためには待ち行列内のメッセージを含む
待ち行列ファイル及びメッセージを指すポインタを含む
ヘッダ・ファイルの現在の状態を知る必要がある。この
情報はメッセージ・リストに保持される。メッセージ・
リストとは待ち行列ごとに1つの二重リンク・リストの
組であり、待ち行列上のメッセージごとに1レコードが
含まれる PUT PART: このログ・レコードは待ち行列に持続性メ
ッセージを書き込む時に必ず書き込まれるが、待ち行列
用の空間割振りルーチンによってばらばらの部分に分割
されて書き込まれる。これはMSGPUTログ・レコードがロ
グ・レコード・サイズの限界に達し、分割が必要になっ
た時にも必ず使用される。メッセージの主要部分はMSGP
UTレコードによって記述されるが、メッセージの残りを
記述するために複数のPUTPARTレコードを書き込むこと
ができる。これはREDO ONLY(UNDO専用)レコードである MSGGET: このログ・レコードのうちの1つが持続性メッ
セージを待ち行列からゲットする時に書き込まれる。こ
れはUNDO/REDOレコードである。メッセージ・ゲット動
作を取り消すためには、ゲットした時のメッセージを指
していたメッセージが変化している可能性があるので、
待ち行列ファイルの現在の状態を知る必要がある QCREATE: 待ち行列ファイルの初期状態を記録するため
待ち行列の生成中に書き込まれる QATTRS: このログ・レコードのうちの1つが待ち行列の
属性を更新する時に必ず書き込まれる。これはREDO ON
LYレコードである QDEPTH: ディスクに記録された待ち行列の現在の深さ
を更新するためロードされたローカル待ち行列ごとに成
功裡の遮断の間にこのレコードのうちの1つが書き込ま
れる。これはREDO ONLYレコードである PURGE: このレコードのうちの1つが待ち行列が除去さ
れる時に必ず書き込まれる。これはREDO ONLYレコード
である 補償ログ・レコード(CLR): ロールバックの間に取り消
された変更のそれぞれを取り消すためこのレコードのう
ちの1つが書き込まれる。CLRはロギングされた動作のう
ちで障害を発生したものを否定するためにも書き込まれ
る。これはREDOONLYレコードである。即ち、このレコー
ドは絶対に取り消されないので、変更を再適用するのに
必要な最低限の情報だけが含まれる。各CLRにはUndoNex
tLSNが存在するので、CLRを用いるとそれが表す変更のU
NDOが再始動の間に繰り返されないようになる。その代
わりに再始動では取り消しの必要な次の変更にスキップ
する。図2にこれを示す。このレコードは変更を正確に
物理的に逆転したものではなく、それが否定する変更の
取り消しに必要な論理動作を表すことに留意されたい。
ライトアヘッド・ロギング・プロトコルを尊重するため
には各CLRを個別に書き込む必要がある TRANTABLE: このログ・レコードはトランザクション・
テーブル(下記を参照されたい)を記録するためチェック
ポイント処理の最初の部分の間に書き込まれる STARTTRAN: このログ・レコードのうちの1つが新トラ
ンザクションの始動時に書き込まれる。これは絶対必要
ではないが、これがあるとログを読み取るのが簡単にな
る PREPARE: このログ・レコードのうちの1つがトランザ
クションのコミットの準備をする時に書き込まれる。こ
のレコードは絶対必要である COMMIT: このログ・レコードのうちの1つがトランザク
ションをコミットすると決定する時に書き込まれる ROLLBACK: このログ・レコードのうちの1つがトランザ
クションをロールバックすると決定する時に書き込まれ
る ENDTRAN: このログ・レコードのうちの1つがトランザ
クションの完了時に書き込まれる。トランザクションを
コミットする時には、このレコードのうちの1つがその
トランザクションに関連する他のすべてのレコードの後
に続く。トランザクションをロールバックする時には、
トランザクションの変更を除去するためロールバック・
レコードを書き込みその後にCLRを続け、最後にトラン
ザクション終りレコード(ENDTRAN)を書き込む BEGINCHKPT: このタイプのレコードはシステム・チェ
ックポイントの開始時に書き込まれる ENDCHKPT: このタイプのレコードはシステム・チェッ
クポイントの終了時に書き込まれる。
に、このログ・レコードのうちの1つが書き込まれる。
これはUNDO/REDOレコードであり、変更を再適用又は除
去するのに十分な情報が含まれる。メッセージ・プット
動作を取り消すためには待ち行列内のメッセージを含む
待ち行列ファイル及びメッセージを指すポインタを含む
ヘッダ・ファイルの現在の状態を知る必要がある。この
情報はメッセージ・リストに保持される。メッセージ・
リストとは待ち行列ごとに1つの二重リンク・リストの
組であり、待ち行列上のメッセージごとに1レコードが
含まれる PUT PART: このログ・レコードは待ち行列に持続性メ
ッセージを書き込む時に必ず書き込まれるが、待ち行列
用の空間割振りルーチンによってばらばらの部分に分割
されて書き込まれる。これはMSGPUTログ・レコードがロ
グ・レコード・サイズの限界に達し、分割が必要になっ
た時にも必ず使用される。メッセージの主要部分はMSGP
UTレコードによって記述されるが、メッセージの残りを
記述するために複数のPUTPARTレコードを書き込むこと
ができる。これはREDO ONLY(UNDO専用)レコードである MSGGET: このログ・レコードのうちの1つが持続性メッ
セージを待ち行列からゲットする時に書き込まれる。こ
れはUNDO/REDOレコードである。メッセージ・ゲット動
作を取り消すためには、ゲットした時のメッセージを指
していたメッセージが変化している可能性があるので、
待ち行列ファイルの現在の状態を知る必要がある QCREATE: 待ち行列ファイルの初期状態を記録するため
待ち行列の生成中に書き込まれる QATTRS: このログ・レコードのうちの1つが待ち行列の
属性を更新する時に必ず書き込まれる。これはREDO ON
LYレコードである QDEPTH: ディスクに記録された待ち行列の現在の深さ
を更新するためロードされたローカル待ち行列ごとに成
功裡の遮断の間にこのレコードのうちの1つが書き込ま
れる。これはREDO ONLYレコードである PURGE: このレコードのうちの1つが待ち行列が除去さ
れる時に必ず書き込まれる。これはREDO ONLYレコード
である 補償ログ・レコード(CLR): ロールバックの間に取り消
された変更のそれぞれを取り消すためこのレコードのう
ちの1つが書き込まれる。CLRはロギングされた動作のう
ちで障害を発生したものを否定するためにも書き込まれ
る。これはREDOONLYレコードである。即ち、このレコー
ドは絶対に取り消されないので、変更を再適用するのに
必要な最低限の情報だけが含まれる。各CLRにはUndoNex
tLSNが存在するので、CLRを用いるとそれが表す変更のU
NDOが再始動の間に繰り返されないようになる。その代
わりに再始動では取り消しの必要な次の変更にスキップ
する。図2にこれを示す。このレコードは変更を正確に
物理的に逆転したものではなく、それが否定する変更の
取り消しに必要な論理動作を表すことに留意されたい。
ライトアヘッド・ロギング・プロトコルを尊重するため
には各CLRを個別に書き込む必要がある TRANTABLE: このログ・レコードはトランザクション・
テーブル(下記を参照されたい)を記録するためチェック
ポイント処理の最初の部分の間に書き込まれる STARTTRAN: このログ・レコードのうちの1つが新トラ
ンザクションの始動時に書き込まれる。これは絶対必要
ではないが、これがあるとログを読み取るのが簡単にな
る PREPARE: このログ・レコードのうちの1つがトランザ
クションのコミットの準備をする時に書き込まれる。こ
のレコードは絶対必要である COMMIT: このログ・レコードのうちの1つがトランザク
ションをコミットすると決定する時に書き込まれる ROLLBACK: このログ・レコードのうちの1つがトランザ
クションをロールバックすると決定する時に書き込まれ
る ENDTRAN: このログ・レコードのうちの1つがトランザ
クションの完了時に書き込まれる。トランザクションを
コミットする時には、このレコードのうちの1つがその
トランザクションに関連する他のすべてのレコードの後
に続く。トランザクションをロールバックする時には、
トランザクションの変更を除去するためロールバック・
レコードを書き込みその後にCLRを続け、最後にトラン
ザクション終りレコード(ENDTRAN)を書き込む BEGINCHKPT: このタイプのレコードはシステム・チェ
ックポイントの開始時に書き込まれる ENDCHKPT: このタイプのレコードはシステム・チェッ
クポイントの終了時に書き込まれる。
【００６４】1つのトランザクションに関連するログ・
レコードは図2に示されるように各ログ・レコードの"Pr
evLSN"フィールドを使用してリンクされる。順次ログ20
0には、待ち行列更新1、2及び3を実行するトランザクシ
ョンのログ・レコードが含まれる。ここで、このトラン
ザクションをロールバックすると仮定する。ログ・レコ
ード、例えばRが書き込まれ、補償ログ・レコード3’、
2’及び1’が書き込まれる(ただし1’は1を取り消すた
めのCLRであり、他も同様である)。その後、トランザク
ション終りレコードＥを書き込む。このトランザクショ
ンのログ・レコードの間に他のトランザクションのログ
・レコードがあってもよい。このトランザクションに関
連するリンクが各トランザクションに実際のログ内のそ
れ自体の論理ログを提供することによってこの可能性に
対応する。
レコードは図2に示されるように各ログ・レコードの"Pr
evLSN"フィールドを使用してリンクされる。順次ログ20
0には、待ち行列更新1、2及び3を実行するトランザクシ
ョンのログ・レコードが含まれる。ここで、このトラン
ザクションをロールバックすると仮定する。ログ・レコ
ード、例えばRが書き込まれ、補償ログ・レコード3’、
2’及び1’が書き込まれる(ただし1’は1を取り消すた
めのCLRであり、他も同様である)。その後、トランザク
ション終りレコードＥを書き込む。このトランザクショ
ンのログ・レコードの間に他のトランザクションのログ
・レコードがあってもよい。このトランザクションに関
連するリンクが各トランザクションに実際のログ内のそ
れ自体の論理ログを提供することによってこの可能性に
対応する。
【００６５】ログは平常処理の間には読み取られず、従
ってデータ構造回復ルーチンはある動作を記録するログ
・レコードが書き込まれたか否かを知らないので、回復
の間のログ・レコードを絶対に書き込まず、従ってログ
・レコードを完全に失う危険を冒すのではなく回復中に
もう一度ログ・レコードを書き込む危険を冒すという方
針をとる。
ってデータ構造回復ルーチンはある動作を記録するログ
・レコードが書き込まれたか否かを知らないので、回復
の間のログ・レコードを絶対に書き込まず、従ってログ
・レコードを完全に失う危険を冒すのではなく回復中に
もう一度ログ・レコードを書き込む危険を冒すという方
針をとる。
【００６６】トランザクション・テーブル 特定の待ち行列管理プログラムのために活動状態である
トランザクションのリンク・リストを待ち行列管理プロ
グラムが維持する。このリスト(以下トランザクション
・テーブルと称する。図3の符号270である)に含まれる
各トランザクションは独自の識別子を有する。具体的に
言うと、このテーブルは活動状態のトランザクションご
とに下記の情報を含む項目260を有する。 ・そのトランザクションの独自の識別子 ・そのトランザクションの現在の状態(活動状態、準備
済み又はロールバック中) ・その"STARTTRAN"ログ・レコード(即ち新トランザクシ
ョン始動時に書き込まれたログ・レコード)のログ・シ
ーケンス番号(LSN) ・その最後のログ・レコードのLSN ・そのソフトログ250(下を参照されたい)を指すポイン
タ ・1つのプロセスだけが1つのトランザクションに関連す
ることを保証するための相互排他セマフォ ・トランザクション制御ブロック(TCB)へのアクセスが
逐次化されることを保証するための相互排他ハンドル(T
CBはトランザクションを記述するデータ構造である)。
トランザクションのリンク・リストを待ち行列管理プロ
グラムが維持する。このリスト(以下トランザクション
・テーブルと称する。図3の符号270である)に含まれる
各トランザクションは独自の識別子を有する。具体的に
言うと、このテーブルは活動状態のトランザクションご
とに下記の情報を含む項目260を有する。 ・そのトランザクションの独自の識別子 ・そのトランザクションの現在の状態(活動状態、準備
済み又はロールバック中) ・その"STARTTRAN"ログ・レコード(即ち新トランザクシ
ョン始動時に書き込まれたログ・レコード)のログ・シ
ーケンス番号(LSN) ・その最後のログ・レコードのLSN ・そのソフトログ250(下を参照されたい)を指すポイン
タ ・1つのプロセスだけが1つのトランザクションに関連す
ることを保証するための相互排他セマフォ ・トランザクション制御ブロック(TCB)へのアクセスが
逐次化されることを保証するための相互排他ハンドル(T
CBはトランザクションを記述するデータ構造である)。
【００６７】トランザクション・テーブルは活動状態の
トランザクションの状態を追跡するのに使用される。ト
ランザクション・テーブルのうちで持続性の部分は障害
の後のシステム再始動の間に再構成しなければならな
い。この処理を最適化するためにその部分をシステム・
チェックポイントの一部として定期的にロギングする。
チェックポイントとはオブジェクトを強制的にディスク
に書き込む動作であり、オブジェクトを最新の状態にす
るために適用する必要のあるログの量を減らすことによ
ってシステム障害の後のオブジェクトの回復に要する時
間を短縮するために行われる動作である。
トランザクションの状態を追跡するのに使用される。ト
ランザクション・テーブルのうちで持続性の部分は障害
の後のシステム再始動の間に再構成しなければならな
い。この処理を最適化するためにその部分をシステム・
チェックポイントの一部として定期的にロギングする。
チェックポイントとはオブジェクトを強制的にディスク
に書き込む動作であり、オブジェクトを最新の状態にす
るために適用する必要のあるログの量を減らすことによ
ってシステム障害の後のオブジェクトの回復に要する時
間を短縮するために行われる動作である。
【００６８】ロギングされた版のトランザクション・テ
ーブルには未確定であるすべてのトランザクションに関
して再始動中に再構成されるソフトログを指すポインタ
を除いてメモリ内の版と同一の項目のすべてが含まれ
る。トランザクション・テーブルはログ・レコードの最
大サイズより大きくなる可能性があり、その場合には複
数のレコードにロギングされる。
ーブルには未確定であるすべてのトランザクションに関
して再始動中に再構成されるソフトログを指すポインタ
を除いてメモリ内の版と同一の項目のすべてが含まれ
る。トランザクション・テーブルはログ・レコードの最
大サイズより大きくなる可能性があり、その場合には複
数のレコードにロギングされる。
【００６９】ソフトログ ソフトログ250には回復を援助するため揮発性メモリ内
で維持されるリストが含まれる。これには不揮発性メモ
リ内のログに保持される情報の多くが複製されるが、ロ
グと同一の情報のすべてが含まれるわけではない。ソフ
トログは待ち行列に対するコミット又はロールバックを
実施するために実行する必要がある処置の記録を提供し
てログの選択的な逆方向走査の必要をなくす。
で維持されるリストが含まれる。これには不揮発性メモ
リ内のログに保持される情報の多くが複製されるが、ロ
グと同一の情報のすべてが含まれるわけではない。ソフ
トログは待ち行列に対するコミット又はロールバックを
実施するために実行する必要がある処置の記録を提供し
てログの選択的な逆方向走査の必要をなくす。
【００７０】図3に概略的に示されるように、未完了の
トランザクションごとに1つのソフトログ250がトランザ
クション・テーブル270内のそのトランザクションの項
目260に付加されている。ソフトログは関連するトラン
ザクション内で実行されたすべてのゲット動作及びプッ
ト動作の記録であり、すばやいコミット処理及びロール
バック処理を可能にするために存在する。これにはトラ
ンザクションに関係がある持続性及び非持続性の両方の
メッセージ動作の項目が含まれる。対照的に、持続性の
メッセージ動作だけが不揮発性の回復ログ80及び90にロ
ギングされ、これにはシステムによって行われる非トラ
ンザクション性の持続性更新のすべてが含まれる。
トランザクションごとに1つのソフトログ250がトランザ
クション・テーブル270内のそのトランザクションの項
目260に付加されている。ソフトログは関連するトラン
ザクション内で実行されたすべてのゲット動作及びプッ
ト動作の記録であり、すばやいコミット処理及びロール
バック処理を可能にするために存在する。これにはトラ
ンザクションに関係がある持続性及び非持続性の両方の
メッセージ動作の項目が含まれる。対照的に、持続性の
メッセージ動作だけが不揮発性の回復ログ80及び90にロ
ギングされ、これにはシステムによって行われる非トラ
ンザクション性の持続性更新のすべてが含まれる。
【００７１】トランザクションのソフトログ内にはトラ
ンザクション内のメッセージ・ゲット動作及びメッセー
ジ・プット動作のそれぞれについて1つの項目280及び29
0がある(通常処理の間に限る。下で説明するように活動
状態トランザクションのソフトログが再構成される再始
動回復の間には持続性メッセージ動作に関する項目だけ
がソフトログに置かれる)。ソフトログ項目のそれぞれ
にはそのソフトログ項目が記述する待ち行列動作のロー
ルバックに対応するCLRを構成するのに十分な情報が含
まれる。
ンザクション内のメッセージ・ゲット動作及びメッセー
ジ・プット動作のそれぞれについて1つの項目280及び29
0がある(通常処理の間に限る。下で説明するように活動
状態トランザクションのソフトログが再構成される再始
動回復の間には持続性メッセージ動作に関する項目だけ
がソフトログに置かれる)。ソフトログ項目のそれぞれ
にはそのソフトログ項目が記述する待ち行列動作のロー
ルバックに対応するCLRを構成するのに十分な情報が含
まれる。
【００７２】ソフトログ項目は下記のフォーマットを有
する。 ・影響されるメッセージを保持する待ち行列の識別子 ・その待ち行列でのメッセージの指標 ・項目の理由(GET、PUT又はTRIGGERPUT) ・トランザクション内でこの動作に関して書き込まれた
ログ・レコード300及び310のLSN又はこのトランザクシ
ョンに関して最後にロギングされた動作のLSN(ログ・レ
コード・リンクの構成に使用される)、もしくはその両
方(この2つのLSNのそれぞれは他方から推論可能である
が、ソフトログ・エントリが両方を有してもよい) ・状況フラグ。
する。 ・影響されるメッセージを保持する待ち行列の識別子 ・その待ち行列でのメッセージの指標 ・項目の理由(GET、PUT又はTRIGGERPUT) ・トランザクション内でこの動作に関して書き込まれた
ログ・レコード300及び310のLSN又はこのトランザクシ
ョンに関して最後にロギングされた動作のLSN(ログ・レ
コード・リンクの構成に使用される)、もしくはその両
方(この2つのLSNのそれぞれは他方から推論可能である
が、ソフトログ・エントリが両方を有してもよい) ・状況フラグ。
【００７３】図3からわかるように、トランザクション
・テーブルの項目260はその動作のソフトログ250を指す
ポインタを有し、ソフトログの項目280及び290はそのロ
グ・レコード300及び310を指すポインタを有する。ログ
・レコードはトランザクション・テーブルを指すポイン
タを有する。
・テーブルの項目260はその動作のソフトログ250を指す
ポインタを有し、ソフトログの項目280及び290はそのロ
グ・レコード300及び310を指すポインタを有する。ログ
・レコードはトランザクション・テーブルを指すポイン
タを有する。
【００７４】またソフトログ内の項目数に関するフィー
ルド、ソフトログ項目の最大数に関するフィールド(ソ
フトログは固定サイズのメモリ・ブロックであり、その
要素数は1トランザクション内で許容される未コミット
のメッセージの最大数である)及びソフトログを処理す
る順序を決定するのに使用される順序フィールド(表立
って配列に要素を追加することは困難なので必要)を含
むヘッダ構造がある。
ルド、ソフトログ項目の最大数に関するフィールド(ソ
フトログは固定サイズのメモリ・ブロックであり、その
要素数は1トランザクション内で許容される未コミット
のメッセージの最大数である)及びソフトログを処理す
る順序を決定するのに使用される順序フィールド(表立
って配列に要素を追加することは困難なので必要)を含
むヘッダ構造がある。
【００７５】ソフトログには通常項目が時間的な順序で
含まれ、これらの項目はコミット処理の間には正方向、
ロールバック処理の間には逆方向に処理される。再始動
回復の間には状況が複雑になる。というのは、ソフトロ
グが実際にはログから逆の順序で再構成されるからであ
る。従って、再始動処理中のコミット処理及びロールバ
ック処理では通常実行の間に使用されるのと反対の順序
でソフトログを処理する。
含まれ、これらの項目はコミット処理の間には正方向、
ロールバック処理の間には逆方向に処理される。再始動
回復の間には状況が複雑になる。というのは、ソフトロ
グが実際にはログから逆の順序で再構成されるからであ
る。従って、再始動処理中のコミット処理及びロールバ
ック処理では通常実行の間に使用されるのと反対の順序
でソフトログを処理する。
【００７６】システム・チェックポイントの一部として
ログ内にソフトログを記録することも可能ではあるが、
これは高価につく可能性があるのでその代わりに後に説
明するようにシステム障害からの回復の間に通常は低い
頻度でソフトログを構成する。
ログ内にソフトログを記録することも可能ではあるが、
これは高価につく可能性があるのでその代わりに後に説
明するようにシステム障害からの回復の間に通常は低い
頻度でソフトログを構成する。
【００７７】作業を含まないトランザクションはトラン
ザクション・テーブル内に項目を有するが、関連ソフト
ログには項目が含まれない。従って、そのような空のト
ランザクションのコミット処理及びロールバック処理で
はソフトログ項目を処理する必要がない。
ザクション・テーブル内に項目を有するが、関連ソフト
ログには項目が含まれない。従って、そのような空のト
ランザクションのコミット処理及びロールバック処理で
はソフトログ項目を処理する必要がない。
【００７８】ロック 単純な相互排他セマフォを使用してロック管理プログラ
ムの必要なしに従って機能の充実したロック管理プログ
ラムを有しないシステムへの移植性という利益を伴って
(ただし多少の並行性が失われるという犠牲を伴う)、共
用情報へのアクセスを制御する。セマフォ・「ロック」
の対象は待ち行列であり、その待ち行列上のすべてのメ
ッセージの暗黙のロックが提供される。各待ち行列は1
時に1つのプロセスだけが保持できる相互排他セマフォ
を有し、各プロセスは1時に1つの相互排他だけを保持で
きる(いくつかの特殊な場合を除く)。待ち行列のデータ
構造のいずれかをアクセスするにはこの相互排他を取得
し、アクセスを実行した後に相互排他を解放しなければ
ならない。この技法だけではシンクポイント制御の下で
のメッセージ・プットの場合に不十分になるはずであ
る。というのは、トランザクション全体にわたって待ち
行列をロックしてはならないからである。ある待ち行列
がアンロード又は削除されないようにその待ち行列が活
動状態のトランザクションに関連するかどうかを知る必
要がある。これを達成するために待ち行列のそれぞれに
関連するカウンタがあり、これはその待ち行列にある未
コミットのメッセージ数である。
ムの必要なしに従って機能の充実したロック管理プログ
ラムを有しないシステムへの移植性という利益を伴って
(ただし多少の並行性が失われるという犠牲を伴う)、共
用情報へのアクセスを制御する。セマフォ・「ロック」
の対象は待ち行列であり、その待ち行列上のすべてのメ
ッセージの暗黙のロックが提供される。各待ち行列は1
時に1つのプロセスだけが保持できる相互排他セマフォ
を有し、各プロセスは1時に1つの相互排他だけを保持で
きる(いくつかの特殊な場合を除く)。待ち行列のデータ
構造のいずれかをアクセスするにはこの相互排他を取得
し、アクセスを実行した後に相互排他を解放しなければ
ならない。この技法だけではシンクポイント制御の下で
のメッセージ・プットの場合に不十分になるはずであ
る。というのは、トランザクション全体にわたって待ち
行列をロックしてはならないからである。ある待ち行列
がアンロード又は削除されないようにその待ち行列が活
動状態のトランザクションに関連するかどうかを知る必
要がある。これを達成するために待ち行列のそれぞれに
関連するカウンタがあり、これはその待ち行列にある未
コミットのメッセージ数である。
【００７９】未コミットのトランザクションによってプ
ット又はゲットされたので使用できないメッセージはメ
ッセージがトランザクション内でゲット又はプットされ
たことを示す標識をセットすることによってそのメッセ
ージ・リスト内で不可視としてマークされ、その結果待
ち行列の走査ではこれらが無視される。これによってロ
ック管理プログラムが個々のメッセージに対する排他ロ
ックを保持する必要がなくなる。
ット又はゲットされたので使用できないメッセージはメ
ッセージがトランザクション内でゲット又はプットされ
たことを示す標識をセットすることによってそのメッセ
ージ・リスト内で不可視としてマークされ、その結果待
ち行列の走査ではこれらが無視される。これによってロ
ック管理プログラムが個々のメッセージに対する排他ロ
ックを保持する必要がなくなる。
【００８０】図4は1トランザクション内での成功裡の完
了までのメッセージの正方向処理の全般的なステップを
示す図である。まず待ち行列をサービスするアプリケー
ションがメッセージ待ち行列に対する相互排他ロックを
取得し(400)、他のアプリケーションがその待ち行列を
アクセスしないようにする。明らかに、これによって個
々のメッセージをロックすることほど高度な並行性は提
供されないが、このロック制御手順は高粒度ロックの場
合より単純である。これがトランザクションの開始であ
る場合、その開始に関するログ・レコードを書き込み(4
10)、トランザクション・テーブル内にそのトランザク
ションに関する項目をアトミック的に作成する(420)。
そうでない場合、現在のトランザクション項目の位置を
突き止める(430)。
了までのメッセージの正方向処理の全般的なステップを
示す図である。まず待ち行列をサービスするアプリケー
ションがメッセージ待ち行列に対する相互排他ロックを
取得し(400)、他のアプリケーションがその待ち行列を
アクセスしないようにする。明らかに、これによって個
々のメッセージをロックすることほど高度な並行性は提
供されないが、このロック制御手順は高粒度ロックの場
合より単純である。これがトランザクションの開始であ
る場合、その開始に関するログ・レコードを書き込み(4
10)、トランザクション・テーブル内にそのトランザク
ションに関する項目をアトミック的に作成する(420)。
そうでない場合、現在のトランザクション項目の位置を
突き止める(430)。
【００８１】その後、メッセージを操作する(440)。GET
動作で待ち行列からメッセージを取得する(取得するア
プリケーションによって処理されるメッセージの場合。
受取り側アプリケーションが目標アプリケーションでな
い場合には、別の待ち行列にPUTする)かPUT動作で待ち
行列にメッセージをプットする。シンクポイント制御の
下のすべてのメッセージ動作はPUT及びGETのシーケンス
である。詳細にいえば、PUT動作の場合のステップ440に
は下記のサブステップが含まれる。 a)メッセージを置く場所を突き止め前のメッセージを識
別する b)持続性メッセージの場合、すべての詳細をロギングす
る c)選択された空間にメッセージを書き込む d)待ち行列にリンクを書き込む e)待ち行列に関するメモリ・リストに追加する GET動作の場合、下記のサブステップが含まれるはずで
ある。 a)メモリ・リスト内でメッセージを突き止める b)メッセージの詳細を読み取る c)if 持続性メッセージの場合 前のメッセージ及び後のメッセージを識別する 詳細をロギングする 待ち行列にリンク解除を書き込む End if d)メモリ・リストから除去する。
動作で待ち行列からメッセージを取得する(取得するア
プリケーションによって処理されるメッセージの場合。
受取り側アプリケーションが目標アプリケーションでな
い場合には、別の待ち行列にPUTする)かPUT動作で待ち
行列にメッセージをプットする。シンクポイント制御の
下のすべてのメッセージ動作はPUT及びGETのシーケンス
である。詳細にいえば、PUT動作の場合のステップ440に
は下記のサブステップが含まれる。 a)メッセージを置く場所を突き止め前のメッセージを識
別する b)持続性メッセージの場合、すべての詳細をロギングす
る c)選択された空間にメッセージを書き込む d)待ち行列にリンクを書き込む e)待ち行列に関するメモリ・リストに追加する GET動作の場合、下記のサブステップが含まれるはずで
ある。 a)メモリ・リスト内でメッセージを突き止める b)メッセージの詳細を読み取る c)if 持続性メッセージの場合 前のメッセージ及び後のメッセージを識別する 詳細をロギングする 待ち行列にリンク解除を書き込む End if d)メモリ・リストから除去する。
【００８２】動作のこの実行に対してアトミック的にメ
ッセージにトランザクション内で操作されたものとして
第1の待ち行列内でフラグを立て(450)、ソフトログ内で
その動作に関する項目を作成する(460)。このメッセー
ジは現在その待ち行列をサービスする他のアプリケーシ
ョンから使用不能である。
ッセージにトランザクション内で操作されたものとして
第1の待ち行列内でフラグを立て(450)、ソフトログ内で
その動作に関する項目を作成する(460)。このメッセー
ジは現在その待ち行列をサービスする他のアプリケーシ
ョンから使用不能である。
【００８３】このアプリケーションはここで他のアプリ
ケーションがその待ち行列をサービスしないようにする
必要がなくなったので、相互排他制御ロックを解放する
(470)。操作されるメッセージは待ち行列から除去され
たものとしてフラグを立てられたままになり、従ってア
プリケーションから使用不能である。このフラグはメッ
セージに対する排他ロックとして働く。その後トランザ
クションが完了するまでそのトランザクション内の他の
メッセージに対して上のステップを繰り返す(480)。ト
ランザクションの成功裡の完了時に、ログ・レコードを
書き込んでトランザクションの終りをマークし(490)、
そのトランザクション内でゲットされたフラグを立てら
れたメッセージのすべてを入力待ち行列からアトミック
的に削除し(500)、そのトランザクション内でプットさ
れたメッセージのすべてのフラグを削除する。
ケーションがその待ち行列をサービスしないようにする
必要がなくなったので、相互排他制御ロックを解放する
(470)。操作されるメッセージは待ち行列から除去され
たものとしてフラグを立てられたままになり、従ってア
プリケーションから使用不能である。このフラグはメッ
セージに対する排他ロックとして働く。その後トランザ
クションが完了するまでそのトランザクション内の他の
メッセージに対して上のステップを繰り返す(480)。ト
ランザクションの成功裡の完了時に、ログ・レコードを
書き込んでトランザクションの終りをマークし(490)、
そのトランザクション内でゲットされたフラグを立てら
れたメッセージのすべてを入力待ち行列からアトミック
的に削除し(500)、そのトランザクション内でプットさ
れたメッセージのすべてのフラグを削除する。
【００８４】トランザクション内で実行された動作のい
ずれかがエラー状態を発生するか他のデータ保全性制約
のいずれかが侵害された場合、そのトランザクションの
完了は許可できずロール・バックしなければならない。
ロールバック手順にはそのトランザクション内でゲット
したメッセージのフラグを削除し、その結果待ち行列上
でこれらをもう一度使用可能にすること、そのトランザ
クション内でPUTされたメッセージを削除すること及び
正方向処理の間に書き込まれたログ・レコードの補償ロ
グ・レコードを書き込むことが含まれる。
ずれかがエラー状態を発生するか他のデータ保全性制約
のいずれかが侵害された場合、そのトランザクションの
完了は許可できずロール・バックしなければならない。
ロールバック手順にはそのトランザクション内でゲット
したメッセージのフラグを削除し、その結果待ち行列上
でこれらをもう一度使用可能にすること、そのトランザ
クション内でPUTされたメッセージを削除すること及び
正方向処理の間に書き込まれたログ・レコードの補償ロ
グ・レコードを書き込むことが含まれる。
【００８５】トランザクションは解決の前に複数の段階
を通過する。トランザクションの各相の間に異なる処理
が実行される。トランザクション管理プログラムはトラ
ンザクションがある相から別の相に移ったことを示す責
任を負う。
を通過する。トランザクションの各相の間に異なる処理
が実行される。トランザクション管理プログラムはトラ
ンザクションがある相から別の相に移ったことを示す責
任を負う。
【００８６】下記の諸ステップがトランザクションの相
ごとに実行される。
ごとに実行される。
【００８７】コミットの準備 準備の時点で"PREPARE"ログ・レコードを書き込まなけ
ればならない。
ればならない。
【００８８】この段階中に待ち行列管理プログラムは要
求された時にコミットできることを保証することが期待
される。トランザクション内部のすべての変更がすでに
ログに固められている場合、準備を求められたという事
実を記録するだけで十分である。従って待ち行列管理プ
ログラムはこのログ・レコードの書込みが不可能でない
限り準備要求に対して必ず"yes"を投票し書込不可能の
場合には"no"を投票する。
求された時にコミットできることを保証することが期待
される。トランザクション内部のすべての変更がすでに
ログに固められている場合、準備を求められたという事
実を記録するだけで十分である。従って待ち行列管理プ
ログラムはこのログ・レコードの書込みが不可能でない
限り準備要求に対して必ず"yes"を投票し書込不可能の
場合には"no"を投票する。
【００８９】コミット トランザクションをコミットする時には"COMMIT"ログ・
レコードを書き込む。これは異なるシステムの間での移
植性にとって望ましい。というのは、すべてのトランザ
クション管理プログラムが監視されるコミットのロギン
グという状況を処理できるとは限らないからである。
レコードを書き込む。これは異なるシステムの間での移
植性にとって望ましい。というのは、すべてのトランザ
クション管理プログラムが監視されるコミットのロギン
グという状況を処理できるとは限らないからである。
【００９０】トランザクションに関連するソフトログを
検査してトランザクションの結果としてどのメッセージ
がプット又はゲットされたかについての詳細を得る。ソ
フトログの走査及び各レコードの処理は必要に応じて待
ち行列をロック又はロック解除しながら下記のように行
われる。 MSGPUT 関連メッセージを可視にし、未コミットのメッ
セージの数を減らす。メッセージ待ち行列管理プログラ
ムのローカル待ち行列管理プログラム構成要素に待機中
のゲット要求を満足する可能性のあるメッセージが待ち
行列に現れたことを知らせる。 MSGGET メッセージが占める空間を解放しメッセージを
待ち行列から除去する。未コミット・メッセージ・カウ
ントを減らす。
検査してトランザクションの結果としてどのメッセージ
がプット又はゲットされたかについての詳細を得る。ソ
フトログの走査及び各レコードの処理は必要に応じて待
ち行列をロック又はロック解除しながら下記のように行
われる。 MSGPUT 関連メッセージを可視にし、未コミットのメッ
セージの数を減らす。メッセージ待ち行列管理プログラ
ムのローカル待ち行列管理プログラム構成要素に待機中
のゲット要求を満足する可能性のあるメッセージが待ち
行列に現れたことを知らせる。 MSGGET メッセージが占める空間を解放しメッセージを
待ち行列から除去する。未コミット・メッセージ・カウ
ントを減らす。
【００９１】最後に"ENDTRAN"ログ・レコードを書き込
む。
む。
【００９２】ロールバック トランザクションをロールバックする時には"ROLLBACK"
ログ・レコードを書き込まなければならない。
ログ・レコードを書き込まなければならない。
【００９３】トランザクションに関連するソフトログを
検査してトランザクションの結果としてどのメッセージ
がプット又はゲットされたかについての詳細を得る。ソ
フトログの走査及び各レコードの処理は必要に応じて待
ち行列をロック又はロック解除しながら下記のように行
われる。
検査してトランザクションの結果としてどのメッセージ
がプット又はゲットされたかについての詳細を得る。ソ
フトログの走査及び各レコードの処理は必要に応じて待
ち行列をロック又はロック解除しながら下記のように行
われる。
【００９４】MSGPUT 前のメッセージからのリンクが次
のメッセージ(存在するならば)を指すように変更するこ
とによってメッセージを待ち行列から除去しなければな
らない。メッセージが持続性であった場合には、この変
更の前に補償ログ・レコードを書き込んでこの更新を記
述しなければならない。メッセージによって占められて
いた空間を解放し未コミット・メッセージ数を減らす。
のメッセージ(存在するならば)を指すように変更するこ
とによってメッセージを待ち行列から除去しなければな
らない。メッセージが持続性であった場合には、この変
更の前に補償ログ・レコードを書き込んでこの更新を記
述しなければならない。メッセージによって占められて
いた空間を解放し未コミット・メッセージ数を減らす。
【００９５】MSGGET 前のメッセージ(存在するならば)
のポインタがこのメッセージを指すように変更すること
によってメッセージを待ち行列上で復元しなければなら
ない。メッセージが持続性であった場合には、補償ログ
・レコードを書き込んでこの更新を記述しなければなら
ない。メッセージを可視にし未コミット・メッセージ・
カウントを減らす。メッセージのバックアウト・カウン
トを増やす。未コミットのゲット・メッセージによって
占められる空間は関連トランザクションがコミットされ
るまで解放されないのでロールバックの間にこのメッセ
ージのために空間を再利用する必要はない。
のポインタがこのメッセージを指すように変更すること
によってメッセージを待ち行列上で復元しなければなら
ない。メッセージが持続性であった場合には、補償ログ
・レコードを書き込んでこの更新を記述しなければなら
ない。メッセージを可視にし未コミット・メッセージ・
カウントを減らす。メッセージのバックアウト・カウン
トを増やす。未コミットのゲット・メッセージによって
占められる空間は関連トランザクションがコミットされ
るまで解放されないのでロールバックの間にこのメッセ
ージのために空間を再利用する必要はない。
【００９６】最後に"ENDTRAN"ログ・レコードを書き込
む。
む。
【００９７】MSGPUTログ・レコード及びMSGGETログ・レ
コードにはそれが変更しつつある区域の前のイメージは
含まれない。これは単純にログから読み取るのではなく
この動作の逆を推測しなければならないことを意味す
る。これは待ち行列の内容の知識を使用して行われる。
コードにはそれが変更しつつある区域の前のイメージは
含まれない。これは単純にログから読み取るのではなく
この動作の逆を推測しなければならないことを意味す
る。これは待ち行列の内容の知識を使用して行われる。
【００９８】再始動 システム障害又は単一のトランザクションを越える範囲
に広がる他の障害の場合、不揮発性記憶域からのログ・
レコードを使用して処理を再始動しなければならない。
に広がる他の障害の場合、不揮発性記憶域からのログ・
レコードを使用して処理を再始動しなければならない。
【００９９】再始動処理にはログの3回のパス、即ち再
実行パス、未確定パス及びUNDOパスが含まれる。待ち行
列及び他のオブジェクトのそれぞれを必要に応じてアク
セスする。回復に参加しない待ち行列はロードしない。
回復を正しく進行できるようになる前にオブジェクト・
カタログを読み込む必要がある。これは損傷を受けてい
ないと仮定され、損傷の場合にはデータ回復のためにそ
れ自体は損傷を受けていないカタログのバックアップ・
コピーを提供する必要がある。
実行パス、未確定パス及びUNDOパスが含まれる。待ち行
列及び他のオブジェクトのそれぞれを必要に応じてアク
セスする。回復に参加しない待ち行列はロードしない。
回復を正しく進行できるようになる前にオブジェクト・
カタログを読み込む必要がある。これは損傷を受けてい
ないと仮定され、損傷の場合にはデータ回復のためにそ
れ自体は損傷を受けていないカタログのバックアップ・
コピーを提供する必要がある。
【０１００】再実行パス 再実行パスは待ち行列管理プログラムが動作を開始する
前の再生の状態の確立に関係がある。このパスが完了す
る前には、待ち行列ファイルに意味があるとは限らな
い。というのは、待ち行列ファイルに不完全な更新が含
まれる可能性があるからである。このパスは前のシステ
ム・チェックポイント・レコード(存在するならば)の読
み取りから始まる。この位置は再始動レコードに保持さ
れている。チェックポイントには、ログの最初の走査の
間に使用されるトランザクション・テーブルが含まれ
る。オブジェクト・カタログはこの処理が始まる前にロ
ードされることになる。というのは、有効なオブジェク
トの知識が必要になるからである。
前の再生の状態の確立に関係がある。このパスが完了す
る前には、待ち行列ファイルに意味があるとは限らな
い。というのは、待ち行列ファイルに不完全な更新が含
まれる可能性があるからである。このパスは前のシステ
ム・チェックポイント・レコード(存在するならば)の読
み取りから始まる。この位置は再始動レコードに保持さ
れている。チェックポイントには、ログの最初の走査の
間に使用されるトランザクション・テーブルが含まれ
る。オブジェクト・カタログはこの処理が始まる前にロ
ードされることになる。というのは、有効なオブジェク
トの知識が必要になるからである。
【０１０１】ログを順方向に走査し現在のチェックポイ
ントからログの末尾までのログ・レコードのそれぞれに
ついて下記の処置を実行する。 1．そのログ・レコードによって既知のトランザクショ
ンの状態が有効な形で変更される場合、必要に応じてト
ランザクションの状態を変更し、完了したならばトラン
ザクションをトランザクション・テーブルから除去す
る。これにはトランザクション・テーブル内のそのトラ
ンザクションの最後のログ・レコードのLSNを更新する
ことが含まれる。 2．そうでない場合、ログ・レコードに詳細を記された
変更を適用する。存在しないオブジェクト(削除された
可能性がある)に適用されるレコードはすべて無視され
る。
ントからログの末尾までのログ・レコードのそれぞれに
ついて下記の処置を実行する。 1．そのログ・レコードによって既知のトランザクショ
ンの状態が有効な形で変更される場合、必要に応じてト
ランザクションの状態を変更し、完了したならばトラン
ザクションをトランザクション・テーブルから除去す
る。これにはトランザクション・テーブル内のそのトラ
ンザクションの最後のログ・レコードのLSNを更新する
ことが含まれる。 2．そうでない場合、ログ・レコードに詳細を記された
変更を適用する。存在しないオブジェクト(削除された
可能性がある)に適用されるレコードはすべて無視され
る。
【０１０２】この処理には必要な時にトランザクション
・テーブル内のそのトランザクションの最後のログ・レ
コードのLSNを更新することが含まれる。
・テーブル内のそのトランザクションの最後のログ・レ
コードのLSNを更新することが含まれる。
【０１０３】この相が終る時点で最後のチェックポイン
ト以降の変更のすべてが待ち行列に再適用されているこ
とになり、トランザクション・テーブルは待ち行列管理
プログラムが停止した時の状態と矛盾しない状態にな
る。
ト以降の変更のすべてが待ち行列に再適用されているこ
とになり、トランザクション・テーブルは待ち行列管理
プログラムが停止した時の状態と矛盾しない状態にな
る。
【０１０４】この時点で後続の再始動中の再再生の量を
減らすためにチェックポイントをとる。
減らすためにチェックポイントをとる。
【０１０５】未確定パス 活動状態のどのトランザクションについてもコミット処
理又はロールバック処理を可能にするためにはそれに関
連するソフトログ250を再構成する必要がある。これは
未確定トランザクションごとにログ・レコードのPrevLS
N連鎖に従ってログを逆方向に走査することによって行
われる。 1．トランザクション・テーブル内のトランザクション
ごとにPrevLSN連鎖に従うことによってそのトランザク
ションのログ・レコードの連鎖に沿って逆方向に走査す
る。トランザクション内でCLRが見つかる場合には、そ
の代わりにこのレコードのNextUndoLSNリンクに従う(既
に取り消されているログ・レコードをスキップするた
め)。 2．見つかった"MSGPUT"ログ・レコード又は"MSGGET"ロ
グ・レコードのそれぞれについてどの待ち行列のどのメ
ッセージが使用されたかを確立し、必要があればディス
クからメッセージを見つけ、そのトランザクションに関
するソフト・ログに変更を記述した項目を追加する。メ
ッセージ・リスト内でメッセージを隠しとしてマーク
し、未コミット・メッセージの数を減らさなければなら
ない。
理又はロールバック処理を可能にするためにはそれに関
連するソフトログ250を再構成する必要がある。これは
未確定トランザクションごとにログ・レコードのPrevLS
N連鎖に従ってログを逆方向に走査することによって行
われる。 1．トランザクション・テーブル内のトランザクション
ごとにPrevLSN連鎖に従うことによってそのトランザク
ションのログ・レコードの連鎖に沿って逆方向に走査す
る。トランザクション内でCLRが見つかる場合には、そ
の代わりにこのレコードのNextUndoLSNリンクに従う(既
に取り消されているログ・レコードをスキップするた
め)。 2．見つかった"MSGPUT"ログ・レコード又は"MSGGET"ロ
グ・レコードのそれぞれについてどの待ち行列のどのメ
ッセージが使用されたかを確立し、必要があればディス
クからメッセージを見つけ、そのトランザクションに関
するソフト・ログに変更を記述した項目を追加する。メ
ッセージ・リスト内でメッセージを隠しとしてマーク
し、未コミット・メッセージの数を減らさなければなら
ない。
【０１０６】ログのこのパスは記録された最後のチェッ
クポイントの先頭を越えて逆方向に継続する可能性があ
る。というのは、最も古い活動状態のトランザクション
の先頭まで読み戻す必要があるからである。
クポイントの先頭を越えて逆方向に継続する可能性があ
る。というのは、最も古い活動状態のトランザクション
の先頭まで読み戻す必要があるからである。
【０１０７】このパスが終わる時点で各トランザクショ
ンはそのソフト・ログを変更されておらず、コミット要
求又はロールバック要求の処理の準備ができている。コ
ミット又はロールバックされたトランザクションによっ
てプット又はゲットされたメッセージはすべてが必要な
状態になっている。未準備のトランザクションのロール
バックだけが残されている。
ンはそのソフト・ログを変更されておらず、コミット要
求又はロールバック要求の処理の準備ができている。コ
ミット又はロールバックされたトランザクションによっ
てプット又はゲットされたメッセージはすべてが必要な
状態になっている。未準備のトランザクションのロール
バックだけが残されている。
【０１０８】UNDOパス このパスは未準備のトランザクションのロールバックに
関係する(システムが停止した時に部分的にロールバッ
クされていたトランザクションが未準備としてマークさ
れていたことを想起する)。これらのトランザクション
のそれぞれのソフトログは未確定パスで再構成されてい
るので、これらのトランザクションのそれぞれについて
単に通常のロールバック処理を呼び出すことができる。
関係する(システムが停止した時に部分的にロールバッ
クされていたトランザクションが未準備としてマークさ
れていたことを想起する)。これらのトランザクション
のそれぞれのソフトログは未確定パスで再構成されてい
るので、これらのトランザクションのそれぞれについて
単に通常のロールバック処理を呼び出すことができる。
【０１０９】単一パスの非常に多数のログ・レコードの
ログ読取をもたらす代替設計が時間的に厳密に逆の順序
で必要な更新を取り消すことである。これにはループを
介するパスのそれぞれで異なるトランザクションからの
更新を取り消すことが含まれる可能性がある。この設計
の短所はループのパスのそれぞれでトランザクション・
テーブルを検査してどのトランザクションが最大のUndo
NextLSNを有するかを知り、この更新を最初に取り消さ
なければならないことである。すべてのUNDO動作が論理
更新として実行され、どのような順序でも適用できるの
で、これは必要ない。
ログ読取をもたらす代替設計が時間的に厳密に逆の順序
で必要な更新を取り消すことである。これにはループを
介するパスのそれぞれで異なるトランザクションからの
更新を取り消すことが含まれる可能性がある。この設計
の短所はループのパスのそれぞれでトランザクション・
テーブルを検査してどのトランザクションが最大のUndo
NextLSNを有するかを知り、この更新を最初に取り消さ
なければならないことである。すべてのUNDO動作が論理
更新として実行され、どのような順序でも適用できるの
で、これは必要ない。
【０１１０】UNDOパスが終わる時点で待ち行列ファイル
は待ち行列を表すメモリ構造と矛盾しない状態であり、
ロールバックの必要があるすべてのトランザクションが
ロールバックされている。この時点で待ち行列管理プロ
グラムが作業を受け入れ始めることができる。
は待ち行列を表すメモリ構造と矛盾しない状態であり、
ロールバックの必要があるすべてのトランザクションが
ロールバックされている。この時点で待ち行列管理プロ
グラムが作業を受け入れ始めることができる。
【０１１１】最後のステップはシステム・チェックポイ
ントを取り、再始動の間にロードされたすべての待ち行
列をアンロードすることである。
ントを取り、再始動の間にロードされたすべての待ち行
列をアンロードすることである。
【０１１２】
【発明の効果】上述のように、本願発明によれば特定の
オペレーティング・システムのために効率的なフォール
ト・トレラント・データ処理をサポートしなければなら
ない場合にそのオペレーティング・システムの非効率的
なログ走査という制約の被害を受けない回復機能が提供
されることとなった。
オペレーティング・システムのために効率的なフォール
ト・トレラント・データ処理をサポートしなければなら
ない場合にそのオペレーティング・システムの非効率的
なログ走査という制約の被害を受けない回復機能が提供
されることとなった。
【図１】トランザクション指向メッセージ伝達及び待合
せシステムで互いに通信する2つのプログラムの概略図
である。
せシステムで互いに通信する2つのプログラムの概略図
である。
【図２】本発明の1実施例によるログ・レコード間のリ
ンクを概略的に示す図である。
ンクを概略的に示す図である。
【図３】本発明の1実施例によるトランザクション・テ
ーブル間の相互関係、トランザクションに関する動作の
揮発性メモリ・リストの組及び回復ログ内の動作のレコ
ードを示す図である。
ーブル間の相互関係、トランザクションに関する動作の
揮発性メモリ・リストの組及び回復ログ内の動作のレコ
ードを示す図である。
【図４】本発明の1実施例による成功裡に完了するトラ
ンザクションの正方向処理の間に実行される動作のシー
ケンスを示す図である。
ンザクションの正方向処理の間に実行される動作のシー
ケンスを示す図である。
10 プログラム 20 プログラム 30 待ち行列 40 待ち行列 50 待ち行列管理プログラム 60 待ち行列管理プログラム 70 ネットワーク・リンク 80 回復ログ 90 回復ログ 200 順次ログ 250 ソフトログ 270 トランザクション・テーブル 280 (ソフトログ)項目 290 (ソフトログ)項目 300 ログ・レコード 310 ログ・レコード
───────────────────────────────────────────────────── フロントページの続き (72)発明者 アンソニー・ロバート・ウォッシャ イギリス エス・オー51 ７アール・ジ ー ハンプシャー州ロムビイ クローバ ー・ウェイ27 (56)参考文献 特開 昭63−195755（ＪＰ，Ａ)
Claims (7)
- 【請求項１】 高速の揮発性記憶域及び低速の不揮発性
記憶域を有し、トランザクションをロールバックするか
又はシステムを再始動する必要がある場合に回復を可能
にするためにシステム動作に関連するレコードがシステ
ム内に記憶されているトランザクション処理システムに
おいて、 前記システム動作を持続性又は非持続性として及びトラ
ンザクション性又は非トランザクション性として定義す
る手段と、 持続性であると定義されたすべてのシステム動作に関連
しかつシステムの再始動に必要な完全な情報を含むレコ
ードを前記不揮発性記憶域に回復ログとして記憶し、ト
ランザクション性であると定義されたすべてのシステム
動作に関連しかつデータを含まずデータを見つけだすた
めの命令のみを含むレコードを、持続性動作か非持続性
動作かを問わず、前記揮発性記憶域に回復リストとして
記憶する手段と、 個々のトランザクションのロールバックを前記回復リス
トの参照によって行う手段と、 システムの再始動を前記回復ログの参照によって行う手
段と、 を具備することを特徴とするトランザクション処理シス
テム。 - 【請求項２】 前記回復ログ及び前記回復リストは対応
する動作が実行される前に前記不揮発性記憶域及び前記
揮発性記憶域にそれぞれ記憶されることを特徴とする請
求項1に記載のシステム。 - 【請求項３】 前記回復リストは処理されるトランザク
ションごとに作成されることを特徴とする請求項1又は
請求項2に記載のシステム。 - 【請求項４】 高速の揮発性記憶域及び低速の不揮発性
記憶域を有し、トランザクションをロールバックするか
又はシステムを再始動する必要がある場合に回復を可能
にするためにシステム動作に関連するレコードがシステ
ム内に記憶されているトランザクション処理システムで
フォールト・トレラント・トランザクション処理を行う
方法において、 システム動作を持続性又は非持続性として及びトランザ
クション性又は非トランザクション性として定義するス
テップと、 持続性として定義されたすべてのシステム動作に関連し
かつシステムの再始動に必要な完全な情報を含むレコー
ドを前記不揮発性記憶域に回復ログとして記憶し、トラ
ンザクション性として定義されたすべてにシステム動作
に関連しかつデータを含まずデータを見つけだすための
命令のみを含むレコードを、持続性であるか非持続性で
あるかを問わず、前記揮発性記憶域に回復リストとして
記憶するステップと、 前記回復リストを参照して個々のトランザクションのロ
ールバックを行うステップと、 前記回復ログを参照してシステムの再始動を行うステッ
プと、 を含むことを特徴とする方法。 - 【請求項５】 前記不揮発性記憶域に前記回復ログを記
録するステップ及び前記揮発性記憶域に前記回復リスト
を記録するステップの後に対応するシステム動作を実行
してトランザクションを処理することを特徴とする請求
項4に記載の方法。 - 【請求項６】 処理されるトランザクションごとに回復
リストを作成するステップを含むことを特徴とする請求
項4又は請求項5に記載の方法。 - 【請求項７】 トランザクション内のプロセスによって
実行される資源更新がトランザクションの解決の前に且
つ障害発生の後にアトミック的にバックアウトされるか
又はトランザクションの成功裡の完了時にコミットされ
るフォールト・トレラント・トランザクション指向デー
タ処理の方法において、 トランザクション内で実行される資源更新動作ごとに更
新される資源に関する相互排他セマフォ・ロックを取得
するステップと、 動作要求に応答してトランザクション内で更新動作を実
行するステップと、 動作がトランザクション内で実行されたことを示す標識
をセットすることによって動作要求を前記プロセスに対
してアクセス不能にするステップと、 相互排他セマフォ・ロックを解放するステップと、 トランザクションの成功裡の完了時に標識がセットされ
ているトランザクション内のすべての動作をコミットす
るステップと、 トランザクションの解決の前の障害発生に応答して標識
がセットされているトランザクション内のすべての動作
をバックアウトするステップと、 を含むことを特徴とする方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| GB9318167.5 | 1993-09-02 | ||
| GB9318167A GB2281644A (en) | 1993-09-02 | 1993-09-02 | Fault tolerant transaction-oriented data processing. |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JPH0784815A JPH0784815A (ja) | 1995-03-31 |
| JP2644188B2 true JP2644188B2 (ja) | 1997-08-25 |
Family
ID=10741363
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP6163804A Expired - Fee Related JP2644188B2 (ja) | 1993-09-02 | 1994-07-15 | フォールト・トレラント・トランザクション指向データ処理システムおよび方法 |
Country Status (5)
| Country | Link |
|---|---|
| US (2) | US6154847A (ja) |
| EP (1) | EP0642079B1 (ja) |
| JP (1) | JP2644188B2 (ja) |
| DE (1) | DE69422105D1 (ja) |
| GB (1) | GB2281644A (ja) |
Families Citing this family (155)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB2281644A (en) * | 1993-09-02 | 1995-03-08 | Ibm | Fault tolerant transaction-oriented data processing. |
| US6351754B1 (en) * | 1998-06-23 | 2002-02-26 | Oracle Corporation | Method and system for controlling recovery downtime |
| GB2343020A (en) * | 1998-10-19 | 2000-04-26 | Ibm | Handling transaction failures in a transaction processing system |
| JP4237354B2 (ja) * | 1999-09-29 | 2009-03-11 | 株式会社東芝 | トランザクション処理方法及びトランザクション処理システム |
| US6618822B1 (en) * | 2000-01-03 | 2003-09-09 | Oracle International Corporation | Method and mechanism for relational access of recovery logs in a database system |
| US7051173B2 (en) * | 2000-02-04 | 2006-05-23 | Fujitsu Limited | Backup system and method thereof in disk shared file system |
| US6658596B1 (en) * | 2000-03-13 | 2003-12-02 | International Business Machines Corporation | Automated queue recovery using element- based journaling |
| US6802022B1 (en) | 2000-04-14 | 2004-10-05 | Stratus Technologies Bermuda Ltd. | Maintenance of consistent, redundant mass storage images |
| US6842823B1 (en) | 2000-04-14 | 2005-01-11 | Stratus Technologies Bermuda Ltd | Methods and apparatus for persistent volatile computer memory |
| EP1277115A2 (en) * | 2000-04-14 | 2003-01-22 | Stratus Technologies Bermuda, Ltd. | Methods and apparatus for persistent volatile computer memory and related applications thereof |
| US6769074B2 (en) * | 2000-05-25 | 2004-07-27 | Lumigent Technologies, Inc. | System and method for transaction-selective rollback reconstruction of database objects |
| US8650169B1 (en) | 2000-09-29 | 2014-02-11 | Oracle International Corporation | Method and mechanism for identifying transaction on a row of data |
| US6631374B1 (en) | 2000-09-29 | 2003-10-07 | Oracle Corp. | System and method for providing fine-grained temporal database access |
| US6871271B2 (en) * | 2000-12-21 | 2005-03-22 | Emc Corporation | Incrementally restoring a mass storage device to a prior state |
| WO2002075483A2 (en) * | 2001-01-11 | 2002-09-26 | Nortel Networks Limtied | Check pointing of processing context of network accounting components |
| US6772363B2 (en) * | 2001-03-12 | 2004-08-03 | Hewlett-Packard Development Company, L.P. | Fast failover database tier in a multi-tier transaction processing system |
| US6961865B1 (en) * | 2001-05-24 | 2005-11-01 | Oracle International Corporation | Techniques for resuming a transaction after an error |
| US7454753B2 (en) * | 2001-06-27 | 2008-11-18 | International Business Machines Corporation | Semaphore management subsystem for use with multi-thread processor systems |
| US7089555B2 (en) | 2001-06-27 | 2006-08-08 | International Business Machines Corporation | Ordered semaphore management subsystem |
| GB0118294D0 (en) * | 2001-07-27 | 2001-09-19 | Ibm | Method and system for deadlock detection and avoidance |
| US7035859B2 (en) * | 2001-08-08 | 2006-04-25 | International Business Machines Corporation | Method and system for intra-table referential integrity for relational database systems |
| US6773083B2 (en) | 2001-08-29 | 2004-08-10 | Lexmark International, Inc. | Method and apparatus for non-volatile memory usage in an ink jet printer |
| US7143414B2 (en) | 2001-09-26 | 2006-11-28 | International Business Machines Corporation | Method and apparatus for locking multiple semaphores |
| US7406690B2 (en) * | 2001-09-26 | 2008-07-29 | International Business Machines Corporation | Flow lookahead in an ordered semaphore management subsystem |
| US7117479B2 (en) * | 2001-10-01 | 2006-10-03 | Sun Microsystems, Inc. | Language-sensitive whitespace adjustment in a software engineering tool |
| US7039671B2 (en) * | 2001-11-30 | 2006-05-02 | Sonic Software Corporation | Dynamically routing messages between software application programs using named routing nodes and named message queues |
| US7020599B1 (en) * | 2001-12-13 | 2006-03-28 | Oracle International Corporation (Oic) | Mean time to recover (MTTR) advisory |
| KR100453228B1 (ko) * | 2002-03-21 | 2004-10-15 | 한국전자통신연구원 | 공유 디스크 파일 시스템의 저널링 및 회복 방법 |
| US7430740B1 (en) * | 2002-04-12 | 2008-09-30 | 724 Solutions Software, Inc | Process group resource manager |
| US20030220935A1 (en) * | 2002-05-21 | 2003-11-27 | Vivian Stephen J. | Method of logical database snapshot for log-based replication |
| US20040003373A1 (en) * | 2002-06-28 | 2004-01-01 | Van De Vanter Michael L. | Token-oriented representation of program code with support for textual editing thereof |
| US7386834B2 (en) * | 2002-06-28 | 2008-06-10 | Sun Microsystems, Inc. | Undo/redo technique for token-oriented representation of program code |
| US7203706B2 (en) * | 2002-08-01 | 2007-04-10 | Oracle International Corporation | Buffered message queue architecture for database management systems with memory optimizations and “zero copy” buffered message queue |
| US7185034B2 (en) | 2002-08-01 | 2007-02-27 | Oracle International Corporation | Buffered message queue architecture for database management systems with guaranteed at least once delivery |
| US20040024771A1 (en) * | 2002-08-01 | 2004-02-05 | Oracle International Corporation | Buffered message queue architecture for database management systems with transactional enqueue support |
| US7181482B2 (en) * | 2002-08-01 | 2007-02-20 | Oracle International Corporation | Buffered message queue architecture for database management systems |
| US7185033B2 (en) | 2002-08-01 | 2007-02-27 | Oracle International Corporation | Buffered message queue architecture for database management systems with unlimited buffered message queue with limited shared memory |
| US7103597B2 (en) * | 2002-10-03 | 2006-09-05 | Mcgoveran David O | Adaptive transaction manager for complex transactions and business process |
| GB0225733D0 (en) * | 2002-11-05 | 2002-12-11 | Ibm | Persistent messaging in a transaction processing environment |
| US7036044B1 (en) * | 2002-11-15 | 2006-04-25 | Microsoft Corporation | Identifying appropriate undo during a forward pass through a log |
| CA2422176C (en) * | 2003-03-14 | 2009-07-21 | Ibm Canada Limited - Ibm Canada Limitee | Method and apparatus for interrupting updates to a database to provide read-only access |
| US20040225997A1 (en) * | 2003-05-06 | 2004-11-11 | Sun Microsystems, Inc. | Efficient computation of line information in a token-oriented representation of program code |
| US20040225998A1 (en) * | 2003-05-06 | 2004-11-11 | Sun Microsystems, Inc. | Undo/Redo technique with computed of line information in a token-oriented representation of program code |
| TW200509604A (en) * | 2003-05-08 | 2005-03-01 | Matsushita Electric Ind Co Ltd | Message processor, apparatus controlling device, home electrical appliance, program for message processor, microcomputer system, program for microcomputer system, and program product |
| US8365193B2 (en) | 2003-08-14 | 2013-01-29 | Oracle International Corporation | Recoverable asynchronous message driven processing in a multi-node system |
| US20050066235A1 (en) * | 2003-09-24 | 2005-03-24 | International Business Machines Corporation | Automated fault finding in repository management program code |
| US7739403B1 (en) | 2003-10-03 | 2010-06-15 | Juniper Networks, Inc. | Synchronizing state information between control units |
| US7231397B2 (en) * | 2003-10-24 | 2007-06-12 | Microsoft Corporation | Method and system for transacted file operations over a network |
| US7484215B2 (en) * | 2003-10-30 | 2009-01-27 | International Business Machines Corporation | Method, system and program product for processing a transaction |
| JP2007511008A (ja) * | 2003-11-04 | 2007-04-26 | コンスタント・データ、インコーポレイテッド | ハイブリッドリアルタイムデータレプリケーション |
| US7418462B2 (en) * | 2003-11-24 | 2008-08-26 | Microsoft Corporation | Optimized recovery logging |
| US7188273B2 (en) | 2003-11-24 | 2007-03-06 | Tsx Inc. | System and method for failover |
| US7296273B2 (en) * | 2003-12-04 | 2007-11-13 | International Business Machines Corporation | System, method and program tool to reset an application |
| US20050144617A1 (en) * | 2003-12-06 | 2005-06-30 | International Business Machines Corporation | Automatic configuration of reinstall information |
| US8140348B2 (en) * | 2004-01-30 | 2012-03-20 | International Business Machines Corporation | Method, system, and program for facilitating flow control |
| US7650606B2 (en) * | 2004-01-30 | 2010-01-19 | International Business Machines Corporation | System recovery |
| US7366801B2 (en) * | 2004-01-30 | 2008-04-29 | International Business Machines Corporation | Method for buffering work requests |
| KR100435985B1 (ko) * | 2004-02-25 | 2004-06-12 | 엔에이치엔(주) | 투표를 활용한 무정지 서비스 시스템 및 그 시스템에서의정보 갱신 및 제공 방법 |
| US8688634B2 (en) * | 2004-02-27 | 2014-04-01 | International Business Machines Corporation | Asynchronous peer-to-peer data replication |
| US7490083B2 (en) * | 2004-02-27 | 2009-02-10 | International Business Machines Corporation | Parallel apply processing in data replication with preservation of transaction integrity and source ordering of dependent updates |
| US20050209841A1 (en) * | 2004-03-22 | 2005-09-22 | Andreas Arning | Optimization of process properties for workflows with failing activities |
| US7870426B2 (en) * | 2004-04-14 | 2011-01-11 | International Business Machines Corporation | Apparatus, system, and method for transactional peer recovery in a data sharing clustering computer system |
| US7281153B2 (en) * | 2004-04-14 | 2007-10-09 | International Business Machines Corporation | Apparatus, system, and method for transactional peer recovery in a data sharing clustering computer system |
| US7499953B2 (en) * | 2004-04-23 | 2009-03-03 | Oracle International Corporation | Online recovery of user tables using flashback table |
| US7366857B2 (en) * | 2004-04-30 | 2008-04-29 | Hewlett-Packard Development Company, L.P. | Internal disk array mirror architecture |
| US8108429B2 (en) | 2004-05-07 | 2012-01-31 | Quest Software, Inc. | System for moving real-time data events across a plurality of devices in a network for simultaneous data protection, replication, and access services |
| US7565661B2 (en) | 2004-05-10 | 2009-07-21 | Siew Yong Sim-Tang | Method and system for real-time event journaling to provide enterprise data services |
| US7587429B2 (en) * | 2004-05-24 | 2009-09-08 | Solid Information Technology Oy | Method for checkpointing a main-memory database |
| US7680834B1 (en) | 2004-06-08 | 2010-03-16 | Bakbone Software, Inc. | Method and system for no downtime resychronization for real-time, continuous data protection |
| US20050289187A1 (en) * | 2004-06-29 | 2005-12-29 | Oracle International Corporation | System and method for investigating a data operation performed on a database |
| US8223785B2 (en) * | 2004-09-13 | 2012-07-17 | International Business Machines Corporation | Message processing and content based searching for message locations in an asynchronous network |
| US7979404B2 (en) | 2004-09-17 | 2011-07-12 | Quest Software, Inc. | Extracting data changes and storing data history to allow for instantaneous access to and reconstruction of any point-in-time data |
| US7904913B2 (en) | 2004-11-02 | 2011-03-08 | Bakbone Software, Inc. | Management interface for a system that provides automated, real-time, continuous data protection |
| US8631347B2 (en) * | 2004-11-15 | 2014-01-14 | Microsoft Corporation | Electronic document style matrix |
| US7716260B2 (en) * | 2004-12-16 | 2010-05-11 | Oracle International Corporation | Techniques for transaction semantics for a database server performing file operations |
| US7779418B2 (en) * | 2004-12-30 | 2010-08-17 | Oracle International Corporation | Publisher flow control and bounded guaranteed delivery for message queues |
| US7818386B2 (en) * | 2004-12-30 | 2010-10-19 | Oracle International Corporation | Repeatable message streams for message queues in distributed systems |
| JP2006203655A (ja) * | 2005-01-21 | 2006-08-03 | Ricoh Co Ltd | 画像形成装置設定方法、画像形成装置 |
| US7434211B2 (en) * | 2005-02-16 | 2008-10-07 | Microsoft Corporation | Transient shared computer resource and settings change bubble for computer programs |
| US7624308B2 (en) * | 2005-03-28 | 2009-11-24 | Microsoft Corporation | Failed message error recovery using application specific error queues |
| US7499955B2 (en) * | 2005-03-30 | 2009-03-03 | Microsoft Corporation | System and method for undoing application actions using inverse actions with atomic rollback |
| US7765186B1 (en) | 2005-04-13 | 2010-07-27 | Progress Software Corporation | Update-anywhere replication of distributed systems |
| US7426653B2 (en) * | 2005-04-13 | 2008-09-16 | Progress Software Corporation | Fault tolerant distributed lock management |
| US8010608B2 (en) * | 2005-06-07 | 2011-08-30 | Microsoft Corporation | Locked receive locations |
| US7809675B2 (en) * | 2005-06-29 | 2010-10-05 | Oracle International Corporation | Sharing state information among a plurality of file operation servers |
| US7788521B1 (en) * | 2005-07-20 | 2010-08-31 | Bakbone Software, Inc. | Method and system for virtual on-demand recovery for real-time, continuous data protection |
| US7689602B1 (en) | 2005-07-20 | 2010-03-30 | Bakbone Software, Inc. | Method of creating hierarchical indices for a distributed object system |
| US20070033157A1 (en) * | 2005-08-08 | 2007-02-08 | Simdesk Technologies | Transaction protection in a stateless architecture using commodity servers |
| US7657454B2 (en) * | 2005-08-09 | 2010-02-02 | Microsoft Corporation | Server-side project manager |
| US7606241B1 (en) | 2005-08-12 | 2009-10-20 | Juniper Networks, Inc. | Extending standalone router syntax to multi-chassis routers |
| US20070061351A1 (en) * | 2005-09-13 | 2007-03-15 | Microsoft Corporation | Shape object text |
| US8001526B2 (en) * | 2005-09-15 | 2011-08-16 | Microsoft Corporation | Hierarchical property storage |
| US7783971B2 (en) * | 2005-09-13 | 2010-08-24 | Microsoft Corporation | Graphic object themes |
| US7721205B2 (en) | 2005-09-15 | 2010-05-18 | Microsoft Corporation | Integration of composite objects in host applications |
| US20070061349A1 (en) * | 2005-09-15 | 2007-03-15 | Microsoft Corporation | Hierarchically describing shapes |
| GB0519033D0 (en) * | 2005-09-17 | 2005-10-26 | Ibm | Optimistic processing of messages in a messaging system |
| US8135857B1 (en) * | 2005-09-26 | 2012-03-13 | Juniper Networks, Inc. | Centralized configuration of a multi-chassis router |
| US7747999B1 (en) | 2005-09-26 | 2010-06-29 | Juniper Networks, Inc. | Software installation in a multi-chassis network device |
| US8196150B2 (en) * | 2005-10-07 | 2012-06-05 | Oracle International Corporation | Event locality using queue services |
| US7680793B2 (en) * | 2005-10-07 | 2010-03-16 | Oracle International Corporation | Commit-time ordered message queue supporting arbitrary read and dequeue patterns from multiple subscribers |
| US7518986B1 (en) | 2005-11-16 | 2009-04-14 | Juniper Networks, Inc. | Push-based hierarchical state propagation within a multi-chassis network device |
| US7804769B1 (en) | 2005-12-01 | 2010-09-28 | Juniper Networks, Inc. | Non-stop forwarding in a multi-chassis router |
| US7502716B2 (en) | 2006-04-10 | 2009-03-10 | International Business Machines Corporation | Closed-loop diagnostic method |
| US7996837B2 (en) * | 2006-05-03 | 2011-08-09 | Oracle International Corporation | Recovery mechanism for transactions |
| US7886099B2 (en) | 2006-06-16 | 2011-02-08 | Superspeed Llc | Systems and methods for providing a personal computer with non-volatile system memory |
| US7725764B2 (en) * | 2006-08-04 | 2010-05-25 | Tsx Inc. | Failover system and method |
| US8161010B2 (en) | 2006-10-04 | 2012-04-17 | Salesforce.Com, Inc. | Methods and systems for providing fault recovery to side effects occurring during data processing |
| US8682863B2 (en) | 2006-10-04 | 2014-03-25 | Salesforce.Com, Inc. | Methods and systems for bulk row save logic in an object relational mapping layer and application framework |
| US8548942B2 (en) | 2006-10-04 | 2013-10-01 | Salesforce.Com, Inc. | Methods and systems for recursive saving of hierarchical objects to a database |
| US7802136B2 (en) * | 2006-12-28 | 2010-09-21 | Intel Corporation | Compiler technique for efficient register checkpointing to support transaction roll-back |
| US8266221B2 (en) * | 2006-12-29 | 2012-09-11 | Sap Ag | Technique for data management in a distributed environment |
| US8131723B2 (en) | 2007-03-30 | 2012-03-06 | Quest Software, Inc. | Recovering a file system to any point-in-time in the past with guaranteed structure, content consistency and integrity |
| US8364648B1 (en) | 2007-04-09 | 2013-01-29 | Quest Software, Inc. | Recovering a database to any point-in-time in the past with guaranteed data consistency |
| US9027025B2 (en) | 2007-04-17 | 2015-05-05 | Oracle International Corporation | Real-time database exception monitoring tool using instance eviction data |
| US7895474B2 (en) * | 2007-05-03 | 2011-02-22 | International Business Machines Corporation | Recovery and restart of a batch application |
| US8140483B2 (en) * | 2007-09-28 | 2012-03-20 | International Business Machines Corporation | Transaction log management |
| US8387075B1 (en) * | 2008-03-28 | 2013-02-26 | Emc Corporation | Common scheduling and synchronization primitives |
| WO2010022246A2 (en) * | 2008-08-20 | 2010-02-25 | Wal-Mart Stores, Inc. | Process auto-restart systems and methods |
| US8572627B2 (en) * | 2008-10-22 | 2013-10-29 | Microsoft Corporation | Providing supplemental semantics to a transactional queue manager |
| US9128895B2 (en) | 2009-02-19 | 2015-09-08 | Oracle International Corporation | Intelligent flood control management |
| US8281185B2 (en) * | 2009-06-30 | 2012-10-02 | Oracle America, Inc. | Advice-based feedback for transactional execution |
| US9201684B2 (en) * | 2009-08-28 | 2015-12-01 | International Business Machines Corporation | Aiding resolution of a transaction |
| US8108721B2 (en) * | 2009-11-24 | 2012-01-31 | Honeywell International Inc. | Architecture and method for hardware-assisted processor checkpointing and rollback |
| US8458403B2 (en) * | 2009-11-24 | 2013-06-04 | Honeywell International Inc. | Architecture and method for cache-based checkpointing and rollback |
| US9165086B2 (en) | 2010-01-20 | 2015-10-20 | Oracle International Corporation | Hybrid binary XML storage model for efficient XML processing |
| US8458530B2 (en) | 2010-09-21 | 2013-06-04 | Oracle International Corporation | Continuous system health indicator for managing computer system alerts |
| US8341134B2 (en) | 2010-12-10 | 2012-12-25 | International Business Machines Corporation | Asynchronous deletion of a range of messages processed by a parallel database replication apply process |
| US9146944B2 (en) * | 2012-03-16 | 2015-09-29 | Oracle International Corporation | Systems and methods for supporting transaction recovery based on a strict ordering of two-phase commit calls |
| US9760584B2 (en) | 2012-03-16 | 2017-09-12 | Oracle International Corporation | Systems and methods for supporting inline delegation of middle-tier transaction logs to database |
| US9389905B2 (en) | 2012-03-16 | 2016-07-12 | Oracle International Corporation | System and method for supporting read-only optimization in a transactional middleware environment |
| JP5938965B2 (ja) * | 2012-03-19 | 2016-06-22 | 富士通株式会社 | マルチノードストレージシステムのノード装置および処理速度管理方法 |
| US9477944B2 (en) * | 2012-04-30 | 2016-10-25 | International Business Machines Corporation | Asynchronous serialization for aggregating process results |
| US9727625B2 (en) | 2014-01-16 | 2017-08-08 | International Business Machines Corporation | Parallel transaction messages for database replication |
| US9916325B2 (en) | 2014-09-30 | 2018-03-13 | International Business Machines Corporation | Quick initialization of data regions in a distributed storage system |
| US9904688B2 (en) | 2014-09-30 | 2018-02-27 | International Business Machines Corporation | Buffering and replicating data written to a distributed storage system |
| US9858312B2 (en) | 2014-10-14 | 2018-01-02 | Red Hat, Inc. | Transaction compensation for single phase resources |
| US10133768B2 (en) | 2015-04-14 | 2018-11-20 | Microsoft Technology Licensing, Llc | Latest external dependee entity in transaction record |
| US9766929B2 (en) * | 2015-04-14 | 2017-09-19 | Microsoft Technology Licensing, Llc | Processing of data stream collection record sequence |
| US9959137B2 (en) | 2015-04-14 | 2018-05-01 | Microsoft Technology Licensing, Llc | Transaction redo using skip element for object |
| US10592494B2 (en) * | 2015-04-14 | 2020-03-17 | Microsoft Technology Licensing, Llc | Collection record for overlapping data stream collections |
| US10031814B2 (en) | 2015-04-14 | 2018-07-24 | Microsoft Technology Licensing, Llc | Collection record location as log tail beginning |
| US10102251B2 (en) | 2015-04-14 | 2018-10-16 | Microsoft Technology Licensing, Llc | Lockless open collection data structure |
| US10565160B1 (en) * | 2015-09-21 | 2020-02-18 | Amazon Technologies, Inc. | Managing state changes of modeled objects in a three dimensional virtual environment |
| WO2017094096A1 (ja) * | 2015-12-01 | 2017-06-08 | 株式会社野村総合研究所 | トランザクション処理システムおよびトランザクション制御方法 |
| US10841148B2 (en) * | 2015-12-13 | 2020-11-17 | Microsoft Technology Licensing, Llc. | Disaster recovery of cloud resources |
| JP6764938B2 (ja) * | 2016-01-14 | 2020-10-07 | アビニシオ テクノロジー エルエルシー | リカバリ可能なストリーム処理 |
| US10540217B2 (en) | 2016-09-16 | 2020-01-21 | Oracle International Corporation | Message cache sizing |
| US10831509B2 (en) | 2017-02-23 | 2020-11-10 | Ab Initio Technology Llc | Dynamic execution of parameterized applications for the processing of keyed network data streams |
| US11947978B2 (en) | 2017-02-23 | 2024-04-02 | Ab Initio Technology Llc | Dynamic execution of parameterized applications for the processing of keyed network data streams |
| US11195176B2 (en) * | 2017-08-23 | 2021-12-07 | Visa International Service Association | System, method, and computer program product for stand-in processing |
| US11481362B2 (en) * | 2017-11-13 | 2022-10-25 | Cisco Technology, Inc. | Using persistent memory to enable restartability of bulk load transactions in cloud databases |
| US10649979B1 (en) | 2017-12-07 | 2020-05-12 | Amdocs Development Limited | System, method, and computer program for maintaining consistency between a NoSQL database and non-transactional content associated with one or more files |
| US11782900B2 (en) * | 2018-04-10 | 2023-10-10 | Walmart Apollo, Llc | High throughput order fullfillment database system |
| US10997153B2 (en) | 2018-04-20 | 2021-05-04 | Hewlett Packard Enterprise Development Lp | Transaction encoding and transaction persistence according to type of persistent storage |
| US11243703B2 (en) | 2018-04-27 | 2022-02-08 | Hewlett Packard Enterprise Development Lp | Expandable index with pages to store object records |
Family Cites Families (17)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB1505603A (en) * | 1976-07-07 | 1978-03-30 | Ibm | Data processing systems |
| US4498145A (en) * | 1982-06-30 | 1985-02-05 | International Business Machines Corporation | Method for assuring atomicity of multi-row update operations in a database system |
| EP0097239B1 (en) * | 1982-06-21 | 1989-09-27 | International Business Machines Corporation | Method and apparatus for restoring data in a computing system |
| US4507751A (en) * | 1982-06-21 | 1985-03-26 | International Business Machines Corporation | Method and apparatus for logging journal data using a log write ahead data set |
| JPH0827752B2 (ja) * | 1984-05-21 | 1996-03-21 | 富士通株式会社 | 資源ステータス保持装置 |
| US4751639A (en) * | 1985-06-24 | 1988-06-14 | Ncr Corporation | Virtual command rollback in a fault tolerant data processing system |
| US4868744A (en) * | 1986-03-03 | 1989-09-19 | International Business Machines Corporation | Method for restarting a long-running, fault-tolerant operation in a transaction-oriented data base system without burdening the system log |
| US4878167A (en) * | 1986-06-30 | 1989-10-31 | International Business Machines Corporation | Method for managing reuse of hard log space by mapping log data during state changes and discarding the log data |
| JPS63195755A (ja) * | 1987-02-09 | 1988-08-12 | Hitachi Ltd | 主記憶装置上の情報の内容保証方式 |
| JPS63307551A (ja) * | 1987-06-08 | 1988-12-15 | インターナシヨナル・ビジネス・マシーンズ・コーポレーシヨン | 先書きロギング型のトランザクシヨン向けシステム中のロールバツク方法 |
| US5043866A (en) * | 1988-04-08 | 1991-08-27 | International Business Machines Corporation | Soft checkpointing system using log sequence numbers derived from stored data pages and log records for database recovery |
| US5095421A (en) * | 1989-08-17 | 1992-03-10 | International Business Machines Corporation | Transaction processing facility within an operating system environment |
| 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 |
| US5201044A (en) * | 1990-04-16 | 1993-04-06 | International Business Machines Corporation | Data processing method for file status recovery includes providing a log file of atomic transactions that may span both volatile and non volatile memory |
| US5212788A (en) * | 1990-05-22 | 1993-05-18 | Digital Equipment Corporation | System and method for consistent timestamping in distributed computer databases |
| US5247644A (en) * | 1991-02-06 | 1993-09-21 | Advanced Micro Devices, Inc. | Processing system with improved sequential memory accessing |
| GB2281644A (en) * | 1993-09-02 | 1995-03-08 | Ibm | Fault tolerant transaction-oriented data processing. |
-
1993
- 1993-09-02 GB GB9318167A patent/GB2281644A/en not_active Withdrawn
-
1994
- 1994-07-15 JP JP6163804A patent/JP2644188B2/ja not_active Expired - Fee Related
- 1994-08-19 EP EP94306155A patent/EP0642079B1/en not_active Expired - Lifetime
- 1994-08-19 DE DE69422105T patent/DE69422105D1/de not_active Expired - Lifetime
- 1994-09-01 US US08/299,715 patent/US6154847A/en not_active Expired - Fee Related
-
2000
- 2000-07-12 US US09/615,518 patent/US6493826B1/en not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| DE69422105D1 (de) | 2000-01-20 |
| GB9318167D0 (en) | 1993-10-20 |
| US6493826B1 (en) | 2002-12-10 |
| JPH0784815A (ja) | 1995-03-31 |
| US6154847A (en) | 2000-11-28 |
| EP0642079B1 (en) | 1999-12-15 |
| GB2281644A (en) | 1995-03-08 |
| EP0642079A1 (en) | 1995-03-08 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP2644188B2 (ja) | フォールト・トレラント・トランザクション指向データ処理システムおよび方法 | |
| US5465328A (en) | Fault-tolerant transaction-oriented data processing | |
| US4868744A (en) | Method for restarting a long-running, fault-tolerant operation in a transaction-oriented data base system without burdening the system log | |
| US9223823B2 (en) | Transaction log management | |
| US10942823B2 (en) | Transaction processing system, recovery subsystem and method for operating a recovery subsystem | |
| US5923833A (en) | Restart and recovery of OMG-compliant transaction systems | |
| US6018746A (en) | System and method for managing recovery information in a transaction processing system | |
| US6526416B1 (en) | Compensating resource managers | |
| US7584474B2 (en) | Systems and methods for transaction chaining | |
| US20040215998A1 (en) | Recovery from failures within data processing systems | |
| US7430740B1 (en) | Process group resource manager | |
| KR101278818B1 (ko) | 트랜잭션 일관 및 문제 상태 | |
| US5745674A (en) | Management of units of work on a computer system log | |
| EP0582681A1 (en) | Distributed transaction processing system | |
| JPH10507558A (ja) | 分散システムにおけるログの削減 | |
| US6948093B2 (en) | Data processing arrangement and method | |
| US6092084A (en) | One system of a multisystem environment taking over log entries owned by another system | |
| US6848037B2 (en) | Data processing arrangement and method | |
| US6076095A (en) | Method of one system of a multisystem environment taking over log entries owned by another system | |
| Lindsay | Single and multi-site recovery facilities | |
| Salzberg et al. | DSDT: Durable scripts containing database transactions | |
| EP0817019B1 (en) | Method of stratified transaction processing | |
| JP4604032B2 (ja) | 非共有データベースシステムにおける１段階コミット | |
| Chundi et al. | Deferred Update Protocols for Multi-Site Transactions |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| LAPS | Cancellation because of no payment of annual fees |