DMO: downtime optimization by migrating app tables during uptime
[Update: blog has been updated on Sept 16th 2019 to reflect general availability]
Downtime-optimized DMO of SUM 2.0 can reduce the downtime of the DMO procedure. It integrates a technology to enable the migration of selected (large) application tables during uptime processing of DMO, thereby reducing the downtime migration time.
During uptime processing, the source system is still available for end users. End user activity in the system may change application tables, so if these tables have already been migrated to the target database (SAP HANA database), the changes have to be recorded and transferred to the target database as well. A dedicated technology offers the required procedure to set triggers on the respective application tables to create log entries, frequently analyze the logs, and transfer the delta to the target database.
Specific considerations compared to “standard” DMO
- A text file has to be created containing the application tables to be migrated during uptime (each table name in a separate line)
- The approach is available with SUM 2.0 (SP 06 and higher), which means:
- The allowed target release of SAP_BASIS is 750 or higher
- The source system has to be on Unicode already
- downtime-optimized DMO works for SAP Business Suite systems (not for SAP BW)
- downtime optimized DMO IS supported for the scenario System Conversion (targeting SAP S/4HANA) as well, if the source system is not yet on SAP HANA database
- [updated on February 26th 2020:] Restriction is removed with SUM 2.0 SP 07: downtime-optimized DMO IS now supported for targeting SAP S/4HANA 1909
No registration for customers any longer
With SUM 2.0 SP 06 and higher, the approach is generally available without the need of registration.
- PAS: Primary Application Server (fka CI)
- PRD: Productive
- SHD: Shadow
- TGT: Target
- CRR: change record and reply technology
The initial situation is like for the “standard” DMO:
Again, like in standard DMO, the shadow repository is created by the shadow instance:
The shadow repository is copied from the source database to the target database, the SAP HANA database.
Note that the shadow instance is still existing, although currently not used, but not deleted as in the standard DMO.
Now the trigger for the selected application tables is set up, and the initial transfer of the triggered tables starts.
The triggers are set by SUM internal technology.
Still in uptime, the delta transfer of the application tables is then executed. Therefore, a job starts the CRR replicator on the shadow instance to check for trigger logs, and transfer the delta to the Writer. For the Writer to write the data to the SAP HANA database, we need an additional instance
that uses the target version kernel for the SAP HANA database. This instance is called TMP instance (temporary).
Downtime starts, now the remaining delta of the application tables are migrated.
Now the remaining application tables (that have not been triggered) have to be migrated as in the standard DMO.
The target kernel is now applied to the PRD instance, the system is started to allow the update of the application tables. This is still business downtime.
Once the application tables are updated and the procedure is finished, the system is available again.