JPH0816881B2 - Database update method - Google Patents

Description

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a transaction database updating method in a database system, and more particularly to data recovery when a system failure such as power failure occurs. And method for updating a database with logical consistency of the database by recovery of the database.

[Conventional technology]

In a database system, when a system failure such as a power failure or a transaction failure due to a program error or the like occurs, logical consistency of the database must be maintained. Especially regarding the database update result by the transaction that has not been executed at the time of failure,
You have to disable this.

As a conventional technique for this purpose, when the transaction updates the database, a method is known in which the update result is stored in a new place different from the place where the information before the update is stored. Database Systems, Volume 2, Issue 1 (1977),
Pages 91 to 104 (ACM Trans.Database Syst., Vol.2,
No. 1 (1977), pp. 91-104). This method is called the Shadow page method, and all the database updates are written to a new storage location by the time transaction execution is completed, and the pre-update information is invalid and the post-update information is valid when the transaction execution is completed. . Summarizing the features of the shear page method, the following (1)-
It becomes (4).

(1) A database is composed of pages that are units of logical areas, and pages that represent the correspondence between pages and slots that are storage locations of pages on the database storage medium.
There are two tables, the current version and the backup version. All of these are stored on a non-volatile medium such as a disk. Normally, the page table itself is also divided into a plurality of blocks, and the transfer between the main storage device and the non-volatile medium is performed in block units.

(2) A new slot that stores the updated contents of the updated page when the database is updated by the transaction is called the current page slot, and the correspondence with the page is held in the current version page table. . On the other hand, the slot storing the contents of the page before the update is called a shy-do page slot, and the correspondence with the page is held in the backup version page table.

(3) When the transaction is completed, the updated version information stored in the current page slot is validated by validating the current version page table. Specifically, the status bit on the non-volatile medium indicating which page table of the current version and the backup version is valid is changed.

(4) If a system / transaction failure occurs during transaction execution, the status bit shows that the backup version page table is valid.
That is, the pre-update information stored in the shed page page slot shown in the backup version page table is valid.

Therefore, even if a system / transaction failure occurs, the logical consistency of the database can be maintained, and acquisition of the database update history information is unnecessary.

[Problems to be solved by the invention]

There are the following three problems in the prior art in the shear page method.

First, multiple transactions share the database at the same time and cannot be updated. The reason for this is that the current version page /
This is because the validation of the table is collectively performed by changing the status bit, and therefore, the page table concerned should not include information about the page being updated by another transaction being executed.

Second, it is difficult to synchronize the validation of the database update result with the validation of the update result of the message transmitted to the terminal or the system management information on the main storage device. The transaction usually involves not only database updating but also message transmission / reception and system management information updating. However, the status bit changes in the prior art relate only to database updates. Therefore, when a system failure occurs, depending on the timing, only the database update result may be valid, or conversely, only the message or the system management information update result may be valid.

Third, it is necessary to update the page table and status bit on the non-volatile medium for each transaction, and this update overhead contributes to the deterioration of system performance.

Due to the first and second problems, under the actual system environment in which multiple online transactions share and update the database at the same time, the database update history information is not used instead of the shadow page method described above. The Shado page method combined with the method of acquiring is used. However, with this method, there is a large overhead in acquiring the database update information, and in addition to the above-mentioned third problem, there is a possibility that the processing efficiency of the system may decrease.

It is an object of the present invention to provide a database updating method that enables simultaneous updating of a database by a plurality of transactions without reducing processing efficiency in a database system using the shadow page method.

[Means for solving problems]

In order to achieve the above object, a database system according to the present invention is a database including a page which is a logical storage location of data, and a database storage in which the latest contents of each page of the database are stored. Records the current version page table for registering the correspondence information with the slots on the medium, the current version slot usage map indicating whether each slot on the database storage medium is used, and the past contents of the current version page table A plurality of backup version page tables and a history file that records history information regarding transaction processing. When the transaction being executed updates the database, the contents of the updated page are stored in the empty slot found based on the current version slot usage map. Then, the correspondence information between the page and the empty slot is registered in the current version page table, and the information about the empty slot in the current version slot usage map is updated. Further, a history record showing the contents of change in the current version page table is acquired in the history file. Further, the backup version page table is periodically updated so that the contents match the current version page table. Then, when a system failure occurs, the current version page table is restored based on the history record indicating the changed contents of the current version page table recorded in the history file and the backup version page table.

Further in such a database system,
In order to synchronize the validation of the database update result with the update result of the message sent to the terminal or the system management information in the memory, it is desirable in the present invention that the transaction being executed transmits or receives the terminal message or is stored in the memory. When updating the system management information, a history record indicating the contents thereof is acquired in the history file, and when the execution of the transaction is completed, a history record indicating the completion of execution of the transaction is acquired in the history file. When a system failure occurs, in the step of recovering the current version page table, the history record indicating the completion of transaction processing is reflected in the database only by the database update by the transaction acquired in the history file. In addition to recovering the current version page table, a message transmitted to the terminal and system management information in the memory are recovered by a known method.

[Action]

Since multiple history records indicating the updated contents of the current version page table and history records indicating the completion of transaction processing are acquired in the history file and the database is recovered using these history records in the event of a system failure, multiple transactions can be executed in the database. Even when updating at the same time, the database update result of a transaction can be validated independently of other transactions. Further, when the database is updated, the database update history record is not acquired in the history file, but the history record indicating the update contents of the current version page table having a small amount of data is acquired in the history file.

Also, the backup version page table is not updated every time the contents of the current version page table are changed, but the backup version page table is updated collectively in a batch, so the update overhead of the backup version page table is small. Therefore, the processing efficiency of the system is not reduced.

In addition, since recovery processing is performed using the history record in the history file when a system failure occurs, it is possible to synchronize the validation of the database update result with the message sent to the terminal or the update result of the system management information in memory. it can.

〔Example〕

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

First, the configuration and operation of the first embodiment will be described. FIG. 1 is a diagram showing the configuration of the first embodiment and is a diagram showing the features of the present invention. In FIG. 1, a database storage medium 50 such as a magnetic disk, a back-up version page table 80, and a back-up version slot-using map.
A nonvolatile storage medium 100 for storing database control information such as 90 and a magnetic disk (or magnetic tape) which is a medium of the history file 70 are connected to the CPU / memory 10. Database area 60 on database storage medium 50
Is divided into fixed-length blocks called slots. On the other hand, the logical space of the database referenced and updated by the transaction is divided into fixed sections called pages. The slot is for storing the contents of the page, and the sizes of both are the same (for example, 4096 bytes). Each slot can be referenced and updated with one input / output operation. Figure 2 shows the backup version page table 80.
FIG. 3 is a diagram for explaining a back-up plate slot use map 90. The backup version page table 80 is updated at the checkpoint, and the contents of the current version page table 30 at that time are reflected. That is, in the backup version page table 80, the slot number which is the storage location in the database area 60 of the latest contents of each page at the time of the first check point is set. In addition, the back-up version slot-using map 90 is
Similar to the backup version page table 80, it is a bit map that is updated at the check point and indicates that each slot in the database area 60 based on the current version page table 30 is not used. That is, the back-up version slot use map 90 is set to 1 for the slot storing the latest contents of each page at the latest check point, and set to 0 for the other slots. The back-up version page table 80 and the back-up version slot-use map 90 are each composed of a plurality of fixed length blocks (512 bytes, for example) 81 and 91, and each block can be referenced / updated by one input / output operation. Is possible. If a failure occurs while writing the backup page table 80, the logical consistency of the database cannot be guaranteed. To solve this problem, the backup page table 80 is duplicated, and after the first write operation is completed normally, writing to the other is continued. If the first write operation is abnormally terminated, the other backup page table It is possible to guarantee the logical consistency of the database by performing recovery processing as an ordinary system failure using. Therefore, hereinafter, in the present embodiment, it is assumed that the write operation to the backup version page table 80 is normally completed.
The backup version page table 80 and the backup version slot use map 90 may be placed on the database storage medium 50. Next, FIG. 3 shows the current version page table 30 and the map using the current version slot.
It is a figure explaining 40. During the system operation, these database control information exists in the memory 10. The current version page table 30 is updated when the database is updated by the transaction, and the slot number of the database area 60 in which the updated content of the updated page is stored is set. That is, the current version page table 30 is set with the slot number in which the latest contents of each page of the database at each point in time during system operation are stored. Further, the current version page table 30 is composed of a plurality of fixed length logical blocks 31 corresponding to the backup version page table 80. In the following embodiments, the memory 10 can store the entire current version page table 30. Otherwise, the blocks of the current version page table 30 excluding the block containing the entry for the page updated by the transaction being executed are stored in a storage device (volatile memory) other than the memory (main storage device) using the LRU algorithm or the like. The entire current version page table 30 may be stored in the memory 10 by writing it to the memory 10. On the other hand, the current version slot use map 40 is updated at the time of updating the database by the transaction and at the completion of the execution of the transaction, and indicates whether or not each slot in the database area 60 is used at each time of the system. The current version slot-use map 40 is composed of a plurality of fixed-length logical blocks 41 corresponding to the back-up version slot-use map 90. Unlike the back-up version slot-using map 90,
In the current version of slot use map 40, not only the slot that stores the latest contents of each page of the database but also the slot that stores the contents before the update of the page updated by the transaction that is being executed (shutter slot Call 61) is also in use. For a block containing an entry corresponding to a shed slot, in addition to a normal block 41 showing the slot usage status, there is a block 42 showing whether or not each slot is a shed slot. FIG. 4 is a diagram for explaining the history file 70. In the history file 70, various history information of the system such as the terminal message journal 73 and the system management information update journal 74 is acquired in time series in addition to the page / table update journal 71 and the transaction processing completion journal 72. The page table update journal 71 includes information such as an updated page number, a slot number in which the contents of the page before updating are stored, and a slot number in which the contents after updating of the page are stored.

Next, the system operation will be described. The system operation is divided into normal operation, checkpoint operation, system failure operation, and transaction failure operation.

(1) Normal-time operation The processes according to the present invention from the start to the end of the execution of the transaction are performed in the order of (a) to (f).

(A) Reading of the page being executed The entry of the page in the current version page table 30 is searched for the slot number storing the latest contents of the page. Then, the page is read from the obtained slot.

(B) Writing updated pages during execution FIG. 5 shows a processing flow when writing updated pages to the database area 60 on the database storage medium 50.

First, check if there is a shed slot for the page. It is possible to determine the presence / absence of a shadow slot for the page based on the information on the shadow slot accumulated in the memory 10 described later.

If there is a shadow slot for the page at, then the page has already been written to the database one or more times at the transaction. In this case, the entry of the page in the current version page table 30 is searched, and the updated content of the page is written in the obtained slot.

If there is no shadow slot for the page at, then the page is first written to the database at the transaction. In this case, the updated contents of the page are written in a new slot by the following procedure, and the original slot is changed to the shadow slot.

Search for the current slot-use map 40 and find an empty slot.

The updated content of the page is written in the above-mentioned empty slot.

The entry of the page in the current version page table 30 is updated, and the number of the new slot is set. Also,
The current version slot use map 40 is updated so that the new slot is in the use state, and the slot storing the contents before the update of the page is changed to the shear slot.

From the page number of the page, the slot storing the pre-update contents (hereinafter referred to as the pre-update slot) and the slot number storing the post-update contents (hereinafter referred to as the post-update slot), etc. The page table update history information is stored in the memory 10. Also, the presence of a shed slot and the number of the shed slot are stored in the memory 10 for the page.

(C) Writing of updated page at the time of issuing a commit instruction The above item (b) is a process executed when the database page storage area in the memory 10 overflows. This section is a process of writing all pages updated by the transaction to the database when a commit instruction indicating the completion of the process is issued from the program being executed by the transaction. The content is nothing but the execution of the processing in the previous section (b) for each page. When a system failure occurs during execution of this process, the transaction is regarded as incomplete and the database update result is not reflected in the database.

(D) Page / table update journal acquisition The page / table update history information accumulated in the memory 10 is acquired in the history file 70 as the page / table update journal 71.

The actual output to the medium is carried out together with various history information such as other terminal message journal 73 and system management information update journal 74, etc., when the transaction processing completion journal in (e) is acquired or the history information is stored in the memory 10. This is done when the area overflows.

(E) Update of current version slot map The shutter slot for the page updated by the transaction is released based on the shutter slot management information accumulated in the memory 10 in the process of (b), and the slot is made empty. Specifically, for each shed slot, search the current version slot use map 40, and turn off both the bit indicating whether or not the slot is used and the bit indicating whether or not the slot is the shed slot. .

(F) Acquisition of Transaction Processing Completion Journal When the previous item (e) is completed, the transaction processing completion journal 72 indicating that the processing of the transaction is completed is acquired in the history file 70.

As described in (d), in this processing, various history information regarding the transaction that has not been output to the medium of the history file 70 is output to the medium of the history file 70 together with the transaction processing completion journal.

(2) Operation at check point The check point is set at the following timing for the reason of shortening the time required for the recovery processing at the time of system failure.

-At the end of system start / restart processing-At the end of system-When a certain number of history information is acquired from the previous check points-Others (when media failure of history file etc.) Processing related to database among check point operations Is performed in the order of (a) and (b) below.

(A) Page / table update journal acquisition The page / table update history information accumulated in the memory 10 is acquired in the history file 70 as the page / table update journal 71 ((1) unlike normal operation (d),
Output to medium).

(B) Update of backup version page table, etc. The backup version page table 80 and the backup version slot use map 90 on the non-volatile storage medium 100 are updated to reflect the contents of the current version page table 30. For back-up version page table 80,
The contents of the current version page table 30 may be directly written out. For the back-up version slot-using map 90, the result of the exclusive OR of the block 41 of the bit map indicating whether the slot is used and the block 42 of the bottom map indicating whether the slot is used or not in the current version slot-using map 40 may be written out.

In addition, an update flag is provided for each block of the current-version page table 30 and the current-version slot-use map 40 to indicate whether or not the update has been made from the previous check point, and only the necessary blocks are back-up version pages on the non-volatile storage medium 100. By writing to the table 80 and the backup-up slot use map 90, the update amount can be reduced.

As the checkpoint information, the number (consistently given to each history information) of the last history information in the history file 70 when updating the backup version page table 80 and all the transactions being executed at the time of the checkpoint are related. The first (upper limit) number of the history information in the history information (consistent to each history information)
It is acquired in the nonvolatile storage medium 100 together with the table 80.

While the transactions (a) and (b) are being performed, the transaction may be in the execution state, but the database cannot be updated, and the transaction requesting the database update is in the waiting state.

Note that the check point information in (b) is normally acquired in a file that stores various information used in recovery processing from a system failure in a system environment in which a database, a message, system management information, or the like has a recovery target.

(3) Operation at the time of system failure The database recovery processing when a system failure such as power failure occurs is described below. The processing flow is shown in FIG.
After executing the processes of (a) to (c) below, the system reads the required page based on the current version page table 30 and starts the normal process.

(A) Reading of database control information The back-up version page table 80 and the back-up version slot-use map 90 are read from the non-volatile storage medium 100 and expanded in the memory 10 as the current version page table 30 and the current-version slot use map 40, respectively. To do. It should be noted that the current version slot use map 40 is composed of only the bit map block 41 which indicates the use or non-use of each slot until the recovery process from the system failure is completed and the normal process is started. There is no Bitmap block 42 indicating that.

(B) Analysis of transaction status The history file 70 is read to analyze the status of the transaction when a system failure occurs. Then, the transactions are classified based on the analysis result. The transaction is
Depending on the contents of the necessary recovery processing, as shown in FIG. In FIG. 7, 111 is a check point, 112 is a system failure occurrence point, 121 to 125.
Indicates a transaction.

A type I transaction A transaction completed before the checkpoint, like the 121 transaction. The completion of the transaction is determined by whether or not the transaction processing completion journal is acquired.

Type II transaction Like the 122 transaction, a transaction that started before the checkpoint and completed after the checkpoint.

A type III transaction Like the 123 transaction, a transaction that started before the checkpoint and was running when the system failed.

Type IV transaction Like the 124 transaction, a transaction that begins after a checkpoint and completes before a system failure occurs.

Type V transaction Like the 125 transaction, the transaction that started after the checkpoint and was running when the system failed.

As will be described later, database recovery processing for type I transactions is not required. Therefore, the range of history information to be analyzed in the database recovery processing is after the first history information of all transactions that were being executed at the checkpoint. The history information number is written in the non-volatile storage medium 100 at the time of the checkpoint together with the final history information number at the checkpoint, so it may be read into the memory 10 at the beginning of the recovery process.

(C) Recovery of database control information Recovery processing is performed according to the transaction type classified in (b).

Type I Transactions All processing by the transaction is valid.
The database update result of the transaction has already been validated, and database recovery processing is unnecessary.

Type II transaction Although all the processing by the transaction is valid, it is possible that a part of the database update result of the transaction is not validated. Therefore, the page table update journal 71 of the transaction in the history file 70 is used to reflect the non-validated database update result of the transaction in the database control information 20 in the memory 10. That is, after the checkpoint of the transaction, the page table update journal 71 acquired in the history file 70 is read from the history file 70 in the order of acquisition, and the current version page table 30 and the current version slot use map 40 are updated. The current version page table 30 is searched for an entry relating to the page and the updated slot number is set. Further, for the current version slot use map 40, the entries for the slots before and after the update are searched and turned off and on, respectively.

Type III transaction Although all processing by the transaction is invalid, the database update result of the transaction may be partially validated. Therefore, the page table update journal 71 of the transaction in the history file 70 is used to remove the validated database update result of the transaction from the database control information 20 in the memory 10. That is, the page table update journal 71 acquired before the check point of the transaction is read in the reverse order of the acquisition order, and the current version page table 30 and the current version slot use map 40 are updated. Current version page table 30
For, the entry for the page is searched and the slot number before update is set. As for the current version slot use map 40, the entries for the slots before and after the update are searched and turned on and off respectively.

Type IV transaction All the processing by the transaction is valid, but the database update result of the transaction is not valid. Therefore, the database update information of the transaction is reflected in the database control information 20 in the memory 10 by using the page table update journal of the transaction in the history file 70. In this section, the specific processing contents are the same as those of the type II transaction except that all the page table update journals 71 of the transaction are used.

When there are multiple transactions of this type, the above processing is performed in the order in which the transaction processing completion journals are acquired.

Type V Transaction All processing by the transaction is invalid.
The database update result of the transaction has not been validated and database recovery processing is unnecessary.

It should be noted that the recovery processing of the messages other than the database, such as the messages to be recovered and the system management information, is performed by a known method by analyzing the history file 70.

(4) Operation at the time of a transaction failure In the case of a transaction failure due to the occurrence of a program error before acquisition of the journal 72, the following recovery processing is performed.

(A) Recovery of database control information Using the shutter / slot management information accumulated in the memory 10, the following processes are performed for all updated pages of the transaction.

The entry for the page in the current version page table 30 is searched and the slot number before update is set.

The current version slot use map 40 is searched, and both the bit indicating whether the slot after update of the page is used and the bit indicating whether the slot before update of the page is a shutter slot are turned off.

(B) Recovery of page contents in memory When handing over a page loaded in the memory 10 between different transactions, the information before the update by the transaction is left in the memory 10 and the information is updated. The contents of the page are returned to the contents at the time when the execution of the transaction is started by using.

Incidentally, the recovery processing of the message, the system management information and the like is carried out by a known method based on the history file 70.

As described above, according to this embodiment, it is possible to solve the above-mentioned three problems of the shear page method.
Further, with the first effect peculiar to this embodiment, the system need not be in the stopped state at the time of the checkpoint and may be in the transaction execution (however, the transaction requesting the database update is in the waiting state). , The check point processing overhead is small. As a second effect, the number of the first history information of all transactions being executed at the time of checkpoint is recorded in the non-volatile storage medium, so the range of history information to be analyzed regarding the database in the recovery process at the time of system failure occurs. It becomes narrower and the time required for the recovery process is shortened. Also,
If the system management information in the memory 10 is written to a non-volatile storage medium at the time of a check point, and the recovery processing is performed using the above written information when a system failure occurs, the range of history information to be analyzed is narrowed even for other than the database. Therefore, the time required for the recovery process is further shortened.

In the recovery processing when a system failure occurs, the database recovery processing is not performed for each transaction as in the present embodiment, but by performing the following, the status analysis of the transaction and the message or system management are performed. It is possible to efficiently perform recovery processing together with the initial recovery of information and the like.

First, the history file 70 is read from the final history information in the reverse order of the acquisition order, and the state analysis of transactions and the processing of incomplete transactions are invalidated.

Next, the history file 70 is read in the order of acquisition, and the processing of the completed transaction is validated.

Next, the configuration and operation of the second embodiment will be described. FIG. 8 is a diagram showing the configuration of the second embodiment. Basically, it is the same as the first embodiment, and the first embodiment is that there are two sets of database control information on the non-volatile storage medium 100 consisting of the backup version page table 80 and the backup version slot use map 90. Different from the example. In addition,
In FIG. 8, these two sets of database control information are stored in different non-volatile storage media 100, but both sets may be stored in the same non-volatile storage medium (may be the database storage medium 50). . Two sets of back-up page tables 80 and back-up slot-using maps 90 are alternately updated at the checkpoint,
In the recovery process when a system failure occurs, the one updated at the latest valid check point is used. For this reason,
As the checkpoint information in the non-volatile storage medium 100,
Similar to the first embodiment, the backup version page table
An area for recording the number of the final history information in the history file 70 at the time of updating 80 is provided, and a check point valid flag showing validity / invalidity of the check point is provided. Note that, unlike the first embodiment, each backup version page table 80 does not need to be duplicated.

Next, the system operation will be described. The normal operation and the transaction failure operation are performed as in the first embodiment. Therefore, the operation at the time of checkpoint and the operation at the time of system failure will be described below.

(1) Checkpoint operation At the checkpoint operation, the processing related to the database will be described. The processing flow is shown in FIG.

(A) Updating the backup version page / table, etc. Select the backup version page table 80 and the backup version slot use map 90 that should be updated at the check point, and perform the necessary update processing. The backup version page / table to be updated is selected at the time of system start / restart, and then switched at each valid check point. The update processing of the selected backup-up page table 80 and the backup-up slot use map 90 is performed in the same manner as in the first embodiment. However, the update flag must be set for each backup version page table 80 and each backup version slot use map 90.

A nonvolatile storage medium is used as the checkpoint information.
The number of the final history information in the history file 70 at the time of updating the backup version page table 80 is acquired in 100, and the check point valid flag on the nonvolatile storage medium 100 is turned off (invalid state).

While performing the above processing, the transaction may be in the execution state including the update of the database.

(B) Checkpoint effective monitoring The execution state of all transactions being executed at the time of the checkpoint is monitored, and the checkpoints are effectively monitored. FIG. 10 is a diagram for explaining checkpoint effective monitoring, in which 210 and 211 are checkpoints and 22.
Reference numerals 1 to 229 denote a transaction, 230 a transaction failure, and 231 a recovery processing for the transaction failure. All the transaction points 221, 224, 226, 228 that are being executed at the time of the checkpoint 210 are the targets of checkpoint valid monitoring, and the occurrence of the transaction failure 230 invalidates the checkpoint. In this case, after completion of the recovery processing 231 for the transaction failure 230, the check point 211 is taken again. This time all the transactions 222,225,22 running at checkpoint 211.
7,229 will be subject to checkpoint effective monitoring, and checkpoint 211 will be completed after transaction 229 processing is completed.
Is valid.

(C) Update of checkpoint valid flag When the checkpoint is valid as a result of the checkpoint valid monitoring, the checkpoint valid flag on the non-volatile storage medium 100 is turned on (valid state).

(2) Operation at the time of system failure The database recovery processing when a system failure such as power failure occurs is basically performed in the same manner as in the first embodiment, but is slightly different as described below. After executing the processes of (a) to (c) below, the system reads the required page based on the current version page table 30 and starts the normal process.

(A) Reading the database control information The backup version page table to be read first
After selecting 80 and the back-up plate slot use map 90, the reading process for them is performed as in the first embodiment. Select the read target as follows.

Checkpoint valid flag and backup version page table from each nonvolatile storage medium 100.
80 Update history file Read the number of the last history information in file 70.

If both checkpoint valid flags are ON (valid state), the numbers of the final history information at the time of updating the backup version page table 80 are compared, and the newer one is targeted for reading.

If only one of the checkpoint valid flags is on, the one that is on will be read. It should be noted that both checkpoint valid flags are never turned off because of the operation at the checkpoint.

The back-up version page table 80 and the back-up version slot use map 90 that have not been selected in the above selection process are to be updated at the next check point. Also, all of these update flags are set to ON.

(B) Analysis of transaction state The history file 70 is read, and the same procedure as in the first embodiment is performed.
However, in the case of the present embodiment, due to the checkpoint effective monitoring, there is no type III transaction, and the range of history information to be analyzed in the database recovery processing is after the last history information at the time of the checkpoint.

(C) Recovery of database control information The procedure is the same as in the first embodiment except that there is no type III transaction.

The recovery processing of the message, system management information and the like is performed by a known method by analyzing the history file 80.

As described above, according to this embodiment, like the first embodiment, it is possible to solve the above-mentioned three problems of the shadow page method. Further, as the first effect peculiar to the present embodiment, the system does not need to be in the stopped state at the check point, and the transaction may be executed including the database update. Therefore, the overhead of the checkpoint process is smaller than that of the first embodiment.
The second effect is that by checking the checkpoints effectively, the range of history information to be analyzed for the database in the recovery process when a system failure occurs is only after the last history information at the time of the checkpoints, and the recovery process time is shortened. As in the first embodiment, the time required for recovery is further shortened by using the same method as the database control information such as the system management information in the memory.

Next, the configuration and operation of the third embodiment will be described. FIG. 11 is a diagram showing the configuration of the third embodiment. In this embodiment, a plurality of checkpoint dump files 200 are further added to the structure of the first embodiment, and the structure is connected to the CPU / memory 10. Check Point
Dump File 200 has 10 memory at checkpoint
It is a file in which the above system management information, database control information 20, etc. are written out, and is used in a round robin system. In other words, each checkpoint dump file is used in sequence for each checkpoint, and after one cycle, the checkpoint dump files are used again in order from the leading checkpoint dump file. At this time, new checkpoint dump information is written out so as not to erase the previously written information (called checkpoint dump information). Then, in the recovery process when a system failure occurs, the checkpoint dump information acquired at the latest valid checkpoint is used. Therefore, in addition to the checkpoint dump information such as the system management information on the memory 10 and the database control information 20 in the checkpoint dump file 200, the checkpoint dump information for the valid checkpoints is used as the checkpoint information at the time of the checkpoint. Contains the number of the last history information in history file 70.
It is not necessary to duplicate the backup version page table 80 as in the second embodiment.

Next, the system operation will be described. The normal operation and the transaction failure operation are performed as in the first embodiment. Therefore, the operation at the time of checkpoint and the operation at the time of system failure will be described below.

(1) Operation at checkpoint Figure 12 shows the processing flow at checkpoint.

(A) Checkpoint dump file selection Select the checkpoint dump file 200 for which you want to obtain checkpoint dump information. The checkpoint dump file 200 to be acquired is used in a round robin method after being selected at the time of system start / restart.

(B) Acquisition of checkpoint / dump information Information on the memory 10 such as system management information and database control information 20 is selected as a checkpoint / dump information.
Get to File 200. The database control information 20 is
For each block, only the parts of the backup up page table 80 and the backup up slot use map 90 that have been updated since the latest update processing are acquired as the check point dump information. Therefore, the current version page table 30 and the current version slot use map 40 are provided with update flags for each block.

(C) Check Point Effective Monitoring As in the second embodiment, the check points are effectively monitored, and when the check points are invalid, the check points are retaken. At this time, the same checkpoint
Dump file 200 invalid checkpoints Overlaid on dump information to newly checkpoints
Get dump information.

(D) Obtaining the number of the final history information When the checkpoint is validated as a result of checking the checkpoint validity, the number of the final history information in the history file 70 at the time of the checkpoint is set to the checkpoint dump dump file. Get to 200. By this processing,
The check point dump information is valid.

(E) Updating the backup version page / table, etc. In order to reduce the amount of checkpoint dump information acquired, the backup version page / table 80 and backup version slot use map 90 are updated for each valid number of valid checkpoints. Set their update flags to off.

(2) Operation at the time of system failure The database recovery processing when a system failure occurs is performed in the following order (a) to (d). After executing the processes of (a) to (d), the system reads necessary pages based on the current version page table 30 and starts the normal process.

(A) Reading of database control information As in the first embodiment, the backup version page table 80 and the backup version slot use map 90 are read from the non-volatile storage medium 100, and the current version page table 30 and the current version slot are read. Use map 40
It is expanded in the memory 10 as.

(B) Reading the checkpoint dump information The checkpoint dump information of the database control information 20 is read from the checkpoint dump file 200,
The current version page table 30 and the current version slot use map 40 are covered with the corresponding blocks to restore the database control information 20 to the state at the time of the check point. Checkpoint dump file to read
Selection of 200 is performed as follows.

The final history information number for each final checkpoint dump information is read from each checkpoint dump file.

The read numbers are compared and the checkpoint dump information for the latest number is read. Note that the checkpoint dump information for which the final history information number has not been acquired is invalid and is not subject to reading.

(C) State analysis of transaction The same as in the second embodiment.

(D) Recovery of database control information The same as the second embodiment.

In addition, recovery processing of messages, system management information, etc. is performed by the history file 70 and checkpoint dump.
This is carried out by a known method by using the file 200.

As described above, according to this embodiment, like the second and third embodiments, it is possible to solve the above-mentioned three problems of the shadow page method. Further, as the effect peculiar to this embodiment, the same effect as the second embodiment can be obtained.

In the above description, when a high-speed random access storage device such as an IC non-volatile memory or a so-called IC disk is applied as the non-volatile storage device, the speed-up and usability are excellent.

According to each of the above-mentioned embodiments, the online page database system in which a plurality of online transactions simultaneously update the database and send and receive messages to and from the terminal can use the shadow page method. Conventionally, in such a system, a method has been widely adopted in which database update history information is acquired from a storage medium such as a magnetic disk or a magnetic tape, and recovery processing is performed using this when a system / transaction failure occurs. Compared with this conventional method, the history information acquisition amount can be reduced by each of the above embodiments. For example, assuming that the page size is about 4 Kbytes, the page number and slot number are 4 bytes, and that both numbers acquire pre- and post-update information, if the average amount of updated data per page is 60 bytes, then 1 / With 10 or 100 bytes, the amount of history information acquired can be reduced to 1/17 (however, comparison of update history information only). When updates concentrate on a specific page, the effect of reducing the amount of acquired history information is even greater.

Further, in each of the above-mentioned embodiments, normally, by referring to / updating the current version page table and the current version slot use map on the memory, the page table update overhead in the shear page method is reduced.

In addition, the backup version page table is stored in a non-volatile memory at the check point after a large number of times (for example, 1,000 times) compared to the conventional method in which the backup version page table is acquired on a magnetic disk at each transaction. The overall speed-up effect by transferring is remarkable.

〔The invention's effect〕

According to the present invention, in a database system using the shadow page method, it is possible to simultaneously update a database by a plurality of transactions without lowering processing efficiency.

[Brief description of drawings]

FIG. 1 is a block diagram of the first embodiment, FIG. 2 is an explanatory diagram of a backup version page table of the present invention and a backup version slot use map, and FIG. 3 is a current version page table of the present invention and a current version slot use. FIG. 4 is an explanatory diagram of a map, FIG. 4 is an explanatory diagram of a history file of the present invention, and FIG. 5 is a processing flow diagram when writing an updated page in the present invention.
FIG. 6 is a flow chart of the database recovery processing at the time of system failure in the present invention, FIG. 7 is a state diagram of the transaction, FIG. 8 is a block diagram of the second embodiment of the present invention, and FIG. 9 is a second embodiment. Example process flow diagram at checkpoint, 10th
FIG. 11 is an explanatory view of checkpoint effective monitoring in the present invention, FIG. 11 is a configuration diagram of a third embodiment of the present invention, and FIG. 12 is a processing flow chart at the time of checkpoint of the third embodiment. 10 ... CPU / memory, 20 ... Database control information, 30 ...
… Current version page table, 40 …… Map using current version slot, 50 …… Database storage medium, 60 ……
Database area, 70 ... History file, 71 ... Page / table update journal, 72 ... Transaction completion journal, 80 ... Back-up version page / table, 90 ... Back-up slot use map, 100
... Non-volatile storage medium, 200 ... Checkpoint dump file.

Claims (9)

[Claims] 1. Corresponding information between a database composed of pages which are logical storage locations of data, each page of the database and a slot on a database storage medium in which the latest contents of the page are stored. A current version page table to be registered, a current version slot usage map indicating whether or not each slot on the database storage medium is used, and a plurality of backup version page tables for recording the past contents of the current version page table. , And has a history file for recording history information about transaction processing, and when an active transaction updates the database, stores the content of the updated page in the empty slot found based on the current version slot usage map, Corresponding information between the page and the empty slot is current Register in the page table, update the information about the empty slots in the current version slot usage map, obtain history records showing the contents of changes in the current version page table in the history file, and periodically Select one backup version page table in order from the backup version page table and update the selected backup version page table so that the contents match the current version page table. Based on the history record showing the contents of change of the current version page table recorded in the history file and the content of the last updated backup version page table among the above multiple backup version page tables,
A database update method characterized by recovering a table. 2. The database updating method according to claim 1, wherein the plurality of backup version page tables are configured on a storage medium that does not lose stored contents when a system failure occurs. 3. The database updating method according to claim 2, wherein upon completion of execution of a transaction, a history record indicating completion of execution of the transaction is acquired in the history file, and the current version page table is recovered. A database updating method, wherein the current version page table is restored so that only a database update by a transaction whose history record indicating completion of transaction processing is acquired in the history file is reflected in the database. 4. The database updating method according to claim 3, wherein in the step of updating the backup version page table, the identifier of the first history record among history records relating to all transactions being executed at the time of the update is the system. A history record acquired in the history file after the history record having the identifier recorded in the storage medium in the step of recovering the current version page table by recording in a storage medium in which the storage content is not lost at the time of failure A method for updating a database, characterized in that the current version page table is recovered by using. 5. In the database updating method according to claim 3, when a transaction being executed transmits / receives a terminal message or updates system management information on a memory, a history record indicating the contents is acquired in the history file. Then, when a system failure occurs, the terminal message and the system management information on the memory are recovered based on the history record in the history file. 6. The method for updating a database according to claim 1, wherein the current version slot usage map indicates a slot for storing the latest contents of each page of the database and contents before updating of the page updated by the transaction being executed. A method for updating a database, characterized in that the storing slot is configured to be in use. 7. The database updating method according to claim 1, further comprising: a backup version slot usage map indicating whether or not each slot of the database storage medium is used based on the presence or absence of registration in the backup version page table,
A database updating method characterized in that the backup version slot usage map is updated in the step of updating the backup version page table. 8. The database updating method according to claim 1, wherein in the step of updating the backup version page table, when a failure occurs during updating of the backup version page table, the previously updated backup version page table is used. A method for updating a database, which comprises recovering the backup version page table that was being updated. 9. The database updating method according to claim 1, further comprising a checkpoint dump file for acquiring system management information on a memory at a checkpoint, the interval being shorter than an interval for updating the backup version page table. Establish the above checkpoint,
At the time of the above checkpoint, the updated part of the current version page table after the previous checkpoint of the current version page table was recorded in the above checkpoint dump file, and when the system failure occurred, it was recorded in the above history file. A history record showing the contents of changes in the current version page table, checkpoint above
A database updating method comprising recovering the current version page table based on the information recorded in a dump file and the backup version page table.