Database Flashback Recovery with Non-Conflicting LSN Jumps
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current database flashback mechanisms have high application limitations, particularly in the read/write mode, where historical data generated after a historical time point is discarded, limiting the ability to flashback to any time point for multiple times.
Innovation Solution
A database recovery method that utilizes an LSN corresponding to a current moment as a start point after rolling back to a historical moment, employing an LSN jump mechanism to ensure non-conflict with previous LSNs, allowing redo logs after the recovery moment to be retained, thus enabling flashback at any time point for multiple times.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If database flashback is started in read/write mode, then the database supports both reading and writing data, but backup data generated after the historical time point is discarded
Solution Approach 1:
The patent implements dynamic LSN management where the start LSN is adjusted based on recovery operations. When flashback is performed to a historical time point, the system dynamically updates the start LSN to a value greater than the current moment's LSN, allowing the system to adapt between read-only and read/write modes without discarding necessary backup data. This dynamic adjustment resolves the contradiction by enabling write support while preserving historical data through intelligent LSN tracking.
2Reliability
If database point-in-time recovery is used, then the database can be recovered to a specified time point, but a large amount of storage space is required
Solution Approach 1:
The patent changes the parameter management approach by introducing dynamic LSN adjustment mechanisms. Instead of storing complete backup data for all time points, the system uses LSN parameters to track and manage recovery points. By modifying the start LSN parameter dynamically based on flashback operations, the system achieves accurate point-in-time recovery while significantly reducing storage requirements compared to traditional methods that require maintaining all backup data.
3Productivity
If redo logs are discarded after flashback to maintain LSN continuity, then the database can be recovered, but the ability to flashback to any time point for multiple times is limited
Solution Approach 1:
The patent implements dynamic LSN management where the start LSN is adjusted based on recovery operations. When flashback is performed to a historical time point, the system dynamically updates the start LSN to a value greater than the current moment's LSN, allowing the system to adapt between read-only and read/write modes without discarding necessary backup data. This dynamic adjustment resolves the contradiction by enabling write support while preserving historical data through intelligent LSN tracking.
Solution Approach 2:
The patent performs preliminary LSN tracking and management before flashback operations occur. By maintaining records of LSN values at different time points and pre-calculating appropriate start LSN values for potential flashback operations, the system prepares in advance for multiple flashback scenarios. This preliminary action enables the database to be flashed back to any time point multiple times without discarding redo logs, as the LSN management structure is already in place to handle these operations efficiently.
Data Source
Figure 1
Figure 2
Figure 3
AI summary
This application discloses a database recovery method and apparatus, and pertains to the field of database technologies. After receiving a recovery instruction for a database, a computer device queries, based on a recovery moment indicated by the recovery instruction, an LSN and time association log for an LSN corresponding to the recovery moment, obtains recovery data of the database based on the LSN corresponding to the recovery moment, and performs data recovery on the database based on the recovery data. Then, a start LSN used by a database corresponding to the recovery moment is greater than an LSN corresponding to a current moment. After the database is rolled back from the current moment to a historical moment, an LSN greater than the LSN corresponding to the current moment is applied to the database starting from the LSN corresponding to the current moment. An LSN jump mechanism is used to ensure that an LSN used after the database is recovered does not conflict with an LSN used before the database is recovered, so that the database can be recovered to any time point for a plurality of times.