Salesforce, inc. (20240256398). REDO AVOIDANCE DURING DATABASE RECOVERY simplified abstract
Contents
REDO AVOIDANCE DURING DATABASE RECOVERY
Organization Name
Inventor(s)
Akshay Manchale Sridhar of San Francisco CA (US)
Matthew Woicik of Bellevue CA (US)
James E. Mace of San Francisco CA (US)
REDO AVOIDANCE DURING DATABASE RECOVERY - A simplified explanation of the abstract
This abstract first appeared for US patent application 20240256398 titled 'REDO AVOIDANCE DURING DATABASE RECOVERY
The abstract describes techniques for database recovery after a system failure, where active transactions are identified and replayed to restore the database system.
- The database system accesses checkpoint information to identify active transactions before the failure.
- Database transactions occurring between a recovery point and the flush point are replayed, excluding committed or aborted transactions.
- Transactions occurring between the flush point and the recovery end point are replayed without exclusion of committed or aborted transactions.
Potential Applications: - Data recovery in case of database failures - Ensuring data integrity and consistency in database systems
Problems Solved: - Efficient recovery of database systems after failures - Minimizing the number of transactions that need to be replayed
Benefits: - Reduced downtime in case of database failures - Improved reliability and consistency of database systems
Commercial Applications: Database recovery software for businesses to ensure data integrity and minimize disruptions in operations.
Questions about Database Recovery: 1. How does this technique improve the efficiency of database recovery processes? 2. What are the key factors to consider when implementing this database recovery routine?
Frequently Updated Research: Stay updated on the latest advancements in database recovery techniques to enhance system reliability and data integrity.
Original Abstract Submitted
techniques are disclosed relating to a database recovery routine to start up a database system in response to a database failure. the database system accesses checkpoint information identifying a set of active database transactions that were active at a flush point that occurred before the database failure. as a part of the database recovery routine, the database system replays database transactions that occurred between a recovery point and the flush point. the database transactions include the set of active database transactions but exclude any committed or aborted database transactions that occurred between the recovery point and the flush point such that less than a total number of database transactions occurring between the recovery point and the flush point are replayed. the database system further replays, without excluding committed or aborted database transactions, database transactions occurring between the flush point and a recovery end point at which the database failure occurred.
