Microsoft Technology Licensing, LLC

Peter Byrne

Hanumantha Rao Kodavalla

Girish Mittur Venkataramanappa

Raghavendra Thallam Kodandaramaih

Rui Wang

Panagiotis Antonopoulos

Robin Dhananjay Dhamankar

Wei Ting Chen

Adrian-Leonard Radu

Cristian Diaconu

Jakub Kulesza

Michael James Zwilling

Naveen Prakash

Alejandro Hernandez Saenz

Sandeep Lingam

Qun Guo

Alexander Budovski

Rajeev Bashyam Rajan

Krystyna Ewa Reisteter

Rogerio Ramos

Huanhui Hu

Michael Habben

Mark Wistrom

Xiaowei Jiang

Gregory A Smith

Shashikant Brijmohan Khandelwal

Craig Steven Freedman

Gregory Irving Thiel

Yogesh Bansal

Vishal Kathuria

Mahesh K Sreenivas

Rahul Mittal

Varun Kunjbihari Tibrewal

Yixue Zhu

Srikanth Sampath

Prashanth Purnananda

Shuab Khan

Ross Edward Smith, Iv

Chaitanya Sreenivas Ravella

Leigh M Stewart

Wei Chen

Srinag Rao Sadananda

Gururama Jithendra Gandikota

Systems, methods, apparatuses, and program products are disclosed for granular tracking of locking queries. Upon receiving a data manipulation command associated with a row of a page, a flag associated with the page is checked to determine whether a row locking query (RLQ) may be associated with the page. If no RLQ is associated with the page, the data manipulation command is executed without acquiring a lock. If an RLQ may be associated with the page, it is determined whether an active lock is associated with the page. If no active lock is associated with the page, the flag is updated to indicate that no RLQ is associated with the page and the data manipulation command is executed without acquiring a lock. If an active lock is associated with the page, page-level and row-level locks are acquired on the page and the row, respectively, before executing the data manipulation command.

Granular tracking of locking queries to reduce locking

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.

Transaction identifier locking with data row locks

Embodiments described herein detect data corruption in a distributed data set system. For example, a system comprises node(s) for processing queries with respect to a distributed data set comprising a plurality of storage segments. A write transaction resulting from a query with respect to a particular storage segment is logged in a log record that describes a modification to the storage segment. A log service provides the log record to a data server managing a portion of the distributed data set in which the storage segment is included, which performs the write transaction with respect to the storage segment. For redundancy purposes, the data server has replica(s) that manage respective replicas of the portion of the distributed data set managed thereby. For backup purposes, snapshots of the replica(s) are periodically generated. To determine a data corruption, a snapshot of one replica is cross-validated with a snapshot of another replica.

Snapshot-based data corruption detection

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.

Persistent version storage for relational database management system

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.

Supporting concurrent updates to a database page

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.

Constant time database recovery

Consolidating a set of tenant log streams from separate user databases into a consolidated log stream. The method includes receiving a plurality of tenant log streams from separate user data bases. The method further includes recording the plurality of tenant log streams as a consolidated log stream. The method further includes maintaining metadata about the consolidated log stream to map log records from the plurality of tenant log streams to their location in the consolidated log stream.

Log consolidation

Techniques to leverage replication to provide rolling point in time backup are described. Some embodiments are directed to techniques to provide rolling point in time backup with simplified restoration through distributed transactional re-creation. In one embodiment, for example, a technique may comprise creating a plurality of availability copies of a primary set of data; designating at least one of the plurality of availability copies as a backup copy; creating a log file that indicates changes to the primary set of data; updating the plurality of availability copies from the log file in near real time, without updating the backup copy; and restoring at least one of: the primary set of data and an availability copy using the backup copy and content resubmitted from a content contributor when an error occurs in at least one of: the primary set of data and an availability copy. Other embodiments are described and claimed.

Techniques for leveraging replication to provide rolling point in time backup with simplified restoration through distributed transactional re-creation

Architecture that addresses an end-to-end solution for logical transactional replication from a shared-nothing clustered database management system, which uses adaptive cloning for high availability. This can be time based using a global logical timestamp. The disclosed architecture, used for refreshing stale clones, does not preserve user transaction boundaries, which is a more complex situation than where the boundaries are preserved. In such a scenario it is probable that for a given data segment no clone of the segment may contain the complete user transaction history, and hence, the history has to be pieced together from the logs of multiple different clones. This is accomplished such that log harvesting is coordinated with the clone state transitions to ensure the correctness of logical replication.

Logical replication in clustered database system with adaptive cloning

Searching cached log blocks. A method includes performing a first search on cached log blocks for a log block having a first log block ID. The log blocks are cached and organized into sequentially ordered log buffers in memory. Adjacent sequentially ordered log buffers are double linked to each other. Each log buffer includes a complete range of log blocks from a starting log block ID to an ending log block ID. As part of the first search one or more links are followed, forward and/or backward, to one or more other log buffers. The method may further include determining that the first log block is not found by following one or more links forward and/or backward to one or more other log buffers and as a result, follow one or more covering pointers to one or more log buffers to search for the first log block.

Lightweight caching of transaction log for sequential access

The present invention relates to a system and method of data restoration, for instance, after the occurrence of a user error. In particular, snapshot database can be maintained that stores a copy of database data. The snapshot database does not have to store a complete copy of all data on a source database, but rather shares data that is common to both but not necessarily identical. If an error occurs on the primary database then the database can be reverted back to a point in time prior to the error by replacing source database files with snapshot files. Additionally, an undo component can be employed in conjunction with the snapshot to approach an error to a finer grained point in time. In brief, the present invention can restore a database much faster and simpler, while utilizing less space and resources than conventional data restoration technologies.

Database data recovery system and method

Aspects of the subject matter described herein relate to data change ordering in multi-log based replication. In aspects, local seeds are maintained for subtransactions involved in a transaction, where each subtransaction may occur on a different node that hosts one or more database fragments involved in the transaction. When a subtransaction communicates with another subtransaction in a transaction, the subtransaction sends its local seed to the other subtransaction. The receiving subtransaction compares its local seed with the received seed and updates its local seed if the received seed is logically after its local seed. A subtransaction uses a local seed to generate sequence identifiers for changes made by the subtransaction. These identifiers allow data changes of a transaction that are made on multiple nodes to be partially ordered relative to other changes made during the transaction.

Data change ordering in multi-log based replication

The creation of multiple recoverable units within a database allows a database partition to be reconstructed during maintenance and disaster recovery operations. A method of creating a recovery unit includes partitioning a database into at least two recovery units. A primary catalog of metadata relating to the logical elements of a database such as tables, indexes, and file groups is created. A secondary catalog of metadata relating to the physical elements of a database such as pages, files, B-Trees, and log streams is created for each recovery unit. The primary and secondary metadata catalogs are linked such that only one log stream is associated with any one recovery unit. A single recovery unit may then be exercised to perform recovery or maintenance operations while the remaining recovery units of the database remain online.

System and method for recovery units in databases

Growing community of inventors

Charlotte Hall, MD, United States of America

Peter Byrne