Database Upgrade Shadow Logging for Zero Downtime Migration

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing database upgrade techniques often result in significant downtime, as they require all database objects to be unavailable during the upgrade process, leading to prolonged unavailability and increased computational costs due to time-consuming algorithms.

Innovation Solution

The system upgrade module facilitates an upgrade from an original table to a target table by recording changes in a logging table and transferring them to the target table, allowing the original system to remain operational, thereby minimizing downtime through the use of a shadow system for partial upgrades.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If traditional database upgrade techniques are used, then the database objects can be upgraded to the target system, but all database objects become unavailable during the upgrade process, resulting in significant downtime

Engineering Contradiction:
Improvesystem availabilityVSAvoiddowntime
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The upgrade process is segmented into multiple phases: (1) copying only changed records from the original table to the target table during system operation, (2) performing the upgrade during a brief downtime period, and (3) completing the migration. This segmentation allows the system to maintain availability for most operations while minimizing actual downtime.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system performs preliminary actions by continuously monitoring and copying changed records from the original table to the target table before the actual upgrade is needed. This preliminary data preparation enables the upgrade to be executed quickly with minimal downtime, as the heavy lifting of data migration is already complete.

Inventive Principle:
Principle #10Preliminary action

2Reliability

If traditional upgrade methods are used, then the database can be upgraded, but the computational cost increases due to time-consuming algorithms that process all database objects

Engineering Contradiction:
Improveupgrade completenessVSAvoidcomputational cost
Core Design Contradiction:
ReliabilityVSUse of energy by moving object

Solution Approach 1:

The system extracts only the changed records from the original table using selective criteria (such as change timestamps or version markers) rather than processing all database objects. This extraction approach significantly reduces computational cost by focusing resources only on the necessary data subset while ensuring upgrade completeness for all modified objects.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The system performs partial action by migrating only the changed records rather than all records in the database. This partial approach reduces computational overhead and energy consumption while still achieving the necessary upgrade completeness for the modified portion of the database.

Inventive Principle:
Principle #16Partial or excessive action

Data Source

PatentEP2605157B1Change data capturing during an upgrade
Publication Date: 2020.01.01 SAP SE
  • EP2605157B1 patent drawingFigure 1
  • EP2605157B1 patent drawingFigure 2
  • EP2605157B1 patent drawingFigure 3

AI summary

In one general aspect, a computer system can include instructions stored on a non-transitory computer-readable storage medium. The computer system can include a logging table generator configured to generate a logging table corresponding with an original table targeted for an upgrade, and a control table generator configured to generate a control table configured to store a version identifier for changes logged in the logging table. The computer system can include a change recorder configured to receive an indicator of a change to a record of the original table during execution of at least a portion of the upgrade of the original table, and a key recorder configured to store in the logging table a primary key identifying the record of the original table and the version identifier stored in the control table.