JP2806342B2 - Database failure recovery method and device - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a database recovery processing method and apparatus, and more particularly to a database recovery method in a network operation system for centrally monitoring and controlling a plurality of transmission apparatuses distributed and installed in a plurality of stations. The present invention relates to a recovery processing method and device.

[0002]

2. Description of the Related Art A network operation system performs monitoring and control of a communication network system composed of a plurality of transmission devices distributed in a plurality of locations in one or a small number of centers. In addition, management data such as environment settings and operation status of the entire system are stored in the database of the monitoring center.

In a data update process in a database system, first, a transaction opening process is performed for each series of data to be updated, data to be updated is sequentially searched and read from the database, and this data is replaced with new data to replace the database. Is repeated until a series of update work is completed, and after the update work is completed, this data is released to another transaction and finished.

If a failure occurs during the transaction processing, the data update is interrupted and the database is destroyed. To minimize this damage, each data before and after the update and related history data are time-series. The journal is stored in a secondary storage device such as a magnetic tape, and when a failure occurs, the database is restored to the state before the failure using the journal stored in the secondary storage device, and the update process is performed. It is. Various proposals have hitherto been made in order to quickly perform the database failure recovery processing.

For example, Japanese Unexamined Patent Publication No. Hei 3-192438, "Database Failure Recovery Method," addresses the emergence of long data, attempts to speed up the history journal acquisition process of the data before updating, and efficiently recovers the database failure. The data before and after the update is identified by the flag information as an update history and current data, respectively, and stored in the database as the update data, the current data is deleted from the database, and the current data is stored as the update history. Restores the database by changing the pre-update data to the current data by changing the flag information, and in the event of a failure, changes the flag information and unnecessary data in the data in the storage area specified by the pointer information acquired in the update history journal Deleting a failed transaction restores it to the state it was in before the failed transaction was opened. Possible to recover the database is disclosed.

Japanese Unexamined Patent Publication No. 5-94352 discloses a "database recovery method" in which the same data block is updated at a time to reduce the number of times of input / output of the database. The pre-update journal records are output to a sort work file, and the record data is sorted in ascending order using the data file name, medium name, medium device name, and relative position of the database block in the file as the sort key. In addition, there is disclosed a method of combining journal records before updating and converting them into an original record image.

Japanese Patent Application Laid-Open No. 5-143422 discloses an "updated journal management method" in which a plurality of pages are restored in parallel in a database restoration process to speed up the process. An updated journal file that stores history information as partitioned organization, an input / output means of a database, and a journal that stores update history information on each updated journal file as a separate member of a partitioned file for each page and controls input and output A control unit, a saving unit for saving the database, and a file restoring unit for executing a plurality of page restoration processes in parallel when the database is abnormal are provided. And
After the update, the update history information is stored separately for each page as a sectioned file, and the file is saved when the database is normal.
Alternatively, it is disclosed that restoration processing of a specific page of the update history is performed in parallel on a plurality of pages.

[0008]

However, in each of the above-mentioned database systems, the acquisition of the update history at the time of updating the database is performed independently of the update of the database. When the information is lost, the recovery process using the history information cannot be performed automatically, and there is a problem that the operator has to perform the update process while checking the contents of the database.

When the backup data stored in the secondary storage device is used, the backup data is restored after the above-mentioned abnormal update data recovery work, and the restored data is compared with the data before the restoration. It is necessary to manually extract and update the data to be updated,
There was a problem that it took a long time to recover and the operation start was delayed.

An object of the present invention is to solve the above-mentioned problems,
It is an object of the present invention to provide a database failure recovery method and device capable of automatically extracting and restoring update information lost during memory development.

[0011]

According to the present invention, there is provided a method for restoring a failure in a database, wherein information on the presence / absence of history information in one-to-one correspondence with history information in an update history file is provided in the update history file. Recording in the first history management map and the second history management map provided in the database,
The first history management map is compared with the second history management map, and as a result of the comparison, a database update process is performed on history information in which both are detected to be unequal.

[0012] The database failure recovery apparatus of the present invention comprises:
An update history file that stores history information of update operations on the database, a history management map that manages the presence / absence of history information in one-to-one correspondence with history information in the update history file, and database backup and restore operations Backup / restore means for performing the comparison, a history management map comparing means for comparing a history management map existing in the update history file with a similar history management map existing in the database, and a result of the comparison by the history management map comparing means. A database automatic updating unit is provided for performing a database updating process on history information in which both are detected to be unequal.

In the database failure recovery apparatus of the present invention, at the time of backup, the history management map is also backed up at the same time.

[0014]

Next, embodiments of the present invention will be described with reference to the drawings.

FIG. 1 is a block diagram of an embodiment of a database failure recovery apparatus according to the present invention, FIG. 2 is a diagram showing a correspondence relationship between an update history file 7 and a history management map 71, and FIG. FIG. 4 is a flowchart at the time of system restart, and FIG. 5 is a flowchart at the time of restoring a backup database.

Referring to FIG. 1, a supervisory control device 1 according to this embodiment
Is a system console 6 having an application program 2 for monitoring and controlling a plurality of transmission devices, a database 4 for storing management data for monitoring and control, and an update history file 7 for storing updated data of the database 4. And a database control unit 3 for controlling input and output of data to and from the system console 6 and the database 4
And a backup recording unit 5 in which backup data of the database 4 is stored.

The update history file 7 includes a database 4
Are recorded for each block of the management data, and as shown in FIG.
A history management map 71 for managing whether or not there is a record in the update history file 71 is provided.
Recorded as N. The database 4 is also provided with a history management map 41, in which management information associated with the update contents of the update history file 7 on a one-to-one basis is recorded.

In the case of a normal update process, the writing unit 31 receives the information on the writing state from the database 4 and writes the contents of the update operation to the update history file 7 only when the writing is normally performed. History management map 4 corresponding to the location of the written update history file 7
The map state of the corresponding position of 1, 71 is changed from OFF to ON. Therefore, when the update processing is performed normally, the contents of the respective parts of the history management maps 41 and 71 match.

The database control unit 3 compares the two history management maps 41 and 71 with the writing unit 31 that writes management data into the database 4 and writes the updated contents into the update history file 7. A comparing unit 32; an automatic updating unit 33 for automatically updating the database 4 with a different update content when a difference is detected as a result of the comparison; and a restore for restoring the backup data stored in the backup recording unit 5 to the database 4. And a processing unit 34.

Next, the operation of this embodiment will be described.

When a normal update process is performed from the system console 6 to the database 4, the writing unit 31 receives the write status information from the database 4, and updates the update history file 7 only when the data is normally written. The update management content 41 corresponding to the location of the written update history file 7 is written.
The map state of the corresponding position 71 is changed from OFF to ON.

Now, it is assumed that a system failure has occurred during the database update operation, and the contents of the update data in the database 4 being developed in memory have been lost.

In this state, when the failure is recovered and the system is restarted, the comparison unit 32 compares the history management map 41 of the database 4 with the history management map 71 of the update history file 7 as shown in FIG. The automatic update unit 33 automatically updates the database 4 in accordance with the update contents of the update history file 7 corresponding to the map position where the difference is detected. Perform

The contents of the database 4 are not lost,
Therefore, when no difference is detected as a result of the comparison, FIG.
As shown in the flowchart, the system is started without any special processing.

In addition, the backup recording unit 5 is provided in preparation for the occurrence of a failure in which the database 4 cannot be rescued.
The backup data of the database 4 is stored together with the history management map 41 in a predetermined cycle in advance, and the restore processing unit 34 restores the backup data of the database 4 when a failure that cannot be repaired occurs. I do. At the time of this backup, the history management map 41 is also backed up at the same time.

At the time of restoring the database, as shown in the flowchart of FIG. 5, similarly to the case of the above-described system restart, the comparison unit 32 stores the history management map 41 restored from the backup recording unit 5 and the update history file 7 The automatic update unit 33 automatically updates the database 4 based on the result, and restores the database to the latest state before the restoration.

[0027]

As described above, according to the present invention, a history management map for managing whether or not update information is recorded in the update history file is provided in the update history file and the database. By extracting and updating the update information to be updated, the update information lost during the memory development can be quickly restored.

Further, by simultaneously backing up the history management map at the time of backup, there is an effect that the database can be quickly restored by the backup data.

[Brief description of the drawings]

FIG. 1 is a block diagram of an embodiment of a database failure recovery apparatus according to the present invention.

FIG. 2 is a diagram showing a correspondence relationship between an update history file 7 and a history management map 71.

FIG. 3 is a flowchart of comparison information of a history management map 71;

FIG. 4 is a flowchart when the system is restarted.

FIG. 5 is a flowchart when restoring a backup database.

[Explanation of symbols]

 REFERENCE SIGNS LIST 1 monitoring control device 2 application program 3 database control unit 4 database 5 backup recording unit 6 system console 7 update history file 31 writing unit 32 comparison unit 33 automatic update unit 34 restore processing unit 41, 71 history management map

Claims (3)

(57) [Claims] 1. A failure recovery device for a database system, comprising: a database in which management data is stored; and an update history file in which update history information of management data stored in the database is stored. , Wherein information on the presence or absence of individual history information in the update history file is stored.
A second history management map provided in the database and storing information on the presence / absence of history information in one-to-one correspondence with history information in the update history file; History management map comparing means for comparing the first history management map with the second history management map; and, as a result of the comparison between the first and second history management maps, Extract
A database failure recovery apparatus comprising: a database automatic updating unit for performing a database update process. 2. The database failure according to claim 1, further comprising backup / restore means for storing the second history management map of the database together with the backup data and restoring the second history management map together with the backup data at the time of restoration. Recovery device. 3. A failure recovery method for a database system, comprising: a database in which management data is stored; and an update history file in which history information of an update operation of management data stored in the database is stored. Is recorded in a first history management map provided in the update history file and a second history management map provided in the database. Comparing the first history management map and the second history management map, and performing a database update process on history information in which it is detected that the two are not equal as a result of the comparison. Disaster recovery method.