Readers of this blog post should be familiar with the approach "DMO with system move", as introduced in this blog https://blogs.sap.com/2017/05/22/dmo-with-system-move-the-use-case-to-change-pas-host-during-dmo/
SUM 2.0 meanwhile creates the shadow repository always on the target database. The approach was introduced in this blog https://blogs.sap.com/2019/09/09/dmo-shadow-repository-on-target-database-for-conversion-to-sap-s4ha... and is now used for all migration scenarios (with SUM 2.0 SP 08 and higher; but not with SUM 1.0). All migration scenarios means: it is not depending on the target product release, and it is not depending on the target database type. So this approach even applies for a move from SAP ECC 6.0 EHP 7 on SAP MaxDB (on-premise) to SAP ECC 6.0 EHP 8 on SAP HANA DB in a cloud infrastructure like SAP HANA Enterprise Cloud (HEC).
For "DMO with system move", the consequence is that on the source landscape, no shadow operations happen. There is no shadow repository created on the source database, and no shadow instance created on the source Application Server host (on which you have started the SUM).
The following figure illustrates this.
This approach (shadow operations only on target landscape) has a couple of implications:
The shadow operations happen on the target landscape, they take quite a while, and the transfer mode decides whether this is uptime or downtime for the source system.
The serial mode:
The parallel mode:
The following figure shows the point in time for which the source system is still in uptime, source SUM waits on downtime dialog (upper left browser window), whereas the target SUM is executing phase EU_CLONE_MIG_DT_IMP which is waiting for dump files to start the import (lower right window).
Boris Rubarth,
SAP SE, Product Management SUM
Shadow repository always created on target database
SUM 2.0 meanwhile creates the shadow repository always on the target database. The approach was introduced in this blog https://blogs.sap.com/2019/09/09/dmo-shadow-repository-on-target-database-for-conversion-to-sap-s4ha... and is now used for all migration scenarios (with SUM 2.0 SP 08 and higher; but not with SUM 1.0). All migration scenarios means: it is not depending on the target product release, and it is not depending on the target database type. So this approach even applies for a move from SAP ECC 6.0 EHP 7 on SAP MaxDB (on-premise) to SAP ECC 6.0 EHP 8 on SAP HANA DB in a cloud infrastructure like SAP HANA Enterprise Cloud (HEC).
No shadow in source landscape for DMO with system move
For "DMO with system move", the consequence is that on the source landscape, no shadow operations happen. There is no shadow repository created on the source database, and no shadow instance created on the source Application Server host (on which you have started the SUM).
The following figure illustrates this.
Shadow repository is created on target database
Changes for the approach DMO with system move
This approach (shadow operations only on target landscape) has a couple of implications:
- SPAU/SPDD happen in target landscape
- SUM will only allow the specification of the shadow instance number in target landscape (if expert mode is selected)
- The shadow operations (creating shadow instance, shadow repository, ...) happen in target landscape, and not necessarily in uptime - depending on the transfer mode selected, see below
- Advantage of the approach is that shadow operations do not affect the source database performance
Strong recommendation to use parallel mode
The shadow operations happen on the target landscape, they take quite a while, and the transfer mode decides whether this is uptime or downtime for the source system.
The serial mode:
- This is the transfer mode in which only one data transfer happens
- You run the complete procedure on the source landscape until it is finished
- This includes entering the downtime for the source system
- Only then you copy the SUM folder from source to target
- You start the SUM in the target and continue the procedure there
- Only then the shadow operations run, which takes a while - in downtime!
[added on Feb 11 2021] Especially phases like these run in downtime then:
- ACT_UPG
- SPDD
- SHD_IMPORT
- SGEN
The parallel mode:
- This transfer mode is based on a continuous data transfer to target
- You run the procedure in source until the dialog on phase HOSTCHANGE_MOVE_SOT
- On this dialog (still uptime), you decide on parallel mode,
so you start a synchronization, either manually or using the delivered script - Once the initial SUM folder is synchronized to the target, you start the SUM in the target
- Still in uptime, the target SUM will execute the shadow operations in target
- You run the source SUM until downtime dialog, but wait there until target SUM has finished shadow operations and is waiting to import dump files (phase EU_CLONE_MIG_DT_IMP)
- Only then you enter downtime in source, so that creation of export files in source landscape runs parallel to import of dump files into target database
The following figure shows the point in time for which the source system is still in uptime, source SUM waits on downtime dialog (upper left browser window), whereas the target SUM is executing phase EU_CLONE_MIG_DT_IMP which is waiting for dump files to start the import (lower right window).
Parallel SUM execution in source and target
Boris Rubarth,
SAP SE, Product Management SUM
- SAP Managed Tags:
55 Comments
