Database Recovery Log Archive Access Avoidance
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current database recovery methods are inefficient due to the need to access archived recovery log files, which are stored in large-volume, long-term archives, leading to slow read processes and performance penalties during database crashes.
Innovation Solution
A computer-implemented method that maintains linked databases with synchronized partitions between a source and target database, using metadata to determine whether to recover data from the recovery log file or the target database based on recovery metric values, allowing for quicker access and bulk loading of data from the target database during recovery.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Duration of action of stationary object
If recovery log files are archived in large-volume long-term archives, then data retention is improved, but read speed deteriorates
Solution Approach 1:
The patent pre-loads recovery log records from long-term archives into short-term storage (memory or fast storage) before they are needed for recovery operations. This preliminary action ensures that when a crash occurs and recovery is needed, the data is already available in fast storage, eliminating the speed penalty of reading from archives during the critical recovery process.
Solution Approach 2:
The patent introduces an intermediate storage layer (short-term storage in memory or fast storage) between the long-term archive and the recovery process. This intermediary buffer allows data to be transferred from slow archive storage to fast storage in advance, so that during recovery operations, all reads occur from the fast intermediate storage rather than directly from the slow archive.
2Reliability
If archived recovery log files are accessed during recovery, then complete data recovery is achieved, but recovery time increases
Solution Approach 1:
The system continuously pre-loads recovery log records from archives into short-term storage during normal operation, maintaining a buffer of recently archived records in fast storage. When a crash occurs, the recovery process can immediately access records from this pre-loaded buffer without needing to read from archives, significantly reducing recovery time while still ensuring complete recovery of all necessary data.
Solution Approach 2:
The patent maintains continuous operation of the pre-loading mechanism during normal database operation, so that the useful action of preparing recovery data never stops. This continuous pre-loading ensures that whenever a crash occurs, the most recently archived recovery logs are already in fast storage, maximizing recovery speed without compromising recovery completeness.
3Speed
If recovery logs are stored in fast storage, then access speed is improved, but storage capacity is reduced
Solution Approach 1:
The patent segments the recovery log storage into two distinct parts: long-term archive storage for historical records and short-term fast storage for recently archived records. This segmentation allows the system to keep only the most recently archived records in expensive fast storage (minimizing the capacity burden) while maintaining the ability to recover data from all archived records by continuously rotating what is kept in fast storage versus what remains in the archive.
Data Source
AI summary
A method for maintaining linked databases including a source database and a target database, maintaining first metadata in a recovery log file of the source database, maintaining second metadata that identifies portions of data that are replicated from the source database to the target database as part of the selected partitions of the selected tables, receiving an indication that a crash of the source database has occurred, determining a first recovery metric value for recovering the source database's, determining a second recovery metric value for recovering the source database's data from the target database based on the second metadata, and determining whether to recover the source database's data from the recovery log file of the source database or from the target database based on a comparison of the determined first recovery metric value and the second recovery metric value.