Volatile Database Caching for Crash Recovery
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Combined transactional and analytical database management systems face significant overhead due to the need for maintaining persistent recovery logs, which slows down processing and performance, especially in systems like the IBM DB2 Analytics Accelerator (IDAA) architecture.
Innovation Solution
A method for crash recovery in linked databases that synchronizes selected portions of the source database content with the target database using a recovery log file, eliminating the need for the target database to maintain its own transaction and recovery logs, and allowing queries to be redirected or delayed during recovery, optimizing performance by leveraging the source database's logs for reconstruction.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If the target database maintains its own transaction and recovery logs to ensure ACID properties, then reliability is improved, but device complexity and processing overhead increase significantly
Solution Approach 1:
The patent extracts the logging function from the target database (accelerator) and centralizes it in the source database (mainframe). The target database no longer maintains its own recovery logs, instead relying on the source database's logs for crash recovery. This eliminates the dual logging overhead while preserving ACID properties through the source database's logging mechanism.
Solution Approach 2:
The source database's logging system serves a dual purpose: it logs transactions for the source database itself and simultaneously provides recovery information for the target database. This universal logging approach eliminates redundant logging infrastructure in the target database while maintaining recovery capabilities.
2Reliability
If data is synchronized incrementally from source to target database, then data freshness is improved, but processing speed deteriorates due to continuous logging requirements
Solution Approach 1:
The patent removes the logging overhead from the data synchronization path. By extracting the logging function to the source database only, incremental data changes can be propagated to the target database without the performance penalty of writing to separate target database logs, thus improving processing speed while maintaining consistency.
3Reliability
If the target database uses persistent storage to maintain recovery logs, then crash recovery capability is improved, but performance degradation occurs due to slow disk I/O
Solution Approach 1:
The patent extracts the persistent logging storage requirement from the target database. The target database operates with in-memory data structures without maintaining persistent recovery logs, achieving high performance. Crash recovery capability is preserved by relying on the source database's persistent logs, which are accessed only when needed for recovery, not during normal processing.
Data Source
AI summary
A computer-implemented method for a crash recovery for linked databases may be provided. The linked databases comprise a source database and a related target database, and selected portions of content of tables of the source database are synchronized with respective portions of the content of the tables of the target database. Thereby, selected queries against a database management system comprising the source database are transferred to a database management system comprising the target database for processing. And the method also comprises synchronizing the portions of the content of the selected tables in the target database with the portions of the content of the selected tables in the source database by reading entries of a recovery log file relating to the source database and applying the read entries to the target database.