Shadow Database Tables for ERP Data Migration
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
The migration of business object (BO) data in ERP systems often results in excessive downtime due to changes in the persistency model, leading to challenges in fulfilling customer requirements and system architectural changes, and can cause conflicts if users modify data during the migration process.
Innovation Solution
The method involves generating a shadow database table corresponding to a new BO persistency model, recording changes to the old database table, transforming the changed data to match the new model, and writing it to the shadow table, allowing for minimal downtime and efficient data migration during system uptime.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Reliability
If BO data migration is performed during software upgrade downtime, then data consistency with the new persistency model is achieved, but business downtime increases excessively
Solution Approach 1:
The patent creates shadow database tables in advance with the new persistency model structure before the actual data migration occurs. This preliminary setup allows the system to prepare the target structure without interrupting business operations, and then perform data transformation during a shorter downtime period.
Solution Approach 2:
The patent introduces shadow database tables as an intermediary structure between the old and new persistency models. These shadow tables serve as a buffer that allows data to be transformed and validated without directly replacing the production tables, enabling continuous business operation during the migration process.
2Productivity
If BO data migration is performed before software upgrade downtime, then business continuity is maintained, but data conflicts occur when users modify migrated data
Solution Approach 1:
The shadow database tables act as an intermediary layer that isolates the migration process from production data. Users continue to operate on the original production tables while the shadow tables capture and transform data changes, preventing conflicts between user modifications and migration operations.
Solution Approach 2:
The patent extracts the data transformation logic into a separate change recording mechanism that operates independently from the production database. This separation allows user modifications to proceed normally while the migration process captures and processes changes through the shadow tables without interference.
3Reliability
If complete BO data migration is performed, then the new persistency model is fully implemented, but migration time and complexity increase significantly
Solution Approach 1:
The patent segments the migration process into distinct phases: creating shadow tables with the new structure, establishing change recording mechanisms, transforming data incrementally, and validating results. This segmentation breaks down the complex migration task into manageable components that can be executed and validated separately.
Solution Approach 2:
The patent implements change recording that captures all data modifications, even those that may not immediately require migration. This excessive action ensures completeness by recording every potential change, allowing the system to migrate data incrementally without missing any updates, while maintaining simplicity through a uniform recording mechanism.
Data Source
AI summary
The disclosure generally describes computer-implemented methods, computer-program products, and systems for modeling and deploying decision services. One computer-implemented method includes during uptime processing: generating at least one shadow database table corresponding to a new business object (BO) persistency model, establishing change recording for at least one database table associated with an old BO persistency model, retrieving, as changed data and using at least one computer, changed BO data from the at least one database table, transforming, as transformed data, the changed data to correspond to the new BO persistency model, writing the transformed data to the generated at least one shadow database table, and retrieving, as further changed data, BO data from the at least one database table upon a determination that the BO data has changed in the at least one database table after a prior retrieval of the BO data from the at least one database table.