JPH02206842A - System for restoring fault of information processing system - Google Patents

Abstract

PURPOSE:To shorten a read time and to speed up a restoration processing by reading only a part including information which requires a restoration processing by means of history information into a main storage device or a virtual storage device and executing the restoration processing through the use of the history information. CONSTITUTION:Various history information accompanied by a transaction processing is obtained in a history information file 40 for various faults in the middle of operation. For shortening the restoration processing when a system stops due to the fault, the copy of resident information 12 on a memory 11 is stored in an area 32 in a CD file 30, and the copy is updated while the system is operated at check points installed at prescribed intervals, for example. When the system stops due to the fault, only the part updated after the final check point time in information 12 is restored by using memory resident information update history information in the file 40 and the contents (a) and (b) of the part concerned, which have been stored in the area 32 in the file 30.

Description

DETAILED DESCRIPTION OF THE INVENTION [Field of Industrial Application] The present invention relates to a failure recovery method for an information processing system that performs transaction processing. The present invention relates to a failure recovery method for an information processing system suitable for an information processing system that requires high-speed system recovery.

[Conventional technology]

Generally, in an information processing system that performs transaction processing such as an online system, it is necessary to maintain the logical consistency of the system even when a failure such as a system down occurs. Normally, information that manages various system states (for example, information representing bank terminal status, online statistical information, etc.) is stored in main storage or virtual storage (hereinafter referred to as
Unless there is a particular need to distinguish, main storage and virtual storage are collectively held in memory (memory). Additionally, some frequently accessed files and databases may be made resident in memory for the purpose of speeding up processing. This memory resident information is lost in the event of a failure such as the above-mentioned system down.

In order to solve this problem, conventional methods have been used to acquire various system history information while the system is running, and at regular intervals (at regular intervals or at predetermined updates) to speed up the recovery process. At each checkpoint, various information on the memory (memory resident information) is stored in a nonvolatile storage device (for example, an external storage device such as a magnetic disk device), and the cause of the failure is removed. Afterwards, it is common practice to recover the data in memory based on the information on the non-volatile storage device and the history information obtained after the checkpoint.

(J.N. Gray, Notes on Database Operating Systems (197J3), Operating System Down Advanced Course, p. 461.

R, Beyer, R, M, Graham, & G, Siegmuller, eds., Schbringer-Verlag (J, N, Gra
y, Notes on Data Ba5e
Operating Systems (1978) +
Operating Systems: An Adv.
ancedCourse+ p461, R, Bay
er, R.M., Graham, and G.

Seegmuller (eds,) Springe
r-Verlag).

According to this method, if the system stops due to a failure, it is possible to restore the system to a logically consistent state before the failure using the contents stored in the nonvolatile storage device and history information. .

[Problem to be solved by the invention]

However, the above-mentioned conventional technology had the following problems. In other words, large-scale DB/DC systems such as bank online systems (Database Data Communicator)
In recent years, the social impact of a system outage due to a system failure has been increasing, and there is a demand for system recovery in a short period of time in the event of a system failure. In recovery processing when a system stops due to a failure, the memory resident information acquired at the checkpoint is read into memory from the non-volatile storage device, and then the update history information of this memory resident information after the checkpoint is used. to recover the contents of resident information. However, in large-scale systems such as bank online systems, the amount of memory-resident information is increasing as the storage capacity of main storage devices increases.
Since it takes a long time to read the memory resident information from the nonvolatile storage device into the memory in the recovery process, the system recovery process may take a long time. In particular, in the above-mentioned conventional technology, during the recovery process, all of the information (data) recorded in the non-volatile storage device at the time of the checkpoint is read into memory, so this reading time is extremely long. This is a factor that increases system recovery processing time.

The present invention has been made in view of the above circumstances, and its purpose is to solve the above-mentioned problems in the failure recovery method of conventional large-scale DB/DC systems, and to reduce the recovery time when the system is stopped due to failure. An object of the present invention is to provide a failure recovery method for an information processing system that significantly reduces the time required.

[Means to solve the problem]

In order to achieve the above object, the failure recovery method of the information processing system of the present invention has, as its basic configuration, a system failure recovery method (whereas the above conventional technology stores data in an area on a non-volatile storage device). While all of the stored resident information is read into memory, only the part of the resident information stored in the area on the non-volatile storage device that includes information that requires recovery processing using historical information (In other words, in order to set up a checkpoint, only the part corresponding to the information that has been updated since the last time the memory-resident information was written to the non-volatile storage device) is ) and configure it to recover using history information.

In addition, memory resident information other than the information recovered by the above configuration may be transferred from the nonvolatile storage device to the memory (main storage device or virtual storage device) during normal processing performed after the system recovery processing is completed. Configure to read and recover entire memory-resident information.

[Effect]

The effect based on the above configuration will be explained.

In the system recovery process, only the part of the memory-resident information that needs to be restored based on historical information, that is, the part corresponding to information that has been updated since the last checkpoint, is read into the main memory from the non-volatile storage device.

For example, all the information (data) written from the main memory to the nonvolatile storage device at the time of checkpoint is a, b, c, d.
Then, after that, only data a and b become a', b
', and data c and d are not updated, the information (data) read from the non-volatile storage device into the main memory during system recovery processing will be only a and b, and this a , b and history information a-+a', b-+
b', the data on the main memory will be recovered.

As a result, compared to the conventional case where the entire memory resident information is read, the time required to read the memory resident information at the time of system recovery can be significantly reduced.

Therefore, it is possible to quickly recover the system when the system is stopped due to a failure.

〔Example〕

An embodiment of the present invention will be described below with reference to the drawings.

FIG. 1 is a diagram showing an overview of the configuration and operation of this embodiment, and is a diagram showing the features of the present invention. For this diagram,
This will be explained when describing the outline of the operation of this embodiment.

First, the general configuration of this embodiment will be explained with reference to FIG. FIG. 2 is a diagram showing the overall configuration of the information processing system in this embodiment. CPU/memory (main memory or virtual storage, hereinafter simply referred to as "memory") 10
A database (hereinafter referred to as r) stored on a magnetic disk, etc.
A checkpoint dump file (hereinafter abbreviated as "rCD file") 30, and a history information file 40 are connected. The CD file 30 and the history information file 40 may be an external storage device such as a disk, but are not necessarily limited to this, and may be an internal memory, as long as they are non-volatile.

FIG. 3 is a diagram showing the contents of memory ti (memory in CPU and memory 10), including memory resident information 12 such as resident tables and resident DB used in transaction processing of the information processing system, and control information 13 for checkpoint processing. , of the memory resident information 12 (for example, the part that has been updated is marked with "rl", and the part that has not been updated is marked with "0")
Indicates whether or not each part of the updated part management information 14 and memory resident information 12 is memory resident (for example, "1" is set for a part that has already been recovered on the memory by the recovery process, and "1" is set for a part that has not been recovered on the memory yet. r□,) memory resident presence/absence management information 15 exists on the memory 11. The updated portion management information 14 and the memory resident status management information 15 are provided as features of this embodiment. CD file 3
0 is a file for acquiring information necessary to recover the resident information 12 on the memory 1 in the recovery process when the system is stopped due to a failure, at checkpoints set at regular intervals during system operation.

FIG. 4 shows the detailed structure of the CD file 30. Fourth
In the figure, 31 is an area for storing checkpoint processing control information, and 32 is an area for storing a copy of the memory resident information 12. Checkpoint processing control information 31
is information indicating whether or not writing to a CD file has been completed at the time of the checkpoint. If a failure occurs during this writing, this written data cannot be used, so writing to the CD at the previous checkpoint is performed. It is used to decide to perform recovery processing based on the information data obtained. Note that the control information 13 is also similar,
It is used to decide to recover from the history information from the previous checkpoint. It is sufficient that there is at least one copy storage area 32 for the memory resident information 12 of the CD file 30;
If a failure occurs during writing, the contents of the relevant part may be lost due to interruption of the writing process, and in that case, it will take a long time to recover the contents of the relevant part.

There are, for example, the following three methods to solve this problem.

(2) Leave enough room in the storage area, write each part of the memory resident information 12 to a location different from the location where it was written last time, and retain the content written last time until the writing process is completed.

(2) Secure two storage areas and sequentially write the contents of the memory resident information 12 to the two areas at checkpoints. (In other words, write the same content twice).

If a failure occurs during the second time, the one written in the first time is used, and if both the first and second times are normal, either one is used.

(2) Secure two storage areas, select each area alternately at each successive checkpoint, and write the contents of the memory resident information 12. If a failure occurs while writing on one side, what was previously written on the other side is used.

With these methods, if necessary, the CD file 30
can improve credibility. Hereinafter, in the embodiment, in order to simplify the explanation, the copy storage area of the memory resident information 12 will be described as one page. CD file 30
A DASD (direct access storage device) such as a magnetic disk is usually used as the medium. In the case of a system such as a bank online system that requires high traffic and high-speed recovery in the event of a system failure, a semiconductor disk, which is a high-speed random access storage medium in which a semiconductor storage device is made non-volatile by a battery, is used.

The history information file 40 contains history information necessary for system recovery processing when the system is stopped due to a failure (for example, in the case of bank deposits, the contents of each transaction, which value of which account changed to which value at the end of the transaction, etc.) information), history information for database media failure recovery (for databases such as magnetic disks, it is necessary to recover data in the event of a failure, so history information for that purpose), history information for recording business processing details (bank, etc.) By law, it is necessary to record what transactions have been done with which customers, so history information for that purpose), history information used in user programs that perform various business processes (statistical information such as which account was used for what kind of processing, etc.) history information for processing programs),
etc. are included.

History information required for system recovery processing includes update history information of resident information in a database or memory, history information regarding input/output messages, history information indicating transaction completion/cancellation, and the like. The medium for the history information file 40 is usually a DASD such as a magnetic disk,
Or use magnetic tape. In the case of DASD, historical information that needs to be stored for a long period of time must be unloaded from the DASD to magnetic tape. In addition, in the case of a system such as a bank online system that requires high traffic and high-speed recovery in the event of a system failure, a semiconductor disk may be used as the medium for the history information file 40, similar to the above-mentioned CD file 30, or It is necessary to use a method such as acquiring the system recovery history report and other history information separately on separate media. However, in this example, in order to simplify the explanation,! ! History information is D
It is assumed that the information is acquired all at once in the history information file 40 on the ASD.

Next, the operation of the system will be explained.

First, an overview of the system operation will be explained using FIG. In this system, in preparation for various failures during operation, various historical information associated with transaction processing is acquired in the historical information file 40. Furthermore, in order to shorten the recovery process when the system stops due to a failure, a copy of the resident information 12 on the memory 1 is stored in the area 32 of the CD file 30, and at checkpoints set at regular intervals during system operation, for example. These copies are being updated. In the illustrated example, at checkpoint T, all resident information a,
b, c, and d are copied from the memory 11 to the CD file 30. After that, until the failure occurs at time T2, part of the resident information a and b are updated as a and b, but c,
d is not updated.

When the system is stopped due to a failure, the database, messages, etc. are recovered, and the parts of the memory resident information 12 updated after the last checkpoint T1 (a,
The part corresponding to a' and

Only the portion corresponding to b') is updated to memory resident information update history information in the history information file 40 (history information indicating that a has been changed to a and history information indicating that b has been changed to b'). and recover using the contents a and b of the part stored in the area 32 of the CD file 30 (T,
). Then, among the memory resident information 12, information c and d that were not recovered onto the memory 11 in the recovery process are
CD file 3 at the point of ■ and ■ below after resuming normal processing.
0 into the memory 11 and restore the resident state.

■When the information is needed, such as access from each transaction.

- When the utilization rate of the CPU/memory 10 and the CD file 30 is low, and the impact of reading memory resident information from the CD file 30 on the normal processing of the system is small.

In addition, in Fig. 1, 121, 122, 123°124 are
Each indicates a transaction.

Next, the system operation will be described in terms of system startup operation, normal operation, transaction failure operation, checkpoint operation, system failure operation, and system recovery processing completion operation.

(1) Operation at System Startup When the system is started, a copy of the memory resident information 12 is acquired in the area 32 in the CD file 30. Furthermore, memory 1
1 is initialized, that is, all parts of the memory resident information 12 are set to a non-updated state. Further, the memory resident presence/absence management information 15 is set to a state in which all parts of the memory resident information are resident (recovery processing has been completed).

(2) Normal operation The processing according to the present invention from the start to the end of transaction execution is as follows.

(a) Access to memory resident information When it becomes necessary to refer to or update the memory resident information 12 during transaction processing, the memory resident information 15
, to check whether the information exists in the memory 11. If the information does not exist in the memory 11, the information is read from the CD file 30 and set in the memory resident information 12. Then, the portion of the memory resident presence/absence management information 15 related to the information is set to the memory resident state.

(b) Acquisition of historical information When events such as updating of the database or memory resident information 12, input/output of messages, completion of transactions, etc. occur during transaction processing, historical information regarding these events is acquired in the historical information file 40. Note that each piece of history information is not immediately written to the history information file 40, but is accumulated in a buffer on the memory. Then, it is written to the history information file 40 when the buffer is full or when a transaction is completed.

(c) Setting of updated partial management information When the memory resident information 12 is updated, the above-mentioned history information is acquired and the corresponding portion of the updated partial management information 14 on the memory 1 is set to indicate that it has been updated.

(d) Transaction completion processing When a transaction ends, the following steps are performed.

■ Acquisition of history information that has not yet been acquired for the transaction.As in (c) above, when the history information accumulated in the -1 buffer memory has not yet been written to the history information file at the time of transaction completion, this is It's about writing it down.

■Acquisition of historical information indicating transaction completion (indicating whether the transaction itself was completed).

■Reflect database updates on the medium (database).

■Obtain history information indicating that all transaction processing (processing including database updates) has been completed.

(3) Operation in the event of transaction failure When canceling the transaction processing result due to a partial failure, the following steps are performed.

(a) Restoration of memory resident information 12 The contents of the memory resident information 12 updated by the processing liquid transaction are restored to the state before the update using history information regarding the transaction. At the same time, update history information indicating that the data in the resident information 12 has been returned to the content before the update is acquired in the history information file 40.

(b) Restoring the database The portion of the database updated by the transaction is restored to its pre-update content using history information regarding the transaction.

(c) Acquisition of cancellation processing completion history information History information indicating completion of transaction cancellation processing (transaction cancellation processing) is obtained in the history information file 40.

(4) At checkpoint: A checkpoint is set every time a certain number of pieces of operation history information (specified at the time of system initialization) are acquired. The processing at the checkpoint is as follows.

(a) The copy of the resident information 12 stored in the area 32 is updated based on the contents of the update portion management information 14 at the checkpoint for writing out the memory resident information. That is, among the memory resident information 12,
The contents of the portion set as updated in the updated portion management information 14 are reflected in the copy. Thereafter, the updated portion management information 14 is initialized.

(b) Enabling checkpoint processing The history information in the history information buffer on the memory 11 is written to the history information file 40. Then, the number of the last acquired history information in the history information file 40 at the start of the check point (the M layer information is given a consistent number to identify each piece of history information) is transferred to the CD file 30. Checkpoint processing control information storage area 3 inside
Set to 1. These two processes enable the process at the checkpoint.

(5) At the time of system failure When the system stops due to an operational failure, system recovery processing is performed using a copy of the memory resident information 12 stored in the area 32 of the CD file 30 and various types of history information in the history information file 40. FIG. 5 shows a schematic flow of system recovery processing.

This will be explained below with reference to FIG.

(a) Positioning to final history information (step 101)C
The history information number is read from the checkpoint processing control information storage area 31 in the D file 30. Then, using the history information of the corresponding number in the history information file 40 as a base point, a binary search method (a method of dividing the data string lined up in order in half and repeatedly searching in which half the target data is located) is used. Position it as the last history information acquired just before the system was stopped.

(b) Initialization of various management information (step 102) Before starting recovery on the memory 11, memory resident information 1
The update portion management information 14 and the memory residency management information 15, which are the management information of No. 2, are initialized. That is, the updated portion management information 14 sets all portions of the memory resident information 12 to a state where they are not updated. In addition, the memory resident presence/absence management information 15 indicates that all parts of the memory resident information are stored in the memory.
Set to non-existent state.

(C) Transaction status analysis and uncompleted transaction return processing (step 103) The history information in the history information file 40 is moved in the reverse direction from the last acquired information to the information at the start of the checkpoint (more precisely, the history information in the history information file 40 is read up to the first historical information about transactions that were running at the time and were not completed at the time the system stopped due to a failure (incomplete transactions),
The processing status (completed/uncompleted) of each transaction is analyzed, and updated data is returned for uncompleted transactions.

The processing status of a transaction is analyzed based on whether history information indicating transaction completion, history information indicating completion of all transaction processing, and history information indicating completion of transaction cancellation processing is obtained. Depending on the content of the recovery process, the transaction processing status is divided into seven states as shown in FIG.

This will be explained below using FIG. 6. In addition, in the figure, 111~
117, each black dot to black dot represents one transaction, an X mark indicates the occurrence of a transaction failure, a wavy line indicates transaction cancellation processing, a dotted line indicates transaction suspension due to a failure, and an O mark indicates acquisition of history information indicating transaction completion. .

■Transactions of type [Like the transaction 111 in FIG. 6, these are transactions that were completed (including the case of cancellation) before the last valid checkpoint. Transactions of type ■ do not require recovery processing and are not subject to processing state analysis.

■Transactions of type ■Like transaction 112 in FIG. 6, these are transactions that have been successfully completed after the start of the last valid checkpoint (the execution start time is irrelevant). Therefore, it is necessary to reflect this normally completed transaction (update result) in the recovery process. Recovery processing for the type ■ transaction is performed in step 104 .

■Transaction of type ■Like the transaction 113 in FIG. 6, this is a transaction that started before the end of the last valid checkpoint and completed the cancellation process after a transaction failure occurred. In this case, the transaction 113 immediately before cancellation may have already been copied to the CD file. Therefore, in the recovery process, it is necessary to use the transaction immediately before 113 to carry out a return process in accordance with the cancellation described above. Recovery processing for the type ■ transaction is performed in step 104 .

■Type ■ Transactions Like the transaction 114 in FIG. 6, these are transactions that begin after the end of the last valid checkpoint and complete cancellation processing after a transaction failure occurs. In the case of a type ■ transaction, the process of returning the updated portion of the database 20 by the transaction to its pre-update content has been completed. In addition, the update result of the memory resident information 12 by the transaction is stored in the CD
It is not reflected in the copy in the area 32 of the file 30 (it is only up to one point before 114), and no reversal processing is necessary.Therefore, there is no need for recovery processing for type (2) transactions.

■Type V transactions As in transaction 115 in Figure 6, after obtaining history information indicating transaction completion (OEII), a failure occurs before obtaining history information indicating completion of all transaction processing (black dots on the right). A system outage occurs,
This is a transaction whose processing has been interrupted. Furthermore, because a failure occurred at the time when the database should have been updated (from the O mark to the black dot on the right), the database may not have been updated.

Therefore, in the recovery process, it is necessary to reflect the 115 transactions to the database. Recovery processing for type V transactions is performed in step 104.

■Transactions of type ■As in transaction 116 in Figure 6, the transaction started before the end of the last valid checkpoint, and the system stopped due to a failure before acquiring the history information indicating transaction completion, and processing was interrupted. It is a transaction. In this case, similarly to type (2) above, there is a possibility that the update results by transaction 116 have been copied to the CD file. Therefore, the transaction of type ■ is processed by the database 20 in this step 103.
and returns the memory resident information 12. That is, using the pre-update information of the transaction in the history information file 40, the portions of the database 20 and the memory resident information 120 updated by the transaction are restored to their pre-update contents. In the process of restoring the memory resident information 12, first, the memory resident presence/absence management information 15 is referred to to check whether the information exists on the memory 11. If the information does not exist on the memory 11,
A copy of the information is read from the area 32 of the CD file 30 and set as the memory resident information 12, and the pre-update information is used to restore the content before the update. Then, it is registered in the updated portion management information 14 and the memory residency management information 15 on the memory 11 that the updated portion has been updated and that it has been recovered on the memory 11, respectively.

■Transactions of type ■Transactions such as transaction 117 in Figure 6, which started after the last valid checkpoint ended and the system stopped due to a failure before acquiring the history information indicating transaction completion, and the processing was interrupted. It is. In the transaction of type ■, "m) The update result of the memory resident information 12 by the transaction is not reflected in the copy in the area 32 of the CD file 30, and the return processing of the memory resident information 12 is not necessary. However, There is a possibility that the database 20 is actually updated (the database update is performed without necessarily waiting for transaction completion), and in this step, the pre-database update information of the transaction in the history information file 40 is used. to return to the contents before the update.

(d) Reflection of updated results of completed transactions and return processing of canceled transactions (step 104) The history information in the history information file 40 is updated from the information at the start of the last effective checkpoint (more precisely, the transaction of type V mentioned above (from the oldest history information and the information at the start of the last valid checkpoint) forward to the last acquired information, reflect the update results of completed transactions, and return canceled transactions. Transactions that require recovery processing in this step are type ■, ■, and V transactions.

■Transaction of type ■In case of transaction of type ■, database 20
The actual update has been completed. Therefore, history information file 4
The updated result of the transaction is reflected in the memory resident information 12 using the update history information of the memory resident information 12 since the start of the last valid checkpoint of the transaction, which is read from 0. In addition, memory resident information 12
In the recovery process, as in the previous section (C) (2), first, the memory resident presence/absence management information 15 is referred to to check whether the information exists on the memory 11. If the information does not exist on the memory 11, save the information to the CD.
It is read from the file 30, set as memory resident information 12, and restored to the updated content using update history information.

Then, it is registered in the updated part management information 14 and the memory residency management information 15 on the memory 11 that the updated part has been updated and that it is resident in the memory 11, respectively.

■Transaction of type ■In the case of a transaction of type ■, the process of restoring the updated portion of the database by the transaction to its pre-update content has been completed. Therefore, history information file 4
Using the update history information (update history information indicating that the updated data has been returned to the content before the update) of the memory resident information 12 of the last valid checkpoint start point of the transaction read from 0, the previous section (C ), similarly to (), the return processing of the memory resident information 12 and the setting of the management information 14 and 15 are performed.

Transactions of type ■ In the case of transactions of type V, from the outside it is a completed transaction, but inside the system there is a possibility that the actual update of the database 20 has not been completed. Therefore, the result of updating to the memory resident information 12 performed by the transaction of type ■ is reflected and the management information 14.1
In addition to the settings in step 5, the database update history information of the transaction in the history information file 40 is used to reflect the database update by the transaction on the medium. Note that in order to perform this process, it is necessary to return to the first history information regarding the transaction, and there is a possibility that the history information may go back to before the start of the last valid checkpoint. To avoid this, in the case of a long transaction that spans multiple checkpoints, the database updates up to the start of the last valid checkpoint may be reflected on the medium by the end of checkpoint processing.

(6) System recovery processing completion operation When the system recovery processing of the system failure operation described in (5) above is completed, the system resumes normal processing. and,
As mentioned in the overview of the system operation above, the information (for example, c and d in FIG. 1) that was not recovered in the memory 12 during the recovery process out of the memory resident information 12 is stored as follows after normal processing is resumed. CD file 30 at the time of ■ and ■
It is read into the memory 11 from the upper area 32 to restore the resident state.

■When the information is needed, such as access from each transaction.

■When the CPU/memory IO and CD file 30 usage rates are low and the impact of reading memory resident information from the CD file 30 on the normal system processing is small.

As described above, according to this embodiment, in the recovery process in the event of a system failure, the time required to read memory resident information from a DASD or the like into the memory is greatly reduced, so the time required for the system recovery process can be significantly reduced. .

Note that supplementary matters regarding this example will be described below.

(1) Memory-resident DB In the above embodiment, the updated part of the memory-resident DB was also written to the same CD file as the resident table, etc., but in the case of a resident DB, it may be written to the DB entity on the DASD. . In this case, D
This has the effect of shortening the time required for the unloading process of B to the DB entity.

(2) Timing of writing to a CD file In the embodiment, data is written to a CD file (or to the DB entity in the case of a memory-resident DB in (1) above) at a checkpoint, but at the end of each transaction, the transaction There is also a way to export the updated part. In this case, in the system recovery process, only type V transactions require recovery of memory resident information, and the system recovery time is further shortened. Note that this method is highly effective for memory-resident information that is updated less frequently. Furthermore, by classifying memory resident information according to update frequency and using the present method and the method described in the embodiments, an efficient system can be achieved.

(3) Reading during recovery processing according to system definition Depending on memory resident information, there is information that needs to be recovered in memory before normal processing is resumed, regardless of whether or not recovery is necessary based on history information.

However, in this embodiment, even such information may not remain resident in the memory when normal processing is resumed (for example, information that is not updated but is frequently referenced). To solve this problem, it may be possible to specify that specific memory resident information be read into memory during system recovery processing and made memory resident by definition at system startup or by inputting a command during system operation.

(4) Operation when starting the system In the above-described embodiment, when starting the system, the entire memory resident information is read into the memory and made resident. However, similar to system recovery processing at system startup, the information is stored in memory only when access to the information occurs or when it is specified to be memory resident at system startup as in (3) above. You may also load it into a file and make it resident.

(5) Speeding up through parallel processing In the above embodiment, in the recovery process when a system failure occurs,
Reading of history information and reading of a copy of memory resident information stored in an area on the CD file are performed in parallel. That is, when update history information of memory resident information is read from the history information file, a copy of the resident information is read into the memory from the area on the CD file, and the next history information is read from the history information file in parallel. Since most of the time required for system recovery processing is the time for reading the M-layer information file and CD file, this method can further reduce the time required for system recovery processing.

[Effects of Examples]

According to the embodiments described above, in the recovery process when the system is stopped due to a failure, the time required to read memory resident information onto a memory such as a DASD is greatly reduced, so that the system recovery time can be significantly reduced. The effects are estimated below using a typical bank online system as an example.

<a> Preconditions (i) Amount of history information acquired/per transaction 8KB (ii) f
The f-history information file/medium is a magnetic disk in both the conventional method and the method of the present invention.

(iii) Amount of memory resident information - Assuming both 40MB and 100MB.

(iv) The CD file/medium is a magnetic disk in both the conventional method and the method of the present invention.

(v) Update pattern - The number of times memory resident information is updated per transaction is normally two.

Further, as a case where the update frequency is low, the number of updates of memory resident information per transaction is assumed to be 0.5 times.

・The distribution of updated parts is random.

(vi) Estimation of system recovery time - The total time for the process of reading memory resident information from the CD file and the process of reading history information in backward and forward directions.

(vi) Checkpoint spacing ・Set to 1000 items.

(b) Effect estimation Determine the system recovery time for each of the conventional method and the method of the present invention.

(i) Conventional method - When memory resident information is 40MB - CD file loading time 33.0 seconds - History information loading time 13.2 seconds - System recovery time
Total 46.2 seconds ■When memory resident information is 100MB ・CD file loading time 82.5 seconds ・History information loading time 13.2 seconds ・System recovery time
Total 95.7 seconds (ii) Method of the present invention In the case of the method of the present invention, the effect differs depending on the update frequency.

(b) Update frequency is 2 times ■ When the memory resident information is 40MB ・CD file loading time 32.6 seconds ・History information loading time 13.2 seconds ・System recovery time
Total 45.8 seconds ■When Mesori resident information is 100MB ・CD file loading time 34.6 seconds ・History information loading time 13.2 seconds ・System recovery time
Total 47.8 seconds (b) Update frequency is 0.5 times ■ When memory resident information is 40 MB - CD file loading time 8.8 seconds - History information loading time 13.2 seconds - System recovery time
Total 22.0 seconds ■When Mesori resident information is 100MB ・CD file loading time 8.9 seconds ・History information loading time 13.2 seconds ・System recovery time
As shown by the total time of 22.1 seconds or more, the method of the present invention can significantly shorten the system recovery time in the event of a failure compared to the conventional method. In particular, the following effects can be cited as features.

(a) Even if the amount of memory resident information increases, the system recovery time hardly increases, and the effect is greater as the amount of memory resident information increases.

(b) In the conventional method, the system recovery time is not shortened even when the update frequency is low, but in the method of the present invention, the system recovery time is shortened as the update frequency decreases.

(c) When a semiconductor disk, which features high-speed random access, is used as a CD file, the system recovery time with the conventional method is 1/3 to 1/! However, in the case of the method of the present invention, it is reduced to 18. decrease to a certain degree.

(d) In the case of the conventional method, it was necessary to read a copy of the memory resident information from the CD file into the memory and then perform recovery processing using the history information.

On the other hand, in the case of the present invention, it is possible to read the history information and read the CD file in parallel, and it is possible to further shorten the system recovery time by about 20 to 30% compared to the above evaluation results. .

〔Effect of the invention〕

As explained in detail above, according to the failure recovery method of the information processing system of the present invention, during recovery processing from a system failure, recovery based on historical information among information stored in an area on a non-volatile storage device is possible. Only the part that contains the information that needs to be processed, that is, the part that corresponds to the information that has been updated after the checkpoint, is read into the main storage or virtual storage and recovered using the history information, so the entire resident information is Compared to the case of reading, the reading time can be significantly shortened and recovery processing can be speeded up, providing excellent effects.

[Brief explanation of the drawing]

FIG. 1 is a diagram illustrating an overview of an embodiment of the present invention, FIG. 2 is an overall configuration diagram of an information processing system to which the embodiment of the present invention is applied, and FIG. 3 is a diagram showing the contents of a memory. Figure 4 is C
FIG. 5 is a diagram showing the contents of the D file, FIG. 5 is an outline flowchart of system recovery processing, and FIG. 6 is a diagram explaining classification of transaction processing states. 10・・・・−・CPU/Memory, 11・−・−・・−
Memory unit (of CPU/memory 10), 12--Memory resident information, 13--Checkpoint processing control information, 14--Memory resident information update partial management information, 15-- −−−−−Memory resident status management information,
20---Database, 30---Checkpoint dump file (non-volatile storage),
31---1.--Checkpoint processing control information storage area, 32.--.Memory resident information copy storage area, 40.--.--History information file. Figure 5

Claims (1)

[Scope of Claims] 1. A history information file that performs transaction processing using information resident on the main storage device or virtual storage device, and stores history information of the transaction processing; In a failure recovery method for an information processing system, the information processing system includes a nonvolatile storage device for writing information contents, and in the event of a system failure, the history information and the contents written to the nonvolatile storage device are used to recover the resident information. Among resident information stored in an area on a non-volatile storage device, only a portion including information that requires recovery processing using history information is read into the main storage device or virtual storage device and recovered using the history information. A failure recovery method for information processing systems characterized by: 2. A history information file that performs transaction processing using information resident on the main storage device or virtual storage device and stores history information of the transaction processing, and a nonvolatile file that writes the contents of the resident information during system operation. In a failure recovery method for an information processing system that includes a permanent storage device and recovers the resident information using the history information and contents written to the nonvolatile storage device in the event of a system failure, Of the resident information stored in the area, only the portion that includes information that requires recovery processing based on history information, and the portion that is specified for recovery of the resident information before normal processing is resumed, is stored in the main storage or virtual storage device. A failure recovery method for an information processing system characterized by reading data into the system and performing recovery using history information. 3. During normal processing after the completion of recovery processing in the event of a system failure, among the resident information stored in the area on the non-volatile storage device, the part whose resident state was not restored by the recovery processing is transferred to the main memory. 3. The failure recovery method for an information processing system according to claim 1, wherein resident information is recovered by reading the information into a device or a virtual storage device. 4. According to claim 1 or 2, in a recovery process when a system failure occurs, reading of the history information and reading of resident information stored in an area on the nonvolatile storage device are performed in parallel. Disaster recovery processing method for information processing systems.