JPH06149641A - On-line backup and fault recovery system - Google Patents

Abstract

PURPOSE:To attain backup in the on-line operation. CONSTITUTION:The on-line backup preparing device 14 stores the information of a data base file 11 in a backup storing file 16 to backup the information. As to each table constituted of logical records, only constitutional information such as a table identifier (ID) and table length is stored. As to each record, the ID and contents of the record are stored. In the case of storing records, only records having transactions in executing out of deleted records or records to be deleted and records not to be deleted are stored. When a fault is generated in a disk device or the like stored in a data base file 11, contents are prepared from the backed-up constitutional information such as the table ID and table length, the record ID and record contents.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to an online backup and failure recovery system for a database using a logical journal system.

[0002]

2. Description of the Related Art Generally, in a database management system,
Commitment control is performed to guarantee the changes made by the transaction against failures. Commitment control refers to control for updating the database by committing after all the processing included in a transaction involving data change is completed. As a result, if any one of the processes included in the transaction is not completed normally, the transaction is rolled back,
It is possible to prevent unauthorized updating of the database. In commitment control, a journal method is used in which a change history of transactions is stored in a journal (log). The logical journal method is a method of storing a record changed by a database management system, a record identifier, an operation, and a record change difference in a journal. The record is specified by a logical identifier, and the journal alone does not have information on the physical storage location.

Backup creation and backup and failure recovery using the journal of the database management system using the logical journal method will be described below. Figure 2
It is a block diagram of the conventional online system. As illustrated, the database management system 20 using the logical journal system manages three types of information: a database file 21, a journal file 22, and a recovery information file 23. The database file 21 stores database tables and index tables. Each table consists of records. Journal file 2
Reference numeral 2 stores a record identifier for uniquely identifying a record changed by the database management system 20 to the database file 21, a record change operation, and a record change difference (journal). The recovery information file 23 stores information about from which position of the journal stored in the journal file 22 the recovery should be performed at the time of failure recovery.

Next, a conventional backup method will be described with reference to FIGS. 2 and 3. FIG. 3 is a flowchart explaining a conventional backup method. Stop the operation of the database management system before starting backup. This is to prevent the database files that should be backed up from changing during the backup. Next, all the database files 21 are copied by the file copy command 24 (step S32).
This creates a copy 25 of the database file. Next, the recovery information file 23 is copied by the file copy command (step S33). This creates a copy 26 of the recovery information file. With that, the backup process ends. Next, a recovery method from backup in the case where the medium destruction occurs will be described with reference to FIGS. 2 and 4.

FIG. 4 is a flow chart for explaining a conventional recovery method from a medium. When the medium of the database file 21 is destroyed, all the copies 25 of the database file are restored (step S4).
1). As a result, the file structure will be the same as when creating the backup. Similarly, copy 2 of the recovery information file
6 is restored (step S42). In this state, the state of the database at the time of backup is restored. Next, recovery is performed using the journal file 22 written from the time of backup (step S43). Here, the position of the journal to start recovery is read from the restored recovery information file 23, the journal is read from the journal file 22, and each record is recovered. This process is repeated until the last journal, the changes of incomplete transactions are invalidated, and the recovery work is completed. When the recovery work is completed, the operation of the database management system is started (step S4).
4).

[0006]

However, the above-mentioned conventional technique has the following problems. In other words, to recover from a disaster when the database media is destroyed,
It is necessary to once complete the operation of the database management system and to make a backup by copying the database file. Also, it is necessary to save the journal from the time of the backup. However, in a database system that performs continuous operation, there is a problem that backup cannot be performed because operation cannot be stopped. If the database management system duplicates the database file while it is modifying the database, the duplicated file will be inconsistent because it is not possible to duplicate all pages at the same time. In addition, the logical journal records only the changed record identifier of the database and the record change history information. Further, in the database management system, when the record is changed, the management information other than the record format is also changed. This information is not recorded in the journal. Therefore, the database and the journal that have been backed up cannot bring the database into the same state as when the failure occurred, and failure recovery is impossible.

As described above, in order to create a database backup by the file copy method, it is necessary to make the target database non-updatable. That is, backup cannot be performed while the database is being updated. The present invention has been made focusing on the above points,
By adding a logical backup device that logically backs up in database record units, in a database management system that uses the logical journal method, backup is performed even when the database file is changed, thereby recovering until a failure occurs. It is an object of the present invention to provide an online backup and a disaster recovery method that enables

[0008]

According to the online backup and failure recovery method of the present invention, there is provided a database consisting of tables composed of logical records, a database file storing the database, and a journal storing update differences of the database. In the case of managing by files, the identifier and the configuration information of the table constituted by logical records, excluding the index record for the predetermined online backup creating apparatus to retrieve the logical record from the database file during updating of the database. By storing the identifier and the content of the logical record that is not deleted by the update in the predetermined backup storage file, the predetermined online backup file is stored. The backup creation device backs up the database that is operating online, and at the time of failure recovery, the specified file recovery device creates the table from the identifier and contents of the backed up logical record and the table identifier and configuration information. Furthermore, an index table for searching each table from the created table is created to reproduce the database file at the time of backup.

[0009]

In the online backup and failure recovery method of the present invention, when backing up a database consisting of tables composed of logical records, only configuration information such as table identifier and table length is stored for each table. Further, for each record, a record identifier and record contents are stored. In this case, only those records that have been deleted or have a possibility of being deleted and have an ongoing transaction and records that are not deleted are stored. On the other hand, when a failure occurs in the disk device of the database file, an empty table with no contents is created from the backed up table identifier and configuration information such as table length, and the contents are created from the backed up record identifier and record contents. . Also, an index record is newly created and an index table is created. In this way, the database file at the time of backup is reproduced. Further, the update difference information is read from the journal file and the database at the time of failure is reproduced.

[0010]

Embodiments of the present invention will now be described in detail with reference to the drawings. FIG. 1 is a block diagram of an embodiment of a system to which the method of the present invention is applied. As shown, the database management system 10 using the logical journal method
Manages three types of information such as a database file 11, a journal file 12, and a recovery information file 13, as in the conventional system shown in FIG. The database file 11 stores database tables and index tables. Each table consists of records. The journal file 12 stores a record identifier for uniquely identifying a record changed to the database file 11 by the database management system 10, a record change operation, and a record change difference (journal). The recovery information file 13 stores information about from which position in the journal stored in the journal file 12 the recovery should be performed in case of failure recovery.

In the illustrated system, an online backup creating device 14 is added for backing up in record units in the database file 11. The backup storage file 16 created by the online backup creation device 14 is different from the conventional copy of the database file. The backup method of the recovery information file 13 is the same as the conventional one. However, it is necessary that the database management system 10 is not changing the recovery information file 13. Next, how the online backup creating device 14 creates the backup storage file 16 will be described with reference to FIG.

FIG. 5 is a flow chart for explaining the online backup creating method according to the present invention. The online backup creation device 14 does not use the database buffer 18 of the database management system 10 to read the data of the database file, but reads the content written in the database file 11. That is, each table is read from the disk device storing the database file 11. This is for the following reason. The database buffer of the database management system 10 may contain data changed before writing the change history in the journal file 12. For this reason, when such data is backed up, the change history is not written in the journal at that time. As a result, the database cannot be properly recovered during disaster recovery after backup.

The online backup creating device 14 is
The following processing is performed for all tables existing in all database files (step S5).
1). When the target table is the index table, the table contents are not backed up (step S52). The reason for this is that the index table can be recovered by extracting only the index information from the corresponding table if the corresponding table exists, so that only the minimum information is backed up. When the table is not the index table, the table identifier of the target table and the management information are backed up (step S53). Here, the table identifier is a number or the like for identifying the table. The management information is information necessary for recreating the target table. Specifically, this is a record length, a record attribute, or the like. In step S53, only the table configuration information is stored in the backup storage file 16.

Next, the following process is performed for all the records in the target table (step S54). If the target record has been deleted or is likely to be deleted (step S55), it is checked whether there is a transaction updating this record (step S56). This can be checked by referring to the deletion flag and the in-transaction flag in the target record. When the deletion flag is set, it means that the record has been deleted or may be deleted. When the in-transaction flag is set, it means that there is a transaction that is updating the record. If such a transaction exists,
Deletion may invalidate. That is, when the transaction does not complete normally and rolls back, the deletion flag in the record is reset, and the record once deleted in the transaction is restored. For this reason, such records also need to be backed up. Conversely, if no such transaction exists,
There is no need to back up because the record remains in the journal even if it is reused after being deleted.

Further, it is necessary to back up all the records that have been deleted or are not likely to be deleted (steps S55 and S57). Therefore, the record identifier and the record content of the record that needs to be backed up are written to the backup storage file (step S5).
7). That is, the data contents are written to the disk device provided for the backup storage file in logical record units, and thereby the backup is performed. In this way, when the backup processing for all the tables is completed, the online backup is completed. Next, a recovery method from medium destruction will be described with reference to FIG. FIG. 6 is a flowchart for explaining a recovery method from medium destruction according to the present invention.

What is different from the conventional method is a backup restoration method. Conventionally, restoration was performed by file copying, but the method of the present invention requires the following processing.
The database file in which the medium is destroyed first is created again (step S61). That is, the failed disk is replaced and the database area is secured in the new disk. However, the database file created here must not contain any data. Next, the following processing is performed on all the tables backed up in the backup storage file 16 (step S62). First, an empty table is created from the table identifier and the configuration information (step S6).
3). That is, a table is created that does not include data contents, but only has a table identifier, record length, record attributes, and the like. With respect to this empty table, the record stored in the backup storage file 16 is stored at the position indicated by the record identifier to complete the table (step S64).

After the above processing is completed for all the tables, the backed up recovery information file 13 is restored (step S65). That is, the data read from the copy 17 of the recovery information file is written in the recovery information file 13. Next, recovery is started (step S66). The recovery here is carried out by a method substantially similar to the conventional method. That is, the position of the journal to start recovery is read from the restored recovery information file 13, the journal is read from the journal file 12, and each record is recovered. The exception is
The recovery of the corrupted index table is not performed. After the recovery is completed, the destroyed index table is recreated by the index configuration table in the database (step S67). That is, the index configuration table is in a normal state by the above recovery. Therefore, an index record is created based on the index identifier, index length, corresponding record identifier, etc. in the index configuration table, and the index table is recreated. This will recover all the tables. Then, the operation of the database management system is started (step S68).

[0018]

As described above, according to the online backup and failure recovery method of the present invention, only the information storing the data structure for storing the minimum records not including the index record and the record contents are backed up. Since the files are recovered, the amount of data to be backed up can be reduced and the data can be backed up at high speed. As a result, in a database management system that uses the logical-value journal method for commitment control, it is possible to perform online backup of the database and use this to recover the database. Therefore, it becomes possible to recover the database in a short time from the medium destruction of the database.

[Brief description of drawings]

FIG. 1 is a block diagram of an embodiment of a system to which the system of the present invention is applied.

FIG. 2 is a block diagram showing a configuration of a conventional online system.

FIG. 3 is a flowchart illustrating a conventional backup method.

FIG. 4 is a flowchart illustrating a conventional recovery method from medium destruction.

FIG. 5 is a flowchart illustrating an online backup creating method according to the present invention.

FIG. 6 is a flowchart illustrating a recovery method from medium destruction according to the present invention.

[Explanation of symbols]

 10 Database Management System 11 Database File 12 Journal File 13 Recovery Information File 14 Online Backup Creation Device 15 File Copy Command 16 Backup Storage File 17 Copy Recovery Information File

Claims (1)

[Claims] 1. In a case where a database composed of a table composed of logical records is managed by a database file storing the database and a journal file storing the update difference of the database, a predetermined online backup creating device Excluding the index record for searching the logical record from the database file during updating of the database, the identifier of the table constituted by the logical record and the configuration information are stored in a predetermined backup storage file, and the predetermined online backup is performed. By storing in the predetermined backup storage file only the identifiers and contents of the logical records that are not deleted by the updating device by the updating device, the predetermined online backup creating device is online. When a failure recovery is performed, a prescribed file recovery device creates the table from the identifier and contents of the backed up logical record, the table identifier and the configuration information, and further creates the table. An online backup and failure recovery method is characterized in that an index table for searching each table is created from the created table and the database file at the time of the backup is reproduced.