JPH01293452A - Data base fault recovering system - Google Patents

Abstract

PURPOSE:To promptly restore a fault by discriminating an updated history data to be used for data base restoration based on an identifier to preserve a sequence relation in time at every time point, selecting the reflecting method of the updated history data to the copied data, and executing a fault restoring processing. CONSTITUTION:An area table to have collected control information for one area of the data base stored in an area table file 110 has a backup completing time 203, re-editing starting time 206, and a re-editing completing time 207 by an identifier 210 at the backup starting time point. When the data base fault is restored, updated history data 402 to be used for the data base restoration are discriminated based on the identifier to preserve the sequence relation in time at each time point at every area to be an object, the reflecting method of the updated history data 402 to the copied data is selected, and the fault restoring processing is executed. Thus, a load to a data base system service manager can be decreased, and the fault can be promptly restored.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to a database failure recovery method, and particularly to a database system that performs database failure recovery work based on database copy data and update history data. This paper relates to a database failure recovery method that enables automation and high performance.

[Conventional technology]

A database is generally composed of several logical areas and is stored in an external storage medium, typically a magnetic disk. Each of the above areas may be stored on multiple media,
Multiple areas may be stored on a certain medium. If this medium becomes unusable for some reason, it is necessary to restore all areas included in the medium to the state immediately before the failure occurred. In database systems, a common recovery method is to overwrite database copy data with database update history data.

Therefore, conventional database systems provide users with a means to obtain copy data in units of areas or databases, and a means to edit update history data obtained during database services by update time interval or area. , users were required to prepare copy data and update history data necessary for database failure recovery.

Regarding such methods, for example, C, J,
“An Introduction to
Database Systems” (Addiso
Wesley, 1983).

[Problem to be solved by the invention]

When operating a database system, in order to expand the database capacity, organize and organize the data storage state, or partially change the database definition, it is necessary to reorganize the database by prohibiting access to that area ( (including “reconfiguration”).

For the sake of explanation, the area where the reorganization was carried out will be referred to as the bond below.
, other areas are similarly designated as Y. In addition, X in the medium where the failure has occurred will be denoted as X', and Y will be denoted as Y'.

If a failure occurs in the medium containing the reorganized area X,
If update history data based on the state of the database after reorganization is overwritten on the copy data obtained before reorganization, the contents of the database will be destroyed. Therefore, in the above-mentioned conventional technology, (1) after reorganization, the database service is interrupted and the composite data of the entire database area is reacquired. In the event of a database failure, recovery is achieved using the reorganized copy data and the updated B calendar data. (2) After the reorganization, the database service for X is not restarted until the copy data of only X has been acquired. When recovering from a failure, first, Y′
is restored to the state at the reorganization end time using the copy data and update history data. After that, recovery is performed using the copy data after reorganization for X' and the update history data of X' and Y'. , Y' is restored to the state at the reorganization end time. Thereafter, recovery operations were performed, such as performing post-reorganization on X' again, and then recovering using the update history data of X' and Y'.

In this way, in the conventional technology, it is up to the database system administrator to identify the medium on which a failure has been detected and the area it contains, and to select the copy data, update history data, and how to reflect them necessary for recovery. (1) Interruption of database service to obtain copy data after reorganization (2) Increased recovery time due to selection of copy data and editing of update history data (3) Used for failure recovery There were problems such as delays in recovery time due to misuse of copy data and update history data and human errors in recovery procedures.

The present invention has been made in view of the above circumstances, and its purpose is to solve the above-mentioned problems in conventional database failure recovery methods, reduce the burden on database system operations managers, and enable high-speed failure recovery. The objective is to provide a database failure recovery method that enables.

[Means to solve the problem]

The above-mentioned object of the present invention is to provide a database system that performs failure recovery based on copy data and update history data of a database, in which copy data of each area constituting the database is used as management data of the area. means for storing an identifier that saves the temporal order relationship at the start and end points of acquisition, and an identifier that saves the content of the reorganization or reconfiguration of the area and the time order relationship at the start and end points. , for each target area during database failure recovery, update history data to be used for database recovery is identified based on the identifier that saves the temporal order relationship at each point in time, and the update history data is transferred to the copy data. This is achieved by a database failure recovery method characterized by selecting a reflection method and executing failure recovery processing.

[Effect]

In the database failure recovery method according to the present invention, the data shown in (11) below is stored as area management data for each area constituting the database, and this is used to perform the following (12) to (14). By performing such processing, it is possible to prevent the database from being restored with inappropriate contents due to reflection of inappropriate update history data.

(11) Prepare a location in the external storage device where the next information for that area can be permanently stored.

Backup start time■2 Backup end time■:Reorganization details■:Reorganization start time■:Reorganization end timeNote that the word ``time J'' is an identifier that preserves the temporal order of each point in time. It is used in this sense and is not limited to time.

(12) When backing up, set the start and end times to (11
). Also, ■ above.

IV and V are set to the initial state.

(13) At the time of reorganization, the information necessary to re-execute the reorganization and the start and end times are secured in (11) III.
, rV, set to V.

(14) The outline of the recovery operation in the event of a database failure is as shown in the flowchart of FIG. This will be briefly explained below.

Identify the area to be recovered (step 1), and read the area management data (step 2). Depending on whether re-editing was performed after the backup, step 3 and following steps (
One of the processes a) and (b) is performed on all areas to be recovered (step 7).

(a) If reorganization has not been performed after backup has been taken, that is, if the above m, rv, and y are in their initial states, (a) Inform the database system operator of the area name to be recovered, and copy data and update history data. is operated so that it becomes accessible (step 4).

(a) For update history data having update times between I and H, only those that have not been reflected in the copy data are overwritten on the copy data based on the before and after update information in the update history data (step 5).

(1) Update history data with an update time after ■ above,
Overwrite the copy data obtained in (a) (Step 6)
.

(b) After backup acquisition, reorganization has been performed, that is, the above I11. If rV and V are not in the initial state, (a) Same as (a) in (a) (step 8).

(b) For update history data with update times between ■ and ■ above, only those that have not been reflected in the copy data are overwritten on the copy data based on the before and after update information (Step 9
).

(1) Reorganize the database based on the above item (1) (step 10).

(1) Update history data with update time after ■ above,
Overwrite the copy data obtained in (step 11)
).

Further, the invention described in claim 2 has the following configuration and operation in addition to the above-mentioned configuration and operation. That is, (21) In (13) above, as reorganization content ■,
Set the area name that will be reorganized at the same time.

(22) In (14) (b) (a) and (i) above, recovery processing is performed not only for the area targeted for failure recovery but also for all areas that need to be reorganized at the same time as set in (11). Perform reorganization processing.

Further, the invention described in claim 3 has the following configuration and operation in addition to the above-mentioned configuration and operation. That is, (31) At the time of backup, the start time is embedded in the copy data.

(32) If the backup start time in the copy data made accessible in (14) (a) (a) is
1) Confirm that the time is the same as the backup start time of I.

Furthermore, the invention set forth in claim 3 has the following configuration and operation in addition to the configuration and operation described above. Namely.

(41) Prepare in advance a location in an external storage device such as a magnetic disk where the following information can be permanently stored as media management data for the media used to store copy data and update history data. .

■: Media name ■2 Used/unused information ■: Connection information (42) In addition to the above (11), prepare a location to store the following information.

■: Copy data storage medium name X: Copy data storage medium connection information XI: Update history data storage medium name Xll: Update history data storage medium connection information (43) When storing copy data or update history data, (41) If the connection information is offline, the name of an unused medium is found, and if the connection information is offline, it is automatically made accessible.

(44) When recovering from a database failure, find the name of the medium on which copy data and update history data are stored from (42),
The corresponding medium is automatically made accessible based on the connection information.

〔Example〕

Embodiments of the present invention will be described in detail below with reference to the drawings. Note that the embodiments described below are embodiments corresponding to claims 1 and 2 described above.

FIG. 2 is a diagram showing the overall configuration of a database system that is a first embodiment of the present invention. In the figure, 101 is a processor, 102 is a main storage device, 108 is a copy data file, 109 is an update history data file, 1
10 is an area table file, Ill is a database definition file, 112 is a database, and 113 is a console. Also, in the main storage device 1.02, a backup processing program 103. Reorganization processing program 1o4. Database management system 1o5. Database initialization program 106. A database failure recovery program 107 is stored.

FIG. 3 shows the configuration of an area table that is stored in the area table file 110 and is a collection of management information for one area of a certain database. In the figure, 201 is an area identifier for specifying an area, 202 is an identifier at the backup start point (hereinafter referred to as "time"), 203 is the backup end time, 204 is the number of reorganizations, and 205 is the content of the reorganization. This information allows reorganization to be executed. Furthermore, if the relevant area and another area are processed as reorganization targets at the same time, the area identifier of the other area shall be included. 206 is the start time of reorganization, and 207 is the end time of reorganization. 205.206.207 is 2
Approximate number of times of reorganization of 04 exists.

It is stored in the update history data file 109. FIG. 4 shows the structure of update history data information. In the figure, 401 is the database update time, and 402 is update history data, which includes the contents of the database before and after the update, as in the past. It is also assumed that the update history data is arranged in the update history data file 109 so that it can be taken out in the order of database update time.

Conventionally, the database initialization program 106 includes:
It was a progera that initialized the database 112. In this embodiment, in addition to this, the area table file 110 for registering area tables for all areas constituting the database is initialized. The outline of this process will be explained based on FIG.

The database initialization program 106 reads the definition information of the database to be initialized from the database definition file 111 shown in FIG. 2, and initializes the database (steps 501 and 502). Thereafter, the initialized area table for each area constituting the database is stored in the area table file 110 in FIG. 2 (step 503).

The backup processing program 103 has conventionally been a program for acquiring copy data of a database. In this embodiment, in addition to this, processing is performed to set backup start and end times in the area table of the area that has been backed up. An overview of this process is
This will be explained based on FIG.

The backup processing program 103 shown in FIG. 2 obtains the copy data acquisition start time of the target area in the database (step 601), and then obtains the copy data from the database 112 (step 602).
. Thereafter, after obtaining the copy data acquisition end time (step 603), the copy data is written to the copy data file 108 in FIG. 2 in step 604.

Next, the area table for the area where the copy data has been acquired is read from the area table file 110 in FIG.
Step 605). The value obtained in step 601 is set as the backup start time in the area table, and the value obtained in step 603 is set as the backup end time (step 606).

The number of reorganizations 204 shown in FIG. 3, which is reorganization information in the area table. Reorganization details 205. Reorganization start time 2
06. After initializing the reorganization end time 207 (step 607), the area table is saved in the area table file 110.
(step 608).

As another example of backup processing, the processing overview when multiple database areas are to be backed up is as follows.
This will be explained based on FIG.

In step 701, the area table of all areas to be backed up is read from the area table file 110.

Next, find the backup start time (step 70).
2). In the process of step 702 from the second time onward, the end time obtained in the previous step 704 may be used as the current start time. After obtaining the copy data of one area to be backed up in the database 112 (step 703
), find the end time (step 704), and write it to the copy data file 108 (step 705). next,
The time obtained in step 702 is used as the backup start time 201 in the area table for the area, and
After setting the time obtained in step 704 as the backup end time 202 (step 706), the reorganization count 204 in the area table, which is reorganization information, is set. Reorganization details 2
05° Reorganization start time 206. Initialize the reorganization end time 207 (step 707), determine whether the backup has been completed for all areas to be backed up (step 708), and if not, perform the processing from step 702 onward for the next area. If completed, the area table of all areas targeted for backup is written to the area table file 110 (step 70).
9).

The reorganization processing program 104 has conventionally been a program that expands the capacity of the database area, organizes and organizes the data storage state, or reconstructs the database due to a partial change in the database definition. Ta. In this embodiment, in addition to this, processing is performed to set information regarding reorganization in the area table corresponding to the area targeted for reorganization. The outline of this process will be explained based on FIG.

After determining the start time of reorganization (step 801), the reorganization processing program 104 performs database reorganization processing according to the reorganization purpose for which the reorganization processing program was started (step 802). Next, the reorganization end time is determined (step 803). The area tables for all areas to be reorganized are read from the area table file 110 (step 804), and the number of reorganizations, which is reorganization information in each area table, is counted up (step 8).
05). Furthermore, information indicating the contents of the reorganization, which collects the information necessary to perform the same operation as the reorganization performed this time, is set (step 806), and the value obtained in step 801 is set as the reorganization start time. , the value obtained in step 803 above is set as the reorganization end time (step 807).

Thereafter, it is determined whether or not the setting of reorganization information has been completed for all areas (step 808); if not, steps 805 and subsequent steps are performed. If completed,
The entire area table is stored in the area table file 110 (step 809).

Note that in this embodiment, the area to be reorganized is
It is assumed that, before starting the reorganization program, a blockage state has been established in the database management system 105 in which access to the database to that area is prohibited by a user's operation instruction means such as an operator command. .

Next, FIG. 9 shows an embodiment in which the reorganization program has a function of notifying the database management system 105 shown in FIG. 2 of blockage of an area to be reorganized during execution of the reorganization program. The explanation will be based on.

In step 901, the database management system is asked to block an area that is subject to one reorganization. At this time, if it is necessary to perform one reorganization process on a plurality of areas at once, blockage of all these areas is required.

Next, the reorganization start time is determined (step 902), and reorganization processing is performed (step 903). After determining the reorganization end time (step 904), the database management system 105 is requested to release the blocked area (step 905).

Thereafter, the reorganization information is set in the area table of the reorganization target area corresponding to steps 804 to 805 shown in FIG. 8 (step 906). It is determined whether or not all areas have been reorganized in accordance with the startup purpose of the reorganization processing program (Step 907). If there are any areas that have not been reorganized, steps 901 and subsequent steps are performed; if all have been performed, the relevant processing is performed. end.

The operation of this embodiment configured as described above will be explained below.

FIG. 10 is a flowchart showing the operation of database failure recovery. When the database management system 105 detects a database failure during database access (step 1001), the database management system 105 specifies all area identifiers included in the medium in which the failure has occurred from the database definition in the database definition file 111.
002), the database failure recovery program 107 is started in step 1003. Note that, as in the past, the system notifies the user via the console or the like when a database failure occurs or when the recovery is completed.

An overview of the processing of the database failure recovery program 107 will be explained based on FIG. 11.

When started, the database failure recovery program 107 reads the area table of the area where the database failure has occurred from the area table file 110 (step 1).
101). The area identifier to be recovered is sent to the console 1.
13 to notify the database system operations manager. After that, the copy data and update history data are
Wait until it can be accessed from the database management system (step 1102), step 1103
Then, it is determined whether the number of reorganizations in the area table is the initial value, and if it is not the initial value, steps 1108 and subsequent steps are executed.

In addition, if it is the initial value, the update history data file 1
09, the database update time shown in FIG. 4 401 reads update history data after the backup start time (step 1104). It is determined whether or not the corresponding data exists (step 1105), and if it does not exist, steps 1107 and subsequent steps are performed. If the data exists, the update history data is reflected in the copy data (step 1106), and then steps 1104 and subsequent steps are performed. implement.

In step 1107, it is determined whether or not another area subject to automatic database failure recovery exists. If not, the process ends; if it exists, steps 1101 and subsequent steps are executed.

On the other hand, in step 1108, after setting the counter I to 1, update history data up to the I-th reorganization start time is read (step 1109), and in step 1110, it is determined whether or not the corresponding data exists, If it does not exist, execute steps 1112 onwards; if it does exist, reflect the update history data in the copy data (step 1111)
, execute steps 1109 and subsequent steps.

In step 1112, reorganization is performed based on the I-th reorganization contents shown at 205 in FIG.

Next, it is determined whether or not the 1st+1st reorganization has been carried out (step 1113), and if it has been carried out, 1 is added to the force untae (step 1117), and then steps 1119 and subsequent steps are carried out. If reorganization has not been performed, update history data after the I-th reorganization end time is read (step 1114). It is determined whether or not the corresponding data exists (step 1115). If the data does not exist, steps 1117 and subsequent steps are performed. If the data exists, the update history data is reflected in the copy data (step 1116).
), steps 1114 and subsequent steps are performed.

The contents of the process of reflecting the update history data to the copy data in each of the above steps 1106, 1111, and 1116 are described in the first step.
This will be explained based on FIG.

In step 1201, it is determined whether the update time 401 of the update history data shown in FIG. 4 is between the backup start and end times shown at 202 and 203 in FIG. For example, step 1204 and subsequent steps are executed. If a backup is in progress, check whether the copied data and the pre-update data match or not in step 1.
202), if there is a mismatch, the updated B calendar data is ignored because the copied data has been taken after the update. If they match, the update history data is overwritten on the copy data (step 1203).

In step 1204, as in step 1202, it is determined whether the copy data and the update data match or not. If they do not match, it is assumed that inappropriate update history data is included, and error processing is performed ( Step 120
5) End the process. If they do not match, step 1203 and subsequent steps are executed.

In the embodiment shown in FIG. 11, a case has been shown in which the reorganization processing executed during the database failure automatic recovery processing can be performed for each area to be recovered. An embodiment in which the processing targets a plurality of areas at the same time, such as an index area and a data area, will be described with reference to FIGS. 13 and 14.

In step 1301, the area table of the area where the database failure has occurred is read from the area table file. The area identifier is displayed on the console 113 in FIG. 2 and notified to the database system operations manager. Then, it waits until the copy data and update history data can be accessed from the database management system (step 1302).

In step 1303, it is determined whether the number of reorganizations in the area table is the initial value, and if it is not the initial value, recovery processing including reorganization is performed (step 1308), and then steps 1307 and subsequent steps are performed. If it is the initial value, read the update history data after the backup start time (Step 1)
304), it is determined whether the corresponding data exists or not (Step 1305), and if it exists, the update history data is reflected in the copy data (Step 1306), and then Step 1
Execute steps 304 onwards. If it does not exist, it is determined whether there is another area that has not been recovered from the database failure (step 1307); if it exists, step 1304)
Perform the following steps, and if the program does not exist, terminate the processing of the program.

The processing contents of step 1308 in FIG. 13 will be explained based on FIG. 14.

In step 1401, after setting the counter I to 1, areas that need to be reorganized simultaneously are identified from the first reorganization content 205 in the area table (step 14
02), first reorganization start time 2 in area table
Read update history data up to 06 (step 1403
). Step 1: Determine whether the relevant data exists or not.
404), if it exists, the updated B calendar data is reflected in the copy data (step 1405), and then step 1403
Perform the following steps. If it does not exist, it is determined whether there is another area that needs to be reorganized at the same time (step 1406). If it does not exist, steps 1410 and subsequent steps are executed, and if it exists, the area table for the area is already set. It is determined whether or not it has been read (step 1407). If the area table has been read, steps 1409 and subsequent steps are executed, and if the area table has not been read, the area table is read from the area table file 110 (step 1408).

Thereafter, after displaying the area identifier of the area on the console 113, the process waits until the copy data and update history data become accessible (step 1409). Once access is possible, steps 1403 and subsequent steps are performed.

In step 1410, reorganization is performed based on the I-th reorganization content 205 shown in FIG. After that, it is determined whether the number of reorganizations in the area table is smaller than I+1 (step 1411), and if it is not, 1 is added to the counter.
After adding (step 1415), step 1402
Perform the following steps. If it is smaller, the update history data after the I-th reorganization end time 207 in the area table is read (step 1412), it is determined whether the corresponding data exists or not (step 1413), and if it exists, the update history data is read. After reflecting the data in the copy data (step 1414),
Step 1412 and subsequent steps are performed. If it does not exist, the process ends.

Note that the details of the processing in step 1306 in FIG. 13 and steps 1405 and 1414 in FIG.
Shown in the figure.

Next, another embodiment of the present invention will be described.

The embodiment described below corresponds to claim 3, and includes the overall system configuration, area table,
The configuration of the update history data is similar to that shown in FIGS. 2 to 4 above.

In this embodiment, a place is provided in the copy data corresponding to each area of the copy data file 108 to set the copy data start time. FIG. 15 shows a specific example of the configuration. FIG. 15 is an example in which a place for setting the copy data start time is provided in the first page among a group of management unit pages obtained by further dividing the database area. Note that the present invention does not depend on the management method in the database area or the setting location of the copy data start time, but it is sufficient to determine when the relevant copy data was acquired at the time of database failure recovery.

In addition, the database initialization program 1 shown in FIG.
06. The processing contents of the reorganization processing program 104 are the same as those shown in FIGS. 5, 8, and 9, respectively.

First, backup processing program 1 in this embodiment
The processing contents of step 03 will be explained based on FIG. In the process shown in this figure, in addition to the process shown in FIG. 6 in the previous embodiment, a process for embedding the copy data acquisition start time in the copy data (step 1504)
is the process of writing the copy data to the copy data file (
is added before step 1505).

Similarly, processing contents corresponding to the processing shown in FIG. 7 in the above-mentioned embodiment will be explained based on FIG. 17. In the process shown in this figure, in addition to the process shown in FIG. 1606).

Next, a database failure recovery method will be explained in comparison with the above embodiments corresponding to claims 1 and 2.

Database failure recovery program 1 shown in Figure 11
07 will be explained based on FIG. 18. In the process shown in this figure, in addition to the process shown in FIG. 11, copy data and update history data are made accessible in step 1702. After waiting until 1703), it is determined that the backup start time in the copy data that has become accessible matches the backup start time 202 in the area table of FIG. 3 regarding the area. If yes, step 1705
If the following steps are performed and there is a mismatch, a message requesting proper copy data is displayed on the console, the process waits until access becomes possible (step 1704), and then processing is added to perform steps 1703 and subsequent steps again.

Steps 1708.1713.1718 shown in FIG.
The detailed processing contents are the same as shown in FIG. 12 above.

The processing contents corresponding to FIG. 13 in the embodiment will be explained based on FIG. 19.

In the process shown in this figure, in addition to the process shown in FIG. 13, after waiting until the copy data and update history data become accessible (step 1802), the backup start time in the copy data that has become accessible is determined. It is determined that the backup start time 202 in the area table shown in FIG. A message requesting data is displayed on the console, the process waits until the primary copy data becomes accessible (step 1804), and the process of performing step 1803 and subsequent steps is added again.

The processing contents corresponding to FIG. 14 in the embodiment will be explained based on FIG. 20.

In the process shown in this figure, in addition to the process shown in FIG. 14, after waiting until the copy data and update history data become accessible (step 1909), the backup start time in the copy data that has become accessible is It is determined that the backup start time 202 in the area table shown in FIG. A message requesting data is displayed on the console, the process waits until the next copy data becomes accessible (step 1911), and the process of performing step 1910 and subsequent steps is added again.

Note that step 1808 in FIG. 1.9 in Figure 20
The detailed processing contents of 05°1916 have already been shown in FIG.

Next, another embodiment of the present invention will be described.

The embodiment described below corresponds to claim 4, and the overall system configuration is as shown in FIG. 21. In the figure, 2001 is a processor, 20
02 indicates a main storage device, 2003 a backup processing program, 2004 a reorganization processing program, 200
5 is a database processing system, 2006 is a database initialization program, 2007 is a database failure recovery program, and 2008 is a media management file;
010 is an area table file, 2011 is a database definition file, 2012 is a database, 2009 is a storage device for media that stores copy data and update history data, and 2013 is a message that informs the user of the occurrence of a database failure, its automatic recovery, termination, etc. Shows a console for communicating.

The configuration of the update history data information in the medium storage device 2009 is the same as that shown in the previous embodiment.

Further, it is assumed that the copy data in the medium storage device 2009 includes a backup start time similar to that shown in the above embodiment.

The structure of the area table file 2010 is shown in FIG. 22. In the figure, 2101 is an area identifier for specifying an area, 2102 is a backup start time, 2103 is a backup end time, 2104 is a backup medium identifier for specifying a medium on which copy data is stored, 2
105 is backup medium connection information, and 2106
is the number of times of reorganization, and 2107 is information indicating the contents of reorganization, and it is assumed that the reorganization can be executed based on these. In addition,
When this area and another area are processed as reorganization targets at the same time, the other area's toy identifier shall be included.

2108 is a reorganization start time, 2109 is a reorganization end time, 2110 is an update history data medium identifier for identifying the medium in which update history data is stored, 2111
is the connection information of the update history data medium. Among these pieces of information, reorganization content 2107. Reorganization start time 210
8, the reorganization end time 2109 is the number of reorganizations 210
Only 6 pairs exist. Also, backup media identifier 2
104 , backup medium connection information 2105 and update history data medium identifier 2110 . Each set of connection information 2111 for update history data media exists as many as there are media.

Note that the media storage device 2009 is a storage device for media that stores copy data and update history data, and is like an automated warehouse, and is usually in an offline state where data on the media cannot be accessed directly. managed.

Upon receiving information identifying the medium and a signal requesting to make it accessible, the device shall bring the medium into an accessible online state.

Further, the medium management file 2008 is a management information file for a medium that stores copy data and update history data.
The configuration example of the media information table for that one medium is shown in the second section.
Shown in Figure 3. In the figure, 2201 is a medium identifier for identifying the medium, 2202 is information indicating whether the medium is used or not,
Connection information 2203 indicates whether the medium is connected to the CPU in an immediately accessible state. In this embodiment, when the medium is in the medium storage device 2009,
It is distinguished from a normal external storage device that can be accessed immediately because it cannot be accessed immediately.

Note that the processing contents of the database initialization program 2006 and the reorganization processing program 2004 are as described in the fifth section above.
8 and 9.

Further, regarding the processing contents of the backup processing program 2003 corresponding to FIG. 16 in the above-mentioned embodiment,
This will be explained based on FIG. 24. In the processing of the backup processing program 2003 in this embodiment, the first
Prior to the process shown in FIG. 6, a process (step 2301) is performed to make the medium in the storage device 2009 that stores the copy data accessible. Step 1 in Figure 16
In process 2306 corresponding to step 505, the write destination of the copy data becomes the copy data storage medium that became accessible in step 23o1.

In process 23o8 corresponding to step 1507 in FIG. 16, in addition to backup start and end times, a medium identifier and connection information are set as information regarding the backup medium. Similarly, step 1508 in FIG.
In process 23o9 corresponding to , in addition to information regarding reorganization, storage medium information for update history data is initialized.

Furthermore, after the process shown in FIG.
11) is implemented.

The detailed processing contents of step 2301 will be explained based on FIG. 25.

In step 2401, the medium information table of an unused medium is read from the medium management file 2008 shown in FIG. 21, and in step 2402, the medium usage information 22o2 of the medium information table shown in FIG. 23 is set to the used state. ,
In step 2403, it is stored in a media management file. Next, the medium corresponding to the medium identifier in the medium storage device of FIG. 21 is made accessible (step 240
4).

Similarly, the process corresponding to FIG. 17 will be explained based on FIG. 26.

In the process shown in this figure, in addition to the process shown in FIG. 17, a process for making the copy data storage medium accessible (step 2502) is added before determining the backup start time. Furthermore, when setting the area table for the area, a copy data medium identifier is set in addition to the backup start/end time (step 2508), a process 2507 corresponding to step 1606 in FIG.
The copy data write destination becomes the copy data storage medium that became accessible in step 2502. Also, the second
Figure 4 step 2308.

Similarly to 2309, in steps 2508 and 2509, the area table is reset.

Furthermore, before determining whether all the backup target areas have been backed up.

Processing (step 2510) of storing the copy data storage medium in the storage device 2009 is performed.

The detailed processing content of step 2502 in FIG.
This is the same as Figure 5.

Next, a database failure recovery method will be explained.

The processing contents after the database management system 2005 detects a failure shown in FIG. 21 are the same as those shown in FIG. 10 for the above-described embodiment. Note that the process of storing database update history data in an external storage device by the database management system 2005 during database service is as shown in FIG.

In step 2601, the area table of the area accessed when starting the database service is read from the area table file. Next, in step 2602, it is determined whether the medium in which the update history data is to be stored has been determined. If the medium has been determined, steps 2609 and subsequent steps are executed; if not, the medium information table is read from the medium management file 2008. (
Step 2603). If it is loaded, step 260
5 and subsequent steps, and if the media information table has not been read, the media information table is read from the media management file (step 2604).
).

In step 2605, a medium is selected whose medium usage information 2202 shown in FIG. Then, it is determined whether the connection information 2203 of the medium is in an immediately accessible state, and if it is in an immediately accessible state, step 260 is performed.
If steps 9 and subsequent steps are performed and it is necessary to make the medium accessible, a signal is sent to the medium storage device 2009 in FIG. 21 to make the medium accessible (step 260).
8).

In step 2609, the history data medium identifier 2110 (see FIG. 22) of the area table and its connection information 211 are checked for all areas covered by the update history data.
Set 1 as the medium information. However, if the same medium has already been set, do not set it.

Next, an overview of the processing of the database failure recovery program 2007 will be explained based on FIG. 28.

When this program is started, it reads the area table of the area where the database failure has occurred from the area table file (step 2701). Next, all the media storing the copy data for the area to be recovered are determined from the backup medium identifier 2104 in the area table, and the media are made accessible based on the connection information (step 2702).

Next, in step 2703, it is verified whether the backup start time embedded in the copy data matches the backup start time in the area table, and if they match, steps 2704 and subsequent steps are executed. If there is a mismatch, error processing is performed in step 2720, and the processing is ended.

In step 2704, it is determined whether the number of reorganizations in the area table is the initial value, and if it is not the initial value, steps 2709 and subsequent steps are executed. If it is the initial value, all media storing update history data are found from the update history medium identifier 2110 in the area table, and the medium is made accessible based on the connection information 2111 (step 2705
), then update history data having an update time after the backup start time is read (step 2706). Step 2707) to determine whether or not the corresponding data exists;
If it does not exist, execute step 2719 and subsequent steps, and if it does exist, after reflecting the update history data in the copy data (
Step 2708), return to step 2706.

In step 2719, it is determined whether or not another area subject to automatic database failure recovery exists. If not, the process ends; if it exists, the process returns to step 2701.

On the other hand, in step 2709, after setting the counter to 1, update history data up to the first reorganization start time is read (step 2710). It is determined whether or not the corresponding data exists (step 2711), and if it does not exist, steps 2713 and subsequent steps are performed. If the data exists, the update history data is reflected in the copy data (step 2711).
712), return to step 2710. Step 2713
Now, reorganization is performed based on the I-th reorganization contents shown at 2107 in FIG.

Next, it is determined whether or not the 1st+1st reorganization has been carried out (step 2714). If it has been carried out, 1 is added to the counter (step 2715), and then the process returns to step 2710. If reorganization has not been carried out, the update history data after the I-th reorganization end time is read (step 2716), and it is determined whether the corresponding data exists (step 2717); if not, step 2719). After performing the following steps, and if the update history data exists, the update history data is reflected in the copy data (step 271).
B), return to step 2716.

The contents of the process of reflecting the update history data to the copy data in steps 2708, 2712, and 2718 in FIG. 28 are as follows.
This is the same as shown in FIG. 12 above.

The above-described embodiment shown in FIG. 28 shows a case where the reorganization process executed during the automatic database failure recovery process can be performed for each area to be recovered. An example in which the reorganization process executed in the automatic recovery process targets multiple areas at the same time, such as an index area and a data area, will be described based on FIGS. 29 and 30. do.

In step 2801, the area table of the area where the database failure has occurred is read from the area table file. Next, all the media on which copy data for the area to be recovered is stored are determined from the backup media identifier 2104 in the area table, and the media is made accessible based on the connection information (step 2802). Next, it is verified that the backup start time embedded in the copy data and the backup start time in the area table match (step 2803), and if they match, steps 2804 and subsequent steps are performed. If they do not match, error processing is performed (step 2810), and the processing ends.

In step 2804, it is determined whether the number of reorganizations in the area table is the initial value, and if it is not the initial value, recovery processing including reorganization is performed (step 2811), and then steps 2809 and subsequent steps are performed. If it is the initial value, all media storing update history data are found from the update history medium identifier 2110 in the area table, and the medium is made accessible based on the connection information 2111 (step 2805).
. Next, update history data after the backup start time is read (step 2806), and it is determined whether the corresponding data exists (step 2807). If the update history data exists, the update history data is reflected in the copy data (step 2808), and then the process returns to step 2806. If the database does not exist, it is determined whether there is another area that has not been recovered from the database failure (step 2809); if it exists, the process returns to step 2801; if it does not exist, the processing of this program ends.

The processing contents of step 2811 shown in FIG.
This will be explained based on Figure 0.

In step 2901, after setting the counter ■ to 1,
After identifying the areas that need to be reorganized at the same time from the I-th reorganization content 2107 in the area table shown in FIG. 22 (step 2902), step 28
Similarly to Step 2905, the update history data storage medium is made accessible (step 2903).

Next, the update history data up to the first reorganization start time in the area table shown in FIG. 22 is read (step 2904), and it is determined whether or not the corresponding data exists. If so, after reflecting the update history data in the copy data (step 2906
), the process returns to step 2904. If it does not exist, it is determined whether there is another area that needs to be reorganized at the same time (step 2907); if it exists, it is determined whether the area table for the area has already been read (step 2907).
Step 2908). If it has been loaded, step 2910
The following steps are performed, and if the area table has not been read, the area table is read from the area table file 2010 (step 2909).

Next, similarly to step 2802, the copy data storage medium is made accessible (step 2910).

After that, similarly to step 2803, the appropriateness of the copy data is verified (step 2911), and if it is appropriate, the process returns to step 2903; if it is inappropriate, error processing is performed (
Step 2912), the process ends.

In step 2913, reorganization is performed based on the I-th reorganization content 2107 shown in FIG. After that, it is determined whether the number of reorganizations in the area table is smaller than I+1 (step 2914), and if it is not, it means that another reorganization has been performed, so after adding 1 to the counter (
Step 291.8), return to step 2902. If it is smaller, update history data after the first pair formation end time 2109 in the area table is read (step 2915). Next, it is determined whether or not the corresponding data exists (Step 2916), and if it exists, the update history data is reflected in the copy data (Step 2917).
Return to step 2915. If it does not exist, the process ends.

Note that the processing contents in steps 2906 and 2917 in FIG. 29 are the same as those shown in FIG. 12 above.

Finally, as an example corresponding to claim 4, a case will be described in which the medium for storing update history data and the medium storage device for storing the data are different.

FIG. 31 shows an overall configuration diagram. Compared to each of the embodiments described above, an update history data copy program 3008 and an update history data file 3010 are added.

In this embodiment, the database management program shown in FIG. 24 does not directly store update history data in the media storage device during database service.
Normally, update history data is stored in a storage device such as a semiconductor disk or a magnetic disk, that is, an update history data file 3010 shown in FIG. 31, as in the past. When the file becomes full, or according to instructions from the database system operations manager, the update history data copying program 3008 shown in FIG.
Move to 4.

The processing contents of the update history data copy program 3008 are as follows:
This will be explained based on FIG. 32.

In step 3101, an unused medium is determined from the medium information table in the medium management file 3009 shown in FIG. The medium usage information in the medium information table is set to a usage state (step 3102).

Next, after making the medium in the medium storage device 3014 accessible (step 3103), the update history data in the update history data file 3010 shown in FIG. 31 is transferred to the medium (step 3104). Thereafter, the medium is stored in the medium storage device (step 3105), and the process ends.

The processing contents of other programs in FIG. 31 are the same as in each of the above-described embodiments.

According to the above embodiment, conventionally, when a database failure occurs after the database is reorganized and before copying data is completed, the problem occurs depending on whether the area to be reorganized is not available, whether the database update is before or after the reorganization, etc. 1 Recovery work becomes complicated and time-consuming as it is necessary to use different recovery data and methods. The database service could not be restarted until after the acquisition, but by automating the recovery work including reorganization, it becomes possible to restart the database service immediately after the reorganization.

Note that in the above embodiment, an example is shown in which time is used as an identifier for preserving the temporal order relationship. The specific content may be expressed in absolute time such as 2:02:02 on February 2nd, milliseconds, microseconds, nanoseconds, or as a total time based on an arbitrary starting point. good. Further, in a computer system having a multiprocessor configuration, when each processor has a different time, correction information between each time may be included as a component of each time.

It goes without saying that this may be used as an identifier for preserving the above-mentioned temporal order relationship in a system that assigns a processing execution total number to each database service, that is, each transaction. In this case, the start or end time of copy data acquisition may be substituted with an execution total number added to transactions started after that time.

Furthermore, it goes without saying that the present invention is not limited to the above embodiments.

〔Effect of the invention〕

As described in detail above, according to the present invention, in a database system that performs failure recovery based on copy data and update history data of a database, management data of the area is stored in units of areas constituting the database. , an identifier that saves the chronological order relationship at the start and end points when copying data of the area was acquired, and an identifier that saves the contents of the reorganization or reconfiguration of the area and the chronological order relationship at the start and end points. and identifying update history data to be used for database recovery based on an identifier that preserves the temporal order relationship at each point in time for each target area during database failure recovery;
Since failure recovery processing is executed by selecting a method for reflecting the update history data in the copy data, it is possible to reduce the burden on the database system operation administrator and enable high-speed failure recovery. This has the remarkable effect of realizing a recovery method.

[Brief explanation of the drawing]

FIG. 1 is a processing flowchart outlining the operation of the present invention, FIG. 2 is an overall configuration diagram of the first embodiment, FIG. 3 is a configuration diagram of an area table, and FIG. 4 is a configuration diagram of update history data information. , FIG. 5 is a processing flowchart of a database initialization program, FIG. 6 is a flowchart of a backup processing program, FIG. 7 is a flowchart of a backup processing program that targets multiple areas, FIG. 8 is a flowchart of a reorganization processing program, FIG. 9 is a flowchart of a reorganization processing program having an area closing function.
0 is a processing flowchart of the database management system when a database failure is detected, FIG. 11 is a processing flowchart of the database failure recovery program, and FIG. 12 is a processing flowchart of the process of reflecting the update history data in the copy data in FIG. 11. Figure 13 is a processing flowchart of a database failure recovery program that includes reorganization that targets multiple areas at the same time, Figure 14 is a flowchart of recovery processing that includes reorganization in Figure 13, and Figure 15 is a second implementation. Configuration diagram of the copy data file used in the example, No. 16
The figure is a flowchart of a backup processing program corresponding to the second embodiment, and FIG. 17 is a flowchart of a backup processing program that targets the same plurality of areas.
Figure 8 is a processing flowchart of the database failure recovery program, Figure 19 is a processing flowchart of the database failure recovery program that includes reorganization that targets multiple areas at the same time, and Figure 20 includes the reorganization shown in Figure 19. A flowchart of the recovery process, FIG. 21 is an overall configuration diagram of the third embodiment, FIG. 22 is a configuration diagram of an area table used in the third embodiment, FIG. 23 is a configuration diagram of the same medium information table, and FIG. FIG. 24 is a flowchart of a backup processing program corresponding to the third embodiment, and FIG. 25 is a flowchart 1 of the process of making the medium in FIG. 24 accessible.
Fig. 26 is a flowchart of the backup processing program that targets the same multiple areas, Fig. 27 is a flowchart of the storage process of the database update history data, Fig. 28 is a processing flowchart of the database failure recovery program, and Fig. 29 is the same. A processing flowchart of a database failure recovery program including reorganization that targets multiple areas at the same time, FIG. 30 is a flowchart of the recovery processing including reorganization in FIG. 29, and FIG. 31 is the overall configuration of the fourth embodiment. 32 are processing flowcharts of the update history data copying program. 101.2001,3001: CPU, 102,
2002.3002: Main storage, 103, 2003
, 3003: Backup processing Progera 11.104
, 2004, 3004: Reorganization processing program, 10
5.2005,3005: Database management system, 106゜2006.3006: Database initialization program, 1o7゜2007.3007: Database failure recovery program, 108: Copy data file, 109,3010: Update history data file, 11
．． 0, 2010, 3011: area table file,
111,2011,3012: Database definition file, 112,2012,3013: Database, 113゜2013.3015: :l n'/-/
L/, 2008, 3009: Media management file, 20
09,3014: Media storage device, 3008: Update history data copy program. Patent applicant: Hitachi Seisaku Shinken Co., Ltd. 2 Figure 3 Figure 4 Figure 5 Figure 6 Figure 7 Figure 8 Figure 9 Figure 10 Figure 12 Figure 16 Figure 17 Figure 27 Figure 21 Figure 24 Figure 25 Figure 31 Figure 32

Claims (1)

[Claims] 1. In a database system that performs failure recovery based on copy data and update history data of a database, for each area constituting the database, copy data of the area is stored as management data of the area. means for storing an identifier that saves the temporal order relationship at the start and end points of acquisition, and an identifier that saves the content of the reorganization or reconfiguration of the area and the time order relationship at the start and end points. , at the time of database failure recovery, for each target area, identify update history data to be used for database recovery based on the identifier that saves the temporal order relationship at each point in time, and transfer the update history data to the copy data of the update history data. A database failure recovery method is characterized in that failure recovery processing is executed by selecting a reflection method. 2. A means is provided to store the name of an area that needs to be reorganized or reconfigured at the same time as management data of the area, and the area to be recovered is recognized based on the area name when recovering from a database failure. A database failure recovery method according to claim 1, characterized by: 3. Provide means for embedding an identifier that preserves the temporal order relationship at the time of acquisition start in the copy data of the area as management data of the area, and when recovering from a database failure,
A database failure recovery method according to claim 1 or 2, characterized in that the validity of the copy data to be used is verified. 4. For each medium storing copy data and update history data of the database, a means is provided for storing the medium name, its usage status, and connection information as management data of the medium, and as management data of the area, Claim 3, characterized in that means is provided for storing the storage medium name of the copy data and update history data of each area, and when the database is restored, the medium is allocated based on both of the management data. Database disaster recovery method.