JPH0827752B2 - Resource status holding device - Google Patents

Description

DETAILED DESCRIPTION OF THE INVENTION [Industrial application] The present invention relates to a recovery method in a computer application system when data update processing on a file is interrupted due to an abnormal situation. In the data processing of the database system that realizes the transaction function, this is a problem that is completely solved automatically by the recovery function of the database management system (hereinafter referred to as DBMS). -It extends to data processing in the system. However, a database that has a transaction processing function and can be subdivided into a series of stages where the update process is clear
Only when it is possible to attribute each step to a process that can be executed sequentially on the same process as the system. Since the existence of a DBMS is a prerequisite, updating the OS definition for building a database system is a typical use case.

[Conventional technology and problems]

"Transaction processing" is one of the most important technologies in DBMS. This technique was fully established practically and logically in the early 1980s. By using this, complicated data can be shared between independent programs, and appropriate post-processing when an error occurs is possible.
Managing the database has never been easier.

By the way, the transaction function is a function called the ACID attribute that guarantees the following properties.

(1) Atomicity Even if it is impossible to continue in the middle of transaction processing, the related data is completely returned to the state before the start (declaration of transaction start) or the update complete state (transaction end) Do not allow transitional states other than the declaration) to occur.

(2) Consistency and isolation When competing processes try to update one set of data at the same time, it is disturbed when there is consistency within one set of data, that is, conditions that must be satisfied at the same time. There is no guarantee that the updates between processes do not interfere with each other. This property is not directly utilized in the present invention.

(3) Durability It is guaranteed that the last update result, which has been executed once, can be completely restored automatically even if the storage medium is destroyed.

However, DB can enjoy the transaction function.
Limited to the data in the database defined according to the format strictly defined in MS. Generally, the ACID attribute cannot be added to the data in any place by the transaction function.

By constructing the data as a database, it became possible to target most of the data quantitatively as a transaction function, but qualitatively most of the data other than the type called a database is outside the scope of the transaction function. That is to say.

All data are at the same risk of interruption of update processing and loss of processing results due to storage media failure, but such data recovery measures are handled by writing individually devised programs according to individual data structures. There is a need.
The easiest measure was to entrust the operator with all ad-hoc measures (usually starting over from the initial setting).

In other words, it relied on unreliable human work. Also,
In order to automate, it was necessary to create a detailed abnormality analysis program for each individual data, and this work was inefficient and error prone.

Data stored in a file by a file system that does not have a means for realizing a transaction function is called non-transaction data, and a file storing non-transaction data is called a non-transaction file.

If the processing is interrupted during the update of the non-transaction file, it is possible to deal with it by an ad hoc method according to the data characteristics of the update target. As a general method, (1) the update target data that may have been lost is reconstructed, the progress stage of the update process is estimated from there, and ad hoc measures are taken.

(2) The update status for storing the update step is separately held, the progress step is checked by referring to the update status, and ad hoc measures are taken.

It seems that (2) is simple at first glance, but since the status data itself is also destroyed, a powerful recovery means must be provided here, resulting in a recursive problem structure. Please note that there is.

[Object of the Invention]

The present invention is based on the above consideration, and an object of the present invention is to provide a resource status holding device in which the transaction processing function of a DBMS is applied so that the update status of out-of-transaction data can always be accurately grasped. To do.

[Means for solving problems]

Therefore, the resource status holding device of the present invention includes a non-transaction file for storing non-transaction data, a database for holding data for recording the progress of update of non-transaction data, a copy file for holding a copy of the database, A database system having a before image file holding a before image of the database, an after image file holding an after image of the database, and a database management system having means for realizing a transaction function, and non-transaction data N update processes (where N is 2
And a process handler that executes by dividing into partial data processing of the above integer), and the process handler starts the transaction in the i-th (i is 1, 2, ..., N) partial data processing. Database notification system, update of non-transaction data, update status data in the database should be changed to a value indicating that the non-transaction data was updated by the i-th partial data process. It is characterized by performing a process of requesting the management system and a process of notifying the database management system of the end of the transaction at the end of the partial data processing.

Example of Invention

Embodiments of the present invention will be described below with reference to the drawings. FIG. 1 is a diagram showing an outline of the present invention. This figure is
The transition of data X and the update status of data Y are drawn in comparison with the serial execution of transactions TRN1, TRN2, and TRN3. Data X represents the update status of data Y,
Data Y is non-transaction data. Note that there are various definitions of transactions, but in a broad sense, it is one meaningful range of data processing.

In FIG. 1, t ₁ , t ₃ and t ₅ respectively indicate the transaction start time, and t ₂ , t ₄ and t ₆ respectively indicate the transaction end time. P ₁ , P ₂ and P ₃ are functions indicating the update processing performed from the start to the end of each transaction for the non-transaction data Y (Pn (Y) is the result Pn ( Y)). For convenience, the transition is illustrated in the row Y. If the update is executed normally, Y is set to P ₁ (Y) during TRN1, P ₁ (Y) is set to P ₂ (P ₁ (Y)) during TRN _2, and P ₁ (Y) is set during TRN 3. ₂ (P ₁ (Y)) will be changed to P ₃ (P ₂ (P ₁ (Y)).

The update status data of the non-transaction data is held as the data X on the database. The data X on the DBMS having the transaction function can naturally enjoy the transaction function.

When the update of Y is described as a function Π, Π = P ₁ * P ₂ * P ₃ ≡
The division into P ₃ (P ₂ (P ₁ (Y))) and the setting selection of the value of X are planned in advance according to the characteristics of the target non-transaction file (in the present invention, This division method is not included), but the embodiment only shows a certain division method.

By knowing exactly at what stage the update of Y, which is the non-transaction data, is abnormally terminated, the recovery processing can be constructed through the post-processing of Y (the construction method is not included in the present invention). It also means choosing Π like that.

When the data Y is requested to be updated by the process handler, the division of Π = P ₁ * P ₂ * P ₃ and the resource status holding data X, which are pre-installed here, are found and the serial transactions TRN1, TRN2, TRN3 , And add "1" to each X from the start to the end of each transaction (in the example shown, the initial value is 1).
So, it will be updated as 2,3,4). Further, during each period (t _1-2 , t _3-4 , t _5-6 ), partial updating of the data Y is executed in the same process according to P ₁ , P ₂ , and P ₃ .

If the processing is interrupted during such a stepwise update process, the transaction function of the DBMS immediately executes the process of guaranteeing the atomicity and persistence of the data X, regardless of whether the interruption time is inside or outside the transaction. , The data X is guaranteed to take the value of the state at the start of each transaction or the state immediately after the end of the transaction, depending on the suspension time. That is, before the successful notification of the end of the transaction, the value before the start of the transaction, and after the successful notification of the end of the transaction, the value after the update by the transaction. .

According to the present invention, it is possible to easily determine where the processing is interrupted by the value of the data X, even though the data Y is not the target of the transaction function.

FIG. 2 is a diagram showing the system configuration of an embodiment of the present invention. In FIG. 2, 1 is a copy file, 2 is a database, 3 is a before image file, 4 is an after image file, 5 is an access handler, 6 is a transaction handler, 7 is a process handler, and 8 Indicates a file of non-transaction data, 9 indicates a terminal, and 10 indicates a DBMS.

File 8 is a non-transaction file Y (first
FIG. 1) is stored, and the database 2 stores data X (FIG. 1) used for holding the resource status. DB
The MS 10 includes an access handler 5 and a transaction handler 6. DBMS10, copy file
1, the database 2, the before image file 3 and the after image file 4, the DBMS realizes the transaction function, and constitutes the database system together with the database.

The copy file 1 holds a copy of the database 2 at a certain point in time. The update history of the database 2 after the acquisition of this copy is acquired in the after image file 4. Before updating the database 2 when the transaction is not completed, the before image
A system configuration in which data for restoring the database 2 to the state before the start of a transaction is stored in the file 3 and is discarded after the end of the transaction is often adopted.

So far, only the structure of the database system having a general transaction function has been described. From here, it becomes the core part peculiar to the present invention.

When the update request for Y is notified from the terminal 9 to the process handler 7, the process handler 7 activates a series of stepwise update schedules scheduled for this update of Y.

According to this procedure, from the first to Yth Nth
The transaction processing for updating the update status holding data X of the database 2 corresponding to the th update procedure is executed.

No matter what abnormal situation occurs during processing, the database system that realizes the transaction function is X
The last value of can be unambiguously determined or restored. For example, after writing X, if it was interrupted before the end of the transaction, it could be restored to its original value by the before image file 3, and if it was interrupted after the transaction was completed, it could be rewritten by the after image file 4. This is because a known database recovery method can be adopted.

This makes it possible to clearly determine the number of Y processing steps between the interruptions. As a result, there is no need to prepare an ad-hoc complicated diagnostic program and estimate the interruption status as in the conventional case. The recovery process can be completed only in the phase of executing a predetermined restart method (this construction method is outside the scope of the present invention).

The operation of the system shown in FIG. 2 will be described with reference to FIG. When the update request of Y is notified from the terminal 9 to the process handler 7, the process handler 7 executes a program for executing this update process. This program consists of partial programs that are executed in sequence. In the example shown, transactions TRN1, TRN2, TR
It consists of N3 partial programs.

The first part program, at the start of the partial process, and notifies the start of the transaction to the transaction handler 6, then subjected to P ₁ (update the value of the data Y to P ₁ (Y)), the initial value 1 After requesting the access handler 5 to increment X by 1, the transaction handler 6 is notified of the end of the transaction. This first
Transaction TRN1 of the above will last for the period from t ₁ to t ₂ . t ₂
After that (until the next transaction is completed), X becomes 2.

Next, although the second partial program is executed,
Similarly, Y P from P ₁ (Y) by P _{2 2} (P
₁ (Y)) and X is updated to 3. The same applies hereinafter.

A specific application example of the present invention will be described by taking area allocation in a database as an example. The data outside the transaction is the free space management table and the database space allocation table,
It is assumed that the entry of the volume VOL2 in the free space management table is filled with the free space of 0 to 99 (the numbers are track numbers). Under this condition, the processing of assigning the areas of track numbers 0 to 49 of volume VOL2 to the database is as follows. The initial value of X is 1.

Transaction start Update the volume VOL2 entry in the free space management table to 50-99.

Update X (X = 2) Transaction end Transaction start Write that areas 0-49 of volume VOL2 have been allocated to the empty entries in the database area allocation table.

Update of X (X = 3) Transaction end [Effect of the invention] As is clear from the above description, according to the present invention, the update status of data outside a transaction can always be known accurately.

[Brief description of drawings]

FIG. 1 is a diagram showing an outline of the present invention, and FIG. 2 is a diagram showing a system configuration of one embodiment of the present invention. 1 ... Copy file, 2 ... Database, 3 ... Before image file, 4 ... After image file, 5 ... Access handler, 6 ... Transaction handler, 7 ... Process handler, 8 ... Data outside transaction File, 9 ... Terminal, 10 ... Database management system.

Claims (1)

[Claims] 1. A non-transaction file that stores non-transaction data, a database that holds data that records the progress of update of non-transaction data, a copy file that holds a copy of the database, and a before image of the database. Before image file,
A database system that has an after image file that holds the after image of the database, and a database management system that has a means for implementing the transaction function, and N (N is an integer of 2 or more) update processing for data outside the transaction. And a process handler that executes by dividing into partial data processing of, and the process handler, in the i-th (i is 1, 2, ..., N) partial data processing, starts the transaction to the database management system. Request the database management system to change the data for notifying transaction, the process for updating non-transaction data, and the update status data in the database to a value indicating that the non-transaction data has been updated by the i-th partial data process. To complete the partial data processing At this time, the resource status holding device is characterized by performing a process of notifying the database management system of the end of the transaction.