Scope
Downtime optimized DMO will reduce the downtime of the DMO procedure. It integrates the SLT technology to enable the migration of selected (big) application tables during uptime processing of DMO, thereby reducing the downtime migration time.
Technology
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. The SLT technology (SAP LT REPLICATION SERVER) offers the required technology to set triggers on the respective application tables to create log entries, frequently analyze the logs, and transfer the delta to the target database. The SLT technology is part of the DMIS AddOn.
Specific considerations compared to "standard" DMO
- The DMIS AddOn (SP06) has to be selected when creating the stack.xml in Maintenance Optimizer
- 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 740 SP5 or higher
Known limitations
- The Unicode conversion for downtime-optimized DMO is not yet supported
- 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:
- Cluster or pool tables
- Tables to be converted
- Tables without primary key
- Tables which start with /BI in the name
- Basis tables and application exchange tables
(Basis tables: tables part of software components SAP_BASIS, SAP_GWFND, or SAP_UI)
Registration for customers
Interested customers have to create an incident for component BC-UPG-TLS-TLA, specify their project details, and ask for pilot registration. Development will decide if conditions are met and if the project can be supported.
Abbreviations
- SLT: SAP Landscape Transformation Server
- PAS: Primary Application Server (fka CI)
- PRD: Productive
- SHD: Shadow
- TGT: Target
Technical background
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 the integrated DMIS technology.
Still in uptime, the delta transfer of the application tables is then done. Therefore, a job starts the DMIS reader (part of SLT) on the shadow instance to check for trigger logs, and transfer the delta to the DMIS writer. For the DMIS 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.
