Hybrid Database Upgrade Migration via Segmented Tool Instances

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Manually coordinating database version migrations is time-consuming and error-prone, especially with multiple versions involved, leading to potential update failures and complexity in maintaining consistency across multi-tenant databases.

Innovation Solution

A system utilizing two database migration tool instances, one for SQL schema changes and another for Java data changes, with independent metadata tables to track versions and facilitate sequential execution, ensuring consistency and providing rollback mechanisms for error handling.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Reliability

If manual coordination is used for database version migrations, then flexibility and control are maintained, but the process becomes time-consuming and error-prone

Engineering Contradiction:
Improvemigration accuracyVSAvoidmigration time
Core Design Contradiction:
ReliabilityVSLoss of time

Solution Approach 1:

The system enables self-service automation where the migration tool automatically coordinates schema and data migrations without manual intervention. The tool independently manages the migration process, tracking versions and executing changes automatically, thereby reducing both time consumption and human error while maintaining reliability

Inventive Principle:
Principle #25Self-service

Solution Approach 2:

A migration tool acts as an intermediary between different database versions and migration scripts. This intermediary automatically coordinates the execution of schema changes and data migrations, ensuring proper sequencing and error handling, thus eliminating manual coordination overhead while maintaining migration accuracy

Inventive Principle:
Principle #24Intermediary (Mediator)

2Productivity

If multiple database versions are migrated simultaneously, then productivity increases, but complexity and error-proneness increase

Engineering Contradiction:
Improvemigration speedVSAvoidmigration complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

The migration process is segmented into distinct components: schema migration scripts, data migration scripts, and version tracking metadata. Each migration version is treated as a separate, manageable unit with its own scripts and tracking entries. This segmentation allows multiple versions to be migrated systematically while keeping complexity manageable through modular organization

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system implements feedback mechanisms through metadata tables that track which migration versions have been applied. This feedback allows the migration tool to automatically determine the current state, plan subsequent migrations, and verify completion, thereby enabling efficient multi-version migrations without increasing complexity

Inventive Principle:
Principle #23Feedback

3Reliability

If schema and data changes are executed together, then consistency is maintained, but error handling and rollback become more difficult

Engineering Contradiction:
Improvedatabase consistencyVSAvoidrollback capability
Core Design Contradiction:
ReliabilityVSEase of repair

Solution Approach 1:

Schema changes and data changes are segmented into separate migration scripts and execution phases. Schema migration scripts modify the database structure, while data migration scripts transfer and transform data. This segmentation allows independent error handling and rollback for each type of change, making repair easier while maintaining consistency through coordinated execution

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The system performs preliminary actions by creating backup states and recording migration metadata before executing schema and data changes. This preliminary preparation enables straightforward rollback by restoring from recorded states, thereby easing repair operations while ensuring database consistency through controlled execution sequences

Inventive Principle:
Principle #10Preliminary action

4Productivity

If automated migration tools are implemented, then time consumption is reduced, but system complexity increases

Engineering Contradiction:
Improvemigration efficiencyVSAvoidsystem complexity
Core Design Contradiction:
ProductivityVSDevice complexity

Solution Approach 1:

A migration tool serves as an intermediary layer that manages the complexity of automated migrations. It handles script execution, version tracking, error management, and coordination between schema and data migrations. This intermediary absorbs system complexity while presenting a simple automated interface, thereby improving productivity without exposing users to underlying complexity

Inventive Principle:
Principle #24Intermediary (Mediator)

Solution Approach 2:

The migration tool implements self-service automation by automatically determining migration requirements, executing appropriate scripts in the correct sequence, tracking version changes in metadata tables, and handling errors independently. This self-service capability reduces time consumption while containing system complexity within the automated tool itself rather than requiring complex user-managed systems

Inventive Principle:
Principle #25Self-service

Data Source

PatentUS9779126B2Hybrid database upgrade migration
Publication Date: 2017.10.03 SAP SE
  • US9779126B2 patent drawing
  • US9779126B2 patent drawing
  • US9779126B2 patent drawing

AI summary

According to some embodiments, it may be determined that a plurality of hybrid database version upgrade migrations are to be performed. Each upgrade migration may include, for example, a schema change portion and a data change portion. A first database migration tool instance may be automatically run to perform the upgrade migration schema change portions. Similarly, a second database migration tool instance may be automatically run to perform the upgrade migration data change portions, wherein the second instance is not run until the first instance is complete.