JP2005316635A - データ処理システムおよび方法並びにその処理プログラム - Google Patents

Abstract

【課題】
データベース管理システムで障害が発生した場合、回復処理に必要なログデータを記憶装置サブシステムから読み込む際に、記憶装置サブシステム内のキャッシュでログデータのキャッシュヒットを保証することはできないため、ディスク装置へのアクセスが発生し、読み込み処理に時間がかかり、回復処理に時間がかかる可能性が高いという問題があった。
【解決手段】
ホストコンピュータ上のデータベース管理システムから、ログデータを格納する記憶装置サブシステムを制御し、記憶装置サブシステムのディスクキャッシュ上に、回復に必要となるログデータのサイズ分のログ専用バッファ領域を確保しておく。このバッファ領域にログを書き出し、ホストコンピュータの障害発生時にはディスクキャッシュからログデータをディスク装置にアクセスすることなく読み出せるようにする。
【選択図】 図１

Description

本発明は、トランザクション処理を実施するデータ装置におけるログデータのキャッシングを記憶装置で実現するデータ処理技術に関する。

近年では、コンピュータシステムは停止することなくサービスを提供することが求められており、システムダウン時間は損失として捉えられる。システムダウン時間を削減するためには、高速復旧技術が必須でおり、特にストレージ技術による復旧支援が求められている。

従来のデータベース管理システムでは、ホストコンピュータ上から記憶装置サブシステムに対し、データブロックおよびログブロックの入出力を行う。ここで、入出力処理の効率を向上するために、ホストコンピュータのメモリ上にバッファを設定し、このバッファ上に入出力するデータブロックおよびログブロックをキャッシングすることにより、できるだけ記憶装置との間の入出力処理を削減する。

また、データベース管理システムでは、障害発生時にログだけで回復処理を行うと回復時間が多大になってしまうため、定期的にチェックポイントを取得しデータベースの整合性を保証する。チェックポイントを取得すると、バッファにキャッシングされている更新されたデータブロックを記憶装置上にすべて書き出し、再開始処理時に必要な管理情報を記憶する。従って、チェックポイントが再開始処理を行う際の起点となるため、それ以前のログは不要となり、回復時間をその分短縮することができる。一般にチェックポイントは稼働中に出力したログブロック数がある一定の数に達した時点に取得することが多い。このような技術は非特許文献1に記載されている。

また、記憶装置サブシステム側で入出力処理の処理効率を向上するための技術として、ディスクキャッシュが用いられている。ホストコンピュータからの要求データがディスクキャッシュに存在する場合にはディスク装置にアクセスせず、ディスクキャッシュ内のデータをホストコンピュータとやりとりすることで、入出力処理を高速化できる。従来のディスクキャッシュの割り当ての制御方法では、ホストコンピュータ上のＯＳから指定された動作モードに従い、ＬＲＵアルゴリズムやＦＩＦＯアルゴリズムを適用することで割り当てを行っている。ディスクキャッシュのヒット率を向上する手段の1つとして、特許文献１では、複数のアプリケーションが多重に動作している環境で効率的な制御を行うために、区分されたディスク装置の領域毎にアクセス頻度を取得し、ディスクキャッシュを割り当てる際に、ディスクキャッシュに格納されているデータブロックのうち、アクセス頻度が低い領域のものから追い出す制御を行っている。

ＷＯ９９／４０５１６号 Abraham Silberschatz, Henry F.Korth , S. Sudarshan ："DATABASE SYSTEM CONCEPTS"、McGraw-Hill社、1997、PP.511-p535

従来の記憶装置サブシステムにおけるディスクキャッシュの割り当て処理は、記憶装置サブシステムの中で独立して行っており、そこではデータブロックのアクセス頻度や登録順序しか制御に使用していないため、ホストコンピュータ上のアプリケーション側から、ディスクキャッシュの割り当てを制御することはできない。
データベース管理システムで障害が発生した場合も、回復処理に必要なログデータを記憶装置サブシステムから読み込む際に、ログデータのディスクキャッシュヒットを保証することはできないため、ディスク装置へのアクセスが発生し、読み込み処理に時間がかかり、それに伴い回復処理に時間がかかる可能性が高い。

本発明の目的は、ホストコンピュータ上のデータベース管理システムから記憶装置サブシステムを制御することで、回復処理に必要なログデータ全体のディスクキャッシュヒットを保証し、障害発生時のログデータの読込みを高速化し、回復処理にかかる時間を短縮化することにある。

本発明は、ホストコンピュータ上のデータベース管理システムから、前記データベース管理システムのログデータを格納する記憶装置サブシステムを制御し、記憶装置サブシステム内のディスクキャッシュ上に、チェックポイント間に出力されるログデータのサイズ分のログ専用バッファ領域をあらかじめ確保しておき、このバッファ領域にログを書き出し、ホストコンピュータの障害発生時にはディスクキャッシュからログデータをディスク装置にアクセスすることなく読み出せるようにするものである。さらに、ホストコンピュータ上のデータベース管理システムから新たなチェックポイントの通知を受信すると、ディスクキャッシュ内に格納されたログデータをディスク装置に出力するものである。

データ処理装置で回復に必要なログ情報を記憶装置側でキャッシュしているため、前記必要なログ情報を読み込む時間が短縮でき、回復処理にかかる時間を短縮することが可能となる。

以下、図面を用いて、発明の詳細を説明する。
図１は、本発明の実施形態の一つを表すシステム構成図である。ホストコンピュータ１０１とディスクサブシステム２０１は、ネットワーク１０７で接続されている。ホストコンピュータ１０１では、データベース管理システム１０２が稼動し、メモリ１０４の中にＤＢ用バッファ１０５とログ用バッファ１０６を持つ。ディスクサブシステム２０１では、ネットワークインタフェース制御部２０２でホストコンピュータからの命令を受け付け、それを受けて動作するディスク制御部２０３から、デバイスインタフェース制御部２０８を通してディスク装置２２０へのアクセスを行う。ディスク装置２２０は、低速な装置であるため、キャッシュメモリ２０４を介して入出力処理を一括して行う。キャッシュメモリ２０４は、ホストコンピュータ１０１から書き込み要求が発生した場合に、ディスク装置２２０に書き込むデータを一時的に保持するために使用される。キャッシュメモリ２０４内にデータを書き込んだ時点で書き込み完了をホストコンピュータ１０１に通知するので、書き込みを高速に行ったように見せることができる。また、データを読み込む場合には、キャッシュメモリ２０４は読み込んだデータを一時的に格納しておくために使用される。再度同一データの読込みがホストコンピュータ１０１から要求された場合に、キャッシュメモリ２０４からホストコンピュータ１０１へデータを返送することで、読み込み処理を高速化することができる。データベース管理システム１０２やログ用キャッシュ制御部１０３、ディスク制御部２０３、ディスク制御部２０３内の２１１〜２１４の各処理部は、プログラムやオブジェクトやハードウェアで実現することができる。

本実施例では、ディスクサブシステム２０１内のキャッシュメモリ２０４を、ログ用キャッシュ領域２０６と通常用キャッシュ領域２０５に分けて管理を行う。ディスク制御部２０３は、ログブロックの入出力処理は、ログ用キャッシュ領域２０６を経由して行い、データブロックの入出力処理は通常用キャッシュ領域２０５を経由して行うように制御をする。ログ用キャッシュ領域２０６に関する情報はログ用キャッシュ管理テーブル２０９に登録される。

ログ用キャッシュ領域２０６上に確保されるログ用バッファ２０７の領域確保処理は、ディスクサブシステム２０１において、データベース管理システム１０２のプログラム起動後かチェックポイント取得後の初回のログブロック書き込み命令を受信した場合に行う。データベース管理システム１０２は、ディスクサブシステム２０１に対して、ログブロック書き込み命令とともにログ用バッファ２０７のサイズを通知する。ここで、ログ用バッファ２０７のサイズは、各チェックポイントの間に出力するログブロック量に相当するサイズを指定する。ディスクサブシステム２０１では、ディスク制御部２０２のログ用バッファ確保プログラム２１２を起動し、そのサイズのバッファ２０７をキャッシュメモリ２０４内のログ用キャッシュ領域２０６上に確保する。このとき、確保したログ用バッファ２０７の情報はログ用キャッシュ管理テーブル２０９に登録する。ここでは、データベース管理システムについての具体例として説明しているが、ログ情報を生成するトランザクションモニタシステムやログ情報を生成するプログラムに効果的である。前記ディスクサブシステムは、ディスクアレイシステム（アレイディスクシステム）やディスク装置にも適用可能である。データベース管理システムでは、障害に備え、定期的にＤＢの整合性を保証する為、稼動中にチェックポイントを取得する。チェックポイントは、システム障害時の再開始処理を行う起点となるデータベースの整合性が保証されたポイントとなる。主にチェックポイントは稼動中に出力したログブロック数がある一定の回数に達した時点に取得する場合が多い。このようなチェックポイント処理では、その時点のデータベースバッファにおける更新が行われたデータベースブロックを記憶装置上に全て書き出す処理が行われる。

次に、トランザクション処理をしている間の動作を説明する。例えば、データベース管理システム１０２が、データベースに格納されたデータの更新要求を、クライアントプログラムから受信した場合、データベース管理システム１０２は、回復に必要なデータ（行識別子など）をログ用バッファ１０５上に書き出してから、データ用バッファ１０５に更新後のデータを書き出す。クライアントプログラムからトランザクションの完了を表すＣＯＭＭＩＴ要求をデータベース管理システム１０２が受理するか、ログ用バッファ１０５が溢れた場合に、データベース管理システム１０２はログ用バッファ１０６のデータをディスクサブシステム２０１に転送する。ディスクサブシステム２０１はディスク制御部２０２のログ書き込みプログラム２１１を呼び出し、データベース管理システム１０２から受信したログデータをログ用キャッシュ領域２０６上に確保されたログ用バッファ２０７に書き込む。このとき、ログ書き込みプログラム２１１は、ログ用バッファ管理テーブル２１０に対し、ログ用バッファ２０７に関する情報を更新する。

データベース管理システム１０２において、出力したログブロック量がある一定の量に達するか、コマンドで指示されると、チェックポイントを取得する。本実施例では、このとき、データベース管理システム１０２のログ用キャッシュ制御部１０３からディスクサブシステム２０１に対しバッファフラッシュ命令を通知し、ディスク制御部２０２のバッファフラッシュプログラム２１３が動作する。バッファフラッシュプログラム２１３は、ログ用バッファ２０７に書き込まれているデータをディスク装置２２０にすべて書き出し、ログ用バッファ２０７の領域を解放する。このとき、ログ用キャッシュ管理テーブル２０９とログ用バッファ管理テーブル２１０から、ログ用バッファ２０７に格納されている情報を削除する。

障害が発生した場合、データベース管理システム１０２を再開始する際に、ログデータを使用してデータベースの状態を回復するため、ディスクサブシステム２０１に対しログデータの読込み要求を行う。ここで必要となるログデータは、障害発生前に取得した最終チェックポイント以降のものであると仮定する。従って、本実施例のログ用キャッシュ領域の制御方式を適用すると、読み込まれるログデータのログブロックはすべて、ディスクサブシステム２０１のキャッシュメモリ２０４内のログ用バッファ２０７に存在することが保証されるため、ディスク装置２２０にアクセスする必要がなくなり、その分ログデータの読込み処理を高速に行うことができる。

本実施例で提案しているディスクサブシステム２０１を用いることにより、ログ用バッファ２０７をＤＢ管理システム１０２側にログ用バッファ１０６の代用として用いることができる。つまり、ＤＢ管理システム１０２では、ログ情報を直接、ディスクサブシステム２０１のログ用バッファ１０６へ格納するようにしても良い。本実施例を機能させるための前記プログラムは、ＣＤ−ＲＯＭ等の記録媒体に記録され磁気ディスク等に格納された後、メモリにロードされて実行されるものとする。なお前記プログラムを記録する記録媒体はＣＤ−ＲＯＭ以外の他の記録媒体でも良い。また前記プログラムを当該記録媒体から情報処理装置にインストールして使用しても良いし、ネットワークを通じて当該記録媒体にアクセスして前記プログラムを使用するものとしても良い。尚、他の装置のプログラムについても同様である。

図２(Ａ)は、ログ用キャッシュ領域を管理するために使用する管理テーブルの構成を示している。ログ用キャッシュ管理テーブルは、図1のログ用キャッシュ管理テーブル２０９に対応している。図1に示すように、本実施例では、ディスクサブシステム２０１のキャッシュメモリ２０４の制御を、ログ用キャッシュ領域２０６と通常用キャッシュ領域２０５に区分けをして行う。キャッシュメモリの領域が不足してログ用バッファ２０７の領域が確保できない場合は、従来どおりのキャッシュ管理を行うように制御する。このキャッシュ制御モードを管理するために、図２(Ａ)に示すログ用キャッシュ管理テーブルを使用する。図２(Ｂ)のログ用バッファ管理テーブルは図1のログ用バッファ管理テーブル２１０に対応している。ログ用バッファ管理テーブルには、ログ用バッファ２０７の中に書き込まれているログブロックの情報が登録される。ログデータ領域を構成するファイルは、ホストコンピュータ上のオペレーティングシステムにおいて、論理ボリュームにマッピングされる。さらに、論理ボリュームは、ディスクサブシステムのディスクに対応するデバイスファイルとしてマッピングされる。ディスクサブシステム内では前記デバイスファイルはＬＵ（Ｌｏｇｉｃａｌ Ｕｎｉｔ）に対応する。従って、ログデータ領域を構成するファイルは最終的に物理デバイスにマッピングされる。対応する物理情報は、ディスクサブシステム２０１内の物理デバイスを識別する物理デバイスＩＤであるＬＵＮ（Ｌｏｇｉｃａｌ Ｕｎｉｔ Ｎｕｍｂｅｒ）と物理デバイス内の相対位置であるＬＢＡ（Ｌｏｇｉｃａｌ Ｂｌｏｃｋ Ａｄｄｒｅｓｓ）となる。データベース管理システム１０２から通知されるログ書き込みおよび読み込み命令は、ホストコンピュータ１０１上のオペレーティングシステムを介して、上記の物理レベルで行われる。ログ用バッファ管理テーブル２１０には、コマンドに指定されたログブロックの物理情報と、そのログブロックが格納されたキャッシュメモリ２０４上での位置情報、およびどのログ用バッファ領域であるかを識別する情報が管理される。

図３(Ａ)と図３(Ｂ)にログ用キャッシュ領域２０４の制御に用いるコマンドの一例を示す。図３(Ａ)のコマンド３０１は、ホストコンピュータ１０１からディスクサブシステム２０１に対し、ログデータの書き込みを指示するコマンドであり、図３(Ｂ)のコマンド３１１は、ホストコンピュータ１０１からディスクサブシステム２０１に対し、ログ用バッファ２０７上に格納されているログブロックのディスク装置への書き込みを指示するコマンドである。コマンド３０１は、命令コード３０２、ＬＵＮ３０３、ＬＢＡ３０４、バッファ識別子３０５、バッファ長３０６等から構成されている。コマンド３１１は、命令コード、バッファ識別子等から構成されている。命令コード３０２、３１２は、それぞれ、ライト、バッファフラッシュである。ＬＵＮ３０３は物理デバイスＩＤ、ＬＢＡ３０４は物理デバイス内の相対位置を示す。バッファＩＤ３０５、３１３は、ログ用バッファを識別する情報を示す。バッファＩＤは、ホストコンピュータ１０１上のデータベース管理システム１０２で管理する。バッファ長はキャッシュメモリ２０４上に確保するログバッファの長さを示す。

図４にログ書き込みプログラム２１１の処理フローを示す。ステップ４１０でコマンドに付与されたバッファＩＤから、ログ用キャッシュ管理テーブル２０９を検索する。一致するバッファＩＤが登録されていない場合には、データベース管理システム起動後またはチェックポイント取得後の初めての書き込みであるので、ログ用バッファ確保処理４０８に移る。一致するバッファＩＤが登録されている場合または、ログ用バッファ確保処理４０８が完了した後、ステップ４０３に進み、キャッシュ管理モードのチェックを行う。キャッシュ管理モードが「通常モード」である場合は、従来のキャッシュ管理による書き込み処理４０９を行う。キャッシュ管理モードが「ログモード」である場合は、ステップ４０４に進み、コマンドに付与されたバッファＩＤでログ用バッファ管理テーブルを検索し、空きのキャッシュブロックを検索する。空きのキャッシュブロックが見つかったら、ステップ４０６に進み、そのキャッシュブロックに対し、ホストコンピュータ１０１から受信したログブロックの内容を書き込む。ステップ４０７でログ用バッファ管理テーブル２１０に対し、ステップ４０６で、書き込んだログブロックのディスク装置２２０での格納先となる、ＬＵＮおよびＬＢＡを登録する。この他、ログ用バッファ内におけるキャッシュブロックの順序管理等については、リストなど通常のアルゴリズムを適用すればよい。

図５にログ用バッファ確保処理のフローを示す。ステップ５０１でコマンド３０１に付与されたバッファ長３０６をチェックする。キャッシュメモリ２０４の空きが十分ではない場合、ステップ５０５に進み、ログ用バッファ２０７は確保せずに、従来どおりのキャッシュ管理を行うようにする。このとき、ステップ５０４において、ログの書き込み処理や読み込み処理を行う際に、コマンドに付与されたバッファＩＤによって、キャッシュ管理モードがログモードと通常モードのどちらになっているかを判別できるようにするために、ログ用キャッシュ管理テーブル２０９に、キャッシュ管理モードを「通常モード」として登録しておく。キャッシュメモリ２０４の空きが十分である場合は、ステップ５０２に進み、キャッシュメモリ２０４上にログ用バッファ２０７を確保する。ステップ５０３、ステップ５０４で、確保したログ用バッファ分の情報をログ用キャッシュ管理テーブル２０９およびログ用バッファ管理テーブル２１０にそれぞれ登録する。

図６にバッファフラッシュプログラム２１３の処理フローを示す。ステップ６０１で、コマンドに付与されたバッファＩＤによって、ログ用キャッシュ管理テーブル２０８からログ用バッファを検索する。一致するバッファＩＤが見つかったら、ステップ６０２でキャッシュ管理モードをチェックし、ログ用モードでない場合は、通常のキャッシュ制御であるので、そのまま処理を終了する。ログ用モードである場合は、ステップ６０３に進み、ログ用バッファ管理テーブル２１０から、コマンドに付与されたバッファＩＤと一致するキャッシュブロックを検索する。ここで、そのキャッシュブロックに対し、ディスク装置２２０における格納先であるＬＵＮ、ＬＢＡの情報が登録されていたら、ログブロックが格納されていることになるので、ステップ６７０に進み、ログブロックの内容をログ用バッファ管理テーブル２１０に登録されている、ＬＵＮ、ＬＢＡで示される場所に書き込む。ディスク装置２２０に対する書き込みが終わったら、ログ用バッファ管理テーブル２１０から、キャッシュブロックに格納されていたログブロックのＬＵＮおよびＬＢＡの情報を削除する。ステップ６０３からステップ６８０までの処理は、コマンドに付与されたバッファＩＤのログ用バッファが割り振られているキャッシュブロックすべてに対し、ステップ６４０における判定で、登録されているＬＵＮおよびＬＢＡがなくなるまで繰り返し行う。ログ用バッファ内に格納されたログブロックのディスク装置２２０への書き込みがすべて完了したら、ステップ６０５に進み、そのログ用バッファ領域を解放し、ステップ６０６において、ログ用キャッシュ管理テーブル２０９とログ用バッファ管理テーブル２１０から、解放したログ用バッファ領域に関する情報をすべて削除する。
障害発生時のログデータ読込み処理については、ログ用ＲＥＡＤコマンドに付与されたバッファＩＤまたは、ＬＵＮおよびＬＢＡにより、ログ用バッファ管理テーブル２１０を検索して、ログ用バッファ２０７上に格納されているログブロックを読み込む。このとき、ディスク装置２２１にアクセスすることはないため、高速に回復処理を行うことができる。

また、同一のディスクサブシステム上で複数のデータベース管理システムのデータおよびログが格納されている場合もあるが、本実施例はこのような場合にも適合することができる。例えば、ログバッファＩＤとして、各ホストコンピュータとその上で動作するプログラムの識別情報を与えることにより、複数のデータベース管理システムから制御するそれぞれログ用バッファの管理を一括して行うことができる。

データベース管理システムの実装方法によっては、障害発生によるダウンの後、再開始をする際に、データベースの状態を回復するために必要となるログデータの対象範囲が異なってくる。ここまでの説明は、図７(Ａ)の場合を想定している。

本実施例では、これ以外の場合にも対応することが可能である。例えば、図７(Ｂ)は、データベース回復時に前回のチェックポイント時点から障害発生時点までのログデータが必要となる場合である。この場合の実現方法の一例としては、ログ用バッファ領域を２面分用意しておき、これら２つのバッファの管理はデータベース管理システム１０２側で行うようにする。データベース管理システム１０２においてチェックポイントを取得したら、ディスクサブシステム２０１へのバッファフラッシュ命令でコマンドに付与するバッファＩＤに、前回のチェックポイントまでのログブロックを格納している側のバッファを指定するようにする。これにより、バッファフラッシュプログラム２１３は、コマンドに付与されたバッファＩＤをもつログ用バッファに格納されたログブロックをディスク装置２２０に書き込み、そのバッファを解放すればよい。このような方式をとることにより、ログ用バッファ領域を複数（チェックポイントの所定回数分）用意し、チェックポイントの所定回数分のログをログ用キャッシュ領域に格納することもできる。所定数のログ用キャッシュ領域に格納されているログ情報の時間的に古いものからログ情報を削除することにより、チェックポイントの所定回数分をキャッシュ領域に確保することが可能となる。

図７(Ｃ)は、最終チェックポイントから所定量分さかのぼったポイントからのログデータが必要となる場合である。この場合の実現方法の一例としては、データベース管理システム１０２において、チェックポイント取得時に、ディスクサブシステム２０１へのバッファフラッシュ命令を行う際に使用するコマンドに対し、そのチェックポイント取得時までのバッファＩＤ（フラッシュ対象のバッファのＩＤ）に加え、次回のチェックポイント取得時までのバッファＩＤ（新しいバッファのＩＤ）と、ログ用バッファに残しておくべきチェックポイント直前のログサイズ（ログブロック数）も指定するようにする。この命令を受けて、ディスクサブシステム２０１内のバッファフラッシュプログラム２１３は、チェックポイント直前の指定ブロック数分のログブロックをキャッシュメモリ上に残し、それ以外のログブロックをディスク装置２２０に書き出す。次に、ログ用バッファ管理テーブルのキャッシュメモリ上に残ったログブロック分のバッファＩＤを、新しいバッファのＩＤに更新する。ディスク装置２２０に書き出した分については、領域を解放し、ログ用バッファ管理テーブルから削除する。チェックポイント取得直後のログＷＲＩＴＥ命令では、バッファフラッシュ命令で指定した新しいバッファのＩＤを指定して、新たなログ用バッファ領域を確保し、キャッシュメモリ上に残ったログブロックの最後尾から、その先頭をポイントするなどして、続けてアクセスできるようにすればよい。所定時間さかのぼったログデータまでをキャッシュバッファに残すことも容易に実現できるのはいうまでもない。

ホストコンピュータ上のデータベース管理システムから記憶装置サブシステムのキャッシュメモリを制御できるようにすることで、回復処理に必要なログデータ全体をキャッシュに常にのせておくことができる。従って、データベース管理システムが障害によってダウンした場合に再開始処理をする際に、ログの読み込み要求があってもキャッシュヒットするので、ディスク装置にアクセスする必要がなく、回復処理にかかる時間を短縮することが可能となる。

システム構成を示す。 ログ用キャッシュ管理テーブルおよびログ用バッファ管理テーブルの構成を示す。 ログ用ＷＲＩＴＥコマンドと、ログ用バッファフラッシュコマンドの構成を示す。 ディスクサブシステムでのログ用ＷＲＩＴＥ処理の流れ図を示す。 ディスクサブシステムでのログ用バッファ確保処理の流れ図を示す。 ディスクサブシステムでのログ用バッファフラッシュ処理の流れ図を示す。 ログデータをメモリに残すバリエーション図を示す。

符号の説明

１０１：ホストコンピュータ
１０２：データベース管理システム
１０３：ログ用キャッシュ制御部
２０１：ディスクサブシステム
２０２：ネットワークインタフェース制御部
２０３：ディスク制御部
２０４：ディスクサブシステムのキャッシュメモリ
２０５：通常用キャッシュ領域
２０６：ログ用キャッシュ領域
２０７：ログ用バッファ
２０８：デバイスインタフェース制御部
２０９：ログ用キャッシュ管理テーブル
２１０：ログ用バッファ管理テーブル
２２０：ディスク装置

Claims (11)

1. トランザクション処理を実行するデータ処理装置と、前記トランザクション処理時に生成したログデータを格納する記憶装置とを有するデータ処理システムにおいて、
   前記データ処理装置は、前記記憶装置内のメモリに前記ログデータを格納する領域のサイズとその領域の識別子を含む領域確保要求を前記記憶装置へ予め送信し、前記ログデータを格納する場合は前記領域の識別情報を含む格納要求を前記記憶装置へ送信し、
   前記記憶装置は、前記領域確保要求の入力に応じて前記メモリ上にログ用キャッシュ領域について該領域確保要求に含まれるサイズ分を確保して該領域に該領域確保要求に含まれる識別情報を該領域識別情報と対応付けて記憶し、前記格納要求の入力に応じて該格納要求に含まれる識別情報に対応する前記領域に前記ログデータを格納することを特徴とするデータ処理システム。
2. 前記データ処理装置は、トランザクション処理におけるチェックポイントのタイミングで前記記憶装置にチェックポイントを通知するための通知要求を前記記憶装置へ送信し、
   前記記憶装置は、前記通知要求を入力すると前記ログデータを前記メモリからディスク装置に書き込むことを特徴とする請求項１記載のデータ処理システム。
3. 前記記憶装置は、前記メモリ内のログデータを全て消去することを特徴とする請求項２記載のデータ処理システム。
4. 前記記憶装置は、前記メモリに格納された前記ログデータについて直前のチェックポイント以前のログデータを消去することを特徴とする請求項２記載のデータ処理システム。
5. 前記記憶装置は、前記メモリに格納された前記ログデータについて所定回数のチェックポイント以前のログデータを消去することを特徴とする請求項２記載のデータ処理システム。
6. トランザクション処理を実行するデータ処理装置と、前記トランザクション処理時に生成したログデータを格納する記憶装置とを有するデータ処理システムにおけるデータ処理方法において、
   前記データ処理装置は、前記記憶装置内のメモリに前記ログデータを格納する領域のサイズとその領域の識別子を含む領域確保要求を前記記憶装置へ予め送信し、前記ログデータを格納する場合は前記領域の識別情報を含む格納要求を前記記憶装置へ送信し、
   前記記憶装置は、前記領域確保要求の入力に応じて前記メモリ上にログ用キャッシュ領域について該領域確保要求に含まれるサイズ分を確保して該領域に該領域確保要求に含まれる識別情報を該領域識別情報と対応付けて記憶し、前記格納要求の入力に応じて該格納要求に含まれる識別情報に対応する前記領域に前記ログデータを格納することを特徴とするデータ処理方法。
7. 前記データ処理装置は、トランザクション処理におけるチェックポイントのタイミングで前記記憶装置にチェックポイントを通知するための通知要求を前記記憶装置へ送信し、
   前記記憶装置は、前記通知要求を入力すると前記ログデータを前記メモリからディスク装置に書き込むことを特徴とする請求項６記載のデータ処理方法。
8. 前記記憶装置は、前記メモリ内のログデータを全て消去することを特徴とする請求項７記載のデータ処理方法。
9. 前記記憶装置は、前記メモリに格納された前記ログデータについて直前のチェックポイント以前のログデータを消去することを特徴とする請求項８記載のデータ処理方法。
10. 前記記憶装置は、前記メモリに格納された前記ログデータについて所定回数のチェックポイント以前のログデータを消去することを特徴とする請求項８記載のデータ処理方法。
11. トランザクション処理を実行するデータ処理装置と、前記トランザクション処理時に生成したログデータを格納する記憶装置とを有するデータ処理システムを機能するためのデータ処理プログラムにおいて、
    前記データ処理装置では、前記記憶装置内のメモリに前記ログデータを格納する領域のサイズとその領域の識別子を含む領域確保要求を前記記憶装置へ予め送信するステップと、前記ログデータを格納する場合は前記領域の識別情報を含む格納要求を前記記憶装置へ送信ステップと、
    前記記憶装置では、前記領域確保要求の入力に応じて前記メモリ上にログ用キャッシュ領域について該領域確保要求に含まれるサイズ分を確保して該領域に該領域確保要求に含まれる識別情報を該領域識別情報と対応付けて記憶するステップと、前記格納要求の入力に応じて該格納要求に含まれる識別情報に対応する前記領域に前記ログデータを格納するステップとを有することを特徴とするデータ処理プログラム。
    

Images