Downtime optimized DMO will reduce the downtime of the DMO procedure. It integrates a technology to enable the migration of selected (big) 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 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)
- Selection of application tables for uptime migration is currently a manual process
- No monitoring of delta transfer ratio is offered yet
- The following tables are not allowed:
– Pool tables
– Basis tables containing deep components (e.g. STRG)
– Tables to be converted
– Tables without primary key
– Tables which start with /BI in the name
– Application exchange tables
- Note that cluster and basis tables are supported starting with SUM SP13 and higher
(with the exception on basis tables with deep components, as listed above)
(Basis tables: tables part of software components SAP_BASIS, SAP_GWFND, or SAP_UI)
- downtime optimized DMO is not supported for the scenario System Conversion (targeting SAP S/4HANA)
Registration for customers
We have pilot projects running and currently do not accept further pilot projects. Stay tuned for an update on this blog.
[SAP internal information: check SAP Note 2377217 – this is not released to customers]
- 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 done. 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.