JPH083810B2 - Shared exclusive control method for resources - Google Patents

Description

Description: TECHNICAL FIELD The present invention relates to a shared exclusive control method for resources, and is particularly suitable for localizing a failure influence range when a partial failure occurs in a complex subsystem type online system such as a distributed database. Shared exclusive control method for various resources.

[Conventional technology]

In the resource shared exclusion control method used in the conventional database system, a record accessed by one transaction during processing is held by the transaction as an exclusive resource until the transaction is completed.

A transaction requesting a resource already held by another transaction waits until the resource is released. As for those related to these exclusive control methods, for example, JP-A-61-25249 and JP-A-61-9
7755 publication etc. are mentioned.

[Problems to be solved by the invention]

In the above conventional technology, when a transaction failure to save resources occurs and the failure recovery processing of the transaction is delayed, a request is made for the resources held by the transaction, and the transaction is already in the waiting state,
No consideration is given to the delay in the execution of a transaction that requests the resources held by the transaction and goes into a wait state after a failure occurs.Particularly, in a distributed database system, some transaction failures may occur due to the failure of the connected partner computer or communication line. When the recovery process is greatly delayed, the number of transactions waiting in the system increases, and the system performance deteriorates.

An object of the present invention is to provide a shared exclusive control method for resources that limits the influence on other normal parts of the system even when the release of resources is delayed due to a cause such as a failure.

[Means for solving problems]

The above purpose is to divide the resource status in the shared exclusive control method of resources into the in-use status, the unused status and the frozen status, and when the release of the resource is delayed due to delay of transaction failure recovery processing, the busy status By changing the existing resource to the frozen state, canceling the waiting state of the transaction that requests the resource and is in the waiting state, and prevents a new transaction from requesting the resource and entering the waiting state. To be achieved.

[Operation] When a failure occurs in a transaction and the normal recovery processing cannot be executed and the recovery processing is delayed, all resources held by the transaction are frozen.

When changing a resource to the frozen state, if there is a transaction that has already requested the resource and is in the waiting state, the waiting state is released. A new use request for a resource in the frozen state notifies that the resource is in the frozen state without putting the requested transaction in the waiting state.

As a result, it is possible to prevent an external transaction from being left in a waiting state unnecessarily or a new transaction being placed in a waiting state due to the flow of resource release due to a delay in failure recovery processing.

〔Example〕

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

FIG. 1 shows an overall configuration diagram of a complex subsystem type online system which realizes the present invention.

In FIG. 1, a composite subsystem type online system is a composite subsystem controller 1 (hereinafter simply referred to as a controller) that controls a plurality of subsystems.
Two types of subsystems under it (front-end subsystem 2 and back-end subsystem 3)
And a recovery file 4 (hereinafter referred to as RF) for each subsystem and controller, a journal file 5 (hereinafter referred to as JNLF) for storing journals of all subsystems, and resource status of all subsystems are managed. A resource management table 6, a transaction management table 7 that manages transactions, a system status table 8 that manages the system status, and a system status file 9 (hereinafter referred to as SYSSF) that exists as a copy of the system status table on an external storage device. Front-end subsystem (hereinafter referred to as FE)
It has an online terminal 10 and generates a transaction which is a unit of business processing. The back-end type subsystem 3 (hereinafter referred to as BE) has a database 11 and FE2
The database 11 is accessed according to the request by the transaction generated.

The distributed database system plays the role of FE2 (hereinafter referred to as distributed server), which performs a transaction within its own processor in response to a database access request from another processor, and the role of BE3 which receives a database access request from another processor from a transaction. It is positioned as a subsystem that also has (hereinafter referred to as distributed client). Therefore, it is possible to consider a distributed database as a part of the complex subsystem type online system.

FIG. 2 shows the structure of the recovery file 4. RF4
Is a general term for an external storage that stores recovery information when there is a failure in the subsystem or the entire system that exists for each subsystem and for the controller 1, and includes a checkpoint file 410 that stores a checkpoint dump and a table. A table recovery file 420 used for recovery,
It consists of a transaction recovery file 430 for saving the journal in transaction units. Less than,
The checkpoint file is called CKPTF, the table recovery file is called TBLRF, and the transaction recovery file is called TRRF.

FIG. 3 shows the structure of the resource management table 6. The resource management table 6 is composed of a transaction node 610 queued for each FE2, a resource node 620 queued for each BE3, and a resource exclusion node 630 indicating a transaction or resource exclusive holding or waiting state.

Transaction node 610 is the transaction ID
, A link 612 to the next transaction node, and a link 613 to the resource exclusion node. The resource node 620 includes a resource name section 621 in which a resource name is stored, a link 622 to a resource exclusive node, and a link 623 to the next resource node. The resource exclusion node 630 is a link to a resource exclusion node for the next resource waiting or waiting for the same resource as the link 632 for the next resource exclusion node waiting for the same resource as the resource name part 631. 633 and transaction ID part 634
And a flag 635 indicating whether or not the resource exclusive node information has been acquired as a journal, and a flag 636 indicating whether the resource exclusive node information is held or waiting.

When a certain transaction TR ₁ holds the resource RS ₁ , there is a resource exclusion node 630 that is connected by a link 613 and a link 622 from the transaction node 610 and the resource node 620 corresponding to TR ₁ and RS ₁ , and is exclusive. The flag 636 indicating whether to hold or wait is turned on. Furthermore, if there is a transaction TR ₂ to wait for said resource RS _1, link 632 to the next resource exclusive node is created from resource exclusion nodes linked with TR ₁ and RS _1, also between the TR ₂ The link 613 is created. In the resource exclusive node linked from TR _{2, the} flag 636 indicating exclusive holding or waiting is turned off.

When the resource management table 6 is used, a list of resources held by a specific transaction or a transaction name holding a specific resource can be obtained by following the links 632 and 633. Each exclusive node has a flag 635 indicating whether exclusive node information has been saved in the journal.

Since the resource management table 6 is unified on the controller 1 through the subsystem, when the subsystem is down, not only exclusive information can be held but also deadlock across subsystems can be easily detected. .

FIG. 4 shows the configuration of the transaction management table 7. In the transaction management table, all transactions that have occurred at a certain point in time for each FE2 are registered.

The table includes a transaction ID 701 (consisting of a serial number 7012 that counts up each time the same entry as the entry number 7011 of the table is used), and an occurrence FE area.
702, a BE area 703 used, a transaction status area 710, a journal pointer 720 to a journal required for recovery of a transaction, a final pointer 730 of a TRRF 430 for storing a journal, and an exclusive node 630 of a resource management table. An entry consisting of the pointer 740 exists for each transaction. The transaction status area 710 includes a synchronization bit for acquiring a checkpoint dump, that is, an influence bit 711 and an execution monitoring bit 7.
12 and a transaction freeze required flag 713 for transaction freeze control, a rollback required flag 714 indicating that rollback recovery needs to be performed, and a sync point flag 715 indicating whether or not a transaction has passed the sync point.
And a freeze flag 716 indicating that the transaction is being frozen and a sync point preparation passing flag 717 indicating that the transaction has passed the sync point preparation and has not yet passed the sync point.
Consists of

FIG. 5 shows the configuration of the system status table 8. The system status table contains the controller 1
810, the status 820 of each subsystem, and the journal serial number recording area 815 at the time of the system checkpoint.

Each time the system status table is updated, a corresponding entry is written in SYSSF, and a copy is made in SYSSF.

In the composite subsystem type online system shown in the present embodiment, in order to recover in the event of a failure, various kinds of information are output to an external storage device to carry out business processing. Resources to be recovered (general term for data and information) are roughly divided into the following 2
There are types.

(1) A volatile resource of a type that disappears when a failure occurs, such as a table on a virtual storage device (2) Generally, even when a failure occurs, such as a database on an external storage device, the state at the time of the failure occurrence A non-volatile resource of the type that retains the same. In order to recover the volatile resource that disappears when a failure occurs, a copy of the resource is created in a non-volatile external storage device on a regular basis. Checkpoint dump). Each time the change is made after the checkpoint dump is acquired, the difference information of the change is acquired as a journal, and the journal information is superimposed on the checkpoint dump, whereby the recovery can be performed. This type of journal is called a history journal.

To recover the non-volatile resource that retains the state at the time of failure, a journal is acquired each time a change is made. At the time of recovery, it is determined whether the update is completed or invalidated for each transaction, which is a unit of business processing, and the post-change information or the pre-change information of the journal acquired each time is changed is superimposed. Make a recovery. This type of journal is called a transaction journal.

In the system of the present embodiment, journal output is performed prior to database update and table update in preparation for failure recovery. Journal output is performed for one JNLF5 by integrating each subsystem using the function under the controller. The integration of JNLF5 will greatly contribute to the improvement of operability when operating the composite subsystem. The journal acquisition method will be described below.

The journal is always acquired before updating the database or updating the table. If a change is made before journal acquisition, recovery will not be possible if a failure occurs before journal acquisition after the change.

At the end of the transaction, after outputting all the journals of the transaction, all journals are output, that is, a journal indicating a synchronization point (hereinafter referred to as a synchronization point journal) is output.

In the transaction in which the synchronization point journal exists as a journal, all transaction-type journals necessary for recovering the non-volatile resource exist, so that recovery in the direction of completing the processing of the transaction can be performed. In contrast, there is no guarantee that all journals are output in a transaction that does not have a sync point journal. However, since a journal is always output before a change, the transaction is updated using the pre-change information of the existing journal. Can be recovered in the direction of invalidating.

After the transaction is completed, the journal indicating the transaction end is acquired. The journal indicating the end is called an end journal. After the journal is output, recovery by the transactional journal becomes unnecessary.

In the case of a distributed database, one transaction updates a database in its own system and a database in another processor, so that it is necessary to synchronize database updates across processors. The method of journal acquisition in the case of a distributed database will be described below.

At the end of the transaction, first, all journals on the distributed client side are output. At this point, the distributed client issues an instruction to output all journals to the distributed server (hereinafter, this is referred to as a synchronization point preparation instruction). The distribution server receives the instruction and outputs a journal indicating that synchronization point preparation is completed after outputting all journals (hereinafter, this is referred to as a synchronization point preparation journal). After the output of the journal is completed, the distributed server reports the completion of the synchronization point preparation to the distributed client. On the distributed client side, after receiving all the journals in the own system of the transaction and the sync point preparation completion report from the distributed servers of all the other processors that have issued the request, the sync point journal is output. After the output of the synchronization point journal is completed, the distributed client updates the database in its own system, and issues an instruction to the distributed server that the transaction has reached the synchronization point (hereinafter, this is referred to as a synchronization point instruction). Do. Upon receiving the sync point instruction, the distributed server first outputs the sync point journal and then completes the database update of the transaction remaining in the buffer. After that, the end journal is output, and after the output is completed, the completion of the transaction is reported to the distributed client. The distributed client outputs the end journal after updating the database in its own system and receiving completion reports from all distributed servers that have issued the instruction.

On the distributed client side, if the sync point journal exists, recovery can be performed in the direction in which the transaction is valid, and recovery can be performed in the direction in which the transaction is invalid. On the distributed server side, if the synchronization point preparation journal and the synchronization point journal exist, the recovery is performed in the direction in which the transaction is valid. If neither the synchronization point journal nor the synchronization point preparation journal exists, the transaction is restored. Perform recovery in the direction of invalidation. If only the synchronization point preparation journal exists, the presence or absence of the synchronization point journal on the distributed client side is checked, and recovery can be performed according to it.

A conventional online system that has its own journal file in the processor and acquires a journal is connected to a complex subsystem type online system, and a transaction executed under the online system is
In the case of updating the database of the BE of the combined subsystem type online, treat the online system as one FE similar to the distributed server, and use the above-described journal acquisition method to update the database in the online system and the combined subsystem type. Synchronized recovery of online system BE database updates.

In this embodiment, the table to be recovered is periodically acquired as a checkpoint dump for each subsystem, and the transaction journal is saved in TRRF at the same time. The method of acquiring each information will be described below.

The concept of checkpoint dump acquisition and the flow chart of the acquisition are shown in FIGS. 6, 7, and 8.

As shown in FIG. 6, each of the subsystems 2 and 3 regularly checks the checkpoint target table 411 on the virtual storage device.
Is stored in CKPTF410. Enabled to recover even if CKPTE410 fails while storing checkpoint dump
CKPTF410 manages generations. At the time of recovery after a system failure, the table can be recovered by superimposing the information on the latest generation CKPTF410 and the update information after the checkpoint stored in JNLF5. Acquiring a checkpoint dump periodically limits the journal information required at the time of recovery after a failure has occurred, which has the effect of reducing the amount of journals input during recovery and shortening the recovery time.

The checkpoint dump is acquired by each subsystem, but at this time, the business process using the subsystem is not stopped. Therefore, the table being updated may be acquired as a checkpoint dump. Even if the table information being updated is acquired in the checkpoint dump,
If the journal corresponding to the update is acquired after the checkpoint time point, the history journal information before the checkpoint time point is not required after the checkpoint dump acquisition is completed.

The timing 410e at which the update of the table and the acquisition of the corresponding journal are completed varies depending on the transaction and is not synchronized. Also, it takes a finite time to acquire a checkpoint dump. Therefore, the checkpoint dump is stored at the checkpoint time 41 as shown in FIG.
0a, checkpoint dump acquisition start time 410b, acquisition end time 410c, and checkpoint dump effective time 410d
Are obtained separately for the four time points. When it is necessary to obtain a checkpoint dump, first declare the checkpoint point 410a. Since the journal corresponding to the table information being updated at that time may have been acquired before the checkpoint time 410a, the checkpoint dump acquisition cannot be started yet. Therefore, the process waits until all the processes being updated at the checkpoint time point 410a have completed the update process, and after the completion, the acquisition of the checkpoint dump is started. Even if the checkpoint dump acquisition is completed,
Since the journal corresponding to the update may not have been output yet, checkpoint dump acquisition end time 41
Wait until the time when all the journals corresponding to the process being updated to 0c are output, and after the output is completed, the checkpoint dump effective time is set to 410d. If a failure occurs before the checkpoint dump valid point 410d has elapsed, the checkpoint dump is not used and recovery is performed using the checkpoint dump of the previous generation.

In this embodiment, a checkpoint dump is acquired according to the flow shown in FIG. First, the controller 1 activates the checkpoint dump acquisition task 412 when a certain number of journal output items is reached. Launched task 412
Stores the journal serial number at the checkpoint as a checkpoint journal serial number 815 in the virtual memory managed by the controller, and waits for the start of checkpoint acquisition. When it becomes possible to start the checkpoint acquisition, it issues a checkpoint dump acquisition instruction to each subsystem. Each subsystem acquires the checkpoint dump in the CKPTF410 of each subsystem according to the checkpoint dump acquisition instruction. When the acquisition is completed, an acquisition completion report is sent to the controller. After confirming the acquisition completion report of each subsystem, the controller waits for checkpoint dump activation. When the checkpoint dump can be enabled, the valid bit is recorded in the CCKTF410 and SYSSF9, the checkpoint dump acquisition ends, and the process waits until the next acquisition timing.

Here, the same method is used for the waiting for the start of checkpoint dump acquisition and the waiting for the checkpoint dump activation. This method will be described with reference to FIG.

In FIG. 8, each transaction turns on the influence flag 711 on the transaction management table 7 when using the function including the table update that is the checkpoint target, and turns on the influence flag 711 at the end of the function use.
Then, the execution monitoring flag 712 is turned off. This flag operation is performed in a common routine when passing to the processing routine. When the common routine is not used, a method of declaring start and end in the processing of each subsystem may be adopted.

In FIG. 10, the checkpoint dump acquisition task 412 in the controller starts the checkpoint dump start wait or the activation wait, if the influence flag 711 is ON for all transactions in the transaction management table 7, the execution monitoring flag Turn off the 712.
After that, it waits with a timer, and every time it is activated, it is checked whether all execution monitoring flags 712 are turned off. If all the execution monitoring flags 712 are turned off, it means that all the processing including the table update is completed at the time of starting the waiting.

When a checkpoint dump is output, the journal pointer information, which will be described later, and the logical information in the resource management table are saved so that recovery can be performed without the journal information or resource management information before the checkpoint. Further, the transaction management table is a checkpoint dump target table and can be recovered. The saving of the logical information of the resource management table is performed in the format of the resource management logical information table 750 shown in FIG. In the logical information table, for all the resources in the resource management table, the transaction ID 701 of the transaction holding the resource is indicated by the resource management table 6 shown in FIG.
The resource exclusive node 630 is obtained by tracing the link 622 from the resource node 620 to the resource exclusive node, and is created by storing the resource name 751 and the transaction ID 752 as a pair. The pair to be output at this time is the resource holding information output to the journal before the checkpoint time point, and the resource holding information after the checkpoint time point is recovered from the journal as described later.

When outputting the journal to JNLF5 on the external storage device,
A journal pointer 720 having the format shown in FIG. 12 is created for all the transaction type journals existing on the output buffer, and the journal pointer 720 is saved in the corresponding transaction entry in the transaction management table. The pointer
720 includes a serial number 721 of the journal, a file name 722 of JNLF5, and a relative block number 723 from the beginning of the file. By using the pointer, the journal output by the transaction at a necessary time can be obtained. If the controller 1 is not down when a failure occurs, the journal can be directly obtained by the journal pointer when the transaction is recovered.

At the time of checkpoint dump output, for the transaction existing at the time of checkpoint dump validity point 410d, the journal pointer 720
The journal is read from JNLF5 by using and the transaction recovery file 430 is saved. To determine whether or not to save, refer to the journal serial number 721 in the journal pointer 720 in the transaction table 7, if the number is prior to the journal serial number 815 at the checkpoint point 410a, save it, and if it is later, checkpoint It is not saved because it is a journal that exists in JNLF5 after the dump.

In this embodiment, a fixed area of TRRF 430 is assigned to each transaction prior to the start of the transaction.

When saving, the additional writing is performed from the TRRF last pointer 730 in the transaction table 7 so as not to lose the information in the TRRF 430 saved at the checkpoint one generation before. Here, the TRRF final pointer 730 points to the beginning of the area in the TRRF allocated to the transaction when the transaction occurs, is updated each time the journal is saved thereafter, and always points to the end of the area allocated to the transaction in the TRRF. It is a pointer.

By saving the journal information to the TRRF430, after the checkpoint dump is acquired, the journal before the checkpoint time is not necessary for the recovery of transactions that have been prolonged from before the checkpoint time.
The TRRF430 is organized into transaction-based entries, so the TR
It's easy to get the data needed for recovery in the RF430 and journals after the checkpoint.

Furthermore, at the time of transaction type journal output,
The resource holding information is output at the same time. This is because when the transaction type journal is output, the resource possessed by the transaction is obtained by tracing the resource exclusion node 630 from the transaction node 610 of the resource management table 6, and the resource holding information is shown in FIG. This is done by adding to the transaction journal and outputting in the same format as the entry of the resource management logic information shown.

JNLF5 together with the transaction journal as the resource management logical information table retained as a checkpoint dump in CKPTF410 during recovery after a failure
The resource management table can be recovered by repeating the resource securing process from the resource holding information output to.

For this reason, it is sufficient to block the database entirely, that is, to block a limited range (only used portions) instead of completely prohibiting access to the database,
If some subsystems are down or some transactions cannot be finalized, the online system can be started.

Recovery when an entire composite subsystem type online system fails is called full recovery, and recovery when only a specific subsystem fails is called subsystem recovery.
The full recovery and the subsystem recovery of the composite subsystem type online system will be described below.

First, the flow of full recovery of the combined subsystem type online system will be described with reference to FIGS. 13 to 17. In the full recovery, the function of the controller 1 is first recovered. After that, each subsystem is restored, but even if some subsystem functions cannot be restored, the system can be restarted with the functions degraded. To recover the function of controller 1, first SY
The controller CCKPTF410 is determined from the SSF9, and the transaction management table 7 in the controller is recovered from the CCKTF410. Also, the resource management logical information table 750 is restored. By reading CKPTF410 for controller,
The journal serial number at the current latest checkpoint and the journal pointer 815 for the journal having the journal serial number are determined.

Next, as shown in FIG. 14, JNLF5 is sequentially read from the position pointed by the journal pointer 815 at the latest checkpoint. If the read journal is a history journal output by the controller, it is used as the update information of the transaction management table 7 or the resource management logical information table 750 according to the flow of FIG. 15, and each table is in the state at the time of failure occurrence. To recover. The history journal output from other than the controller is output to the output subsystem TBLRF420. In the case of a transaction type journal, it is stored in the area of the journal pointer 720 of the corresponding transaction entry in the transaction management table 7 in the journal pointer format. The entry of each transaction in the transaction management table 7 is recorded by turning on the sync point passage flag 715 when the sync point journal is found, and deleted when the end journal is found.

When the sync point preparation journal exists like the distributed server side of the distributed database, if the sync point preparation journal is found, the sync point preparation passing flag 717 is first turned on to record the sync point preparation state. If a synchronization point journal is found, the synchronization point preparation passage flag 717 is turned off and the synchronization point passage flag 715 is turned on. If the end journal is found, the entry is deleted.

When the journal reading is completed, the history journal of each serve system is TB for each subsystem.
It is classified into LRF420 and output. The transaction management table 7 has been recovered up to the point of failure,
Only the transactions that existed at the time of failure were registered. Transaction management table 7 at this point
The entry for each transaction for which the freeze-necessity flag of all the transactions therein is turned on is recovered including the journal pointer 720 area.

As for the resource management logical information, the state at the time of the latest checkpoint and the updated information after that point are all available. When the reading of the journal is completed, the resource management table 6 is recovered by repeating the resource securing and releasing operations based on the resource management logical information. Further, all the exclusive nodes 630 in the recovered resource management table are frozen. If a new resource is secured for the resource in the frozen state, the resource securing request fails without creating the exclusive node 630 because of the frozen state. Therefore, by freezing the resource management table, the resources used at the time of failure can be temporarily disabled.
Even if a new transaction occurs, if it can operate only with available resources, it can be executed and if an unusable resource is required, it is treated as an error and does not wait for a long time. That is, the recovery as the controller 1 ends when the resource management table 6 is recovered and frozen. At this point, a system ready message is output, but the subsystem has not been recovered yet, so the operation of the combined subsystem-type online system as a whole does not start.

There is also a method of freezing resources only when they fail in the settlement described later. In this case, the transaction accessing the same resource waits, but only waits until the settlement is completed, so that the influence of the failure can be reduced.

Next, subsystem recovery begins. Each subsystem performs a recovery process in parallel according to an instruction from the controller 1.
The recovery of each subsystem ends by recovering the recovery target table in the subsystem based on the history journal stored in TRLRF420. At this point, the combined subsystem online system begins operation. In addition,
If some of the subsystems fail to recover, only those subsystems are in a degenerated state. Even at this time, the transactions that were operating at the time of the occurrence of the failure have not been recovered, but all of these transactions need to be frozen, and will be recovered by the transaction freeze settlement process described later. Newly generated transactions are executed as they are.

After issuing a recovery instruction to each subsystem, in parallel with the recovery in the subsystem, the controller 1 accesses resources (in general, all the transactions for which the freeze required flag in the transaction management table 7 is on). Recovers the database). Therefore, the controller 1 starts processing for transaction recovery. This is called freeze settlement processing. FIG. 16 shows the flow of the freeze settlement process.

In the freeze settlement process, first, a transaction that needs to be frozen is frozen. Here, to freeze a transaction means to temporarily stop the transaction without ending it, and for this reason, information necessary for recovery is saved.

In the transaction freezing process, as shown in FIG. 16, the journal of the transaction management table 7 reads out the journal output under the transaction from JNLF5 based on the pointer 720. The read journal is additionally written to the TRRF 430 from the position of the TRRF final pointer 730 of the transaction management table 7 as in the checkpoint dump output. With respect to the journal pointer 720 of the transaction, when all the journals are saved in the TRRF 430, the freeze processing of the transaction is completed, the freeze required flag is turned off, and the freeze flag is turned on. When a transaction is frozen, all journals needed to recover the transaction have been stored in TRRF 430. This is because the transaction journal output before the latest checkpoint time has been saved to TRRF430 at the checkpoint time, and the journal after the checkpoint time is saved to TRRF430 by freeze processing using the journal pointer 720. Because it was done.

The controller 1 periodically selects from the transaction management table 7 a transaction in a frozen state, that is, a transaction in which the freeze flag is turned on, and recovers the resource held by the transaction.
Resource recovery is determined by the presence or absence of a sync point journal.
If the synchronization point journal exists, that is, if the synchronization point passage flag 715 is on, the update is completed based on the journal. This is called roll forward. If there is no sync point journal, that is, sync point passing flag 71
If 5 is off, the update in the transaction is invalid and the updated part is returned to the previous state based on the journal. This is called rollback. Roll forward and rollback processing are collectively referred to as resource settlement or transaction settlement.

In the settlement processing, as shown in FIG. 16, first, one transaction in which the freeze flag 716 in the transaction management table 7 is on is selected, and the status of the transaction is selected as the sync point passage flag in the transaction management table 7. Check at 715. If it has passed the synchronization point, roll forward processing is performed, and if it has not passed the synchronization point, roll back processing is performed. Roll forward and roll back are performed by determining the use BE 3 of the transaction from the use BE 703 of the transaction management table 7 and instructing all use BEs to perform roll forward and roll back. To issue an instruction, the TRRF 430 is read in advance, a journal related to the BE of the transaction is created as a table on the virtual storage, and delivered to the BE.
BE3 has already recovered itself, and if the BE function has recovered,
Settle resources based on the given journal. When the recovery is completed, release the exclusive node of the frozen resource,
Release the resources and turn off the freeze flag 716. If BE has not completed recovery or cannot recover,
Leave the transaction frozen. Therefore, even if the recovery process is not terminated by a BE that cannot recover from a failure, the range that cannot be recovered can be limited to only the transactions that have updated the database of the BE.

Fig. 17 shows the settlement process when the databases of multiple BEs are updated in one transaction. When updating the database of multiple BEs, if BE3 to which the journal input from TRRF430 is to be passed is in failure, the journal is skipped.
Processing continues for the remaining journals in RRF430. TR
If there are any journals in RF430 that are skipped because of BE3's failure after the end of the journal, BE3 that has been processed excluding the BE3.
Output the partial end journal for, release the resources corresponding to the closed BE, and leave the transaction frozen. Regarding the processed BE3, it is recorded in the used BE entry in the transaction management table that it has been processed. Next, when the settlement process is executed, if the journal input from the TRRF 430 is the already processed BE3 journal, the reading is skipped. Therefore,
When a transaction updates the database of multiple BEs, part of the BEs are in failure recovery processing, not the entire transaction but the failed BEs of the transaction.
Recovery is only pending, and a recoverable BE
The non-recoverable range can be minimized by completing the recovery process for.

In the case of the distributed server side of the distributed database, the subsystem corresponds to FE2, and the state before passing through the sync point is further divided into the sync point preparation state and the state before sync point preparation. If the state is before the synchronization point preparation, the rollback process is performed, and if the state after the synchronization point has passed, the rollforward process is performed. In the sync point ready state, the distribution server of the distributed database inquires the distributed client that generated the transaction, and if the corresponding transaction on the distributed client side has passed the sync point, the roll forward process is performed and the sync point If it has not passed, rollback processing is performed. The identification information of the distributed client and the transaction to be inquired from the distributed server is recorded in the generated FE entry 702 of the transaction management table at the time of the transaction generation on the distributed server side.

The distributed database system in my system is in failure,
Alternatively, when the other processor is in failure, only the transaction in the sync point preparation state cannot be settled and remains, but the other transactions are settled according to the flow of FIGS. 16 and 17.

On the other hand, in the case of the distributed client of the distributed database, this subsystem corresponds to BE3. In the flow of FIG.
If the distributed client is recorded in the used BE entry 703 in the transaction management table, the controller 1 issues a rollback or rollforward instruction to the distributed client at the time of journal transfer processing to each BE3. The distributed client sends the instruction to the distributed server. On the distributed server side, if the transaction that has received the instruction is in the sync point preparation state, in the case of the roll forward instruction, the transaction is in the sync point passing state. In the case of the rollback instruction, the state is set to the state before the synchronization point preparation, and the corresponding settlement processing is performed.

If a transaction on the distributed server side issues a request to the distributed database of another processor, it will be handled in the same way simply by associating it with the case where the distributed client on the system is used as one BE of the transaction. be able to.

Second, recovery from a subsystem failure will be described with reference to FIG.

In the composite subsystem type online system, when a failure occurs in the subsystem, only the subsystem is treated as a failure and the subsystem is recovered. The subsystem recovery method differs between FE2 and BE3.

In the recovery when a failure occurs in the FE2, it is necessary to recover the function of the subsystem and to recover all the transactions generated under the subsystem. When only the subsystem has a failure, the transaction management table 7 of the controller 1 exists on the virtual storage device as it is. Therefore, in the routine called when the subsystem ends abnormally, the FE area 702 of the transaction management table 7 is generated.
The freeze required flag 713 is turned on for all transactions generated by the subsystem. Here, the transaction generated by the failed FE2 is limited by referring to the generated transaction area 702 in the transaction management table 7. Therefore, the failure of the FE can be limited to the transaction generated by the FE, and the business process can be performed without affecting the transaction generated by another FE.

When the controller detects the subsystem down, the controller 1 sequentially reads JNLF5 from the latest checkpoint, and stores the history journal associated with the faulty subsystem in the TBLRF420 of the subsystem, as in the case of the full down. After that, the controller 1 restarts the subsystem and issues a recovery instruction to the subsystem after the startup. The subsystem that received the recovery instruction is CKPTF410
The function of the subsystem is restored based on TBLRF420.

In parallel with the function recovery of the subsystem, the controller 1 sets the freeze-necessary flag of the transaction management table 7.
For all transactions in which 713 is ON, all transactions are frozen according to the flow shown in FIG. 16 and settled as in the case of full recovery. Since the resource management table 6 is managed by the controller 1, the resource management table 6 remains valid at the time of subsystem failure and recovery. Therefore, the failure occurrence FE2 freezes and finalizes the transaction of the controller 1 after recovery of the subsystem function. You can start processing new transactions without waiting.

In the recovery when a failure occurs in the BE3, it is necessary to recover the function of the subsystem and the transaction using the BE. As in the case of the FE2 failure, the transaction management table exists on the virtual storage device.
In the routine called at the time of abnormal termination of BE3, the rollback required flag 714 is turned on for all transactions using the BE with reference to the used BE area 703 area of the transaction management table 7. Here, since the transaction using the failed BE3 is limited to the used BE area 703 of the transaction management table 7, the failure of the BE can be limited to the transaction actually using the BE, Business processing can be executed without affecting transactions using only other BEs.

Further, the resources managed by the BE3 cannot be released until the failure recovery of the BE3 ends, so that it is necessary to freeze the resources. The resource is frozen for all the resource nodes 630 in the resource management table 6 which are connected to the BE3 in a routine called when the BE2 ends abnormally. Resource freezing may be simply required to be frozen when a failure occurs, and may be delayed until BE recovery and transaction settlement are completed. As a result, other transactions requesting the same resource do not return with an error, but wait temporarily, and if the transaction holding the resource is successfully settled, the processing continues as if there was no failure. You can do it.

When the controller 1 detects a subsystem down,
Controller 1 uses JNLF5 to TBLRF4 as in the case of FE2 failure.
Create 20. After that, the controller 1 restarts the BE3, and after starting the BE3, issues a recovery instruction to the failure BE3. The BE 3, which has received the recovery instruction, recovers the function of the BE based on the CKPTF 410 and the TBLRF 420. However, depending on the type of BE, CKPTF4
Does not require 10 or TBLRF420. In this case, the controller 1 simply issues a recovery instruction without reading JNLF5, and the BE performs function recovery.

Waiting for the functional recovery of the subsystem, the controller 1
In the same manner as in the case of full recovery, all transactions in which the rollback required flag 714 of the transaction management table 7 is ON are frozen according to the flow of FIG. 16, and the rollback direction is decided.

As described above in the subsystem failure recovery, the effect of subsystem failure is limited to a specific transaction by using the generated FE area 702 and the used BE area 703 of the transaction management table 7. Because of this mechanism, the processing of other subsystems can be performed normally even if some subsystems fail, and the operation of the combined subsystem type online system can be continued. In addition, by having RF4, the subsystem that failed can recover with a delay without being affected by the progress of other subsystems, and can join without affecting other subsystems. it can.

Thirdly, when a failure occurs in the business processing program and the transaction being executed abnormally ends, the freeze-necessary flag 713 of the transaction is turned on in the routine called at the abnormal end. As a result, the controller 1 freezes and finalizes the transaction in the same manner as when the entire system goes down. The business processing program recovers its function by being started again by the FE2.

〔The invention's effect〕

According to the present invention, due to a delay in resource release due to a delay in failure recovery processing, other transactions are not left unnecessarily in a waiting state, and a new transaction is not put in a waiting state. It can prevent the deterioration.

[Brief description of drawings]

FIG. 1 is an overall configuration diagram of a composite subsystem type online system, FIG. 2 is a configuration diagram of a recovery file, FIG. 3 is a configuration diagram of a resource management table, FIG. 4 is a configuration diagram of a transaction management table, and FIG. Is a configuration diagram of the system status table, FIG. 6 is a conceptual diagram of checkpoint dump acquisition, FIG. 7 is a timing diagram of checkpoint dump acquisition, FIG. 8 is a flow chart of checkpoint dump acquisition, and FIG. 9 is a checkpoint dump. Flow chart of the validation method, Figure 10 is a flow chart of the waiting process in the checkpoint dump acquisition, Figure 11 is a block diagram of the resource management logical information table, Figure 12 is a concept and block diagram of the journal pointer,
Fig. 13 is a flow chart of full recovery, Fig. 14 is a flow chart of journal recovery, Fig. 15 is a flow chart of journal recovery of controller, Fig. 16 is a flow chart of transaction freeze / conclusion, Fig.
Figure 17 is a flow chart of the settlement when one transaction updates multiple BEs, and Figure 18 is a flow chart of subsystem failure recovery. 1 ... Composite subsystem controller, 2 ... Front-end subsystem, 3 ... Back-end subsystem, 4 ...
Recovery file, 5 ... Journal file, 6 ... Resource management table, 7 ... Transaction management table, 8
… System status table, 9… System status file, 10… Online terminal, 11… Database.

Claims (3)

[Claims] 1. A time point at which a resource to be managed, a user who uses the resource, and a user who has not yet been given a usage right for the resource requested by the user are placed in a waiting state and the usage right for the resource is given. In the shared exclusive control method for resources that releases the waiting state with, the state of the resource is a busy state indicating a state in which the right to use the resource requested by the user is given,
An unused state, which indicates that none of the users are given the right to use the resource requested by the user, and a state that is the same as the normal state for the user who holds the right to use the resource. Is held for the resource, and the user who already has the usage right for the resource requested by the user is notified that the usage right request has failed, and the user is released from the waiting state. It is classified into a frozen state, which indicates the status that the usage right request fails unconditionally to the user of the new usage request, and any resources in use or unused are used by the user. If the resource requested by the user is already in the frozen state, the resource user is not put in the waiting state by changing to the frozen state in response to the request.
Notify the user that the resource is in the frozen state, and if the resource in use changes to the frozen state, wait for the user requesting the resource in the waiting state without being given the usage right. Shared exclusive control of resources characterized by notifying the user that the relevant resource is in a frozen state after releasing the state, and performing processing to prevent the notified user from falling into an unnecessary waiting state Method. 2. The resource shared exclusive control method according to claim 1, wherein each resource unit is changed to a frozen state, and resources to which a specific user has a usage right are assigned. A shared exclusive control method for resources, which is characterized by changing all to a frozen state. 3. A resource shared exclusion control method according to claim 1, wherein a group to which the resource belongs is stored, a certain group is designated, and all the resources belonging to the group are frozen. A shared exclusive control method for resources, characterized by: