WO2016120988A1

WO2016120988A1 - Database system and database management method

Info

Publication number: WO2016120988A1
Application number: PCT/JP2015/052160
Authority: WO
Inventors: 田中　剛; 敦友田; 有哉礒田; 上村　哲也
Original assignee: 株式会社日立製作所
Priority date: 2015-01-27
Filing date: 2015-01-27
Publication date: 2016-08-04

Abstract

In this database system, an active system server has a first execution unit, which executes a plurality of first sub-execution units in a parallel manner, and an integrated log management unit. The plurality of first sub-execution units executed in a parallel manner perform a plurality of transactions with respect to a first database managed by the active system server, generate a plurality of logs, each corresponding to a respective one of the plurality of transactions, and writes each of the generated plurality of logs to a corresponding one of a plurality of log storage regions. The integrated log management unit reads the plurality of logs from the plurality of log storage regions, generates an integrated log including the read plurality of logs, and transfers the generated integrated log to a standby system server.

Description

Database system and database management method

The present invention generally relates to database management, for example, to output of transaction processing logs.

Generally, in database management, a transaction processing log (Tx log) is output. For example, Patent Document 1 is known as this type of technology. In Patent Document 1, a plurality of clients in an application program each pass a Tx log to a single log management system, and the log management system stores a plurality of logs in a single log disk. Multiple clients and log management systems exist within a computing device.

When a database is applied to a system such as a financial institution, it is desirable that the HA (High Availability) configuration, that is, the database system includes an active server and a standby server. In the HA configuration, it is necessary to transfer the Tx log from the active server to the standby server. For example, Patent Document 2 is known as this type of technology. In Patent Document 2, a plurality of Tx logs generated in the active server are transferred in parallel to the standby server.

US2012 / 0078854 US 7,305,421

In either of Patent Documents 1 and 2, a conflict may occur when writing or transferring a Tx log, and thus it is necessary to acquire a lock. Specifically, in Patent Document 1, the client needs to write a Tx log in a single log management system after acquiring a lock. In Patent Document 2, in particular, when the number of Tx logs to be transferred is larger than the transfer parallelism (the number of Tx logs that can be simultaneously transferred from the active server to the standby server), the transfer from the active server to the standby server is performed. It is necessary to transfer the Tx log after acquiring the lock of the transfer path.

As described above, both serial log writing as in Patent Document 1 and parallel log transfer as in Patent Document 2 can cause contention, so that it is necessary to acquire a lock.

The active server has a first execution unit that executes a plurality of first sub-execution units in parallel, and an integrated log management unit. The plurality of first sub-execution units executed in parallel execute a plurality of transactions for the first database managed by the active server, generate a plurality of logs respectively corresponding to the plurality of transactions, and generate the plurality of logs Are respectively written in a plurality of log storage areas. The integrated log management unit reads a plurality of logs from a plurality of log storage areas, generates an integrated log including the read logs, and transfers the generated integrated log to the standby server.

∙ There is no contention in log writing and transfer, so log writing and transfer can be performed at high speed.

1 shows a configuration of a database system according to a first embodiment. The data structure of the Tx log which concerns on Example 1, and an integrated Tx log is shown. An example of log output is shown. It is a flowchart of a Tx process. 6 is a flowchart of log output processing according to the first embodiment. 6 is a flowchart of integrated Tx log writing processing according to the first embodiment. The structure of the database system which concerns on Example 2 is shown. The data structure of the integrated Tx log which concerns on Example 2 is shown. The structure of a partition access map is shown. 12 is a flowchart of log output processing according to the second embodiment. 12 is a flowchart of integrated Tx log writing processing according to the second embodiment. It is a flowchart of an integrated Tx log reflection process.

Hereinafter, some embodiments will be described with reference to the drawings.

In the following description, “PDEV” indicates a physical storage device, and may typically be a nonvolatile storage device (for example, an auxiliary storage device). The PDEV may be, for example, an HDD (Hard Disk Drive) or an SSD (Solid State Drive).

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).

Further, in the following description, there is a case where the process is described with a functional unit (for example, a query reception unit, a query execution plan generation unit, a query execution unit, an integrated log management unit, an LLSN management unit) as a subject, The program is executed by a processor (for example, a CPU (Central Processing Unit)), so that a predetermined process is appropriately performed using a storage unit (for example, a memory) and / or an interface device (for example, a communication port). The subject of processing may be a processor. The processing described with the functional unit as the subject may be processing performed by a processor or an apparatus or system having the processor. The processor may include a hardware circuit that performs a part or all of the processing. At least a part of the plurality of functional units may be realized by a hardware circuit. 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 functional units may be realized as one functional unit, or one functional unit may be realized as two or more functional units.

Further, in the following description, when a description is given without distinguishing the same element, a common code among the reference codes is used (for example, DBMS 101). (For example, DBMS 101C, 101S).

Also, hereinafter, the reference numerals of the active server and its constituent elements include “C” meaning the active system, and the reference numerals of the standby server and its constituent elements are “S” meaning the standby system. Including.

FIG. 1 shows a configuration of a database system according to the first embodiment.

The database system includes an active server 100C and a standby server 100S. An in-memory database is realized in each of the active server 100C and the standby server 100S. That is, the memory 117C of the active server 100C stores the DB partitions 109CA and 109CB constituting the DB, and the memory 117S of the standby server 100S also corresponds to the DB partitions 109CA and 109CB and constitutes the DB. 109SA and 109SB are stored. In this embodiment, the DB is divided into two DB partitions, but the DB may be divided into three or more DB partitions. In a state where the active server 100C and the standby server 100S are synchronized, the DB partitions 109SA and 109SB have the same contents (replication) as the DB partitions 109CA and 109CB.

Hereinafter, description will be given mainly using the active server 100C as an example. At least a part of the description of the active server 100C can be applied to the standby server 100S. The elements illustrated for the standby server 100S are elements related to the operation as the standby server 100S, but the standby server 100S operates as the active server by being failed over from the active server 100C. Therefore, although not shown, it can have the same functional units as the active server 100C.

The active server 100C includes a PDEV I / F (interface device) 119C, a network I / F 120C, a memory 117C, and a processor 118C connected thereto. A plurality of local logs PDEV 121C are connected to the PDEV I / V 119C. The local log PDEV 121C is a PDEV that stores a local log file (described later). The local log file (for example, the local log PDEV 121C) and the DB partition 109C may correspond 1: 1. The standby server 100S is connected to the network I / F 120C via a communication medium such as a communication network.

The memory 117C is an example of a storage unit, and includes at least a main memory of a main memory (for example, a volatile memory such as a DRAM (Dynamic Random Access Memory)) and an auxiliary memory (for example, a non-volatile memory such as a flash memory). .

The DBMS 101C is realized by the processor 118C executing a DBMS (Database Management System) program. The DBMS 101C includes a query reception unit 102C, a query execution plan generation unit 103C, a dictionary 104C, an integrated log management unit 105C, and a query execution unit 106C. The DBMC 101C manages the integrated log buffer 115C. The DBMS 101C has an LLSN management unit 111C for each DB partition 109C, and manages a log buffer 113C provided for each DB partition 109C. The processor 118C executes an OS (Operating System) 116C. The DBMS 101C is executed on the OS 116C.

The log buffer 113C temporarily stores a Tx log including the update history of the corresponding DB partition 109C. In this embodiment, the Tx log written in the log buffer 113C is not deleted from the log buffer 113C even if written in the local log PDEV 121C, and is at least acquired by the integrated log management unit 105C (included in the integrated Tx log). To the log buffer 113C. The processing thread 107C and the log buffer 113C may correspond 1: 1.

The LLSN management unit 111C is an example of an order management unit, and manages the LLSN. “LLSN” is an abbreviation for local log sequence number. The LLSN is a number that does not overlap in one DB partition 109C. The LLSN is numbered when outputting the Tx log.

The dictionary 104C is information indicating the position of a database element (for example, a table and an index).

The query receiving unit 102C receives a query issued by a query issuer. The query is described by, for example, a structured query language (SQL, Structured Query Language). A plurality of transactions may be described by one query, and a plurality of transactions may be described by a plurality of queries. The query issuer may be a functional unit in the DBMS 101C or a functional unit outside the DBMS 101C (for example, a client computer (not shown)).

The query execution plan generation unit 103C 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 102C. The query execution plan is information including, for example, a relationship between one or more database operations and the execution order of the database operations, and may be stored as query execution plan information. 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. One or a plurality of transaction sets can be specified from one query execution plan or a combination of a plurality of query execution plans.

The query execution unit 106C executes the query received by the query reception unit 102C according to the query execution plan generated by the query execution plan generation unit 103C, and returns the execution result to the query issuer. At this time, the query execution unit 106C issues a data read request (reference request) necessary for the execution of the database operation, and uses the data read from the DB partition 109C in accordance with the read request, to execute the database operation ( For example, new data is calculated using the read data (value), and a write request for updating the data in the read source record to the calculated data is issued. The query execution unit 106C performs a database operation by executing the processing thread 107C. That is, the processing thread 107C can execute the database operation with reference to the dictionary 104C as appropriate. In the DBMS 101C, a plurality of processing threads 107C are executed in parallel. For this reason, the processor 118C has a plurality of cores. A plurality of cores exist in one or a plurality of processors 118C. The processing thread 107C may be called a task. As the implementation of the processing thread 107C, for example, a user thread realized by a library or the like may be used in addition to a process and kernel thread realized by the OS 116C. One transaction corresponding to one or more database operations may be executed by one processing thread 107C. Hereinafter, the subject of processing performed by the query execution unit 106C executing the processing thread 107C may be the processing thread 107C.

The query execution unit 106C (processing thread 107C) issues an I / O request for the local log PDEV 121C to the OS 116C in order to write a Tx log to the local log file in the local log PDEV 121C during execution of the transaction. The OS 116C accepts the I / O request and issues an I / O request to the local log PDEV 121C.

The PDEV I / F 119C may be provided with a plurality of I / O queues (not shown). In the transaction processing, the processing thread 107C issues an I / O request for writing the Tx log, but the I / O request may be stored in the I / O queue. Specifically, the I / O request may be stored in the I / O queue by the OS 116C.

The local log PDEV 121C stores the local log file. The Tx log to which the I / O request is written is recorded in the local log file.

In this embodiment, the DB partition 109C, the I / O queue, and the local log file may correspond 1: 1: 1. That is, there may be one I / O queue and one local log file for each DB partition 109C. There may be one or more processing threads 107C per local log file. However, it may be possible to reduce the I / O request processing by sending an interrupt for notifying completion of the I / O request to a specific processing thread 107C for each I / O queue. For example, there may be a case where the processing thread 107C, the DB partition 109C, and the I / O queue have a 1: 1 correspondence. In this embodiment, in order to make the explanation easy to understand, the processing thread 107C may also correspond to the local log file 1: 1. For example, the processing thread 107CA issues a Tx log I / O request indicating that a record in the DB partition 109CA has been updated to a local log file corresponding to the DB partition 109CA. The issued I / O request is sent to the OS 116C via the log buffer 113CA. The OS 116C receives the I / O request for the local log file, and stores the I / O request in the I / O queue corresponding to the local log file. The I / O request stored in the I / O queue is sent from the I / O queue to the local log PDEV 121C that stores the local log file of the I / O destination by the OS 116C.

As described above, the plurality of processing threads 107CA and 107CB write Tx logs in the plurality of log buffers 113CA and 113CB, respectively. The integrated log management unit 105C extracts a plurality of Tx logs from the plurality of log buffers 113CA and 113CB, generates one integrated Tx log including the plurality of Tx logs, and stores the integrated Tx log in the integrated log buffer 115C. Write. Then, the integrated log management unit 105C transfers the integrated Tx log written in the integrated log buffer 115C to the standby server 100S. With such a configuration, when writing the Tx log into the log buffer 113C, when writing the integrated Tx log into the integrated log buffer 115C, and when transferring the integrated Tx log to the standby server 100S, There can be no contention, so there is no need to acquire a lock.

The integrated Tx log transferred to the standby server 100S and received by the standby server 100S is written to the integrated log PDEV (PDEV in which the integrated Tx log is stored) 134S through the integrated log buffer 115S by the integrated log management unit 105S. Then, a processing thread (processing thread for log expansion processing) 107S for each DB partition 109S copies the integrated Tx log from the integrated log PDEV 134S to the memory 117S. The processing thread 107S changes the records in the order of the LLSN written in the integrated Tx log by referring to the last Tx log from the first Tx log in the integrated Tx log based on the position information in the integrated Tx log. The update indicated by the history 204 is performed on the corresponding DB partition 109S.

FIG. 2 shows the data structure of the Tx log and the integrated Tx log.

The Tx log 201 may be one per transaction, and the TxID 202 that is the ID of the transaction, one or more LLSNs 203 that are numbered during the execution of the transaction, and the record change that is information representing the update history of the transaction History 204. The number of LLSNs 203 included in the Tx log 201 is the same as the number of DB partitions 109C updated in the execution of one corresponding transaction.

Note that there may be a checkpoint log as the Tx log. The checkpoint log may be a log indicating that a checkpoint has been generated. The checkpoint log may include the TxID of the transaction that generates the checkpoint, all the LLSNs numbered in the generation of the checkpoint, and the ID of the generated checkpoint. When the database is restored, the checkpoint ID can be used to specify the restoration point. Note that the checkpoint ID may be a value representing the time when the checkpoint is generated.

The integrated Tx log 209 includes position information 210 and a plurality of Tx logs 201A, 201B,... Read from the plurality of log buffers 113CA and 113CB, respectively. The position information is at least a part of the header information in the integrated Tx log 209 and includes a plurality of Tx start positions 211A, 211B,... Respectively corresponding to the plurality of Tx logs 201A, 201B,. The Tx start position 211 is information (for example, an address) that is a position in the integrated Tx log 209 and that indicates the start position of the corresponding Tx log 201. In the standby server 100S, the integrated log management unit 105S can identify the positions of the plurality of Tx logs 201A, 201B,... In the integrated Tx log 209 by referring to the plurality of Tx start positions 211A, 211B,. .

Fig. 3 shows an example of log output.

The local log file 211C is stored in the local log PDEV 121C. The Tx log 201 is stored in the local log file 211C. In the local log file 211C, a plurality of Tx logs 201 are arranged sequentially.

Similarly, the integrated log file 219S is stored in the integrated log PDEV 134S. The integrated Tx log 209 is stored in the integrated log file 219S. In the integrated log file 219S, a plurality of integrated Tx logs 209 are arranged sequentially.

Hereinafter, processing performed in this embodiment will be described.

FIG. 4 is a flowchart of the Tx process. In the following description, one transaction A is taken as an example. Therefore, the thread that executes the transaction A is the processing thread 107CA, the DB partitions updated by the transaction A are the DB partitions 109CA and 109CB, and the local log files corresponding to the DB partitions 109CA and 109CB, respectively, are local log files. 211CA and 211CB.

When the transaction A is started, the processing thread 107CA generates a reference / update set for each of the DB partitions 109CA and 109CB based on an instruction corresponding to the transaction A (instruction in the query) (S301). The reference / update set is a set of record reference (read request for partition) and record update (write request for partition). The reference / update set is a request set for updating the partition, but at the time of S301, the DB partitions 109CA and 109CB are not changed, and are allocated in the local memory area (main memory 461) corresponding to the transaction A. The reference / update set is held in a region (not shown).

Next, the processing thread 107CA makes a commit determination (S302). The commit determination is performed according to the isolation level of the database, for example, whether the change to the DB partitions 109CA and 109CB performed by the transaction A based on the reference / update set is consistent with other transactions. .

When the commit determination is NG (S303: No), the processing thread 107CA performs an abort process (S307).

When the commit determination is OK (S303: Yes), the processing thread 107CA executes a log output process (S304). Next, the processing thread 107CA updates the DB partitions 109CA and 109CB based on the reference / update set (S305), issues a commit completion notification to the query issuer (S306), and ends the transaction.

FIG. 5 is a flowchart of the log output process.

The LLSN management unit of the local log file 211CA associated with the processing thread 107CA executing the transaction A is the LLSN management unit 111CA. The processing thread 107CA acquires the log file address from the LLSN management unit 111CA, and adds the log size of the transaction A to the log file address of the LLSN management unit 111CA (S401).

Next, the processing thread 107CA numbers the LLSN of the DB partition 109CA or 109CB updated by executing the transaction A (S402). Depending on the isolation level and data structure of the database, it may be necessary to also assign the LLSN of the partition referenced by the execution of transaction A.

If there is a partition in which the LLSN is not numbered among the updated DB partitions 109CA and 109CB (S403: No), the processing thread 107CA performs S402 on the unnumbered DB partition. On the other hand, if the LLSNs of all the updated DB partitions 109CA and 109CB have been numbered (S403: No), the processing thread 107CA generates the Tx log 201 and writes the Tx log 201 to the log buffer 113CA. Then, a write request for the Tx log 201 (write request specifying the log file address acquired from the LLSN management unit 111CA) is issued (S404). The processing thread 107CA receives a write completion notification from the local log PDEV 121CA via the PDEV I / F 119C (S405).

When the mode is the log synchronization mode (S406: Yes), the processing thread 107CA executes the integrated Tx log writing process (S407), and ends the log output process when the integrated Tx log writing process is completed. When the mode is the log asynchronous mode (S406: No), the processing thread 107CA ends the log output process without executing the integrated Tx log writing process. The “log synchronous mode” is a mode in which the log output process ends when the integrated Tx log write process is executed in the log output process and the integrated Tx log write process ends. The “log asynchronous mode” is a mode in which the integrated Tx log writing process is executed asynchronously with the log output process. The current mode may be registered in the memory 117C. Whether the mode is the log synchronous mode or the log asynchronous mode may be set or changed by the user, or may be dynamically changed depending on the status of the active server 100C. Synchronous mode is used for systems that handle information that should not be lost, such as bank account information such as bank ATMs, and is used in cases where reliability is more important than performance. In synchronous mode, the transaction log is completely identical between the active system and the standby system, so even if a single failure point (single point of failure) occurs, up to which transaction can be processed by referring to either log disk. Whether or not the processing is complete can be reliably determined, and the processing data is not lost. On the other hand, the asynchronous mode is utilized in a system that places importance on response time even if there is a possibility that a log that cannot be copied to the standby system may occur when a failure occurs.

FIG. 6 is a flowchart of the integrated Tx log writing process.

When the mode is the log synchronous mode, the integrated Tx log writing process starts when the processing thread 107CA that executes the transaction A to be executed starts the integrated log management unit 105C. When the mode is the log asynchronous mode, the integrated Tx log writing process starts at a preset interval or when a predetermined event occurs.

The integrated log management unit 105C polls all the log buffers 113C and determines whether Tx logs are stored in two or more log buffers 113C (for example, all log buffers 113C) (S501). If the determination result in S501 is negative (S501: No), the integrated Tx log writing process ends.

If the determination result in S501 is affirmative (S501: Yes), the integrated log management unit 105C performs S502. That is, all Tx logs are acquired from all log buffers 113C in which Tx logs are stored. The integrated log management unit 105C determines a Tx start position 211 (position (address) in the integrated Tx log) for each Tx log based on a plurality of Tx log sizes respectively corresponding to the acquired plurality of Tx logs. Position information 210 including a plurality of Tx start positions 211 respectively corresponding to the Tx logs. The integrated log management unit 105C generates an integrated Tx log 209 including the generated position information 210 and a plurality of acquired and sequentially arranged Tx logs. The integrated log management unit 105C writes the generated integrated Tx log 209 in the integrated log buffer 115C.

Next, the integrated log management unit 105C transfers the integrated Tx log 209 (the integrated Tx log 209 generated in S502) in the integrated log buffer 115C to the standby server 100S through the network I / F 120C (S503).

The standby server 100S receives the integrated Tx log 209, and the integrated log management unit 105S writes the received integrated Tx log 209 in the integrated log file 219S in the integrated log PDEV 134S (S504). When the received integrated Tx log 209 is written in the integrated log file 219S, the integrated log management unit 105S notifies the active server 100C of the reception completion (S505).

The active server 100C receives the notification of reception completion, and the integrated log management unit 105C clears the integrated Tx log 209 from the integrated log buffer 115C in response to the notification, and the processing thread 107C (at least Tx in S502) The processing thread 107C) corresponding to the log buffer 113C of the log acquisition source is notified of the completion of log writing in the standby server 100S (S506). The processing thread 107C that has received the notification clears the Tx log from the log buffer 113C corresponding to the processing thread 107C (S507).

As described above, according to the first embodiment, the processing thread 107C writes the Tx log 201 to the log buffer 113C corresponding to the processing thread 107C. In other words, a dedicated log buffer 113C is provided for each processing thread 107C. Therefore, in the active server 100C, a plurality of Tx can be written in the plurality of log buffers 113C in parallel, and there is no contention for writing to the log buffer 113C. Further, since the integrated Tx log is generated by reading a plurality of Tx logs from the plurality of log buffers 113C and written to the integrated log buffer 115C, there is no contention when the integrated Tx logs are generated / written. In addition, a plurality of Tx logs are serially arranged in the integrated Tx log, and the single integrated Tx log is transferred from the active server 100C to the standby server 100S. Thus, as in the case of parallel transfer of Tx logs. There is no competition that can occur. As described above, in the first embodiment, when writing the Tx log into the log buffer 113C, when writing the integrated Tx log into the integrated log buffer 115C, or when transferring the integrated Tx log to the standby server 100S. In addition, no contention can occur, so there is no need to acquire a lock.

Example 2 will be described. At that time, differences from the first embodiment will be mainly described, and description of common points with the first embodiment will be omitted or simplified.

The integrated Tx log includes a Tx log that does not need to be referred to by the processing thread 107S, specifically, a Tx log that includes an update history of a DB partition 109S different from the DB partition 109S corresponding to the processing thread 107S. ing. In the first embodiment, when the integrated Tx log is reflected in the standby server 100S, the processing thread 107S of each DB partition 109S refers to all the Tx logs of the integrated Tx log. For this reason, it takes time to restore the DB partition 109S. Particularly in an in-memory database, it is desirable to shorten the database restoration time as much as possible.

Therefore, in the second embodiment, in reflecting the integrated Tx log, the processing thread refers to only the Tx log related to the update of the DB partition corresponding to the processing thread among the plurality of Tx logs in the integrated Tx log. It is possible to skip Tx logs that are not related to the update of the DB partition corresponding to the processing thread. For this reason, the database restoration time can be shortened.

Hereinafter, Example 2 will be described in detail. In the following description, elements different from those in the first embodiment are denoted by reference numerals different from those in the first embodiment.

FIG. 7 shows the configuration of the database system according to the second embodiment.

In the memory 127C of the active server 100C, the DBMS 1010C manages the partition access map 151C for each processing thread 1070C. The partition access map 151C is information indicating the DB partition 109C updated by the corresponding processing thread 1070C.

FIG. 8 shows the data structure of the integrated Tx log according to the second embodiment.

The location information 2100 of the integrated Tx log 2090 includes a partition access map 151C in addition to the Tx start location 211 for each Tx log 201. With this configuration, for example, the processing thread (processing thread for log expansion processing) 1070SA determines whether or not the partition access map 151CA indicates the update of the DB partition 109SA. When the determination result is affirmative, the processing thread 1070 Sk updates the DB partition 109SA according to the Tx log 201A specified from the Tx start position 211A. On the other hand, if the determination result is negative, the processing thread 1070 Sk skips reading the Tx start position 211A (Tx log 201A).

FIG. 9 shows the configuration of the partition access map 151C.

The partition access map 151C is a bitmap. The partition access map 151C is composed of a plurality of bits respectively corresponding to the plurality of DB partitions 109C. Bit “1” means that the DB partition 109 corresponding to the bit has been updated. Bit “0” means that the DB partition 109 corresponding to the bit has not been updated.

The bit map is an example of the partition access map 151C. The partition access map 151C may have another configuration, for example, a list of updated DB partition 109C IDs.

FIG. 10 is a flowchart of the log output process according to the second embodiment.

The processing thread 1070S updates the bit corresponding to the updated DB partition 109C in the partition access map 151C corresponding to the processing thread 1070S to “1” for each DB partition 109C updated in the transaction processing (S441). Others are the same as in the first embodiment.

FIG. 11 is a flowchart of the integrated Tx log writing process according to the second embodiment.

S5020 is performed instead of S502. In S5020, all Tx logs are acquired from all log buffers 113C in which Tx logs are stored. The integrated log management unit 105C determines a Tx start position 211 (position (address) in the integrated Tx log) for each Tx log based on a plurality of Tx log sizes respectively corresponding to the acquired plurality of Tx logs. The integrated log management unit 1050C includes a plurality of partition access maps 151C corresponding to the plurality of Tx logs in addition to the plurality of Tx start positions 211 respectively corresponding to the plurality of Tx logs included in the integrated Tx log. Information 2100 is generated. The integrated log management unit 1050C generates an integrated Tx log 2090 that includes the generated position information 2100 and a plurality of acquired and sequentially arranged Tx logs. The integrated log management unit 1050C writes the generated integrated Tx log 2090 in the integrated log buffer 115C. Others are the same as in the first embodiment.

FIG. 12 is a flowchart of the integrated Tx log reflection process.

The integrated Tx log reflection process may be started, for example, when the administrator of the standby server 100S is instructed to start the integrated Tx log reflection process, or when the integrated Tx log is stored in the integrated log PDEV 134S. May be started. The plurality of processing threads (log development processing thread) 1070S are executed in parallel, for example, and the following processing is performed for each processing thread 1070S.

The processing thread 1070S reads the integrated Tx log from the integrated log PDEV 134S to the work area of the processing thread 1070S (S1201).

Each processing thread 1070S refers to the first partition access map 151C in the integrated Tx log stored in the work area, and determines whether the partition access map 151C indicates the update of the DB partition 109S (S1202). .

If the determination result in S1202 is affirmative, the processing thread 1070S performs a reflection process of the Tx log 201 specified from the Tx start position 211x corresponding to the partition access map 151C (S1203). Specifically, the processing thread 1070S refers to the identified Tx log 201, and updates the DB partition 109Sk according to the referenced Tx log 201k.

If the determination result in S1202 is negative, the processing thread 1070S skips the Tx start position 211 (Tx log 201) corresponding to the referenced partition access map 151C (S1204).

Next to S1203 or S1204, the processing thread 1070S determines whether or not the partition access map 151C referenced in the immediately preceding 1202 is the last partition access map 151C (S1205).

If the determination result in S1205 is affirmative, the processing thread 1070S finishes reflecting the integrated Tx log.

If the determination result in S1205 is negative, the processing thread 1070S performs S1202 for the next partition access map 151C.

As described above, according to the second embodiment, in the integrated Tx log reflection process, the processing thread 1070S selects only the Tx log related to the update of the DB partition corresponding to the processing thread 1070S among the plurality of Tx logs in the integrated Tx log. The Tx log that is not related to the update of the DB partition corresponding to the processing thread 1070S can be skipped. For this reason, the database restoration time can be shortened.

Although several embodiments have been described above, they are merely examples for explaining the present invention, and the scope of the present invention is not limited to these embodiments. The present invention can be implemented in various other forms.

For example, the Tx log may be deleted from the log buffer 113C when it is written from the log buffer 113C to the local log PDEV 121C. In this case, the integrated log management unit 105C may acquire a Tx log to be included in the integrated Tx log (a Tx log that has not been included in the integrated Tx log) from the local log PDEV 121C in the integrated Tx log writing process. .

Also, for example, the case where the LLSN is numbered may be a case where a set of transactions executed between checkpoints is at least a first type transaction set of a first type transaction set and a second type transaction set. The first type transaction set may be a set of transactions whose results change depending on the transaction execution order. For example, according to the partial order, a plurality of transactions that update the same record must be executed in a defined order, but a plurality of transactions that update different records may be executed in any order. The second type transaction set may be a transaction set in which the execution order of transactions does not affect the result. Whether the transaction to be executed belongs to the first type or the second type transaction set may be determined from one or a plurality of query execution plans, for example.

Also, for example, the LLSN (order) managed by the LLSN management unit 111C may be updated each time a Tx log of a transaction in which the DB partition 109C corresponding to the LLSN management unit 111C is updated is generated. M Tx logs may be generated (M is N or less and M is an integer of 1 or more) as a transaction log (N is an integer of 2 or more) that updates N DB partitions 109C among a plurality of DB partitions 109C. ). At least one of the M Tx logs may include two or more LLSNs among the N LLSNs respectively corresponding to the N DB partitions 109C. Of the N log buffers 113C corresponding to the N DB partitions 109C, the Tx log including one LLSN is written to the log buffer 113C corresponding to the LLSN and includes two or more LLSNs. The Tx log may be written in any one of two or more log buffers 113C corresponding to two or more LLSNs. M = 1 may be sufficient.

100C: Active server 100S: Standby server

Claims

Having at least the active server of the active server and the standby server connected to the active server,
The active server is
A plurality of first sub-execution units that execute a plurality of transactions for the first database, generate a plurality of logs corresponding to the plurality of transactions, and write the generated logs to a plurality of log storage areas, respectively, are executed in parallel. A first execution unit;
A database having an integrated log management unit that reads the plurality of logs from the plurality of log storage areas, generates an integrated log including the read logs, and transfers the generated integrated log to the standby server system.
Each of the plurality of first sub-execution units may update two or more first database portions by executing a transaction among the plurality of first database portions that are the divided first databases,
Each of the plurality of first sub-execution units executes an update partial map corresponding to the sub-execution unit among the plurality of update partial maps respectively corresponding to the plurality of sub-execution units, and the sub-execution unit executes a transaction. Update the first database part updated in step 1 to the identifiable information,
The integrated log includes a plurality of updated partial maps corresponding to the plurality of logs in addition to the plurality of logs,
The database system according to claim 1.
Further comprising the standby server,
The standby server manages a plurality of second database parts that are divided second databases,
The standby server has a second execution unit that executes a plurality of second sub-execution units in parallel,
The plurality of second database portions correspond to the plurality of first database portions, respectively.
Each of the plurality of second sub execution units, for each update partial map in the integrated log,
Refer to the update partial map in the unified log,
When it is determined from the referenced update part map that the first database part corresponding to the second database part corresponding to the second sub-execution unit has been updated, the reference among the plurality of logs in the unified log The second database part corresponding to the second sub-execution unit is updated in accordance with the referred log.
When it is determined from the referenced update part map that the first database part corresponding to the second database part corresponding to the second sub-execution part has not been updated, the plurality of logs in the unified log Do not refer to the log corresponding to the referenced update partial map,
The database system according to claim 2.
For each of a plurality of first database portions that are the first database divided, an order management unit that manages the order of logs,
The order managed by each order management unit is updated each time a transaction log generated by updating the first database part corresponding to the order management unit is generated.
M logs are generated (N is an integer equal to or greater than N, where M is an integer equal to or greater than 1) as a log of transactions in which N of the first database portions are updated (N is an integer greater than or equal to 2). ),
At least one of the M logs includes two or more orders of N orders corresponding to the N first database parts, respectively.
The database system according to claim 1.
There are N log storage areas respectively corresponding to the N first database parts,
Logs containing one order are written to the log storage area corresponding to the order,
The log including the two or more orders is written in one of two or more log storage areas respectively corresponding to the two or more orders.
The database system according to claim 4.
M = 1
The database system according to claim 4.
In the integrated log, a plurality of logs are serially arranged.
The database system according to claim 1.
The active server has a first memory;
The standby server has a second memory;
The first database is stored in the first memory;
The second database is stored in the second memory;
The database system according to claim 3.
A plurality of transactions for the first database managed by the active server are executed in parallel, a plurality of logs corresponding to the plurality of transactions are generated in parallel, and the generated logs are respectively stored in a plurality of log storage areas. Write in parallel,
Reading the plurality of logs from the plurality of log storage areas, generating an integrated log including the plurality of read logs, and transferring the generated integrated log to a standby server;
Database management method.
An interface device connected to the standby server;
A storage unit storing a first database and having a plurality of logable areas;
A processor connected to the interface device and the storage unit;
The processor is
By executing a plurality of threads in parallel, a plurality of transactions for the first database are executed, a plurality of logs corresponding to the plurality of transactions are generated, and the generated logs are stored in the plurality of logs. Write to each area,
Reading the plurality of logs from the plurality of log storage areas, generating an integrated log including the plurality of read logs, and transferring the generated integrated log to the standby server;
calculator.