WO2017006423A1 - Computer system and database management method - Google Patents

Abstract

In an environment in which, without receiving a log output response for the commitment of a database transaction, it is possible to commence another transaction which is based on the result of the database transaction, the computer system outputs a commitment completion without receiving the log output response if the log output for the commitment of the database transaction has been carried out.

Description

Computer system and database management method

The present invention generally relates to database management.

Changes to the database are generally completed when writing to a so-called persistence device (typically a non-volatile storage device) is complete. However, as represented by a hard disk drive, the time required for writing to the permanent device is longer than the time required for writing to the main memory. Therefore, when another transaction refers to a record updated by a preceding transaction, it is necessary to wait for a log of the preceding transaction to be output and a completion response received.

In Patent Document 1, if there is no collision with another transaction, the log output of the preceding transaction is started, and at the same time, the record updated by the preceding transaction is not changed without waiting for the log output completion response. A technique (so-called speculative execution processing technique) that enables a transaction to refer to is disclosed.

Japanese Patent No. 4295333

In recent years, in-memory databases that place database tables and indexes on memory have become popular. On the other hand, a transaction log output destination device is generally a device having I / O (Input / Output) response performance lower than that of a memory in which a database is arranged. For this reason, in the entire database transaction processing, the ratio of the time from the log output for committing the transaction to the reception of the response of the log output is not small, so it is difficult to recognize the throughput improvement by the speculative execution processing. .

This kind of problem can occur regardless of whether or not the in-memory database is adopted and the I / O response performance of the log output destination device.

In an environment where it may be possible to initiate another transaction based on the outcome of a transaction without receiving a log output response for the commit of the database transaction, the computer system may When log output is performed, commit completion is output without receiving a response to the log output. This computer system includes at least one of a server system (one or more server computers) that executes a DBMS and a client system (one or more client computers) that issues a request (for example, a query) to the server system.

It is easy to recognize the throughput improvement due to speculative execution processing of the database.

1 shows an example of the configuration of the entire system according to an embodiment. A configuration example of a DBMS (database management system) and a relationship example between the DBMS, an OS (Operating System), an I / O adapter, and an external storage device are shown. The structural example of a Tx (transaction) management part is shown. The structural example of a log management part is shown. An example of the flow of Tx processing is shown. An example of the flow of log output processing is shown. An example of log configuration is shown. An example of the flow of database recovery processing is shown. An example of the flow of log application processing is shown. It is a sequence diagram which shows an example of communication between a client and DBMS. It is a sequence diagram which shows another example of communication between a client and DBMS. An example of the flow of I / F control processing is shown. An example of a setting user interface is shown.

Hereinafter, an embodiment will be described with reference to the drawings.

In the following description, the issuer of a query to a database management system (hereinafter referred to as DBMS) may be a computer program inside the DBMS or a computer program outside the DBMS (for example, executed by a client system). Computer program). In the following embodiment, the query issuer is a client computer.

In the following description, an I / O (Input / Output) request is a write request or a read request, and may be referred to as an access request.

In the following description, there is a case where “bbb part” is used as the subject, but these function parts perform processing determined by being executed by the processor with a memory and a communication port (network I / F). Since it is performed while being used, the description may be made with the processor as the subject. The processor typically includes a microprocessor (for example, CPU (Central Processing Unit)), and further includes dedicated hardware (for example, ASIC (Application Specific Integrated Circuit) or FPGA (Field-Programmable Gate Array)). Good. Further, the processing disclosed with these functional units as the subject may be processing performed by a computer. Further, some or all of these functional units may be realized by dedicated hardware. Various functional units may be installed in each computer by a program distribution server or a computer-readable storage medium. The various functional units and the server may be installed and executed in one computer, or may be installed and executed in a plurality of computers. The processor is an example of a control unit, and may include a hardware circuit that performs part or all of the processing. The program may be installed in a computer-like device from a program source. The program source may be, for example, a storage medium that can be read by a program distribution server or a computer. When the program source is a program distribution server, the program distribution server may include a processor (for example, a CPU) and a storage unit, and the storage unit may further store a distribution program and a program to be distributed. Then, the processor of the program distribution server executes the distribution program, so that the processor of the program distribution server may distribute the distribution target program to other computers. In the following description, two or more programs may be realized as one program, or one program may be realized as two or more programs.

In the following description, the “thread” may be an OS thread or a pseudo thread. The OS thread is a thread managed by an OS (Operating System) (for example, a thread managed by a kernel and a library), and can also be called a real thread. On the other hand, the “pseudo thread” is a thread managed by the DBMS. The OS thread can be included in a plurality of pseudo threads by being subdivided in a pseudo manner by the DBMS.

In the following description, the “storage unit” may be one or more storage devices including a memory. For example, the storage unit may be at least a main storage device of a main storage device (typically a volatile memory) and an auxiliary storage device (typically a nonvolatile storage device).

In the following description, “displaying display information” by a server system (for example, a database server) may be displaying display information on a display device included in the server system, or an external system ( For example, the display information may be transmitted to a client system (in the latter case, the display information is displayed by an external system).

FIG. 1 shows a configuration example of the entire system according to the embodiment.

An external storage device 402 is connected to the database server 401 via, for example, a communication network 403. A client computer (hereinafter referred to as a client) 405 is connected to the database server 401 via a communication network 404, for example.

The client 405 is an example of a client system. The client 405 issues a request to the database server 401 and receives a response as a processing result of the request from the database server 401. The request is, for example, a query. The client 405 is an example of a query issuer.

The database server 401 is an example of a server system. The database server 401 is a computer, and may be, for example, a personal computer, a workstation, or a mainframe, or may be a virtual computer configured by a virtualization program in these computers. The database server 401 includes an I / O adapter 409, an I / O adapter 413, a memory (typically main memory) 416, a storage device 415, and a processor 414 connected thereto.

The processor 414 may be, for example, a microprocessor or a module including a microprocessor and a dedicated hardware circuit. The processor 414 executes a computer program. The computer program executed by the processor 414 is, for example, an operating system (OS) 117 and a database management system (DBMS) 412.

The memory 416 is, for example, a volatile DRAM (Dynamic Random Access Memory) or the like, and temporarily stores a program executed by the processor 414 and data used by the program. The storage device 415 is non-volatile, and is, for example, an HDD (Hard Disk Drive) or an SSD (Solid State Drive). The storage device 415 may store a program and data used by the program. At least the memory 416 of the memory 416 and the storage device 415 is an example of a storage unit.

The I / O adapter 409 connects the communication network 404 and the database server 401. The I / O adapter 413 connects the communication network 403 and the database server 401. At least one of the I / O adapters 409 and 413 is an example of an interface device.

The external storage device 402 is a device having a storage device group 451 including a plurality of storage devices, and is, for example, a disk array device, but may instead be a single storage device. The external storage device 402 stores the log file 301. The external storage apparatus 402 receives a log I / O request from the database server 401, reads and writes data (for example, a log) in accordance with the I / O request, and returns the result to the database server 401. Note that the storage device included in the storage device group 451 is a device having a nonvolatile storage medium, and is, for example, an HDD or an SSD. The storage device group 451 may be a RAID (Redundant Array of Independent Disks) group, and may store data at a predetermined RAID level. A logical storage device (for example, logical unit, logical volume, file system volume) based on the storage space of the storage device group 451 is provided to the database server 401, and the log file 301 is stored on the logical storage device. May be. In the present embodiment, the log file 301 is an example of a log storage area.

The external storage apparatus 402 includes an I / O adapter 441 and a storage controller 442 connected thereto in addition to the storage device group 451. The I / O adapter 441 connects the external storage apparatus 402 to the communication network 403, and is connected to the database server 401 via this. As a communication protocol via the communication network 403, for example, Fiber Channel (FC), SCSI (Small Computer System Interface), or TCP / IP (Transmission Control Protocol / Internet Protocol) may be employed. For example, when Fiber Channel or SCSI is adopted, the I / O adapter 441 (and 413) may be called a host bus adapter. The storage controller 442 includes, for example, a memory and a processor, and reads / writes data from / to the storage device group 451 storing the log file 301 in response to an I / O request from the database server 401.

FIG. 2 shows a configuration example of the DBMS 412 and a relationship example between the DBMS 412, the OS 117, the I / O adapter 413, and the external storage device 402.

The DBMS 412 is an in-memory database. The DBMS 412 arranges a database (for example, the table 111 and the index 112) on the memory 416. Further, the DBMS 412 may include a lock mechanism 116. This is because the lock mechanism 116 prevents two or more threads 110 from competing. The lock mechanism 116 may be information indicating whether or not the lock has been acquired. For example, the lock mechanism 116 may have a value “1” if the lock has been acquired, and may have a value “0” if the lock has not been acquired.

The DBMS 412 includes a Tx (transaction) management unit 113, a log buffer 114, and a log management unit 115. The Tx management unit 113 manages Tx being executed and its state (particularly, a commit state described later). The log buffer 114 temporarily stores a log including an update history for the table 111 and the index 112. The log management unit 115 manages the log file 301 and log writing to the log file.

The DBMS 412 has system information 24. The system information 24 is an example of information included in the management information. The system information 24 includes output control information 26 and mode control information 28. The output control information 26 is information indicating whether or not to execute a logical commit output, which is to output (for example, display) a commit completion before a log output response is received after a log output for commit is performed. It is. The mode control information 28 is information indicating whether or not a speculative execution processing mode, which is a processing mode for starting another Tx based on the result of the Tx without receiving a log output response for the commit of Tx, is on. is there. That is, the DBMS 412 can select whether to perform speculative execution processing according to the mode control information 28 in the system information 24. Further, the DBMS 412 can select whether or not to execute the logical commit output in the speculative execution process according to the output control information 26 in the system information 24. In the present embodiment, for each Tx, as a commit state in the speculative execution processing mode, a state of logical commit in addition to physical commit is managed. “Physical commit” is a state that means that a log output response for Tx commit is received and that the Tx states of all generated Tx related to the Tx are physical commits. The generated Tx related to Tx is Tx generated (updated) by the record referenced by Tx. On the other hand, the “logical commit” is a state before the log output response is received after the log output for the Tx commit is performed.

The DBMS 412 receives a query from the query issuer, and executes one or a plurality of Tx in the execution of the received query. Specifically, the DBMS 412 includes a query reception unit 421, a query execution plan generation unit 422, and a query execution unit 424.

The query receiving unit 421 receives a query issued by a query issuer. The query is described in, for example, a structured query language (SQL (Structured Query) Language). A plurality of Tx may be described in one query, or a plurality of Tx may be described in a plurality of queries.

The query execution plan generation unit 422 generates a query execution plan including one or more database operations necessary for executing the query from the query received by the query reception unit 421. The query execution plan is, for example, information including a relationship between one or more database operations and the execution order of the database operations, and is stored as query execution plan information 423. A query execution plan may be represented by a tree structure in which a database operation is a node and a relation of execution order of database operations is an edge.

The query execution unit 424 executes the query received by the query reception unit 421 according to the query execution plan generated by the query execution plan generation unit 422, and returns the execution result to the query issuer. At this time, the query execution unit 424 issues a data read request (reference request) necessary for execution of the database operation, and uses the data read from the table 111 in accordance with the read request to execute the database operation (for example, Then, new data is calculated using the read data (value), and a write request is issued to update the data in the read source record to the calculated data). The query execution unit 424 performs database operation by executing the thread 110. In the DBMS 412, a plurality of threads 110 are executed in parallel. For this reason, the processor 414 has a plurality of cores. A plurality of cores exist in one or a plurality of CPUs. The thread 110 may be called a task. One thread 110 may execute one Tx corresponding to one or more database operations. Hereinafter, the subject of the processing performed by the query execution unit 424 executing the thread 110 may be the thread 110.

The query execution unit 424 (thread 110) issues an I / O request to the external storage apparatus 402 to the OS 117 in order to write a log to the log file 301 in the external storage apparatus 402 during execution of Tx. The OS 117 accepts the I / O request and issues an I / O request to the external storage apparatus 402.

In the I / O adapter 413, a plurality of I / O queues 201 are prepared. In the process of Tx, the thread 110 issues an I / O request for writing a log. The I / O queue 201 stores the I / O request. Specifically, the I / O request is stored in the I / O queue 201 by the OS 117.

External storage device 402 stores log file 301. In the log file 301, a log to which an I / O request is written is recorded. The external storage apparatus 402 is an example of a log output destination device, and is an example of a storage device having an I / O response performance lower than that of the memory 416. The log file 301 may exist in another storage device having an I / O response performance lower than that of the memory 416 instead of the external storage apparatus 402. For example, the log file 301 may also exist in the memory 416.

In this embodiment, the thread 110 and the I / O queue 201 correspond 1: 1. That is, one I / O queue 201 is assigned to each thread 110. For example, the thread 110 issues a log write request indicating that the record of the table 111 has been updated to the log file 301. The issued write request is sent to the OS 117. The OS 117 receives a write request for the log file 301 and stores the write request in the I / O queue 201 corresponding to the thread 110. The write request stored in the I / O queue 201 is sent from the I / O queue 201 to the external storage device 402 by the OS 117. As a result, the log that is the write target data of the write request is written to the log file 301.

The configuration of the DBMS 412 shown in FIG. 2 is merely an example. For example, a certain component may be divided into a plurality of components, and a plurality of components may be integrated into one component.

FIG. 3 shows a configuration example of the Tx management unit 113.

The Tx management unit 113 includes Tx state information 130 and Tx information 140.

The Tx state information 130 includes a Tx state entry 131 for each Tx being executed. The Tx state entry 131 includes information such as TxID, Tx state, and Tx information pointer. TxID is the ID of Tx. Examples of the Tx state include begin, select, update, insert, logical commit, physical commit, and others. Select, update, and insert are examples of states belonging to the SQL state. A logical commit and a physical commit are examples of states belonging to a commit state. The Tx information pointer is a pointer to the Tx information 140. The Tx state indicated by the Tx state entry 131 is the current state of Tx corresponding to the entry 131.

Tx information 140 exists for each Tx. The Tx information 140 includes a read set 150 and a write set 160. The details of the Tx information 140 will be described below by taking one Tx as an example. The Tx is referred to as “target Tx” in the description of FIG.

The lead set 150 includes information related to the record referred to by the target Tx, in other words, information related to Tx (hereinafter, generated Tx) that generated the record referred to by the target Tx. Specifically, the lead set 150 has a reference record entry 151 for each record referenced by the target Tx. The reference record entry 151 includes information such as record ID, value, and TxID. The record ID is the ID of the record referenced by the target Tx. The value is each column value (value in the column) in the record referenced by the target Tx. TxID is the ID of the generated Tx that generated the record referenced by the target Tx.

The light set 160 includes information related to the record updated by the target Tx. Specifically, the light set 160 has an update record entry 161 for each record updated by the target Tx. The update record entry 161 has information such as a record ID and a value. The record ID is an ID of a record updated (generated) by the target Tx. The value is a value (value in the record) updated by the target Tx.

An example of Tx management is as follows. At the beginning of Tx, the Tx management unit 113 adds the Tx state entry 131 to the Tx state information 130 and adds the Tx information 140. The Tx management unit 113 registers the Tx ID of the started Tx, the Tx state “begin”, and the Tx information pointer to the added Tx information 140 in the added Tx state entry 131. Thereafter, for example, at the time of selection in the Tx, the Tx management unit 113 stores the information of the selected record in the read set 150 in the added Tx information 140 (Tx information 140 linked to the Tx information pointer). As a result of the selection, specifically, a reference record entry 151 is written for each referenced record. The TxID registered in the reference record entry 151 (TxID of the generated Tx) is the TxID of Tx corresponding to the light set 160 including the same record ID as the referenced record ID. In accordance with the result of processing performed by Tx, the Tx state (Tx state in the entry 131 corresponding to the Tx) is updated by the Tx management unit 113 to update, insert, logical commit, physical commit, or the like.

FIG. 4 shows a configuration example of the log management unit 115.

The log management unit 115 has a lock mechanism 121 and a log file address 122.

The lock mechanism 121 may also be data indicating whether or not the lock of the log management unit 115 has been acquired, like the lock mechanism 116 shown in FIG. For example, the lock mechanism 121 may have a value “1” if the lock has been acquired, and may have a value “0” if the lock has not been acquired. In order to write or read the log file address 122, the lock of the lock mechanism 121 must be acquired.

The log file address 122 is a log write destination address in the log file 301. The address (value) represented by the log file address 122 is added by the size of the log to be output each time a log is written to the log file 301.

FIG. 5 shows an example of the flow of Tx processing. In the following description, one Tx is taken as an example. The Tx is referred to as “target Tx” in the description of FIGS.

When the target Tx is started, the query execution unit 424 generates the read set 150 / write set 160 based on the instruction corresponding to the target Tx (instruction in the query) (S501). At the beginning of the target Tx, the table 111 and the index 112 are not changed. Thereafter, selection, update, and the like are performed, so that reference or update of the table 111 and the index 112 is performed. After that, a commit will be performed.

The query execution unit 424 makes a commit determination (S502). In the commit determination, for example, whether the change to the table 111 and the index 112 performed by the target Tx based on the read set 150 / write set 160 is consistent with other Tx is based on the isolation level of the database. Determined.

If the commit determination is NG (S503: No), the query execution unit 424 performs an abort process (S507), issues an abort completion notification (S508), and ends the target Tx.

If the commit determination is OK (S503: Yes), the query execution unit 424 executes the log output process (S504) and ends the target Tx. In the log output process, a commit completion notification according to at least a physical commit is performed.

FIG. 6 shows an example of the flow of the log output process (S504 in FIG. 5).

The query execution unit 424 secures an area for temporary storage of logs from the log buffer 114. A log, specifically, information that is a component of the log is written in the reserved area. FIG. 7 shows a configuration example of the log. There is one (or a plurality) of logs 30 per Tx. The log 30 includes a log header 31 and a log main body 32.

The log header 31 includes a log size 33 and a commit flag 34. The log size 33 represents the size of the log 30. The commit flag 34 indicates whether the current Tx state (at the time of generation of the log 30) of each generation Tx of the target Tx corresponding to the log 30 is a physical commit, in other words, whether the Tx state of the target Tx is a physical commit. Is information. The commit flag 34 is an example of commit status information.

The log main body 32 includes a TxID 35, a write set 36, and a read set 37. TxID 35 is the TxID of the target Tx corresponding to the log 30. The light set 36 is a copy of the light set 160 in the Tx information (hereinafter, target Tx information) 140 corresponding to the target Tx. The lead set 37 includes a copy of the lead set 150 in the target Tx information 140 and a Tx state for each reference record entry. The Tx state associated with the reference record entry is the Tx state of the generated Tx corresponding to the entry. The log 30 may not record the Tx state of the generated Tx.

Now, as shown in FIG. 6, the query execution unit 424 determines whether all the read sets 150 and write sets 160 in the target Tx information 140 have been recorded in the log of the target Tx (S601).

When the determination result in S601 is negative (S601: No), the query execution unit 424 reads from the target Tx information 140 the read set 150 or the write set 160 that is not yet recorded in the log 30 from the target Tx information 140 (S602). . The query execution unit 424 records the read set 150 or write set 160 in the log (S603). When the set read in S602 is the lead set 150, in S603, the query execution unit 424 adds to each reference record entry in the lead set 37 recorded in the log 30 the generated Tx corresponding to the reference record entry. The current Tx state (Tx state specified from the Tx state information 130) is associated. The associated Tx state is also recorded in the log 30. However, in S603, the reference record entry corresponding to the generated Tx whose current Tx state is physical commit is not recorded in the log 30 in the log 30. Specifically, for example, the query execution unit 424 determines whether the current Tx state of the generated Tx is a physical commit for each reference record entry in the read set 150 that has been read, and the determination result Does not record a positive reference record entry in the log 30. Thereby, the size of the log 30 can be reduced.

If the determination result in S601 is affirmative (S601: Yes), the query execution unit 424 calculates the size of the log 30 on the log buffer 114 (S605), and based on the calculated size, the log output destination log file An address for 301 is secured (addition of log file address) (S606). The output destination log file 301 may be the log file 301 assigned to the thread 110 that executes the target Tx. That is, the log file 301 may be assigned to each thread 110.

Further, the query execution unit 424 rechecks the current Tx state of the generated Tx by referring to the Tx state information 130 for each reference record entry of the lead set 37 in the log 30 (S607). That is, the Tx state of the generated Tx is checked in S603, but is also checked in S607. This is because there is a possibility that the state of the generated Tx has transitioned to physical commit between S603 and S607. For each generated Tx identified from the lead set 37 of the log 30, the Tx state recorded in the log 30 may be updated to the current Tx state identified in S607. The reference record entry of the generated Tx whose current Tx state is a physical commit may be deleted from the log 30.

The query execution unit 424 determines whether or not the current Tx state of all the generated Tx specified from the read set 37 in the log 30 of the target Tx is a physical commit (S608). If the determination result in S608 is affirmative (S608: Yes), the query execution unit 424 sets the commit flag 16 in the log 30 of the target Tx (S609). If the determination result in S608 is negative (S608: No), S609 is skipped. This means that the initial value of the commit flag 16 is that the Tx state of at least one generated Tx is not a commit flag (for example, the value of the flag 16 = “0”). If the initial value of the commit flag 16 means that the Tx states of all the generated Txs are physical commits (for example, the value of the flag 16 = “1”), S608: Yes, S609 is performed. Then, when S608: No, the commit flag 16 may be defeated (the value is set to “0”).

After S609 or after S608: No, the query execution unit 424 outputs a log output, specifically, a request to write the log 30 to the log file 301 (S610). At this time, the query execution unit 424 updates the current Tx state of the target Tx (Tx state in the Tx state information 130) to a logical commit. The log management unit 115 may perform I / F control processing (S1000), and output (for example, display) commit completion according to the result. The commit completion output here may be a completion meaning a logical commit, or may be a simple commit completion that does not distinguish between a logical commit and a physical commit. The output destination of the completion of commit may be a client 405 as a query issuer, or a management system (one or more computers) (not shown) that manages the database server 401. Since the commit completion is output before receiving the log output response, the user (for example, the user of the client 405 or the user of the management system (for example, the administrator)) related to the output destination of the commit completion executes speculation. You can feel an improvement in throughput as a result of processing.

After S610, the query execution unit 424 waits for a log output response (S611). When a log output response (log write completion response) is received from the log output destination (for example, the external storage device 402), the query execution unit 424 indicates that the current state of all generated Tx related to the target Tx is a physical commit. If so, the current Tx state of the target Tx is updated to a physical commit (S612). When the Tx state of the target Tx is a physical commit, the log management unit 115 can output a commit completion notification to, for example, a query issuer (or management system). For the sake of convenience, the commit completion output performed at S612 is referred to as “physical commit output”. The physical commit output may be omitted when the logical commit output is performed (in other words, when the output control information 26 in the system information 24 indicates that the logical commit output is executed). In other words, the physical commit output is performed at least when the logical commit output is not performed (in other words, when the output control information 26 in the system information 24 indicates that at least the logical commit output is not executed). It's okay. The commit completion notification according to the physical commit output may be a completion notification meaning a physical commit, or may be a simple commit completion notification that does not distinguish between a logical commit and a physical commit. Specifically, for example, when only one of the logical commit output and the physical commit output is performed, the output of the commit completion notification may be the simple commit completion notification. When both logical commit output and physical commit output are performed, the commit completion notification in the logical commit output may be a commit completion notification that means logical commit, and the commit completion notification in the physical commit output means physical commit A commit completion notification may be used.

FIG. 8 shows an example of the flow of database recovery processing.

In the database recovery process, the database at the latest point is recovered from the backed up database at a certain point in time and the log in which the differences from that point are sequentially recorded.

The query execution unit 424 loads the backed up database onto the memory 416 (S801).

Next, the log management unit 115 determines whether all logs have been read from the read source log file 301 (S802).

If the determination result in S802 is negative (S802: No), the log management unit 115 reads a log that has not been read from the read source log file 301 to, for example, the log buffer 114 (S803), and applies the log to the log. The process is executed (S804).

If the determination result in S802 is affirmative (S802: Yes), the database recovery process ends. However, when the log 30 is registered in the pending log list (S811: Yes), the log management unit 115 discards the pending log list (S812). In S812, a recovery error may be output. This is because not all logs have been applied. The pending log list will be described later.

FIG. 9 shows an example of the flow of the log application process (S804 in FIG. 8).

The log management unit 115 records the TxID 35 and the Tx state in the read log 30 in the Tx state information 130 (S901). The Tx state recorded in S901 is the Tx state indicated by the commit flag 16 in the read log 30. Specifically, if the commit flag 16 is set (if the value is “1”), the physical commit is recorded as a Tx state, and if the commit flag 16 is collapsed (if the value is “0”). ), A logical commit is recorded as a Tx state.

The log management unit 115 determines whether the recorded Tx state (Tx state represented by the commit flag 16 in the read log 30) is a physical commit (S902).

When the determination result in S902 is positive (S902: Yes), the log management unit 115 applies the read log 30 in the database recovery process (S908). In S908, for example, database recovery is performed based on the light set 36 in the log 30. The log management unit 115 changes the Tx state of Tx corresponding to the log 30 (Tx state in the Tx state information 130) to physical commit (S909). If all the logs registered in the pending log list have been checked (S910: Yes), the log management unit 115 ends the log application process. The “pending log list” is an entry that includes a log (or a pointer indicating the location of the log and a Tx ID of Tx corresponding to the log) for which the determination of whether or not to apply is pending. ) Is registered information. The pending log list may be information prepared in the database recovery process by the log management unit 115, for example.

If the determination result in S902 is affirmative (S902: Yes), the log management unit 115 adds the read log 30 to the pending log list (S903). The log management unit 115 specifies the generated Tx (TxID of the generated Tx) from the lead set 37 in the log 30 (S904), and specifies the current Tx state of the specified generated Tx from the Tx state information 130 (S905). ). The log management unit 115 determines whether or not the Tx states of all the generated Tx are physical commits (S906).

If the determination result in S906 is affirmative (S906: Yes), the log management unit 115 deletes the log 30 from the pending log list (S907), applies the log 30 (S908), and corresponds to the log 30 The Tx state of Tx is changed to physical commit (S909). If all the logs registered in the pending log list have been checked (S910: Yes), the log management unit 115 ends the log application process.

In the log application process, in addition to the log registered in the pending log list in the log application process, the processes in and after S904 are performed for the log registered in the pending log list in the log application process prior to the log application process. (S910: No). This is because, even if the Tx state of the generated Tx is not a physical commit in the past log application process, the Tx state of the generated Tx may transition to the physical commit in the current log application process. Alternatively, entries that are not yet in the Tx state information 130 in the past log application process may exist in the current log application process. In one log application process, the number of times S904 and subsequent steps are performed on logs registered in the pending log list is one time, but may be two or more times.

FIG. 10 is a sequence diagram illustrating an example of communication between the client 405 and the DBMS 412. Hereinafter, one Tx is taken as an example. The Tx is referred to as “target Tx” in the description of FIGS.

For example, when the query execution unit 424 in the DBMS 412 receives a request for a select statement after the target Tx begin from the client 405, the Tx state of the generated Tx that generated the referenced record is returned together with the result of the select statement. The value returned here may be a physical commit. Thereby, the client 405 can know whether or not the Tx state of the generated Tx related to the target Tx is a physical commit.

Similarly, when the query execution unit 424 receives a request for an update statement, it returns a value indicating whether the Tx state of the generated Tx corresponding to the record to be updated is a physical commit, together with the result of the update statement. .

When the query execution unit 424 receives a commit request from the client 405 and outputs a log, if the result of the I / F control process (S1000) is a commit completion output, a commit completion notification (for example, a logical commit completion notification) return it.

After that, when the query execution unit 424 receives a check request from the client 405, it receives a response to the log output of the target Tx, and if the Tx states of all the generated Tx related to the target Tx are physical commits, Returns a commit completion notification (eg, physical commit completion notification).

Note that the client 405 may perform the I / F control processing. In other words, the client 405 may control whether to output (display) the received commit completion notification. Specifically, for example, if the client 405 determines not to output the received commit completion notification, the client 405 does not output the commit completion notification.

Also, as described above, the completion notification of the physical commit does not necessarily have to be performed. Specifically, for example, at least when a logical commit completion notification is not sent, a physical commit completion notification may be sent.

FIG. 11 is a sequence diagram illustrating another example of communication between the client 405 and the DBMS 412.

According to FIG. 11, when the query execution unit 424 receives a Tx request, the query execution unit 424 executes a series of Tx processes from Begin to Commit, and returns a result of the Tx process. At this time, the query execution unit 424 outputs / does not output the logical commit completion notification according to the result of the I / F control process (S1000). The query execution unit 424 controls whether or not to output a physical commit completion notification.

FIG. 12 shows an example of the flow of I / F control processing (S1000).

The query execution unit 424 determines whether or not the mode control information 28 in the system information 24 indicates that the speculative execution processing mode is on (S1201). When the determination result in S1201 is negative (S1201: No), the completion notification of the logical commit output is not performed.

If the determination result in S1201 is affirmative (S1201: Yes), the query execution unit 424 determines whether or not the output control information 26 in the system information 24 represents performing logical commit output (S1202). When the determination result in S1202 is negative (S1202: No), the completion notification of the logical commit output is not performed.

If the determination result in S1202 is affirmative (S1202: Yes), the query execution unit 424 notifies the completion of the logical commit output.

FIG. 13 shows an example of the setting user interface.

The setting user interface 1300 is, for example, a GUI (Graphical User Interface), and is provided by the log management unit 115 to an external system such as the client 405 or a management system. The setting user interface 1300 is used to select a UI (user interface) for selecting whether the speculative execution processing mode is turned on or off, and whether to perform logical commit output (on) or not (off). UI. Each UI is a radio button, but is not limited thereto. The designation (speculation execution processing mode on / off and logical commit output on / off) input via the setting user interface 1300 is registered in the system information 24.

Hereinafter, the embodiments will be summarized. Note that in the general description, new descriptions such as modifications of the embodiment can be added as appropriate.

A system for solving at least one of the following problems is provided.
(Problem 1) In an environment where speculative execution processing for starting another Tx based on the result of Tx can be performed without receiving a log output response for Tx commit of the database, throughput improvement by speculative execution processing is improved. At least difficult for the user to recognize. This is because, in the entire Tx processing of the database, the ratio of the time from the log output for Tx commit to the reception of the log output response is not small.
(Problem 2) Log inconsistency may occur in speculative execution processing. For example, although the first log that Tx1 updated record A to record B was output, the second log that Tx2 updated record B to record C even though the writing of the first log was not completed If a failure occurs before the first log is written, the log inconsistency may occur in the database recovery process.

Issue 1 can be solved as follows, for example. That is, the DBMS 412 outputs a log for committing a database transaction, and outputs commit completion (commit completion as a logical commit output) without receiving a response to the log output. Thereby, the user can feel the throughput improvement by speculative execution processing.

Note that the DBMS 412 is output control information that is information indicating whether or not to execute logical commit output, which is to output commit completion before receiving a log output response after log output for commit is performed. 26 is managed. If the output control information 26 indicates that a logical commit output is to be executed, the DBMS 412 outputs the completion of the commit before receiving a log output response made for the commit of the transaction. Thus, depending on the contents of the output control information 26, it is possible to control whether or not to perform logical commit output.

Also, the DBMS 412 provides a setting user interface 1300 that accepts an output designation that is a designation of whether or not to perform logical commit output. The DBMS 412 receives an output designation (logical commit output on / off designation) through the setting user interface 1300 and updates the output control information 26 according to the received output designation. In this way, the user can switch on / off of the logical commit output. If the commit output is simply switched on / off, the logical commit output is not necessary, but if the physical commit output is required, the physical commit output is also turned off. For this reason, regarding the on / off switching of the commit output, it is significant that the logical commit output is cut out and the logical commit output can be switched on / off. Note that in addition to turning on / off the logical commit output, a UI for switching on / off the physical commit output may be included in the setting user interface 1300.

Also, the DBMS 412 manages mode control information 28 that is information indicating whether or not the speculative execution processing mode is ON. If the mode control information 28 indicates that the speculative execution processing mode is on, the DBMS 412 starts another transaction based on the result of the transaction without receiving a log output response for committing the transaction. It is like that. The DBMS 412 receives a mode designation that is a designation as to whether or not the speculative execution processing mode is on through the setting user interface 1300 (or another user interface), and updates the mode control information 28 according to the received mode designation. Thus, the user can also switch on / off of the speculative execution processing mode. The UI for turning on / off the logical commit output, the UI for turning on / off the speculative execution processing mode, and the UI for turning on / off the physical commit output may be in the same GUI. It may be in the GUI. In addition, when ON is selected for the speculative execution processing mode, the DBMS 412 may disable the logical commit output ON (for example, in a disabled state so that it cannot be selected).

Further, the DBMS 412 may execute the physical commit output if the output control information 26 indicates that at least the logical commit output is not executed.

Problem 2 can be solved as follows, for example. That is, the DBMS 412 receives a Tx log output completion response, and the log output is only performed in addition to the physical commit which means that the Tx state of all generated Tx related to the Tx is a physical commit. Manages commit status called logical commit, which means status. In the database recovery process, the DBMS 412 can set a recovery error if there is only one Tx for which physical commit is not established forever (S811: Yes in FIG. 8), and the Tx states of all Tx are physical commits. When it comes to, the database recovery process is completed. As a result, it is possible to avoid application of logs that may have log inconsistencies.

Specifically, the Tx log 30 includes a commit flag 16 that is an example of information indicating whether or not the state of the Tx is a physical commit. Further, the log 30 includes a lead set 37 which is an example of information including information related to Tx reference. The DBMS 412 determines whether each Tx state of the generated transaction is a physical commit based on the read set 37.

The lead set 37 includes TxID of each generated Tx. The DBMS 412 determines whether or not the state of each generated Tx is a physical commit by specifying the current Tx state corresponding to the TxID of each generated Tx specified from the lead set 37.

The DBMS 412 determines whether or not the current Tx state of each generated Tx specified from the read set 37 included in the output target log 30 is a physical commit when outputting the output target log 30. If the result of the determination is affirmative, the DBMS 412 sets the commit flag 16 included in the output target log 30 and then outputs the log 30.

If the Tx state of the generated Tx is a physical commit, the DBMS 412 does not record the TxID of the generated Tx in the log 30.

The DBMS 412 applies the log in the database recovery process if the commit flag 16 included in the log indicates a physical commit for the log read in the database recovery process (an example of an output log).

If the commit flag 16 included in the log read in the database recovery process does not indicate a physical commit, the DBMS 412 (x1) determines whether the current state of all generated Tx related to the transaction corresponding to the log is a physical commit. If the determination result of (x2) (x1) is affirmative, the log is applied, and the current Tx state of Tx corresponding to the log is changed to physical commit. The DBMS 412 performs a log application process every time a log is read in the database recovery process. In the log application process, the determination of (x1) for the read log and the determination of (x1) again for the log for which the determination result of (x1) is negative in the past log application process are performed. Is called.

As mentioned above, although one embodiment was described, it cannot be overemphasized that this invention can be variously changed in the range which is not limited to this embodiment and does not deviate from the summary.

For example, a lead set (an example of reference information) may be only a time stamp (hereinafter referred to as TS) instead of each reference record entry, or a list of record IDs that can be referred to at the time of the TS. TS may be a time or a count value. For example, if all Tx states of Tx prior to TS “120” are physical commits, the query execution unit can determine that the Tx state of Tx corresponding to TS “120” may also be physical commits. Further, for example, the query execution unit, for example, should have output a log for commit for Tx corresponding to TS “119”, but if the log is not written in the log file, TS “120” It can be determined that the Tx state corresponding to Tx should not be a physical commit (because the Tx state corresponding to TS “119” is not a physical commit). In this way, even if the lead set is TS, it can be determined whether the Tx state of the target Tx can be a physical commit.

401 ... Database server

Claims (14)

A computer system that starts another transaction based on the result of a transaction without receiving a log output response for the commit of the database transaction,
A storage unit for storing management information which is information including information on transactions;
A computer system comprising: a processor that outputs a log generated based on the management information and commits completion without receiving a response to the log output for committing a database transaction. The storage unit is output control information that is information indicating whether or not to execute a logical commit output that is to output a commit completion before receiving a log output response after a log output for commit is performed Remember
If the output control information indicates that a logical commit output is to be executed, the processor outputs the completion of the commit before receiving a log output response made for transaction commit.
The computer system according to claim 1. The processor is
Provide a user interface that accepts output specification that specifies whether to perform logical commit output,
Receive output designation through the user interface,
Updating the output control information according to the received output designation;
The computer system according to claim 2. The storage unit is information indicating whether or not a speculative execution processing mode, which is a processing mode for starting another transaction based on a result of the transaction without receiving a log output response for committing the transaction, is on. Store mode control information,
When the mode control information indicates that the speculative execution processing mode is on, the processor can execute another transaction based on the result of the transaction without receiving a log output response for committing the transaction. To start,
The processor is
Receiving a mode designation that is a designation of whether or not the speculative execution processing mode is on, through the user interface or another user interface;
Updating the mode control information in accordance with the received mode designation;
The computer system according to claim 3. The processor is
If the output control information indicates that the logical commit output is not executed, the commit completion is not output before receiving the log output response made for the transaction commit,
If the output control information indicates that at least the logical commit output is not executed, the response of the log output performed for the transaction commit is received, and the state of each of the generated transactions related to the transaction is physical. In case of commit, output commit completion,
A physical commit is a state that means that a response of a log output for committing a transaction is received and each state of a generated transaction related to the transaction is a physical commit.
Each of the generated transactions is a transaction that generated a record referenced by the transaction.
The computer system according to claim 2. As the status of the target transaction that is one of the transactions,
A logical commit that is in a state before the log output for the commit of the target transaction is performed and a response of the log output is received;
There is a physical commit that receives a log output response for committing the target transaction, and that means that each state of the generated transaction related to the target transaction is a physical commit,
Each of the generation transactions is a transaction that generates a record referenced by the target transaction.
The log output by the processor includes commit status information that is information indicating whether the status of the transaction corresponding to the log is a physical commit.
The computer system according to claim 1. The log corresponding to the target transaction includes reference information that is information including information related to the reference of the target transaction,
The processor determines whether each state of the generated transaction is a physical commit based on the reference information.
The computer system according to claim 6. The reference information includes, for each of the generated transactions, an ID of the generated transaction,
The processor determines whether each state of the generated transaction is a physical commit by specifying a current transaction state corresponding to an ID of each generated transaction specified from the reference information.
The computer system according to claim 7. The processor is
Determining whether the current state of each of the generated transactions corresponding to the reference information included in the output target log is a physical commit when executing the output target log;
If the result of the determination is affirmative, the commit status information included in the output target log is changed to information representing a physical commit, and then the output target log is output.
The computer system according to claim 6. The processor is
If the state of the generated transaction is not a physical commit, the ID of the generated transaction is recorded in the log of the target transaction,
If the status of the generated transaction is a physical commit, the ID of the generated transaction is not recorded in the log of the target transaction.
The computer system according to claim 9. For each output log, the processor applies the log in the database recovery process if the commit status information included in the log represents a physical commit.
The computer system according to claim 6. The processor, for each output log, if the commit status information included in the log does not represent a physical commit,
(X1) It is determined whether the current state of each of the generated transactions related to the transaction corresponding to the log is a physical commit,
(X2) When the determination result of (x1) is affirmative, the log is applied in the database recovery process, and the current state of the transaction corresponding to the log is changed to a physical commit.
The computer system according to claim 11. The processor performs a log application process each time a log is read in the database recovery process,
In the log application process, the determination of (x1) for the read log and the determination of (x1) again for the log for which the determination result of (x1) is negative in the past log application process. Done,
The computer system according to claim 12. In the database management method of starting another transaction based on the result of the transaction without receiving a log output response for the commit of the database transaction,
Detects that log output for database transaction commit occurred,
Output commit completion without receiving response of detected log output,
Database management method.

Images