JPH05303523A - In-fault process restore system - Google Patents

Abstract

PURPOSE:To process update requests by plural tasks in parallel and to efficiently restore data by stopping a process in a short period in the case of fault detec tion. CONSTITUTION:An update request by a task 1 to a block B1 is fetched (S9) and an update request by a task 2 to B1 is fetched (S10). Once the task 1 makes a commitment, update information (update journal, data before update, and data after update) determined by the S9 and S10 is saved in a magnetic disk device(MD). Then the update request by the task 1 is fetched (S14) and then the update request by the task 2 is fetched (S15). Once the task 2 makes a commitment 2, update information determined by S14 and S15 is saved in the MD. If a fault occurs here, the pieces of update information in the MD are stored in a corresponding storage area in a main storage device to enter the storage state at the time of the commitment 1 which is determined last time, and CPU processing is restarted.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a failure process recovery system, and more particularly to a failure process recovery system suitable for application to a failure process recovery in a computer system or the like.

[0002]

2. Description of the Related Art In recent years, online information systems have become popular. For example, in a bank online system or the like, if a failure occurs for some reason and the CPU processing is stopped, the data being processed is lost, or the processing that has been performed up to now must be restarted from the beginning. Not to mention, it may cause a great deal of confusion to users, and the banks may suffer a great loss. For this reason, various methods have been developed to deal with failures (for example, power failure, device hardware failure, program failure, etc.).

For example, as a method for coping with the above-mentioned obstacles,
When updating data, store the updated contents in a separate file from the updated data (for example, called a non-volatile update history file), and if a failure occurs during certain processing, update history There is a method (referred to as a first failure process recovery method) of referring to the update content of the file to reproduce the data before the update and restarting the process based on the reproduced data.

In addition, when updating data,
Store the data in a separate file from the updated data (for example, a non-volatile log file), and if a failure occurs during certain processing, use the data in this log file before the update. There is also a method of restarting processing (this method is called a second failure processing recovery method).

[0005]

However, according to the first failure processing recovery method, depending on the update contents, 1
It is expected that the amount of update contents stored in the update history file will increase or decrease as the update contents become larger, and it will be difficult to determine the file size of the update history file. When the amount is large, there is a problem that it takes time to recover the processing. Also, if the same block of data is updated many times, it will take more and more time to recover because the state before the update must be restored based on the contents of multiple updates during the recovery process. There's a problem. In addition, such a time-consuming process recovery causes a problem that it takes a long time to start the processing of the application, which is the original purpose, and the time the user cannot use becomes long.

In the second method for recovering from a process when a failure occurs,
When updating the data, it is necessary to write the data before the update in order to save the data from the main memory to the log file. However, while a commit (COMMIT: command to confirm the update) is declared from a certain task to update a certain block and writing from the main memory to the magnetic disk device, the update target from another task If it is not possible to update the block, and the task that issued the commit and issued the commit again issues a commit etc. and one transaction does not end, the other task can update the block. There was a problem that I could not. Therefore, there is a problem that it takes time to update the same block from different tasks.

The present invention has been made in view of the above problems, and an object thereof is to enable parallel processing of updating data of the same block by a plurality of tasks in a computer system, for example. It is an object of the present invention to provide a failure recovery processing method capable of efficiently recovering data by stopping processing for a short time when a failure is detected.

[0008]

The present invention comprises the following characteristic means and methods for achieving the above object. That is, each time an update request for the update target data is issued, the update journal storage unit that stores the update journal in a volatile manner and the update target data corresponding to the update request are updated, and the updated data is updated. After-update data storage means for volatile storage, before-update data storage means for volatile storage of pre-update data each time the update is confirmed, and at least one or more update requests issued by the same task And a update information storage unit that stores the update journal, the data before the update, and the data after the update in a non-volatile manner each time the transaction is confirmed.

At the time of detecting a failure, the update journal stored in the update information storage means and updated by the transaction determined at the closest previous time when the failure confirmed by the failure detection occurs is stored in the update journal. In the same manner, the pre-updated data stored in the same means is stored in the pre-updated data storage means, and the post-updated data stored in the same manner is also stored in the post-updated data storage means to prevent the failure. It is characterized by recovering the storage state at the time of the transaction that was finalized at the closest previous time when the transaction occurred.

[0010]

According to the present invention, even if a plurality of update requests for the same block of data are issued from different tasks,
Since the update information is stored in the update journal storage means, the updated data storage means, and the pre-update data storage means, update requests from a plurality of tasks can be taken in parallel, and the same task Each time one or more update requests are issued from the above, the above-mentioned update information of the task is determined and saved by the above-mentioned update information saving means, so the update information can be saved more efficiently than in the past. ..

When a failure occurs due to, for example, power-off, the failure is detected after performing an IPL after the power is turned on, and the transaction is updated with the transaction confirmed at the time closest to the failure occurrence time. The update journal stored by the update information storage means, the updated data, and the pre-update data are read into the corresponding update journal storage means, post-update data storage means, and pre-update data storage means, respectively. Since it is stored and is in the storage state at the time of the confirmed transaction, the processing can be automatically restarted from this storage state. Therefore, even if an update request is issued from a plurality of tasks, it is possible to automatically restart from the state of the transaction confirmed last time automatically by the failure recovery processing.

[0012]

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT A preferred embodiment of the present invention applied to a failure processing recovery system of a computer system will be described with reference to the drawings.

In this embodiment, in a general computer system, when a failure occurs, the computer is stopped (locked) for a short time.
Then, an example of efficiently recovering the processing will be described below.

As an example, at least one task issues an update request for a target block, and each time the update is performed, the update journal and the data of the target block before the update are stored in the main memory as failure recovery data. Each time the task that has issued the update request issues a commit and confirms the update, the update contents and the data before update stored up to that point are saved in the magnetic disk device, and during the CPU processing. If a failure occurs, an example of performing the IPL and referring to the contents of the magnetic disk to recover the data before the failure will be described below.

FIG. 1 is a processing flowchart of an example of a failure recovery processing method for a computer system according to this embodiment (part 1: an example of the overall processing flow). FIG. 2 is a processing flowchart of an example of a failure recovery processing method for a computer system according to this embodiment (part 2:
2 is an example of a detailed processing flow of a failure recovery processing part in FIG. 1).

Before describing the processing flowcharts of the examples of FIGS. 1 and 2, the configuration of an example of a computer system for implementing the failure recovery processing method of the computer system will be described with reference to FIG.

FIG. 3 is a hardware configuration diagram of an example of a computer system which realizes the failure recovery processing method of the computer system according to this embodiment.

In FIG. 3, the computer system of this example comprises a CPU 7, a main storage device 1, magnetic disk devices 2 to 5, and an input / output device 8.

The magnetic disk device 4 mainly stores a main program (MP) and the like, and when the power is turned on, an IPL (Initial Program) is stored in the main program (MP) storage area of the main storage device 1 by an instruction from the CPU 7.
ram Loading). Magnetic disk unit 5
Mainly stores an application program (AP), and based on an instruction supplied from the CPU 7 to the input / output device 8, the application program (A) of the main storage device 1 is stored.
P) Store in storage area 16.

The CPU 7 causes an application program (AP) supplied from the magnetic disk device 5 to be stored in a predetermined application program (AP) storage area 16 of the main storage device 1 for task processing. When the application program (AP) supplies a commit or the like for changing the program, the CPU 7 commands the program to update the program for the data file (DF).

The magnetic disk device 3 stores a failure recovery log file (SKF) by the failure recovery data supplied from the main storage device 1 based on an instruction from the CPU 7, and a checkpoint file (SKF) based on the supplied checkpoints. CPF) etc. are stored. Further, these files are read into a predetermined storage area of the main storage device 1 based on an instruction from the CPU 7. The magnetic disk device 2 stores or reads the data obtained in the main storage device 1 in a data file (DF) based on an instruction from the CPU 7.

The main storage device 1 is a volatile storage device, and stores the main program (MP) supplied from the magnetic disk device 4 in the main program (MP) storage area, and stores the journal log J in the journal log storage. In the area, the failure recovery data is stored in the failure recovery data storage area, the input / output data is stored in the input / output data storage area, and the checkpoint is stored in the checkpoint storage area. The journal log J in the journal log storage area is edited and stored in the failure recovery processing log file (SKF) of the magnetic disk device 3 based on a command from the CPU 7. Further, the failure recovery data in the failure recovery data storage area is edited and stored in the failure recovery processing log file (SKF) of the magnetic disk device 3 based on an instruction from the CPU 7. Also, based on the instruction from the CPU 7,
The checkpoints in the checkpoint storage area are also edited and stored in the checkpoint file (CPF) of the magnetic disk device 3. Input / output data in the input / output data storage area is stored in the magnetic disk device 2 based on an instruction from the CPU 7.

The input / output device 8 is, for example, an input unit (not shown) for supplying various instructions and data to the system and an output unit ((not shown) for outputting data generated in the system. ) And so on.

FIG. 4 is an explanatory diagram of an example for explaining a time sequence example of the data update by the task 1 and the task 2 for a certain block B1 in the failure recovery processing method of the computer system of this embodiment.

In FIG. 4, an example of data update by the task 1 and task 2 of the application program (AP) will be described. Application program (A
P) issued a commit in task 1 (T1), and then also issued a commit in task 2 (T2).
Next, in task 1, A for the data in block B1
DD (R1) (this is the process of adding record R1) was performed (T3). Next, in task 2, block B1
ADD (R2) for this data (this is record R2
Was added) (T4). Next, in task 1, a commit (number 1) was issued (T5). Transaction 1 (TR) from the last commit (T1) issuance in task 1 to the current commit issuance (T5)
1). Transaction 1 (TR1) is confirmed by issuing the above-mentioned commit (number 1), and ADD (R1)
Confirm and save.

Then, in task 1, DELETE (R1) for block 1 (this is the process of deleting the record R1) was performed (T6). Next, in task 2, ADD (R3) (this is the process of adding record R3) to block 1 was performed (T7). Next, in task 2, a commit (number 2) was issued (T8).
Transaction 2 (T) from the previous commit (T2) issuance to the current commit issuance (T8) in task 2
R3). Then, the transaction 2 (TR2) is confirmed by issuing the above-mentioned commit (number 1), and ADD
(R2) and ADD (R3) are confirmed and saved. Then, the DELETE (R1) (T6) after the commit issuance (T5) in the task 1 is transaction 3
(TR3). However, in task 1, since commit has not been issued to DELETE (R1) (T6), transaction 3 (TR3) is in an indeterminate state.

FIG. 5 is a diagram showing the storage and storage states of various files and data in the computer system according to this embodiment, and the main storage device 1 is finally obtained by the processing of FIG.
Shows the state of being stored and stored in the magnetic disk devices 2 and 3.

The main storage device 1 includes, for example, a main program (MP) storage area 11 and a journal log storage area 12
A failure recovery data storage area 13, an input / output data storage area 14, a checkpoint storage area 15, and an application program (AP) storage area 16. Then, for example, the journal log storage area 12 stores journal logs J1 to J4, which are the contents of the data update, as the data is updated to the block B1. Then, each journal log J has a task number, a transaction number, and an update content (for example, ADD (R
1) etc.) and the update block number. Further, the failure recovery data storage area 13 stores the block data L1 before the update when updating the data of the block B1, for example.

The input / output data storage area 14 stores the updated block data B1 in the cache format. In addition, the checkpoint storage area 15 stores, when the task update is enabled by issuing the commit,
The task number, transaction number, effective commit number, etc. are stored.

In the magnetic disk device 2, the updated block data in the main storage device 1 is stored in the data file DF.
It is stored in. The magnetic disk device 3 uses the log file SKF and the checkpoint file C for failure recovery processing.
The PF is stored. The failure recovery processing log file SKF includes a journal log J supplied from the main storage device 1, failure recovery data L, and a valid commit number. The checkpoint file CPF stores the commit number for which the update is valid, the task number, and the transaction number.

FIG. 1 is a processing flowchart (part 1: an example of the overall processing flow) of an example of a failure recovery processing method for a computer system according to this embodiment. FIG. 2 is a processing flowchart of an example of the failure recovery processing method of the computer system according to this embodiment (part 2: an example of a detailed processing flow of the failure recovery processing portion in FIG. 1).

First, referring to FIG. 1, the computer system is such that the magnetic disk device 4 is firstly turned on when the power is turned on.
The main program stored in
PL (S1). Next, the CPU 7 is the magnetic disk device 3
Checkpoint file CPF1 saved in
2 is referenced (S2), and it is determined whether or not there is a valid commit number (S3). If it exists here, then only the data file DF and the failure recovery processing log file (SKF) stored in the magnetic disk devices 2 and 3 having the same commit number are stored in the corresponding main storage device 1. The data is read into the areas 12, 13, and 14 (S4), the stored data is used as recovery data (S5), and the CPU processing is started based on this storage state (S6). S2 above
The processing of S5 is temporarily stopped, for example, when the computer system is in use and the power is cut off.
It may be considered as the processing when it is performed.

On the other hand, in S3, when the power supply is cut off without any failure, and when the power is turned on thereafter, the file contents of the data file DF and the failure recovery processing log file (SKF) are kept consistent. Since the failure recovery data corresponding to the valid commit number does not exist in the magnetic disk device 3, S6 is subsequently executed.

In S6, the CPU 7 causes the application
The program (AP) is executed. Next, for example, the CPU 7 monitors whether or not a data update request is issued from the application program (AP) loaded from the magnetic disk device 5 to the main storage device 1 (S7). When CPU processing is continued and, for example, a commit for task 1 and task 2 is issued from the application program (AP) (S8), the update content for block B1 by task 1 is updated in the journal log J1 (J1 (ADD in FIG. 5). (R1))) in the journal log storage area 12 of the main storage device 1 (S9). As a result, R1 is also set in the input / output data area 14. Data storage area for failure recovery 1
The state L0 of the block B1 before the update is stored in 3.

Next, the update contents of, for example, the block B1 by the task 2 are displayed in the journal log J2 (J2 (A in FIG. 5).
DD (R2))) in the journal log storage area 12 of the main storage device 1 (S10). As a result, in addition to the previous setting of R1 in the input / output data storage area 14,
R2 is also set. In this state, the state L0 before update of the block B1 already exists in the failure recovery data storage area 13, and new recovery data for B1 is not stored.

Next, the application program (A
Commit from P) to task 1 (commit number 1)
Is issued (S11), the journal log J2 stored in the journal log storage area 12 at this time is then written.
(ADD (R2)) and failure recovery data storage area 13
The data L0 (data empty) of the block before the update stored in the log file SKF for failure recovery processing of the magnetic disk device 3 and the changed data B0 stored in the input / output data storage area 14 are stored. (R1, R2) is saved in the data file DF of the magnetic disk device 2, and the checkpoint CP0 is stored in the checkpoint storage area 14.
(Task 1: TR1 (determined), task 2: TR0 (undetermined), valid commit number 1) is generated and saved in the checkpoint file CPF1 of the magnetic disk device 3 (S12). If no failure occurs during this saving (S13), it is determined that the data update by the transaction TR1 for the block B1 with the commit number 1 is confirmed.

However, if it is judged that the data cannot be saved due to a failure such as power failure and that the data in the main storage device 1 has been lost, the log file SKF for failure recovery processing saved in the magnetic disk device 3 is checked. Fault recovery processing is performed using the point file CPF1 or CPF2 (S20).

The details of this failure recovery processing (S20) are shown in FIG. 2, and according to this FIG.
Perform L (S201), then refer to the checkpoint files CPF1 and CPF2 of the magnetic disk device 3 (S202), determine whether or not a valid commit number exists (S203), and if there is a valid commit number. For example, the failure recovery processing log of the failure recovery processing log file SKF corresponding to this number is read into the main storage device 1 (S
204), the data is recovered based on the failure recovery data L and the journal log J (S205) and saved in the data file DF of the magnetic disk device 2 (S206). At this time, it is judged whether or not a failure has occurred (S2
07), if it occurs, the above steps S201 to 206 are performed again. In the example up to S13 in FIG. 1, since there is no update content etc. saved, it is judged in S203 that the valid commit number has not been saved, and the failure recovery process is terminated. Resume in the state.

For example, when the process is completed in S13 as a failure-free operation and no failure has occurred in the processing so far, the main storage device 1 stores the data in the state of S11, and It is stored in the disk devices 2 and 3 in the state of S12.

After performing the above S20, the next S14
Whether or not the subsequent processing is performed depends on the processing of the application program (AP), but in this example, an example of performing the processing of S14 and subsequent steps will be described.

Then, for example, after the end of S13 (no failure), the update contents of the block B1 by the task 1 are updated in S14 in the journal log J3 (J3 (DE in FIG. 5) (DE
LETE (R1))) in the journal log storage area 12 of the main storage device 1. As a result, R1 is deleted from the input / output data storage area 14, and as a result, R2 remains. Further, R is stored in the failure recovery processing data storage area 13.
1 is set. The checkpoint storage area 15 retains the previous state.

Next, for example, the update contents of the block B1 by the task 2 are written in the journal log J4 (J4 (A in FIG. 5).
DD (R3))) in the journal log storage area 11 of the main storage device 1 (S15). As a result, R3 is set in the input / output data storage area 14 in addition to R2. Further, R is stored in the failure recovery processing data storage area 13.
In addition to 1, R2 is set. The checkpoint storage area 15 retains the previous state.

Next, the application program (A
Commit from P) to task 2 (commit number 2)
Is issued (S16), the journal log J3 stored in the journal log storage area 12 at this time is then issued.
(DELETE (R1)) and the data L1 of the block before update stored in the failure recovery data storage area 13
(R1, R2) are saved in the failure recovery processing log file SKF of the magnetic disk device 3, and the changed data B1 (R2, R2) stored in the input / output data storage area 14 is stored.
3) is rewritten and saved in the data file DF of the magnetic disk device 2 over the previously saved data, and the checkpoint CP1 (task 1: TR1, task 2: TR2, valid commit number 2) is stored in the checkpoint storage area 14.
Is generated and stored in the checkpoint file CPF2 of the magnetic disk device 3 (S17). If no failure occurs during this saving (S18), it is determined that the data update by the transaction 2 (TR2) for the block B1 with the commit number 2 is confirmed.

However, if it is judged that the data cannot be saved due to a failure such as power failure and that the data in the main memory 1 has been lost, the log file SKF for failure recovery processing saved in the magnetic disk device 3 is checked. Fault recovery processing is performed using the point file CPF1 or CPF2 (S21).

The details of the failure recovery process (S21) are the same as in FIG. 2 above. According to FIG.
Perform L (S201), then refer to the checkpoint files CPF1 and CPF2 of the magnetic disk device 3 (S202), determine whether a valid commit number exists (S203), and save the valid commit number 1. Therefore, the failure recovery processing log (commit number 1: J2, L0) of the failure recovery processing log file SKF corresponding to this commit number 1 is read into the corresponding storage areas 12, 13 of the main storage device 1, respectively. Then, the data file DF (R1, R1,
R2) is also read onto the input / output data storage area 14 of the main storage device 1 (S204), and the journal log J2 (ADD
Based on (R2)), reverse processing (that is, that is, to the data (R1, R2) read in the input / output data storage area 14 is performed.
DELETE (R2) processing is performed to recover (reproduce) the data (R1) (S205), and the data (R1) is saved in the data file DF of the magnetic disk device 2 (S2).
06).

As a result, the data could be restored to the state of the transaction 1 (TR1) confirmed by the previous commit number 1. At this time, it is determined whether or not a failure has occurred (S207), and if so, the above steps S201 to S206 are performed again.

Upon completion of S18 or S21, the CP is updated based on the updated data or the error-recovered data.
The predetermined process by U7 can be performed (S19).
Whether to proceed to S19 depends on the instruction of the application program (AP), but in this example, S21 is followed by S
An example that can proceed to 19 will be described.

Further, the task 1 is processing the transaction 3 (TR3) by the update processing of the block B1 by the task 1 in S14, and the transaction 3 (TR3) is determined by issuing the next commit for the task 1. Can be made Even if an update request is issued from another task before the transaction TR3 is finalized, the request should be stored in the journal log storage area 12, the failure recovery data storage area 13, and the input / output data storage area 14. You can

As described above, in the process flow chart of FIG. 1, if no failure occurs in the commit number 1 (S11) and the commit number 2 (S16), the storage state and the save state of FIG. 5 are finally obtained. Be put into a state. That is, the log file S for failure recovery processing of the magnetic disk device 3
Logs (L, J) with commit numbers 1 and 2 are stored in KF, valid commit number 1 is stored in checkpoint file CPF1, and checkpoint file CPF is stored.
The valid commit number 2 is stored in 2.

Even if the processing of the commit number 2 is confirmed without a failure in S18 and the data in the main storage device 1 is lost due to a failure such as power failure in S19, the same as in FIG. By referring to the effective commit number 2 from the checkpoint file CPF2, L1 (R1, R2) and J3 (DELETE (R1)) of the log file SKF for failure recovery processing of the same number 2 are stored in the main storage device 1 in the main storage device 1. The data (R2, R) is read from the corresponding storage areas 12, 13 and further read from the data file DF.
3) is read into the input / output data storage area 14, data (R2, R3) is set, and the storage state of the transaction 2 (TR2) confirmed last time is restored.

According to the above embodiment, even if the CPU processing is stopped due to a power failure or the like, the data before the data update is automatically reproduced along with the re-IPL so that the processing can be restarted. In addition, the time until the processing of the CPU is stopped due to the failure and the processing can be restarted can be shortened as compared with the conventional case.

This means that a plurality of update requests for the data of the same update target block can be fetched and stored during the period of one transaction TR, and the plurality of update journals can be stored each time one transaction is confirmed. Since the data before the update and the data after the update are saved, these data are used for the failure recovery processing to store the data in the main storage device 1 in the state of the transaction determined at the earliest time before the failure. This is because the state can be recovered (reproduced).

Furthermore, the application program (A
The update process by P) can be processed with a short-term lock, and the processing efficiency of the application program (AP) can be improved. Therefore, a plurality of task processes can be performed in parallel, and the process efficiency can be improved. Further, the above computer system is effective when applied to a system that suffers serious damage when the operation stop time is long, such as an online system or various database search systems.

In the above embodiment, the configuration of the computer system has been described by taking the configuration shown in FIG. 3 as an example, but the configuration is not limited to this. For example, the present invention can be applied even if the I / O device 8 having a communication function is configured to be online with another system through an external wired line or wireless line. Further, the main storage device 1 is volatile, and a storage device having a high access speed is desirable.

Further, in FIG. 3 of the above embodiment,
Although the magnetic disk devices 2 to 5 are used, they may be non-volatile, and may be a magnetic tape device or the like as long as the access speed is not limited. Further, the magnetic disk devices 2 to 5 may be one magnetic disk device without being individually divided.

In the above embodiment, the computer system has been described as an example, but the invention is not limited to this. For example, if a dedicated system is provided with an MPU, a storage device, etc., it can be basically applied.

Further, in the processing flowchart of FIG. 1 of the above embodiment, the contents of update are the journal logs J1 to J1.
Although the case of J4 has been described, the contents are not limited to this update content. Further, the commit issuance timing is such that the commit number 1 is issued between the journal logs J2 and J3 and the commit number 2 is issued after the journal log J4. However, the commit number is not limited to this, and is issued at any timing. Can be applied. Further, in the processing flowchart of FIG. 1, when the commit is issued to the task 1 in S12, the input / output data B0 at that time is issued.
Although (R1, R2) is stored in the magnetic disk device 2 as it is, it is not limited to this. For example, in step S12, the transaction 1 (TR1) of task 1 is confirmed, so the ADD (R1) belonging to transaction 1 (TR1) is confirmed and the ADD of task 2 is determined.
Since (R2) is undetermined, only R1 may be stored. Further, the flow of other processing is not limited to the flow shown in FIG.

[0058]

As described above, according to the present invention, the update journal storage means, the post-update data storage means, the pre-update data storage means, and the update information storage means are provided, and a failure occurs. At the time of detection, the update journal that has been updated by the transaction established at the closest previous time when the failure occurred and saved by the update information saving means, the updated data, and the pre-update data respectively correspond to the update journal. Read and store in the storage means, the updated data storage means, and the pre-updated data storage means,
Since the storage state at the time of the confirmed transaction is set, the processing can be automatically restarted from this storage state.

Therefore, even if an update request is issued from a plurality of tasks, even if a failure occurs, it is possible to automatically and efficiently restart from the state of the last confirmed transaction. Furthermore, the update processing by the application program can be processed with a short-term lock, and the processing efficiency of the application program can be improved.

[Brief description of drawings]

FIG. 1 is a processing flowchart (part 1) of a failure recovery processing method for a computer system according to an embodiment of the present invention.

FIG. 2 is a processing flowchart (part 2) of the failure recovery processing method of the computer system according to the embodiment of the present invention.

FIG. 3 is a hardware configuration diagram for realizing a failure time process recovery method for a computer system according to an embodiment of the present invention.

FIG. 4 is an explanatory diagram illustrating an example of a sequence of updating data of a block in a failure recovery processing method for a computer system according to an embodiment of the present invention.

FIG. 5 is an explanatory diagram of an example of a storage state of files and data in a main storage device and a magnetic disk device in a failure processing recovery method for a computer system according to an embodiment of the present invention.

[Explanation of Codes] 1 ... Main storage device, 2-5 ... Magnetic disk device, 7 ... CP
U, 12 ... Journal log storage area, 13 ... Failure recovery data storage area, 14 ... Input / output data storage area, 15 ...
Checkpoint storage area, 16 ... Application
Program (AP) storage area.

Claims (1)

[Claims] 1. An update journal storage unit that stores an update journal in a volatile manner each time an update request for update target data is issued, and the update target data is updated in response to the update request,
An updated data storage means for storing the updated data in a volatile manner, an unupdated data storage means for storing the unupdated data in a volatile manner each time the update is confirmed, and at least one or more updates by the same task. Each time a request is issued, one transaction is confirmed, and each time this one transaction is confirmed, the update journal and the update information storage means for storing the data before update and the data after update in a non-volatile manner. When a failure is detected, the update journal stored in the update information storage means is updated by the transaction confirmed in the closest previous period when the failure confirmed by the failure detection occurs, and the update journal storage means is used. Stored in
Similarly, the pre-updated data stored is stored in the pre-updated data storage means, and the post-updated data stored in the same manner is stored in the post-updated data storage means. A failure recovery method characterized by recovering the storage status of a transaction that was established in the previous period.