(57)【要約】  データ管理システムが、Tx（トランザクション）処理命令を受けた都度に、（Ａ）その受信した命令に従うトランザクション処理に関連付けた状態であって、非永続状態を、記憶空間に登録し、（Ｂ）そのトランザクションを終了する場合、そのトランザクション処理の状態を、永続状態に変更する。これにより、Tx処理における全てのデータを同時に永続化できる。
2017060941.tif 000002
【特許請求の範囲】
【請求項１】
不揮発空間を含んだ記憶空間と、
トランザクション処理命令を受け付けその命令に従うトランザクション処理におけるデータを前記不揮発空間に書き込むプロセッサと
を有し、
前記プロセッサが、トランザクション処理命令を受けた都度に、
（Ａ）その受信した命令に従うトランザクション処理に関連付けた状態であって、非永続状態を、前記記憶空間に書き込み、
（Ｂ）そのトランザクション処理を終了する場合、そのトランザクション処理の状態を、永続状態に変更する、
データ管理システム。
【請求項２】
（Ａ）において、前記プロセッサは、前記受信した命令に従うトランザクション処理におけるいずれかのデータを前記不揮発空間に書き込む前に、そのトランザクション処理に関連付けた状態を前記不揮発空間に書き込む、
請求項１記載のデータ管理システム。
【請求項３】
前記プロセッサは、トランザクション処理において、データの挿入、更新又は削除の都度に、
そのデータに、（Ａ）において前記不揮発空間に書き込まれた、そのトランザクション処理の状態を、関連付けて、
そのデータを、前記不揮発空間に書き込む、
請求項２記載のデータ管理システム。
【請求項４】
前記プロセッサは、そのトランザクション処理を終了する場合、
そのトランザクション処理における全てのデータが前記不揮発空間に書き込まれていれば、そのトランザクション処理の状態を、永続状態に変更する、
請求項２記載のデータ管理システム。
【請求項５】
前記プロセッサは、全ての対象トランザクション処理の各々の状態をアボート状態に変更する処理を障害回復処理として実行し、
前記全ての対象トランザクション処理の各々は、未永続状態を示す状態に関連付いているトランザクション処理である、
請求項４記載のデータ管理システム。
【請求項６】
前記記憶空間に、前回の終了が正常に実施されたのか否かを示すシステム状態が格納されており、
前記プロセッサは、起動時の前記システム状態が異常状態を示している場合、前記障害回復処理を実行する、
請求項５記載のデータ管理システム。
【請求項７】
前記不揮発空間が、状態管理情報を記憶し、
前記状態管理情報は、トランザクション処理毎に、トランザクション処理のIDと、トランザクション処理の状態とを含んだ情報である、
請求項２記載のデータ管理システム。
【請求項８】
前記不揮発空間が、更に、データ管理情報を記憶し、
前記データ管理情報は、いずれかのトランザクション処理におけるデータ毎に、データと、そのデータを処理対象としたトランザクション処理の状態の前記状態管理情報における所在を示す情報要素とを含んだ情報である、
請求項７記載のデータ管理システム。
【請求項９】
前記データ管理情報は、いずれかのトランザクション処理におけるデータ毎に、更に、そのデータが前記不揮発空間における必要性を示す情報要素と、そのデータの更新後のデータの所在を示す情報要素とを含む、
請求項８記載のデータ管理システム。
【請求項１０】
前記不揮発空間が、更に、トランザクション管理情報を記憶し、
前記トランザクション管理情報は、トランザクション処理毎に、トランザクション処理のIDと、そのトランザクション処理での各データについてそのデータの前記データ管理情報における所在を示す情報要素とを含んだ情報である、
請求項８記載のデータ管理システム。
【請求項１１】
前記トランザクション管理情報は、トランザクション処理毎にエントリを含み、
各エントリが、トランザクション処理のIDと、そのトランザクション処理での各データについてそのデータの前記データ管理情報における所在を示す情報要素とを含み、
前記プロセッサは、前記トランザクション管理情報から、永続状態のトランザクション処理又はアボート状態のトランザクションに対応したエントリを削除する、
請求項１０記載のデータ管理システム。
【請求項１２】
前記記憶空間に、前回の終了が正常に実施されたのか否かを示すシステム状態が格納されており、
前記プロセッサは、起動時の前記システム状態が異常状態を示している場合、障害回復処理として、全ての対象トランザクション処理の各々の状態をアボート状態に変更する処理と、前記トランザクション管理情報を削除する処理とを実行し、
前記全ての対象トランザクション処理の各々は、未永続状態を示す状態に関連付いているトランザクション処理である、
請求項１０記載のデータ管理システム。
【請求項１３】
不揮発メモリを有し、
前記不揮発空間は、前記不揮発メモリに基づく空間であり、
前記プロセッサが、インメモリDBMS（Database Management System）を実行することにより、（Ａ）及び（Ｂ）を実行する、
請求項１記載のデータ管理システム。
【請求項１４】
トランザクション処理命令を受信し、
その受信した命令に従うトランザクション処理に関連付けた状態であって、非永続状態を、トランザクション処理におけるデータの書込み先となる不揮発空間を含む記憶空間に書き込み、
そのトランザクション処理を終了する場合、そのトランザクション処理の状態を、永続状態に変更する、
データ管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、複数のデータの整合性を維持するデータ管理に関する。
【背景技術】
【０００２】
複数のデータの整合性を維持することが必要な環境（システム）として、例えば、DBMS（Database Management System）がある。【０００３】
DBMSは、入出力するデータであるレコードの一貫性及び永続性を制御する。これにより、ユーザは常に意図したレコードを入出力することが可能となる。このようなDBMSの一貫性制御をTx（トランザクション）処理と呼ぶ。Tx処理は、複数の命令（参照命令及び更新命令）をアトミックに実現するときに用いられる。Tx処理では、アトミックに実行したい命令区間の始めと終わり（Tx処理区間）を宣言することにより、指定した区間の複数の命令をアトミックに処理する。Tx処理がコミットする場合、その結果はストレージなどの外部記憶媒体に永続化される。【０００４】
Tx処理を実現するためには、ACID特性を満たす必要がある。ACID特性とは、原子性（Atomicity）、一貫性（Consistency）、独立性（Isolation）及び永続性（Durability）を示す。原子性とは、Tx処理区間の複数の命令を全て実行するか、全て実行させないことである。一貫性とは、データベースに与えられたルール以外の状態に遷移させないことである。独立性とは、Tx処理の結果は、必ずTx処理を逐次的に実行したときと同じになることをいう。永続性とは、Tx処理がコミットしていれば、ACID特性を満たすことによって、Tx処理の一貫性を維持している。【０００５】
また、DBMSには、性能や可用性も求められる。【０００６】
性能は、例えば特許文献１又は２に開示の技術により向上することが期待される。特許文献１によれば、データベースやインデックスをサーバのメモリに展開してTx処理するインメモリDBMSによって性能向上が期待できる。しかし、インメモリDBMSにおいてもログ処理は発生し、ログ処理が性能の課題となる。特許文献２の技術によれば、ログ処理の性能の課題を解決することが期待される。特許文献２によれば、コミット前の未コミットな状態を定義することにより、未コミットな結果を参照することが可能となる。これにより、例えば、Tx 1の後にTx 2を実行していた処理を、Tx 1のログ処理の完了を待つことなく、Tx 2がTx 1のコミット結果を参照することができ、以って、ログ処理を隠蔽することが期待できる。【０００７】
可用性は、例えば特許文献３に開示の技術により向上することが期待される。特許文献３によれば、ログ連携のHA（High Availability）構成によって可用性の向上が期待される。HA構成は、システムの多重化であり、Tx処理する実行系と実行系の同期を取る待機系とを有する。このようなHA構成により、実行系の障害時に待機系へ即座に切り替えることで可用性の向上が期待される。
【先行技術文献】
【特許文献】
【０００８】
【特許文献１】US2,011/0252000
【特許文献２】US8407195
【特許文献３】特開2013-84293号公報
【発明の概要】
【発明が解決しようとする課題】
【０００９】
特許文献１、２及び３に開示の技術によって、性能や可用性の向上が期待される。しかし、単一システムにおいて性能と可用性を両立することができない。例えば、インメモリDBMSは、データベース（例えばインデックス及び表）を揮発メモリに展開することで高性能を実現する。しかし、障害回復時には、一般に、ストレージ（典型的にはディスク）からデータベースを揮発メモリに展開する（読み出す）処理やその後にストレージからログファイルを読み出し読み出したログファイルをメモリ上のデータベースに反映する処理が必要になり、可用性は低い。一方、障害回復時にデータベースの読み出しを行わないことが考えられるが、そうすると、必要なデータをTx処理で揮発メモリに展開するために度々ストレージにアクセスする必要があり、性能が低下する。【００１０】
単一システムにおいて性能と可用性を両立することが望ましい。例えば、インメモリDBMSの障害回復を高速に実行することが望まれる。インメモリDBMSでは、ストレージからデータをメモリに展開する処理、ストレージからログファイルを読み出しメモリ上のデータに適応する処理が課題となる。【００１１】
このような課題は、DBMSに限らず、複数のデータの整合性を維持することが必要な他種の環境（システム）、例えば、ファイルシステム、又は、KVS（Key Value Store）においてもあり得る。
【課題を解決するための手段】
【００１２】
データ管理システムが、Tx（トランザクション）処理命令を受けた都度に、
（Ａ）その受信した命令に従うトランザクション処理に関連付けた状態であって、非永続状態（非永続を意味する状態）を、記憶空間に登録し、
（Ｂ）そのトランザクションを終了する場合、そのトランザクション処理の状態を、永続状態（永続を意味する状態）に変更する。
【発明の効果】
【００１３】
単一システムにおいて性能と可用性を両立することができる。
【図面の簡単な説明】
【００１４】
【図１】実施形態に係るシステム全体の構成を示す。
【図２】記憶空間とその記憶空間に格納される情報を示す。
【図３】管理プログラムの機能ブロック図である。
【図４】TxMSのフローチャートである。
【図５】TxMSのフローチャートである。
【図６】NVMS_STATE管理システムのフローチャートである。
【図７】NVMS_DATA管理システムのフローチャートである。
【図８】複数データをアトミックに永続化する処理のシーケンス図である。
【図９】図２に示したNVMS_STATE、NVMS_DATA及びNVMS_TABLEの詳細例を示す。
【図１０】NVMS_DATA管理システムのフローチャートのうち、図７に示したフローチャートとの差分を含んだ部分である。
【図１１】複数データをアトミックに永続化する処理のシーケンス図のうち、図８に示したシーケンス図との差分を含んだ部分である。
【図１２】図９に示したNVMS_STATE、NVMS_DATA及びNVMS_TABLEの詳細例と、記憶空間に格納される更なる情報であるSYSTEM_PARAMとを示す。
【図１３】NVMSが有する更なる機能を示す。
【図１４】NVMS_START管理システムのフローチャートである。
【図１５】NVMS_STATE管理システムのフローチャートのうち、図６に示したフローチャートとの差分を含んだ部分である。
【図１６】NVMS_DATA管理システムのフローチャートのうち、図７に示したフローチャート（又は、図１０に示した部分を含んだフローチャート）との差分を含んだ部分である。
【図１７】起動及び終了のシーケンス図である。
【発明を実施するための形態】
【００１５】
以下、図面を参照して、データ管理システムとしてDBMS（特に、インメモリDBMS）を例に取り、実施形態を説明する。
【００１６】
以下の説明では、プログラムを主語として処理を説明する場合があるが、プログラムがプロセッサ（例えばＣＰＵ（Central Processing Unit））によって実行されることで、定められた処理を、適宜にメモリ及び／又はインターフェースデバイス（例えば通信ポート）等を用いながら行うため、処理の主語がプロセッサ（或いは、そのプロセッサを有する装置又はシステム）が行う処理としてもよい。また、プロセッサは、処理の一部または全部を行うハードウェア回路を含んでもよい。プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記憶メディアであってもよい。プログラムソースがプログラム配布サーバの場合、プログラム配布サーバは配布対象のプログラムを他の計算機に配布してよい。
【００１７】
また、以下の説明では、「トランザクション」を「Tx」と言う。Txの実行により行われる処理を「Tx処理」と言う。また、生成処理（CREATE）、インサート処理（INSERT）、アップデート処理（UPDATE）及びデリート処理（DELETE）のいずれかを意味する言葉として「SQL処理」と言うことができる。Tx処理は、ビギン処理、１以上のSQL処理、及びコミット処理を含む。
【００１８】
以下、まず、図１〜図１０を参照して、実施形態の基本部分に関する説明をする。次に、図９〜図１１を参照して、複数データを同時にアップデート、インサート又はデリートする処理に関する説明をする。最後に、図１２〜図１７を参照して、正常に起動及び終了するための処理に関する説明をする。
【００１９】
＜実施形態の基本部分に関する説明＞
【００２０】
図１は、実施形態に係るシステム全体の構成を示す。
【００２１】
計算機システム１１０Ｂが、ユーザ１００から、計算機システム１１０Ａ及びネットワーク１５０を通じて、命令を受けることができる。計算機システム１１０Ｂは、計算機システム１１０Ａ及びネットワーク１５０を経由すること無しに命令を受けてもよい。また、計算機システム１１０Ｂは、複数台の計算機システム１１０Ａと接続することも可能である。
【００２２】
計算機システム１１０Ｂは、１以上のノード、例えば２つのノード１３０及び１４０を有する。これらのノード１３０及び１４０は、システムバス１５１を介して接続されていてよい。計算機システム１１０Ｂに、ネットワーク１５０経由で外部記憶デバイス１２０が接続されていてよい。
【００２３】
１以上のノードの各々の構成は同じ構成でよい。例えば、ノード１３０は、メモリ１３２、内部記憶デバイス１３３、入出力デバイス１３４及びそれらに接続されたプロセッサ１３１を有する。同様に、ノード１４０も、メモリ１４２、内部記憶デバイス１４３、入出力デバイス１４４及びそれらに接続されたプロセッサ１４１を有する。以下の説明では、ノード１３０を主に例に取るが、ノード１４０のような他のノードも同じ機能及び構成を有していてよい。計算機システム１１０Ｂ（又は、いずれか１つのノード）が、データ管理システムの一例でよい。
【００２４】
入出力デバイス１３４は、外部記憶デバイス１２０のような外部の装置と通信する通信インターフェイスデバイスでもよいし、ヒューマンマシンインターフェイスデバイス（例えば、キーボード及びポインティングデバイスのような入力デバイスと、表示デバイスのような出力デバイス）でもよい。メモリ１３２は、DRAM（Dynamic Random Access Memory）のような揮発メモリとフラッシュメモリのような不揮発メモリ（以下、NVM）とのうちの少なくとも１つを含んでよい。メモリ１３２に、ＤＢＭＳのようなプログラムが格納されていて、そのプログラムがプロセッサ１３１により実行される。
【００２５】
図２は、記憶空間とその記憶空間に格納される情報を示す。
【００２６】
記憶空間２００は、メモリ１３２、内部記憶デバイス１３３及び外部記憶デバイス１２０のうちの少なくともメモリ１３２に基づく。記憶空間２００は、揮発空間２０１と不揮発空間２０２を含む。
【００２７】
揮発空間２０１は、メモリ１３２における揮発記憶領域（例えばDRAMのうちの少なくとも一部）に基づく空間である。不揮発空間２０２は、メモリ１３２におけるNVM（例えばNVMのうちの少なくとも一部）のみに基づく空間であるが、それに代えて又は加えて、内部記憶デバイス１３３（例えば、SSD（Solid State Drive）又はHDD（Hard Disk Drive））と外部記憶デバイス１２０とのうちの少なくとも一部に基づく空間を含んでもよい。但し、プログラムの設定により、NVMに揮発空間２０１を意図的に配置することは可能である。以下、記憶空間２００の操作に関して、言及がなければ不揮発空間２０２が操作対象であるとする。不揮発空間２０２のキャッシュとして、揮発空間２０１が用いられてもよい。
【００２８】
記憶空間２００は、NVMS_STATE２１０とNVMS_DATA２２０とNVMS_TABLE２３０といった情報を記憶する。NVMS_STATE２１０は、状態管理情報の一例である。NVMS_DATA２２０は、データ管理情報の一例である。NVMS_TABLE２３０は、トランザクション管理情報の一例である。
【００２９】
NVMS_STATE２１０は、Tx処理での処理対象データ（例えばデータベースにおけるレコード）の状態を各Tx処理について示す情報である。例えば、NVMS_STATE２１０は、Tx処理毎にエントリを有する。各エントリに、ID２１１とSTATE２１２が登録される。ID２１１は、Tx処理のID（例えば識別番号）である。STATE２１２は、Tx処理での処理対象データの状態を示す情報である。STATE２１２の値として、例えば、“PROCESSING”、“COMMIT”、“ABORT”等がある。“PROCESSING”は、Tx処理が未コミットであるが故にそのTx処理での全ての処理対象データが不揮発空間２０２から削除されてもよいことを意味する。一方、“COMMIT”は、Tx処理がコミット済であるが故にそのTx処理での全ての処理対象データが不揮発空間２０２から削除されてはならないことを意味する。エントリ２１３によれば、Tx 1（ID“1”のTx処理）での処理対象データの状態が“PROCESSING”である。
【００３０】
NVMS_DATA２２０は、Tx処理でのデータ（処理対象データ）とそのデータに関連付けられたSTATE２１２との対応関係をデータ毎に示す情報である。例えば、NVMS_DATA２２０は、Tx処理でのデータ毎にエントリを有する。各エントリに、DATA２２１とSTATE_pt２２２が登録される。DATA２２１は、Tx処理におけるデータ（又はその複製）である。STATE_pt２２２は、データに関連付けられているSTATE２１２へのポインタ（NVMS_STATE２１０におけるSTATE２１２の所在を表す情報）である。エントリ２２３、２２４及び２２５によれば、データＡ、データＢ及びデータＣの各々は、Tx 1（ID=1のTx処理）での処理対象データであり、Tx 1のSTATE２１２“PROCESSING”に関連付けられていることがわかる。
【００３１】
NVMS_TABLE２３０は、Tx処理とそのTx処理でのデータとの対応関係をTx処理毎に示す情報である。例えば、NVMS_TABLE２３０は、Tx処理毎にエントリを有する。各エントリに、ID２３１と１以上のDATA_pt２３２が登録される。ID２３１は、Tx処理のIDである。DATA_pt２３２の各々は、Tx処理におけるデータのDATA２２１へのポインタ（NVMS_DATA２２０におけるDATA２２１の所在を表す情報）である。エントリ２３５によれば、Tx 1でのデータは、データＡ、データＢ及びデータＣであり、それらはNVMS_DATA２２０におけるエントリ２２３〜２２５にそれぞれ関連付けられていることがわかる。
【００３２】
上述の説明において、NVMS_TABLE２３０は、NVMS_DATA２２０が不揮発空間２０２に書込まれたかを判断する機能（ハードウェア機能又はソフトウェア機能）が無い場合に用いられてよい。言い換えれば、NVMS_DATA２２０が不揮発空間２０２に書込まれたかを判断する機能が有る場合、NVMS_TABLE２３０は無くてよい。また、STATE_pt２２２やDATA_pt２３２は、それぞれ、ユニーク番号、アドレス番地及び配列番号等のうちの少なくとも１つを用いて表現可能である。また、NVMS_STATE２１０、NVMS_DATA２２０及びNVMS_TABLE２３０のいずれも不揮発空間２０２に格納されてよい。
【００３３】
図３は、管理プログラムの機能ブロック図である。
【００３４】
管理プログラム２４０は、プロセッサ１３１により実行されるプログラムの１つであり、例えばDBMSである。管理プログラム２４０は、Tx処理の開始及び終了等を制御するTx処理システム２５０と、Tx処理を管理するTxMS（Transaction Management System）２６０と、不揮発空間２０２を管理するNVMS（Non-Volatile Management System）２７０とを有する。これらの要素２５０、２６０及び２７０の各々は、管理プログラム２４０の機能（例えばプログラムモジュール）でよい。また、これらの要素２５０、２６０及び２７０のうちの少なくとも要素２５０及び２６０が、Tx処理毎に存在してよい。
【００３５】
NVMS２７０は、NVMS_STATE管理システム２７１と、NVMS_DATA管理システム２７２とを有する。これらの要素２７１及び２７２の各々は、NVMS２７０の機能（例えばプログラムモジュール）でよい。
【００３６】
TxMS２６０は、Tx処理システム２５０やNVMS２７０と連動して動作する。NVMS_STATE管理システム２７１は、NVMS_STATE２１０を管理し、NVMS_DATA管理システム２７２と連動して動作する。NVMS_DATA管理システム２７２は、NVMS_DATA２２０やNVMS_TABLE２３０を管理し、NVMS_STATE管理システム２７１と連動して動作する。
【００３７】
このような管理プログラム２４０は、記憶空間２００に存在しても、ハードウェアとして実装されていてもよい。
【００３８】
以下、図４〜図９を参照して、本実施形態で行われるデータ処理の一例を説明する。その説明では、１つのTx処理を例に取る。
【００３９】
図４は、Tx処理システム２５０のフローチャートである。
【００４０】
Tx処理システム２５０は、ユーザ１００からの指示によって（例えば計算機システム１１０Ａからの指示に応答して）、Tx処理を開始（BEGIN）する（Ｓ１００）。このとき、Tx処理システム２５０は、開始命令（BEGIN）をTxMS２６０へ送る。
【００４１】
次に、Tx処理システム２５０は、ユーザ１００からの指示により処理を生成し（Ｓ１１０）、処理判定を行う（Ｓ１２０）。Ｓ１２０では、Tx処理システム２５０は、処理命令がCOMMITかABORTであるかを判断する。処理命令がCOMMIT及びABORTのいずれでもないと判定された場合、Tx処理システム２５０は、処理実行Ａを行う（Ｓ１３０）。Ｓ１３０では、Tx処理システム２５０は、処理命令に応じてデータをTxMS２６０へ送る。これらの処理が、Ｓ１２０において処理命令がCOMMIT又はABORTであると判定されるまで、繰り返される。
【００４２】
処理命令がCOMMIT又はABORTであると判定された場合、Tx処理システム２５０は、処理実行Ｂを行う（Ｓ１４０）。Ｓ１４０では、Tx処理システム２５０は、処理命令（COMMIT又はABORT）に応じたデータをTxMS２６０へ送る。
【００４３】
その後、Tx処理システム２５０は終了する（Ｓ１５０）。
【００４４】
図５は、TxMS２６０のフローチャートである。
【００４５】
TxMS２６０は、Tx処理システム２５０から開始命令（BEGIN）を受信することにより開始する（Ｓ２００）。TxMS２６０は、Tx処理システム２５０から処理命令を受信した場合、その受信した処理命令を判定する（Ｓ２１０）。
【００４６】
処理命令がBEGINの場合、TxMS２６０は、処理命令（CREATE）をNVMS_STATE管理システム２７１に送る（Ｓ２２０）。CREATEは、Tx処理のID２１１及びSTATE２１２を含んだNVMS_STATEエントリ（NVMS_STATE２１０におけるエントリ）を生成することの命令である。Ｓ２２０の後、TxMS２６０は終了する（Ｓ２６０）。
【００４７】
処理命令がINSERT、UPDATE又はDELETEの場合、TxMS２６０は、処理命令に応じたデータをNVMS_DATA管理システム２７２に送る（Ｓ２３０）。その後、TxMS２６０は終了する（Ｓ２６０）。
【００４８】
処理命令がCOMMITの場合、TxMS２６０は、処理命令（CHECK）とTx処理のIDとをNVMS_DATA管理システム２７２に送る（Ｓ２４０）。CHECKは、Tx処理での全ての処理対象データが不揮発空間２０２に書込み済みであるか否かを確認することの命令である。Ｓ２４０の後、TxMS２６０は、処理命令（COMMIT）をNVMS_STATE管理システム２７１に送る（Ｓ２５０）。Ｓ２５０の後、TxMS２６０は、処理命令（DELETE TABLE）をNVMS_DATA管理システム２７２に送る（Ｓ２５１）。DELETE TABLEは、COMMIT（又はABORT）が完了したTx処理に対応したNVMS_STATEエントリをNVMS_STATE２１０から削除することの命令である。Ｓ２５１の後、TxMS２６０は終了する（Ｓ２６０）。
【００４９】
処理命令がABORTの場合、TxMS２６０は、処理命令（ABORT）とTx処理のIDとをNVMS_STATE管理システム２７１に送る（Ｓ２５０）、その後、TxMS２６０は、処理命令（DELETE TABLE）をNVMS_DATA管理システム２７２に送る（Ｓ２５１）。その後、TxMS２６０は終了する（Ｓ２６０）。
【００５０】
図６は、NVMS_STATE管理システム２７１のフローチャートである。
【００５１】
NVMS_STATE管理システム２７１は、TxMS２６０から処理命令を受信した場合に開始する（Ｓ３００）。NVMS_STATE管理システム２７１は、TxMS２６０から受信した処理命令を判定する（Ｓ３１０）。
【００５２】
処理命令がCREATEの場合、NVMS_STATE管理システム２７１は、Tx処理に応じてNVMS_STATEエントリ（NVMS_STATE２１０のエントリ）のための領域を不揮発空間２０２から確保する（Ｓ３２０）。次に、NVMS_STATE管理システム２７１は、Ｓ３２０で確保した領域（NVMS_STATEエントリ）に、STATE２１２として“PROCESSING”を書込む（Ｓ３２１）。また、NVMS_STATE管理システム２７１は、Tx処理のIDを生成し（Ｓ３２２）、生成したIDを、Ｓ３２０で格納したNVMS_STATEエントリにID２１１として書込む（Ｓ３２３）。次に、NVMS_STATE管理システム２７１は、Ｓ３２０で格納したNVMS_STATEエントリ（不揮発空間２０２）に、Tx処理に対応したID２１１及びSTATE２１２が書込み済みであることを確認する（Ｓ３２４）。その後、NVMS_STATE管理システム２７１は、TxMS２６０へ、その書込み済のID２１１を応答して終了する（Ｓ３４０）。
【００５３】
処理命令がCOMMITの場合、NVMS_STATE管理システム２７１は、受信したIDと同じID２１１が登録されているNVMS_STATEエントリをNVMS_STATE２１０から検索し（Ｓ３３０）、見つかったNVMS_STATEエントリのSTATE２１２として“COMMIT”を書込む（Ｓ３３１）。つまり、NVMS_STATE管理システム２７１は、Tx処理のSTATE２１２を“COMMIT”に変更する。その後、NVMS_STATE管理システム２７１は終了する（Ｓ３４０）。
【００５４】
処理命令がABORTの場合、NVMS_STATE管理システム２７１は、受信したIDと同じID２１１が登録されているNVMS_STATEエントリをNVMS_STATE２１０から検索し（Ｓ３３０）、見つかったNVMS_STATEエントリのSTATE２１２として“ABORT”を書込む（Ｓ３３１）。その後、NVMS_STATE管理システム２７１は終了する（Ｓ３４０）。
【００５５】
図７は、NVMS_DATA管理システム２７２のフローチャートである。
【００５６】
NVMS_DATA管理システム２７２は、TxMS２６０から処理命令を受信した場合に開始する（Ｓ４００）。NVMS_DATA管理システム２７２は、TxMS２６０から受信した処理命令を判定する（Ｓ４１０）。
【００５７】
処理命令がINSERTの場合、NVMS_DATA管理システム２７２は、受信したIDをID２３１として含むNVMS_TABLEエントリのエントリ部分（DATA_pt２３２）のための領域を不揮発空間２０２から確保する（Ｓ４２０）。次に、NVMS_DATA管理システム２７２は、INSERT対象データがDATA２２０として書き込まれるNVMS_DATAエントリのための領域を不揮発空間２０２から確保する（Ｓ４２１）。NVMS_DATA管理システム２７２は、Ｓ４２０で確保したエントリ部分に、DATA_pt２３２として、Ｓ４２１で確保した領域（NVMS_DATAエントリ）の所在を書き込む（Ｓ４２２）。そして、NVMS_DATA管理システム２７２は、Ｓ４２１で確保した領域（NVMS_DATAエントリ）に、STATE_pt２２２として、受信したIDをID２３１として含むNVMS_STATEエントリの所在を書き込み、且つ、DATA２２１として、受信したデータ（INSERT対象データ）を書き込む（Ｓ４２３）。その後、NVMS_DATA管理システム２７２は終了する（Ｓ４５０）。
【００５８】
処理命令がCHECKの場合、NVMS_DATA管理システム２７２は、Tx処理での全ての処理対象データ（すなわち、受信したIDをID２３１として含んだNVMS_TABLEエントリにおける全てのDATA_pt２３２にそれぞれ関連付いている全てのデータ）が不揮発空間２０２に書込まれているか否かを確認（判定）する（Ｓ４３０）。全ての処理対象データが書込み済みであれば、NVMS_DATA管理システム２７２は終了する（Ｓ４５０）。少なくとも１つの処理対象データが未書込みであれば、NVMS_DATA管理システム２７２は、全ての処理対象データが不揮発空間２０２に書き込まれるのを待つ。
【００５９】
処理命令がDELETE TABLEの場合、NVMS_DATA管理システム２７２は、受信したIDをID２１１として含んだNVMS_TABLEエントリをNVMS_TABLE２３０から削除する（Ｓ４４０）。その後、NVMS_DATA管理システム２７２は終了する（Ｓ４５０）。
【００６０】
図８は、複数データをアトミックに永続化する処理のシーケンス図である。なお、シーケンス図では、命令を「Com.」と表記する。
【００６１】
Tx処理システム２５０は、開始命令（BEGIN）をTxMS２６０へ送る（３００）。TxMS２６０は、受信した開始命令（BEGIN）に応答して開始し、処理命令（CREATE）をNVMS_STATE管理システム２７１へ送る（３０１）。NVMS_STATE管理システム２７１は、処理命令（CREATE）を受信する。NVMS_STATE管理システム２７１は、受信した処理命令（CREATE）に従い、NVMS_STATEエントリを不揮発空間２０２に確保し、Tx処理のIDを生成し、ID２１１（生成したID）とSTATE２１２“PROCESSING”を、そのNVMS_STATEエントリに書き込む（つまり、ID２１１とSTATE２１２とを不揮発空間２０２に書き込む）。その後、NVMS_STATE管理システム２７１は、不揮発空間２０２に書き込まれたIDをTxMS２６０に返す。TxMS２６０は、NVMS_STATE管理システム２７１からIDを受信し、そのIDをTx処理システム２５０へ返す。
【００６２】
Tx処理システム２５０は、開始命令（BEGIN）の送信後、開始されたTx処理のIDをTxMS２６０から受信する。Tx処理システム２５０は、SQL命令（INSERT）と、INSERT対象データと、TxMS２６０から受信したIDとを、TxMS２６０へ送る（３１０）。TxMS２６０は、SQL命令（INSERT）、データ及びIDを受信する。TxMS２６０は、受信したSQL命令（INSERT）に従い、処理命令（INSERT）と、受信したデータ及びIDとを、NVMS_DATA管理システム２７２へ送る（３１１）。NVMS_DATA管理システム２７２は、処理命令（INSERT）、データ及びIDを受信する。NVMS_DATA管理システム２７２は、受信した処理命令（INSERT）に従い、受信したデータのNVMS_DATAエントリ（不揮発空間２０２）に、DATA２２１（受信したデータ）と、STATE_pt２２２（受信したIDに対応したNVMS_STATEエントリへのポインタ）とを書き込む。なお、Tx処理システム２５０及びTxMS２６０は、NVMS_STATE管理システム２７１のその処理の終了を待たなくてもよい。
【００６３】
Tx処理システム２５０は、終了命令（COMMIT）とCOMMIT対象のTx処理のIDとをTxMS２６０へ送る（３２０）。TxMS２６０は、終了命令（COMMIT）及びIDを受信する。TxMS２６０は、受信した終了命令（COMMIT）に従い、処理命令（CHECK）と受信したIDとをNVMS_DATA管理システム２７２に送る（３２１）。NVMS_DATA管理システム２７２は、終了命令（COMMIT）及びIDを受信する。NVMS_DATA管理システム２７２は、受信した処理命令（CHECK）に従い、受信したIDに関連する全ての処理対象データ（全てのDATA_pt２３２）が不揮発空間２０２に書かれていることを確認する。その確認が取れれば、NVMS_DATA管理システム２７２は、TxMS２６０へ完了通知を送る。TxMS２６０は、その完了通知を受信し、処理命令（COMMIT）とTx処理のIDとをNVMS_STATE管理システム２７１に送る（３２２）。NVMS_STATE管理システム２７１は、処理命令（COMMIT）及びIDを受信する。NVMS_STATE管理システム２７１は、受信した処理命令（COMMIT）に従い、受信したIDに対応したSTATE２１２を“COMMIT”に変更する。この変更により、Tx処理での全ての処理対象データ（DATA２２１）の永続化が完了する。
【００６４】
NVMS_STATE管理システム２７１は、完了通知をTxMS２６０へ送る。TxMS２６０は、完了通知を受信し、処理命令（DELETE TABLE）とTx処理のIDとをNVMS_DATA管理システム２７２に送る（３２３）。処理命令（COMMIT）の完了通知を受けたNVMS_STATE管理システム２７１が処理命令（DELETE TABLE）を送る理由は、コミット後には、コミットしたTx処理に対応したNVMS_TABLEエントリ（コミットしたTx処理での各データへのDATA_pt２３２を含んだNVMS_TABLEエントリ）は不要になるためである（アボートについても同様のことが言えるので、アボート後に、処理命令（DELETE TABLE）が送られてもよい）。NVMS_DATA管理システム２７２は、処理命令（DELETE TABLE）及びIDを受信する。NVMS_DATA管理システム２７２は、受信した処理命令（DELETE TABLE）に従い、受信したIDと同じID２１１を含んだNVMS_TABLEエントリを削除し、完了通知をTxMS２６０へ送る。TxMS２６０は、その完了通知を受信し、完了通知をTx処理システム２５０へ送る。
【００６５】
これらの処理により、複数データのアトミックな永続化が実現される。
【００６６】
なお、Tx処理を途中で中止する場合、Tx処理システム２５０は、処理命令（ABORT）とTx処理のIDとをTxMS２６０へ送る（３３０）。TxMS２６０は、処理命令（ABORT）及びIDを受信し、その処理命令（ABORT）に基づき、処理命令（ABORT）及びIDをNVMS_STATE管理システム２７１に送る（３３１）。NVMS_STATE管理システム２７１は、処理命令（ABORT）及びIDを受信し、その処理命令（ABORT）に従い、そのIDに対応したSTATE２１２を“ABORT”に変更する。この変更により、Tx処理での全ての処理対象データの永続化が取り消されたことになる。NVMS_STATE管理システム２７１は、完了通知をTxMS２６０へ送る。TxMS２６０は、その完了通知を受信し、処理命令（DELETE TABLE）及びIDをNVMS_DATA管理システム２７２に送る（３３２）。NVMS_DATA管理システム２７２は、処理命令（DELETE TABLE）及びIDを受信し、その処理命令（DELETE TABLE）に従い、受信したIDをID２２１として含んだNVMS_TABLEエントリを削除し、完了通知をTxMS２６０へ送る。TxMS２６０は、その完了通知を受信し、完了通知をTx処理システム２５０へ送る。
【００６７】
一連のTx処理において、管理プログラム２４０は、Tx処理の処理対象データ（DATA２２１）の状態を明示するために、Tx処理に対応したNVMS_DATA２２０（例えばTx処理での最初の処理対象データ（DATA２２１））を不揮発空間２０２に書き込む前に、そのTx処理に対応したID２１１及びSTATE２２０を不揮発空間２０２に書き込む。
【００６８】
＜複数データを同時にアップデート、インサート又はデリートする処理に関する説明＞
【００６９】
図９は、図２に示したNVMS_STATE２１０、NVMS_DATA２２０及びNVMS_TABLE２３０の詳細例を示す。
【００７０】
NVMS_STATE２１０とNVMS_TABLE２３０の各々の構成（情報項目）は、図２に示した通りである。
【００７１】
NVMS_DATA２２０の各エントリには、DATA２２１及びSTATE_pt２２２に加えて、FLAG２２４及びNEXT_pt２２５が書き込まれる。FLAG２２４は、特定の処理対象データ（DATA２２１）の種類を示す。例えば、処理対象データが削除対象データであれば、FLAG２２４は“DELETE”であり、処理対象データが不要データであれば、FLAG２２４は“GARBAGE”である。NEXT_pt２２５は、そのNEXT_pt２２５に対応する処理対象データの次のデータ（次のSQL処理後（例えば更新後）のデータ）の所在を表す。なお、図９に示すNVMS_DATA２２０によれば、１つのTx処理における複数データは片方向ポインタ（NEXT_pt）で関連付けられているが、双方向ポインタ（NEXT_pt及びPREV_pt）で関連付けられていてもよい。
【００７２】
図１０は、NVMS_DATA管理システム２７２のフローチャートのうち、図７に示したフローチャートとの差分を含んだ部分である。以下、図７との差分を主に説明する。
【００７３】
受信した処理命令がUPDATEの場合、NVMS_DATA管理システム２７２は、受信したIDをID２３１として含むNVMS_TABLEエントリのエントリ部分（DATA_pt２３２）のための領域を不揮発空間２０２から確保する（Ｓ４５０）。次に、NVMS_DATA管理システム２７２は、UPDATE対象データ（更新後データ）がDATA２２０として書き込まれるNVMS_DATAエントリのための領域を不揮発空間２０２から確保する（Ｓ４５１）。NVMS_DATA管理システム２７２は、Ｓ４５０で確保したエントリ部分に、DATA_pt２３２として、Ｓ４５１で確保した領域（NVMS_DATAエントリ）の所在を書き込む（Ｓ４５２）。そして、NVMS_DATA管理システム２７２は、Ｓ４５１で確保した領域（NVMS_DATAエントリ）に、STATE_pt２２２として、受信したIDをID２３１として含むNVMS_STATEエントリの所在を書き込み、且つ、DATA２２１として、受信したデータ（UPDATE対象データ）を書き込む（Ｓ４５３）。NVMS_DATA管理システム２７２は、UPDATE対象データに対応する更新前データのNEXT_pt２２５として、UPDATE対象データ（DATA２２１）の所在を書き込む（Ｓ４５４）。その後、NVMS_DATA管理システム２７２は終了する（Ｓ４４０）。
【００７４】
処理命令がDELETEの場合も、Ｓ４５０〜Ｓ４５４と同様の処理が行われる。相違点としては、例えば、UPDATE対象データがDELETE対象データであることと、Ｓ４５３においてDELETE対象データに対応したFLAG２２４として“DELETE”が書き込まれることである。
【００７５】
Tx処理における最新のDATA２２１を参照するために、NVMS_DATA管理システム２７２は、NEXT_pt２２５を辿る。最新のDATA２２１のFLAG２２４が“DELETE”でなく、且つ、そのTx処理に対応したSTATE２１２が“COMMIT”であれば、整合性を維持した参照が可能であることを意味する。最新のDATA２２１のFLAG２２４が“DELETE”であり、Tx処理に対応したSTATE２２１が“COMMIT”であれば、その最新のDATA２２１は削除されていることを意味する。また、最新のDATA２２１のFLAG２２４が“GARBAGE”であれば、その最新のDATA２２１はガベージコレクション（GC）の対象であることを意味する。
【００７６】
図１１は、複数データをアトミックに永続化する処理のシーケンス図のうち、図８に示したシーケンス図との差分を含んだ部分である。以下、図８との差分を主に説明する。
【００７７】
Tx処理システム２５０は、SQL命令（UPDATE）と、更新前データの所在（DATA_pt）と、UPDATE対象データと、IDとをTxMS２６０へ送る（３４０）。TxMS２６０は、それらを受信し、受信したSQL命令（UPDATE）に従い、処理命令（UPDATE）と、更新前データの所在（DATA_pt）と、UPDATE対象データと、IDとをNVMS_DATA管理システム２７２へ送る（３４１）。NVMS_DATA管理システム２７２は、それらを受信し、受信した処理命令（UPDATE）に従い、NVMS_DATA２２０を作成し、受信したDATA_ptに対応したNEXT_pt２２５を、UPDATE対象データ（DATA２２１）の所在に更新する。このとき、Tx処理システム２５０やTxMS２６０は、NVMS_DATA管理システム２７２の処理終了を待たなくてもよい。
【００７８】
Tx処理システム２５０は、SQL命令（DELETE）と、更新前データの所在（DATA_pt）と、IDとをTxMS２６０へ送る（３５０）。TxMS２６０は、それらを受信し、受信したSQL命令（DELETE）に従い、処理命令（DELETE）と、更新前データの所在（DATA_pt）と、IDとをNVMS_DATA管理システム２７２へ送る（３５１）。NVMS_DATA管理システム２７２は、それらを受信し、受信した処理命令（DELETE）に従い、受信したDATA_ptに対応したNEXT_pt２２５を、DELETE対象データ（DATA２２１）の所在に更新する。このとき、Tx処理システム２５０やTxMS２６０は、NVMS_DATA管理システム２７２の処理終了を待たなくてもよい。
【００７９】
このような処理によって、複数データを同時にアップデート、インサート又はデリートすることが可能となる。
【００８０】
なお、UPDATE処理をアボートした場合、更新前データのNEXT_pt２２５がUPDATE対象データの所在を示したままになるが、そのUPDATE対象データのSTATE_pt２２２から特定されるSTATE２２１が“ABORT”となるので、管理プログラム２４０は、UPDATE処理が失敗したことがわかる。更に、管理プログラム２４０は、UPDATE処理のアボート後に、更新前データのNEXT_pt２２５を初期化してもよい。
【００８１】
また、UPDATE又はDELETE後のデータについてコミットが完了した場合、管理プログラム２４０は、更新前又は削除前のデータのFLAG２２４を“GARBAGE”に変更してもよい。管理プログラム２４０は、FLAG２２４“GARBAGE”に対応したデータについてガベージコレクションを実行してよい。
【００８２】
＜正常に起動及び終了するための処理に関する説明＞
【００８３】
図１２は、図９に示したNVMS_STATE２１０、NVMS_DATA２２０及びNVMS_TABLE２３０の詳細例と、記憶空間２００に格納される更なる情報であるSYSTEM_PARAM５４０とを示す。
【００８４】
NVMS_STATE２１０、NVMS_DATA２２０及びNVMS_TABLE２３０の各々の構成は、図９に示した構成と同じである。
【００８５】
SYSTEM_PARAM５４０は、例えば不揮発空間２０２に格納される。SYSTEM_PARAM５４０は、システム（例えば、計算機システム１１０Ｂ又は管理プログラム２４０）の状態や管理に必要なパラメータを含む。具体的には、例えば、SYSTEM_PARAM５４０は、正常な起動や終了を実現するためのSTART_STATUS５４１を保持する。START_STATUS５４１は、前回のTx処理の終了が正常終了か（“SUCCESS”）異常終了か（“FAILURE”）を示す。起動時のSTART_STATUS５４１が“FAILURE”であれば、前回の終了は異常終了であった（例えば意図しない終了であった又は終了が失敗であった）ことがわかる。
【００８６】
図１３は、NVMS２７０が有する更なる機能を示す。
【００８７】
NVMS２７０は、NVMS_STATE管理システム２７１及びNVMS_DATA管理システム２７２に加えて、NVMS_START管理システム２７３を有する。NVMS_START管理システム２７３は、起動及び終了を管理し、NVMS_STATE管理システム２７１及びNVMS_DATA管理システム２７２と連携して動作する。NVMS_START管理システム２７３は、SYSTEM_PARAM５４０のSTART_STATUS５４１を制御することで、正常な起動と終了を保証する。
【００８８】
図１４は、NVMS_START管理システム２７３のフローチャートである。
【００８９】
NVMS_START管理システム２７３は、ユーザ１００（計算機システム１１０Ａ）から起動（START）や終了（END）といった処理命令を受け付ける（Ｓ５００）。NVMS_START管理システム２７３は、受けた処理命令を判定する（Ｓ５１０）。ここで言う「起動」は、システム２７３（又はシステム２７３を含む管理プログラム２４０）の起動であり、「終了」は、システム２７３（又はシステム２７３を含む管理プログラム２４０）の終了である。
【００９０】
処理命令がSTARTの場合、NVMS_START管理システム２７３は、前回の終了が正常か否かの障害判定を行う（Ｓ５２０）。具体的には、その障害判定は、START_STATUS５４１が“SUCCESS”か“FAILURE”かの判定である。
【００９１】
START_STATUS５４１が“SUCCESS”の場合、NVMS_START管理システム２７３は、START_STATUS５４１を“FAILURE”に変更し（Ｓ５４０）、起動処理を終了する（Ｓ５５０）。
【００９２】
START_STATUS５４１が“FAILURE”の場合、NVMS_START管理システム２７３は、NVMS_STATE２１０の領域確認としてデータの異常を確認し修復する（Ｓ５２１）。また、NVMS_START管理システム２７３は、NVMS_TABLE２３０の領域を初期化する（Ｓ５２２）。最後に、NVMS_START管理システム２７３は、START_STATUS５４１を“FAILURE”に維持し（Ｓ５４０）、起動処理を終了する（Ｓ５５０）。なお、Ｓ５４０が無くてもSTART_STATUS５４１は“FAILURE”のままなので、Ｓ５４０はスキップされてもよい。
【００９３】
処理命令がENDの場合、NVMS_START管理システム２７３は、システムの終了処理を待つ（Ｓ５３０）。システム終了待ちでは、NVMS_START管理システム２７３は、少なくともTx処理が実行中でないことを確認する。Tx処理の実行中の確認方法として、例えば、NVMS_STATE２１０における全てのSTATE２１２が“PROCESSING”でないことを確認する方法、或いは、Tx処理を実行中のスレッドが存在しないことを確認する方法を挙げることができる。NVMS_START管理システム２７３は、システムの終了が確認できた場合、START_STATUS５４１を“SUCCESS”に変更し（Ｓ５４０）、終了処理を終了する（Ｓ５５０）。
【００９４】
図１５は、NVMS_STATE管理システム２７１のフローチャートのうち、図６に示したフローチャートとの差分を含んだ部分である。以下、図６との差分を主に説明する。
【００９５】
NVMS_STATE管理システム２７１は、受信した処理命令を判定する（Ｓ３１０）。処理命令がSTART又はENDの場合、NVMS_STATE管理システム２７１は終了する（Ｓ３４０）。
【００９６】
処理命令がUNDOの場合、NVMS_STATE管理システム２７１は、NVMS_STATE２１０に未判定のSTATE２１２があるか否かを判定する（Ｓ３５１）。
【００９７】
Ｓ３５１の結果、未判定のSTATE２１２が無ければ、NVMS_STATE管理システム２７１は終了する（Ｓ３４０）。
【００９８】
Ｓ３５１の結果、未判定のSTATE２１２があれば、NVMS_STATE管理システム２７１は、そのSTATE２１２が“PROCESSING”か否かを判定する（Ｓ３５２）。参照したSTATE２１２が“PROCESSING”であれば、NVMS_STATE管理システム２７１は、そのSTATE２１２を“PROCESSING”から“ABORT”に変更する（Ｓ３５３）。参照したSTATE２１２が“PROCESSING”以外であれば、Ｓ３５１を再度実行する。
【００９９】
図１６は、NVMS_DATA管理システム２７２のフローチャートのうち、図７に示したフローチャート（又は、図１０に示した部分を含んだフローチャート）との差分を含んだ部分である。以下、図７（及び図１０）との差分を主に説明する。
【０１００】
NVMS_DATA管理システム２７２は、受信した処理命令を判定する（Ｓ４１０）。処理命令が、START又はENDの場合、NVMS_DATA管理システム２７２は終了する（Ｓ４４０）。
【０１０１】
処理命令がUNDOの場合、NVMS_DATA管理システム２７２は、NVMS_TABLE２３０を初期化する（Ｓ４６０）。正常な終了がされなかった場合、NVMS_TABLE２３０には不要データが残っている可能性があるためである。NVMS_TABLE２３０の初期化によって、NVMS_TABLE２３０から全てのエントリ（或いは、STATE２１２“ABORT”に対応したTx処理に対応するエントリのみ）が削除される。Ｓ４６０の後、NVMS_DATA管理システム２７２は終了する（Ｓ４４０）。
【０１０２】
図１７は、起動及び終了のシーケンス図である。
【０１０３】
NVMS_START管理システム２７３は、ユーザ１００（計算機システム１１０Ａ）からの命令により実行され、命令としてSTART又はENDを受け付ける。
【０１０４】
ユーザ１００から命令（START）を受けた場合（３６０）、NVMS_START管理システム２７３は、START_STATUS５４１が“SUCCESS”か“FAILURE”かを判定する。
【０１０５】
START_STATUS５４１が“SUCCESS”の場合、NVMS_START管理システム２７３は、START_STATUS５４１を“FAILURE”に変更して、終了する。
【０１０６】
START_STATUS５４１が“FAILURE”の場合（３７０）、NVMS_START管理システム２７３は、NVMS_STATE管理システム２７１に処理命令（UNDO）を送ることでNVMS_STATE２１０を復元し（３７１）、NVMS_DATA管理システム２７２に処理命令（UNDO）を送ることでNVMS_TABLE２３０を初期化する（３７２）。START_STATUS５４１は“FAILURE”に維持される。なお、NVMS_STATE２１０の復元（３１０）では、STATE２１２が“PROCESSING”であるTx処理のSTATE２１２が“ABORT”に変更される。
【０１０７】
ユーザ１００から命令（END）を受けた場合（３８０）、NVMS_START管理システム２７３は、システム終了待ちとなる（例えば全てのTx処理の終了を待つ）。システム終了を検出した後、NVMS_START管理システム２７３は、START_STATUS５４１を“SUCCESS”に変更して、終了する。
【０１０８】
このような処理によって、正常な起動及び終了を実現することが可能となる。
【０１０９】
以下、実施形態を総括する。なお、総括の説明において、適宜、実施形態の変形例等の新たな記載を追加することができる。
【０１１０】
例えば、インメモリDBMSは、一般に、障害回復時には、ストレージからデータベースを揮発メモリに展開する（読み出す）処理やその後にストレージからログファイルを読み出し読み出したログファイルを揮発メモリ上のデータベースに反映する処理が必要になる。障害回復時にデータベースの読み出しを行わないことが考えられるが、そうすると、必要なデータをTx処理でメモリに展開するために度々ストレージにアクセスする必要がある。
【０１１１】
そこで、比較例１として、データベースを、ストレージに代えてNVMに配置することが考えられる。これにより、アクセスの高速化が期待でき、結果として、データベースを揮発メモリに展開したりログファイルをデータベースに反映したりする処理の高速化が期待できる。
【０１１２】
さらに、比較例２として、インメモリDBMSを採用し、データベースを、揮発メモリに代えてNVMに配置することも考えられる。これにより、更新前データと更新後データのいずれもNVMに残ることになり、ログファイルを不要にすることが期待される。ログファイルを不要にすることで、障害回復時にログファイルをデータベースに反映する処理を無くし、結果として、障害回復の高速化が期待される。
【０１１３】
しかし、NVMには、複数のデータ（例えばプロセッサのキャッシュにある複数のデータ）を同時に書き込むことができないので、データの整合性を保つことができないおそれがある。具体的には、例えば、データ１をNVMに書き込みその後にデータ２をNVMに書き込む必要があるケースにおいて、データ１をNVMに書き込んだ後であってデータ２をNVMに書き込む前に障害が生じると、データ２が書き込まれていないため、不整合が生じる。言い換えれば、第１の比較例では、NVMに存在するデータは、コミットしたデータであるが、第２の比較例では、コミットしていないデータもNVMに存在する。このため、比較例２の採用は困難であり、NVMは、比較例１のようにストレージの代替デバイスとして採用される（すなわちログファイルの格納先として採用される）ことになると考えられる。
【０１１４】
そこで、本実施形態では、管理プログラム２４０が、複数のデータの状態をTx処理毎に一元管理する。つまり、管理プログラム２４０が、Tx処理毎に、状態を管理し、且つ、複数のデータをTx処理に関連付ける。管理プログラム２４０は、複数のデータを不揮発空間２０２（例えばNVM）に書き込んだ後、その複数のデータが関連付いたTx処理の状態を非永続（“PROCESSING”）から永続（“COMMIT”）に変更する。これにより、データ量に依存せず複数のデータが同時に永続化される。
【０１１５】
本実施形態では、管理プログラム２４０により、下記の２つの規則が守られる。
（規則１）Tx処理の開始時の状態（“PROCESSING”）を、そのTx処理におけるいずれかのデータを不揮発空間２０２に書き込む前に、不揮発空間２０２に書き込む必要がある。つまり、状態“PROCESSING”を不揮発空間２０２に書いたことが保証されてから、Tx処理でのデータを不揮発空間２０２に書き込む必要がある。先に不揮発空間２０２にデータが書かれると、そのデータの関連先を示すポインタ（STATE_pt）が不明だからである。
（規則２）Tx処理をコミットする場合、そのTx処理に関付けられている全てのデータが不揮発空間２０２に書き込まれていることが確認された後に、Tx処理の状態を“PROCESSING”から“COMMIT”に変更する必要がある。なお、データは、SQL処理の都度に不揮発空間２０２に書き込まれる必要は無い。データは、Tx処理のコミット前に不揮発空間２０２にあればよい。
【０１１６】
本実施形態では、状態が“PROCESSING”であるTx処理の状態を“ABORT”にするだけで、障害回復処理が完了する。
【０１１７】
以上、一実施形態を説明したが、本発明は、この実施形態に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、本発明は、複数のデータの整合性を維持することが必要な他種の環境（データ管理システム）、例えば、ファイルシステム、又は、KVS（Key Value Store）にも適用できる。
【符号の説明】
【０１１８】
１１０Ｂ：計算機システム
【図１】
2017060941.tif 000003
【図２】
2017060941.tif 000004
【図３】
2017060941.tif 000005
【図４】
2017060941.tif 000006
【図５】
2017060941.tif 000007
【図６】
2017060941.tif 000008
【図７】
2017060941.tif 000009
【図８】
2017060941.tif 000010
【図９】
2017060941.tif 000011
【図１０】
2017060941.tif 000012
【図１１】
2017060941.tif 000013
【図１２】
2017060941.tif 000014
【図１３】
2017060941.tif 000015
【図１４】
2017060941.tif 000016
【図１５】
2017060941.tif 000017
【図１６】
2017060941.tif 000018
【図１７】
2017060941.tif 000019
【国際調査報告】
2017060941.tif 000020
2017060941.tif 000021