JPH08314784A - File management device - Google Patents

Abstract

(57) [Summary] [Purpose] To prevent the occurrence of inconsistency between the file and the file update log corresponding to this file, and improve the reliability of the file contents. [Structure] A file that acquires information on online processing as a file update log for each fixed processing unit, updates the file online with the log, and restores the file using the file update log when a failure occurs. In the management device, when a file is brought online, a file ID management means 3 for issuing a file ID that can be distinguished from other files brought online and the file that was previously made online, and a file ID is given to the file. Then, it is provided with a file online means 2 for bringing this file online, and a file update log acquisition means 5 for giving the file ID of the file brought online to this file update log when information is acquired as a file update log. File management device.

Description

Detailed Description of the Invention

[0001]

BACKGROUND OF THE INVENTION 1. Field of the Invention The present invention relates to a file management device in a transaction system that handles online files, and more particularly to a file management device that prevents occurrence of file inconsistency due to a failure occurrence, file modification, and the like.

[0002]

2. Description of the Related Art In systems such as a bank deposit withdrawal system, a ticket issuing system, a factory line control system, and a warehouse inventory management device, data to be managed is processed online.

In a system in which online processing is performed in this manner and executed processing is sequentially saved, each processing proceeds in units called transactions or processing units and is saved in a file.

A file that can be accessed by this transaction is called an online file, and a file in the opposite state is called an offline file.

The information in each system described above, for example, the file information for managing the deposit information of the depositor in the bank deposit withdrawal system, is very important in many cases.
In order to ensure that such important and information that is constantly changing during online processing is stored, the system stores each of the above files stored in the database as well as a kind of update in the storage part called journal file. A file update log that is a file for use is provided. The online file described above is also a file that can be recovered by the file update log.

[0006] For example, when a depositor uses ATM to withdraw a deposit or the like, a transaction is executed, and the information is first stored in the file update log. Then, the online file, which is a formal information storage unit, is updated using the contents of the file update log, and a series of processing is completed.

If the file contents are lost due to a failure of the database, for example,
Restore the file using the information in the file update log.

[0008] Here, the transaction has processing unity, and no matter what happens to the system, the transaction can be in either one of the state where the processing is completed and the state where it is not processed. It is possible to save the file update log in units of and restore the file.

An overall system for surely executing online processing including transaction of such a business process and file management and for recovering a file is called a transaction system.

FIG. 2 is a block diagram showing the configuration of a file management device in a conventional transaction system. In FIG. 2, the file management device 30 includes a database 31, a journal file 32, and a file writing unit 3.
3, a file update log acquisition unit 34, a file search restoration unit (not shown), and other peripheral elements.

The database 31 stores files such as online files and offline files, and the journal file 32 stores a file update log.

Now, let us consider a case where the files A and B in the database 31 are brought online and the business process related to these files is carried out in the business process 35.

First, in the business process 35, the file A
Alternatively, the processing regarding the file B is executed. The temporary information at the time of execution is temporarily stored as a log called a task local journal 36, and the process proceeds.
Also, information regarding the online file A or online file B is used as necessary.

Although the task local journal 36 is shown in the business process 35 in FIG. 2, a storage means is actually provided as an input / output destination from the business process 35, in which the task local journal is provided. 36
Is configured.

When a series of processes in the business process 35 is completed, a commit is executed and the contents of the task local journal 36 are saved as a file update log.

At this time, the file update log acquisition unit 34
Saves the information in the task local journal 36 in the journal file 32 as a file update log based on the log acquisition command from the business process 35.

When the file update log acquisition unit 34 saves the file update log in the journal file 32, the file update log acquisition unit 34 sends a log saving notification s1 to the file writing unit 33. Upon receiving the log storage notification s1, the file writing unit 33 uses the corresponding file update log as the basis for the database 3
Save to the corresponding online file in 1.

When the file writing unit 33 saves in the online file, the file writing unit 33 sends a signal called a clean point cl to the file update log acquisition unit 34 as a notification of the end of saving in the file.

Upon receiving the clean point cl, the file update log acquisition unit 34 determines that the corresponding file has been updated based on the contents of the file update log, and stores the file update confirmation information in the log management file 37. Here, information having contents such as “file A2, updated by log A2” is recorded.

For example, in the case shown in FIG. 2, the database 31
In, the file A and the file B are online, and the file update logs in the journal file 32 are log A1, log B1, log B2, log A2, log B3,
Logs A3 ,. ． ． And sequentially acquired.

Then, each of these file update logs is
Online file A1, Online file B1, B
2, A2, B3, A3 ,. ． ． Are being updated sequentially. That is, the file names of these files and the file update log determine the correspondence between the file and the file update log at the time of file restoration in the above file update or failure processing.

These file names are defined as online files at the time of system definition of the transaction system or file creation, that is, files that can be recovered by the file update log.

The correspondence between the file name and the file update confirmation information of the log management file 37 makes it possible to confirm the correspondence between the files and logs.
In such a transaction system, when a system failure occurs, file recovery by recovery such as system stop recovery or recovery from a medium is performed.

That is, at this time, the file search recovery unit (not shown) searches the journal file 32 for a file update log having the same file name as the file to be recovered, and based on the log management file 37, the file update log is already created. The file is restored using the updated log. For example, in FIG. 2, when A2 and A3 of the file A are to be restored, the restoration process is performed using the logs A2 and A3 of the file update log.

[0025]

In addition to the access from the business process 35 managed by the transaction system, the above-mentioned file management device 30 can access the database 31 from the general process 38 outside the management of the transaction system. It is accessible. At this time, the general process can access the file regardless of whether it is an online file or an offline file.

File access from this general process causes the following problems. First, if any online file is updated while the file is online,
The corresponding file update log in the journal file 32 is not acquired, and the file cannot be recovered when a failure occurs. There is also a possibility of file destruction due to operator error.

On the other hand, when a file is taken offline for system maintenance or other reasons, the file can be updated in the same manner. In this case as well, the file control information (the number of valid records, free record area information, etc.) and record Since the state (physical position of record) and so on are inconsistent with the previous file update log, file recovery by the file update log cannot be performed.

When the file is taken offline, the transaction system does not recognize the file access. For example, it is possible to delete the file and recreate the file with the same file name.

However, since there is no change in the file update log at this time, the file information on the database 31 side and the file update log information on the journal file 32 are different.

Therefore, if a file is brought online as it is and recovery is performed, for example, the transaction system that manages the file by the file name cannot distinguish between the old file and the new file, and the file recreated by the old file update log will be deleted. Destroyed. Therefore, it is necessary to invalidate the old file update log of the corresponding file in the journal file, which is a laborious and time consuming task.

In particular, when an OS which can identify a file only by a file name is used and the file is mistakenly brought online again in the above case, the file in the database and the file update log in the journal file are separated. Correspondence cannot be taken.

Further, in the case of a system using such an OS, the above system cannot avoid the inconvenience caused by the operator's mishandling of the file name. Further, regarding file recovery, it is difficult to completely automate reliable recovery processing because of the possibility of recreating a file with the same name.

On the other hand, even if the file is not identified only by the file name but the system using the OS capable of transferring the file to the corresponding portion is used, the file name and the file content are changed in the file which is once offline. If this happens, the following problems will occur.

First, in the file management device shown in FIG.
Although one database 31 is provided, in a large-scale system, a plurality of databases are provided,
Through acquisition of file update log between databases,
Files are being copied between databases.

Further, in the file copying between the databases, the file name is often changed by changing the file name without changing the substance of the file by a certain relational expression.

In such a case, if the file name of a file of a certain database that has been offline once is changed and then brought back online, the file name of the file update log for that database and the file name of the file whose file name has been changed become the same. The file copy between the databases is started without any conflict.

Furthermore, when a system failure occurs in this state and file restoration is performed, the file update log of the first journal file remains unchanged and the file update log of the journal file involved in file copying is changed. Therefore, inconsistency will occur in the file (file name) between the restored databases.

The present invention has been made in consideration of such a situation, prevents inconsistency between a file and a file update log corresponding to the file, and improves reliability of file contents. An object is to provide a file management device that can be improved.

[0039]

In order to solve the above-mentioned problems, the invention according to claim 1 acquires information processed online by an information processing unit as a file update log for every fixed processing unit, Use this file update log to update online files, and
In a file management device that recovers a file by a file update log when a failure occurs, when a file is brought online, a file that issues a file ID that can be distinguished from other files that have been brought online and the file that was previously made online ID management means, when a file online request is made, a file ID is given to the file and the file is brought online, and when online processed information is acquired as a file update log, this file update The file management apparatus is provided with a file update log acquisition unit that gives the log the file ID of the file that has been brought online.

The invention according to claim 2 is the file access according to the invention according to claim 1, wherein processing means other than an information processing unit for performing online processing is prohibited from accessing the file brought online. The file management apparatus is characterized by comprising management means.

Further, the invention according to claim 3 is the same as the invention according to claim 1 or 2, wherein the file ID assigned to the file brought online at the time of occurrence of a failure is used, and the file having the same file ID as this file ID is used. The file management apparatus includes a file update log search unit that searches the update log as a file update log for use in file recovery.

[0042]

Therefore, first, in the file management apparatus of the invention according to claim 1, the information processed online by an information processing unit such as a so-called transaction is acquired as a file update log for each fixed processing unit. The fixed processing unit may be, for example, one transaction or a plurality of transactions.

Then, the online file is updated using this file update log, and when a failure occurs, the file is restored by the file update log.

Further, when a file is brought online, the file ID management means issues a file ID that can be distinguished from other files that have been brought online and the file itself that was previously made online.

This file is brought online by the file online means, and the file online means makes the file I in response to the online request.
The file ID issued to the D management means is added to the file to bring the file online.

Then, the processing by the information processing unit proceeds, and the file update log acquisition means acquires the information processed online as the file update log. Further, at the time of acquiring this file update log, the file update log acquisition means gives the file ID of the corresponding file that has been brought online.

Therefore, even if an OS (operating system) for identifying and managing files by file name is used, it is possible to reliably identify only the file update log in the online state of a certain file at a certain time. It is possible to prevent inconsistency due to file modification, etc.

Next, in the file management device of the invention according to claim 2, in addition to the same operation as the invention according to claim 1, the information processing unit that is the target of online processing by the file access management means. It is prohibited to access files online by any other processing means.

Therefore, for example, since the processing means that enables file deletion, rewriting, etc. by an operator operation does not access an online file, a certain file and a file in the online state at a certain time point of the file. Consistency with the update log can be more reliably ensured.

Further, in the file management apparatus of the invention according to claim 3, the file update device, which operates in the same manner as the invention according to claim 1 or 2, is brought online by the file update log search means. The file ID assigned to the file update log is used, and a file update log having the same file ID as this is searched as a file update log to be used for file recovery.

Therefore, in the file restoration operation by the file update log in this file management device,
It is possible to perform reliable file management without the file being restored by the file update log in which the inconsistency has occurred.

[0052]

Embodiments of the present invention will be described below. FIG. 1 is a block diagram showing an embodiment of a file management device according to the present invention. The same parts as those of the conventional device shown in FIG.

The file management device 1 is a file management part of a transaction system for managing file access from a business process executing a transaction.

The transaction system is a system for storing and managing business processes and the like consisting of transactions satisfying the processing unity condition and information generated from these transactions. The journal files are combined, and when a failure occurs, processing such as file restoration is performed.

The general process 38 is not included in a part of the transaction system. In FIG. 1, the file management device 1 includes a file online unit 2
A file ID management unit 3, a database 4 for storing online files and offline files, a file update log acquisition unit 5, a journal file 6, a file writing unit 7, a file access management unit 8, and a file update It is composed of a log search unit 9, a file restoration unit 10, and other peripheral elements (not shown).

Upon receiving the file online request, the file online unit 2 requests the file ID of the file to be brought online to the file ID management unit 3, and records the returned file ID in the file as file control information. At the same time, the file is incorporated into the transaction system and brought online.

However, when the system is restarted at the time of file recovery, the file ID is left unchanged and the file is brought online. The file ID management unit 3 uses the file I
D is managed, and when a request from the file online unit 2 is received, an ID number that is unique within the transaction system is issued.

The database 4 is provided with a file as formal storage information of information processed in the business process. This file is made into an online file by the file online unit 2 and incorporated in the transaction system. In addition, each file is provided with a file ID storage unit 11, which stores the file ID when online.

The file update log acquisition unit 5 is constructed and operates in the same manner as the file update log acquisition unit 34 in the conventional apparatus, and in addition, the information read from the task local journal 13 of the business process 12 is stored in the journal file 6. The file ID is stored in the file ID storage unit 14 in the file update log.

Here, the business process 12 and the task local journal 13 are configured in the same manner as the business process 35 and the task local journal 36 in the conventional apparatus, and also extract the file ID from the file to be processed incorporated in the transaction system. , Part of the information saved in the file update log.

The journal file 6 is provided with a file update log and a log management file 37. Here, it is the same as the log management file 37. The file update log is configured in the same manner as the file update log in the conventional device, and also has a file ID storage unit 14. The file ID storage unit 14 stores the same file ID as the file ID in the file ID storage unit 11 of the corresponding online file.

The file writing section 7 is constructed and operates similarly to the file writing section 33 in the conventional apparatus. However,
Only the access permitted by the file access management unit 8 is executed by the general process 38.

The file access management unit 8 prohibits access from outside the transaction system while online. Here, the business process is accessible because it is incorporated in the transaction system during business processing. On the other hand, access from the general process 38 that performs processing such as changing the contents of the database 4 is prohibited.

The file update log search unit 9 uses the file I stored in the file ID storage unit 11 in the file.
Based on D, the file update log with the matching file ID is searched from the journal file 6, and the result is notified to the file restoration unit 10.

The file recovery unit 10 applies the file update log searched by the file update log search unit 9 to the file to be recovered to recover the file. Next, the operation of the file management device of this embodiment configured as described above will be described.

First, the operation of storing the processing information by the business process 12 in the database 4 in the online processing will be described. First, a file to be processed is created. In FIG. 2, a file A and a file B are provided. Also, the file immediately after creation is offline.

Next, when a file online request is made, the file online unit 2 requests the file ID management unit 3 for the file ID of the file to be brought online.

Here, it is assumed that the file B has been previously brought online, and at that time, ID1 is given as the file ID and the information of B1 and B2 is stored, and this time, the files A and B are brought online. Shall be done.

At this time, the file ID management section 3 issues ID2 as the file ID of the file A and ID3 as the file ID of the file B. Note that ID1, ID2, and ID as file IDs
3 is merely an example, and a file ID that is unique within the transaction system is actually issued.

Upon receiving the file ID, the file online unit 2 makes the file ID storage unit 11 for the file A.
ID2 as file control information is stored in and the file A is incorporated into the transaction system, that is, brought online.

On the other hand, similarly, for file B, ID3 is added as file control information, and file B is brought online. Next, in the business process 12, processing regarding the file A or the file B is executed.
At this time, the file ID of the processing target file is stored in the task local journal 13 together with the information at the time of execution.

Although the task local journal 13 and the business process 12 are shown in FIG. 1, the task local journal 13 may actually be provided in a separate storage means.

When a series of processes in the business process 12 is completed, the contents of the task local journal 13 are saved via the file update log acquisition unit 5. here,
The file update log acquisition unit 5 saves log information for file update in the file update log, and
The file ID of the corresponding file is stored in the file ID storage unit 14.

In FIG. 1, the file update logs B1 and B2 saved by the previous online operation of the file B and the file update logs A1, B3, A2, A3 saved by the online operation of the files A and B this time. B4 and are stored.

Here, ID1 is given to the file update logs B1 and B2 as a file ID. Also, ID2 is assigned to the file update logs A1, A2, A3,
ID3 is stored as the file ID in the file update logs B3 and B4, respectively.

When the file update log acquisition unit 5 stores the file update log in the journal file 6, the file update log acquisition unit 5 sends the log storage notification s1 to the file writing unit 7. Upon receiving the log saving notification s1, the file writing unit 7 reads the corresponding file update log from the journal file 6 and saves it in the corresponding online file in the database 4.

When the file writing unit 7 saves the file in the online file, the clean point cl is output as a file save completion notification signal, and the file update confirmation information is stored in the log management file 37. It

The point up to the point where the file update confirmation information is stored is a so-called check point, and the file update up to this point is guaranteed. Database 4 of processing information by business process 12 during online processing
The saving to is performed as described above. On the other hand, when there is a request from the general process 38 to open an online file in the database 4 and rewrite the contents, the file access management unit 8 prohibits access.

Therefore, when the file is online, the file cannot be deleted, created or modified from outside the transaction system. Next, the operation of restoring a file due to the occurrence of a system failure will be described.

At this time, the file is a checkpoint immediately before the system goes down, that is, a clean point c.
It has been updated up to the point at which 1 was issued, and the file update log in the journal file 6 stores update information and the log management file 37 stores checkpoints.

At the time of file restoration, the file is made online while keeping the file ID as it is when the system is started. Therefore, the file update log search unit 9 searches the file update log having the same file ID and the same file ID from the journal file 6 based on the above file ID of the file to be recovered, and the result is the file recovery unit 1
Notify 0.

Then, the file restoration unit 10 restores the files in the database 4 based on the retrieved file update log. At this time, only the file update log acquired when the file was online at the time of the failure occurred is searched, so the file update log before that, that is, after the file offline state before the failure occurred Is never used,
The file update log and the file before the failure will be completely consistent.

This will be described by taking the case of FIG. 1 as an example.
For example, of the files B1 and B2 of the file B, it is assumed that the data of B2 is modified by the general process 38 after the file is offline. The file update log corresponding to B2 of the file B is the log B2. Further, ID1 is stored as the file ID in the log B2, and the file ID of the file B at the time of acquisition of the log B2 is ID1.

Next, when the file B is brought online, the file ID of the file update log B2 remains ID1, but the file ID of the file B becomes ID3, so a system failure occurs at this point. When the recovery, that is, the file restoration is performed, as described above, only the file update logs B3 and B4 are restored, and the file B2 portion corrected at the time of offline remains unchanged.

The file is usually downloaded to another storage medium such as a magnetic tape at regular intervals, especially when it is taken offline. Therefore, the file update log B3.
Information of the file before B4 is not lost.

Next, the operation when the file is processed offline will be described. When the file is offline, the general process 38 can create, delete, and modify the file.

If a part of the file is modified here,
After that, when the file is brought online, a new file ID will be issued to the file, so even if a system failure occurs and there is file recovery, the old file update log will overwrite the modified part as described above. There is no such thing.

On the other hand, even if a file is deleted and a file with the same file name is recreated, a new file ID is issued when the file is brought online. The files recreated by the update log will not be updated.

Therefore, when information changes such as correction and re-creation of a file are made while the file is offline,
A new file ID is always issued at the time of the next online operation, and is distinguished from the previous one, so that it is possible to perform file recovery without causing file inconsistency, for example, when performing file recovery. .

That is, except when the file is restored when a failure occurs, it is possible to easily and surely invalidate the file update log before the file online by adding a new file ID by the file online unit 2. Has been realized.

As described above, in the file management apparatus according to the present embodiment, the file online management unit 2 adds the unique file ID issued from the file ID management unit 3 to the file and then makes the file online. Since this file ID is added to the file update log when the update log is acquired, only the file update log in the online state at that time can be reliably identified, and the file and the file update log are inconsistent. Can be prevented.

That is, it is possible to prevent the file information and the database from being destroyed due to the discrepancy between the file and the file update log, and to improve the reliability of the information. In this way, since the file and the file update log are associated with each other by the file ID, even if the system uses an OS that identifies the file only by the file name, for example, when a file with the same name is created after file deletion, It is possible to prevent confusion in the correspondence relationship between the old file, the new file, and the file update log.

Further, as described above, in the file management apparatus according to the present embodiment, the file update log search unit 9 updates the file having the same file ID as the file ID given to the file brought online at the time of the occurrence of the failure. Since the file is recovered by searching the log and using the file update log searched by the file recovery unit 10, the file is not recovered by the file update log having the inconsistency, and is simple and reliable. You can manage various files.

Therefore, for example, when a failure occurs after an offline access to an online file and the file update log is applied to restore the file, inconsistency of the file control data caused by the missing file update log of the online operation or It is possible to prevent the file data from being destroyed because the data updated offline is not in the file update log.

Further, since the file is managed by the unique ID in the system, the operator does not need to be aware of the distinction of the file, and the file destruction due to the operator's erroneous operation can be prevented.

Further, as described above, the file management apparatus according to the present embodiment is provided with the file access management unit 8 to prohibit the access of the general process 38 which is online. If you go offline, a new file ID will be assigned and the file ID will change when you go online, so the file update log up to that point will be invalidated because the file ID is different, and the file names will match. It is possible to prevent the file update log from being confused by.

Incidentally, when the file is brought online, the file ID may be used to discard the inconsistent file update log. By doing this, you can leave only the necessary file update log when recovering the file, and discard all unnecessary file update logs when normal files are brought online. It is possible to achieve good consistency. Further, the present invention is not limited to the above-mentioned embodiments,
Various modifications can be made without departing from the spirit of the invention.

[0098]

As described above in detail, according to the present invention, a file ID is issued every time a file is brought online, and the file ID is given to the file update log. It is possible to provide a file management device that prevents inconsistency with the corresponding file update log and improves the reliability of file contents.

[Brief description of drawings]

FIG. 1 is a configuration diagram showing an embodiment of a file management device according to the present invention.

FIG. 2 is a configuration diagram showing a conventional file management device.

[Explanation of symbols]

1 ... File management device, 2 ... File online unit,
3 ... File ID management unit, 4 ... Database, 5 ... File update log acquisition unit, 6 ... Journal file, 7 ... File writing unit, 8 ... File access management unit, 9 ... File update log search unit, 10 ... File recovery Department.

Claims (3)

[Claims] 1. Information obtained by online processing by an information processing unit is acquired as a file update log for each fixed processing unit, an online file is updated using this file update log, and a failure occurs. Sometimes, in a file management device that recovers the file by the file update log, when the file is brought online, a file ID that is distinguishable from other files that have been brought online and the file that was previously made online is issued. File ID management means for performing an online request of the file, a file online means for adding the file ID to the file and bringing the file online, and the online processed information as a file update log When retrieving this file update log And a file update log acquisition means for assigning a file ID of a corresponding file that is brought online to the file management apparatus. 2. The file management device according to claim 1, further comprising a file access management unit that prohibits a processing unit other than the information processing unit that performs the online processing from accessing the online file. A file management device characterized by the above. 3. The file management device according to claim 1, wherein a file ID assigned to the file brought online when the failure occurs is used, and the same file ID as that is used.
And a file update log search means for searching the file update log having the above as a file update log for use in recovering the file.