Sap Se

Kyu Hwan Kim

Juchang Lee

Chang Gyoo Park

Beomsoo Kim

Chul Won Lee

Deok Koo Kim

Joo Yeon Lee

Deok Hoe Kim

Hyoung Jun Na

Myunggon Park

Ki Hong Kim

Werner Thesing

Hyejeong Lee

Christian Bensberg

Christoph Roterring

Jane Jung Lee

Jeong Hee Won

Wonyoung Kwak

Mihnea Andrei

Sang Kyun Cha

Steffen Geissinger

Yong Sik Kwon

Jaeyoung Choi

Michael Muehle

Reiner Singer

Nosub Sung

Kyungyul Park

Marcel Birn

Chae Kwang Lee

Eunjin Song

Norman May

Di Wu

Andreas Kemmler

Alexander Boehm

Sung Heun Wi

Jaeyun Noh

Hyeong Seog Kim

Eunsang Kim

Seyeong Bae

Kai Morich

Friedrich Keller

Jeong Ae Han

Curtis Johnson

Zhi Qiao

Karim Khamis

Christoph Rottering

Christoph Glania

Armin Risch

Kurt Deschler

Seoyoon Choi

Technologies are described providing adaptive query routing in a replicated database environment. The technologies can be used with a variety of replication protocols. Prepared statements, such as for queries, from a database client can be routed to a source node, or a source node and available replica nodes, when a replica node becomes unavailable. When a replica node becomes available again, a prepared statement can be updated to indicate that the updated prepared statement can be executed at nodes including the replica node that is available again. Prepared statement routing can also be used when a portion of replicated data becomes unavailable at a replica node, but a portion of replicated data remains available.

Adaptive query routing in a replicated database environment

Technologies are described for facilitating database system recovery in a distributed database environment having a master node and at least one slave node. The master node maintains an in-memory reference that includes transaction identifiers and their corresponding commit identifiers. When a slave node requests that a commit identifier be assigned to a transaction, the transaction and commit identifiers for the transaction are added to the in-memory reference. The commit identifier is sent by the master node to the slave node. The slave node writes a log entry to a commit log that includes the transaction identifier and the assigned commit identifier. If the database system is interrupted before the slave node writes the commit log entry, the slave node can request the commit identifier for the transaction from the master node, which retrieves the identifier from the in-memory reference.

Transaction commit protocol with recoverable commit identifier

Technologies are described for facilitating data workload capture, workload replay, and comparing the performance of a plurality of database systems. A plurality of requests for database operations are received from one or more database clients. The requests for database operations are executed. For the plurality of requests for database operations, execution context information is generated for a plurality of execution contexts. For the plurality of requests for database operations, a plurality of performance measures are generated. The execution context information and the performance measures are stored in a workload capture store, such as a file. The workload capture file is useable to replay the captured workload at a second database system using at least a portion of the execution context information and at least a portion of the performance measures.

Database workload capture and replay

Technologies are described for routing structured query language (SQL) statements to elastic compute nodes (ECNs) using workload classes within a distributed database environment. The elastic compute nodes do not store persistent database tables. For example, a SQL statement can be received for execution within the distributed database environment. A workload class can be identified that matches properties of the SQL statement. Based on the workload class, a routing location hint can be obtained that identifies a set of elastic compute nodes. The SQL statement can then be routed to one of the identified elastic compute nodes for execution. Execution of the SQL statement at the elastic compute node can involve retrieving database data from other nodes which store persistent database tables.

Routing SQL statements to elastic compute nodes using workload class

Innovations in the area of server-side processing when committing transactions to disk in a distributed database system can improve computational efficiency at database nodes and/or reduce network bandwidth utilization. For example, when transactions are committed in a database system, at a master node of the database system, a server uses different threads for certain processor-intensive operations and certain I/O-intensive operations.

Transaction commit operations with thread decoupling

A computer implemented method is provided for determining a delay between a first database and an associated replicated database by replicating transactions of the first database in the replicated database, determining a delay between the two databases based on a commit timestamp from the first database and a timestamp associated with the commit transaction becoming visible in the replicated database. Then, after a predefined period of time has elapsed since replicating the commit transaction, determining a second delay based on a timestamp associated with a heartbeat log and a replicated database system time. And, selectively determining to execute or deny a statement received by the replicated database based on the second delay. Related apparatus, systems, techniques and articles are also described.

Measuring snapshot delay between source database and its asynchronous replica

Implementations of the present disclosure include providing, at each node in a set of nodes of a database system, a table partition of a plurality of table partitions, the plurality of table partitions being provided by partitioning a table using a primary key, providing, at each node in the set of nodes of the database system, a secondary index partition of a plurality of secondary index partitions, each secondary index partition including a replicate table of at least a portion of the table, the plurality of secondary index partitions being provided by partitioning the table using one or more secondary keys, and for at least one operation executed on a table partition, executing a replication protocol to replicate the at least one operation on a secondary index partition that corresponds to the table partition.

Supporting scalable distributed secondary index using replication engine for high-performance distributed database systems

Technologies are described for performing replication of data within a database environment having a source node and a replica node. The source node executes a database operation on at least one database table stored by the source node. The source node asynchronously sends the database operation to the replica node. A prepare commit request is synchronously sent from the source node to the replica node. The source node receives a synchronous precommit acknowledgement from the replica node. The precommit acknowledgement indicates that the database operation was executed at the replica node. The source node commits a transaction associated with the database operation.

Table replication in a database environment

RTR of a database transaction to a replica table may include receiving replication and transaction commit log entries (representing a database transaction). The replication log entry has a row-ID value, and the row at the replica table has a row-ID value. The replication log entry may be dispatched to a parallel log replayer and the associated transaction commit log entry to a transaction commit log replayer. The row-ID values may be compared, and the replication log entry is replayed at the parallel log replayer based on the comparison. The database transaction may then be committed to the replica table by replaying the associated transaction commit log entry at the transaction log replayer, wherein the database transaction is associated with row-level parallel replay having transactional consistency and DDL replication and reconstruction of a DDL statement at the replica system is associated with one or multiple metadata update log entries.

Real-time cross-system database replication for hybrid-cloud elastic scaling and high-performance data virtualization

A computer implemented method is provided comprising receiving a group of transaction logs from a first database, allocating transaction logs from the group of transaction logs to a first queue and to a second queue, generating an end-of-group transaction log indicative of an end of the group of transaction logs, allocating the end-of-group log to the first queue and the second queue; replaying transaction logs from the first queue including the end-of-group transaction log allocated to the first queue, replaying transaction logs from the second queue including the end-of-group transaction log allocated to the second queue; and changing visibility of one or more transactions in response to replaying the end-of-group transaction log allocated to the first queue and the end-of-group transaction log allocated to the second queue. Related apparatus, systems, techniques and articles are also described.

Delayed snapshot isolation for read service at a database

Innovations in the area of server-side processing when committing transactions to disk in a distributed database system can improve computational efficiency at database nodes and/or reduce network bandwidth utilization. For example, when transactions are committed in a database system, at a master node of the database system, a server uses different threads for certain processor-intensive operations and certain I/O-intensive operations. Or, as another example, when transactions are committed in a database system, at a master node of the database system, a server groups jobs for I/O requests.

Transaction commit operations with thread decoupling and grouping of I/O requests

Technologies are described for facilitating transaction processing within a database environment having a coordinator node, a first worker node, and at least a second worker node. The first worker node sends a request from to the coordinator node for at least a first synchronization token maintained by the coordinator node. The first worker node receives the at least a first synchronization token from the coordinator node. The first worker node assigns the at least a first synchronization token to a snapshot as a snapshot ID value. The snapshot is executed at the first worker node. The first worker node forwards the snapshot ID value to the at least a second worker node.

Distributed database transaction protocol

Growing community of inventors

Seoul, South Korea

Kyu Hwan Kim