JP3514332B2 - Database backup method - Google Patents

Description

Description: BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a backup of database data and a backup of a memory database having log information on a secondary storage. How to create. 2. Description of the Related Art A memory database stores all tables contained in the database on a memory, thereby providing a memory database.
This is a method to realize high-speed database access. In general, in the operation of a memory database,
Various failures occur, such as a failure of an application program, a failure of a system including a database management system, or a failure of a secondary storage medium such as a fixed disk. For this reason, a backup of the database is acquired in the secondary storage, and when a failure occurs, the database is restored from the backed up data. Hereinafter, a conventional backup method for a memory database will be described. When an update process based on a statement such as UPDATE / INSERT / DELETE is performed on a table stored in a memory database from a transaction for performing database access,
The updated portion is stored in the I / O buffer, and the pre-update value and the post-update value to be updated are stored in the pre-update log buffer and the post-update log buffer, respectively, in chronological order. Of these, the pre-update log is used for rollback processing for returning the database to the pre-update state on the memory when the transaction ends abnormally. The post-update log is output to the secondary storage when the transaction ends normally, to prepare for a system failure that occurs while updating the backup from the I / O buffer. The I / O buffer is used to update the database backup on the secondary storage when the transaction ends normally. [0006] Of these update processes, it may not be necessary to obtain the update result in the secondary storage. One such example is a representative telephone service that uses multiple lines with one telephone number. In general, when this example is managed using a database, a table including columns indicating telephone numbers and the number of available lines is prepared. The following operation is performed on the table. (1) Processing for Registering a New Service According to an INSERT statement, data including a telephone number to be newly registered and the number of lines prepared for the number is inserted into a table. (2) Call processing to the corresponding telephone number The number of lines currently permitted for the corresponding telephone number is referred to by the SELECT statement. If there is a free line, the UPDATE statement updates the table with a value obtained by decrementing the number of permitted lines by one. After that, connection processing to the corresponding line is performed. (3) Processing for disconnecting the telephone line to the relevant line The processing for disconnecting the relevant line is performed. UPDA refers to the number of lines currently permitted for the telephone number by the SELECT statement, and increments the value by 1.
Update the table with the TE statement. (4) Change processing of the prepared number of lines The number of new lines is reflected in the table by the UPDATE statement. (5) Stop the representative telephone service Delete the corresponding telephone number inserted into the table by the DELETE statement and the number of lines permitted by the number. Further, in the recovery processing of this database, all the lines are in an unused state because the table is returned to the initial state. Therefore, the number of lines permitted for one telephone number can be obtained by restoring the latest value in any of the above processes (1), (4) and (5), and updating (2) and (3). There is no need to back up the results. [0008] As in this example, depending on the table to be updated, it may not be necessary to back up the processing result changed by the UPDATE statement. However, according to the conventional method, the backup and the log information on the secondary storage are updated even for the update that does not require the backup. To update these secondary storages, I / O
Processing is required. Generally, I / O processing requires a processing time of several milliseconds to several tens of milliseconds. for that reason,
Since such unnecessary backup is performed, there is a problem that the transaction processing time becomes long. [0010] It is an object of the present invention to provide a database backup method for reducing transaction processing time. [0011] According to the database backup method of the present invention, for a table in which data is stored, a type for which a processing result is always guaranteed by recovery processing from secondary storage, and a specific update method A data type field, which is a field for specifying a type guaranteed by the recovery process from the secondary storage for the process only, is provided in the database management information, and the processing result of the update statement is stored in the secondary storage for the transaction accessing the database. The transaction management information is provided with a processing type field which is a field for designating a type that is always guaranteed by the recovery process from the above and a type that is not guaranteed for a specific table,
At the end of normal transaction, for insert statements and delete statements, the processing result is reflected in the backup on the secondary storage and log information of the updated value is added. For the update statement, the data type field is processed. If the type is such that the result is always guaranteed in the recovery process from the secondary storage , the process type file
Regardless of the field type, backup to secondary storage
Update results and add the updated values to the log information.
And the data type field corresponds to a specific update process.
Type guaranteed by recovery processing from secondary storage only
If the processing type field guarantees the processing result of the update statement in the recovery processing from the secondary storage at all times , the update result is reflected in the backup on the secondary storage and the updated value is added to the log information. And the data type field is a type that guarantees only a specific update process in the recovery process from the secondary storage, and the process type field is a type in which the processing result of the update statement is specified in the recovery process from the secondary storage . Guaranteed for tables
If you do not type, for backups on secondary storage
Reflection of the update result also does not perform also updates the log information. According to the present invention, backup of a table stored in a database is not performed depending on the type of data that is always backed up at the time of table creation (persistent designation) and the type of transaction that performs update processing. Add a data type field that specifies the type (temporary specification) to the schema information and set it. In addition, for the transaction for which the update process is performed, the type (all guarantee designation) that always guarantees the processing result of the UPDATE statement issued from the transaction on the secondary storage and, depending on the processing target table, the secondary storage A process type field that specifies a type that may not be guaranteed (non-guaranteed specification) is added to the transaction management information and set. [0013] Then, at the end of the transaction,
Regarding the result of the update processing based on the INSERT / DELETE statement, the updated log output and the backup on the secondary storage are reflected regardless of the specified values of the data type field and the processing type field. Regarding the result of the update process based on the UPDATE statement, (1) When the data type field is persistently specified, the output of the updated log and the secondary storage in the secondary storage are performed regardless of the specified value of the process type field. (2) When the data type field is specified as temporary and the processing type field is specified as all guarantees, the update is performed on the output of the updated log and the backup on the secondary storage. 3) When the data type field is temporary and the processing type field is non-guaranteed, the output of the updated log and the reflection on the backup on the secondary storage are not performed. As described above, according to the present invention, the I / O is not performed for the update processing by the UPDATE statement from the transaction whose processing type is non-guaranteed for a table whose data type is temporary specification. Processing time can be reduced. Next, an embodiment of the present invention will be described with reference to the drawings. FIG. 1 is a diagram for explaining a configuration for realizing a process for creating a table in one embodiment of the present invention. The table creation mechanism 102 is activated by the table creation command 101 and creates a table 104 and a data type field 105 on the memory DB 103. The table creation mechanism 102 creates a backup 107 of the table 104 and a backup 108 of the data type field 105 on the secondary storage 106. FIG. 2 is a flowchart of a process for creating the table 104 in the configuration shown in FIG. (1) The table creation instruction 101 is the table creation mechanism 1
02 is started (step 200). (2) The table creation mechanism 102 executes the table creation instruction 1
A table 104 is created on the memory DB 103 using the parameter 01 (step 201). (3) The table creation mechanism 102 creates the data type field 105 of the table 104 on the memory DB 103 (Step 202). (4) The table creation mechanism 102 executes the table creation instruction 1
01, the data type field 105
In this case, one of a type for always backing up data (designated as persistent) and a type for not performing backup (designated as temporary) is set depending on the type of transaction for which update processing is performed (step 20).
3). (5) The table creation mechanism 102 creates a backup 107 of the table 104 on the secondary storage 106 (Step 204). (6) The table creation mechanism 102 creates a backup 108 of the data type field 105 on the secondary storage 106 (Step 205). According to the above procedure, the table 104 in which the data type is specified is created on the memory DB 103. FIG. 3 is a diagram for explaining a configuration for realizing a process of updating a secondary storage from a transaction according to the present invention. The transaction 109 is a start instruction 110
And an update instruction 111 and an end instruction 112. The access mechanism 113 performs each process of starting, updating, and ending a transaction. FIG. 4 is a flowchart of a transaction start process based on the configuration of FIG. The transaction start processing is performed according to the following procedure. (1) The start command 110 instructs the access mechanism 113 to start a transaction (step 300). (2) The access mechanism 113 secures the processing type field 114 of the transaction 109 on the memory DB 103 (Step 301). (3) In accordance with the parameters of the start instruction 110, the access mechanism 113 always guarantees the processing result of the UPDATE statement issued from the transaction 109 on the secondary storage 106 (designated as all guarantees) and the processing target table In some cases, a type that may not be guaranteed on the secondary storage 106 (designated as non-guaranteed) is set in the processing type field 114 (step 302). FIG. 5 is a flowchart of a transaction update process based on the configuration of FIG. The transaction update processing is performed according to the following procedure. (1) The update instruction 111 instructs the access mechanism 113 to update the database (step 400). (2) In accordance with the UPDATE / INSERT / DELETE statement issued from the update instruction 111, the access mechanism 113 stores the pre-update values of the table 104 in the pre-update log buffer 115 in chronological order (step 401). (3) The access mechanism 113 updates the update target table 104 according to the UPDATE / INSERT / DELETE statement issued from the update instruction 110 (step 402). (4) Determine update statement (step 40)
3). (5) When the statement issued from the update instruction 111 is INSERT or DELETE, the access mechanism 1
13 shows the result of updating the table 104 performed in (3) as I
It is stored in the / O buffer 117 (step 404). (6) The access mechanism 113 stores the updated values of the table 104 in the updated log buffer 116 in chronological order (step 405). (7) When the statement issued from the update instruction 111 is UPDATE, the data type field 105 of the update table 104 is determined (step 406). (8) If the data type field 105 is persistent, the processing of (5) and (6) is performed. (9) If the data type field 105 is temporary, the processing type field 114 is determined (step 4).
07). (10) Transaction processing type field 114
If is guaranteed, the processing of (5) and (6) is performed. In the case of non-guarantee, it ends as it is. FIG. 6 is a flowchart of a transaction end process based on the configuration of FIG. The transaction end processing is performed according to the following procedure. (1) The end command 112 instructs the access mechanism 113 to end the transaction (Step 500). (2) Determine the end command 112 (step 501). (3) The access mechanism 113 sends CO
When the MMIT is issued, the access mechanism 113 adds the contents of the post-update log buffer 116 to the post-update log file 118 on the secondary storage 106 (step 50).
2). (4) The access mechanism 113 stores the contents of the I / O buffer 117 in the table backup 10 on the secondary storage 106.
7 (step 503). (5) When the end instruction 112 is ROLLBACK, the access mechanism 113 instructs the update processing to the table 104 to rollback based on the pre-update log buffer 115 (step 504). According to the above procedure, the result of the update processing of the UPDATE statement issued from the transaction whose processing type is not guaranteed for the table whose data type is temporary is not reflected in the secondary storage 106, but is updated accordingly. I / O can be reduced. FIG. 7 is a diagram for explaining a configuration for realizing a process of restoring a database from the acquired table backup 107 on the secondary storage 106, updated log information, and the data type field 105 according to the present invention. It is. The restoration mechanism 120 performs a process of restoring the database according to the restoration instruction 119. FIG. 8 is a flowchart of a database restoration process based on the configuration of FIG. The database is restored according to the following procedure. (1) The restore command 119 instructs the restore mechanism 120 to restore the database (step 600). (2) The restoration mechanism 120 loads the backup 107 of the table 104 on the secondary storage 106 into the memory DB 103 (Step 601). (3) The restoration mechanism 120 sets the value of the data type field 121 on the secondary storage 106 to the data type field 1
05 (step 602). (4) It is determined whether the processing of (2) and (3) has been completed for all tables (step 603). If not completed, the processes of (2) and (3) are repeated. (5) When the processes of (2) and (3) are completed for all tables, the restoration mechanism 120
18 are read out in order of time, and the table 104 in the memory DB 103 is updated. By the above procedure, the latest value is always guaranteed for a table whose data type is designated as persistent, and the INSERT statement or the processing type is guaranteed for a table whose data type is designated as temporary. The latest update value of the UPDATE statement of a certain transaction is restored. As described above, according to the present invention, the data type field is provided in the database management information, the processing type field is provided in the transaction management information, and the update processing necessary for restoring the database in the event of a failure. By obtaining only the result of I / O to the secondary storage, the I /
O can be reduced, thereby providing an effect that DB access can be performed at a higher speed than before.

BRIEF DESCRIPTION OF THE DRAWINGS FIG. 1 is a diagram for explaining a configuration for realizing a process for creating a table. FIG. 2 is a flowchart of a process for creating a table. FIG. 3 is a diagram for explaining a configuration for realizing a process of updating a secondary storage from a transaction; FIG. 4 is a flowchart of a transaction start process. FIG. 5 is a flowchart of a transaction update process. FIG. 6 is a flowchart of a transaction end process. FIG. 7 shows an acquired table backup 107 on the secondary storage 106, log information after update, and data type field 1
FIG. 14 is a diagram for explaining a configuration for realizing a process of restoring a database from the database 05. FIG. 8 is a flowchart of a database restoration process. [Description of Signs] 101 Table creation instruction 102 Table creation mechanism 103 Memory DB 104 Data type field 105 Table 106 Secondary storage 107 Table backup 108 Data type field 109 Transaction 110 Start instruction 111 Update instruction 112 End instruction 113 Access mechanism 114 Processing type Field 115 Log buffer before update 116 Log buffer after update 117 I / O buffer 118 Log file after update 119 Restore instruction 120 Restore mechanism 200 to 205 Step 300 to 302 Step 400 to 407 Step 500 to 504 Step 600 to 604 Step

Continuation of front page (56) References JP-A-5-61751 (JP, A) JP-A-3-78047 (JP, A) V. , Recovering From Main-Memory Lapse, Proceedings of the 19th VLDB Conference, USA, 1993, p. 391-404, URL, http: // www. inform ik. uni-trier. de / ~ ley / db / conf / vldb / J gadish SS93. html (58) Field surveyed (Int. Cl. ⁷ , DB name) G06F 12/00

Claims (1)

(57) [Claims] [Claim 1] All databases are resident in main storage, and 2
A method of backing up database data and storing log data having log information on a secondary storage, and a method for always guaranteeing a processing result for a table storing data in a recovery process from a secondary storage, In the database management information, a data type field, which is a field for specifying a type guaranteed by the recovery processing from the secondary storage only for the update processing of the secondary storage, is provided. A transaction type field that specifies the type that is always guaranteed in the recovery process from the next storage and the type that is not guaranteed for a specific table is set in the transaction management information. about The processing result is reflected in the backup on the secondary storage and the log information of the updated value is added, and for the update statement, the data type field always guarantees the processing result in the recovery processing from the secondary storage. If the type is
Regardless of the field type, backup to secondary storage
Update results and add the updated values to the log information.
And the data type field corresponds to a specific update process.
Type guaranteed by recovery processing from secondary storage only
If the processing type field guarantees the processing result of the update statement in the recovery processing from the secondary storage at all times , the update result is reflected in the backup on the secondary storage and the updated value is added to the log information. And the data type field is a type that guarantees only a specific update process in the recovery process from the secondary storage, and the process type field is a type in which the processing result of the update statement is specified in the recovery process from the secondary storage . Guaranteed for tables
If you do not type, for backups on secondary storage
Database backup method that reflects the update result also does not perform also updates the log information.