Abstract: A data processing system implements techniques for provisioning and operating databases including receiving a request to provision a new database that includes multiple replicas. The data processing system provisions the new database including the plurality of replicas. The plurality of replicas includes a primary replica, one or more secondary replicas, and one or more delta replicas. The primary replica is configured to handle read and write operations. The one or more secondary replicas include a copy of data and transactional log information of the primary replica and are unable to handle write operations. The one or more delta replicas are a copy of the transactional log information of the primary replica and are unable to handle read operations or write operations.

Abstract: A computing device is provided, including non-volatile memory storing a database including a table having a plurality of rows. The computing device may further include a processor configured to receive a request to perform a first transaction on a row. The processor may assign a first transaction identifier (TID) of the first transaction to the row. The processor may impose a first exclusive TID lock on the first TID of the row and may impose a first exclusive data lock associated with the first transaction on the row. The processor may perform the first transaction on the row. Performing the first transaction may include modifying the table as stored in the memory. In response to completing the first transaction, the processor may release the first exclusive data lock on the row and release the first exclusive TID lock on the first TID of the row.

Abstract: The present application relates to database management in a cloud environment. A compute service generates a transaction log for database actions. The compute service writes at least a first portion of the transaction log to a log replica service. The log replica service replicates at least the first portion of the transaction log to two or more local log replicas persisted on solid state drives. A page server service updates database data in a remote storage based on at least a second portion of the transaction log retrieved from at least one of the log replicas. The page server service moves at least the second portion of the transaction log to the remote storage. The log replica service truncates the local log replicas by purging the second portion.

Abstract: A data processing system implements techniques for provisioning and operating databases including receiving a request to provision a new database that includes multiple replicas. The data processing system provisions the new database including the plurality of replicas. The plurality of replicas includes a primary replica, one or more secondary replicas, and one or more delta replicas. The primary replica is configured to handle read and write operations. The one or more secondary replicas include a copy of data and transactional log information of the primary replica and are unable to handle write operations. The one or more delta replicas are a copy of the transactional log information of the primary replica and are unable to handle read operations or write operations.

Abstract: A computing device is provided, including non-volatile memory storing a database including a table having a plurality of rows. The computing device may further include a processor configured to receive a request to perform a first transaction on a row. The processor may assign a first transaction identifier (TID) of the first transaction to the row. The processor may impose a first exclusive TID lock on the first TID of the row and may impose a first exclusive data lock associated with the first transaction on the row. The processor may perform the first transaction on the row. Performing the first transaction may include modifying the table as stored in the memory. In response to completing the first transaction, the processor may release the first exclusive data lock on the row and release the first exclusive TID lock on the first TID of the row.

Abstract: A relational database system that implements persistent version storage may include an in-row module that is executable by one or more processors to implement an in-row scheme by storing in-row previous version information within a payload of a row within a database page. The relational database system may additionally include an off-row module that is executable by the one or more processors to implement an off-row scheme by storing off-row previous version information in an off-row page that is separate from the database page. The relational database system may additionally include a storage policy that defines when previous version information is stored in accordance with the in-row scheme and when the previous version information is stored in accordance with the off-row scheme. The relational database system may additionally include a cleanup module that cleans up older versions when they are deemed unnecessary by the system.

Abstract: A method for supporting concurrent updates to a database page may include providing shared access to the database page. A first update may be performed with respect to a first record in the database page. A second update may be performed with respect to a second record in the database page. The first update and the second update may be performed concurrently while the shared access to the database page is being provided. The method may also include synchronizing the first update and the second update.

Abstract: Database recovery can be performed in substantially constant time. From a database transaction log, the state of one or more transactions is identified including those that were active at a time of a crash but not committed. Transactions can be reapplied sequentially starting from the beginning of a last successful checkpoint to the end of the transaction log. Uncommitted user transactions are not undone synchronously, but simply marked as aborted. Subsequently, versions of affected data elements can be reverted back to a prior saved version asynchronously.

Abstract: A Distributed Availability Group (DAG) spans two AGs, each spanning one or more replica nodes and functioning as primary or secondary AG. A primary AG is replicated to the secondary AG synchronously or asynchronously. A failover in the DAG results in the AGs swapping their roles. Multiple DAGs can be linked together as a chain, which provides many useful features including disaster recovery across geographical regions, massive read scale (numerous readable secondary nodes), online migration of databases (across different operating systems and computing environments). The systems using DAGs can replicate databases across multiple independent high availability (HA) failover clusters using complex replication topologies and allow for manual failover and failback. The systems allow chaining of multiple AGs to provision a treelike structure of replicas and numerous secondary replicas without impacting performance.

Abstract: A Distributed Availability Group (DAG) spans two AGs, each spanning one or more replica nodes and functioning as primary or secondary AG. A primary AG is replicated to the secondary AG synchronously or asynchronously. A failover in the DAG results in the AGs swapping their roles. Multiple DAGs can be linked together as a chain, which provides many useful features including disaster recovery across geographical regions, massive read scale (numerous readable secondary nodes), online migration of databases (across different operating systems and computing environments). The systems using DAGs can replicate databases across multiple independent high availability (HA) failover clusters using complex replication topologies and allow for manual failover and failback. The systems allow chaining of multiple AGs to provision a treelike structure of replicas and numerous secondary replicas without impacting performance.

Abstract: A Distributed Availability Group (DAG) spans two AGs, each spanning one or more replica nodes and functioning as primary or secondary AG. A primary AG is replicated to the secondary AG synchronously or asynchronously. A failover in the DAG results in the AGs swapping their roles. Multiple DAGs can be linked together as a chain, which provides many useful features including disaster recovery across geographical regions, massive read scale (numerous readable secondary nodes), online migration of databases (across different operating systems and computing environments). The systems using DAGs can replicate databases across multiple independent high availability (HA) failover clusters using complex replication topologies and allow for manual failover and failback. The systems allow chaining of multiple AGs to provision a treelike structure of replicas and numerous secondary replicas without impacting performance.

Abstract: A Distributed Availability Group (DAG) spans two AGs, each spanning one or more replica nodes and functioning as primary or secondary AG. A primary AG is replicated to the secondary AG synchronously or asynchronously. A failover in the DAG results in the AGs swapping their roles. Multiple DAGs can be linked together as a chain, which provides many useful features including disaster recovery across geographical regions, massive read scale (numerous readable secondary nodes), online migration of databases (across different operating systems and computing environments). The systems using DAGs can replicate databases across multiple independent high availability (HA) failover clusters using complex replication topologies and allow for manual failover and failback. The systems allow chaining of multiple AGs to provision a treelike structure of replicas and numerous secondary replicas without impacting performance.

Abstract: A Distributed Availability Group (DAG) spans two AGs, each spanning one or more replica nodes and functioning as primary or secondary AG. A primary AG is replicated to the secondary AG synchronously or asynchronously. A failover in the DAG results in the AGs swapping their roles. Multiple DAGs can be linked together as a chain, which provides many useful features including disaster recovery across geographical regions, massive read scale (numerous readable secondary nodes), online migration of databases (across different operating systems and computing environments). The systems using DAGs can replicate databases across multiple independent high availability (HA) failover clusters using complex replication topologies and allow for manual failover and failback. The systems allow chaining of multiple AGs to provision a treelike structure of replicas and numerous secondary replicas without impacting performance.

Abstract: Consistent read queries are enabled from a secondary compute node. In response to a read query, a page of data can be requested from a storage node with a first log sequence number indicating an update state of a local store of a compute node. The page of data can be received from the storage node with a second log sequence number indicating an update state of the page. Processing can be deferred until the first log sequence number is greater than or equal to the second log sequence number, wherein the first log sequence number is updated in response to automatic updates of the local store. A row of data can be retrieved from the page in accordance with the request. Further, a version of the row of data can be retrieved that has a timestamp equal to or before a timestamp associated with initiation of the read request.

Abstract: Database recovery can be performed in substantially constant time. From a database transaction log, the state of one or more transactions is identified including those that were active at a time of a crash but not committed. Transactions can be reapplied sequentially starting from the beginning of a last successful checkpoint to the end of the transaction log. Uncommitted user transactions are not undone synchronously, but simply marked as aborted. Subsequently, versions of affected data elements can be reverted back to a prior saved version asynchronously.

Abstract: A relational database system that implements persistent version storage may include an in-row module that is executable by one or more processors to implement an in-row scheme by storing in-row previous version information within a payload of a row within a database page. The relational database system may additionally include an off-row module that is executable by the one or more processors to implement an off-row scheme by storing off-row previous version information in an off-row page that is separate from the database page. The relational database system may additionally include a storage policy that defines when previous version information is stored in accordance with the in-row scheme and when the previous version information is stored in accordance with the off-row scheme. The relational database system may additionally include a cleanup module that cleans up older versions when they are deemed unnecessary by the system.

Abstract: A method for supporting concurrent updates to a database page may include providing shared access to the database page. A first update may be performed with respect to a first record in the database page. A second update may be performed with respect to a second record in the database page. The first update and the second update may be performed concurrently while the shared access to the database page is being provided. The method may also include synchronizing the first update and the second update.

Abstract: Systems and methods according to various embodiments disclose a worker process manager adapted to spawn one or more worker processes on a server and to load an application on each of the worker processes. The worker process manager is adapted to isolate the one or more worker processes from each other and to control resource usage by the worker processes. A resource manager is adapted to detect applications that overuse system resources. The worker process manager is adapted to isolate worker processes and to control resource usage using one or more of the following techniques: least-privilege execution, messaging isolation, credentials isolation, data isolation, network isolation, fair share resource usage, and managed runtime security. Heuristic algorithms are used to detect applications that frequently overuse system resources that are unchargeable and that cause system unresponsiveness.

Abstract: Aspects extend to methods, systems, and computer program products redoing transaction log records in parallel. Different aspects of replaying log records are allocated to different threads, for example, read threads, analysis threads, logical operation redo threads, and page operation redo threads. The different threads can be distributed across different processor cores. Activities at read threads, analysis threads, logical operation redo threads, and page operation redo threads can be performed on an ongoing basis and in parallel with activities at other threads (including user tasks). In some aspects, pre-allocated memory blocks are used in a lock free manner to store log records prior to processing by a page operation redo thread.

Abstract: A Distributed Availability Group (DAG) spans two AGs, each spanning one or more replica nodes and functioning as primary or secondary AG. A primary AG is replicated to the secondary AG synchronously or asynchronously. A failover in the DAG results in the AGs swapping their roles. Multiple DAGs can be linked together as a chain, which provides many useful features including disaster recovery across geographical regions, massive read scale (numerous readable secondary nodes), online migration of databases (across different operating systems and computing environments). The systems using DAGs can replicate databases across multiple independent high availability (HA) failover clusters using complex replication topologies and allow for manual failover and failback. The systems allow chaining of multiple AGs to provision a treelike structure of replicas and numerous secondary replicas without impacting performance.