JPH01125631A - System fault recovering system - Google Patents

Abstract

PURPOSE:To quickly recover a system fault by setting the check points during the operation of a system and replacing and storing the back-up copies of the residence information for each check point. CONSTITUTION:The area where plural pieces of memory residence information 12 are added to one or more nonvolatile memory (CPU/memory) 10. The transaction processing is carried out while a system is working and the history information produced by said transaction processing is acquired for a recording history information file 50 and a system recovering history file 40. When the file 40 acquires a fixed number of items, the check points are added. Then the areas 34 and 38 of a check point dump file 30 are alternately selected for each check point and the contents of storage are replaced. Then, the residence information 12 are recovered at a system fault with use of the replacement history information stored in the file 40 and based on the final storage contents of both areas 34 and 38. Thus the previous histories can be omitted and the system fault can be recovered at a high speed.

Description

[Detailed Description of the Invention] [Field of Industrial Application] The present invention relates to an information processing system that performs transaction processing, and is particularly suitable for an information processing system that requires rapid system recovery when the system is stopped due to a failure. Concerning disaster recovery methods.

[Conventional technology]

In information processing systems that perform transaction processing such as online systems, it is necessary to maintain the logical consistency of the system even in the event of a failure such as a power outage or system down.Normally, various states of the system are managed. Information is held on the main memory or virtual memory, and these are lost in the event of the above failure. For this reason, various historical information about the system has been acquired while the system is running, and checkpoints have been set at regular intervals during system operation to speed up recovery processing.

2. Description of the Related Art It is widely practiced to record various types of information on a main storage device or a virtual storage device into a nonvolatile storage device at the time of a checkpoint. (J.N. Gray, Notes on Database Operating Systems (1978), Operating System Down Advanced Course, R. Beyer, R.M., Graham, & G. Schiebmuller, eds., Springer Verlag (J.N.)
.

Gray, Notes on Data Ba5e
0peratin(5yste+*5(1978), O
Perating Systems: An Advantage
ced Course.

R+Rayer, R, M, Graham, and
G. Seegmuller (eds,) Spring
er-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 that the invention seeks to solve]

However, the above-mentioned conventional technology had the following problems. In other words, (1) At the time of a checkpoint, all the resident information in memory (main memory or virtual memory) is acquired to a non-volatile storage device, so the writing process may become a bottleneck and reduce system performance. There is.

(2) Recovery processing when the system stops due to a failure.

After reading the memory resident information acquired at the time of the checkpoint into the memory from the nonvolatile storage device, the contents of the resident information are recovered using the resident information update history information after the time of the checkpoint. Therefore, by shortening the checkpoint interval, system recovery time can be shortened. On the other hand, large-scale databases such as bank online systems
The social impact of a system outage due to a system failure has been increasing dramatically in recent years, and there is a demand for system recovery in a short period of time in the event of a system failure. However, in these large-scale systems, the amount of memory-resident information is increasing as the storage capacity of the main storage device increases, and the time required to acquire memory-resident information at checkpoints tends to increase. The above-mentioned checkpoint interval cannot be made shorter than the time required to acquire resident information to a nonvolatile storage device, so it is difficult to shorten checkpoints with conventional methods, and system downtime in the event of a failure will be reduced in the future. may be prolonged.

The present invention has been made in view of the above information, and its purpose is to solve the above-mentioned problems in the failure recovery method of conventional large-scale DB/DC systems, and to save memory resident information at the time of checkpoint. An object of the present invention is to provide a system failure recovery method that greatly improves system performance by reducing the overhead acquired in a nonvolatile storage device, and also significantly shortens the recovery time when the system is stopped due to a failure.

[Means for solving problems]

The above objects of the present invention are achieved by the following (1) to (3).

(1) One or more areas for storing memory-resident information are provided on a nonvolatile storage device, and a backup copy of the memory-resident information is stored in each area. Each area may be located on the same nonvolatile storage device, or may be located on different nonvolatile storage devices.

(2) At the time of a checkpoint, one area is selected from the plurality of memory resident information storage areas.

Update the backup copy stored in the selected area. The area selection method is to sequentially select multiple areas for each checkpoint.

(3) Each memory resident information storage area is provided with updated part management information that stores which part of the resident information has been updated since the last update of the backup copy stored in the area, and is updated when the resident information is updated. Memorize parts. In the above-mentioned backup copy update processing at checkpoint, based on the updated part management information corresponding to the area selected at checkpoint, only the updated part of the backup copy stored in the area after the previous update is updated. do.

[Effect]

The operation of the above means will be described below.

(1) Multiple areas are provided to store backup copies of memory-resident information, and at the time of a checkpoint, the areas to be updated at the checkpoint are selected in order, so if a failure occurs during the update process, the backup copy will be copied during the update. Even if the contents of the system are destroyed, the system can be recovered using the backup copy stored in the area selected during the previous checkpoint.

(2) At the time of a checkpoint, the memory resident information that has been updated since the last update of the backup copy is updated for the backup copy of the memory resident information, so the processing overhead at the time of a checkpoint is small and the processing time is short. Therefore, in addition to improving system performance, by making the checkpoint interval sufficiently short, 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 operation of this embodiment, and is a diagram showing the features of the present invention. This diagram will be explained when describing the outline of the operation of this embodiment.

First, the configuration of this embodiment will be explained. FIG. 2 is a diagram showing the overall configuration of the information processing system in this embodiment,
CPU/memory (main storage or virtual storage) 1
0, a database 20.0 stored on a magnetic disk or the like.
Checkpoint dump file (hereinafter referred to as CD file) 30. System recovery history information file 40. A recording history information file 50 is connected.

FIG. 3 is a diagram showing the contents of the memory 11, which includes resident information 12, such as resident tables used in transaction processing of the information processing system.・Control information 1 at checkpoint
3. Also, update portion management information 14 and 15 provided for each backup copy storage area of memory resident information 12, which will be described later, exists on the memory 11.

The CD file 30 is a file that acquires information necessary to recover the resident information 12 on the memory in a recovery process when the system is stopped due to a failure, at checkpoints set at regular intervals during system operation. The structure of the CD file 30 is shown in FIG.

In this embodiment, two areas are provided for storing backup copies of the memory resident information 12 on the nonvolatile storage device. It is sufficient to have at least one backup copy storage area, but if a failure occurs during the backup copy update process, the contents of that part may be lost due to interruption of the write process.

In that case, it will take a long time to recover the contents of that part. Therefore, in this embodiment, there are two backup copy storage areas for the memory resident information 12. In FIG. 4, 31 and 35 are areas composed of the above-mentioned storage areas and related information storage areas, including management information areas 32 and 36 at checkpoint, and an update partial management information storage area for other storage areas, respectively. 33 and 37
, backup copy storage area 3 of memory resident information 12
4 and 38. A DASD (direct access storage device) such as a magnetic disk is normally used as the medium for the CD file 30. This embodiment is intended for a system such as a bank online system that requires high traffic and high speed recovery in the event of a system failure, and uses a semiconductor disk in which the semiconductor storage device is made non-volatile by a battery.

The system recovery history information file 40 is a file that stores history information necessary for system recovery processing when the system is stopped due to a failure. History information required in the system recovery process includes update history information of resident information in a database or memory, history information regarding input/output messages, history information 1 indicating transaction completion/cancellation, and the like.

Normally, a DASD such as a magnetic disk is used as the medium for the system recovery history information file, but in this embodiment, a CSD is used.
Like the D Faol 30, a semiconductor disk is used. The history information required for system recovery processing is basically information after the last valid checkpoint. therefore,
If you have secured enough file capacity (preferably several times the minimum required amount) to store history information in these ranges, you can use the wraparound method to delete old information from the system recovery history information file 40 and repeat it. can be used.

The recording history information file 50 includes history information for database medium failure recovery, history information for recording business process contents, history information 1 used in user programs that perform various business processes, and the like. As the acquisition medium, a DASD such as a magnetic disk or a magnetic tape is used. Recording history information needs to be stored for a long time, so even if it is acquired on a DASD, it must ultimately be copied onto a magnetic tape and stored.

Next, the operation of the system will be explained. First, we will explain the outline of system operation using Figure 1.
In preparation for various failures during operation, various types of history information associated with transaction processing are acquired in a system recovery history information file 50 and a recording history information file 60. Furthermore, in order to shorten the recovery process when the system stops due to a failure, a backup copy of the resident information 12 on the memory 11 is stored in areas 34 and 38 in the CD file 3o,
These backup copies are updated at checkpoints set at regular intervals during system operation. When the system stops due to a failure, the CD file 30
The resident information 12 is recovered using the resident information update history information in the system recovery history information file 40 based on the last updated backup copy of the backup copies stored in the area 34 or 38.

Next, system operations will be described by dividing them into operations at system startup, operations at normal times, operations at transaction failures, operations at checkpoints, and operations at system failures.

(1) Operation at System Startup When the system is started, a backup copy of the resident information 12 on the memory 11 is acquired into the backup copy storage areas 34 and 38 in the CD file 30. Further, the updated portion management information 14 and 15 on the memory 11 is initialized, that is, all portions of the memory resident information 12 are set to a non-updated state.

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

(a) During historical information acquisition transaction processing, database and memory 11
When events such as updating of the above resident information 12, message input/output, and transaction completion occur, history information related to these events is acquired from the system recovery history information file 40 and the recording history information file 5o.

Which or both of these files should be used to acquire various types of history information is specified at the time of system initialization. Note that each history information is not immediately written to the above file, but is accumulated in a buffer on the memory. Then, when the buffer is full or in the case of system recovery history information, it is written to the above-mentioned file medium at a time such as when a transaction is completed.

(b) Setting of updated partial management information When the memory resident information 12 is updated, the updated page management information 14 on the memory 11 is
And it is set that the part corresponding to the updated part of 15 has been updated.

(c) Transaction completion processing After the transaction is completed, perform the following steps.

■ Obtaining unobtained history information for the transaction.

■ Acquisition of history information indicating transaction completion.

■ Reflect database updates on the media.

■ Obtain historical information that indicates that all processing of a transaction 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 process of memory resident information 12 The contents of memory resident information 12 updated by the 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 restored to its pre-update content is acquired in the system recovery history information file 4°.

(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 the completion of cancellation processing of the transaction is obtained in the system recovery history information file 40.

(4) Operation at checkpoint A checkpoint is set every time a certain number of pieces of system recovery history information (specified at the time of system initialization) are acquired.

The checkpoint and time processing are as follows.

(a) Selection of backup copy update target area Select the area storing the backup copy to be updated at the time of the checkpoint, and set information identifying the selected area in the checkpoint control information 13 on the memory 11.

In this embodiment, there are two backup copy storage areas 34 and 38, and these areas are alternately selected for each checkpoint. The case where area 34 is selected will be described below.

(b) Acquisition of updated partial management information Updated partial management information on the memory 11 corresponding to an area different from the area selected by the above process is transferred to the CD file 3.
0 to the updated partial management information storage area corresponding to the selected area. In the case of this embodiment, it is assumed that the updated portion management information 14 corresponds to the backup copy storage area 34 and the updated portion management information 15 corresponds to the area 38. Therefore, when the area 34 is selected, the contents of the updated partial management information 15 are written to the updated partial management information storage area 33.

(c) Updating the backup copy The backup copy of the resident information 12 stored in the area 34 is updated based on the contents of the updated partial management information 14 corresponding to the selected area 34 at the time of the checkpoint. That is, the contents of the portion of the memory resident information 12 that is set to have been updated in the updated portion management information 14 are reflected in the backup copy. Thereafter, the updated portion management information 14 corresponding to the area 34 is initialized.

(d) Enabling checkpoint processing The system recovery history information in the history information buffer on the memory 11 is written to the system recovery history information file 40. Then, the number of the last acquired history information in the system recovery history information file 40 at the start of the checkpoint (the history information is given a consistent number to identify each piece of history information) is transferred to the CD. The management information area 32 corresponding to the selected area 34 in the file 30 is set.

These two processes enable the process at the checkpoint.

(5) At the time of system failure When the system is stopped due to an operational failure, system recovery processing is performed using a backup copy of the memory resident information 12 in the CD file 30 and various types of history information in the system recovery history information file 40. FIG. 5 shows a schematic flow of system recovery processing. This will be explained below with reference to FIG.

(a) Selection of read target area (step 101) Read the history information numbers set in the management information areas 32 and 36 from the CD file 30, and select the backup copy storage area corresponding to the area to which the new number is set. Select as the read target area. Below, management information area 32
The explanation will be based on the assumption that the number set in . Therefore, area 34 is selected as the backup copy readout target area.

(b) Backup copy reading step 102) The backup copy of the memory resident information 12 is read from the area 34 selected by the above process and developed as the resident information 12 on the memory II. Furthermore, CD file 3o
The updated portion management information is read from the updated portion management information storage area 37 in the storage area 37, and is developed as updated portion management information 15 for the area 38 on the memory 11.

Then, the updated portion management information 14 for the area 34 is initialized.

(c) Transaction status analysis and uncompleted transaction return processing (step) The history information in the system recovery history information file 40 is moved backwards from the latest acquisition information to the information at the start of the checkpoint (more precisely,
reads the processing status of each transaction (up to the first historical information about transactions that were running at the time the checkpoint started and had not completed when the system stopped).
Completed/uncompleted transactions are analyzed, and updated data is returned for uncompleted transactions. The transaction processing status includes historical information indicating transaction completion,
Analysis is performed based on whether history information indicating the 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.

■ Transactions of type ■ Transactions that complete (including the case of cancellation) before the last valid checkpoint, such as transaction 111 in Figure 6. Transactions of type I do not require 1 recovery processing. .

Not subject to processing status analysis.

■ Type II transactions Like the transaction 112 in Figure 6, the recovery process for type ■ transactions, which are transactions that completed normally after the start of the last valid checkpoint (the execution start point is irrelevant), is as follows: Do it in 103.

■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. Recovery processing for the type ■ transaction is performed in step 103 .

■Transaction of type ■Like the transaction 114 in FIG. 6, this is a transaction that starts after the end of the last valid checkpoint and completes the cancellation process 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. Further, the update result of the resident information 12 by the 1-ranzaktion is not reflected in the backup copy in the CD file 30, and no return processing is necessary. Therefore, recovery processing for type ■ transactions is unnecessary.

■ Transaction of type ■ As in transaction 115 in Figure 6, after acquiring ff&fi information indicating transaction completion, but before acquiring history information indicating completion of all processing of the transaction, a system stoppage occurs due to a failure, and processing is interrupted. This is an aborted transaction. Recovery processing for the type ■ transaction is performed in step 103 .

■ Transactions of type ■ Like the transaction 116 in Figure 6, it 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 the processing was interrupted. It is a transaction. In the type ■ transaction, the database 20 and resident information 12 are returned in this step.

That is, using the pre-update information of the transaction in the system recovery history information file 40, the updated portions of the database 20 and resident information 12 by the transaction are restored to their pre-update contents. and.

The fact that the updated portion has been updated is registered in the updated portion management information 14 and 15.

■ Transactions of type ■ Transactions, such as transaction 117 in Figure 6, which started after the end of the last valid checkpoint, and whose processing was interrupted due to a system stoppage due to a failure before acquiring history information indicating transaction completion. It is. For transactions of type ■, the result of updating the resident information 12 by the transaction is not reflected in the backup copy in the CD file 3o.

Processing to return the resident information 12 is not necessary. However, there is a possibility that the database 20 has been actually updated, and in this step, the pre-update database information of the transaction in the system recovery H history information file 40 is used to restore the content before the update.

(d) Reflection of updated results of completed transactions and return processing of canceled transactions (step 104) The history information in the system recovery history information file 40 is
Read forward from the information at the start of the last valid checkpoint (more precisely, from the oldest of the first history information regarding transactions of type ■ above and the information at the start of the last valid checkpoint) to the last acquired information, Reflects update results of completed transactions and returns canceled transactions. Transactions that require recovery processing in this step are transactions of types ■, ■, and ■.

■ Transaction of type ■ For transaction of type ■, database 20
The actual update has been completed.

Therefore, the updated result of the transaction is reflected in the resident information 12 using the update history information of the resident information 12 after the start of the last valid checkpoint of the transaction read from the system recovery history information file 40. Then, it is registered in the updated portion management information 14 and 15 that the updated portion has been updated.

(2) Transaction of type (2) In the case of a transaction of type In, the process of restoring the updated portion of the database by the transaction to its pre-updated content has been completed. Therefore, the update history information of the resident information 12 after the start of the last valid checkpoint of the transaction read from the system recovery history information file 40 (update history information indicating that the update data has been returned to the content before the update) is used. Then, the resident information 12 is returned. Then, it is registered in the updated portion management information 14 and 15 that the updated portion has been updated.

■ Transaction of type ■ In the case of a transaction of type ■, it is a completed transaction from the outside, but there is a possibility that the actual update of the database 20 has not been completed inside the system. Therefore, in addition to reflecting the update results performed in the transaction of type ■ to the resident information 12 and registering the update fact to the updated partial management information 14 and 15, the database of the transaction in the system recovery history information file 40 is updated. The database update by the transaction is reflected on the medium using the history information. Note that in order to perform this process, it is necessary to go back to the first history information regarding the transaction, and there is a possibility that it goes back to before the start of the last valid checkpoint. To avoid this, in the case of a long transaction that spans multiple checkpoints, data updates up to the start of the last valid checkpoint may be reflected in the medium by the end of checkpoint processing.

As described above, according to this embodiment, it is possible to improve the overall performance of the system by reducing the overhead during checkpointing, and to quickly recover the system when the system is stopped due to a failure. In addition, there is one effect unique to this embodiment.

By using a semiconductor disk as a medium for the CD file 30 and the system recovery history information file 40, it is possible to further improve the overall performance of the system and speed up system recovery. Furthermore, by acquiring memory-resident information updated partial management information for areas other than the backup copy update target area at the time of a checkpoint into the CD file 30, the updated partial management information 14 and 15 on the memory 11 can be recovered at the time of system recovery. can be easily done. Thereby, when the system recovery process ends, normal processing can be started without updating the backup copy that was not used in the system recovery process, so the system recovery time can be shortened. Note that the method of the present invention shown in this embodiment is suitable for cases where the amount of memory-resident information is not very large (about several MB or less)7 or when the amount of updates per transaction is large and the updated portion is not biased. , the effect cannot be expected.

Taking these cases into consideration, the effect of applying the present invention can be improved by classifying memory-resident information according to the update characteristics of each part, combining the method of the present invention with the conventional method, or using both methods depending on hourly fluctuations. can be done.

〔Effect of the invention〕

According to the present invention, the overall performance of the system can be improved by reducing the overhead during checkpointing, and the system can be quickly recovered when the system is stopped due to a failure. The effects will be estimated below using one typical bank online system as an example.

(a) Preconditions (i) Amount of system recovery history information to be acquired per transaction: 12 KB (ii) System recovery history information file/medium is a semiconductor disk in both the conventional method and the method of the present invention.

(ni) Memory resident information area - Assuming both 40MB and 100MB.

- Among the above areas, the system area is 4MB, and the rest is the user area.

(tv) The CD file/medium is a semiconductor disk in both the conventional method and the present invention method.

(v) Semiconductor disk performance ■Access time - 0.50 milliseconds when processing a block consecutive to the previous block in one input/output process - Average access time for other cases 0.73 milliseconds ■Data Transfer rate: 6 MB/sec (vi) Media storage format for various information: % Formula % - For both system recovery history information and CD information, 20 blocks are input/output in batches during checkpoints and system recovery processing.

- Overhead rings during discontinuous block input/output are ignored.

(i) Traffic - 100 items/second.

(m) Number of updates - The number of times memory resident information is updated per transaction is 4 times. The breakdown is twice for the system area and twice for the user area.

・The distribution of updated parts is random.

(x) Estimation of system recovery time - The total time of reading memory resident information from the CD file and reading system recovery history information in both forward and reverse directions.

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

(i) Conventional method ■When the memory resident information area is 40MB ・CD information input/output time 11.8 seconds ・Checkpoint interval From the CD information input/output time and traffic, the minimum is 120 MB
0 items.

- Time to read system recovery history information - It is necessary to read 12 KB x 1200 x 2 - 28.8 MB of information, which takes 8.5 seconds.

・System recovery time: 20.3 seconds in total ・Processing at checkpoint Oβ head transaction 2
20 blocks per 321 items - Number of pattern input/output processing times: 0.42 times - When memory resident information area is 100MB - CD information input/output time: 29.5 seconds - Minimum checkpoint interval: 3000 items 6 - Time to read system recovery history information: 21.2 seconds ・Total system recovery time: 50.7 seconds ・Checkpoint processing Oβ head transaction 2
20 blocks per 321 items - 0.42 times in pattern input/output processing (ii) Method of the present invention - When the memory resident information area is 40MB - Number of updated blocks The number of blocks that need to be updated at checkpoint is '1st
As shown in the table (CP is an abbreviation for checkpoint).

Table 1: System recovery time and processing overhead are shown in Table 2.

Estimate in the same way as above (recovery time is in seconds, processing overhead is in units of 2 seconds per transaction).
0 block - number of pattern input/output processing processes).

Table 2 - When the memory resident information area is 100 MB - Number of updated blocks The number of blocks that need to be updated at checkpoint is as shown in Table 3.

Table 3 - System recovery time and processing overhead are as shown in Table 4.

As shown in Table 4, the method of the present invention can reduce the system recovery time in the event of a failure by almost half compared to the conventional method.
This effect becomes larger as the amount of memory-resident information increases. Furthermore, processing overhead is reduced by about 15 to 30%.

[Brief explanation of the drawing]

Fig. 1 is an explanatory diagram of the outline of one embodiment of the present invention, Fig. 2 is an overall configuration diagram of the information processing system in this embodiment, Fig. 3 is a diagram showing the contents of the memory, and Fig. 4 is a diagram showing the contents of the CD file. A diagram showing the contents, Figure 5 is a schematic flow diagram of system recovery processing,
FIG. 6 is an explanatory diagram of classification of transaction processing states. 10...CPU/memory, 12...Memory resident information, 14 and 15...Memory resident information update partial management information, 20...Database, 30...Checkpoint dump file, 33 and 37...・Memory resident information update partial management information storage area, 34 and 38...
Memory resident information backup copy storage area. 40... System recovery history information file, 50...
・Historical information file for recording.

Claims (1)

[Claims] 1. In an information processing system that performs transaction processing using information resident on the main storage device or virtual storage device, multiple areas for storing the above-mentioned resident information are provided on one or more non-volatile storage devices, and the transaction processing A history information storage means for acquiring processing history information in a history information file, an updated part storage means for storing an updated part of the above-mentioned resident information, and an update part storage means for storing the above-mentioned information used for recovery processing in the event of a system failure at checkpoints set during system operation. It is equipped with a checkpoint processing means for acquiring a checkpoint in a non-volatile storage device, and a system recovery means for restoring the system to the correct state when the system is stopped, and the update partial storage means stores the previous update to each resident information storage area for each of the above-mentioned resident information storage areas. When the resident information is updated, the fact of the partial update is set in the updated part management information that stores the updated part after the time of partial writing, and the checkpoint processing means reads the data from the plurality of resident information storage areas at the time of the checkpoint. Selecting an area to be used and writing an updated part of the resident information to the area based on the updated part management information corresponding to the area, and the above system recovery means is a final effective check during recovery processing when the system is stopped due to a failure. A failure recovery method for a system characterized by reading resident information from a resident information storage area updated at the time of a point, and recovering the resident information using resident information update history information in a history information file.