WO2015111152A1 - データベース管理システム及び方法 - Google Patents

データベース管理システム及び方法 Download PDF

Info

Publication number
WO2015111152A1
WO2015111152A1 PCT/JP2014/051263 JP2014051263W WO2015111152A1 WO 2015111152 A1 WO2015111152 A1 WO 2015111152A1 JP 2014051263 W JP2014051263 W JP 2014051263W WO 2015111152 A1 WO2015111152 A1 WO 2015111152A1
Authority
WO
WIPO (PCT)
Prior art keywords
log
database
transaction
order
checkpoint
Prior art date
Application number
PCT/JP2014/051263
Other languages
English (en)
French (fr)
Inventor
敦 友田
有哉 礒田
一智 牛嶋
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to JP2015558634A priority Critical patent/JP6152431B2/ja
Priority to DE112014002275.6T priority patent/DE112014002275T5/de
Priority to GB1521129.5A priority patent/GB2537446A/en
Priority to US14/894,042 priority patent/US10366075B2/en
Priority to PCT/JP2014/051263 priority patent/WO2015111152A1/ja
Publication of WO2015111152A1 publication Critical patent/WO2015111152A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2365—Ensuring data consistency and integrity
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/23—Updating
    • G06F16/2358—Change logging, detection, and notification
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/10—File systems; File servers
    • G06F16/18—File system types
    • G06F16/1805—Append-only file systems, e.g. using logs or journals to store data
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F16/00—Information retrieval; Database structures therefor; File system structures therefor
    • G06F16/20—Information retrieval; Database structures therefor; File system structures therefor of structured data, e.g. relational data
    • G06F16/24—Querying
    • G06F16/245—Query processing
    • G06F16/2455—Query execution

Definitions

  • the present invention generally relates to database management, for example, to output of transaction processing logs.
  • DBMS database management system
  • main data such as tables and indexes
  • HDD Hard Disk Drive
  • a disk database and an in-memory database in which the database is arranged in a main memory are known (a hybrid DBMS combining an on-disk database and an in-memory database is also known).
  • Logs are generally output to a single log file when a transaction is executed. Even if transactions are processed in parallel by a plurality of cores (or a plurality of CPUs (Central Processing Units)), a log output destination is a single log file. For this reason, log output becomes a bottleneck.
  • cores or a plurality of CPUs (Central Processing Units)
  • CPUs Central Processing Units
  • Patent Document 1 a log file is prepared for each distributed database, and a log including a database update history is output to a log file corresponding to the database among a plurality of log files.
  • the in-memory database can divide the database into multiple partitions and manage each partition.
  • a log file is prepared for each partition managed by the in-memory database, and a log including a partition update history is output to a log file corresponding to the partition. be able to.
  • Patent Document 1 when the technique of Patent Document 1 is simply applied to the in-memory database, I / O requests several times the number of transactions are generated to the storage apparatus. This is because partitions are defined in advance, and it is inevitable that data of multiple partitions may be referred to and updated in transaction processing. In this case, even if one transaction is processed, This is because a log must be output to each of a plurality of log files corresponding to a plurality of partitions.
  • Such a problem is not limited to the in-memory database, and may be applied to another DBMS that manages a divided database or another DBMS that manages a single database.
  • the DBMS generates a transaction log for each transaction in the execution of a plurality of transactions, and stores the generated log in the log storage area.
  • the DBMS records the order of logs in at least a log generated for transactions belonging to a set of transactions that have different results depending on the transaction execution order.
  • the transaction execution order can be specified for a set of transactions with different results depending on the transaction execution order . For this reason, even if the number of logs generated for one transaction in which two or more database parts of a plurality of database parts into which the database is divided is updated is smaller than the number of updated database parts, Based on the stored log, it is possible to specify the execution order (for example, a partial order) of transactions.
  • FIG. 1 shows a configuration of a computer system according to an embodiment.
  • An example of a transaction set is shown. It is a functional block diagram of the computer system which concerns on an Example. The structure of a LLSN management part is shown. Indicates the data structure of the log. Shows the data structure of the checkpoint log.
  • An example of a transaction set is shown. The table before and after execution of the transaction set is shown. An example of the log output which concerns on an Example is shown. An example of the log output which concerns on the comparative example 1 is shown. An example of the log output which concerns on the comparative example 2 is shown.
  • the same reference numbers for the same type of elements include the same parent number.
  • the reference numerals of the elements are used (for example, partitions 111A, 111B, etc.
  • the parent of the reference signs of the elements Only numbers may be used (eg, partition 111).
  • the process may be described using “program” as a subject, but the program is executed by the processor so that the determined process can be appropriately performed with storage resources (for example, memory) and / or Since the processing is performed using a communication interface device or the like, the subject of processing may be a processor.
  • the processing described with the program as the subject may be processing performed by a processor or an apparatus (for example, a database server) having the processor.
  • the processor may include a hardware circuit that performs part or all of the processing.
  • the program may be installed on each controller from a program source.
  • the program source may be, for example, a program distribution computer or a storage medium.
  • FIG. 1 shows a configuration of a computer system according to the embodiment.
  • An external storage device 402 is connected to the database server 401 via, for example, a communication network 403.
  • 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 413, a 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 dedicated hardware circuitry.
  • 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.
  • OS operating system
  • DBMS database management system
  • the main memory 416 is, for example, a volatile DRAM (Dynamic Random Access Memory), 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.
  • the I / O adapter 413 connects the communication network 403 and the database server 401.
  • 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.
  • 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.
  • 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.
  • 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.
  • 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 an example of a transaction set.
  • This figure shows an example of a transaction executed between two checkpoints 1 and 2.
  • Each transaction executed in this embodiment is classified into either a first type transaction set or a second type transaction set.
  • the first type transaction set is a set of transactions whose results change depending on the transaction execution order.
  • a partial order is defined. According to the partial order, for example, 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 is 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 second type transaction set can be determined from one or a plurality of query execution plans, for example.
  • FIG. 3 is a functional block diagram of the computer system according to the embodiment.
  • the DBMS 412 is an in-memory database.
  • the DBMS 412 divides the database into a plurality of partitions 111 (for example, three partitions 111A to 111C) and arranges them on the main memory 416.
  • Each partition 111 includes a portion of a database, eg, a table 112 that is a portion of a table in the database, and an index 113 that is a portion of an index in the database.
  • data can be specified from the table 112 (for example, 112A) in the partition 111 using the index 113 (for example, 113A) in the partition 111.
  • Data included in one table 112 may be specified only from the index 113 in the partition 111 including the table 112.
  • Each partition 111 may include a lock mechanism 116. This is to prevent two or more threads 110 from competing for the same partition 111.
  • the lock mechanism 116 may be information indicating whether or not the partition 111 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 lock mechanism 116 may be associated with the partition 111 and may be outside the partition 111.
  • the DBMS 412 has a log buffer 114 and an LLSN management unit 115 for each partition 111.
  • the log buffer 114 temporarily stores a log including the update history of the partition 111.
  • the LLSN management unit 115 manages the LLSN.
  • “LLSN” is an abbreviation for local log sequence number.
  • the LLSN is a number that does not overlap in one partition 111.
  • the LLSN is numbered when outputting a log of transactions belonging to the first type transaction set (transaction set whose result changes depending on the transaction execution order).
  • the LLSN may be numbered when outputting a log of transactions belonging to the second type transaction set as well as the first type transaction set.
  • the DBMS 412 receives a query from a query issuer, and executes one or more transactions in executing the received query.
  • 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 by, for example, a structured query language (SQL, 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 computer program inside the DBMS 412 or a computer program outside the DBMS 412.
  • the external computer program may be a computer program (for example, an application program) executed in the database server 401 or a computer program (for example, a client computer connected to the database server 401) (for example, Application program).
  • 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. From one query execution plan or a combination of a plurality of query execution plans, it is possible to specify one or a plurality of transaction sets and whether each transaction set is a first type or a second type transaction set. .
  • 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 partition 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.
  • the thread 110 may be called a task.
  • 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 117.
  • One thread 110 may execute one transaction corresponding to one or more database operations.
  • the subject of processing performed when the query execution unit 424 executes the thread 110 may be referred to as 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 the transaction.
  • the OS 117 accepts the I / O request and issues an I / O request to the external storage apparatus 402.
  • a plurality of I / O queues 201 are prepared.
  • the thread 110 issues an I / O request for writing a log.
  • the I / O queue 201 stores the I / O request.
  • the I / O request is stored in the I / O queue 201 by the OS 117.
  • External storage device 402 stores a plurality of log files 301 (301A to 301C).
  • a log to which an I / O request is written is recorded.
  • the partition 111, the I / O queue 201, and the log file 301 have a 1: 1: 1 correspondence. That is, there is one I / O queue 201 and one log file 301 for each partition 111.
  • the partition 111A is associated with the I / O queue 201A and the log file 301A
  • the partition 111B is associated with the I / O queue 201B and the log file 301B
  • the partition 111C is associated with the I / O queue 201C and A log file 301C is associated.
  • the thread 110 may also correspond to the log file 301 in a 1: 1 manner for easy understanding.
  • the thread 110A issues a log I / O request indicating that a record in the table 112A in the partition 111A has been updated to the log file 301A corresponding to the partition 111A.
  • the issued I / O request is sent to the OS 117 via the log buffer 114A.
  • the OS 117 receives an I / O request for the log file 301A, and stores the I / O request in the I / O queue 201A corresponding to the log file 301A.
  • the I / O request stored in the I / O queue 201A is sent from the I / O queue 201 to the external storage apparatus 402 by the OS 117.
  • the log that is the write target data of the I / O request is written to the log file 301A.
  • the configuration of the DBMS 412 shown in FIG. 3 is merely an example.
  • a certain component may be divided into a plurality of components, and a plurality of components may be integrated into one component.
  • FIG. 4 shows the configuration of the LLSN management unit 115.
  • the LLSN management unit 115 includes a lock mechanism 121, an LLSN 122, and a log file address 123.
  • the lock mechanism 121 may be data indicating whether or not the lock of the LLSN management unit 115 has been acquired. 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.
  • LLSN 122 is a log sequence number (LLSN) for the partition 111 including the LLSN management unit 115.
  • the LLSN is a combination of the ID of the LLSN management unit 115 and a serial number.
  • the value represented by the LLSN 122 is updated as 1-001, 1-002, 1-003.
  • the LLSN is a combination of the ID “1” of the LLSN management unit 115A and the updated serial number.
  • the log file address 123 is a log write destination address in the log file 301 corresponding to the partition 111 including the LLSN management unit 115.
  • the address (value) represented by the log file address 123 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 the data structure of the log.
  • the log may be one per transaction, and includes a transaction ID, one or more LLSNs numbered during the execution of the transaction, and information indicating the update history of the transaction.
  • the number of LLSNs included in the log is the same as the number of partitions 111 updated in the execution of the transaction.
  • Fig. 6 shows the data structure of the checkpoint log.
  • the checkpoint log is a log indicating that a checkpoint has been generated.
  • the checkpoint log includes the ID of the transaction that generates the checkpoint, all the LLSNs that are numbered in the generation of the checkpoint, and the ID of the generated checkpoint.
  • the checkpoint ID can be used to specify the time point for recovery. Note that the checkpoint ID may be a value representing the time when the checkpoint is generated.
  • FIG. 7 shows an example of a transaction set.
  • FIG. 8 shows the tables 112A and 112B before and after the execution of the transaction set.
  • the transaction is abbreviated as “Tr.”.
  • a record has a row ID and Val (value).
  • a record with a row ID: X is called a record X
  • a record with a row ID: Y is called a record Y.
  • the transaction set shown in FIG. 7 is a first type of transaction set, that is, a set of transactions whose results change depending on the transaction execution order. Records X and Y are updated by the transaction set.
  • record X is a record in table 112A in partition 111A
  • record Y is a record in table 112B in another partition 111B.
  • Val (value) in the record X is “100”
  • Val (value) in the record Y is also “100”.
  • Val (value) in the record X is updated to “110”
  • Val (value) in the record Y is updated to “122”.
  • the results of transactions A, B, and E vary depending on the execution order. This is because they are transactions for updating the same record X.
  • the results of transactions A, C, and D change depending on the execution order. This is because they are transactions for updating the same record Y.
  • the following method can be considered as a method for recording the minimum necessary order relation.
  • a transaction executed between an arbitrary checkpoint 1 and a checkpoint 2 generated after checkpoint 1 and belonging to the first type of transaction set execution of transaction
  • the order according to the committed order log generation order
  • the order is not recorded in the log of transactions belonging to the second type of transaction set (transactions that only need to be executed between checkpoint 1 and checkpoint 2 without depending on the execution order between transactions). .
  • a semi-order can be defined for the log of the first type of transaction set.
  • an LLSN is assigned to each updated partition 111 in the execution of one transaction.
  • the LLSN numbered for one partition 111 is a sequence number for that partition 111 and is not related to the LLSN for the other partition 111.
  • a series of LLSNs are numbered for each partition 111, and the numbered LLSNs are recorded in a log, thereby defining a partial order for the first type of transaction set.
  • the log is output as follows. That is, as described above, the partition 111 and the log file 301 are prepared in a 1: 1 ratio, and the log including the update history of the partition 111 is written in the log file 301 corresponding to the partition 111.
  • N partitions 111 (N is an integer of 2 or more) may be updated in the execution of one transaction.
  • N log files respectively corresponding to the N partitions 111 are stored.
  • N the number of partitions 111 updated in the execution of one transaction
  • one of the updated partitions 111 corresponds to one partition 111.
  • a log is written in one log file 301.
  • N LLSNs respectively corresponding to the updated N partitions are written in the log.
  • FIG. 9 shows an example of log output according to the embodiment.
  • the LLSN of the partition 111A is 1-201 and the LLSN of the partition 111B is 2-100 before execution of the transaction set shown in FIG.
  • this is only an example and does not exclude other values.
  • both the record X of the partition 111A and the record Y of the partition 111B are updated.
  • the LLSN of each of the LLSN management units 115A and 115B is incremented by 1.
  • the LLSN of the LLSN management unit 115A may be 1-202
  • the LLSN of the LLSN management unit 115B may be 2-101.
  • the log output destination is one of the log files 301A and 301B respectively corresponding to the partitions 111A and 111B (for example, even if the output destination is sequentially switched by round robin) Either or may be predetermined).
  • the log is output to the log file A.
  • the log file address is acquired from the LLSN management unit 115A, and a value corresponding to the size of the log to be output is added to the log file address in the LLSN management unit 115A.
  • the thread 110A stores the log 901A in the log buffer 114A, and issues a write request specifying the acquired log file address with the log 901A as a write target.
  • the OS 117 receives the write request, writes the write request to the I / O queue 201A corresponding to the log file 301A, and transmits the write request from the I / O queue 201A to the external storage apparatus 402.
  • the external storage apparatus 402 receives the write request, writes the log 901A to be written in accordance with the write request to the log file 301A, and returns a write request completion response.
  • the completion response returns to the DBMS 412 through the OS 117.
  • To the log file 301B (acquired log file address) corresponding to the partition 111B.
  • LLSN 1-103 and 2-103 are assigned from the LLSN management units 115A and 115B, respectively, and a log 901E including the assigned LLSN is stored in the log file. 301B is written.
  • the order of transaction A-> B-> E and transaction A-> C-> D-> E can be recovered by referring to the LLSN in each log.
  • the fact that the first LLSN is larger than the second LLSN means that the first LLSN is numbered (in the future) after the second LLSN.
  • the first LLSN being greater than the second LLSN may mean that the first LLSN has been numbered (in the past) before the second LLSN. That is, it is only necessary that the order relationship can be specified from the LLSN size relationship.
  • an order relationship between transactions (which is expressed as “ ⁇ ” for convenience) is defined by the LLSN magnitude relationship of any one LLSN management unit 115
  • a partial order is set in the set of all transactions with some exceptions. Determined.
  • the LLSN of the LLSN management unit 115A is arranged in the order of transactions A-> B (A ⁇ B)
  • the LLSN of the LLSN management unit 115B is arranged in the order of transactions B-> A (B ⁇ A).
  • the order is not defined between transactions A and B.
  • the execution order of transactions A and B may be either.
  • FIG. 10 shows an example of log output according to Comparative Example 1.
  • Comparative Example 1 is an example in which five logs corresponding to five transactions A to E are output to a single log file.
  • logs are output to a log file in the order of transaction execution. In this case, even if two or more transactions are executed in parallel, log output is executed sequentially, and competition between I / O resources (for example, a single I / O queue corresponding to a single log file) between transactions. Will occur.
  • a plurality of log files are prepared, and a plurality of I / O resources (for example, I / O queues) respectively corresponding to the plurality of log files are prepared.
  • I / O resources for example, I / O queues
  • FIG. 11 shows an example of log output according to Comparative Example 2.
  • Comparative Example 2 is an example of log output performed in a distributed database. For transactions that update only one of the partitions 111A and 111B, such as transactions B, C, and D, log output is the same as in the embodiment. However, for transactions that update both partitions 111A and 111B, such as transaction A (and E), the same number of logs as the updated partitions are output to the same number of log files. For this reason, the number of log I / Os is larger than in the embodiment.
  • the number of logs written even if a transaction updates a plurality of partitions is smaller than the number of updated partitions. Therefore, the number of log I / Os can be suppressed.
  • the order may not be defined depending on the transaction. For example, it is indefinite on the log which transaction B and transaction C completed the transaction execution first. Therefore, in general, the database cannot be recovered to any state other than the latest state. Thus, in this embodiment, as described above, it is possible to record and recover the state of the database at a certain point in time by generating checkpoints.
  • FIG. 12 is a flowchart of transaction processing.
  • the thread executing the transaction A is the thread 110A
  • the partitions updated by the transaction A are the partitions 111A and 111B
  • the log files corresponding to the partitions 111A and 111B are the log files 301A and 301B, respectively.
  • the thread 110A When the transaction A is started, the thread 110A generates a reference / update set for each of the partitions 111A and 111B 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 partitions 111A and 111B are not changed, and the local memory area corresponding to the transaction A (reserved on the main memory 461) A reference / update set is held in a region (not shown).
  • the thread 110A makes a commit determination (S302).
  • the commit determination is performed, for example, according to the isolation level of the database as to whether or not the change to the partitions 111A and 111B performed by the transaction A based on the reference / update set is consistent with other transactions.
  • the thread 110A executes a log output process (S304).
  • the thread 110A updates the partitions 111A and 111B based on the reference / update set (S305), issues a commit completion notification (S306), and ends the transaction.
  • FIG. 13 is a flowchart of the log output process (S304 in FIG. 12).
  • LLSN management unit 115 of log file 301A associated with thread 110A executing transaction A is LLSN management unit 115A.
  • the thread 110A acquires the log file address from the LLSN management unit 115A, and adds the log size of the transaction A to the log file address of the LLSN management unit 115A (S401). Note that before this series of operations, the thread 110A acquires the lock of the LLSN management unit 115A and releases the lock after the operation.
  • the thread 110A selects an arbitrary LLSN management unit 115 and performs the same processing on the selected LLSN management unit 115. However, in order to avoid a deadlock in the recovery process described later, a log needs to be written in the log file 301 corresponding to the LLSN management unit 115 operated in S401.
  • the thread 110A numbers the LLSN of the partition 111A or 111B updated by the execution of the transaction A (S402). Depending on the isolation level and data structure of the database, it may be necessary to assign the LLSN of the partition referenced by the execution of transaction A.
  • the thread 110A performs S402 on the unnumbered partition.
  • the thread 110A generates a log 901A (see FIG. 9) and writes the log 901A to the log buffer 114A.
  • a write request for the log 901A (write request specifying the log file address acquired from the LLSN management unit 115A) is issued (S404).
  • the thread 110A receives a write completion notification from the external storage apparatus 402 via the I / O adapter 413, the thread 110A sets the write completion (S405), and ends the log output flow.
  • FIG. 14 is a flowchart of the checkpoint generation process. In the description of FIG. 14, it is assumed that the thread that generates the checkpoint is the thread 110A.
  • Thread 110A first prohibits starting a new commit (S501). Specifically, the thread 110A previously sets a flag bit indicating prohibition of new commit in the thread sharing area, and sets the initial value to 0. The thread 110A changes the flag bit to 1 when prohibiting the start of a new commit. The thread that executes the transaction checks the flag bit at the start of execution of the commit process, and executes the commit process only when the flag bit is 0. When the flag bit is 1, the flag bit is changed to 0. Wait until. After the new commit start prohibition process of the thread 110A, any thread 110 cannot start commit, and the commit proceeds only for the transaction being committed.
  • the thread 110A waits until the number of transactions being committed reaches 0 (S502: No). When the number of transactions being committed becomes 0 (S502: Yes), the thread 110A assigns an LLSN and logs from the LLSN management unit 115 (eg, 115A) corresponding to the arbitrarily selected log file 301 (eg, 301A). A file address is acquired, and a value corresponding to the size of the checkpoint log is added to the log file address in the LLSN management unit 115 (for example, 115A) (S503).
  • the LLSN management unit 115 for example, 115A
  • the thread 110A numbers all the LLSNs corresponding to the remaining log files (S504).
  • the thread 110A completes a checkpoint log including the LLSN numbered in S503, the LLSN numbered in S504, and the checkpoint ID.
  • the thread 110 ⁇ / b> A sends a log write request specifying the log file address acquired in S ⁇ b> 503 (the write target is the completed checkpoint log) to the log buffer 114 (for example, 301 ⁇ / b> A) corresponding to the arbitrarily selected log file 301 (for example, 301 ⁇ / b> A).
  • 114A a log write request is issued from the log buffer 114 (for example, 114A) (S505).
  • the thread 110A determines whether or not a condition for backing up the database is satisfied (S506).
  • the condition may be that the number of checkpoint generations has reached N (N is a natural number), or that a fixed time has elapsed since the last backup time.
  • the thread 110A can include the database backup, that is, the database (the table 112 and the index 113 of each partition 111) on the main memory 416 in the checkpoint log.
  • the database (image) associated with the checkpoint ID and associated with the checkpoint ID is stored in the external storage device 402 (S507). This action is not necessary at every checkpoint. However, by backing up the database when writing the checkpoint log, the database at the time of checkpoint generation (or the database near the time of the checkpoint) can be recovered at high speed.
  • checkpoint management information including the correspondence between the backed up database (image), the checkpoint ID, and the write destination address of the checkpoint log including the checkpoint ID is determined by the thread.
  • the data may be stored in a storage area inside or outside the database server 401 (for example, the main memory 416).
  • the thread 110A cancels the prohibition of starting a new commit (S508), and the checkpoint generation process ends. Specifically, the thread 110A changes the flag bit indicating prohibition of new commit from 1 to 0.
  • FIG. 15 is a flowchart of database recovery processing (parent). In the description of FIG. 15 (and FIG. 16), it is assumed that the thread for recovering the database is the thread 110A.
  • the thread 110A is a database (backup image) associated with the checkpoint ID of the specified checkpoint, or a check generated in the past from the checkpoint ID of the specified checkpoint.
  • a database (backup image) associated with the point ID is loaded from the external storage apparatus 402 onto the main memory 416 (S601).
  • the checkpoint ID may be specified by a query received from the query issuer, or may be specified by a computer (not shown) connected to the database server 401 (for example, a management computer).
  • the thread 110A acquires a checkpoint log including a checkpoint ID associated with the database from the log address (log file), and acquires each LLSN in the log.
  • the LLSN of the LLSN management unit 115 in the partition 111 corresponding to the LLSN is set (S602). For example, the LLSN with the leading number 1 is set as the LLSN of the LLSN management unit 115A, and the LLSN with the leading number 2 is set as the LLSN of the LLSN management unit 115B.
  • the thread 110A performs a recovery process (child) on the thread 110 corresponding to each partition 111. This is executed (S604). For the partition 111A, the thread 110A also executes a recovery process (child). The thread 110A waits for the end of all recovery processing (child) (S605: Yes), and ends the recovery processing (parent).
  • the thread 110A performs the recovery process (parent) without performing S604 and 605. Exit. This is because the database loaded in S601 is a database to be recovered.
  • FIG. 16 is a flowchart of database recovery processing (child).
  • the recovery process (child) is executed for each partition 111.
  • the recovery process (child) will be described by taking one partition 111B as an example.
  • the thread 110B acquires the LLSN (LLSN in the LLSN management unit 115B) set in the recovery process (parent) as the LLSN at the time of backup (S700).
  • LLSN LLSN in the LLSN management unit 115B
  • the log including the LLSN is referred to as “post-backup log”.
  • the post-backup log including the largest LLSN among the post-backup logs may be the end log of the log file 301B.
  • post-backup logs there may be a post-backup log including LLSN other than the LLSN of the partition 111B in addition to the LLSN of the partition 111B.
  • the LLSN of the partition 111B is referred to as “corresponding LLSN”
  • the LLSN other than the LLSN of the partition 111B is referred to as “non-corresponding LLSN”.
  • the thread 110B identifies the post-backup log including the smallest relevant LLSN among the unprocessed post-backup logs in the log file 301B corresponding to the partition 111B (S701).
  • target log the post-backup log specified in S701 is referred to as “target log”.
  • the thread 110B indicates that the corresponding LLSN in the target log is the next corresponding LLSN of the corresponding LLSN in the post-backup log processed in the previous S705 or S706 (for example, the post-backup log processed in the previous S705 or S706). It is determined whether or not the corresponding LLSN is a corresponding LLSN obtained by adding 1 (S702).
  • the thread 110B determines whether or not a non-corresponding LLSN is included in the target log.
  • the thread 110B executes the update for the partition 111B to the partition 111B in the update history in the target log, and does not copy the target log. Transfer to the thread corresponding to the partition corresponding to the corresponding LLSN (thread executing the recovery process (child) of the partition corresponding to the non-corresponding LLSN) (S705). For example, when the leading number of the non-applicable LLSN is 1, a copy of the target log is transferred to the thread 110A. When the number of non-corresponding LLSNs is two or more, the copy of the target log is transferred to a thread corresponding to two or more partitions corresponding to two or more non-corresponding LLSNs.
  • the thread 110B determines whether an unprocessed post-backup log still remains after S705 or S706 (S707). If there is an unprocessed log after backup (S707: Yes), S701 is performed again, and if there is no unprocessed log after backup (S707: Yes), the recovery process (child) for the partition 111B is completed.
  • a DBMS other than the in-memory database may be adopted as the DBMS.
  • the plurality of database parts constituting the database may be distributed to a plurality of different database servers, or at least one of the plurality of database parts may be stored in the external storage device.
  • log file 301 (and database part) may be stored in the storage device 415 in the database server 401 instead of the external storage apparatus 402.
  • the order (log generation order like LLSN) may be recorded for the logs of transactions belonging to the second type transaction set.
  • the log may be generated but the LLSN may not be numbered. As a result, a reduction in the load on the processor 414 can be expected.
  • log storage area is an area in the external storage device 402, the main memory 416, or the storage device 415, and a log file generated for each log may be written in the area. That is, in the above-described embodiment, a plurality of logs are written in one log file. However, in one modified example, one log file may be written in the log storage area for each log.
  • the LLSN may be a combination of the ID of the corresponding LLSN management unit 115 and a time stamp.
  • checkpoint logs may be generated for the same checkpoint, and all LLSNs corresponding to all LLSN management units 115 may be recorded in the two or more checkpoint logs.
  • the number of checkpoint logs for the same checkpoint is preferably smaller than the number of partitions 111. This is to reduce the number of log I / Os.
  • the checkpoint log may be stored in an area other than the log file (for example, the main memory 416).
  • the recovery process may be performed by a recovery execution unit (not shown) provided separately from the query execution unit, instead of the thread (query execution unit). That is, in the above embodiment, the query execution unit also serves as the recovery execution unit, but a recovery execution unit may be provided separately from the query execution unit.
  • Database server 402 External storage device

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Data Mining & Analysis (AREA)
  • Databases & Information Systems (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Security & Cryptography (AREA)
  • Computational Linguistics (AREA)
  • Information Retrieval, Db Structures And Fs Structures Therefor (AREA)
  • Debugging And Monitoring (AREA)

Abstract

　データベース管理システムは、複数のトランザクションの実行において、トランザクション毎に、トランザクションのログを生成し、生成したログをログ格納領域に格納する。データベース管理システムは、少なくとも、トランザクション実行順序によって結果が異なるトランザクションの集合に属するトランザクションについて生成されたログには、ログの順番を記録する。

Description

データベース管理システム及び方法
　本発明は、概して、データベース管理に関し、例えば、トランザクション処理のログの出力に関する。
　データベース管理システム（以下、ＤＢＭＳ）として、データベース（特に、テーブル及びインデックスといった主要なデータ）を不揮発性のストレージ装置（典型的にはＨＤＤ（Hard　Disk　Drive）のようなディスクストレージ装置）に配置するオンディスクデータベースと、データベースをメインメモリ（一般的に揮発性メモリ）に配置するインメモリデータベースが知られている（オンディスクデータベースとインメモリデータベースを組み合わせたハイブリット型のＤＢＭＳも知られている）。
　インメモリデータベースも、メインメモリ上のデータベースの状態をリカバリーするためには、不揮発性のストレージ装置に更新履歴を含んだログを出力しておく必要がある。
　ログは、一般に、トランザクション実行時に単一のログファイルに出力される。複数のコア（又は複数のＣＰＵ（Central　Processing　Unit））で並行してトランザクションが処理されるようになっていても、ログの出力先は、単一のログファイルである。このため、ログ出力がボトルネックとなる。
　ところで、必ずしも全てのトランザクションの間に順序を定める必要はない。例えば、２つのトランザクションが参照及び更新するデータの集合が共通部分を持たない場合には、その２つのトランザクションの実行順序を入れ替えても、データベースへの操作結果は変わらない。このため、２つのトランザクションには順序を定める必要はない。特許文献１では、分散されたデータベース毎にログファイルが用意され、データベースの更新履歴を含んだログが、複数のログファイルのうちのそのデータベースに対応したログファイルに出力される。
ＵＳ５８７８４１４
　インメモリデータベースは、データベースを複数のパーティションに分割し、各パーティションを管理することができる。特許文献１に開示の技術をインメモリデータベースに適用した場合、インメモリデータベースが管理するパーティション毎にログファイルを用意し、パーションの更新履歴を含んだログをそのパーティションに対応するログファイルに出力することができる。
　しかし、特許文献１の技術を単純にインメモリデータベースに適用すると、トランザクション数の数倍のＩ／Ｏ要求がストレージ装置に対して発生してことになる。なぜなら、パーティションは予め定義されており、トランザクションの処理において複数のパーティションのデータを参照及び更新することがあることを避けることができず、その場合、処理されたトランザクションが１つであっても、複数のパーティションにそれぞれ対応した複数のログファイルの各々にログを出力しなければならないからである。
　このような課題は、インメモリデータベースに限らず、分割されたデータベースを管理する他のＤＢＭＳ、或いは、単一のデータベースを管理する他のＤＢＭＳについてもあり得る。
　ＤＢＭＳは、複数のトランザクションの実行において、トランザクション毎に、トランザクションのログを生成し、生成したログをログ格納領域に格納する。ＤＢＭＳは、少なくとも、トランザクション実行順序によって結果が異なるトランザクションの集合に属するトランザクションについて生成されたログには、ログの順番を記録する。
　トランザクション実行順序によって結果が異なるトランザクションの集合に属するトランザクションについて生成されたログにログの順番が記録されるので、トランザクション実行順序によって結果が異なるトランザクションの集合について、トランザクションの実行順序を特定することができる。このため、データベースが分割された複数のデータベース部分のうちの２以上のデータベース部分を更新した１つのトランザクションについて生成されるログが、更新されたデータベース部分の数より少ない数のログであっても、格納されたログを基に、トランザクションの実行順序（例えば半順序）を特定することができる。
実施例に係る計算機システムの構成を示す。 トランザクション集合の一例を示す。 実施例に係る計算機システムの機能ブロック図である。 ＬＬＳＮ管理部の構成を示す。 ログのデータ構造を示す。 チェックポイントログのデータ構造を示す。 トランザクション集合の一例を示す。 トランザクション集合の実行前と実行後のテーブルを示す。 実施例に係るログ出力の一例を示す。 比較例１に係るログ出力の一例を示す。 比較例２に係るログ出力の一例を示す。 トランザクション処理のフローチャートである。 ログ出力処理のフローチャートである。 チェックポイント生成処理のフローチャートである。 データベースのリカバリー処理（親）のフローチャートである。 データベースのリカバリー処理（子）のフローチャートである。
　以下、図面を参照して、一実施例を説明する。
　なお、以下の説明では、同種の要素の参照符号には同一の親番号を含んでいる。同種の要素を区別して説明する場合には、要素の参照符号を使用し（例えばパーティション１１１Ａ、１１１Ｂ、…）、同種の要素を区別しないで説明する場合には、要素の参照符号のうちの親番号のみ使用することがある（例えばパーティション１１１）。
　また、以下の説明では、「プログラム」を主語として処理を説明する場合があるが、プログラムは、プロセッサによって実行されることで、定められた処理を、適宜に記憶資源（例えばメモリ）及び／又は通信インターフェイスデバイス等を用いながら行うため、処理の主語がプロセッサとされてもよい。プログラムを主語として説明された処理は、プロセッサ或いはそのプロセッサを有する装置（例えばデータベースサーバ）が行う処理としてもよい。また、プロセッサは、処理の一部又は全部を行うハードウェア回路を含んでもよい。プログラムは、プログラムソースから各コントローラにインストールされてもよい。プログラムソースは、例えば、プログラム配布計算機又は記憶メディアであってもよい。
　図１は、実施例に係る計算機システムの構成を示す。
　データベースサーバ４０１に外部ストレージ装置４０２が、例えば通信ネットワーク４０３を介して接続されている。
　データベースサーバ４０１は、計算機であって、例えば、パーソナルコンピュータ、ワークステーション又はメインフレームであってよく、もしくは、これらの計算機において仮想化プログラムによって構成された仮想的な計算機であってよい。データベースサーバ４０１は、Ｉ／Ｏアダプタ４１３、メインメモリ４１６、記憶デバイス４１５及びそれらに接続されたプロセッサ４１４を有する。プロセッサ４１４は、例えば、マイクロプロセッサ、又は、マイクロプロセッサと専用ハードウェア回路を含んだモジュールでよい。プロセッサ４１４は、コンピュータプログラムを実行する。プロセッサ４１４により実行されるコンピュータプログラムは、例えば、オペレーティングシステム（ＯＳ）１１７及びデータベース管理システム（ＤＢＭＳ）４１２である。メインメモリ４１６は、例えば、揮発性のＤＲＡＭ（Dynamic　Random　Access　Memory）等であり、プロセッサ４１４によって実行されるプログラムと、プログラムが使用するデータを一時的に記憶する。記憶デバイス４１５は、不揮発性であり、例えば、ＨＤＤ（Hard　Disk　Drive）又はＳＳＤ（Solid　State　Drive）である。記憶デバイス４１５は、プログラム及びプログラムが使用するデータを格納してよい。Ｉ／Ｏアダプタ４１３は、通信ネットワーク４０３とデータベースサーバ４０１を接続する。
　外部ストレージ装置４０２は、複数の記憶デバイスを含む記憶デバイス群４５１を有する装置であり、例えば、ディスクアレイ装置であるが、それに代えて、単一の記憶デバイスであってもよい。外部ストレージ装置４０２は、ログファイル３０１を記憶する。外部ストレージ装置４０２は、データベースサーバ４０１からログのＩ／Ｏ要求を受け付け、当該Ｉ／Ｏ要求に従いデータ（例えばログ）の読み書きを行い、その結果をデータベースサーバ４０１に返す。なお、記憶デバイス群４５１が有する記憶デバイスは、不揮発性の記憶媒体を有するデバイスであって、例えば、ＨＤＤ又はＳＳＤである。記憶デバイス群４５１は、ＲＡＩＤ（Redundant　Array　of　Independent　Disks）グループでよく、所定のＲＡＩＤレベルでデータを記憶してもよい。記憶デバイス群４５１の記憶空間に基づく論理的な記憶デバイス（例えば、論理ユニット、論理ボリューム、ファイルシステムボリューム）が、データベースサーバ４０１に提供され、当該論理的な記憶デバイス上にログファイル３０１が格納されてもよい。なお、本実施例において、ログファイル３０１は、ログ格納領域の一例である。
　外部ストレージ装置４０２は、記憶デバイス群４５１に加えて、Ｉ／Ｏアダプタ４４１及びこれらに接続されたストレージコントローラ４４２を有する。Ｉ／Ｏアダプタ４４１は、外部ストレージ装置４０２を通信ネットワーク４０３に接続し、これを介して、データベースサーバ４０１と接続される。通信ネットワーク４０３を介した通信プロトコルとしては、例えば、ファイバチャネル（ＦＣ）、ＳＣＳＩ（Small　Computer　System　Interface）、又は、ＴＣＰ／ＩＰ（Transmission　Control　Protocol／Internet　Protocol）が採用されてよい。例えば、ファイバチャネルもしくはＳＣＳＩが採用される場合、Ｉ／Ｏアダプタ４４１（及び４１３）は、ホストバスアダプタと呼ばれることがある。ストレージコントローラ４４２は、例えば、メモリ及びプロセッサを含み、データベースサーバ４０１からのＩ／Ｏ要求に応じて、ログファイル３０１を格納した記憶デバイス群４５１との間でデータの読出し、もしくは、書込みを行う。
　図２は、トランザクション集合の一例を示す。
　この図は、２つのチェックポイント１及び２の間で実行されるトランザクションの例を示す。本実施例において実行される各トランザクションは、第１種トランザクション集合と第２種トランザクション集合のいずれかに分類される。
　第１種トランザクション集合は、トランザクション実行順序によって結果が変化するトランザクションの集合である。図示の例では、半順序が定義されている。半順序によれば、例えば、同一のレコードを更新する複数のトランザクションは定義された順序で実行されなければならないが、異なるレコードを更新する複数のトランザクションはどのような順序で実行されてもよい。
　第２種トランザクション集合は、トランザクションの実行順序が結果に影響を与えないトランザクション集合である。
　実行対象のトランザクションが第１種及び第２種トランザクション集合のどちらに属するかは、例えば、１又は複数のクエリ実行プランから判断することができる。
　図３は、実施例に係る計算機システムの機能ブロック図である。
　ＤＢＭＳ４１２は、インメモリデータベースである。ＤＢＭＳ４１２は、データベースを複数のパーティション１１１（例えば３つのパーティション１１１Ａ～１１１Ｃ）に分割してメインメモリ４１６上に配置する。各パーティション１１１は、データベースの一部分、例えば、データベース中のテーブルの一部分であるテーブル１１２と、データベース中のインデックスの一部分であるインデックス１１３とを含む。１つのパーティション１１１（例えば１１１Ａ）において、そのパーティション１１１内のインデックス１１３（例えば１１３Ａ）を用いて、そのパーティション１１１内のテーブル１１２（例えば１１２Ａ）からデータを特定することができる。１つのテーブル１１２が有するデータは、そのテーブル１１２を含むパーティション１１１内のインデックス１１３のみから特定可能でよい。また、各パーティション１１１は、ロック機構１１６を含んでよい。同一のパーティション１１１に対して２以上のスレッド１１０が競合することを避けるためである。ロック機構１１６は、パーティション１１１のロックの取得済か否かを表す情報でよい。例えば、ロック機構１１６は、ロック取得済なら値「１」でよくロック未取得なら値「０」でよい。ロック機構１１６は、パーティション１１１に関連付けられていればよく、パーティション１１１の外にあってもよい。
　ＤＢＭＳ４１２は、パーティション１１１毎に、ログバッファ１１４とＬＬＳＮ管理部１１５を有する。ログバッファ１１４は、パーティション１１１の更新履歴を含んだログを一時格納する。ＬＬＳＮ管理部１１５は、ＬＬＳＮを管理する。「ＬＬＳＮ」は、ローカルログシーケンス番号の略である。ＬＬＳＮは、１つのパーティション１１１において重複しない番号である。ＬＬＳＮは、第１種トランザクション集合（トランザクション実行順序によって結果が変化するトランザクション集合）に属するトランザクションのログの出力の際に採番される。ＬＬＳＮは、第１種トランザクション集合に限らず第２種トランザクション集合に属するトランザクションのログの出力の際にも採番されてもよい。
　ＤＢＭＳ４１２は、クエリ発行元からクエリを受信し、受信したクエリの実行において、１又は複数のトランザクションを実行する。具体的には、ＤＢＭＳ４１２は、クエリ受付部４２１、クエリ実行プラン生成部４２２及びクエリ実行部４２４を有する。
　クエリ受付部４２１は、クエリ発行元が発行するクエリを受け付ける。クエリは、例えば、構造化問合せ言語（ＳＱＬ、Structured　Query　Language）によって記述される。１つのクエリで複数のトランザクションが記述されていてもよいし、複数のクエリで複数のトランザクションが記述されてもよい。また、クエリ発行元は、ＤＢＭＳ４１２の内部のコンピュータプログラムであってよいし、ＤＢＭＳ４１２外部のコンピュータプログラムであってよい。例えば、外部のコンピュータプログラムは、データベースサーバ４０１内で実行されるコンピュータプログラム（例えばアプリケーションプログラム）であってもよいし、データベースサーバ４０１に接続されたクライアント計算機等の装置で実行されるコンピュータプログラム（例えば、アプリケーションプログラム）であってもよい。
　クエリ実行プラン生成部４２２は、クエリ受付部４２１が受け付けたクエリから、当該クエリを実行するために必要な１以上のデータベースオペレーションを含むクエリ実行プランを生成する。クエリ実行プランは、例えば、１以上のデータベースオペレーションと、データベースオペレーションの実行順序の関係を含む情報であり、クエリ実行プラン情報４２３として格納される。クエリ実行プランは、データベースオペレーションをノード、データベースオペレーションの実行順序の関係をエッジとする木構造で表されることがある。１つのクエリ実行プラン、又は、複数のクエリ実行プランの組合せから、１又は複数のトランザクション集合と、各トランザクション集合が第１種及び第２種のトランザクション集合のどちらであるかを特定することができる。
　クエリ実行部４２４は、クエリ実行プラン生成部４２２が生成したクエリ実行プランに従って、クエリ受付部４２１が受け付けたクエリを実行し、その実行結果をクエリ発行元に返す。この際、クエリ実行部４２４は、データベースオペレーションの実行に必要なデータの読出し要求（参照要求）を発行し、その読出し要求に従いパーティション１１１から読み出されたデータを使用して、そのデータベースオペレーション（例えば、読み出されたデータ（値）を用いて新たなデータを算出し、読出し元レコードにおけるデータを算出後のデータに更新する書込み要求を発行する）を行う。クエリ実行部４２４は、データベースオペレーションを、スレッド１１０を実行することにより行う。なお、ＤＢＭＳ４１２において、複数のスレッド１１０が並行して実行される。このため、プロセッサ４１４は、複数のコアを有する。複数のコアは、１又は複数のＣＰＵに存在する。スレッド１１０は、タスクと呼ばれてもよい。スレッド１１０の実装としては、例えば、ＯＳ１１７が実現するプロセスやカーネルスレッド等のほか、ライブラリ等が実現するユーザスレッドを用いてよい。１つのスレッド１１０により、１以上のデータベースオペレーションに対応した１つのトランザクションが実行されてよい。以下、クエリ実行部４２４がスレッド１１０を実行することにより行われる処理の主語を、スレッド１１０、とすることがある。
　クエリ実行部４２４（スレッド１１０）は、トランザクションの実行において、外部ストレージ装置４０２内のログファイル３０１にログを書き込むために、外部ストレージ装置４０２に対するＩ／Ｏ要求をＯＳ１１７に発行する。ＯＳ１１７は、そのＩ／Ｏ要求を受け付け、外部ストレージ装置４０２へＩ／Ｏ要求を発行する。
　Ｉ／Ｏアダプタ４１３には、複数のＩ／Ｏキュー２０１（２０１Ａ～２０１Ｃ）が用意される。トランザクションの処理において、スレッド１１０が、ログの書込みのためのＩ／Ｏ要求を発行するが、Ｉ／Ｏキュー２０１には、そのＩ／Ｏ要求が格納される。具体的には、Ｉ／Ｏ要求は、ＯＳ１１７によりＩ／Ｏキュー２０１に格納される。
　外部ストレージ装置４０２が、複数のログファイル３０１（３０１Ａ～３０１Ｃ）を記憶する。ログファイル３０１に、Ｉ／Ｏ要求の書込み対象のログが記録される。
　本実施例では、パーティション１１１と、Ｉ／Ｏキュー２０１と、ログファイル３０１が、１：１：１で対応している。つまり、パーティション１１１毎に、１つのＩ／Ｏキュー２０１と、１つのログファイル３０１がある。具体的には、パーティション１１１ＡにＩ／Ｏキュー２０１Ａ及びログファイル３０１Ａが関連付けられており、パーティション１１１ＢにＩ／Ｏキュー２０１Ｂ及びログファイル３０１Ｂが関連付けられており、パーティション１１１ＣにＩ／Ｏキュー２０１Ｃ及びログファイル３０１Ｃが関連付けられている。スレッド１１０は、１つのログファイル３０１につき１つであっても複数であってもよい。ただし、Ｉ／Ｏ要求の完了を通知するための割り込みをＩ／Ｏキュー２０１毎に特定のスレッド１１０に送信するようにする方がＩ／Ｏ要求の処理が軽減できる場合があり、その場合には例えばスレッド１１０とパーティション１１１とＩ／Ｏキュー２０１を１対１対応させておくとよい場合がある。本実施例では、説明を分かり易くするために、スレッド１１０もログファイル３０１に１：１で対応していてよい。例えば、スレッド１１０Ａが、パーティション１１１Ａにおけるテーブル１１２Ａ中のレコードを更新したことを表すログのＩ／Ｏ要求を、そのパーティション１１１Ａに対応するログファイル３０１Ａに対して発行するようになっている。発行されたＩ／Ｏ要求は、ログバッファ１１４Ａを経由して、ＯＳ１１７に送られる。ＯＳ１１７が、ログファイル３０１Ａに対するＩ／Ｏ要求を受けて、そのＩ／Ｏ要求を、ログファイル３０１Ａに対応するＩ／Ｏキュー２０１Ａに格納する。Ｉ／Ｏキュー２０１Ａに格納されたＩ／Ｏ要求は、ＯＳ１１７によりＩ／Ｏキュー２０１から外部ストレージ装置４０２に送られる。それにより、そのＩ／Ｏ要求の書込み対象データであるログが、ログファイル３０１Ａに書き込まれる。
　図３に示すＤＢＭＳ４１２の構成は一例に過ぎない。例えば、或る構成要素は複数の構成要素に分割されていてもよく、複数の構成要素が１つの構成要素に統合されていてもよい。
　図４は、ＬＬＳＮ管理部１１５の構成を示す。
　ＬＬＳＮ管理部１１５は、ロック機構１２１と、ＬＬＳＮ１２２と、ログファイルアドレス１２３とを有する。
　ロック機構１２１も、図３に示したロック機構１１６と同様、ＬＬＳＮ管理部１１５のロックの取得済か否かを表すデータでよい。例えば、ロック機構１２１は、ロック取得済なら値「１」でよくロック未取得なら値「０」でよい。
　ＬＬＳＮ１２２は、このＬＬＳＮ管理部１１５を含むパーティション１１１についてのログのシーケンス番号（ＬＬＳＮ）である。例えば、ＬＬＳＮは、このＬＬＳＮ管理部１１５のＩＤと、シリアル番号との組合せである。例えば、ＬＬＳＮ管理部１１５Ａからスレッド１１０ＡによりＬＬＳＮが採番される度に、ＬＬＳＮ１２２が表す値は、１－００１、１－００２、１－００３のように更新される。ＬＬＳＮは、ＬＬＳＮ管理部１１５ＡのＩＤ「１」と、更新後のシリアル番号との組合せである。
　ログファイルアドレス１２３は、ＬＬＳＮ管理部１１５を含むパーティション１１１に対応したログファイル３０１におけるログの書込み先アドレスである。ログファイルアドレス１２３が表すアドレス（値）は、ログファイル３０１にログを書き出す度に出力するログのサイズ分だけ加算される。
　図５は、ログのデータ構造を示す。
　ログは、１つのトラザクションにつき１つでよく、トランザクションのＩＤと、そのトランザクションの実行中に採番された１以上のＬＬＳＮと、そのトランザクションの更新履歴を表す情報とを含む。ログに含まれるＬＬＳＮの数は、トランザクションの実行において更新されたパーティション１１１の数と同じである。
　図６は、チェックポイントログのデータ構造を示す。
　チェックポイントログは、チェックポイントが生成されたことのログである。チェックポイントログは、チェックポイントを生成するトランザクションのＩＤと、そのチェックポイントの生成において採番された全てのＬＬＳＮと、生成されたチェックポイントのＩＤとを含む。データベースのリカバリーの際には、チェックポイントＩＤを使用して、リカバリーする時点を特定することができる。なお、チェックポイントＩＤは、チェックポイント生成時の時刻を表す値でもよい。
　図７は、トランザクション集合の一例を示す。図８は、トランザクション集合の実行前と実行後のテーブル１１２Ａ及び１１２Ｂを示す。なお、図７（及び後述の図９～図１１）では、トランザクションは「Tr.」と略記されている。また、以下の説明では、レコードは、行ＩＤとＶａｌ（値）を有していて、行ＩＤ：ＸのレコードをレコードＸと言い、行ＩＤ：ＹのレコードをレコードＹと言う。
　図７に示すトランザクション集合は、第１種のトランザクション集合、すなわち、トランザクション実行順序によって結果が変化するトランザクションの集合である。トランザクション集合により、レコードＸ及びＹが更新される。
　図８に示すように、レコードＸは、パーティション１１１Ａ中のテーブル１１２Ａにあるレコードであり、レコードＹは、別のパーティション１１１Ｂ中のテーブル１１２Ｂにあるレコードである。図７に示したトランザクション集合の実行前、レコードＸにおけるＶａｌ（値）は「１００」であり、レコードＹにおけるＶａｌ（値）も「１００」である。図７に示したトランザクション集合の実行により、レコードＸにおけるＶａｌ（値）は「１１０」に更新され、レコードＹにおけるＶａｌ（値）は「１２２」に更新される。
　図７に示すトランザクション集合によれば、トランザクションＡ、Ｂ及びＥは、実行順序によって結果が変化する。それらは同一のレコードＸを更新するトランザクションだからである。同様に、トランザクションＡ、Ｃ及びＤも、実行順序によって結果が変化する。それらは同一のレコードＹを更新するトランザクションだからである。
　しかし、トランザクションＢと、トランザクションＣ又はＤのどちらを先に実行しても結果が変化しない。それらは異なるレコードＸ、Ｙを更新するトランザクションだから、言い換えれば、更新されるレコードが共通でないからである。
　そこで、ログに基づいてデータベースをリカバリーする際に最低限の必要なトランザクション実行順序を記録する必要がある。この実行したトランザクション集合に半順序を定義する実装方法は１つではなく、例えば必要最小限の順序関係を記録する方法として次の方法が考えられる。例えば図２に示したように、任意のチェックポイント１とチェックポイント１より後に生成されたチェックポイント２の間に実行されたトランザクションであって、第１種のトランザクション集合に属するトランザクション（トランザクションの実行順序によって結果が異なるトランザクション）のログには、コミットされた順序に従う順番（ログの生成順番）が記録される。一方、第２種のトランザクション集合に属するトランザクション（トランザクション間の実行順序によって結果が異ならず、チェックポイント１からチェックポイント２の間に実行されていればよいトランザクション）のログには、順番が記録されない。これにより、第１種のトランザクション集合のログについて、半順序を定義することができる。
　本実施例では、１つのトランザクションの実行において、更新されるパーティション１１１別にＬＬＳＮが採番される。１つのパーティション１１１について採番されるＬＬＳＮは、そのパーティション１１１についてのシーケンス番号であり、他のパーティション１１１についてのＬＬＳＮとの関連性は無い。つまり、本実施例では、パーティション１１１別に一連のＬＬＳＮ（シーケンス番号）が採番され、採番されたＬＬＳＮがログに記録されることで、第１種のトランザクション集合について半順序が定義される。
　具体的には、次のようにログが出力される。すなわち、前述したように、パーティション１１１とログファイル３０１が１：１で用意されており、パーティション１１１の更新履歴を含んだログは、そのパーティション１１１に対応したログファイル３０１に書き込まれる。また、１つのトランザクションの実行においてＮ個のパーティション１１１（Ｎは２以上の整数）が更新されることもあるが、その場合には、Ｎ個のパーティション１１１にそれぞれ対応したＮ個のログファイルにＮ個のログがそれぞれ書き込まれるのではなく、更新されたパーティション１１１の数（Ｎ）よりも少ない数のログファイル（Ｍ個のログファイル）３０１にそれぞれＭ個のログが書き込まれる。本実施例では、Ｍ＝１である。すなわち、本実施例では、Ｎの値（１つのトランザクションの実行において更新されたパーティション１１１の数）が幾つであっても、更新されたパーティション１１１のうちのいずれかの１つのパーティション１１１に対応した１つのログファイル３０１にログが書き込まれる。但し、そのログには、更新されたＮ個のパーティションにそれぞれ対応したＮ個のＬＬＳＮが書き込まれる。
　図９は、実施例に係るログ出力の一例を示す。
　図７に示したトランザクション集合の実行前、パーティション１１１ＡのＬＬＳＮは１－２０１、パーティション１１１ＢのＬＬＳＮの値は２－１００であるとする。もちろん、これは一例にすぎず、これ以外の値であることを排除するものではない。
　まず、トランザクションＡの実行により、パーティション１１１ＡのレコードＸとパーティション１１１ＢのレコードＹの両方が更新される。このため、ＬＬＳＮ管理部１１５ＡからＬＬＳＮ＝１－２０１が採番され、ＬＬＳＮ管理部１１５ＢからＬＬＳＮ＝２－１００が採番される。この段階で、ＬＬＳＮ管理部１１５Ａ及び１１５ＢのそれぞれのＬＬＳＮが１インクリメントされ、その結果、ＬＬＳＮ管理部１１５ＡのＬＬＳＮが１－２０２となり、ＬＬＳＮ管理部１１５ＢのＬＬＳＮが２－１０１となってよい。また、パーティション１１１Ａ及び１１１Ｂが更新された場合、ログの出力先は、パーティション１１１Ａ及び１１１Ｂにそれぞれ対応したログファイル３０１Ａ及び３０１Ｂのうちのどちらかとなる（例えばラウンドロビンで順次出力先が切り替えられてもよいしどちらかに予め決められてもよい）。ここでは、ログファイルＡにログが出力される。このため、ＬＬＳＮ管理部１１５Ａからログファイルアドレスが取得され、ＬＬＳＮ管理部１１５Ａにおけるログファイルアドレスに、出力するログのサイズ分の値が加算される。トランザクションＡを実行したスレッド１１０Ａが、採番されたＬＬＳＮ＝１－２０１及びＬＬＳＮ＝２－１００、トランザクションＩＤ＝Ａ、及びレコードＸ及びＹの更新履歴をログに記録し、それらが記録されたログ９０１Ａを、ログファイル３０１Ａにおける、取得したログファイルアドレスに従う位置から、書き込む。具体的には、スレッド１１０Ａが、ログ９０１Ａをログバッファ１１４Ａに格納し、そのログ９０１Ａを書込み対象とし上記取得したログファイルアドレスを指定した書込み要求を発行する。ＯＳ１１７が、その書込み要求を受けて、その書込み要求を、ログファイル３０１Ａに対応したＩ／Ｏキュー２０１Ａに書き込み、Ｉ／Ｏキュー２０１Ａからその書込み要求を外部ストレージ装置４０２に送信する。外部ストレージ装置４０２が、その書込み要求を受けて、その書込み要求に従う書込み対象のログ９０１Ａをログファイル３０１Ａに書き込み、書込み要求の完了応答を返す。完了応答は、ＯＳ１１７を通じてＤＢＭＳ４１２に戻る。
　次に、トランザクションＢの実行により、パーティション１１１ＡのレコードＸだけが更新される。このため、トランザクションＢを実行したスレッド１１０Ａが、ＬＬＳＮ管理部１１５ＡからＬＬＳＮ＝１－２０２を採番し（ＬＬＳＮ管理部１１５ＡのＬＬＳＮは１－２０３にインクリメントされ）、且つログファイルアドレスを取得し（ＬＬＳＮ管理部１１５Ａのログファイルアドレスに出力対象のログのサイズが加算され）、ＬＬＳＮ＝１－２０２、トランザクションＩＤ＝Ｂ、及びレコードＸの更新履歴を含んだログ９０１Ｂを、トランザクションＢの実行により更新されたパーティション１１１Ａに対応するログファイル３０１Ａ（取得したログファイルアドレス）に出力する。
　また、トランザクションＣの実行により、パーティション１１１ＢのレコードＹだけが更新される。このため、トランザクションＣを実行したスレッド１１０Ｂが、ＬＬＳＮ管理部１１５ＢからＬＬＳＮ＝２－１０１を採番し（ＬＬＳＮ管理部１１５ＢのＬＬＳＮは２－１０２にインクリメントされ）、且つログファイルアドレスを取得し（ＬＬＳＮ管理部１１５Ｂのログファイルアドレスに出力対象のログのサイズが加算され）、ＬＬＳＮ＝２－１０１、トランザクションＩＤ＝Ｃ、及びレコードＹの更新履歴を含んだログ９０１Ｃを、トランザクションＣの実行により更新されたパーティション１１１Ｂに対応するログファイル３０１Ｂ（取得したログファイルアドレス）に出力する。
　同様に、トランザクションＤが実行された場合には、ＬＬＳＮ管理部１１５ＢからＬＬＳＮ＝２－１０２が採番され、ＬＬＳＮ＝２－１０２を含んだログ９０１Ｄがログファイル３０１Ｂに書き込まれる。
　最後に、トランザクションＥが実行された場合には、ＬＬＳＮ管理部１１５Ａ及び１１５ＢからそれぞれＬＬＳＮ＝１－１０３及び２－１０３が採番され、それら採番されたＬＬＳＮを含んだログ９０１Ｅが、ログファイル３０１Ｂに書き込まれる。
　このようにログを出力することにより、それぞれのログにおけるＬＬＳＮを参照することで、トランザクションＡ－＞Ｂ－＞Ｅ、トランザクションＡ－＞Ｃ－＞Ｄ－＞Ｅの順序がリカバリー可能である。なお、本実施例では、同一のパーティションについて、第１のＬＬＳＮが第２のＬＬＳＮより大きいことは、第１のＬＬＳＮが第２のＬＬＳＮよりも後に（将来に）採番されたことを意味するが、一変形例では、第１のＬＬＳＮが第２のＬＬＳＮより大きいことは、第１のＬＬＳＮが第２のＬＬＳＮよりも前に（過去に）採番されたことを意味してもよい。つまり、ＬＬＳＮの大小関係から順序関係が特定できればよい。
　一般に、いずれか１つのＬＬＳＮ管理部１１５のＬＬＳＮの大小関係でトランザクション間の順序関係（これを便宜上「≧」と表す）を定義すると、トランザクション全体の集合にいくつかの例外を除いて半順序が定まる。例えば、ＬＬＳＮ管理部１１５ＡのＬＬＳＮではトランザクションＡ->Ｂの順に並び（Ａ≧Ｂ）、ＬＬＳＮ管理部１１５ＢのＬＬＳＮではトランザクションＢ->Ａの順に並ぶ（Ｂ≧Ａ）ということが起こる。この場合には、トランザクションＡとＢの間には順序が定義されていないこととして取り扱われる。実際に、トランザクションＡとＢはそれぞれ更新を行ったレコードのロックをトランザクション終了まで解放しないため、このような事象が発生するのは、トランザクションＡ及びＢがそれぞれ更新するレコードが異なるレコードであるからであり、トランザクションＡとＢの実行順序はどちらでもかまわない。
　以下、図７に示したトランザクション集合のログ出力の比較例１及び２を説明する。
　図１０は、比較例１に係るログ出力の一例を示す。
　比較例１は、５個のトランザクションＡ～Ｅにそれぞれ対応した５個のログを単一ログファイルへ出力する例である。比較例１では、トランザクションの実行順にログがログファイルへ出力される。この場合、２以上のトランザクションが並行して実行されてもログ出力が逐次実行になってしまい、トランザクション間でＩ／Ｏリソース（例えば単一ログファイルに対応した単一Ｉ／Ｏキュー）の競合が発生してしまう。
　本実施例では、複数のログファイルが用意され、且つ、複数のログファイルにそれぞれ対応した複数のＩ／Ｏリソース（例えばＩ／Ｏキュー）が用意される。これにより、Ｉ／Ｏリソースの競合を減らすことができる。
　図１１は、比較例２に係るログ出力の一例を示す。
　比較例２は、分散データベースにおいて行われているログ出力例である。トランザクションＢ、Ｃ及びＤのように、パーティション１１１Ａ及び１１１Ｂの一方のみを更新するトランザクションについては、ログの出力は、実施例と同様である。しかし、トランザクションＡ（及びＥ）のように、パーティション１１１Ａ及び１１１Ｂの両方を更新するトランザクションについては、更新されたパーティションと同数のログが同数のログファイルにそれぞれ出力される。このため、ログＩ／Ｏ数が実施例よりも多くなる。
　すなわち、本実施例では、トランザクションが複数のパーティションを更新しても書き込まれるログの数は、更新されたパーティションの数よりも少ない。そのため、ログＩ／Ｏ数を抑えることができる。
　本実施例では、上述した通り、トランザクションによって順序が定義されない場合がある。例えば、トランザクションＢとトランザクションＣはどちらが先にトランザクション実行が完了したかログ上は不定である。従って、一般には、最新状態以外の任意のタイミングの状態にデータベースをリカバリーすることはできない。そこで、本実施例では、前述したように、チェックポイントを生成することにより、ある時点のデータベースの状態を記録しリカバリーすることが可能である。
　以下、実施例において行われる処理を説明する。
　図１２は、トランザクション処理のフローチャートである。なお、以下の説明では、１つのトランザクションＡを例に取り説明する。そのため、そのトランザクションＡを実行するスレッドはスレッド１１０Ａであり、そのトランザクションＡにより更新されるパーティションはパーティション１１１Ａ及び１１１Ｂであり、パーティション１１１Ａ及び１１１Ｂにそれぞれ対応したログファイルはログファイル３０１Ａ及び３０１Ｂである。
　スレッド１１０Ａが、トランザクションＡが開始されると、トランザクションＡに対応した指示（クエリ中の指示）に基づいて、パーティション１１１Ａ及び１１１Ｂの各々について、参照／更新セットの生成を行う（Ｓ３０１）。参照／更新セットは、レコードの参照（パーティションに対する読出し要求）とレコードの更新（パーティションに対する書込み要求）とのセットである。参照／更新セットは、パーティションの更新のための要求セットであるが、Ｓ３０１の時点では、パーティション１１１Ａ及び１１１Ｂの変更は行われず、トランザクションＡに対応したローカルメモリ領域（メインメモリ４６１上に確保された領域（図示せず））に参照／更新セットが保持される。
　次に、スレッド１１０Ａが、コミット判定を行う（Ｓ３０２）。コミット判定は、例えば、トランザクションＡが参照／更新セットに基づいて行うパーティション１１１Ａ及び１１１Ｂへの変更が他のトランザクションとの整合性を保てているかどうかをデータベースのアイソレーションレベルに応じて行われる。
　コミット判定がＮＧの場合（Ｓ３０３：Ｎｏ）、スレッド１１０Ａは、アボート処理を行う（Ｓ３０７）。
　コミット判定がＯＫの場合（Ｓ３０３：Ｙｅｓ）、スレッド１１０Ａは、ログ出力処理を実行する（Ｓ３０４）。次に、スレッド１１０Ａは、参照／更新セットに基づいてパーティション１１１Ａ及び１１１Ｂをそれぞれ更新し（Ｓ３０５）、コミット完了通知を出して（Ｓ３０６）、トランザクションを終了する。
　図１３は、ログ出力処理（図１２のＳ３０４）のフローチャートである。
　トランザクションＡを実行しているスレッド１１０Ａと対応付けられているログファイル３０１ＡのＬＬＳＮ管理部１１５は、ＬＬＳＮ管理部１１５Ａである。スレッド１１０Ａは、ＬＬＳＮ管理部１１５Ａからログファイルアドレスを取得し、ＬＬＳＮ管理部１１５ＡのログファイルアドレスにトランザクションＡのログサイズを加算する（Ｓ４０１）。なお、この一連の動作の前に、スレッド１１０Ａが、ＬＬＳＮ管理部１１５Ａのロックを取得し、動作後にロックを解放する。ＬＬＳＮ管理部１１５及びログファイル３０１がスレッド１１０Ａに対応付けられていない場合には、スレッド１１０Ａは、任意のＬＬＳＮ管理部１１５を選択し、その選択したＬＬＳＮ管理部１１５について同様の処理を行う。ただし、後述するリカバリー処理においてデッドロックを回避するためには、Ｓ４０１で操作されたＬＬＳＮ管理部１１５に対応するログファイル３０１にログが書き込まれる必要がある。
　次に、スレッド１１０Ａは、トランザクションＡの実行により更新されたパーティション１１１Ａ又は１１１ＢのＬＬＳＮを採番する（Ｓ４０２）。データベースのアイソレーションレベルやデータ構造によっては、トランザクションＡの実行により参照されたパーティションのＬＬＳＮも採番する必要がある場合がある。
　スレッド１１０Ａは、更新されたパーティション１１１Ａ及び１１１ＢのうちＬＬＳＮが採番されていないパーティションがあれば（Ｓ４０３：Ｎｏ）、その採番されていないパーティションについてＳ４０２を行う。一方、更新された全てのパーティション１１１Ａ及び１１１ＢのＬＬＳＮが採番されたのであれば（Ｓ４０３：Ｎｏ）、スレッド１１０Ａは、ログ９０１Ａ（図９参照）を生成しそのログ９０１Ａをログバッファ１１４Ａに書き込み、そのログ９０１Ａの書込み要求（ＬＬＳＮ管理部１１５Ａから取得したログファイルアドレスを指定した書込み要求）を発行する（Ｓ４０４）。スレッド１１０Ａは、外部ストレージ装置４０２からＩ／Ｏアダプタ４１３を介して書込み完了通知を受信した場合に書込み完了とし（Ｓ４０５）、ログ出力フローを終了する。
　図１４は、チェックポイント生成処理のフローチャートである。図１４の説明では、チェックポイントを生成するスレッドがスレッド１１０Ａであるとする。
　スレッド１１０Ａは、まず、新規コミット開始を禁止する（Ｓ５０１）。具体的には、スレッド１１０Ａは、スレッド共有の領域に新規コミット禁止を表すフラグビットを予め置き、初期値を０とする。スレッド１１０Ａは、新規コミット開始を禁止する際に、該フラグビットを１に変更する。トランザクションを実行するスレッドは、コミット処理実行開始時に、該フラグビットを確認し、該フラグビットが０の時に限りコミット処理を実行し、該フラグビットが１の時には該フラグビットが０に変更されるまで待ち状態となる。スレッド１１０Ａの新規コミット開始禁止処理以降、いずれのスレッド１１０もコミットを開始することできなくなり、コミット中のトランザクションについてのみコミットが進む。
　スレッド１１０Ａは、コミット中のトランザクション数が０になるまで待つ（Ｓ５０２：Ｎｏ）。コミット中のトランザクション数が０になると（Ｓ５０２：Ｙｅｓ）、スレッド１１０Ａは、任意に選択したログファイル３０１（例えば３０１Ａ）に対応するＬＬＳＮ管理部１１５（例えば１１５Ａ）から、ＬＬＳＮを採番し且つログファイルアドレスを取得し、チェックポイントログのサイズ分の値を、そのＬＬＳＮ管理部１１５（例えば１１５Ａ）内のログファイルアドレスに加算する（Ｓ５０３）。
　さらに、スレッド１１０Ａは、残りのログファイルに対応する全てのＬＬＳＮをそれぞれ採番する（Ｓ５０４）。スレッド１１０Ａは、Ｓ５０３で採番したＬＬＳＮと、Ｓ５０４で採番したＬＬＳＮと、チェックポイントＩＤとを含んだチェックポイントログを完成させる。スレッド１１０Ａは、Ｓ５０３で取得したログファイルアドレスを指定したログ書込み要求（書込み対象は上記完成したチェックポイントログ）を、上記任意に選択したログファイル３０１（例えば３０１Ａ）に対応したログバッファ１１４（例えば１１４Ａ）に書き込み、ログバッファ１１４（例えば１１４Ａ）からログ書込み要求を発行する（Ｓ５０５）。
　次に、スレッド１１０Ａは、データベースのバックアップをする条件が満たされているか否かを判断する（Ｓ５０６）。その条件は、チェックポイント生成が行われた回数がＮ回（Ｎは自然数）に達したことでもよいし、直前回のバックアップ時刻から一定時間経過したことでもよい。
　Ｓ５０６の判断結果が真の場合（Ｓ５０６：Ｙｅｓ）、スレッド１１０Ａは、データベースのバックアップ、すなわち、メインメモリ４１６上のデータベース（各パーティション１１１のテーブル１１２及びインデックス１１３）を、上記チェックポイントログに含められたチェックポイントＩＤに関連付け、そのチェックポイントＩＤが関連付けられたデータベース（イメージ）を、外部ストレージ装置４０２に格納する（Ｓ５０７）。この動作は、すべてのチェックポイントで必ずしも必要ではない。しかし、チェックポイントログの書込みの際にデータベースのバックアップが行われることで、チェックポイント生成時点のデータベース（或いは、チェックポイント時点近傍の時点のデータベース）を高速にリカバリーすることができる。なお、バックアップされたデータベース（イメージ）と、チェックポイントＩＤと、そのチェックポイントＩＤを含んだチェックポイントログの書込み先アドレスとの対応関係を含んだ情報（以下、チェックポイント管理情報）は、スレッドにより、データベースサーバ４０１の中又は外の記憶領域（例えばメインメモリ４１６）に格納されてよい。
　バックアップ完了後、又は、Ｓ５０６の判断結果が偽の場合（Ｓ５０６：Ｎｏ）、スレッド１１０Ａは、新規コミット開始の禁止を解除し（Ｓ５０８）、チェックポイント生成処理が終了する。具体的には、スレッド１１０Ａは、新規コミット禁止を表すフラグビットを１から０に変更する。
　図１５は、データベースのリカバリー処理（親）のフローチャートである。図１５（及び図１６）の説明では、データベースをリカバリーするスレッドがスレッド１１０Ａであるとする。
　スレッド１１０Ａが、チェックポイント管理情報を基に、指定されたチェックポイントのチェックポイントＩＤに関連付けられたデータベース（バックアップイメージ）、又は、指定されたチェックポイントのチェックポイントＩＤよりも過去に生成されたチェックポイントＩＤに関連付けられたデータベース（バックアップイメージ）を、外部ストレージ装置４０２からメインメモリ４１６上にロードする（Ｓ６０１）。チェックポイントＩＤは、クエリ発行元から受けたクエリで指定されていてもよいし、データベースサーバ４０１に接続された図示しない計算機（例えば管理計算機）より指定されてもよい。
　スレッド１１０Ａは、チェックポイント管理情報を基に、そのデータベースに関連付けられているチェックポイントＩＤを含んだチェックポイントログを、そのログのアドレス（ログファイル）から取得して、そのログ中の各ＬＬＳＮを、そのＬＬＳＮに対応したパーティション１１１中のＬＬＳＮ管理部１１５のＬＬＳＮに設定する（Ｓ６０２）。例えば、先頭番号が１であるＬＬＳＮは、ＬＬＳＮ管理部１１５ＡのＬＬＳＮに設定され、先頭番号が２であるＬＬＳＮは、ＬＬＳＮ管理部１１５ＢのＬＬＳＮに設定される。
　スレッド１１０Ａは、ロードされたデータベースに関連付けられているチェックポイントＩＤと指定されたチェックポイントＩＤが違っていれば（Ｓ６０３：Ｎｏ）、各パーティション１１１に対応したスレッド１１０に、リカバリー処理（子）を実行させる（Ｓ６０４）。パーティション１１１Ａについては、スレッド１１０Ａが、リカバリー処理（子）も実行する。スレッド１１０Ａは、全てのリカバリー処理（子）が終了となるのを待って（Ｓ６０５：Ｙｅｓ）、リカバリー処理（親）を終了する。
　一方、スレッド１１０Ａは、ロードされたデータベースに関連付けられているチェックポイントＩＤと指定されたチェックポイントＩＤが同じであれば（Ｓ６０３：Ｙｅｓ）、Ｓ６０４及び６０５を行うこと無しに、リカバリー処理（親）を終了する。なぜなら、Ｓ６０１でロードされたデータベースが、リカバリーされるべきデータベースだからである。
　図１６は、データベースのリカバリー処理（子）のフローチャートである。
　リカバリー処理（子）は、各パーティション１１１について実行される。以下、１つのパーティション１１１Ｂを例に取り、リカバリー処理（子）を説明する。
　スレッド１１０Ｂは、リカバリー処理（親）において設定されたＬＬＳＮ（ＬＬＳＮ管理部１１５Ｂ内のＬＬＳＮ）を、バックアップ時点のＬＬＳＮとして取得する（Ｓ７００）。以下、パーティション１１１Ｂに対応したログファイル３０１Ｂにおいて、Ｓ７０５で取得したＬＬＳＮよりも大きなＬＬＳＮであって、指定されたチェックポイントＩＤより古いＬＬＳＮ（指定されたチェックポイントＩＤの生成時点よりも過去に採番されたＬＬＳＮ）を含んだログを、「バックアップ後ログ」と言うことにする。バックアップ後ログのうち最も大きいＬＬＳＮを含むバックアップ後ログは、ログファイル３０１Ｂの終端のログであることもある。また、バックアップ後ログのうち、パーティション１１１ＢのＬＬＳＮの他に、パーティション１１１ＢのＬＬＳＮ以外のＬＬＳＮを含んでいるバックアップ後ログもあり得る。以下、パーティション１１１ＢのＬＬＳＮを「該当ＬＬＳＮ」と言い、パーティション１１１ＢのＬＬＳＮ以外のＬＬＳＮを「非該当ＬＬＳＮ」と言う。
　スレッド１１０Ｂは、パーティション１１１Ｂに対応したログファイル３０１Ｂにおける未処理のバックアップ後ログのうち最小の該当ＬＬＳＮを含んだバックアップ後ログを特定する（Ｓ７０１）。以下、Ｓ７０１で特定されたバックアップ後ログを「対象ログ」と言う。
　スレッド１１０Ｂは、対象ログ中の該当ＬＬＳＮが、直前回のＳ７０５又はＳ７０６で処理されたバックアップ後ログ中の該当ＬＬＳＮの次の該当ＬＬＳＮ（例えば、直前回のＳ７０５又はＳ７０６で処理されたバックアップ後ログ中の該当ＬＬＳＮに１が加算された該当ＬＬＳＮ）か否かを判断する（Ｓ７０２）。
　Ｓ７０２の判断結果が真の場合（Ｓ７０２：Ｙｅｓ）、スレッド１１０Ｂは、対象ログに非該当ＬＬＳＮが含まれているか否かを判断する。
　Ｓ７０４の判断結果が真の場合（Ｓ７０４：Ｙｅｓ）、スレッド１１０Ｂは、対象ログ中の更新履歴のうち、パーティション１１１Ｂについての更新をパーティション１１１Ｂに対して実行し、且つ、対象ログのコピーを、非該当ＬＬＳＮに対応するパーティションに対応したスレッドに（非該当ＬＬＳＮに対応するパーティションのリカバリー処理（子）を実行しているスレッド）に転送する（Ｓ７０５）。例えば、非該当ＬＬＳＮの先頭番号が１の場合、対象ログのコピーは、スレッド１１０Ａに転送される。非該当ＬＬＳＮが２以上の場合、対象ログのコピーは、２以上の非該当ＬＬＳＮに対応した２以上のパーティションに対応するスレッドにそれぞれ転送される。
　Ｓ７０４の判断結果が偽の場合（Ｓ７０４：Ｎｏ）、スレッド１１０Ｂは、対象ログ中の更新履歴通りの更新をパーティション１１１Ｂに対して実行する（Ｓ７０６）。
　Ｓ７０２の判断結果が偽の場合（Ｓ７０２：Ｎｏ）、実行すべき更新の履歴を含んだログが、ログファイル３０１Ｂ以外のログファイルに格納されているということである。このため、スレッド１１０Ｂは、Ｓ７０５とは逆に、別のスレッドから、実行すべき更新の履歴を含んだログ（直前回のＳ７０５又はＳ７０６で処理されたバックアップ後ログ中の該当ＬＬＳＮの次の該当ＬＬＳＮを含んだログ）のコピーを待ち、そのログのコピーを受信した場合（Ｓ７０３）、そのログのコピー中の更新履歴のうちの、パーティション１１１Ｂについての更新をパーティション１１１Ｂに対して実行する（Ｓ７０６）。
　スレッド１１０Ｂは、Ｓ７０５又はＳ７０６の後、未処理のバックアップ後ログが未だ残っているか否かを判断する（Ｓ７０７）。未処理のバックアップ後ログがあれば（Ｓ７０７：Ｙｅｓ）、再度Ｓ７０１が行われ、未処理のバックアップ後ログがなければ（Ｓ７０７：Ｙｅｓ）、パーティション１１１Ｂについてのリカバリー処理（子）が終了となる。
　以上、一実施例を説明したが、本発明はその実施例に限られない。
　例えば、ＤＢＭＳとして、インメモリデータベース以外のＤＢＭＳが採用されてもよい。データベースを構成する複数のデータベース部分は、異なる複数のデータベースサーバに分散していてもよいし、複数のデータベース部分のうちの少なくとも１つが、外部ストレージ装置に格納されていてもよい。
　また、ログファイル３０１（及びデータベース部分）は、外部ストレージ装置４０２に代えてデータベースサーバ４０１内の記憶デバイス４１５に格納されていてもよい。
　また、第２種のトランザクション集合に属するトランザクションのログについても、順番（ＬＬＳＮのようなログの生成順番）が記録されてもよい。しかし、実施例のように、第２種のトランザクション集合に属するトランザクションのログにはＬＬＳＮが記録されないようにすることで、ログを生成するがＬＬＳＮを採番しなくてもよいことがあり、結果として、プロセッサ４１４の負荷の軽減が期待できる。
　また、ログファイル３０１に代えて別のログ格納領域が採用されてもよい。例えば、ログ格納領域は、外部ストレージ装置４０２、メインメモリ４１６、又は記憶デバイス４１５内の領域であり、その領域に、ログ毎に生成されたログファイルが書き込まれてもよい。つまり、上記実施例では１つのログファイルに複数のログが書き込まれるが、一変形例では、１つのログにつき１つのログファイルがログ格納領域に書き込まれてもよい。
　また、ＬＬＳＮは、対応するＬＬＳＮ管理部１１５のＩＤと、タイムスタンプとの組み合わせでもよい。
　また、同一のチェックポイントについて２以上のチェックポイントログが生成され、それら２以上のチェックポイントログに、全てのＬＬＳＮ管理部１１５に対応した全てのＬＬＳＮが記録されてもよい。ただし、同一のチェックポイントについてのチェックポイントログの数は、パーティション１１１の数よりも少ないことが望ましい。ログＩ／Ｏ数の削減のためである。なお、チェックポイントログは、ログファイル以外の領域（例えばメインメモリ４１６）に格納されてもよい。
　また、リカバリー処理は、スレッド（クエリ実行部）に代えて、クエリ実行部とは別に設けられたリカバリー実行部（図示せず）によって行われてもよい。つまり、上記実施例では、クエリ実行部がリカバリー実行部を兼ねているが、クエリ実行部とは別にリカバリー実行部が設けられてもよい。
　４０１：データベースサーバ　４０２：外部ストレージ装置

Claims (15)

  1. 　データベースを管理するデータベース管理システムであって、
    　前記データベースへのクエリをクエリ発行元から受け付けるクエリ受付部と、
    　前記受け付けたクエリに関する情報を基に、複数のトランザクションを実行し、トランザクション毎に、トランザクションのログを生成し、前記生成したログをログ格納領域に書き込むためのログ書込み要求を発行するクエリ実行部と
    を有し、
    　前記クエリ実行部は、トランザクション実行順序によって結果が異なるトランザクションの集合である第１種トランザクション集合に属するトランザクション毎に、トランザクションのログに、ログの順番を記録する、
    データベース管理システム。
  2. 　分割された前記データベースである複数のデータベース部分、の各々について、ログの順番を管理する順番管理部を有し、
    　各順番管理部により管理される順番は、その順番管理部に対応したデータベース部分を更新したトランザクションのログの生成の都度に更新され、
    　前記複数のデータベース部分のうちＮ個のデータベース部分を更新したトランザクションのログとして（Ｎは２以上の整数）、Ｍ個のログが生成され（ＭはＮ以下であり１以上の整数）、
    　前記Ｍ個のログのうちの少なくとも１つが、前記Ｎ個のデータベース部分にそれぞれ対応したＮ個の順番のうちの２以上の順番を含む、
    請求項１記載のデータベース管理システム。
  3. 　前記Ｎ個のデータベース部分にそれぞれ対応したＮ個のログ格納領域があり、
    　１つの順番を含んだログは、その順番に対応したログ格納領域に書き込まれ、
    　前記２以上の順番を含んだログは、前記２以上の順番にそれぞれ対応した２以上のログ格納領域のうちのいずれかに書き込まれる、
    請求項２記載のデータベース管理システム。
  4. 　Ｍ＝１である、
    請求項２記載のデータベース管理システム。
  5. 　前記複数のデータベース部分にそれぞれ対応した複数のＩ／Ｏ（Input/Output）リソースがあり、
    　１つの順番を含んだログは、その順番に対応したＩ／Ｏリソースを通じて、そのＩ／Ｏリソースに対応したログ格納領域に書き込まれ、
    　前記２以上の順番を含んだログは、前記２以上の順番にそれぞれ対応した２以上のＩ／Ｏリソースのいずれかを通じて、そのＩ／Ｏリソースに対応したログ格納領域に書き込まれる、
    請求項２記載のデータベース管理システム。
  6. 　前記クエリ実行部は、トランザクション実行順序が結果に影響を与えないトランザクションの集合である第２種トランザクション集合に属するトランザクションのログには、順番を記録しない、
    請求項１記載のデータベース管理システム。
  7. 　前記クエリ実行部は、前記クエリに関する情報を基に、実行対象のトランザクションが、前記第１トランザクション集合と前記第２種トランザクション集合とのどちらに属するかを判断する、
    請求項６記載のデータベース管理システム。
  8. 　前記受け付けたクエリに基づいて前記受け付けたクエリを実行するために必要な１以上のデータベースオペレーションと前記１以上のデータベースオペレーションの実行手順とを表す情報を含んだクエリ実行プランを生成するクエリ実行プラン生成部を更に有し、
    　前記クエリに関する情報は、前記クエリ実行プランを表す情報である、
    請求項７記載のデータベース管理システム。
  9. 　前記クエリ実行部は、チェックポイント毎に、全ての順番管理部にそれぞれ対応した全ての順番を含んだ１以上のチェックポイントログを生成する、
    請求項１記載のデータベース管理システム。
  10. 　チェックポイント毎に、チェックポイントログの数は、データベース部分の数よりも少ない、
    請求項９記載のデータベース管理システム。
  11. 　指定された第１のチェックポイントの時点におけるデータベースをリカバリーするリカバリー実行部を更に有し、
    　前記クエリ実行部は、複数のチェックポイントのうちの少なくとも１つのチェックポイントにおいてデータベースをバックアップし、
    　前記リカバリー実行部は、
    　　バックアップされたデータベースのうち、前記第１のチェックポイントと同じ、又は、前記第１のチェックポイントよりも過去のチェックポイントである第２のチェックポイントに対応したデータベースをロードし、
    　　前記第２のチェックポイントに対応したチェックポイントログ中の各順番を、その順番に対応する順番管理部に設定する、
    請求項９記載のデータベース管理システム。
  12. 　前記リカバリー実行部は、前記第２のチェックポイントと前記第１のチェックポイントが異なっていれば、ロードされたデータベースのデータベース部分毎に、データベース部分に対応したログ格納領域に格納されている、前記第２のチェックポイントから前記第１のチェックポイントまでの１以上のログを、ログ中の順番の小さい順に用いて、データベース部分をリカバリーし、
    　前記リカバリー実行部は、データベース部分毎のリカバリーにおいて、そのデータベース部分に対応した順番である該当順番と該当順番以外の１以上の順番である１以上の非該当順番とを含んだログについては、そのログに従う更新を、そのデータベース部分と、前記１以上の非該当順番にそれぞれ対応する１以上のデータベース部分とに対して実行し、
    　前記リカバリー実行部は、データベース部分毎のリカバリーにおいて、そのデータベース部分に対応したログ中の順番が、直前回に用いたログ中の順番の次の番号でなければ、前記次の番号を含んだログを待つ、
    請求項１１記載のデータベース管理システム。
  13. 　前記データベースは、メインメモリ上に存在する、
    請求項２記載のデータベース管理システム。
  14. 　データベースを管理する計算機システムであって、
    　ログ格納領域に接続されたインターフェイスデバイスと、
    　前記インターフェイスデバイスに接続されたプロセッサと
    を有し、
    　前記プロセッサは、複数のトランザクションを実行し、複数のトランザクションの実行において、トランザクション毎に、トランザクションのログを生成し、生成したログをログ格納領域に格納し、
    　前記プロセッサは、少なくとも、トランザクション実行順序によって結果が異なるトランザクションの集合に属するトランザクションのログには、ログの順番を記録する、
    計算機システム。
  15. 　データベースを管理するデータベース管理方法であって、
    　複数のトランザクションの実行において、トランザクション毎に、トランザクションのログを生成し、
    　生成したログをログ格納領域に格納し、
    　少なくとも、トランザクション実行順序によって結果が異なるトランザクションの集合に属するトランザクションについて生成されたログには、ログの順番が記録される、
    データベース管理方法。
PCT/JP2014/051263 2014-01-22 2014-01-22 データベース管理システム及び方法 WO2015111152A1 (ja)

Priority Applications (5)

Application Number Priority Date Filing Date Title
JP2015558634A JP6152431B2 (ja) 2014-01-22 2014-01-22 データベース管理システム及び方法
DE112014002275.6T DE112014002275T5 (de) 2014-01-22 2014-01-22 Datenbankverwaltungssystem und -verfahren
GB1521129.5A GB2537446A (en) 2014-01-22 2014-01-22 Database management system and method
US14/894,042 US10366075B2 (en) 2014-01-22 2014-01-22 Database management system and method
PCT/JP2014/051263 WO2015111152A1 (ja) 2014-01-22 2014-01-22 データベース管理システム及び方法

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2014/051263 WO2015111152A1 (ja) 2014-01-22 2014-01-22 データベース管理システム及び方法

Publications (1)

Publication Number Publication Date
WO2015111152A1 true WO2015111152A1 (ja) 2015-07-30

Family

ID=53680984

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2014/051263 WO2015111152A1 (ja) 2014-01-22 2014-01-22 データベース管理システム及び方法

Country Status (5)

Country Link
US (1) US10366075B2 (ja)
JP (1) JP6152431B2 (ja)
DE (1) DE112014002275T5 (ja)
GB (1) GB2537446A (ja)
WO (1) WO2015111152A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017097639A (ja) * 2015-11-25 2017-06-01 富士通株式会社 データベース制御プログラム、データベース制御装置及びデータベース制御方法
JP2020504927A (ja) * 2016-12-19 2020-02-13 スワールズ，インコーポレイテッド イベントの削除を可能にする分散データベースのための方法および装置
US11734260B2 (en) 2015-08-28 2023-08-22 Hedera Hashgraph, Llc Methods and apparatus for a distributed database within a network
US11797502B2 (en) 2015-08-28 2023-10-24 Hedera Hashgraph, Llc Methods and apparatus for a distributed database within a network

Families Citing this family (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US10002153B2 (en) 2015-05-14 2018-06-19 Illumon Llc Remote data object publishing/subscribing system having a multicast key-value protocol
US10452491B2 (en) * 2016-04-14 2019-10-22 Sap Se Scalable log partitioning system
JP6390748B1 (ja) * 2017-04-19 2018-09-19 富士通株式会社 情報処理装置、情報処理方法および情報処理プログラム
US10198469B1 (en) 2017-08-24 2019-02-05 Deephaven Data Labs Llc Computer data system data source refreshing using an update propagation graph having a merged join listener
US11334439B2 (en) 2018-08-29 2022-05-17 International Business Machines Corporation Checkpointing for increasing efficiency of a blockchain
US11196542B2 (en) 2018-08-29 2021-12-07 International Business Machines Corporation Checkpointing for increasing efficiency of a blockchain
US10901957B2 (en) * 2018-08-29 2021-01-26 International Business Machines Corporation Checkpointing for increasing efficiency of a blockchain
US11086840B2 (en) 2018-12-07 2021-08-10 Snowflake Inc. Transactional streaming of change tracking data

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH01246645A (ja) * 1988-03-29 1989-10-02 Hitachi Ltd ディレイド・ジャーナル・マージ方式
JP2001229063A (ja) * 2000-02-17 2001-08-24 Mitsubishi Electric Corp データ管理システム
WO2008105098A1 (ja) * 2007-02-28 2008-09-04 Fujitsu Limited メモリミラー化制御方法
JP2012069031A (ja) * 2010-09-27 2012-04-05 Nec Corp データベースシステム

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US5878414A (en) * 1997-06-06 1999-03-02 International Business Machines Corp. Constructing a transaction serialization order based on parallel or distributed database log files
US6366915B1 (en) * 1998-11-04 2002-04-02 Micron Technology, Inc. Method and system for efficiently retrieving information from multiple databases
JP2001249903A (ja) * 2000-03-07 2001-09-14 Toshiba Corp 情報処理システム
JP4437650B2 (ja) * 2003-08-25 2010-03-24 株式会社日立製作所 ストレージシステム
JP4452533B2 (ja) * 2004-03-19 2010-04-21 株式会社日立製作所 システムおよび記憶装置システム
JP4912973B2 (ja) * 2007-07-11 2012-04-11 株式会社日立製作所 端末及びデータ配信システム
JP4870190B2 (ja) * 2009-04-27 2012-02-08 株式会社日立製作所 データ処理方法、計算機、及びデータ処理プログラム
US8964849B2 (en) * 2011-11-01 2015-02-24 Blackberry Limited Multi-level significance maps for encoding and decoding

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH01246645A (ja) * 1988-03-29 1989-10-02 Hitachi Ltd ディレイド・ジャーナル・マージ方式
JP2001229063A (ja) * 2000-02-17 2001-08-24 Mitsubishi Electric Corp データ管理システム
WO2008105098A1 (ja) * 2007-02-28 2008-09-04 Fujitsu Limited メモリミラー化制御方法
JP2012069031A (ja) * 2010-09-27 2012-04-05 Nec Corp データベースシステム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
D. GAINPAOLO, BEOS: FILE SYSTEM -JISSEN FILE SYSTEM KOCHIKU, 20 November 1999 (1999-11-20), pages 134 - 135 *

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11734260B2 (en) 2015-08-28 2023-08-22 Hedera Hashgraph, Llc Methods and apparatus for a distributed database within a network
US11797502B2 (en) 2015-08-28 2023-10-24 Hedera Hashgraph, Llc Methods and apparatus for a distributed database within a network
JP2017097639A (ja) * 2015-11-25 2017-06-01 富士通株式会社 データベース制御プログラム、データベース制御装置及びデータベース制御方法
JP2020504927A (ja) * 2016-12-19 2020-02-13 スワールズ，インコーポレイテッド イベントの削除を可能にする分散データベースのための方法および装置
JP7211943B2 (ja) 2016-12-19 2023-01-24 スワールズ，インコーポレイテッド イベントの削除を可能にする分散データベースのための方法および装置
US11657036B2 (en) 2016-12-19 2023-05-23 Hedera Hashgraph, Llc Methods and apparatus for a distributed database that enables deletion of events

Also Published As

Publication number Publication date
GB2537446A (en) 2016-10-19
US20160125018A1 (en) 2016-05-05
US10366075B2 (en) 2019-07-30
JP6152431B2 (ja) 2017-06-21
GB201521129D0 (en) 2016-01-13
DE112014002275T5 (de) 2016-01-28
JPWO2015111152A1 (ja) 2017-03-23

Similar Documents

Publication Publication Date Title
JP6152431B2 (ja) データベース管理システム及び方法
US10977124B2 (en) Distributed storage system, data storage method, and software program
CN105339939B (zh) 对在线热备份数据库的复制
EP2731013B1 (en) Backing up method, device, and system for virtual machine
US9251233B2 (en) Merging an out of synchronization indicator and a change recording indicator in response to a failure in consistency group formation
US8086810B2 (en) Rapid defragmentation of storage volumes
JP6445049B2 (ja) ログの管理方法及び計算機システム
JP6479186B2 (ja) 計算機システム及びデータベース管理方法
US9495253B2 (en) Virtual snapshot system and method
KR100819022B1 (ko) 하나의 타겟 볼륨과 하나의 소스 볼륨 사이의 관계 관리
JPWO2012117534A1 (ja) 計算機システムおよびその制御方法
US20120198150A1 (en) Assigning device adaptors and background tasks to use to copy source extents to target extents in a copy relationship
US11169817B1 (en) Optimizing a boot sequence in a storage system
CN109313593A (zh) 存储系统
US9513840B2 (en) Parallel processes for performing multiple incremental copies
JP6272556B2 (ja) 共有リソース更新装置及び共有リソース更新方法
JP2007323657A (ja) 過渡状態情報を格納するための方法、システムおよびコンピュータ・プログラム
US8850139B2 (en) Changing ownership of cartridges
JP6210501B2 (ja) データベース管理システム、計算機、データベース管理方法
US8738823B2 (en) Quiescing input/output (I/O) requests to subsets of logical addresses in a storage for a requested operation
JP6263673B2 (ja) 計算機システム及びデータベース管理方法
US20220229693A1 (en) Centralized high-availability flows execution framework
EP3690656A1 (en) Method and system for inline deduplication using accelerator pools
WO2016120988A1 (ja) データベースシステム及びデータベース管理方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 14879379

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2015558634

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 14894042

Country of ref document: US

ENP Entry into the national phase

Ref document number: 201521129

Country of ref document: GB

Kind code of ref document: A

Free format text: PCT FILING DATE = 20140122

WWE Wipo information: entry into national phase

Ref document number: 1120140022756

Country of ref document: DE

Ref document number: 112014002275

Country of ref document: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14879379

Country of ref document: EP

Kind code of ref document: A1

ENPC Correction to former announcement of entry into national phase, pct application did not enter into the national phase

Ref country code: GB