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: 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: 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: 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: Disclosed herein are system, method, and computer readable device embodiments for parallel replication of databases across row-store and column-store table formats. An embodiment operates by maintaining a replication log and a storage-level recovery log formatted according to separate respective log formats, logging a record-level SQL execution result, and replicating at least one database table from a primary server to at least one replica server. The primary server and the at least one replica server may each be configured to store data according to one table format of a row-store table format and a column-store table format, such that the primary server's table format is different from the at least one replica server's table format.

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: Technologies are described for performing synchronization within a database environment. A source host stores multiple database tables and a replica host stores copies of the multiple database tables. During synchronization, replication log replay is blocked at the replica node, and a multithreaded process locks the multiple database tables of the source hosts, reactivates replication log generation for each of the multiple database tables, and then unlocks the database tables. A synchronization timestamp is acquired and used to synchronize the multiple database tables with the copies of the multiple database tables. After synchronization, replication log replay is reactivated at the replica host for the copies of the multiple database tables.

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

Abstract: Technologies are described for performing synchronization within a database environment. A source host stores multiple database tables and a replica host stores copies of the multiple database tables. During synchronization, replication log replay is blocked at the replica node, and a multithreaded process locks the multiple database tables of the source hosts, reactivates replication log generation for each of the multiple database tables, and then unlocks the database tables. A synchronization timestamp is acquired and used to synchronize the multiple database tables with the copies of the multiple database tables. After synchronization, replication log replay is reactivated at the replica host for the copies of the multiple database tables.

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

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.

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

Abstract: Disclosed herein are system, method, and computer program product embodiments for minimizing table lock duration during lost change resynchronization between a source table and a replica table. An embodiment operates by detecting a restart at a source node or a replica node. A source table at the source node is then locked based on the detection. A database transaction is then created for a lost change resynchronization operation and the source table is unlocked. The database transaction is then compared to another database transaction based on its timestamp. Based on the comparison, either the database transaction for the lost change resynchronization operation or the other database transaction is executed.

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.