JP2006106868A - ファイル管理機能を備えたファイルシステム及びファイル管理方法 - Google Patents

ファイル管理機能を備えたファイルシステム及びファイル管理方法 Download PDF

Info

Publication number
JP2006106868A
JP2006106868A JP2004289029A JP2004289029A JP2006106868A JP 2006106868 A JP2006106868 A JP 2006106868A JP 2004289029 A JP2004289029 A JP 2004289029A JP 2004289029 A JP2004289029 A JP 2004289029A JP 2006106868 A JP2006106868 A JP 2006106868A
Authority
JP
Japan
Prior art keywords
page
file
update
map
area
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.)
Granted
Application number
JP2004289029A
Other languages
English (en)
Other versions
JP4104586B2 (ja
Inventor
Koji Matsui
浩二 松井
Hitoshi Tanigawa
均 谷川
Yuji Kondo
雄二 近藤
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Toshiba Corp
Toshiba Digital Solutions Corp
Original Assignee
Toshiba Corp
Toshiba Solutions Corp
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by Toshiba Corp, Toshiba Solutions Corp filed Critical Toshiba Corp
Priority to JP2004289029A priority Critical patent/JP4104586B2/ja
Priority to CNB2005100646024A priority patent/CN100412862C/zh
Priority to US11/144,637 priority patent/US7266669B2/en
Publication of JP2006106868A publication Critical patent/JP2006106868A/ja
Application granted granted Critical
Publication of JP4104586B2 publication Critical patent/JP4104586B2/ja
Expired - Fee Related legal-status Critical Current
Anticipated expiration legal-status Critical

Links

Images

Classifications

    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1415Saving, restoring, recovering or retrying at system level
    • G06F11/1435Saving, restoring, recovering or retrying at system level using file system or storage system metadata
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1474Saving, restoring, recovering or retrying in transactions
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10File systems; File servers
    • G06F16/18File system types
    • G06F16/1865Transactional file systems
    • GPHYSICS
    • G06COMPUTING; CALCULATING OR COUNTING
    • G06FELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00Error detection; Error correction; Monitoring
    • G06F11/07Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/14Error detection or correction of the data by redundancy in operation
    • G06F11/1402Saving, restoring, recovering or retrying
    • G06F11/1446Point-in-time backing up or restoration of persistent data
    • G06F11/1458Management of the backup or restore process
    • G06F11/1466Management of the backup or restore process to make the backup process non-disruptive
    • YGENERAL TAGGING OF NEW TECHNOLOGICAL DEVELOPMENTS; GENERAL TAGGING OF CROSS-SECTIONAL TECHNOLOGIES SPANNING OVER SEVERAL SECTIONS OF THE IPC; TECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10TECHNICAL SUBJECTS COVERED BY FORMER USPC
    • Y10STECHNICAL SUBJECTS COVERED BY FORMER USPC CROSS-REFERENCE ART COLLECTIONS [XRACs] AND DIGESTS
    • Y10S707/00Data processing: database and file management or data structures
    • Y10S707/99951File or database maintenance
    • Y10S707/99952Coherency, e.g. same view to multiple users

Abstract

【課題】シャドウページ方式におけるページテーブルに相当するマップテーブルのサイズを小さくし、且つファイルデータの断片化を防止する。
【解決手段】ストレージ装置20の記憶領域には、データセグメント領域21とシャドウセグメント領域22とが確保される、上記記憶領域にはマップ23-0,23-1が配置される。ファイル管理システム10は、データセグメント領域21に格納されているファイルのページ更新を、シャドウセグメント領域22から取得される空きページに更新データを書き込むことで実行する。ファイル管理システム10はトランザクションのコミット時毎に、その時点におけるシャドウセグメント領域22の有効ページのリストをマップ23-0,23-1に交互に書き込む。ファイル管理システム10は、シャドウセグメント領域22内の有効ページの更新データをデータセグメント領域21の元のページ位置に書き戻す。
【選択図】 図1

Description

本発明は、トランザクション管理を含むファイル管理機能を備えたファイルシステムに係り、特にファイルの更新を一時書き込み領域上で実行するファイル管理機能を備えたファイルシステム及びファイル管理方法に関する。
一般にファイル管理システムにおけるトランザクション管理では、原子性(atomicity)、一貫性(consistency)、分離性(isolation)及び持続性(durability)の4つの基本要件、いわゆるACID特性が要求される。このACID性のうち、ACD(原子性、一貫性、持続性)はコミット/ロールバックとリカバリによって実現される。リソースマネージャのACDの実現手法はログ(ロギング)方式とサイドファイル方式とに分けられる。
<ログ方式>
ログ方式は、データの更新に際し、更新前の状態(UNDO)とコミットで確定した状態(REDO)とをログに保存する手法である。システムの異常終了に際しては、コミット前の更新済みデータに対してはUNDOログにより更新前状態に戻し、コミット後の未更新データに対してREDOにより確定状態にする。ログ方式には、コミット前のデータを書き出さない(non-steal)方式や、ログを物理的に採るか論理的に採るかなど、様々な手法がある。
<サイドファイル方式>
サイドファイル方式は、データは「その場」では変更されずに、新しい値が「別の場所」に書き出される方式である(例えば、非特許文献1参照)。「その場」と「別の場所」は論理空間では同じ場所に所属し、時系列で異なるイメージを保持していることを管理するためのメカニズムが提供される。サイドファイルを実現する代表的な方式がシャドウページ方式である。このシャドウページ方式では完全に原子的な更新が提供されるため、システム障害に際しては復旧が不要という特徴がある。
シャドウページ方式では、ページテーブルとビットマップとの組が2組用いられる。ページテーブルは、ファイルのブロック(ページ)に対して1つのエントリを持つ配列である。ページテーブルのそれぞれのエントリは、対応するブロックの現イメージを保持するスロットの番号を持つ。一方、ビットマップは、スロットあたり1ビットで構成され、対応するスロットが現時点でブロックイメージを保持しているかを示す。ディレクトリは、現在の有効な現ページテーブルとビットマップとの組を示す。シャドウページ方式では、このディレクトリの更新により原子性が保障される。
シャドウページ方式の特徴は、データの更新は別の場所に行われ、ページテーブルが複数化されていることで、データ更新からディレクトリ更新の間のどのタイミングで障害が発生しても、リカバリ処理を一切行うことなく更新をキャンセルすることができる点にある。
ジム・グレイ、アンドレアス・ロイター著、喜連川 優 監訳、「トランザクション処理(概念と技法)」下巻、13.5.1節 サイドファイル、日経BP社、2001年10月20日、p.860−870
ログ方式とサイドファイル方式の一方式であるシャドウページ方式とを比較すると、性能的にはログ方式が優れていることが知られている。
高可用性が要求されるファイル管理システムでは、万一の障害に対して短時間にサービスを再開しなければならない。そこで通常は、高信頼化と高いスループットの実現のためにログ方式が適用されることが多い。ところがログ方式は、障害発生時に、未更新のデータを、ログからロールフォワードにより回復する必要があるため、その回復に長時間(例えば数分程度の時間)を要することがある。
一方、実装の簡易さや障害からの復旧の高速性の点では、シャドウページ方式が優れている。つまり、シャドウページ方式では、上述したように障害回復が不要であることから、短時間(例えば数秒以内)でサービスを回復することができる。しかし、従来のシャドウページ方式は性能面で以下のような問題、つまり
・大きなサイズのページテーブルを必要とする
・フラグメントを起こしやすい
・コミット時のコストが高い
という問題があり、実用的ではない。特に大規模なデータベースでは、シャドウページ方式はディスクのアクセスコストの増加により性能の劣化が顕著になる。以下、上記の問題について詳述する。
まず、従来のシャドウページ方式では、大きなデータベースに対しページテーブルが完全に主記憶に入るという保証はない。例えばページサイズ2KB(キロバイト)で1TB(テラバイト)のデータベースのページ数は、500M(メガ)ページである。この場合、2つのページテーブルに必要なサイズは、1エントリ4Bであるものとすると、500M*2*4B=4GBにもなる。つまり、大きなサイズのページテーブルが必要である。ページテーブルのサイズが巨大になると、ページテーブルのバッファヒット率が、例えば90%を下回る可能性がある。もし、ページテーブルがバッファにヒットせず、ディスクからの読み出しが必要になると、ページテーブルとデータはディスク上は離れて配置されるため、ページテーブルとデータページをまたぐランダムアクセスが急激に増加し、性能を著しく劣化させる。仮に100%近いヒット率であったとしても、バッファの呼び出しが多くなり性能を劣化させる。
また、データ更新の結果、ブロック(ページ)を再割り当てすると、フラグメントを起こす。フラグメントの結果ランダムなブロック入出力が増えるため、ディスクアクセス時のデータ転送速度が低下する。
また、コミット時にはデータブロックとページテーブルのディスクへの同期書き込みが必要になる。特にデータブロックの書き込みはランダムになる。このため、コミット時のコストが大きい。
更に、システム内で一貫性のとれた状態を保持するためには、ディスクへの同期書込み(コミット処理)を排他する必要がある。そのため、バックアップ処理中の更新ができない、換言すれば更新処理中のバックアップができないという問題もある。
トランザクションの基本要件の1つとしてトランザクションの分離性がある。つまり、更新中のデータを他のトランザクションから読めないようにすること、読み込み処理に時間がかかっても開始時点の一貫性を保証することが必要となる。多くのトランザクション処理システムでは、ロックによる相互排他によって分離する方法が採られている。この場合、更新中のデータの読み込み(参照)が待たされるという問題もある。
本発明は上記事情を考慮してなされたものでその目的は、シャドウページ方式におけるページテーブルに相当するマップテーブルのサイズを小さくすることができ、且つファイルデータの断片化を防止できるファイル管理機能を備えたファイルシステム及びファイル管理方法を提供することにある。
本発明の他の目的は、更新処理中のバックアップができるファイル管理機能を備えたファイルシステム及びファイル管理方法を提供することにある。
本発明の更に他の目的は、更新中のデータ参照を待たせることなく一貫性を保証できるファイル管理機能を備えたファイルシステム及びファイル管理方法を提供することにある。
本発明の1つの観点によれば、トランザクション管理機能を有するファイルシステムが提供される。このファイルシステムは、ファイルによって占有されるファイル領域と、ファイルのページ単位の更新データを一時的に保持する一時書き込み領域とが確保される記憶領域を有するストレージ装置と、このストレージ装置の上記記憶領域に配置される、上記一時書き込み領域内の更新が行われた有効ページのリストを記録するための1対のマップテーブルと、上記ファイル領域に格納されているファイルを管理するファイル管理手段と、このファイル管理手段によって管理される、上記ファイル領域に格納されているファイルのページ更新を、上記一時書き込み領域から取得される空きページに更新データを書き込むことで実行する更新処理手段と、トランザクションのコミット時毎に、その時点における上記一時書き込み領域内の有効ページのリストを上記1対のマップテーブルに交互に書き込むコミット手段と、上記一時書き込み領域内の有効ページの更新データを上記ファイル領域の元のページ位置に書き戻し、当該書き戻しが行われた有効ページを開放する実更新処理を行う実更新手段とを備える。
このような構成のファイルシステムにおいては、ストレージ装置の記憶領域をファイル領域と一時書き込み領域とに分け、ページ更新のリストを保持するマップテーブル(シャドウページ方式におけるページテーブルに相当)を一時書き込み領域内のページへの書き込みにのみ適用することで、当該マップテーブルのサイズを小さくすることを可能とし、加えて、一時書き込み領域内の有効ページの更新データをファイル領域の元のページ位置に書き戻す実更新処理により、ファイルデータの断片化防止を可能とする。
ここで、上記ファイル管理手段に、上記ファイル領域に格納されるファイルテーブルであって、上記ファイル領域に格納されているファイルをエクステント単位で管理し、上記ファイルを構成するエクステントを示すエクステント情報を1つのレコードとして保持するファイルテーブルが含まれる構成とすると共に、当該ファイルテーブル自身を1つのファイルとしてトランザクション管理の対象とされる構成とすると良い。
このような構成においては、ファイルテーブルをトランザクション管理の対象とすることで、ファイルの追加や、ファイルの拡張を含む更新処理をトランザクションとして管理することができる。
また、上記実更新手段による実更新処理の確定操作が、上記1対のマップテーブルの一方に対する更新処理によって実行される構成とすると良い。このように、通常のファイル更新の確定だけでなく、実更新処理の確定も、マップテーブルの更新処理で行うことができるため、実更新中に通常のファイル更新が可能になる。
また、上記実更新手段による実更新処理を複数回に分けて実行すると良い。このように、実更新処理を一貫性のある単位ではなく部分的に実行することで、実更新の負荷を平準化することができる。
また、ストレージ装置の記憶領域のデータをオンラインでバックアップするバックアップ手段であって、バックアップ開始時に、上記一時記憶領域内に、上記実更新手段による更新データの書き戻しが完了していない有効ページが存在する場合には、上記ファイル領域のデータと、当該書き戻しが完了していない有効ページのデータと、上記一対のマップテーブルのうち、最も最近に確定されたマップテーブルとをバックアップするバックアップ手段を追加すると良い。このような構成においては、上述の実更新処理の確定をマップテーブルの更新処理で行うことで実現される、一貫性の取れた、ファイル領域のデータと一時書き込み領域の有効ページデータとを、最も最近に確定されたマップテーブルと共にバックアップすることで、バックアップ処理中の更新が可能となる。つまり、更新中の一貫性のあるバックアップが可能となる。
また、上記1対のマップテーブルのうちトランザクションのコミット時に確定されたマップテーブルが反映されたローカルマップを、当該コミット時の時刻を表すタイムスタンプを付して積むための多版同時実行制御キューと、任意のトランザクションにおいて要求されたページのデータを読み込む読み込み手段であって、上記要求されたページが上記任意のトランザクションで更新されていない場合、当該任意のトランザクションの開始時刻に対応するタイムスタンプが付されたローカルマップを上記多版同時実行制御キューから検索し、当該ローカルマップに従い、前記要求されたページのデータを読み込む読み込み手段とを追加すると良い。
このような構成においては、複数世代のトランザクションの更新リスト(ローカルマップ)をタイムスタンプを付して多版同時実行制御キューに保持して、任意のトランザクションにおいて要求されたページのデータの読み込みに、当該任意のトランザクションの開始時刻に対応するタイムスタンプが付された更新リストを利用することで、更新中に、トランザクション開始時点の一貫性のあるデータを取得することが可能となる。
本発明によれば、シャドウページ方式におけるページテーブルに相当するマップテーブルのサイズを小さくすることができ、且つファイルデータの断片化を防止でき、これにより通常運用の性能の向上と障害回復の高速化とを両立させることができる。
また本発明によれば、更新中に、一貫性の取れた、ファイル領域のデータと一時書き込み領域の有効ページデータとを実現できるため、更新処理中のバックアップができる。更に本発明によれば、複数世代のトランザクションの更新リストをタイムスタンプを付して多版同時実行制御キューに保持して、任意のトランザクションにおいて要求されたページのデータの読み込みに、当該任意のトランザクションの開始時刻に対応するタイムスタンプが付された更新リストを利用することにより、更新中にデータ読み込みを待たせることなく一貫性を保証できる。
以下、本発明の一実施形態につき図面を参照して説明する。
図1は本発明の一実施形態に係るトランザクション管理機能を備えたファイルシステムの構成を示すブロック図である。このファイルシステムは、主として、ファイル管理システム10と、ストレージ装置20と、バッファメモリ30と、ローカルメモリ40とから構成される。
ストレージ装置20は、例えばディスクドライブを用いて構成されるディスクストレージ装置である。ストレージ装置20の記憶領域(ディスク領域)は、主として、データセグメント領域21とシャドウセグメント領域22とに分けて管理される。
データセグメント領域21はファイルによって占有されるファイル領域である。ファイルとは、データベース(DB)に格納される「論理的な」まとまり毎に割り当てられた管理単位である。また、ファイルは、物理的には1つ、もしくは複数のエクステントから構成される。エクステントとは、指定されたサイズで確保された物理連続ページ領域のことを指す。ファイルは、初期エクステントサイズで作成され、データの追加に応じて、エクステント単位で拡張される。図1には、データセグメント領域21に、ファイルF1(#1),F2(#2),F3(#3)…が格納されている様子が示されている。
データセグメント領域21にはまた、ファイルテーブル210が格納されている。ファイルテーブル210は、データセグメント領域21に格納されているファイルを管理するためのテーブルである。このファイルテーブル210自身が、データセグメント領域21に格納されている1つのファイル(ここではファイル#0)である。ファイルテーブル210は、データセグメント領域21に格納されているファイルの数分のレコードを保持する。つまりファイルテーブル210は、ファイル#0,#1,#2…に関するレコード(ファイルテーブルレコード)FTR0,FTR1,FTR2…を保持する。
シャドウセグメント領域22は、ファイルの更新データ(更新ページ)を一時的に保持する一時書き込み領域である。つまりシャドウセグメント領域22は、ファイル内のページに対して更新が行われた際のカレントページ格納領域である。従来のシャドウページ方式では、データベースに割り当てられた全てのページの中からカレントページ用空きページが探し求められる。これに対して本実施形態では、更新に利用する空きページは、全てシャドウセグメント領域22から探し求められる。そこで、この方式を、従来のシャドウページ方式に対比させて、シャドウセグメント方式と呼ぶ。
このように本実施形態では、データを保持する場所とデータが更新される場所とを、従来のシャドウページ方式とは異なって、基本的にはディスク領域上に混在させない構成を適用している。つまり本実施形態では、ファイルの更新が、シャドウセグメント領域22と呼ぶ、ファイル領域(データセグメント領域21)とは異なる限られた領域のみで行われる。そこで以下の説明では、ファイル更新が行われないファイル領域(データセグメント領域21)を「オリジナル領域」と呼ぶこともある。但し、ファイルのエクステント内の使用されていないページへのデータ追加に限り、そのページに直接データが追加される。
ストレージ装置20のディスク領域には、従来のシャドウページ方式におけるページテーブルに相当する1対のマップ(マップテーブル)23-0(#0)及び23-1(#1)が配置される。このマップ23-0及び23-1は、シャドウページ方式におけるページテーブルとは異なって、ディスク領域に構築されるデータベースの全ページではなく、シャドウセグメント領域22のページ数に等しいエントリだけを有する。マップ23-0及び23-1は、シャドウセグメント領域22内の有効なページ(更新されたページ)のリスト(更新リスト)を保持する。このリストは、シャドウセグメント領域22内の有効なページのID情報(物理ID)と、当該ページに対応するデータセグメント領域21内のページのID情報(物理ID)との組を含むレコードの配列である。
ストレージ装置20のディスク領域にはまた、ディレクトリ24が配置される。ディレクトリ24は、マップ23-0及び23-1のいずれがオリジナルのマップ(確定されたマップ)であるかを示す。オリジナルでない方のマップは、カレントのマップである。
ファイル管理システム10は、トランザクション管理を含むファイル管理機能を有する。ファイル管理システム10は、ファイル管理用のプログラムを、計算機が読み取り実行することにより実現される。このファイル管理用のプログラムは、計算機で読み取り可能な記憶媒体に予め格納して頒布可能である。また、このプログラムが、ネットワークを介してダウンロード(頒布)されても構わない。
図2はファイル管理システム10の構成を示すブロック図である。ファイル管理システム10は、更新処理機構11と、読み込み処理機構12と、チェックポイント処理機構13と、ファイル管理制御機構14とから構成される。
更新処理機構11は、更新トランザクションを管理し、読み込み部111と、更新部112と、コミット部113とから構成される。読み込み部111は、マップサーチ部111aと、最新ページ読み込み部111bとを含む。更新部112は、シャドウセグメント更新部112aを含む。コミット部113は、マップ更新部113aと、更新ページフラッシュ部113bと、マップフラッシュ部113cと、ディレクトリ切替部113dとを含む。
読み込み処理機構12は、読み込み部121から構成される。読み込み部121は、マップサーチ部121aと、最新ページ読み込み部121bとを含む。読み込み処理機構12内の読み込み部121は、更新処理機構11内の読み込み部111に相当する。このため、読み込み部111及び121の一方を、更新処理機構11及び読み込み処理機構12で共有使用することにより、読み込み部111及び121の他方を省略することが可能である。
チェックポイント処理機構13は、チェックポイント部131と、コミット部132とから構成される。チェックポイント部131は、コピー部131aを含む。コミット部132は、マップ更新部132aと、更新ページフラッシュ部132bと、マップフラッシュ部132cと、ディレクトリ切替部132dとを含む。チェックポイント処理機構13内のコミット部132は更新処理機構11内のコミット部113に相当する。両者の違いは、後述するように、コミット部113のマップ更新部113aがマップにレコードを記録する更新処理を行うのに対し、コミット部132のマップ更新部132aはマップからレコードを削除する更新処理を行う点にある。したがって、コミット部113及び132の一方を、更新処理機構11及びチェックポイント処理機構13で共有使用すると共に、その一方のマップ更新部に、レコード記録とレコード削除の両機能を持たせるならば、コミット部113及び132の他方を省略することが可能である。
ファイル管理制御機構14は、図1のファイルシステムを利用するアプリケーションからの要求、例えばトランザクションの開始要求、当該トランザクションでの更新操作を確定させるためのコミット要求に従い、上記更新処理機構11、更には読み込み処理機構12を制御する。ファイル管理制御機構14はまた、チェックポイント処理のためのトランザクションを発生し、チェックポイント処理機構13を制御する。
バッファメモリ30は、ファイル管理システム10とストレージ装置20との間で入出力されるページデータを一時記憶するのに用いられるディスクキャッシュメモリである。ローカルメモリ40は、ファイル管理システム10のファイル管理に必要な一時的な情報を保持するのに用いられる。
ここで、図1のシステムで適用されるシャドウセグメント方式の前提条件となるファイルとエクステント(extent)の概要について説明する。本実施形態では、ファイル内のページを物理ディスクに確保する(割り当てる)方式として、エクステント方式を採る。エクステント方式の基本は、
・ファイルは複数の(物理的に)連続な領域(これをエクステントと呼ぶ)によって構成される
・データ増加に伴って領域が不足する場合には、エクステント単位で新たな連続領域を確保する
点にある。
図3は、ファイルテーブル210に保持されるファイル#i(Fi)に関するレコード(ファイルテーブルレコード)FTRiのデータ構造例を示し、図4はファイル#i(Fi)とエクステントとの関係を示す。図3及び図4の例は、ファイル#i(Fi)が、3つのエクステントEi1(#i1),Ei2(#i2)及びEi3(#i3)によって構成される場合を想定している。
レコードFTRiは、ヘッダと、対応するファイル#i(Fi)を構成する各エクステントに関する情報(エクステント情報)とを含む。ヘッダは、内部識別子と呼ばれるファイル#i(Fi)のID(ファイルID)と、外部識別子と呼ばれるファイル#i(Fi)の名前(ファイル名)と、ファイル#i(Fi)を構成するエクステントの数を示す情報とを含む。一方、エクステント情報は、対応するエクステントのディスク(ディスク領域)上の開始位置と、確保(予約)された累積ページ数と、使用済みページ位置とをそれぞれ示す情報を含む。使用済みページ位置は、対応するエクステントにおける最後尾の使用済みページの、ファイル先頭(先頭エクステントの先頭ページ)を起点とするページ位置を示す。図4の例では、エクステント#i1(Ei1),#i2(Ei2)及び#i3(Ei3)のページ数は、それぞれ5,10及び10である。また、エクステント#i3(Ei3)の最後のページだけが未使用である。したがって、エクステント#i1(Ei1),#i2(Ei2)及び#i3(Ei3)の累積ページ数は、それぞれ、5,15及び25であり、エクステント#i1(Ei1),#i2(Ei2)及び#i3(Ei3)の使用済みページ位置は、それぞれ5,15及び24である。
以降で説明する処理の流れの中では、各ファイルには、そのファイルを構成するエクステント、即ち連続した領域が確保(予約)されている、ということが前提になっている。言い換えれば、次のようなポイントがある。
従来のシャドウページ方式では、空きページは完全に(つまりシステム的に、どの機能から見ても)空きページであって何に使っても構わない。しかし本実施形態では、エクステント方式で確保(予約)された領域については、実データが書かれていないという意味で空きページであったとしても、そのページは確保された際の用途以外で使われることはない。
次に、本実施形態の動作について、ページ内データの更新が行われる場合を例に、図5の動作説明図を参照して説明する。
まず、ファイル管理システム10のファイル管理制御機構14に、図1のファイルシステムを利用するアプリケーションからトランザクションTRの開始が要求されたものとする。ここでは、トランザクションTRで更新されるデータがファイル#2(F2)で、更新の必要なページがエクステント#22の2ページ目のページPD1であるとする。また、このページの物理IDを1000とする。
シャドウセグメント方式では、オリジナルページはシャドウとして残しておく必要がある。このため、更新は、更新が必要なページPD1のイメージのコピーを利用して、シャドウセグメント領域22内のページに対して行われる。そこで、更新処理機構11内の読み込み部111に含まれているマップサーチ部111aは、シャドウセグメント領域22内から更新用に用いる空きページを取得する。この空きページは、マップ23-0及び23-1のうちのオリジナルマップをサーチすることで取得することができる。ここでは、上記トランザクションTRの開始時のオリジナル(確定)マップはマップ23-0(#0)であり、カレントなマップはマップ23-1(#1)であるものとする。また、空きページとしてページPS1が見つけられたものとする。このシャドウセグメント領域22内のページPS1のIDをSS1とする。
読み込み部111の最新ページ読み込み部111bは、更新の必要なページPD1のデータを読み込む(ステップS1)。最新ページ読み込み部111bによって読み込まれたページPD1のイメージは、シャドウセグメント領域22内のページPS1にコピーされる。但し、ファイル管理システム10とストレージ装置20との間にバッファメモリ30が設けられている本実施形態では、このコピーは実際には、ページPS1に対応するバッファメモリ30内のページ(ブロック)に対して行われる。
更新処理機構11内の更新部112に含まれているシャドウセグメント更新部112aは、シャドウセグメント領域22内のページ(カレントページ)PS1の更新を行う(ステップS2)。但し、ここでの更新も、実際には、ページPS1に対応するバッファメモリ30内のページ(ブロック)に対して行われる。このとき、シャドウセグメント更新部112aはマップ登録要求記録部として機能して、ページPD1の更新後のページイメージ(カレントページのイメージ)がシャドウセグメント領域22内のページ(カレントページ)PS1に存在することを示す情報を、ローカルメモリ40内にトランザクションTRに対応付けて確保された一時マップに格納(記録)する。この情報は、PD1の物理ID=1000とPS1の物理ID=SS1との対を含む。この情報は、トランザクションTRを終了させる際に、その時点におけるカレントマップに追加される。そこで、この情報をローカルメモリ40内のトランザクションTRに対応した一時マップに記録することを、マップ追加要求記録と表現する。物理IDは、データセグメント領域21内のページに関しては、当該データセグメント領域21内の相対ページ位置を示し、シャドウセグメント領域22内のページに関しては、当該シャドウセグメント領域22内の相対ページ位置を示す。
その後、トランザクションTRを終了させるために、アプリケーションから当該トランザクションTRでの更新操作を確定するコミット処理が要求されたものとする。上述したように、このトランザクションTRの開始時のオリジナルマップはマップ23-0(#0)である。この場合、更新処理機構11のコミット部113に含まれているマップ更新部113aは、マップ23-0(#0)をマップ23-1(#1)にコピーし、ローカルメモリ40内のトランザクションTRに対応した一時マップに格納されている情報(マップ追加要求)に従い、物理ID=1000に関するレコード、つまりページPD1の物理ID=1000とページPS1の物理ID=SS1との対を含むレコードを追加(記録)する(ステップS3)。このレコードは、物理ID=1000のページPD1に対応する最新版ページSS1がシャドウセグメント領域22内に存在することを表す。なお、上記レコード追加のマップ更新操作は、実際には、マップ23-0(#0)及びマップ23-1(#1)が配置されるページに対応するバッファメモリ30内のページ(ブロック)に対して行われる。
次にコミット部113の更新ページフラッシュ部113bは、バッファメモリ30内にシャドウセグメント領域22に反映されていない更新ページ(ダーティな更新ページ)があれば、その更新ページを全て、シャドウセグメント領域22内の対応するページにフラッシュする。同様にコミット部113のマップフラッシュ部113cは、バッファメモリ30内にマップ23-1に反映されていない当該更新マップのページがあれば、その更新マップを、マップ23-1にフラッシュする。
この段階で、コミット部113のディレクトリ切替部113dは、ディレクトリ24を操作して、マップのオリジナルを、マップ23-0(#0)からマップ23-1(#1)に切り替える(ステップS4)。これによりコミット処理は終了する。
以上の処理のなかでポイントとなるのは、次の2点である。1つは、更新用のカレントページが、シャドウセグメント領域22の中から用意される点である。つまり、更新用のカレントページには、シャドウセグメントのみを利用する点である。もう1つは、マップ23-i(ここではi=1)には、シャドウセグメント領域22内にページイメージがあるカレントページ(更新ページ)の物理IDを含むレコードのみが追加される点である。つまり、マップ23-iに格納されていない物理IDで示される、シャドウセグメント領域22内のページは空きページである。マップ23-Iに追加されたレコードには、シャドウセグメント領域22内の更新ページの物理IDと対をなして、当該更新ページに対応するデータセグメント領域21内の古いページの物理IDが含まれている。
トランザクションの更新によって、コミットされるまではトランザクションローカルとなるデータが発生する。このデータの管理のために、トランザクションで更新したドキュメントページのマップ情報(データセグメント領域21内のページの物理IDとシャドウセグメント領域22内の対応するページの物理IDとを含む情報)を保持するのが上述の一時マップである。一時マップは、トランザクションの開始で作成され、トランザクションの終了(コミット/ロールバック)で破棄される。
本実施形態ではリカバリ方式としてシャドウセグメント方式を採用しているが、そのベースはシャドウページ方式である。シャドウページ方式においては、更新確定(コミット)処理の際には、
(1)データ(データページ)のディスクへの書き込み
(2)マップのコピー・更新・書き込み
(3)空き領域管理のためのフリービットページ(FBP)とそのシャドウ処理
が必要となる。
ページのディスクI/O処理はメモリアクセスや計算処理に比較して非常に重い。コミット処理を行うとコミット処理の直列化及び上記マップ処理により応答性が低下する恐れがある。また、マップの更新は一貫性のある単位で行わなければならないため、直接マップを更新する方法では同時に複数の更新を行うことができない。
そのため、個々のトランザクションの更新情報を一貫性のある単位で上記一時マップに記録し、コミット要求のタイミングでカレントマップを一度に更新する。更に、本実施形態では複数のコミット要求をまとめて処理する。この複数のコミット要求をまとめて処理することをグループコミットと呼ぶ。
コミットの遅延により、各トランザクションの平均応答時間が長くなるが、その分、トランザクション当たりオーバヘッド(I/O準備と発行、完了後の後始末など)は非常に短くなる。一般に低負荷の場合遅延させず、高負荷の場合は一定時間遅延させることによって最適なスループットが得られる。本実施形態では、グループコミット実行中のコミット要求はコミット完了まで遅延させ、次のグループコミットによってその間の要求をまとめて処理することで、最適化を図る。遅延時間の制御までは行わない。
次に、本実施形態におけるチェックポイント処理について、図6の動作説明図を参照して説明する。このチェックポイント処理によって、上記2つのポイントが大いに重要であることが理解されよう。
チェックポイント処理の目的は、シャドウセグメント領域22に作られている更新後のページイメージを、データセグメント領域21内の元の位置(=連続領域の中)に戻すことで、ディスクI/Oの高速化を図ることにある。
本実施形態におけるチェックポイント処理(実更新処理)を、ファイル管理システム10のファイル管理制御機構14で内部的に発生させる独立したトランザクションTRcとする。つまり、このチェックポイント処理を、他のトランザクション内の一部に相乗りさせることはしない。但し、コミットについては、他のトランザクション同様、グループコミットによって一括処理可能とする。本実施形態において、トランザクションTRcは、シャドウセグメント領域22内の空きページが少なくなった場合、例えば全ページ数に対する空きページの比率が一定値未満となった場合に発生される。なお、トランザクションTRcが定期的に発生される構成としても構わない。
まず、マップ23-1(#1)がオリジナルであることがディレクトリ24によって示されているものとする。この場合、チェックポイント処理機構13のチェックポイント部131に含まれているコピー部131aは、オリジナルのマップ23-1(#1)を参照する。これによりコピー部131aは、シャドウセグメント領域22に作られている更新後のページイメージ(カレントページのイメージ)に対応する、データセグメント領域21内の元の古いページイメージの物理IDを取得する。そしてコピー部131aは、この取得された物理IDで示される、データセグメント領域21内の古いページイメージを必要とするトランザクションが存在しないことを確認する(ステップS11)。ここでは、シャドウセグメント領域22内のカレントページがPS1であり、PS1に対応するデータセグメント領域21内の古いページ(オリジナルページ)が物理ID=1000のPD1であるものとする。この場合、コピー部131aは、シャドウセグメント領域22内のカレントページPS1のイメージを、データセグメント領域21内の元の位置、つまりページPD1にコピーする(ステップS12)。つまりコピー部131aは、シャドウセグメント領域22内のカレントページPS1のイメージを、データセグメント領域21内の元の位置に書き戻す実更新処理を行う。但し、この実更新処理(コピー処理)は、ページPD1に対応するバッファメモリ30内のページに対して行われる。このときコピー部131aはマップ削除要求記録部として機能して、カレントページPS1のイメージが元のデータセグメント領域21内のページPD1に反映されていることを示す情報を、ローカルメモリ40に確保された、トランザクションTRcに対応した一時マップに格納(記録)する。この情報は、PD1の物理ID=1000とPS1の物理ID=SS1との対を含む。この情報は、チェックポイント処理のトランザクションTRcを終了させる際に、その時点におけるカレントマップから削除される。そこで、この情報をローカルメモリ40内のトランザクションTRcに対応した一時マップに記録することを、マップ削除要求記録と表現する。
上述の実更新処理(コピー処理)が、シャドウセグメント領域22内の幾つかのカレントページ(例えば全てのカレントページ)について繰り返された結果、チェックポイント処理のトランザクションTcを終了させたいものとする。この場合、このトランザクションTRcでの操作を確定するコミット処理が、チェックポイント処理機構13のコミット部132によって開始される。
まず、コミット部132のマップ更新部132aは、チェックポイント処理のトランザクションTRcの開始時のオリジナルマップであるマップ23-1(#1)をマップ23-0(#0)にコピーし、ローカルメモリ40内のトランザクションTRcに対応した一時マップに格納されている情報(マップ削除要求)に従い、物理ID=1000に関するレコード、つまりページPD1の物理ID=1000とページPS1の物理ID=SS1との対を含むレコードを削除する(ステップS13)。このレコード削除のマップ更新操作は、実際には、マップ23-0(#0)及びマップ23-1(#1)が配置されるページに対応するバッファメモリ30内のページ(ブロック)に対して行われる。
次にコミット部132の更新ページフラッシュ部132bは、バッファメモリ30内にデータセグメント領域21に反映されていない更新ページがあれば、その更新ページを全て、データセグメント領域21内の対応するページにフラッシュする。同様にコミット部132のマップフラッシュ部132cは、バッファメモリ30内にマップ23-0に反映されていない当該更新マップのページがあれば、その更新マップを、マップ23-0にフラッシュする。
この段階で、コミット部132のディレクトリ切替部132dは、ディレクトリ24を操作して、マップのオリジナルを、マップ23-1(#1)からマップ23-0(#0)に切り替える(ステップS14)。これによりコミット処理は終了する。
ここで、前述の2つのポイントについて、上記チェックポイント処理を踏まえて再度確認する。第1のポイントは、更新用のカレントページには、シャドウセグメントのみを利用する点である。発明が解決しようとする課題で指摘したように、従来から知られているシャドウページ方式では、新しい空きページを探し、そのページを更新する。そのため、更新によってページのフラグメントが発生しやすい。これに対して本実施形態で適用されるシャドウセグメント方式では、カレントページをシャドウセグメント領域22に配置することと、チェックポイント処理により当該カレントページイメージを元の連続領域内に戻すことにより、更新によって発生するフラグメントを抑制することができる。
次に第2のポイントは、マップ23-I(iは0または1)は、シャドウセグメント領域22内にカレントなページイメージがあるページのみのレコードを持つ点である。発明が解決しようとする課題で指摘したように、シャドウページ方式では、論理物理IDと物理IDとのマッピングのために、ページ数によっては巨大なテーブル(ページテーブル)が必要である。これに対して本実施形態で適用されるシャドウセグメント方式では、更新されたページのみのレコードを持つことで、圧倒的にマップサイズを抑制できる。更にチェックポイント処理により、マップ(マップテーブル)自体が整理され、マップの肥大化を抑制できる。
次に、トランザクションTRでの例えばデータ検索に伴うデータ読み込み処理(参照処理)について、ファイル#2(F2)における通しページ番号10のページを読み込む場合を例に、図7及び図8を参照して説明する。なお、図7はファイルテーブル210内のファイルテーブルレコードFTR2によって示される、ファイル#2(F2)のエクステント構成を示す図、図8はデータ読み込み処理の動作説明図である。図7では、ファイル#2(F2)が、図1とは異なって、3つのエクステント#21,#22及び#23から構成されている場合を前提としている。つまり、ファイル#2(F2)は、図4に示すファイル#i(Fi)であるものとする(i=2)。
まず、読み込み処理機構12の読み込み部121は、ファイルテーブル210中のファイルテーブルレコードFTR2を読み込む。そして読み込み部121は、このファイルテーブルレコードFTR2に含まれている、ファイル#2(F2)のエクステント構成を示すエクステント情報から、通しページ番号10のページが、エクステント#22の5ページ目、即ち物理IDが215のページであることを認識する。
読み込み部121は、トランザクションTRに対応付けてローカルメモリ40内のトランザクションTRに対応した一時マップに格納されている情報(マップ追加要求)に、物理ID=215のページを示す情報が含まれているかにより、このページが、当該トランザクションTRで更新されたページであるかを判定する。もし、物理ID=215のページが、トランザクションTRで更新されたページであるならば、読み込み部121の最新ページ読み込み部121bは、その更新されたページのデータを読み込む。
これに対し、物理ID=215のページが、トランザクションTRで更新されたページでないならば、読み込み部121のマップサーチ部121aは、ディレクトリ24を参照してマップ23-0及び23-1のいずれがオリジナルのマップであるかを確認する(ステップS21)。ここでは、マップ23-0がオリジナルのマップであるものとする。この場合、マップサーチ部121aは、オリジナルマップ23-0をサーチして、物理ID=215を含むレコードが格納されているか、つまり物理ID=215のページに対応するカレントページ(更新済みページ)がシャドウセグメント領域22に存在するかを調べる。もし、物理ID=215を含むレコードが格納されているならば、マップサーチ部121aは当該レコードから物理ID=215と対をなすカレントページの物理IDを取り出して、読み込み部121の最新ページ読み込み部121bに渡す。これにより最新ページ読み込み部121bは、マップサーチ部121aから渡された物理IDで示されるシャドウセグメント領域22内のカレントページのデータを読み込む。但し、図8の例では、マップ23-0には、物理ID=215を含むレコードは格納されていない。
最新ページ読み込み部121bは、物理ID=215のページがトランザクションTRで更新されたページでなく、且つオリジナルマップ23-0に物理ID=215を含むレコードが格納されていない場合、直接物理ID=215のページのデータを読み込む。
ファイル#i(Fi)のサイズが徐々に増加し、持ち合わせているエクステント領域を全て利用したとする。この場合には、エクステントを拡張する必要、つまり物理的な連続領域を確保し、その情報をファイルテーブル210中のファイルテーブルレコードFTRiに反映させる必要がある。
そこで、エクステントの拡張処理について説明する。
まず、本実施形態におけるエクステントの拡張処理を、上述したチェックポイント処理と同様に、ファイル管理システム10で内部的に発生させる独立したトランザクションTReとする。その理由は次の通りである。
エクステントの拡張が必要となったトランザクションが仮にロールバックしたとしても、近々別のトランザクションによってエクステントの拡張が必要になる可能性が非常に高い(局所性の原理)。そのため、エクステントの拡張だけは完了させておいても問題はない。
あるトランザクションによって、エクステント拡張のためにファイルテーブル210の該当ページの排他ロックが獲得された場合、そのトランザクションが終了するまで他のトランザクションはファイルテーブル210の該当ページの参照が待たされることになり、並列性に問題が生じる。
したがって、エクステントの拡張は、あるトランザクションをトリガに行われる処理ではあるが、そのトランザクションのエクステントの拡張に関する原子性は保証されない。ただしこれはデータベース管理の内部で発生するものであり外部的にはエクステント拡張による影響はでない。
以下、ファイル#2(F2)に、データを格納するための十分な領域がなかった場合を例に、エクステントの拡張処理について図9の動作説明図を参照して説明する。なお、前述したようにファイルテーブル210もファイルの1つ(ここではファイル#0)であり、エクステントの拡張処理は基本的に他のファイルと同様に行われる。
今、ファイルテーブル210に格納されている、ファイル#2(F2)に関するレコード(即ちファイルテーブルレコードFTR2)の存在するページが、物理ID=2のページPD02であるものとする。このページPD02を含むエクステントが、エクステントE01であるものとする。
図2には、エクステントの拡張処理を行う機構(エクステント拡張処理機構)が省略されている。しかし、このエクステント拡張処理は、更新処理機構11による更新処理とほぼ同様に実行される。そこで本実施形態では、便宜的に更新処理機構11によりエクステントの拡張処理が行われるものとして説明する。マップサーチ部111aは、シャドウセグメント領域22内から更新用に用いる空きページを探す。マップサーチ部111aは、シャドウセグメント領域22内からページPD02の更新用に用いる空きページを探し、その空きページに当該ページPD02のイメージをコピーする(ステップS31)。ここではページPD02のイメージは、図9に示すように、シャドウセグメント領域22内のページPS1にコピーされたものとする。更新部112は、エクステント拡張サイズとして指定されたサイズ分の連続領域を、ストレージ装置20のデータセグメント領域21上に確保する(ステップS32)。更新部112は、ステップS32で確保された領域が、ファイル#2(F2)の拡張されたエクステント#22として扱われるように、ページPS1上で、ファイル#2(F2)のファイルテーブルレコードFTR2を更新する(ステップS33)。ここでは、ファイルテーブルレコードFTR2の第2エクステントカラムに、ステップS32で確保された領域(エクステント#22)のエクステント情報が追加される。
次に上述のエクステント拡張処理のトランザクションTReを終了させるためのコミット処理について説明する。まず、このトランザクションTReの開始時のオリジナルマップはマップ23-0(#0)であるものとする。この場合、コミット部113は、マップ23-0(#0)をマップ23-1(#1)にコピーし、物理ID=2に関するレコード、つまりページPD02の物理ID=2とページPS1の物理IDとの対を含むレコードを追加(記録)する(ステップS34)。そしてコミット部113は、マップのオリジナルを、マップ23-0(#0)からマップ23-1(#1)に切り替える(ステップS35)。これによりコミット処理は終了する。
既に詳述したように、本実施形態で適用されるシャドウセグメント方式は、マップサイズを抑制すると共に、更新によって発生するフラグメントを抑制する点で非常に効果がある。しかし、これだけでは、一括登録など大量の登録が行われた場合のチェックポイント処理が非常に重くなる。例えば、シャドウセグメント領域22の全てのページがカレントページであるような状態でのチェックポイント処理では、シャドウセグメント領域22のサイズ分のページコピーが必要となる。そこで本実施形態では、チェックポイント処理の負荷軽減のために、以下に述べる第1及び第2の負荷軽減手法が適用される。
まず、第1の負荷軽減手法について、図10の動作説明図を参照して説明する。
第1の負荷軽減手法の特徴は、エクステント内の使用されていないページへのデータ追加では、シャドウセグメント領域22内にコピーをとらず、割り当てられているページの位置に直接データを追加する点にある。このデータ追加に失敗した場合、ファイルテーブル210内の対応するファイルテーブルレコードに含まれている使用されている最大の有効ページ番号(使用済みページ位置)を更新しないことでリカバリを実現する。
今、ファイル#1(F1)が、図10に示すように、ページ数が4の2つのエクステント#1及び#2から構成され、エクステント#2の使用済みページ位置が5であるものとする。つまりエクステント#2内の2ページ目以降にはデータはないものとする。このファイル#1(F1)のエクステント構成は、ファイルテーブル210に格納されているファイルテーブルレコードFTR1中のエクステント情報によって示される。したがって、エクステント#2の使用済みページ位置が5であることは、このファイルテーブルレコードFTR1中のエクステント情報によって確定されている。
このような状態で、あるトランザクションTRの中で、ファイル#1(F1)へのデータ追加が発生し、使用済みページ位置の次のページ位置である6、即ちエクステント#2の2ページ目への書き込みが必要になったとする。エクステント#2の開始物理IDは211であることから、当該エクステント#2の2ページ目の物理IDは212である。このとき、エクステント#2の2ページ目、つまり物理ID=212のページには、有効なデータは全く書かれていない。このことは、上述したように、ファイルテーブルレコードFTR1のエクステント情報(エクステント#2に関するエクステント情報)の示す「使用済みページ位置」が5であることによって保証される。
このような場合、更新部112は、シャドウセグメント領域22ではなく、データセグメント領域21内の物理ID=212のページ位置へ直接データの書き込みを行う(ステップS41)。やがて、トランザクションTRを終了させるために、アプリケーションからコミット処理が要求されて、正常に書き込みが完了したものとする。この場合、コミット部113は、ファイルテーブルレコードFTR1に含まれている、エクステント#2に関するエクステント情報の示す「使用済みページ位置」を、5から6に書き換える(ステップS42)。
これに対し、物理ID=212への書き込みに失敗した場合には、コミット部113は、ファイルテーブルレコードFTR1の「使用済みページ位置」の情報を書き換えずに5のままにする。これにより、リカバリが完了する。
このように第1の負荷軽減手法によれば、エクステント内の使用されていないページへのデータ追加では、シャドウセグメント領域22を使わないことによって、チェックポイント処理を不要とし、加えて検索時のマップ参照も不要とすることができるという、2点の負荷軽減が実現できる。
次に、第2の負荷軽減手法について、図11の動作説明図を参照して説明する。
第2の負荷軽減手法の特徴は、チェックポイント処理によるデータセグメント領域21への書き戻しが発生する前に、同一ページが更に更新された場合には、チェックポイント処理で書き戻すべきページは最新(最終)ページのイメージのみとする点にある。
チェックポイント処理が発生する前に、複数のトランザクションによって、同一ページの更新が複数回行われた場合、シャドウセグメント領域22内に同一ページの過去のバージョンが順次保持される。
今、図11に示すように、ファイル#1(F1)の先頭エクステント#1におけるページPD12の更新が3回順に行われたものとする。この場合、図11に示すように、まずシャドウセグメント領域22内の例えばページPS1にページPD12の最初の更新イメージが保持される。次に、シャドウセグメント領域22内の例えばページPS3にページPD12の次の更新イメージが保持される。そして、シャドウセグメント領域22内の例えばページPS4にページPD12の最新の更新イメージが保持される。
このような状態で、第2の負荷軽減手法を適用するチェックポイント処理が発生したものとする。このチェックポイント処理では、旧バージョンのページイメージを参照しているトランザクションが存在しなくなった後に、データセグメント領域21内の元のエクステント領域に対して、最新版のページイメージが書き戻される。図11の例では、データセグメント領域21内のページPD12に関し、シャドウセグメント領域22内に、複数の旧バージョンのページイメージが保存されている。しかし、旧バージョンを参照しているトランザクションが存在しなくなった以上、必要なデータはシャドウセグメント領域22内のページPS4に保持されている最新ページイメージだけである。そこで、チェックポイント処理機構13は、ページPS4に保持されている最新ページイメージのみの書き戻しを行う。旧バージョンのページイメージを保存していたページは、空きページとして管理される。
上述の説明から明らかなように、本実施形態で適用されるシャドウセグメント方式は、従来から知られているシャドウページ方式に対して以下に述べる相違点と、シャドウページ方では得られない効果とを有する。
(1)シャドウページ方式におけるページテーブルに相当する、マップ(マップテーブル)のサイズが、データベースのサイズに依存しない。これに対して、シャドウページ方式は、データベースのサイズに応じてページテーブルのサイズが大きくなるという問題を有する。つまり本実施形態では、更新ページをシャドウセグメント領域22と呼ぶ更新データの一時格納領域に配置し、ページ変換(物理IDの変換)を、データベース全体に対するテーブルではなくて、更新ページ集合に対する連想記憶により行う、シャドウセグメント方式を適用している。このため、シャドウセグメント方式では、マップテーブルは、更新量に応じたサイズで済む。特にチェックポイント処理が完了した時点では、マップテーブル内のレコード数はゼロになることから、マップサーチでのページ変換のオーバーヘッドがなくなるというメリットがある。
(2)ファイルの断片化が防止できる。即ち本実施形態においては、データ更新において一時的にファイルの断片化が生じるが、チェックポイント処理によりオリジナルのエクステントの連続性が復元される。つまり、エクステント方式によるファイル管理方式をシャドウページ方式と組み合わせ、チェックポイント処理により、シャドウセグメント領域22からデータセグメント領域(ファイル領域)21への実更新を行うことで、ファイルの断片化を防止可能としている。
(3)コミットの応答時間を短くできる。一般に、シャドウページ方式におけるコミット時のコストは、更新を含む全ページをコミット時にバッファメモリからディスクに書かないといけないというデータ量の問題と、ファイルの断片化によるディスクのランダム書き込みのコストが高いことの2点である。一方、シャドウセグメント方式では、書き込み量の点はシャドウページ方式と同等である。しかし、シャドウセグメント方式では、シャドウセグメント領域22を更新量に対して十分に大きくすることにより、当該シャドウセグメント領域22内の新規ページの割り当てをサイクリックに行うことができる。これによりシャドウセグメント方式では、ロギング方式に近いシーケンシャル書き込みの性能を得ることができる。
(4)オリジナルへの書き戻し(チェックポイント処理)中に更新が可能である。シャドウセグメント方式は、シャドウページ方式とサイドファイル方式を組み合わせた方式と考えることができる。このサイドファイル方式は、オリジナルファイルへの書き戻し中に更新ができないとう欠点がある。しかし本実施形態では、チェックポイント処理をファイル管理システム10内で発生する独立したトランザクション(内部トランザクション)TRcとすることで、この欠点を克服している。つまり、本実施形態では、チェックポイント処理のトランザクションTRcを通常のトランザクション同様、グループコミットによって一括処理可能とし、チェックポイント処理を通常のトランザクション処理にピギーバックさせて部分的に実行することで、上記の欠点を克服している。
前述したように、シャドウセグメント領域22の全てのページがカレントページであるような状態でのチェックポイント処理(実更新処理)では、当該チェックポイント処理の負荷が大きくなる。そこで、チェックポイント処理を、一定数のページを上限に複数回に分けて実行すると良い。このように、チェックポイント処理を一貫性のある単位ではなく部分的に実行することで、チェックポイント処理の負荷を平準化することができる。
次に、本実施形態におけるオンラインバックアップ動作について、第1及び第2のオンラインバックアップに分けて順に説明する。なお、第1のオンラインバックアップとは、データセグメント領域21のデータのみをオンラインでバックアップすることをいい、第2のオンラインバックアップとは、シャドウセグメント領域22内の実更新できなかったページを含めてオンラインでバックアップすることをいう。
まず、第1のオンラインバックアップについて、図12の動作説明図を参照して説明する。ここでは、オンラインバックアップに際し、チェックポイント処理機構13により図6に示されるようなチェックポイント処理(実更新処理)が実行される。この「チェックポイント処理」(実更新処理)は、前述した内部トランザクションTRcにより、通常のトランザクションでの更新処理と並列に実行することが可能である。
今、チェックポイント処理により、シャドウセグメント領域22にある全ての更新ページ(カレントページ)のデータの、データセグメント領域21への書き戻し(実更新)が完了したものとする。この場合、ファイル管理システム10内のバックアップ機構(図示せず)は、図12に示すように、データセグメント領域(オリジナル領域)21のみのバックアップを行う(ステップS51)。このバックアップ中にデータセグメント領域21に対して行われる更新は、その更新が必要なページのイメージのコピーを利用して、シャドウセグメント領域22内の空きページに対して行われる。ここでは、図12に示すように、データセグメント領域21に格納されているファイル#2(F2)内のページPDxへの更新が、シャドウセグメント領域22内のページPSyに対して行われるものとする(ステップS52)。このように、シャドウセグメント領域22に更新データが書かれるため、バックアップ中のデータセグメント領域21のデータの一貫性は保証される。
次に、第2のオンラインバックアップについて、図13の動作説明図を参照して説明する。
まず、オンラインバックアップに際して実行されるチェックポイント処理(実更新処理)で、シャドウセグメント領域22にある一部のページの実更新(書き戻し)ができなかったものとする。このようなページは、チェックポイント処理の内部トランザクションTRcが、通常のトランザクションと並列に実行される場合に発生する可能性がある。つまり、シャドウセグメント領域22内の更新ページの書き戻し先となる、データセグメント領域21内のページを必要としているトランザクションが存在する場合に、当該更新ページの実更新(書き戻し)ができなくなる。
図13の例では、シャドウセグメント領域22内の実更新ができなかったページとして、ページPS1,PS8,PSt及びPSuの4つが示されている。ファイル管理システム10内のバックアップ機構は、シャドウセグメント領域22内に実更新ができなかったページが存在する場合には、データセグメント領域(オリジナル領域)のバックアップに加えて、シャドウセグメント領域22内の実更新ができなかったカレントページ、つまりページPS1,PS8,PSt及びPSuのバックアップを行う。またバックアップ機構は、マップ23-0及び23-1のうちのオリジナルマップのバックアップも行う。図13の例では、マップ23-0がオリジナルマップであることから、当該マップ23-0がバックアップされる。明らかなように、マップ23-0には、ページPS1,PS8,PSt及びPSuの物理IDを含むレコードのみが格納されている。このレコードは、ページPS1,PS8,PSt及びPSuのイメージが書き戻されるべき、データセグメント領域21内の元のページ(オリジナルページ)の物理IDを含む。
バックアップ中にデータセグメント領域21に対して行われる更新と、シャドウセグメント領域22に対して行われる更新は、当該シャドウセグメント領域22の新しいページに書かれる。そのため、データセグメント領域21と、実更新ができなかったシャドウセグメント領域22内のページとの組み合わせによって実現される一貫性は保証されている。
上述したように、シャドウセグメント領域22内に実更新ができなかったページが存在する場合、データセグメント領域21のバックアップに加えて、実更新ができなかったページと、オリジナルマップとがバックアップされる。これにより、ストレージ装置20等の障害が発生したとしても、バックアップデータに基づいてバックアップ時点の確定された状態に復旧した後に、その時点において実更新ができなかったページを、オリジナルマップに格納されている対応するレコードに従ってデータセグメント領域21内の元のページ位置に正しく書き戻すことができる。ここで、オンラインバックアップに際して実行されるチェックポイント処理で、実更新(書き戻し)ができなかった更新ページが発生した場合、その実更新ができなかったページ(カレントページ)と元のページとに関する情報を、ローカルメモリ40に保持しておき、その保持情報もバックアップすると良い。この場合、上記の保持情報に基づいて、更新ができなかったページ(カレントページ)と元のページとを直接特定できる。このため復旧時には、オリジナルマップをサーチすることなく、速やかに実更新を行うことができる。
[変形例]
既に述べているように、上記実施形態の特徴は、シャドウページ方式をベースとするシャドウセグメント方式により、データの更新が、データセグメント領域21内の元のページ(オリジナルページ)とは別の、シャドウセグメント領域22内のページ(カレントページ)に対して行われる構成を適用する点にある。よって本実施形態においては、トランザクション処理中であっても更新前の状態を一貫性を保ったまま参照することが可能である。しかし本実施形態では、1対のマップ(マップテーブル)23-0及び23-1を原子的に切り替えることにより、トランザクション性を実現している。このため、オリジナルページを参照しているトランザクションが存在する場合に次のトランザクションを開始することができなくなる。この問題について以下に説明する。
今、更新トランザクションTR1がマップ23-0(#0)をオリジナルマップとして用いて処理を開始し、マップ23-1(#1)をカレントとしたものとする。参照トランザクションTR2はオリジナルのマップ#0を参照し一貫性のある問い合わせを実行する。その後、更新トランザクションTR1が完了したものとする。更に、この状態で、更新トランザクションTR3がマップ#1をオリジナルマップとして用いて処理を開始して、マップ#0をカレントとしようとするものとする。しかし、参照トランザクションTR2がマップ#0を参照しているので、更新トランザクションTR3は処理を開始することができない。この問題は、1対のページテーブルを原子的に切り替えることにより、トランザクション性を実現している従来のシャドウページ方式でも同様である。
この種の問題を解決する手段として、多版同時実行制御(multi-version concurrency control:MVCC)が知られている。多版型同時実行制御機能は、以下の4つの特徴
(a)検索(参照)ではロックを取得しない
(b)別のトランザクションが更新中であっても、検索(参照)要求では「待ち」は発生しない
(c)別のトランザクションが更新中に検索(参照)要求をした場合、取得できるのは、検索開始直前までにコミットされたデータイメージである
(d)この旧バージョンのデータイメージは、検索による結果セット(Result Set)クローズされるまで、つまり検索結果の一部のデータをサーバ上に保持することが不要となるまで保持される
を持つ。
一方、ログ方式では、ビフォアイメージを多数の世代保持するという手法によりトランザクション性が実現されている。しかし、この手法では、オリジナル領域の他に、アフターイメージとビフォアイメージの両方を持たないといけないため、ディスク使用量のコストが高くなる。
上記実施形態の変形例の特徴は、多版型同時実行制御をシャドウセグメント方式に適用可能とした点にある。そのため、この変形例では、(1)コミット時刻、(2)MVCCキューという2つの概念が適用される。以下、この2つの概念について説明する。
(1)コミット時刻
上記(c)の特徴に相当するトランザクション分離レベル(MVCCによる)READ_COMMITTEDを実現するためには、「検索を行った時点」で前回コミットが完了しているデータイメージが必要になる。「検索を行った時点」とは、検索を行う直前にコミットが完了した時点を意味する。この「検索を行った時点」を特定するための概念として、「コミット時刻」が用意される。本変形例では、コミット時刻には、システムが初めて起動した時点から行われてきたコミットの回数が用いられる。つまりコミット時刻は単調増加する。
(2)MVCCキュー
単純なシャドウページ方式では、コミットが完了した時点で、更新前のオリジナルページは破棄して構わない。しかし、この変形例では、過去のバージョンの参照を可能にするために、他のトランザクションが参照しているページを破棄(再利用)しない構成を適用する。この構成を適用するには、他のトランザクションが参照しているページかどうかの判断基準とするための情報が必要となる。この情報が、マップ23-I(i=1,2)に対応する世代の異なるローカルマップであり、MVCCキューは、当該ローカルマップを積むのに用いられる。このMVCCキューは永続的な保存は必要ないので、ローカルメモリ40上に構築することができる。
図14は、ローカルメモリ40に保持されるMVCCキュー41の一例を示す。図14の例では、MVCCキュー41には、複数世代のローカルマップ410-1,410-2…が積まれている。各ローカルマップ410-j(j=1,2…)には、タイムスタンプとしてのコミット時刻Tjの情報が付加されている。コミット時刻Tjは、対応するトランザクションTRjのコミット時刻、つまりシステムが最初に起動してからトランザクションTRjがコミットされるまでのコミット回数を表す。ここでは、T1<T2である。
このように本変形例では、MVCCキュー41の導入により、マップ23-0及び23-1とは別に、実行中のトランザクションにより利用される世代の異なるマップ(ローカルマップ)410-iを動的に持ち、これらのマップから参照されているオリジナルページは再利用しない構成を適用する。
この構成は、前述したログとビフォアイメージによるトランザクション性の実現と比較し、
アフターイメージのみで実現するためデータのコピー回数が少ない
ビフォアイメージ領域が不要なのでディスク使用量が少ない
トランザクション性実現のためのマップ参照とMVCCのためのマップ参照は基本的には同様の処理であり、実現のためのコストが少ない
という長所を有する。
次に、本変形例の動作について、まずページ内データの更新が行われる場合を例に図5を援用して説明する。
前述したように、図5の例では、トランザクションTRで更新されるデータがファイル#2(F2)で、更新の必要なページがエクステント#22の2ページ目のページPD1である。以下では、説明の都合上、トランザクションTRがトランザクションTRjであるものとする。ページPD1の物理IDは1000である。シャドウセグメント方式では、このページPD1に対する更新が、当該ページPD1のイメージのコピーを利用して、シャドウセグメント領域22内の空きのページに対して行われる。図5の例では、この空きのページがページPS1であり、その物理ID=SS1である。
この場合、トランザクションTRjのコミット処理では、更新処理機構11のコミット部113によって当該トランザクションTRの開始時点のオリジナルマップ23-0がマップ23-1にコピーされ、当該マップ23-1に物理ID=1000と物理ID=SS1の対を含むレコードが追加される。そしてマップのオリジナルが、マップ23-0(#0)からマップ23-1(#1)に切り替えられる。本変形例では、この他に、コミット時点でオリジナルに切り替えられるマップ(ここではマップ23-1)のコピーが、コミット部113によって作成されて最新のローカルマップ410-jとしてMVCCキュー41に積まれる(追加される)。このローカルマップ410-jには、トランザクションTRjのコミット時点のコミット時刻Tjがタイムスタンプとして付加される。
次に、トランザクションTRkでのデータ検索に伴うデータ読み込み処理(参照処理)について、上記実施形態と同様に、ファイル#2(F2)における通しページ番号10のページを読み込む場合を例に、図7及び図8を援用して説明する。
まず、読み込み処理機構12の読み込み部121は、トランザクションTRkでのデータ検索要求(参照要求)時点のコミット時刻をトランザクション開始時刻とする。
次に読み込み部121は、ファイルテーブル210中のファイルテーブルレコードFTR2を読み込む。そして読み込み部121は、このファイルテーブルレコードFTR2の示すファイル#2のエクステント構成から、通しページ番号10のページが、エクステント#22の5ページ目、即ち物理IDが215のページであることを認識する。
読み込み部121は、トランザクションTRkに対応付けてローカルメモリ40に格納されている情報(マップ追加要求)から、物理ID=215のページが、当該トランザクションTRk自身で更新されたページであるかを判定する。もし、物理ID=215のページが、トランザクションTRkで更新されたページであるならば、読み込み部121の最新ページ読み込み部121bは、その更新されたページのデータを読み込む。
これに対し、物理ID=215のページが、トランザクションTRkで更新されたページでないならば、読み込み部121のマップサーチ部121aはMVCCキュー41を参照して、上記トランザクション開始時刻Tkと一致するコミット時刻を持つローカルマップを探す。このように、本変形例における1つのポイントは、トランザクション開始時刻をキーにMVCCキュー41を検索することにある。
ここでは、トランザクション開始時刻Tkと一致するコミット時刻を持つローカルマップとして、ローカルマップ410-2が見つけられたものとする。するとマップサーチ部121aは、このローカルマップ410-2をサーチして、物理ID=215を含むレコードが格納されているかを調べる。もし、物理ID=215を含むレコードが格納されているならば、マップサーチ部121aは当該レコードから物理ID=215と対をなすカレントページの物理IDを取り出して、読み込み部121の最新ページ読み込み部121bに渡す。これにより最新ページ読み込み部121bは、マップサーチ部121aから渡された物理IDで示されるシャドウセグメント領域22内のカレントページのデータを読み込む。
これに対し、ローカルマップ410-2に、物理ID=215を含むレコードが格納されていないならば、マップサーチ部121aは、その時点におけるオリジナルマップ23-0をサーチして、物理ID=215を含むレコードが格納されているかを調べる。もし、物理ID=215を含むレコードがオリジナルマップ23-0に格納されているならば、マップサーチ部121aは当該レコードから物理ID=215と対をなすカレントページの物理IDを取り出して、読み込み部121の最新ページ読み込み部121bに渡す。これにより最新ページ読み込み部121bは、マップサーチ部121aから渡された物理IDで示されるシャドウセグメント領域22内のカレントページのデータを読み込む。
一方、物理ID=215を含むレコードがオリジナルマップ23-0にも格納されていないならば、最新ページ読み込み部121bは、直接物理ID=215のページのデータを読み込む。
次に、MVCCキュー41の解放処理について説明する。この処理も、上記実施形態における実更新処理と同様にチェックポイント処理と呼ぶ。MVCCキュー41の解放は、例えばチェックポイント処理機構13の図示せぬキュー解放部によって定期的に行われる。
キュー解放部はまず、現在実行中のトランザクションの開始時刻(トランザクション開始時刻)の中から、最も古いトランザクション開始時刻Tを取得する。次にキュー解放部は、トランザクション開始時刻Tを、MVCCキュー41に積まれているローカルマップ410-1,410-2…のタイムスタンプ、つまりコミット時刻T1,T2…と比較する。そして、トランザクション開始時刻Tよりも古いタイムスタンプ(コミット時刻)のローカルマップを全て解放する。
さて、ローカルマップの解放に伴って、シャドウセグメント領域22の空きページ管理とオリジナルマップの圧縮が必要となる。この処理は、ファイル管理システム10における内部トランザクションとして実行される。システムにおいて更新が頻繁に行われるときには、グループコミットにより一括処理することにより、負荷を軽減することができる。
上述したシャドウセグメント方式でMVCC機能を実現する場合、実更新にも影響を与える。実更新はMVCCキュー41に積まれているローカルマップにより参照されないページに対してのみ行うことができる。換言すれば、MVCCキュー41に積まれているローカルマップにより示されるページは、現在実行中のトランザクションによって参照される可能性があるため、再利用の対象外とされる。
なお、本発明は、上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。
本発明の一実施形態に係るトランザクション管理機能を備えたファイルシステムの構成を示すブロック図。 図1中のファイル管理システム10の構成を示すブロック図。 図1中のファイルテーブル210に保持されるファイル#i(Fi)に関するレコードFTRiのデータ構造例を示す図。 ファイル#i(Fi)とエクステントとの関係を示す図。 同実施形態におけるページ内データの更新を説明するための図。 同実施形態におけるチェックポイント処理を説明するための図。 ファイルテーブル210内のファイルテーブルレコードFTR2によって示される、ファイル#2(F2)のエクステント構成を示す図。 同実施形態におけるデータ読み込み処理を説明するための図。 同実施形態におけるエクステントの拡張処理を説明するための図。 同実施形態で適用される第1の負荷軽減手法を説明するための図。 同実施形態で適用される第2の負荷軽減手法を説明するための図。 同実施形態で適用される第1のオンラインバックアップを説明するための図。 同実施形態で適用される第2のオンラインバックアップを説明するための図。 同実施形態の変形例で適用されるMVCC(多版同時実行制御)キュー41におけるデータ構造例を示す図。
符号の説明
10…ファイル管理システム、11…更新処理機構、12…読み込み処理機構、13…チェックポイント処理機構、14…ファイル管理制御機構、20…ストレージ装置、21…データセグメント領域(ファイル領域)、22…シャドウセグメント領域(一時書き込み領域)、23-0,23-1…マップ(マップテーブル)、24…ディレクトリ、30…バッファメモリ、40…ローカルメモリ、41…MVCC(多版同時実行制御)キュー、111,121…読み込み部、112…更新部、113,132…コミット部、131…マッピング要求部、210…ファイルテーブル。

Claims (13)

  1. トランザクション管理機能を有するファイルシステムにおいて、
    ファイルによって占有されるファイル領域と、ファイルのページ単位の更新データを一時的に保持する一時書き込み領域とが確保される記憶領域を有するストレージ装置と、
    前記ストレージ装置の前記記憶領域に配置される、前記一時書き込み領域内の更新が行われた有効ページのリストを記録するための1対のマップテーブルと、
    前記ファイル領域に格納されるファイルを管理するファイル管理手段と、
    前記ファイル管理手段によって管理される、前記ファイル領域に格納されているファイルのページ更新を、前記一時書き込み領域から取得される空きページに更新データを書き込むことで実行する更新処理手段と、
    トランザクションのコミット時毎に、その時点における前記一時書き込み領域内の有効ページのリストを前記1対のマップテーブルに交互に書き込むコミット手段と、
    前記一時書き込み領域内の有効ページの更新データを前記ファイル領域の元のページ位置に書き戻し、当該書き戻しが行われた有効ページを開放する実更新処理を行う実更新手段と
    を具備することを特徴とするトランザクション管理機能を有するファイルシステム。
  2. 前記ファイル管理手段は、前記ファイル領域に格納されるファイルテーブルであって、前記ファイル領域に格納されているファイルをエクステント単位で管理し、前記ファイルを構成するエクステントを示すエクステント情報を1つのレコードとして保持するファイルテーブルを含み、当該ファイルテーブル自身を1つのファイルとしてトランザクション管理の対象とすることを特徴とする請求項1記載のトランザクション管理機能を有するファイルシステム。
  3. 前記更新処理手段は、前記ページ更新が、前記ファイルテーブルによって管理されているエクステント内の使用されていないページへのデータ追加である場合、当該エクステント内の使用されていないページに直接データを書き込むことを特徴とする請求項2記載のトランザクション管理機能を有するファイルシステム。
  4. 前記実更新手段は、前記実更新処理の確定操作を、前記1対のマップテーブルの一方に対する更新処理で実行することを特徴とする請求項1記載のトランザクション管理機能を有するファイルシステム。
  5. 前記実更新手段は、前記実更新処理を複数回に分けて実行することを特徴とする請求項4記載のトランザクション管理機能を有するファイルシステム。
  6. 前記実更新手段は、前記実更新処理の前に、前記ファイル領域内の同一ページに対する更新が複数回発生して、その都度前記一時書き込み領域から取得される空きページへの更新データの書き込みが前記更新処理手段によって行われた場合、前記同一ページに対する複数回の更新のうち最新の更新で更新データが書き込まれたページのみ、当該ページから前記ファイル領域の元のページ位置への更新データの書き戻しを行うことを特徴とする請求項4記載のトランザクション管理機能を有するファイルシステム。
  7. 前記ストレージ装置の記憶領域のデータをオンラインでバックアップするバックアップ手段であって、前記実更新手段によって、前記一時記憶領域内の全ての有効ページから前記ファイル領域の元のページ位置への更新データの書き戻しが完了している場合には、前記ファイル領域のデータのみをバックアップするバックアップ手段を更に具備することを特徴とする請求項4記載のトランザクション管理機能を有するファイルシステム。
  8. 前記ストレージ装置の記憶領域のデータをオンラインでバックアップするバックアップ手段であって、バックアップ開始時に、前記一時記憶領域内に、前記実更新手段による更新データの書き戻しが完了していない有効ページが存在する場合には、前記ファイル領域のデータと、当該書き戻しが完了していない有効ページのデータと、前記一対のマップテーブルのうち、最も最近に確定されたマップテーブルとをバックアップすることを特徴とする請求項4記載のトランザクション管理機能を有するファイルシステム。
  9. 前記1対のマップテーブルのうちトランザクションのコミット時に確定されたマップテーブルが反映されたローカルマップを、当該コミット時の時刻を表すタイムスタンプを付して積むための多版同時実行制御キューと、
    任意のトランザクションにおいて要求されたページのデータを読み込む読み込み手段であって、前記要求されたページが前記任意のトランザクションで更新されていない場合、当該任意のトランザクションの開始時刻に対応するタイムスタンプが付されたローカルマップを前記多版同時実行制御キューから検索し、当該ローカルマップに従い、前記要求されたページのデータを読み込む読み込み手段と
    を更に具備することを特徴とする請求項1記載のトランザクション管理機能を有するファイルシステム。
  10. 前記読み込み手段は、前記要求されたページが前記任意のトランザクションで更新されている場合には、当該更新されたページのデータを読み込み、前記多版同時実行制御キューから検索されたローカルマップによって前記要求されたページの更新された有効ページの存在が示されていない場合には、前記1対のマップテーブルのうち、その時点において確定されているマップテーブルに従って当該有効ページのデータを読み込むことを特徴とする請求項9記載のトランザクション管理機能を有するファイルシステム。
  11. 前記多版同時実行制御キューに積まれているローカルマップに付されたタイムスタンプに基づき、現在実行中のトランザクションの開始時刻のうち最も古い開始時刻より古いタイムスタンプが付されたローカルマップを前記多版同時実行制御キューから解放するキュー解放手段を更に具備することを特徴とする請求項9記載のトランザクション管理機能を有するファイルシステム。
  12. 前記更新処理手段は、前記一時書き込み領域内の新規ページの割り当てをサイクリックに行うことを特徴とする請求項1記載のトランザクション管理機能を有するファイルシステム。
  13. トランザクション管理機能を有するファイルシステムに適用されるファイル管理方法であって、
    ストレージ装置の記憶領域内に、ファイルによって占有されるファイル領域と、ファイルのページ単位の更新データを一時的に保持する一時書き込み領域とを確保するステップと、
    前記ファイル領域に格納されているファイルのページ更新が要求された場合、前記一時書き込み領域から空きページを取得するステップと、
    前記要求されたページ更新を、前記一時書き込み領域から取得された空きページに更新データを書き込むことで実行するステップと、
    トランザクションのコミット時に、前記一時書き込み領域内の更新が行われた有効ページのリストを記録するための1対のマップテーブルのうち、前回のトランザクションのコミット時にリストの記録に用いられなかったマップテーブルに、前回のトランザクションのコミット時にリストの記録に用いられたマップテーブルをコピーするステップと、
    前記1対のマップテーブルのうちの前記コピーされたマップテーブルに、現在の前記一時書き込み領域内の有効ページのリストを記録するステップと
    前記一時書き込み領域内の有効ページの更新データを前記ファイル領域の元のページ位置に書き戻し、当該書き戻しが行われた有効ページを開放する実更新処理を行うステップと
    を具備することを特徴とするファイル管理方法。
JP2004289029A 2004-09-30 2004-09-30 ファイル管理機能を備えたファイルシステム及びファイル管理方法 Expired - Fee Related JP4104586B2 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
JP2004289029A JP4104586B2 (ja) 2004-09-30 2004-09-30 ファイル管理機能を備えたファイルシステム及びファイル管理方法
CNB2005100646024A CN100412862C (zh) 2004-09-30 2005-04-15 具备文件管理功能的文件系统及文件管理方法
US11/144,637 US7266669B2 (en) 2004-09-30 2005-06-06 File system with file management function and file management method

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
JP2004289029A JP4104586B2 (ja) 2004-09-30 2004-09-30 ファイル管理機能を備えたファイルシステム及びファイル管理方法

Publications (2)

Publication Number Publication Date
JP2006106868A true JP2006106868A (ja) 2006-04-20
JP4104586B2 JP4104586B2 (ja) 2008-06-18

Family

ID=36100569

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2004289029A Expired - Fee Related JP4104586B2 (ja) 2004-09-30 2004-09-30 ファイル管理機能を備えたファイルシステム及びファイル管理方法

Country Status (3)

Country Link
US (1) US7266669B2 (ja)
JP (1) JP4104586B2 (ja)
CN (1) CN100412862C (ja)

Cited By (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009069436A1 (ja) * 2007-11-28 2009-06-04 Kyoto Software Research, Inc. データ格納システムおよびデータ格納プログラム
JP2012008997A (ja) * 2010-05-26 2012-01-12 Sanyo Electric Co Ltd ファイルデータ保護機能を備えた電子装置及びファイル保護方法
JP2012155705A (ja) * 2011-01-27 2012-08-16 Micron Technology Inc トランザクションメモリ
KR20120104302A (ko) * 2009-12-11 2012-09-20 마이크로소프트 코포레이션 순서 의존성 없는 일관성
JP2013508885A (ja) * 2009-10-26 2013-03-07 ウェアラブル・インコーポレイテッド ブロックアクセスデバイスとグラフアクセスデバイス間で共有されたメモリプールへの同時アクセス
JP2013528883A (ja) * 2010-06-15 2013-07-11 マイクロソフト コーポレーション ファイルシステムのチェックポイント
US8621163B2 (en) 2009-09-17 2013-12-31 Kabushiki Kaisha Toshiba Management apparatus for improved database registration and update
WO2014097475A1 (ja) * 2012-12-21 2014-06-26 株式会社Murakumo 情報処理方法、情報処理装置、及び、プログラム
CN104166606A (zh) * 2014-08-29 2014-11-26 华为技术有限公司 文件备份方法和主存储设备
US8984233B2 (en) 2010-06-17 2015-03-17 Microsoft Corporation Error detection for files
US9563487B2 (en) 2011-08-11 2017-02-07 Microsoft Technology Licensing, Llc. Runtime system
JP2018527653A (ja) * 2015-07-10 2018-09-20 アビニシオ テクノロジー エルエルシー 分散型データベースシステムを用いるネットワーク内でデータベースアクセス制御を提供する方法及びアーキテクチャ
US10635504B2 (en) 2014-10-16 2020-04-28 Microsoft Technology Licensing, Llc API versioning independent of product releases
JP2021533495A (ja) * 2018-11-30 2021-12-02 テンセント・テクノロジー・(シェンジェン)・カンパニー・リミテッド データリカバリー方法、装置、サーバ及びコンピュータ・プログラム
US11372883B2 (en) 2016-10-12 2022-06-28 Fujitsu Limited Apparatus for calculating size of processing unit, method for calculating size of processing unit, and non-transitory computer-readable storage medium for storing program
WO2022224451A1 (ja) * 2021-04-23 2022-10-27 株式会社東芝 管理装置、データベースシステム、管理方法およびプログラム

Families Citing this family (27)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20070005552A1 (en) * 2005-07-01 2007-01-04 Udo Klein Methods and systems for reducing transient memory consumption in an object-oriented system
US7533135B2 (en) * 2005-07-01 2009-05-12 Sap Aktiengesellschaft Methods and systems for reducing database accesses in an object-oriented system
US20090100290A1 (en) * 2005-08-22 2009-04-16 Matsushita Electric Industrial Co., Ltd. Memory controller, nonvolatile memory device, nonvolatile memory system, and data writing method
US20070130231A1 (en) * 2005-12-06 2007-06-07 Brown Douglas P Closed-loop supportability architecture
US8615643B2 (en) * 2006-12-05 2013-12-24 Microsoft Corporation Operational efficiency of virtual TLBs
US8402201B2 (en) 2006-12-06 2013-03-19 Fusion-Io, Inc. Apparatus, system, and method for storage space recovery in solid-state storage
EP2153340A4 (en) * 2007-05-08 2015-10-21 Riverbed Technology Inc HYBRID SEGMENT ORIENTED FILE SERVER, AND WAN ACCELERATOR
US7930497B2 (en) * 2008-01-10 2011-04-19 International Business Machines Corporation Using multiple sidefiles to buffer writes to primary storage volumes to transfer to corresponding secondary storage volumes in a mirror relationship
US8738573B2 (en) * 2008-05-23 2014-05-27 Microsoft Corporation Optimistic versioning concurrency scheme for database streams
CN107247565B (zh) * 2009-03-18 2020-06-09 株式会社日立制作所 存储控制装置以及虚拟卷的控制方法
KR20100133710A (ko) * 2009-06-12 2010-12-22 삼성전자주식회사 메모리 시스템 및 그것의 코드 데이터 로딩 방법
TWI453747B (zh) * 2009-09-02 2014-09-21 Silicon Motion Inc 用來管理一快閃記憶體的複數個區塊之方法以及相關之記憶裝置及其控制器
US8601222B2 (en) * 2010-05-13 2013-12-03 Fusion-Io, Inc. Apparatus, system, and method for conditional and atomic storage operations
JP5404798B2 (ja) * 2009-09-21 2014-02-05 株式会社東芝 仮想記憶管理装置及び記憶管理装置
JP5269213B2 (ja) * 2010-02-02 2013-08-21 株式会社東芝 ストレージ機能を持つ通信装置
US20130091331A1 (en) * 2011-10-11 2013-04-11 Iulian Moraru Methods, apparatus, and articles of manufacture to manage memory
CN102331949B (zh) 2011-10-12 2014-11-05 华为技术有限公司 一种虚拟机内存快照生成和恢复方法、装置及系统
WO2013101194A1 (en) * 2011-12-30 2013-07-04 Intel Corporation Selective control for commit lines for shadowing data in storage elements
US20140143476A1 (en) * 2012-11-16 2014-05-22 Rotem Sela Usage of cache and write transaction information in a storage device
CN103530420B (zh) * 2013-10-30 2017-07-04 北京奇虎科技有限公司 数据文件的动态更新方法及装置
US10359937B2 (en) * 2013-12-20 2019-07-23 Sandisk Technologies Llc System and method of implementing a table storage support scheme
US9626119B2 (en) * 2014-11-14 2017-04-18 Intel Corporation Using counters and a table to protect data in a storage device
DE102015220485A1 (de) * 2015-10-21 2017-04-27 Robert Bosch Gmbh Verfahren zum Schreiben und Lesen eines Datensatzes
CN105956090B (zh) * 2016-04-27 2019-06-11 中国科学技术大学 一种基于i/o自适应的日志文件系统数据存储方法
US20180067817A1 (en) * 2016-09-07 2018-03-08 Ulsan National Institute of Science and Technology (UNIST) Electronic device and method of controlling the same
JP7193713B2 (ja) * 2018-10-31 2022-12-21 富士通株式会社 転送方式制御プログラム、転送方式制御装置及び転送方式制御方法
US11487467B1 (en) 2021-05-28 2022-11-01 Microsoft Technology Licensing, Llc Layered memory mapped file technology

Family Cites Families (5)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5455946A (en) * 1993-05-21 1995-10-03 International Business Machines Corporation Method and means for archiving modifiable pages in a log based transaction management system
US5721915A (en) * 1994-12-30 1998-02-24 International Business Machines Corporation Interaction between application of a log and maintenance of a table that maps record identifiers during online reorganization of a database
US6856993B1 (en) * 2000-03-30 2005-02-15 Microsoft Corporation Transactional file system
US6651073B1 (en) * 2000-05-23 2003-11-18 International Business Machines Corporation Method and apparatus for insuring database data integrity without data recovery logging
US7177866B2 (en) * 2001-03-16 2007-02-13 Gravic, Inc. Asynchronous coordinated commit replication and dual write with replication transmission and locking of target database on updates only

Cited By (29)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009069436A1 (ja) * 2007-11-28 2009-06-04 Kyoto Software Research, Inc. データ格納システムおよびデータ格納プログラム
KR100921876B1 (ko) 2007-11-28 2009-10-13 가부시키가이샤 교토 소프트웨어 리서치 데이터 격납 시스템 및 데이터 격납 프로그램
US8055853B2 (en) 2007-11-28 2011-11-08 Kyoto Software Research, Inc. Data storage system and data storage program for atomic transactions
US8621163B2 (en) 2009-09-17 2013-12-31 Kabushiki Kaisha Toshiba Management apparatus for improved database registration and update
JP2013508885A (ja) * 2009-10-26 2013-03-07 ウェアラブル・インコーポレイテッド ブロックアクセスデバイスとグラフアクセスデバイス間で共有されたメモリプールへの同時アクセス
KR20120104302A (ko) * 2009-12-11 2012-09-20 마이크로소프트 코포레이션 순서 의존성 없는 일관성
KR101690824B1 (ko) 2009-12-11 2017-01-09 마이크로소프트 테크놀로지 라이센싱, 엘엘씨 순서 의존성 없는 일관성
JP2013513862A (ja) * 2009-12-11 2013-04-22 マイクロソフト コーポレーション 順序の依存関係を持たない整合性
US9430160B2 (en) 2009-12-11 2016-08-30 Microsoft Technology Licensing, Llc Consistency without ordering dependency
US8996829B2 (en) 2009-12-11 2015-03-31 Microsoft Technology Licensing, Llc Consistency without ordering dependency
JP2012008997A (ja) * 2010-05-26 2012-01-12 Sanyo Electric Co Ltd ファイルデータ保護機能を備えた電子装置及びファイル保護方法
JP2013528883A (ja) * 2010-06-15 2013-07-11 マイクロソフト コーポレーション ファイルシステムのチェックポイント
US9448869B2 (en) 2010-06-17 2016-09-20 Microsoft Technology Licensing, Llc Error detection for files
US8984233B2 (en) 2010-06-17 2015-03-17 Microsoft Corporation Error detection for files
US9104690B2 (en) 2011-01-27 2015-08-11 Micron Technology, Inc. Transactional memory
US10083122B2 (en) 2011-01-27 2018-09-25 Micron Technology, Inc. Transactional memory
JP2012155705A (ja) * 2011-01-27 2012-08-16 Micron Technology Inc トランザクションメモリ
US9563487B2 (en) 2011-08-11 2017-02-07 Microsoft Technology Licensing, Llc. Runtime system
JPWO2014097475A1 (ja) * 2012-12-21 2017-01-12 株式会社Murakumo 情報処理方法、情報処理装置、及び、プログラム
WO2014097475A1 (ja) * 2012-12-21 2014-06-26 株式会社Murakumo 情報処理方法、情報処理装置、及び、プログラム
US10437812B2 (en) 2012-12-21 2019-10-08 Murakumo Corporation Information processing method, information processing device, and medium
CN104166606A (zh) * 2014-08-29 2014-11-26 华为技术有限公司 文件备份方法和主存储设备
US10635504B2 (en) 2014-10-16 2020-04-28 Microsoft Technology Licensing, Llc API versioning independent of product releases
JP2018527653A (ja) * 2015-07-10 2018-09-20 アビニシオ テクノロジー エルエルシー 分散型データベースシステムを用いるネットワーク内でデータベースアクセス制御を提供する方法及びアーキテクチャ
US11372883B2 (en) 2016-10-12 2022-06-28 Fujitsu Limited Apparatus for calculating size of processing unit, method for calculating size of processing unit, and non-transitory computer-readable storage medium for storing program
JP2021533495A (ja) * 2018-11-30 2021-12-02 テンセント・テクノロジー・(シェンジェン)・カンパニー・リミテッド データリカバリー方法、装置、サーバ及びコンピュータ・プログラム
JP7108782B2 (ja) 2018-11-30 2022-07-28 テンセント・テクノロジー・(シェンジェン)・カンパニー・リミテッド データリカバリー方法、装置、サーバ及びコンピュータ・プログラム
US11531594B2 (en) 2018-11-30 2022-12-20 Tencent Technology (Shenzhen) Company Limited Data recovery method and apparatus, server, and computer-readable storage medium
WO2022224451A1 (ja) * 2021-04-23 2022-10-27 株式会社東芝 管理装置、データベースシステム、管理方法およびプログラム

Also Published As

Publication number Publication date
JP4104586B2 (ja) 2008-06-18
CN100412862C (zh) 2008-08-20
US20060069885A1 (en) 2006-03-30
US7266669B2 (en) 2007-09-04
CN1755673A (zh) 2006-04-05

Similar Documents

Publication Publication Date Title
JP4104586B2 (ja) ファイル管理機能を備えたファイルシステム及びファイル管理方法
US7035881B2 (en) Organization of read-write snapshot copies in a data storage system
US8074035B1 (en) System and method for using multivolume snapshots for online data backup
US8356150B2 (en) Systems and methods for providing nonlinear journaling
US7318135B1 (en) System and method for using file system snapshots for online data backup
US8380689B2 (en) Systems and methods for providing nonlinear journaling
US10949415B2 (en) Logging system using persistent memory
US7885921B2 (en) Managing atomic updates on metadata tracks in a storage system
US8181065B2 (en) Systems and methods for providing nonlinear journaling
US7246211B1 (en) System and method for using file system snapshots for online data backup
US6678809B1 (en) Write-ahead log in directory management for concurrent I/O access for block storage
CN113868192B (zh) 一种数据存储设备、方法与分布式数据存储系统
US8280858B2 (en) Storage pool scrubbing with concurrent snapshots
US20060224639A1 (en) Backup system, program and backup method
CN109871386A (zh) 非易失性存储器中的多版本并发控制(mvcc)
JP2004199497A (ja) データベース処理方法及び装置並びにその処理プログラム及びディザスタリカバリ方法及びシステム
JP2005316635A (ja) データ処理システムおよび方法並びにその処理プログラム
CN110515705A (zh) 可扩展的持久性事务内存及其工作方法
US9003106B1 (en) Crash consistency
US9335941B1 (en) Crash consistency
US11593352B2 (en) Cloud-native object storage for page-based relational database
EP4002148A1 (en) Cloud-native object storage for page-based relational database
CN115437550A (zh) 存储系统的写入方法、分布式存储系统的写入方法
KR101968474B1 (ko) 플래시 캐시에서 트랜잭션 지원 방법 및 장치
JP2012128596A (ja) データベースシステム、その情報処理方法、およびそのプログラム

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20071113

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20080115

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: 20080318

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20080325

R150 Certificate of patent or registration of utility model

Ref document number: 4104586

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: 20110404

Year of fee payment: 3

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20130404

Year of fee payment: 5

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20140404

Year of fee payment: 6

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

S533 Written request for registration of change of name

Free format text: JAPANESE INTERMEDIATE CODE: R313533

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

LAPS Cancellation because of no payment of annual fees