(57)【要約】  データベースのトランザクションのコミットのためのログ出力の応答を受けること無しに、そのトランザクションの結果に基づく別のトランザクションを開始することが行われ得る環境において、計算機システムが、データベースのトランザクションのコミットのためのログ出力が行われた場合、そのログ出力の応答を受けること無しにコミット完了を出力する。
2017006423.tif 000002
【特許請求の範囲】
【請求項１】
データベースのトランザクションのコミットのためのログ出力の応答を受けること無しに、そのトランザクションの結果に基づく別のトランザクションを開始する計算機システムであって、
トランザクションに関する情報を含んだ情報である管理情報を記憶する記憶部と、
データベースのトランザクションのコミットのために、前記管理情報に基づき生成されたログを出力し、そのログ出力の応答を受けること無しにコミット完了を出力するプロセッサと
を有する計算機システム。
【請求項２】
前記記憶部は、コミットのためのログ出力が行われてからそのログ出力の応答を受ける前にコミット完了を出力することであるロジカルコミット出力を実行するか否かを表す情報である出力制御情報を記憶し、
前記プロセッサは、ロジカルコミット出力を実行することを前記出力制御情報が表していれば、トランザクションのコミットのために行ったログ出力の応答を受ける前にそのコミットの完了を出力する、
請求項１記載の計算機システム。
【請求項３】
前記プロセッサは、
ロジカルコミット出力を行うか否かの指定である出力指定を受け付けるユーザインターフェースを提供し、
前記ユーザインターフェースを通じて出力指定を受け、
前記受けた出力指定に従い前記出力制御情報を更新する、
請求項２記載の計算機システム。
【請求項４】
前記記憶部は、トランザクションのコミットのためのログ出力の応答を受けること無しにそのトランザクションの結果に基づく別のトランザクションを開始する処理モードである投機実行処理モードがオンか否かを表す情報であるモード制御情報を記憶し、
前記プロセッサは、前記投機実行処理モードがオンであることを前記モード制御情報が表している場合、トランザクションのコミットのためのログ出力の応答を受けること無しにそのトランザクションの結果に基づく別のトランザクションを開始するようになっており、
前記プロセッサは、
前記投機実行処理モードがオンか否かの指定であるモード指定を、前記ユーザインターフェース又は別のユーザインターフェースを通じて受け、
前記受けたモード指定に従い前記モード制御情報を更新する、
請求項３記載の計算機システム。
【請求項５】
前記プロセッサが、
ロジカルコミット出力を実行しないことを前記出力制御情報が表していれば、トランザクションのコミットのために行ったログ出力の応答を受ける前にコミット完了を出力せず、
前記出力制御情報が、少なくとも、ロジカルコミット出力を実行しないことを表していれば、トランザクションのコミットのために行ったログ出力の応答を受け、且つ、そのトランザクションに関わる生成トランザクションの各々の状態がフィジカルコミットの場合、コミット完了を出力し、
フィジカルコミットは、トランザクションのコミットのためのログ出力の応答を受け、且つ、そのトランザクションに関わる生成トランザクションの各々の状態がフィジカルコミットであることを意味する状態であり、
前記生成トランザクションの各々は、そのトランザクションにより参照されたレコードを生成したトランザクションである、
請求項２記載の計算機システム。
【請求項６】
いずれかのトランザクションである対象トランザクションの状態として、
前記対象トランザクションのコミットのためのログ出力が行われてからそのログ出力の応答を受ける前の状態であるロジカルコミットと、
前記対象トランザクションのコミットのためのログ出力の応答を受け、且つ、前記対象トランザクションに関わる生成トランザクションの各々の状態がフィジカルコミットであることを意味する状態であるフィジカルコミットと
があり、
前記生成トランザクションの各々は、前記対象トランザクションにより参照されたレコードを生成したトランザクションである、
前記プロセッサにより出力されたログは、そのログに対応したトランザクションの状態がフィジカルコミットであるか否かを示す情報であるコミット状態情報を含む、
請求項１記載の計算機システム。
【請求項７】
前記対象トランザクションに対応したログは、前記対象トランザクションの参照に関する情報を含んだ情報である参照情報を含み、
前記プロセッサは、前記参照情報に基づき、前記生成トランザクションの各々の状態がフィジカルコミットであるか否かを判定する、
請求項６記載の計算機システム。
【請求項８】
前記参照情報は、前記生成トランザクションの各々について、その生成トランザクションのＩＤを含み、
前記プロセッサは、前記参照情報から特定された各生成トランザクションのＩＤに対応した現在のトランザクション状態を特定することで、前記生成トランザクションの各々の状態がフィジカルコミットであるか否かを判定する、
請求項７記載の計算機システム。
【請求項９】
前記プロセッサは、
出力対象のログに含まれる参照情報に対応した生成トランザクションの各々の現在の状態がフィジカルコミットか否かの判定を、前記出力対象のログを出力するときに実行し、
その判定の結果が肯定の場合、前記出力対象のログが含むコミット状態情報を、フィジカルコミットを表す情報に変更してから、前記出力対象のログを出力する、
請求項６記載の計算機システム。
【請求項１０】
前記プロセッサは、
生成トランザクションの状態がフィジカルコミットでなければ、その生成トランザクションのＩＤを前記対象トランザクションのログに記録し、
生成トランザクションの状態がフィジカルコミットであれば、その生成トランザクションのＩＤを前記対象トランザクションのログに記録しない、
請求項９記載の計算機システム。
【請求項１１】
前記プロセッサは、出力済のログの各々について、そのログが含むコミット状態情報がフィジカルコミットを表していれば、データベースリカバリ処理においてそのログを適用する、
請求項６記載の計算機システム。
【請求項１２】
前記プロセッサは、出力済のログの各々について、そのログが含むコミット状態情報がフィジカルコミットを表していなければ、
（ｘ１）そのログに対応したトランザクションに関わる生成トランザクションの各々の現在の状態がフィジカルコミットか否かを判定し、
（ｘ２）（ｘ１）の判定の結果が肯定の場合、前記データベースリカバリ処理においてそのログを適用し、且つ、そのログに対応したトランザクションの現在の状態をフィジカルコミットに変更する、
請求項１１記載の計算機システム。
【請求項１３】
前記プロセッサは、前記データベースリカバリ処理において、ログが読み出される都度にログ適用処理を行い、
前記ログ適用処理では、読み出されたログについての（ｘ１）の判定と、過去のログ適用処理において（ｘ１）の判定の結果が否定となったログについての再度の（ｘ１）の判定とが行われる、
請求項１２記載の計算機システム。
【請求項１４】
データベースのトランザクションのコミットのためのログ出力の応答を受けること無しに、そのトランザクションの結果に基づく別のトランザクションを開始するデータベース管理方法において、
データベースのトランザクションのコミットのためのログ出力が行われたことを検出し、
検出されたログ出力の応答を受けること無しにコミット完了を出力する、
データベース管理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、概して、データベース管理に関する。
【背景技術】
【０００２】
データベースへの変更は、一般に、いわゆる永続化デバイス（典型的には不揮発記憶デバイス）への書込みが完了した場合に、完了する。ところが、ハードディスクドライブに代表されるように、永続化デバイスへの書込みにかかる時間は、メインメモリへの書込みにかかる時間に比べて長い。そのため、先行のトランザクションが更新したレコードを別のトランザクションが参照する場合、その先行のトランザクションのログが出力されてその完了応答を受けるのを待つ必要がある。【０００３】
特許文献１には、他のトランザクションとの衝突が起こっていないならば、先行トランザクションのログ出力が開始されると同時に、ログ出力の完了応答を待たずに、先行トランザクションが更新したレコードを別のトランザクションが参照することを可能とする技術（いわゆる投機実行処理の技術）を開示している。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特許４２９５３３３号
【発明の概要】
【発明が解決しようとする課題】
【０００５】
昨今、データベースのテーブルやインデックスをメモリ上に配置するインメモリデータベースが普及してきている。一方で、トランザクションのログの出力先デバイスは、一般に、データベースが配置されるメモリよりもＩ／Ｏ（Input/Output）応答性能が低いデバイスである。このため、データベースのトランザクション処理の全体において、トランザクションのコミットのためのログ出力からそのログ出力の応答を受信するまでの時間が占める割合は小さくなく、故に、投機実行処理によるスループット向上を認識しづらい。【０００６】
この種の課題は、インメモリデータベースが採用されているか否かや、ログの出力先デバイスのＩ／Ｏ応答性能に関わらずにあり得る。
【課題を解決するための手段】
【０００７】
データベースのトランザクションのコミットのためのログ出力の応答を受けること無しに、そのトランザクションの結果に基づく別のトランザクションを開始することが行われ得る環境において、計算機システムが、データベースのトランザクションのコミットのためのログ出力が行われた場合、そのログ出力の応答を受けること無しにコミット完了を出力する。この計算機システムは、ＤＢＭＳを実行するサーバシステム（１以上のサーバ計算機）と、サーバシステムに要求（例えばクエリ）を発行するクライアントシステム（１以上のクライアント計算機）とのうちの少なくとも１つを含む。
【発明の効果】
【０００８】
データベースの投機実行処理によるスループット向上を認識し易い。
【図面の簡単な説明】
【０００９】
【図１】実施形態に係るシステム全体の構成例を示す。
【図２】ＤＢＭＳ（データベース管理システム）の構成例と、ＤＢＭＳ、ＯＳ（Operating System）、Ｉ／Ｏアダプタ及び外部ストレージ装置間の関係例とを示す。
【図３】Ｔｘ（トランザクション）管理部の構成例を示す。
【図４】トログ管理部の構成例を示す。
【図５】Ｔｘ処理の流れの一例を示す。
【図６】ログ出力処理の流れの一例を示す。
【図７】ログの構成例を示す。
【図８】データベースリカバリ処理の流れの一例を示す。
【図９】ログ適用処理の流れの一例を示す。
【図１０】クライアントとＤＢＭＳ間の通信の一例を示すシーケンス図である。
【図１１】クライアントとＤＢＭＳ間の通信の別の一例を示すシーケンス図である。
【図１２】Ｉ／Ｆ制御処理の流れの一例を示す。
【図１３】設定ユーザインターフェースの一例を示す。
【発明を実施するための形態】
【００１０】
以下、図面を参照しながら、一実施形態を説明する。
【００１１】
以下の説明では、データベース管理システム（以下、ＤＢＭＳ）へのクエリの発行元としては、ＤＢＭＳの内部のコンピュータプログラムであってもよいし、ＤＢＭＳの外部のコンピュータプログラム（例えば、クライアントシステムで実行されるコンピュータプログラム）であってよい。以下の実施形態では、クエリ発行元は、クライアント計算機である。
【００１２】
また、以下の説明では、Ｉ／Ｏ（Input/Output）要求は、ライト要求又はリード要求であり、アクセス要求と呼ばれてもよい。
【００１３】
また、以下の説明では、「ｂｂｂ部」を主語として説明を行う場合があるが、これら機能部は、プロセッサによって実行されることで定められた処理をメモリ及び通信ポート（ネットワークＩ／Ｆ）を用いながら行うため、プロセッサを主語とした説明としてもよい。プロセッサは、典型的には、マイクロプロセッサ（例えばＣＰＵ（Central Processing Unit））を含んでおり、更に、専用ハードウェア（例えばＡＳＩＣ（Application Specific Integrated Circuit）又はＦＰＧＡ（Field-Programmable GateArray））を含んでもよい。また、これら機能部を主語として開示された処理は、計算機が行う処理としてもよい。また、これら機能部の一部または全ては、専用ハードウェアによって実現されてもよい。また、各種機能部は、プログラム配布サーバや、計算機が読み取り可能な記憶媒体によって各計算機にインストールされてもよい。また，各種機能部及びサーバは１つの計算機にインストールされ実行されても良いし、複数の計算機にインストールされ実行されても良い。プロセッサは、制御部の一例であり、処理の一部または全部を行うハードウェア回路を含んでもよい。プログラムは、プログラムソースから計算機のような装置にインストールされてもよい。プログラムソースは、例えば、プログラム配布サーバまたは計算機が読み取り可能な記憶メディアであってもよい。プログラムソースがプログラム配布サーバの場合、プログラム配布サーバはプロセッサ（例えばＣＰＵ）と記憶部を含み、記憶部はさらに配布プログラムと配布対象であるプログラムとを記憶してよい。そして、プログラム配布サーバのプロセッサが配布プログラムを実行することで、プログラム配布サーバのプロセッサは配布対象のプログラムを他の計算機に配布してよい。また、以下の説明において、２以上のプログラムが１つのプログラムとして実現されてもよいし、１つのプログラムが２以上のプログラムとして実現されてもよい。
【００１４】
また、以下の説明において、「スレッド」は、ＯＳスレッドであってもよいし疑似スレッドであってもよい。ＯＳスレッドは、ＯＳ（Operating System）によって管理されるスレッド（例えばカーネルとライブラリによって管理されるスレッド）であり、リアルスレッドと言うこともできる。一方、「擬似スレッド」は、ＤＢＭＳによって管理されるスレッドである。ＯＳスレッドが、ＤＢＭＳによって疑似的に細分化されることで、複数の疑似スレッドを含むことができる。
【００１５】
また、以下の説明において、「記憶部」は、メモリを含んだ１以上の記憶デバイスでよい。例えば、記憶部は、主記憶デバイス（典型的には揮発性のメモリ）及び補助記憶デバイス（典型的には不揮発性の記憶デバイス）のうちの少なくとも主記憶デバイスでよい。
【００１６】
また、以下の説明において、サーバシステム（例えばデータベースサーバ）が「表示用情報を表示する」ことは、サーバシステムが有する表示デバイスに表示用情報を表示することであってもよいし、外部システム（例えばクライアントシステム）に表示用情報を送信することであってもよい（後者の場合は外部システムによって表示用情報が表示される）。
【００１７】
図１は、実施形態に係るシステム全体の構成例を示す。
【００１８】
データベースサーバ４０１に、外部ストレージ装置４０２が、例えば通信ネットワーク４０３を介して接続されている。また、データベースサーバ４０１に、クライアント計算機（以下、クライアント）４０５が、例えば通信ネットワーク４０４を介して接続されている。
【００１９】
クライアント４０５は、クライアントシステムの一例である。クライアント４０５は、データベースサーバ４０１に要求を出し、その要求の処理結果としての応答をデータベースサーバ４０１から受信する。要求は、例えば、クエリである。クライアント４０５は、クエリ発行元の一例である。
【００２０】
データベースサーバ４０１は、サーバシステムの一例である。データベースサーバ４０１は、計算機であって、例えば、パーソナルコンピュータ、ワークステーション又はメインフレームであってよく、もしくは、これらの計算機において仮想化プログラムによって構成された仮想的な計算機であってよい。データベースサーバ４０１は、Ｉ／Ｏアダプタ４０９、Ｉ／Ｏアダプタ４１３、メモリ（典型的にはメインメモリ）４１６、記憶デバイス４１５及びそれらに接続されたプロセッサ４１４を有する。
【００２１】
プロセッサ４１４は、例えば、マイクロプロセッサ、又は、マイクロプロセッサと専用ハードウェア回路を含んだモジュールでよい。プロセッサ４１４は、コンピュータプログラムを実行する。プロセッサ４１４により実行されるコンピュータプログラムは、例えば、オペレーティングシステム（ＯＳ）１１７及びデータベース管理システム（ＤＢＭＳ）４１２である。
【００２２】
メモリ４１６は、例えば、揮発性のＤＲＡＭ（Dynamic Random Access Memory）等であり、プロセッサ４１４によって実行されるプログラムと、プログラムが使用するデータを一時的に記憶する。記憶デバイス４１５は、不揮発性であり、例えば、ＨＤＤ（Hard Disk Drive）又はＳＳＤ（Solid State Drive）である。記憶デバイス４１５は、プログラム及びプログラムが使用するデータを格納してよい。メモリ４１６及び記憶デバイス４１５のうちの少なくともメモリ４１６が記憶部の一例である。
【００２３】
Ｉ／Ｏアダプタ４０９は、通信ネットワーク４０４とデータベースサーバ４０１を接続する。Ｉ／Ｏアダプタ４１３は、通信ネットワーク４０３とデータベースサーバ４０１を接続する。Ｉ／Ｏアダプタ４０９及び４１３の少なくとも１つが、インターフェースデバイスの一例である。
【００２４】
外部ストレージ装置４０２は、複数の記憶デバイスを含む記憶デバイス群４５１を有する装置であり、例えば、ディスクアレイ装置であるが、それに代えて、単一の記憶デバイスであってもよい。外部ストレージ装置４０２は、ログファイル３０１を記憶する。外部ストレージ装置４０２は、データベースサーバ４０１からログのＩ／Ｏ要求を受け付け、当該Ｉ／Ｏ要求に従いデータ（例えばログ）の読み書きを行い、その結果をデータベースサーバ４０１に返す。なお、記憶デバイス群４５１が有する記憶デバイスは、不揮発性の記憶媒体を有するデバイスであって、例えば、ＨＤＤ又はＳＳＤである。記憶デバイス群４５１は、ＲＡＩＤ（Redundant Array of Independent Disks）グループでよく、所定のＲＡＩＤレベルでデータを記憶してもよい。記憶デバイス群４５１の記憶空間に基づく論理的な記憶デバイス（例えば、論理ユニット、論理ボリューム、ファイルシステムボリューム）が、データベースサーバ４０１に提供され、当該論理的な記憶デバイス上にログファイル３０１が格納されてもよい。なお、本実施形態において、ログファイル３０１は、ログ格納領域の一例である。
【００２５】
外部ストレージ装置４０２は、記憶デバイス群４５１に加えて、Ｉ／Ｏアダプタ４４１及びこれらに接続されたストレージコントローラ４４２を有する。Ｉ／Ｏアダプタ４４１は、外部ストレージ装置４０２を通信ネットワーク４０３に接続し、これを介して、データベースサーバ４０１と接続される。通信ネットワーク４０３を介した通信プロトコルとしては、例えば、ファイバチャネル（ＦＣ）、ＳＣＳＩ（Small  Computer System Interface）、又は、ＴＣＰ／ＩＰ（Transmission Control Protocol／Internet Protocol）が採用されてよい。例えば、ファイバチャネルもしくはＳＣＳＩが採用される場合、Ｉ／Ｏアダプタ４４１（及び４１３）は、ホストバスアダプタと呼ばれることがある。ストレージコントローラ４４２は、例えば、メモリ及びプロセッサを含み、データベースサーバ４０１からのＩ／Ｏ要求に応じて、ログファイル３０１を格納した記憶デバイス群４５１との間でデータの読出し、もしくは、書込みを行う。
【００２６】
図２は、ＤＢＭＳ４１２の構成例と、ＤＢＭＳ４１２、ＯＳ１１７、Ｉ／Ｏアダプタ４１３及び外部ストレージ装置４０２間の関係例とを示す。
【００２７】
ＤＢＭＳ４１２は、インメモリデータベースである。ＤＢＭＳ４１２は、データベース（例えばテーブル１１１及びインデクス１１２）を、メモリ４１６上に配置する。更に、ＤＢＭＳ４１２は、ロック機構１１６を含んでよい。ロック機構１１６は、２以上のスレッド１１０が競合することを避けるためである。ロック機構１１６は、ロックの取得済か否かを表す情報でよい。例えば、ロック機構１１６は、ロック取得済なら値「１」でよくロック未取得なら値「０」でよい。
【００２８】
ＤＢＭＳ４１２は、Ｔｘ（トランザクション）管理部１１３とログバッファ１１４とログ管理部１１５を有する。Ｔｘ管理部１１３は実行中のＴｘとその状態（特に後述のコミット状態）を管理する。ログバッファ１１４は、テーブル１１１やインデクス１１２への更新履歴を含んだログを一時格納する。ログ管理部１１５は、ログファイル３０１およびログファイルへのログ書き出しを管理する。
【００２９】
ＤＢＭＳ４１２は、システム情報２４を有する。システム情報２４は、管理情報に含まれる情報の一例である。システム情報２４は、出力制御情報２６と、モード制御情報２８とを含む。出力制御情報２６は、コミットのためのログ出力が行われてからそのログ出力の応答を受ける前にコミット完了を出力（例えば表示）することであるロジカルコミット出力を実行するか否かを表す情報である。モード制御情報２８は、Ｔｘのコミットのためのログ出力の応答を受けること無しにそのＴｘの結果に基づく別のＴｘを開始する処理モードである投機実行処理モードがオンか否かを表す情報である。すなわち、ＤＢＭＳ４１２は、システム情報２４中のモード制御情報２８に従い、投機実行処理を行うか否かを選択できる。更に、ＤＢＭＳ４１２は、システム情報２４中の出力制御情報２６に従い、投機実行処理においてロジカルコミット出力を実行するか否かを選択できる。本実施形態では、Ｔｘ毎に、投機実行処理モードにおけるコミット状態として、フィジカルコミットに加えてロジカルコミットという状態が管理される。「フィジカルコミット」は、Ｔｘのコミットのためのログ出力の応答を受け、且つ、そのＴｘに関わる全ての生成ＴｘのＴｘ状態がフィジカルコミットであることを意味する状態である。Ｔｘに関わる生成Ｔｘとは、Ｔｘにより参照されたレコードを生成（更新）したＴｘである。一方、「ロジカルコミット」は、Ｔｘのコミットのためのログ出力が行われてからそのログ出力の応答を受ける前の状態である。
【００３０】
ＤＢＭＳ４１２は、クエリ発行元からクエリを受信し、受信したクエリの実行において、１又は複数のＴｘを実行する。具体的には、ＤＢＭＳ４１２は、クエリ受付部４２１、クエリ実行プラン生成部４２２及びクエリ実行部４２４を有する。
【００３１】
クエリ受付部４２１は、クエリ発行元が発行するクエリを受け付ける。クエリは、例えば、構造化問合せ言語（ＳＱＬ（Structured Query Language））によって記述される。１つのクエリで複数のＴｘが記述されていてもよいし、複数のクエリで複数のＴｘが記述されてもよい。
【００３２】
クエリ実行プラン生成部４２２は、クエリ受付部４２１が受け付けたクエリから、当該クエリを実行するために必要な１以上のデータベースオペレーションを含むクエリ実行プランを生成する。クエリ実行プランは、例えば、１以上のデータベースオペレーションと、データベースオペレーションの実行順序の関係を含む情報であり、クエリ実行プラン情報４２３として格納される。クエリ実行プランは、データベースオペレーションをノード、データベースオペレーションの実行順序の関係をエッジとする木構造で表されることがある。
【００３３】
クエリ実行部４２４は、クエリ実行プラン生成部４２２が生成したクエリ実行プランに従って、クエリ受付部４２１が受け付けたクエリを実行し、その実行結果をクエリ発行元に返す。この際、クエリ実行部４２４は、データベースオペレーションの実行に必要なデータの読出し要求（参照要求）を発行し、その読出し要求に従いテーブル１１１から読み出されたデータを使用して、そのデータベースオペレーション（例えば、読み出されたデータ（値）を用いて新たなデータを算出し、読出し元レコードにおけるデータを算出後のデータに更新する書込み要求を発行する）を行う。クエリ実行部４２４は、データベースオペレーションを、スレッド１１０を実行することにより行う。なお、ＤＢＭＳ４１２において、複数のスレッド１１０が並行して実行される。このため、プロセッサ４１４は、複数のコアを有する。複数のコアは、１又は複数のＣＰＵに存在する。スレッド１１０は、タスクと呼ばれてもよい。１つのスレッド１１０により、１以上のデータベースオペレーションに対応した１つのＴｘが実行されてよい 。以下、クエリ実行部４２４がスレッド１１０を実行することにより行われる処理の主語を、スレッド１１０、とすることができる。
【００３４】
クエリ実行部４２４（スレッド１１０）は、Ｔｘの実行において、外部ストレージ装置４０２内のログファイル３０１にログを書き込むために、外部ストレージ装置４０２に対するＩ／Ｏ要求をＯＳ１１７に発行する。ＯＳ１１７は、そのＩ／Ｏ要求を受け付け、外部ストレージ装置４０２へＩ／Ｏ要求を発行する。
【００３５】
I／Ｏアダプタ４１３には、複数のＩ／Ｏキュー２０１が用意される。Ｔｘの処理において、スレッド１１０が、ログの書込みのためのＩ／Ｏ要求を発行するが、Ｉ／Ｏキュー２０１には、そのＩ／Ｏ要求が格納される。具体的には、Ｉ／Ｏ要求は、ＯＳ１１７によりＩ／Ｏキュー２０１に格納される。
【００３６】
外部ストレージ装置４０２が、ログファイル３０１を記憶する。ログファイル３０１に、Ｉ／Ｏ要求の書込み対象のログが記録される。なお、外部ストレージ装置４０２は、ログ出力先デバイスの一例であって、メモリ４１６よりもＩ／Ｏ応答性能の低い記憶デバイスの一例である。ログファイル３０１は、外部ストレージ装置４０２に代えて、メモリ４１６よりもＩ／Ｏ応答性能の低い別の記憶デバイスに存在してもよい。例えば、ログファイル３０１も、メモリ４１６に存在してもよい。
【００３７】
本実施形態では、スレッド１１０と、Ｉ／Ｏキュー２０１が、１：１で対応している。つまり、スレッド１１０毎に、１つのＩ／Ｏキュー２０１が割り当てられている。例えば、スレッド１１０が、テーブル１１１のレコードを更新したことを表すログの書込み要求を、ログファイル３０１に対して発行するようになっている。発行された書込み要求は、ＯＳ１１７に送られる。ＯＳ１１７が、ログファイル３０１に対する書込み要求を受けて、その書込み要求を、そのスレッド１１０に対応するＩ／Ｏキュー２０１に格納する。Ｉ／Ｏキュー２０１に格納された書込み要求は、ＯＳ１１７によりＩ／Ｏキュー２０１から外部ストレージ装置４０２に送られる。それにより、その書込み要求の書込み対象データであるログが、ログファイル３０１に書き込まれる。
【００３８】
図２に示すＤＢＭＳ４１２の構成は一例に過ぎない。例えば、或る構成要素は複数の構成要素に分割されていてもよく、複数の構成要素が１つの構成要素に統合されていてもよい。
【００３９】
図３は、Ｔｘ管理部１１３の構成例を示す。
【００４０】
Ｔｘ管理部１１３は、Ｔｘ状態情報１３０とＴｘ情報１４０とを有する。
【００４１】
Ｔｘ状態情報１３０は、実行中のＴｘ毎に、Ｔｘ状態エントリ１３１を有する。Ｔｘ状態エントリ１３１は、ＴｘＩＤ、Ｔｘ状態及びＴｘ情報ポインタといった情報を含む。ＴｘＩＤは、ＴｘのＩＤである。Ｔｘ状態としては、例えば、ビギン、セレクト、アップデート、インサート、ロジカルコミット、フィジカルコミット及びその他がある。セレクト、アップデート及びインサートは、ＳＱＬ状態に属する状態の一例である。ロジカルコミット及びフィジカルコミットは、コミット状態に属する状態の一例である。Ｔｘ情報ポインタは、Ｔｘ情報１４０へのポインタである。Ｔｘ状態エントリ１３１が示すＴｘ状態が、そのエントリ１３１に対応したＴｘの現在の状態である。
【００４２】
Ｔｘ情報１４０は、Ｔｘ毎に存在する。Ｔｘ情報１４０は、リードセット１５０とライトセット１６０を含む。以下、１つのＴｘを例に取り、Ｔｘ情報１４０の詳細を説明する。なお、そのＴｘを、図３の説明において「対象Ｔｘ」と呼ぶ。
【００４３】
リードセット１５０は、対象Ｔｘが参照したレコードに関する情報、別の言い方をすれば、対象Ｔｘが参照したレコードを生成したＴｘ（以下、生成Ｔｘ）に関する情報を含む。具体的には、リードセット１５０は、対象Ｔｘが参照したレコード毎に、参照レコードエントリ１５１を有する。参照レコードエントリ１５１は、レコードＩＤ、値及びＴｘＩＤといった情報を有する。レコードＩＤは、対象Ｔｘが参照したレコードのＩＤである。値は、対象Ｔｘが参照したレコードにおける各カラム値（カラムにおける値）である。ＴｘＩＤは、対象Ｔｘが参照したレコードを生成した生成ＴｘのＩＤである。
【００４４】
ライトセット１６０は、対象Ｔｘが更新したレコードに関する情報を含む。具体的には、ライトセット１６０は、対象Ｔｘが更新したレコード毎に、更新レコードエントリ１６１を有する。更新レコードエントリ１６１は、レコードＩＤ及び値といった情報を有する。レコードＩＤは、対象Ｔｘが更新（生成）したレコードのＩＤである。値は、対象Ｔｘが更新した値（レコードにおける値）である。
【００４５】
Ｔｘ管理の一例は次の通りである。Ｔｘのビギンのときに、Ｔｘ管理部１１３が、Ｔｘ状態情報１３０にＴｘ状態エントリ１３１を追加し、且つ、Ｔｘ情報１４０を追加する。Ｔｘ管理部１１３は、追加されたＴｘ状態エントリ１３１に、開始されたＴｘのＴｘＩＤと、Ｔｘ状態“ビギン”と、追加されたＴｘ情報１４０へのＴｘ情報ポインタとを登録する。その後、例えば、そのＴｘにおいてセレクトのとき、Ｔｘ管理部１１３は、セレクトされたレコードの情報として、追加されたＴｘ情報１４０（Ｔｘ情報ポインタに繋がっているＴｘ情報１４０）内のリードセット１５０に、セレクトの結果、具体的には、参照されたレコード毎の参照レコードエントリ１５１を書く。参照レコードエントリ１５１に登録されるＴｘＩＤ（生成ＴｘのＴｘＩＤ）は、参照されたレコードＩＤと同じレコードＩＤを含んだライトセット１６０に対応するＴｘのＴｘＩＤである。Ｔｘが行う処理の結果に応じて、Ｔｘ状態（そのＴｘに対応したエントリ１３１内のＴｘ状態）が、Ｔｘ管理部１１３により、アップデート、インサート、ロジカルコミット又はフィジカルコミット等に更新される。
【００４６】
図４は、ログ管理部１１５の構成例を示す。
【００４７】
ログ管理部１１５は、ロック機構１２１と、ログファイルアドレス１２２とを有する。
【００４８】
ロック機構１２１も、図２に示したロック機構１１６と同様、ログ管理部１１５のロックの取得済か否かを表すデータでよい。例えば、ロック機構１２１は、ロック取得済なら値「１」でよくロック未取得なら値「０」でよい。ログファイルアドレス１２２の書込み又は読出しのためには、ロック機構１２１のロックが取得されていなければならない。
【００４９】
ログファイルアドレス１２２は、ログファイル３０１におけるログの書込み先アドレスである。ログファイルアドレス１２２が表すアドレス（値）は、ログファイル３０１にログを書き出す度に出力するログのサイズ分だけ加算される。
【００５０】
図５は、Ｔｘ処理の流れの一例を示す。なお、以下の説明では、１つのＴｘを例に取り説明する。そのＴｘを、図５〜図７の説明において、「対象Ｔｘ」と呼ぶ。
【００５１】
クエリ実行部４２４が、対象Ｔｘが開始されると、対象Ｔｘに対応した指示（クエリ中の指示）に基づいて、リードセット１５０／ライトセット１６０の生成を行う（Ｓ５０１）。対象Ｔｘのビギンの時点では、テーブル１１１及びインデクス１１２の変更は行われない。その後、セレクト及びアップデート等が行われることで、テーブル１１１及びインデクス１１２のうちの参照又は更新等が行われる。その後、コミットが行われることになる。
【００５２】
クエリ実行部４２４が、コミット判定を行う（Ｓ５０２）。コミット判定では、例えば、対象Ｔｘがリードセット１５０／ライトセット１６０に基づいて行うテーブル１１１及びインデクス１１２への変更が他のＴｘとの整合性を保てているかどうかがデータベースのアイソレーションレベルに基づき判定される。
【００５３】
コミット判定がＮＧの場合（Ｓ５０３：Ｎｏ）、クエリ実行部４２４は、アボート処理を行い（Ｓ５０７）、アボート完了通知を出して（Ｓ５０８）、対象Ｔｘを終了する。
【００５４】
コミット判定がＯＫの場合（Ｓ５０３：Ｙｅｓ）、クエリ実行部４２４は、ログ出力処理を実行し（Ｓ５０４）、対象Ｔｘを終了する。ログ出力処理において、少なくともフィジカルコミットに従うコミット完了通知が行われる。
【００５５】
図６は、ログ出力処理（図５のＳ５０４）の流れの一例を示す。
【００５６】
クエリ実行部４２４が、ログの一時記憶のための領域をログバッファ１１４から確保する。確保された領域に、ログ、具体的には、ログの構成要素となる情報が書き込まれることになる。図７が、ログの構成例を示す。ログ３０は、１つのＴｘにつき１つ（又は複数）存在する。ログ３０は、ログヘッダ３１とログ本体３２から構成されている。
【００５７】
ログヘッダ３１は、ログサイズ３３とコミットフラグ３４とを含む。ログサイズ３３は、ログ３０のサイズを表す。コミットフラグ３４は、ログ３０に対応する対象Ｔｘの生成Ｔｘの各々の現在（ログ３０の生成時）のＴｘ状態がフィジカルコミットか否か、言い換えれば、対象ＴｘのＴｘ状態がフィジカルコミットか否かを表す情報である。コミットフラグ３４が、コミット状態情報の一例である。
【００５８】
ログ本体３２は、ＴｘＩＤ３５と、ライトセット３６と、リードセット３７とを含む。ＴｘＩＤ３５は、ログ３０に対応する対象ＴｘのＴｘＩＤである。ライトセット３６は、対象Ｔｘに対応したＴｘ情報（以下、対象Ｔｘ情報）１４０内のライトセット１６０の複製である。リードセット３７は、対象Ｔｘ情報１４０内のリードセット１５０の複製と、参照レコードエントリ毎にＴｘ状態とを含む。参照レコードエントリに関連付けられるＴｘ状態は、そのエントリに対応した生成ＴｘのＴｘ状態である。なお、ログ３０には、生成ＴｘのＴｘ状態が記録されないでもよい。
【００５９】
さて、図６に示すように、クエリ実行部４２４が、対象Ｔｘ情報１４０内の全てのリードセット１５０及びライトセット１６０を対象Ｔｘのログに記録済か否かを判定する（Ｓ６０１）。
【００６０】
Ｓ６０１の判定結果が否定の場合（Ｓ６０１：Ｎｏ）、クエリ実行部４２４は、対象Ｔｘ情報１４０から未だログ３０に記録されていないリードセット１５０又はライトセット１６０を対象Ｔｘ情報１４０から読み出す（Ｓ６０２）。クエリ実行部４２４は、クエリ実行部４２４は、読み出したリードセット１５０又はライトセット１６０をログに記録する（Ｓ６０３）。Ｓ６０２で読み出されたセットがリードセット１５０の場合、Ｓ６０３では、クエリ実行部４２４は、ログ３０に記録されたリードセット３７内の各参照レコードエントリに、その参照レコードエントリに対応した生成Ｔｘの現在のＴｘ状態（Ｔｘ状態情報１３０から特定されるＴｘ状態）を関連付ける。関連付けられたＴｘ状態もログ３０に記録される。但し、Ｓ６０３では、ログ３０には、現在のＴｘ状態がフィジカルコミットである生成Ｔｘに対応した参照レコードエントリは、ログ３０に記録されない。具体的には、例えば、クエリ実行部４２４が、読み出されたリードセット１５０内の各参照レコードエントリについて、生成Ｔｘの現在のＴｘ状態がフィジカルコミットであるか否かを判定し、その判定結果が肯定の参照レコードエントリをログ３０に記録しない。これにより、ログ３０のサイズを削減できる。
【００６１】
Ｓ６０１の判定結果が肯定の場合（Ｓ６０１：Ｙｅｓ）、クエリ実行部４２４は、ログバッファ１１４上におけるログ３０のサイズを計算し（Ｓ６０５）、計算したサイズを基に、そのログの出力先ログファイル３０１のためのアドレスを確保する（ログファイルアドレスの加算）（Ｓ６０６）。なお、出力先ログファイル３０１は、対象Ｔｘを実行するスレッド１１０に割り当てられたログファイル３０１でよい。すなわち、各スレッド１１０にログファイル３０１が割り当てられていてよい。
【００６２】
更に、クエリ実行部４２４は、ログ３０内のリードセット３７の各参照レコードエントリについて、生成Ｔｘの現在のＴｘ状態を、Ｔｘ状態情報１３０を参照することにより再チェックする（Ｓ６０７）。すなわち、生成ＴｘのＴｘ状態は、Ｓ６０３でチェックされたが、Ｓ６０７でもチェックされる。なぜなら、Ｓ６０３からＳ６０７の間に、生成Ｔｘの状態がフィジカルコミットに遷移している可能性があるからである。ログ３０のリードセット３７から特定される各生成Ｔｘについて、ログ３０に記録されているＴｘ状態が、Ｓ６０７で特定された現在のＴｘ状態に更新されてもよい。現在のＴｘ状態がフィジカルコミットである生成Ｔｘの参照レコードエントリは、ログ３０から削除されてもよい。
【００６３】
クエリ実行部４２４は、対象Ｔｘのログ３０内のリードセット３７から特定される全ての生成Ｔｘの現在のＴｘ状態がフィジカルコミットか否かを判定する（Ｓ６０８）。Ｓ６０８の判定結果が肯定の場合（Ｓ６０８：Ｙｅｓ）、クエリ実行部４２４は、対象Ｔｘのログ３０内のコミットフラグ１６を立てる（Ｓ６０９）。Ｓ６０８の判定結果が否定の場合（Ｓ６０８：Ｎｏ）、Ｓ６０９がスキップされる。これは、コミットフラグ１６の初期値が、少なくとも１つの生成ＴｘのＴｘ状態がコミットフラグでないことを意味する（例えばフラグ１６の値＝「０」）。コミットフラグ１６の初期値が、全ての生成ＴｘのＴｘ状態がフィジカルコミットであることを意味していれば（例えばフラグ１６の値＝「１」）、Ｓ６０８：ＹｅｓでＳ６０９が行われることに代えて、Ｓ６０８：Ｎｏのときにコミットフラグ１６を倒す（値を「０」にする）ことが行われてよい。
【００６４】
Ｓ６０９の後、又は、Ｓ６０８：Ｎｏの後、クエリ実行部４２４は、ログ出力、具体的には、ログ３０のログファイル３０１への書込み要求を出力する（Ｓ６１０）。このとき、クエリ実行部４２４は、対象Ｔｘの現在のＴｘ状態（Ｔｘ状態情報１３０におけるＴｘ状態）を、ロジカルコミットに更新する。ログ管理部１１５が、Ｉ／Ｆ制御処理（Ｓ１０００）を行い、その結果に応じて、コミット完了を出力（例えば表示）してよい。ここで出力されるコミット完了は、ロジカルコミットを意味する完了であってもよいし、ロジカルコミットとフィジカルコミットのどちらであるかを区別しない単純なコミット完了であってもよい。コミット完了の出力先は、クエリ発行元としてのクライアント４０５であってもよいし、データベースサーバ４０１を管理する図示しない管理システム（１以上の計算機）であってもよい。ログ出力の応答を受ける前にコミット完了が出力されることになるので、コミット完了の出力先に関わるユーザ（例えばクライアント４０５のユーザ、又は、管理システムのユーザ（例えば管理者））は、投機実行処理の結果としてのスループット向上を感じることができる。
【００６５】
Ｓ６１０の後、クエリ実行部４２４は、ログ出力の応答を待つ（Ｓ６１１）。ログ出力の応答（ログ書込みの完了の応答）をログ出力先（例えば外部ストレージ装置４０２）から受信した場合、クエリ実行部４２４は、対象Ｔｘに関わる全ての生成Ｔｘの現在の状態がフィジカルコミットになっていれば、対象Ｔｘの現在のＴｘ状態を、フィジカルコミットに更新する（Ｓ６１２）。対象ＴｘのＴｘ状態がフィジカルコミットになった場合、ログ管理部１１５が、コミット完了通知を、例えばクエリ発行元（又は管理システム）に出力することができる。Ｓ６１２を契機に行われるコミット完了出力を、便宜上、「フィジカルコミット出力」と言う。フィジカルコミット出力は、ロジカルコミット出力が行われている場合（言い換えれば、システム情報２４内の出力制御情報２６が、ロジカルコミット出力を実行することを表している場合）、省略されてもよい。言い換えれば、フィジカルコミット出力は、少なくともロジカルコミット出力が行われていない場合（言い換えれば、システム情報２４内の出力制御情報２６が、少なくともロジカルコミット出力を実行しないことを表している場合）、行われてよい。フィジカルコミット出力に従うコミット完了通知は、フィジカルコミットを意味する完了通知であってもよいし、ロジカルコミットとフィジカルコミットのどちらであるかを区別しない単純なコミット完了通知であってもよい。具体的には、例えば、ロジカルコミット出力とフィジカルコミット出力の一方だけが行われる場合、出力されるコミット完了通知は、上記単純なコミット完了通知であってよい。ロジカルコミット出力とフィジカルコミット出力の両方が行われる場合、ロジカルコミット出力でのコミット完了通知は、ロジカルコミットを意味するコミット完了通知でよく、フィジカルコミット出力でのコミット完了通知は、フィジカルコミットを意味するコミット完了通知でよい。
【００６６】
図８は、データベースリカバリ処理の流れの一例を示す。
【００６７】
データベースリカバリ処理では、バックアップされた或る時点のデータベースと、その時点からの差分を逐次的に記録したログとから、最新時点のデータベースがリカバリされる。
【００６８】
クエリ実行部４２４が、バックアップされたデータベースをメモリ４１６上にロードする（Ｓ８０１）。
【００６９】
次に、ログ管理部１１５が、読出し元ログファイル３０１から全てのログが読み出されたか否かを判定する（Ｓ８０２）。
【００７０】
Ｓ８０２の判定結果が否定の場合（Ｓ８０２：Ｎｏ）、ログ管理部１１５は、未だ読み出されていないログを、読出し元ログファイル３０１から例えばログバッファ１１４に読み出し（Ｓ８０３）、そのログについてログ適用処理を実行する（Ｓ８０４）。
【００７１】
Ｓ８０２の判定結果が肯定の場合（Ｓ８０２：Ｙｅｓ）、データベースリカバリ処理が終了する。但し、保留ログ一覧にログ３０が登録されている場合（Ｓ８１１：Ｙｅｓ）、ログ管理部１１５は、その保留ログ一覧を破棄する（Ｓ８１２）。Ｓ８１２では、リカバリエラーが出力されてもよい。全てのログが適用されたわけではないからである。保留ログ一覧については後述する。
【００７２】
図９は、ログ適用処理（図８のＳ８０４）の流れの一例を示す。
【００７３】
ログ管理部１１５は、読み出されたログ３０内のＴｘＩＤ３５とＴｘ状態とを、Ｔｘ状態情報１３０に記録する（Ｓ９０１）。Ｓ９０１で記録されるＴｘ状態は、読み出されたログ３０内のコミットフラグ１６が表すＴｘ状態である。具体的には、コミットフラグ１６が立っていれば（値が「１」であれば）、フィジカルコミットがＴｘ状態として記録され、コミットフラグ１６が倒れていれば（値が「０」であれば）、ロジカルコミットがＴｘ状態として記録される。
【００７４】
ログ管理部１１５は、記録されたＴｘ状態（読み出されたログ３０内のコミットフラグ１６が表すＴｘ状態）がフィジカルコミットか否かを判定する（Ｓ９０２）。
【００７５】
Ｓ９０２の判定結果が肯定の場合（Ｓ９０２：Ｙｅｓ）、ログ管理部１１５は、読み出されたログ３０をデータベースリカバリ処理において適用する（Ｓ９０８）。Ｓ９０８では、例えば、ログ３０内のライトセット３６に基づきデータベースリカバリが行われる。ログ管理部１１５は、そのログ３０に対応したＴｘのＴｘ状態（Ｔｘ状態情報１３０におけるＴｘ状態）を、フィジカルコミットに変更する（Ｓ９０９）。ログ管理部１１５は、保留ログ一覧に登録されている全てのログについてチェック済であれば（Ｓ９１０：Ｙｅｓ）、ログ適用処理を終了する。なお、「保留ログ一覧」とは、適用対象とするか否かの決定が保留とされているログ（或いは、ログの場所を示すポインタと、そのログに対応するＴｘのＴｘＩＤとを含んだエントリ）が登録される情報である。保留ログ一覧は、例えばログ管理部１１５によりデータベースリカバリ処理において用意された情報でよい。
【００７６】
Ｓ９０２の判定結果が肯定の場合（Ｓ９０２：Ｙｅｓ）、ログ管理部１１５は、読み出されたログ３０を保留ログ一覧に追加する（Ｓ９０３）。ログ管理部１１５は、そのログ３０内のリードセット３７から生成Ｔｘ（生成ＴｘのＴｘＩＤ）を特定し（Ｓ９０４）、特定された生成Ｔｘの現在のＴｘ状態をＴｘ状態情報１３０から特定する（Ｓ９０５）。ログ管理部１１５は、全ての生成ＴｘのＴｘ状態がフィジカルコミットか否かを判定する（Ｓ９０６）。
【００７７】
Ｓ９０６の判定結果が肯定の場合（Ｓ９０６：Ｙｅｓ）、ログ管理部１１５は、そのログ３０を保留ログ一覧から削除し（Ｓ９０７）、そのログ３０を適用し（Ｓ９０８）、そのログ３０に対応したＴｘのＴｘ状態を、フィジカルコミットに変更する（Ｓ９０９）。ログ管理部１１５は、保留ログ一覧に登録されている全てのログについてチェック済であれば（Ｓ９１０：Ｙｅｓ）、ログ適用処理を終了する。
【００７８】
ログ適用処理では、そのログ適用処理において保留ログ一覧に登録されたログに加えて、そのログ適用処理より前のログ適用処理において保留ログ一覧に登録されたログについても、Ｓ９０４以降の処理が行われる（Ｓ９１０：Ｎｏ）。なぜなら、過去のログ適用処理においては生成ＴｘのＴｘ状態がフィジカルコミットではなくても、今回のログ適用処理においては生成ＴｘのＴｘ状態がフィジカルコミットに遷移している可能性があるからである。或いは、過去のログ適用処理において未だＴｘ状態情報１３０に無いエントリが、今回のログ適用処理においては存在する可能性があるからである。１つのログ適用処理において、保留ログ一覧に登録されているログについてＳ９０４以降が行われる回数は、１回であるが、２回以上であってもよい。
【００７９】
図１０は、クライアント４０５とＤＢＭＳ４１２間の通信の一例を示すシーケンス図である。以下、１つのＴｘを例に取る。そのＴｘを、図１０〜図１２の説明において、「対象Ｔｘ」と呼ぶ。
【００８０】
例えば、ＤＢＭＳ４１２内のクエリ実行部４２４が、対象Ｔｘのbeginの後にselect文の要求をクライアント４０５から受けた場合、select文の結果と共に、参照されたレコードを生成した生成ＴｘのＴｘ状態を返す。ここで返される値は、フィジカルコミットか否かでよい。これにより、クライアント４０５が、対象Ｔｘに関わる生成ＴｘのＴｘ状態がフィジカルコミットであるか否かを知ることができる。
【００８１】
同様にして、クエリ実行部４２４が、update文の要求を受けた場合、update対象のレコードに対応した生成ＴｘのＴｘ状態がフィジカルコミットか否かを示す値を、update文の結果と合わせて返す。
【００８２】
クエリ実行部４２４が、commit要求をクライアント４０５から受け、ログ出力を行った場合、Ｉ／Ｆ制御処理（Ｓ１０００）の結果がコミット完了出力であれば、コミット完了通知（例えばロジカルコミットの完了通知）を返す。
【００８３】
その後、クエリ実行部４２４が、check要求をクライアント４０５から受けた場合、対象Ｔｘのログ出力に対する応答を受けており、且つ、対象Ｔｘに関わる全ての生成ＴｘのＴｘ状態がフィジカルコミットであれば、コミット完了通知（例えばフィジカルコミットの完了通知）を返す。
【００８４】
なお、Ｉ／Ｆ制御処理は、クライアント４０５が行ってもよい。すなわち、クライアント４０５が、受信したコミット完了通知を出力（表示）するか否かを制御してもよい。具体的には、例えば、クライアント４０５は、受信したコミット完了通知を出力しないと決めたらなら、そのコミット完了通知を出力しない。
【００８５】
また、上述したように、フィジカルコミットの完了通知は必ずしもされないでもよい。具体的には、例えば、少なくともロジカルコミットの完了通知がされなかった場合に、フィジカルコミットの完了通知がされてもよい。
【００８６】
図１１は、クライアント４０５とＤＢＭＳ４１２間の通信の別の一例を示すシーケンス図である。
【００８７】
図１１によれば、クエリ実行部４２４は、Ｔｘ要求を受信した場合、Begin〜Commitまでの一連のＴｘ処理を実行し、そのＴｘ処理の結果を返す。その際、クエリ実行部４２４は、Ｉ／Ｆ制御処理（Ｓ１０００）の結果に従い、ロジカルコミットの完了通知を出力する／出力しない。また、クエリ実行部４２４は、フィジカルコミットの完了通知を出力する／出力しないを制御する。
【００８８】
図１２は、Ｉ／Ｆ制御処理（Ｓ１０００）の流れの一例を示す。
【００８９】
クエリ実行部４２４は、システム情報２４内のモード制御情報２８が、投機実行処理モードのオンを表しているか否かを判定する（Ｓ１２０１）。Ｓ１２０１の判定結果が否定の場合（Ｓ１２０１：Ｎｏ）、ロジカルコミット出力の完了通知は行われない。
【００９０】
Ｓ１２０１の判定結果が肯定の場合（Ｓ１２０１：Ｙｅｓ）、クエリ実行部４２４は、システム情報２４内の出力制御情報２６が、ロジカルコミット出力を行うことを表しているか否かを判定する（Ｓ１２０２）。Ｓ１２０２の判定結果が否定の場合（Ｓ１２０２：Ｎｏ）、ロジカルコミット出力の完了通知は行われない。
【００９１】
Ｓ１２０２の判定結果が肯定の場合（Ｓ１２０２：Ｙｅｓ）、クエリ実行部４２４は、ロジカルコミット出力の完了通知を行う。
【００９２】
図１３は、設定ユーザインターフェースの一例を示す。
【００９３】
設定ユーザインターフェース１３００は、例えばＧＵＩ（Graphical User Interface）であり、ログ管理部１１５によりクライアント４０５又は管理システム等の外部システムに提供される。設定ユーザインターフェース１３００は、投機実行処理モードをオンとするかオフとするかを選択するためのＵＩ（ユーザインターフェース）と、ロジカルコミット出力を行う（オン）か否か（オフ）を選択するためのＵＩとを含む。いずれのＵＩも、ラジオボタンであるが、それに限らない。設定ユーザインターフェース１３００を介して入力された指定（投機実行処理モードのオン／オフ、及び、ロジカルコミット出力のオン／オフ）が、システム情報２４に登録される。
【００９４】
以下、実施形態を総括する。なお、総括の説明において、適宜、実施形態の変形例等の新たな記載を追加することができる。
【００９５】
以下の課題のうちの少なくとも１つを解決するシステムが提供される。
（課題１）データベースのＴｘのコミットのためのログ出力の応答を受けること無しにそのＴｘの結果に基づく別のＴｘを開始する投機実行処理が行われ得る環境では、投機実行処理によるスループット向上を少なくともユーザが認識しづらい。データベースのＴｘ処理の全体において、Ｔｘのコミットのためのログ出力からそのログ出力の応答を受信するまでの時間が占める割合は小さくないからである。
（課題２）投機実行処理では、ログ不整合が起こり得る。例えば、Ｔｘ１がレコードＡをレコードＢに更新したという第１ログが出力されたものの第１ログの書込みが完了していないにも関わらず、Ｔｘ２がレコードＢをレコードＣに更新したという第２ログの書込みが先に完了してしまい、第１ログが書き込まれる前に障害が生じた場合、データベースリカバリ処理においてログ不整合が起こり得る。
【００９６】
課題１は、例えば次の通り解決可能である。すなわち、ＤＢＭＳ４１２が、データベースのトランザクションのコミットのためにログを出力し、そのログ出力の応答を受けること無しにコミット完了（ロジカルコミット出力としてのコミット完了）を出力する。これにより、投機実行処理によるスループット向上をユーザが感じることができる。
【００９７】
なお、ＤＢＭＳ４１２は、コミットのためのログ出力が行われてからそのログ出力の応答を受ける前にコミット完了を出力することであるロジカルコミット出力を実行するか否かを表す情報である出力制御情報２６を管理する。ＤＢＭＳ４１２は、ロジカルコミット出力を実行することを出力制御情報２６が表していれば、トランザクションのコミットのために行ったログ出力の応答を受ける前にそのコミットの完了を出力する。このように、出力制御情報２６の内容次第で、ロジカルコミット出力を行うか否かの制御が可能である。
【００９８】
また、ＤＢＭＳ４１２は、ロジカルコミット出力を行うか否かの指定である出力指定を受け付ける設定ユーザインターフェース１３００を提供する。ＤＢＭＳ４１２は、設定ユーザインターフェース１３００を通じて出力指定（ロジカルコミット出力のオン／オフの指定）を受け、受けた出力指定に従い出力制御情報２６を更新する。このように、ユーザが、ロジカルコミット出力のオン／オフを切り替えることができる。単にコミット出力のオン／オフを切り替えるとなると、ロジカルコミット出力が不要であるがフィジカルコミット出力が必要とされる場合、フィジカルコミット出力もオフとされてしまうことになる。このため、コミット出力のオン／オフの切替えに関して、ロジカルコミット出力が切り出され、そのロジカルコミット出力についてオン／オフの切替えが可能であることの意義は大きい。なお、ロジカルコミット出力のオン／オフに加えて、フィジカルコミット出力のオン／オフの切替えのＵＩが設定ユーザインターフェース１３００に含まれてもよい。
【００９９】
また、ＤＢＭＳ４１２は、投機実行処理モードがオンか否かを表す情報であるモード制御情報２８を管理する。ＤＢＭＳ４１２は、投機実行処理モードがオンであることをモード制御情報２８が表している場合、トランザクションのコミットのためのログ出力の応答を受けること無しにそのトランザクションの結果に基づく別のトランザクションを開始するようになっている。ＤＢＭＳ４１２は、投機実行処理モードがオンか否かの指定であるモード指定を、設定ユーザインターフェース１３００（又は別のユーザインターフェース）を通じて受け、受けたモード指定に従いモード制御情報２８を更新する。このように、投機実行処理モードのオン／オフもユーザは切り替えることができる。ロジカルコミット出力のオン／オフのためのＵＩと、投機実行処理モードのオン／オフのためのＵＩと、フィジカルコミット出力のオン／オフのためのＵＩが、同一のＧＵＩにあってもよいし異なるＧＵＩにあってもよい。また、投機実行処理モードについてオンが選択されている場合、ＤＢＭＳ４１２は、ロジカルコミット出力のオンを無効（例えば、選択できないようディスエーブルの状態）としてよい。
【０１００】
また、ＤＢＭＳ４１２は、出力制御情報２６が、少なくとも、ロジカルコミット出力を実行しないことを表していれば、フィジカルコミット出力を実行してよい。
【０１０１】
課題２は、例えば次の通り解決可能である。すなわち、ＤＢＭＳ４１２が、Ｔｘのログ出力の完了応答を受信し且つそのＴｘに関わる全ての生成ＴｘのＴｘ状態がフィジカルコミットであることを意味するフィジカルコミットの他に、ログ出力が行われただけの状態を意味するロジカルコミットというコミット状態を管理する。データベースリカバリ処理では、ＤＢＭＳ４１２は、いつまでもフィジカルコミットが成立しないＴｘが１つでもでれば（図８のＳ８１１：Ｙｅｓとなれば）リカバリエラーとすることができ、全てのＴｘのＴｘ状態がフィジカルコミットになったら、データベースリカバリ処理を完了する。これにより、ログ不整合のあり得るログの適用を回避できる。
【０１０２】
具体的には、Ｔｘのログ３０は、そのＴｘの状態がフィジカルコミットであるか否かを示す情報の一例であるコミットフラグ１６を含む。また、ログ３０は、Ｔｘの参照に関する情報を含んだ情報の一例であるリードセット３７を含む。ＤＢＭＳ４１２は、リードセット３７に基づき、生成トランザクションの各々のＴｘ状態がフィジカルコミットであるか否かを判定する。
【０１０３】
リードセット３７は、各生成ＴｘのＴｘＩＤを含む。ＤＢＭＳ４１２は、リードセット３７から特定された各生成ＴｘのＴｘＩＤに対応した現在のＴｘ状態を特定することで、各生成Ｔｘの状態がフィジカルコミットであるか否かを判定する。
【０１０４】
ＤＢＭＳ４１２は、出力対象のログ３０に含まれるリードセット３７から特定される各生成Ｔｘの現在のＴｘ状態がフィジカルコミットか否かの判定を、出力対象のログ３０を出力するときに実行する。その判定の結果が肯定の場合、ＤＢＭＳ４１２は、出力対象のログ３０が含むコミットフラグ１６を立ててから、そのログ３０を出力する。
【０１０５】
ＤＢＭＳ４１２は、生成ＴｘのＴｘ状態がフィジカルコミットであれば、その生成ＴｘのＴｘＩＤをログ３０に記録しない。
【０１０６】
ＤＢＭＳ４１２は、データベースリカバリ処理において読み出されたログ（出力済ログの一例）について、そのログが含むコミットフラグ１６がフィジカルコミットを表していれば、データベースリカバリ処理においてそのログを適用する。
【０１０７】
ＤＢＭＳ４１２は、データベースリカバリ処理において読み出されたログが含むコミットフラグ１６がフィジカルコミットを表していなければ、（ｘ１）そのログに対応したトランザクションに関わる全ての生成Ｔｘの現在の状態がフィジカルコミットか否かを判定し、（ｘ２）（ｘ１）の判定の結果が肯定の場合、そのログを適用し、且つ、そのログに対応したＴｘの現在のＴｘ状態をフィジカルコミットに変更する。ＤＢＭＳ４１２は、データベースリカバリ処理において、ログが読み出される都度にログ適用処理を行う。ログ適用処理では、読み出されたログについての（ｘ１）の判定と、過去のログ適用処理において（ｘ１）の判定の結果が否定となったログについての再度の（ｘ１）の判定とが行われる。
【０１０８】
以上、一実施形態を説明したが、本発明は、この実施形態に限定されるものでなく、その要旨を逸脱しない範囲で種々変更可能であることはいうまでもない。
【０１０９】
例えば、リードセット（参照情報の一例）は、各参照レコードエントリに代えて、タイムスタンプ（以下、ＴＳ）のみでもよいし、そのＴＳのときに参照可能なレコードのＩＤのリストでもよい。ＴＳは、時刻でもよいしカウント値であってもよい。クエリ実行部は、例えば、ＴＳ「１２０」より前のＴｘのＴｘ状態が全てフィジカルコミットであれば、ＴＳ「１２０」に対応したＴｘのＴｘ状態もフィジカルコミットにしてよいと判断できる。また、例えば、クエリ実行部は、例えば、ＴＳ「１１９」に対応したＴｘについてコミットのためのログ出力が行われたはずであるがそのログがログファイルに書かれていなければ、ＴＳ「１２０」に対応したＴｘのＴｘ状態をフィジカルコミットにしてはならないと判断できる（ＴＳ「１１９」に対応したＴｘのＴｘ状態がフィジカルコミットでないからである）。このように、リードセットがＴＳであっても、対象ＴｘのＴｘ状態をフィジカルコミットにできるか否かの判断することができる。
【符号の説明】
【０１１０】
４０１…データベースサーバ
【図１】
2017006423.tif 000003
【図２】
2017006423.tif 000004
【図３】
2017006423.tif 000005
【図４】
2017006423.tif 000006
【図５】
2017006423.tif 000007
【図６】
2017006423.tif 000008
【図７】
2017006423.tif 000009
【図８】
2017006423.tif 000010
【図９】
2017006423.tif 000011
【図１０】
2017006423.tif 000012
【図１１】
2017006423.tif 000013
【図１２】
2017006423.tif 000014
【図１３】
2017006423.tif 000015
【国際調査報告】
2017006423.tif 000016
2017006423.tif 000017