JP2016194826A

JP2016194826A - データベースの処理制御方法、処理制御プロラム及びデータベースサーバ

Info

Publication number: JP2016194826A
Application number: JP2015074599A
Authority: JP
Inventors: 佳弘辻川; Yoshihiro Tsujikawa; 藤井　久也; Hisaya Fujii; 久也藤井; 直樹中戸川; Naoki Nakatogawa; 泰裕鈴木; Yasuhiro Suzuki
Original assignee: Fujitsu Ltd
Current assignee: Fujitsu Ltd
Priority date: 2015-03-31
Filing date: 2015-03-31
Publication date: 2016-11-17
Anticipated expiration: 2035-03-31
Also published as: US20160292203A1; JP6477169B2

Abstract

【課題】処理対象のデータを簡易に特定することを目的とする。【解決手段】データベースの処理制御方法の一観点によれば、データベースの第１の記憶領域に記憶されたデータを更新データに更新する更新処理を行なう際に、該更新処理に割り当てた識別情報を該更新データに対応付けて前記第１の記憶領域に記憶させ、前記更新処理の確定処理に応じて、前記第１の記憶領域とは異なる第２の記憶領域に、前記識別情報と確定時刻とを対応付けて記憶させることを含む。【選択図】図１

Description

本発明は、データベースの処理制御方法、処理制御プロラム及びデータベースサーバに関する。

データベースに含まれるレコードは、外部からの指示に従って、その一部について、参照、更新、挿入、削除等の処理が施されることがあり、後に、特定の期間に処理がされたレコードを特定して、バッチ処理等の処理を行なうことがある。

その際、レコードに更新フラグを設けておき、レコードのデータが更新されると更新フラグをセットし、特定の期間の満了時に、更新フラグを確認することで、特定の期間の間に更新されたデータを検出し、バッチ処理等の処理の対象の対象データとして扱い、バッチ処理後、再び更新フラグを解除する技術が存在する。

特開２０１２―１７３８２６号公報

しかし、更新フラグを用いる場合、対象レコードにおけるフラグのセット、解除処理が強いられ、処理が煩雑である。また、特定の期間が一致しない複数のバッチ処理がある場合にあっては、１種類の更新フラグでは対応できなくなる。

一の側面では、本発明は、処理対象のデータを簡易に特定することを目的とする。

データベースの処理制御方法の一観点によれば、データベースの第１の記憶領域に記憶されたデータを更新データに更新する更新処理を行なう際に、更新処理に割り当てた識別情報を更新データに対応付けて第１の記憶領域に記憶させ、更新処理の確定処理に応じて、第１の記憶領域とは異なる第２の記憶領域に、識別情報と確定時刻とを対応付けて記憶させる。

本発明によれば、処理対象のデータを簡易に特定することが可能となる。

図１は、データベースサーバの構成例を示す図である。図２ａは、実データテーブルの一例を示す図である。図２ｂは、図２ａに示す実データテーブルの処理後の実データテーブルの一例を示す図である。図３は、コミット時刻管理テーブルの一例を示す図である。図４は、データベースサーバのハードウェア構成例を示す図である。図５は、データベースサーバとアプリケーションサーバの接続形態の一例を示す図である。図６は、第１実施形態に係るトランザクションによるデータの処理手順を示すフローチャートである。図７は、第１実施形態に係るコミット時刻に基づくデータの処理手順を示すフローチャートである。図８ａは、コミット時刻反映処理前の実データテーブルの一例を示す図である。図８ｂは、コミット時刻反映処理後の実データテーブルの一例を示す図である。図９は、第２実施形態に係るコミット時刻の実データテーブルへの反映処理手順を示すフローチャートである。図１０は、第２実施形態に係るトランザクション処理によるデータの更新処理手順を示すフローチャートである。図１１は、第２実施形態に係るコミット時刻に基づくデータの処理手順を示すフローチャートである。

以下、図面を参照して各実施形態について詳細に説明する。各実施形態における各処理は適宜組み合わせることが可能である。なお、各実施形態を説明するための全図において、同一部には原則として同一の符号を付し、その繰り返しの説明は省略する。

（第１実施形態）
以下、図面を参照して、本発明の第１実施形態について説明する。図１は、本発明の実施形態に係るデータベースサーバ１０の構成例を示す。データベースサーバ１０は、データベース１１、ＳＱＬ（ＳｔｒｕｃｔｕｒｅＱｕｅｒｙＬａｎｇｕａｇｅ）実行制御部１２、及び実行部１３を有する。データベースサーバ１０の構成はこれに限られるものではなく、例えば、データベース１１は、データベースサーバ１０と接続された外部装置の記憶装置に記憶されても良い。

データベース１１は、例えば、ＨＤＤ（ＨａｒｄＤｉｓｋＤｒｉｖｅ）等の記憶装置に体系的に記録されたデータ（情報）の集合である。各実施形態では、データを表形式によって管理するＲＤＢ（ＲｅｌａｔｉｏｎａｌＤａｔｅｂａｓｅ）を例に挙げて説明する。データベース１１は、例えば、実データテーブル２０とコミット時刻管理テーブル３０を含む。図２ａは、実データテーブル２０の一例を示す。実データテーブル２０のレコードは、例えば、レコードＩＤ２１、データ名２２、個数２３、処理ＩＤ２４等の項目を含む。なお、レコードＩＤ２１は、レコードを識別する情報である。データ名２２は、例えば、商品名などの名称を示すデータであり、個数２３は、例えば、その商品の個数を示すデータである。また、処理ＩＤ２４は、レコードに対する処理を識別する情報である。なお、レコードは、商品名や個数のデータの代わりに他のデータを含んでも良い。

図３は、コミット時刻管理テーブル３０の一例を示し、図２ａの実データテーブルとは異なる記憶領域に記憶される。コミット時刻管理テーブル３０のレコードは、処理ＩＤ２４、コミット時刻３１等の項目を含む。コミット時刻管理テーブル３０は、処理ＩＤ２４とコミット時刻３１の情報を対応付けて記憶させておくテーブルである。図２ａの実データテーブルにおける処理ＩＤ２４と、コミット時刻管理テーブル３０における処理ＩＤ２４は、同じＩＤであれば、同じ処理に対応するものである。なお、コミット時刻３１は、例えば、実行部１３が、ＳＱＬ実行制御部１２からコミットする指示を受け付けた時刻である。

図１に示すように、ＳＱＬ実行制御部１２は、ＳＱＬによるデータベース１１への操作指示を受け付け、受け付けた指示内容に基づく処理の制御を行う。例えば、ＳＱＬ実行制御部１２は、受け付けた指示内容に基づき、実行部１３に処理の実行に関する指示をする。ＳＱＬによるデータベース１１への操作指示は、ユーザの入力操作に基づいて、データベースサーバ１０と通信ネットワークを介して接続されたアプリケーションサーバより送信されるようにしても良い。

実行部１３は、ＳＱＬ実行制御部１２からの指示に応じて、データベース１１内のデータに対する処理（参照、更新、挿入、削除等）を実行する。

実行部１３は、例えば、トランザクションによるデータの処理を実行し、処理のコミット（確定）を行なう際に、コミット時刻３１の情報を、処理を施したデータと対応付けてデータベース１１に格納させ、データの処理をコミットする。

図２ｂは、図２ａに示す実データテーブルの処理後の実データテーブルの一例を示す。例えば、図２ａ及び図２ｂ（レコードＩＤ２１「００１」及びレコードＩＤ２１「００２」参照）で示す様に、実行部１３は、実データテーブル２０のデータの処理の実行の際に、その処理に割当てられた処理ＩＤ２４を用いて、処理ＩＤ２４を新たな処理ＩＤ２４に更新する。具体的には、レコードＩＤ２１「００１」のレコードでは、個数を「０」から「５０」に更新する処理が実行されるため、処理ＩＤ２４は、格納されている「ａｚ６」から、実行した処理に割り当てられた処理ＩＤ２４「ａｂ１」に更新される。そして、実行部１３は、コミット時刻３１の情報を取得し、コミット時刻管理テーブル３０に処理ＩＤ２４とコミット時刻３１の情報を対応付けて格納させて、データの処理をコミットする。

実行部１３は、コミット時刻に応じて特定されるデータの処理を実行する際に、コミット時刻管理テーブル３０を参照して、実データテーブル２０の処理対象のレコードを特定し、処理を実行する。

具体的には、実行部１３は、ＳＱＬ実行制御部１２からの時間条件（コミット時刻の時間条件）を含む指示に応じて、コミット時刻管理テーブル３０を参照し、時間条件を満たすコミット時刻３１と対応付けられた処理ＩＤ２４を抽出する。続いて、実行部１３は、抽出した処理ＩＤ２４を基に、実データテーブル２０の処理対象のレコードを特定し、特定したレコードに対して、処理を実行する。なお、この場合においても、実行部１３は、コミット時刻３１の情報を取得し、コミット時刻管理テーブル３０に処理ＩＤ２４とコミット時刻３１の情報とを対応付けて格納させ、処理をコミットしても良い。

図４は、本発明の実施形態に係るデータベースサーバ１０のハードウェア構成例を示す。データベースサーバ１０は、ＣＰＵ（ＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ）４０、主記憶装置４１、補助記憶装置４２、ネットワーク接続装置４３を有し、これらはシステムバス４４で相互に接続されている。

ＣＰＵ４０は、例えば、主記憶装置４１に格納されているＯＳ（ＯｐｅｒａｔｉｎｇＳｙｓｔｅｍ）、各種プログラムに基づいて、各種演算や各ハードウェア構成部とのデータ入出力等、データベースサーバの処理を制御して、各種処理を実行する。ＣＰＵ４０は、各実施形態に係る制御プログラムに基づき、ＳＱＬ実行制御部１２、実行部１３等の機能を果たす。

主記憶装置４１は、ＣＰＵ４０に実行させるＯＳや各種プログラムの少なくとも一部を一時的に記憶する。また、主記憶装置４１は、ＣＰＵ４０による処理に必要な各種データを記憶する。なお、主記憶装置４１は、例えば、ＲＯＭ（ＲｅａｄＯｎｌｙＭｅｍｏｒｙ）やＲＡＭ（ＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙ）等である。

補助記憶装置４２は、例えば、各実施形態に係る制御プログラムや、データベースサーバに設けられた制御プログラム等を記憶する。補助記憶装置４２は、ＣＰＵ４０からの制御信号に基づいて、記憶された各種情報の読み出しや、書き込みを行うことができる。補助記憶装置４２は、例えば、ＨＤＤ（ＨａｒｄＤｉｓｋＤｒｉｖｅ）、ＳＳＤ（ＳｏｌｉｄＳｔａｔｅＤｒｉｖｅ）等のストレージ等である。補助記憶装置４２は、各実施形態の処理において使用される情報やデータベース１１を格納する。また、主記憶装置４１と補助記憶装置４２は、互いの機能を担い合っても良い。

ネットワーク接続装置４３は、例えば、ＣＰＵ４０からの制御信号に基づき、図５に示す様に、通信ネットワーク１４を介して接続されたアプリケーションサーバ１５等との通信を行う。図５は、データベースサーバとアプリケーションサーバの接続形態の一例を示す。ところで、データベースサーバ１０とアプリケーションサーバ１５とは、別の装置として例に挙げたが、これに限られるものではなく、１台のサーバでデータベースサーバとアプリケーションサーバの２役の機能を担っても良い。

続いて、第１実施形態に係るデータベースサーバ１０の、例えば、トランザクションによるデータの処理（参照、更新、挿入、削除等）手順について説明する。図６は、データの処理手順を示すフローチャートである。

例えば、アプリケーションサーバ１５よりデータの処理指示を受信したＳＱＬ実行制御部１２からのデータの処理内容、処理対象の情報（例えば、レコードＩＤ２１等）、処理ＩＤ２４等を含む指示に応じ、実行部１３は、実データテーブル２０を検索し、実データテーブル２０の処理対象のレコードを特定する（Ｓ１０１）。実行部１３は、特定した全てのレコードに対して、他の処理のアクセスを禁止する（ロックする）（Ｓ１０２）。

ロックがなされた場合（Ｓ１０２Ｙｅｓ）、実行部１３は、ロックしたレコードに対して、ＳＱＬ実行制御部１２からの指示に応じた処理（処理ＩＤ２４の更新を含む）を実行する（Ｓ１０３）。実行部１３は、処理が正常になされたと判断した場合、コミット時刻３１を取得し、コミット時刻３１と更新した処理ＩＤ２４とを対応づけてコミット時刻管理テーブル３０に格納すると共に、処理のコミットを行う（Ｓ１０４）。コミット後、実行部１３は、処理した全てのレコードのロックを解除する（Ｓ１０５）。
ロックがなされなかった場合（Ｓ１０２Ｎｏ）、処理は一時待ち状態となる。実行部１３は、レコードが他の処理等の排他から解除され、ロックがなされると、上記同様の処理を実行する。

なお、何らかの原因で、データの処理に失敗した場合、実行部１３は、処理が正常になされなかったと判断し、処理のコミットを実行せず、ロールバック処理を実行し、レコードを処理前の状態に復元する。

次に、第１実施形態に係るデータベースサーバ１０のコミット時刻に基づくデータの処理（参照、更新、挿入、削除等）手順について説明する。図７は、コミット時刻に基づくデータの更新処理手順を示すフローチャートである。

例えば、アプリケーションサーバ１５よりデータの処理指示を受信したＳＱＬ実行制御部１２からの、データの処理内容、処理対象の情報（例えば、時間条件等）等を含む指示に応じ、実行部１３は、コミット時刻管理テーブル３０を検索し、指定された時間条件を満たすコミット時刻３１と対応付けられた処理ＩＤ２４を取得する（Ｓ２０１）。次に、実行１３は、実データテーブル２０を検索して、取得した処理ＩＤ２４と対応付けられたレコードを特定する（Ｓ２０２）。実行部１３は、特定した全てのレコードに対して、他の処理のアクセスを禁止する（ロックをする）（Ｓ２０３）。

ロックがなされた場合（Ｓ２０３Ｙｅｓ）、実行部１３は、ロックしたレコードに対して、ＳＱＬ実行制御部１２からの指示に応じた処理を実行する（Ｓ２０４）。続いて、実行部１３は、処理が正常になされたと判断した場合、処理のコミットを行う（Ｓ２０５）。コミット処理後、実行部１３は、処理した全てのレコードのロックを解除する（Ｓ２０６）。

ロックがなされなかった場合（Ｓ２０３Ｎｏ）、処理は一時待ち状態となる。実行部１３は、レコードが他の処理等の排他から解除され、ロックがなされると、上記同様の処理を実行する。

なお、何らかの原因で、データの処理に失敗した場合、実行部１３は、処理が正常になされなかったと判断し、処理のコミットを実行せず、ロールバック処理を実行し、レコードを更新処理前の状態に復元する。

第１実施形態によれば、データベース１１は、コミット時刻３１と処理を施したデータを対応付けて格納することとなる。処理ＩＤ２４とコミット時刻３１の格納は、一の処理に対して、コミット時刻管理テーブル３０の一のレコードを更新するだけで良く、処理量が少なく、処理時間も短い。そのため、データベースサーバ１０は、コミット時刻３１が所定の時間帯に含まれるデータを処理対象のデータとして特定するバッチ処理等を行なう場合に、コミット時刻３１を利用して処理対象のデータを特定して処理を行なうことで、処理コスト及び漏れを抑制して、所望のデータに対して処理を実行することが可能である。

ところで、上記、実行部１３による排他制御のためのロックは、共有ロックでも良いし、占有ロックでも良い。より具体的には、実行部１３は、他のトランザクションの参照は許可するが更新は許可しない共有ロックをしても良く、他のトランザクションの参照及び更新の両方を許可しない占有ロックをしても良い。更に、ロックするデータの範囲は、テーブル全体でも良く、レコード単位でも良い。

（第２実施形態）
次に、図面を参照して、本発明の第２実施形態について説明する。第２実施形態に係るデータベースサーバ１０の実行部１３は、第１実施形態に係る各種処理の他に、コミット時刻管理テーブル３０に格納されたコミット時刻３１を、実データテーブル２０へ反映させる処理を実行する。

実行部１３は、例えば、事前に設定されたスケジュールに基づき、コミット時刻管理テーブル３０に格納されたコミット時刻３１を、実データテーブル２０へ反映させる処理を実行する。図８ａは、コミット時刻反映処理前の実データテーブルの一例を示す。図８ａに示すように、実データテーブル２０のレコードは、例えば、レコードＩＤ２１、データ名２２、個数２３、処理ＩＤ２４、コミット時刻３１等の項目を有する。

実行部１３は、コミット時刻管理テーブル３０を参照し、一組の更新ＩＤ２４とコミット時刻３１を抽出する。実行部１３は、抽出した処理ＩＤ２４を基に、実データテーブル２０を参照し該当するレコードを検索し、特定する。そして、実行部１３は、特定したレコードに抽出したコミット時刻３１を格納する。また、実行部１３は、図８ｂに示すように、コミット時刻３１を実データテーブル２０に格納する際に、そのレコードの処理ＩＤ２４を削除（ｎｕｌｌの状態に）しても良い。図８ｂは、コミット時刻反映処理後の実データテーブルの一例を示す。

第２実施形態に係るデータベースサーバ１０のコミット時刻管理テーブル３０に格納されたコミット時刻３１の実データテーブル２０への反映処理手順について説明する。図９は、コミット時刻の実データテーブルへの反映処理手順を示すフローチャートである。

まず、実行部１３は、コミット時刻管理テーブル３０を参照し、例えば、テーブルの最上列にある一組の処理ＩＤ２４とコミット時刻３１を抽出する（Ｓ３０１）。実行部１３は、抽出した処理ＩＤ２４を基に、実データテーブル２０を検索し、更新するレコードを特定する（Ｓ３０２）。実行部１３は、特定したレコードに対して、他の処理からのアクセスを禁止するロックを行う（Ｓ３０３）。

ロックがなされた場合（Ｓ３０３Ｙｅｓ）、実行部１３は、抽出したコミット時刻３１を格納すると共に、格納されてある処理ＩＤ２４を削除（ｎｕｌｌの状態）する（Ｓ３０４）。実行部１３は、コミット処理し、レコードのロックを解除する（Ｓ３０５）。実データテーブル２０への反映処理後、実行部１３は、コミット時刻管理テーブル３０から処理ＩＤ２４とコミット時刻３１のレコードを削除する（Ｓ３０６）。

ロックがなされなかった場合（Ｓ３０３Ｎｏ）、反映処理は一時待ち状態となる。実行部１３は、レコードが他の処理等の排他から解除され、ロックがなされると、上記同様の処理を実行する。

なお、上記手順では、実行部１３は、コミット時刻３１を実データテーブル２０に反映した後に、コミット時刻管理テーブル３０から処理ＩＤ２４とコミット時刻３１のレコードを削除するが、これに限られるものではなく、実行部１３は、コミット時刻管理テーブル３０から処理ＩＤ２４とコミット時刻３１を抽出する（Ｓ３０１）と共に、抽出した処理ＩＤ２４とコミット時刻３１をコミット時刻管理テーブル３０から削除し、実データテーブル２０に反映させても良い。

続いて、第２実施形態に係るデータベースサーバ１０の、例えば、トランザクションによるデータの処理（参照、更新、挿入、削除等）手順について説明する。図１０は、データの処理手順を示すフローチャートである。

例えば、アプリケーションサーバ１５よりデータの処理指示を受信したＳＱＬ実行制御部１２からのデータの処理内容、処理対象の情報（例えば、レコードＩＤ２１等）、処理ＩＤ２４等を含む指示に応じ、実行部１３は、実データテーブル２０を検索し、実データテーブル２０の処理対象のレコードを特定する（Ｓ４０１）。実行部１３は、特定した全てのレコードに対して、他の処理のアクセスを禁止する（ロックをする）（Ｓ４０２）。

ロックがなされた場合（Ｓ４０２Ｙｅｓ）、実行部１３は、ロックしたレコードに対して、ＳＱＬ実行制御部１２からの指示に応じた処理（処理ＩＤ２４の更新及びコミット時刻３１の削除（ｎｕｌｌの状態）を含む）を実行する（Ｓ４０３）。実行部１３は、処理が正常になされたと判断した場合、コミット時刻３１を取得し、コミット時刻３１と更新した処理ＩＤ２４とを対応づけてコミット時刻管理テーブル３０に格納すると共に、処理のコミットを行う（Ｓ４０４）。コミット後、実行部１３は、処理した全てのレコードのロックを解除する（Ｓ４０５）。

ロックがなされなかった場合（Ｓ４０２Ｎｏ）、更新処理は一時待ち状態となる。実行部１３は、レコードが他の処理等の排他から解除され、ロックがなされると、上記同様の処理を実行する。

次に、第２実施形態に係るデータベースサーバ１０のコミット時刻に基づくデータの処理（参照、更新、挿入、削除等）手順について説明する。図１１は、コミット時刻に基づくデータの処理手順を示すフローチャートである。

例えば、アプリケーションサーバ１５よりデータの処理指示を受信したＳＱＬ実行制御部１２からの、データの処理内容、処理対象の情報（例えば、時間条件等）等を含む指示に応じ、実行部１３は、実データテーブル２０を検索し、指定された時間条件を満たすコミット時刻３１と対応付けられたレコードを特定する（コミット時刻３１が「ｎｕｌｌ」のレコードについては、処理ＩＤ２４に基づいて、コミット時刻管理テーブル３０よりコミット時刻３１を取得し、処理対象のレコードを特定する）（Ｓ５０１）。実行部１３は、特定した全てのレコードに対して、他の処理のアクセスを禁止する（ロックをする）（Ｓ５０２）。

ロックがなされた場合（Ｓ５０２Ｙｅｓ）、実行部１３は、ロックしたレコードに対して、ＳＱＬ実行制御部１２からの指示に応じた処理を実行する（Ｓ５０３）。続いて、実行部１３は、処理が正常になされたと判断した場合、処理のコミットを行う（Ｓ５０４）。コミット処理後、実行部１３は、処理した全てのレコードのロックを解除する（Ｓ５０５）。

ロックがなされなかった場合（Ｓ５０２Ｎｏ）、処理は一時待ち状態となる。実行部１３は、レコードが他の処理等の排他から解除され、ロックがなされると、上記同様の処理を実行する。

第２実施形態によれば、コミット時刻３１を実データテーブル２０に反映させるため、つまり反映させたコミット時刻３１が格納されたレコードをコミット時刻管理テーブル３０から削除（解放）できるため、コミット時刻管理テーブル２０の肥大化を抑制することができる。それに伴い、処理時等の実行部１３によるコミット時刻管理テーブル３０の検索量を抑えることができる。更に、コミット時刻３１に基づくデータの処理において、実行部１３は、実データテーブル２０にコミット時刻３１が格納されているため、コミット時刻管理テーブル３０を参照することなく、処理することが可能となる。なお、実データテーブル２０への非反映のデータを考慮して、実データテーブル２０、コミット時刻管理テーブル３０の双方を検索して、対象となる時間条件を満たすコミット時刻と対応付けられたデータを特定しても良い。

なお、実データテーブル２０は、処理ＩＤ２４とコミット時刻３１とが別の項目に格納されている例を挙げて説明したが、これに限られるものではない。例えば、１つの項目で処理ＩＤ２４及びコミット時刻３１を格納しても良い。つまり、処理ＩＤ２４又はコミット時刻３１のどちらか一方が適宜格納されても良い。

ところで、第２実施形態において、列指向データベースを適用しても良い。列指向データベースでは、列単位でデータの格納やアクセスを行う。そのため、列指向データベースは、多数の行に対する少数列の一括更新等に優れており、実データテーブル２０に対するコミット時刻３１の反映処理を高速に処理可能である。

本発明は、上述した各実施形態の構成及び手順に限定されるものではなく、本発明の趣旨を逸脱しない範囲で適宜処理方法の変更、組み換え等が可能である。

１０：データベースサーバ
１１：データベース
１２：ＳＱＬ実行制御部
１３：実行部
１４：通信ネットワーク
１５：アプリケーションサーバ
２０：実データテーブル
２１：レコードＩＤ
２２：データ名
２３：個数
２４：処理ＩＤ
３０：コミット時刻管理テーブル
３１：コミット時刻
４０：ＣＰＵ
４１：主記憶装置
４２：補助記憶装置
４３：ネットワーク接続装置
４４：システムバス

Claims

データベースの第１の記憶領域に記憶されたデータを更新データに更新する更新処理を行なう際に、該更新処理に割り当てた識別情報を該更新データに対応付けて前記第１の記憶領域に記憶させ、
前記更新処理の確定処理に応じて、前記第１の記憶領域とは異なる第２の記憶領域に、前記識別情報と確定時刻とを対応付けて記憶させる、
ことを特徴とするデータベースの処理制御方法。
更に、前記識別情報に対応する更新データについて確定処理が行われた後に、前記識別情報に対応する前記更新データに対応付けて前記確定時刻を前記第１の記憶領域に記憶させ、
前記第２の記憶領域に記憶させた前記識別情報と前記確定時刻の記憶領域を他の識別情報と確定時刻の記憶に利用可能とする、
ことを特徴とする請求項１に記載のデータベースの処理制御方法。
第１の記憶領域に記憶されたデータを更新データに更新する更新処理を行なう際に、該更新処理に割り当てた識別情報を該更新データに対応付けて前記第１の記憶領域に記憶させ、前記更新処理の確定処理に応じて、前記第１の記憶領域とは異なる第２の記憶領域に、前記識別情報と確定時刻とを対応付けて記憶させたデータベースにおける処理方法において、
所定の時間帯内に属する確定時刻と対応付けて記憶された前記識別情報が前記第２の記憶領域に存在することを検出すると、検出した該識別情報に対応付けて前記第１の記憶領域に記憶された更新データを、前記所定の時間帯内に更新処理が確定した処理対象のデータとして特定する、
ことを特徴とするデータベースの処理制御方法。
データベースに記憶されたデータの処理を行う際に、該処理の確定時刻と対応付けて記憶された前記処理を施されたデータを、
前記確定時刻に基づき、前記データベースを検索することにより特定し、
特定した前記データを処理対象とする、
ことを特徴とするデータベースの処理制御方法。
コンピュータに、
データベースの第１の記憶領域に記憶されたデータを更新データに更新する更新処理を行なう際に、該更新処理に割り当てた識別情報を該更新データに対応付けて前記第１の記憶領域に記憶させ、
前記更新処理の確定処理に応じて、前記第１の記憶領域とは異なる第２の記憶領域に、前記識別情報と確定時刻とを対応付けて記憶させる、
処理を実行させることを特徴とするデータベースの処理制御プログラム。
データベースの第１の記憶領域に記憶されたデータを更新データに更新する更新処理を行なう際に、該更新処理に割り当てた識別情報を該更新データに対応付けて前記第１の記憶領域に記憶させ、
前記更新処理の確定処理に応じて、前記第１の記憶領域とは異なる第２の記憶領域に、前記識別情報と確定時刻とを対応付けて記憶させる実行部を、
有することを特徴とするデータベースサーバ。
第１の記憶領域に記憶されたデータを更新データに更新する更新処理を行なう際に、該更新処理に割り当てた識別情報を該更新データに対応付けて前記第１の記憶領域に記憶させ、前記更新処理の確定処理に応じて、前記第１の記憶領域とは異なる第２の記憶領域に、前記識別情報と確定時刻とを対応付けて記憶させたデータベースサーバにおいて、
所定の時間帯内に属する確定時刻と対応付けて記憶された前記識別情報が前記第２の記憶領域に存在することを検出すると、検出した該識別情報に対応付けて前記第１の記憶領域に記憶された更新データを、前記所定の時間帯内に更新処理が確定した処理対象のデータとして特定する実行部を、
有することを特徴とするデータベースサーバ。