Database Log File Segmentation for Faster Transaction Logging

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing database systems face inefficiencies in managing log file growth during transactions, particularly when handling binary large objects, and require improvements in generating snapshots for efficient database restoration and replication.

Innovation Solution

The system employs a method to manage log files by allocating a reserved portion of storage for transaction logging, using a tracking file to efficiently locate the most recent data, and optimizing snapshot generation to ensure reliable database recovery and replication.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If log files are periodically updated and truncated to manage transactions, then transaction logging capability is improved, but time spent growing log files increases and transaction completion is delayed

Engineering Contradiction:
Improvetransaction logging capabilityVSAvoidtime spent growing log files
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent divides the log file management into multiple segments or portions. When a log file becomes full, the system allocates a new log file rather than continuously growing the existing one. This segmentation allows transactions to be distributed across multiple log files, reducing the time spent growing individual log files while maintaining reliable transaction logging capability.

Inventive Principle:
Principle #1Segmentation

2Reliability

If snapshots are generated for database restoration and replication, then database recovery reliability is improved, but snapshot generation time and storage resources increase

Engineering Contradiction:
Improvedatabase recovery reliabilityVSAvoidsnapshot generation time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent implements preliminary actions by maintaining log files and tracking data changes continuously before a snapshot is needed. The system pre-processes and organizes transaction logs, so when a snapshot is required for restoration or replication, the generation process is accelerated because the underlying data structure is already prepared and optimized.

Inventive Principle:
Principle #10Preliminary action

3Quantity of substance

If binary large objects are stored in conventional databases, then data storage capability is improved, but management efficiency and performance deteriorate

Engineering Contradiction:
Improvedata storage capabilityVSAvoidmanagement efficiency
Core Design Contradiction:
Quantity of substanceVSProductivity

Solution Approach 1:

The patent extracts binary large objects from the conventional database structure and manages them separately. By removing BLOBs from the main database tables and handling them as distinct entities with specialized management mechanisms, the system maintains the storage capability for large binary data while significantly improving overall database management efficiency and performance.

Inventive Principle:
Principle #2Taking out (Extraction)

Data Source

PatentEP3953832B1Database management system
Publication Date: 2025.10.15 SINGLESTORE INC
  • EP3953832B1 patent drawingFigure 1
  • EP3953832B1 patent drawingFigure 2
  • EP3953832B1 patent drawingFigure 3

AI summary

A method for managing log files is provided, wherein a set of log files is updated, storage allocated to the log files is monitored, and further storage is allocated in dependence on a determination that available storage is below a predetermined size. A method for generating a snapshot is provided, wherein data entries are included in the snapshot in dependence on a determined relative order of log records. A method of replicating a binary large object is provided, wherein the binary large object is sent to a second database in response to identifying a log record comprising data indicating the binary large object. A method for deleting one or more binary large objects is provided, wherein data indicating the binary large object(s) that have been logically deleted is stored in a snapshot and used to delete the binary large object(s) after a previous snapshot is deleted.