【発明の詳細な説明】〔概要〕トランザクションによる追加レコードをデータベースに
格納するヒストリカルなデータ蓄積処理に適したデータ
ベース管理処理方式に関し。DETAILED DESCRIPTION OF THE INVENTION [Summary] The present invention relates to a database management processing method suitable for historical data accumulation processing in which records added by transactions are stored in a database.
データ収集トランザクションのコンカレンシーを向上さ
せ、かつ蓄積データの一括処理や処理済みデータの削除
を円滑に行うことができるようにすることを目的とし。The purpose is to improve the concurrency of data collection transactions and to facilitate batch processing of accumulated data and deletion of processed data.
追加レコードのログが格納されるセーフログ域と、コミ
ットされたレコードが格納されるバッファ域と、二次記
憶上に設けられるデータベース格納域と、レコードの追
加時に、セーフログ域にそのレコードのログデータを採
取するデータベースアクセス部と、コミット済みのログ
データをセーフログ域から取り出し、バッファ域に格納
するコミットレコード収集部と、バッファ域の内容をト
ランザクションの処理とは非同期にデータベース格納域
に書き出すバッファ制御部とを備え、追加レコードのデ
ィスクロージャを、前記バッファ域への転送で行うよう
に構成する。There is a safe log area where the log of added records is stored, a buffer area where committed records are stored, a database storage area provided on secondary storage, and when a record is added, the log data of that record is stored in the safe log area. A database access unit that collects the data, a commit record collection unit that extracts committed log data from the safe log area and stores it in the buffer area, and a buffer control unit that writes the contents of the buffer area to the database storage area asynchronously with transaction processing. and is configured to perform disclosure of additional records by transferring them to the buffer area.
本発明は、トランザクションによる追加レコードをデー
タベースに格納するヒストリカルなデータ蓄積処理に適
したデータベース管理処理方式に関する。The present invention relates to a database management processing method suitable for historical data accumulation processing in which records added by transactions are stored in a database.
現在、計算機システムの著しい進歩により５例えば（ａ
）多品種少量生産化、Φ）商品のタイムリーな納入、（
Ｃ）在庫や生産設備の無駄の削減、というようなデータ
蓄積処理のユーザニーズを計算機システムで実現する要
求が高まっている。Nowadays, due to remarkable progress in computer systems, 5 e.g.
) High-mix low-volume production, Φ) Timely delivery of products, (
C) There is a growing demand for computer systems to meet user needs for data storage and processing, such as reducing waste in inventory and production equipment.
このようなニーズに応えるためには、データの蓄積／参
照をリアルタイムに行うことが計算機システムに要求さ
れる。In order to meet such needs, computer systems are required to store and reference data in real time.
第９図は従来技術の例を示す。FIG. 9 shows an example of the prior art.
第９図（イ）は、一般的なデータベース管理システムの
構成を示しており、１０は応用処理部。FIG. 9(a) shows the configuration of a general database management system, and 10 is an application processing section.
１６はバッファプール、１８はデータベース格納域、３
０はデータベース管理部、３１はログ管理部、３２はロ
グ格納域を表す。16 is a buffer pool, 18 is a database storage area, 3
0 represents a database management section, 31 represents a log management section, and 32 represents a log storage area.
応用処理部１０は、ユーザからの一つのまとまった処理
要求を、トランザクションとして処理する。特にデータ
蓄積処理の場合、応用処理部１０は、データペース管理
部３０に対して収集データの格納を要求し、バッファプ
ール１６を介して収集データを、二次記憶上のデータベ
ース格納域１８に格納する。The application processing unit 10 processes a single processing request from a user as a transaction. In particular, in the case of data accumulation processing, the application processing unit 10 requests the data pace management unit 30 to store the collected data, and stores the collected data in the database storage area 18 on the secondary storage via the buffer pool 16. do.
また、収集データについてのログを、ダウンリカバリの
ために、ログ管理部３１によってログ格納域３２に採取
する。Further, the log management unit 31 collects logs regarding the collected data in the log storage area 32 for down recovery.
従来、このようなシステムにおいて、第９図（ロ）に示
すように複数のトランザクションＴＩＴ２が走行すると
き、一般にデータが発生したときからトランザクション
処理が終了するまでの間。Conventionally, in such a system, when a plurality of transactions TIT2 run as shown in FIG. 9(B), generally from the time when data is generated until the end of transaction processing.
データベース格納域１８のファイルに対するロック制御
を行い、データ間の不整合が発生しないようにしていた
。Lock control was performed on files in the database storage area 18 to prevent inconsistency between data.
例えばトランザクションＴ１は、レコードＲ１の追加を
行ってからトランザクション終了時にそれを有効化する
コミットを行うまでの間、その格納媒体に対するロック
を保持する。したがって他のトランザクションＴ２がレ
コードＲ２を追加しようとしても、ロックの解除待ちと
なり、トランザクションＴ１の処理の終了を待たなけれ
ばならなかった。For example, transaction T1 holds a lock on the storage medium from the time it adds record R1 until the time it commits to make it valid at the end of the transaction. Therefore, even if another transaction T2 tried to add record R2, it would have to wait for the lock to be released and wait for the processing of transaction T1 to finish.
なお、コミットとは、トランザクション内で行った更新
、追加、削除などのデータを確定させ。Note that a commit commits data such as updates, additions, and deletions performed within a transaction.
有効化させる処理のことである。This is the process of enabling it.
なお、トランザクションや格納、ログ、ロックなど、デ
ータベース管理についての一般的な技術は、 ＤＡＴＡ
ＢＡＳＥ ＤＥＳＩＧＮ、 ＧＩＯＷＩＥＤＥＲＨＯ
ＬＤ 著（ＩＳＢＮ ０−０７−Ｙ６６６３８−５）に
詳しい。In addition, general database management technologies such as transactions, storage, logs, and locks are DATA.
BASE DESIGN, GIOWIEDERHO
Written by LD (ISBN 0-07-Y66638-5) for details.
従来技術では、第９図（ロ）に示すように、データ間の
不整合が発生しないようにするために。In the conventional technology, as shown in FIG. 9(b), in order to prevent inconsistency between data from occurring.
データ蓄積処理の並列性が犠牲となっていた。The parallelism of data accumulation processing was sacrificed.
これは、従来のデータベースの格納機構には。This is a traditional database storage mechanism.
いわゆるＢ’ ）リーやハツシュ、ヒープなどがある
が、エントリデータの収集を主として扱う場合に適した
格納機構がないことに起因している。This is due to the fact that there is no storage mechanism suitable for mainly handling the collection of entry data, although there are so-called B') storage systems, hashs, and heaps.
すなわち、従来の格納機構を、エントリデータの収集を
目的としたシステムに適用すると、データ収集トランザ
クションの高度な同時並行動作ができないという問題が
あった。That is, when the conventional storage mechanism is applied to a system for collecting entry data, there is a problem that data collection transactions cannot be performed in a highly parallel manner.
また、インデックスによる収集データのアトホックな収
集が難しかったり、蓄積データの一括処理や処理済みデ
ータの削除を行っている時間帯では、データ収集処理が
止まってしまうという問題があった。There are also problems in that it is difficult to collect data on an ad-hoc basis using indexes, and that data collection processing stops during periods when batch processing of accumulated data or deletion of processed data is being performed.
そこで、従来はアプリケーションレベルで個別に解決す
ることを試み、データ収集専門の処理と収集データの加
工処理とを分け、またデータベースも分けて、それぞれ
処理する時間帯を決め、この間のバッチ的な転送を行う
などしていた。しかし、このようにアプリケーションレ
ベルで対処するのは、アプリケージジンの開発が難しく
なり。Therefore, in the past, attempts were made to solve this problem individually at the application level, separating specialized processing for data collection and processing of collected data, and also separating the database, determining the processing time for each, and batch-like transfer during this time. etc. However, dealing with this at the application level makes it difficult to develop an app cage.
またシステムの運用も難しいものになるという問題があ
った。There is also the problem that the system becomes difficult to operate.
本発明は上記問題点の解決を図り、データ収集トランザ
クションのコンカレンシーを向上させ。The present invention aims to solve the above problems and improves the concurrency of data collection transactions.
かつ蓄積データの一括処理や処理済みデータの削除を円
滑に行うことができるようにすることを目的としている
。It also aims to facilitate batch processing of accumulated data and deletion of processed data.
第１図は本発明の原理説明図である。FIG. 1 is a diagram explaining the principle of the present invention.
応用処理部１０は、トランザクションに関するデータ収
集・蓄積処理を行うものである。データベースアクセス
部１１は、応用処理部１０からの要求により、データベ
ースのレコードの追加・更新・検索・削除などの処理を
行う。The application processing unit 10 performs data collection and accumulation processing regarding transactions. The database access unit 11 performs processes such as adding, updating, searching, and deleting database records in response to requests from the application processing unit 10.
セーフログ域１２は、追加レコードのログが格納される
記憶領域である。なお１通常の更新後イメージ・ログや
コミット・ログなどの他のログが混在して格納されても
よい０例えば、高速の不揮発性メモリ内に設けられる。The safe log area 12 is a storage area in which a log of additional records is stored. Note that 1. Other logs such as a normal post-update image log and a commit log may be stored together. 0. For example, the log is provided in a high-speed non-volatile memory.
コミットレコード収集部１３は、コミシト済みのログデ
ータをセーフログ域１２から取り出し。The commit record collection unit 13 takes out committed log data from the safe log area 12.
ボラタイルバッファ域１４に格納する処理を行うもので
ある。ボラタイルバッファ域１４上に格納されたデータ
は、直接または後述するサロゲートマップ１９を介して
アクセス可能であり、アクセス要求元からは２実際のデ
ータベースに格納されたデータと同様に取り扱うことが
できる。It performs processing for storing data in the volatile buffer area 14. The data stored in the volatile buffer area 14 can be accessed directly or via a surrogate map 19, which will be described later, and can be handled by the access requester in the same way as data stored in an actual database.
バッファ制御部１５は、従来と同様なバッファ制御を行
うとともに、ボラタイルバッファ域１４の内容をトラン
ザクションの処理とは非同期に。The buffer control unit 15 performs buffer control similar to conventional buffer control, and controls the contents of the volatile buffer area 14 asynchronously with transaction processing.
データベース格納域１８−１または１８−２に書き出す
処理を行う。バッファブール１６は、従来から用いられ
ている一般のデータベースのバッファである。Processing for writing to the database storage area 18-1 or 18-2 is performed. The buffer Boolean 16 is a conventionally used general database buffer.
データベース格納域は、第１のデータベース格納域１８
−１と第２のデータベース格納域１８２とからなり、ヒ
ストリカルな蓄積データが格納される二次記憶上の記憶
領域である。The database storage area is the first database storage area 18
-1 and a second database storage area 182, which is a storage area on secondary storage in which historical accumulated data is stored.
再構成処理部１７は、データベース格納域１８−１．１
８−２の一方からレコードを読み出し。The reconfiguration processing unit 17 has a database storage area 18-1.1.
Read the record from one side of 8-2.
削除レコードを廃棄して、他方に有効レコードを詰めて
転記する処理を行うものである。This process involves discarding deleted records and filling them with valid records for transcription.
サロゲートマップ１９は、各レコードを識別する情報と
そのレコードの物理的な格納位置との対応情報を記憶し
、管理するものである。ここでのレコードを識別する情
報は１例えばサロゲートマップ１９のエントリ番号であ
る。The surrogate map 19 stores and manages correspondence information between information identifying each record and the physical storage location of that record. The information for identifying the record here is 1, for example, the entry number of the surrogate map 19.
インデックス部２０は９通常のデータベースにおけるイ
ンデックスと同様なものであるが、各しコードをサロゲ
ートマンブ１９のエントリ番号で管理する。したがって
、レコードの物理的な格納位置を変更した場合に、サロ
ゲートマップ１９におけるエントリの格納位置情報を変
更するだけで９インデックス部２０等の変更は不要とな
っている。The index section 20 is similar to the index in a normal database, but each code is managed by the entry number of the surrogate manbu 19. Therefore, when the physical storage location of a record is changed, it is only necessary to change the storage location information of the entry in the surrogate map 19, and there is no need to change the 9 index section 20 or the like.
これにより、レコードは、ボラタイルバッファ域１４に
存在していても、データベース格納域１８−１または１
８−２に存在しても、インデックス部２０からは同等に
扱うことができるようになっている。As a result, even if a record exists in the volatile buffer area 14, it is stored in the database storage area 18-1 or 1.
Even if it exists in 8-2, it can be treated equally from the index unit 20.
本発明の基本的なアイデアは、他のトランザクションへ
の収集データ（レコード）のアンロックを意味するディ
スクロージャが、コミット時点以降の適当なタイミング
で行えばよいことに基づいている。すなわち、一般のデ
ータ蓄積処理では。The basic idea of the present invention is based on the fact that disclosure, which means unlocking collected data (records) to other transactions, can be performed at an appropriate timing after the commit point. In other words, in general data accumulation processing.
参照処理のリアルタイム性やデータの読み込みの順序性
を、必ずしもコミット時点を基準として厳密に保証する
必要がないことが多く、それよりも参照処理と追加処理
間および追加処理と追加処理間の並列性に対する要求が
大きいことに着目している。In many cases, it is not necessary to strictly guarantee the real-time nature of reference processing and the order of data loading based on the commit time, but rather the parallelism between reference processing and addition processing and between addition processing and addition processing. We are focusing on the large demand for
エントリデータの収集を行うトランザクションの収集デ
ータ以外のアンロックについては、従来と同等の方式で
行ってかまわない。Unlocking of data other than the collected data of a transaction that collects entry data may be performed using the same method as in the past.
収集データに関しては、データ追加指示の時点で、従来
の意味の二次記憶に対する直接のデータ追加処理は行わ
ず、セーフログ域１２に蓄えておく、コミット時点また
はコミット後の適当なタイミングで、コミット対象のレ
コードをセーフログ域１２から収集し、ボラタイルバッ
ファ域１４に設定する。コミット処理そのものは、コミ
ット対象レコードの収集で終わってよいが、コミットか
らディスクロージャまでの期間におけるシステムファイ
ルからの回復を行うためのチエツクポイントを取得する
。Regarding the collected data, at the time of the data addition instruction, direct data addition processing to secondary storage in the conventional sense is not performed, but it is stored in the safe log area 12, and the commit target is stored at the time of commit or at an appropriate timing after commit. records are collected from the safe log area 12 and set in the volatile buffer area 14. The commit process itself may end with the collection of records to be committed, but checkpoints are acquired for recovery from the system file during the period from commit to disclosure.
ボラタイルバッファ域１４への転送が、これらのレコー
ドの他のトランザクションへのディスクロージャに相当
し、当該レコードに対する格納域の裏付けをとると同時
に、インデックス部２０へのアップグレードを行う。Transfer to the volatile buffer area 14 corresponds to disclosure of these records to other transactions, and at the same time, the storage area for the records is backed up and the index unit 20 is upgraded.
ボラタイルバッファ域１４の内容は、バッファ制御部１
５により２適当な機会にデータベース格納域」８−１ま
たは１８−２に転送する。システムダウン時において、
ボラタイルバッファ域１４のデータが失われた場合には
、セーフログ域１２からのデータ復旧が可能である。The contents of the volatile buffer area 14 are stored in the buffer control unit 1.
5 to the database storage area 8-1 or 18-2 at an appropriate opportunity. When the system is down,
If data in the volatile buffer area 14 is lost, data can be recovered from the safe log area 12.
収集データの一括削除やインデックス部２０を用いた削
除による虫食い状態のデータベース格納域を再利用する
ために、それをデータベース格納域１８−１．１８−２
の２つに分け、再構成処理部１７によって、一方から他
方へのコンプレスを行う、また、サロゲートマップ１９
によって、レコードの物理的な格納位置を浮動状態にし
た管理を可能とする。In order to reuse the database storage area that has become moth-eaten due to bulk deletion of collected data or deletion using the index unit 20, it is stored in the database storage area 18-1.18-2.
The reconstruction processing unit 17 compresses one to the other, and the surrogate map 19
This makes it possible to manage the physical storage location of records in a floating state.
本発明は、特にレコード追加要求時の処理に関係してい
るが、更新要求が、レコードの削除処理と追加処理に？
実現されるオプションでも有効であ〔実施例〕第２図は本発明の一実施例による動作例、第３図および
第４図は本発明の一実施例に係るデータベースアクセス
部の処理フロー、第５図は本発明の一実施例によるコミ
ントレコード収集部の処理フロー、第６図は本発明の一
実施例によるバッファ制御部の処理フロー、第７図は本
発明の一実施例に係る再構成処理部の処理フロー、第８
図は本発明の一実施例による再構成処理説明図を示す。The present invention is particularly related to processing when a record addition request is made, but does an update request include record deletion processing and record addition processing?
[Embodiment] Fig. 2 shows an example of operation according to an embodiment of the present invention, Figs. 3 and 4 show a processing flow of a database access unit according to an embodiment of the present invention, and FIG. 5 is a processing flow of a comment record collection unit according to an embodiment of the present invention, FIG. 6 is a processing flow of a buffer control unit according to an embodiment of the present invention, and FIG. Processing flow of configuration processing unit, 8th
The figure shows an explanatory diagram of reconstruction processing according to an embodiment of the present invention.
第２図において、ＴＩ、Ｔ２はレコード追加を主たる目
的としたトランザクションであり、それぞれ応用処理部
１０−１．１０−２で実行される。In FIG. 2, TI and T2 are transactions whose main purpose is to add records, and are executed by application processing units 10-1 and 10-2, respectively.
本発明では、このようなトランザクションＴＩ。In the present invention, such a transaction TI.
Ｔ２が同時に動作するとき、トランザクションへの入力
データであるエントリデータのレコードＲ１、Ｒ２の追
加では、直接、二次記憶上のデータベース格納域に書き
込むことはしないで、第２図（イ）に示すように、セー
フログ域１２に、更新後イメージのログとして、追加レ
コードＲ１，Ｒ２の内容を収集する。なお、このような
エントリデータ以外のデータベースの更新データについ
てもセーフログ域１２上にログを採る。なお、ここでは
説明を簡単化するため、その他のデータベースアクセス
で衝突はしていないものとする。When T2 operates simultaneously, adding entry data records R1 and R2, which are input data to a transaction, is not written directly to the database storage area on secondary storage, as shown in Figure 2 (a). As such, the contents of additional records R1 and R2 are collected in the safe log area 12 as a log of the updated image. Note that database update data other than such entry data is also logged in the safe log area 12. Note that here, to simplify the explanation, it is assumed that there is no conflict in other database accesses.
レコードＲ１，Ｒ２の追加については、セーフログ域１
２にログを採るだけであるので、単にセーフログ域１２
への格納のシリアライズのための簡単な制御表ロックを
行うだけでよく、トランザクション間の排他のためのト
ランザクションロックは不要である。したがって、複数
の応用処理部１０−１．１０−２が並行して処理を続け
ることができる。For adding records R1 and R2, safe log area 1
Since we only need to log in 2, we simply save the safe log area 12.
A simple control table lock is required for serialization of data stored in a transaction, and no transaction lock is required for exclusive use between transactions. Therefore, the plurality of application processing units 10-1 and 10-2 can continue processing in parallel.
トランザクションＴ１とＴ２とが、並行に動作する様子
を、第２図（ロ）に示している。FIG. 2 (b) shows how transactions T1 and T2 operate in parallel.
トランザクションＴＩが、レコードＲ１を追加すると、
そのレコードのログがセーフログ域１２に格納される。When transaction TI adds record R1,
A log of that record is stored in the safe log area 12.
トランザクションＴ１の終了処理で、それまでのデータ
操作を有効化するコミットの指示があると、そのコミッ
トログについてもセーフログ域１２に格納される。In the end processing of transaction T1, when a commit instruction is issued to validate the data operations up to that point, the commit log is also stored in the safe log area 12.
トランザクションＴ２が、レコードＲ２を追加しコミッ
トする場合も同様である。トランザクシヨンＴ１のコミ
ット終了まで、トランザクションＴ２の処理が待たされ
ることはない。The same applies when transaction T2 adds and commits record R2. The processing of transaction T2 does not have to wait until the commit of transaction T1 is completed.
コミットされた場合、セーフログ域１２からコミット対
象のレコードのログが収集され、ボラタイルバッファ域
１４に書き出される。ボラタイルバッファ域１４の内容
は、各トランザクションが参照可能である。ボラタイル
バッファ域１４は。When committed, the log of the record to be committed is collected from the safe log area 12 and written to the volatile buffer area 14. The contents of the volatile buffer area 14 can be referenced by each transaction. Volatile buffer area 14 is.
適宜、必要な時点で二次記憶上のデータベース格納域１
８に書き出される。Database storage area 1 on secondary storage as needed
8 will be written out.
次に第１図に示すデータベースアクセス部１１の処理に
ついて説明する。Next, the processing of the database access section 11 shown in FIG. 1 will be explained.
（ａ） レコード追加データベースアクセス部１１によるレコード追加では、
第３図（イ）に示すように、対象レコードをセーフログ
域１２に転送する処理を行う、なお、トランザクション
単位にローカルログバッファを持つようにし、コミット
時にセーフログ域１２に一括転送するようにしてもよい
。(a) In record addition by the record addition database access unit 11,
As shown in FIG. 3 (a), the target records are transferred to the safe log area 12. Note that it is also possible to have a local log buffer for each transaction and transfer them all at once to the safe log area 12 at the time of commit. good.
（ｂ） レコード更新データベースアクセス部１１によるレコード更新では、
第３図（ロ）に示すように、更新対象のレコードがボラ
タイルバッファ域１４上にあるか否かを調べ、ボラタイ
ルバッファ域１４上にあれば、そのレコードを更新する
。ボラタイルバッファ域１４上になければ５通常のデー
タベースアクセスにより、データベースバッファ（第１
図に示すバッファプール１６）上でのレコードの更新を
行う。(b) Record update In record update by the database access unit 11,
As shown in FIG. 3(B), it is checked whether the record to be updated is on the volatile buffer area 14, and if it is on the volatile buffer area 14, the record is updated. If it is not on the volatile buffer area 14, the database buffer (first
Records are updated on the buffer pool 16) shown in the figure.
（Ｃ） レコード検索データベースアクセス部１工によるレコード検索では、
第３図（ハ）に示すように、従来と同様にデータベース
バッファ経由のレコード検索処理を行う、検索対象が見
つかったならば、それを提示する。検索対象が見つから
なかった場合、さらにボラタイルバッファ域１４上のレ
コードを検索する。(C) Record search by the record search database access department 1
As shown in FIG. 3(c), record search processing via the database buffer is performed as in the conventional case, and if a search target is found, it is presented. If the search target is not found, records on the volatile buffer area 14 are further searched.
同 レコード削除データベースアクセス部１１によるレコード削除では、
第４図（イ）に示ｔように、ボラタイルバッファ域１４
上に対象レコードがあるか否かを調べ、ボラタイルバッ
ファ域１４上にあれば、そのレコードを削除する。そう
でなければ１通常の格納構造の場合と同様にデータベー
スバッファ上でのレコードの削除を行う。In record deletion by the record deletion database access unit 11,
As shown in FIG. 4(a), the volatile buffer area 14
It is checked whether there is a target record on the volatile buffer area 14, and if it is on the volatile buffer area 14, that record is deleted. Otherwise, the record is deleted from the database buffer as in the case of a normal storage structure.
（ｅ） コミシトコミット処理は、それまでのトランザクションによるデ
ータ操作をすべて有効化する処理である。(e) The commit process is a process that validates all data operations performed by transactions up to that point.
この処理では、第４図（ロ）に示すように、セーフログ
域１２に採取したログの安定化処理を行う。In this process, as shown in FIG. 4(b), the logs collected in the safe log area 12 are stabilized.
具体的には、コミットログを出力し、それ以前のコミッ
ト対象のログを明確化する０本実施例では。Specifically, in this embodiment, a commit log is output and the previous commit target log is clarified.
セーフログ域１２は不揮発メモリで構成されているが、
セーフログ域１２が揮発性の場合、この安定化処理で、
不揮発化の処理を行う、その後、トランザクション終了
処理を行う、この終了処理では、必要に応して１本処理
方式によらない通常の方式でアクセスしたデータベース
レコードに対するアンロック処理等を行う。The safe log area 12 is composed of non-volatile memory,
If the safelog area 12 is volatile, this stabilization process will
Non-volatization processing is performed, and then transaction termination processing is performed. In this termination processing, unlocking processing is performed for database records accessed by a normal method other than the one-line processing method, as necessary.
（ｆ） ロールバックロールバック処理は、それまでのトランザクションによ
るデータ掻作をすべて無効化する処理である。この処理
では、第４図（ハ）に示すように。(f) Rollback Rollback processing is processing that invalidates all data manipulation by previous transactions. In this process, as shown in FIG. 4(c).
セーフログ域１２に採取したログの無効化処理を行う、
具体的には、ロールバックログを出力し。Performs invalidation processing of logs collected in safe log area 12,
Specifically, output the rollback log.
それ以前の更新後イメージのログが無効であることを明
確化する。または更新後イメージのログを削除する。さ
らに２本処理方式によらない通常のデータベースに対す
る更新などを行っていた場合には、それらのデータベー
スバッファ更新の無効化処理を行い、必要に応じてその
アンロック処理を行う。Clarify that logging for earlier post-update images is invalid. Or delete the post-update image log. Furthermore, if updates have been made to a normal database that is not based on the two-processing method, those database buffer updates are invalidated, and if necessary, unlocked.
第１図に示すコミットレコード収集部１３はコミット済
みレコードの収集を行う、セーフログ域１２には１本処
理方式による追加レコード以外のためのログも含まれて
いる。また、ロールバックによって無効化されたログが
含まれていることもある。そこで、それらのログの中か
ら、コミット済みになっている本処理方式による追加レ
コードのみを収集する。The commit record collection unit 13 shown in FIG. 1 collects committed records. The safe log area 12 also includes logs for records other than those added by the one-line processing method. It may also include logs that were invalidated by rollback. Therefore, from those logs, only records added by this processing method that have been committed are collected.
その処理のため、コミットレコード収集部１３は、第５
図に示す処理■〜■を行う。For this process, the commit record collection unit 13
Perform the processes ① to ② shown in the figure.
■ まず、セーフログ域１２から、それまでのログレコ
ードを取り出す。■ First, extract the log records up to that point from the safe log area 12.
■ 取り出した各ログレコードについて、それが本処理
方式による追加レコードであって、コミット済みになっ
ているものかどうかを判定する。■ For each retrieved log record, determine whether it is an additional record by this processing method and has been committed.
そうでない場合には、処理を終了する。If not, the process ends.
■ 本処理方式による追加レコードであって、コミット
済みになっているものを、ボラタイルバッファ域１４に
詰めて格納する。(2) Fill and store committed records added by this processing method in the volatile buffer area 14.
■ サロゲートマップ１９から空きエントリを確保し、
その番号をレコードの識別情報とするとともに、ボラタ
イルバッファ域１４の格納アドレスをサロゲートマンブ
１９に設定する。■ Secure a free entry from surrogate map 19,
The number is used as record identification information, and the storage address of the volatile buffer area 14 is set in the surrogate manbu 19.
■ コミット済みになっているレコードが、インデック
ス部２０で扱う対象になっている場合には、インデック
ス部２０を更新し、インデックス部２０にレコードの識
別情報を設定する。これらを対象となっている全ログに
ついて行ったならば、処理を終了する。(2) If a committed record is to be handled by the index section 20, the index section 20 is updated and the identification information of the record is set in the index section 20. Once these steps have been performed for all target logs, the process ends.
第１図に示すバッファ制御部１５は２通常のデータベー
スアクセスにおけるバッファブール１６を利用したデー
タベースページの読み込み、書き出し以外に、第６図に
示す処理を行う。The buffer control unit 15 shown in FIG. 1 performs the processing shown in FIG. 6 in addition to reading and writing database pages using the buffer boolean 16 in normal database access.
すなわち、バッファ制御部１５は、トランザクションの
処理とは非同期に、レコードの詰まったボラタイルバッ
ファ域１４を、データベース格納域１８−１または１８
−２に書き出す、そしてサロゲートマップ１９における
該当するレコードの物理的な格納位置情報を書き換える
。レコード識別情報の変更はないので、ボラタイルバッ
ファ域１４の書き出しによるインデックス部２０の更新
は不要である。That is, the buffer control unit 15 transfers the volatile buffer area 14 filled with records to the database storage area 18-1 or 18-1 asynchronously with transaction processing.
-2, and the physical storage position information of the corresponding record in the surrogate map 19 is rewritten. Since there is no change in the record identification information, there is no need to update the index section 20 by writing out the volatile buffer area 14.
再構成処理部１７は、システムの負荷が低下したとき２
またはシステム管理者によって任意のときに起動され、
第７図■〜■に示すデータベースの再構成を行う。The reconfiguration processing unit 17 performs 2 when the system load decreases.
or launched at any time by the system administrator,
The database shown in FIGS. 7 - 7 is reconfigured.
■ カレントとなっているデータベース格納域１８−１
，１８−２の一方から、レコードを順に取り出す。■ Current database storage area 18-1
, 18-2.
■ 取り出したレコードが削除レコードであれば。■ If the retrieved record is a deleted record.
それを廃棄し、有効なレコードについて、他方のデータ
ベース格納域１８−２または１８−１上の格納位置を決
定し、レコードを格納する。It discards it, determines the storage position of the valid record on the other database storage area 18-2 or 18-1, and stores the record.
■ レコードの物理的な格納位置が変わるのでサロゲー
トマップ１９の該当するエントリの内容を書き換える。■ Since the physical storage location of the record changes, the contents of the corresponding entry in the surrogate map 19 are rewritten.
第８図は、この再構成処理の具体例を示している。FIG. 8 shows a specific example of this reconfiguration process.
データベースの格納域は２例えば第８図に示すように、
データベース格納域１８−１とデータベース格納域１８
−２の２つの領域からなる。サロゲートマップ１９は、
データベース格納域１８−１または１８−２上のレコー
ドの物理的な格納位置およびボラタイルバッファ域１４
上の格納アドレスを指している。The storage area of the database is 2. For example, as shown in Figure 8,
Database storage area 18-1 and database storage area 18
It consists of two areas: -2. Surrogate map 19 is
Physical storage location of records on database storage area 18-1 or 18-2 and volatile buffer area 14
It points to the storage address above.
インデックス部２０は、レコードの物理的な格納位置の
情報を持つのではなく、サロゲートマップ１９における
エントリ番号を、レコード識別情報として持つ。すなわ
ち、インデックスとなる各キーｋｅｙｌ、ｋｅｙ２．・
・・に対応して、サロゲートマップ１９上のエントリ番
号１５．Ｉｌｌ、・・・を保持する。The index unit 20 does not have information about the physical storage position of a record, but has an entry number in the surrogate map 19 as record identification information. That is, each key keyl, key2 .・
. . , entry number 15 on the surrogate map 19. Ill, . . . are retained.
再構成処理部１７による再構成は、第８図に示すように
、データベース格納域１８−１から順番にレコードを取
り出し、有効なレコードＲ１，Ｒ２、・・・だけをデー
タベース格納域１８−２に設定する処理である。データ
ベース格納域１８−１からデータベース格納域１８−２
へレコードを移したならば、サロゲートマップ１９の内
容を１点線の矢印で示すように更新する。As shown in FIG. 8, the reconstruction processing unit 17 extracts records in order from the database storage area 18-1 and stores only valid records R1, R2, . . . in the database storage area 18-2. This is the process to set. From database storage area 18-1 to database storage area 18-2
After moving the record to , the contents of the surrogate map 19 are updated as shown by the one-dot arrow.
データベース格納域１８−１からのレコードの転記が終
了したならば２次はデータベース格納域１８−２からデ
ータベース格納域１８−１に対するレコードの転記を行
う。When the transcription of the record from the database storage area 18-1 is completed, the record is secondary transferred from the database storage area 18-2 to the database storage area 18-1.
以上のようにエントリデータの収集を専門的に扱うデー
タ構造を想定することにより２次のような処理に適した
構造とすることができる。As described above, by assuming a data structure that specializes in collecting entry data, it is possible to create a structure that is suitable for secondary processing.
（ａ） ヒストリカルにオーダエントリのような伝票
の収集を行う。(a) Historically collect slips such as order entries.
（ｂ） 必要に応じて、収集データをインデックス等
でアクセスができるようにカテゴリ分けする。(b) If necessary, categorize the collected data so that it can be accessed using indexes, etc.
（Ｃ） 時系列に沿った集信データの一括処理を行う
。(C) Perform batch processing of received data in chronological order.
（ロ）処理済みデータは、原則的には削除される。(b) In principle, processed data will be deleted.
なお１以上の実施例では、ボラタイルバッファ域１４に
収集されたコミット済みのレコードを。In one or more embodiments, the committed records collected in the volatile buffer area 14.
他のトランザクションから参照可能としたが、ボラタイ
ルバッファ域１４を単なるＩ１０バッファ的な扱いとし
、データベース格納域１８−１，１８−２に反映された
レコードのみをディスクロージャするようにしてもよい
、実際のオーダエントリ型の適用業務を考えた場合、コ
ミット済みレコードは、必ずすぐに参照できなければな
らないといった要請は少ないからである。Although it can be referenced from other transactions, the volatile buffer area 14 may be treated as a mere I10 buffer and only the records reflected in the database storage areas 18-1 and 18-2 may be disclosed. This is because when considering order entry type applications, there is little requirement that committed records must be immediately accessible.
コミット順保証が必要であれば、コミット済みレコード
の収集時にコミットログを参照しながら並べ換えを行う
ことなどにより、保証することが可能である。If it is necessary to guarantee the commit order, it can be guaranteed by sorting the committed records while referring to the commit log when collecting committed records.
また、ユニークなキーを扱わなく、かつ参照整合性を必
ずしも保証しなくてもよい適用業務では。Also, in applications that do not handle unique keys and do not necessarily need to guarantee referential integrity.
サロゲートマップ１９を持たなくてもよい。この場合、
データベース格納域１８−１，１８−２におけるある位
置から全レコードをアクセスし、必要なレコードのみを
処理（参照／更新／削除）するような格納構造として使
用する。It is not necessary to have the surrogate map 19. in this case,
It is used as a storage structure in which all records are accessed from a certain position in the database storage areas 18-1 and 18-2 and only necessary records are processed (referenced/updated/deleted).
以上説明したように２本発明によれば、オーダエントリ
型のデータ蓄積処理に適したデータベースの格納構造を
実現することができ、データ収集トランザクションの高
度な同時並行動作が可能になる。また、インデックスに
よる収集データのアトホックな訂正、蓄積データの一括
処理、処理済みデータの削除などを、データ収集トラン
ザクションと並行して処理することができるようになる
。As described above, according to the two aspects of the present invention, it is possible to realize a database storage structure suitable for order entry type data accumulation processing, and it is possible to perform highly concurrent data collection transactions. Additionally, it becomes possible to perform ad-hoc correction of collected data using indexes, batch processing of accumulated data, deletion of processed data, etc. in parallel with data collection transactions.
この結果、アプリケーションの開発負担が大幅に削減さ
れ、システムの運用も不必要な制限がなくなるので、容
易に行うことができるようになる。As a result, the burden of application development is significantly reduced, and unnecessary restrictions are removed from system operation, making it easier to operate the system.
第１図は本発明の原理説明図。第２図は本発明の一実施例による動作例、第３図および
第４図は本発明の一実施例に係るデータベースアクセス
部の処理フロー第５図は本発明の一実施例によるコミットレコード収集
部の処理フロー第６図は本発明の一実施例によるバッファ制御部の処理
フロー第７図は本発明の一実施例に係る再構成処理部の処理フ
ロー第８図は本発明の一実施例による再構成処理説明図。第９図は従来技術の例を示す。図中、１０は応用処理部、１１はデータベースアクセス
部、１２はセーフログ域、１３はコミットレコード収集
部、１４はボラタイルバッファ域。１５はバッファ制御部、１６はバッファプール。１７は再構成処理部、１８−，１，１８−２はデータベ
ース格納域、１９はサロゲートマ・ンプ、２０はインデ
ックス部を表す。FIG. 1 is a diagram explaining the principle of the present invention. FIG. 2 is an example of operation according to an embodiment of the present invention, and FIGS. 3 and 4 are processing flows of the database access unit according to an embodiment of the present invention. FIG. 5 is commit record collection according to an embodiment of the present invention. FIG. 6 is a processing flow of the buffer control section according to an embodiment of the present invention. FIG. 7 is a processing flow of the reconfiguration processing section according to an embodiment of the present invention. FIG. 8 is a processing flow of the reconfiguration processing section according to an embodiment of the present invention. An explanatory diagram of reconstruction processing by. FIG. 9 shows an example of the prior art. In the figure, 10 is an application processing section, 11 is a database access section, 12 is a safe log area, 13 is a commit record collection section, and 14 is a volatile buffer area. 15 is a buffer control unit, and 16 is a buffer pool. 17 represents a reconstruction processing section; 18-, 1, and 18-2 represent database storage areas; 19 represents a surrogate map; and 20 represents an index section.
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2124627AJP2503289B2 (en) | 1990-05-15 | 1990-05-15 | Database management processing method |
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2124627AJP2503289B2 (en) | 1990-05-15 | 1990-05-15 | Database management processing method |
| Publication Number | Publication Date |
|---|---|
| JPH0424750Atrue JPH0424750A (en) | 1992-01-28 |
| JP2503289B2 JP2503289B2 (en) | 1996-06-05 |
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2124627AExpired - Fee RelatedJP2503289B2 (en) | 1990-05-15 | 1990-05-15 | Database management processing method |
| Country | Link |
|---|---|
| JP (1) | JP2503289B2 (en) |
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1993003436A1 (en)* | 1991-08-06 | 1993-02-18 | Fujitsu Limited | Method and apparatus for reducing lock period of shared buffer |
| JPH08179978A (en)* | 1994-12-27 | 1996-07-12 | Nec Software Ltd | Master data management system |
| US5715447A (en)* | 1991-08-06 | 1998-02-03 | Fujitsu Limited | Method of and an apparatus for shortening a lock period of a shared buffer |
| US5956719A (en)* | 1996-03-29 | 1999-09-21 | Fujitsu Limited | Synchronization method applied to databases in network management system |
| JP2014532919A (en)* | 2011-10-26 | 2014-12-08 | エヌイーシー ラボラトリーズ アメリカ インクＮＥＣ Ｌａｂｏｒａｔｏｒｉｅｓ Ａｍｅｒｉｃａ， Ｉｎｃ． | Online transaction processing |
| WO2020194403A1 (en) | 2019-03-22 | 2020-10-01 | 富士通株式会社 | Information processing program, information processing method, and information processing device |
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| WO1993003436A1 (en)* | 1991-08-06 | 1993-02-18 | Fujitsu Limited | Method and apparatus for reducing lock period of shared buffer |
| US5715447A (en)* | 1991-08-06 | 1998-02-03 | Fujitsu Limited | Method of and an apparatus for shortening a lock period of a shared buffer |
| JPH08179978A (en)* | 1994-12-27 | 1996-07-12 | Nec Software Ltd | Master data management system |
| US5956719A (en)* | 1996-03-29 | 1999-09-21 | Fujitsu Limited | Synchronization method applied to databases in network management system |
| JP2014532919A (en)* | 2011-10-26 | 2014-12-08 | エヌイーシー ラボラトリーズ アメリカ インクＮＥＣ Ｌａｂｏｒａｔｏｒｉｅｓ Ａｍｅｒｉｃａ， Ｉｎｃ． | Online transaction processing |
| WO2020194403A1 (en) | 2019-03-22 | 2020-10-01 | 富士通株式会社 | Information processing program, information processing method, and information processing device |
| Publication number | Publication date |
|---|---|
| JP2503289B2 (en) | 1996-06-05 |
| Publication | Publication Date | Title |
|---|---|---|
| US20210042286A1 (en) | Transactional key-value store | |
| EP3418883B1 (en) | Apparatus and method for read optimized bulk data storage | |
| US5276835A (en) | Non-blocking serialization for caching data in a shared cache | |
| EP0351387B1 (en) | Minimizing locking and reading in a segmented storage space | |
| KR920000395B1 (en) | How to Fetch and Insert and Delete Key Record Data | |
| US9305046B2 (en) | Compressing a multi-version database | |
| JP2505040B2 (en) | Data access method and data processing system for parallel access to index tree | |
| Mohan et al. | ARIES/CSA: A method for database recovery in client-server architectures | |
| US20170351543A1 (en) | Heap data structure | |
| EP0501160A2 (en) | Intelligent page store for concurrent and consistent access to a database by a transaction processor and a query processor | |
| EP0490525A2 (en) | Removal of data from a shared cache | |
| JP2007501468A (en) | Database management system with efficient version control | |
| JPH056297A (en) | Method of transaction processing and system | |
| JP2001101044A (en) | Transactional file management method, transactional file system, and composite transactional file system | |
| Dong et al. | Optimistic transaction processing in deterministic database | |
| CN101080715B (en) | System and method for managing binary large objects | |
| JPH0424750A (en) | Database management processing method | |
| JP4306023B2 (en) | Storage method and apparatus for transaction processing, transactional storage | |
| WO1993003436A1 (en) | Method and apparatus for reducing lock period of shared buffer | |
| JPS62162136A (en) | Simultaneous-updating control system for file with indices in hierarchy structure | |
| JP3450154B2 (en) | File access processing system | |
| JP2721034B2 (en) | Clustering control system | |
| JP2980610B2 (en) | Transaction management device | |
| JPH04155548A (en) | Log management/recovery processing method | |
| Jaluta | Index cache consistency in client-server database systems |
| Date | Code | Title | Description |
|---|---|---|---|
| FPAY | Renewal fee payment (event date is renewal date of database) | Free format text:PAYMENT UNTIL: 20080402 Year of fee payment:12 | |
| FPAY | Renewal fee payment (event date is renewal date of database) | Free format text:PAYMENT UNTIL: 20090402 Year of fee payment:13 | |
| LAPS | Cancellation because of no payment of annual fees |