(57)【要約】【課題】メッセージのキューを処理するための方法を提供すること。【解決手段】各メッセージはデータベースの更新に関する少なくとも１つの要求を表す。メッセージはブラウズされ、少なくとも１つの更新要求がメッセージから抽出される。更新要求は、更新されることになるデータベースに対する責務を負うデータベース管理システム（ＤＢＭＳ）に送信される。更新要求が偽更新要求であること、および、ＤＢＭＳは更新を実行すべきではないが対応する実更新が要求された場合に必要となるデータを事前に取り出すべきであることを示すインジケーションも、ＤＢＭＳに送信される。【選択図】  図１
2007501449.tif 000002
【特許請求の範囲】
【請求項１】
各メッセージがデータベースの更新に関する少なくとも１つの要求を表し、メッセージをブラウズするステップと、
ブラウズされたメッセージから更新要求を抽出するステップと、
更新されることになるデータベースに対する責務を負うデータベース管理システム（ＤＢＭＳ）に偽更新要求を送信するステップであって、
前記偽更新要求は、ＤＢＭＳは更新を実行すべきではないが対応する実更新が要求された場合に必要となるデータを事前に取り出すべきであることを示すインジケーションを有する、前記送信するステップとを有する
メッセージのキューを処理するための方法。
【請求項２】
前記偽更新要求を事前取り出し要求に変換するステップと、要求されたデータを事前に取り出すステップと、を有する、請求項１に記載の方法。
【請求項３】
前記更新要求を有するメッセージを破壊的に取得することによって実更新要求を開始するステップを有し、前記実更新要求は事前に取り出されたデータを使用する、請求項１に記載の方法。
【請求項４】
マスタ・スレッドが実更新要求の開始ステップを実行し、１つまたは複数の先読みスレッドがメッセージのブラウズ・ステップを実行する、請求項３に記載の方法。
【請求項５】
マスタ・スレッドを先読みスレッドの後方に所定の処理量で維持するステップを有する、請求項４に記載の方法。
【請求項６】
前記事前取り出し要求が所定の形式であり、前記方法は、所定の形式で保存するステップと、保存された所定の形式を識別してその後の実更新要求の実行で使用できるように、識別子を関連付けるステップと、前記偽更新要求に応答して識別子を戻すステップと、をさらに有する、請求項２に記載の方法。
【請求項７】
前記偽更新が、所定の形式の事前取り出し要求に変換され、ＤＢＭＳによって識別子と関連付けられるものであって、前記方法は、ＤＢＭＳから前記識別子を受け取るステップと、前記更新要求と共に前記識別子を送信することによって実更新要求を発行するステップとを有する、請求項１に記載の方法。
【請求項８】
使用された事前に取り出されたデータがメモリから廃棄される可能性があることを、メモリ・マネージャに通知するステップを有する、請求項１に記載の方法。
【請求項９】
ＤＢＭＳで更新要求を受け取るステップと、
前記更新要求が偽更新要求であること、およびその結果、ＤＢＭＳは前記更新を実行すべきではないが対応する実更新が要求された場合に必要となるデータを事前に取り出すべきであることを示すインジケーションを、ＤＢＭＳで受け取るステップと、
前記偽更新要求を事前取り出し要求に変換するステップと、
前記事前取り出し要求に基づいて要求されたデータを事前に取り出すステップとを有する、
データベース管理システム（ＤＢＭＳ）でＤＢＭＳによって制御されるデータベースへの更新要求を事前に処理するための方法。
【請求項１０】
実更新要求を受け取るステップと、前記実更新要求を実行するためにすでに事前に取り出されたデータを使用するステップとを有する、請求項９に記載の方法。
【請求項１１】
事前取り出し要求が所定の形式であり、前記方法は、前記所定の形式を保存するステップと、前記保存された所定の形式が識別され、実更新要求のその後の実行で使用できるように、前記保存された所定の形式と識別子を関連付けるステップと、前記識別子を前記偽更新要求に応答して戻すステップと、をさらに有する、請求項９に記載の方法。
【請求項１２】
前記識別子を実更新要求と共に受け取るステップと、前記実更新要求の実行時に、前記識別子に関連付けられた前記所定の形式を使用するステップと、を有する、請求項１１に記載の方法。
【請求項１３】
前記使用された事前に取り出されたデータがメモリから廃棄される可能性があることを、メモリ・マネージャに通知するステップを有する、請求項９に記載の方法。
【請求項１４】
各メッセージがデータベースへの更新に関する少なくとも１つの要求を表し、
メッセージをブラウズするための手段と、
ブラウズされたメッセージから更新要求を抽出するための手段と、
更新されることになるデータベースに対する責務を負うデータベース管理システム（ＤＢＭＳ）に偽更新要求を送信するための手段と、
を有するものであって、
前記偽更新要求は、ＤＢＭＳは前記更新を実行すべきではないが対応する実更新が要求された場合に必要となるデータを事前に取り出すべきであることを示すインジケーションを有する、
メッセージのキューを処理するための装置。
【請求項１５】
各メッセージがデータベースの更新に関する少なくとも１つの要求を表し、
コンピュータ上で実行された場合に、メッセージをブラウズするステップと、
ブラウズされたメッセージから更新要求を抽出するステップと、
更新されることになるデータベースに対する責務を負うデータベース管理システム（ＤＢＭＳ）に偽更新要求を送信するステップと、
が実行されるように適合されたプログラム・コード手段を有するものであって、
前記偽更新要求は、ＤＢＭＳは更新を実行すべきではないが対応する実更新が要求された場合に必要となるデータを事前に取り出すべきであることを示すインジケーションを有する、
メッセージのキューを処理するためのコンピュータ・プログラム。
【請求項１６】
コンピュータ上で実行された場合に、
ＤＢＭＳで更新要求を受け取るためのステップと、
前記更新要求が偽更新要求であること、およびその結果、ＤＢＭＳは更新を実行すべきではないが対応する実更新が要求された場合に必要となるデータを事前に取り出すべきであることを示すインジケーションを、ＤＢＭＳで受け取るためのステップと、
前記偽更新要求を事前取り出し要求に変換するためのステップと、
前記事前取り出し要求に基づいて要求されたデータを事前に取り出すためのステップとの、
方法を実行するように適合されたプログラム・コード手段を有する、
データベース管理システム（ＤＢＭＳ）でＤＢＭＳによって制御されるデータベースへの更新要求を事前に処理するためのコンピュータ・プログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明はデータ処理システムに関し、とりわけ、こうしたシステムによるメッセージのキューの処理に関する。
【背景技術】
【０００２】
データベースまたは他のシステム（メッセージング・システムなど）にアクションのシーケンスを「リプレイ（ｒｅｐｌａｙ）」することが必要な場合がしばしばある。
【０００３】
このシーケンスは、たとえば（リカバリで使用される）ログ・リプレイ、（データベースのレプリケーションで使用される）トランザクション変更リプレイ、または（おそらくＳＱＬまたはストアード・プロシージャ・レベル、あるいはより高度なアプリケーション・レベルでの、実行された呼び出しの監査ログの）呼び出しリプレイなど、様々なレベルで表すことができる。
【０００４】
しばしばオリジナル・アクションの実行は、論理順序（時には部分的な順序のみ）を保証するデータベース・トランザクションおよびロック技法と高度に並列処理された。この並列処理は、良好なシステム性能を達成するために不可欠であった。
【０００５】
データベース・トランザクションおよびロック技法によって保証された論理順序は、リプレイされるシーケンスで表される。問題は、リプレイが可能な限り高速でなければならないことであり、これにはある程度の並列処理も要求される。しかしながら、依然としてオリジナルの論理シーケンスを保持することも必要である。
【０００６】
一例として、リプレイされるシーケンスが作業項目のキューとして表されるシステムを考えてみる。それぞれの作業項目がオリジナルのトランザクションを表し、実行されることになるデータベース・レコード・レベル更新のリストを含む。
【０００７】
（本明細書で使用される更新という用語は、少なくともＳＱＬ  ＩＮＳＥＲＴ、ＤＥＬＥＴＥ、およびＵＰＤＡＴＥステートメント、ならびにデータ定義の更新などの任意の他の更新も含む、データベースを変更するどのような操作も含むものである。）
【０００８】
その自然な（かなり簡略化された）インプリメンテーションが、以下の単一の「ｍａｓｔｅｒ  ｔｒａｎｓａｃｔｉｏｎ」スレッドである。
//mastertransaction thread
for each work item // i.e. originatingtransaction
get (e.g. read) work item
for each record update in work item
apply update // e.g. record levelupdate
end for each update
commit (work item read operation anddatabase update operation)
end for each work item
【０００９】
しかしながら、各「ａｐｐｌｙ  ｕｐｄａｔｅ」（一般に、更新を適用する前に関連するデータベース・レコードを取り出す（たとえば読み取る）必要がある）は、現在データがデータベースに関連付けられたバッファプール内に保持されていないことを必要とする可能性が高いため、処理は停止され、必要なデータの取り出しが保留される。したがって、処理スループットに深刻な影響を与える可能性があるという点で問題である。
【００１０】
もちろん、標準データベースの遅延書き込み技法を使用することが可能であるため、実際に更新をデータベース・ディスクに戻すことについては対応する問題がないことも理解されよう。
【００１１】
この問題はメッセージング・システムに適用される場合があるが、これはそれほど重要ではない。ほとんどのキュー・アクティビティはキューの終わりに予測可能であるため、読み取られるメッセージのバッファプールを適切かつ予測的に事前に取り出すことができる。言い換えれば、キューは通常ＦＩＦＯ順に読み取られるため、予測的かつ順番に事前に取り出すことができる。
【００１２】
こうした予測をデータベース・システムで実行することはかなり困難である。それは、通常、データベースから順番に読み取られるレコードがデータベース・ディスク全体にわたって分散しており、データベースに関する作業は、順番に（すなわち隣接して）格納されたデータ・レコードを必要とする可能性が低いためである。
【００１３】
米国特許第６０９２１５４号は、マルチメディア環境におけるスレッド・リストを使用した事前キャッシュの方法を開示している。将来必要となるデータ（読み取り要求）のリストが、ホスト・アプリケーションによってデータ・ストレージ・デバイスに渡される。マルチメディア環境では、読み取り要求の結果として必要となるデータを、ホスト・アプリケーションによって容易に指定することができる。データベース環境では、ホスト・アプリケーションはデータが格納される方法を知らない場合があり、たとえ知っていても、ホスト・アプリケーションはこれを適切にデータ・ストレージ・デバイスに送ることができない場合がある。したがって、その後の操作に必要なデータの一部が使用できなくなる可能性がある。
【００１４】
米国特許第６４４９６９６号も、読み取り要求を使用した、リストの内容に基づいたディスクからのデータの事前取り出しについて開示している。
【特許文献１】米国特許第６０９２１５４号
【特許文献２】米国特許第６４４９６９６号
【発明の開示】
【発明が解決しようとする課題】
【００１５】
本発明の目的は、メッセージのキューを処理するための方法を提供することである。
【課題を解決するための手段】
【００１６】
したがって本発明は、メッセージのキューを処理するための方法を提供するものであり、各メッセージはデータベースの更新に関する少なくとも１つの要求を表し、当該方法は、メッセージをブラウズするステップと、ブラウズされたメッセージから更新要求を抽出するステップと、更新されることになるデータベースに対する責務を負うデータベース管理システム（ＤＢＭＳ）に偽更新要求を送信するステップとを有し、当該偽更新要求は、ＤＢＭＳは更新を実行すべきではないが対応する実更新が要求された場合に必要となるデータを事前に取り出すべきであることを示すインジケーションを有する。
【００１７】
好ましくは、偽更新要求は事前取り出し要求に変換され、要求されたデータが事前に取り出される。
【００１８】
好ましくは、続いて実更新要求が開始され、実更新要求は実行するために事前に取り出されたデータを使用する。好ましくは、更新を有するメッセージはキューから破壊的に取得される。好ましくは、更新の確認が実際に受け取られるまでメッセージのコピーが削除されないように、破壊的取得は実際のデータベース更新と整合される（２フェーズ・コミット）。
【００１９】
一実施形態では、マスタ・スレッドは更新要求の開始ステップを実行し、１つまたは複数の先読みスレッドはメッセージのブラウズ・ステップを実行する。
【００２０】
好ましくは、マスタ・スレッドは先読みスレッドの後方に所定の処理量で維持される。この処理量はメッセージ、更新などに関して測定可能であり、必要な場合にデータがメモリ内に存在することを保証するのに役立つ。マスタ・スレッドが近づき過ぎると、実行される予定の更新要求に必要な場合に、必要なデータがメモリ内に存在しない可能性があるという危険がある。他方で、マスタ・スレッドが遅れ過ぎる場合、メモリが満杯になり、その結果まだ使用されていないデータを上書きしなければならなくなるという危険がある。
【００２１】
一実施形態では、事前取り出し要求は保存された所定の形式であり、保存された所定の形式を識別してその後の実更新要求の実行で使用できるように、識別子がそれに関連付けられる。好ましくは、識別子は偽更新要求に応答して戻される。
【００２２】
一実施形態では、偽更新は所定の形式の事前取り出し要求に変換され、ＤＢＭＳによって識別子と関連付けられる。識別子はＤＢＭＳから受け取られ、実更新要求の発行に使用される。
【００２３】
好ましいことには、更新要求のために事前に取り出されたデータを使用することに応答して、使用された事前に取り出されたデータがメモリから廃棄される可能性があることがメモリ・マネージャに通知される。これにより、メモリが満杯にならないようにすることができる。
【００２４】
一態様によれば、データベース管理システム（ＤＢＭＳ）でＤＢＭＳによって制御されるデータベースへの更新要求を事前に処理するための方法が提供され、当該方法は、ＤＢＭＳで更新要求を受け取るステップと、更新要求が偽更新要求であること、およびその結果、ＤＢＭＳは更新を実行すべきではないが対応する実更新が要求された場合に必要となるデータを事前に取り出すべきであることを示すインジケーションを、ＤＢＭＳで受け取るステップと、偽更新要求を事前取り出し要求に変換するステップと、事前取り出し要求に基づいて要求されたデータを事前に取り出すステップとを有する。
【００２５】
好ましくは、その後実更新要求が受け取られ、すでに事前に取り出されたデータを使用して実更新要求が実行される。
【００２６】
一実施形態では、事前取り出し要求は所定の形式であり、保存される。好ましくは、その後識別子は、保存された所定の形式が識別され、実更新要求のその後の実行で使用できるように、保存された所定の形式と関連付けられる。好ましくは、識別子は偽更新要求に応答して戻される。
【００２７】
一実施形態では、識別子は実更新要求と共に受け取られ、実更新要求の実行時に使用される。
【００２８】
他の態様によれば、メッセージのキューを処理するための装置が提供され、各メッセージはデータベースへの更新に関する少なくとも１つの要求を表し、当該装置は、メッセージをブラウズするための手段と、ブラウズされたメッセージから更新要求を抽出するための手段と、更新されることになるデータベースに対する責務を負うデータベース管理システム（ＤＢＭＳ）に偽更新要求を送信するための手段と、を有するものであり、当該偽更新要求は、ＤＢＭＳは更新を実行すべきではないが対応する実更新が要求された場合に必要となるデータを事前に取り出すべきであることを示すインジケーションを有する。
【００２９】
他の態様によれば、データベース管理システム（ＤＢＭＳ）でＤＢＭＳによって制御されるデータベースへの更新要求を事前に処理するための装置が提供され、当該装置は、ＤＢＭＳで更新要求を受け取るための手段と、更新要求が偽更新要求であること、およびその結果、ＤＢＭＳは更新を実行すべきではないが対応する実更新が要求された場合に必要となるデータを事前に取り出すべきであることを示すインジケーションを、ＤＢＭＳで受け取るための手段と、偽更新要求を事前取り出し要求に変換するための手段と、事前取り出し要求に基づいて要求されたデータを事前に取り出すための手段とを有する。
【００３０】
他の態様によれば、メッセージのキューを処理するためのコンピュータ・プログラムが提供され、各メッセージはデータベースの更新に関する少なくとも１つの要求を表し、当該コンピュータ・プログラムは、コンピュータ上で実行された場合に、メッセージをブラウズするステップと、ブラウズされたメッセージから更新要求を抽出するステップと、更新されることになるデータベースに対する責務を負うデータベース管理システム（ＤＢＭＳ）に偽更新要求を送信するステップとが実行されるように適合されたプログラム・コード手段を有し、当該偽更新要求は、ＤＢＭＳは更新を実行すべきではないが対応する実更新が要求された場合に必要となるデータを事前に取り出すべきであることを示すインジケーションを有する。
【００３１】
他の態様によれば、データベース管理システム（ＤＢＭＳ）でＤＢＭＳによって制御されるデータベースへの更新要求を事前に処理するためのコンピュータ・プログラムが提供され、当該コンピュータ・プログラムは、コンピュータ上で実行された場合に、ＤＢＭＳで更新要求を受け取るためのステップと、更新要求が偽更新要求であること、およびその結果、ＤＢＭＳは更新を実行すべきではないが対応する実更新が要求された場合に必要となるデータを事前に取り出すべきであることを示すインジケーションを、ＤＢＭＳで受け取るためのステップと、偽更新要求を事前取り出し要求に変換するためのステップと、事前取り出し要求に基づいて要求されたデータを事前に取り出すためのステップとの、方法を実行するように適合されたプログラム・コード手段を有する。
【発明を実施するための最良の形態】
【００３２】
図１は、従来技術に従ったデータベース・システムを示す図である。システム１０は、処理のための作業のキュー２０の項目（メッセージ）を有する。それぞれの作業項目は、データベース３０内のレコードに対する少なくとも１つの更新を表す。
【００３３】
作業のキュー２０は右から左へ読み取られ（ＦＩＦＯ順）、データベース３０から要求されるデータはデータ項目（レコード）Ａ、Ｂ、Ｃ、Ｄとみなすことができる。（各作業項目は複数の更新を表す場合があるため、データベース３０からの複数のレコードを必要とする場合があることに留意されたい。）
【００３４】
適用アプリケーション４０はキュー２０から読み取り、適切なデータを（データベース・インターフェース４５を介して）データベース管理システム（ＤＢＭＳ）７０に要求する。ＤＢＭＳは、バッファプール・マネージャ（図示せず）を介してバッファプール６０（揮発性メモリ）にデータを要求する照会プロセッサ５０（パーサ（ｐａｒｓｅｒ）を含む）を含む。起こり得ることであるが、バッファプール内にデータが見つからなかった場合、データはデータベースそれ自体から取り出さなければならない。データベースは何千ものレコードをディスク上に格納している可能性があり、データが予測できる順序で格納される可能性は低いため、要求されたデータがバッファプール６０に取り出される間に、システム・スループットはかなりの影響を受ける可能性がある。この例では、作業のキュー２０はレコードＡ、Ｂ、Ｃ、およびＤがその順序で取り出される必要があるが、ディスクはこうしたレコードをまったく異なる順序（Ａ、Ｃ、Ｄ、Ｂ）で格納する。このため、データベースにとって、レコードを予測的に（すなわち、通常は起こった順に）事前に取り出すこと、たとえばＡを読み取った後にＣを取得することは役に立たない。
【００３５】
本発明はこの問題に対処する。図２は、好ましい実施形態に従った本発明の処理を示す図であり、図１と共に読むものとする。
【００３６】
適用アプリケーション４０内の主先読みスレッドは、キュー２０からそれぞれの作業項目をブラウズする（ステップ１００）。前述のように、各作業項目はデータベース３０の少なくとも１つの要求された更新を備える。こうした要求された各更新について、先駆的（ｐｉｏｎｅｅｒ）更新スレッドが作成される（ステップ１１０）。各先駆的更新スレッドは、要求された場合に適切な更新がデータベース３０に適用できるように、（ＤＢＭＳ  ５０を介して）要求されたデータのバッファプール６０への取り出しを開始する（ステップ１２０）。
【００３７】
先駆的更新スレッドはデータベースそれ自体を変更しない（データを読み取るのみ）ため、これらを並列に適用するのは容易である。この並列処理により、データベースはそのＩ／Ｏパターンを（オリジナル・トランザクションを並列に実行する際と同じ方法で）最適化することができる。
【００３８】
先駆的呼び出しを完全に実施することによって、好ましくは、レコードおよびインデックスの両方に関するすべての関連データが確実にバッファプールに読み込まれる。たとえば、人物番号１２３４から５００００の給与を設定する更新を例にとってみる。これにはおそらく人物レコードそれ自体、および人物番号に関する人物テーブルへのインデックスが含まれる。給与に関するインデックスがある場合、それも好ましくは事前に取り出される。
【００３９】
先駆的更新（偽更新）を達成する際には、以下の３つのメカニズムが使用できる。
【００４０】
メカニズムＡ：先駆的スレッドが更新要求を、照会（すなわち、更新それ自体を実際に実行するのではなく、適切なデータを事前に取り出すための照会）である関連する事前取り出し要求に変換し、その要求をデータベースに発行する。したがって、先駆的呼び出しは人物番号１２３４に関する照会でシミュレートされる。
【００４１】
メカニズムＢ：呼び出しが先駆的呼び出し（偽更新要求）であって「実」更新ではない旨を、先駆的スレッドがデータベースに指示できるようにするために、データベース・インターフェース４５が拡張される。先駆的スレッドは、作業項目から更新要求を抽出し（図３のステップ２００）、その更新要求をＤＢＭＳに送信し（ステップ２１０）、ＤＢＭＳが要求されたデータを取り出すために偽更新要求を事前取り出し要求に変換できるように、これが偽更新要求である旨を（更新要求を備えたインジケーションを介して）ＤＢＭＳに通知する（ステップ２２０）。
【００４２】
メカニズムＣ：（事前取り出し要求を開始している）先駆的スレッドからの呼び出し、およびマスタ・トランザクション・スレッド（すなわち、要求された更新をその後実行するスレッド）からの呼び出しが、たとえば呼び出し間の更新のためにトークン（識別子）を渡すことによって、明示的に関連付けられるように、データベース・インターフェース４５がさらに拡張される。メカニズムＣは、好ましくはメカニズムＢの拡張であることに留意されたい。
【００４３】
メカニズムＡは、データベースへの変更を含まない。しかしながら、更新を関連する照会に変換する際の適用アプリケーションによる作業をさらに含む。照会がバッファプール内のすべての適切なデータをデータベースに読み取らせない可能性もあり、この例では、給与に関するインデックスの関連部分も同様に事前に取り出されない場合がある。これは、適用アプリケーションが、データベースがその情報をどのように格納しているかを完全に理解していない場合があるため、または適切な要求をＤＢＭＳに送るのが困難であるとわかる場合があるためである。これらの問題は、メカニズムＢで解決される。
【００４４】
メカニズムＢでは、偽更新要求は事前取り出し要求に変換され、対応する実更新が実行される場合に必要となるデータを取り出すために使用される。ＤＢＭＳは事前取り出し要求を作成するため、特定の実更新要求に関するすべての要求されたデータが事前に取り出されることになる可能性がかなり高い。ＤＢＭＳはデータが格納される方法を知っており、これを適切な事前取り出し要求に効果的に変換することができる。
【００４５】
メカニズムＣについてより詳細に説明すると、先駆的更新要求は適用アプリケーションによって作成される場合、照会プロセッサが更新要求を内部（所定の）形式に解析するために照会プロセッサに送られる。この内部形式は、データベースから取り出すデータを決定する際に使用される。データがいったん取り出されると、この内部形式は廃棄することができる。しかしながらこれを実行すると、マスタ・スレッドが実更新の実行を望む場合、更新要求を再度解析しなければならなくなる。
【００４６】
時間および処理能力を節約するために、照会プロセッサは、先駆的更新要求の結果として生じる解析済みの内部形式を保存することが可能であり、これを適用アプリケーションに戻されるトークンに関連付けることができる。マスタ・トランザクション・スレッドが更新要求の実行を望む場合、適用アプリケーションは同じトークンをＤＢＭＳに渡すことが可能であり、これを使用してその要求の適切な解析済み内部形式を決定することができる。この改良により、二重解析の必要がなくなる。
【００４７】
メカニズムＣの照会トークンも、好ましくは、事前に取り出されたデータ項目がもはや不要であることをバッファプール・マネージャ（図示せず）が決定するために使用される。更新を適用するために適用アプリケーションからＤＢＭＳにトークンが戻される場合、関連するデータがバッファプールから取り出され、トークンに関連付けられたデータがバッファプールから除去可能であることを示すために、好ましくは、トークンはバッファプール・マネージャに渡される。こうした状況に限り、好ましくはデータがバッファプールから除去される。
【００４８】
これによって、事前に取り出されたデータが、要求される前にバッファプールから除去されるリスク、あるいは逆に、他のデータに損害を与えてバッファプール内に長く保持されすぎるリスクが減少することになる。
【００４９】
メカニズムＡは、データベースの実施またはインターフェースを変更せずに適用アプリケーションによって実施可能であるが、メカニズムＢおよびＣは、データベースのインターフェースおよび実施を変更する必要があることに留意されたい。
【００５０】
前述のように、主先読みスレッドは（同様に適用アプリケーション４０内で実行中の）マスタ・トランザクション・スレッドよりも先に動作する。マスタ・トランザクション・スレッドは、先読みスレッドが以前に実行した方法と同じ方法で各作業項目を取得するが、今回は、要求された更新を実際に実行するために作業項目は実際にキューから除去される。先読み（および先駆的スレッド）は、マスタ・トランザクション・スレッドがデータを要求することになるより前に決定されているため、必要なデータはすでにバッファプール６０に取り出されているはずである。したがってバッファプール・マネージャは、要求された更新を実行するために、マスタ・スレッドが要求したデータをバッファプール６０から直接取り出すことができるはずである。要求されたデータは即時使用可能であるため、Ｉ／Ｏは停止されず、性能は大幅に向上する。（前述のように、標準的な遅延書き込みを使用して、更新されたデータを実際にディスクに戻すことができる。）
【００５１】
マスタ・トランザクション・スレッドが主先読みスレッドに近づき過ぎないこと、または遅れ過ぎないことは、性能の面で重要である。（マスタ・スレッドが遅れ過ぎると、古いデータがまだ使用されていない場合、バッファプールを新しいデータで上書きしなければならない可能性があり、マスタ・スレッドが近づき過ぎると、データは要求される前にバッファプールに正しく事前取り出しされていない可能性がある。）
【００５２】
したがって、これが生じるのを防ぐために、主先読みスレッドとマスタ・トランザクション・スレッドとの間に何らかの形の信号通知があることが好ましい。
【００５３】
したがって好ましくは、主先読みスレッド（および結果としてその先駆的スレッド）は、（たとえば、処理された作業項目、処理された更新、または処理されたバイトで測定された）所定量（ｒｅｑｕｉｒｅｄＲｅａｄａｈｅａｄ）を超えずにマスタ・トランザクション・スレッドより先行できる。
【００５４】
したがって、適用アプリケーション４０は２つのカウンタ、ｒｅａｄａｈｅａｄＡｍｏｕｎｔＰｒｏｃｅｓｓｅｄおよびｍａｓｔｅｒＡｍｏｕｎｔＰｒｏｃｅｓｓｅｄを有する。好ましい実施形態では、ｒｅｕｉｒｅｄＲｅａｄａｈｅａｄ値は処理された作業項目に関して測定される。先読みスレッドが次の作業項目に移動するごとに、ｒｅａｄａｈｅａｄＡｍｏｕｎｔＰｒｏｃｅｓｓｅｄが増分される。マスタ・スレッドによる作業項目の処理が完了するごとに、ｍａｓｔｅｒＡｍｏｕｎｔＰｒｏｃｅｓｓｅｄが増分される。主先読みスレッドは、以下のような、先読みスレッドによって制御される任意の先駆的スレッドもスリープさせるスリープ・ループを含む。
while(readaheadAmountProcessed-masterAmountProcessed > requiredReadahead) sleep(10)
【００５５】
この方法では、先読みスレッドが主スレッドから先行し過ぎることはない。そうでない場合にはバッファプール６０が満杯になってしまい、その結果、まだ使用されていない可能性のあるデータの除去を余儀なくする危険があるため、これは重要なことである。
【００５６】
マスタ・スレッドは、以下のようなスリープ・ループも含む。
while(readaheadAmountProcessed-masterAmountProcessed < requiredReadahead) sleep(10)
【００５７】
これにより、マスタ・スレッドが主先読みスレッドを追い越さないことが保証される。
【００５８】
先読み項目の完了は規則的に生じない可能性があるため、先読みがどの程度にまで達したかを精密に定義することは困難であることに留意されたい。したがって、どの先駆的更新が完了したかを精密にするために、この信号通知をより高度に実行することができる。
【００５９】
第１の更新の実行が、その後の更新を実施するために読み取らなければならないデータを変更するような形で、更新が互いに依存している場合があることに留意されたい。たとえば、以下のとおりである。
［０］初めに、フレッドはＹ部門にいる。
［１］フレッドはＸ部門に移動する。
［２］フレッドの部門のマネージャをビルに変更する。
【００６０】
［１］の先駆的実行は、フレッドに関するデータをバッファプールに読み込む。このデータはその後、マスタ・トランザクション・スレッドが［１］を実行した場合に使用される。［２］の先駆的実行はこの更新より前に生じる可能性があるため、Ｙ部門（フレッドの以前の部門）に関するデータをバッファプールに読み込むことになる。しかしながら、［２］の実実行は、Ｘ部門に関するデータをバッファプールに読み込む必要がある。
【００６１】
こうした場合、マスタ・トランザクション・スレッドは、対応する実更新が実行されている間（すなわち、要求されたデータがバッファプール内にないために）、停止する可能性がある。これにより性能は若干低下するにもかかわらず、一般に、従来技術の方法よりはかなり改善されることになる。（トランザクション自体の不適切な処理が終了することになるため）不正な結果は発生させないことに留意されたい。
【００６２】
改良／変形
次に、前述の基本的な考えに基づくいくつかの改良／変形について論じる。
【００６３】
これまでに論じた実施形態では、各先駆的更新について作成され、その作業の完了時に終了する、新しいスレッドと共に単一の先読みスレッドを使用する。
【００６４】
しかしながら、スレッドの作成／終了は費用のかかるプロセスである。したがって、その代わりにスレッド・プールを使用することができる。この実施形態では、先駆的更新スレッドのプールは継続的に使用可能であり、それらの作業が終了すると、後で再度使用するためにプールに戻る。
【００６５】
他のオプション（スレッド・プールと共に使用できる）は複数の先読みスレッドを有することになり、複数の先読みスレッドについて作業を共有する。一実施形態では、先読みスレッドのプールも使用される。
【００６６】
さらに複数の先読みスレッドは、好ましくはどの作業項目に対して責務を負っているかを互いに信号通知する。この方法では、１つの先読みスレッドは他の先読みスレッドによってすでに完了された（または完了過程にある）作業は実行しようとしないため、努力が不必要に重複することがない。
【００６７】
非常に単純な実施は、第１の先読みスレッドが作業項目１、４、および７に対する責務を負い、第２の先読みスレッドが作業項目２、５、および８をブラウズし、第３の先読みスレッドが作業項目３、６、および９に対する責務を負っているというものである。
【００６８】
基本原理に基づく他の改良は、バッチングの使用である。オリジナル・トランザクションは並列に実行されるため、それらの（バックアップのための）ログ強制はボックスカー（ｂｏｘｃａｒ）（並列バッチング）が可能である。これは、ログ強制がプロセッサ集中であり、強制が完了するまで他の処理を止めるため、有用である。
【００６９】
マスタ・トランザクション・スレッドは単一にスレッド化される（これは論理順序を保存するために重要である）ため、ボックスカー化は適用しない。しかしながら、トランザクション・バッチングは、ある量の処理が実施された後にのみ、実施されるコミット操作で使用可能である（時間、メッセージ数、更新数、バイト数に関して測定される）。各コミット操作もログに対する強制操作を実行させるため、複数の（時間のかかる）ログ強制でマスタ・トランザクション・スレッドへ連続して割り込むのではなく、トランザクション・バッチングは一回でより多くの量のデータを強制することができる。
【００７０】
他のオプションは、ペアのマスタ・トランザクション・スレッドを使用することである。単一のマスタ・トランザクション・スレッドでは、このスレッドは処理のために更新のバッチをＤＢＭＳに送信し、その後コミットを送信する（またはコマンドを終了する）ことになる。その後マスタ・トランザクション・スレッドは、ＤＢＭＳがデータベース・ディスクに強制された更新を実行する間、待機しなければならない。マスタ・スレッドから（コミットから）制御が戻されるまで待機する間、他のスレッドが他の更新のバッチを処理すること、たとえば、各バッチのログ強制が後続のバッチの処理と並列処理されることが好ましい。
【００７１】
以上、本発明について、データベースへのアクションのシーケンスをリプレイすることに関して説明してきたが、こうしたことに限定されないことを理解されよう。データへのランダム・アクセスを含み、メッセージのキューが処理される任意の環境に適用可能である。
【図面の簡単な説明】
【００７２】
【図１】従来技術に従ったデータベース・システムを示す図である。
【図２】好ましい実施形態に従った本発明の処理を示す図である。
【図３】好ましい実施形態に従った本発明の処理を示す図である。
【図１】
2007501449.tif 000003
【図２】
2007501449.tif 000004
【図３】
2007501449.tif 000005
【国際調査報告】
2007501449.tif 000006
2007501449.tif 000007
2007501449.tif 000008