JPS6389944A - Managing system for file updating history - Google Patents

Abstract

PURPOSE:To recover a state to the one just before a fault occurs by recording and preserving a request of its own to register to another file in a sequence of data processing unit at the time of registering and updating to a data life. CONSTITUTION:When the request for the registration and updating of the data is sent from a work station through a common bus 10, a request acceptance part 11 accepts the request. And a data write part 12 is started up, and the registration and the updating of the data are performed in the data file 14. Simultaneously, the record of the request of its own is preserved in a history file 15 that is another file in a sequence of data processing unit. In a case that the recovery of the data is performed when the fault occurs, a history processing part 13 performs a processing by using the history file 15, and performs the recovery of the data file 14.

Description

DETAILED DESCRIPTION OF THE INVENTION Technical Field The present invention relates to a file update history management system, and more particularly to a file update history management system that allows complete data recovery in the event of a failure.

Conventional technology.

In conventional file management systems, the contents of the main storage device are stored in a backup memory to prevent the system from going down in the event of a failure. for example.

In the method described in Japanese Patent Application Laid-Open No. 59-201297, a magnetic tape device or a cartridge magnetic tape device is added to the backup memory, and data is transmitted between the additional device and the backup memory, between the main storage device and the backup memory,
By arbitrarily verifying information between the main storage device and additional devices, system downtime is prevented and failure detection is performed. In addition, in the method described in Japanese Patent Application Laid-open No. 59-58566, log data is first written to a history logging file buffer, and after this is completed, this log data is written to a temporary logging file, so that the history logging file buffer becomes full. When this happens, this content is written to the above logging file. This makes it possible to eliminate bottlenecks caused by the acquisition of huge amounts of log data restricting the processing capacity of the system.

In this way, in the conventional system, data is regularly or irregularly backed up using magnetic tape or the like to prepare for the occurrence of a failure. That is, conventionally.

Because the backup process was performed at an arbitrary time or during the main program's free time, in the event of a failure or damage, only the state of the last backup can be restored, and the state immediately before the failure occurs. I couldn't go back.

Purpose The purpose of the present invention is to solve these conventional problems and provide a file update history management method that, in combination with normal backup, can accurately reproduce data and restore it to the state immediately before a failure occurred. Our goal is to provide the following.

Configuration In order to achieve the above purpose, the file modification according to the present invention is performed.
In the history management method, in addition to the main program that updates data files, a history management process is provided that records and restores the request contents. When a data file update request is input, the main program executes the request. After moving the contents to the common memory area and starting the above history management process, the data file is updated, and the above history management process writes to the history file when one processing unit is successfully completed, and updates the data. At the time of recovery, data files are sequentially recovered based on the records of the history file.

Hereinafter, the configuration of the present invention will be explained in detail using examples.

FIG. 1 is a configuration diagram of a file management system showing an embodiment of the present invention. In FIG. 1, 10 is a common bus connected to the CPU, input/output devices, etc., 11 is a request reception unit that receives data registration and update requests from the workstation computer, and 12 is data that writes data to a data file. A writing unit 13 is a history processing unit that manages the history of stored data, and 14 is a data file using a magnetic storage device A.

15 is a history file using magnetic storage device B;

When a data registration/update request is sent from the workstation computer via the common bus 10, the request receiving unit 11 accepts the request, starts the data writing unit 12, and writes the data to the data file 14. Register and update. At the same time, the request itself is recorded in a series of data processing units in the history file 15, which is a separate file. When restoring data when a failure occurs, the history processing unit 13 performs processing using this history file 15 and restores the data file 1.
Perform the repair in step 4.

The main differences between the present invention' and the prior art are the following two points.

(a) The logging process of the present invention is normally activated when a data addition or update event occurs in the sleep state, and this process is repeated. This is to save memory space and CPU time.

Furthermore, if the main process requests processing to the logging process, it can immediately move on to its next process, and operates asynchronously with the logging process.

This makes it possible to save processing time.

(b) The data targeted for logging is the exact image of the command from the workstation computer, which eliminates the need to record history for each file and improves processing speed.

FIG. 2 shows L A N (I, oc
alArea Network). 2
0 is a common bus, 21 is a work station, 22.23
are the magnetic storage device and optical disk device in the file storage system. The magnetic storage device 22 is provided with an index file 22-1 and a history file 222, and is connected to the image data file of the optical disk device 23. 30 is a data update request command from the workstation 21, which is composed of a command, an index, and image data. The index is entered into an index file 221 , the command and index are entered into a history file 222 , and the image data is entered into an image data file 23 .

FIG. 3 is an explanatory diagram of the processing outline in FIG. 2. In the LAN system shown in Fig. 2, as shown in Fig. 3,
When a request for data update (registration, modification, deletion) arrives from the workstation 21, the command part and
The index section to be updated is stored in the history file 222.
write to.

FIG. 3 shows the flow of data for (a) a data update request and (b) a data recovery. The explanation will be given below in order.

(b) Creation of B history file At the same time as system startup, history file 1 incorporates the current day's system date and time and the TD of the data file into its name.
Create 5.

(b) Preparation of history management process A history management process 2 is prepared as a program for recording and restoring requested contents, and enters a start-waiting state when the system starts up.

(c) When a request to update the history writing data file comes, the main program 1 copies the request contents to the common memory area 3 (operation ■), starts the history management process 2 (operation ■),
From white, the process moves to updating the data file 14.

Upon activation, the history management process 2 stores the common memory area 3.
The main program 1 is transferred to the write area 4 (operation (2)), the result is notified to the main program 1 (operation (2)), and the program enters the startup waiting state again. In addition, the actual writing to history file 15,
Loading is performed when one processing unit (one processing may be completed with multiple requests) has been successfully completed (operation ■),
History file 15 is for each date, corresponding data file 14
prepared for each.

(d) Data Recovery In the event of a failure, etc., in order to recover the data, the backed up data file is expanded onto the magnetic disk as shown in FIG. 3(b). And from the operator,
Upon receiving instructions such as data file Tr), period, etc., the data files are sequentially restored based on the records left in the corresponding history file [5].

(e) Relation to backup When data is packed up onto a magnetic tape or the like at a certain point, the history file 15 up to that point may be deleted.

Effects As explained above, according to the present invention, when registering and updating data in a file, the request itself is recorded in a separate file as a series of data processing units, so that when a failure occurs, By using the records for data recovery, almost complete data recovery can be achieved.

[Brief explanation of the drawing]

Fig. 1 is a block diagram of a file management system showing an embodiment of the present invention, Fig. 2 is a block diagram of a LAN system to which the present invention is applied, and Fig. 3 is an explanatory diagram of the flow of processing in Fig. 2. be.

Claims (1)

[Claims] (1) In a file management system equipped with a data file and a history file that records the history of the data file,
In addition to the main program that performs data file update processing, a history management process is provided to record and restore request contents. When a data file update request is input, the main program stores the request contents in a common memory area. After moving the file and starting the above history management process, the data file is updated, and the above history management process writes to the history file when one processing unit is successfully completed, and when data is restored, the history file is updated. A file update history management method characterized by sequentially restoring data files based on records.