LOB Log Data Segmentation in DB2 Database Systems
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current database management systems, such as DB2, face challenges in efficiently managing and logging Large Object (LOB) data types due to their large size and complex nature, which leads to issues like disabled logging for LOB columns over 1 GB and incomplete support from tools like Log Master, preventing effective UNDO processing and SQL undo operations.
Innovation Solution
A system and method that manages LOB log records by reading them from the DB2 Log, using specialized LOB log handlers to store and track LOB data with keys in a VSAM store, allowing for efficient retrieval and reassembly of LOB data for operations like data recovery and migration, thereby overcoming the limitations of conventional logging practices.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If LOB data is stored in base table log records, then logging is enabled for LOB columns, but log record size becomes excessively large and processing efficiency deteriorates
Solution Approach 1:
The patent segments LOB log data from base table log records by storing LOB log records in a separate VSAM store rather than embedding them in base log records. This segmentation allows base log records to remain compact and processable, while LOB log data is handled independently through specialized handlers that read from the VSAM store, thereby maintaining both logging capability and processing efficiency.
Solution Approach 2:
The patent extracts LOB log data from the base log record structure and stores it separately in a VSAM store. The base log records contain only control information and references to LOB data locations, while the actual LOB log data is extracted and stored independently. This extraction resolves the contradiction by enabling logging without burdening the base log processing path with large LOB data.
2Loss of information
If LOB log data is embedded in base log records, then complete log information is captured, but storage space consumption increases significantly
Solution Approach 1:
The patent extracts LOB log data from base log records and stores it separately in a VSAM store. Base log records retain only essential control information and references, while LOB data is extracted and stored independently. This maintains complete log information across both storage locations while significantly reducing the storage footprint of base log records.
Solution Approach 2:
The patent moves LOB log data from the traditional linear log file structure to a separate VSAM store with different organizational characteristics. This dimensional change allows efficient random access and reduces the linear size of base log records, thereby reducing overall storage requirements while preserving information completeness.
3Adaptability or versatility
If conventional logging methods are used for LOB data, then standard log processing applies, but UNDO operations and SQL undo functions cannot be performed
Solution Approach 1:
The patent introduces specialized LOB log handlers as intermediaries between the base log processing system and LOB data. These handlers read LOB log records from the VSAM store and provide the necessary information for UNDO operations and SQL undo functions. This intermediary layer enables advanced operations without fundamentally redesigning the entire logging architecture.
Solution Approach 2:
The patent segments the logging system into base log processing and LOB-specific processing paths. The base system handles control information, while specialized handlers manage LOB data retrieval and UNDO operations by accessing the separate VSAM store. This segmentation enables UNDO capability while maintaining manageable system complexity through clear separation of concerns.
Data Source
AI summary
A mechanism works in conjunction with a DB2® Log and an analysis tool, such as BMC's Log Master™, to handle logged data for Large Objects (LOBs) stored in tables of a DB2 database system. A plurality of controls track data logged for the LOBs. The mechanism reads log records from a DB2 Log and uses the controls to determine which of the tracked LOBs is associated with the log records and obtains data from those associated log records. The mechanism builds keys to index the data and stores the keys and the data in a Virtual Storage Access Method store having Key Sequenced Data Sets maintained separate from the log record store for the DB2 Log. When requested by the analysis tool, the data in the store can be reassembled using the keys and map records in the first store that map the logged data for the tracked LOBs.