JPH0395645A - Control system for decentralized data base - Google Patents

Abstract

PURPOSE:To improve the parallelism of transaction operations and at the same time to increase the processing speed by releasing the lock of a table as soon as possible by making use of the update/reference history information on an update/reference history information store table. CONSTITUTION:A lock manager 4 accepts a lock request and lock the corresponding area by reference to a lock table 5 and carries on a transaction to which the lock request is granted. In this case, a specific part of the data item locked by the transaction and its operating way are recorded into an update/ reference history information table. Then this table is stored in an update/ reference history information store device 6. While the lock is released before execution of a comitting operation for the items to which no reference/update of a data base 2 are not actually carried out during the execution of the transaction out of a data base table which is locked based on the information on the update/reference history information store table. Thus it is possible to improve the parallelism of transaction operations and also to increase the processing speed.

Description

DETAILED DESCRIPTION OF THE INVENTION [Object of the Invention] (Industrial Application Field) The present invention relates to a distributed database management method for a network system in which computer sites equipped with databases are connected to each other via communication lines.

(Prior art) In distributed database systems, such as online systems of financial institutions and ticketing operations, in which multiple computer sites are connected to each other via communication lines, each site has a database that is connected to other sites. Updates, references,
Additions and deletions occur frequently.

In this case, access requests often concentrate on one database. Therefore, locking is performed to maintain data consistency. A locked state means that one transaction prohibits access from other transactions until the transaction ends. The database consists of 5 octable parts called items, and the size of the 100 items can be selected by the system designer. For example, in the relation model, the relation itself can be an item. It is also possible to select individual tuples or items that make up the tuples. However, the size of an item affects the overhead for managing it and the degree of parallelism of transactions.

Large units of locks, such as locks on entire transactions or on multiple tuples, reduce the overhead of the lock management system, but the probability of lock collisions is high, and many transactions are parallel at the same time. It becomes difficult to function properly.

On the other hand, commitment control is performed to maintain atomicity of transaction processing. This ensures that when a transaction updates multiple pieces of data, all or none of the data is updated. A specific example is shown in FIG. Database DBSl to be updated from site S where transaction A occurs
, DBSn. At each site, it is stored in a log and Precorrmitte
d returns a signal to site S, and if signals from all update sites are returned, a commit is performed. Here, a lock on updated data is placed on the updated data after transaction A starts, and release of the lock is delayed until 1 after commit. Therefore, in the case of updating to n sites, it is necessary to perform 4n communications in the lock release trench. This indicates that it may take a considerable amount of time to release 1 after locking.

(Problem to be Solved by the Invention) In the conventional distributed database management system, as described above, there is a possibility that a large number of transactions occur and accesses to the data collide, resulting in a large number of waiting transactions. In the worst case, it may lead to deadlock.

Also, due to commitment control, especially in the case of transactions involving updates to multiple sites, it takes a considerable amount of time to release the lock after locking. There is a problem in that these things consume a lot of CPU processing time and put a damper on high-speed processing.

Therefore, the present invention provides a distributed database management method that improves the parallelism of transaction operations and enables high-speed processing by releasing locks on tables as quickly as possible using table update/reference history information. The goal is to earn money.

[Structure of the invention]

(Means for Solving the Problems) The present invention solves the above problems by using a distributed database management method for a network system in which computer sites equipped with databases are connected to each other via communication lines, and each site has a table. Lock tiir@'fI for
: A lock table to store, a lock manager to manage the lock table f'W, an update/reference history information storage device to store history information of update/reference requests for the locked table, and history information of update/reference requests. A lock table operation manager is provided to perform lock release changes using .

(Operation) In the distributed database management system of the present invention, when the lock manager receives a lock request, it refers to the lock table and locks the corresponding location. The transaction that passed the lock request continues its casing 1 transaction.

At this time, update which part of the data items locked by the above transaction was manipulated and how.
It is recorded in the reference history information storage table and stored in this table update/reference history information storage device. According to the information in this update/reference history information storage table, even among locked database tables, items for which no database reference or update operations were actually performed during a transaction are subject to commit operations. Release the lock without waiting.

(Example) Embodiments of the present invention will be described below with reference to the drawings.

Referring to FIG. 1, a plurality of computer sizes A, B, and C forming part of a network system are connected via communication lines.

The system A has a general CPU 1 as its main body, and is connected to a database 2, a communication means 3, a lock manager 4, a lock table 5, and an update/reference history information storage means 6. The same applies to the other sizes}B and C.

Update●Reference history information storage 6 is the update/reference history information storage stage 6 shown in Figure 2.
It has a reference history information storage table. The update ● reference history information storage table in FIG. 2 has a history of locks placed on the database and how the database was manipulated in transactions. In this case, FIG. 2 is an update/reference history information storage table for the relational database of FIG. 3. Figure 3 shows a part of the relational database, which has the attribute xl,
It has data such as A, B, C, etc. Figure 2 shows 3 columns corresponding to attribute X in Figure 3, and each item has an update/reference B.
Historical information can be stored. Figure 2(a)
, (b) The areas surrounded by large frames represent the locations where a certain transaction has locked the database.

This will be explained in detail. In M2 diagram (a), a lock is placed on Fi from data B of b1 attribute X by a certain transaction, but the actual operations are an update operation on data C and a reference operation on data D. Indicates that If the transaction's operations on the database are as shown in Figure 2(a), the lock manager 4 performs the operations shown in Figure 2(a) before committing this transaction.
The locked state shown in FIG. 2(b) is changed from the locked state shown in FIG.

The locks held on data B, E, and F in FIG. 2(a) are released. This allows other transactions to access the database without waiting for the first transaction to commit.

This will be explained in detail using the flowchart in FIG. When a transaction 1 execution request is accepted at a certain site A (401), execution of transaction 1 is started (402). For example, in the case of transaction 1, if an operation is performed on the database and the scheduler expects that attribute X will be accessed among them, the lock manager will execute the
A lock is placed on attribute X (403). Since transaction l has acquired a lock on attribute X of database R, it actually accesses it (404) and stores the data operation contents in the update/reference history information storage table as shown in FIG. 2(a) (405). At the same time as the data manipulation for transaction 7=rxl is completed, check the data storage table for analysis and reference history information, and release the lock for items other than the smallest unit of data operations such as update and reference (406). . Meanwhile, the transaction manager accepts other transactions (407). On the other hand, the updated/referenced items are committed (408).

The method of changing the lock will be described in detail using FIG. Ronok manages the rock table full shown in Figure 5. In the lock table, each entry in the same formal format as table R corresponds to an entry in the table. The lock table is unique to the database and is referenced by all transactions requesting access, and when locked, other transactions cannot access the item. On lock tables, flags are raised on locked items. FIG. 5 shows the locked state in this example, which is a lock from data B to F1. To change the lock contents in 406 of FIG. 4, each record is compared using the lock table and the update/reference/history information storage table, and data update/reference operations are performed in the update/reference history information storage table. For records that have been touched, the flag is in box 1, and for records that have not been touched, the flag is removed. This allows you to change the lock state.

In this example, it is possible to release the lock quickly, which increases the parallelism of transactions and enables efficient transaction processing.

The invention is not limited to the embodiments described above.

For example, the unit of locking can be modified in various ways, and is not limited to the block unit, which is a set of a plurality of records in this embodiment, but may also be a relay unit, a table unit, etc.

Various methods can be considered for unlocking the lock. Second
In the diagram, from (a) to (b), update ●Referenced attribute
Although the locks on data other than data C and D have been released, for example, it is also possible to continue locking data E with commit operation 1.

However, the present invention may be modified and implemented as appropriate without departing from the gist thereof.

〔Effect of the invention〕

As explained above, according to the present invention, even if a lock is placed, if an operation such as update or reference is not actually performed on the database, by releasing the lock before committing, It is possible to operate in parallel with other transactions, improve parallelism in distributed databases, and realize efficient database processing.
It becomes possible to realize a distributed database system that can have great practical effects.

[Brief explanation of drawings]

Fig. 1 is a block explanatory diagram showing the structure of a distributed database management system according to an embodiment of the present invention, and Fig. 2 is an update/reference history information storage table stored in the update/reference history information storage means. 3 is a diagram showing an example of the database in this embodiment, FIG. 4 is a flowchart showing the processing method of the present invention, FIG. 5 is a diagram showing the lock table in this embodiment, and FIG. 6 is a diagram showing a two-phase commit procedure. 1... CPU 2... Database 3... Communication means 4... Lock manager 5... Lock table 6... Update/reference history information storage device

Claims (1)

[Claims] In a distributed database management system that is a network system in which computer sites equipped with databases are connected to each other via communication lines, each site has a lock table that stores lock information for tables and a history of update/reference requests for lock information. A distributed database management method comprising: an update/reference history information storage means for storing information; and a lock manager that performs lock release changes using update/reference request history information.