Constant time database recovery

Abstract

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

Description

Background Art

[0001] The present disclosure relates to the field of computer science and, in particular, to database recovery. Background Art

[0003] Databases are transaction systems that can provide certain guarantees, namely atomicity, consistency, isolation, and durability (known as ACID properties). A transaction is an action or series of actions that reads or updates the contents of a database. For example, a transaction can be a money transfer that debits a first account and credits a second account. An atomic transaction is a transaction in which all actions are performed or none of the actions are performed. Money is not debited from the first account and the second account is not credited. Consistency refers to the requirement that transactions change data in an allowed way to produce a new valid state from a previous valid state. For example, money cannot be lost or gained. Isolation ensures that ongoing transactions are isolated from each other. For example, the first account and the second account cannot be viewed until the operation is completed. In addition, changes are durable in that the data can maintain its correct state even in the event of a failure or system restart.

[0004] At any point in time, the database may need to recover from a crash or failure caused by power outages, critical errors in the code, disk crashes, or natural disasters. The database recovery process ensures that the database returns to a consistent state. Many databases adopt the ARIES (Recovery and Isolation Algorithm with Semantics) transaction recovery protocol. ARIES consists of three phases: analysis, redo, and undo. First, the transaction log is traversed to identify all transactions and their states at the time of the crash. Second, the transaction log is traversed in chronological order to the end of the log, and the operations are redone sequentially to return the database to a state consistent with the crash. Third, the transaction log is traversed backwards from the end of the log to the oldest active transaction, and all operations performed by uncommitted transactions are undone or rolled back. Summary of the invention

[0005] A simplified overview is presented below in order to provide a basic understanding of some aspects of the disclosed subject matter. This summary is not an extensive overview. It is not intended to identify key / critical elements or to delineate the scope of the claimed subject matter. Its sole purpose is to present some concepts in a simplified form as a prelude to a more detailed description that will be presented later.

[0006] Briefly described, the present disclosure relates to constant time database recovery. Recovery includes: identifying transactions specified in a transaction log of a database, and redoing the transactions in chronological order starting from the last successful checkpoint to the end of the transaction log. In addition, uncommitted transactions are marked as aborted, and further processing of uncommitted transactions is performed asynchronously. Subsequently, transactions marked as aborted are identified, and the data is restored to a previously committed version. In addition, there is a subset of transaction operations that cannot be versioned. One category involves logical operations bound to user transactions. These operations can be added to an auxiliary log, which can be used to synchronously redo and undo those transactions. In addition, the transaction log can be substantially truncated by removing transactions before the checkpoint.

[0007] To achieve the foregoing and related purposes, certain illustrative aspects of the claimed subject matter are described herein in conjunction with the following description and accompanying drawings. These aspects indicate various ways in which the subject matter may be practiced, all of which are intended to be within the scope of the disclosed subject matter. Additional advantages and novel features may become apparent from the following detailed description when considered in conjunction with the accompanying drawings. BRIEF DESCRIPTION OF THE DRAWINGS

[0008] Figure 1 It is a schematic block diagram of a database recovery system.

[0009] Figure 2 is a schematic block diagram of an undo component.

[0010] Figure 3 It is a timeline diagram of database recovery.

[0011] Figure 4 It is a flowchart of the database recovery method.

[0012] Figure 5 is a flow chart of the cleaner method.

[0013] Figure 6 is a flow chart of a method for processing updates.

[0014] Figure 7 is a flow chart of a method for constructing an auxiliary log.

[0015] Figure 8 It is a flowchart of the method of database recovery.

[0016] Fig. 9 is a flowchart of a method for employing transaction locking during database recovery.

[0017] Fig.10 is a schematic block diagram illustrating a suitable operating environment for aspects of the present disclosure. DETAILED DESCRIPTION

[0018] Conventional database recovery protocols (including analyze, redo, and undo) perform recovery for the oldest active transaction. Therefore, the recovery time is proportional to the longest transaction size, which can be several hours for long-running transactions. This lengthy recovery can cause the database to be unavailable to users for a long time. In cloud environments, failures are significantly more frequent than on-premises deployments and are beyond the control of users. This leads to unexpected downtime and severe service interruptions, which reduces the quality of service. In addition, since the transaction log from the oldest active transaction is utilized, a large amount of disk space is required to maintain the log when long-running transactions are active.

[0019] This description relates to constant time database recovery. The recovery protocol is modified so that recovery can be performed substantially in constant time, rather than depending on the length of long-running active transactions. The transaction log can be analyzed to determine the state of the transaction at the time of the crash, including whether the transaction was committed or aborted. The transaction can then be redone or replayed in conjunction with a forward traversal of the transaction log from the last successful checkpoint to the end of the transaction log. However, the undo operation of the uncommitted transaction is not performed synchronously, and is performed backward from the end of the log to the oldest active transaction. Instead, the uncommitted transaction is so marked or tagged, and additional actions are performed asynchronously at a later time. The marked transaction can subsequently be used to restore the affected data to a previously committed version of the data. Therefore, redo and undo do not need to process the transaction log from the oldest active transaction and to the oldest active transaction. Therefore, as opposed to varying based on the oldest active transaction, the recovery time is limited by the checkpoint cycle, thereby significantly improving the availability of the database.

[0020] A large number of transactions are user transactions with physical operations that can be versioned. However, other user transaction operations that cannot be versioned may also occur, including, for example, logical operations associated with locking and cache coherence. To handle a limited set of logical operations as well as physical operations that are not versioned, an auxiliary or special log containing only these operations can be created. Such transaction operations can then be undone and redone in a synchronized manner relative to the oldest active transaction using the auxiliary log. However, database recovery time will not be affected in any significant way, at least due to the sparse frequency and short processing time of such logical operations compared to physical operations.

[0021] Additionally, the transaction log can be truncated to reduce the amount of space that needs to be allocated. More specifically, the transaction log can be proactively truncated to remove transactions before a checkpoint. Truncating the transaction log in this manner allows large transactions to be performed using a small and constant amount of log space.

[0022] Various aspects of the present disclosure are now described in more detail with reference to the accompanying drawings, wherein throughout the text, the same reference numerals generally refer to the same or corresponding elements. However, it should be understood that the drawings and the detailed description related thereto are not intended to limit the claimed subject matter to the specific forms disclosed. On the contrary, it is intended to cover all modifications, equivalents and alternatives that fall within the spirit and scope of the claimed subject matter.

[0023] First reference Figure 1 , a database recovery system 100 is illustrated. The database recovery system 100 interacts with a database 102 and a transaction log 104. The transaction log 104 is a write-ahead log, in which all modifications to the database 102 are written to the transaction log before the modifications are applied to the database 102. The database 102 is a non-volatile computer-readable storage medium. In one example, the database 102 provides version control storage for user data. Instead of performing an update in place to replace the current data, the update is not effectively performed in place. In other words, the update generates a new version of the data element, which can be linked to the old version. As an example, if a first account indicates a balance of $100, and a loan of $10 is added, the balance will be updated to $110 by generating a new version linked to the old balance of $100. The database recovery system 100 utilizes the transaction log 104 to enable the database 102 to recover from a crash or other failure (e.g., caused by a power outage, a disk crash, a critical error, or a natural disaster). The database recovery system 100 includes an analysis component 110 , a redo component 120 , an undo component 130 , a cleaner component 140 , an auxiliary log component 150 , a log truncation component 160 , and a locking component 170 .

[0024] The analysis component 110 traverses the transaction log 104 and determines the state of each transaction after the crash. Checkpoints can be performed periodically (e.g., every two minutes) during normal processing, and active transactions, their states, and modified data (e.g., dirty pages) are recorded in the buffer pool. The analysis component 110 can start the analysis from the last successful checkpoint and forward to the end of the transaction log. Each transaction can be identified and its state determined, such as whether the transaction is committed or aborted. The analysis component 110 can also determine additional information used by one or both of the redo component 120 and the undo component 130. As an example and not limitation, the analysis component 110 can determine the starting point of the redo (i.e., the redo log sequence number) and can determine the transactions to be undone or rolled back.

[0025] The redo component 120 is configured to redo transactions in the event of a crash to reestablish the state of the database 102. In other words, the redo component 120 replays transactions. Transactions are replayed forward and sequentially from the beginning to the end of the transaction log. The starting point may be the time of the last successful checkpoint, or may be a redo log sequence number identified by the analysis component 110. Due to possible state inconsistencies, the database may be made unavailable until the redo is complete.

[0026] The undo component 130 is configured to effectively undo uncommitted transactions to return the database to a consistent state. It may be very time consuming to traverse the transaction log backwards or in reverse chronological order from the end of the transaction log to the oldest uncommitted transaction. For example, consider a transaction that updates every record in the database 102 to apply interest to an account. If the database 102 crashes before the transaction is committed to the persistent storage device, all changes will need to be undone to maintain database consistency. According to one aspect of the present disclosure, the undo component 130 may simply mark or flag the transaction as aborted or revoked and postpone subsequent processing. Each data element in the database 102 may be associated with a version and include a transaction identifier. If the transaction identifier is marked as aborted, the database 102 may be restored to a previous value.

[0027] The cleaner component 140 is configured to perform a cleanup of the database, which updates the data to a previous value or reclaims space. The cleanup process may be referred to as a logical restore. A logical restore is an operation that updates a data element with its last submitted version. There may be two phases - identification and update. First, the cleaner component 140 may determine whether a data element such as a row belongs to an aborted transaction. This may be determined by searching for data elements with transaction identifiers marked as aborted. Second, the uncommitted rows are replaced with the latest submitted version. In one embodiment, a logical restore may be performed by performing a compensating operation that may include an insert, delete, or modify. For example, if the latest version of a record on a page is ghosted, meaning that the row is marked for deletion, the compensating operation is an insert. Conversely, if the current version of the record is not a shadow record, but the record submitted in the past is empty or a shadow record, the compensating operation is a delete. Otherwise, the compensating operation may be a modification operation, such as adding $10 to an account to increase the account from $100 to $110. According to one aspect, the cleaner component 140 and the logical restore process may be performed as a background process. Alternatively, such functionality may be triggered by updating a transaction. For example, before a data element is updated, a check may be made as to whether the data element is associated with a transaction marked as aborted. If the transaction is marked as aborted, a logical restore may be initiated.

[0028] The auxiliary log component 150 generates auxiliary logs or special logs for a subset of operations. A large number of database transactions are user transactions that perform physical operations (e.g., insert, update, delete...) that can be version controlled. There may be a subset of transaction operations that cannot be version controlled. One category involves logical operations that are still bound to user transactions, such as various metadata operations and the management of corresponding caches and counters. If the corresponding transaction is to be rolled back, this logical operation can also be undone. However, the undoing of such transactions may not be managed with version control because they are logical and there are no physical objects for version control. For these operations, auxiliary logs can be generated and maintained to enable recovery. The auxiliary log can be a sequential log stream similar to the transaction log 104. In addition, the checkpoint mechanism used to set checkpoints for the transaction log 104 can be changed to further support setting checkpoints for the auxiliary log. During recovery, the redo component 120 can reapply the operations in the auxiliary log in chronological order from the oldest active transaction to the end of the log, and the undo component 130 can roll back the operations associated with the uncommitted transactions in reverse chronological order from the end of the auxiliary log. Given that the number of log records in the auxiliary log is very small, the undo operation should be completed in a negligible time, such as in less than a second.

[0029] The log truncation component 160 is configured to truncate one or both of the transaction log 104 and the auxiliary log, which reduces space provisioning and management. Since recovery uses the transaction log 104 from the beginning of the last successful checkpoint (rather than from the oldest active transaction), as checkpoints occur, the log truncation component 160 can continuously truncate the transaction log 104 to eliminate records before the checkpoint. More specifically, the transaction log 104 can be used only to redo version-controlled transactions from the beginning of the checkpoint to the end of the log. The transaction log is not used to undo version-controlled transactions, and some non-version-controlled transactions are processed in conjunction with the auxiliary log. This allows users to perform large transactions using a smaller, constant amount of space. The auxiliary log is related to the beginning of the oldest active transaction and the end of the log. Therefore, the log truncation component 160 can eliminate any records that do not fall within this range.

[0030] In addition to non-versioned logical operations, there is also a collection of non-versioned system transactions associated with allocating new pages, storing additional data, or releasing unused space. The operations associated with these system transactions are highly compressed (e.g., one bit per sixty-four kilobytes) and difficult to version. In addition, these operations do not need to be bound to user transactions. For example, some additional space can be allocated even if the space is not used immediately. Therefore, according to one aspect of the present disclosure, these system transactions can be executed as short-term system transactions, which can be quickly recovered in the event of a crash. As an example, consider a large number of insert operations that require allocation of additional space. The corresponding system transaction can be executed quickly and essentially immediately after submission. Even if it is a small and fast operation, the operation may fail in the middle of execution. A traditional method can be performed in which such an operation is redone and then undone if it is not submitted. Although traditional recovery methods are used, transactions are fewer and shorter, so they do not significantly affect recovery time.

[0031] The locking component 170 is configured to lock data that has not been cleaned or undone. The database recovery system 100 can allow the database 102 to be available before the full recovery is completed. Conventional database systems store the locks acquired for each transaction in the transaction log and reacquire them during analysis and redo so that the database can be accessible when the undo occurs. The database recovery system 100 allows database access before the recovery is completed without having to store and reacquire all locks for each transaction during the recovery. Since each data element (e.g., row) version is marked with the transaction identifier of the transaction that generated the data element, the locking component 170 can apply an exclusive lock on the transaction identifier for each transaction to be recovered and make the database 102 available immediately after the redo. Any new access to the data element version will need to acquire a shared lock on the transaction identifier of the version, thereby synchronizing with the transaction in the middle of the recovery. Once the transaction has been fully redone, the transaction lock is released by the locking component 170, and all access can proceed normally. This significantly reduces the number of locks that need to be maintained and allows database availability without having to traverse the transaction log to reacquire all appropriate locks. Some database objects are not directly associated with data elements such as rows (e.g., object metadata), so locks still need to be recorded and reacquired. However, since they are extremely rare, the auxiliary log can be used to store and reacquire such locks during recovery without worrying about the number of locks.

[0032] Turn your attention to Figure 2, illustrates in more detail the undo component 130 according to one embodiment. The undo component 130 includes a physical component 210, a logical component 220, and a system component 230. The undo component 130 is configured to undo the operation of a transaction that has not been submitted. However, the functionality of the undo component 130 may vary based on the type of transaction.

[0033] The physical component 210 operates relative to physical operations including user transactions. In this case, the rollback operation will be postponed and will not occur synchronously as part of the undo process. Instead, user data modifications in the database are versioned (e.g., using row level versioning) and associated with the corresponding transaction that generated the version. If a transaction is rolled back because it is not committed, the transaction can be marked as "aborted" in the persistent storage device. These aborted versions can be slowly cleared by a background thread that sweeps the database to remove them. If a new user transaction attempts to update a row with an aborted version, the page can be repaired to show the last committed version of the row.

[0034] The logic component 220 operates with respect to logical operations associated with user transactions. Logical operations may be bound to user transactions (such as various metadata operations and management of corresponding caches and counters, etc.). These operations may need to be rolled back if the corresponding user transaction was not committed before the crash. However, version control is not applicable because the operations are logical and there are no physical objects to version control. These operations can be recorded in the auxiliary log in conjunction with traditional undo, where the recorded operations generated by the transaction are rolled back in reverse chronological order from the end of the auxiliary log to the oldest active transaction.

[0035] System component 230 operates with respect to operations associated with system transactions. Such operations may involve operations on system pages such as index pages, allocation pages, and bitmaps, etc. These operations typically manage system data and do not necessarily need to be tied to user transactions. Furthermore, these pages are highly compressed and therefore version control is not an appropriate option. In these cases, all updates to such pages may be moved to internal short-lived transactions, which will perform traditional undo, but given their short length, should not significantly impact recovery and the constant time associated therewith.

[0036] Figure 3300 is a timeline diagram of the recovery process associated with the physical and logical operations of a user transaction to help clarify and understand. A transaction log timeline 310 is shown, which includes multiple physical operation records (P1-P6) and logical operation records (L1-L4). The auxiliary log timeline 320 includes only logical operations (L1-L4). Physical operations may include the insertion, deletion, or modification of data elements (such as a row of a table). Logical operations may include metadata operations and the management of corresponding caches and counters, etc. Three discrete time points are represented on both timelines, namely the beginning of the oldest active transaction 330, the checkpoint 340, and the end of the log 350. Database recovery can be initiated after a crash, for example, occurring at the end of the log 350. First, at 360, recovery can be initiated using an analysis process that analyzes the transaction log in time from the checkpoint 340 to the end of the log 350 to determine the transaction and determine whether the transaction is committed. In addition, the auxiliary log can be loaded from the checkpoint. Next, at 370, redo of the logical operations may be applied from the oldest transaction to the checkpoint (here, L1 and L2). Then, at 380, redo may be performed from the transaction log in time from the checkpoint 340 to the end of the log 350. In addition, redo may include rebuilding the auxiliary log by filling it with any logical operation records after the last checkpoint, thereby restoring the auxiliary log to its state at the time of the crash. Finally, at 390, uncommitted logical operations are undone in reverse chronological order from the end of the log 350 to the oldest active transaction 330. Version control and logical restore are used to handle uncommitted physical transactions, thereby avoiding rollback as part of physical transaction undo in the recovery sequence.

[0037] The above-mentioned systems, architectures, environments, etc. have been described with respect to the interaction between several components. It should be understood that such systems and components may include those components or subcomponents specified therein, some of the specified components or subcomponents, and / or additional components. Subcomponents may also be implemented as components that are communicatively coupled to other components rather than being included in a parent component. In addition, one or more components and / or subcomponents may be combined into a single component to provide aggregate functionality. Communication between systems, components, and / or subcomponents may be implemented according to a push and / or pull model. For the sake of brevity, components may also interact with one or more other components that are not specifically described herein but are known to those skilled in the art.

[0038] In view of the above exemplary system, reference can be made to Figure 4-9The flowchart of the present invention can be used to better understand the methods that can be implemented according to the disclosed subject matter. Although the method is shown and described as a series of frames for the purpose of simplifying the description, it should be understood and appreciated that the disclosed subject matter is not limited by the order of the frames, because some frames can appear in different orders and / or occur simultaneously with other frames depicted and described in this article. In addition, all the illustrated frames may not be required to implement the methods described below. In addition, each frame or combination of frames can be implemented by computer program instructions that can be provided to a processor to generate a machine, so that the instructions executed on the processor create components for implementing the functions specified by the flowchart frames.

[0039] Figure 4 A method 400 for database recovery is illustrated. At reference numeral 410, log records are analyzed by traversing the transaction log from the checkpoint to the end of the log. In particular, the analysis may reveal active transactions and corresponding operations being executed before the crash. In one embodiment, the active transactions may be stored in a transaction table. At reference numeral 420, the state of the identified active transactions is also determined from the transaction log. For example, the state may correspond to whether the active transaction was committed (e.g., written to disk) before the crash. In one embodiment, the state information may be used to populate a dirty page table, which includes identification of pages that were updated in the buffer but not written to disk according to a particular log operation. At reference numeral 430, operations for all transactions, even those that were not committed, are redone or replayed to return the database to the state at the time of the crash. At reference numeral 440, uncommitted transactions are marked as aborted, and further actions are postponed. In other words, the conventional undo process is performed asynchronously, in which the transaction log is scanned backward from the end, and all operations for each uncommitted transaction are undone. Instead, version control and logical restoration may be performed asynchronously to effectively undo the operations of an aborted transaction, but in a different manner at a later time.

[0040] Figure 5is a flow chart of the cleaner method 500. At least for physical user transactions, the impact of the operation of the uncommitted transaction does not have to be undone immediately. Instead, the background cleaner method 500 can resolve the impact asynchronously. At reference numeral 510, the identification of one or more locations affected by the suspended transaction can be identified. A data element or object (such as a row of a table) can include data and a transaction identifier associated with the data. Thus, for example, a location can be identified by scanning data with a transaction identifier marked as suspended. At reference numeral 520, the current version of the data is restored to a previously submitted version. Instead of performing an update in place to replace existing data, the update is not effectively performed in place. In other words, the update generates a new version of the data element, which can be linked to the old version. Although not limited to this, in one embodiment, a logical restore can be performed by performing a compensating operation that can include an insertion, deletion, or modification.

[0041] Figure 6 A method 600 for processing updates in view of a potentially aborted transaction is illustrated. At reference numeral 610, a request to update a data element (such as a row of a table) may be received. At reference numeral 620, a determination may be made as to whether the data element is associated with an aborted transaction. For example, a check may be made as to whether a transaction identifier associated with the data has been marked as aborted. If the data element is associated with an aborted transaction ("yes"), the method continues at reference numeral 630, where the data element is restored to a previously submitted version. For example, a logical restore may be performed, where a compensating operation is applied to produce a previously submitted version. Subsequently, at 640, an update request is executed. If it is determined at 620 that the update does not involve a data element associated with an aborted transaction ("no"), the method proceeds directly to reference numeral 640, where the update request is executed.

[0042] Figure 7 is a flow chart of a method 700 for constructing an auxiliary log. At reference numeral 710, a transaction including one or more operations is received, retrieved, or otherwise obtained or acquired from a transaction log. At reference numeral 720, a determination is made as to whether the transaction log includes one or more logical operations. Logical operations are bound to user transactions and may include various metadata operations and management of corresponding caches and counters, among other things. If it is determined at 720 that there are no logical operations ("no"), the method may terminate. Alternatively, if it is determined at 720 that there are one or more logical operations ("yes"), the method proceeds to reference numeral 730, where one or more logical operations are added to the auxiliary log. For example, during recovery, starting from a checkpoint, transactions may be analyzed and logical operations may be added to the auxiliary log to support subsequent undo.

[0043] Figure 8A method 800 for database recovery is depicted. At reference numeral 810, transactions in an auxiliary log are analyzed. The auxiliary log differs from a transaction log in that it includes only logical operations and, optionally, a limited set of physical operations that do not support versioning. The result of the analysis may be an identification of all transactions, including transactions that were aborted at the time of the crash. At reference numeral 820, transactions are redone or reapplied in time from the oldest active transaction to the end of the log. As a result, for the transactions in the auxiliary log, the database will be in the state it was in at the time of the crash. At reference numeral 830, transactions that were aborted or not committed are undone. For example, the auxiliary log may be traversed in reverse chronological order from the end to the oldest active transaction, and the effects of the aborted transaction may be undone or rolled back by performing appropriate compensating actions.

[0044] Fig. 9 is a flow chart illustrating a method for employing transaction locks during database recovery. At reference numeral 910, a transaction in the recovery process is identified. For example, if a transaction is not committed, the transaction may be marked as aborted, and action may need to be taken to undo the effects of the transaction. At reference numeral 920, an exclusive transaction lock is set on a transaction identifier associated with the transaction being recovered. As a result, any user query attempting to access the data will be blocked by the lock. According to one embodiment, a data element such as a row of a table may be associated with a transaction identifier. By applying a lock to the identifier, access to all data elements having the transaction identifier may be blocked without having to set a lock on each individual data element. At reference numeral 930, a determination may be made that recovery of the transaction is complete. According to one embodiment, recovery may be considered complete when rollback or undo of an aborted transaction in an auxiliary log is complete. At reference numeral 940, a lock is removed or released from the transaction identifier. After the lock is released, a logical restore to the corresponding version may occur asynchronously. In addition, user queries may be able to access and interact with the data. As an alternative to the above, the lock may be maintained until the transaction is identified as being committed or aborted. In some cases, the analysis may immediately conclude that the transaction was aborted because access to an external transaction manager might be required, in which case locking is useful.

[0045] Aspects of the present disclosure relate to technical problems of processing time and storage requirements associated with database recovery. Technical features associated with solving these problems include: redoing user transactions from the beginning of the last successful checkpoint, versioning user operations and marking versions with identifiers of corresponding transactions, and undoing user operations based on versions. In addition, auxiliary logs are generated for logical systems and other transactions that cannot be versioned. Additionally, as checkpoints occur, the database transaction log can be continuously truncated, thereby reducing the storage space required between checkpoints to a small and substantially constant amount. The auxiliary log can also be truncated to remove transactions before the oldest active transaction.

[0046] The present disclosure supports various products and processes that perform or are configured to perform various actions with respect to database recovery. The following are one or more exemplary systems and methods.

[0047] A database recovery system includes: a processor coupled to a memory, the processor configured to execute computer executable instructions stored in the memory, the computer executable instructions causing the processor to perform the following actions when executed: determining the status of one or more transactions identified in a transaction log associated with a database, wherein the database supports versioning of user data; sequentially redoing the one or more transactions starting from the beginning of the last successful checkpoint to the end of the transaction log as specified by the transaction log; and marking one or more uncommitted transactions of the one or more transactions as aborted. The system also includes: identifying data elements associated with the transaction identifiers marked as aborted; and restoring the data elements to a previously committed version. The system also includes obtaining an auxiliary log, the auxiliary log storing non-versioned logical operations. In addition, the system includes: redoing the logical operations captured by the auxiliary log starting in time from the oldest active transaction to the end of the auxiliary log; and undoing the uncommitted logical operations in reverse chronological order from the end of the auxiliary log to the oldest active transaction. The system also includes applying a transaction lock on the transaction identifier and releasing the transaction lock after the undoing of the uncommitted logical operations is completed. The system also includes: truncating the auxiliary log based on the longest active transaction, and truncating the transaction log by removing transactions before the most recent successful checkpoint. The system also includes: redoing transactions sequentially as specified by the transaction log, starting from the earliest of the oldest dirty page or the beginning of the last successful checkpoint.

[0048] A method for database recovery includes: using at least one processor, the processor is configured to execute computer executable instructions stored in a memory, the computer executable instructions when executed cause the at least one processor to perform the following actions: identifying active transactions and uncommitted transactions specified in a transaction log of a database, wherein the database stores versions of user data; redoing one or more active transactions in sequence as specified by the transaction log starting from the beginning of the last successful checkpoint to the end of the transaction log; and marking one or more uncommitted transactions of the one or more transactions as aborted. The method also includes: identifying data elements associated with the transaction identifiers marked as aborted; and restoring the data elements to previously saved versions. The method also includes: identifying the data elements in response to receiving a request to update the data elements. The method also includes: applying a transaction lock on the transaction identifier when the data elements are restored to the previously committed version. The method also includes: generating an auxiliary log, the auxiliary log storing logical transactions that perform non-versioning operations. In addition, the method includes: redoing transactions captured by the auxiliary log starting from the oldest active logical transaction; and undoing the uncommitted transactions backward from the end of the auxiliary log to the oldest active logical transaction. The method also includes truncating the transaction log based on the most recent checkpoint.

[0049] A system for database recovery includes: components for identifying active and uncommitted transactions from a transaction log after a database crash, wherein the database supports versioning of user data; components for redoing one or more active transactions from the last successful checkpoint forward to the end of the transaction log; and components for marking one or more uncommitted transactions as aborted and deferring undo. The system also includes components for identifying a data element associated with a transaction identifier marked as aborted, and includes components for restoring the data element to a previously saved version of the data element. The system also includes components for obtaining an auxiliary log that stores logical operations for performing non-versioning operations. Additionally, the system includes components for redoing transactions captured by the auxiliary log forward from the oldest active transaction to the end of the log, and includes components for undoing uncommitted database transactions backward from the end of the auxiliary log to the oldest active transaction.

[0050] As used herein, the term "dirty page" refers to a page of data that has been modified in memory but has not yet been written to a non-volatile storage device (e.g., written on a disk). The page is called a dirty page because it is different from the corresponding page in the non-volatile storage device. For example, when a page is read from a disk into memory, the page is clean. Subsequently, the page can be updated in memory by a user query and is called a dirty page.

[0051] As used herein, the terms "component" and "system" and their various forms (e.g., component, system, subsystem, ...) are intended to refer to a computer-related entity, either hardware, a combination of hardware and software, software, or software execution. For example, a component can be, but is not limited to, a process running on a processor, a processor, an object, an instance, an executable file, an execution thread, a program, and / or a computer. As an illustration, both an application running on a computer and a computer can be a component. One or more components can reside within a process and / or execution thread, and a component can be localized on one computer and / or distributed between two or more computers.

[0052] As used in this specification and the appended claims, the conjunction "or" is intended to mean an inclusive "or" rather than an exclusive "or," unless otherwise specified or clear from the context. In other words, "X" or "Y" is intended to mean any inclusive permutation of "X" and "Y." For example, if "'A' employs 'X'," "'A' employs 'Y'," and "'A' employs both 'X' and 'Y'," then in any of the foregoing instances, "'A' employs 'X' or 'Y'" satisfies.

[0053] Furthermore, where the terms “include,” “contain,” “has,” “having,” or variations thereof, are used in either the detailed description or the claims, these terms are intended to be inclusive in a manner similar to that the term “comprising” is interpreted when used as a transitional word in a claim.

[0054] To provide context for the disclosed subject matter, Fig.10 The following discussion is intended to provide a brief general description of a suitable environment in which various aspects of the disclosed subject matter may be implemented. However, the suitable environment is merely an example and is not intended to imply any limitation on the scope of use or functionality.

[0055] Although the systems and methods disclosed above can be described in the general context of computer executable instructions of programs running on one or more computers, those skilled in the art will recognize that these aspects can also be implemented in conjunction with other program modules, etc. Typically, program modules include routines, programs, components, data structures, etc. that perform specific tasks and / or implement specific abstract data types. In addition, those skilled in the art will understand that various computer system configurations can be used to practice the above systems and methods, including single processors, multi-processor or multi-core processor computer systems, micro-computing devices, mainframe computers, and personal computers, handheld computing devices (e.g., personal digital assistants (PDAs), smart phones, tablets, watches...), microprocessor-based or programmable consumer or industrial electronic devices, etc. Various aspects can also be practiced in a distributed computing environment, in which tasks are performed by remote processing devices linked through a communication network. However, some (if not all) aspects of the disclosed subject matter can be practiced on independent computers. In a distributed computing environment, program modules can be located in one or both of local and remote memory devices.

[0056] refer to Fig.10 , an example general purpose computer or computing device 1002 (e.g., a desktop computer, a laptop computer, a tablet computer, a watch, a server, a handheld device, a programmable consumer or industrial electronic device, a set-top box, a gaming system, a computing node, etc.) is shown. The computer 1002 includes one or more processors 1020, a memory 1030, a system bus 1040, one or more mass storage devices 1050, and one or more interface components 1070. The system bus 1040 at least communicatively couples at least the above-mentioned system components. However, it should be understood that in its simplest form, the computer 1002 may include one or more processors 1020 coupled to the memory 1030, which execute various computer executable actions, instructions, and / or components stored in the memory 1030.

[0057] One or more processors 1020 can be implemented with a general purpose processor, a digital signal processor (DSP), an application specific integrated circuit (ASIC), a field programmable gate array (FPGA) or other programmable logic device, discrete gate or transistor logic, discrete hardware components, or any combination thereof designed to perform the functions described herein. A general purpose processor can be a microprocessor, but in an alternative, the processor can be any processor, controller, microcontroller, or state machine. One or more processors 1020 can also be implemented as a combination of computing devices, such as a combination of a DSP and a microprocessor, a plurality of microprocessors, a multi-core processor, one or more microprocessors in combination with a DSP core, or any other such configuration. In one embodiment, one or more processors can be a graphics processor.

[0058] The computer 1002 may include or otherwise interact with various computer-readable media to support control of the computer 1002 to implement one or more aspects of the disclosed subject matter. Computer-readable media can be any available media that can be accessed by the computer 1002, and includes both volatile and nonvolatile media and removable and non-removable media. Computer-readable media can include two distinct and mutually exclusive types, namely computer storage media and communication media.

[0059] Computer storage media includes volatile and nonvolatile, removable and non-removable media implemented in any method or technology for storage of information such as computer readable instructions, data structures, program modules or other data. Computer storage media includes storage devices such as memory devices (e.g., random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM) ...), magnetic storage devices (e.g., hard disks, floppy disks, magnetic cassettes, tapes ...), optical disks (e.g., compact disks (CDs), digital versatile disks (DVDs) ...) and solid-state devices (e.g., solid-state drives (SSDs), flash drives (e.g., cards, sticks, key drives ...) ...), or any other similar media that stores the desired information accessible to the computer 1002, as opposed to transmission or communication. Therefore, computer storage media excludes modulated data signals and content described relative to communication media.

[0060] Communication media implements computer readable instructions, data structures, program modules, or other data in a modulated data signal such as a carrier wave or other transport mechanism, and includes any information delivery media. The term "modulated data signal" means a signal that has one or more of its characteristics set or changed in a manner capable of encoding information in the signal. By way of example, and not limitation, communication media include wired media such as a wired network or direct-wired connection, and wireless media such as acoustic, RF, infrared and other wireless media.

[0061] Memory 1030 and one or more mass storage devices 1050 are examples of computer-readable storage media. Depending on the exact configuration and type of computing device, memory 1030 may be volatile (e.g., RAM), non-volatile (e.g., ROM, flash memory, etc.), or some combination of the two. As an example, a basic input / output system (BIOS) (including basic routines to transfer information between elements within the computer 1002, such as during startup) may be stored in non-volatile memory, while volatile memory may be used as external cache memory to support processing by one or more processors 1020, etc.

[0062] The one or more mass storage devices 1050 include removable / non-removable, volatile / non-volatile computer storage media for storing large amounts of data relative to the memory 1030. For example, the one or more mass storage devices 1050 include, but are not limited to, one or more devices such as a magnetic or optical disk drive, a floppy disk drive, a flash memory, a solid state drive, or a memory stick.

[0063] The memory 1030 and the one or more mass storage devices 1050 may include or store an operating system 1060, one or more applications 1062, one or more program modules 1064, and data 1066. The operating system 1060 is used to control and allocate resources of the computer 1002. The application 1062 includes one or both of system and application software, and can utilize the management of resources by the operating system 1060 to perform one or more actions through the program module 1064 and the data 1066 stored in the memory 1030 and / or the one or more mass storage devices 1050. Therefore, the application 1062 can convert the general-purpose computer 1002 into a special-purpose machine according to the logic provided thereby.

[0064] All or part of the disclosed subject matter can be implemented using standard programming and / or engineering techniques to produce software, firmware, hardware, or any combination thereof to control a computer to implement the disclosed functionality. As an example and not limitation, the database recovery system 100 or a portion thereof can be or form part of an application 1062 and include one or more modules 1064 and data 1066 stored in memory and / or one or more mass storage devices 1050, the functions of which can be implemented when executed by one or more processors 1020.

[0065] According to a specific embodiment, one or more processors 1020 may correspond to a system on chip (SOC) or similar architecture, including or in other words integrating hardware and software on a single integrated circuit substrate. Here, one or more processors 1020 may include one or more processors and a memory at least similar to one or more processors 1020 and memory 1030, etc. Conventional processors include a minimum amount of hardware and software and rely extensively on external hardware and software. In contrast, the SOC implementation of the processor is more powerful because hardware and software are embedded therein, which enables specific functions to be implemented with minimal or no reliance on external hardware and software. For example, the database recovery system 100 and / or associated functions can be embedded in the hardware in the SOC architecture.

[0066] The computer 1002 also includes one or more interface components 1070 that are communicatively coupled to the system bus 1040 and support interaction with the computer 1002. As an example, the interface component 1070 can be a port (e.g., serial, parallel, PCMCIA, USB, FireWire, ...) or an interface card (e.g., sound, video, ...), etc. In one example implementation, the interface component 1070 can be implemented as a user input / output interface to enable a user to input commands and information into the computer 1002, such as through one or more gestures or voice input, through one or more input devices (e.g., a pointing device such as a mouse, trackball, stylus, touchpad, keyboard, microphone, joystick, game pad, satellite dish, scanner, camera, other computer, ...). In another example implementation, the interface component 1070 can be implemented as an output peripheral interface to provide output to a display (e.g., LCD, LED, plasma, organic light emitting diode display (OLED) ...), a speaker, a printer, and / or other computers, etc. Additionally, interface component 1070 may be implemented as a network interface to enable communications with other computing devices (not shown), such as through wired or wireless communication links.

[0067] The above description includes examples of various aspects of the claimed subject matter. Of course, for the purpose of describing the claimed subject matter, it is not possible to describe every conceivable combination of components or methods, but one of ordinary skill in the art will recognize that many additional combinations and permutations of the disclosed subject matter are possible. Therefore, the disclosed subject matter is intended to encompass all such changes, modifications, and variations that fall within the spirit and scope of the appended claims.

Claims

1. A database recovery system, comprising: A processor coupled to the memory, the processor being configured to execute computer executable instructions stored in the memory, the computer executable instructions when executed causing the processor to perform the following actions: determining a status of one or more transactions identified in a transaction log associated with a database, wherein the database supports version control of user data; redoing the one or more transactions sequentially as specified by the transaction log, starting from the beginning of the last successful checkpoint to the end of the transaction log; marking one or more uncommitted transactions of the one or more transactions as aborted; identifying a data element associated with a transaction identifier of an uncommitted transaction of the one or more uncommitted transactions that is marked as aborted; as well as In an asynchronous background process or when the data element is updated, the data element is restored to a previously committed version.

2. The system of claim 1, wherein the actions further comprise: A logical restore is performed by applying a compensating operation to the data elements to produce the previously committed version.

3. The system of claim 1, wherein the actions further comprise: Obtaining an auxiliary log, where the auxiliary log stores non-version-controlled logical operations; as well as The obtained auxiliary log is used in a database recovery step.

4. The system according to claim 3, wherein using the obtained auxiliary log in the database recovery step comprises: redoing the logical operations captured by the auxiliary log starting in time from the oldest active transaction to the end of the auxiliary log; as well as Uncommitted logical operations are undone in reverse chronological order from the end of the auxiliary log to the oldest active transaction.

5. The system of claim 4, wherein the actions further comprise: A transaction lock is applied on the transaction identifier during recovery and released after completion of the undoing of the uncommitted logical operation.

6. The system of claim 3, wherein the actions further comprise truncating the auxiliary log based on a longest active transaction.

7. The system of claim 1, wherein the actions further comprise truncating the transaction log based on a most recent successful checkpoint.

8. The system of claim 1, wherein the actions further comprise: The transactions are redone sequentially as specified by the transaction log, starting with the oldest dirty page or the beginning of the last successful checkpoint, whichever is earlier.

9. A method for restoring a database, comprising: At least one processor is employed, the at least one processor being configured to execute computer executable instructions stored in a memory, the computer executable instructions when executed causing the at least one processor to perform the following actions: determining a transaction state specified in a transaction log of a database, wherein the database stores versions of user data; redoing the one or more transactions sequentially as specified by the transaction log, starting from the beginning of the last successful checkpoint to the end of the transaction log; marking one or more uncommitted transactions of the one or more transactions as aborted; identifying a data element associated with a transaction identifier of an uncommitted transaction of the one or more uncommitted transactions that is marked as aborted; as well as In an asynchronous background process or when the data element is updated, the data element is restored to a previously committed version.

10. The method of claim 9, wherein the actions further comprise: In response to receiving a request to update the data element, the data element is identified.

11. The method of claim 9, wherein the actions further comprise generating an auxiliary log, the auxiliary log storing non-versioned logical operations; and The generated auxiliary log is used in a database recovery step.

12. The method according to claim 11, wherein using the generated auxiliary log in the database recovery step further comprises: redoing one or more transactions captured by the auxiliary log, starting with the oldest active transaction; as well as One or more uncommitted transactions are undone backwards from the end of the auxiliary log to the oldest active transaction.

13. The method of claim 9, wherein the actions further comprise truncating the transaction log based on a most recent checkpoint.

14. The method of claim 9, wherein the actions further comprise: identifying one or more system transactions captured in the transaction log; redoing one or more system transactions starting in time from the oldest active transaction to said end of said transaction log; as well as One or more uncommitted system transactions are undone in reverse chronological order from the end of the transaction log to the oldest active transaction.

15. A database recovery system, comprising: A processor coupled to the memory, the processor being configured to execute computer executable instructions stored in the memory, the computer executable instructions when executed causing the processor to perform the following actions: determining a status of transactions from a transaction log after a crash of a database, wherein the database supports versioning of user data; Redo one or more transactions starting from the last successful checkpoint and moving forward to the end of the transaction log; Mark one or more uncommitted transactions as aborted and postpone rollback; Obtaining an auxiliary log, where the auxiliary log stores non-version-controlled logical operations; as well as The obtained auxiliary log is used in a database recovery step.

16. The system of claim 15, wherein the actions further comprise: identifying a data element associated with a transaction identifier that is marked as aborted; as well as At least one of the data elements is restored to a previously saved version.

17. The system according to claim 16, wherein using the obtained auxiliary log in the database recovery step further comprises: redoing the logical operations captured by the auxiliary log, starting from the oldest active transaction and moving forward to the end of the auxiliary log; as well as Undo uncommitted logical operations from the end of the auxiliary log backward to the oldest active transaction.

18. The system of claim 16, wherein the actions further comprise: In response to receiving a request to update the data element, the data element is identified.

19. The system of claim 16, wherein the actions further comprise: A logical restore is performed by applying compensating operations to the data elements to produce a previously committed version.

20. The system of claim 15, wherein the actions further comprise truncating the transaction log based on a most recent checkpoint.

Images