JP2012128596A - データベースシステム、その情報処理方法、およびそのプログラム - Google Patents

Abstract

【課題】 トランザクション実行中の任意のタイミングの更新状態を、他のトランザクションで利用可能とするには時間がかかる問題があった。
【解決手段】 データベースファイルのデータの一部が変更されたデータをローカルメモリに保持し、データベースファイルに書き込むためのデータをファイルバッファのバッファデータとしてファイルキャッシュに書き込み、バッファデータをデータベースファイルに書き込み、データベースファイルに書き込みを実行している間にデータベースファイルのデータの出力を要求された場合、ファイルキャッシュ保持手段が保持するバッファデータが出力を要求されたデータであるとして出力する。
【選択図】 図２

Description

本発明は、ファイルベースのデータベースシステムに関する。

近年、記憶メディアの大容量化に伴って機器の扱うデータが増大している。同時に扱うデータの種類も増えている。そのため、機器でのデータ処理負荷低減および機器内アプリケーションの開発負荷低減のために、組込み機器用のデータベースシステムが多数提案され利用されるようになってきている。

一般にデータベースシステムでは、不可分な一連の処理をトランザクションとして管理する。処理結果はトランザクション単位で利用され、トランザクション実行中の処理途中状態結果を他が利用することを阻止する。トランザクション単位での処理結果の確定はコミットによって指示し、結果の破棄（トランザクション実行前に戻す）はロールバックによって指示する。

また、データベースシステムはコミットした処理結果を障害等で紛失しないことを保証する。データを保証するため、コミット時にハードディスク装置等の永続化可能な記憶装置へ処理結果を書き込んでいる。書き込み途中の状態での利用は処理結果を正しく読み出すことができないため、他からのアクセスを排他する。

永続化可能な記憶装置への書き込み時間は、通常メモリ上の更新時間と比べ数十倍以上遅い。ファイルシステムはメモリ上にファイルバッファを持ち、ファイルバッファ上に書き込まれただけでアプリケーションに終了をリターンする。これにより、アプリケーションへの書込応答時間を短縮している。実際には記憶装置に書き終わっていないので、リターン時にはデータは保証されていない。ファイルベースのデータベースシステムは、データ保証のために、ファイルバッファから記憶装置への書き込みを実行している時間に、他からのアクセスを排他する。よって、他が利用できるようになるには、書き込みが終わるまで待機し、時間がかかる。

排他時間を短縮するために、記憶装置への書き込みが終了する前に他から利用可能とする取り組みがなされてきた。例えば特許文献１においては、データベースファイルのコピーをメモリ上に保持すると同時にコミット時の更新差分情報もトランザクション単位で保持する手法が開示されている。

特開平５−８８９５４号公報

しかしながら、データベースファイルのコピーをメモリ上に保持する手法は登録データ量に比例してメモリリソースを必要とする。そのため、近年適用が進んでいる組込み機器のような環境では適用できない。メモリ上の共有は、データの一部に制限する必要がある。

しかし、データベースエンジンのローカルメモリ自体を共有する手法では、ローカルメモリを共有化するための制御にかかる負荷が大きいという問題がある。またファイルバッファからファイルへの書き込みを行わないコミット手法も提供されているが、その場合はロールバック用の更新前データと更新後データの整合性を失うことでリカバリが不可能になる問題がある。

また、コミットのようなトランザクションをクローズさせる指示は、直後にファイルへの書き込み指示を実行する他のトランザクションが開始されてしまう問題もある。

以上の問題から、組込み機器において、トランザクション実行中の任意のタイミングの更新状態を、他のトランザクションで高速に利用することはできなかった。

本発明はこのような問題点に鑑みなされたもので、トランザクションが指示するタイミングで、トランザクション実行中に更新内容を、他から高速に利用可能とすることを目的とする。

上記の目的は、以下のシステムによって達成できる。

すなわち、ファイルベースのデータベースファイルのデータの一部が変更されたデータを保持するローカル保持手段と、前記データベースファイルに書き込むための前記ローカル保持手段が保持したデータを、ファイルバッファのバッファデータとしてファイルキャッシュ保持手段に書き込む仮想コミット手段と、前記仮想コミット手段で書き込まれた前記バッファデータを前記データベースファイルに書き込むコミット手段と、前記コミット手段が前記データベースファイルに書き込みを実行している間に前記データベースファイルのデータの出力を要求された場合、前記ファイルキャッシュ保持手段が保持するバッファデータが、出力を要求されたデータであるとして出力する出力手段とを有することを特徴とするデータベースシステム。

本発明によれば、トランザクションが指示するタイミングで、トランザクション実行中に更新内容を高速に他のトランザクションへ反映することができる。これにより、更新内容をすぐに他のトランザクションから読み出すことができる。

情報処理装置の一例であるデータベースシステムのハードウェア構成の一例を示した図である。 本実施形態におけるデータベースシステムによる仮想コミット処理動作の一例を示した図である。 本実施形態において仮想コミットを使用するアプリケーションのデータベース操作シーケンスの一例を示した図である。 本実施形態におけるロールバック用のジャーナルファイルの構成の一例を示した図である。 仮想コミットを整合性非保証で使用した時のキャッシュとジャーナルファイルの状態遷移の一例を示した図である。 本実施形態におけるデータベースエンジンの仮想コミット処理手順の一例を示したフローチャートである。 本実施形態におけるデータベースエンジンのコミット処理手順の一例を示したフローチャートである。 本実施形態におけるデータベースエンジンのロールバック処理手順の一例を示したフローチャートである。

以下、本発明の実施形態について図面に基づいて説明する。

〔実施形態１〕
図１は、情報処理装置（コンピュータ）の一例であるデータベースシステムのハードウェア構成の一例を示す図である。図１において、ＣＰＵ（中央演算装置）１０１は、データベースシステムのための演算・論理判断等を行い、後述するバス１０８を介してバス１０８に接続された後述する各構成要素を制御する。ＲＯＭ１０２は、ＣＰＵ１０１の処理手順となる制御プログラムや各種データを記憶している。ＲＡＭ１０３は、処理中の各種制御のための一時記憶用のワークエリアとして使用される。入力装置１０４は、ボタン・タッチパネル・マウス等から構成される。表示装置１０５は、液晶ディスプレイ等で構成される。記憶装置１０６は、ハードディスク等の各種ディスク機器やフラッシュメモリ等から構成される。ＣＰＵ１０１の処理手順となる制御プログラムやデータベースに保持されるデータやロールバック用データ等の各種データが格納される。通信装置１０７は、ＵＳＢ等の外部入出力機器やモデム等の有線或いは無線通信機器から構成され、外部機器とのデータ交換を行う。バス１０８は、機器・装置間１０１〜１０７で制御プログラムやデータのやり取りを行うものである。

かかる各構成要素からなる本実施形態の情報処理装置は、入力装置等からの各種イベントに応じて作動するものである。入力装置からのインタラプトが供給されると信号がＣＰＵに送られ、それに伴ってイベントが発生する。ＣＰＵは、そのイベントに応じてＲＯＭ又はＲＡＭ内に記憶される各種命令（プログラム）を読み出し、その実行によって各種の制御が行なわれる。

図２は、本実施形態におけるデータベースシステムによる仮想コミット処理動作の一例を示す図である。

アプリケーション２０１、２０４は、使用するデータベースエンジン２０２、２０５を使用する。データベースエンジン２０２、２０５は、データの一部をローカル保持部（以下、ローカルメモリと呼ぶ）２０３、２０６に保持する。メモリ上（ＲＡＭ１０３）にその領域が確保される。

ファイルシステム２０７は、データベースファイル２０９の内容の一部をファイルキャッシュ保持部２０８（以下、ファイルキャッシュ２０８と呼ぶ）に保持する。このファイルキャッシュ２０８は、データベースファイル２０９などのファイルにデータを書き込むバッファデータを保持するファイルバッファとして機能する。ローカルメモリ同様にメモリ上（ＲＡＭ１０３）にその領域が確保される。データベースファイル２０９、ジャーナル保持部２１０（以下、ジャーナルファイル２１０と呼ぶ）は、記憶装置１０６にその領域が確保される。また、本実施形態における、ファイルシステム２０７は、ファイルキャッシュ２０８に保持されているデータを、アプリケーション２０４などの外部に出力することができる。

データベースエンジン２０２、２０５は、扱うテーブルのスキーマ情報やレコード、カラムデータへのインデックスデータ等を固定長ブロックに分割して管理する。データベースファイル２０９に、すべてのブロックが格納されている。データベースエンジンは、アプリケーションの要求に基づいて、データベースファイル２０９内のブロックの一部をローカルメモリに適宜保持する。

データベースの更新方法は、トランザクションの開始要求、レコード等のデータ更新要求を繰り返し、コミット要求によってその更新内容を記憶装置に書き込んでトランザクションを終了する。データ更新要求時点では、実際に更新するのはローカルメモリ内ののみであり、更新前のブロックイメージをジャーナルファイル２１０へ格納する。その後、コミットが指示された時点で、データベースファイル２０９に更新されたブロックを格納する。ロールバックが指示された場合は、ジャーナルファイル２１０に格納されたブロックイメージを使用して変更前に戻す。

また、データベースエンジンは複数のトランザクションが同時に実行されようとする場合、矛盾無く実行させるために各トランザクションを制御する。そのために、一般的なデータベースエンジンで実施されている以下の方法を用いている。すなわち、共有ロック・排他ロック・更新ロックを用いて制御する。データの読み出しには共有ロックの取得、データのローカルメモリ上の更新には更新ロックの取得、コミットによるファイルへの書き込みには排他ロックの取得を必要とする。共有ロックの取得は、排他ロックが解放されていれば、他のトランザクションが共有・更新ロックいずれを取得していても可能である。更新ロックの取得は、更新ロック・排他ロックがともに解放されていれば可能。排他ロックの取得は、他のトランザクションのロックがすべて解放されていれば可能である。３つのロックにより、複数の読み出しトランザクションと１つの更新トランザクションの同時実行を可能する。標準的なファイルシステムは、ファイルに対し共有ロック・排他ロックの２つのロックをサポートしている。データベースエンジンは、ファイルシステムがサポートしていない更新ロックを、データベースファイルの一部の領域に対する排他ロックによって実現している。ロックが取得できない場合は、データベースエンジンはＢＵＳＹであることを示すコードをアプリケーションに返し、リトライするか否かをアプリケーションが判断する。

以上から、データベースの更新において、トランザクション開始時に共有ロック、データ更新時に更新ロック、コミット時に排他ロックの取得をそれぞれ要する。コミットによりトランザクションが終了すると、すべてのロックは解放される。トランザクション実行中に動作する仮想コミットは、更新ロックを取得している状態で終了する。

アプリケーション２０１は、デバイスの一機能を担当し、その処理の実行段階に応じて処理結果を含むステータスデータを、データベースエンジン２０１を用いてデータベースに格納している。デバイスの一機能とは、例えばデジタル複合機にデータベースを適用した場合、コピー・印刷・スキャン送信機能等である。その場合、ステータスデータは、処理済枚数，課金情報，エラー情報等のログ情報である。

アプリケーション２０４は、デバイスのステータス表示機能を担当、アプリケーション２０１の担当する機能の実行状態をユーザに提示している。アプリケーション２０４は、アプリケーション２０１が更新した結果をリアルタイムに表示している。

仮想コミット処理は、アプリケーション２０１のトランザクションが指示するタイミングで、トランザクション実行中に更新内容を高速に他のトランザクションへ反映する。これにより、アプリケーション２０４で更新内容をすぐに読み出すことができる。

アプリケーション２０１は、データベースエンジン２０２に対し、複数のデータ更新を指示する。データベースエンジン２０２は、指示された更新内容に基づき、ローカルメモリ２０３内に保持するブロックの内容を更新する。同時に、データベースエンジン２０２は、更新前のブロックの内容をジャーナルファイル２１０に対応するファイルキャッシュ２０８へ書き込むように、ファイルシステム２０７に指示する。ステータス表示に必要なデータの更新が終了した段階で、アプリケーション２０１は、データベースエンジン２０２に仮想コミットを指示する。

データベースエンジン２０２は、ファイルシステム２０７にジャーナルファイル２１０のファイル同期を指示し、ジャーナルファイル２１０への更新前ブロックのデータ書き込みを保証する。次に、データベースエンジン２０２は、ファイルシステム２０７にローカルメモリ２０３内にある更新済データをデータベースファイル２０９に対応するファイルキャッシュ２０８へ書き込むように指示する。

アプリケーション２０４は、データベースエンジン２０５に対し、定期的に更新内容の検索を実行するため、データベースのデータの出力を要求する。データベースエンジン２０５は、データベースファイル２０９に保持されるブロックの内容の取得を、ファイルシステム２０７に要求する。ファイルシステム２０７は、データ取得要求に対し、既に対象ブロックがファイルキャッシュ２０８に読み込まれていた場合、ファイルキャッシュ２０８から出力する。ファイルキャッシュ２０８に存在しない場合は、通常どおり、データベースファイル２０９から読み出し可能になるまで待機して出力してもよい。

通常のファイルデータベースであれば、アプリケーションによって更新を実行している間、データベースファイルのデータは確定していないため、取得することができない。本実施形態では、アプリケーション２０１による仮想コミット指示によってファイルキャッシュ２０８に更新データを書き込む。そして、書き込まれた更新データは、データベースファイル２０９に実際は書き込まれていなくても、データベースエンジン２０５がファイルシステム２０７から取得することができる。

以上により、アプリケーション２０１のトランザクションが指示するタイミングで、トランザクション実行中に更新内容を高速に他のトランザクションへ反映する。これにより、アプリケーション２０４で更新内容をすぐに読み出すことができる。デジタル複合機に適用した場合では、コピーや印刷実行中の処理途中枚数等のステータス情報をリアルタイムにユーザに提示することが可能となる。

また、仮想コミットを指示する際に、ジャーナルファイル２１０へのファイル同期を行わないように指示することも可能である。この場合は、ロールバック用データのファイル書き込みが保証されていない。つまりデータベースファイル２０９とジャーナルファイル２１０との整合性が保証されないため、障害時のリカバリ処理が実行できなくなる。リカバリ時はバックアップされたデータベースファイルからリストアすることが必要となる。

以上のような整合性非保証（ジャーナルファイル２１０へのファイル同期を行わない）を指示した仮想コミットは、基本的にロールバック用データのファイル書き込みを行わないためさらに高速に処理することが可能である。本実施形態においては、仮想コミット時に整合性保証・非保証を指示することが可能である。

図３は、本実施形態において仮想コミットを使用するアプリケーションのデータベース操作シーケンスの一例を示す図である。

具体的にはアプリケーション２０１がデータベースエンジン２０２への更新処理におけるクエリシーケンスである。アプリケーション２０１による更新トランザクションの全体シーケンス３０３は、開始要求（ｂｅｇｉｎ）で始まり、コミット要求（ｃｏｍｍｉｔ）で終了する。この間、他のアプリが更新トランザクションを開始することはできない。アプリケーション２０１は、処理のステータス情報を３つのテーブルへの更新処理で行っている。アプリケーション２０４によるステータス表示を更新するための更新処理３０１は、テーブル１〜３への３つの更新要求（ｕｐｄａｔｅ）から成る。テーブル１のみを更新した状態では更新内容の整合性が取れていないため、ステータス表示に使用することはできない。３つのテーブルへの更新が終了した段階で、仮想コミット要求（ｖｉｒｔｕａｌ−ｃｏｍｍｉｔ）によって整合性のとれた更新内容をアプリケーション２０４で使用可能になる。処理の進捗に合わせて実行される次の更新処理３０２の結果を、再び仮想コミット要求によって他から使用可能とし、ステータス情報が更新されていくことになる。仮想コミット要求は、アプリケーション２０１によって整合性保証モードが指示される。

アプリケーション２０１は、数回の仮想コミット要求によってステータスを更新しながら処理を進め、アプリの処理終了後のステータス表示も終了した後、最終的にコミット要求によってデータを確定している。

アプリケーション２０４は、検索によって更新結果を得るトランザクションを定期的に繰り返すことで、アプリケーション２０１による任意の更新情報を利用している。

図３で示したシーケンスは、最終的にコミット要求によって確定しているが、アプリケーション２０１の処理結果によってはロールバック要求によって更新前に戻すことが可能である。その場合、直前の仮想コミット時までの更新内容を確定することも可能である。ロールバックを要する状況が更新処理３０２の途中に生じた場合、直前の仮想コミット時点、つまり更新処理３０１の結果を確定させることが可能である。本実施形態では、ロールバック要求時にアプリケーションが選択可能である。

図４は、本実施形態におけるロールバック用のジャーナルファイルの構成の一例を示す図である。

ジャーナルヘッダ４０１は、ジャーナルファイル２１０に格納されているロールバック用のブロック総数やデータベースファイル２０９の整合性非保証フラグが格納される。

ロールバック用データ４０２は、トランザクション実行中に更新されたデータベースファイル２０９内のブロックのＩＤと更新前のブロックイメージが格納される。ロールバック用データ４０２は、ジャーナルヘッダ４０１に格納されたブロック総数分だけ連続して格納されている。

図５は、仮想コミットを整合性非保証で使用した時のキャッシュとジャーナルファイルの状態遷移の一例を示す図である。

（状態５０１）ローカルメモリ及びジャーナルファイル２１０の初期状態５０１では、ジャーナルファイル２１０にデータは格納されていない。

（状態５０２）次に、更新要求実施によって、ローカルメモリのデータ１がジャーナルファイル２１０に書き込まれるときに、ローカルメモリのデータ１が書かれていたブロックの内容を５に変更する。変更する更新要求後に整合性非保証の仮想コミット要求が実行された状態５０２となる。このときの仮想コミット要求実施において、非保証フラグをｏｎにしてジャーナルファイル２１０のファイル書き込み（データ保証）が実行される。

（状態５０３）続けて、ローカルメモリのデータ３がジャーナルファイル２１０に書き込まれるときに、ローカルメモリのデータ３が書かれていたブロックの内容を６に変更する。変更する更新要求後に整合性非保証の仮想コミット要求が実行された状態５０３となる。既に整合性非保証フラグはジャーナルファイル２１０に書き込まれているので、フラグを書き直してジャーナルファイル２１０へ書き込む（データ保証）必要はない。この状態での整合性非保証の仮想コミットは、ファイルアクセスをまったく必要としないため、より高速に処理することが可能である。更新要求実施において、ジャーナルファイル２１０のファイルキャッシュ２０８に、更新されたブロックの更新前イメージである３が書き込まれているのみである。図５のジャーナルファイル２１０内における破線で示されたブロックは、ファイルキャッシュ２０８までの書き込みは済んでいるが、データベースファイル２０９までの書き込みが済んでいる保証ができないものを示している。

（状態５０４）更に続けて、ローカルメモリのデータ４がジャーナルファイル２１０に書き込まれるときに、ローカルメモリのデータ４が書かれていたブロックの内容を７に変更する。変更する更新要求後に整合性保証の仮想コミット要求が実行された状態５０４となる。整合性非保証から整合性保証に切り替わるため、ジャーナルファイル２１０はロールバックに必要な内容１、３、４が書き込まれている（データ保証）。また、非保証フラグはｏｆｆに戻されている。

以下、上述のデータベース更新手段をフローチャートに従って説明する。

（仮想コミット処理）図６は、本実施形態におけるデータベースエンジンの仮想コミット処理手順の一例を示したフローチャートである。仮想コミットの処理手順について図６を用いて説明する。

ステップＳ６０１において、ＣＰＵ１０１は、仮想コミット要求時に指示された整合性保証モードを確認する。整合性保証が指示された場合、ステップＳ６０２へ進む。一方、整合性保証が指示されなかった場合、ステップＳ６０５へ進む。

ステップＳ６０２において、ステップＳ６０１で整合性保証が指示された場合、ジャーナルファイルヘッダに存在する整合性非保証フラグを確認する。ステップＳ６０２での非保証フラグがｏｎであった場合、ステップＳ６０３へ進む。一方、非保証フラグがｏｆｆであった場合、フラグの変更処理は不要で、そのままステップＳ６０４へ進む。

ステップＳ６０３において、ステップＳ６０２で非保証フラグがｏｎであった場合、非保証フラグをｏｆｆに変更してファイルキャッシュ２０８に書き込んでから、ステップＳ６０４へ進む。

ステップＳ６０４において、ジャーナルファイル２１０のファイル同期処理が行われ、ロールバック用データのファイル書き込みが保証される。

ステップＳ６０５において、ステップＳ６０１で整合性非保証が指示された場合も、ジャーナルファイルヘッダに存在する整合性非保証フラグを確認する。非保証フラグがｏｆｆであった場合は、ステップＳ６０６へ進む。非保証フラグがｏｎであった場合は、ステップＳ６０７へ進む。

ステップＳ６０６において、非保証フラグをｏｎに変更してファイルキャッシュ２０８に書き込んでから、ステップＳ６０４へ進む。ステップＳ６０４では、ジャーナルファイル２１０のファイル同期処理が行われ、非保証フラグのファイル書き込みが保証される。ステップＳ６０４のジャーナルファイル２１０の同期処理終了後、ステップＳ６０７へ進む。

ステップＳ６０７において、ＣＰＵ１０１は、取得済であるデータベースファイル２０９の更新ロックを解放し、排他ロックを取得する。ファイルキャッシュ２０８への書き込み途中状態を、他のトランザクションに読み込まれないようにするためである。排他ロックが取得できない場合、ステップＳ６１０へ進む。排他ロックが取得できた場合、ステップＳ６０８へ進む。

ステップＳ６０８において、ステップＳ６０７で排他ロックが取得できた場合、ローカルメモリ２０３内の更新済ブロックをファイルキャッシュ２０８へ書き込む。書き込みが終了したら、ステップＳ６０９へ進む。

ステップＳ６０９において、ステップＳ６０７で取得した排他ロックを解放してから更新ロックを取得後、リターンする。トランザクションは実行中であり、更新ロックを取得している状態でリターンする。

ステップＳ６１０において、ステップＳ６０７で排他ロックが取得できなかった場合、リターンコードをＢＵＳＹに変更し、リターンする。

（コミット処理）図７は、データベースエンジンのコミット処理の詳細を示したフローチャートである。データベースエンジンのコミット処理を図７を用いて説明する。なお、コミット処理を実行している間、仮想コミットされたファイルキャッシュ２０８からのデータ読み出し実行を開放する。

ステップＳ７０１において、ＣＰＵ１０１は、ジャーナルファイル２１０のファイル同期処理を行い、ロールバック用データのファイル書き込みが保証される。これにより、整合性保証が可能となる。

ステップＳ７０２において、ジャーナルファイルヘッダに存在する整合性非保証フラグを確認する。整合性非保証フラグがｏｎであることを確認された場合、ステップＳ７０３へ進む。整合性非保証フラグが、ｏｆｆであることを確認された場合、ステップＳ７０５へ進む。

ステップＳ７０３において、ステップＳ７０２で整合性非保証フラグがｏｎであることを確認された場合、整合性非保証フラグをｏｎからｏｆｆに変更してファイルキャッシュ２０８へ書き込み、ステップＳ７０４へ進む。

ステップＳ７０４において、再びジャーナルファイル２１０のファイル同期処理を行って、非保証フラグｏｆｆのファイル書き込みを保証する。整合性非保証フラグｏｆｆのファイル書き込みが終了後、ステップＳ７０５へ進む。

ステップＳ７０５において、ＣＰＵ１０１は、取得済であるデータベースファイル２０９の更新ロックを解放し、排他ロックを取得する。排他ロックを取得できない場合、ステップＳ７１０へ進む。排他ロックを取得できた場合、ステップＳ７０６へ進む。

ステップＳ７０６において、ステップＳ７０５で排他ロックを取得できた場合、ローカルメモリ２０３内の更新済ブロックをファイルキャッシュ２０８へ書き込む。ファイルキャッシュ２０８への書き込みが終了して、ステップＳ７０７へ進む。

ステップＳ７０７において、データベースファイル２０９のファイル同期処理を行う。これにより、全更新済データのファイル書き込みが保証される。ファイル同期処理後、ステップＳ７０８へ進む。

ステップＳ７０８において、不要となったジャーナルファイル２１０内のロールバックデータを削除し、ステップＳ７０９へ進む。

ステップＳ７０９において、ＣＰＵ１０１は、取得した排他ロックを解放してからリターンする。トランザクションを終了した状態でリターンする。

ステップＳ７１０において、ステップＳ７０５で排他ロックを取得できなかった場合、リターンコードをＢＵＳＹに変更し、リターンする。

（ロールバック処理）図８は、データベースエンジンのロールバック処理の詳細を示したフローチャートである。データベースエンジンのロールバック処理を図８を用いて説明する。ここでの、ロールバック処理は、仮想コミット実行後にロールバックを行う場合、直前の仮想コミット時点までを確定することが可能である。ロールバック処理自体を実行している時の障害から、リカバリ可能となるようにジャーナルデータを確定する。

ステップＳ８０１において、ＣＰＵ１０１は、ジャーナルファイル２１０のファイル同期処理を行い、ロールバック用データのファイル書き込みが保証される。これにより、整合性保証が可能となる。

ステップＳ８０２において、ジャーナルファイルヘッダに存在する整合性非保証フラグを確認する。整合性非保証フラグがｏｎである場合、ステップＳ８０３へ進む。整合性非保証フラグがｏｆｆである場合、ステップＳ８０５へ進む。

ステップＳ８０３において、ステップＳ８０２で整合性非保証フラグがｏｎであった場合、整合性非保証フラグをｏｎからｏｆｆに変更してファイルキャッシュ２０８へ書き込み、ステップＳ８０４へ進む。

ステップＳ８０４において、再びジャーナルファイル２１０のファイル同期処理を行って、非保証フラグｏｆｆのファイル書き込みを保証する。整合性非保証フラグｏｆｆのファイル書き込みが終了後、ステップＳ８０５へ進む。

ステップＳ８０５において、ＣＰＵ１０１は、取得済であるデータベースファイル２０９の更新ロックを解放し、排他ロックを取得する。排他ロックを取得できない場合、ステップＳ８１２へ進む。排他ロックを取得できた場合、ステップＳ８０６へ進む。

ステップＳ８０６において、排他ロックを取得できた場合、ＣＰＵ１０１は、ロールバック要求時に指示された直前の仮想コミット時の更新内容を確定するか否かを確認する。直前の仮想コミット時点までを確定することが確認された場合、ステップＳ８１３へ進む。一方、直前の仮想コミット時点の更新内容を確定しないことが確認された場合、ステップＳ８０７へ進む。更新内容を確定しない場合、トランザクション開始時に戻すため、ジャーナルファイル２１０を用いて仮想コミットで書き込まれたデータをもとに戻していく。

ステップＳ８０７において、ジャーナルファイル２１０内のロールバックデータをローカルメモリへ更新済ブロックとして読み出し、ステップＳ８０８へ進む。

ステップＳ８０８において、ローカルメモリ内の更新済ブロック、つまり読み出されたロールバックデータをファイルキャッシュ２０８へ上書きし、ステップＳ８０９へ進む。

ステップＳ８０９において、データベースファイル２０９のファイル同期処理を行う。これにより、ロールバックデータのファイル書き込みを保証する。すなわち、仮想コミット処理によってファイルキャッシュ２０８まで書き込まれていた更新データを、データベースファイル２０９上でもとに戻したことを保証する。

ステップＳ８１０において、不要となったジャーナルファイル２１０内のロールバックデータを削除し、ステップＳ８１１へ進む。

ステップＳ８１１において、ＣＰＵ１０１は、取得した排他ロックを解放してからリターンする。

ステップＳ８１２において、Ｓ８０５で排他ロックを取得できない場合、リターンコードをＢＵＳＹに変更してリターンする。

ステップＳ８１３において、Ｓ８０６で直前の仮想コミット時点までを確定することが確認された場合、データベースファイル２０９のファイル同期処理を行う。これにより、仮想コミット処理によってファイルキャッシュ２０８まで書き込まれている更新データのデータベースファイル２０９へのファイル書き込みを保証する。ファイル同期処理終了後、ステップＳ８１４へ進む。

ステップＳ８１４において、不要となったジャーナルファイル２１０内のロールバックデータを削除し、ステップＳ８１５へ進む。

ステップＳ８１５において、更新途中のデータが存在するローカルメモリをクリアする。そして、ステップＳ８１１に進み、ＣＰＵ１０１は、取得した排他ロックを解放してからリターンする。

〔変形例〕
実施形態１では、システム共通のファイルシステムおよびそのファイルキャッシュ２０８を用いているが、データベースファイル２０９専用のファイルキャッシュ２０８を管理するサービスを介在させてもよい。これにより、システム全体のファイル操作の影響を受けにくくなる。
また、ロールバック時の選択は直前の仮想コミット後に戻す指示のみを可能にしている。一方、ジャーナルファイル２１０に仮想コミット後の更新処理に対し、同トランザクション内で再び更新されたブロックの更新前イメージも格納するようにしてもよい。これにより、ロールバック時に任意の仮想コミット時の状態に戻すことが可能になる。
また、整合性非保証フラグをジャーナルファイル２１０に保持していたが、データベースファイル２０９あるいは独立の別ファイルに保持するようにしてもよい。

〔その他の実施形態〕
また、上述した実施形態の目的は、以下のようにすることによって達成される。即ち、上述した実施形態の機能を実現するソフトウェアのプログラムコードを記録した記憶媒体（又は記録媒体）を、システム或いは装置に供給する。そして、そのシステム或いは装置の中央演算処理手段（ＣＰＵやＭＰＵ）が記憶媒体に格納されたプログラムコードを読み出し実行する。この場合、記憶媒体から読み出されたプログラムコード自体が上述した実施形態の機能を実現することになり、そのプログラムコードを記録した記憶媒体は上述した実施形態を構成することになる。

更に、記憶媒体から読み出されたプログラムコードが、前記システム或いは装置に挿入された機能拡張カードや、接続された機能拡張ユニットに備わるメモリに書き込まれたとする。その後、そのプログラムコードの指示に基づき、その機能拡張カードや機能拡張ユニットに備わるＣＰＵ等が実際の処理の一部又は全部を行い、その処理によって上述した実施形態の機能が実現される場合も含まれる。

上述した実施形態を前記記憶媒体に適用する場合、その記憶媒体には、先に説明したフローチャートに対応するプログラムコードが格納されることになる。

以上、上述した各実施形態によれば、トランザクションが指示するタイミングで、トランザクション実行中に更新内容を高速に他のトランザクションへ反映することができる。これにより、更新内容をすぐに他のトランザクションから読み出すことができる。

以上、本発明の好ましい実施形態について詳述したが、本発明は係る特定の実施形態に限定されるものではなく、特許請求の範囲に記載された本発明の要旨の範囲内において、種々の変形・変更が可能である。

Claims (5)

1. ファイルベースのデータベースファイルのデータの一部が変更されたデータを保持するローカル保持手段と、
   前記データベースファイルに書き込むための前記ローカル保持手段が保持したデータを、ファイルバッファのバッファデータとしてファイルキャッシュ保持手段に書き込む仮想コミット手段と、
   前記仮想コミット手段で書き込まれた前記バッファデータを前記データベースファイルに書き込むコミット手段と、
   前記コミット手段が前記データベースファイルに書き込みを実行している間に前記データベースファイルのデータの出力を要求された場合、前記ファイルキャッシュ保持手段が保持するバッファデータが、出力を要求されたデータであるとして出力する出力手段と
   を有することを特徴とするデータベースシステム。
2. 前記ローカル保持手段のデータの一部が変更される前のロールバックデータを保持するジャーナル保持手段と、
   を更に有することを特徴とする請求項１に記載のデータベースシステム。
3. 前記コミット手段が前記データベースファイルに書き込みを実行する前に、前記仮想コミット手段によって前記ファイルキャッシュ保持手段に書き込まれたバッファデータを、前記ロールバックデータに基づいて上書きするロールバック手段と、
   を更に有し、
   前記コミット手段が、前記上書きされたバッファデータを前記データベースファイルに書き込むことを特徴とする請求項２に記載のデータベースシステム。
4. ファイルベースのデータベースシステムが実行する情報処理方法であって、
   前記データベースシステムが有する仮想コミット手段が、前記データベースファイルに書き込むためのローカル保持手段が保持した該データベースファイルのデータの一部が変更されたデータを、ファイルバッファのバッファデータとしてファイルキャッシュ保持手段に書き込む仮想コミット工程と、
   前記データベースシステムが有するコミット手段が、前記仮想コミット手段で書き込まれた前記バッファデータを前記データベースファイルに書き込むコミット工程と、
   前記データベースシステムが有する出力手段が、前記コミット手段が前記データベースファイルに書き込みを実行している間に前記データベースファイルのデータの出力を要求された場合、前記ファイルキャッシュ保持手段が保持するバッファデータが、出力を要求されたデータであるとして出力する出力工程と
   を有することを特徴とする情報処理方法。
5. 請求項４に記載の情報処理方法が有する各工程の処理をコンピュータに実行させることを特徴とするプログラム。

Images