JPH03102545A - Recovery system for data base - Google Patents

Abstract

PURPOSE:To easily execute the recovery of a data base at high speed by returning and restoring page management information and a physical page under commit operation from a transaction log to the old physical page while referring the transaction log when a fault is generated. CONSTITUTION:Corresponding to system down, a recovery processing is activated and all the physical pages are restored while being matched with the old physical pages. A saved transaction log 1 is retrieved and the physical page under the commit operation is taken out as the transaction log 1. Then, the physical page is matched with the old physical page while referring the transaction log 1.

Description

[Detailed Description of the Invention] [Summary] Regarding a recovery method for recovering a database, the purpose is to perform database recovery quickly and easily without checking points, and for each transaction that exclusively performs database updates, etc. , the changed page information and transaction status (such as during a soft operation) are saved as a transaction log to update the database, and if a failure occurs at any point, the above transaction log can be saved. In addition to referencing the page management information and returning it to the old physical page, it also searches the transaction log for the physical page that is being operated on and takes precautions to return it to the old physical page and restore it.

[Industrial application field]

The present invention relates to a recovery method for recovering a database. Database systems became popular,
It is desired to recover when the system I1 goes down.

[Problems to be solved by conventional technology and invention] Conventionally, in order to recover when a database system goes down, a log of updated information is saved, and a Chenok point I is set appropriately before the log increases too much. to save the database state. When the system goes down for some reason, recovery is done by restoring the database state based on the database state at the time of the checkpoint and the log.

For this reason, there is a problem in that recovery cannot be achieved unless the database state is saved by appropriately setting checkpoints before the log information increases too much.

An object of the present invention is to perform database recovery quickly and easily without using checkpoints.

The system takes out the one being operated on and refers to it to return the physical page to the old physical page and restore it.

Therefore, transaction log 1 for each transaction
By saving the transaction log 1, when a database failure occurs, it is possible to refer to this transaction log 1 and easily restore all physical pages to match the old physical pages.

〔Example〕

Next, the structure and operation of the first embodiment of the present invention will be explained in detail with reference to FIGS.

In Fig. 1, the 1-run transaction log 1 records changed page information (for example, identification of update, creation, or deletion, page number, etc.) for each 1-transaction that exclusively updates the data header. ) and the status of the first transaction (for example, Fumino I - operation in progress) are saved in an external storage device (for example, a magnetic disk device, etc.).

Recovery place J1! [Means for Solving the Problem] The means for solving the problem will be explained with reference to FIG. 1.

In Figure 1, the 1-transaction log 1 records the changed page information and the status of the transaction (e.g., during operation) for each 1-transaction that exclusively updates the data header, etc. It is something to save.

Recovery processing 2 refers to the transaction log 1 and recovers the database.

[Effect]

The present invention, as shown in FIG.
The changed page information and the status of 1.transaction (commisso I - in progress, etc.) are saved as 1.transaction log 1, and when a failure occurs, recovery processing 2 saves this 1.transaction log 1. See page tube p
In addition to returning the llj information to the physical page for 1 day,
The commit transaction log 1 is referred to from the transaction log 1 to restore page management information of the database (see FIG. 2).

Next, the structure and operation of one embodiment of the present invention will be described in detail in accordance with the order shown in FIG. 1 and with reference to FIG.

In FIG. 1, 0 accepts updates from the user;
Memorize it on the sofa.

Before updating the information stored on the bus sofa to the data directory on the external storage device, @ will update the changed page information stored on the bus sofa and the transaction status (such as during a command operation) as necessary. Save it to an external storage device as a transaction log l.

■Start updating the database.

In case (2), the system goes down for some reason, such as while updating the data directory.

In (2), in response to the system failure in (2), the system is started up, the recovery process 2 according to the present embodiment is started, and the [phase] to [phase] processes are performed.

[Phase] aligns all physical pages to the old physical page. This is the saved transaction log
For example, if the page information in Figure 2 (A) is the page management information at the time of downtime, all the underlined parts where the new physical page and the old physical page are different are adjusted to match the old physical page, and the page information in Figure 2 (B) is changed. ) Restore as shown in the underlined section.

O takes out the transaction log l that is being committed. This is done by searching the saved transaction log l and searching for the transaction log during the commit operation (from receiving the command to issuing the commit decision), for example, as shown in Figure 2 (c). (During ξ sort operation) Extract as 1.

[Phase] Adjusts the physical page to the old physical page while referring to the transaction log 1 retrieved in step (■). In this case, referring to the transaction log (during multiple operations) in Figure 2 (c), for example, as shown in ■, the new physical page (old physical page) after recovery (l) in [phase], and,
A new physical page in the transaction log (comint operation) is saved as physical transaction log 1, and when a failure occurs, this is referenced to restore database page management information, etc. Therefore, when recovering a database, there is no need to set up conventional checkpoints, and recovery can be performed quickly and easily.

[Brief explanation of drawings]

FIG. 1 is a diagram illustrating the structure and operation of an embodiment of the present invention, and FIG. 2 is a diagram illustrating a specific example of the present invention. In the figure, 1 represents a transaction log, and 2 represents a recovery process.

Claims (1)

[Claims] In a recovery method for recovering a database, for each transaction that exclusively updates the database, changed page information and transaction status (commit operation, etc.) are recorded in a transaction log (
1) and update the database, etc. If a failure occurs at any point, refer to the transaction log (1) above and return the page management information to the old physical page, and also update the transaction log. A recovery method for a database characterized in that it is configured to search for a physical page that is undergoing a commit operation from (1) and restore it by returning it to an old physical page.