(57)【要約】【課題】シャドウページ方式におけるページテーブルに相当するマップテーブルのサイズを小さくし、且つファイルデータの断片化を防止する。【解決手段】ストレージ装置２０の記憶領域には、データセグメント領域２１とシャドウセグメント領域２２とが確保される、上記記憶領域にはマップ２３-0，２３-1が配置される。ファイル管理システム１０は、データセグメント領域２１に格納されているファイルのページ更新を、シャドウセグメント領域２２から取得される空きページに更新データを書き込むことで実行する。ファイル管理システム１０はトランザクションのコミット時毎に、その時点におけるシャドウセグメント領域２２の有効ページのリストをマップ２３-0，２３-1に交互に書き込む。ファイル管理システム１０は、シャドウセグメント領域２２内の有効ページの更新データをデータセグメント領域２１の元のページ位置に書き戻す。【選択図】      図１
2006106868.tif 000002
【特許請求の範囲】
【請求項１】
トランザクション管理機能を有するファイルシステムにおいて、
ファイルによって占有されるファイル領域と、ファイルのページ単位の更新データを一時的に保持する一時書き込み領域とが確保される記憶領域を有するストレージ装置と、
前記ストレージ装置の前記記憶領域に配置される、前記一時書き込み領域内の更新が行われた有効ページのリストを記録するための１対のマップテーブルと、
前記ファイル領域に格納されるファイルを管理するファイル管理手段と、
前記ファイル管理手段によって管理される、前記ファイル領域に格納されているファイルのページ更新を、前記一時書き込み領域から取得される空きページに更新データを書き込むことで実行する更新処理手段と、
トランザクションのコミット時毎に、その時点における前記一時書き込み領域内の有効ページのリストを前記１対のマップテーブルに交互に書き込むコミット手段と、
前記一時書き込み領域内の有効ページの更新データを前記ファイル領域の元のページ位置に書き戻し、当該書き戻しが行われた有効ページを開放する実更新処理を行う実更新手段と
を具備することを特徴とするトランザクション管理機能を有するファイルシステム。
【請求項２】
前記ファイル管理手段は、前記ファイル領域に格納されるファイルテーブルであって、前記ファイル領域に格納されているファイルをエクステント単位で管理し、前記ファイルを構成するエクステントを示すエクステント情報を１つのレコードとして保持するファイルテーブルを含み、当該ファイルテーブル自身を１つのファイルとしてトランザクション管理の対象とすることを特徴とする請求項１記載のトランザクション管理機能を有するファイルシステム。
【請求項３】
前記更新処理手段は、前記ページ更新が、前記ファイルテーブルによって管理されているエクステント内の使用されていないページへのデータ追加である場合、当該エクステント内の使用されていないページに直接データを書き込むことを特徴とする請求項２記載のトランザクション管理機能を有するファイルシステム。
【請求項４】
前記実更新手段は、前記実更新処理の確定操作を、前記１対のマップテーブルの一方に対する更新処理で実行することを特徴とする請求項１記載のトランザクション管理機能を有するファイルシステム。
【請求項５】
前記実更新手段は、前記実更新処理を複数回に分けて実行することを特徴とする請求項４記載のトランザクション管理機能を有するファイルシステム。
【請求項６】
前記実更新手段は、前記実更新処理の前に、前記ファイル領域内の同一ページに対する更新が複数回発生して、その都度前記一時書き込み領域から取得される空きページへの更新データの書き込みが前記更新処理手段によって行われた場合、前記同一ページに対する複数回の更新のうち最新の更新で更新データが書き込まれたページのみ、当該ページから前記ファイル領域の元のページ位置への更新データの書き戻しを行うことを特徴とする請求項４記載のトランザクション管理機能を有するファイルシステム。
【請求項７】
前記ストレージ装置の記憶領域のデータをオンラインでバックアップするバックアップ手段であって、前記実更新手段によって、前記一時記憶領域内の全ての有効ページから前記ファイル領域の元のページ位置への更新データの書き戻しが完了している場合には、前記ファイル領域のデータのみをバックアップするバックアップ手段を更に具備することを特徴とする請求項４記載のトランザクション管理機能を有するファイルシステム。
【請求項８】
前記ストレージ装置の記憶領域のデータをオンラインでバックアップするバックアップ手段であって、バックアップ開始時に、前記一時記憶領域内に、前記実更新手段による更新データの書き戻しが完了していない有効ページが存在する場合には、前記ファイル領域のデータと、当該書き戻しが完了していない有効ページのデータと、前記一対のマップテーブルのうち、最も最近に確定されたマップテーブルとをバックアップすることを特徴とする請求項４記載のトランザクション管理機能を有するファイルシステム。
【請求項９】
前記１対のマップテーブルのうちトランザクションのコミット時に確定されたマップテーブルが反映されたローカルマップを、当該コミット時の時刻を表すタイムスタンプを付して積むための多版同時実行制御キューと、
任意のトランザクションにおいて要求されたページのデータを読み込む読み込み手段であって、前記要求されたページが前記任意のトランザクションで更新されていない場合、当該任意のトランザクションの開始時刻に対応するタイムスタンプが付されたローカルマップを前記多版同時実行制御キューから検索し、当該ローカルマップに従い、前記要求されたページのデータを読み込む読み込み手段と
を更に具備することを特徴とする請求項１記載のトランザクション管理機能を有するファイルシステム。
【請求項１０】
前記読み込み手段は、前記要求されたページが前記任意のトランザクションで更新されている場合には、当該更新されたページのデータを読み込み、前記多版同時実行制御キューから検索されたローカルマップによって前記要求されたページの更新された有効ページの存在が示されていない場合には、前記１対のマップテーブルのうち、その時点において確定されているマップテーブルに従って当該有効ページのデータを読み込むことを特徴とする請求項９記載のトランザクション管理機能を有するファイルシステム。
【請求項１１】
前記多版同時実行制御キューに積まれているローカルマップに付されたタイムスタンプに基づき、現在実行中のトランザクションの開始時刻のうち最も古い開始時刻より古いタイムスタンプが付されたローカルマップを前記多版同時実行制御キューから解放するキュー解放手段を更に具備することを特徴とする請求項９記載のトランザクション管理機能を有するファイルシステム。
【請求項１２】
前記更新処理手段は、前記一時書き込み領域内の新規ページの割り当てをサイクリックに行うことを特徴とする請求項１記載のトランザクション管理機能を有するファイルシステム。
【請求項１３】
トランザクション管理機能を有するファイルシステムに適用されるファイル管理方法であって、
ストレージ装置の記憶領域内に、ファイルによって占有されるファイル領域と、ファイルのページ単位の更新データを一時的に保持する一時書き込み領域とを確保するステップと、
前記ファイル領域に格納されているファイルのページ更新が要求された場合、前記一時書き込み領域から空きページを取得するステップと、
前記要求されたページ更新を、前記一時書き込み領域から取得された空きページに更新データを書き込むことで実行するステップと、
トランザクションのコミット時に、前記一時書き込み領域内の更新が行われた有効ページのリストを記録するための１対のマップテーブルのうち、前回のトランザクションのコミット時にリストの記録に用いられなかったマップテーブルに、前回のトランザクションのコミット時にリストの記録に用いられたマップテーブルをコピーするステップと、
前記１対のマップテーブルのうちの前記コピーされたマップテーブルに、現在の前記一時書き込み領域内の有効ページのリストを記録するステップと
前記一時書き込み領域内の有効ページの更新データを前記ファイル領域の元のページ位置に書き戻し、当該書き戻しが行われた有効ページを開放する実更新処理を行うステップと
を具備することを特徴とするファイル管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、トランザクション管理を含むファイル管理機能を備えたファイルシステムに係り、特にファイルの更新を一時書き込み領域上で実行するファイル管理機能を備えたファイルシステム及びファイル管理方法に関する。
【背景技術】
【０００２】
一般にファイル管理システムにおけるトランザクション管理では、原子性（atomicity）、一貫性（consistency）、分離性（isolation）及び持続性（durability）の４つの基本要件、いわゆるＡＣＩＤ特性が要求される。このＡＣＩＤ性のうち、ＡＣＤ（原子性、一貫性、持続性）はコミット／ロールバックとリカバリによって実現される。リソースマネージャのＡＣＤの実現手法はログ（ロギング）方式とサイドファイル方式とに分けられる。
【０００３】
＜ログ方式＞
ログ方式は、データの更新に際し、更新前の状態（UNDO）とコミットで確定した状態（REDO）とをログに保存する手法である。システムの異常終了に際しては、コミット前の更新済みデータに対してはＵＮＤＯログにより更新前状態に戻し、コミット後の未更新データに対してＲＥＤＯにより確定状態にする。ログ方式には、コミット前のデータを書き出さない（non-steal）方式や、ログを物理的に採るか論理的に採るかなど、様々な手法がある。
【０００４】
＜サイドファイル方式＞
サイドファイル方式は、データは「その場」では変更されずに、新しい値が「別の場所」に書き出される方式である（例えば、非特許文献１参照）。「その場」と「別の場所」は論理空間では同じ場所に所属し、時系列で異なるイメージを保持していることを管理するためのメカニズムが提供される。サイドファイルを実現する代表的な方式がシャドウページ方式である。このシャドウページ方式では完全に原子的な更新が提供されるため、システム障害に際しては復旧が不要という特徴がある。
【０００５】
シャドウページ方式では、ページテーブルとビットマップとの組が２組用いられる。ページテーブルは、ファイルのブロック（ページ）に対して１つのエントリを持つ配列である。ページテーブルのそれぞれのエントリは、対応するブロックの現イメージを保持するスロットの番号を持つ。一方、ビットマップは、スロットあたり１ビットで構成され、対応するスロットが現時点でブロックイメージを保持しているかを示す。ディレクトリは、現在の有効な現ページテーブルとビットマップとの組を示す。シャドウページ方式では、このディレクトリの更新により原子性が保障される。
【０００６】
シャドウページ方式の特徴は、データの更新は別の場所に行われ、ページテーブルが複数化されていることで、データ更新からディレクトリ更新の間のどのタイミングで障害が発生しても、リカバリ処理を一切行うことなく更新をキャンセルすることができる点にある。
【非特許文献１】ジム・グレイ、アンドレアス・ロイター著、喜連川 優 監訳、「トランザクション処理（概念と技法）」下巻、１３．５．１節  サイドファイル、日経ＢＰ社、２００１年１０月２０日、ｐ．８６０−８７０
【発明の開示】
【発明が解決しようとする課題】
【０００７】
ログ方式とサイドファイル方式の一方式であるシャドウページ方式とを比較すると、性能的にはログ方式が優れていることが知られている。
【０００８】
高可用性が要求されるファイル管理システムでは、万一の障害に対して短時間にサービスを再開しなければならない。そこで通常は、高信頼化と高いスループットの実現のためにログ方式が適用されることが多い。ところがログ方式は、障害発生時に、未更新のデータを、ログからロールフォワードにより回復する必要があるため、その回復に長時間（例えば数分程度の時間）を要することがある。
【０００９】
一方、実装の簡易さや障害からの復旧の高速性の点では、シャドウページ方式が優れている。つまり、シャドウページ方式では、上述したように障害回復が不要であることから、短時間（例えば数秒以内）でサービスを回復することができる。しかし、従来のシャドウページ方式は性能面で以下のような問題、つまり
・大きなサイズのページテーブルを必要とする
・フラグメントを起こしやすい
・コミット時のコストが高い
という問題があり、実用的ではない。特に大規模なデータベースでは、シャドウページ方式はディスクのアクセスコストの増加により性能の劣化が顕著になる。以下、上記の問題について詳述する。
【００１０】
まず、従来のシャドウページ方式では、大きなデータベースに対しページテーブルが完全に主記憶に入るという保証はない。例えばページサイズ２ＫＢ（キロバイト）で１ＴＢ（テラバイト）のデータベースのページ数は、５００Ｍ（メガ）ページである。この場合、２つのページテーブルに必要なサイズは、１エントリ４Ｂであるものとすると、５００Ｍ＊２＊４Ｂ＝４ＧＢにもなる。つまり、大きなサイズのページテーブルが必要である。ページテーブルのサイズが巨大になると、ページテーブルのバッファヒット率が、例えば９０％を下回る可能性がある。もし、ページテーブルがバッファにヒットせず、ディスクからの読み出しが必要になると、ページテーブルとデータはディスク上は離れて配置されるため、ページテーブルとデータページをまたぐランダムアクセスが急激に増加し、性能を著しく劣化させる。仮に１００％近いヒット率であったとしても、バッファの呼び出しが多くなり性能を劣化させる。
【００１１】
また、データ更新の結果、ブロック（ページ）を再割り当てすると、フラグメントを起こす。フラグメントの結果ランダムなブロック入出力が増えるため、ディスクアクセス時のデータ転送速度が低下する。
【００１２】
また、コミット時にはデータブロックとページテーブルのディスクへの同期書き込みが必要になる。特にデータブロックの書き込みはランダムになる。このため、コミット時のコストが大きい。
【００１３】
更に、システム内で一貫性のとれた状態を保持するためには、ディスクへの同期書込み(コミット処理)を排他する必要がある。そのため、バックアップ処理中の更新ができない、換言すれば更新処理中のバックアップができないという問題もある。
【００１４】
トランザクションの基本要件の１つとしてトランザクションの分離性がある。つまり、更新中のデータを他のトランザクションから読めないようにすること、読み込み処理に時間がかかっても開始時点の一貫性を保証することが必要となる。多くのトランザクション処理システムでは、ロックによる相互排他によって分離する方法が採られている。この場合、更新中のデータの読み込み（参照）が待たされるという問題もある。
【００１５】
本発明は上記事情を考慮してなされたものでその目的は、シャドウページ方式におけるページテーブルに相当するマップテーブルのサイズを小さくすることができ、且つファイルデータの断片化を防止できるファイル管理機能を備えたファイルシステム及びファイル管理方法を提供することにある。
【００１６】
本発明の他の目的は、更新処理中のバックアップができるファイル管理機能を備えたファイルシステム及びファイル管理方法を提供することにある。
【００１７】
本発明の更に他の目的は、更新中のデータ参照を待たせることなく一貫性を保証できるファイル管理機能を備えたファイルシステム及びファイル管理方法を提供することにある。
【課題を解決するための手段】
【００１８】
本発明の１つの観点によれば、トランザクション管理機能を有するファイルシステムが提供される。このファイルシステムは、ファイルによって占有されるファイル領域と、ファイルのページ単位の更新データを一時的に保持する一時書き込み領域とが確保される記憶領域を有するストレージ装置と、このストレージ装置の上記記憶領域に配置される、上記一時書き込み領域内の更新が行われた有効ページのリストを記録するための１対のマップテーブルと、上記ファイル領域に格納されているファイルを管理するファイル管理手段と、このファイル管理手段によって管理される、上記ファイル領域に格納されているファイルのページ更新を、上記一時書き込み領域から取得される空きページに更新データを書き込むことで実行する更新処理手段と、トランザクションのコミット時毎に、その時点における上記一時書き込み領域内の有効ページのリストを上記１対のマップテーブルに交互に書き込むコミット手段と、上記一時書き込み領域内の有効ページの更新データを上記ファイル領域の元のページ位置に書き戻し、当該書き戻しが行われた有効ページを開放する実更新処理を行う実更新手段とを備える。
【００１９】
このような構成のファイルシステムにおいては、ストレージ装置の記憶領域をファイル領域と一時書き込み領域とに分け、ページ更新のリストを保持するマップテーブル（シャドウページ方式におけるページテーブルに相当）を一時書き込み領域内のページへの書き込みにのみ適用することで、当該マップテーブルのサイズを小さくすることを可能とし、加えて、一時書き込み領域内の有効ページの更新データをファイル領域の元のページ位置に書き戻す実更新処理により、ファイルデータの断片化防止を可能とする。
【００２０】
ここで、上記ファイル管理手段に、上記ファイル領域に格納されるファイルテーブルであって、上記ファイル領域に格納されているファイルをエクステント単位で管理し、上記ファイルを構成するエクステントを示すエクステント情報を１つのレコードとして保持するファイルテーブルが含まれる構成とすると共に、当該ファイルテーブル自身を１つのファイルとしてトランザクション管理の対象とされる構成とすると良い。
【００２１】
このような構成においては、ファイルテーブルをトランザクション管理の対象とすることで、ファイルの追加や、ファイルの拡張を含む更新処理をトランザクションとして管理することができる。
【００２２】
また、上記実更新手段による実更新処理の確定操作が、上記１対のマップテーブルの一方に対する更新処理によって実行される構成とすると良い。このように、通常のファイル更新の確定だけでなく、実更新処理の確定も、マップテーブルの更新処理で行うことができるため、実更新中に通常のファイル更新が可能になる。
【００２３】
また、上記実更新手段による実更新処理を複数回に分けて実行すると良い。このように、実更新処理を一貫性のある単位ではなく部分的に実行することで、実更新の負荷を平準化することができる。
【００２４】
また、ストレージ装置の記憶領域のデータをオンラインでバックアップするバックアップ手段であって、バックアップ開始時に、上記一時記憶領域内に、上記実更新手段による更新データの書き戻しが完了していない有効ページが存在する場合には、上記ファイル領域のデータと、当該書き戻しが完了していない有効ページのデータと、上記一対のマップテーブルのうち、最も最近に確定されたマップテーブルとをバックアップするバックアップ手段を追加すると良い。このような構成においては、上述の実更新処理の確定をマップテーブルの更新処理で行うことで実現される、一貫性の取れた、ファイル領域のデータと一時書き込み領域の有効ページデータとを、最も最近に確定されたマップテーブルと共にバックアップすることで、バックアップ処理中の更新が可能となる。つまり、更新中の一貫性のあるバックアップが可能となる。
【００２５】
また、上記１対のマップテーブルのうちトランザクションのコミット時に確定されたマップテーブルが反映されたローカルマップを、当該コミット時の時刻を表すタイムスタンプを付して積むための多版同時実行制御キューと、任意のトランザクションにおいて要求されたページのデータを読み込む読み込み手段であって、上記要求されたページが上記任意のトランザクションで更新されていない場合、当該任意のトランザクションの開始時刻に対応するタイムスタンプが付されたローカルマップを上記多版同時実行制御キューから検索し、当該ローカルマップに従い、前記要求されたページのデータを読み込む読み込み手段とを追加すると良い。
【００２６】
このような構成においては、複数世代のトランザクションの更新リスト（ローカルマップ）をタイムスタンプを付して多版同時実行制御キューに保持して、任意のトランザクションにおいて要求されたページのデータの読み込みに、当該任意のトランザクションの開始時刻に対応するタイムスタンプが付された更新リストを利用することで、更新中に、トランザクション開始時点の一貫性のあるデータを取得することが可能となる。
【発明の効果】
【００２７】
本発明によれば、シャドウページ方式におけるページテーブルに相当するマップテーブルのサイズを小さくすることができ、且つファイルデータの断片化を防止でき、これにより通常運用の性能の向上と障害回復の高速化とを両立させることができる。
【００２８】
また本発明によれば、更新中に、一貫性の取れた、ファイル領域のデータと一時書き込み領域の有効ページデータとを実現できるため、更新処理中のバックアップができる。更に本発明によれば、複数世代のトランザクションの更新リストをタイムスタンプを付して多版同時実行制御キューに保持して、任意のトランザクションにおいて要求されたページのデータの読み込みに、当該任意のトランザクションの開始時刻に対応するタイムスタンプが付された更新リストを利用することにより、更新中にデータ読み込みを待たせることなく一貫性を保証できる。
【発明を実施するための最良の形態】
【００２９】
以下、本発明の一実施形態につき図面を参照して説明する。  
図１は本発明の一実施形態に係るトランザクション管理機能を備えたファイルシステムの構成を示すブロック図である。このファイルシステムは、主として、ファイル管理システム１０と、ストレージ装置２０と、バッファメモリ３０と、ローカルメモリ４０とから構成される。
【００３０】
ストレージ装置２０は、例えばディスクドライブを用いて構成されるディスクストレージ装置である。ストレージ装置２０の記憶領域（ディスク領域）は、主として、データセグメント領域２１とシャドウセグメント領域２２とに分けて管理される。
【００３１】
データセグメント領域２１はファイルによって占有されるファイル領域である。ファイルとは、データベース（ＤＢ）に格納される「論理的な」まとまり毎に割り当てられた管理単位である。また、ファイルは、物理的には１つ、もしくは複数のエクステントから構成される。エクステントとは、指定されたサイズで確保された物理連続ページ領域のことを指す。ファイルは、初期エクステントサイズで作成され、データの追加に応じて、エクステント単位で拡張される。図１には、データセグメント領域２１に、ファイルＦ１（＃１），Ｆ２（＃２），Ｆ３（＃３）…が格納されている様子が示されている。
【００３２】
データセグメント領域２１にはまた、ファイルテーブル２１０が格納されている。ファイルテーブル２１０は、データセグメント領域２１に格納されているファイルを管理するためのテーブルである。このファイルテーブル２１０自身が、データセグメント領域２１に格納されている１つのファイル（ここではファイル＃０）である。ファイルテーブル２１０は、データセグメント領域２１に格納されているファイルの数分のレコードを保持する。つまりファイルテーブル２１０は、ファイル＃０，＃１，＃２…に関するレコード（ファイルテーブルレコード）ＦＴＲ０，ＦＴＲ１，ＦＴＲ２…を保持する。
【００３３】
シャドウセグメント領域２２は、ファイルの更新データ（更新ページ）を一時的に保持する一時書き込み領域である。つまりシャドウセグメント領域２２は、ファイル内のページに対して更新が行われた際のカレントページ格納領域である。従来のシャドウページ方式では、データベースに割り当てられた全てのページの中からカレントページ用空きページが探し求められる。これに対して本実施形態では、更新に利用する空きページは、全てシャドウセグメント領域２２から探し求められる。そこで、この方式を、従来のシャドウページ方式に対比させて、シャドウセグメント方式と呼ぶ。
【００３４】
このように本実施形態では、データを保持する場所とデータが更新される場所とを、従来のシャドウページ方式とは異なって、基本的にはディスク領域上に混在させない構成を適用している。つまり本実施形態では、ファイルの更新が、シャドウセグメント領域２２と呼ぶ、ファイル領域（データセグメント領域２１）とは異なる限られた領域のみで行われる。そこで以下の説明では、ファイル更新が行われないファイル領域（データセグメント領域２１）を「オリジナル領域」と呼ぶこともある。但し、ファイルのエクステント内の使用されていないページへのデータ追加に限り、そのページに直接データが追加される。
【００３５】
ストレージ装置２０のディスク領域には、従来のシャドウページ方式におけるページテーブルに相当する１対のマップ（マップテーブル）２３-0（＃０）及び２３-1（＃１）が配置される。このマップ２３-0及び２３-1は、シャドウページ方式におけるページテーブルとは異なって、ディスク領域に構築されるデータベースの全ページではなく、シャドウセグメント領域２２のページ数に等しいエントリだけを有する。マップ２３-0及び２３-1は、シャドウセグメント領域２２内の有効なページ（更新されたページ）のリスト（更新リスト）を保持する。このリストは、シャドウセグメント領域２２内の有効なページのＩＤ情報（物理ＩＤ）と、当該ページに対応するデータセグメント領域２１内のページのＩＤ情報（物理ＩＤ）との組を含むレコードの配列である。
【００３６】
ストレージ装置２０のディスク領域にはまた、ディレクトリ２４が配置される。ディレクトリ２４は、マップ２３-0及び２３-1のいずれがオリジナルのマップ（確定されたマップ）であるかを示す。オリジナルでない方のマップは、カレントのマップである。
【００３７】
ファイル管理システム１０は、トランザクション管理を含むファイル管理機能を有する。ファイル管理システム１０は、ファイル管理用のプログラムを、計算機が読み取り実行することにより実現される。このファイル管理用のプログラムは、計算機で読み取り可能な記憶媒体に予め格納して頒布可能である。また、このプログラムが、ネットワークを介してダウンロード（頒布）されても構わない。
【００３８】
図２はファイル管理システム１０の構成を示すブロック図である。ファイル管理システム１０は、更新処理機構１１と、読み込み処理機構１２と、チェックポイント処理機構１３と、ファイル管理制御機構１４とから構成される。
【００３９】
更新処理機構１１は、更新トランザクションを管理し、読み込み部１１１と、更新部１１２と、コミット部１１３とから構成される。読み込み部１１１は、マップサーチ部１１１ａと、最新ページ読み込み部１１１ｂとを含む。更新部１１２は、シャドウセグメント更新部１１２ａを含む。コミット部１１３は、マップ更新部１１３ａと、更新ページフラッシュ部１１３ｂと、マップフラッシュ部１１３ｃと、ディレクトリ切替部１１３ｄとを含む。
【００４０】
読み込み処理機構１２は、読み込み部１２１から構成される。読み込み部１２１は、マップサーチ部１２１ａと、最新ページ読み込み部１２１ｂとを含む。読み込み処理機構１２内の読み込み部１２１は、更新処理機構１１内の読み込み部１１１に相当する。このため、読み込み部１１１及び１２１の一方を、更新処理機構１１及び読み込み処理機構１２で共有使用することにより、読み込み部１１１及び１２１の他方を省略することが可能である。
【００４１】
チェックポイント処理機構１３は、チェックポイント部１３１と、コミット部１３２とから構成される。チェックポイント部１３１は、コピー部１３１ａを含む。コミット部１３２は、マップ更新部１３２ａと、更新ページフラッシュ部１３２ｂと、マップフラッシュ部１３２ｃと、ディレクトリ切替部１３２ｄとを含む。チェックポイント処理機構１３内のコミット部１３２は更新処理機構１１内のコミット部１１３に相当する。両者の違いは、後述するように、コミット部１１３のマップ更新部１１３ａがマップにレコードを記録する更新処理を行うのに対し、コミット部１３２のマップ更新部１３２ａはマップからレコードを削除する更新処理を行う点にある。したがって、コミット部１１３及び１３２の一方を、更新処理機構１１及びチェックポイント処理機構１３で共有使用すると共に、その一方のマップ更新部に、レコード記録とレコード削除の両機能を持たせるならば、コミット部１１３及び１３２の他方を省略することが可能である。
【００４２】
ファイル管理制御機構１４は、図１のファイルシステムを利用するアプリケーションからの要求、例えばトランザクションの開始要求、当該トランザクションでの更新操作を確定させるためのコミット要求に従い、上記更新処理機構１１、更には読み込み処理機構１２を制御する。ファイル管理制御機構１４はまた、チェックポイント処理のためのトランザクションを発生し、チェックポイント処理機構１３を制御する。
【００４３】
バッファメモリ３０は、ファイル管理システム１０とストレージ装置２０との間で入出力されるページデータを一時記憶するのに用いられるディスクキャッシュメモリである。ローカルメモリ４０は、ファイル管理システム１０のファイル管理に必要な一時的な情報を保持するのに用いられる。
【００４４】
ここで、図１のシステムで適用されるシャドウセグメント方式の前提条件となるファイルとエクステント（extent）の概要について説明する。本実施形態では、ファイル内のページを物理ディスクに確保する(割り当てる)方式として、エクステント方式を採る。エクステント方式の基本は、
・ファイルは複数の(物理的に)連続な領域(これをエクステントと呼ぶ)によって構成される
・データ増加に伴って領域が不足する場合には、エクステント単位で新たな連続領域を確保する
点にある。
【００４５】
図３は、ファイルテーブル２１０に保持されるファイル＃ｉ（Ｆｉ）に関するレコード（ファイルテーブルレコード）ＦＴＲｉのデータ構造例を示し、図４はファイル＃ｉ（Ｆｉ）とエクステントとの関係を示す。図３及び図４の例は、ファイル＃ｉ（Ｆｉ）が、３つのエクステントＥｉ１（＃ｉ１），Ｅｉ２（＃ｉ２）及びＥｉ３（＃ｉ３）によって構成される場合を想定している。
【００４６】
レコードＦＴＲｉは、ヘッダと、対応するファイル＃ｉ（Ｆｉ）を構成する各エクステントに関する情報（エクステント情報）とを含む。ヘッダは、内部識別子と呼ばれるファイル＃ｉ（Ｆｉ）のＩＤ（ファイルＩＤ）と、外部識別子と呼ばれるファイル＃ｉ（Ｆｉ）の名前（ファイル名）と、ファイル＃ｉ（Ｆｉ）を構成するエクステントの数を示す情報とを含む。一方、エクステント情報は、対応するエクステントのディスク（ディスク領域）上の開始位置と、確保(予約)された累積ページ数と、使用済みページ位置とをそれぞれ示す情報を含む。使用済みページ位置は、対応するエクステントにおける最後尾の使用済みページの、ファイル先頭（先頭エクステントの先頭ページ）を起点とするページ位置を示す。図４の例では、エクステント＃ｉ１（Ｅｉ１），＃ｉ２（Ｅｉ２）及び＃ｉ３（Ｅｉ３）のページ数は、それぞれ５，１０及び１０である。また、エクステント＃ｉ３（Ｅｉ３）の最後のページだけが未使用である。したがって、エクステント＃ｉ１（Ｅｉ１），＃ｉ２（Ｅｉ２）及び＃ｉ３（Ｅｉ３）の累積ページ数は、それぞれ、５，１５及び２５であり、エクステント＃ｉ１（Ｅｉ１），＃ｉ２（Ｅｉ２）及び＃ｉ３（Ｅｉ３）の使用済みページ位置は、それぞれ５，１５及び２４である。
【００４７】
以降で説明する処理の流れの中では、各ファイルには、そのファイルを構成するエクステント、即ち連続した領域が確保(予約)されている、ということが前提になっている。言い換えれば、次のようなポイントがある。
【００４８】
従来のシャドウページ方式では、空きページは完全に（つまりシステム的に、どの機能から見ても）空きページであって何に使っても構わない。しかし本実施形態では、エクステント方式で確保(予約)された領域については、実データが書かれていないという意味で空きページであったとしても、そのページは確保された際の用途以外で使われることはない。
【００４９】
次に、本実施形態の動作について、ページ内データの更新が行われる場合を例に、図５の動作説明図を参照して説明する。  
まず、ファイル管理システム１０のファイル管理制御機構１４に、図１のファイルシステムを利用するアプリケーションからトランザクションＴＲの開始が要求されたものとする。ここでは、トランザクションＴＲで更新されるデータがファイル＃２（Ｆ２）で、更新の必要なページがエクステント＃２２の２ページ目のページＰＤ１であるとする。また、このページの物理ＩＤを１０００とする。
【００５０】
シャドウセグメント方式では、オリジナルページはシャドウとして残しておく必要がある。このため、更新は、更新が必要なページＰＤ１のイメージのコピーを利用して、シャドウセグメント領域２２内のページに対して行われる。そこで、更新処理機構１１内の読み込み部１１１に含まれているマップサーチ部１１１ａは、シャドウセグメント領域２２内から更新用に用いる空きページを取得する。この空きページは、マップ２３-0及び２３-1のうちのオリジナルマップをサーチすることで取得することができる。ここでは、上記トランザクションＴＲの開始時のオリジナル（確定）マップはマップ２３-0（＃０）であり、カレントなマップはマップ２３-1（＃１）であるものとする。また、空きページとしてページＰＳ１が見つけられたものとする。このシャドウセグメント領域２２内のページＰＳ１のＩＤをＳＳ１とする。
【００５１】
読み込み部１１１の最新ページ読み込み部１１１ｂは、更新の必要なページＰＤ１のデータを読み込む（ステップＳ１）。最新ページ読み込み部１１１ｂによって読み込まれたページＰＤ１のイメージは、シャドウセグメント領域２２内のページＰＳ１にコピーされる。但し、ファイル管理システム１０とストレージ装置２０との間にバッファメモリ３０が設けられている本実施形態では、このコピーは実際には、ページＰＳ１に対応するバッファメモリ３０内のページ（ブロック）に対して行われる。
【００５２】
更新処理機構１１内の更新部１１２に含まれているシャドウセグメント更新部１１２ａは、シャドウセグメント領域２２内のページ（カレントページ）ＰＳ１の更新を行う（ステップＳ２）。但し、ここでの更新も、実際には、ページＰＳ１に対応するバッファメモリ３０内のページ（ブロック）に対して行われる。このとき、シャドウセグメント更新部１１２ａはマップ登録要求記録部として機能して、ページＰＤ１の更新後のページイメージ（カレントページのイメージ）がシャドウセグメント領域２２内のページ（カレントページ）ＰＳ１に存在することを示す情報を、ローカルメモリ４０内にトランザクションＴＲに対応付けて確保された一時マップに格納（記録）する。この情報は、ＰＤ１の物理ＩＤ＝１０００とＰＳ１の物理ＩＤ＝ＳＳ１との対を含む。この情報は、トランザクションＴＲを終了させる際に、その時点におけるカレントマップに追加される。そこで、この情報をローカルメモリ４０内のトランザクションＴＲに対応した一時マップに記録することを、マップ追加要求記録と表現する。物理ＩＤは、データセグメント領域２１内のページに関しては、当該データセグメント領域２１内の相対ページ位置を示し、シャドウセグメント領域２２内のページに関しては、当該シャドウセグメント領域２２内の相対ページ位置を示す。
【００５３】
その後、トランザクションＴＲを終了させるために、アプリケーションから当該トランザクションＴＲでの更新操作を確定するコミット処理が要求されたものとする。上述したように、このトランザクションＴＲの開始時のオリジナルマップはマップ２３-0（＃０）である。この場合、更新処理機構１１のコミット部１１３に含まれているマップ更新部１１３ａは、マップ２３-0（＃０）をマップ２３-1（＃１）にコピーし、ローカルメモリ４０内のトランザクションＴＲに対応した一時マップに格納されている情報（マップ追加要求）に従い、物理ＩＤ＝１０００に関するレコード、つまりページＰＤ１の物理ＩＤ＝１０００とページＰＳ１の物理ＩＤ＝ＳＳ１との対を含むレコードを追加（記録）する（ステップＳ３）。このレコードは、物理ＩＤ＝１０００のページＰＤ１に対応する最新版ページＳＳ１がシャドウセグメント領域２２内に存在することを表す。なお、上記レコード追加のマップ更新操作は、実際には、マップ２３-0（＃０）及びマップ２３-1（＃１）が配置されるページに対応するバッファメモリ３０内のページ（ブロック）に対して行われる。
【００５４】
次にコミット部１１３の更新ページフラッシュ部１１３ｂは、バッファメモリ３０内にシャドウセグメント領域２２に反映されていない更新ページ（ダーティな更新ページ）があれば、その更新ページを全て、シャドウセグメント領域２２内の対応するページにフラッシュする。同様にコミット部１１３のマップフラッシュ部１１３ｃは、バッファメモリ３０内にマップ２３-1に反映されていない当該更新マップのページがあれば、その更新マップを、マップ２３-1にフラッシュする。
【００５５】
この段階で、コミット部１１３のディレクトリ切替部１１３ｄは、ディレクトリ２４を操作して、マップのオリジナルを、マップ２３-0（＃０）からマップ２３-1（＃１）に切り替える（ステップＳ４）。これによりコミット処理は終了する。
【００５６】
以上の処理のなかでポイントとなるのは、次の２点である。１つは、更新用のカレントページが、シャドウセグメント領域２２の中から用意される点である。つまり、更新用のカレントページには、シャドウセグメントのみを利用する点である。もう１つは、マップ２３-i（ここではｉ＝１）には、シャドウセグメント領域２２内にページイメージがあるカレントページ（更新ページ）の物理ＩＤを含むレコードのみが追加される点である。つまり、マップ２３-iに格納されていない物理ＩＤで示される、シャドウセグメント領域２２内のページは空きページである。マップ２３-Iに追加されたレコードには、シャドウセグメント領域２２内の更新ページの物理ＩＤと対をなして、当該更新ページに対応するデータセグメント領域２１内の古いページの物理ＩＤが含まれている。
【００５７】
トランザクションの更新によって、コミットされるまではトランザクションローカルとなるデータが発生する。このデータの管理のために、トランザクションで更新したドキュメントページのマップ情報（データセグメント領域２１内のページの物理ＩＤとシャドウセグメント領域２２内の対応するページの物理ＩＤとを含む情報）を保持するのが上述の一時マップである。一時マップは、トランザクションの開始で作成され、トランザクションの終了(コミット/ロールバック)で破棄される。
【００５８】
本実施形態ではリカバリ方式としてシャドウセグメント方式を採用しているが、そのベースはシャドウページ方式である。シャドウページ方式においては、更新確定(コミット)処理の際には、
（１）データ(データページ)のディスクへの書き込み
（２）マップのコピー・更新・書き込み
（３）空き領域管理のためのフリービットページ（ＦＢＰ）とそのシャドウ処理
が必要となる。
【００５９】
ページのディスクＩ／Ｏ処理はメモリアクセスや計算処理に比較して非常に重い。コミット処理を行うとコミット処理の直列化及び上記マップ処理により応答性が低下する恐れがある。また、マップの更新は一貫性のある単位で行わなければならないため、直接マップを更新する方法では同時に複数の更新を行うことができない。
【００６０】
そのため、個々のトランザクションの更新情報を一貫性のある単位で上記一時マップに記録し、コミット要求のタイミングでカレントマップを一度に更新する。更に、本実施形態では複数のコミット要求をまとめて処理する。この複数のコミット要求をまとめて処理することをグループコミットと呼ぶ。
【００６１】
コミットの遅延により、各トランザクションの平均応答時間が長くなるが、その分、トランザクション当たりオーバヘッド（Ｉ／Ｏ準備と発行、完了後の後始末など）は非常に短くなる。一般に低負荷の場合遅延させず、高負荷の場合は一定時間遅延させることによって最適なスループットが得られる。本実施形態では、グループコミット実行中のコミット要求はコミット完了まで遅延させ、次のグループコミットによってその間の要求をまとめて処理することで、最適化を図る。遅延時間の制御までは行わない。
【００６２】
次に、本実施形態におけるチェックポイント処理について、図６の動作説明図を参照して説明する。このチェックポイント処理によって、上記２つのポイントが大いに重要であることが理解されよう。
【００６３】
チェックポイント処理の目的は、シャドウセグメント領域２２に作られている更新後のページイメージを、データセグメント領域２１内の元の位置（＝連続領域の中）に戻すことで、ディスクＩ／Ｏの高速化を図ることにある。
【００６４】
本実施形態におけるチェックポイント処理（実更新処理）を、ファイル管理システム１０のファイル管理制御機構１４で内部的に発生させる独立したトランザクションＴＲｃとする。つまり、このチェックポイント処理を、他のトランザクション内の一部に相乗りさせることはしない。但し、コミットについては、他のトランザクション同様、グループコミットによって一括処理可能とする。本実施形態において、トランザクションＴＲｃは、シャドウセグメント領域２２内の空きページが少なくなった場合、例えば全ページ数に対する空きページの比率が一定値未満となった場合に発生される。なお、トランザクションＴＲｃが定期的に発生される構成としても構わない。
【００６５】
まず、マップ２３-1（＃１）がオリジナルであることがディレクトリ２４によって示されているものとする。この場合、チェックポイント処理機構１３のチェックポイント部１３１に含まれているコピー部１３１ａは、オリジナルのマップ２３-1（＃１）を参照する。これによりコピー部１３１ａは、シャドウセグメント領域２２に作られている更新後のページイメージ（カレントページのイメージ）に対応する、データセグメント領域２１内の元の古いページイメージの物理ＩＤを取得する。そしてコピー部１３１ａは、この取得された物理ＩＤで示される、データセグメント領域２１内の古いページイメージを必要とするトランザクションが存在しないことを確認する（ステップＳ１１）。ここでは、シャドウセグメント領域２２内のカレントページがＰＳ１であり、ＰＳ１に対応するデータセグメント領域２１内の古いページ（オリジナルページ）が物理ＩＤ＝１０００のＰＤ１であるものとする。この場合、コピー部１３１ａは、シャドウセグメント領域２２内のカレントページＰＳ１のイメージを、データセグメント領域２１内の元の位置、つまりページＰＤ１にコピーする（ステップＳ１２）。つまりコピー部１３１ａは、シャドウセグメント領域２２内のカレントページＰＳ１のイメージを、データセグメント領域２１内の元の位置に書き戻す実更新処理を行う。但し、この実更新処理（コピー処理）は、ページＰＤ１に対応するバッファメモリ３０内のページに対して行われる。このときコピー部１３１ａはマップ削除要求記録部として機能して、カレントページＰＳ１のイメージが元のデータセグメント領域２１内のページＰＤ１に反映されていることを示す情報を、ローカルメモリ４０に確保された、トランザクションＴＲｃに対応した一時マップに格納（記録）する。この情報は、ＰＤ１の物理ＩＤ＝１０００とＰＳ１の物理ＩＤ＝ＳＳ１との対を含む。この情報は、チェックポイント処理のトランザクションＴＲｃを終了させる際に、その時点におけるカレントマップから削除される。そこで、この情報をローカルメモリ４０内のトランザクションＴＲｃに対応した一時マップに記録することを、マップ削除要求記録と表現する。
【００６６】
上述の実更新処理（コピー処理）が、シャドウセグメント領域２２内の幾つかのカレントページ（例えば全てのカレントページ）について繰り返された結果、チェックポイント処理のトランザクションＴｃを終了させたいものとする。この場合、このトランザクションＴＲｃでの操作を確定するコミット処理が、チェックポイント処理機構１３のコミット部１３２によって開始される。
【００６７】
まず、コミット部１３２のマップ更新部１３２ａは、チェックポイント処理のトランザクションＴＲｃの開始時のオリジナルマップであるマップ２３-1（＃１）をマップ２３-0（＃０）にコピーし、ローカルメモリ４０内のトランザクションＴＲｃに対応した一時マップに格納されている情報（マップ削除要求）に従い、物理ＩＤ＝１０００に関するレコード、つまりページＰＤ１の物理ＩＤ＝１０００とページＰＳ１の物理ＩＤ＝ＳＳ１との対を含むレコードを削除する（ステップＳ１３）。このレコード削除のマップ更新操作は、実際には、マップ２３-0（＃０）及びマップ２３-1（＃１）が配置されるページに対応するバッファメモリ３０内のページ（ブロック）に対して行われる。
【００６８】
次にコミット部１３２の更新ページフラッシュ部１３２ｂは、バッファメモリ３０内にデータセグメント領域２１に反映されていない更新ページがあれば、その更新ページを全て、データセグメント領域２１内の対応するページにフラッシュする。同様にコミット部１３２のマップフラッシュ部１３２ｃは、バッファメモリ３０内にマップ２３-0に反映されていない当該更新マップのページがあれば、その更新マップを、マップ２３-0にフラッシュする。
【００６９】
この段階で、コミット部１３２のディレクトリ切替部１３２ｄは、ディレクトリ２４を操作して、マップのオリジナルを、マップ２３-1（＃１）からマップ２３-0（＃０）に切り替える（ステップＳ１４）。これによりコミット処理は終了する。
【００７０】
ここで、前述の２つのポイントについて、上記チェックポイント処理を踏まえて再度確認する。第１のポイントは、更新用のカレントページには、シャドウセグメントのみを利用する点である。発明が解決しようとする課題で指摘したように、従来から知られているシャドウページ方式では、新しい空きページを探し、そのページを更新する。そのため、更新によってページのフラグメントが発生しやすい。これに対して本実施形態で適用されるシャドウセグメント方式では、カレントページをシャドウセグメント領域２２に配置することと、チェックポイント処理により当該カレントページイメージを元の連続領域内に戻すことにより、更新によって発生するフラグメントを抑制することができる。
【００７１】
次に第２のポイントは、マップ２３-I（ｉは０または１）は、シャドウセグメント領域２２内にカレントなページイメージがあるページのみのレコードを持つ点である。発明が解決しようとする課題で指摘したように、シャドウページ方式では、論理物理ＩＤと物理ＩＤとのマッピングのために、ページ数によっては巨大なテーブル（ページテーブル）が必要である。これに対して本実施形態で適用されるシャドウセグメント方式では、更新されたページのみのレコードを持つことで、圧倒的にマップサイズを抑制できる。更にチェックポイント処理により、マップ（マップテーブル）自体が整理され、マップの肥大化を抑制できる。
【００７２】
次に、トランザクションＴＲでの例えばデータ検索に伴うデータ読み込み処理（参照処理）について、ファイル＃２（Ｆ２）における通しページ番号１０のページを読み込む場合を例に、図７及び図８を参照して説明する。なお、図７はファイルテーブル２１０内のファイルテーブルレコードＦＴＲ２によって示される、ファイル＃２（Ｆ２）のエクステント構成を示す図、図８はデータ読み込み処理の動作説明図である。図７では、ファイル＃２（Ｆ２）が、図１とは異なって、３つのエクステント＃２１，＃２２及び＃２３から構成されている場合を前提としている。つまり、ファイル＃２（Ｆ２）は、図４に示すファイル＃ｉ（Ｆｉ）であるものとする（ｉ＝２）。
【００７３】
まず、読み込み処理機構１２の読み込み部１２１は、ファイルテーブル２１０中のファイルテーブルレコードＦＴＲ２を読み込む。そして読み込み部１２１は、このファイルテーブルレコードＦＴＲ２に含まれている、ファイル＃２（Ｆ２）のエクステント構成を示すエクステント情報から、通しページ番号１０のページが、エクステント＃２２の５ページ目、即ち物理ＩＤが２１５のページであることを認識する。
【００７４】
読み込み部１２１は、トランザクションＴＲに対応付けてローカルメモリ４０内のトランザクションＴＲに対応した一時マップに格納されている情報（マップ追加要求）に、物理ＩＤ＝２１５のページを示す情報が含まれているかにより、このページが、当該トランザクションＴＲで更新されたページであるかを判定する。もし、物理ＩＤ＝２１５のページが、トランザクションＴＲで更新されたページであるならば、読み込み部１２１の最新ページ読み込み部１２１ｂは、その更新されたページのデータを読み込む。
【００７５】
これに対し、物理ＩＤ＝２１５のページが、トランザクションＴＲで更新されたページでないならば、読み込み部１２１のマップサーチ部１２１ａは、ディレクトリ２４を参照してマップ２３-0及び２３-1のいずれがオリジナルのマップであるかを確認する（ステップＳ２１）。ここでは、マップ２３-0がオリジナルのマップであるものとする。この場合、マップサーチ部１２１ａは、オリジナルマップ２３-0をサーチして、物理ＩＤ＝２１５を含むレコードが格納されているか、つまり物理ＩＤ＝２１５のページに対応するカレントページ（更新済みページ）がシャドウセグメント領域２２に存在するかを調べる。もし、物理ＩＤ＝２１５を含むレコードが格納されているならば、マップサーチ部１２１ａは当該レコードから物理ＩＤ＝２１５と対をなすカレントページの物理ＩＤを取り出して、読み込み部１２１の最新ページ読み込み部１２１ｂに渡す。これにより最新ページ読み込み部１２１ｂは、マップサーチ部１２１ａから渡された物理ＩＤで示されるシャドウセグメント領域２２内のカレントページのデータを読み込む。但し、図８の例では、マップ２３-0には、物理ＩＤ＝２１５を含むレコードは格納されていない。
【００７６】
最新ページ読み込み部１２１ｂは、物理ＩＤ＝２１５のページがトランザクションＴＲで更新されたページでなく、且つオリジナルマップ２３-0に物理ＩＤ＝２１５を含むレコードが格納されていない場合、直接物理ＩＤ＝２１５のページのデータを読み込む。
【００７７】
ファイル＃ｉ（Ｆｉ）のサイズが徐々に増加し、持ち合わせているエクステント領域を全て利用したとする。この場合には、エクステントを拡張する必要、つまり物理的な連続領域を確保し、その情報をファイルテーブル２１０中のファイルテーブルレコードＦＴＲｉに反映させる必要がある。
【００７８】
そこで、エクステントの拡張処理について説明する。  
まず、本実施形態におけるエクステントの拡張処理を、上述したチェックポイント処理と同様に、ファイル管理システム１０で内部的に発生させる独立したトランザクションＴＲｅとする。その理由は次の通りである。
【００７９】
エクステントの拡張が必要となったトランザクションが仮にロールバックしたとしても、近々別のトランザクションによってエクステントの拡張が必要になる可能性が非常に高い(局所性の原理)。そのため、エクステントの拡張だけは完了させておいても問題はない。
【００８０】
あるトランザクションによって、エクステント拡張のためにファイルテーブル２１０の該当ページの排他ロックが獲得された場合、そのトランザクションが終了するまで他のトランザクションはファイルテーブル２１０の該当ページの参照が待たされることになり、並列性に問題が生じる。
【００８１】
したがって、エクステントの拡張は、あるトランザクションをトリガに行われる処理ではあるが、そのトランザクションのエクステントの拡張に関する原子性は保証されない。ただしこれはデータベース管理の内部で発生するものであり外部的にはエクステント拡張による影響はでない。
【００８２】
以下、ファイル＃２（Ｆ２）に、データを格納するための十分な領域がなかった場合を例に、エクステントの拡張処理について図９の動作説明図を参照して説明する。なお、前述したようにファイルテーブル２１０もファイルの１つ（ここではファイル＃０）であり、エクステントの拡張処理は基本的に他のファイルと同様に行われる。
【００８３】
今、ファイルテーブル２１０に格納されている、ファイル＃２（Ｆ２）に関するレコード（即ちファイルテーブルレコードＦＴＲ２）の存在するページが、物理ＩＤ＝２のページＰＤ０２であるものとする。このページＰＤ０２を含むエクステントが、エクステントＥ０１であるものとする。
【００８４】
図２には、エクステントの拡張処理を行う機構（エクステント拡張処理機構）が省略されている。しかし、このエクステント拡張処理は、更新処理機構１１による更新処理とほぼ同様に実行される。そこで本実施形態では、便宜的に更新処理機構１１によりエクステントの拡張処理が行われるものとして説明する。マップサーチ部１１１ａは、シャドウセグメント領域２２内から更新用に用いる空きページを探す。マップサーチ部１１１ａは、シャドウセグメント領域２２内からページＰＤ０２の更新用に用いる空きページを探し、その空きページに当該ページＰＤ０２のイメージをコピーする（ステップＳ３１）。ここではページＰＤ０２のイメージは、図９に示すように、シャドウセグメント領域２２内のページＰＳ１にコピーされたものとする。更新部１１２は、エクステント拡張サイズとして指定されたサイズ分の連続領域を、ストレージ装置２０のデータセグメント領域２１上に確保する（ステップＳ３２）。更新部１１２は、ステップＳ３２で確保された領域が、ファイル＃２（Ｆ２）の拡張されたエクステント＃２２として扱われるように、ページＰＳ１上で、ファイル＃２（Ｆ２）のファイルテーブルレコードＦＴＲ２を更新する（ステップＳ３３）。ここでは、ファイルテーブルレコードＦＴＲ２の第２エクステントカラムに、ステップＳ３２で確保された領域（エクステント＃２２）のエクステント情報が追加される。
【００８５】
次に上述のエクステント拡張処理のトランザクションＴＲｅを終了させるためのコミット処理について説明する。まず、このトランザクションＴＲｅの開始時のオリジナルマップはマップ２３-0（＃０）であるものとする。この場合、コミット部１１３は、マップ２３-0（＃０）をマップ２３-1（＃１）にコピーし、物理ＩＤ＝２に関するレコード、つまりページＰＤ０２の物理ＩＤ＝２とページＰＳ１の物理ＩＤとの対を含むレコードを追加（記録）する（ステップＳ３４）。そしてコミット部１１３は、マップのオリジナルを、マップ２３-0（＃０）からマップ２３-1（＃１）に切り替える（ステップＳ３５）。これによりコミット処理は終了する。
【００８６】
既に詳述したように、本実施形態で適用されるシャドウセグメント方式は、マップサイズを抑制すると共に、更新によって発生するフラグメントを抑制する点で非常に効果がある。しかし、これだけでは、一括登録など大量の登録が行われた場合のチェックポイント処理が非常に重くなる。例えば、シャドウセグメント領域２２の全てのページがカレントページであるような状態でのチェックポイント処理では、シャドウセグメント領域２２のサイズ分のページコピーが必要となる。そこで本実施形態では、チェックポイント処理の負荷軽減のために、以下に述べる第１及び第２の負荷軽減手法が適用される。
【００８７】
まず、第１の負荷軽減手法について、図１０の動作説明図を参照して説明する。  
第１の負荷軽減手法の特徴は、エクステント内の使用されていないページへのデータ追加では、シャドウセグメント領域２２内にコピーをとらず、割り当てられているページの位置に直接データを追加する点にある。このデータ追加に失敗した場合、ファイルテーブル２１０内の対応するファイルテーブルレコードに含まれている使用されている最大の有効ページ番号(使用済みページ位置)を更新しないことでリカバリを実現する。
【００８８】
今、ファイル＃１（Ｆ１）が、図１０に示すように、ページ数が４の２つのエクステント＃１及び＃２から構成され、エクステント＃２の使用済みページ位置が５であるものとする。つまりエクステント＃２内の２ページ目以降にはデータはないものとする。このファイル＃１（Ｆ１）のエクステント構成は、ファイルテーブル２１０に格納されているファイルテーブルレコードＦＴＲ１中のエクステント情報によって示される。したがって、エクステント＃２の使用済みページ位置が５であることは、このファイルテーブルレコードＦＴＲ１中のエクステント情報によって確定されている。
【００８９】
このような状態で、あるトランザクションＴＲの中で、ファイル＃１（Ｆ１）へのデータ追加が発生し、使用済みページ位置の次のページ位置である６、即ちエクステント＃２の２ページ目への書き込みが必要になったとする。エクステント＃２の開始物理ＩＤは２１１であることから、当該エクステント＃２の２ページ目の物理ＩＤは２１２である。このとき、エクステント＃２の２ページ目、つまり物理ＩＤ＝２１２のページには、有効なデータは全く書かれていない。このことは、上述したように、ファイルテーブルレコードＦＴＲ１のエクステント情報（エクステント＃２に関するエクステント情報）の示す「使用済みページ位置」が５であることによって保証される。
【００９０】
このような場合、更新部１１２は、シャドウセグメント領域２２ではなく、データセグメント領域２１内の物理ＩＤ＝２１２のページ位置へ直接データの書き込みを行う（ステップＳ４１）。やがて、トランザクションＴＲを終了させるために、アプリケーションからコミット処理が要求されて、正常に書き込みが完了したものとする。この場合、コミット部１１３は、ファイルテーブルレコードＦＴＲ１に含まれている、エクステント＃２に関するエクステント情報の示す「使用済みページ位置」を、５から６に書き換える（ステップＳ４２）。
【００９１】
これに対し、物理ＩＤ＝２１２への書き込みに失敗した場合には、コミット部１１３は、ファイルテーブルレコードＦＴＲ１の「使用済みページ位置」の情報を書き換えずに５のままにする。これにより、リカバリが完了する。
【００９２】
このように第１の負荷軽減手法によれば、エクステント内の使用されていないページへのデータ追加では、シャドウセグメント領域２２を使わないことによって、チェックポイント処理を不要とし、加えて検索時のマップ参照も不要とすることができるという、２点の負荷軽減が実現できる。
【００９３】
次に、第２の負荷軽減手法について、図１１の動作説明図を参照して説明する。  
第２の負荷軽減手法の特徴は、チェックポイント処理によるデータセグメント領域２１への書き戻しが発生する前に、同一ページが更に更新された場合には、チェックポイント処理で書き戻すべきページは最新(最終)ページのイメージのみとする点にある。
【００９４】
チェックポイント処理が発生する前に、複数のトランザクションによって、同一ページの更新が複数回行われた場合、シャドウセグメント領域２２内に同一ページの過去のバージョンが順次保持される。
【００９５】
今、図１１に示すように、ファイル＃１（Ｆ１）の先頭エクステント＃１におけるページＰＤ１２の更新が３回順に行われたものとする。この場合、図１１に示すように、まずシャドウセグメント領域２２内の例えばページＰＳ１にページＰＤ１２の最初の更新イメージが保持される。次に、シャドウセグメント領域２２内の例えばページＰＳ３にページＰＤ１２の次の更新イメージが保持される。そして、シャドウセグメント領域２２内の例えばページＰＳ４にページＰＤ１２の最新の更新イメージが保持される。
【００９６】
このような状態で、第２の負荷軽減手法を適用するチェックポイント処理が発生したものとする。このチェックポイント処理では、旧バージョンのページイメージを参照しているトランザクションが存在しなくなった後に、データセグメント領域２１内の元のエクステント領域に対して、最新版のページイメージが書き戻される。図１１の例では、データセグメント領域２１内のページＰＤ１２に関し、シャドウセグメント領域２２内に、複数の旧バージョンのページイメージが保存されている。しかし、旧バージョンを参照しているトランザクションが存在しなくなった以上、必要なデータはシャドウセグメント領域２２内のページＰＳ４に保持されている最新ページイメージだけである。そこで、チェックポイント処理機構１３は、ページＰＳ４に保持されている最新ページイメージのみの書き戻しを行う。旧バージョンのページイメージを保存していたページは、空きページとして管理される。
【００９７】
上述の説明から明らかなように、本実施形態で適用されるシャドウセグメント方式は、従来から知られているシャドウページ方式に対して以下に述べる相違点と、シャドウページ方では得られない効果とを有する。
【００９８】
（１）シャドウページ方式におけるページテーブルに相当する、マップ（マップテーブル）のサイズが、データベースのサイズに依存しない。これに対して、シャドウページ方式は、データベースのサイズに応じてページテーブルのサイズが大きくなるという問題を有する。つまり本実施形態では、更新ページをシャドウセグメント領域２２と呼ぶ更新データの一時格納領域に配置し、ページ変換（物理ＩＤの変換）を、データベース全体に対するテーブルではなくて、更新ページ集合に対する連想記憶により行う、シャドウセグメント方式を適用している。このため、シャドウセグメント方式では、マップテーブルは、更新量に応じたサイズで済む。特にチェックポイント処理が完了した時点では、マップテーブル内のレコード数はゼロになることから、マップサーチでのページ変換のオーバーヘッドがなくなるというメリットがある。
【００９９】
（２）ファイルの断片化が防止できる。即ち本実施形態においては、データ更新において一時的にファイルの断片化が生じるが、チェックポイント処理によりオリジナルのエクステントの連続性が復元される。つまり、エクステント方式によるファイル管理方式をシャドウページ方式と組み合わせ、チェックポイント処理により、シャドウセグメント領域２２からデータセグメント領域（ファイル領域）２１への実更新を行うことで、ファイルの断片化を防止可能としている。
【０１００】
（３）コミットの応答時間を短くできる。一般に、シャドウページ方式におけるコミット時のコストは、更新を含む全ページをコミット時にバッファメモリからディスクに書かないといけないというデータ量の問題と、ファイルの断片化によるディスクのランダム書き込みのコストが高いことの２点である。一方、シャドウセグメント方式では、書き込み量の点はシャドウページ方式と同等である。しかし、シャドウセグメント方式では、シャドウセグメント領域２２を更新量に対して十分に大きくすることにより、当該シャドウセグメント領域２２内の新規ページの割り当てをサイクリックに行うことができる。これによりシャドウセグメント方式では、ロギング方式に近いシーケンシャル書き込みの性能を得ることができる。
【０１０１】
（４）オリジナルへの書き戻し（チェックポイント処理）中に更新が可能である。シャドウセグメント方式は、シャドウページ方式とサイドファイル方式を組み合わせた方式と考えることができる。このサイドファイル方式は、オリジナルファイルへの書き戻し中に更新ができないとう欠点がある。しかし本実施形態では、チェックポイント処理をファイル管理システム１０内で発生する独立したトランザクション（内部トランザクション）ＴＲｃとすることで、この欠点を克服している。つまり、本実施形態では、チェックポイント処理のトランザクションＴＲｃを通常のトランザクション同様、グループコミットによって一括処理可能とし、チェックポイント処理を通常のトランザクション処理にピギーバックさせて部分的に実行することで、上記の欠点を克服している。
【０１０２】
前述したように、シャドウセグメント領域２２の全てのページがカレントページであるような状態でのチェックポイント処理（実更新処理）では、当該チェックポイント処理の負荷が大きくなる。そこで、チェックポイント処理を、一定数のページを上限に複数回に分けて実行すると良い。このように、チェックポイント処理を一貫性のある単位ではなく部分的に実行することで、チェックポイント処理の負荷を平準化することができる。
【０１０３】
次に、本実施形態におけるオンラインバックアップ動作について、第１及び第２のオンラインバックアップに分けて順に説明する。なお、第１のオンラインバックアップとは、データセグメント領域２１のデータのみをオンラインでバックアップすることをいい、第２のオンラインバックアップとは、シャドウセグメント領域２２内の実更新できなかったページを含めてオンラインでバックアップすることをいう。
【０１０４】
まず、第１のオンラインバックアップについて、図１２の動作説明図を参照して説明する。ここでは、オンラインバックアップに際し、チェックポイント処理機構１３により図６に示されるようなチェックポイント処理(実更新処理)が実行される。この「チェックポイント処理」(実更新処理)は、前述した内部トランザクションＴＲｃにより、通常のトランザクションでの更新処理と並列に実行することが可能である。
【０１０５】
今、チェックポイント処理により、シャドウセグメント領域２２にある全ての更新ページ（カレントページ）のデータの、データセグメント領域２１への書き戻し（実更新）が完了したものとする。この場合、ファイル管理システム１０内のバックアップ機構（図示せず）は、図１２に示すように、データセグメント領域（オリジナル領域）２１のみのバックアップを行う（ステップＳ５１）。このバックアップ中にデータセグメント領域２１に対して行われる更新は、その更新が必要なページのイメージのコピーを利用して、シャドウセグメント領域２２内の空きページに対して行われる。ここでは、図１２に示すように、データセグメント領域２１に格納されているファイル＃２（Ｆ２）内のページＰＤｘへの更新が、シャドウセグメント領域２２内のページＰＳｙに対して行われるものとする（ステップＳ５２）。このように、シャドウセグメント領域２２に更新データが書かれるため、バックアップ中のデータセグメント領域２１のデータの一貫性は保証される。
【０１０６】
次に、第２のオンラインバックアップについて、図１３の動作説明図を参照して説明する。  
まず、オンラインバックアップに際して実行されるチェックポイント処理(実更新処理)で、シャドウセグメント領域２２にある一部のページの実更新（書き戻し）ができなかったものとする。このようなページは、チェックポイント処理の内部トランザクションＴＲｃが、通常のトランザクションと並列に実行される場合に発生する可能性がある。つまり、シャドウセグメント領域２２内の更新ページの書き戻し先となる、データセグメント領域２１内のページを必要としているトランザクションが存在する場合に、当該更新ページの実更新（書き戻し）ができなくなる。
【０１０７】
図１３の例では、シャドウセグメント領域２２内の実更新ができなかったページとして、ページＰＳ１，ＰＳ８，ＰＳｔ及びＰＳｕの４つが示されている。ファイル管理システム１０内のバックアップ機構は、シャドウセグメント領域２２内に実更新ができなかったページが存在する場合には、データセグメント領域（オリジナル領域）のバックアップに加えて、シャドウセグメント領域２２内の実更新ができなかったカレントページ、つまりページＰＳ１，ＰＳ８，ＰＳｔ及びＰＳｕのバックアップを行う。またバックアップ機構は、マップ２３-0及び２３-1のうちのオリジナルマップのバックアップも行う。図１３の例では、マップ２３-0がオリジナルマップであることから、当該マップ２３-0がバックアップされる。明らかなように、マップ２３-0には、ページＰＳ１，ＰＳ８，ＰＳｔ及びＰＳｕの物理ＩＤを含むレコードのみが格納されている。このレコードは、ページＰＳ１，ＰＳ８，ＰＳｔ及びＰＳｕのイメージが書き戻されるべき、データセグメント領域２１内の元のページ（オリジナルページ）の物理ＩＤを含む。
【０１０８】
バックアップ中にデータセグメント領域２１に対して行われる更新と、シャドウセグメント領域２２に対して行われる更新は、当該シャドウセグメント領域２２の新しいページに書かれる。そのため、データセグメント領域２１と、実更新ができなかったシャドウセグメント領域２２内のページとの組み合わせによって実現される一貫性は保証されている。
【０１０９】
上述したように、シャドウセグメント領域２２内に実更新ができなかったページが存在する場合、データセグメント領域２１のバックアップに加えて、実更新ができなかったページと、オリジナルマップとがバックアップされる。これにより、ストレージ装置２０等の障害が発生したとしても、バックアップデータに基づいてバックアップ時点の確定された状態に復旧した後に、その時点において実更新ができなかったページを、オリジナルマップに格納されている対応するレコードに従ってデータセグメント領域２１内の元のページ位置に正しく書き戻すことができる。ここで、オンラインバックアップに際して実行されるチェックポイント処理で、実更新（書き戻し）ができなかった更新ページが発生した場合、その実更新ができなかったページ（カレントページ）と元のページとに関する情報を、ローカルメモリ４０に保持しておき、その保持情報もバックアップすると良い。この場合、上記の保持情報に基づいて、更新ができなかったページ（カレントページ）と元のページとを直接特定できる。このため復旧時には、オリジナルマップをサーチすることなく、速やかに実更新を行うことができる。
【０１１０】
［変形例］
既に述べているように、上記実施形態の特徴は、シャドウページ方式をベースとするシャドウセグメント方式により、データの更新が、データセグメント領域２１内の元のページ（オリジナルページ）とは別の、シャドウセグメント領域２２内のページ（カレントページ）に対して行われる構成を適用する点にある。よって本実施形態においては、トランザクション処理中であっても更新前の状態を一貫性を保ったまま参照することが可能である。しかし本実施形態では、１対のマップ（マップテーブル）２３-0及び２３-1を原子的に切り替えることにより、トランザクション性を実現している。このため、オリジナルページを参照しているトランザクションが存在する場合に次のトランザクションを開始することができなくなる。この問題について以下に説明する。
【０１１１】
今、更新トランザクションＴＲ１がマップ２３-0（＃０）をオリジナルマップとして用いて処理を開始し、マップ２３-1（＃１）をカレントとしたものとする。参照トランザクションＴＲ２はオリジナルのマップ＃０を参照し一貫性のある問い合わせを実行する。その後、更新トランザクションＴＲ１が完了したものとする。更に、この状態で、更新トランザクションＴＲ３がマップ＃１をオリジナルマップとして用いて処理を開始して、マップ＃０をカレントとしようとするものとする。しかし、参照トランザクションＴＲ２がマップ＃０を参照しているので、更新トランザクションＴＲ３は処理を開始することができない。この問題は、１対のページテーブルを原子的に切り替えることにより、トランザクション性を実現している従来のシャドウページ方式でも同様である。
【０１１２】
この種の問題を解決する手段として、多版同時実行制御（multi-version concurrency control:ＭＶＣＣ）が知られている。多版型同時実行制御機能は、以下の４つの特徴
（ａ）検索(参照)ではロックを取得しない
（ｂ）別のトランザクションが更新中であっても、検索(参照)要求では「待ち」は発生しない
（ｃ）別のトランザクションが更新中に検索(参照)要求をした場合、取得できるのは、検索開始直前までにコミットされたデータイメージである
（ｄ）この旧バージョンのデータイメージは、検索による結果セット(Result Set)クローズされるまで、つまり検索結果の一部のデータをサーバ上に保持することが不要となるまで保持される
を持つ。
【０１１３】
一方、ログ方式では、ビフォアイメージを多数の世代保持するという手法によりトランザクション性が実現されている。しかし、この手法では、オリジナル領域の他に、アフターイメージとビフォアイメージの両方を持たないといけないため、ディスク使用量のコストが高くなる。
【０１１４】
上記実施形態の変形例の特徴は、多版型同時実行制御をシャドウセグメント方式に適用可能とした点にある。そのため、この変形例では、（１）コミット時刻、（２）ＭＶＣＣキューという２つの概念が適用される。以下、この２つの概念について説明する。
【０１１５】
（１）コミット時刻
上記（ｃ）の特徴に相当するトランザクション分離レベル(ＭＶＣＣによる)READ_COMMITTEDを実現するためには、「検索を行った時点」で前回コミットが完了しているデータイメージが必要になる。「検索を行った時点」とは、検索を行う直前にコミットが完了した時点を意味する。この「検索を行った時点」を特定するための概念として、「コミット時刻」が用意される。本変形例では、コミット時刻には、システムが初めて起動した時点から行われてきたコミットの回数が用いられる。つまりコミット時刻は単調増加する。
【０１１６】
（２）ＭＶＣＣキュー
単純なシャドウページ方式では、コミットが完了した時点で、更新前のオリジナルページは破棄して構わない。しかし、この変形例では、過去のバージョンの参照を可能にするために、他のトランザクションが参照しているページを破棄（再利用）しない構成を適用する。この構成を適用するには、他のトランザクションが参照しているページかどうかの判断基準とするための情報が必要となる。この情報が、マップ２３-I（ｉ＝１，２）に対応する世代の異なるローカルマップであり、ＭＶＣＣキューは、当該ローカルマップを積むのに用いられる。このＭＶＣＣキューは永続的な保存は必要ないので、ローカルメモリ４０上に構築することができる。
【０１１７】
図１４は、ローカルメモリ４０に保持されるＭＶＣＣキュー４１の一例を示す。図１４の例では、ＭＶＣＣキュー４１には、複数世代のローカルマップ４１０-1，４１０-2…が積まれている。各ローカルマップ４１０-j（ｊ＝１，２…）には、タイムスタンプとしてのコミット時刻Ｔｊの情報が付加されている。コミット時刻Ｔｊは、対応するトランザクションＴＲｊのコミット時刻、つまりシステムが最初に起動してからトランザクションＴＲｊがコミットされるまでのコミット回数を表す。ここでは、Ｔ１＜Ｔ２である。
【０１１８】
このように本変形例では、ＭＶＣＣキュー４１の導入により、マップ２３-0及び２３-1とは別に、実行中のトランザクションにより利用される世代の異なるマップ（ローカルマップ）４１０-iを動的に持ち、これらのマップから参照されているオリジナルページは再利用しない構成を適用する。
【０１１９】
この構成は、前述したログとビフォアイメージによるトランザクション性の実現と比較し、
アフターイメージのみで実現するためデータのコピー回数が少ない
ビフォアイメージ領域が不要なのでディスク使用量が少ない
トランザクション性実現のためのマップ参照とＭＶＣＣのためのマップ参照は基本的には同様の処理であり、実現のためのコストが少ない
という長所を有する。
【０１２０】
次に、本変形例の動作について、まずページ内データの更新が行われる場合を例に図５を援用して説明する。  
前述したように、図５の例では、トランザクションＴＲで更新されるデータがファイル＃２（Ｆ２）で、更新の必要なページがエクステント＃２２の２ページ目のページＰＤ１である。以下では、説明の都合上、トランザクションＴＲがトランザクションＴＲｊであるものとする。ページＰＤ１の物理ＩＤは１０００である。シャドウセグメント方式では、このページＰＤ１に対する更新が、当該ページＰＤ１のイメージのコピーを利用して、シャドウセグメント領域２２内の空きのページに対して行われる。図５の例では、この空きのページがページＰＳ１であり、その物理ＩＤ＝ＳＳ１である。
【０１２１】
この場合、トランザクションＴＲｊのコミット処理では、更新処理機構１１のコミット部１１３によって当該トランザクションＴＲの開始時点のオリジナルマップ２３-0がマップ２３-1にコピーされ、当該マップ２３-1に物理ＩＤ＝１０００と物理ＩＤ＝ＳＳ１の対を含むレコードが追加される。そしてマップのオリジナルが、マップ２３-0（＃０）からマップ２３-1（＃１）に切り替えられる。本変形例では、この他に、コミット時点でオリジナルに切り替えられるマップ（ここではマップ２３-1）のコピーが、コミット部１１３によって作成されて最新のローカルマップ４１０-jとしてＭＶＣＣキュー４１に積まれる（追加される）。このローカルマップ４１０-jには、トランザクションＴＲｊのコミット時点のコミット時刻Ｔｊがタイムスタンプとして付加される。
【０１２２】
次に、トランザクションＴＲｋでのデータ検索に伴うデータ読み込み処理（参照処理）について、上記実施形態と同様に、ファイル＃２（Ｆ２）における通しページ番号１０のページを読み込む場合を例に、図７及び図８を援用して説明する。
【０１２３】
まず、読み込み処理機構１２の読み込み部１２１は、トランザクションＴＲｋでのデータ検索要求（参照要求）時点のコミット時刻をトランザクション開始時刻とする。
【０１２４】
次に読み込み部１２１は、ファイルテーブル２１０中のファイルテーブルレコードＦＴＲ２を読み込む。そして読み込み部１２１は、このファイルテーブルレコードＦＴＲ２の示すファイル＃２のエクステント構成から、通しページ番号１０のページが、エクステント＃２２の５ページ目、即ち物理ＩＤが２１５のページであることを認識する。
【０１２５】
読み込み部１２１は、トランザクションＴＲｋに対応付けてローカルメモリ４０に格納されている情報（マップ追加要求）から、物理ＩＤ＝２１５のページが、当該トランザクションＴＲｋ自身で更新されたページであるかを判定する。もし、物理ＩＤ＝２１５のページが、トランザクションＴＲｋで更新されたページであるならば、読み込み部１２１の最新ページ読み込み部１２１ｂは、その更新されたページのデータを読み込む。
【０１２６】
これに対し、物理ＩＤ＝２１５のページが、トランザクションＴＲｋで更新されたページでないならば、読み込み部１２１のマップサーチ部１２１ａはＭＶＣＣキュー４１を参照して、上記トランザクション開始時刻Ｔｋと一致するコミット時刻を持つローカルマップを探す。このように、本変形例における１つのポイントは、トランザクション開始時刻をキーにＭＶＣＣキュー４１を検索することにある。
【０１２７】
ここでは、トランザクション開始時刻Ｔｋと一致するコミット時刻を持つローカルマップとして、ローカルマップ４１０-2が見つけられたものとする。するとマップサーチ部１２１ａは、このローカルマップ４１０-2をサーチして、物理ＩＤ＝２１５を含むレコードが格納されているかを調べる。もし、物理ＩＤ＝２１５を含むレコードが格納されているならば、マップサーチ部１２１ａは当該レコードから物理ＩＤ＝２１５と対をなすカレントページの物理ＩＤを取り出して、読み込み部１２１の最新ページ読み込み部１２１ｂに渡す。これにより最新ページ読み込み部１２１ｂは、マップサーチ部１２１ａから渡された物理ＩＤで示されるシャドウセグメント領域２２内のカレントページのデータを読み込む。
【０１２８】
これに対し、ローカルマップ４１０-2に、物理ＩＤ＝２１５を含むレコードが格納されていないならば、マップサーチ部１２１ａは、その時点におけるオリジナルマップ２３-0をサーチして、物理ＩＤ＝２１５を含むレコードが格納されているかを調べる。もし、物理ＩＤ＝２１５を含むレコードがオリジナルマップ２３-0に格納されているならば、マップサーチ部１２１ａは当該レコードから物理ＩＤ＝２１５と対をなすカレントページの物理ＩＤを取り出して、読み込み部１２１の最新ページ読み込み部１２１ｂに渡す。これにより最新ページ読み込み部１２１ｂは、マップサーチ部１２１ａから渡された物理ＩＤで示されるシャドウセグメント領域２２内のカレントページのデータを読み込む。
【０１２９】
一方、物理ＩＤ＝２１５を含むレコードがオリジナルマップ２３-0にも格納されていないならば、最新ページ読み込み部１２１ｂは、直接物理ＩＤ＝２１５のページのデータを読み込む。
【０１３０】
次に、ＭＶＣＣキュー４１の解放処理について説明する。この処理も、上記実施形態における実更新処理と同様にチェックポイント処理と呼ぶ。ＭＶＣＣキュー４１の解放は、例えばチェックポイント処理機構１３の図示せぬキュー解放部によって定期的に行われる。
【０１３１】
キュー解放部はまず、現在実行中のトランザクションの開始時刻（トランザクション開始時刻）の中から、最も古いトランザクション開始時刻Ｔを取得する。次にキュー解放部は、トランザクション開始時刻Ｔを、ＭＶＣＣキュー４１に積まれているローカルマップ４１０-1，４１０-2…のタイムスタンプ、つまりコミット時刻Ｔ１，Ｔ２…と比較する。そして、トランザクション開始時刻Ｔよりも古いタイムスタンプ（コミット時刻）のローカルマップを全て解放する。
【０１３２】
さて、ローカルマップの解放に伴って、シャドウセグメント領域２２の空きページ管理とオリジナルマップの圧縮が必要となる。この処理は、ファイル管理システム１０における内部トランザクションとして実行される。システムにおいて更新が頻繁に行われるときには、グループコミットにより一括処理することにより、負荷を軽減することができる。
【０１３３】
上述したシャドウセグメント方式でＭＶＣＣ機能を実現する場合、実更新にも影響を与える。実更新はＭＶＣＣキュー４１に積まれているローカルマップにより参照されないページに対してのみ行うことができる。換言すれば、ＭＶＣＣキュー４１に積まれているローカルマップにより示されるページは、現在実行中のトランザクションによって参照される可能性があるため、再利用の対象外とされる。
【０１３４】
なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。
【図面の簡単な説明】
【０１３５】
【図１】本発明の一実施形態に係るトランザクション管理機能を備えたファイルシステムの構成を示すブロック図。
【図２】図１中のファイル管理システム１０の構成を示すブロック図。
【図３】図１中のファイルテーブル２１０に保持されるファイル＃ｉ（Ｆｉ）に関するレコードＦＴＲｉのデータ構造例を示す図。
【図４】ファイル＃ｉ（Ｆｉ）とエクステントとの関係を示す図。
【図５】同実施形態におけるページ内データの更新を説明するための図。
【図６】同実施形態におけるチェックポイント処理を説明するための図。
【図７】ファイルテーブル２１０内のファイルテーブルレコードＦＴＲ２によって示される、ファイル＃２（Ｆ２）のエクステント構成を示す図。
【図８】同実施形態におけるデータ読み込み処理を説明するための図。
【図９】同実施形態におけるエクステントの拡張処理を説明するための図。
【図１０】同実施形態で適用される第１の負荷軽減手法を説明するための図。
【図１１】同実施形態で適用される第２の負荷軽減手法を説明するための図。
【図１２】同実施形態で適用される第１のオンラインバックアップを説明するための図。
【図１３】同実施形態で適用される第２のオンラインバックアップを説明するための図。
【図１４】同実施形態の変形例で適用されるＭＶＣＣ（多版同時実行制御）キュー４１におけるデータ構造例を示す図。
【符号の説明】
【０１３６】
１０…ファイル管理システム、１１…更新処理機構、１２…読み込み処理機構、１３…チェックポイント処理機構、１４…ファイル管理制御機構、２０…ストレージ装置、２１…データセグメント領域（ファイル領域）、２２…シャドウセグメント領域（一時書き込み領域）、２３-0，２３-1…マップ（マップテーブル）、２４…ディレクトリ、３０…バッファメモリ、４０…ローカルメモリ、４１…ＭＶＣＣ（多版同時実行制御）キュー、１１１，１２１…読み込み部、１１２…更新部、１１３，１３２…コミット部、１３１…マッピング要求部、２１０…ファイルテーブル。
【図１】
2006106868.tif 000003
【図２】
2006106868.tif 000004
【図３】
2006106868.tif 000005
【図４】
2006106868.tif 000006
【図５】
2006106868.tif 000007
【図６】
2006106868.tif 000008
【図７】
2006106868.tif 000009
【図８】
2006106868.tif 000010
【図９】
2006106868.tif 000011
【図１０】
2006106868.tif 000012
【図１１】
2006106868.tif 000013
【図１２】
2006106868.tif 000014
【図１３】
2006106868.tif 000015
【図１４】
2006106868.tif 000016