JP3587445B2 - マルチシステム環境のシステムがログ・ストリームを圧縮する頻度を歩調合わせする方法 - Google Patents
マルチシステム環境のシステムがログ・ストリームを圧縮する頻度を歩調合わせする方法 Download PDFInfo
- Publication number
- JP3587445B2 JP3587445B2 JP2000060776A JP2000060776A JP3587445B2 JP 3587445 B2 JP3587445 B2 JP 3587445B2 JP 2000060776 A JP2000060776 A JP 2000060776A JP 2000060776 A JP2000060776 A JP 2000060776A JP 3587445 B2 JP3587445 B2 JP 3587445B2
- Authority
- JP
- Japan
- Prior art keywords
- log stream
- compression
- certain
- frequency
- rate
- 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 - Lifetime
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
- H04L69/04—Protocols for data compression, e.g. ROHC
Landscapes
- Engineering & Computer Science (AREA)
- Computer Security & Cryptography (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Debugging And Monitoring (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は一般に、マルチシステム環境のログ・ストリームの管理に関し、特に、ログ・ストリームがマルチシステム環境のシステムにより圧縮される頻度の歩調合わせ（ペーシング）に関する。
【０００２】
【従来の技術】
様々なコンピュータ・システムにおいて、履歴ログ・データが例えばログ・ファイル内に保持され、システム回復、問題判別、及びシステム保守のために使用される。一般に、これらのログ・ファイルは、履歴データを保存するための限られた容量を有する。容量が満杯になると、少なくとも一部のデータ記録がログ・ファイルから直接アクセス記憶装置（ＤＡＳＤ）などの外部記憶装置に移動され、それによりログ・ファイル内に追加のデータのための追加の空間を提供する。
【０００３】
ある時点で、ログ・ファイル内または外部記憶装置上のデータは、もはや必要とされなくなる。例えば、一旦データがその保存要件を過ぎると、そのデータを保持する必要性が無くなる。データをその有効期限を過ぎて保管することは、多くの点でシステム性能に悪影響を及ぼす。例えば、不要なデータが保存され、故障の回復の間にログ・データを回復するために、ログ・ファイルが走査検索される必要がある場合、ブラウザは潜在的に大きな容量の不要データを扱わねばならず、その結果、回復プロセスを遅らせることになる。更に、不要なデータ記録の保管は、一般にデータへの低速アクセスを提供する外部記憶装置の使用を要求し、そのためにデータの読出しに長い時間を要し、システム性能に影響することになる。
【０００４】
従って、あらゆる不要なデータをログ・ファイルから消去することが好都合である。これはログ・ファイルを圧縮し、次に消去され得るあらゆるエントリを物理的に消去することにより達成される。ログ・ファイルがマルチシステム環境の様々なシステムにより使用されるとき、各システムはその不要なエントリを圧縮し、消去する責任を担う。
【０００５】
しかしながら、マルチシステム環境のシステムが異なるトランザクション・レートで処理しており、低速のシステムが高速のシステムに釣り合うレートで、ログ・ファイルを十分に圧縮できない場合、低速のシステムは高速のシステムの性能に悪影響を及ぼす。これはトランザクション・レートの不均衡の理由がハードウェア性能特性であるか、作業負荷の差であるかに関わらず当てはまる。従って、高速のシステムは潜在的に、低速のシステムよりもより多くの要素をログ・ファイル内に有し、高速のシステムの要素は、低速のシステムにより書込まれる１つの要素により分離され得る。この問題は、幾つかの高速のシステムと、単一の低速のシステムだけが存在する状況において悪化し得る。
【０００６】
【発明が解決しようとする課題】
前述の状況を鑑み、システムがマルチシステム・ログ・ファイルを圧縮する頻度を歩調合わせする機能が待望される。更に、各システムが他のシステムの圧縮レートにもとづき、その圧縮レートを調整することを可能にし、最小サイズのログ・ファイルを保証する機能が待望される。更に、圧縮の頻度が、ログ・ファイルに接続されるシステムの現トランザクション・レートにもとづき、リアルタイムに調整されることを可能にする、歩調合わせ技術が待望される。
【０００７】
【課題を解決するための手段】
マルチシステム・ログ・ストリームが圧縮される頻度を歩調合わせする方法の提供により、従来技術の欠点が克服され、追加の利点が提供される。１例では、マルチシステム・ログ・ストリームがマルチシステム環境のあるシステムにより圧縮されるレートが確認される。ここでレートは、マルチシステム・ログ・ストリームが、マルチシステム環境の少なくとも１つの他のシステムにより圧縮される頻度との比較で示される。あるシステムがマルチシステム・ログ・ストリームを圧縮する頻度が、リアルタイムに調整される。
【０００８】
１実施例では、あるシステムの圧縮遅れカウントをチェックすることにより、レートが確認される。圧縮遅れカウントは、マルチシステム・ログ・ストリームが少なくとも１つの他のシステムにより圧縮される頻度との比較において、あるシステムがマルチシステム・ログ・ストリームを圧縮しているレートを表す。
【０００９】
別の実施例では、確認されたレートから、あるシステムが、少なくとも１つの他のシステムよりも遅いレートでマルチシステム・ログ・ストリームを圧縮していることが判明するとき、そのシステムがマルチシステム・ログ・ストリームを圧縮する頻度を増加することにより、圧縮の頻度を調整する。例えば、頻度の増加は、あるシステムによる圧縮の実行を強制するステップを含む。
【００１０】
更に別の実施例では、本方法は、確認されたレートから、あるシステムが圧縮を実行する頻度を増加すべきか否かを、所定の時間間隔で決定するステップを含む。
【００１１】
更に別の実施例では、あるシステムの確認されたレートが、選択値と所定の関係を有すると判断されるとき、所定の時間間隔が減少される。例えば、選択値は、マルチシステム・ログ・ストリームに接続されるシステムの数から１を差し引いた値の２倍である。
【００１２】
本発明の別の実施例では、マルチシステム・ログ・ストリームが圧縮される頻度を歩調合わせする方法が提供される。この方法は、例えば、マルチシステム・ログ・ストリームが、マルチシステム環境のあるシステムにより圧縮されるレートを確認するステップと、所定の時間間隔で、確認されたレートを所定値と比較し、あるシステムがマルチシステム・ログ・ストリームを圧縮する頻度が、調整されるべきか否かを決定するステップと、比較が調整の必要性を示す場合、あるシステムがマルチシステム・ログ・ストリームを圧縮する頻度をリアルタイムに調整するステップと、所定の時間間隔が変更されるべきか否かを決定するステップと、所定の時間間隔が変更されるべきと決定される場合、所定の時間間隔を変更し、比較が実行される頻度を調整するステップとを含む。
【００１３】
本発明の圧縮歩調合わせ機能は、システムがマルチシステム・ログ・ストリームを圧縮する頻度をリアルタイムに有利に調整する。各システムはその圧縮レートを他のシステムの圧縮レートにもとづき調整し、最小サイズのログ・ストリームを保証する。これはログ・ストリームが結合機構内にもっぱら含まれる可能性を増加させ、アクティブ・データを外部記憶装置にオフロードすることにより生じる、システム性能の低下の可能性を減少させる。本発明の技術は、異なるプロセッサ能力などの永久トランザクション・レート差や、トランザクション・レートにおけるスパイクのような時間変化を有利に処理する。本発明のログ・ストリーム圧縮歩調合わせは、発見的手法（ヒューリスティック）にもとづくものであり、圧縮の頻度が現トランザクション・レート（すなわちログ・ストリームへの書込み）にもとづき、リアルタイムに調整される。
【００１４】
【発明の実施の形態】
本発明の原理に従えば、マルチシステム・ログ・ストリームがマルチシステム環境の特定のシステムにより圧縮される頻度が、リアルタイムに調整される。この調整は、マルチシステム環境の他のシステムがマルチシステム・ログ・ストリームを圧縮している頻度に依存する。
【００１５】
本発明の圧縮歩調合わせ機能を組み込み、使用するマルチシステム環境の１例が、図１に示される。マルチシステム環境１００は、結合機構１０４に結合される１つ以上のシステム１０２を含む。各システム１０２は、ＩＢＭにより提供されるＥＳＡ（Ｅｎｔｅｒｐｒｉｓｅ Ｓｙｓｔｅｍｓ Ａｒｃｈｉｔｅｃｔｕｒｅ）／３９０にもとづき、オペレーティング・システム１０６及び１つ以上の資源マネージャ１０８を含む。これらの各々については、後述する。
【００１６】
１実施例では、オペレーティング・システム１０６は、ＩＢＭにより提供される多重仮想記憶（ＭＶＳ）オペレーティング・システム（またはＯＳ／３９０オペレーティング・システム）である。オペレーティング・システム１０６は、例えばシステム・ロガー・コンポーネント１１０及び同期点マネージャ１１２を含む。
【００１７】
システム・ロガー・コンポーネント１１０は、オペレーティング・システムにより開始されるそれ自身のアドレス空間内で実行され、後述のように、ログ・ストリームの圧縮に関与する。システム・ロガーの１実施例が、ＭＶＳプログラミング・アセンブラ・サービス・レファレンス（ＩＢＭ発行番号：ＧＣ２８−１９１０−０１（１９９６年９月））、及びＭＶＳプログラミング・アセンブラ・サービス・ガイド（ＩＢＭ発行番号：ＧＣ２８−１７６２−０１（１９９６年９月））で述べられている。
【００１８】
同期点マネージャ１１２は、参加プログラム（資源マネージャなど）を２相コミット・プロトコルにより調整する。同期点マネージャの１例は、ＩＢＭにより提供される資源回復サービスであり、これについてはＭＶＳ Ｐｒｏｇｒａｍｍｉｎｇ： Ｒｅｓｏｕｒｃｅ Ｒｅｃｏｖｅｒｙ（ＩＢＭ発行番号：ＧＣ２８−１７３９−０３（１９９８年９月））で述べられている。同期点マネージャは、後述のように、本発明の圧縮歩調合わせ技術に関与する。
【００１９】
資源マネージャ１０８の各々は、コンピュータ・システム内の資源のセットを所有し、管理する。例えば資源マネージャは、ＩＢＭにより提供されるＩＭＳまたはＤＢ２などのデータベース管理機構である。
【００２０】
前述のように、各システム１０２は結合機構１０４に結合される。結合機構１０４（構造化外部記憶プロセッサ（ＳＥＳ）とも呼ばれる）は、システムによりアクセス可能な記憶装置を含み、資源管理マネージャやシステム内で実行されるプログラムにより要求されるオペレーションを実行する、共用可能な機構である。結合機構の例は、米国特許第５３１７７３９号及び１９９６年４月１５日付けの米国特許出願第０８／６３２６８３号で詳述されている。
【００２１】
結合機構１０４は、例えば１つ以上のスクラッチ・パッド１１４及び１つ以上のログ・ストリーム１１６を含む。各スクラッチ・パッド１１４は、後述のように、本発明により使用されるデータを含み得、１例では、スクラッチ・パッドを読出そうとする第１のシステム・ロガーにより作成される。例えば、各ログ・ストリームは関連スクラッチ・パッドを有する。
【００２２】
各ログ・ストリーム１１６は、マルチシステム環境の１つ以上のシステムによりアクセス可能であり、システムのための１つ以上のエントリを含むことができる。例えば、ログ・ストリームのための十分な空間が、もはや結合機構内に存在しない場合、各ログ・ストリームに対して、ログ・ストリームの少なくとも一部が１つ以上の記憶装置（例えば直接アクセス記憶装置（ＤＡＳＤ））に記憶され得る。
【００２３】
ログ・ストリームの１例が、図２に関連して述べられる。ログ・ストリーム２００は、ここでは１次ログ・ストリームと呼ばれ、システム上のトランザクション処理、並びにそれらのトランザクションに関与する資源マネージャに関する情報を含む。情報は、例えば同期点マネージャからの命令に応じて、システム・ロガーにより１次ログ・ストリームに書込まれる。
【００２４】
１実施例では、１次ログ・ストリーム２００が多数のログ・ブロックまたはログ・エントリ２０２を含み、各々がトランザクション識別子、トランザクションの状態（例えばコミット済み、バックアウト）、トランザクションＩＤにより識別されるトランザクションに関連付けられる資源マネージャのセット、及びエントリを所有するシステム（すなわち、データを１次ログ・ストリームに書込むシステム）の名前などの、様々なデータを含む。各ログ・エントリはブロックＩＤ２０４を有し、これは例えば、ログ・ストリーム内の相対オフセットを表す。１例では、ブロックＩＤが小さいほどデータが古い。
【００２５】
１次ログ・ストリームの一端は、ここではログ・ストリームの尾部または後部と呼ばれる。１実施例では、ログ・ストリームの後部は一般に、ログ・ストリームの最も古いエントリ（すなわち、最も小さなブロックＩＤを有するエントリ）を含む。ログ・ストリームの他端は、ここでは頭部と呼ばれ、尾部または後部から前方に位置する。（別の実施例では、頭部が最も古いエントリを保持してもよい。）
【００２６】
１次ログ・ストリーム２００は、本発明では述べる必要がない追加のデータを有し得る。１次ログ・ストリームは、本発明により管理されるログ・ストリームの１例に過ぎない。他のログ・ストリームも、本発明の技術により管理され得る。更に、本発明の別の実施例では、ログ・ストリームが結合機構内に含まれず、代わりに、例えば共用外部記憶装置（例えばＤＡＳＤ）などの共用記憶装置に記憶される。
【００２７】
エントリはログ・ストリームに接続されるシステムにより、ログ・ストリーム２００に追加される。（ログ・ストリームに接続する１実施例が、１９９７年３月２８日付けの米国特許出願第０８／８２７２１４号で述べられている。）例えば、１つ以上の同期点マネージャの命令に従い、データが１つ以上のシステム・ロガーにより、ログ・ストリームに書込まれる。特に、同期点マネージャは、１つ以上の資源マネージャのために、データがログ・ストリームに書込まれることを要求する。
【００２８】
エントリをログ・ストリームに追加する１実施例が、米国特許第５９２０８７５号及び米国特許第５９５６７３５号で述べられている。
【００２９】
エントリをログ・ストリーム２００に追加する１例について、図３に関連して詳述する。後述の図示の例では、システム（例えばシステムＸ）の同期点マネージャが、データがシステム・ロガーにより１次ログ・ストリーム２００に書込まれることを要求する。この同期点マネージャは、ここでは同期点マネージャＸと呼ばれる。しかしながら、同一の論理が情報をログ・ストリームに書込むことを希望する他の同期点マネージャ（または他のコンポーネントまたはエンティティ）により使用される。
【００３０】
図３を参照すると、最初にステップ３００で、システムＸ内に配置される主キューのために、共用直列化資源（例えばＭＶＳ／ＥＳＡ共用ラッチ）が獲得される。共用ラッチは、複数のエンティティが同時にキューをアクセスすることを可能にする。主キューは、１次ログ・ストリーム内のエントリを表す要素を保持するために使用される。主キュー４００の１例が、図４に示される。
【００３１】
１例では、主キュー４００はシステムＸの記憶装置内に配置される。ログ・ストリームに書込む各システムは、それ自身の主キューを有する。１例では、主キュー４００は１つ以上の要素４０２を含む。各要素は、１次ログ・ストリームに書込まれるエントリの表現を含む。例えば、各要素は対応するログ・ストリーム・エントリのブロックＩＤ、及び後述する論理消去フラグ（ＬＤＦ）を含む。この例では、エントリのデータはキュー内に保持されず、例えば主記憶装置、キャッシュ、補助記憶装置、外部記憶装置、結合機構、またはそれらの任意の組み合わせに別々に記憶される。従って、各要素はまた、その要素により表されるエントリのための対応するデータを指し示すポインタ（ＰＴＲ）を含む。
【００３２】
図３を参照すると、ラッチの獲得に続き、ステップ３０２で新たなエントリがログ・ストリームに追加され、ブロックＩＤを与えられる。１例では、エントリがログ・ストリームの頭部に書込まれ、ブロックＩＤが、任意のシステムにより既に割当てられたブロックＩＤよりも大きくなるように、システム・ロガー１１０が保証する。
【００３３】
その後、ステップ３０４で、ＬＧＢと呼ばれる新たな要素がシステムＸの主キュー４００にブロックＩＤの順に挿入される。１例では、最も高いブロックＩＤがキューの先頭に位置する。特に、要素が比較交換論理を用いて、待ち行列化される。これはキューに対する複数の更新が同時に発生しないように、キューの直列化を提供する。
【００３４】
続いて、ステップ３０６でラッチが解放され、システムＸによる追加のプロセスが完了する。
【００３５】
ログ・ストリームのエントリがもはや必要とされなくなると（例えばその保存要件が満たされる）、エントリは論理的に消去される。特に、エントリは物理的にログ・ストリームに留まるが、エントリに関連付けられるＬＧＢは、論理的に消去されたとマークされる。
【００３６】
エントリを論理的に消去する１実施例が、米国特許第５９２０８７５号及び米国特許第５９５６７３５号で述べられている。
【００３７】
ログ・ストリームのエントリを論理的に消去する１例について、図５に関連して詳述する。後述の図示の例では、同期点マネージャＸが、１次ログ・ストリーム２００からエントリを論理的に消去する。しかしながら、同一の論理が、情報をログ・ストリームから論理的に消去することを希望する、他の同期点マネージャ（または他のコンポーネントまたはエンティティ）によっても使用される。
【００３８】
図５を参照すると、最初にステップ５００で、消去されるエントリに対して、論理消去フラグ（ＬＤＦ）が、システムＸに対応する主キュー内でセットされる。このフラグは、エントリがもはや必要とされず（すなわち非活動状態である）、適切な時期にログ・ストリームから物理的に除去され得ることを示す。
【００３９】
続いてステップ５０２で、システムＸにおいて論理的に消去される要素のカウントが１増分される。このカウントが、例えばシステムＸの記憶装置内に保持される。しかしながら、他の例では、それは結合機構内、または外部記憶装置上に保持され得る。
【００４０】
次にステップ５０４で、カウントが所定の最大値（例えば１００の論理消去）を越えたか否かが判断される。カウントがまだその限度を越えていない場合、論理消去プロシージャは、ステップ５０６で完了する。しかしながら、カウントが限度を越えた場合、ステップ５０８でログ・ストリーム２００が圧縮される。
【００４１】
ログ・ストリームを圧縮する１実施例が、米国特許第５９２０８７５号及び米国特許第５９５６７３５号で述べられている。
【００４２】
ログ・ストリームを、例えばシステムＸの同期点マネージャにより圧縮する１例について、図６に関連して詳述する。最初にステップ６００で、システムＸの主キューのためのラッチが排他的に獲得され、それによりラッチが解放されるまで、システム内の他のエンティティがキューに書込むことを阻止する。更に、圧縮キューのためのラッチも排他的に獲得される。
【００４３】
圧縮キューは後述のように、ログ・ストリーム圧縮の間に処理されるエントリを含む。１例では、ログ・ストリームに接続され得る各システムに対して圧縮キューが存在する。各圧縮キューは、例えば特定のシステムの記憶装置内に記憶される。（別の実施例では、圧縮キューが結合機構などの共用機構内に記憶され得る。）圧縮キューの要素は、主キューの要素と同一の形式を有する。
【００４４】
排他的ラッチの獲得に続き、ステップ６０２で、システムＸの主キューで論理的に消去された第１の要素（ＬＧＢ）を突き止める。例えば、主キューに書込まれた最後の要素から開始し、セット済みの論理消去フラグを有する要素が見いだされるまで、主キューの各要素の論理消去フラグをチェックする。
【００４５】
次にステップ６０４で、論理的に消去された主キューの第１の要素、並びにそれに続く全ての他のエントリ（これらのエントリはここでは圧縮可能セットのエントリ、または圧縮ゾーン内のエントリと呼ばれる）が、主キューからデキューされ（すなわちキューから取り出され）、ステップ６０６で、圧縮キューに待ち行列化される。
【００４６】
例えば、図７及び図８を参照すると、論理的に消去される（ＬＤＦ＝１）主キュー４００の第１の要素が、ブロックＩＤ００５に相当する場合、ブロックＩＤ００５は主キューから除去され、ブロックＩＤ００４乃至００１と一緒に、システムＸの圧縮キュー７００に配置される。
【００４７】
図６に戻り、続いてステップ６０８で、主キュー・ラッチが解放される。その後ステップ６１０で、圧縮キュー７００の第１の要素（例えばブロックＩＤ００１）がデキューされ、問い合わせ６１２で、その要素が論理的に消去されるか否かが判断される。要素が論理的に消去される場合（ＬＤＦ＝１）、ステップ６１４で、その要素が解放される（例えば、圧縮技術による再利用のために、フリー・キューに配置される）。
【００４８】
しかしながら、要素が論理的に消去されない場合（ＬＤＦ＝０）、ステップ６１６で、主キュー・ラッチが共用として獲得され、ステップ６１８で、要素に対応するログ・エントリがログ・ストリームに再書込みされる。例えば、この図示の例では（図８のブロックＩＤ００１を有する要素を参照）、ブロックＩＤ００１を有するログ・ストリーム・エントリが論理的に消去されておらず、従って、ブロックＩＤ００１により表されるログ・ストリーム・エントリが、ログ・ストリーム内の別の位置に再書込みされる。特に、１例では、ブロックＩＤ００１の内容のコピーが、（圧縮キュー内に配置されるポインタにより示される）記憶装置から獲得され、ログ・ストリームの頭部のエントリに配置される。そのエントリは、新たなブロックＩＤ（例えばブロックＩＤ００７（図９参照））を与えられる。エントリが新たなブロックＩＤを与えられるとき、たとえそのエントリ内に配置されるデータが他のエントリのデータよりも古くても、それはここでは新たなエントリと見なされる。
【００４９】
図６に戻り、前述の処理に加え、ステップ６２０で、新たなブロックＩＤが要素内に配置され、ステップ６２２で、要素が主キューにブロックＩＤの順序に従い挿入される。
【００５０】
主キューへの要素の挿入に続き、または要素が解放された後、問い合わせ６２４で、圧縮キューに、処理されるべき要素が更に存在するか否かが判断される。こうした要素が存在する場合、処理はステップ６１０に継続し、圧縮キューの第１の要素をデキューする。しかしながら、もはや処理されるべきエントリが存在しない場合、ステップ６２６で、圧縮キュー・ラッチが解放され、圧縮が完了する。
【００５１】
図１０を参照すると、ステップ９００で各システムがその圧縮を実行する度に、システムはステップ９０２で、圧縮を反映するように、最終エントリ・ベクトルと呼ばれるベクトルを更新する。
【００５２】
最終エントリ・ベクトルの１実施例が、図１１に示される。最終エントリ・ベクトル１０００は、ログ・ストリームへのエントリの書込みに潜在的に参加する各システムに対するエントリ１００２を含む。例えば、マルチシステム環境が、ログ・ストリームに書込み得る３つのシステム、すなわちシステムＸ、システムＹ及びシステムＺを含む場合、ベクトル内に３つのエントリが存在する。各エントリは、それぞれのシステムにより必要とされる１次ログ・ストリーム内の、最も古いログ・エントリのブロックＩＤ（例えば最小のブロックＩＤ）を含む。
【００５３】
例えば、ベクトル１０００のエントリ１がシステムＸに対応し、システムＸが依然必要とする最も古いブロックＩＤが００４の場合、ブロックＩＤ００４がベクトル・エントリ１内に配置される（図１２参照）。同様に、エントリ３がシステムＺに対応し、ブロックＩＤ００１がシステムＺにより必要とされる最も古いブロックＩＤの場合、ブロックＩＤ００１がエントリ００３内に配置される。更に、可能な最高のブロックＩＤ（例えばｘ’ＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦ’）が、例えばシステムＹなどの、切り離されたシステムに対応する任意のベクトル・エントリ内に配置される。
【００５４】
１例として、最終エントリ・ベクトル１０００は、システム・ロガー１１０により提供されるサービスのセットを使用することにより、結合機構１０４のスクラッチ・パッド１１４内に作成される。他の実施例では、最終エントリ・ベクトルが共用外部記憶装置（例えばＤＡＳＤ）上に保持されるか、ベクトルのコピーが各システムの主記憶装置、キャッシュ、または補助記憶装置内に保持される。他の例も可能であり、これらについても本発明の趣旨及び範囲内に含まれる。
【００５５】
図１０のステップ９０２に戻り、最終エントリ・ベクトル１０００が、システムＸが依然必要とする最も古いエントリのブロックＩＤにより更新される。これは例えば、ベクトルが１度に１つのシステムだけにより変更されるように保証する、比較交換（ｃｏｍｐａｒｅ ａｎｄ ｓｗａｐ）プロトコルを用いて達成される。エントリ内に配置されるブロックＩＤは、システムＸの主キュー４００内で、論理的に消去されなかった最低のブロックＩＤである。
【００５６】
ベクトルを更新後、問い合わせ９０４において、前に置換したベクトル・エントリがベクトルの最低のブロックＩＤを含んでいたか否かを判断する。最低のブロックＩＤを含まない場合、追加のアクションは実行されない。しかしながら、最低のブロックＩＤを有する場合、ステップ９０６で、（この例では）同期点マネージャがシステムＸのシステム・ロガーに、ベクトル内の新たな最低ブロックＩＤよりも低い全てのエントリのログ尾部を消去するように要求する。
【００５７】
例えば、ログ・ストリームが３つのシステム、すなわちシステムＸ、システムＹ及びシステムＺにより書込まれるエントリを有すると仮定する（図１３参照）。更に、システムＸが要求する最も古いエントリが００１であり、システムＺが要求する最も古いエントリが００４であり、システムＹがこの時活動状態でないと仮定する（図１４参照）。図１５に示されるように、システムＸがベクトルを、それが依然必要とする最も古いエントリ（例えば図１３のブロックＩＤ００６）により更新するとき、システムＸはそのエントリが前にベクトルの最低のブロックＩＤを含んでいたか否かを判断する。この例では、エントリが最低のブロックＩＤ００１を含んでいたので、システムＸは新たな最低のブロック（例えばブロックＩＤ００４）よりも低い全てのエントリを消去する。すなわち、ブロックＩＤ００３乃至００１が１次ログ・ストリームから物理的に除去され、ブロックＩＤ００４がログ・ストリームの新たな尾部となる。これで尾部消去が完了する。
【００５８】
マルチシステム・ログ・ストリームがマルチシステム環境のシステムにより圧縮される頻度は、システム性能に影響する。本発明の原理に従えば、マルチシステム環境の特定のシステムがログ・ストリームを圧縮する頻度は発見的手法にもとづく。すなわち、各システムがその圧縮レート（すなわち圧縮頻度）を、ログ・ストリームに接続される他のシステムの圧縮レートにもとづき、リアルタイムに調整する。このことが最小サイズのログ・ストリームを保証し、ログ・ストリームが結合機構内にもっぱら含まれる可能性を増加させる。このことは、システム性能に肯定的に影響する。
【００５９】
本発明の原理に従えば、ログ・ストリームがマルチシステム環境のシステムにより圧縮される頻度を歩調合わせするために、圧縮ベクトルが使用される。１実施例では、図１６に示されるように、圧縮ベクトル１２００が、結合機構のスクラッチ・パッド１１４内に保持される。
【００６０】
圧縮ベクトル１２００は複数のエントリ１２０２を含む。圧縮されるログ・ストリームに接続される各システムに対して、１つのエントリ１２０２が存在する。各エントリは圧縮遅れカウントを含み、これは例えば０から２５５の範囲の数を取り得る。この数は、他のシステムのログ・ストリームに対する圧縮活動との比較で、各システムのログ・ストリームに対する圧縮活動を表すために使用される。従って、圧縮遅れカウントは、そのカウントに関連するシステムにより実行されたログ・ストリームに対する圧縮回数を表すのではなく、他のシステムの圧縮回数との比較における各システムの相対的な圧縮回数を示す。
【００６１】
圧縮遅れカウントは、圧縮が実行されるときに更新され、圧縮遅れカウントを更新する１実施例が、図１７に関連して述べられる。図１７の論理は、例えば圧縮を実行したシステムの同期点マネージャにより実行される。従って、もしシステムＸが圧縮を実行した場合、同期点マネージャＸが更新を実行する。
【００６２】
図１７を参照すると、圧縮があるシステム（例えばシステムＸ）により実行されるとき、システムがその主キューに、所定数（例えば１００）の論理的に消去されるエントリが存在することを検出したので、圧縮が実行されたのか否かの初期判断が下される（ステップ１３００）。（このタイプの圧縮は図６に関連して前述し、ここでは”正規圧縮（ｎｏｒｍａｌ ｃｏｍｐｒｅｓｉｏｎ）”と呼ばれる。）
【００６３】
圧縮が正規圧縮の場合、システム（例えばシステムＸ）に対する圧縮遅れカウントが０にセットされ（ステップ１３０２）、ログ・ストリームに接続されるあらゆる他のシステムの圧縮遅れカウントが１増分されるか、２５５にセットされる（いずれか小さい方の値を取る）（ステップ１３０４）。これで更新が完了する。
【００６４】
問い合わせ１３００に戻り、圧縮が正規圧縮でなく、代わりに強制圧縮（ここでは全圧縮（ＣｏｍｐｒｅｓｓＡｌｌ）と呼ぶ）の場合、圧縮を実行するシステムの圧縮遅れカウントが、０にセットされ（ステップ１３０６）、他の圧縮遅れカウントは調整されない。
【００６５】
圧縮遅れカウントの使用が、更に図１８に関連して述べられる。図１８の論理は、システムに関連付けられるタイマがトリガし、強制圧縮が実行されるべきか否かに関する判断が下されるべきことを示すとき、ログ・ストリームに接続されるシステムの同期点マネージャにより実行される。特に、システムに関連付けられるタイマがポップするとき（すなわち、所定の時間間隔が経過するとき）、そのシステムの圧縮遅れカウントがチェックされ、同期点マネージャがログ・ストリームに全圧縮を実行し、それにより尾部消去を可能にする必要があるか否かを判断する。システムが他のシステムと同等の頻度で、正規圧縮を実行していない場合、同期点マネージャは、強制圧縮が必要であることを検出する。
【００６６】
図１８を参照すると、最初に、タイマ・ポップに関連付けられるシステム（図示の例では、システムＺを想定）の圧縮遅れカウントの値がチェックされる（問い合わせ１４００）。システムＺの圧縮遅れカウントの値が０に等しく、少なくとも他のシステムと同等の頻度で、正規圧縮を実行していることを示す場合、システムＺに関連付けられる圧縮ゼロ・カウントが、１増分される（ステップ１４０２）。圧縮ゼロ・カウントは、ローカル記憶装置内に保持され（すなわち、他のシステムにとって使用不能であり）、ローカル・システム（この例ではシステムＺ）により使用され、更新される。これはタイマ・ポップの所定の時間間隔が調整されるべきか否かを決定するために使用される。
【００６７】
その後、圧縮ゼロ・カウントがチェックされ、それが２以上であるか否かが判断される（ステップ１４０４）。圧縮ゼロ・カウントが２未満の場合、調整は実行されず、タイマ・ポップ・ルーチンが完了する。しかしながら、圧縮ゼロ・カウントの値が２以上の場合、タイマが余りに頻繁にポップしており、その結果、強制圧縮（全圧縮）が要求されるか否かをチェックするために、過度な処理時間が使用されている。従って、タイマ・インタバルが増加される（ステップ１４０６）。１例では、タイマ・インタバルが倍増されるが、最大インタバルを越えることはない。これれによりタイマがポップする回数が低減される。
【００６８】
前述の処理に加え、圧縮ゼロ・カウントが０にセットされ（ステップ１４０８）、タイマ・ポップ・ルーチンの処理が完了する。
【００６９】
問い合わせ１４００に戻り、圧縮遅れカウントの値が０よりも大きく、システムＺがログ・ストリームに接続される他のシステムに比較して、十分に頻繁に圧縮していないことを示す場合、システムＺの同期点マネージャが強制圧縮を実行する（ステップ１４１０）。１実施例では、強制圧縮はシステムＺの主キューにある論理的に消去されない全てのエントリを、１次ログ・ストリーム及び主キューに書込む。例えば、図１９乃至図２０を参照し、システムＺがその主キュー１５００に、ブロックＩＤ００１乃至００３を含む３つのエントリを有し、それらのエントリの２つ、すなわちブロックＩＤ００１及びブロックＩＤ００３が論理的に消去されていない場合、これらの２つのエントリが１次ログ・ストリームの頭部に再書込みされ、従って、新たなブロックＩＤを与えられる。新たなブロックＩＤ００８が旧ブロックＩＤ００１に対応し、新たなブロックＩＤ００９が旧ブロックＩＤ００３に対応すると仮定すると、図２０に示されるように、ブロックＩＤ００８及びブロックＩＤ００９が、システムＺの主キューに再書込みされる。図示のように、ブロックＩＤ００２はもはや要求されないので（すなわち論理的に消去されたので）、主キューまたは１次ログ・ストリームに再書込みされない。
【００７０】
図１８に戻り、システムＺによる強制圧縮の実行に続き、システムＺの圧縮遅れカウントが選択値、例えばログ・ストリームに接続されるシステムの数から１を差し引いた値の２倍よりも大きいか否かが判断される（すなわち、圧縮遅れカウント＞２ｘ（システム数−１）か？）。これはシステムＺが、ログ・ストリームに接続される他のシステムの少なくとも１つよりも遅いトランザクション・レートを有し、そのログ・ストリームをより少ない頻度で圧縮していることを示す。この差を補償するためにより頻繁な圧縮を生じるように、タイマ・ポップがリアルタイムに調整される。圧縮遅れカウントが選択値よりも大きい場合、タイマ・インタバルが減少され、それによりタイマがより頻繁にトリガされることになる（ステップ１４１４）。１例では、タイマ・インタバルが半減される。その後、システムＺの圧縮ゼロ・カウントが０にセットされ（ステップ１４０８）、タイマ・ポップ・ルーチンの処理が完了する。
【００７１】
問い合わせ１４１２に戻り、圧縮遅れカウントが選択値よりも大きくない場合、この時点でタイマ・インタバルを減少する必要はない。従って、システムＺの圧縮ゼロ・カウントは０にセットされ（ステップ１４０８）、処理が完了する。
【００７２】
前述の処理は、システムがログ・ストリームを圧縮する頻度をリアルタイムに調整するための機能に相当する。システムがその主キューが所定数の論理的に消去されるエントリ、例えば１００の論理的に消去されるエントリを有することを検出するとき、圧縮が実行される。更に、システムに関連付けられるタイマがポップし、別のシステムが既に圧縮を実行済みであるが、ポップしたタイマのシステムがまだ圧縮を実行していない場合、圧縮が実行される。タイマがポップする頻度も、本発明の原理に従い、タイマ・ポップが過度な処理時間を使用しないように制御される。
【００７３】
各同期点マネージャは、活動作業負荷を処理している最速のシステムのスピードで、圧縮または全圧縮を実行する。例えば、あるシステムが１秒につき１００トランザクションを処理しており、ログ・ストリームに接続される他の２つのシステムが、１秒につき１トランザクションを処理している場合、他の２つのシステムは１秒につき１００トランザクションのレートで、圧縮または全圧縮を発行する。もしこれが達成されない場合、ログ・ストリームのサイズが成長し始める。なぜなら、高速のシステムが低速のシステムにより、尾部消去を発行することを阻止されるからである。
【００７４】
前述のように、ログ・ストリームは１つ以上のデータ（例えばログ・データ）を含む。従って、１つ以上のデータを含む他のエンティティが、ログ・ストリームの定義内に含まれる。これらのエンティティには、ログ・ファイル及びログ・データ・セットなどが含まれる。
【００７５】
前述のマルチシステム環境は、１例に過ぎない。本発明は本発明の趣旨から逸れることなく、他のシステムまたは環境内でも使用され、組み込まれ得る。例えば、異なるアーキテクチャまたはオペレーティング・システムが、本発明の趣旨から逸れることなく使用され得る。別の例として、１つ以上の中央処理コンプレックスが結合機構に接続され、各中央処理コンプレックスが、オペレーティング・システムを実行する１つ以上の中央処理ユニットを含み得る。更に別の実施例では、コンピュータ・システムが複数の結合機構を含む。更に、本発明は、結合機構を含まないコンピュータ・システムにも適用可能である。
【００７６】
更に、本発明の趣旨及び範囲から逸れることなく、システムの他のコンポーネントも、本発明により管理及び圧縮され得る関連ログ・ストリームを有し得る。
【００７７】
更に別の実施例では、システム・ロガーがオペレーティング・システムとは別のコンポーネントである。更に、システム・ロガー以外のコンポーネントが、ログ・ストリームにエントリを書込み、また消去できる。更に別の実施例では、同期点マネージャだけが圧縮を実行できる、或いは圧縮を歩調合わせできる唯一のコンポーネントではない。別の実施例では、資源マネージャなどのシステムの他のコンポーネントが、圧縮または歩調合わせ技術を実行する。再度、ここで述べたマルチシステム環境は、１例に過ぎない。
【００７８】
本発明は、例えばコンピュータ読取り可能媒体を有する製造物（例えば１つ以上のコンピュータ・プログラム製品）内に含まれ得る。媒体は例えば、本発明の機能を提供及び容易にするコンピュータ読取り可能プログラム・コード手段を実装する。製造物は、コンピュータ・システムの一部として含まれるか、別々に販売される。
【００７９】
ここで示されたフロー図は、典型例に過ぎない。本発明の趣旨から逸れることなく、これらのフロー図またはステップ（またはオペレーション）に対する多くの変化が存在し得る。例えば、ステップが異なる順序で実行されたり、或いはステップが追加、消去または変更されてもよい。これらの全ての変化は、本発明の一部と見なされる。
【００８０】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００８１】
（１）マルチシステム・ログ・ストリームが圧縮される頻度を歩調合わせする方法であって、
前記マルチシステム・ログ・ストリームがマルチシステム環境のあるシステムにより圧縮されるレートを、前記マルチシステム・ログ・ストリームが、前記マルチシステム環境の少なくとも１つの他のシステムにより圧縮される頻度との比較において確認するステップと、
前記あるシステムが前記マルチシステム・ログ・ストリームを圧縮する頻度を、リアルタイムに調整するステップと
を含む、方法。
（２）前記確認するステップが、前記あるシステムの圧縮遅れカウントをチェックするステップを含み、前記圧縮遅れカウントが、前記マルチシステム・ログ・ストリームが前記少なくとも１つの他のシステムにより圧縮される頻度との比較において、前記あるシステムが前記マルチシステム・ログ・ストリームを圧縮しているレートを表す、前記（１）記載の方法。
（３）前記あるシステムが前記マルチシステム・ログ・ストリームを圧縮するとき、前記圧縮遅れカウントを更新するステップを含む、前記（２）記載の方法。
（４）前記あるシステムが前記マルチシステム・ログ・ストリームを圧縮するとき、前記少なくとも１つの他のシステムの少なくとも１つの他の圧縮遅れカウントをセットするステップを含む、前記（３）記載の方法。
（５）前記調整するステップが、前記確認レートから、前記あるシステムが前記マルチシステム・ログ・ストリームを、前記少なくとも１つの他のシステムよりも遅いレートで圧縮していることが判明するとき、前記あるシステムが前記マルチシステム・ログ・ストリームを圧縮する頻度を増加するステップを含む、前記（１）記載の方法。
（６）前記増加するステップが、前記あるシステムによる圧縮の実行を強制するステップを含む、前記（５）記載の方法。
（７）前記確認レートが、前記あるシステムが圧縮を実行する頻度が増加されるべきことを示しているか否かを、所定時間間隔で決定するステップを含む、前記（５）記載の方法。
（８）前記あるシステムの前記確認レートが選択値と所定の関係を有すると判断されるとき、前記所定時間間隔を減少するステップを含む、前記（７）記載の方法。
（９）前記確認レートが、前記マルチシステム・ログ・ストリームに接続されるシステムの数から１を差し引いた値の２倍よりも大きいことが判明するとき、前記減少するステップが、前記所定時間を半減するステップを含む、前記（８）記載の方法。
（１０）所定時間間隔で前記確認レートを所定値と比較し、前記あるシステムが圧縮を実行する頻度が調整されるべきか否かを決定するステップを含む、前記（１）記載の方法。
（１１）前記確認レートが前記所定値と所定の関係を有するとき、前記調整が実行される、前記（１０）記載の方法。
（１２）前記あるシステムの前記確認レートが選択値と所定の関係を有すると判断されるとき、前記所定時間間隔を減少するステップを含む、前記（１０）記載の方法。
（１３）前記比較がより少ない頻度で実行されるべきと決定されるとき、前記所定時間間隔を増加するステップを含む、前記（１０）記載の方法。
（１４）前記マルチシステム・ログ・ストリームが、少なくとも部分的に、前記マルチシステム環境の前記あるシステム及び前記少なくとも１つの他のシステムに接続される結合機構内に配置される、前記（１）記載の方法。
（１５）マルチシステム・ログ・ストリームが圧縮される頻度を歩調合わせする方法であって、
前記マルチシステム・ログ・ストリームがマルチシステム環境のあるシステムにより圧縮されるレートを、前記マルチシステム・ログ・ストリームが、前記マルチシステム環境の少なくとも１つの他のシステムにより圧縮される頻度との比較において確認するステップと、
所定時間間隔で前記確認レートを所定値と比較し、前記あるシステムが前記マルチシステム・ログ・ストリームを圧縮する頻度が、調整されるべきか否かを決定するステップと、
前記比較が調整の必要性を示す場合、前記あるシステムが前記マルチシステム・ログ・ストリームを圧縮する頻度を、リアルタイムに調整するステップと、
前記所定時間間隔が変更されるべきか否かを決定するステップと、
前記所定時間間隔が変更されるべきと決定される場合、前記所定時間間隔を変更し、前記比較が実行される頻度を調整するステップと
を含む、方法。
（１６）前記比較するステップが、前記あるシステムによる圧縮の頻度が増加されるべきことを示す、前記（１５）記載の方法。
（１７）前記決定するステップが、前記所定時間間隔が減少されるべきことを示し、それにより前記比較するステップがより頻繁に実行される、前記（１６）記載の方法。
（１８）前記決定するステップが、前記所定時間間隔が増加されるべきことを示し、それにより前記比較するステップがより少ない頻度で実行される、前記（１５）記載の方法。
【図面の簡単な説明】
【図１】本発明のログ・ストリーム圧縮歩調合わせ機能を組み込み、使用するマルチシステム環境の１例を示す図である。
【図２】本発明の原理に従い管理される、図１のマルチシステム環境の１次ログ・ストリームの１例を示す図である。
【図３】図２の１次ログ・ストリームに新たなエントリを追加するために使用される論理の１実施例を示す図である。
【図４】本発明の原理に従い使用される主キューの１実施例を示す図である。
【図５】本発明の原理に従い、図２の１次ログ・ストリームからエントリを論理的に消去するために使用される論理の１実施例を示す図である。
【図６】図２の１次ログ・ストリームを圧縮するために使用される論理の１実施例を示す図である。
【図７】本発明の原理に従い使用される図４の主キューの別の例を示す図である。
【図８】本発明の原理に従い使用される圧縮キューの１例を示す図である。
【図９】本発明の原理に従い、第１のエントリが７番目のエントリとして書換えられた、図２の１次ログ・ストリームの別の例を示す図である。
【図１０】図２の１次ログ・ストリームから、論理的に消去されたエントリを物理的に除去するために使用される論理の１実施例を示す図である。
【図１１】図１０の尾部消去の間に更新される最終入力ベクトルの例を示す図である。
【図１２】図１０の尾部消去の間に更新される最終入力ベクトルの例を示す図である。
【図１３】本発明の原理に従い管理される図２の１次ログ・ストリームの別の例を示す図である。
【図１４】本発明の原理に従い使用される図１１の最終入力ベクトルの他の例を示す図である。
【図１５】本発明の原理に従い使用される図１１の最終入力ベクトルの他の例を示す図である。
【図１６】本発明の原理に従い使用される圧縮ベクトルの１例を示す図である。
【図１７】本発明の原理に従い、図１６の圧縮ベクトル内に記憶される圧縮遅れカウントを更新するために使用される論理の１実施例を示す図である。
【図１８】本発明の原理に従い、タイマ・ポップ・ルーチンの間に、圧縮が強制されるべきか否かを決定するために使用される論理の１実施例を示す図である。
【図１９】本発明の原理に従い使用される、システムＺのための主キューの例を示す図である。
【図２０】本発明の原理に従い使用される、システムＺのための主キューの例を示す図である。
【符号の説明】
１００ マルチシステム環境
１０２ システム
１０４ 結合機構
１０６ オペレーティング・システム
１０８ 資源マネージャ
１１０ システム・ロガー・コンポーネント
１１２ 同期点マネージャ
１１４ スクラッチ・パッド
１１６、２００ ログ・ストリーム
２０２ ログ・エントリ
２０４ ブロックＩＤ
４００ 主キュー
４０２ 要素
６１２、６２４、１３００、１４００ 問い合わせ
７００ 圧縮キュー
１０００ 最終エントリ・ベクトル
１００２、１２０２ エントリ
１２００ 圧縮ベクトル
【発明の属する技術分野】
本発明は一般に、マルチシステム環境のログ・ストリームの管理に関し、特に、ログ・ストリームがマルチシステム環境のシステムにより圧縮される頻度の歩調合わせ（ペーシング）に関する。
【０００２】
【従来の技術】
様々なコンピュータ・システムにおいて、履歴ログ・データが例えばログ・ファイル内に保持され、システム回復、問題判別、及びシステム保守のために使用される。一般に、これらのログ・ファイルは、履歴データを保存するための限られた容量を有する。容量が満杯になると、少なくとも一部のデータ記録がログ・ファイルから直接アクセス記憶装置（ＤＡＳＤ）などの外部記憶装置に移動され、それによりログ・ファイル内に追加のデータのための追加の空間を提供する。
【０００３】
ある時点で、ログ・ファイル内または外部記憶装置上のデータは、もはや必要とされなくなる。例えば、一旦データがその保存要件を過ぎると、そのデータを保持する必要性が無くなる。データをその有効期限を過ぎて保管することは、多くの点でシステム性能に悪影響を及ぼす。例えば、不要なデータが保存され、故障の回復の間にログ・データを回復するために、ログ・ファイルが走査検索される必要がある場合、ブラウザは潜在的に大きな容量の不要データを扱わねばならず、その結果、回復プロセスを遅らせることになる。更に、不要なデータ記録の保管は、一般にデータへの低速アクセスを提供する外部記憶装置の使用を要求し、そのためにデータの読出しに長い時間を要し、システム性能に影響することになる。
【０００４】
従って、あらゆる不要なデータをログ・ファイルから消去することが好都合である。これはログ・ファイルを圧縮し、次に消去され得るあらゆるエントリを物理的に消去することにより達成される。ログ・ファイルがマルチシステム環境の様々なシステムにより使用されるとき、各システムはその不要なエントリを圧縮し、消去する責任を担う。
【０００５】
しかしながら、マルチシステム環境のシステムが異なるトランザクション・レートで処理しており、低速のシステムが高速のシステムに釣り合うレートで、ログ・ファイルを十分に圧縮できない場合、低速のシステムは高速のシステムの性能に悪影響を及ぼす。これはトランザクション・レートの不均衡の理由がハードウェア性能特性であるか、作業負荷の差であるかに関わらず当てはまる。従って、高速のシステムは潜在的に、低速のシステムよりもより多くの要素をログ・ファイル内に有し、高速のシステムの要素は、低速のシステムにより書込まれる１つの要素により分離され得る。この問題は、幾つかの高速のシステムと、単一の低速のシステムだけが存在する状況において悪化し得る。
【０００６】
【発明が解決しようとする課題】
前述の状況を鑑み、システムがマルチシステム・ログ・ファイルを圧縮する頻度を歩調合わせする機能が待望される。更に、各システムが他のシステムの圧縮レートにもとづき、その圧縮レートを調整することを可能にし、最小サイズのログ・ファイルを保証する機能が待望される。更に、圧縮の頻度が、ログ・ファイルに接続されるシステムの現トランザクション・レートにもとづき、リアルタイムに調整されることを可能にする、歩調合わせ技術が待望される。
【０００７】
【課題を解決するための手段】
マルチシステム・ログ・ストリームが圧縮される頻度を歩調合わせする方法の提供により、従来技術の欠点が克服され、追加の利点が提供される。１例では、マルチシステム・ログ・ストリームがマルチシステム環境のあるシステムにより圧縮されるレートが確認される。ここでレートは、マルチシステム・ログ・ストリームが、マルチシステム環境の少なくとも１つの他のシステムにより圧縮される頻度との比較で示される。あるシステムがマルチシステム・ログ・ストリームを圧縮する頻度が、リアルタイムに調整される。
【０００８】
１実施例では、あるシステムの圧縮遅れカウントをチェックすることにより、レートが確認される。圧縮遅れカウントは、マルチシステム・ログ・ストリームが少なくとも１つの他のシステムにより圧縮される頻度との比較において、あるシステムがマルチシステム・ログ・ストリームを圧縮しているレートを表す。
【０００９】
別の実施例では、確認されたレートから、あるシステムが、少なくとも１つの他のシステムよりも遅いレートでマルチシステム・ログ・ストリームを圧縮していることが判明するとき、そのシステムがマルチシステム・ログ・ストリームを圧縮する頻度を増加することにより、圧縮の頻度を調整する。例えば、頻度の増加は、あるシステムによる圧縮の実行を強制するステップを含む。
【００１０】
更に別の実施例では、本方法は、確認されたレートから、あるシステムが圧縮を実行する頻度を増加すべきか否かを、所定の時間間隔で決定するステップを含む。
【００１１】
更に別の実施例では、あるシステムの確認されたレートが、選択値と所定の関係を有すると判断されるとき、所定の時間間隔が減少される。例えば、選択値は、マルチシステム・ログ・ストリームに接続されるシステムの数から１を差し引いた値の２倍である。
【００１２】
本発明の別の実施例では、マルチシステム・ログ・ストリームが圧縮される頻度を歩調合わせする方法が提供される。この方法は、例えば、マルチシステム・ログ・ストリームが、マルチシステム環境のあるシステムにより圧縮されるレートを確認するステップと、所定の時間間隔で、確認されたレートを所定値と比較し、あるシステムがマルチシステム・ログ・ストリームを圧縮する頻度が、調整されるべきか否かを決定するステップと、比較が調整の必要性を示す場合、あるシステムがマルチシステム・ログ・ストリームを圧縮する頻度をリアルタイムに調整するステップと、所定の時間間隔が変更されるべきか否かを決定するステップと、所定の時間間隔が変更されるべきと決定される場合、所定の時間間隔を変更し、比較が実行される頻度を調整するステップとを含む。
【００１３】
本発明の圧縮歩調合わせ機能は、システムがマルチシステム・ログ・ストリームを圧縮する頻度をリアルタイムに有利に調整する。各システムはその圧縮レートを他のシステムの圧縮レートにもとづき調整し、最小サイズのログ・ストリームを保証する。これはログ・ストリームが結合機構内にもっぱら含まれる可能性を増加させ、アクティブ・データを外部記憶装置にオフロードすることにより生じる、システム性能の低下の可能性を減少させる。本発明の技術は、異なるプロセッサ能力などの永久トランザクション・レート差や、トランザクション・レートにおけるスパイクのような時間変化を有利に処理する。本発明のログ・ストリーム圧縮歩調合わせは、発見的手法（ヒューリスティック）にもとづくものであり、圧縮の頻度が現トランザクション・レート（すなわちログ・ストリームへの書込み）にもとづき、リアルタイムに調整される。
【００１４】
【発明の実施の形態】
本発明の原理に従えば、マルチシステム・ログ・ストリームがマルチシステム環境の特定のシステムにより圧縮される頻度が、リアルタイムに調整される。この調整は、マルチシステム環境の他のシステムがマルチシステム・ログ・ストリームを圧縮している頻度に依存する。
【００１５】
本発明の圧縮歩調合わせ機能を組み込み、使用するマルチシステム環境の１例が、図１に示される。マルチシステム環境１００は、結合機構１０４に結合される１つ以上のシステム１０２を含む。各システム１０２は、ＩＢＭにより提供されるＥＳＡ（Ｅｎｔｅｒｐｒｉｓｅ Ｓｙｓｔｅｍｓ Ａｒｃｈｉｔｅｃｔｕｒｅ）／３９０にもとづき、オペレーティング・システム１０６及び１つ以上の資源マネージャ１０８を含む。これらの各々については、後述する。
【００１６】
１実施例では、オペレーティング・システム１０６は、ＩＢＭにより提供される多重仮想記憶（ＭＶＳ）オペレーティング・システム（またはＯＳ／３９０オペレーティング・システム）である。オペレーティング・システム１０６は、例えばシステム・ロガー・コンポーネント１１０及び同期点マネージャ１１２を含む。
【００１７】
システム・ロガー・コンポーネント１１０は、オペレーティング・システムにより開始されるそれ自身のアドレス空間内で実行され、後述のように、ログ・ストリームの圧縮に関与する。システム・ロガーの１実施例が、ＭＶＳプログラミング・アセンブラ・サービス・レファレンス（ＩＢＭ発行番号：ＧＣ２８−１９１０−０１（１９９６年９月））、及びＭＶＳプログラミング・アセンブラ・サービス・ガイド（ＩＢＭ発行番号：ＧＣ２８−１７６２−０１（１９９６年９月））で述べられている。
【００１８】
同期点マネージャ１１２は、参加プログラム（資源マネージャなど）を２相コミット・プロトコルにより調整する。同期点マネージャの１例は、ＩＢＭにより提供される資源回復サービスであり、これについてはＭＶＳ Ｐｒｏｇｒａｍｍｉｎｇ： Ｒｅｓｏｕｒｃｅ Ｒｅｃｏｖｅｒｙ（ＩＢＭ発行番号：ＧＣ２８−１７３９−０３（１９９８年９月））で述べられている。同期点マネージャは、後述のように、本発明の圧縮歩調合わせ技術に関与する。
【００１９】
資源マネージャ１０８の各々は、コンピュータ・システム内の資源のセットを所有し、管理する。例えば資源マネージャは、ＩＢＭにより提供されるＩＭＳまたはＤＢ２などのデータベース管理機構である。
【００２０】
前述のように、各システム１０２は結合機構１０４に結合される。結合機構１０４（構造化外部記憶プロセッサ（ＳＥＳ）とも呼ばれる）は、システムによりアクセス可能な記憶装置を含み、資源管理マネージャやシステム内で実行されるプログラムにより要求されるオペレーションを実行する、共用可能な機構である。結合機構の例は、米国特許第５３１７７３９号及び１９９６年４月１５日付けの米国特許出願第０８／６３２６８３号で詳述されている。
【００２１】
結合機構１０４は、例えば１つ以上のスクラッチ・パッド１１４及び１つ以上のログ・ストリーム１１６を含む。各スクラッチ・パッド１１４は、後述のように、本発明により使用されるデータを含み得、１例では、スクラッチ・パッドを読出そうとする第１のシステム・ロガーにより作成される。例えば、各ログ・ストリームは関連スクラッチ・パッドを有する。
【００２２】
各ログ・ストリーム１１６は、マルチシステム環境の１つ以上のシステムによりアクセス可能であり、システムのための１つ以上のエントリを含むことができる。例えば、ログ・ストリームのための十分な空間が、もはや結合機構内に存在しない場合、各ログ・ストリームに対して、ログ・ストリームの少なくとも一部が１つ以上の記憶装置（例えば直接アクセス記憶装置（ＤＡＳＤ））に記憶され得る。
【００２３】
ログ・ストリームの１例が、図２に関連して述べられる。ログ・ストリーム２００は、ここでは１次ログ・ストリームと呼ばれ、システム上のトランザクション処理、並びにそれらのトランザクションに関与する資源マネージャに関する情報を含む。情報は、例えば同期点マネージャからの命令に応じて、システム・ロガーにより１次ログ・ストリームに書込まれる。
【００２４】
１実施例では、１次ログ・ストリーム２００が多数のログ・ブロックまたはログ・エントリ２０２を含み、各々がトランザクション識別子、トランザクションの状態（例えばコミット済み、バックアウト）、トランザクションＩＤにより識別されるトランザクションに関連付けられる資源マネージャのセット、及びエントリを所有するシステム（すなわち、データを１次ログ・ストリームに書込むシステム）の名前などの、様々なデータを含む。各ログ・エントリはブロックＩＤ２０４を有し、これは例えば、ログ・ストリーム内の相対オフセットを表す。１例では、ブロックＩＤが小さいほどデータが古い。
【００２５】
１次ログ・ストリームの一端は、ここではログ・ストリームの尾部または後部と呼ばれる。１実施例では、ログ・ストリームの後部は一般に、ログ・ストリームの最も古いエントリ（すなわち、最も小さなブロックＩＤを有するエントリ）を含む。ログ・ストリームの他端は、ここでは頭部と呼ばれ、尾部または後部から前方に位置する。（別の実施例では、頭部が最も古いエントリを保持してもよい。）
【００２６】
１次ログ・ストリーム２００は、本発明では述べる必要がない追加のデータを有し得る。１次ログ・ストリームは、本発明により管理されるログ・ストリームの１例に過ぎない。他のログ・ストリームも、本発明の技術により管理され得る。更に、本発明の別の実施例では、ログ・ストリームが結合機構内に含まれず、代わりに、例えば共用外部記憶装置（例えばＤＡＳＤ）などの共用記憶装置に記憶される。
【００２７】
エントリはログ・ストリームに接続されるシステムにより、ログ・ストリーム２００に追加される。（ログ・ストリームに接続する１実施例が、１９９７年３月２８日付けの米国特許出願第０８／８２７２１４号で述べられている。）例えば、１つ以上の同期点マネージャの命令に従い、データが１つ以上のシステム・ロガーにより、ログ・ストリームに書込まれる。特に、同期点マネージャは、１つ以上の資源マネージャのために、データがログ・ストリームに書込まれることを要求する。
【００２８】
エントリをログ・ストリームに追加する１実施例が、米国特許第５９２０８７５号及び米国特許第５９５６７３５号で述べられている。
【００２９】
エントリをログ・ストリーム２００に追加する１例について、図３に関連して詳述する。後述の図示の例では、システム（例えばシステムＸ）の同期点マネージャが、データがシステム・ロガーにより１次ログ・ストリーム２００に書込まれることを要求する。この同期点マネージャは、ここでは同期点マネージャＸと呼ばれる。しかしながら、同一の論理が情報をログ・ストリームに書込むことを希望する他の同期点マネージャ（または他のコンポーネントまたはエンティティ）により使用される。
【００３０】
図３を参照すると、最初にステップ３００で、システムＸ内に配置される主キューのために、共用直列化資源（例えばＭＶＳ／ＥＳＡ共用ラッチ）が獲得される。共用ラッチは、複数のエンティティが同時にキューをアクセスすることを可能にする。主キューは、１次ログ・ストリーム内のエントリを表す要素を保持するために使用される。主キュー４００の１例が、図４に示される。
【００３１】
１例では、主キュー４００はシステムＸの記憶装置内に配置される。ログ・ストリームに書込む各システムは、それ自身の主キューを有する。１例では、主キュー４００は１つ以上の要素４０２を含む。各要素は、１次ログ・ストリームに書込まれるエントリの表現を含む。例えば、各要素は対応するログ・ストリーム・エントリのブロックＩＤ、及び後述する論理消去フラグ（ＬＤＦ）を含む。この例では、エントリのデータはキュー内に保持されず、例えば主記憶装置、キャッシュ、補助記憶装置、外部記憶装置、結合機構、またはそれらの任意の組み合わせに別々に記憶される。従って、各要素はまた、その要素により表されるエントリのための対応するデータを指し示すポインタ（ＰＴＲ）を含む。
【００３２】
図３を参照すると、ラッチの獲得に続き、ステップ３０２で新たなエントリがログ・ストリームに追加され、ブロックＩＤを与えられる。１例では、エントリがログ・ストリームの頭部に書込まれ、ブロックＩＤが、任意のシステムにより既に割当てられたブロックＩＤよりも大きくなるように、システム・ロガー１１０が保証する。
【００３３】
その後、ステップ３０４で、ＬＧＢと呼ばれる新たな要素がシステムＸの主キュー４００にブロックＩＤの順に挿入される。１例では、最も高いブロックＩＤがキューの先頭に位置する。特に、要素が比較交換論理を用いて、待ち行列化される。これはキューに対する複数の更新が同時に発生しないように、キューの直列化を提供する。
【００３４】
続いて、ステップ３０６でラッチが解放され、システムＸによる追加のプロセスが完了する。
【００３５】
ログ・ストリームのエントリがもはや必要とされなくなると（例えばその保存要件が満たされる）、エントリは論理的に消去される。特に、エントリは物理的にログ・ストリームに留まるが、エントリに関連付けられるＬＧＢは、論理的に消去されたとマークされる。
【００３６】
エントリを論理的に消去する１実施例が、米国特許第５９２０８７５号及び米国特許第５９５６７３５号で述べられている。
【００３７】
ログ・ストリームのエントリを論理的に消去する１例について、図５に関連して詳述する。後述の図示の例では、同期点マネージャＸが、１次ログ・ストリーム２００からエントリを論理的に消去する。しかしながら、同一の論理が、情報をログ・ストリームから論理的に消去することを希望する、他の同期点マネージャ（または他のコンポーネントまたはエンティティ）によっても使用される。
【００３８】
図５を参照すると、最初にステップ５００で、消去されるエントリに対して、論理消去フラグ（ＬＤＦ）が、システムＸに対応する主キュー内でセットされる。このフラグは、エントリがもはや必要とされず（すなわち非活動状態である）、適切な時期にログ・ストリームから物理的に除去され得ることを示す。
【００３９】
続いてステップ５０２で、システムＸにおいて論理的に消去される要素のカウントが１増分される。このカウントが、例えばシステムＸの記憶装置内に保持される。しかしながら、他の例では、それは結合機構内、または外部記憶装置上に保持され得る。
【００４０】
次にステップ５０４で、カウントが所定の最大値（例えば１００の論理消去）を越えたか否かが判断される。カウントがまだその限度を越えていない場合、論理消去プロシージャは、ステップ５０６で完了する。しかしながら、カウントが限度を越えた場合、ステップ５０８でログ・ストリーム２００が圧縮される。
【００４１】
ログ・ストリームを圧縮する１実施例が、米国特許第５９２０８７５号及び米国特許第５９５６７３５号で述べられている。
【００４２】
ログ・ストリームを、例えばシステムＸの同期点マネージャにより圧縮する１例について、図６に関連して詳述する。最初にステップ６００で、システムＸの主キューのためのラッチが排他的に獲得され、それによりラッチが解放されるまで、システム内の他のエンティティがキューに書込むことを阻止する。更に、圧縮キューのためのラッチも排他的に獲得される。
【００４３】
圧縮キューは後述のように、ログ・ストリーム圧縮の間に処理されるエントリを含む。１例では、ログ・ストリームに接続され得る各システムに対して圧縮キューが存在する。各圧縮キューは、例えば特定のシステムの記憶装置内に記憶される。（別の実施例では、圧縮キューが結合機構などの共用機構内に記憶され得る。）圧縮キューの要素は、主キューの要素と同一の形式を有する。
【００４４】
排他的ラッチの獲得に続き、ステップ６０２で、システムＸの主キューで論理的に消去された第１の要素（ＬＧＢ）を突き止める。例えば、主キューに書込まれた最後の要素から開始し、セット済みの論理消去フラグを有する要素が見いだされるまで、主キューの各要素の論理消去フラグをチェックする。
【００４５】
次にステップ６０４で、論理的に消去された主キューの第１の要素、並びにそれに続く全ての他のエントリ（これらのエントリはここでは圧縮可能セットのエントリ、または圧縮ゾーン内のエントリと呼ばれる）が、主キューからデキューされ（すなわちキューから取り出され）、ステップ６０６で、圧縮キューに待ち行列化される。
【００４６】
例えば、図７及び図８を参照すると、論理的に消去される（ＬＤＦ＝１）主キュー４００の第１の要素が、ブロックＩＤ００５に相当する場合、ブロックＩＤ００５は主キューから除去され、ブロックＩＤ００４乃至００１と一緒に、システムＸの圧縮キュー７００に配置される。
【００４７】
図６に戻り、続いてステップ６０８で、主キュー・ラッチが解放される。その後ステップ６１０で、圧縮キュー７００の第１の要素（例えばブロックＩＤ００１）がデキューされ、問い合わせ６１２で、その要素が論理的に消去されるか否かが判断される。要素が論理的に消去される場合（ＬＤＦ＝１）、ステップ６１４で、その要素が解放される（例えば、圧縮技術による再利用のために、フリー・キューに配置される）。
【００４８】
しかしながら、要素が論理的に消去されない場合（ＬＤＦ＝０）、ステップ６１６で、主キュー・ラッチが共用として獲得され、ステップ６１８で、要素に対応するログ・エントリがログ・ストリームに再書込みされる。例えば、この図示の例では（図８のブロックＩＤ００１を有する要素を参照）、ブロックＩＤ００１を有するログ・ストリーム・エントリが論理的に消去されておらず、従って、ブロックＩＤ００１により表されるログ・ストリーム・エントリが、ログ・ストリーム内の別の位置に再書込みされる。特に、１例では、ブロックＩＤ００１の内容のコピーが、（圧縮キュー内に配置されるポインタにより示される）記憶装置から獲得され、ログ・ストリームの頭部のエントリに配置される。そのエントリは、新たなブロックＩＤ（例えばブロックＩＤ００７（図９参照））を与えられる。エントリが新たなブロックＩＤを与えられるとき、たとえそのエントリ内に配置されるデータが他のエントリのデータよりも古くても、それはここでは新たなエントリと見なされる。
【００４９】
図６に戻り、前述の処理に加え、ステップ６２０で、新たなブロックＩＤが要素内に配置され、ステップ６２２で、要素が主キューにブロックＩＤの順序に従い挿入される。
【００５０】
主キューへの要素の挿入に続き、または要素が解放された後、問い合わせ６２４で、圧縮キューに、処理されるべき要素が更に存在するか否かが判断される。こうした要素が存在する場合、処理はステップ６１０に継続し、圧縮キューの第１の要素をデキューする。しかしながら、もはや処理されるべきエントリが存在しない場合、ステップ６２６で、圧縮キュー・ラッチが解放され、圧縮が完了する。
【００５１】
図１０を参照すると、ステップ９００で各システムがその圧縮を実行する度に、システムはステップ９０２で、圧縮を反映するように、最終エントリ・ベクトルと呼ばれるベクトルを更新する。
【００５２】
最終エントリ・ベクトルの１実施例が、図１１に示される。最終エントリ・ベクトル１０００は、ログ・ストリームへのエントリの書込みに潜在的に参加する各システムに対するエントリ１００２を含む。例えば、マルチシステム環境が、ログ・ストリームに書込み得る３つのシステム、すなわちシステムＸ、システムＹ及びシステムＺを含む場合、ベクトル内に３つのエントリが存在する。各エントリは、それぞれのシステムにより必要とされる１次ログ・ストリーム内の、最も古いログ・エントリのブロックＩＤ（例えば最小のブロックＩＤ）を含む。
【００５３】
例えば、ベクトル１０００のエントリ１がシステムＸに対応し、システムＸが依然必要とする最も古いブロックＩＤが００４の場合、ブロックＩＤ００４がベクトル・エントリ１内に配置される（図１２参照）。同様に、エントリ３がシステムＺに対応し、ブロックＩＤ００１がシステムＺにより必要とされる最も古いブロックＩＤの場合、ブロックＩＤ００１がエントリ００３内に配置される。更に、可能な最高のブロックＩＤ（例えばｘ’ＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦＦ’）が、例えばシステムＹなどの、切り離されたシステムに対応する任意のベクトル・エントリ内に配置される。
【００５４】
１例として、最終エントリ・ベクトル１０００は、システム・ロガー１１０により提供されるサービスのセットを使用することにより、結合機構１０４のスクラッチ・パッド１１４内に作成される。他の実施例では、最終エントリ・ベクトルが共用外部記憶装置（例えばＤＡＳＤ）上に保持されるか、ベクトルのコピーが各システムの主記憶装置、キャッシュ、または補助記憶装置内に保持される。他の例も可能であり、これらについても本発明の趣旨及び範囲内に含まれる。
【００５５】
図１０のステップ９０２に戻り、最終エントリ・ベクトル１０００が、システムＸが依然必要とする最も古いエントリのブロックＩＤにより更新される。これは例えば、ベクトルが１度に１つのシステムだけにより変更されるように保証する、比較交換（ｃｏｍｐａｒｅ ａｎｄ ｓｗａｐ）プロトコルを用いて達成される。エントリ内に配置されるブロックＩＤは、システムＸの主キュー４００内で、論理的に消去されなかった最低のブロックＩＤである。
【００５６】
ベクトルを更新後、問い合わせ９０４において、前に置換したベクトル・エントリがベクトルの最低のブロックＩＤを含んでいたか否かを判断する。最低のブロックＩＤを含まない場合、追加のアクションは実行されない。しかしながら、最低のブロックＩＤを有する場合、ステップ９０６で、（この例では）同期点マネージャがシステムＸのシステム・ロガーに、ベクトル内の新たな最低ブロックＩＤよりも低い全てのエントリのログ尾部を消去するように要求する。
【００５７】
例えば、ログ・ストリームが３つのシステム、すなわちシステムＸ、システムＹ及びシステムＺにより書込まれるエントリを有すると仮定する（図１３参照）。更に、システムＸが要求する最も古いエントリが００１であり、システムＺが要求する最も古いエントリが００４であり、システムＹがこの時活動状態でないと仮定する（図１４参照）。図１５に示されるように、システムＸがベクトルを、それが依然必要とする最も古いエントリ（例えば図１３のブロックＩＤ００６）により更新するとき、システムＸはそのエントリが前にベクトルの最低のブロックＩＤを含んでいたか否かを判断する。この例では、エントリが最低のブロックＩＤ００１を含んでいたので、システムＸは新たな最低のブロック（例えばブロックＩＤ００４）よりも低い全てのエントリを消去する。すなわち、ブロックＩＤ００３乃至００１が１次ログ・ストリームから物理的に除去され、ブロックＩＤ００４がログ・ストリームの新たな尾部となる。これで尾部消去が完了する。
【００５８】
マルチシステム・ログ・ストリームがマルチシステム環境のシステムにより圧縮される頻度は、システム性能に影響する。本発明の原理に従えば、マルチシステム環境の特定のシステムがログ・ストリームを圧縮する頻度は発見的手法にもとづく。すなわち、各システムがその圧縮レート（すなわち圧縮頻度）を、ログ・ストリームに接続される他のシステムの圧縮レートにもとづき、リアルタイムに調整する。このことが最小サイズのログ・ストリームを保証し、ログ・ストリームが結合機構内にもっぱら含まれる可能性を増加させる。このことは、システム性能に肯定的に影響する。
【００５９】
本発明の原理に従えば、ログ・ストリームがマルチシステム環境のシステムにより圧縮される頻度を歩調合わせするために、圧縮ベクトルが使用される。１実施例では、図１６に示されるように、圧縮ベクトル１２００が、結合機構のスクラッチ・パッド１１４内に保持される。
【００６０】
圧縮ベクトル１２００は複数のエントリ１２０２を含む。圧縮されるログ・ストリームに接続される各システムに対して、１つのエントリ１２０２が存在する。各エントリは圧縮遅れカウントを含み、これは例えば０から２５５の範囲の数を取り得る。この数は、他のシステムのログ・ストリームに対する圧縮活動との比較で、各システムのログ・ストリームに対する圧縮活動を表すために使用される。従って、圧縮遅れカウントは、そのカウントに関連するシステムにより実行されたログ・ストリームに対する圧縮回数を表すのではなく、他のシステムの圧縮回数との比較における各システムの相対的な圧縮回数を示す。
【００６１】
圧縮遅れカウントは、圧縮が実行されるときに更新され、圧縮遅れカウントを更新する１実施例が、図１７に関連して述べられる。図１７の論理は、例えば圧縮を実行したシステムの同期点マネージャにより実行される。従って、もしシステムＸが圧縮を実行した場合、同期点マネージャＸが更新を実行する。
【００６２】
図１７を参照すると、圧縮があるシステム（例えばシステムＸ）により実行されるとき、システムがその主キューに、所定数（例えば１００）の論理的に消去されるエントリが存在することを検出したので、圧縮が実行されたのか否かの初期判断が下される（ステップ１３００）。（このタイプの圧縮は図６に関連して前述し、ここでは”正規圧縮（ｎｏｒｍａｌ ｃｏｍｐｒｅｓｉｏｎ）”と呼ばれる。）
【００６３】
圧縮が正規圧縮の場合、システム（例えばシステムＸ）に対する圧縮遅れカウントが０にセットされ（ステップ１３０２）、ログ・ストリームに接続されるあらゆる他のシステムの圧縮遅れカウントが１増分されるか、２５５にセットされる（いずれか小さい方の値を取る）（ステップ１３０４）。これで更新が完了する。
【００６４】
問い合わせ１３００に戻り、圧縮が正規圧縮でなく、代わりに強制圧縮（ここでは全圧縮（ＣｏｍｐｒｅｓｓＡｌｌ）と呼ぶ）の場合、圧縮を実行するシステムの圧縮遅れカウントが、０にセットされ（ステップ１３０６）、他の圧縮遅れカウントは調整されない。
【００６５】
圧縮遅れカウントの使用が、更に図１８に関連して述べられる。図１８の論理は、システムに関連付けられるタイマがトリガし、強制圧縮が実行されるべきか否かに関する判断が下されるべきことを示すとき、ログ・ストリームに接続されるシステムの同期点マネージャにより実行される。特に、システムに関連付けられるタイマがポップするとき（すなわち、所定の時間間隔が経過するとき）、そのシステムの圧縮遅れカウントがチェックされ、同期点マネージャがログ・ストリームに全圧縮を実行し、それにより尾部消去を可能にする必要があるか否かを判断する。システムが他のシステムと同等の頻度で、正規圧縮を実行していない場合、同期点マネージャは、強制圧縮が必要であることを検出する。
【００６６】
図１８を参照すると、最初に、タイマ・ポップに関連付けられるシステム（図示の例では、システムＺを想定）の圧縮遅れカウントの値がチェックされる（問い合わせ１４００）。システムＺの圧縮遅れカウントの値が０に等しく、少なくとも他のシステムと同等の頻度で、正規圧縮を実行していることを示す場合、システムＺに関連付けられる圧縮ゼロ・カウントが、１増分される（ステップ１４０２）。圧縮ゼロ・カウントは、ローカル記憶装置内に保持され（すなわち、他のシステムにとって使用不能であり）、ローカル・システム（この例ではシステムＺ）により使用され、更新される。これはタイマ・ポップの所定の時間間隔が調整されるべきか否かを決定するために使用される。
【００６７】
その後、圧縮ゼロ・カウントがチェックされ、それが２以上であるか否かが判断される（ステップ１４０４）。圧縮ゼロ・カウントが２未満の場合、調整は実行されず、タイマ・ポップ・ルーチンが完了する。しかしながら、圧縮ゼロ・カウントの値が２以上の場合、タイマが余りに頻繁にポップしており、その結果、強制圧縮（全圧縮）が要求されるか否かをチェックするために、過度な処理時間が使用されている。従って、タイマ・インタバルが増加される（ステップ１４０６）。１例では、タイマ・インタバルが倍増されるが、最大インタバルを越えることはない。これれによりタイマがポップする回数が低減される。
【００６８】
前述の処理に加え、圧縮ゼロ・カウントが０にセットされ（ステップ１４０８）、タイマ・ポップ・ルーチンの処理が完了する。
【００６９】
問い合わせ１４００に戻り、圧縮遅れカウントの値が０よりも大きく、システムＺがログ・ストリームに接続される他のシステムに比較して、十分に頻繁に圧縮していないことを示す場合、システムＺの同期点マネージャが強制圧縮を実行する（ステップ１４１０）。１実施例では、強制圧縮はシステムＺの主キューにある論理的に消去されない全てのエントリを、１次ログ・ストリーム及び主キューに書込む。例えば、図１９乃至図２０を参照し、システムＺがその主キュー１５００に、ブロックＩＤ００１乃至００３を含む３つのエントリを有し、それらのエントリの２つ、すなわちブロックＩＤ００１及びブロックＩＤ００３が論理的に消去されていない場合、これらの２つのエントリが１次ログ・ストリームの頭部に再書込みされ、従って、新たなブロックＩＤを与えられる。新たなブロックＩＤ００８が旧ブロックＩＤ００１に対応し、新たなブロックＩＤ００９が旧ブロックＩＤ００３に対応すると仮定すると、図２０に示されるように、ブロックＩＤ００８及びブロックＩＤ００９が、システムＺの主キューに再書込みされる。図示のように、ブロックＩＤ００２はもはや要求されないので（すなわち論理的に消去されたので）、主キューまたは１次ログ・ストリームに再書込みされない。
【００７０】
図１８に戻り、システムＺによる強制圧縮の実行に続き、システムＺの圧縮遅れカウントが選択値、例えばログ・ストリームに接続されるシステムの数から１を差し引いた値の２倍よりも大きいか否かが判断される（すなわち、圧縮遅れカウント＞２ｘ（システム数−１）か？）。これはシステムＺが、ログ・ストリームに接続される他のシステムの少なくとも１つよりも遅いトランザクション・レートを有し、そのログ・ストリームをより少ない頻度で圧縮していることを示す。この差を補償するためにより頻繁な圧縮を生じるように、タイマ・ポップがリアルタイムに調整される。圧縮遅れカウントが選択値よりも大きい場合、タイマ・インタバルが減少され、それによりタイマがより頻繁にトリガされることになる（ステップ１４１４）。１例では、タイマ・インタバルが半減される。その後、システムＺの圧縮ゼロ・カウントが０にセットされ（ステップ１４０８）、タイマ・ポップ・ルーチンの処理が完了する。
【００７１】
問い合わせ１４１２に戻り、圧縮遅れカウントが選択値よりも大きくない場合、この時点でタイマ・インタバルを減少する必要はない。従って、システムＺの圧縮ゼロ・カウントは０にセットされ（ステップ１４０８）、処理が完了する。
【００７２】
前述の処理は、システムがログ・ストリームを圧縮する頻度をリアルタイムに調整するための機能に相当する。システムがその主キューが所定数の論理的に消去されるエントリ、例えば１００の論理的に消去されるエントリを有することを検出するとき、圧縮が実行される。更に、システムに関連付けられるタイマがポップし、別のシステムが既に圧縮を実行済みであるが、ポップしたタイマのシステムがまだ圧縮を実行していない場合、圧縮が実行される。タイマがポップする頻度も、本発明の原理に従い、タイマ・ポップが過度な処理時間を使用しないように制御される。
【００７３】
各同期点マネージャは、活動作業負荷を処理している最速のシステムのスピードで、圧縮または全圧縮を実行する。例えば、あるシステムが１秒につき１００トランザクションを処理しており、ログ・ストリームに接続される他の２つのシステムが、１秒につき１トランザクションを処理している場合、他の２つのシステムは１秒につき１００トランザクションのレートで、圧縮または全圧縮を発行する。もしこれが達成されない場合、ログ・ストリームのサイズが成長し始める。なぜなら、高速のシステムが低速のシステムにより、尾部消去を発行することを阻止されるからである。
【００７４】
前述のように、ログ・ストリームは１つ以上のデータ（例えばログ・データ）を含む。従って、１つ以上のデータを含む他のエンティティが、ログ・ストリームの定義内に含まれる。これらのエンティティには、ログ・ファイル及びログ・データ・セットなどが含まれる。
【００７５】
前述のマルチシステム環境は、１例に過ぎない。本発明は本発明の趣旨から逸れることなく、他のシステムまたは環境内でも使用され、組み込まれ得る。例えば、異なるアーキテクチャまたはオペレーティング・システムが、本発明の趣旨から逸れることなく使用され得る。別の例として、１つ以上の中央処理コンプレックスが結合機構に接続され、各中央処理コンプレックスが、オペレーティング・システムを実行する１つ以上の中央処理ユニットを含み得る。更に別の実施例では、コンピュータ・システムが複数の結合機構を含む。更に、本発明は、結合機構を含まないコンピュータ・システムにも適用可能である。
【００７６】
更に、本発明の趣旨及び範囲から逸れることなく、システムの他のコンポーネントも、本発明により管理及び圧縮され得る関連ログ・ストリームを有し得る。
【００７７】
更に別の実施例では、システム・ロガーがオペレーティング・システムとは別のコンポーネントである。更に、システム・ロガー以外のコンポーネントが、ログ・ストリームにエントリを書込み、また消去できる。更に別の実施例では、同期点マネージャだけが圧縮を実行できる、或いは圧縮を歩調合わせできる唯一のコンポーネントではない。別の実施例では、資源マネージャなどのシステムの他のコンポーネントが、圧縮または歩調合わせ技術を実行する。再度、ここで述べたマルチシステム環境は、１例に過ぎない。
【００７８】
本発明は、例えばコンピュータ読取り可能媒体を有する製造物（例えば１つ以上のコンピュータ・プログラム製品）内に含まれ得る。媒体は例えば、本発明の機能を提供及び容易にするコンピュータ読取り可能プログラム・コード手段を実装する。製造物は、コンピュータ・システムの一部として含まれるか、別々に販売される。
【００７９】
ここで示されたフロー図は、典型例に過ぎない。本発明の趣旨から逸れることなく、これらのフロー図またはステップ（またはオペレーション）に対する多くの変化が存在し得る。例えば、ステップが異なる順序で実行されたり、或いはステップが追加、消去または変更されてもよい。これらの全ての変化は、本発明の一部と見なされる。
【００８０】
まとめとして、本発明の構成に関して以下の事項を開示する。
【００８１】
（１）マルチシステム・ログ・ストリームが圧縮される頻度を歩調合わせする方法であって、
前記マルチシステム・ログ・ストリームがマルチシステム環境のあるシステムにより圧縮されるレートを、前記マルチシステム・ログ・ストリームが、前記マルチシステム環境の少なくとも１つの他のシステムにより圧縮される頻度との比較において確認するステップと、
前記あるシステムが前記マルチシステム・ログ・ストリームを圧縮する頻度を、リアルタイムに調整するステップと
を含む、方法。
（２）前記確認するステップが、前記あるシステムの圧縮遅れカウントをチェックするステップを含み、前記圧縮遅れカウントが、前記マルチシステム・ログ・ストリームが前記少なくとも１つの他のシステムにより圧縮される頻度との比較において、前記あるシステムが前記マルチシステム・ログ・ストリームを圧縮しているレートを表す、前記（１）記載の方法。
（３）前記あるシステムが前記マルチシステム・ログ・ストリームを圧縮するとき、前記圧縮遅れカウントを更新するステップを含む、前記（２）記載の方法。
（４）前記あるシステムが前記マルチシステム・ログ・ストリームを圧縮するとき、前記少なくとも１つの他のシステムの少なくとも１つの他の圧縮遅れカウントをセットするステップを含む、前記（３）記載の方法。
（５）前記調整するステップが、前記確認レートから、前記あるシステムが前記マルチシステム・ログ・ストリームを、前記少なくとも１つの他のシステムよりも遅いレートで圧縮していることが判明するとき、前記あるシステムが前記マルチシステム・ログ・ストリームを圧縮する頻度を増加するステップを含む、前記（１）記載の方法。
（６）前記増加するステップが、前記あるシステムによる圧縮の実行を強制するステップを含む、前記（５）記載の方法。
（７）前記確認レートが、前記あるシステムが圧縮を実行する頻度が増加されるべきことを示しているか否かを、所定時間間隔で決定するステップを含む、前記（５）記載の方法。
（８）前記あるシステムの前記確認レートが選択値と所定の関係を有すると判断されるとき、前記所定時間間隔を減少するステップを含む、前記（７）記載の方法。
（９）前記確認レートが、前記マルチシステム・ログ・ストリームに接続されるシステムの数から１を差し引いた値の２倍よりも大きいことが判明するとき、前記減少するステップが、前記所定時間を半減するステップを含む、前記（８）記載の方法。
（１０）所定時間間隔で前記確認レートを所定値と比較し、前記あるシステムが圧縮を実行する頻度が調整されるべきか否かを決定するステップを含む、前記（１）記載の方法。
（１１）前記確認レートが前記所定値と所定の関係を有するとき、前記調整が実行される、前記（１０）記載の方法。
（１２）前記あるシステムの前記確認レートが選択値と所定の関係を有すると判断されるとき、前記所定時間間隔を減少するステップを含む、前記（１０）記載の方法。
（１３）前記比較がより少ない頻度で実行されるべきと決定されるとき、前記所定時間間隔を増加するステップを含む、前記（１０）記載の方法。
（１４）前記マルチシステム・ログ・ストリームが、少なくとも部分的に、前記マルチシステム環境の前記あるシステム及び前記少なくとも１つの他のシステムに接続される結合機構内に配置される、前記（１）記載の方法。
（１５）マルチシステム・ログ・ストリームが圧縮される頻度を歩調合わせする方法であって、
前記マルチシステム・ログ・ストリームがマルチシステム環境のあるシステムにより圧縮されるレートを、前記マルチシステム・ログ・ストリームが、前記マルチシステム環境の少なくとも１つの他のシステムにより圧縮される頻度との比較において確認するステップと、
所定時間間隔で前記確認レートを所定値と比較し、前記あるシステムが前記マルチシステム・ログ・ストリームを圧縮する頻度が、調整されるべきか否かを決定するステップと、
前記比較が調整の必要性を示す場合、前記あるシステムが前記マルチシステム・ログ・ストリームを圧縮する頻度を、リアルタイムに調整するステップと、
前記所定時間間隔が変更されるべきか否かを決定するステップと、
前記所定時間間隔が変更されるべきと決定される場合、前記所定時間間隔を変更し、前記比較が実行される頻度を調整するステップと
を含む、方法。
（１６）前記比較するステップが、前記あるシステムによる圧縮の頻度が増加されるべきことを示す、前記（１５）記載の方法。
（１７）前記決定するステップが、前記所定時間間隔が減少されるべきことを示し、それにより前記比較するステップがより頻繁に実行される、前記（１６）記載の方法。
（１８）前記決定するステップが、前記所定時間間隔が増加されるべきことを示し、それにより前記比較するステップがより少ない頻度で実行される、前記（１５）記載の方法。
【図面の簡単な説明】
【図１】本発明のログ・ストリーム圧縮歩調合わせ機能を組み込み、使用するマルチシステム環境の１例を示す図である。
【図２】本発明の原理に従い管理される、図１のマルチシステム環境の１次ログ・ストリームの１例を示す図である。
【図３】図２の１次ログ・ストリームに新たなエントリを追加するために使用される論理の１実施例を示す図である。
【図４】本発明の原理に従い使用される主キューの１実施例を示す図である。
【図５】本発明の原理に従い、図２の１次ログ・ストリームからエントリを論理的に消去するために使用される論理の１実施例を示す図である。
【図６】図２の１次ログ・ストリームを圧縮するために使用される論理の１実施例を示す図である。
【図７】本発明の原理に従い使用される図４の主キューの別の例を示す図である。
【図８】本発明の原理に従い使用される圧縮キューの１例を示す図である。
【図９】本発明の原理に従い、第１のエントリが７番目のエントリとして書換えられた、図２の１次ログ・ストリームの別の例を示す図である。
【図１０】図２の１次ログ・ストリームから、論理的に消去されたエントリを物理的に除去するために使用される論理の１実施例を示す図である。
【図１１】図１０の尾部消去の間に更新される最終入力ベクトルの例を示す図である。
【図１２】図１０の尾部消去の間に更新される最終入力ベクトルの例を示す図である。
【図１３】本発明の原理に従い管理される図２の１次ログ・ストリームの別の例を示す図である。
【図１４】本発明の原理に従い使用される図１１の最終入力ベクトルの他の例を示す図である。
【図１５】本発明の原理に従い使用される図１１の最終入力ベクトルの他の例を示す図である。
【図１６】本発明の原理に従い使用される圧縮ベクトルの１例を示す図である。
【図１７】本発明の原理に従い、図１６の圧縮ベクトル内に記憶される圧縮遅れカウントを更新するために使用される論理の１実施例を示す図である。
【図１８】本発明の原理に従い、タイマ・ポップ・ルーチンの間に、圧縮が強制されるべきか否かを決定するために使用される論理の１実施例を示す図である。
【図１９】本発明の原理に従い使用される、システムＺのための主キューの例を示す図である。
【図２０】本発明の原理に従い使用される、システムＺのための主キューの例を示す図である。
【符号の説明】
１００ マルチシステム環境
１０２ システム
１０４ 結合機構
１０６ オペレーティング・システム
１０８ 資源マネージャ
１１０ システム・ロガー・コンポーネント
１１２ 同期点マネージャ
１１４ スクラッチ・パッド
１１６、２００ ログ・ストリーム
２０２ ログ・エントリ
２０４ ブロックＩＤ
４００ 主キュー
４０２ 要素
６１２、６２４、１３００、１４００ 問い合わせ
７００ 圧縮キュー
１０００ 最終エントリ・ベクトル
１００２、１２０２ エントリ
１２００ 圧縮ベクトル
Claims (15)
- マルチシステム環境のあるシステムがマルチシステム・ログ・ストリームを圧縮する頻度を歩調合わせする方法であって、
前記あるシステムが、前記マルチシステム・ログ・ストリームを圧縮するレートを、前記マルチシステム・ログ・ストリームが、前記マルチシステム環境の少なくとも１つの他のシステムにより圧縮される頻度との比較において確認するステップと、
前記あるシステムが前記マルチシステム・ログ・ストリームを圧縮する頻度を、リアルタイムに調整するステップと
を含み、
前記確認するステップが、前記あるシステムの圧縮遅れカウントをチェックするステップを含み、前記圧縮遅れカウントが、前記マルチシステム・ログ・ストリームが前記少なくとも１つの他のシステムにより圧縮される頻度との比較において、前記あるシステムが前記マルチシステム・ログ・ストリームを圧縮しているレートを表し、前記あるシステムが前記マルチシステム・ログ・ストリームを圧縮するとき、前記あるシステムが前記圧縮遅れカウントを更新するステップと、前記あるシステムが前記少なくとも１つの他のシステムの少なくとも１つの他の圧縮遅れカウントをセットするステップを含む、方法。 - 前記調整するステップが、前記確認したレートから、前記あるシステムが前記マルチシステム・ログ・ストリームを、前記少なくとも１つの他のシステムよりも遅いレートで圧縮していることが判明するとき、前記あるシステムが前記マルチシステム・ログ・ストリームを圧縮する頻度を増加するステップを含む、請求項１記載の方法。
- 前記増加するステップが、前記あるシステムによる圧縮の実行を強制するステップを含む、請求項２記載の方法。
- 前記確認したレートが、前記あるシステムが圧縮を実行する頻度が増加されるべきことを示しているか否かを、前記あるシステムが所定時間間隔で決定するステップを含む、請求項２記載の方法。
- 前記あるシステムの前記確認したレートが選択値と所定の関係を有すると判断されるとき、前記あるシステムが前記所定時間間隔を減少するステップを含む、請求項４記載の方法。
- 前記確認したレートが、前記マルチシステム・ログ・ストリームに接続されるシステムの数から１を差し引いた値の２倍よりも大きいことが判明するとき、前記減少するステップが、前記所定時間を半減するステップを含む、請求項５記載の方法。
- 前記あるシステムが、所定時間間隔で前記確認したレートを所定値と比較し、前記あるシステムが圧縮を実行する頻度が調整されるべきか否かを決定するステップを含む、請求項１記載の方法。
- 前記確認したレートが前記所定値と所定の関係を有するとき、前記調整が実行される、請求項７記載の方法。
- 前記あるシステムの前記確認したレートが選択値と所定の関係を有すると判断されるとき、前記あるシステムが前記所定時間間隔を減少するステップを含む、請求項７記載の方法。
- 前記比較がより少ない頻度で実行されるべきと決定されるとき、前記あるシステムが前記所定時間間隔を増加するステップを含む、請求項７記載の方法。
- 前記マルチシステム・ログ・ストリームが、少なくとも部分的に、前記マルチシステム環境の前記あるシステム及び前記少なくとも１つの他のシステムに接続される結合機構内に配置される、請求項１記載の方法。
- マルチシステム環境のあるシステムがマルチシステム・ログ・ストリームを圧縮する頻度を歩調合わせする方法であって、
前記あるシステムが、前記マルチシステム・ログ・ストリームを圧縮するレートを、前記マルチシステム・ログ・ストリームが、前記マルチシステム環境の少なくとも１つの他のシステムにより圧縮される頻度との比較において確認するステップと、
前記あるシステムが、所定時間間隔で前記確認レートを所定値と比較し、前記あるシステムが前記マルチシステム・ログ・ストリームを圧縮する頻度が、調整されるべきか否かを決定するステップと、
前記比較が調整の必要性を示す場合、前記あるシステムが、前記マルチシステム・ログ・ストリームを圧縮する頻度を、リアルタイムに調整するステップと、
前記あるシステムが、前記所定時間間隔が変更されるべきか否かを決定するステップと、
前記所定時間間隔が変更されるべきと決定される場合、前記あるシステムが、前記所定時間間隔を変更し、前記比較が実行される頻度を調整するステップと
を含み、
前記確認するステップが、前記あるシステムの圧縮遅れカウントをチェックするステップを含み、前記圧縮遅れカウントが、前記マルチシステム・ログ・ストリームが前記少なくとも１つの他のシステムにより圧縮される頻度との比較において、前記あるシステムが前記マルチシステム・ログ・ストリームを圧縮しているレートを表し、前記あるシステムが前記マルチシステム・ログ・ストリームを圧縮するとき、前記あるシステムが前記圧縮遅れカウントを更新するステップと、前記あるシステムが前記少なくとも１つの他のシステムの少なくとも１つの他の圧縮遅れカウントをセットするステップを含む、方法。 - 前記比較するステップが、前記あるシステムによる圧縮の頻度が増加されるべきことを示す、請求項１２記載の方法。
- 前記決定するステップが、前記所定時間間隔が減少されるべきことを示し、それにより前記比較するステップがより頻繁に実行される、請求項１３記載の方法。
- 前記決定するステップが、前記所定時間間隔が増加されるべきことを示し、それにより前記比較するステップがより少ない頻度で実行される、請求項１２記載の方法。
Applications Claiming Priority (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| US09/262,250 US6438609B1 (en) | 1999-03-04 | 1999-03-04 | Method of pacing the frequency at which systems of a multisystem environment compress log streams |
| US09/262250 | 1999-03-04 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2000284993A JP2000284993A (ja) | 2000-10-13 |
| JP3587445B2 true JP3587445B2 (ja) | 2004-11-10 |
Family
ID=22996792
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2000060776A Expired - Lifetime JP3587445B2 (ja) | 1999-03-04 | 2000-03-06 | マルチシステム環境のシステムがログ・ストリームを圧縮する頻度を歩調合わせする方法 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US6438609B1 (ja) |
| JP (1) | JP3587445B2 (ja) |
Families Citing this family (4)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6539389B1 (en) * | 1999-03-04 | 2003-03-25 | International Business Machines Corporation | Pacing the frequency at which systems of a multisystem environment compress log streams |
| US20040044796A1 (en) * | 2002-09-03 | 2004-03-04 | Vangal Sriram R. | Tracking out-of-order packets |
| US7181544B2 (en) * | 2002-09-03 | 2007-02-20 | Intel Corporation | Network protocol engine |
| US7324540B2 (en) | 2002-12-31 | 2008-01-29 | Intel Corporation | Network protocol off-load engines |
Family Cites Families (16)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| GB8503867D0 (en) | 1985-02-15 | 1985-03-20 | Delta Technical Services Ltd | Data loggers |
| US5317739A (en) | 1992-03-30 | 1994-05-31 | International Business Machines Corp. | Method and apparatus for coupling data processing systems |
| US5471631A (en) * | 1992-10-19 | 1995-11-28 | International Business Machines Corporation | Using time stamps to correlate data processing event times in connected data processing units |
| US5537588A (en) | 1994-05-11 | 1996-07-16 | International Business Machines Corporation | Partitioned log-structured file system and methods for operating the same |
| US5737600A (en) | 1994-09-12 | 1998-04-07 | International Business Machines Corporation | Method and system for log management in a coupled data processing system |
| US6021408A (en) | 1996-09-12 | 2000-02-01 | Veritas Software Corp. | Methods for operating a log device |
| US5996054A (en) | 1996-09-12 | 1999-11-30 | Veritas Software Corp. | Efficient virtualized mapping space for log device data storage system |
| US5920875A (en) | 1997-03-28 | 1999-07-06 | International Business Machines Corporation | Tail compression of a sparse log stream of a computer system |
| US6108667A (en) * | 1997-03-28 | 2000-08-22 | International Business Machines Corporation | System of compressing a log stream using a scratch pad of logically deleted entries |
| US5956735A (en) | 1997-03-28 | 1999-09-21 | International Business Machines Corporation | System of compressing the tail of a sparse log stream of a computer system |
| US6092084A (en) * | 1997-03-28 | 2000-07-18 | International Business Machines Corporation | One system of a multisystem environment taking over log entries owned by another system |
| US5999935A (en) | 1997-03-28 | 1999-12-07 | International Business Machines Corporation | Tail compression of a sparse log stream of a multisystem environment |
| US6076095A (en) * | 1997-03-28 | 2000-06-13 | International Business Machines Corporation | Method of one system of a multisystem environment taking over log entries owned by another system |
| US6125393A (en) * | 1997-03-28 | 2000-09-26 | International Business Machines Corporation | System of compressing the tail of a sparse log stream of a multisystem environment |
| US5966708A (en) | 1997-03-28 | 1999-10-12 | International Business Machines | Tail compression of a log stream using a scratch pad of logically deleted entries |
| US6208273B1 (en) | 1999-01-29 | 2001-03-27 | Interactive Silicon, Inc. | System and method for performing scalable embedded parallel data compression |
-
1999
- 1999-03-04 US US09/262,250 patent/US6438609B1/en not_active Expired - Lifetime
-
2000
- 2000-03-06 JP JP2000060776A patent/JP3587445B2/ja not_active Expired - Lifetime
Also Published As
| Publication number | Publication date |
|---|---|
| JP2000284993A (ja) | 2000-10-13 |
| US6438609B1 (en) | 2002-08-20 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US7383290B2 (en) | Transaction processing systems and methods utilizing non-disk persistent memory | |
| US7124128B2 (en) | Method, system, and program for managing requests to tracks subject to a relationship | |
| US7574557B2 (en) | Updated data write method using journal log | |
| US7055009B2 (en) | Method, system, and program for establishing and maintaining a point-in-time copy | |
| US10339132B2 (en) | Flow control technique for EOS system | |
| US7293145B1 (en) | System and method for data transfer using a recoverable data pipe | |
| US7107396B2 (en) | Chaining of blocks for optimal performance with DASD (Direct Access Storage Devices) free nonvolatile updates | |
| US8499004B2 (en) | File system with optimistic I/O operations on shared storage | |
| US7085892B2 (en) | Method, system, and program for removing data in cache subject to a relationship | |
| US20040260735A1 (en) | Method, system, and program for assigning a timestamp associated with data | |
| US8819059B2 (en) | Facilitation of search, list, and retrieval operations on persistent data set using distributed shared memory | |
| US6202136B1 (en) | Method of creating an internally consistent copy of an actively updated data set without specialized caching hardware | |
| US20220318223A1 (en) | Rowgroup consolidation with global delta accumulation and versioning in distributed systems | |
| JP3587446B2 (ja) | マルチシステム環境のシステムがログ・ストリームを圧縮する頻度を歩調合わせするプログラム製品 | |
| US5956735A (en) | System of compressing the tail of a sparse log stream of a computer system | |
| US5999935A (en) | Tail compression of a sparse log stream of a multisystem environment | |
| WO2022048358A1 (zh) | 数据处理方法、装置及存储介质 | |
| US6125393A (en) | System of compressing the tail of a sparse log stream of a multisystem environment | |
| US5966708A (en) | Tail compression of a log stream using a scratch pad of logically deleted entries | |
| US6539389B1 (en) | Pacing the frequency at which systems of a multisystem environment compress log streams | |
| JP2002132582A (ja) | 圧縮メモリ・システムの再利用スペース予約 | |
| US6345280B1 (en) | System of compressing a log stream using a scratch pad of logically deleted entries | |
| JP3587445B2 (ja) | マルチシステム環境のシステムがログ・ストリームを圧縮する頻度を歩調合わせする方法 | |
| US5920875A (en) | Tail compression of a sparse log stream of a computer system | |
| US8909875B1 (en) | Methods and apparatus for storing a new version of an object on a content addressable storage system |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20040302 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20040528 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20040602 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20040727 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20040727 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20040806 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 3587445 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080820 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20080820 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090820 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20090820 Year of fee payment: 5 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100820 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20100820 Year of fee payment: 6 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20110820 Year of fee payment: 7 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120820 Year of fee payment: 8 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130820 Year of fee payment: 9 |
|
| EXPY | Cancellation because of completion of term |