JPH0350648A - Fault restoration method for data base - Google Patents

Abstract

PURPOSE:To shorten time required for a restoration processing at the time of a fault in a data base by extracting data base update journal from a journal file and sorting them in the order of physical addresses on the storage medium of the data base. CONSTITUTION:It is assumed that the fault occurs in an area B20-B after the processing of a transaction 3(200-3). At that time, the data base update journal on the area B20-B is integrated and sorted so as to generate an integration journal file 50. Namely, the data base update journals on the area B are extracted from respective magnetic tapes 30-a and 30-b and are sorted in the order of the physical addresses on the storage medium storing the area B of data to be updated. The order of the physical addresses of update data in the area B is b1, b3 and b2 and the update journals as against them are sorted in the order. Then, the content of a backup file B40-B in the area B is copied in a standby volume 70 at the time of the fault in the data base. Then, the area B is restored on the volume 70 at last.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to a database failure recovery method in a database system.

[Conventional technology]

In a database system, it is necessary to recover the contents of a database in case of a database failure such as a hardware failure of a medium such as a magnetic disk storing the database or logical destruction of the database contents due to a software error. For this reason, database failure recovery has conventionally been performed using the following method. That is, when the database is updated while the system is running, database update history information is recorded in a journal file, and the contents of the database are periodically copied to a backup file such as a magnetic tape.
In the event of a database failure, after copying the contents of the backup file to the area where the failure occurred (in the case of a media failure, to a newly allocated area on another medium), the update history information of the database recorded since the backup file was created is The database is recovered by sequentially reading the journal files and updating them in the order in which they were previously performed (for example, Yutaka Ohno (ed.), Software for the Pa-Online System'', Sangyo Tosho, 1977148-1).
(See page 49).

[Problem that the invention seeks to solve]

The above conventional technology has a problem in that database failure recovery processing requires a long time for the reasons described below.

(1) Read and process the database update history information in the journal file in the order in which it was recorded during normal system operation. At this time, it is necessary to determine whether or not each transaction is completed based on the presence or absence of history information indicating processing completion/cancellation for each transaction, and to recover so that only the update results of completed transactions are reflected in the database. Therefore, even when necessary database update history information is stored on multiple volumes of media such as magnetic tapes, it is necessary to process the information sequentially in chronological order, and the above-mentioned manual processing takes a long time.

(2) Since the database is restored in the order in which it was updated during normal processing during system operation, access to the database becomes random. Further, if the same part of the database is repeatedly updated, each time the update history information of the part is read from the journal file, it is necessary to read the part from the database and write back the updated contents. Therefore, accessing the database takes a long time.

The present invention has been made in view of the above circumstances.

The purpose is to provide a database failure recovery method that significantly shortens the recovery processing time in the event of a database failure.

[Means to solve the problem]

The above objects of the present invention are achieved by the following (1) and (2).

(1) Database update history information necessary for database recovery is extracted from the journal file and sorted in order of physical addresses on the database storage medium. Note that when extracting database update history information from a journal file, a medium such as a magnetic tape that stores history information is divided into a plurality of groups, and database update history information is extracted from each group in parallel. At this time, for each group, for transactions whose history information is stored across multiple groups, whether or not the transaction is completed is stored, and it is determined whether the database update history information extracted from other groups is the history information of a completed transaction. to extract only the necessary database update history information.

(2) Using the database update history information sorted in the order of the physical addresses of the areas of the database to be recovered, the areas are recovered in the order of the physical addresses based on the backup file of the database.

[Effect]

The operation of the above means will be described below.

(1) When extracting and sorting database update M history information, there is no need to process journal files sequentially.
Multiple volumes of magnetic tape, which is the medium for journal files, can be processed in parallel. Therefore, the time required to read database update history information from the journal file can be significantly reduced.

(2) Since the database update history information is sorted in the order of the physical addresses on the database storage medium, when the contents of each page of the database are recovered using the database update history information, each page is accessed in the order of the physical addresses. Therefore, the time required to access each page is shortened.

Furthermore, if the same page has been updated multiple times, this would conventionally require multiple accesses, but by sorting the update history information, the process can be done with a single access.

These allow the time required to access the database to be significantly reduced. Furthermore, since each page of the database is processed in order of physical address, there is a high possibility that pages that are physically close to each other will be processed consecutively.

Therefore, the access time can be further shortened by outputting multiple pages at once.

(Example〕 Embodiments of the present invention will be described below with reference to the drawings.

FIG. 1 is a diagram showing an overview of the operation of the first embodiment, and FIG. 2 is a diagram showing the configuration of the present embodiment.

An overview of the operation of this embodiment will be described below with reference to FIGS. 1 and 2.

The database system 100 records various historical information in preparation for various hardware and software failures. In particular, historical information regarding transaction processing during online system operation is stored in a journal file 3 provided on a magnetic disk, magnetic tape, etc.
0 in the order of processing. The journal file 30 also includes a database update journal for recovering the database in the event of a database 20 failure.

In FIG. 1, the journal file storage medium consists of magnetic tapes 30-a and 30-b, and the journal of transaction l (200-1) is stored on magnetic tape 30-a.
The journals of transaction 2 (200-2) and transaction 3 (200-3) are recorded on magnetic tape 30-b. Transaction 1, 2
and 3, processing requests are generated and processed in that order. Transaction 1 is in database area A.
Data a1 in (20-A) is updated to al', and data bz in database area H (20-B) is updated to b1'. Similarly, transaction 2 is data a2 in area A.
and data b2 of area B are respectively az and b2'
transaction 3 updates data b3 of area B.
is updated to ba'. Database update journals related to these update processes are recorded on the magnetic tapes 30-a and 30-b in the order of update processes. On the other hand, for the database 20, those backup files 4o are created periodically during times when online processing is not being performed, such as at night.
(20-A) backup file A (40-A)
and backup file B of area B (20-8)
(40-B) is created before the start of online processing (process 120).Next, the recovery process in the event of a database failure, which is a feature of the present invention, will be explained. In FIG. 1, a failure occurs in area B (20-8) after the processing of transaction 3 (200-3) is completed. At this time, first, database update journals related to area B (20-B) are accumulated and sorted, and an accumulated journal file 50 is created (processing 130). The database update journals related to the update target data are extracted and sorted in the order of the physical addresses on the storage medium storing the area B of the update target data. In FIG. 1, the physical address order of update data in area B is , ba, b, and the update journals for these are sorted in this order. Copy the contents of backup file B (40-B) in area B (backup restore...process 140).Finally, read the accumulated journal files 50 in area B sequentially from the beginning and use the database update journal to create a backup file. Area B is recovered on the volume 70 (database recovery process 150).

At this time, since the database update journals in the accumulated journal file 50 are sorted according to the physical addresses and responses of the data to be updated, the processing for the spare volume 70 is performed in the order of the physical addresses.

Next, the configuration of this embodiment will be explained. FIG. 2 is a diagram showing the overall configuration of the system in this embodiment, and shows the CPtJ/
A database 20 stored on a magnetic disk or the like is stored in a memory (main storage or virtual storage, hereinafter simply referred to as memory) 10. Journal file 30, backup file 40, database accumulation journal file 5
0, a work file for journal sorting 60, and a spare volume 70 in case of a database failure are connected to the database 20, which is usually a hard drive such as a magnetic disk.
ASD (stored in a direct access storage device, consisting of multiple areas in units of volumes, data sets, etc.) The journal file 30 is a journal file 30 that stores journals necessary for system recovery processing when the system stops due to a failure.
It includes journals used for database failure recovery, journals for recording the contents of business processes, journals used by user programs that perform various business processes, etc. The medium for the journal file 30 is usually a DASD such as a magnetic disk, or a magnetic tape. Since the amount of journal is proportional to the amount of transaction processing, multiple volumes are usually required for one journal file. Furthermore, in the case of DASD, journals that need to be stored for at least several days, such as database update journals, must be unloaded onto magnetic tape. Hereinafter, it is assumed that the medium of the journal file 30 is a magnetic tape, and that each magnetic tape is given a journal sequence number, which is a consistent number from the start of online processing, to identify each magnetic tape. Further, the backup file 40 is a file that stores a backup copy of the database in units of volumes, data sets, etc. in case of a database failure, and usually uses a magnetic tape as the medium.

Next, the operation of the system will be explained by dividing it into normal operation, operation at transaction failure, operation at system failure, operation at backup creation, and operation at database failure.

(1) Normal operation In normal transaction processing, the processing according to the present invention from the start to the end of transaction execution is as follows.

(a) Database update 1 - When updating the database 20 in the runzaktion process, the database system 100 writes a database update journal to the journal file 30 prior to the update;
writes journals related to events such as database updates, message input/output, and transaction completion to the journal file 30 when such events occur.

Each journal record contains management information common to each journal, such as the journal type, journal record serial number, journal write date and time, serial number of the transaction, and record number of the first journal of the transaction, as well as information for each journal type. Consists of unique information. In the case of a database update journal, the above unique parts include the database area name, address information of the updated part,
Journals related to this embodiment, including pre-update information, post-update information, etc., include a database update journal as well as a journal indicating transaction completion/cancellation, which will be described later.

(b) Transaction completion processing When a transaction ends normally, a transaction completion journal is written to the journal file 30.The transaction completion journal has no unique part, and the part indicating the type of journal indicates that it is a transaction completion journal. value.

(2) Operation at the time of transaction failure When canceling the transaction processing result due to a partial failure, the following procedure is performed.

(a) Restoring the database The portion of the database updated by the transaction is restored to its original content using the journal related to the transaction.

(b) Writing a transaction cancellation journal A journal indicating the completion of cancellation processing of the transaction is written to the journal file 30.A transaction cancellation journal, like a transaction completion journal, does not have a unique part, but a part indicating the type of journal is a transaction cancellation journal. The value indicates that

(3) Operation in the event of system failure Among the recovery processes in the event of system failure, the following is related to the present invention:
In zero processing, which is recovery processing for transactions whose processing has been interrupted due to a system failure, database return processing and transaction cancellation journal writing are performed for these interrupted transactions, similar to the transaction failure operation described above.

(4) Operation when creating a backup In preparation for a failure of the database 20, a copy of the database is periodically created in the backup file 40. The time period for creating a backup file is when the online system is stopped, such as at night, or when there are no updates due to online processing. Therefore, when creating a backup during online processing, the relevant area of the database cannot be updated by transactions until the backup creation is completed. If the capacity of the database is large, it is not possible to back up the entire database in - days, so it is grouped by volume or data set, etc., and created on multiple days.

Therefore, the database system 100 associates each backup creation unit with a journal.

As a method of association, in this embodiment, the date and time of backup creation, the record number of the last journal record recorded at the time of completion of backup creation, and the journal sequence number of the magnetic tape containing the record are recorded at the beginning of the backup file. This makes it possible to determine the range of the magnetic tape in which journals necessary for database failure recovery processing are recorded (that is, after backup creation) at the time of failure recovery.

(5) Operation when a database failure occurs A schematic flow of recovery processing when a database failure occurs is shown in FIG. 3. Hereinafter, it will be explained with reference to FIG. 3 assuming that a failure has occurred in area B.

(a) Determination of journal range (step 301) The database system 100 determines the date and time of backup creation, the last journal record number at the time of completion of backup creation, and the journal of the magnetic tape containing the record for each area that is the unit of backup creation. In step 0, where the sequence number is recorded at the beginning of the backup file and associated with the journal, this association allows area B to be
Determine the range of journals required for recovery. In FIG. 3, it is determined that six volumes of magnetic tape numbered 1 to 6 are required.

(b) Accumulation of journals (step 302) Step 3
The journal in area B is extracted from the journals in the range determined in step 01. At this time, by using a plurality of magnetic tape devices, the extraction process is speeded up.For example, in FIG.
Divide into two groups, 4 to 30-6, allocate 11 magnetic tape devices to each group, extract journals from the magnetic tapes of each group in parallel, and output the extracted journals to the database accumulation journal file 50. do. An outline of the extraction process will be explained using FIG. 4. In addition,
In FIG. 4, for convenience of explanation, all database update journals are journals related to QB updates. In the extraction process, database update journals of area B are accumulated on the memory for each transaction, and if the transaction is completed, they are written to the database accumulation journal file 50, and if the transaction is canceled, they are discarded. In the first group 30-1 to 30-3, transaction 4 and transaction 5 have transaction completion journals 404-2 and 405-2 and are completed. Therefore, each database update journal 404-1, 405-1 is written to the aggregate journal file 50. Also, transaction 6 is in the transaction cancellation journal 406-2
Since there is a database update journal 406-
1 is discarded. The same applies to the second groups 30-4 to 30-6. A transaction for which neither a transaction completion journal nor a transaction cancellation journal appears in the magnetic tape of a group is processed as follows.

■Database update journal 4 of the last group transaction 10
10-1 and 410-2, the last group (
In this case, the database update journal of the second group) is.

Since transaction 10 has not been completed, it is discarded without being accumulated.

■ Groups other than the last The database update journal of the group other than the last (in this case, the first group) determines the completion/cancellation of the transaction based on the processing results of the next group,
Process as above. Therefore, when processing a group other than the first group (in this case, the second group), for transactions whose journals span the previous group, the completion/cancellation of the corresponding transaction is stored in the transaction management list 500. 6 For example, in the second group extraction process, for transaction 7, database update journal 4
07-2 is written to the accumulated journal file 50, and the transaction is recorded as a completed transaction in the transaction management list 500. Also, regarding transaction 8, transaction management list 50
0 to indicate that it is a canceled transaction, and when the end of the first group is reached,
With reference to the transaction management list 500, the database update journal 407-1 of transaction 7
is written to the accumulated journal file 50, and the database update journal 408-1 of transaction 8 is discarded.

Note that whether or not the journal of each transaction straddles the previous group can be determined based on the record number of the first journal of the transaction recorded in each journal record. In other words, if the record number of the first journal in the transaction is smaller than the record number of the first journal in the group (in this case, the second group), the transaction straddles the previous group (in this case, the first group). If not, they are not straddled.

(C) Sorting journals (step 303) The database update journals in area B accumulated in step 302 are sorted in ascending order using the physical address of the update data and the journal writing date and time as first and second keys. That is, the updated data is sorted in ascending order of the physical address, and if the physical addresses are the same, it is further sorted in ascending order of the journal write date and time. There are several sorting methods for writing out the sorted journals to the database accumulation journal file 50, but in this embodiment, polyphase merge sorting, which is suitable for sorting journals, is adopted, and a magnetic field is used as the work file for journal sorting. Tape 60-1.60-2°...
, 60-n is used. Journal sorting will be briefly explained below using FIG. 5.

In this step, the 200 MB accumulated journals are sorted using four series of magnetic tapes 60-1 to 60-4. In FIG. 5, the number columns at each stage represent the number of sorted groups on each magnetic tape.First, the accumulated journals (200MB) were sorted in memory in units of just over 1M8, resulting in 193 groups. 81 pieces on the first tape, 68 pieces on the second tape, 4 pieces on the third tape.
Place 4 pieces. There is no fourth tape. In the first stage, the first to third tapes are manually operated, the fourth tape is output, and the sorted groups in the manually operated tapes are merged.

In this way, at each stage, an empty magnetic tape is used as the output, and the journals of other magnetic tapes are sorted and merged, and when any one manual tape becomes empty, the output tape is empty. Switch to the new tape and move on to the next step. Sorting is completed when merging into one series is completed.

In the case of FIG. 5, sorting is completed in eight stages.

(d) Backup paste store (step 304) Backup file B of area B in the spare volume 70
Copy the contents of (40-B).

In Fig. 3, this step is performed after journal sorting (step 303), but in parallel with journal accumulation (step 302) and sorting (step 303), journal range determination (step 301) is performed. You may continue.

(e) Database recovery (step 3o5) Step 3
Database accumulation journal file 5 created in 03
0, the database update journal is read in order from the beginning, the update results are reflected in the spare volume 70, and area B is recovered. Database update journals for the same data (journals with the same physical address of the data to be updated) can also be sorted in ascending order of journal write date and time.
Therefore, the updated information in the journal record can be reflected in the data to be updated sequentially in memory, and then written to the spare volume 70 when the corresponding journal is no longer available. volume 70
When writing to a journal, the validity of the contents of the journal can be checked by comparing the contents of the updated portion with the pre-update information in the journal record. Whether or not to perform a check based on comparison with pre-update information is given as an option for database recovery processing.

As described above, according to this embodiment, the recovery time in the event of a database failure can be significantly shortened. In the embodiment, journals were accumulated and sorted after a database failure occurred, but these processes may be performed in advance during normal times.

That is, for data that is important and requires rapid recovery in the event of a failure, the recovery time in the event of a failure can be further shortened by collecting and sorting the database update journals of the area in advance during normal times.

Furthermore, although the database recovery process was performed after the backup was stored, the database recovery process can be executed directly from the backup file. In other words, in this embodiment, since the journals are sorted in the order of the physical addresses of the updated data, the backup file 4
It is possible to read the contents of 0 in order from the beginning, copy the portions that have not been updated to the spare volume 70 as they are, and write the updated contents of the portions that have been updated to the spare volume 70 using a journal.

Furthermore, in this embodiment, the database update journals related to the same data are reflected in the update data sequentially in the database recovery step (step 3o5), but when journal sorting (step 303), only the last journal is left and the remaining journals are You can also throw away your journal.

Hereinafter, the effects of this embodiment will be estimated using specific examples.

(a) Preconditions (i) Journal grave The amount of journals per day is 30 GB (gigabytes). Then, update the database update journal as part 1/
3, 10GB.

(n) Database size The capacity of the entire database is 100 GB, and the size of each area that is the unit of backup creation and failure recovery is I.
GB.

(Stopped) The total number of database updates per day will be 107. Note that the access pattern is random and uniform.

(Costume) Backup creation method Divide the database into two groups and create backups of each group alternately every day.

(v) Performance of magnetic tape The capacity of each magnetic tape for storing journals and backups shall be 200 MB (megabytes), and the effective amount of data transferred in each process shall be 2 MB/sec.

(vi) Database access performance In the case of Nendum access, the effective data transfer amount is 25 ms/time, and in the case of sequential access processing, the effective data transfer amount is 2M
B/sec.

(vM) Database failure recovery procedure ■ Conventional method As shown in Figure 6 (a), the first step is to accumulate journals for the day of the failure, accumulate journals for the day before the failure, and perform backup operations in the area where the failure occurred. The data is stored, and the database is recovered using the journal in the second step.

0 Method of this Embodiment As shown in FIG. 6(b), the first step is to accumulate journals, the second step is to sort journals, and the third step is to perform backup storage and database recovery using journals. .

Four series of magnetic tapes are input as journal files. In the second step, as described above, the accumulated journals are sorted by polyphase merge sort (using four series of magnetic tapes).

(b) Effect estimation The database failure recovery time is determined for each of the conventional method and the method of this embodiment.

(1) Conventional method ■First step ・The journal collection time for the previous day is 30GB ÷ 2MB/sec = 250 minutes (Therefore, the maximum time for that day is 250 minutes) ・Backup restore time is IGB÷2MB/sec=500 seconds With the above, the first step is 250 minutes.

■Second step: The total number of database updates per day for each area of the database is 10”.

Two accesses per item using human power and output and up to 2 days worth of updates. From the need for new recovery, 25 milliseconds x 2 x 2 x lo' = 167 minutes.

■■■■ In the case of the conventional method, it takes 417 minutes to recover the failed area of the database.

(...) Method of this embodiment ■First step 300BX2-r4+2MB/sec = 125 minutes■Second step Total amount of data transferred at each stage of sorting is 556M
Become B. Combined with one human output each to the accumulation journal (200MH x 2).

956MB ÷ 2MB/sec = 8 minutes ■ 3rd step: Estimate the backup restore time a little larger, 1o
minutes.

From ■■■, it takes 143 minutes to recover.

As described above, in this example, the recovery time for a failed area of the database can be greatly reduced to approximately 1/3.

Next, we will explain the second embodiment.The difference between this embodiment and the first embodiment is that in the first embodiment, the failed database is recovered using the accumulated and sorted database update journals, but only one In the embodiment, a new backup file is created from an old backup file using the accumulated and sorted database update journals. below.

This embodiment will be explained using FIGS. 7 and 8.

FIG. 7 is a diagram showing the overall configuration of the system in the second embodiment, in which the CPtJ/memory 11 includes a database 21 and a journal file stored in a magnetic disk or the like.
31, old backup file 41, new backup file 42, database accumulation journal file 51
, and a journal sort work file 61 are connected.

These contents are as explained in the first embodiment.

Next, the operation of the system will be explained. Of the system operations, five normal operations, transaction failure operations, system failure operations, and database failure operations are performed in the same manner as in the first embodiment.

The operation during backup creation will be explained below.

In this embodiment, as described above, a new backup file is created by reflecting the contents of the accumulated and sorted database update journals in the previously created backup file.

In addition, if the capacity of the database is large, it may be necessary to group it by volume or data set, etc., and create it over multiple days.In order to correspond with the journal, the date and time of backup creation and the time and date of backup creation for each backup creation unit can be recorded. As in the first embodiment, the record number of the last recorded journal record and the journal sequence number of the magnetic tape containing the record are recorded at the beginning of the backup file.

A schematic flow of the backup creation process is shown in FIG. 8, and will be described below with reference to FIG. In addition, in the following,
The case of creating a backup file of one area of a database will be explained.

(a) Determination of journal range (step 311) As in the first embodiment, in this embodiment, the system records the backup creation date and time and the last journal record recorded at the time of backup creation completion for each area that is the unit of backup creation. The number and the journal sequence number of the magnetic tape containing the record are recorded at the beginning of the backup file and are associated with the journal.

In this step, the range of journals required to create the new backup file 42 from the old backup file 41 is determined based on this association.

(b) Journal Collection M (Step 312) Step 3
The database journals are extracted from the journals in the range determined in step 11. The extraction process is performed in the same manner as in the first embodiment.

(C) Sorting journals (step 313) The database update journals accumulated in step 312 are sorted using the physical address of the update data and the journal date and time as first and second keys. Then, the sorted journals are written to the database accumulation journal file 51. As in the first embodiment, polyphase merge sort is used for sorting, and magnetic tape 61 is used as a work file for journal sorting.

(d) Creating a new backup file (step 314)
) The old backup file 41 and the database accumulation journal file 51 created in step 313 both have data stored in the order of the physical addresses on the database medium.

Therefore, a new backup file 42 is created from the old backup file 41 and the database accumulation journal file 51 according to the following steps (1) to (2).

■Record the start date and time of this step execution and the last journal record number at the start of this step execution at the beginning of the new backup file, and associate it with the journal.

■Read the database update journals in order from the database accumulation journal file 51 λ ■In addition to the above ■, read the contents of each page in order from the old backup file, and write pages for which there is no database update journal as they are to the new backup file 42. , for other pages, contents reflecting the update results are written to the new backup file 42 using the database update journal.

■Repeat the above ■■ until the end of the old backup file 41 and database accumulation journal file 51.

As described above, according to this embodiment, the time required to create a new backup file from an old backup file using a journal can be significantly reduced. Also 1
In this embodiment, the database used in online processing is not used when creating a backup. Therefore, a backup file can be created during online processing without blocking the database.

Note that when creating a backup of a plurality of areas when creating a rose 4-up, one of the following two methods is used.

■When accumulating database update journals, the journals in the backup creation area are also accumulated into one database accumulation journal file. Then, when sorting the journals, the area number is included at the top of the physical address, which is the first key for sorting. moreover.

When creating a backup, new backup files are created in the order of area numbers.

- Create a database accumulation journal file for each backup creation area, and when accumulating database update journals, separate and accumulate journals for each area. Then, the journals are sorted by area and a new backup file is created.

Next, the third embodiment will be explained. The difference between this embodiment and the first embodiment is that in this embodiment, a backup file of the database is created without prohibiting database updates during online processing. It is a point. This embodiment will be described below with reference to FIGS. 9, 10, 11, and 12.

FIG. 10 is a diagram showing the overall configuration of the system in the third embodiment, in which the CPU/memory 15 includes a database 25 and a journal file 3 stored in a magnetic disk or the like.
5, a backup file 45, a database accumulation journal file 55, a journal sorting work file 65, and a backup volume 75 in case of database failure are connected.

Next, the operation of the system will be explained. First, an overview of the operation of the system in this embodiment will be described with reference to FIG. 9, focusing on the differences from the first embodiment.

As in the first embodiment, in this embodiment as well, the database system 105 records historical information regarding transaction processing during online system operation as a journal in a journal file 35 provided on a magnetic tape, magnetic disk, or the like. . Journal file 35 also includes a database update journal for database recovery in the event of database 71 25 failure. on the other hand.

The backup files 45 of the database 25 are created periodically. As mentioned above, in this embodiment, the backup files of the database are created without prohibiting database updates during online processing. do.

In FIG. 9, the backup file 45 is created (
If a failure occurs in the database 25 in this embodiment when transaction 1 and transaction 2 are updating the database during process 125), as in the first embodiment, ■ Collecting and sorting database update journals (process 135) ), ■Backup paste storage (processing 145), ■Database recovery using database update journal (processing 155). However, in this embodiment, the database failure recovery process is performed.
The update results of canceled transactions such as transaction 1 in Figure 9 are backed up by Hale 4.
This may be reflected in 5. Therefore, it is necessary to cancel the update results of the transaction using the database update journal of the cancel transaction. Therefore, when collecting and sorting database update journals (process 135), the database update journals of completed transactions are collected and sorted as in the first embodiment, and also the database update journals of completed transactions are collected and sorted (processing 135). A management list 510 is created, and the database update journal of the canceled transaction is also collected and sorted. Then, when the database is restored using the database update journal (process 155), the update results of the completed transaction are reflected, and the update results of the canceled transaction are canceled.

Next, each operation of the system will be explained. Among system operations, normal operation, transaction failure operation,
And the operation at the time of system failure is the first embodiment. The operation when creating a backup and the operation when a database failure occurs will be explained below.

(1) Operation when creating a backup In preparation for a failure of the database 25, a copy of the database is periodically created in the backup file 45. When the capacity of the database is large, it is the same as in the first embodiment that the database is grouped in units of volumes, data sets, etc. and created over multiple days, and that each backup creation unit is associated with a journal. However, in this embodiment, information for association is added. FIG. 11 shows the processing flow when creating a backup.

(a) Recording backup start information (step 341)
Before starting backup file creation, the following (1) (...) is performed to establish correspondence with the journal.

(i) Record the following items at the beginning of the backup file 45.

■Date and time when backup file creation started ■Journal record number of the first journal of the Shiomoto Runzaktion being executed when backup file creation started and journal sequence number which is the serial number of the magnetic tape that contains the record ■Data base execution time when backup file creation started The journal record number of the first journal in the database update journal for which updates have not yet been processed and the journal sequence number, which is the serial number of the magnetic tape that contains the record ■Indicates that the backup was created without updating the database during online processing. A flag (1i) indicating the start of backup file creation is written in the journal file 35 (including the name of the backup creation area).

(b) Copying the database (step 342) After all the transactions being executed at the start of step 341 are completed, the contents of the backup creation areas of the two databases are copied to the backup file 45.

(c) Recording backup end information (step 343)
After the completion of step 342, a journal record (
(including the name of the backup creation area).

(2) Operation in the event of database failure A schematic flowchart of recovery processing in the event of database failure is shown in FIG.

(a) Determination of journal range (step 351) Similar to the first embodiment, based on the information recorded at the beginning of the backup file 45 when creating the backup file,
The range of journals required to recover the failed area of the database 25 is determined. The required range is as follows.

(i) Journal of canceled transaction This may be the first journal of all transactions being executed at the start of backup file creation.Backup file creation is complete! to.

The successor material is determined based on the backup file creation completion journal in the journal file 35 when extracting the database update journal in step 352, which will be described later.

(i) After the first journal among the database update journals for which actual database updates are unprocessed at the time of starting the creation of a journal backup file for completed transactions.

(b) Accumulation of journals (step 352) Step 3
Database 25 from the range of journals determined in step 51
Extract the database update journal of the failed area.

As described above, in this embodiment, database update journals for canceled transactions are accumulated in the database accumulation journal file 55 together with database update journals for completed transactions. Journal accumulation is performed in the same manner as in the first embodiment, except for accumulating journals of canceled transactions. A management list 510 of transactions executed during the period from the start of backup file creation to the end Y is created.

(c) Sorting journals (step 353) Sort the database accumulated journal files 55 created in step 352 in ascending order using the physical address of updated data and journal writing date and time as first and second keys, and sort the journals into the database. Writing to the accumulated journal file 55, sorting uses a polyphase margin as in the first embodiment, and a magnetic tape 65-1.65 is used as a work file for journal sorting.
-2. ..., 65-k is used.

(d) Backup storage (step 354) Copy the contents of the database backup file 45 to the spare volume 75. In addition, No. 9. In the figure to glaze, this step is sorted by journal (step 353)
Although the process is described above, it may be performed in parallel with the journal accumulation (step 352) and sorting (step 353), and subsequent to the journal range determination (step 351).

(e) Database recovery (step 355) Step 3
Database accumulation journal file 5 created in 53
5 in order from the beginning and recover the database using the read database update journal. That is, the update result of the canceled transaction is canceled and the update result of the completed transaction is reflected on the data on the spare volume 75 in which the contents of the backup file 45 have been restored.

Completion/cancellation of a transaction is determined by referring to the canceled transaction management list 510. That is, if the transaction is 'n@', it is a canceled transaction, and if it is not registered, it is a completed transaction (green). If there are multiple database update journals for the same part, they are processed as follows in ascending order of journal writing time.

(i) Journal of canceled transactions Restore the data to be recovered to the contents before the update.

However, if multiple journals exist for the data in one transaction, only the first journal is used.

(it) Make the journal recovery target data of the completed transaction the updated contents.

As described above, according to this embodiment, even if a backup file is created without updating the database during online processing, the recovery time in the event of a database failure can be significantly shortened. In this embodiment, when there are multiple database update journals related to the same data, they are reflected in the updated data sequentially in the database recovery step (step 355), but only the last journal is reflected in the journal sort (step 353). You can leave the rest of your journal behind and throw it away.

〔Effect of the invention〕

According to the present invention, a database update journal is extracted from a journal file, a plurality of media storing the journals are processed in parallel, and the extracted database update journals are sorted in the order of the physical addresses on the database storage media. This can significantly reduce the time required for recovery processing in the event of a database failure.

[Brief explanation of drawings]

FIG. 1 is a diagram explaining the outline of the operation of the first embodiment of the present invention, FIG. 2 is an overall configuration diagram of the system of the first embodiment, and FIG. 3 is a diagram of the database in the first embodiment. A schematic flowchart of the recovery process in the event of a failure, Figure 4 is a diagram explaining the journal extraction method, Figure 5 is a diagram explaining the journal sorting method, and Figure 6 is a diagram showing the details of the database failure recovery process. It is. Fig. 7 is an overall configuration diagram of the system in the second embodiment, Fig. 8 is a schematic flow of recovery processing in the event of a database failure in the second embodiment, and Fig. 9 is a diagram of the operation of the third embodiment. FIG. 10 is a schematic diagram of the overall system configuration, FIG. 11 is a schematic flow diagram of backup creation processing, and FIG. 12 is a schematic flow diagram of recovery processing in the event of a database failure. 10.11.15...CPU/memory, 20,21゜25...Database, 30,31.35...Journal file, 40,41,42,45...Backup file, 50,51. 55...Database accumulation journal file, 60,61.65...Work file for journal sorting, 70.75...Spare volume, 100,105...Database system, 500...Transaction management list, 51
0: Cancellation transaction management list. Figure 6: Sc long 3; 1゜millet [〉flea (11) large) 4〉ear + i〉〉1゜circle 21 ke=gu - person 42 bamboo ヮヮ゛゛71
Ile 31 Tsuru-1 Rukichi Ile ft rz blind sea r
Rufu, 4ru 3 Defense 42 Analysis Buzz 7f J'7v4ru 1st Theta Figure leverage Tf, Ifu'h Uru Koma I 2 times

Claims (1)

[Claims] 1. In a database system comprising a database, a backup file of the database, and a journal file storing transaction processing history information including database update history information for database recovery, The above database update history information is extracted for each area that is the unit of database recovery, and is sorted in the order of the physical addresses on the database storage medium, and the areas to be recovered of the database are extracted as described above, sorted in the order of the physical addresses of the database in the area. A database failure recovery method that uses database update history information to recover from the backup file in the order of physical addresses. 2. In a database system equipped with a database, a backup file of the database, and a journal file that stores transaction processing history information including database update history information for database recovery, the database update history information is retrieved from the journal file. Database failure recovery that extracts each area that is the recovery unit of the database, sorts it in the order of physical addresses on the database storage medium, and creates a new backup file from the backup file using the sorted database update history information. Method. 3. When extracting database update history information from journal files for each area that is the unit of database recovery, divide the journal file storage medium into groups and extract database update history information from each group in parallel. For transactions whose history information is stored across multiple groups for each group, whether or not that transaction has been completed is stored, and it is determined whether the database update history information extracted from other groups is the history information of a completed transaction. The database failure recovery method according to claim 1 or 2, wherein only necessary database update history information is extracted. 4. When recovering the area to be recovered from the backup file using the database update history information, after the contents of each page of the above area read into the main storage from the backup file are recovered in memory using the update history information. The database failure recovery method according to claim 1 or 3, further comprising: writing on a medium on which the recovered area is placed. 5. When creating a new backup file from the backup file using the sorted database update history information, the contents of each page in the area read from the backup file into the main storage are stored in the memory using the update history information. 4. A database failure recovery method according to claim 2 or 3, wherein after the above recovery, a new backup file is written to a storage medium. 6. When creating a backup file of the database during a period when database update processing is not performed, and extracting and sorting the database update history information of the database processing target area from the journal file, the database of transactions completed after the backup file was created. A database failure recovery method according to claim 3, which extracts only update history information. 7. Create a backup file of the database in parallel with the database update process, and at this time, identify the range of history information from the start to the end of creation of the backup file for each area for each area that is the unit of database recovery; When extracting and sorting the database update history information of the database processing target area from the journal file, the database update history information of transactions that were being executed at the time of backup file creation but did not complete after that, and the database update history information of the transactions that were executed at the time of backup file creation but were not completed after that, and the database on the media after backup file creation started. Extracts the database update history information of completed transactions that were updated in , The database failure recovery method according to claim 3, wherein the database update history information of completed transactions is used to recover the updated contents. 8. When extracting database update history information from the journal file for each area that is the unit of database recovery, extract only the database update history information that includes the last content of that part from among the database update history information regarding the same part of the database. , a database failure recovery method according to claim 3.