JPS61193241A - Updated career recording - Google Patents

Abstract

PURPOSE:To reduce the amount of updated career to be recorded on a recording medium by half by obtaining exclusive OR 8 of the contents before and after updated, merging them to one content and outputting it to the recording medium as a journal when updating a main memory or a data base, etc. CONSTITUTION:The shaped portions show updated areas. Conventionally an updated history journal 23 is made of record contents before and after updating without any modification, while this updated career journal 24 is made by exclusively ORing 8 record contents before and after updating which are merged to one content. In addition, to this updated career journal 24, the initial byte of the initial field to be updated in the before record 21 is added as an identification information 25 to judge whether the system is at the before state or the after state when the system is recovered from a trouble. In such a way, the updated career is made not of both before and after record contents, but of one content whereto both the contents are merged; thus the record quantity of updated history on the recording medium can be reduced by half compared with the conventional method.

Description

DETAILED DESCRIPTION OF THE INVENTION C. Field of Application of the Invention The present invention relates to a method for recording update history of a main storage device or a database in a recording medium as a journal in an online real-time system or a database system.

[Background of the invention]

Generally, in an online real-time system, when a main storage device or a database is updated, the update history is output as a journal to a disk device, etc. as a countermeasure against failures.

In this case, conventionally, both the pre-update and post-update contents are output as the update history to a disk device or the like. This method has the advantage of being able to immediately recover from either the pre- or post-update state when a failure occurs, but on the other hand, since the contents of both the pre- and post-update states are output, the update history information cannot be stored on a recording medium such as a disk device. There is a problem in that the area occupied increases and the number of inputs and outputs to the recording medium increases, resulting in a decrease in system performance.

[Purpose of the invention]

It is an object of the present invention to provide an update history recording method that improves the usage efficiency of recording media and system processing efficiency by reducing the amount of update history information recorded, and that can recover from any state before or after an update when a failure occurs. Our goal is to provide the following.

[Summary of the invention]

When updating a main storage device, a database, etc., the present invention performs an exclusive OR of the contents before and after the update.
and output it to a recording medium as a journal. , Thereby, the amount of update history recorded on the recording medium can be halved. Furthermore, in order to return to the state before the update when a failure occurs, it is sufficient to perform an exclusive OR operation on the updated i in the main storage device or the database and the update history information again.

[Embodiments of the invention]

FIG. 1 shows a schematic configuration of an online real-time system to which the present invention is applied. Prior to system startup, the central processing unit 2 uses a backup acquisition program 21 to transfer data from the main storage device 3 and database 4 to magnetic tape. It is output and stored in a backup file 6 of the device, etc. As described later, this backup file 6 is
When the system status becomes catastrophic due to the occurrence of a failure.

First, it is necessary to restore the system state to the state at the start of processing. After backing up data in the main storage device 3 and database 4 to file 6.

The system starts operating.

While the system is in operation, a program in the central processing unit 2 that processes original messages input from the terminal device 1
When updating the table 31 on the main storage device 3 or the record 41 on the database 4.

Central processing unit with updated contents! 12, the journal acquisition routine 22 is called. The journal acquisition routine 22 acquires update history information (update history journal) based on the unupdated contents in the main storage device 3 and database 4 and the updated contents held in the central processing unit 2. )31'.

41' and output it to the journal file 5 of a magnetic disk device or the like. Thereafter, the processing returns to the normal program 1, which transfers the update data held in the central processing unit 2 to the main storage device 3 and database 4.

FIG. 2 is a diagram comparing the formats of update history journals according to the conventional method and the method according to the present invention.

In FIG. 2, 21 is a record before updating, and 22 is a record after updating. The shaded area indicates the update area. Conventionally, the update layer/history journal 23 was created by using the recorded contents of both records 21 and 22 before and after the update as the N update history. In contrast, the present invention performs an exclusive OR of the recorded content before the update and the recorded content after the update.
merge into.

An update history journal 24 is created. Furthermore, this update history journal 24 contains information about the updated information in the pre-update record 21 as identification information 25 for determining whether the system status is before or after the update when the system recovers after a failure occurs. Add the first 1 byte of the first field.

As mentioned above, when updating the table 31 on the main storage device 3 or the record 41 on the database 4, the journal acquisition routine 22 updates the update history journals 33' and 41.
' and output it to journal file 5, and
After that, return to normal program processing and save the updated contents stored in the central processing bag @2 to the main memory l! 3 and database 4, and updates the table 31 and records 41. Therefore, update history journals 33', 34'
is acquired in the journal file 5 and then transferred to the main storage device 3.
There is a certain amount of time delay before the table 31 and records 41 of the database 4 are actually rewritten. If a failure occurs during this period, journal file 1. Even if the update history journal is output to the file 5, the contents before the update remain in the main storage device 3 and the database 4. When recovering the system after a failure occurs, whether the contents of the main storage device 3 or database 4 are before or after the update is determined by the third
The determination is made based on the identification information 25 added to the update history journal 24 shown in the figure. That is, since the identification information 25 is data before updating, by comparing this with the corresponding data in the main storage device 3 and the database 4, if they match, the main storage device 3
The database 4 can be determined to be in its pre-update state, and if they do not match, it can be determined that it is in its post-update state.

Next, the recovery process after the occurrence of a failure using the update history journal of the present invention will be explained with reference to FIG.

There are two methods for recovery processing after a failure occurs.

1. Restore the system state after the failure to the state immediately before processing the message in which the failure occurred.

2. If the system status becomes catastrophic after a failure occurs, the backup file first restores the system to the state at the start of processing, and then the journal restores the system to the state before the failure message was processed.

In the former case 1, it is necessary to return all records updated by the program that processed the failed message to their pre-update state. Conventionally, it was possible to easily restore the information before the update to the update history journal, but in the present invention, since the information before the update is not stored in the update history journal, it is possible to return the information before the update to the update history journal as shown in block 31 of FIG. Recover. That is, first, it is determined whether the system state after the occurrence of a failure is before or after an update, based on the identification information 25 on the update history journal 24 described in FIG.

As a result, if the system state is the state before the update, no recovery processing is required. If the system state is the state after the update, the system memory contents (pre-update records) and the update history journal in the journal file Exclusive OR is performed with and returns to the state before update (pre-update record).

If the latter system state becomes catastrophic, recovery is performed as in block 32 of FIG. That is,
First, a backup file is used to restore the system state to the state at the start of system processing. Next, for the storage areas that have been updated after system processing started, by sequentially performing an exclusive OR with the update history journal acquired in the journal file, the state after the update is sequentially reproduced, and the failure is detected. Return to the system state (post-update record) immediately before the occurrence.

〔Effect of the invention〕

According to the present invention, since the update history does not include both pre-update and post-update recorded contents, but merges both into one, the amount of update history recorded on the recording medium is halved compared to the conventional method. be able to.

Additionally, the number of inputs and outputs to the journal file is reduced, resulting in improved system processing efficiency.

[Brief explanation of drawings]

FIG. 1 is a block diagram of an example of a system targeted by the present invention.
FIG. 2 is a diagram showing format examples of update history journals according to the conventional method and the method of the present invention, and FIG. 3 is a diagram illustrating recovery processing after a failure occurs using the update history journal according to the method of the present invention. 1...Terminal device, 2...Central processing unit, 3...
・Main storage device, 4...Database, 5...Journal file, 6...Backup file,
21... Record before update. 22...Updated record, 24...Update history journal, 25...Identification information. Figure 1 Figure 2 Figure 3

Claims (2)

[Claims] (1) When recording the processing history in an information processing system, the content before the update and the content after the update are exclusively ORed and merged into one, and the merged information is recorded on a recording medium. Update history recording method. (2) The update history recording method according to claim 1, wherein a part of the content before or after the update is added to the merged information as update identification information.