JP2017054207A - データベース制御プログラム、データベース制御方法及びデータベース制御装置 - Google Patents
データベース制御プログラム、データベース制御方法及びデータベース制御装置 Download PDFInfo
- Publication number
- JP2017054207A JP2017054207A JP2015176111A JP2015176111A JP2017054207A JP 2017054207 A JP2017054207 A JP 2017054207A JP 2015176111 A JP2015176111 A JP 2015176111A JP 2015176111 A JP2015176111 A JP 2015176111A JP 2017054207 A JP2017054207 A JP 2017054207A
- Authority
- JP
- Japan
- Prior art keywords
- record
- update process
- value
- transaction
- updated
- 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
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
- G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
- G06F16/23—Updating
- G06F16/2308—Concurrency control
- G06F16/2336—Pessimistic concurrency control approaches, e.g. locking or multiple versions without time stamps
Abstract
【課題】更新処理の待ち時間を短縮することを目的とする。
【解決手段】コンピュータに、データベースに記憶されたレコードに含まれる、データ項目の項目値に対する更新処理が発生した場合に、前記項目値が前記更新処理により更新された場合の数値を項目値とするレコードと、前記項目値が前記更新処理により更新されない場合の数値を項目値とするレコードと、を生成し、前記更新処理が発生したレコードに対して新たな更新処理が発生した場合に、前記更新された場合の数値を項目値とするレコードと前記更新されない場合の数値を項目値とするレコードとのそれぞれに対して、前記新たな更新処理を行う、ことを実行させるデータベース制御プログラムが提供される。
【選択図】図５
【解決手段】コンピュータに、データベースに記憶されたレコードに含まれる、データ項目の項目値に対する更新処理が発生した場合に、前記項目値が前記更新処理により更新された場合の数値を項目値とするレコードと、前記項目値が前記更新処理により更新されない場合の数値を項目値とするレコードと、を生成し、前記更新処理が発生したレコードに対して新たな更新処理が発生した場合に、前記更新された場合の数値を項目値とするレコードと前記更新されない場合の数値を項目値とするレコードとのそれぞれに対して、前記新たな更新処理を行う、ことを実行させるデータベース制御プログラムが提供される。
【選択図】図５
Description
本発明は、データベース制御プログラム、データベース制御方法及びデータベース制御装置に関する。
複数のトランザクションからデータベースへのアクセスが同時に発生した場合、排他制御を行うことでデータベース内のデータの整合性が保証される。このとき、競合するトランザクションのうちの一方がデータの更新をコミット又はロールバックするまで他方のトランザクションは待ち状態になる。つまり、排他制御では、複数のトランザクションを並列に実行することができないため、トランザクションの処理効率が低下する。これに対して、競合するトランザクションを並列に実行する技術が知られている（例えば、特許文献１及び特許文献２参照）。
また、データベースの更新処理において、オンライン処理とバッチ処理とを並列に実行する技術として、ＭＶＣＣ（Multi-Version Concurrency Control：多版式同時実行制御）が知られている。ＭＶＣＣでは、更新前のレコードをデータベース上に記憶しつつ、更新後のレコードを新しいレコードとしてデータベース上に追記することで複数の新旧バージョンのレコードを管理する。これにより、比較的少量のレコードの更新を行うオンライン処理と比較的大量のレコードの更新を行うバッチ処理とを並列に実行することができる。
しかしながら、データベース内のデータのうち、最新のレコードはあくまで一つである。よって、複数のトランザクションがいずれも最新のレコードを更新しようとすると、それらの更新処理を同時に行うことはできず、排他制御しなければならない。例えば、並列に実行されているオンライン処理とバッチ処理とにおいて最新のレコードを更新する更新処理が発生した場合、オンライン処理とバッチ処理の一方の更新処理が完了しないと、ロックが解除されず、他方の更新処理が実行できない。このため、ロックが解除されるまでの間に他方の更新処理の待ち時間が発生し、処理効率が低下するという課題がある。
そこで、一側面では、本発明は、更新処理の待ち時間を短縮することを目的とする。
一つの案では、コンピュータに、データベースに記憶されたレコードに含まれる、データ項目の項目値に対する更新処理が発生した場合に、前記項目値が前記更新処理により更新された場合の数値を項目値とするレコードと、前記項目値が前記更新処理により更新されない場合の数値を項目値とするレコードと、を生成し、前記更新処理が発生したレコードに対して新たな更新処理が発生した場合に、前記更新された場合の数値を項目値とするレコードと前記更新されない場合の数値を項目値とするレコードとのそれぞれに対して、前記新たな更新処理を行う、ことを実行させるデータベース制御プログラムが提供される。
一側面によれば、更新処理の待ち時間を短縮することができる。
以下、本発明の実施形態について添付の図面を参照しながら説明する。なお、本明細書及び図面において、実質的に同一の機能構成を有する構成要素については、同一の符号を付することにより重複した説明を省く。
（データベース更新処理）
データベースへの更新処理を、オンライン処理とバッチ処理とに分け、昼間はオンライン処理、夜間はバッチ処理というように時間を分けて実行する方法がある。しかし、２４時間サービス化、グローバル化、スピード化に伴い、オンライン処理とバッチ処理とを並列で実行する必要性が出てきている。そこで、オンライン処理とバッチ処理とを並列に実行することができる技術としてＭＶＣＣが知られている。
データベースへの更新処理を、オンライン処理とバッチ処理とに分け、昼間はオンライン処理、夜間はバッチ処理というように時間を分けて実行する方法がある。しかし、２４時間サービス化、グローバル化、スピード化に伴い、オンライン処理とバッチ処理とを並列で実行する必要性が出てきている。そこで、オンライン処理とバッチ処理とを並列に実行することができる技術としてＭＶＣＣが知られている。
（ＭＶＣＣ）
ＭＶＣＣ（Multi-Version Concurrency Control：多版式同時実行制御）について、図１を参照しながら簡単に説明する。図１は、データベースに記憶されるレコードの一例を示す。ＭＶＣＣでは、更新前のレコードをデータベース上に記憶しつつ、更新後のレコードを新しいレコードとして同じデータベース上に追記する。
ＭＶＣＣ（Multi-Version Concurrency Control：多版式同時実行制御）について、図１を参照しながら簡単に説明する。図１は、データベースに記憶されるレコードの一例を示す。ＭＶＣＣでは、更新前のレコードをデータベース上に記憶しつつ、更新後のレコードを新しいレコードとして同じデータベース上に追記する。
例えば図１（ａ）に示すように、にんじんを１０個入荷するトランザクションプログラム（以下、「トランザクション」ともいう。）Ｔｘ１００による更新処理によってデータベースにレコード番号「Ｎｏ．１」のレコードが記憶されたとする。このとき、レコード番号「Ｎｏ．１」の品目、個数、追加トランザクション（Ｔｘ）ＩＤ、レコード状態の各項目には、にんじん、１０、Ｔｘ１００、有効の情報がそれぞれ記憶される。
次に、たまねぎを４個入荷するトランザクションＴｘ１０１による更新処理によってデータベースには図１（ｂ）に示すレコード番号「Ｎｏ．２」のレコードが記憶される。次に、たまねぎを４個加算するトランザクションＴｘ１０５による更新処理によって、データベースには図１（ｃ）に示すレコード番号「Ｎｏ．３」のレコードが記憶される。レコード番号「Ｎｏ．３」のレコードのたまねぎの個数は８個になる。このとき、更新前のレコード番号「Ｎｏ．２」のレコードをデータベースに記憶したまま、更新後のレコード番号「Ｎｏ．３」のレコードが新たに記憶される。レコード番号「Ｎｏ．２」のレコードの削除トランザクション（Ｔｘ）ＩＤには、トランザクションＴｘ１０５が記憶され、レコード番号「Ｎｏ．２」のレコードのレコード状態は無効になる。
次に、しいたけを２個入荷することと品目からたまねぎを削除するトランザクションＴｘ１１０による更新処理によって、図１（ｄ）に示すように、データベースにはレコード番号「Ｎｏ．４」のしいたけを２個入荷したことを記録するレコードが記憶される。また、品目からたまねぎを削除することで、レコード番号「Ｎｏ．３」のレコードの削除トランザクション（Ｔｘ）ＩＤには、トランザクションＴｘ１１０が記憶され、レコード番号「Ｎｏ．３」のレコードのレコード状態は無効になる。
例えばトランザクションＮｏ．が若い数字から順にトランザクション処理が実行された場合、他トランザクションＴｘ９０、Ｔｘ１０６、Ｔｘ１２０からのレコードの見え方の一例を図１（ｅ）に示す。図１（ｅ）では、トランザクションＴｘ９０、Ｔｘ１０６、Ｔｘ１２０のそれぞれからデータベースに格納された各レコードがどのように見えるかを示す。
トランザクションＴｘ９０は、トランザクションＴｘ１００よりも早く実行されるため、トランザクションＴｘ９０から見てレコード番号「Ｎｏ．１」〜「Ｎｏ．４」のレコードはデータベースに存在しない。トランザクションＴｘ１０６は、トランザクションＴｘ１０５とトランザクションＴｘ１１０との間に実行される。よって、トランザクションＴｘ１０６は、図１（ｃ）に示す有効なレコード番号「Ｎｏ．１」及び「Ｎｏ．３」のレコードを見ることができ、図１（ｃ）に示す無効なレコード番号「Ｎｏ．２」のレコードを見ることができない。また、このとき、図１（ｄ）に示すレコード番号「Ｎｏ．４」のレコードは存在しない。
トランザクションＴｘ１２０は、トランザクションＴｘ１１０の後に実行される。よって、トランザクションＴｘ１２０は、図１（ｄ）に示す有効なレコード番号「Ｎｏ．１」及び「Ｎｏ．４」のレコードを見ることができ、図１（ｄ）に示す無効なレコード番号「Ｎｏ．２」及び「Ｎｏ．３」のレコードを見ることができない。
（レコード更新時のロック）
以上に示したＭＶＣＣではデータベースに新旧バージョンのレコードが記憶される。しかしながら、一のデータについての最新のレコードはあくまで一つである。よって、複数のトランザクションがいずれも最新のレコードを更新しようとすると、それらの更新処理を同時に行うことはできず、排他制御が発生する。
以上に示したＭＶＣＣではデータベースに新旧バージョンのレコードが記憶される。しかしながら、一のデータについての最新のレコードはあくまで一つである。よって、複数のトランザクションがいずれも最新のレコードを更新しようとすると、それらの更新処理を同時に行うことはできず、排他制御が発生する。
例えば、図２を参照しながら２種類のトランザクションのレコード更新時のロックについて説明する。オンライン処理のトランザクションをＴｏ１〜Ｔｏ３で示し、バッチ処理のトランザクションをＴｂ１で示す。
オンライン処理のトランザクションＴｏ１〜Ｔｏ３は、少量のレコードを更新する。オンライン処理の一例としては出荷処理がある。オンライン処理のトランザクションは、同時に多数動作することがある。これに対して、バッチ処理のトランザクションＴｂ１は、大量のレコードを更新する。バッチ処理の一例としては入荷処理がある。バッチ処理のトランザクションが同時に動作する数は、オンライン処理よりも少ない。
例えば、同じデータベースに記憶されたレコードを更新する場合、先行のトランザクションを実行中、後続のトランザクションがロック待ちとなり後続のトランザクションの処理時間が間延びする。つまり、ロックが解除されるまで後続のトランザクションの更新処理が行えずに待ち時間が発生し、処理効率が低下するという課題がある。
図２の横軸は、各トランザクションＴｏ１〜Ｔｏ３、Ｔｂ１と各レコードのロック状況を示し、縦軸は、紙面の上から下へ向かって経過する時間を示す。具体的には、バッチ処理Ｔｂ１がにんじんのレコードを更新するためににんじんのレコードをロックした後、オンライン処理Ｔｏ１がたまねぎのレコードを更新するためにたまねぎのレコードをロックする。その後、バッチ処理Ｔｂ１がたまねぎのレコードを更新する際、図２の（１）に示すように、オンライン処理Ｔｏ１が更新中のためにたまねぎのレコードはロックされており、ロックが解除されるまでバッチ処理Ｔｂ１に待ち時間が生じる。オンライン処理Ｔｏ１のたまねぎのレコードの更新が完了（コミット）すると、バッチ処理Ｔｂ１がたまねぎのレコードをロックする。
次に、オンライン処理Ｔｏ２がしいたけのレコードを更新するためにしいたけのレコードをロックする。次に、バッチ処理Ｔｂ１がしいたけのレコードを更新する際、図２の（２）に示すように、オンライン処理Ｔｏ２が更新中であるため、しいたけのレコードのロックが解除されるまでバッチ処理Ｔｂ１に待ち時間が生じる。この結果、図２の（３）に示すように、同一レコードを同時に更新することができず、同一レコードの更新処理をシリアルに実行しているためにバッチ処理Ｔｂ１に待ち時間が蓄積する。このようにしてバッチ処理Ｔｂ１の処理時間がオンライン処理Ｔｏ１、Ｔｏ２の処理状況に応じて長くなる。同様に、図２の（４）に示すように、バッチ処理Ｔｂ１が更新中のレコードを更新したいオンライン処理Ｔｏ３は、バッチ処理Ｔｂ１の更新処理が完了するまで待たされる。
このように、データベースの更新処理において、オンライン処理とバッチ処理とを並列して実行するＭＶＣＣ技術があるものの、あくまでも最新のレコードは一つであるため複数のトランザクションで同時に同一のレコードを更新することはできない。あるレコードを更新する場合、そのレコードが他のトランザクションから更新されないようにロックする。ロックが解除されるのは、トランザクションの終了時、つまり、トランザクションがコミットされたときである。よって、先行のオンライン処理中のトランザクションのコミットを待たないと後続のバッチ処理が実行できない。同様に、先行のバッチ処理中のトランザクションのコミットを待たないと後続のオンライン処理が実行できない。
そこで、以下に説明する本実施形態にかかるデータベース制御方法では、複数のトランザクションによる同一レコードへの更新を並列に、かつ同時に更新する。これにより、先行のトランザクションがコミット又はロールバックするまで後続のトランザクションに生じる待ち時間を減らすことができる。その結果、トランザクションの更新処理における実行時間を短縮することができる。
なお、コミットは、更新処理を確定することをいい、ロールバックは、更新処理をコミットせずに更新処理の一つ前の状態に戻すことをいう。
［データベースサーバの機能構成］
まず、本発明の一実施形態に係るデータベースサーバ２０の機能構成の一例について、図３を参照しながら説明する。本実施形態に係るデータベースサーバ２０は、利用者端末１０とネットワークを介して接続されており、データベース２７に記憶されたデータの検索、更新、削除などの処理を実行するトランザクションを受け付ける。データベースサーバ２０は、データベース制御装置の一例である。
まず、本発明の一実施形態に係るデータベースサーバ２０の機能構成の一例について、図３を参照しながら説明する。本実施形態に係るデータベースサーバ２０は、利用者端末１０とネットワークを介して接続されており、データベース２７に記憶されたデータの検索、更新、削除などの処理を実行するトランザクションを受け付ける。データベースサーバ２０は、データベース制御装置の一例である。
データベースサーバ２０は、トランザクション実行部２１、レコード生成部２３、レコード削除部２４及び記憶部２５を有する。トランザクション実行部２１は、記憶部２５に記憶されるデータベース２７のデータの検索、更新、削除などの各種トランザクション処理を実行する。トランザクション実行部２１で実行されるトランザクション処理のうちの更新処理は、更新処理部２２により実行される。
具体的には、更新処理部２２は、更新処理が発生したレコードに対して新たな更新処理が発生した場合に、前記更新された場合の数値を項目値とするレコードと前記更新されない場合の数値を項目値とするレコードとのそれぞれに対して、新たな更新処理を行う。
データベース２７に記憶されたレコードに含まれる、データ項目の項目値に対する更新処理が発生した場合について説明する。この場合、レコード生成部２３は、項目値が更新処理により更新された場合の数値を項目値とするレコードと、項目値が更新処理により更新されない場合の数値を項目値とするレコードとを生成する。
レコード削除部２４は、いずれかの更新処理（新たな更新処理を含む）がコミット又はロールバックした時点で、取り得る可能性がなくなったデータ項目の項目値を含むレコードを削除する。
記憶部２５は、データベース２７に所定のデータを記憶する。図６にデータベース２７のデータ構造の一例を示す。データベース２７は、レコード番号２７１、品目２７２、個数２７３、トランザクションＩＤ２７４及びレコードの状態２７５の各データ項目を有する。本実施形態では、入荷処理や出荷処理のトランザクションを実行することで、数値の項目値である個数２７３が更新される。
記憶部２５には、データベース２７のデータの更新等を行うための更新処理プログラム２８がインストールされている。データベースサーバ２０は、更新処理プログラム２８がインストールされることにより、利用者端末１０が要求するデータベース２７のデータの検索、更新、削除などの各種トランザクション処理を実行する。
［データベース制御処理］
次に、本実施形態に係るデータベース制御処理中の更新処理について図４のフローチャートを参照して説明する。トランザクション実行部２１は、利用者端末１０からデータベース２７のデータ検索等を行うトランザクションを受け付けると、所定のデータを検索する。トランザクション実行部２１の更新処理部２２は、トランザクション中で実行されるデータの更新処理を実行する。
次に、本実施形態に係るデータベース制御処理中の更新処理について図４のフローチャートを参照して説明する。トランザクション実行部２１は、利用者端末１０からデータベース２７のデータ検索等を行うトランザクションを受け付けると、所定のデータを検索する。トランザクション実行部２１の更新処理部２２は、トランザクション中で実行されるデータの更新処理を実行する。
図４の更新処理の実行が開始されると、トランザクション実行部２１の更新処理部２２は、データベース２７の更新処理が発生したかを判定する（ステップＳ１０）。更新処理部２２は、データベース２７の更新処理が発生するまで待つ。更新処理部２２は、更新処理が発生した場合、更新処理により更新された場合の更新後レコードと、更新処理により更新されない場合の更新後レコードとの２ｎ（ｎ＝１）個（ここでは２個）の更新後レコードを生成する（ステップＳ１２）。
例えば、図５には、以下の＜パターン１−１＞のトランザクションが順に発生した場合にデータベース２７に記憶されるレコードの一例を示す。図５の紙面の左から右に向かって時間が経過し、各レコードの数値の経時的な遷移が示されている。
＜パターン１−１＞
先行トランザクション：入荷処理（バッチ処理）
後続トランザクション：出荷処理（オンライン処理）
・後続トランザクションが先行トランザクションよりも先にコミット（確定）する場合
（１）先行トランザクションを実行し、５０個を入荷
（２）後続トランザクションを実行し、３０個を出荷
（３）後続トランザクションの出荷処理がコミット（確定）
（４）先行トランザクションの入荷処理がコミット（確定）
図４のステップＳ１０において（１）先行トランザクションの更新処理が発生したとする。この場合、ステップＳ１２では、この時点で考えられる更新処理のすべてのレコードが生成される。ここで、（１）の入荷処理が成功した場合と、失敗した場合との２つの更新処理がこの時点で考えられる更新処理のすべてである。よって、（１）先行トランザクションの実行後、データベース２７には入荷処理が成功した場合の１５０個を記憶したレコードと、入荷処理が失敗した場合の１００個を記憶したレコードとが記憶される。
先行トランザクション：入荷処理（バッチ処理）
後続トランザクション：出荷処理（オンライン処理）
・後続トランザクションが先行トランザクションよりも先にコミット（確定）する場合
（１）先行トランザクションを実行し、５０個を入荷
（２）後続トランザクションを実行し、３０個を出荷
（３）後続トランザクションの出荷処理がコミット（確定）
（４）先行トランザクションの入荷処理がコミット（確定）
図４のステップＳ１０において（１）先行トランザクションの更新処理が発生したとする。この場合、ステップＳ１２では、この時点で考えられる更新処理のすべてのレコードが生成される。ここで、（１）の入荷処理が成功した場合と、失敗した場合との２つの更新処理がこの時点で考えられる更新処理のすべてである。よって、（１）先行トランザクションの実行後、データベース２７には入荷処理が成功した場合の１５０個を記憶したレコードと、入荷処理が失敗した場合の１００個を記憶したレコードとが記憶される。
つまり、（１）の先行トランザクション実行前、図６（ａ）に示すように、レコード番号２７１「Ｎｏ．１」のレコード（以下、「レコード１」ともいう。）がデータベース２７に記憶されているとする。
図６（ａ）の（１）に示すように、先行トランザクションＴｘ１１の実行後、（１）の入荷処理が成功した場合のレコード番号２７１「Ｎｏ．２」のレコード（以下、「レコード２」ともいう。）がデータベース２７に追記される。レコード２の各データ項目には、品目２７２「たまねぎ」、個数２７３「１５０」、トランザクションＩＤ２７４「Ｔｘ１１」、状態２７５「未コミット」が記憶される。また、（１）の入荷処理が失敗した場合のレコード番号２７１「Ｎｏ．１」もそのままデータベース２７に記憶される。
図４に戻り、次に、更新処理部２２は、すべての更新処理がコミットしたかを判定し（ステップＳ１４）、すべての更新処理がコミットした場合、本処理を終了する。この時点では、先行トランザクションの更新処理はコミットされていない。よって、更新処理部２２は、ステップＳ１６に進み、新たな更新処理が発生したかを判定する（ステップＳ１６）。
更新処理部２２は、新たな更新処理が発生していないと判定した場合、ステップＳ２２に進む。更新処理部２２は、新たな更新処理が発生したと判定した場合、ｎに「１」を加算する（ステップＳ１８）。次に、更新処理部２２は、更新後のレコード（図５の「１００」と「１５０」のレコード）のそれぞれに対して新たな更新処理により更新された場合の更新後レコード及び更新されない場合の更新後レコードの２ｎ（＝４）個の更新後レコードを生成する（ステップＳ２０）。
図４のステップＳ１６では図５の（２）後続トランザクションの更新処理が発生したとする。この場合、ステップＳ２０では、（１）の入荷処理が成功した場合と、失敗した場合とのそれぞれに対して、（２）の出荷処理が成功した場合と、失敗した場合との４つの組み合わせの更新処理が、この時点で考えられる更新処理のすべてである。
よって、（２）後続トランザクションの実行後、データベース２７には以下の４つのレコードが記憶される。
・（１）入荷処理が成功し、（２）出荷処理が成功した場合の１２０個を記憶したレコード
・（１）入荷処理が成功し、（２）出荷処理が失敗した場合の１５０個を記憶したレコード
・（１）入荷処理が失敗し、（２）出荷処理が成功した場合の７０個を記憶したレコード
・（１）入荷処理が失敗し、（２）出荷処理が失敗した場合の１００個を記憶したレコード
つまり、図６（ａ）の（２）に示すように、（２）の後続トランザクションＴｘ１２の実行後、レコード番号２７１「Ｎｏ．３」のレコード（レコード３）と「Ｎｏ．４」のレコード（レコード４）とがデータベース２７に追記される。レコード３の各データ項目には、品目２７２「たまねぎ」、個数２７３「７０」、トランザクションＩＤ２７４「Ｔｘ１２」、状態２７５「未コミット」が記憶される。レコード４の各データ項目には、品目２７２「たまねぎ」、個数２７３「１２０」、トランザクションＩＤ２７４「Ｔｘ１２」、状態２７５「未コミット」が記憶される。
・（１）入荷処理が成功し、（２）出荷処理が成功した場合の１２０個を記憶したレコード
・（１）入荷処理が成功し、（２）出荷処理が失敗した場合の１５０個を記憶したレコード
・（１）入荷処理が失敗し、（２）出荷処理が成功した場合の７０個を記憶したレコード
・（１）入荷処理が失敗し、（２）出荷処理が失敗した場合の１００個を記憶したレコード
つまり、図６（ａ）の（２）に示すように、（２）の後続トランザクションＴｘ１２の実行後、レコード番号２７１「Ｎｏ．３」のレコード（レコード３）と「Ｎｏ．４」のレコード（レコード４）とがデータベース２７に追記される。レコード３の各データ項目には、品目２７２「たまねぎ」、個数２７３「７０」、トランザクションＩＤ２７４「Ｔｘ１２」、状態２７５「未コミット」が記憶される。レコード４の各データ項目には、品目２７２「たまねぎ」、個数２７３「１２０」、トランザクションＩＤ２７４「Ｔｘ１２」、状態２７５「未コミット」が記憶される。
図４に戻り、次に、更新処理部２２は、いずれかの更新処理がコミット又はロールバックしたかを判定する（ステップＳ２２）。図５の場合、更新処理部２２は、（１）の先行トランザクションの更新処理又は（２）の後続トランザクションの更新処理がコミット又はロールバックしたかを判定する。更新処理部２２は、いずれの更新処理もコミット又はロールバックしていないと判定した場合、ステップＳ１４に戻り、ステップＳ１４以降の処理を繰り返す。
他方、更新処理部２２は、いずれかの更新処理がコミット又はロールバックしたと判定した場合、取り得る可能性がない更新後のレコードを削除し（ステップＳ２４）、その後、ステップＳ１４に戻り、ステップＳ１４以降の処理を繰り返す。
図５では（３）において後続トランザクションの出荷処理がコミットする。この場合、（３−２）に示す出荷されていない場合の「１５０」のレコードは、取り得る可能性がない更新後レコードであるため、削除される。また、（３−１）に示すように、「１００」で示すレコードがコミット済の古いレコードになり、「７０」で示すレコードがコミット済の最新レコードになる。更に、（３−３）に示すように、「１２０」で示すレコードは、入荷後に出荷した（１２０＝１００＋５０−３０）ではなく、出荷後に入荷した（１２０＝１００−３０＋５０＝７０＋５０））未コミットのレコードになる。
この結果、この時点では、図６（ｂ）に示すように、（３）の後続トランザクションＴｘ１２のコミット後、レコード２がデータベース２７から削除される。この結果、レコード１の状態２７５が「コミット済古い（コミット済の古いレコード）」、レコード３の状態２７５が「コミット済最新（コミット済の最新レコード）」、レコード４の状態２７５が「未コミット（コミットされていないレコード）」となる３つのレコードが記憶される。
図４に戻り、次に、更新処理部２２は、ステップＳ１４に戻り、すべての更新処理がコミットされているかを判定する。この時点で（４）先行トランザクションの入荷処理がコミットされていない。よって、更新処理部２２は、ステップＳ１６に進み、新たな更新処理が発生したかを判定する。この時点では新たな更新処理が発生していない。よって、更新処理部２２は、ステップＳ２２に進み、いずれかの更新処理がコミット又はロールバックしたかを判定する（ステップＳ２２）。図５の場合、更新処理部２２は、（３）の後続トランザクションがコミットした後、（４）の先行トランザクションの更新処理がコミットされている。このとき、更新処理部２２は、取り得る可能性がない更新後のレコードを削除する（ステップＳ２４）。ここでは削除すべき更新後のレコードは存在しない。
図５に示すように、（４）の先行トランザクションの更新処理がコミットされた場合、図５の（４―１）に示す「１２０」のレコード４が、コミット済の最新値「１２０」を有する最新レコードと判定される。これにより、「１２０」を有する最新レコードは、他のトランザクションから参照可能になる。そして、図５の（４―２）に示す「７０」のレコード３が、「コミット済古い」となる。この時点では、図６（ｃ）に示すように、（４）の先行トランザクションＴｘ１１のコミット後、レコード１及びレコード３の状態２７５「コミット済古い」、レコード４の状態２７５「コミット済最新」で示される３つのレコードが記憶される。
図４に戻り、ステップＳ１４に戻り、この時点で、更新処理部２２は、すべての更新処理がコミットされたと判定し、本処理を終了する。
以上に説明したように、本実施形態にかかるデータベース制御方法によれば、本実施形態は、データベースのトランザクションの同時実行に関し、特に同一資源に対して複数のトランザクションの更新処理を同時に行うことができる。つまり、一のトランザクションが他のトランザクションの更新処理が終わることを待つのではなく、同時に同一のデータに対して更新処理を行うことができる。これにより、データベースの更新処理において、オンライン処理とバッチ処理を同時に実行できる。
具体的には、本実施形態では、あるトランザクションがコミットする前に、別のトランザクションの処理を実行した場合において、その時点で考えられる更新処理のすべてのレコードが生成される。これにより、データベース２７の更新処理において、複数のトランザクション（例えば、オンライン処理とバッチ処理）の更新処理を同時に実行できる。この結果、複数のトランザクション処理の待ち時間を短縮することができる。
また、本実施形態では、それぞれのトランザクションがコミットした時点で取り得ないレコードを削除する。これにより、不要なレコードをデータベース２７から削除し、複数のトランザクションアクセス可能な共通資源を有効利用することができる。
以上の＜パターン１−１＞では、後続トランザクションが先行トランザクションよりも先にコミットする場合についてのデータベース２７に記憶されるレコードについて説明した。次に、先行トランザクションが後続トランザクションよりも先にコミットする場合の＜パターン１−２＞について、図７を参照して説明する
＜パターン１−２＞
＜パターン１−２＞では以下の手順でトランザクションが処理される。
（１）先行トランザクションを実行し、５０個を入荷
（２）後続トランザクションを実行し、３０個を出荷
（３）先行トランザクションの入荷処理がコミット
（４）後続トランザクションの出荷処理がコミット
この場合、図４の本実施形態にかかる更新処理を実行すると、（３）の先行トランザクションの処理がコミットされた場合、図７の（３−２）に示す入荷されていない場合の「７０」のレコードは、取り得る可能性がない更新後レコードであるため、削除される。
＜パターン１−２＞
＜パターン１−２＞では以下の手順でトランザクションが処理される。
（１）先行トランザクションを実行し、５０個を入荷
（２）後続トランザクションを実行し、３０個を出荷
（３）先行トランザクションの入荷処理がコミット
（４）後続トランザクションの出荷処理がコミット
この場合、図４の本実施形態にかかる更新処理を実行すると、（３）の先行トランザクションの処理がコミットされた場合、図７の（３−２）に示す入荷されていない場合の「７０」のレコードは、取り得る可能性がない更新後レコードであるため、削除される。
（４）の後続トランザクションの処理がコミットされた場合、図７の（４―１）に示す「１２０」のレコードが、コミット済の最新値「１２０」を有する最新レコードと判定される。これにより、「１２０」を有する最新レコードは、他のトランザクションから参照可能になる。そして、図７の（４―２）に示す「１５０」のレコードが、「コミット済古い」となる。この結果、（４）の後続トランザクションＴｘ１２のコミット後、「１００」、「１５０」の２つのレコードの状態２７５が「コミット済古い」、「１２０」のレコードの状態２７５が「コミット済最新」となる３つのレコードが記憶される。
以上では、更新処理部２２は、各トランザクションがコミットした時点で取り得る可能性がなくなったレコードを削除した。次に、更新処理部２２は、各トランザクションがロールバック（失敗）した時点においても取り得る可能性がなくなったレコードを削除する場合のデータベース制御方法について説明する。
＜パターン２−１＞
以下では、＜パターン２−１＞の後続トランザクションがコミット後に先行トランザクションがロールバック（取消）される場合について、図８を参照して説明する。＜パターン２−１＞では以下の手順でトランザクションが処理される。
（１）先行トランザクションを実行し、５０個を入荷
（２）後続トランザクションを実行し、３０個を出荷
（３）後続トランザクションの出荷処理がコミット
（４）先行トランザクションの入荷処理がロールバック（取消）
＜パターン２−１＞の（１）〜（３）の手順は、＜パターン１−１＞の（１）〜（３）の手順と同じである。よって、図８の（３）後続トランザクションの出荷処理がコミットしたときにデータベース２７に記憶されたレコードは、＜パターン１−１＞の場合と同じである。
以下では、＜パターン２−１＞の後続トランザクションがコミット後に先行トランザクションがロールバック（取消）される場合について、図８を参照して説明する。＜パターン２−１＞では以下の手順でトランザクションが処理される。
（１）先行トランザクションを実行し、５０個を入荷
（２）後続トランザクションを実行し、３０個を出荷
（３）後続トランザクションの出荷処理がコミット
（４）先行トランザクションの入荷処理がロールバック（取消）
＜パターン２−１＞の（１）〜（３）の手順は、＜パターン１−１＞の（１）〜（３）の手順と同じである。よって、図８の（３）後続トランザクションの出荷処理がコミットしたときにデータベース２７に記憶されたレコードは、＜パターン１−１＞の場合と同じである。
＜パターン２−１＞の（４）の手順は、図５に示す＜パターン１−１＞の入荷処理のコミットと異なり、入荷処理のロールバックである。このとき、図８の（４―１）に示す「７０」のレコードが、最新レコードと判定される。これにより、「７０」を有する最新レコードは、他のトランザクションから参照可能になる。そして、図８の（４―２）に示す「１２０」のレコードは、取り得る可能性がなくなったレコードであり、削除される。この時点では、（４）の先行トランザクションのロールバック後、図８の（４）に示す「１００」のレコードの状態２７５が「コミット済古い」、「７０」のレコードの状態２７５が「コミット済最新」となる２つのレコードが記憶される。
＜パターン２−２＞
次に、＜パターン２−２＞の先行トランザクションがロールバック後に後続トランザクションがコミットされる場合について、図９を参照して説明する。＜パターン２−２＞では以下の手順でトランザクションが処理される。
（１）先行トランザクションを実行し、５０個を入荷
（２）後続トランザクションを実行し、３０個を出荷
（３）先行トランザクションの入荷処理がロールバック
（４）後続トランザクションの出荷処理がコミット
＜パターン２−２＞の（１）（２）（４）の手順は、図７に示す＜パターン１−２＞の（１）（２）（４）の手順と同じである。＜パターン２−２＞の（３）の手順は、＜パターン１−２＞の入荷処理のコミットと異なり、入荷処理のロールバックである。このとき、図９の（３）に示す「１２０」、「１５０」のレコードは、取り得る可能性がなくなったレコードであり、削除される。そして、＜パターン２−２＞の（４）にて後続トランザクションの出荷処理がコミットすると、図９の（４）に示す「７０」が「コミット済み最新」レコードになり、「１００」が「コミット済古い」となる２つのレコードがデータベース２７上に記憶される。
次に、＜パターン２−２＞の先行トランザクションがロールバック後に後続トランザクションがコミットされる場合について、図９を参照して説明する。＜パターン２−２＞では以下の手順でトランザクションが処理される。
（１）先行トランザクションを実行し、５０個を入荷
（２）後続トランザクションを実行し、３０個を出荷
（３）先行トランザクションの入荷処理がロールバック
（４）後続トランザクションの出荷処理がコミット
＜パターン２−２＞の（１）（２）（４）の手順は、図７に示す＜パターン１−２＞の（１）（２）（４）の手順と同じである。＜パターン２−２＞の（３）の手順は、＜パターン１−２＞の入荷処理のコミットと異なり、入荷処理のロールバックである。このとき、図９の（３）に示す「１２０」、「１５０」のレコードは、取り得る可能性がなくなったレコードであり、削除される。そして、＜パターン２−２＞の（４）にて後続トランザクションの出荷処理がコミットすると、図９の（４）に示す「７０」が「コミット済み最新」レコードになり、「１００」が「コミット済古い」となる２つのレコードがデータベース２７上に記憶される。
＜パターン３−１＞
以下では、＜パターン３−１＞の後続トランザクションがロールバック後に先行トランザクションがコミットする場合について、図１０を参照して説明する。＜パターン３−１＞では以下の手順でトランザクションが処理される。
（１）先行トランザクションを実行し、５０個を入荷
（２）後続トランザクションを実行し、３０個を出荷
（３）後続トランザクションの出荷処理がロールバック
（４）先行トランザクションの入荷処理がコミット
＜パターン３−１＞の（１）（２）（４）の手順は、図５に示す＜パターン１−１＞の（１）（２）（４）の手順と同じである。＜パターン３−１＞の（３）の手順は、＜パターン１−１＞の出荷処理のコミットと異なり、出荷処理のロールバックである。このとき、図１０の（３−１）及び（３−２）に示す「７０」、「１２０」のレコードは、取り得る可能性がなくなったレコードであり、削除される。そして、＜パターン３−１＞の（４）にて先行トランザクションの入荷処理がコミットすると、図１０の（４）に示す「１５０」が「コミット済み最新」、「１００」のレコードの状態２７５が「コミット済古い」となる２つのレコードがデータベース２７上に記憶される。
以下では、＜パターン３−１＞の後続トランザクションがロールバック後に先行トランザクションがコミットする場合について、図１０を参照して説明する。＜パターン３−１＞では以下の手順でトランザクションが処理される。
（１）先行トランザクションを実行し、５０個を入荷
（２）後続トランザクションを実行し、３０個を出荷
（３）後続トランザクションの出荷処理がロールバック
（４）先行トランザクションの入荷処理がコミット
＜パターン３−１＞の（１）（２）（４）の手順は、図５に示す＜パターン１−１＞の（１）（２）（４）の手順と同じである。＜パターン３−１＞の（３）の手順は、＜パターン１−１＞の出荷処理のコミットと異なり、出荷処理のロールバックである。このとき、図１０の（３−１）及び（３−２）に示す「７０」、「１２０」のレコードは、取り得る可能性がなくなったレコードであり、削除される。そして、＜パターン３−１＞の（４）にて先行トランザクションの入荷処理がコミットすると、図１０の（４）に示す「１５０」が「コミット済み最新」、「１００」のレコードの状態２７５が「コミット済古い」となる２つのレコードがデータベース２７上に記憶される。
＜パターン３−２＞
次に、＜パターン３−２＞の先行トランザクションがコミット後に後続トランザクションがロールバックする場合について、図１１を参照して説明する。＜パターン３−２＞では以下の手順でトランザクションが処理される。
（１）先行トランザクションを実行し、５０個を入荷
（２）後続トランザクションを実行し、３０個を出荷
（３）先行トランザクションの入荷処理がコミット
（４）後続トランザクションの出荷処理がロールバック
＜パターン３−２＞の（１）〜（３）の手順は、図７に示す＜パターン１−２＞の（１）〜（３）の手順と同じである。＜パターン３−２＞の（４）の手順は、＜パターン１−２＞の出荷処理のコミットと異なり、出荷処理のロールバックである。このとき、図１１の（４）に示す「１２０」のレコードは、取り得る可能性がなくなったレコードであり、削除される。よって、「１００」のレコードの状態２７５が「コミット済古い」、「１５０」のレコードの状態２７５が「コミット済最新」となる２つのレコードがデータベース２７上に記憶される。
次に、＜パターン３−２＞の先行トランザクションがコミット後に後続トランザクションがロールバックする場合について、図１１を参照して説明する。＜パターン３−２＞では以下の手順でトランザクションが処理される。
（１）先行トランザクションを実行し、５０個を入荷
（２）後続トランザクションを実行し、３０個を出荷
（３）先行トランザクションの入荷処理がコミット
（４）後続トランザクションの出荷処理がロールバック
＜パターン３−２＞の（１）〜（３）の手順は、図７に示す＜パターン１−２＞の（１）〜（３）の手順と同じである。＜パターン３−２＞の（４）の手順は、＜パターン１−２＞の出荷処理のコミットと異なり、出荷処理のロールバックである。このとき、図１１の（４）に示す「１２０」のレコードは、取り得る可能性がなくなったレコードであり、削除される。よって、「１００」のレコードの状態２７５が「コミット済古い」、「１５０」のレコードの状態２７５が「コミット済最新」となる２つのレコードがデータベース２７上に記憶される。
以上に説明したように、本実施形態にかかるデータベース制御方法及び更新方法によれば、先行の更新処理が発生したレコードに対してその更新処理がコミットされる前に、後続の新たな更新処理が発生する度に、新たな更新処理を行う。新たな更新処理は、更新された場合の数値を項目値とするレコードと更新されない場合の数値を項目値とするレコードとのそれぞれに対して行われる。これにより、先行トランザクションがコミットされる前に後続トランザクションの更新処理を実行できる。つまり、データベース２７に記憶したデータの整合性を担保しながら、先行トランザクションと後続トランザクションとの更新処理を同時に実行することができる。
なお、以上の各パターンの説明では、先行と後続の関係にある２つのトランザクションの更新処理を例に挙げて説明した。しかしながら、本実施形態にかかる更新処理は、先行と後続の関係にある２つのトランザクションの更新処理に限らず、他のトランザクションについても適用可能である。
例えば、先行の更新処理が発生したレコードに対して該更新処理がコミットされる前に、後続の新たな更新処理が発生する度に、更新された場合の数値をもつレコードと更新されなかった場合の数値を持つレコードとのそれぞれに対して、前記新たな更新処理を行う。これにより、先行と後続の関係にある３つ以上のトランザクションの更新処理を同時に実行することができる。
（ハードウェア構成例）
最後に、本実施形態に係るデータベースサーバ２０のハードウェア構成について、図１２を参照して説明する。は、入力装置１０１、表示装置１０２、外部Ｉ／Ｆ１０３、ＲＡＭ（Random Access Memory）１０４、ＲＯＭ（Read Only Memory）１０５、ＣＰＵ（Central Processing Unit）１０６、通信Ｉ／Ｆ１０７、及びＨＤＤ（Hard Disk Drive）１０８などを備え、それぞれがバスＢで相互に接続されている。
最後に、本実施形態に係るデータベースサーバ２０のハードウェア構成について、図１２を参照して説明する。は、入力装置１０１、表示装置１０２、外部Ｉ／Ｆ１０３、ＲＡＭ（Random Access Memory）１０４、ＲＯＭ（Read Only Memory）１０５、ＣＰＵ（Central Processing Unit）１０６、通信Ｉ／Ｆ１０７、及びＨＤＤ（Hard Disk Drive）１０８などを備え、それぞれがバスＢで相互に接続されている。
入力装置１０１は、キーボードやマウスなどを含み、データベースサーバ２０に各操作信号を入力するために用いられる。表示装置１０２は、ディスプレイなどを含み、各種の処理結果を表示する。通信Ｉ／Ｆ１０７は、データベースサーバ２０をネットワークに接続するインタフェースである。これにより、データベースサーバ２０は、通信Ｉ／Ｆ１０７を介して、利用者端末１０とデータ通信を行うことができる。
ＨＤＤ１０８は、プログラムやデータを格納している不揮発性の記憶装置である。格納されるプログラムやデータには、データベースサーバ２０の全体を制御する基本ソフトウェア及びアプリケーションソフトウェアがある。例えば、ＨＤＤ１０８には、各種のデータベースやプログラム等が格納されてもよい。
外部Ｉ／Ｆ１０３は、外部装置とのインタフェースである。外部装置には、記録媒体１０３ａなどがある。これにより、データベースサーバ２０は、外部Ｉ／Ｆ１０３を介して記録媒体１０３ａの読み取り及び／又は書き込みを行うことができる。記録媒体１０３ａには、ＣＤ（Compact Disk）、及びＤＶＤ（Digital Versatile Disk）、ならびに、ＳＤメモリカード（SD Memory card）やＵＳＢメモリ（Universal Serial Bus memory）等がある。
ＲＯＭ１０５は、電源を切っても内部データを保持することができる不揮発性の半導体メモリ（記憶装置）である。ＲＯＭ１０５には、ネットワーク設定等のプログラム及びデータが格納されている。ＲＡＭ１０４は、プログラムやデータを一時保持する揮発性の半導体メモリ（記憶装置）である。ＣＰＵ１０６は、上記記憶装置（例えば「ＨＤＤ１０８」や「ＲＯＭ１０５」など）から、プログラムやデータをＲＡＭ１０４上に読み出し、処理を実行することで、装置全体の制御や搭載機能を実現する演算装置である。
かかる構成により、本実施形態に係るデータベースサーバ２０では、ＣＰＵ１０６が、ＲＯＭ１０５やＨＤＤ１０８内に格納されたデータベース２７内のデータ及び更新処理プログラム２８を用いて更新処理を実行する。更新処理プログラム２８は、データベース制御プログラムの一例である。なお、データベース２７に記憶された情報は、ＲＡＭ１０４、ＨＤＤ１０８、又はネットワークを介してデータベースサーバ２０に接続されるクラウド上のサーバ等に格納され得る。
以上、データベース制御プログラム、データベース制御方法及びデータベース制御装置を上記実施形態により説明したが、本発明にかかるデータベース制御プログラム、データベース制御方法及びデータベース制御装置は上記実施形態に限定されるものではなく、本発明の範囲内で種々の変形及び改良が可能である。また、上記実施形態及び変形例が複数存在する場合、矛盾しない範囲で組み合わせることができる。
なお、データベース２７に記憶し、本発明の更新対象となるデータは、数値のみなず、文字データ、所定のステータスを示すフラグ、バイナリデータ等であってもよい。また、トランザクションのコミットにより不要となったレコードは、定期的に削除されるようになっている。
また、本発明は、入荷処理のトランザクションの実行後に入荷処理後の値を参照するトランザクションを実行する場合前後のトランザクションを並行して処理することは困難である。また、出荷処理のトランザクションの実行後に出荷処理後の値を参照するトランザクションを実行する場合、前後のトランザクションを並行して処理することは困難である。
以上の説明に関し、更に以下の項を開示する。
（付記１）
コンピュータに、
データベースに記憶されたレコードに含まれる、データ項目の項目値に対する更新処理が発生した場合に、前記項目値が前記更新処理により更新された場合の数値を項目値とするレコードと、前記項目値が前記更新処理により更新されない場合の数値を項目値とするレコードと、を生成し、
前記更新処理が発生したレコードに対して新たな更新処理が発生した場合に、前記更新された場合の数値を項目値とするレコードと前記更新されない場合の数値を項目値とするレコードとのそれぞれに対して、前記新たな更新処理を行う、
ことを実行させるデータベース制御プログラム。
（付記２）
前記更新処理及び新たな更新処理の少なくともいずれかがコミット又はロールバックした時点で、取り得る可能性がなくなったデータ項目の項目値を含むレコードを削除する、
付記１に記載のデータベース制御プログラム。
（付記３）
先行の前記更新処理が発生したレコードに対して該更新処理がコミットされる前に、後続の前記新たな更新処理が発生する度に、前記更新された場合の数値を項目値とするレコードと前記更新されない場合の数値を項目値とするレコードとのそれぞれに対して、前記新たな更新処理を行う、
付記１又は２に記載のデータベース制御プログラム。
（付記４）
コンピュータが、
データベースに記憶されたレコードに含まれる、データ項目の項目値に対する更新処理が発生した場合に、前記項目値が前記更新処理により更新された場合の数値を項目値とするレコードと、前記項目値が前記更新処理により更新されない場合の数値を項目値とするレコードと、を生成し、
前記更新処理が発生したレコードに対して新たな更新処理が発生した場合に、前記更新された場合の数値を項目値とするレコードと前記更新されない場合の数値を項目値とするレコードとのそれぞれに対して、前記新たな更新処理を行う、
ことを実行するデータベース制御方法。
（付記５）
前記更新処理及び新たな更新処理の少なくともいずれかがコミット又はロールバックした時点で、取り得る可能性がなくなったデータ項目の項目値を含むレコードを削除する、
付記４に記載のデータベース制御方法。
（付記６）
先行の前記更新処理が発生したレコードに対して該更新処理がコミットされる前に、後続の前記新たな更新処理が発生する度に、前記更新された場合の数値を項目値とするレコードと前記更新されない場合の数値を項目値とするレコードとのそれぞれに対して、前記新たな更新処理を行う、
付記４又は５に記載のデータベース制御方法。
（付記７）
データベースに記憶されたレコードに含まれる、データ項目の項目値に対する更新処理が発生した場合に、前記項目値が前記更新処理により更新された場合の数値を項目値とするレコードと、前記項目値が前記更新処理により更新されない場合の数値を項目値とするレコードと、を生成するレコード生成部と、
前記更新処理が発生したレコードに対して新たな更新処理が発生した場合に、前記更新された場合の数値を項目値とするレコードと前記更新されない場合の数値を項目値とするレコードとのそれぞれに対して、前記新たな更新処理を行う更新処理部と、
を有するデータベース制御装置。
（付記８）
前記更新処理及び新たな更新処理の少なくともいずれかがコミット又はロールバックした時点で、取り得る可能性がなくなったデータ項目の項目値を含むレコードを削除するレコード削除部を有する、
付記７に記載のデータベース制御装置。
（付記９）
前記更新処理部は、先行の前記更新処理が発生したレコードに対して該更新処理がコミットされる前に、後続の前記新たな更新処理が発生する度に、前記更新された場合の数値を項目値とするレコードと前記更新されない場合の数値を項目値とするレコードとのそれぞれに対して、前記新たな更新処理を行う、
付記７又は８に記載のデータベース制御装置。
（付記１）
コンピュータに、
データベースに記憶されたレコードに含まれる、データ項目の項目値に対する更新処理が発生した場合に、前記項目値が前記更新処理により更新された場合の数値を項目値とするレコードと、前記項目値が前記更新処理により更新されない場合の数値を項目値とするレコードと、を生成し、
前記更新処理が発生したレコードに対して新たな更新処理が発生した場合に、前記更新された場合の数値を項目値とするレコードと前記更新されない場合の数値を項目値とするレコードとのそれぞれに対して、前記新たな更新処理を行う、
ことを実行させるデータベース制御プログラム。
（付記２）
前記更新処理及び新たな更新処理の少なくともいずれかがコミット又はロールバックした時点で、取り得る可能性がなくなったデータ項目の項目値を含むレコードを削除する、
付記１に記載のデータベース制御プログラム。
（付記３）
先行の前記更新処理が発生したレコードに対して該更新処理がコミットされる前に、後続の前記新たな更新処理が発生する度に、前記更新された場合の数値を項目値とするレコードと前記更新されない場合の数値を項目値とするレコードとのそれぞれに対して、前記新たな更新処理を行う、
付記１又は２に記載のデータベース制御プログラム。
（付記４）
コンピュータが、
データベースに記憶されたレコードに含まれる、データ項目の項目値に対する更新処理が発生した場合に、前記項目値が前記更新処理により更新された場合の数値を項目値とするレコードと、前記項目値が前記更新処理により更新されない場合の数値を項目値とするレコードと、を生成し、
前記更新処理が発生したレコードに対して新たな更新処理が発生した場合に、前記更新された場合の数値を項目値とするレコードと前記更新されない場合の数値を項目値とするレコードとのそれぞれに対して、前記新たな更新処理を行う、
ことを実行するデータベース制御方法。
（付記５）
前記更新処理及び新たな更新処理の少なくともいずれかがコミット又はロールバックした時点で、取り得る可能性がなくなったデータ項目の項目値を含むレコードを削除する、
付記４に記載のデータベース制御方法。
（付記６）
先行の前記更新処理が発生したレコードに対して該更新処理がコミットされる前に、後続の前記新たな更新処理が発生する度に、前記更新された場合の数値を項目値とするレコードと前記更新されない場合の数値を項目値とするレコードとのそれぞれに対して、前記新たな更新処理を行う、
付記４又は５に記載のデータベース制御方法。
（付記７）
データベースに記憶されたレコードに含まれる、データ項目の項目値に対する更新処理が発生した場合に、前記項目値が前記更新処理により更新された場合の数値を項目値とするレコードと、前記項目値が前記更新処理により更新されない場合の数値を項目値とするレコードと、を生成するレコード生成部と、
前記更新処理が発生したレコードに対して新たな更新処理が発生した場合に、前記更新された場合の数値を項目値とするレコードと前記更新されない場合の数値を項目値とするレコードとのそれぞれに対して、前記新たな更新処理を行う更新処理部と、
を有するデータベース制御装置。
（付記８）
前記更新処理及び新たな更新処理の少なくともいずれかがコミット又はロールバックした時点で、取り得る可能性がなくなったデータ項目の項目値を含むレコードを削除するレコード削除部を有する、
付記７に記載のデータベース制御装置。
（付記９）
前記更新処理部は、先行の前記更新処理が発生したレコードに対して該更新処理がコミットされる前に、後続の前記新たな更新処理が発生する度に、前記更新された場合の数値を項目値とするレコードと前記更新されない場合の数値を項目値とするレコードとのそれぞれに対して、前記新たな更新処理を行う、
付記７又は８に記載のデータベース制御装置。
１０：利用者端末
２０：データベースサーバ
２１：トランザクション実行部
２２：更新処理部
２３：レコード生成部
２４：レコード削除部
２５：記憶部
２７：データベース
２０：データベースサーバ
２１：トランザクション実行部
２２：更新処理部
２３：レコード生成部
２４：レコード削除部
２５：記憶部
２７：データベース
Claims (5)
- コンピュータに、
データベースに記憶されたレコードに含まれる、データ項目の項目値に対する更新処理が発生した場合に、前記項目値が前記更新処理により更新された場合の数値を項目値とするレコードと、前記項目値が前記更新処理により更新されない場合の数値を項目値とするレコードと、を生成し、
前記更新処理が発生したレコードに対して新たな更新処理が発生した場合に、前記更新された場合の数値を項目値とするレコードと前記更新されない場合の数値を項目値とするレコードとのそれぞれに対して、前記新たな更新処理を行う、
ことを実行させるデータベース制御プログラム。 - 前記更新処理及び新たな更新処理の少なくともいずれかがコミット又はロールバックした時点で、取り得る可能性がなくなったデータ項目の項目値を含むレコードを削除する、
請求項１に記載のデータベース制御プログラム。 - 先行の前記更新処理が発生したレコードに対して該更新処理がコミットされる前に、後続の前記新たな更新処理が発生する度に、前記更新された場合の数値を項目値とするレコードと前記更新されない場合の数値を項目値とするレコードとのそれぞれに対して、前記新たな更新処理を行う、
請求項１又は２に記載のデータベース制御プログラム。 - コンピュータが、
データベースに記憶されたレコードに含まれる、データ項目の項目値に対する更新処理が発生した場合に、前記項目値が前記更新処理により更新された場合の数値を項目値とするレコードと、前記項目値が前記更新処理により更新されない場合の数値を項目値とするレコードと、を生成し、
前記更新処理が発生したレコードに対して新たな更新処理が発生した場合に、前記更新された場合の数値を項目値とするレコードと前記更新されない場合の数値を項目値とするレコードとのそれぞれに対して、前記新たな更新処理を行う、
ことを実行するデータベース制御方法。 - データベースに記憶されたレコードに含まれる、データ項目の項目値に対する更新処理が発生した場合に、前記項目値が前記更新処理により更新された場合の数値を項目値とするレコードと、前記項目値が前記更新処理により更新されない場合の数値を項目値とするレコードと、を生成するレコード生成部と、
前記更新処理が発生したレコードに対して新たな更新処理が発生した場合に、前記更新された場合の数値を項目値とするレコードと前記更新されない場合の数値を項目値とするレコードとのそれぞれに対して、前記新たな更新処理を行う更新処理部と、
を有するデータベース制御装置。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2015176111A JP6515753B2 (ja) | 2015-09-07 | 2015-09-07 | データベース制御プログラム、データベース制御方法及びデータベース制御装置 |
| US15/246,886 US10417214B2 (en) | 2015-09-07 | 2016-08-25 | Non-transitory computer-readable storage medium, database control method and database control device |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2015176111A JP6515753B2 (ja) | 2015-09-07 | 2015-09-07 | データベース制御プログラム、データベース制御方法及びデータベース制御装置 |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2017054207A true JP2017054207A (ja) | 2017-03-16 |
| JP6515753B2 JP6515753B2 (ja) | 2019-05-22 |
Family
ID=58191003
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2015176111A Active JP6515753B2 (ja) | 2015-09-07 | 2015-09-07 | データベース制御プログラム、データベース制御方法及びデータベース制御装置 |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US10417214B2 (ja) |
| JP (1) | JP6515753B2 (ja) |
Cited By (1)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2019102059A (ja) * | 2017-12-04 | 2019-06-24 | エスアーペー エスエー | 不揮発性メモリにおけるマルチバージョン同時実行制御（ｍｖｃｃ） |
Citations (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH1185544A (ja) * | 1997-09-04 | 1999-03-30 | Nec Corp | トランザクションプログラム並列実行方法およびトラン ザクションプログラム並列実行方式 |
| US20090292706A1 (en) * | 2008-05-22 | 2009-11-26 | Fujitsu Limited | Apparatus and method for data management |
Family Cites Families (5)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2837288B2 (ja) | 1990-09-17 | 1998-12-14 | インターナショナル・ビジネス・マシーンズ・コーポレイション | 連鎖分散データトランザクションシステムにおけるワーク単位識別子の管理方法 |
| US5950212A (en) * | 1997-04-11 | 1999-09-07 | Oracle Corporation | Method and system for workload based group committing for improved performance |
| GB2397401A (en) * | 2003-01-15 | 2004-07-21 | Luke Leonard Martin Porter | Time in databases and applications of databases |
| JP4261609B1 (ja) | 2008-05-02 | 2009-04-30 | 透 降矢 | トランザクションの同時実行制御を備えたマルチオペレーション・プロセッシングを用いたデータベースのトランザクション処理システム |
| JP5652228B2 (ja) | 2011-01-25 | 2015-01-14 | 富士通株式会社 | データベースサーバ装置、データベース更新方法及びデータベース更新プログラム |
-
2015
- 2015-09-07 JP JP2015176111A patent/JP6515753B2/ja active Active
-
2016
- 2016-08-25 US US15/246,886 patent/US10417214B2/en active Active
Patent Citations (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JPH1185544A (ja) * | 1997-09-04 | 1999-03-30 | Nec Corp | トランザクションプログラム並列実行方法およびトラン ザクションプログラム並列実行方式 |
| US20090292706A1 (en) * | 2008-05-22 | 2009-11-26 | Fujitsu Limited | Apparatus and method for data management |
| JP2009282746A (ja) * | 2008-05-22 | 2009-12-03 | Fujitsu Ltd | データ管理プログラム、データ管理方法、及びデータ管理装置 |
Cited By (2)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2019102059A (ja) * | 2017-12-04 | 2019-06-24 | エスアーペー エスエー | 不揮発性メモリにおけるマルチバージョン同時実行制御（ｍｖｃｃ） |
| JP7101566B2 (ja) | 2017-12-04 | 2022-07-15 | エスアーペー エスエー | 不揮発性メモリにおけるマルチバージョン同時実行制御（ｍｖｃｃ） |
Also Published As
| Publication number | Publication date |
|---|---|
| US10417214B2 (en) | 2019-09-17 |
| US20170068701A1 (en) | 2017-03-09 |
| JP6515753B2 (ja) | 2019-05-22 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US8868514B2 (en) | Transaction support for distributed data | |
| EP3117348B1 (en) | Systems and methods to optimize multi-version support in indexes | |
| EP3079078B1 (en) | Multi-version concurrency control method in database, and database system | |
| US8832159B2 (en) | Systems and methods for asynchronous schema changes | |
| US9020916B2 (en) | Database server apparatus, method for updating database, and recording medium for database update program | |
| US9652492B2 (en) | Out-of-order execution of strictly-ordered transactional workloads | |
| US11914569B2 (en) | Light weight redundancy tool for performing transactions | |
| CN107710203B (zh) | 分布式键/值存储库之上的事务数据库层 | |
| US11023457B1 (en) | Targeted sweep method for key-value data storage | |
| US11099960B2 (en) | Dynamically adjusting statistics collection time in a database management system | |
| JP6079876B2 (ja) | 分散処理システム | |
| US10127270B1 (en) | Transaction processing using a key-value store | |
| EP3377970B1 (en) | Multi-version removal manager | |
| JP6515753B2 (ja) | データベース制御プログラム、データベース制御方法及びデータベース制御装置 | |
| US9009718B2 (en) | Processing singleton task(s) across arbitrary autonomous server instances | |
| CN108475211B (zh) | 无状态系统和用于获得资源的系统 | |
| CN110377614B (zh) | 一种分布式环境下的订单处理锁系统 | |
| US20180150498A1 (en) | Database management device, information processing system, and database management method | |
| JP5967628B2 (ja) | クエリを処理する装置及び方法 | |
| JP6402537B2 (ja) | 更新処理プログラム、装置、及び方法 | |
| US10452424B2 (en) | Unique transaction identifier based transaction processing | |
| JP6398786B2 (ja) | データベースシステム、データベースサーバ、データベースサーバプログラム、データベースクライアント及びデータベースクライアントプログラム | |
| EP2875451A1 (en) | Method and system for replicating data in a cloud storage system | |
| US11157307B2 (en) | Count and transaction identifier based transaction processing | |
| CN114722125A (zh) | 数据库事务处理的方法、装置、设备和计算机可读介质 |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20180514 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20190116 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20190219 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20190313 |
|
| 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: 20190319 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20190401 |
|
| R150 | Certificate of patent or registration of utility model |
Ref document number: 6515753 Country of ref document: JP Free format text: JAPANESE INTERMEDIATE CODE: R150 |