KR0139724B1 - How to Detect and Process Zombie Transactions in a DBMS on Unix Environments - Google Patents

Abstract

The present invention relates to a method of detecting and processing a zombie transaction when there is a zombi transaction caused by abnormal termination of a process during a transaction operation in a DBMS in a UNIX environment. A first step of checking whether a means a zombie transaction, a second step of checking a next transaction entry if the check result is not a zombie transaction, and processing a latch resource if a zombie transaction is confirmed; And a fourth step of invalidating by undoing a database change portion performed by the transaction, and a fifth step of returning the transaction table entry, thereby increasing DBMS system resource utilization. Resource usage can be efficient without error It has an effect.

Description

Detection and Management Method of Zombi Transaction in DBMS of Unix System

1 is a hardware configuration to which the present invention is applied.

2 is a block diagram of a shared memory system according to the present invention.

3 is a flowchart of a transaction in normal execution according to the present invention.

4 is a flowchart illustrating a zombie transaction discovery processing operation according to the present invention.

* Explanation of symbols for main parts of the drawings

11: Processor 12: Memory

13: Shared memory in memory 14: Input / output dedicated processor

15: secondary memory

In the present invention, when there is a zombi transaction caused by abnormal termination of a process during the operation of a transaction in a database base management system (DBMS) in a UNIX environment, It's about finding a zombie transaction and handling it.

In general, a DBMS transaction is a resource that is managed by the DBMS (resources for lock management, resources for file management, resources for latch management to use critical areas, etc.) in addition to the basic behavior of changing the contents of the database while the operation continues. It is assigned by itself.

And when the transaction ends normally (completed or withdrawn), these resources are returned.

However, there are cases where a DBMS process is removed by an abnormal method, in which case the corresponding transaction table entry in the DBMS system appears to be assigned to any process, but in reality the process is no longer in the operating system and therefore the process is removed. It will be executed until it is returned until the system resources allocated to it are returned.

Transactions in this state are called zombi transactions.

As such, when a zombie transaction is made, the resources used by this transaction are left unreturned. Therefore, the system becomes short of resources or other transactions wait for the resources of the zombie transaction.

Nevertheless, there was no technical explanation or introduction literature on this.

Therefore, an object of the present invention is to provide a method for discovering and processing a zombie transaction when a zombie transaction occurs to improve the utilization of system resources in a DBMS in a UNIX environment to solve the above problems.

In order to achieve the above object, the present invention provides a first step of checking whether each entry represents a zombie transaction for each transaction table entry, and if the first step is not a zombie transaction, the next transaction entry is checked and a zombie transaction is performed. A second step of processing a latch resource, a third step of processing a LOCK resource, a fourth step of invalidating, by Undo, a portion of the database change performed by the transaction, when the check is performed. And performing a fifth step of returning a transaction table entry.

The present invention uses system functions related to process status checking supported by the UNIX operating system.

Hereinafter, with reference to the accompanying drawings will be described in detail the present invention.

1 is a hardware configuration diagram to which the present invention is applied, and includes a processor (Pi (1 = I = n)) 11, a memory area (Mem) 12, a shared memory (SM) 13 in a memory, and input / output only. It consists of a processor (IOP) 14 and an auxiliary memory (DISK) 15.

As such, the present invention can be operated in a general hardware environment including a single processor or multiple processors and shared memory.

2 is a block diagram of a shared memory system according to the present invention, which is a block diagram of a shared memory block of a DBMS system when n transactions operate in the system.

TT (i) is a transaction table entry for one transaction Ti being executed.

One transaction table entry includes a process number (process_ID), a latch hold list (LatchHoldList), a lock hold list (LockHoldList), and information necessary for transaction management. In FIG. 2, only parts necessary for describing the present invention are illustrated in FIG. Specified.

Where the process number represents the identifier of the UNIX operating system process on which the transaction is performed.

A transaction is allocated and used with resources of a DBMS system during normal operation. The latch maintenance list and lock maintenance list are used to maintain the latch and lock resources allocated to the transaction. will be.

A latch pool is a set of latch data structures L (i) (i = i = m) held in a DBMS system.

Latch is used as a way to implement a critical section for a resource that needs to be mutually exclusive among the resources in the system. Every transaction must be assigned a latch first to use the system resource defined as the critical section.

A lock pool is also a collection of lock table entries maintained in a DBMS system.

In normal execution, a transaction must be allocated a designated latch first to use an arbitrary threshold area, and the latch is returned immediately after the use of the critical area is completed.

This latch is the most frequently used resource in the DBMS system. If any latch is not returned after being used, other transactions must wait until the latch is returned.

3 is a flowchart of a normal transaction in accordance with an embodiment of the present invention. In the normal execution, a transaction is registered to a corresponding list in a transaction table entry in order to maintain a DBMS resource usage state.

First, check if the lock resource is requested (32).

When the lock resource is requested, the lock request is granted, and the lock table entry is registered in the lock holding list of the transaction table entry (33).

If a lock resource is not requested, then it is checked if a latch resource is requested next (34).

When a latch resource is requested, a latch request is granted and the corresponding latch structure entry is registered in the latch holding list of the transaction table entry (35).

If the latch resource is not requested, it is checked next if the latch resource is returned.

When the latch resource is returned, the latch resource is recovered, that is, the latch structure entry is returned to the latch pool, and the latch structure entry is deleted from the latch holding list of the transaction table entry (37).

4 is a flow chart illustrating a process of discovering and processing such a transaction when a zombie transaction occurs as a zombie transaction processing flowchart according to the present invention.

First, for each of the transaction table entries TT (i) (1 = i = n) described in FIG. 2, it is checked whether each entry represents a zombie transaction (42).

The inspection method uses the UNIX system call kill (an action that interrupts and erases a running or registered processor before it finishes normally), which is used to validate the process identifier.

In other words, if the result is kimm (TT (i) .process_ID, 0) and the result is not 0, the corresponding transaction table entry is determined as a zombie transaction.

After the determination, if a zombie transaction is confirmed, the next steps 43 to 46 are performed, and if it is not a zombie transaction, the next transaction entry is examined.

Since latches are most frequently used during DBMS sleeping, the latch resources are processed first (43).

That is, all latch resources registered in the latch holding list of the transaction table entry are recovered.

This process prevents the inefficiency of waiting for other transactions to use the latches occupied by the zombie transaction.

After processing the latch resource, a lock resource is processed (44).

That is, the lock is released and lock table entries are retrieved for the locks registered in the lock maintenance list.

Next, when the part of the database changes made by this transaction cannot be executed to the end due to a failure that occurred during the execution of the transaction, the database is returned to the state before the start of the transaction to implement the atomicity of the transaction. The function is invalidated (45).

This transaction table entry is returned (46).

This process is the same as when a transaction ends normally.

The present invention performed as described above removes the phenomenon of wasting DBMS system resources by zombie transactions and waiting for other transactions to wait for system resources not returned by zombie transactions in DBMS under UNIX operating system, thereby increasing DBMS system resource utilization and resources. There is an effect that can be used efficiently without error.

Claims (4)

A method of detecting and processing a zombie transaction in a UNIX database management system (DBMS), the first step of checking whether each entry represents a zombie transaction for each transaction table entry (42) Wow; A second step of inspecting a next transaction entry if it is not a zombie transaction and processing 43 for a latch resource if it is confirmed as a zombie transaction; A third step of processing 44 a lock resource; A fourth step of invalidating (45) by undoing a database change part performed by the transaction; And a fifth step of returning (46) the transaction table entry. The method of claim 1, wherein the first step is performed by using a kill (TT (i) .process_ID, 0) statement of a UNIX system call and determining that the corresponding transaction table entry is a zombie transaction if the result value is not zero. Characterized by zombie transaction discovery and processing method. The method of claim 1, wherein the second step is performed by retrieving all latch resources registered in the latch hold list of the transaction table entry. The method of claim 1, wherein the third step is performed by releasing locks on locks registered in the lock list and retrieving a lock table entry.