DB2 LOB Completion Handler for Partially Logged Data Recovery
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
In DB2 database systems, partially logged large objects (LOBs) pose challenges due to the lack of prior images, limiting operations like undo and recovery, as only current images are logged for inserts and updates, but not for deletes, making typical completion methods inefficient or inoperable.
Innovation Solution
A LOB completion handler is introduced to identify and generate prior images of LOBs by analyzing space map records and using resources like log files and backup repositories, enabling completion processing and recovery operations.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Loss of energy
If selective logging is performed on LOBs (logging only after images for inserts and updates, not for deletes), then storage space is conserved and logging performance is improved, but the ability to perform undo operations and data recovery is lost
Solution Approach 1:
The system performs preliminary actions by creating before images of LOBs in buffer pools before delete operations, and by pre-positioning completion handlers to intercept and process these delete operations. This allows the system to have recovery capability without continuously logging all LOB changes, thus resolving the contradiction between logging overhead and data recovery capability
Solution Approach 2:
Completion handlers act as intermediaries between the database engine and LOB data. These handlers intercept LOB delete operations, retrieve before images from buffer pools or backup repositories, and complete the logging process selectively. This intermediary mechanism enables recovery capability without requiring continuous logging of all LOB changes, thus reducing logging overhead while maintaining reliability
2Ease of manufacture
If typical row completion methods are used for LOBs in auxiliary tables, then processing simplicity is maintained, but the methods become inefficient or inoperable due to the unique structure of auxiliary tables storing LOBs
Solution Approach 1:
The completion processing system is segmented into specialized components: completion identifiers that detect LOBs requiring completion, completion analyzers that determine the appropriate recovery strategy, and completion handlers that execute the recovery. This segmentation allows the system to handle the complex multi-page LOB structure in auxiliary tables efficiently, rather than using generic row completion methods
Solution Approach 2:
The system transitions from traditional single-row completion to a multi-dimensional approach that considers space map records, auxiliary table page mappings, backup repositories, and log files simultaneously. By adding these dimensions to the completion process, the system can efficiently handle LOBs stored across multiple pages in auxiliary tables, overcoming the limitations of simple row completion methods
Data Source
AI summary
In one general aspect, an apparatus can include a completion identifier configured to identify, for completion processing, a large object (LOB) deleted from an auxiliary table within a DB2 database environment based on a space map record associated with the large object where the auxiliary table functions as an auxiliary space to a base table. The apparatus can also include a completion analyzer configured to identify a resource where an image of the large object is stored at a time before the deletion of the large object from the auxiliary table.