Zero Downtime Software Updates via Shadow Database Schema

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing software update techniques often require downtime, are lengthy, and need expert administration, making them unsuitable for frequent, small updates in non-expert environments.

Innovation Solution

The zero downtime software update engine enables fast, targeted updates by creating a shadow database that allows continuous operation during updates, with automated error correction and minimal preparation, suitable for frequent updates without expert intervention.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If a copy is made of the software being updated to allow continuous operation, then software availability is maintained, but update time becomes lengthy and requires expert administration

Engineering Contradiction:
Improvesoftware availabilityVSAvoidupdate time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The patent segments the database into multiple tables and updates them individually rather than copying the entire database. This allows selective updating of only the necessary tables, significantly reducing update time while maintaining software availability through continuous operation on other tables.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent creates a shadow database table as a copy of the original table for updating purposes. This copy allows updates to be applied without affecting the original table that the software application is actively using, thus maintaining availability while enabling updates.

Inventive Principle:
Principle #26Copying

2Ease of operation

If the software is stopped to implement updates, then update simplicity is achieved, but software availability is interrupted

Engineering Contradiction:
Improveupdate simplicityVSAvoidsoftware availability
Core Design Contradiction:
Ease of operationVSReliability

Solution Approach 1:

By creating and using a shadow database table as a copy, the patent enables updates to be applied to the copy while the original remains operational. This eliminates the need to stop the software for updates, maintaining both simplicity and availability.

Inventive Principle:
Principle #26Copying

Solution Approach 2:

The patent uses rename operations to switch between the original and shadow tables. After successful updates, the shadow table becomes the new original through a simple rename operation, and the old original is discarded. This provides a simple mechanism that maintains availability throughout the process.

Inventive Principle:
Principle #34Discarding and recovering

3Reliability

If expert administration is used for update processes, then update reliability is improved, but ease of operation deteriorates

Engineering Contradiction:
Improveupdate reliabilityVSAvoidease of update
Core Design Contradiction:
ReliabilityVSEase of operation

Solution Approach 1:

The patent implements automated error detection and correction mechanisms that allow the update process to self-correct without expert intervention. The system automatically detects errors during updates and applies corrections, enabling non-experts to perform updates reliably.

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

The patent changes the operational parameters of the database by creating shadow tables with the same structure but separate from the original. This parameter change (separating update operations from operational operations) allows automated error handling and simplifies the update process for non-experts.

Inventive Principle:
Principle #35Parameter changes

Data Source

PatentUS10656933B2Zero downtime for frequent software updates
Publication Date: 2020.05.19 SAP SE
  • US10656933B2 patent drawing
  • US10656933B2 patent drawing
  • US10656933B2 patent drawing

AI summary

In order to perform relatively frequent, zero-downtime software updates, a bridge schema corresponding to an original schema of a database system may be generated. Within the bridge schema, a plurality of views corresponding to a plurality of database tables of an application executing on an application server may be generated. A connection from the application to the original schema may be changed to the bridge schema, to thereby continue executing the application using the plurality of views. When a change file defining update changes to at least one original database table of the plurality of database tables is received, content of the at least one original database table may be synchronized with a target table reflecting the update changes. Then, the connection may be changed back to the original database schema to continue executing the software application, using the plurality of database tables and including the target table.