KR100502501B1 - Method for real-time remote logging and recovery of database system - Google Patents

Abstract

The present invention discloses a real time remote logging and recovery method of a database system.

According to the present invention, after the DB server operates as a process in the service host, processes the user's request, records the local DB log, checks the persistence condition when performing the commit operation, and delays the completion of the commit process until the condition is met. Local D-AGENT operates as a separate process on the service host and periodically checks the local DB log buffer, reads the new local DB log, sends it to the remote logging host server, and receives the LSN that succeeded in recording. Remote D-AGENT operates as a process on the remote logging host, and records the remote DB log received from the local D-AGENT to the remote DB log buffer and the remote DB log file, and sends the last LSN to the local D-AGENT. When the user executes the commit command, the DB log is completely written to the DB log file in the conventional manner. Instead, it can improve transaction processing performance by sending the DB log to a separate remote logging host completely and waiting only for the time of receiving the response. Also, if the DB server is restarted due to a system error, the DB log is lost. By solving this problem, the persistence characteristics of the DB server can be strengthened.

Description

{Method for real-time remote logging and recovery of database system}

The present invention relates to database management, and more particularly, to a real-time remote logging method using a separate remote logging host and a database recovery method in case of an error.

In general, the DB server manages database changes in transaction units to manage the database. Transaction processing needs to comply with the ACID characteristics. ACID characteristics mean atomicity, consistency, isolation, and durability. In particular, the persistence property specifies that once a transaction is committed, changes in database state by that transaction must be stored permanently.

For this purpose, DB and DB logs are generally kept on disk, which is a permanent storage. However, while the disk is stable, the performance of the read / write operation is relatively longer than that of the main memory, resulting in a decrease in performance. To compensate for this, there are conventional attempts to improve transaction processing performance at some cost of persistence.

Figure 1 is a comprehensive representation of a conceptual diagram of a conventional DB server 200 processes a transaction, DB service means 211 is recorded in the DB log buffer 213 when the user 100 requests to commit (1a) (1c) The DB log is recorded in the DB log file (1d), and after confirming that the recording is completed (1e), a completion message is sent to the user (1f). At this time, if necessary, the pages in the DB memory buffer 212 are written to the DB file 214 (1g). In this case, the persistence can be guaranteed, but the user waits for the disk recording to be completed, which causes a problem of slowing down the transaction processing speed of the DB server.

FIG. 2 is a general view of a conceptual diagram of a conventional DB server 200 modifying and processing a transaction processing method. When the DB service means 211 requests a user to commit (2a), the DB log buffer is used. Write a commit log at 211 (2c) and immediately send a completion message to the user (2d). Thereafter, the DB log matching means 216 reads the DB log buffer 213 periodically or when the DB log buffer 213 is full (2e) and writes the log to the DB log file 215 (2f). At this time, if necessary, the pages in the DB memory buffer 212 are written to the DB file 214 (2g). In this case, the user does not wait for the DB log to actually be written to the DB log file, which speeds up transaction processing. However, the DB log, which is not written to the DB log file and only exists in the DB log buffer, is at risk of being lost if a system error occurs. There is a problem that can not guarantee the sustainability.

The technical problem to be achieved by the present invention is to provide a real-time remote logging method of a database system to improve the transaction processing performance and at the same time to solve the above problems.

Another object of the present invention is to provide a DB state recovery method using a remote DB log that safely recovers the DB state even when a system error occurs and restarts the DB server.

According to the present invention for solving the above technical problem, a real-time remote logging method of a database system includes a service host including a DB server and a local DB agent D-AGENT and a remote D-AGENT that is a DB agent in a remote area. A method of recording a DB log by a DB server in a system configured with one or more remote logging hosts, the method comprising: (a) After the DB server operates as a process on the service host, processes a user's request and records a local DB log. Checking the persistence condition when performing a commit operation, delaying the completion of the commit process until the condition is satisfied, and recording the local DB log and commit transaction completion; (b) While the local D-AGENT operates as a separate process on the service host, periodically checks the local DB log buffer, reads new local DB logs, and transmits them to the remote logging host server. Setting a persistence condition by receiving; And (c) recording the remote DB log received from the local D-AGENT into a remote DB log buffer and a remote DB log file while the remote D-AGENT operates as a process at a remote logging host, and records the last LSN in the local D- AGENT. And transmitting to the AGENT.

At this time, the commit transaction completion check in the step (a), (a1) receiving a user request to start a transaction; (a2) allocating an LSN to a local DB log corresponding to the transaction and recording the local DB log in a local DB log buffer; (a3) determining a type of operation to transmit a success message to the user if it is not a commit, and checking a persistence condition by comparing a commit LSN with a D-LSN stored in D-INFO, which is a shared memory, if the commit is performed; (a4) If the commit LSN is less than or equal to the D-LSN, it is determined that the transaction has secured the persistence, and a success message is returned to the user. If the commit LSN is greater than the D-LSN, the transaction has not yet secured the persistence. Determining to wait and periodically checking again; And (a5) periodically storing the local DB log of the local DB log buffer as a local DB log file and recording the matching log in the local DB log buffer.

In this case, the D-INFO is a shared memory for storing information including the D-LSN which determines that the DB log is continuously stored on the disk, and the D-LSN is transmitted to the most recent matching LSN or the remote logging host. It is preferable to store the final LSN.

The step (b) may include: (b1) periodically monitoring the area DB log buffer and reading a corresponding area DB log and transmitting it to the remote D-AGENT when there is a new area DB log; (b2) inspecting the message received from the remote D-AGENT and, if the check succeeds, setting the last LSN value received as the D-LSN value; And (b3) if a successful message is not received for a predetermined time due to a check failure or a failure in the remote logging host, finding a recent match log in the local DB log buffer and setting the corresponding LSN to the D-LSN value. It is preferable to include.

In step (c), (c1) storing the remote DB log received from the local D-AGENT in a remote DB log buffer and transmitting a success message including the LSN of the last remote DB log stored to the local D-AGENT. step; And (c2) periodically or when the remote DB log buffer is full, recording the remote DB log of the remote DB log buffer to a remote DB log file.

The DB state recovery method using a remote DB log according to the present invention for solving the above another technical problem, the service host including the DB server and the local DB agent D-AGENT and the remote D- DB agent in the remote region A method for recovering a database by restarting the DB server due to a system error in a system configured as a remote logging host including AGENT, the method comprising: (a) finding the last matching log stored in a local DB log file and searching for the LSN. Requesting the required remote DB log by transmitting to the local D-AGENT as a reference LSN, and recording the received remote DB log in the local DB log file to recover the DB state through UNDO / REDO; (b) the local D-AGENT sending a reference LSN to the remote D-AGENT by request of the DB server to request a necessary remote DB log, and transmitting the received remote DB log to the DB server; And (c) a remote DB log that meets a predetermined criterion among the remote DB log buffer and the remote DB log stored in the remote DB log file based on the reference LSN received by the remote D-AGENT by the request of the local D-AGENT. And transmitting a DB log to the local D-AGENT.

At this time, the step (a), (a1) finding the last local DB log file to obtain the LSN of the last matching log; (a2) transmitting the acquired LSN as a reference LSN to the local D-AGENT and requesting a required remote DB log; (a3) recording the remote DB log received from the local D-AGENT in the local DB log file; And (a4) recovering a DB state by a predetermined DB recovery means through an UNDO / REDO process based on the local DB log file.

And (b) step (b1) transmitting the reference LSN received from the DB recovery means to a remote D-AGENT and requesting the required remote DB log; And (b2) transmitting the remote DB log received from the remote D-AGENT to the DB recovery means. The step (c) may include (c1) received from the local D-AGENT. Retrieving a remote DB log larger than a reference LSN from a remote DB log buffer and a remote DB log file; And (c2) transmitting the retrieved remote DB logs to the local D-AGENT.

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

3 is a block diagram illustrating an example of a configuration for executing a remote logging and recovery method according to the present invention. This configuration includes one or more remote logging including a service host 300 including a DB server 310 and a D-AGENT 320 as a local DB agent and a remote D-AGENT 410 as a DB agent in a remote area. It is a system composed of a host (400). In short, a computer system in which a DB server is operated and a computer system in which a corresponding D-AGENT is operated are connected to a network.

The user 100 accesses the service host 300 to process a task. The service host 300 operates the DB server 310 and the local D-AGENT 320 and interacts with the remote D-AGENT 410 operating in the remote logging host 400 connected to the network. The local D-AGENT 320 transmits the DB log recorded by the DB server 310 to the remote D-AGENT 410, and each remote D-AGENT 410 records the remote DB log received in its own storage. .

In this configuration, more than one remote logging host can be operated, and if one remote logging host fails, the local D-AGENT can continue remote logging by selecting the next remote logging host from the list of remote logging hosts. . That is, it has the effect of increasing the availability and stability through the configuration of multiple remote logging host.

4 illustrates a configuration for explaining a remote logging method according to the present invention.

In FIG. 4, the user 100 requests transaction processing from the DB server 310 operating in the service host 300 (4a). The DB service means 311 changes the record in the DB memory buffer 312 (4b) and records the local DB log in the local DB log buffer 313. At this time, the DB service means 311 immediately returns the result to the user if the user request is not a commit (4k), and if the commit is to compare the D-LSN value of the D-INFO 230 with its own LSN, and the D-LSN If the value is small, it waits (4d). The D-INFO 230 is a shared memory in which the DB server 310 and the local D-AGENT 320 exchange data.

After that, the DB service means 311 periodically performs a comparison and if the D-LSN value is large, complete the transaction and return the result to the user (4k). When the local D-AGENT 320 starts execution, it connects with the remote D-AGENT 410 operating in the logging host 400, and then checks the local DB log buffer 313 to generate a new local DB log. Read (4e) and transmit to remote D-AGENT 410 (4f).

The remote D-AGENT 410 records the received DB log in the remote DB log buffer 420 and returns the LSN of the last remote DB log stored in the local D-AGENT 320 (4h). The local D-AGENT 320 stores the received LSN in the D-INFO 230 (4i).

Meanwhile, the DB log matching means 316, which provides a function of matching the logs of the DB, periodically reads the local DB logs in the local DB log buffer 313 (4l) and records them in the local DB log file 315 (4l). 4m) The matching LSN is recorded in the local DB log buffer 313 (4n).

In this process, the pages in the DB memory buffer 312 are written to the DB file 314 if necessary (4o), and the remote D-AGENT 410 periodically reads the remote DB log buffer 420 to read the remote DB log file ( Record the remote DB log at 430 (4p).

If this communication process fails, the local D-AGENT 320 finds the most recent matching LSN (4e) and stores it in the D-INFO 230 (4i). Through this, even in a situation where remote logging is impossible, the DB server 310 guarantees persistence by completing the processing of only transactions having an LSN smaller than the matching LSN. Under normal circumstances, only transactions with LSNs smaller than the D-LSN whose logging is completed on the logging host can be processed to ensure persistence.

Figure 5 shows a configuration for a more detailed illustration of a remote logging method according to the present invention.

In FIG. 5, in a situation where a local DB log having an LSN of up to 100 is stored in the local DB log buffer 313, the user 1 (100) executes insert, update, and commit operations in a new transaction, and then executes the local D−. The AGENT 320 reads the local DB log buffer 313, and after some time elapses, the user 2 100 starts a new transaction and executes a delete operation and a commit operation in this order. At this time, user 1 (100) waits for the D-INFO (230) value to be 103 or greater than its commit LSN value after performing the commit operation (5i), and user 2 (100) also performs the commit operation. After that, it waits for the D-INFO 230 value to be 105 or more greater than its commit LSN value (5o).

The local DB log file 315 stores the local DB log having the LSN between 90 and 100 as a result of the previous DB log match (5a), and the LSN is sequentially 101, 102 in the local DB log buffer 313. The new local DB log of 103 is stored (5b). The local D-AGENT 320 reads a new local DB log from the local DB log buffer 313 (5c) and transmits new local DB logins 101, 102, and 103 to the remote D-AGENT 410 (5e).

The remote D-AGENT 410 stores the received remote DB logins 101, 102, and 103 in the remote DB log buffer 420 (5f), and returns 103, the last LSN value (5g). The local D-AGENT 320 stores the last LSN value 103 as the D-LSN value in the D-INFO 230 (5h). During this process, a new local DB log with LSN 104 and 105 is stored in the local DB log buffer 313 by a transaction executed by user 2 (100) (5d). At this point, since the D-LSN value is 103 and the commit LSN of user 1 (100) satisfies the condition as 103, the transaction of user 1 (100) is completed.

On the other hand, since the commit LSN of the user 2 (100) is 105, the user 2 (100) starts to wait again because the condition is not satisfied (5o). Again, the local D-AGENT 320 reads the local DB log buffer 313 (5j) and sends new local DB logins 104 and 105 to the remote D-AGENT 410 (5k). The remote D-AGENT 410 stores the received remote DB logins 104 and 105 in the remote DB log buffer 420 (5l) and returns 105, the last LSN value. The local D-AGENT 320 stores the last LSN value 105 as the D-LSN value in the D-INFO 230 (5n). Since the D-LSN value is equal to 105, which is the commit LSN of the waiting user 2 100, the condition is satisfied and the transaction of the user 2 100 is completed.

Meanwhile, the remote D-AGENT 410 reads from the remote DB log buffer 420 and stores it in the remote DB log file 430 in order to safely manage the received remote DB log (5p).

6 is a block diagram illustrating a recovery method using remote logging according to the present invention.

In FIG. 6, a DB server 310 operating in a service host 300, a local D-AGENT 320, and a remote D-AGENT 410 operating in a remote logging host 400 cooperate with each other in a system error situation. Provide a recovery method.

The DB recovery means 317 is responsible for the DB recovery function as a module of the DB server 310. If a recovery process is needed, the DB recovery means 317 reads the last local DB log file 315 (6a), obtains the last matched LSN, and uses the LSN value as the reference LSN to the local D-AGENT 320. 6b through a normal communication method.

Local D-AGENT 320 sends a reference LSN value to remote D-AGENT 410 (6c) and waits for reception. The remote D-AGENT 410 reads the remote DB log having all LSNs greater than the received reference LSN value from the remote DB log file 430 and the remote DB log buffer 420 (6d, 6e), and the local D-AGENT. (6f). The local D-AGENT 320 transmits the received remote DB log to the DB recovery means 317 through a communication method (6g), and the DB recovery means 317 sends the received remote DB log to the local DB log buffer 313. (6h), and then to the local DB log file 315. At this time, if necessary, a new local DB log file 318 is generated and recorded (6i).

Thereafter, the DB recovery means 317 performs the UNDO / REDO process in the same manner as the conventional method (6j), recovers the DB state, and records the completed state in the DB file 314 (6k). ).

7 shows a configuration for a more detailed example of a recovery method utilizing remote logging according to the present invention.

In FIG. 7, the service host 300 stores up to a DB log having an LSN value of 100 in the DB log file 315, and a log having an LSN value of 90 to 102 in the remote logging host 400 is a remote DB log file. At 430, the DB logs 103, 104, 105 are stored in the remote DB log buffer 420.

First, the DB recovery means 317 reads the local DB log from the last local DB log file 315 and copies it to the local DB log buffer 313 (7a), finds the last match log, and converts the LSN value to the local D-AGENT ( In step 320, the LSN value 100 is transmitted (step 7b). The local D-AGENT 320 sends the received LSN value to the remote D-AGENT 410 and waits for reception (7c).

The remote D-AGENT 410 finds a remote DB log having a large value by comparing the received LSN value 100 with the LSN value of each remote DB log stored in the remote DB log file 430 and the remote DB log buffer 420 ( 7d, 7e), the remote DB logins 101, 102, 103, 104, and 105 satisfying the condition are transmitted to the local D-AGENT 320 (7f). The local D-AGENT 320 transmits the remote DB log to the DB recovery means 317 through a communication method (7g).

The DB recovery means 317 records the remote DB log in the local DB log buffer 313 (7h) and stores the remote DB log in the local DB log file 315. At this time, if necessary, a new local DB log file 318 is generated and stored (7i).

When the above processes are completed, all necessary DB logs are stored in the service host 300, and the DB recovery means 317 recovers the DB state using the DB logs.

8A to 8E illustrate a flow of a remote logging operation method according to the present invention.

In Fig. 8A, the DB service means 311, which is a module of the DB server 310, receives a request of the connected user 100 (step S101). In step S102, a local DB log necessary for transaction processing is generated and an LSN is assigned to the local DB log (step S103). In step S104, the local DB log is recorded in the local DB log buffer 313, and it is checked whether the operation processed by the user 100 request is a commit (step S105).

If it is determined in step S105 that the test result is a failure, a success message is returned to the user 100 (step S109). If it is determined in step S105 that the check result is successful, that is, commit, the LSN value of the commit log is set in the C-LSN variable value (step S106), and the C-LSN is read by reading the D-LSN value stored in the D-INFO 230. The value is compared (step S107). If the check fails in step S107, since the corresponding log has not been stored yet, the step S107 is repeated after a period of rest (step S110). If the check succeeds in step S107, since the corresponding log is stored, a success message is returned to the user (step S108) and the transaction processing ends.

In FIG. 8B, the DB log matching means 316, which is a module of the DB server 310, periodically monitors the local DB log buffer 313 (step S201) and checks whether there is a new local DB log (step S202). . If the check fails in step S202, complete the cycle. If the check succeeds in step S202, a new local DB log is recorded in the local DB log file 315 (step S203). This process is repeated while there is a new local DB log in the local DB log buffer 313 (step S204).

If there is no new local DB log at step S204, a match log (S-LOG) is generated and an LSN is assigned to indicate that the matching process is completed (step S205). The generated match log is recorded in the local DB log buffer 313 (step S206), and the corresponding periodic task is completed.

8C to 8D, the area D-AGENT 320 periodically monitors the area DB log buffer 313 (step S301), and checks whether there is a new area DB log (step S302).

If the check fails in step S302, complete the cycle work. If the check succeeds in step S302, a new local DB log is added to the transmission log list (step S303), and it is checked whether the DB log matches the login log (step S304).

If the check succeeds in step S304, the latest S-LSN variable value is set to the LSN value of the match log (step S310). If the check fails in step S304, check again whether there is a new log, and if successful, repeat step S303 (step S305).

If the check fails in step S305, it is checked whether communication with the host of the current D-HOST variable value is connected (step S306). If it succeeds in step S306, the transmission log list is transmitted to the remote D-AGENT 410 (step S307), and waits for reception from the remote D-AGENT 410.

It is checked whether the last LSN value has been received (step S308). If the reception is successful, the D-LSN of the D-INFO 230 is set to the received LSN value (step S309), and the cycle operation is terminated. If the check in step S306 or S308 fails, it is checked whether there is another remote logging host (D-HOST) in the D-HOST list (step S311).

If the check fails in step S311, that is, the remote logging is no longer possible if there is no other D-HOST capable of communication, the local logging is performed only by setting the D-LSN value to the S-LSN value (step S315). After that, the point is reset to the first host in the list in order to attempt communication from the beginning of the D-HOST list (step S316).

If the check succeeds in step S311, it attempts to connect to the corresponding D-HOST (step S312), and checks whether the connection is successful (step S313). If the check fails in step S313, the D-LSN value is set to the S-LSN value (step S317), and step S311 is performed again. If the check succeeds in step S313, the current D-HOST variable is changed to the D-HOST (step S314) and the cycle ends.

In FIG. 8E, when the remote D-AGENT 410 connects with the local D-AGENT 320 and receives a message (step S401), the remote D-AGENT 410 reads the message header and checks whether it is a log transmission protocol (step S402). If the check fails in step S402, the corresponding processing ends and waits for reception again. If the check succeeds in step S402, the DB log list is received (step S403) and stored in the remote DB log buffer 420 (step S404). Obtain the last LSN value from the DB log list (step S405), send it to the local D-AGENT 320 (step S406), save the list in a remote DB log file (step S407), and then finish the receiving operation. And wait for reception again.

9a to 9c illustrate the flow of a recovery method utilizing remote logging according to the present invention.

In FIG. 9A, it is determined whether a DB recovery process is required in the process of restarting the DB server 310 due to a system error (step S501). If the check fails in step S501, the DB recovery process ends, and if the check succeeds, the DB recovery means 317 opens the last local DB log file 315 (step S502).

The last matching log S-LOG is retrieved from the local DB log file 315 (step S503) to obtain an LSN of the corresponding log (step S504). The acquired LSN is transmitted to the local D-AGENT 320 through a communication means and waits for a message (step S505). When the local D-AGNET 320 sends the DB log list larger than the LSN (step S506), the DB log list is written to the local DB log buffer 313 and stored in the local DB log file 315. (Step S507). The DB state is recovered by performing UNDO / REDO as in the conventional method (step S508).

In Fig. 9B, the local D-AGENT 320 receives a message sent by the DB recovery means 317 (step S601). The message header is examined to see if it is a DB log request message (step S602), and if the check fails, the process ends. If the check succeeds in step S602, the LSN is obtained from the received message (step S603).

The LSN is sent to each D-HOST in the D-HOST list (step S604), and a DB log list is received from each D-HOST (step S605). The received DB log list is sorted based on the LSN (step S606), the sorted DB log list is transmitted to the DB recovery means 317 (S607), and the operation ends.

In FIG. 9C, the remote D-AGENT 410 receives a message from the local D-AGENT 320 (step S701) and checks whether it is a DB log request protocol (step S702). If the check fails in step S702, the process is terminated, and if successful, the LSN is obtained from the message and the LSN value is used as the reference LSN (step S703).

A combination list is created by combining the remote DB log file 430 and the remote DB log stored in the remote DB log buffer 420 (step S704). The remote DB log is read from the combined list (step S705), and it is checked whether the LSN of the remote DB log is larger than the reference LSN (step S706).

If the check succeeds in step S706, the remote DB log is added to the DB log list (step S709). Check if the join list is empty, that is, the last login (step S707), or perform step S705 again. If the inspection is successful in step S707, all necessary remote DB logs are collected, and the DB log list is transmitted to the local D-AGENT 320 (step S708), and the process ends.

By modifying the method of recording the DB log to the DB log file and returning the result to the user through the above process, when the user executes the commit command, instead of waiting for the DB log to be completely written to the DB log file in the conventional manner In addition, transaction processing performance can be improved by transmitting DB logs to a separate remote logging host and waiting only for the time for receiving a response. At the same time, it provides a way to improve the persistence by replicating and storing DB logs on a separate remote logging host.In case of restarting the DB server due to a system error, the DB status is combined by combining the local DB log file and the remote DB log file. Provides the ability to safely recover.

Those skilled in the art will appreciate that the present invention can be implemented in a modified form without departing from the essential features of the present invention. Therefore, the disclosed embodiments should be considered in descriptive sense only and not for purposes of limitation. Examples included in the above description are introduced for the understanding of the present invention, and these examples do not limit the spirit and scope of the present invention. It will be apparent to those skilled in the art that various embodiments in accordance with the present invention in addition to the above examples are possible. The scope of the present invention is shown not in the above description but in the claims, and all differences within the scope will be construed as being included in the present invention.

In addition, it can be easily understood by those skilled in the art that each of the above steps according to the present invention can be variously implemented in software or hardware using a general programming technique.

And some steps of the invention may also be embodied as computer readable code on a computer readable recording medium. The computer-readable recording medium includes all kinds of recording devices in which data that can be read by a computer system is stored. Examples of computer-readable recording media include ROM, RAM, CD-ROM, CD-RW, magnetic tape, floppy disks, HDDs, optical disks, magneto-optical storage devices, and carrier wave (eg, Internet It also includes the implementation in the form of). The computer readable recording medium can also be distributed over network coupled computer systems so that the computer readable code is stored and executed in a distributed fashion.

According to the present invention, after the DB server operates as a process in the service host, processes the user's request, records the local DB log, checks the persistence condition when performing the commit operation, and delays the completion of the commit process until the condition is met. Local D-AGENT operates as a separate process on the service host and periodically checks the local DB log buffer, reads the new local DB log, sends it to the remote logging host server, and receives the LSN that succeeded in recording. Remote D-AGENT operates as a process on the remote logging host, and records the remote DB log received from the local D-AGENT to the remote DB log buffer and the remote DB log file, and sends the last LSN to the local D-AGENT. When the user executes the commit command, the DB log is completely written to the DB log file in the conventional manner. Instead of legs, it can be completely transferred to the DB log on a separate remote logging host, and by waiting only for the recipient to improve the response time transaction processing performance. In addition, by providing a method of transmitting and recording the remote DB log to a separate remote logging host while recording in the local DB log file, when the DB server is restarted due to a system error, the DB log of the conventional method is lost. By solving the problem, the persistence characteristics of the DB server can be strengthened. And by providing a method to effectively combine local DB log and remote DB log, DB status can be completely recovered, and by providing a method of operating by configuring a number of remote logging hosts, it increases the availability and stability against system failure Can be further improved.

1 is a conceptual diagram of a conventional transaction processing and logging.

2 is a conceptual diagram of a conventional modified transaction processing and logging.

3 is a block diagram showing a configuration for executing a remote logging and recovery method according to the present invention.

4 illustrates a configuration for explaining a remote logging method according to the present invention.

Figure 5 shows a configuration for a more detailed illustration of a remote logging method according to the present invention.

6 is a block diagram illustrating a recovery method using remote logging according to the present invention.

7 shows a configuration for a more detailed example of a recovery method utilizing remote logging according to the present invention.

8A to 8E illustrate a flow of a remote logging operation method according to the present invention.

9a to 9c illustrate the flow of a recovery method utilizing remote logging according to the present invention.

Claims (9)

The DB server records DB logs in a system composed of a DB server, a service host including D-AGENT, a local DB agent, and one or more remote logging hosts, including a remote D-AGENT, a DB agent in a remote area. In (a) After the DB server operates as a process on the service host, processes the user's request, records the local DB log, checks the persistence condition when performing a commit operation, and completes the commit process until the condition is met. Checking local DB log and commit transaction completion processing the transaction by delay; (b) While the local D-AGENT operates as a separate process on the service host, periodically checks the local DB log buffer, reads new local DB logs, and transmits them to the remote logging host server. Setting a persistence condition by receiving; And (c) The remote D-AGENT operates as a process in the remote logging host, and records the remote DB log received from the local D-AGENT in the remote DB log buffer and the remote DB log file, and records the last LSN in the local D-AGENT. Transmitting to the real-time remote logging method of a database system comprising a. The method of claim 1, wherein the commit transaction completion check in the step (a), (a1) initiating a transaction upon request of a user; (a2) allocating an LSN to a local DB log corresponding to the transaction and recording the local DB log in a local DB log buffer; (a3) determining a type of operation to transmit a success message to the user if it is not a commit, and checking a persistence condition by comparing a commit LSN with a D-LSN stored in D-INFO, which is a shared memory, if the commit is performed; (a4) If the commit LSN is less than or equal to the D-LSN, it is determined that the transaction has secured the persistence, and a success message is returned to the user. If the commit LSN is greater than the D-LSN, the transaction has not yet secured the persistence. Determining to wait and periodically checking again; And (a5) periodically storing the local DB log of the local DB log buffer as a local DB log file and recording the matching log in the local DB log buffer. The method of claim 2, The D-INFO is a shared memory for storing information including the D-LSN which determines that a DB log is continuously stored on a disk, and the D-LSN is a most recent matching LSN or a final LSN transmitted to the remote logging host. Real time remote logging method of the database system, characterized in that for storing. According to claim 1, wherein step (b), (b1) periodically monitoring the local DB log buffer and reading a corresponding local DB log and transmitting the new local DB log to the remote D-AGENT; (b2) inspecting the message received from the remote D-AGENT and, if the check succeeds, setting the last LSN value received as the D-LSN value; And (b3) if a successful message is not received for a predetermined time due to a check failure or a failure in the remote logging host, finding a recent match log in the local DB log buffer and setting a corresponding LSN as the D-LSN value; Real time remote logging method of the database system, characterized in that. The method of claim 1, wherein step (c) comprises: (c1) storing the remote DB log received from the local D-AGENT in a remote DB log buffer and transmitting a success message including the LSN of the last stored remote DB log to the local D-AGENT; And (c2) periodically or when the remote DB log buffer is full, recording the remote DB log of the remote DB log buffer to a remote DB log file. Recover the DB by restarting the DB server due to a system error in a system composed of a DB server, a service host including D-AGENT, a local DB agent, and a remote logging host including remote D-AGENT, a DB agent in a remote area. In the way, (a) The DB server finds the last matching log stored in the local DB log file and sends the local D-AGENT to the local D-AGENT using the LSN as the reference LSN to request the necessary remote DB log, and sends the received remote DB log to the local DB log file. Restoring the DB state through the UNDO / REDO process by writing to the; (b) the local D-AGENT sending a reference LSN to the remote D-AGENT by request of the DB server to request a necessary remote DB log, and transmitting the received remote DB log to the DB server; And (c) a remote DB that meets a predetermined criterion among the remote DB log buffer and the remote DB log stored in the remote DB log file based on the reference LSN received by the remote D-AGENT by the request of the local D-AGENT; Transmitting a log to the local D-AGENT; DB status recovery method using a remote DB log, comprising the. According to claim 6, wherein step (a), (a1) finding the last local DB log file to obtain the LSN of the last matching log; (a2) transmitting the acquired LSN as a reference LSN to the local D-AGENT and requesting a required remote DB log; (a3) recording the remote DB log received from the local D-AGENT in the local DB log file; And (a4) recovering a DB state by a predetermined DB recovery means through a UNDO / REDO process based on the local DB log file; and a DB state recovery method using a remote DB log. According to claim 6, wherein step (b), (b1) transmitting a reference LSN received from the DB recovery means to a remote D-AGENT and requesting a required remote DB log; And (b2) transmitting the remote DB log received from the remote D-AGENT to the DB recovery means; DB state recovery method using a remote DB log, comprising the. The method of claim 6, wherein step (c) comprises: (c1) retrieving a remote DB log larger than a reference LSN received from the local D-AGENT in a remote DB log buffer and a remote DB log file; And (c2) transmitting the retrieved remote DB log to the local D-AGENT; and recovering the DB state using the remote DB log.