Database Restore Using Sparse Data Files and Redirection

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Current database restoration and recovery techniques are time-consuming, as they involve copying and transmitting large amounts of data from backups, leading to prolonged downtime following media failures.

Innovation Solution

The method employs sparse data files and blocks to restore and recover databases by redirecting requests to backup copies, allowing for data population while the database remains operational, thus reducing the time required for restoration.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If full restoration of data is performed from backup, then data completeness is improved, but restoration time increases

Engineering Contradiction:
Improvedata completenessVSAvoidrestoration time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent segments data restoration into two phases: (1) restoring only metadata (data dictionary, indexes, schemas) to enable immediate database operation, and (2) progressively populating actual data blocks from backup as needed. This segmentation allows the database to become operational quickly while maintaining data completeness through subsequent background population operations.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent performs preliminary restoration of metadata and structural elements before actual data blocks. By pre-restoring the data dictionary, indexes, and schemas, the database can be brought online immediately with operational metadata, while actual data is populated in the background as required by user requests.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If data is copied from backup, then data availability is improved, but network transmission time increases

Engineering Contradiction:
Improvedata availabilityVSAvoidnetwork transmission time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent extracts and restores only the essential metadata and structural information from backup before actual data blocks. This extraction of critical structural elements enables the database to operate immediately without requiring transmission of the entire data payload, significantly reducing network transmission time while maintaining data availability through subsequent on-demand data retrieval.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent performs preliminary extraction and restoration of metadata and indexes from backup before actual data blocks. This preliminary action ensures that the database structure is ready for immediate operation, while actual data is transmitted and populated only when needed by user requests, thereby reducing overall network transmission time.

Inventive Principle:
Principle #10Preliminary action

3Reliability

If data is written to database, then data integrity is improved, but restoration speed decreases

Engineering Contradiction:
Improvedata integrityVSAvoidrestoration speed
Core Design Contradiction:
ReliabilityVSSpeed

Solution Approach 1:

The patent segments the restoration process into metadata restoration (performed immediately at high speed) and data block population (performed progressively in the background). This segmentation allows the database to achieve operational integrity through metadata restoration while maintaining high restoration speed through parallel background data population operations.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent performs preliminary restoration of metadata and structural elements at high speed before actual data blocks. This preliminary action establishes data integrity for the database structure immediately, while actual data is written to the database in the background as needed, maintaining both integrity and restoration speed.

Inventive Principle:
Principle #10Preliminary action

4Loss of time

If database is brought back up quickly, then downtime is reduced, but data completeness may be compromised

Engineering Contradiction:
ImprovedowntimeVSAvoiddata completeness
Core Design Contradiction:
Loss of timeVSReliability

Solution Approach 1:

The patent segments restoration into immediate metadata restoration (enabling quick database startup) and progressive data block population (ensuring data completeness). This segmentation allows the database to be brought back up quickly with complete structural integrity while maintaining data completeness through background population operations that continue after startup.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent performs preliminary restoration of metadata and structural elements before actual data blocks, enabling the database to be brought back up quickly with operational readiness. Data completeness is then ensured through background population operations that continue after the database is operational, thus reducing downtime while maintaining data completeness.

Inventive Principle:
Principle #10Preliminary action

Data Source

PatentUS20230021672A1Database rapid restore after media failure
Publication Date: 2023.01.26 ORACLE INT CORP
  • US20230021672A1 patent drawing
  • US20230021672A1 patent drawing
  • US20230021672A1 patent drawing

AI summary

A computer program product, system, and computer implemented method for rapid database restoration using a database restore and recovery process that leverages one or more sparse data files and/or blocks by restoring one or more sparse data files and/or blocks and providing a mechanism to redirect requests to the one or more sparse data files and/or blocks to a backup copy of the actual data files and/or blocks and a process to populate the one or more sparse data files and/or blocks while the database is operational for servicing user requests. The approach includes the creation and population of one or more sparse data files and/or blocks, a redirection mechanism to service read operations where necessary, and a process to restore the data to one or more sparse data files and/or blocks over time, while the database maintains operability.