JP2004341926A - Database management system, database management program - Google Patents

Abstract

Translated fromJapanese

【課題】索引アクセスにおいてトランザクションロックを用いることなくトランザクションの独立性を実現することにより、良好なシステムのスループットを実現する。
【解決手段】アプリケーション１２からのアクセス要求に応じて、更新された未確定の状態にあるデータをトランザクション毎に格納するためのトランザクションローカルログバッファ４０と、トランザクションローカルログバッファ４０に格納されたデータに対応する索引を格納するためのシステムグローバルログバッファ３８が設けられる。更新ログ生成部２８は、アプリケーション１２からのアクセス要求に応じた処理後の更新されたデータをトランザクションローカルログバッファ４０に格納し、このデータに対応する索引に対して未確定フラグを設定してシステムグローバルログバッファ３８に格納する。
【選択図】 図１An object of the present invention is to realize good system throughput by realizing transaction independence without using a transaction lock in index access.
A transaction local log buffer for storing updated data in an undetermined state for each transaction in response to an access request from an application, and a data stored in the transaction local log buffer. A system global log buffer 38 for storing a corresponding index is provided. The update log generation unit 28 stores the updated data after processing in response to the access request from the application 12 in the transaction local log buffer 40, sets an undetermined flag for the index corresponding to this data, and sets It is stored in the global log buffer 38.
[Selection diagram] Fig. 1

Description

Translated fromJapanese

【０００１】
【発明の属する技術分野】
本発明は、トランザクション管理を実行するデータベース管理システム、データベース管理プログラムに関する。
【０００２】
【従来の技術】
一般に、トランザクション管理を実行するデータベース管理システムでは、トランザクションの独立性を実現するために、トランザクションロックによりトランザクション間でデータを排他する方法が一般に用いられる。
【０００３】
トランザクションは、データ更新に先立って、更新対象のデータの更新ロックを獲得して、更新対象データを他のトランザクションからの更新または参照から保護する。この更新ロックは、トランザクションをコミットまたはロールバックして更新を確定または破棄するまで維持する。
【０００４】
一方、参照を行うトランザクションは、参照に先立って参照対象データに対して参照ロックを獲得して、参照対象データを他のトランザクションからの更新から保護する。
【０００５】
トランザクション管理システムは、トランザクションロックによって複数のトランザクションからのアクセス要求を必要に応じて逐次化して、トランザクションの独立性を実現する。
【０００６】
これはデータに付随する索引の更新に関しても同様の制御が必要であり、索引の中でトランザクションが更新する個所に更新に先立って更新ロックの確保を行うことで、トランザクションの独立性を実現する。
【０００７】
しかしながら、上記した従来技術においては、トランザクションの独立性維持の目的で索引に対してもアクセスに先立ってトランザクションロックを確保するため、競合やデッドロックが起き易くシステムのスループット劣化の大きな要因になっていた。
【０００８】
従来、例えば、マスタファイルアクセスのための更新処理と参照処理の競合待ち合わせを改善するために、マスタデータ索引領域を主記憶へ格納し、更新データは更新データキューに蓄積するようにし、業務の終了までは、マスタデータの更新処理は主記憶上のマスタデータ索引領域と更新データキューを更新し、マスタデータの参照処理はこのマスタデータ索引領域と更新データキューに基き読み出されたマスタデータを更新し参照するようにしたマスタデータ管理方式が考えられている（特許文献１）。
【０００９】
【特許文献１】
特開平８−１７９９７８号公報
【００１０】
【発明が解決しようとする課題】
従来のデータベース管理システムでは、索引対象となる全てのデータに対して、１つの索引を構成しているため、索引対象のデータの何れに対する参照または更新であっても、それに伴って索引に対するトランザクションロックが必要になる。
【００１１】
トランザクションロックで保護する保護範囲を大きくすると、索引のトランザクションロックがトランザクション間で競合しやすくなり、そのため索引の更新と更新、または更新と参照が逐次化され、結果的にデータへのアクセスがこのロックのために逐次化されて、システムのスループットを大きく劣化させる要因になる。
【００１２】
逆にトランザクションロックで保護する保護範囲を小さくすると、索引のトランザクションロックの確保順によりデッドロックが多発して、これもまたシステムのスループットを大きく劣化させる要因になる。
【００１３】
つまり、索引へのトランザクションロックはトランザクションの独立性維持のため必要ではあるが、競合やデッドロックが起き易いため、システムのスループット劣化の大きな要因になっていた。
【００１４】
本発明は前記のような事情を考慮してなされたもので、索引アクセスにおいてトランザクションロックを用いることなくトランザクションの独立性を実現することにより、良好なシステムのスループットを実現することが可能なデータベース管理システム、データベース管理プログラムを提供することを目的とする。
【００１５】
【課題を解決するための手段】
本発明は、アプリケーションからのアクセス要求に応じたトランザクションを管理するデータベース管理システムにおいて、アプリケーションが扱うデータを格納するデータ格納手段と、前記データ格納手段に格納されたデータに対応する索引を格納する索引格納手段と、アプリケーションからのアクセス要求に応じて、更新された未確定の状態にあるデータをトランザクション毎に格納するための第１の格納手段と、前記第１の格納手段に格納されたデータに対応する索引を格納するための第２の格納手段と、前記アプリケーションからの前記データ格納手段に格納されたデータに対するアクセス要求に応じた処理後の更新されたデータを前記第１の格納手段に格納する更新データ格納手段と、前記更新データ格納手段により前記第１の格納手段に格納されたデータに対応する前記索引格納手段に格納された索引に対して、未確定状態を示すフラグを付加して前記第２の格納手段に格納する更新索引格納手段とを具備したことを特徴とする。
【００１６】
【発明の実施の形態】
以下、図面を参照して本発明の実施の形態について説明する。
図１は本実施形態に係わるデータベース管理システムのシステム構成を示すブロック図である。本実施形態におけるデータベース管理システムは、例えば半導体メモリ、ＣＤ−ＲＯＭ、ＤＶＤ、磁気ディスク等の記録媒体に記録されたプログラムを読み込み、このプログラムによって動作が制御されるコンピュータによって実現される。
【００１７】
本実施形態のデータベース管理システムでは、データに付随する索引に対する更新に際してトランザクションロックを用いる代わりに、追加に関する索引更新については即時行い、削除に関する索引更新についてはトランザクション確定まで遅延し、問い合わせ処理において更新ログにより索引の有効無効の判定を行うことで、トランザクションの独立性を実現する。データベース管理システムが何らかの障害等でダウンした場合は、索引に未確定の余分な索引レコードが残るが、未確定索引レコードに削除予定や追加予定のフラグを設けて判別することにより、再起動後にそれらのフラグが設定された索引レコードを回収するように構成する。
【００１８】
図１に示すように、本実施形態におけるデータベース管理システムは、トランザクション管理システム１０、データファイル３４、索引ファイル３６、ログファイル４２を含んでいる。トランザクション管理システム１０は、アプリケーション１２からのトランザクションによる検索アクセス要求、追加アクセス要求、更新アクセス要求、削除アクセス要求、トランザクション確定要求などに対する処理を実行する。
【００１９】
データファイル３４は、データを格納するファイルであり、複数のレコードデータを含むデータページ単位でデータを格納する（詳細については後述する（図２））。索引ファイル３６は、データファイル３４に格納されたデータに対する索引を格納するファイルであり、複数の索引レコードを含む索引ページ単位で索引を格納する（詳細については後述する（図３））。
【００２０】
ログファイル４２は、トランザクション管理システム１０によるデータファイル３４及び索引ファイル３６に対する更新に伴うログを格納するファイルである。本実施形態では、後述するシステムグローバルログバッファ３８及びトランザクションローカルログバッファ４０に格納されたログをトランザクション確定処理によって格納する。
【００２１】
データベース管理システムを実現するコンピュータのメモリ上には、データファイル３４及び索引ファイル３６との間の入出力バッファであるバッファ３２と、索引ページの未確定の更新イメージを格納するシステムグローバルログバッファ３８（第２の格納手段）がそれぞれシステムに１つ設けられる。システムグローバルログバッファ３８は、各トランザクションの処理に参照される。さらにトランザクション毎にそれぞれ１つのトランザクションローカルログバッファ４０（第１の格納手段）が設けられ、データページの未確定の更新イメージ、すなわちアプリケーションからのアクセス要求に応じたトランザクション毎に未確定の状態にある更新されたデータが格納される。
【００２２】
トランザクション管理システム１０には、アクセス処理部２０、トランザクションロック管理部２２、データ更新部２４、索引更新部２６、更新ログ生成部２８、トランザクション確定部３０、バッファ３２、システムグローバルログバッファ３８、及びトランザクションローカルログバッファ４０が含まれる。
【００２３】
アクセス処理部２０は、アプリケーションからのアクセス要求を受け付け、トランザクションロック管理部２２、データ更新部２４、索引更新部２６、更新ログ生成部２８の各部を用いてアクセス処理を実行する。
【００２４】
トランザクションロック管理部２２は、アクセス処理部２０により受け付けられたアクセス要求に応じて、データファイル３４に格納されるデータに対してトランザクションロックを確保する。
【００２５】
データ更新部２４は、アクセス処理部２０により受け付けられたアクセス要求に応じて、データファイル３４に格納されたデータレコードを更新する。
【００２６】
索引更新部２６は、アクセス処理部２０により受け付けられたアクセス要求に応じて、索引ファイル３６からバッファ３２にロードされる索引レコードに対する更新を実行する。索引更新部２６は、アプリケーション１２からのデータレコード追加要求を受け付けた場合には索引へ対応する索引レコードを追加し、アプリケーション１２からデータレコードに対する削除アクセス要求あるいは更新アクセス要求を受け付けた場合、該当する索引から対応する索引レコードの削除を行わない。該当する索引の索引レコードを、トランザクションに対応するトランザクションローカルログバッファ４０にコピーし、トランザクションローカルログバッファ４０上で更新ログ生成部２８により削除させる。
【００２７】
更新ログ生成部２８は、システムグローバルログバッファ３８及びトランザクションローカルログバッファ４０上で、アプリケーション１２からのデータレコード追加要求を受け付けた場合には追加アクセスのログを生成し、アプリケーション１２からのデータレコード削除要求を受け付けた場合には削除アクセスのログを生成する。
【００２８】
トランザクション確定部３０は、例えばアプリケーション１２からのトランザクション確定処理（コミット処理）の要求などに応じたトランザクション確定時に、そのトランザクションに対応するシステムグローバルログバッファ３８に記録された削除ログを元に索引更新部２６に対して索引レコードの削除を要求すると共に、データ更新部２４へデータレコードの削除を要求し、また追加ログを元にデータ更新部２４へデータレコードの追加を要求する。
【００２９】
図２は、データファイル３４へのデータの格納形式の一例を示す図である。 データファイル３４にはデータが格納される。データファイル３４の先頭は、図２（ａ）に示すようにファイルヘッダであり、ファイルの単位の制御情報が格納され、その中にシステムコミット番号が記録される領域が存在する。
【００３０】
ファイル内は一定サイズのデータページに区切られていて、先頭から連番のページ番号（ページ番号（ＰＮＯ）（１，２，３，…，Ｎ））が付与されている。
【００３１】
各データページ内には、図２（ｂ）に示すように、アプリケーションの論理的なデータ処理単位であるレコードの実体データがレコードデータとして格納されている。
【００３２】
ページ末尾には、図２（ｅ）に示すように、ページ制御情報が格納されており、その前方に順にレコード制御情報が格納されている。ページ制御情報には、ページ番号（Ｎ）が格納されている。レコード制御情報は、ページ末尾の方向からの順序をレコード番号（ＲＮＯ（１，２，３，…））として識別される。レコード制御情報の領域には、図２（ｄ）に示すように、レコードデータのページ内開始オフセット（データ開始オフセット）とデータサイズが格納されていて、レコードデータを参照可能である。ページ番号（ＰＮＯ）とレコード番号（ＲＮＯ）でレコードデータを一意に識別することができる。
【００３３】
図３は、索引ファイル３６への索引の格納形式の一例を示す図である。
【００３４】
索引ファイル先頭は、ファイルヘッダであり、ファイルの単位の制御情報が格納されている。
【００３５】
索引ファイル内は、データファイル同様に一定サイズのページに区切られていて、先頭から連番の索引ページ番号（ＩＰＮＯ（１，２，３，…，Ｎ））が付与されている。索引ページ内には、図３（ａ）に示すように、索引の実体である索引レコードが格納されている。ページ末尾にはページ制御情報が格納されており、その中に、図３（ｇ）に示すように、ページ番号（Ｎ）と共に、このページ内の索引レコードの何れかを最後に確定したコミット処理を示すコミット番号（最終コミット番号）を格納する領域が存在する。また、ページ制御情報には、索引ページ中に存在する未確定索引レコード数が格納され、各アクセス処理に伴って更新されるものとする。
【００３６】
ページ制御情報の前方に順にレコード制御情報が格納されている。レコード制御情報は、ページ末尾の方向からの順序を索引レコード番号（ＩＲＮＯ（１，２，３，…））として識別される。レコード制御情報の領域には、図３（ｆ）に示すように、索引レコードのページ内開始オフセット（索引レコード開始オフセット）が格納されていて、索引レコードを参照可能である。索引ページ番号（ＩＰＮＯ）と索引レコード番号（ＩＲＮＯ）で索引レコードを一意に識別可能である。さらに、レコード制御情報の領域には、未確定（コミットされていない）索引レコードであることを識別する未確定フラグを格納するためのフラグ格納領域が存在する。本実施形態では、例えば「１」は追加アクセスの未確定、「２」は削除アクセスの未確定を表すものとする。なお、「０」は確定を表すものとする。
【００３７】
例えば、論理的に木構造を持つＢｔｒｅｅ索引を持つシステムでは、木構造の各ノードをページに対応させて索引ファイルへ格納する。図３（ｂ）には、論理的な索引構造の一例を示している。
【００３８】
木構造のリーフノードでは、索引レコードの内部に、図３（ｃ）に示すように、データレコードの一部が用いられたキー値と、そのキー値に対応するレコードデータへのポインタを格納する。レコードデータへのポインタは、図３（ｅ）に示すように、ページ番号（ＰＮＯ）とレコード番号（ＲＮＯ）との組で表される。
【００３９】
次に、本実施形態におけるデータベース管理システムの動作について説明する。
まず、追加アクセス処理について、図４に示すフローチャート、図５に示す追加アクセスの流れを示す図を参照しながら説明する。
【００４０】
アクセス処理部２０は、アプリケーション１２から追加アクセス要求があると、データ更新部２４により、データファイル３４内から追加レコードを格納可能なサイズの空き領域が存在するページを検索させ（ステップＡ１）、その該当ページに対してトランザクションロック管理部２２により、更新モードのトランザクションロックを確保する（ステップＡ２）（図５▲１▼）。
【００４１】
ここで、アクセス処理部２０は、データ更新部２４により、データファイル３４から検索された該当ページがバッファ３２に格納されているか検索し、バッファ３２に無ければデータファイル３４からロードする（ステップＡ４）。さらに、アクセス処理部２０は、データ更新部２４によりバッファ３２にロードされたページを、トランザクションローカルログバッファ４０へコピーする（ステップＡ５）（図５▲２▼）。
【００４２】
更新ログ生成部２８は、トランザクションローカルログバッファ４０上で、アプリケーション１２からの要求に応じた所望の追加レコードをページの空き領域へ追加すると共に、この追加レコードに対応するレコード制御情報（データサイズ、データ開始オフセット）を作成する。ここで、ページ番号（ＰＮＯ）、レコード番号（ＲＮＯ）が決定する（ステップＡ６）（図５▲３▼）。
【００４３】
次に、更新ログ生成部２８は、トランザクションローカルログバッファ４０上で作成された追加レコードに対応する索引レコードを格納すべき索引ページの索引ページ番号（ＩＰＮＯ）を計算して求め（ステップＡ７）、この索引ページ番号（ＩＰＮＯ）の索引ページをシステムグローバルログバッファ３８上で検索する（ステップＡ８）（図５▲４▼）。
【００４４】
ここで、システムグローバルログバッファ３８に該当索引ページが格納されていない場合（ステップＡ９、Ｎｏ）、アクセス処理部２０は、索引更新部２６により、該当索引ページを索引ファイル３６からバッファ３２にロードさせ、バッファ３２からシステムグローバルログバッファ３８へコピーする（ステップＡ１０）（図５▲５▼）。
【００４５】
更新ログ生成部２８は、システムグローバルログバッファ３８上で索引ページ番号（ＩＰＮＯ）の索引ページへ索引レコードを追加し、この索引レコードに対応するレコード制御情報を作成し（ステップＡ１１）、未確定フラグを「１」（追加未確定）に設定する（ステップＡ１２）（図５▲６▼）。また、更新ログ生成部２８は、索引ページのページ制御情報に未確定索引レコード数を更新して格納しておく。
【００４６】
例えば、追加レコードのデータ「ＡＢＣ」をトランザクションローカルログバッファ４０上で追加した場合、この追加したデータレコードに対応する索引レコードをシステムグローバルログバッファ３８上で追加する（例えば、索引レコード３）。ここで、索引レコード３のキー値は、例えば追加データレコードの先頭「Ａ」を用い（図３（ｄ））、レコードデータへのポインタは、ステップＡ６で決定されたページ番号（ＰＮＯ）、レコード番号（ＲＮＯ）を用いる（図３（ｅ））。また、この索引レコード３に対応するレコード３制御情報において、未確定フラグを「１」に設定して追加する（図３（ｆ））。
【００４７】
なお、トランザクション毎に、追加アクセス処理により更新した索引の「索引ページ番号（ＩＰＮＯ）、索引レコード番号（ＩＲＮＯ）」の組みを更新するたびにメモリ４４に記憶しておくものとする。この索引の「ＩＰＮＯ、ＩＲＮＯ」の組みのデータは、後述するトランザクション確定処理において、確定対象とする索引ページ（索引レコード）を判別する際に参照される。
【００４８】
こうして、トランザクションローカルログバッファ４０上で追加したレコードに対する索引レコードを、該当索引ページをロックをすることなくシステムグローバルログバッファ３８上で追加する。システムグローバルログバッファ３８では、レコード制御情報において、追加未確定を示す未確定フラグ「１」を設定しておくことで、後述するトランザクション確定処理によって確定させることができる。
【００４９】
次に、削除アクセス処理について、図６に示すフローチャート、図７に示す削除アクセスの流れを示す図を参照しながら説明する。
【００５０】
アクセス処理部２０は、アプリケーション１２から削除アクセス要求があると、データ更新部２４により、バッファ３２のみを使用して削除すべきレコード（削除レコード）を検索し（ステップＢ１）、該当するページ番号（ＰＮＯ）とレコード番号（ＲＮＯ）、及び索引ページ番号（ＩＰＮＯ）と索引レコード番号（ＩＲＮＯ）の対を決定する（ステップＢ２）。
【００５１】
なお、削除すべきレコードは、例えばユーザが別の処理によって検索しておき、その検索によって得られたレコードをアプリケーション１２を通じて指定されたり、ユーザによって明示的に指定された削除対象とするデータの索引（索引レコードに格納されるキー値）がアプリケーション１２を通じて指定されたりするなど何れの形態であっても良い。
【００５２】
トランザクションロック管理部２２は、データ更新部２４により決定されたページ番号（ＰＮＯ）に対して更新モードのトランザクションロックを確保する（ステップＢ３）（図７▲１▼）。
【００５３】
次に、アクセス処理部２０は、データ更新部２４により、ページ番号（ＰＮＯ）のデータページがバッファ３２に格納されているか検索し、バッファ３２に無ければデータファイル３４からロードして、バッファ３２からトランザクションローカルログバッファ４０へコピーする（ステップＢ４）（図７▲２▼）。
【００５４】
更新ログ生成部２８は、トランザクションローカルログバッファ４０上で、ページ番号（ＰＮＯ）のデータページからアプリケーション１２からの要求に応じた削除レコードを削除する（ステップＢ５）（図７▲３▼）。
【００５５】
次に、更新ログ生成部２８は、システムグローバルログバッファ３８上で索引ページ番号（ＩＰＮＯ）の索引ページを検索する（ステップＢ６）（図７▲４▼）。
【００５６】
ここで、システムグローバルログバッファ３８に該当索引ページが格納されていない場合（ステップＢ７、Ｎｏ）、アクセス処理部２０は、索引更新部２６により、該当索引ページを索引ファイル３６からバッファ３２にロードさせ、バッファ３２からシステムグローバルログバッファ３８へコピーする（ステップＢ８）（図７▲５▼）。
【００５７】
更新ログ生成部２８は、システムグローバルログバッファ３８上で索引ページ番号（ＩＰＮＯ）の索引ページのレコードについてレコード制御情報の未確定フラグを「２」（削除未確定）に設定する（ステップＢ９）（図７▲６▼）。また、更新ログ生成部２８は、索引ページのページ制御情報に未確定索引レコード数を更新して格納しておく。
【００５８】
なお、削除アクセス処理の場合についても、追加アクセス処理と同様に、トランザクション毎に、更新した索引の「索引ページ番号（ＩＰＮＯ）、索引レコード番号（ＩＲＮＯ）」の組みを更新するたびにメモリ４４に記憶しておくものとする。
【００５９】
こうして、トランザクションローカルログバッファ４０上でアプリケーション１２により指定されたレコードを削除し、この削除したレコードに対する索引レコードを該当索引ページをロックをすることなく、システムグローバルログバッファ３８上で削除未確定を示す未確定フラグ「２」を設定しておく。この時、バッファ３２上では削除レコードは削除されていない。これにより、後述するトランザクション確定処理によって、レコードの削除を索引レコードを索引ファイル３６中の索引ページに反映させることができる。
【００６０】
次に、更新アクセス処理について、図８に示すフローチャート、図９に示す更新アクセスの流れを示す図を参照しながら説明する。更新アクセスは、前述した追加アクセスと削除アクセスとを組み合わせた処理となる。
【００６１】
アクセス処理部２０は、アプリケーション１２から更新アクセス要求があると、データ更新部２４により、バッファ３２のみを使用して更新すべきレコード（更新レコード）を検索し（ステップＣ１）、該当するページ番号（ＰＮＯ）とレコード番号（ＲＮＯ）、及び索引ページ番号（ＩＰＮＯ）と索引レコード番号（ＩＲＮＯ）の対を決定する（ステップＣ２）。
【００６２】
なお、更新すべきレコードは、例えばユーザが別の処理によって検索しておき、その検索によって得られたレコードをアプリケーション１２を通じて指定されたり、ユーザによって明示的に指定された更新対象とするデータの索引（索引レコードに格納されるキー値）がアプリケーション１２を通じて指定されたりするなど何れの形態であっても良い。
【００６３】
トランザクションロック管理部２２は、データ更新部２４により決定されたページ番号（ＰＮＯ）に対して更新モードのトランザクションロックを確保する（ステップＣ３）（図９▲１▼）。
【００６４】
次に、アクセス処理部２０は、データ更新部２４により、ページ番号（ＰＮＯ）のデータページがバッファ３２に格納されているか検索し、バッファ３２に無ければデータファイル３４からロードして、バッファ３２からトランザクションローカルログバッファ４０へコピーする（ステップＣ４）（図９▲２▼）。
【００６５】
データ更新部２４は、トランザクションローカルログバッファ４０上で、ページ番号（ＰＮＯ）のデータページの更新前レコードデータを更新後レコードデータに更新する（ステップＣ５）。同時に更新前のレコード番号（ＲＮＯ）のレコードデータを無効化し、レコード番号（ＲＮＯ）とは別のレコード番号（ＲＮＯ＿Ｐ）を更新後のレコードデータのために確保して（ステップＣ６）、レコード番号（ＲＮＯ＿Ｐ）へ更新後レコードデータのレコード制御情報を作成する（ステップＣ７）（図９▲３▼）。例えば、図９では、更新前のレコードデータ「ＡＢＣ」を無効化して、レコードデータ「ＡＢＣ」とは別の場所に更新後のレコードデータ「ＤＥＦ」を追加する。
【００６６】
次に、更新ログ生成部２８は、更新前のレコードデータに対応する索引ページ番号（ＩＰＮＯ）の索引ページ、及び更新後レコードデータに対応したキーを格納すべき索引ページ（ＩＰＮＯ＿Ｐ）をシステムグローバルログバッファ３８上で検索する（ステップＣ８）（図９▲４▼）。
【００６７】
ここで、システムグローバルログバッファ３８に該当索引ページが格納されていない場合（ステップＣ９、Ｎｏ）、アクセス処理部２０は、索引更新部２６により、該当索引ページを索引ファイル３６からバッファ３２にロードさせ、バッファ３２からシステムグローバルログバッファ３８へコピーする（ステップＣ１０）（図９▲５▼）。
【００６８】
更新ログ生成部２８は、システムグローバルログバッファ３８上で、索引ページ番号（ＩＰＮＯ）の索引ページにおける、更新前のレコードデータに対応する索引レコード番号（ＩＲＮＯ）の索引レコードに対応するレコード制御情報に対して未確定フラグを「２」（削除未確定）に設定する（ステップＣ１１）。例えば、図９において、トランザクションローカルログバッファ４０上で削除されたデータレコード「ＡＢＣ」に対して、索引レコード（キー値「Ａ」）に対応するレコード制御情報に対して削除未確定を示す「２」に設定する。さらに、更新ログ生成部２８は、システムグローバルログバッファ３８上で、索引ページ番号（ＩＰＮＯ＿Ｐ）の索引ページにおける、更新後のレコードデータに対応する索引レコードを追加し、この索引レコードに対応するレコード制御情報を作成する（ステップＣ１２）。この時、レコード制御情報に対して、未確定フラグを「１」（追加未確定）に設定する（ステップＣ１３）。例えば、図９において、トランザクションローカルログバッファ４０上で追加されたデータレコード「ＤＥＦ」に対して、索引レコード（キー値「Ｄ」）に対応するレコード制御情報に対して追加未確定を示す「１」に設定する（図９▲６▼）。また、更新ログ生成部２８は、索引ページのページ制御情報に未確定索引レコード数を更新して格納しておく。
【００６９】
なお、更新アクセス処理の場合についても、追加アクセス処理と同様に、トランザクション毎に、更新した索引の「索引ページ番号（ＩＰＮＯ）、索引レコード番号（ＩＲＮＯ）」の組みを更新するたびにメモリ４４に記憶しておくものとする。
【００７０】
こうして、更新アクセス処理において、トランザクションローカルログバッファ４０上で追加、削除したレコードに対する索引レコードを、該当索引ページをロックをすることなくシステムグローバルログバッファ３８上で追加、削除する。システムグローバルログバッファ３８では、追加したレコードデータに対応するレコード制御情報において追加未確定を示す未確定フラグ「１」を設定し、削除したレコードデータに対応するレコード制御情報において削除未確定を示す未確定フラグ「２」を設定しておくことで、後述するトランザクション確定処理によって確定させることができる。
【００７１】
次に、トランザクション確定処理について、図１０に示すフローチャート、図１１に示すトランザクション確定処理の流れを示す図を参照しながら説明する。
【００７２】
まず、アクセス処理部２０は、アプリケーション１２からトランザクション確定処理（コミット処理）の実行要求があると、更新ログ生成部２８により、システムグローバルログバッファ３８上に存在する今回確定する索引ページのページ制御情報の最終コミット番号に現在のシステムコミット番号を記録する（ステップＤ１）。
【００７３】
なお、図示していないが、データベース管理システムが起動される場合に、システム動作を制御するための各種制御情報がデータファイル３４などから読み出されてメモリ４４に格納される。この時に格納される制御情報には、データファイル３４のファイルヘッダに含まれるシステムコミット番号（図２（ａ））が含まれている。トランザクション管理システム１０は、システム起動時に、システム内に１つ存在するコミットカウンタに、データファイル３４から読み出したシステムコミット番号を初期値としてセットし、トランザクション確定処理を実行するたびにカウンタ更新を実行する。
【００７４】
トランザクション確定処理では、コミットカウンタによりカウントされたシステムコミット番号を、システムグローバルログバッファ３８上の索引ページに最終コミット番号として格納する。
【００７５】
さらに更新ログ生成部２８は、今回確定する索引レコードのレコード制御情報の未確定フラグを「０」（確定）へ更新する（ステップＤ２）（図１１▲１▼）。
【００７６】
なお、何れの索引ページ及び索引レコードを確定させるかは、各アクセス処理（追加、削除、更新）の際に、トランザクション毎に格納された、更新された索引の「索引ページ番号（ＩＰＮＯ）、索引レコード番号（ＩＲＮＯ）」の組みを参照することで判別するものとする。
【００７７】
更新ログ生成部２８は、確定するトランザクションに対応したトランザクションローカルログバッファ４０上のデータページを全てログファイル４２へ記録する（ステップＤ３）（図１１▲２▼）。また、更新ログ生成部２８は、システムグローバルログバッファ３８上の索引ページのうち、今回確定する索引ページをログファイル４２に記録する（ステップＤ４）（図１１▲３▼）。
【００７８】
また、更新ログ生成部２８は、ログファイル４２へコミット番号を記録する（ステップＤ５）（図１１▲４▼）。
【００７９】
アクセス処理部２０は、更新ログ生成部２８により、トランザクションローカルログバッファ４０上のデータページを読み出して、データ更新部２４を通じて全てバッファ３２へ転送する。既に同じページ番号（ＰＮＯ）のページが存在する場合は上書きする（ステップＤ６）（図１１▲５▼）。同時に更新ログ生成部２８は、トランザクションローカルログバッファ４０上のデータページを全て無効化する（ステップＤ７）。
【００８０】
また、アクセス処理部２０は、更新ログ生成部２８により、システムグローバルログバッファ３８から今回確定した索引ページを読み出して、索引更新部２６を通じてバッファ３２へ転送する。既に同じ索引ページ番号（ＩＰＮＯ）のページが存在する場合は上書きする（ステップＤ８）（図１１▲６▼）。同時に更新ログ生成部２８は、今回確定したシステムグローバルログバッファ３８上の索引ページを無効化する（ステップＤ９）。
【００８１】
ここで、トランザクションロック管理部２２は、今回確定したトランザクションに属するトランザクションロックを全て開放する（ステップＤ１０）（図１１▲７▼）。
【００８２】
トランザクション管理システム１０は、ステップＤ６においてシステムグローバルログバッファ３８からバッファ３２に転送されたデータページ、及びステップＤ８においてトランザクションローカルログバッファ４０からバッファ３２に転送された索引ページを、それぞれデータファイル３４も索引ファイル３６へ書き込むように、データ書き込みタスクへ登録する（ステップＤ１１）（図１１▲８▼）。
【００８３】
また、トランザクション管理システム１０は、トランザクション確定処理実行時のコミットカウンタの値（システムコミット番号）を、データファイル３４のファイルヘッダに保存しておく。システムコミット番号は、前述したようにシステム起動時に読み出され、それ以降、トランザクション確定処理が実行されるたびに更新されると共に、システムグローバルログバッファ３８上で確定対象とする索引ページに書き込まれる。索引ページに保存されたシステムコミット番号（最終コミット番号）は、後述するシステムダウン後のリカバリ処理の際に参照される。
【００８４】
こうして、トランザクション確定処理では、アプリケーション１２から要求されたアクセス処理（追加、削除、更新）によってシステムグローバルログバッファ３８に格納された未確定状態にある索引レコードを、索引ファイル３６に対して反映させることができる。
【００８５】
次に、前述した各アクセス処理（追加、削除、更新）の対象となったデータレコードに対する、自トランザクションと他トランザクションのそれぞれによるアクセス処理に伴う更新の参照について説明する。
【００８６】
自トランザクションによるアクセス処理では、自トランザクションにより更新されたレコードが参照され、他トランザクションにより更新されたレコードが参照さない（処理前のレコードが参照される）ようにすることで、トランザクションの独立性が実現される。
【００８７】
図１２は、自トランザクションの更新の参照の流れを示している。
図１２（ａ）は、自トランザクションの追加レコードの参照を説明する図である。
トランザクション管理システム１０は、システムグローバルログバッファ３８を検索して、参照対象とするデータレコードに対応する索引ページ中の索引レコードを参照し、ページ番号（ＰＮＯ）とレコード番号（ＲＮＯ）を得る（図１２（ａ）▲１▼）。図１２（ａ）では、キー値「Ａ」の索引レコードが参照されている。このとき未確定フラグは意識しない（追加未確定「１」となっている）。
【００８８】
トランザクション管理システム１０は、ページ番号（ＰＮＯ）、レコード番号（ＲＮＯ）をもとに、自トランザクションに対応するトランザクションローカルログバッファ４０を検索して、自トランザクションが追加したレコード（追加レコードのデータ「ＡＢＣ」）を得る（図１２（ａ）▲２▼）。
【００８９】
図１２（ｂ）は、自トランザクションの削除レコードの参照を説明する図である。
トランザクション管理システム１０は、システムグローバルログバッファ３８を検索して、参照対象とするデータレコードに対応する索引ページ中の索引レコードを参照し、ページ番号（ＰＮＯ）とレコード番号（ＲＮＯ）を得る（図１２（ｂ）▲１▼）。図１２（ｂ）では、キー値「Ａ」の索引レコードが参照されている。このとき未確定フラグは意識しない（削除未確定「２」となっている）。
【００９０】
トランザクション管理システム１０は、ページ番号（ＰＮＯ）、レコード番号（ＲＮＯ）をもとに、自トランザクションに対応するトランザクションローカルログバッファ４０を検索する。すると、無効化されたレコード制御情報を参照することになり、無効化されたデータレコードであることを検出することができる（図１２（ｂ）▲２▼）。
【００９１】
図１２（ｃ）は、自トランザクションの更新レコードの参照を説明する図である。
トランザクション管理システム１０は、更新前キー（キー値「Ａ」）でシステムグローバルログバッファ３８を検索した場合は、前述した自トランザクションの削除レコードの参照（図１２（ｂ））と同様の手順で無効化されたレコードであることを検出する（図１２（ｃ）▲１▼▲２▼）。
【００９２】
また、更新後キー（キー値「Ｄ」）でシステムグローバルログバッファ３８を検索した場合は、前述した自トランザクションの追加レコードの参照（図１２（ａ）と同様の手順で更新後レコード（追加レコードのデータ「ＤＥＦ」）を検出する（図１２（ｃ）▲１▼▲２▼）。
【００９３】
図１３は、他トランザクションの更新の参照の流れを示している。
図１３（ａ）は、他トランザクションの追加レコードの参照を説明する図である。
トランザクション管理システム１０は、システムグローバルログバッファ３８を検索して、参照対象とするデータレコードに対応する索引ページ中の索引レコードを参照し、ページ番号（ＰＮＯ）とレコード番号（ＲＮＯ）を得る（図１３（ａ）▲１▼）。図１３（ａ）では、キー値「Ａ」の索引レコードが参照されている。このとき未確定フラグは意識しない（追加未確定「１」となっている）。
【００９４】
ここで、ページ番号（ＰＮＯ）をもとに自トランザクションに対応するトランザクションローカルログバッファ４０上で追加レコードを検索するが、これはヒットしない（図１３（ａ）▲２▼）。つまり、データページへのトランザクションロックによって排他されているため、他トランザクションの更新中のページが自トランザクションのトランザクションローカルログバッファ４０に存在することは無い。
【００９５】
トランザクション管理システム１０は、参照対象とするデータレコードがトランザクションローカルログバッファ４０に存在しないので、バッファ３２を検索してページ番号（ＰＮＯ）に対応するデータページを得る（図１３（ａ）▲３▼）。ページ番号（ＰＮＯ）のページの中のレコード番号（ＲＮＯ）が示すデータレコードは空き領域として管理されている状態（だから他トランザクションが追加可能だった）なので、無効レコードであることを検出することができる（他トランザクションによる追加前の状態）。
【００９６】
図１３（ｂ）は、他トランザクションの削除レコードの参照を説明する図である。
トランザクション管理システム１０は、システムグローバルログバッファ３８を検索して、参照対象とするデータレコードに対応する索引ページ中の索引レコードを参照し、ページ番号（ＰＮＯ）とレコード番号（ＲＮＯ）を得る。（図１３（ｂ）▲１▼）。図１３（ｂ）では、キー値「Ａ」の索引レコードが参照されている。このとき未確定フラグは意識しない（削除未確定「２」となっている）。
【００９７】
ここで、ページ番号（ＰＮＯ）をもとに°トランザクションに対応するトランザクションローカルログバッファ４０上でデータレコードを検索するが、前述と同じ理由でこれはヒットしない（図１３（ｂ）▲２▼）。
【００９８】
トランザクション管理システム１０は、参照対象とするデータレコードがトランザクションローカルログバッファ４０に存在しないので、バッファ３２を検索してページ番号（ＰＮＯ）に対応するデータページを得る（図１３（ｂ）▲３▼）。ページ番号（ＰＮＯ）のページの中のレコード番号（ＲＮＯ）が示すデータレコードは、削除前の状態なので、削除前レコードを有効レコードとして得ることができる。すなわち他のトランザクションによるアクセス処理によって削除未確定となっているデータレコードを参照することができる。
【００９９】
図１３（ｃ）は、他トランザクションの更新レコードの参照を説明する図である。
トランザクション管理システム１０は、更新前キー（キー値「Ａ」）でシステムグローバルログバッファ３８を検索した場合は（図１３（ｃ）▲１▼）、前述した他トランザクションの削除レコードの参照（図１３（ｂ））と同様の手順で更新前レコード（「ＡＢＣ」）を得る（図１３（ｃ）▲２▼▲３▼）。
【０１００】
また、更新後キー（キー値「Ｄ」）でシステムグローバルログバッファ３８を検索した場合は（図１３（ｃ）▲１▼）、前述した他トランザクションの追加レコードの参照（図１３（ａ））と同様の手順で無効レコードであることを検出する（図１３（ｃ）▲２▼▲３▼）。
【０１０１】
こうして、自トランザクションの更新したデータについては更新後のデータを参照でき、他トランザクションが更新したデータについては、トランザクション確定処理が実行されていなければ、更新前のデータを参照することができる。これにより、一貫性をもったデータの参照が実現され、トランザクションの独立性を実現することができる。
【０１０２】
次に、システムダウン後のリカバリ処理について、図１４に示すフローチャート、及び図１５に示すリカバリ処理の流れを示す図を参照しながら説明する。
【０１０３】
システムが何らかの障害等によりダウンした後、システム起動されると、トランザクション管理システム１０は、ログファイル４２に格納されたログをデータファイル３４及び索引ファイルに適用する（図１５▲１▼）。この状態ではシステムダウン時に処理中であったトランザクションによる未確定状態の索引レコードが索引ページ中に混在している場合がある。未確定状態の索引レコードは、実際には確定されていないので削除する必要がある。
【０１０４】
また、トランザクション管理システム１０は、システム起動時にはログからシステム停止時のコミット番号を得る（ステップＥ１）。
【０１０５】
アプリケーション１２が起動され、任意のアクセスを処理中に索引ページのバッファ３２へのミスヒットが発生した場合（ステップＥ２）、索引ファイル３６から索引ページをバッファ３２へロードする過程で、索引ページ内のページ制御情報の最終コミット番号を起動時にメモリに保存したシステム起動時のコミット番号と比較する（ステップＥ３，Ｅ４）（図１５▲２▼）。
【０１０６】
ここで、システム起動時のコミット番号の方が新しい場合（ステップＥ５、Ｙｅｓ）、トランザクション管理システム１０は、索引ページのページ制御情報に記録された未確定索引レコード数を確認し（ステップＥ６）、未確定索引レコードが存在するようであれば（ステップＥ７、Ｙｅｓ）、索引ページ内の全てのレコード制御情報を参照して、未確定フラグが「０」（確定）でないレコード制御情報と対応する索引レコードを無効化する（ステップＥ８）（図１５▲３▼）。
【０１０７】
これらの処理を行った上でバッファ３２上の索引ページを有効とする（ステップＥ９）。
【０１０８】
このようにして、システムダウン後のリカバリ処理では、索引ページ参照において索引レコード参照に先立ってシステム内のコミットカウンタとページ内のコミットカウンタ（最終コミット番号）を比較して、ページ内のコミットカウンタの方が小さいことにより、この索引ページへのシステム起動後最初のアクセスであることを識別し、その索引ページ内の未確定索引を全て削除することで索引のダウンリカバリをするので、トランザクションの永続性を実現することができる。
【０１０９】
なお、前述したリカバリ処理では、索引ファイル３６からバッファ３２に索引ページをロードする際に、この索引ページについてシステム起動後最初のアクセスと判断された場合に、この索引ページに対して未確定索引レコードの無効化をしているが、システム起動時に、ログファイル４２のログを索引ファイル３６に適用する際に全ての索引ページについて一括して未確定索引レコードの無効化を実行しても良い。この場合、システム起動時に多くの処理負担がかかるが、各索引ページのシステム起動後最初のアクセスの際の処理負担を軽減することができる。
【０１１０】
このようにして、本実施形態におけるデータベース管理システムでは、索引ファイル３６に対してトランザクションロックを取得することなく、索引のレコードの有効性をアクセスのたびにログ（システムグローバルログバッファ３８、トランザクションローカルログバッファ４０）上で判断することによって、図１２及び図１３を用いて説明したトランザクションの独立性、及び図１５に示すようなトランザクションの永続性を実現することができる。索引ファイル３６に対してトランザクションロックをしないことで、索引ページに対する競合やデッドロックを排除することができるので、システムのスループット劣化を回避する事ができる。
【０１１１】
なお、本実施形態では、トランザクションの永続性を実現するリカバリ方法として、ロギング方式などの他、何れの方式を問わずに適用することが可能である。
【０１１２】
また、本実施形態では、索引ファイル３６の索引ページが図３（ｂ）に示す論理的な索引構造を持つとして説明しているが、索引種別について、ツリー形式、ビットマップ形式などの他、何れの索引種別を問わずに適用することが可能である。
【０１１３】
また、上述した実施形態において記載した手法は、コンピュータに実行させることのできるプログラムとして、例えば磁気ディスク（フレキシブルディスク、ハードディスク等）、光ディスク（ＣＤ−ＲＯＭ、ＤＶＤ等）、半導体メモリなどの記録媒体に書き込んで各種装置に提供することができる。また、通信媒体により伝送して各種装置に提供することも可能である。本装置を実現するコンピュータは、記録媒体に記録されたプログラムを読み込み、または通信媒体を介してプログラムを受信し、このプログラムによって動作が制御されることにより、上述した処理を実行する。
【０１１４】
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合わせにより、種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。さらに、異なる実施形態にわたる構成要素を適宜組み合わせてもよい。
【０１１５】
【発明の効果】
以上詳述したように本発明によれば、索引アクセスにおいてはトランザクションロックを用いることなくトランザクションの独立性を実現することにより、競合やデッドロックを排除し、良好なシステムのスループットを実現することが可能となるものである。
【図面の簡単な説明】
【図１】本実施形態に係わるデータベース管理システムのシステム構成を示すブロック図。
【図２】データファイル３４へのデータの格納形式の一例を示す図。
【図３】索引ファイル３６への索引の格納形式の一例を示す図。
【図４】本実施形態における追加アクセス処理について説明するためのフローチャート。
【図５】本実施形態における追加アクセス処理の流れを示す図。
【図６】本実施形態における削除アクセス処理について説明するためのフローチャート。
【図７】本実施形態における削除アクセス処理の流れを示す図。
【図８】本実施形態における更新アクセス処理について説明するためのフローチャート。
【図９】本実施形態における更新アクセス処理の流れを示す図。
【図１０】本実施形態におけるトランザクション確定処理について説明するためのフローチャート。
【図１１】本実施形態におけるトランザクション確定処理の流れを示す図。
【図１２】自トランザクションの更新の参照の流れを示す図。
【図１３】他トランザクションの更新の参照の流れを示す図。
【図１４】本実施形態におけるシステムダウン後のリカバリ処理について説明するためのフローチャート。
【図１５】本実施形態におけるリカバリ処理の流れを示す図。
【符号の説明】
１０…トランザクション管理システム、１２…アプリケーション、２０…アクセス処理部、２２…トランザクションロック管理部、２４…データ更新部、２６…索引更新部、２８…更新ログ生成部、３０…トランザクション確定部、３２…バッファ、３４…データファイル、３６…索引ファイル、３８…システムグローバルログバッファ、４０…トランザクションローカルログバッファ、４２…ログファイル。[0001]
TECHNICAL FIELD OF THE INVENTION
The present invention relates to a database management system that executes transaction management, and a database management program.
[0002]
[Prior art]
Generally, in a database management system that performs transaction management, a method of excluding data between transactions by using a transaction lock is generally used in order to realize transaction independence.
[0003]
Prior to updating data, the transaction acquires an update lock on the data to be updated and protects the data to be updated from being updated or referenced by another transaction. This update lock is held until the transaction is committed or rolled back to commit or discard the update.
[0004]
On the other hand, the transaction performing the reference acquires a reference lock on the reference target data prior to the reference, and protects the reference target data from being updated by another transaction.
[0005]
The transaction management system realizes transaction independence by serializing access requests from a plurality of transactions as necessary by using a transaction lock.
[0006]
This requires the same control as for the update of the index attached to the data, and the independence of the transaction is realized by securing the update lock at the place where the transaction is updated in the index prior to the update.
[0007]
However, in the above-described conventional technology, a transaction lock is secured prior to access to an index for the purpose of maintaining transaction independence, so that contention and deadlock are likely to occur, which is a major factor in deterioration of system throughput. Was.
[0008]
Conventionally, for example, in order to improve contention queuing between update processing and reference processing for master file access, a master data index area is stored in a main memory, update data is stored in an update data queue, and the end of a job. Up to now, the master data update process updates the master data index area and update data queue in the main memory, and the master data reference process updates the master data read based on this master data index area and update data queue. There has been proposed a master data management method for making reference to the data (Japanese Patent Application Laid-Open No. H10-163,837).
[0009]
[Patent Document 1]
JP-A-8-179978
[0010]
[Problems to be solved by the invention]
In the conventional database management system, one index is configured for all data to be indexed. Therefore, even if reference or update is performed to any of the data to be indexed, a transaction lock on the index is accompanied. Is required.
[0011]
Increasing the scope of protection protected by transaction locks makes it more likely that transaction locks on the index will conflict between transactions, thus serializing index updates and updates, or updates and references, and consequently access to data. , And becomes a factor that greatly degrades the throughput of the system.
[0012]
Conversely, if the protection range protected by the transaction lock is reduced, deadlocks frequently occur depending on the order of securing the transaction locks of the index, which also causes a large decrease in the throughput of the system.
[0013]
That is, the transaction lock on the index is necessary to maintain the independence of the transaction, but it is likely to cause contention and deadlock, which has been a major factor in deterioration of the system throughput.
[0014]
SUMMARY OF THE INVENTION The present invention has been made in view of the above circumstances, and realizes a database management that can realize a good system throughput by realizing transaction independence without using a transaction lock in index access. It aims to provide a system and a database management program.
[0015]
[Means for Solving the Problems]
The present invention relates to a database management system for managing a transaction in response to an access request from an application, a data storage unit for storing data handled by the application, and an index for storing an index corresponding to the data stored in the data storage unit. Storage means, first storage means for storing updated data in an undetermined state in response to an access request from an application for each transaction, and data stored in the first storage means. Second storage means for storing a corresponding index, and updated data after processing in response to an access request from the application to the data stored in the data storage means, stored in the first storage means Update data storage means, and the first case is stored by the update data storage means. Update index storage means for adding a flag indicating an undetermined state to the index stored in the index storage means corresponding to the data stored in the means and storing the index in the second storage means. It is characterized by.
[0016]
BEST MODE FOR CARRYING OUT THE INVENTION
Hereinafter, embodiments of the present invention will be described with reference to the drawings.
FIG. 1 is a block diagram showing a system configuration of the database management system according to the present embodiment. The database management system according to the present embodiment is implemented by a computer that reads a program recorded on a recording medium such as a semiconductor memory, a CD-ROM, a DVD, and a magnetic disk, and whose operation is controlled by the program.
[0017]
In the database management system of this embodiment, instead of using a transaction lock when updating an index attached to data, an index update related to addition is immediately performed, and an index update related to deletion is delayed until the transaction is determined. By determining whether the index is valid or invalid, the independence of the transaction is realized. If the database management system goes down due to some kind of failure, undetermined extra index records will remain in the index. It is configured to collect index records for which the flag is set.
[0018]
As shown in FIG. 1, the database management system according to the present embodiment includes atransaction management system 10, adata file 34, anindex file 36, and alog file 42. Thetransaction management system 10 executes processing for a search access request, an additional access request, an update access request, a delete access request, a transaction confirmation request, and the like from a transaction from theapplication 12.
[0019]
Thedata file 34 is a file for storing data, and stores data in data page units including a plurality of record data (details will be described later (FIG. 2)). Theindex file 36 is a file for storing an index for data stored in thedata file 34, and stores the index in units of index pages including a plurality of index records (details will be described later (FIG. 3)).
[0020]
Thelog file 42 is a file that stores a log accompanying the update of the data file 34 and theindex file 36 by thetransaction management system 10. In the present embodiment, logs stored in a systemglobal log buffer 38 and a transactionlocal log buffer 40, which will be described later, are stored by a transaction determination process.
[0021]
On a memory of a computer for realizing the database management system, abuffer 32 which is an input / output buffer between the data file 34 and theindex file 36, and a system global log buffer 38 (which stores an indeterminate update image of an index page) One second storage means) is provided in each system. The systemglobal log buffer 38 is referred to for processing of each transaction. Further, one transaction local log buffer 40 (first storage means) is provided for each transaction, and the update image of the data page is undetermined, that is, in an undetermined state for each transaction in response to an access request from an application. The updated data is stored.
[0022]
Thetransaction management system 10 includes anaccess processing unit 20, a transactionlock management unit 22, adata update unit 24, anindex update unit 26, an updatelog generation unit 28, atransaction determination unit 30, abuffer 32, a systemglobal log buffer 38, and a transaction. Alocal log buffer 40 is included.
[0023]
Theaccess processing unit 20 receives an access request from an application, and performs an access process using the transactionlock management unit 22, thedata update unit 24, theindex update unit 26, and the updatelog generation unit 28.
[0024]
The transactionlock management unit 22 secures a transaction lock on the data stored in the data file 34 in response to the access request received by theaccess processing unit 20.
[0025]
Thedata updating unit 24 updates a data record stored in the data file 34 in response to the access request received by theaccess processing unit 20.
[0026]
Theindex updating unit 26 updates the index records loaded from theindex file 36 into thebuffer 32 in response to the access request received by theaccess processing unit 20. Theindex updating unit 26 adds a corresponding index record to the index when receiving a data record addition request from theapplication 12, and when receiving a delete access request or an update access request for a data record from theapplication 12, the corresponding index record is applicable. Do not delete the corresponding index record from the index. The index record of the corresponding index is copied to the transactionlocal log buffer 40 corresponding to the transaction, and is deleted by the updatelog generation unit 28 on the transactionlocal log buffer 40.
[0027]
The updatelog generation unit 28 generates a log of additional access on the systemglobal log buffer 38 and the transactionlocal log buffer 40 when receiving a data record addition request from theapplication 12, and deletes the data record from theapplication 12. When the request is accepted, a log of the deletion access is generated.
[0028]
When a transaction is determined in response to, for example, a request for transaction determination processing (commit processing) from theapplication 12, thetransaction determination unit 30 updates the index update unit based on the deletion log recorded in the systemglobal log buffer 38 corresponding to the transaction. 26, requesting thedata update unit 24 to delete the data record, and requesting thedata update unit 24 to add the data record based on the additional log.
[0029]
FIG. 2 is a diagram illustrating an example of a storage format of data in the data file 34. Data is stored in the data file 34. The head of the data file 34 is a file header as shown in FIG. 2A, in which control information in units of files is stored, and an area in which a system commit number is recorded exists.
[0030]
The file is divided into data pages of a fixed size, and serial page numbers (page numbers (PNO) (1, 2, 3,..., N)) are given from the top.
[0031]
In each data page, as shown in FIG. 2B, actual data of a record, which is a logical data processing unit of the application, is stored as record data.
[0032]
As shown in FIG. 2E, page control information is stored at the end of the page, and record control information is stored in front of the page control information. The page number (N) is stored in the page control information. The record control information identifies the order from the end of the page as a record number (RNO (1, 2, 3,...)). In the area of the record control information, as shown in FIG. 2D, the start offset within the page (data start offset) and the data size of the record data are stored, and the record data can be referred to. Record data can be uniquely identified by a page number (PNO) and a record number (RNO).
[0033]
FIG. 3 is a diagram illustrating an example of a storage format of the index in theindex file 36.
[0034]
The head of the index file is a file header, which stores control information for each file.
[0035]
Like the data file, the index file is divided into pages of a fixed size, and index page numbers (IPNO (1, 2, 3,..., N)) are assigned sequentially from the top. As shown in FIG. 3A, an index record, which is the substance of the index, is stored in the index page. At the end of the page, page control information is stored. In the page control information, as shown in FIG. 3 (g), together with the page number (N), any one of the index records in this page is finally committed. There is an area for storing a commit number (final commit number) indicating the number. The page control information stores the number of undetermined index records existing in the index page and is updated with each access process.
[0036]
Record control information is stored in front of the page control information. The record control information identifies the order from the end of the page as an index record number (IRNO (1, 2, 3,...)). In the area of the record control information, as shown in FIG. 3F, the start offset within the page of the index record (index record start offset) is stored, and the index record can be referred to. An index record can be uniquely identified by an index page number (IPNO) and an index record number (IRNO). Further, in the area of the record control information, there is a flag storage area for storing an undetermined flag for identifying an undetermined (uncommitted) index record. In the present embodiment, for example, “1” indicates that the additional access has not been determined, and “2” indicates that the delete access has not been determined. Note that “0” indicates determination.
[0037]
For example, in a system having a Btree index having a logical tree structure, each node of the tree structure is stored in an index file in association with a page. FIG. 3B shows an example of a logical index structure.
[0038]
In the tree structure leaf node, as shown in FIG. 3C, a key value using a part of a data record and a pointer to record data corresponding to the key value are stored in the index record. . The pointer to the record data is represented by a set of a page number (PNO) and a record number (RNO), as shown in FIG.
[0039]
Next, the operation of the database management system according to the present embodiment will be described.
First, the additional access process will be described with reference to the flowchart shown in FIG. 4 and the diagram showing the flow of the additional access shown in FIG.
[0040]
Upon receiving an additional access request from theapplication 12, theaccess processing unit 20 causes thedata updating unit 24 to search the data file 34 for a page having a free area large enough to store an additional record (step A1). The transactionlock management unit 22 secures a transaction lock in the update mode for the corresponding page (step A2) ((1) in FIG. 5).
[0041]
Here, theaccess processing unit 20 uses thedata updating unit 24 to search whether the relevant page searched from the data file 34 is stored in thebuffer 32, and loads the page from the data file 34 if not found in the buffer 32 (step A4). . Further, theaccess processing unit 20 copies the page loaded into thebuffer 32 by thedata updating unit 24 to the transaction local log buffer 40 (Step A5) (FIG. 5 (2)).
[0042]
The updatelog generation unit 28 adds a desired additional record in response to a request from theapplication 12 to the free area of the page on the transactionlocal log buffer 40, and records control information (data size, Data start offset). Here, the page number (PNO) and the record number (RNO) are determined (step A6) (FIG. 5, (3)).
[0043]
Next, the updatelog generation unit 28 calculates and obtains an index page number (IPNO) of an index page in which an index record corresponding to the additional record created on the transactionlocal log buffer 40 is to be stored (step A7). The index page of this index page number (IPNO) is searched in the system global log buffer 38 (step A8) (FIG. 5, (4)).
[0044]
If the index page is not stored in the system global log buffer 38 (No in step A9), theaccess processing unit 20 causes theindex update unit 26 to load the index page from theindex file 36 into thebuffer 32. Is copied from thebuffer 32 to the system global log buffer 38 (step A10) (FIG. 5 (5)).
[0045]
The updatelog generation unit 28 adds an index record to the index page of the index page number (IPNO) on the systemglobal log buffer 38, creates record control information corresponding to the index record (step A11), and Is set to "1" (addition not determined) (step A12) (FIG. 5 (6)). Further, the updatelog generation unit 28 updates and stores the number of undetermined index records in the page control information of the index page.
[0046]
For example, when data "ABC" of the additional record is added on the transactionlocal log buffer 40, an index record corresponding to the added data record is added on the system global log buffer 38 (for example, index record 3). Here, as the key value of theindex record 3, for example, the head “A” of the additional data record is used (FIG. 3D), the pointer to the record data is the page number (PNO) determined in step A6, the record The number (RNO) is used (FIG. 3E). Further, in therecord 3 control information corresponding to theindex record 3, the undetermined flag is set to “1” and added (FIG. 3 (f)).
[0047]
It should be noted that each time a set of “index page number (IPNO) and index record number (IRNO)” of the index updated by the additional access processing is updated for each transaction, it is stored in the memory 44. The data of the pair of “IPNO, IRNO” of this index is referred to when determining the index page (index record) to be determined in the transaction determination processing described later.
[0048]
Thus, an index record for the record added on the transactionlocal log buffer 40 is added on the systemglobal log buffer 38 without locking the corresponding index page. In the systemglobal log buffer 38, by setting an undetermined flag “1” indicating addition undetermined in the record control information, it can be determined by a transaction determining process described later.
[0049]
Next, the delete access process will be described with reference to the flowchart shown in FIG. 6 and the diagram showing the flow of the delete access shown in FIG.
[0050]
When a deletion access request is received from theapplication 12, theaccess processing unit 20 searches thedata update unit 24 for a record to be deleted (deletion record) using only the buffer 32 (step B1), and finds the corresponding page number (deletion record). PNO) and a record number (RNO), and an index page number (IPNO) and an index record number (IRNO) are determined (step B2).
[0051]
The record to be deleted is, for example, searched by the user by another process, and the record obtained by the search is specified through theapplication 12, or the index of the data to be deleted that is explicitly specified by the user. (The key value stored in the index record) may be specified through theapplication 12.
[0052]
The transactionlock management unit 22 secures an update mode transaction lock for the page number (PNO) determined by the data update unit 24 (step B3) ((1) in FIG. 7).
[0053]
Next, theaccess processing unit 20 searches thedata update unit 24 for a data page of the page number (PNO) stored in thebuffer 32. The data is copied to the transaction local log buffer 40 (step B4) ((2) in FIG. 7).
[0054]
The updatelog generation unit 28 deletes the deletion record in response to the request from theapplication 12 from the data page of the page number (PNO) on the transaction local log buffer 40 (step B5) (FIG. 7 (3)).
[0055]
Next, the updatelog generation unit 28 searches the systemglobal log buffer 38 for the index page of the index page number (IPNO) (step B6) (FIG. 7 (4)).
[0056]
If the index page is not stored in the system global log buffer 38 (No in step B7), theaccess processing unit 20 causes theindex update unit 26 to load the index page from theindex file 36 into thebuffer 32. Is copied from thebuffer 32 to the system global log buffer 38 (step B8) (FIG. 7 (5)).
[0057]
The updatelog generation unit 28 sets the undetermined flag of the record control information for the record of the index page of the index page number (IPNO) on the systemglobal log buffer 38 to “2” (deletion undetermined) (step B9) (step B9) (Fig. 7 (6)). Further, the updatelog generation unit 28 updates and stores the number of undetermined index records in the page control information of the index page.
[0058]
In addition, in the case of the delete access process, similarly to the additional access process, the memory 44 is stored in the memory 44 every time the set of the updated index “index page number (IPNO), index record number (IRNO)” is updated for each transaction. It shall be stored.
[0059]
Thus, the record specified by theapplication 12 is deleted on the transactionlocal log buffer 40, and the index record corresponding to the deleted record is indicated on the systemglobal log buffer 38 without locking the corresponding index page. An undetermined flag “2” is set in advance. At this time, the deleted record is not deleted on thebuffer 32. Thus, the record deletion can be reflected in the index page in theindex file 36 by deleting the record by the transaction confirmation processing described later.
[0060]
Next, the update access process will be described with reference to the flowchart shown in FIG. 8 and the diagram showing the flow of the update access shown in FIG. The update access is a process combining the above-described addition access and deletion access.
[0061]
Upon receiving an update access request from theapplication 12, theaccess processing unit 20 searches for a record (update record) to be updated using only thebuffer 32 by the data updating unit 24 (step C1), and finds the corresponding page number ( PNO) and a record number (RNO) and an index page number (IPNO) and an index record number (IRNO) are determined (step C2).
[0062]
The record to be updated is searched, for example, by another process by the user, and the record obtained by the search is specified through theapplication 12 or the index of the data to be updated specified by the user. (The key value stored in the index record) may be specified through theapplication 12, for example.
[0063]
The transactionlock management unit 22 secures a transaction lock in the update mode for the page number (PNO) determined by the data update unit 24 (step C3) ((1) in FIG. 9).
[0064]
Next, theaccess processing unit 20 searches thedata update unit 24 for a data page of the page number (PNO) stored in thebuffer 32. The data is copied to the transaction local log buffer 40 (step C4) ((2) in FIG. 9).
[0065]
Thedata updating unit 24 updates the pre-update record data of the data page of the page number (PNO) to the post-update record data on the transaction local log buffer 40 (Step C5). At the same time, the record data of the record number (RNO) before the update is invalidated, and a record number (RNO_P) different from the record number (RNO) is reserved for the record data after the update (step C6), and the record number (R6) is obtained. RNO_P), the record control information of the updated record data is created (step C7) (FIG. 9 (3)). For example, in FIG. 9, the record data “ABC” before the update is invalidated, and the record data “DEF” after the update is added to a place different from the record data “ABC”.
[0066]
Next, the updatelog generation unit 28 stores the index page of the index page number (IPNO) corresponding to the record data before update and the index page (IPNO_P) to store the key corresponding to the record data after update in the system global log. A search is performed on the buffer 38 (step C8) (FIG. 9-4).
[0067]
If the corresponding index page is not stored in the system global log buffer 38 (step C9, No), theaccess processing unit 20 causes theindex updating unit 26 to load the corresponding index page from theindex file 36 into thebuffer 32. Is copied from thebuffer 32 to the system global log buffer 38 (step C10) (FIG. 9-5).
[0068]
The updatelog generation unit 28 stores, in the systemglobal log buffer 38, record control information corresponding to the index record of the index record number (IRNO) corresponding to the record data before update in the index page of the index page number (IPNO). On the other hand, the undetermined flag is set to "2" (deletion undetermined) (step C11). For example, in FIG. 9, for the data record “ABC” deleted on the transactionlocal log buffer 40, the record control information corresponding to the index record (key value “A”) indicates “2” indicating that the deletion is not confirmed. To "." Further, the updatelog generation unit 28 adds an index record corresponding to the updated record data in the index page of the index page number (IPNO_P) on the systemglobal log buffer 38, and controls the record corresponding to the index record. Information is created (step C12). At this time, the undetermined flag is set to "1" (addition undetermined) for the record control information (step C13). For example, in FIG. 9, for the data record “DEF” added on the transactionlocal log buffer 40, “1” indicating that the record control information corresponding to the index record (key value “D”) has not been added is “1”. "(FIG. 9-6). Further, the updatelog generation unit 28 updates and stores the number of undetermined index records in the page control information of the index page.
[0069]
In the case of the update access process, similarly to the additional access process, the memory 44 is updated every time a set of the updated index “index page number (IPNO), index record number (IRNO)” is updated for each transaction. It shall be stored.
[0070]
Thus, in the update access processing, the index record for the record added or deleted on the transactionlocal log buffer 40 is added or deleted on the systemglobal log buffer 38 without locking the corresponding index page. In the systemglobal log buffer 38, an undetermined flag “1” indicating addition undetermined is set in the record control information corresponding to the added record data, and an undetermined flag indicating deletion undetermined in the record control information corresponding to the deleted record data is set. By setting the determination flag “2”, the determination can be performed by a transaction determination process described later.
[0071]
Next, the transaction determination processing will be described with reference to the flowchart shown in FIG. 10 and the diagram showing the flow of the transaction determination processing shown in FIG.
[0072]
First, when there is a request from theapplication 12 to execute a transaction determination process (commit process), theaccess processing unit 20 causes the updatelog generation unit 28 to control the page control information of the index page presently determined on the systemglobal log buffer 38. The current system commit number is recorded in the last commit number (step D1).
[0073]
Although not shown, when the database management system is started, various control information for controlling the system operation is read from the data file 34 and stored in the memory 44. The control information stored at this time includes the system commit number (FIG. 2A) included in the file header of the data file 34. When the system is started, thetransaction management system 10 sets the system commit number read from the data file 34 as an initial value in one commit counter existing in the system, and updates the counter each time the transaction determination processing is executed. .
[0074]
In the transaction confirmation process, the system commit number counted by the commit counter is stored in the index page on the systemglobal log buffer 38 as the final commit number.
[0075]
Further, the updatelog generation unit 28 updates the undetermined flag of the record control information of the index record determined this time to “0” (determined) (step D2) (FIG. 11 (1)).
[0076]
It should be noted that which index page and index record are to be determined is determined by the “index page number (IPNO), index of the updated index stored for each transaction at the time of each access process (addition, deletion, update). It is determined by referring to a set of "record number (IRNO)".
[0077]
The updatelog generation unit 28 records all data pages in the transactionlocal log buffer 40 corresponding to the determined transaction in the log file 42 (step D3) (FIG. 11 (2)). Further, the updatelog generation unit 28 records the index page determined this time among the index pages in the systemglobal log buffer 38 in the log file 42 (step D4) (FIG. 11 (3)).
[0078]
Further, the updatelog generation unit 28 records the commit number in the log file 42 (step D5) (FIG. 11-4).
[0079]
Theaccess processing unit 20 reads the data page on the transactionlocal log buffer 40 by the updatelog generation unit 28 and transfers the data page to thebuffer 32 through thedata update unit 24. If a page with the same page number (PNO) already exists, it is overwritten (step D6) (FIG. 11-5). At the same time, the updatelog generation unit 28 invalidates all data pages on the transaction local log buffer 40 (step D7).
[0080]
Further, theaccess processing unit 20 reads the index page determined this time from the systemglobal log buffer 38 by the updatelog generation unit 28, and transfers the index page to thebuffer 32 through theindex update unit 26. If a page with the same index page number (IPNO) already exists, it is overwritten (step D8) (FIG. 11-6). At the same time, the updatelog generation unit 28 invalidates the index page in the systemglobal log buffer 38 determined this time (step D9).
[0081]
Here, the transactionlock management unit 22 releases all transaction locks belonging to the transaction determined this time (step D10) (FIG. 11 (7)).
[0082]
Thetransaction management system 10 indexes the data page transferred from the systemglobal log buffer 38 to thebuffer 32 in step D6 and the index page transferred from the transactionlocal log buffer 40 to thebuffer 32 in step D8. The data is registered in the data writing task so as to be written in the file 36 (step D11) (FIG. 11 (8)).
[0083]
Further, thetransaction management system 10 stores the value of the commit counter (system commit number) at the time of executing the transaction confirmation processing in the file header of the data file 34. As described above, the system commit number is read when the system is started, and thereafter, is updated each time the transaction determination processing is executed, and is written in the index page to be determined on the systemglobal log buffer 38. The system commit number (final commit number) stored in the index page is referred to at the time of recovery processing after a system failure described later.
[0084]
Thus, in the transaction confirmation processing, the index record in the undetermined state stored in the systemglobal log buffer 38 by the access processing (addition, deletion, update) requested from theapplication 12 is reflected in theindex file 36. Can be.
[0085]
Next, a description will be given of a reference to an update associated with an access process performed by each of the own transaction and another transaction with respect to a data record targeted for each access process (addition, deletion, update) described above.
[0086]
In the access processing by the own transaction, the records updated by the own transaction are referred to, and the records updated by other transactions are not referred to (the records before processing are referred to). Is achieved.
[0087]
FIG. 12 shows the flow of referring to updating of the own transaction.
FIG. 12A is a diagram illustrating reference to an additional record of the own transaction.
Thetransaction management system 10 searches the systemglobal log buffer 38, refers to the index record in the index page corresponding to the data record to be referred, and obtains the page number (PNO) and the record number (RNO) (FIG. 12 (a) {1}). In FIG. 12A, the index record having the key value “A” is referred to. At this time, the undecided flag is not considered (additional undecided "1").
[0088]
Thetransaction management system 10 searches the transactionlocal log buffer 40 corresponding to the own transaction based on the page number (PNO) and the record number (RNO), and records the record added by the own transaction (data “ABC of the additional record”). )) (FIG. 12 (a) (2)).
[0089]
FIG. 12B is a diagram illustrating reference to the deletion record of the own transaction.
Thetransaction management system 10 searches the systemglobal log buffer 38, refers to the index record in the index page corresponding to the data record to be referred, and obtains the page number (PNO) and the record number (RNO) (FIG. 12 (b) (1)). In FIG. 12B, the index record having the key value “A” is referred to. At this time, the undetermined flag is not considered (deletion is undetermined “2”).
[0090]
Thetransaction management system 10 searches the transactionlocal log buffer 40 corresponding to the own transaction based on the page number (PNO) and the record number (RNO). Then, the invalidated record control information is referred to, and it can be detected that the data record is an invalidated data record ((2) in FIG. 12B).
[0091]
FIG. 12C is a diagram illustrating reference to the update record of the own transaction.
When thetransaction management system 10 searches the systemglobal log buffer 38 with the pre-update key (key value “A”), thetransaction management system 10 invalidates the deleted record by the same procedure as that for referring to the deleted record of the own transaction (FIG. 12B). It is detected that the record is a converted record (FIG. 12 (c) (1) and (2)).
[0092]
When the systemglobal log buffer 38 is searched with the updated key (key value “D”), the additional record of the own transaction is referred to as described above (the updated record (added record is added in the same procedure as in FIG. 12A). ("DEF" in FIG. 12 (c)).
[0093]
FIG. 13 shows the flow of referring to update of another transaction.
FIG. 13A is a diagram illustrating reference to an additional record of another transaction.
Thetransaction management system 10 searches the systemglobal log buffer 38, refers to the index record in the index page corresponding to the data record to be referred, and obtains the page number (PNO) and the record number (RNO) (FIG. 13 (a) {1}). In FIG. 13A, the index record having the key value “A” is referred to. At this time, the undecided flag is not considered (additional undecided "1").
[0094]
Here, an additional record is searched in the transactionlocal log buffer 40 corresponding to the own transaction based on the page number (PNO), but this is not hit (FIG. 13 (a) (2)). That is, since the data page is locked by the transaction lock, the page being updated by another transaction does not exist in the transactionlocal log buffer 40 of the own transaction.
[0095]
Since the data record to be referred to does not exist in the transactionlocal log buffer 40, thetransaction management system 10 searches thebuffer 32 to obtain a data page corresponding to the page number (PNO) ((3) in FIG. 13 (a)). ). Since the data record indicated by the record number (RNO) in the page with the page number (PNO) is managed as an empty area (so other transactions could be added), it is possible to detect that it is an invalid record. Yes (before addition by another transaction).
[0096]
FIG. 13B is a diagram illustrating reference to a delete record of another transaction.
Thetransaction management system 10 searches the systemglobal log buffer 38, refers to the index record in the index page corresponding to the data record to be referred, and obtains the page number (PNO) and the record number (RNO). (FIG. 13 (b) (1)). In FIG. 13B, the index record having the key value “A” is referred to. At this time, the undetermined flag is not considered (deletion is undetermined “2”).
[0097]
Here, a data record is searched in the transactionlocal log buffer 40 corresponding to the transaction based on the page number (PNO), but this is not hit for the same reason as described above (FIG. 13 (b) (2)). .
[0098]
Since the data record to be referred to does not exist in the transactionlocal log buffer 40, thetransaction management system 10 searches thebuffer 32 and obtains a data page corresponding to the page number (PNO) (FIG. 13B (3)). ). Since the data record indicated by the record number (RNO) in the page of the page number (PNO) is in a state before deletion, the record before deletion can be obtained as a valid record. That is, it is possible to refer to a data record that has not been deleted by an access process by another transaction.
[0099]
FIG. 13C is a diagram illustrating reference to an update record of another transaction.
When thetransaction management system 10 searches the systemglobal log buffer 38 with the pre-update key (key value “A”) ((1) in FIG. 13C), thetransaction management system 10 refers to the above-described deletion record of another transaction (FIG. 13) A record before update ("ABC") is obtained in the same procedure as (b)) ((2)-(3) in FIG. 13 (c)).
[0100]
When the systemglobal log buffer 38 is searched with the updated key (key value “D”) ((1) in FIG. 13C), the additional record of the other transaction is referred to (FIG. 13A). An invalid record is detected in the same procedure as in (1) (2) and (3) in FIG.
[0101]
In this manner, the updated data of the own transaction can be referred to, and the updated data of the other transaction can refer to the data before the update unless the transaction confirmation process is executed. As a result, consistent data reference is realized, and transaction independence can be realized.
[0102]
Next, a recovery process after a system failure will be described with reference to a flowchart shown in FIG. 14 and a diagram showing a flow of the recovery process shown in FIG.
[0103]
When the system is started after the system is down due to some failure or the like, thetransaction management system 10 applies the log stored in thelog file 42 to the data file 34 and the index file ((1) in FIG. 15). In this state, index records in an undetermined state due to a transaction being processed at the time of the system down may be mixed in the index page. An index record in an undetermined state is not actually determined and must be deleted.
[0104]
Further, thetransaction management system 10 obtains the commit number at the time of system shutdown from the log at the time of system startup (step E1).
[0105]
When theapplication 12 is started up and a mishit to theindex page buffer 32 occurs during the processing of an arbitrary access (step E2), the process of loading the index page from theindex file 36 into thebuffer 32 causes The final commit number of the page control information is compared with the commit number at the time of system startup stored in the memory at the time of startup (steps E3 and E4) ((2) in FIG. 15).
[0106]
If the commit number at the time of system startup is newer (step E5, Yes), thetransaction management system 10 checks the number of undetermined index records recorded in the page control information of the index page (step E6). If there is an unconfirmed index record (step E7, Yes), an index corresponding to the record control information whose unconfirmed flag is not “0” (confirmed) is referred to by referring to all record control information in the index page. The record is invalidated (step E8) ((3) in FIG. 15).
[0107]
After performing these processes, the index page on thebuffer 32 is validated (step E9).
[0108]
In this way, in the recovery processing after a system failure, the commit counter in the system is compared with the commit counter in the page (final commit number) prior to the index record reference in the index page reference, and the commit counter in the page is checked. Is smaller, the first access to the index page after system startup is identified, and index down recovery is performed by deleting all indoubt indexes in the index page. Can be realized.
[0109]
In the above-described recovery processing, when loading an index page from theindex file 36 into thebuffer 32, if it is determined that this index page is the first access after the system is started, an undefined index record is assigned to this index page. However, at the time of system startup, when applying the log of thelog file 42 to theindex file 36, the undetermined index record may be invalidated for all index pages at once. In this case, a large processing load is applied when the system is started up, but the processing load at the time of the first access after the system startup of each index page can be reduced.
[0110]
As described above, in the database management system according to the present embodiment, the validity of the index record is checked every time the access is performed (the systemglobal log buffer 38, the transaction local log 38) without acquiring the transaction lock on theindex file 36. By making the determination on the buffer 40), the independence of the transaction described with reference to FIGS. 12 and 13 and the durability of the transaction as shown in FIG. 15 can be realized. By not performing a transaction lock on theindex file 36, it is possible to eliminate contention and deadlock on the index page, thereby avoiding degradation in system throughput.
[0111]
In the present embodiment, as a recovery method for realizing transaction durability, any method other than the logging method can be used.
[0112]
Also, in the present embodiment, the index page of theindex file 36 is described as having the logical index structure shown in FIG. 3B. This can be applied regardless of the index type.
[0113]
In addition, the method described in the above-described embodiment can be executed on a recording medium such as a magnetic disk (flexible disk, hard disk, etc.), an optical disk (CD-ROM, DVD, etc.), a semiconductor memory, etc. It can be written and provided to various devices. Further, it is also possible to transmit the data via a communication medium and provide the data to various devices. A computer that realizes the present apparatus reads the program recorded on the recording medium or receives the program via the communication medium, and executes the above-described processing by controlling the operation of the program.
[0114]
Note that the present invention is not limited to the above-described embodiment as it is, and can be embodied by modifying constituent elements in an implementation stage without departing from the scope of the invention. Various inventions can be formed by appropriately combining a plurality of constituent elements disclosed in the above embodiments. For example, some components may be deleted from all the components shown in the embodiment. Further, components of different embodiments may be appropriately combined.
[0115]
【The invention's effect】
As described above in detail, according to the present invention, by achieving transaction independence without using transaction locks in index access, it is possible to eliminate contention and deadlocks and achieve good system throughput. It is possible.
[Brief description of the drawings]
FIG. 1 is a block diagram showing a system configuration of a database management system according to an embodiment.
FIG. 2 is a view showing an example of a data storage format in adata file 34;
FIG. 3 is a diagram showing an example of an index storage format in anindex file 36.
FIG. 4 is a flowchart illustrating additional access processing according to the embodiment.
FIG. 5 is a diagram showing a flow of an additional access process in the embodiment.
FIG. 6 is a flowchart for explaining a deletion access process according to the embodiment;
FIG. 7 is a view showing a flow of a deletion access process in the embodiment.
FIG. 8 is a flowchart for explaining an update access process in the embodiment.
FIG. 9 is a diagram showing a flow of an update access process in the embodiment.
FIG. 10 is a flowchart for explaining transaction confirmation processing according to the embodiment;
FIG. 11 is a diagram showing a flow of a transaction confirmation process in the embodiment.
FIG. 12 is a diagram showing a flow of referring to update of a self-transaction.
FIG. 13 is a diagram showing a flow of referring to update of another transaction.
FIG. 14 is a flowchart for describing recovery processing after a system failure in the embodiment.
FIG. 15 is a diagram showing a flow of a recovery process in the embodiment.
[Explanation of symbols]
DESCRIPTION OFSYMBOLS 10 ... Transaction management system, 12 ... Application, 20 ... Access processing part, 22 ... Transaction lock management part, 24 ... Data update part, 26 ... Index update part, 28 ... Update log generation part, 30 ... Transaction determination part, 32 ...Buffer 34 data file 36index file 38 systemglobal log buffer 40 transactionlocal log buffer 42 log file

Claims (9)

Translated fromJapanese

アプリケーションからのアクセス要求に応じたトランザクションを管理するデータベース管理システムにおいて、
アプリケーションが扱うデータを格納するデータ格納手段と、
前記データ格納手段に格納されたデータに対応する索引を格納する索引格納手段と、
アプリケーションからのアクセス要求に応じて、更新された未確定の状態にあるデータをトランザクション毎に格納するための第１の格納手段と、
前記第１の格納手段に格納されたデータに対応する索引を格納するための第２の格納手段と、
前記アプリケーションからの前記データ格納手段に格納されたデータに対するアクセス要求に応じた処理後の更新されたデータを前記第１の格納手段に格納する更新データ格納手段と、
前記更新データ格納手段により前記第１の格納手段に格納されたデータに対応する前記索引格納手段に格納された索引に対して、未確定状態を示すフラグを付加して前記第２の格納手段に格納する更新索引格納手段と
を具備したことを特徴とするデータベース管理システム。In a database management system that manages transactions in response to access requests from applications,
Data storage means for storing data handled by the application,
Index storage means for storing an index corresponding to the data stored in the data storage means;
First storage means for storing updated data in an undetermined state for each transaction in response to an access request from an application;
A second storage unit for storing an index corresponding to data stored in the first storage unit;
Update data storage means for storing, in the first storage means, updated data after processing in response to an access request for data stored in the data storage means from the application;
The update data storage unit adds a flag indicating an undetermined state to the index stored in the index storage unit corresponding to the data stored in the first storage unit, and adds the flag to the second storage unit. A database management system, comprising: an update index storage unit for storing.前記更新索引格納手段は、前記アプリケーションから、削除アクセス要求があった場合に削除未確定を示すフラグを索引に対して付加し、追加アクセス要求があった場合に追加未確定を示すフラグを索引に対して付加することを特徴とする請求項１記載のデータベース管理システム。The update index storage unit adds a flag indicating deletion unconfirmed to the index when a deletion access request is received from the application, and adds a flag indicating addition unconfirmed to the index when an addition access request is received. 2. The database management system according to claim 1, wherein the database management system is added.前記データ格納手段に格納されたデータに対する問い合わせに対して、前記第２の格納手段から問い合わせ対象とするデータに対応する索引を検索する検索手段と、
前記検索手段によって検索された索引が示すデータが、前記第１の格納手段に格納されている場合には同データを参照し、前記第１の格納手段に格納されていない場合には、前記データ格納手段に格納されたデータを参照する更新参照手段と
を具備することを特徴とするデータベース管理システム。Searching means for searching an index corresponding to data to be queried from the second storing means in response to an inquiry for data stored in the data storing means;
When the data indicated by the index searched by the search means is stored in the first storage means, the data is referred to. When the data is not stored in the first storage means, the data is referred to. A database management system, comprising: update reference means for referring to data stored in storage means.前記更新参照手段は、前記問い合わせをしたトランザクションに対応して前記第１の格納手段に格納されたデータを対象として参照することを特徴とする請求項３記載のデータベース管理システム。4. The database management system according to claim 3, wherein the update reference unit refers to data stored in the first storage unit in correspondence with the inquired transaction.前記更新索引格納手段により前記第２の格納手段に格納された未確定状態を示すフラグが付加された索引を確定状態にして前記索引格納手段に格納すると共に、前記索引に対応する前記第１の格納手段に格納されたデータを前記データ格納手段に格納して確定状態にする確定手段を具備したことを特徴とする請求項１記載のデータベース管理システム。The index added to the flag indicating the undetermined state stored in the second storage means by the update index storage means is set to a fixed state and stored in the index storage means, and the first index corresponding to the index is stored. 2. The database management system according to claim 1, further comprising a determination unit that stores the data stored in the storage unit in the data storage unit and sets the data in a determined state.システム起動時に、未確定状態を示すフラグが付された索引を検索する未確定索引検索手段と、
前記未確定索引検索手段によって検索された該当する索引を無効化する索引無効化手段と
を具備したことを特徴とする請求項１記載のデータベース管理システム。An undetermined index search means for searching an index with a flag indicating an undetermined state at system startup;
2. The database management system according to claim 1, further comprising: index invalidation means for invalidating a corresponding index searched by said undetermined index search means.前記索引格納手段に格納された特定のサイズのページに区切られた索引に対するアクセス時に、当該索引のページへのシステム起動後最初のアクセスであるか否かを識別する識別手段と、
前記識別手段により最初のアクセスであると判別された場合に、当該ページから未確定状態を示すフラグが付された索引を検索する未確定索引検索手段と、
前記未確定索引検索手段によって検索された該当する索引を無効化する索引無効化手段と
を具備したことを特徴とする請求項１記載のデータベース管理システム。When accessing an index partitioned into pages of a specific size stored in the index storage means, an identification means for identifying whether or not the first access after system startup to a page of the index,
An undetermined index search unit that searches an index with a flag indicating an undetermined state from the page when the identification unit determines that the access is the first access;
2. The database management system according to claim 1, further comprising: index invalidation means for invalidating a corresponding index searched by said undetermined index search means.前記更新索引格納手段により前記第２の格納手段に格納された未確定状態を示すフラグが付加された索引のページを確定状態にして前記索引格納手段に格納すると共に、前記索引のページに対応する前記第１の格納手段に格納されたデータを前記データ格納手段に格納して確定状態にする確定手段と、前記確定手段によって確定状態にされた回数をカウントするカウンタ管理手段と、
システム起動時に前記カウンタ管理手段によりカウントされた回数を初期値として設定する初期値設定手段と、
前記確定手段による確定のたびに前記カウンタ管理手段に回数を更新させると共に、前記確定手段により確定対象の索引のページ内に前記カウンタ管理手段によりカウントされた回数の値を記録する回数記録手段と、
前記識別手段は、前記回数記録手段によって索引のページに記録された回数と前記カウンタ管理手段によりカウントされた回数とを比較した結果、索引のページに記録された回数が少ない場合にシステム起動後最初のアクセスであると識別することを特徴とする請求項７記載のデータベース管理システム。The updated index storage unit sets the page of the index to which the flag indicating the undetermined state stored in the second storage unit is added to a fixed state, stores the page in the index storage unit, and corresponds to the page of the index. Determining means for storing the data stored in the first storage means in the data storage means and setting it to a fixed state; counter managing means for counting the number of times the fixed state is set by the determining means;
Initial value setting means for setting the number of times counted by the counter management means at system startup as an initial value,
Number of times recording means for causing the counter management means to update the number of times for each determination by the determination means, and recording the value of the number of times counted by the counter management means in the page of the index to be determined by the determination means,
The identification means compares the number of times recorded on the index page by the number of times recording means with the number of times counted by the counter management means. 8. The database management system according to claim 7, wherein the access is identified as an access.アプリケーションからのアクセス要求に応じたトランザクションを管理するデータベース管理プログラムであって、
コンピュータを、
アプリケーションが扱うデータを格納するデータ格納手段と、
前記データ格納手段に格納されたデータに対応する索引を格納する索引格納手段と、
アプリケーションからのアクセス要求に応じて、更新された未確定の状態にあるデータをトランザクション毎に格納するための第１の格納手段と、
前記第１の格納手段に格納されたデータに対応する索引を格納するための第２の格納手段と、
前記アプリケーションからの前記データ格納手段に格納されたデータに対するアクセス要求に応じた処理後の更新されたデータを前記第１の格納手段に格納する更新データ格納手段と、
前記更新データ格納手段により前記第１の格納手段に格納されたデータに対応する前記索引格納手段に格納された索引に対して、未確定状態を示すフラグを付加して前記第２の格納手段に格納する更新索引格納手段とに機能させるためのデータベース管理プログラム。A database management program that manages transactions according to access requests from applications,
Computer
Data storage means for storing data handled by the application,
Index storage means for storing an index corresponding to the data stored in the data storage means;
First storage means for storing updated data in an undetermined state for each transaction in response to an access request from an application;
A second storage unit for storing an index corresponding to data stored in the first storage unit;
Update data storage means for storing, in the first storage means, updated data after processing in response to an access request for data stored in the data storage means from the application;
The update data storage unit adds a flag indicating an undetermined state to the index stored in the index storage unit corresponding to the data stored in the first storage unit, and adds the flag to the second storage unit. A database management program for functioning as an update index storage unit for storing.

Images