Abstract: A computer implemented method is provided. The method comprises initializing a first database image of a first database system based on a recovery image comprising committed transactions, visible uncommitted transactions, and undo logs associated with the visible uncommitted transactions, undoing the visible uncommitted transactions using the undo logs, generating redo logs from the undo logs, replaying the redo logs to create invisible uncommitted transactions, and after replaying the redo logs, replaying transaction logs received from a second database system. Related apparatus, systems, techniques and articles are also described.

Abstract: An oldest version timestamp is received from a first database. A current commit timestamp is received from a second database configured to asynchronously replicate the first database. The current global commit timestamp corresponds to a commit transaction executed in the first database and subsequently replicated in the second database. A first test query is then issued to the second database including a request for a current timestamp of the second database. A second test query is issued to the primary database requesting records associated with a target update version that has a target timestamp equal to the current snapshot timestamp. A determination is then made that a first return associated with the first test query and a second return associated with the second test query are identical indicating a successful validation. Related apparatus, systems, techniques and articles are also described.

Abstract: 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.

Abstract: Technologies are described for performing replication within a database environment. Where a database transaction is replicated at multiple replica nodes, a replica node is selected as a coordinator replica node for the transaction. The other replica node or nodes are designated as follower replica nodes for the transaction. A follower replica node sends the coordinator replica node a precommit notification when the follower replica node has precommitted the transaction. The coordinator replica node sends the follower replica node a postcommit notification to commit the transaction when the transaction has been precommitted by all of the replica nodes to which the transaction is to be replicated.

Abstract: 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.

Abstract: 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.

Abstract: A computer implemented method is provided. The method comprises initializing a first database image of a first database system based on a recovery image comprising committed transactions, visible uncommitted transactions, and undo logs associated with the visible uncommitted transactions, undoing the visible uncommitted transactions using the undo logs, generating redo logs from the undo logs, replaying the redo logs to create invisible uncommitted transactions, and after replaying the redo logs, replaying transaction logs received from a second database system. Related apparatus, systems, techniques and articles are also described.

Abstract: 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.

Abstract: A computer implemented method for initializing a first image of a first database from a recovery image; modifying the first image of the first database by replaying transaction logs of a second database; establishing a connection with a client; receiving a query via the connection, the query including a transaction to be executed on the first database; and rejecting the query when the transaction would cause any one of: updating of the first image of the first database; generating a new transaction log; and modifying the recovery image. Related apparatus, systems, techniques and articles are also described.

Abstract: Disclosed herein are system, method, and computer program product embodiments for synchronizing lost change between a source table and a replica table. An embodiment operates by detecting a restart at a source node or a replica node. Row-ID values of replication log entries are then compared to row-ID column values of rows at a replica table of the replica node. Replication errors at a source table or the replica table are then determined based on the row-ID comparison. The rows of the source table and the replica table are then updated based on the determination.

Abstract: Disclosed herein are system, method, and computer program product embodiments for replicating a database transaction to a replica table. An embodiment operates by receiving a replication log entry and an associated transaction commit log entry for a database transaction to be replayed to a row at a replica table. A row-ID value of the replication log entry is compared to a row-ID column value of the row at the replica table. The replication log entry is then replayed at a parallel log replayer based on the comparison. The database transaction is then committed to the replica table by replaying the associated transaction commit log entry at a transaction log replayer.

Abstract: A system includes transmission of a first transaction identifier and a first commit identifier to a first data storage system, the first commit identifier identifying a first data snapshot of the first data storage system, transmission of a first query to the first data storage system, transmission of a first prepare instruction and the first transaction identifier to the first data storage system, determination that a first ready response has been received from the first data storage system in response to the first prepare instruction, transmission, in response to the determination, of a first commit instruction and the first transaction identifier to the first data storage system, and reception of a second commit identifier from the first data storage system, the second commit identifier identifying a second data snapshot of the first data storage system.

Abstract: Technologies are described for facilitating replay of requests for database operations. A plurality of requests for database operations are received. Each of the plurality of requests includes a type, an access unit identifier, and a chronological identifier. Execution dependencies are determined between the plurality of requests based on the type, access unit identifier, and chronological identifier of each of the plurality of requests. The execution dependencies are stored.

Abstract: 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.

Abstract: Technologies are described for performing replication within a database environment. For example, replication of database data can be performed using data manipulation language (DML) statements and logical logs. A database node can execute a DML statement, create a logical log comprising the DML statement, and insert the logical log into a logical log queue. The logical log can be sent to one or more other database nodes for execution of the DML statement stored within the logical log. Logical logs can be grouped for sending to other nodes. Logical logs can be executed on a first node and one or more other nodes within the same transaction boundary. Execution of DML statements can be decoupled from sending, receiving, grouping, and/or processing of logical logs.

Abstract: Technologies are described for facilitating transaction processing within a database environment having first, second, and third database system nodes. In the database system, the first database system node receives from the second database system node a request to precommit a first database transaction. The first database system node stores information for the first database transaction that includes an indication that the second database system node coordinates the committing of the first database transaction. The first database system node receives from the third database system node a request to precommit a second database transaction. The first database system node stores information for the second database transaction that includes an indication that the third database system node coordinates the committing of the second database transaction.

Abstract: 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.

Abstract: A method may include receiving a query for data to be provided by a database server, wherein the query includes an indication of a maximum lag. The method may further include determining whether a hint is available to apply to the query, wherein the hint affects an execution of the query. When no hint is available, a baseline database server may be selected to be the database server. When the hint is available, a replication server or a cache server may be selected to be the database server based on the hint and the maximum lag. The query may be processed at the selected database server.

Abstract: For each data change occurring transaction created as part of a write operation initiated for one or more tables in a main-memory-based DBMS, a transaction log entry can be written to a private log buffer corresponding to the transaction. All transaction log entries in the private log buffer can be flushed to a global log buffer upon completion of the transaction to which the private log buffer corresponds.

Abstract: 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.