Abstract: Embodiments are directed to implementing a transitional redo phase to allow pre-redo phase data access and to determining which data pages including unprocessed transactions are to be processed during a transitional redo phase. In an embodiment, a computer system initiates an analysis phase of a database recovery that scans a database transaction log and builds a dirty page table that includes pages corresponding to unprocessed data transactions. The computer system determines from the dirty page table which pages are to be processed during the transitional redo phase, before the final redo phase. The computer system processes the determined pages during the transitional redo phase, before the final redo phase is reached and, upon completion of the system transaction undo phase, makes available those pages that were processed during the transitional redo phase, as well as those database pages that are not scheduled for processing during the final redo phase.

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

Abstract: A method includes requesting a lock on a resource. The request for the lock on the resource is specified as a low priority non-blocking request that does not block one or more other requests such that one or more other requests can request a lock on the resource and obtain the lock on the resource in priority to the low priority non-blocking request. Based on the low priority request, the method includes maintaining the low priority request in a non-blocking fashion until a predetermined condition occurs. As a result of the predetermined condition occurring, the method includes handling the low priority request such that it is no longer treated as a low priority non-blocking request. Embodiments may further include a kill request which kills any operations on the resource, aborts any transactions having a lock on the resource, and locks the resource.

Abstract: Managing database recovery time. A method includes receiving user input specifying a target recovery time for a database. The method further includes determining an amount of time to read a data page of the database from persistent storage. The method further includes determining an amount of time to process a log record of the database to apply changes specified in the log record to a data page. The method further includes determining a number of dirty pages that presently would be read in recovery if a database failure occurred. The method further includes determining a number of log records that would be processed in recovery if a database failure occurred. The method further includes adjusting at least one of the number of dirty pages that presently would be read in recovery or the number of log records that would be processed in recovery to meet the specified target recovery time.

Abstract: Embodiments are directed to implementing a transitional redo phase to allow pre-redo phase data access and to determining which data pages including unprocessed transactions are to be processed during a transitional redo phase. In an embodiment, a computer system initiates an analysis phase of a database recovery that scans a database transaction log and builds a dirty page table that includes pages corresponding to unprocessed data transactions. The computer system determines from the dirty page table which pages are to be processed during the transitional redo phase, before the final redo phase. The computer system processes the determined pages during the transitional redo phase, before the final redo phase is reached and, upon completion of the system transaction undo phase, makes available those pages that were processed during the transitional redo phase, as well as those database pages that are not scheduled for processing during the final redo phase.

Abstract: Managing database recovery time. A method includes receiving user input specifying a target recovery time for a database. The method further includes determining an amount of time to read a data page of the database from persistent storage. The method further includes determining an amount of time to process a log record of the database to apply changes specified in the log record to a data page. The method further includes determining a number of dirty pages that presently would be read in recovery if a database failure occurred. The method further includes determining a number of log records that would be processed in recovery if a database failure occurred. The method further includes adjusting at least one of the number of dirty pages that presently would be read in recovery or the number of log records that would be processed in recovery to meet the specified target recovery time.

Abstract: A buffer manager that manages blocks of memory amongst multiple levels of buffer pools. For instance, there may be a first level buffer pool for blocks in first level memory, and a second level buffer pool for blocks in second level memory. The first level buffer pool evicts blocks to the second level buffer pool if the blocks are not used above a first threshold level. The second level buffer pool evicts blocks to a yet lower level if they have not used above a second threshold level. The first level memory may be dynamic random access memory, whereas the second level memory may be storage class memory, such as a solid state disk. By using such a storage class memory, the working block set of the buffer manager may be increased without resorting to lower efficiency random block access from yet lower level memory such as disk.

Abstract: Described is a technology by which a database management system more efficiently processes read requests than write requests for a read-mostly database table, which is a database table that is generally read far more often than written. A lock partitioning mechanism may be implemented to provide a read lock for each CPU of a plurality of CPUs, in which only one read lock is acquired to process a read request. A database table state changing mechanism may be implemented that more efficiently processes read requests relative to write requests by maintaining the database table in a read-only state until a write request is processed. When a write request is received, the database table is changed to a read-write state to process the write request. The database table is then reset back to a read-only state, such as by running a background thread.

Abstract: To ensure that logs representative of data changes are durably written, localized storage media cache is flushed to force a write to stable storage. Log sequence number tracking is leveraged to determine if log data in a localized storage media cache is likely to have not been written to durable storage. When this condition is likely, a FLUSH_CACHE command is issued to a storage media controller to force a durable write. This allows recovery of data changes to a transactional system even when its associated storage media does not provide write-ordering guarantees. Moreover, flushing of the storage media cache can be accomplished at a frequency that provides an upper bound on a maximum time between a transaction commit and data being made durable.

Abstract: A system and method for serialization and/or de-serialization of file system item(s) and associated entity(ies)is provided. A file system “item” comprises a core class which can include property(ies). Through serialization, a consistent copy of the item and associated entity(ies), such as fragment(s), link(s) with other item(s) and/or extension(s),if any, can be captured. The serialization system includes an identification component that identities entity(ies) associated with an item and a serialization component that serializes the item and associated entity(ies). The serialization component can further serialize a header that includes information associated with the item and associated entity(ies). The header can facilitate random access to the item and associated entity(ies). The serialization system can expose application program interface(s) (API's) that facilitate the copying, moving and/or transfer of an item and its associated entity(ies) from one location to another location.

Abstract: The subject invention relates to systems and/or methods that perform an authoritative and/or a non-authoritative restore of items in a data store. Backups are provided that include data associated with items and metadata related to the items that can include a history of operations and previous synchronizations to enable replications to converge after restoration. The operations that can be performed on the items include, for example, create, delete, update, move, etc. The items in the backups can be restored along with the metadata, which can be utilized to enable synchronization partners to converge based on a desired type of restoration.

Abstract: The subject invention relates to systems and methods that enable pausing and/or resuming a backup of file system items. The items are backed up in an order based on a unique property associated with each of the items. When the backup is paused, the unique property associated with a last backed up item prior to the pause is stored. Additionally, a timestamp associated with a snapshot from which the backup was taken can be stored with the unique property. Upon being resumed, the backup can continue from the paused location via utilizing the stored unique property. The backup can be resumed either employing an original snapshot associated with a time prior to the pause or a second snapshot related to a subsequent time. The subject invention can perform an initial backup of file system items and/or an incremental backup of such items. Additionally, the subject invention can support backing up a file system at disparate levels of granularity such as, for example, an item level.

Abstract: Described is a technology by which a database management system more efficiently processes read requests than write requests for a read-mostly database table, which is a database table that is generally read far more often than written. A lock partitioning mechanism may be implemented to provide a read lock for each CPU of a plurality of CPUs, in which only one read lock is acquired to process a read request. A database table state changing mechanism may be implemented that more efficiently processes read requests relative to write requests by maintaining the database table in a read-only state until a write request is processed. When a write request is received, the database table is changed to a read-write state to process the write request. The database table is then reset back to a read-only state, such as by running a background thread.

Abstract: To ensure that logs representative of data changes are durably written, localized storage media cache is flushed to force a write to stable storage. Log sequence number tracking is leveraged to determine if log data in a localized storage media cache is likely to have not been written to durable storage. When this condition is likely, a FLUSH_CACHE command is issued to a storage media controller to force a durable write. This allows recovery of data changes to a transactional system even when its associated storage media does not provide write-ordering guarantees. Moreover, flushing of the storage media cache can be accomplished at a frequency that provides an upper bound on a maximum time between a transaction commit and data being made durable.

Abstract: The present invention is directed a logical consistency checker (LCC) working alone or in conjunction with a physical consistency checker (PCC) and/or a data reliability system (DRS) for a database files system of a hardware/software interface system. Logical data correction pertains to logical data corruptions for entities (e.g., items, extensions, and/or relationships in an item-based operating system, where an item-based operating system is one example of an item-based hardware/software interface system). In this regard, a LCC analyses and corrects logical damage to entities representatively stored in the data store in order to ensure that all such entities in said data store are both consistent and conform to the data model rules.

Abstract: The present invention relates generally to database and file system management and, more particularly, to automatic database and file system maintenance and repair to ensure data reliability. Various aspects of the present invention relate to responding and correcting data corruptions at a data page level for all data page types, as well as to recovery (including rebuild or restore operations) for various scenarios including, without limitation, index page corruptions (clustered and non-clustered), data page corruptions, and page corruptions in the log file.