JP2011076487A - Computer and database management program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To construct a multiplex database control system having a simple configuration on the assumption of an inexpensive hardware configuration using no shared disk devices. <P>SOLUTION: A node 2 holds a redo logs 120 for node as update information of a database held in the node 2 and redo logs 130 for the other nodes as update information of databases other than the database held in the node 2 for each database. When the node 2 updates the redo log 120 for node, the node 2 refers to redo logs 130 for the other nodes to determine whether contention occurs between updating of the database held in the node 2 and updating of databases other than the database held in the node 2. <P>COPYRIGHT: (C)2011,JPO&INPIT

Description

  The present invention relates to a computer including at least one of multiplexed databases and a database management program.

A conventional multiplexed database has a DB file for storing the data itself in each node and a redo log for sequentially writing update history information.
As shown in FIG. 11 (a), the multiplexed database duplicates nodes in order to improve the availability of the database. One method of duplexing nodes is to use a distributed transaction function.

  In this method, when updating, the client issues an update request with the same contents to both nodes, and the consistency of the contents of the DB file between both nodes is ensured by the two-phase commit method. That is, in this method, at the time of a commit request, a commit preparation instruction is given to both nodes, and after a preparation completion response is obtained from both nodes, a commit instruction is issued to both nodes. Details of the method using the distributed transaction function are described in Patent Document 1, for example.

  As another method, there is a duplex method using a shared disk. As shown in FIG. 11B, the database is duplicated by storing the redo log and the DB file in the shared disk and connecting to both nodes. One redo log is prepared for each node, but the DB files share the same physical file. Details of the method using the shared disk are described in Non-Patent Document 1, for example.

  In this method, since one DB is shared to configure a DB, an operation executed on one node is immediately reflected on another node.

JP-A-6-119227 (paragraphs 0002 to 0006, FIG. 2 etc.)

Barb Lundhild, Peter Sechser, “Oracle RAC 10g”, [online], September 2005, Oracle Corporation, [searched September 16, 2009], Internet <URL: http://otndnld.oracle.co.jp /products/database/oracle10g/clustering/pdf/TWP_RAC10g.pdf>

As described above, in the database multiplexing method using the distributed transaction function, if there is contention for the update operation, a wait occurs at that time, and if a failure occurs during the commit operation, the lock is automatically released. There is a problem that control is complicated and control is complicated.
In addition, in the database multiplexing method using the shared disk device, the shared disk device is expensive, and there is a drawback that it is not possible to arrange both nodes geographically dispersed.

  The present invention has been made in view of the above problems, and provides a computer and a database management program capable of determining competition in database update even when the database is geographically dispersed. With the goal.

  In order to achieve the above object, a computer according to the present invention is a computer comprising at least one of a plurality of databases connected in a communicable manner to a plurality of databases having the same contents, the database held by itself. A self-update information and a storage unit that holds other update information of databases other than the database held by the database separately for each database, and refers to the other update information when updating the self-update information And a contention determination unit for determining contention in the update of the multiplexed database.

  In order to achieve the above object, a database management program according to the present invention is a database that is executed by a computer control apparatus including at least one of a plurality of databases that are connected to be communicably connected to a plurality of databases having the same contents. A management program, the function of causing the storage unit to store the self-update information of the database held by the own computer and other update information of the database other than the database held by the self for each database; When the self-information is updated, the control device is configured to refer to the other update information to determine a conflict in updating the multiplexed database.

  According to the present invention, it is possible to determine a conflict in updating a database even when the database is geographically dispersed. Therefore, on the premise of an inexpensive hardware configuration that does not use a shared disk device, the configuration can be made simpler than a database control system using a distributed transaction method.

1 is a configuration diagram of a database control system according to a first embodiment of the present invention. It is a functional block diagram of the node which comprises the database control system which concerns on 1st Embodiment of this invention. It is a figure which shows an example of the redo log with which the node which concerns on 1st Embodiment of this invention is provided. It is a figure which shows an example of the redo log information which the node which concerns on 1st Embodiment of this invention transmits mutually. It is operation | movement explanatory drawing explaining the database update operation | movement (no conflict of update data) of the database control system which concerns on 1st Embodiment of this invention. It is a figure which shows the state of the redo log after each step of the database update operation | movement (no conflict of update data) of the database control system which concerns on 1st Embodiment of this invention. It is a figure which shows the state of the redo log after each step of the database update operation | movement (no conflict of update data) of the database control system which concerns on 1st Embodiment of this invention. It is operation | movement explanatory drawing explaining the database update operation | movement (with competition of update data) of the database control system which concerns on 1st Embodiment of this invention. It is a figure which shows the state of the redo log after each step of the database update operation | movement (with conflict of update data) of the database control system which concerns on 1st Embodiment of this invention. It is a functional block diagram of the node which comprises the database control system which concerns on 2nd Embodiment of this invention. It is operation | movement explanatory drawing explaining the database update operation | movement (with competition of update data) of the database control system which concerns on 2nd Embodiment of this invention. It is a block diagram which shows the conventional component (distributed transaction) and (b) the conventional component (shared disk).

<< Configuration of Database Control System According to First Embodiment >>
<Overview>
FIG. 1 is a configuration diagram of a database control system according to the first embodiment.
The database control system 1 includes nodes 2A, 2B (hereinafter sometimes collectively referred to as node 2), clients 8A, 8B,... 8X (hereinafter sometimes collectively referred to as client 8), and network 9 It is prepared for. The database control system 1 includes databases (DB) 220A and 220B stored in storage devices 200A and 200B (hereinafter sometimes collectively referred to as storage devices 200) provided in the node 2 by the client 8 via the network 9. (Hereinafter sometimes referred to collectively as the database (DB) 220) is updated. The database 220 is updated using the redo logs 120 and 130 (see FIG. 2) stored in the control device 100. Details of the update processing of the database 220 will be described later.

  Here, the database 220A and the database 220B have the same contents. In the database control system 1, when updating the database 220, the client 8 accesses either the node 2A or the node 2B and updates one of the databases 220A or 220B. One node 2 provided with the updated database 220 transmits update information to the other node 2, and the other node 2 that has received the update information updates its own database 220 based on the received update information. As described above, in the database control system 1 according to the first embodiment, the nodes 2 transmit update information of their own databases 220 to each other so that the contents of the databases 220 are identical.

  The database control system 1 shown in FIG. 1 has a configuration in which the database 220 is duplicated. However, the database 220 may be configured in a triple, quadruple or more multiplex by connecting a larger number of nodes 2. . In that case, the node 2 including the updated database 220 transmits the update information of its own database 220 to all the nodes 2 including the multiplexed database 220.

Further, the database control system 1 connects the node 2A to a certain local network, connects the node 2B to a local network different from the local network to which the node 2A belongs, and connects each local network to the global network. Good. With such a configuration, the node 2 can be installed in a geographically separated place.
Hereinafter, each component apparatus of the database control system 1 will be described.

<Node>
The node 2 is a disk device that is connected to a network and includes a database. For example, it is a broad concept including a server that performs processing of a data access layer in a client server system of a three-tier architecture, a host computer in a centralized processing system, and the like.
The configuration of the node 2 differs depending on the type of device, but in the case of a server in a client server system, for example, it is composed of a control device 100, a storage device 200, an input device 3, a display device 4, a communication device 5, and a timer 6. The

(Control device)
The control device 100 includes a CPU, a memory (storage unit), and peripheral circuits thereof (not shown). The control device 100 loads and executes a DBMS (DataBase Management System) 210 and an OS (Operating System) 230 stored in the storage device 200 to execute various functions. Realize. Functions provided in the control device 100 will be described later.

(Storage device)
The storage device 200 is configured by an HDD (Hard Disk Drive) or the like, and stores DBMS 210, DB 220, and OS 230. The DBMS 210 is software for controlling and utilizing information stored as a database. The DB 220 is data stored in the storage device 200 under the management of the DBMS 210. The OS 230 is software that manages the computer system of the node 2 and provides a basic user operation environment.
The DB 220 is composed of a plurality of files. The files that make up the DB 220 will be described later.

(Input device, display device, communication device, timer)
The input device 3 includes operation input devices such as a keyboard and a mouse, receives an input operation of the operator of the node 2, and outputs it to the control device 100.
The display device 4 is an LCD, a CRT, or the like, and displays an output image or the like delivered from the control device 100.
The communication device 5 is a LAN adapter device, an ISDN communication line TA, or a modem, and operates according to instructions from the control device 100 to transmit / receive data to / from the node 2 or the client 8 via the network 9. .
The timer 6 is a clock of the node 2, and is composed of an RTC (Real Time Clock) or the like. The timer 6 provides time to the control device 100 as data.

<Client>
The client 8 is a device that requests an update of the DB 220 included in the node 2 via the network 9. The client 8 is composed of a PC (Personal Computer), a portable terminal, or the like.

<Network>
The network 9 is a LAN (Local Area Network), a WAN (Wide Area Network), or the like, and is configured by one or both of wired and wireless, and realizes data communication.
Examples of the cable include an optical fiber, a general telephone line, a dedicated line, and the like, and examples of the wireless include radio waves such as infrared rays.

<< Functions of nodes constituting the database control system according to the first embodiment and formats used >>
<Functions of the node>
(Overview)
FIG. 2 is a functional configuration diagram of nodes constituting the database control system according to the first embodiment. In FIG. 2, each function is described as “XX section”.
The node 2 has the functions shown in FIG. 2 in order to realize the database control system 1 according to the first embodiment. Each unit 110, 111, 112, 113, 114 described in FIG. 2 is realized by loading the DBMS 210 into a memory and being executed by the CPU. The communication unit 140 is realized by loading the OS 230 into a memory and being executed by the CPU. The logs 120 and 130 are secured as areas on the memory.
For convenience of explanation, FIG. 2 does not show functions other than those necessary for explaining the database control system 1 according to the first embodiment. For example, functions for managing the input device 3, the display device 4, and the timer 6 are not shown.

(Database (DB))
The DB 220 includes three files: a redo log file 221, a control file 222, and a data file 223.
The redo log file 221 is a file that stores update information of the data file 223. The control file 222 is a file in which file names and storage locations of the redo log file 221 and the data file 223 are recorded. The data file 223 is a file containing actual data.

(Redo log)
The redo logs 120 and 130 as update information are the change history data of the DB 220, and the configuration thereof is shown in FIG. One entry of the redo logs 120 and 130 includes time stamp fields 121 and 131, transaction number fields 122 and 132, DB operation code fields 123 and 133, DB operation address fields 124 and 134, and DB operation parameter fields 125 and 135. The
Entries are added to the redo logs 120 and 130 every time processing for the DB 220 is performed.
FIG. 2 shows a configuration in which the nodes 2 are duplicated. If the nodes 2 are tripled or quadrupled, the number of redo logs included in each node 2 is the number of nodes 2. Minutes, three and four.

(Redo log update unit)
The redo log update unit 111 shown in FIG. 2 is basically a function for updating the redo logs 120 and 130.
Hereinafter, the function of the redo log update unit 111 will be described separately when a transaction occurs in its own node 2 and when a transaction occurs in another node 2.
(1) When a transaction occurs in its own node The redo log update unit 111 starts a transaction (hereinafter sometimes referred to as “Tx”), executes an update operation (update, delete, insert) of the DB 220, When a commit (result confirmation) is executed, an entry is added to the redo log 120 for the own node. Specifically, an entry in which the following contents (a) to (c) are set is added.

(A) At the start of Tx The redo log update unit 111 sets “time” in the time stamp column 121 of the redo log 120 for the own node, and sets “arbitrary Tx number” in the transaction number column 122.
(B) When executing DB update operation The redo log update unit 111 sets “time” in the time stamp column 121 of the redo log 120 for the own node, and sets “Tx number set at the start of Tx” in the transaction number column 122. And set any one of “update”, “delete”, and “insert” in the DB operation code column 123, set “address of update target record” in the DB operation address column 124, and set the DB operation parameter column 125, “DB update contents” is set.
Whether to set “update”, “delete”, or “insert” in the DB operation code field 123 depends on whether the update target record is updated, deleted, or newly added. Is done.

(C) When executing commit (result confirmation) The redo log update unit 111 sets “time” in the time stamp column 121 of the redo log 120 for the own node, and “Tx number set at the start of Tx” in the transaction number column 122. Is set, and “commit” or “rollback” is set in the DB operation code column 123.
Whether “commit” or “rollback” is set in the DB operation code field 123 is determined by “commit” when the update target conflict determination unit 112 (see FIG. 2) described later determines that there is no conflict in the update target record. ”Is set, and“ rollback ”is set when it is determined that there is a conflict in the update target record.

Also, the redo log update unit 111 creates redo log information 300 shown in FIG. 4 each time an entry is added to the redo log 120 for the own node. That is, the redo log update unit 111 creates the redo log information 300 at all timings of (a) Tx start, (b) DB update operation execution, and (c) commit execution. The configuration of the redo log information 300 is the same as the configuration of one entry of the redo logs 120 and 130. The redo log update unit 111 sets the same contents as the contents set in the same field name of the redo log 120 for the own node in each field of the redo log information 300.
The redo log update unit 111 instructs the communication unit 140 to transmit the created redo log information 300 to the other nodes 2. The communication unit 140 (see FIG. 2) packetizes the redo log information 300 in accordance with a communication protocol such as TCP (Transmission Control Protocol), IP (Internet Protocol), etc., and other nodes via the communication device 5 (see FIG. 1). 2 to send.

(2) When a transaction occurs in another node The redo log update unit 111 adds an entry to the redo log 130 for another node based on the redo log information 300 received from the other node 2. Specifically, the redo log update unit 111 sets the same content as the content stored in the same column name of the redo log information 300 in each column of the redo log 130 for other nodes, and adds an entry. As a result, the contents of the own node redo log 120 of one node 2 and the contents of the other node redo log 130 of the other node 2 are matched.

(Update conflict determination unit)
The update target conflict determination unit 112 illustrated in FIG. 2 determines whether or not an update target record conflicts between the own node 2 and another node 2 when a transaction occurs in the own node 2 and the commit is performed. Judgment is made. The update target conflict determination unit 112 determines the conflict of the update target record by examining the contents of the redo log 130 for other nodes for the time period from the start of the transaction to when the commit is performed.
Specifically, the update target conflict determination unit 112 has a DB operation address column 124 of the entry added to the redo log 120 for the own node in the time period from when the transaction is started at the own node 2 until the commit is performed. And the address set in the DB operation address column 134 of the entry added to the other node redo log 130 match, and in the other node redo log 130, the DB operation code column 133 shows “commit”. It is determined that the record to be updated has conflicted when an entry in which is set is added.

  Even if the addresses set in the DB operation address field 124 of the local node redo log 120 and the DB operation address field 134 of the other node redo log 130 match, the DB operation code is stored in the other node redo log 130. If an entry in which “commit” is set in the column 133 is not added, it is not determined that the update target record has conflicted. In this case, the update target conflict determination unit 112 of the other node 2 determines that the update target record has conflicted. In other words, when the update target record competes, the update process in which the commit is performed first is given priority.

(Redo log file update part)
The redo log file update unit 113 shown in FIG. 2 reads the contents of the local node redo log 120 when an entry in which “commit” is set in the DB operation code column 123 is added to the local node redo log 120. Write to the redo log file 221.
The redo log file update unit 113 also adds the contents of the redo log 130 for another node to the redo log 130 for another node when an entry in which “commit” is set in the DB operation code column 133 is added. Write to file 221.

(Data file update part)
The data file update unit 114 illustrated in FIG. 2 updates the contents of the redo log file 221 to the data file 223 at an arbitrary timing.

<< Database Update Operation of Database Control System According to First Embodiment >>
The database update operation of the database control system according to the first embodiment will be described below with reference to FIGS.
FIG. 5 is an explanatory diagram of a database update operation (no conflict of update data) of the database control system according to the first embodiment.
FIG. 5 shows the flow of processing when TxA is executed at the node 2A and TxB is executed at the node 2B almost simultaneously. Since TxA updates the record at address # 0001 and TxB updates the record at address # 0002, the update target record does not compete between TxA and TxB. A white arrow on the redo log 130 for other nodes represents a time zone in which the update target conflict determination unit 112 performs the conflict determination.

In the description, some descriptions of data settings of the redo logs 120 and 130 and the redo log information 300 are omitted.
In addition, after each step, the status of the redo log 120A for the node 2A and the redo log 130B for the other node of the node 2B, the redo log 120B for the own node of the node 2B, and the redo for the other node of the node 2A The state of the log 130A is shown in FIGS. 6A (a) to (c) and FIGS. 6B (a) to (c).

(Step S001A)
The redo log update unit 111A of the node 2A adds one line to the redo log 120A for the own node with the start of TxA and an entry in which “arbitrary Tx number” is set in the transaction number column 122A. Also, the redo log update unit 111A creates redo log information 300 with the same contents as the added entry, and transmits the redo log information 300 to the node 2B.
Based on the received redo log information 300, the redo log updating unit 111B of the node 2B adds one line to the redo log 130B for other nodes.

(Step S001B)
The redo log updating unit 111B of the node 2B adds one line to the local node redo log 120B with the start of TxB, in which an “arbitrary Tx number” is set in the transaction number column 122B. Also, the redo log update unit 111B creates redo log information 300 with the same content as the added entry, and transmits the redo log information 300 to the node 2A.
Based on the received redo log information 300, the redo log updating unit 111A of the node 2A adds one line to the redo log 130A for other nodes.

(Step S002A)
The redo log update unit 111A of the node 2A sets an entry in which “update” is set in the DB operation code column 123A, “0001” is set in the DB operation address column 124A, and “AAAAA” is set in the DB operation parameter column 125A. Then, one line is added to the redo log 120A for the own node. Also, the redo log update unit 111A creates redo log information 300 with the same contents as the added entry, and transmits the redo log information 300 to the node 2B.
Based on the received redo log information 300, the redo log updating unit 111B of the node 2B adds one line to the redo log 130B for other nodes.

(Step S002B)
The redo log update unit 111B of the node 2B sets an entry in which “update” is set in the DB operation code column 123B, “0002” is set in the DB operation address column 124B, and “BBBBB” is set in the DB operation parameter column 125B. Then, one line is added to the redo log 120B for the own node. Also, the redo log update unit 111B creates redo log information 300 with the same content as the added entry, and transmits the redo log information 300 to the node 2A.
Based on the received redo log information 300, the redo log updating unit 111A of the node 2A adds one line to the redo log 130A for other nodes.

(Step S003A)
When performing a commit, the update target conflict determination unit 112A of the node 2A determines whether or not the update target records have conflicted between the node 2A and the node 2B. Here, the current time is “20090101010101005”.
The update target conflict determination unit 112A refers to the time stamp column 121A of the self-node redo log 120A to grasp that the start of TxA is “20090101010101001”, and the time stamp column 131A of the redo log 130A for other nodes Entries with the date and time of “20090101010101001” to “20090101010101005” matching the values of the DB operation address field 124A of the local node redo log 120A and the DB operation address field 134A of the redo log 130A for other nodes. It is checked whether there is an entry, but it is found that there is no matching entry. Therefore, the update target conflict determination unit 112A determines that there is no conflict of update target records.

Next, the redo log update unit 111A of the node 2A determines that there is no conflict in the update target record, so an entry in which “commit” is set in the DB operation code column 123A is stored in the redo log 120A for the own node. to add. Also, the redo log update unit 111A creates redo log information 300 with the same contents as the added entry, and transmits the redo log information 300 to the node 2B. Further, the redo log file update unit 113A writes the contents of the local node redo log 120A to the redo log file 221A.
Based on the received redo log information 300, the redo log updating unit 111B of the node 2B adds one line to the redo log 130B for other nodes. Further, the redo log file update unit 113B writes the contents of the redo log for other nodes 130B to the redo log file 221B.

(Step S003B)
When performing a commit, the update target conflict determination unit 112B of the node 2B determines whether or not the update target records have conflicted between the node 2A and the node 2B. Here, the current time is “20090101010101006”.
The update target conflict determination unit 112B refers to the time stamp column 121B of the redo log 120B for the own node to grasp that the start of TxB is “20090101010101002”, and the time stamp column 131B of the redo log 130B for other nodes Entries with the date and time of “20090101010101002” to “20090101010101006” matching the values of the DB operation address field 124B of the local node redo log 120B and the DB operation address field 134B of the redo log 130B for other nodes. It is checked whether there is an entry, but it is found that there is no matching entry. Therefore, the update target conflict determination unit 112B determines that there is no update target record conflict.

Next, since the redo log update unit 111B of the node 2B has determined that there is no conflict in the update target record, an entry in which “commit” is set in the DB operation code column 123B is stored in the redo log 120B for the own node. to add. Also, the redo log update unit 111B creates redo log information 300 with the same content as the added entry, and transmits the redo log information 300 to the node 2A. Further, the redo log file update unit 113B writes the contents of the local node redo log 120B to the redo log file 221B.
Based on the received redo log information 300, the redo log updating unit 111A of the node 2A adds one line to the redo log 130A for other nodes. Further, the redo log file update unit 113A writes the contents of the redo log for other nodes 130A to the redo log file 221A.
This is the end of the description of the database update operation (no update data conflict) of the database control system 1 according to the first embodiment.

FIG. 7 is an explanatory diagram of a database update operation (with update data conflict) of the database control system according to the first embodiment.
FIG. 7 shows a process flow when TxA is executed at the node 2A and TxB is executed at the node 2B almost simultaneously. Since both TxA and TxB update the record at address # 0001, the update target records compete. A white arrow on the redo log 130 for other nodes represents a time zone in which the update target conflict determination unit 112 performs the conflict determination.

In the description, some descriptions of data settings of the redo logs 120 and 130 and the redo log information 300 are omitted.
In addition, after each step, the status of the redo log 120A for the node 2A and the redo log 130B for the other node of the node 2B, the redo log 120B for the own node of the node 2B, and the redo for the other node of the node 2A The state of the log 130A is shown in FIGS. 6A (a) to 6 (c) and FIGS. 8 (a) to 8 (c).

(Steps S001A, S001B, S002A)
Since the processing in steps S001A, S001B, and S002A is the same as the description (see FIG. 5) of the database update operation (no conflict of update data) of the database control system according to the first embodiment, the description is omitted.

(Step S002B)
The redo log update unit 111B of the node 2B sets an entry in which “update” is set in the DB operation code column 123B, “0001” is set in the DB operation address column 124B, and “BBBBB” is set in the DB operation parameter column 125B. Then, one line is added to the redo log 120B for the own node. Also, the redo log update unit 111B creates redo log information 300 with the same content as the added entry, and transmits the redo log information 300 to the node 2A.
Based on the received redo log information 300, the redo log updating unit 111A of the node 2A adds one line to the redo log 130A for other nodes.

(Step S003A)
When performing a commit, the update target conflict determination unit 112A of the node 2A determines whether or not the update target records have conflicted between the node 2A and the node 2B. Here, the current time is “20090101010101005”.
The update target conflict determination unit 112A refers to the time stamp column 121A of the self-node redo log 120A to grasp that the start of TxA is “20090101010101001”, and the time stamp column 131A of the redo log 130A for other nodes In the entry between “20090101010101001” and “20090101010101005”, the value of the DB operation address column 124A of the local node redo log 120A matches the value of the DB operation address column 134A of the redo log 130A for other nodes. It can be seen that there is an entry, but there is no entry in which “commit” is set in the DB operation code column 133A. Therefore, the update target conflict determination unit 112A determines that there is no conflict of update target records.

Next, the redo log update unit 111A of the node 2A determines that there is no conflict in the update target record, so an entry in which “commit” is set in the DB operation code column 123A is stored in the redo log 120A for the own node. to add. Also, the redo log update unit 111A creates redo log information 300 with the same contents as the added entry, and transmits the redo log information 300 to the node 2B. Further, the redo log file update unit 113A writes the contents of the local node redo log 120A to the redo log file 221A.
Based on the received redo log information 300, the redo log updating unit 111B of the node 2B adds one line to the redo log 130B for other nodes. Further, the redo log file update unit 113B writes the contents of the redo log for other nodes 130B to the redo log file 221B.

(Step S003B)
When performing a commit, the update target conflict determination unit 112B of the node 2B determines whether or not the update target records have conflicted between the node 2A and the node 2B. Here, the current time is “20090101010101006”.
The update target conflict determination unit 112B refers to the time stamp column 121B of the redo log 120B for the own node to grasp that the start of TxB is “20090101010101002”, and the time stamp column 131B of the redo log 130B for other nodes Entries in which the date and time of "20090101010101002" to "20090101010101006" match the value of the DB operation address field 124B of the local node redo log 120B and the value of the DB operation address field 134B of the redo log 130B for other nodes It can be seen that there is also an entry in which “commit” is set in the DB operation code column 133B. Therefore, the update target conflict determination unit 112B determines that there is a conflict of update target records.

Next, since the redo log update unit 111B of the node 2B has determined that there is a conflict with the update target record, an entry in which “rollback” is set in the DB operation code column 123B is added to the redo log 120B for the own node. to add. Also, the redo log update unit 111B creates redo log information 300 with the same content as the added entry, and transmits the redo log information 300 to the node 2A. Then, the node 2B stops the execution of TxB.
Based on the received redo log information 300, the redo log updating unit 111A of the node 2A adds one line to the redo log 130A for other nodes.
This is the end of the description of the database update operation (with update data conflict) of the database control system according to the first embodiment. Thus, in the database control system according to the present embodiment, no waiting occurs even if there is a conflict in the update operation.

<< Functions of nodes constituting the database control system according to the second embodiment and formats used >>
<Functions of the node>
(Overview)
In the node 2 (see FIG. 2) according to the first embodiment, as described above, when the update target record competes between the nodes 2, the one that has been committed first is given priority. When comparing the information in the redo log 120 for the own node and the redo log 130 for the other node, the time stamps of the redo logs 120 and 130 are based on the timer 6 (see FIG. 1) synchronized with each node 2. The range of the redo logs 120 and 130 to be referred to is determined using the time information written in the fields 121 and 131.

  Actually, since transmission of the redo log information 300 between the nodes 2 takes some time, it is not possible to immediately determine the conflict of the update target records when performing the commit. That is, when commit is performed on the own node, the information on the commit of the other node is not reflected in the redo log 130 for the other node included in the own node, but actually, the commit is performed on the other node. This is a case where the commit information of the other node is not reflected in the redo log 130 for the other node included in the own node due to the transmission delay of the redo log information 300. In this case, the self node cannot determine whether another node is committing at the time of commit.

Therefore, even if there is no update information, the node according to the second embodiment periodically transmits redo log information (hereinafter referred to as empty redo log information) in which data other than the time stamp field is not set to other nodes, The node that has received the empty redo log information uses the difference between the received time and the time stored in the time stamp column of the empty redo log information to determine whether or not the update target record has competed.
Here, the configuration of the database control system according to the second embodiment is the same as the database control system 1 according to the first embodiment shown in FIG.
Hereinafter, the node according to the second embodiment will be described.

FIG. 9 is a functional configuration diagram of nodes constituting the database control system according to the second embodiment. In FIG. 9, each function is described as “XX section”.
The node 2 according to the second embodiment further includes a redo log information transmission delay calculation unit 115 in addition to the function of the node 2 (see FIG. 2) according to the first embodiment. Further, the redo log update unit 111 and the update target conflict determination unit 112 have different functions. Other data configurations are the same as those in the first embodiment. This will be described below.

(Redo log update unit)
The redo log update unit 111 includes the following functions in addition to the functions of the redo log update unit 111 according to the first embodiment.
The redo log update unit 111 according to the present embodiment does not update the redo log 120 for its own node, and even if it is originally not necessary to transmit redo log information to other nodes, FIG. The time stamp field 301 shown is set to “time”, and the other fields are provided with a function of periodically transmitting empty redo log information 300 with no data set to other nodes 2.

(Redo log information transmission delay calculation unit)
When the redo log information transmission delay calculation unit 115 receives the empty redo log information 300, the redo log information transmission delay calculation unit 115 stores the time difference between the current time and the time set in the time stamp column 301 of the empty redo log information 300 in the memory. .
Here, the time difference stored in the memory is not only a simple time difference between the current time and the time set in the latest empty redo log information 300, but also the current time and a plurality of received redo log information 300. It is good also as a difference with the average value with the time set to. In addition to the above, a value considering various influences can be set for the time difference stored in the memory.

(Update conflict determination unit)
The update target conflict determination unit 112 according to the present embodiment waits for the time difference stored in the memory by the redo log information transmission delay calculation unit 115 when a transaction occurs in its own node 2 and commit is performed. Then, it is determined whether or not the record to be updated has conflicted between its own node 2 (2A) and another node 2 (2B).
In other words, the update target conflict determination unit 112 checks the contents of the update target record by examining the contents of the redo log 130 for other nodes from the start of the transaction to the time zone added with the time difference stored in the memory. Determine conflicts.

<< Database Update Operation of Database Control System According to Second Embodiment >>
Hereinafter, the database update operation of the database control system according to the second embodiment will be described with reference to FIG.
FIG. 10 is an explanatory diagram of a database update operation (with conflict of update data) of the database control system according to the second embodiment.
FIG. 10 shows a processing flow when TxA is executed at the node 2A and TxB is executed at the node 2B almost simultaneously. Since both TxA and TxB update the record at address # 0001, the update target records compete. The operation of this embodiment will be described below using step S003B.

In the description, some descriptions of data settings of the redo logs 120 and 130 and the redo log information 300 are omitted.
In addition, after the step, the status of the redo log 120A for the node 2A and the redo log 130B for the other node of the node 2B, the redo log 120B for the node 2B, and the redo log for the other node of the node 2A The state of 130A is the same as that shown in FIGS.

(Step S003B)
The update target conflict determination unit 112B of the node 2B determines whether or not the update target record conflicts between the local node and another node before committing. Here, it is assumed that the current date and time is “20090101010101006”. Further, the redo log information transmission delay calculation unit 115 of the node 2B receives empty redo log information, recognizes that there is a certain time difference, and stores this time difference in the memory.

  The update target conflict determination unit 112B determines whether or not the update target record has competed after the time difference stored in the memory from the current time. The update target conflict determination unit 112B refers to the time stamp column 121B of the redo log 120B for its own node to grasp that the start of TxB is “20090101010101002”, and the time stamp column 131B of the redo log 130B for other nodes Entries in which the date and time of “20090101010101002” to “20090101010101006” match the value of the DB operation address field 124B of the local node redo log 120B and the value of the DB operation address field 134B of the redo log 130B for other nodes It can be seen that there is also an entry in which “commit” is set in the DB operation code column 133B. Therefore, the update target conflict determination unit 112B determines that there is a conflict of update target records.

It is assumed that the update target conflict determination unit 112B determines a conflict at the current time “20090101010101006”. At this time, since the commit information of the node 2A has not reached the node 2B, the update target conflict determination unit 112B determines that there is actually no conflict but there is no conflict.
This is the end of the description of the database update operation (with update data conflict) of the database control system according to the second embodiment.

  In the database control system according to the present embodiment, when the commit is performed at the own node, the information on the commit of the other node is not reflected in the redo log 130 for the other node included in the own node. This is effective in the case where commit information is being performed at the other node and the commit information of the other node is not reflected in the redo log 130 for the other node included in the own node due to the transmission delay of the redo log information 300.

(Effect of the database control system according to the second embodiment)
Even if there is a delay in transmission between nodes, it is possible to determine the conflict of records to be updated.

1 Database control system 2 (2A, 2B) Node (computer)
6 (6A, 6B) Timer 100 (100A, 100B) Control device 110 (110A, 110B) Database management unit 111 (111A, 111B) Redo log update unit 112 (112A, 112B) Update target conflict determination unit 115 (115A, 115B) ) Redo log information transmission delay calculation unit 120 (120A, 120B) own node redo log (self update information)
130 (130A, 130B) Redo log for other nodes (other update information)
200 (200A, 200B) Storage device 210 (210A, 210B) DBMS (database management program)
220 (220A, 220B) DB (database)
300 redo log information (update data)

Claims (6)

A computer comprising at least one database multiplexed in communication with a plurality of databases having the same contents,
A storage unit that holds the self-update information of the database owned by itself and other update information of the database other than the database owned by the self for each database,
When updating the self-update information, by referring to the other update information, a contention determination unit that determines contention in the update of the multiplexed database,
A computer comprising: The other update information is stored in the storage unit when update data of a database provided in a computer other than the self is received,
The computer according to claim 1. In the time period from the start of updating the self-update information to the result confirmation, the conflict determination unit matches the address of the update target record of the self-update information and the address of the update target record of the other update information, And it is determined that the update of the multiplexed database has conflicted when the update processing of other update information is confirmed as a result,
The computer according to claim 2. It further includes a delay calculation unit that calculates the time difference between the time when the data describing the transmission time transmitted by a computer other than the self is transmitted, and the transmission time,
The contention determination unit waits for the time difference and determines whether the update of the multiplexed database has contention,
The computer according to claim 2 or claim 3, wherein The data describing the transmission time of transmission is the update data.
The computer according to claim 4, wherein: A database management program to be executed by a control device of a computer including at least one of a plurality of databases that are communicably connected to a plurality of databases having the same contents,
A function of storing in the storage unit the database self-update information held by the own computer and other update information of the database other than the database held by the self for each database;
A function of determining a conflict in updating the multiplexed database by referring to the other update information when updating the self-information;
A database management program for causing the control device to realize the above.

Images