Community
Technology Blog Posts by Members
cancel
Turn on suggestions
Auto-suggest helps you quickly narrow down your search results by suggesting possible matches as you type.
Showing results for 
Search instead for 
Did you mean: 

In this blog, I will talk about the downtime optimization using 

1. DMOVE2S4

2. Downtime Optimized DMO (DoDMO)

Introduction: In today's scenario of digital transformation when all SAP customers are adopting the hyperscalers on cloud, converting there ECC system to S/4HANA. The major challenges during the transformation journey is business downtime.

When we talk about very big source database size eg. - 25-30 TB then it will be more difficult to manage the downtime. Here I will talk about the downtime optimization using downtime optimized DMO run.

Scenario Description - The source database size was ~30 TB and running on SQL Server that we need to migrate on SAP HANA database running on RISE environment. We need to finish the conversion activities along with technical downtime within conversion weekend considering less business disruption.

Taking into consideration of large database size, we finalized to perform the migration using - Classical RUN (DMOVE2S4) followed by downtime optimized DMO(DoDMO).

Solution Description: In order to achieve the downtime expectation, we planned our first conversion cycle using DMOVE2S4 method to capture the following -

  • Uptime Table Selection for DoDMO 
  • Impact Analysis for DoDMO
  • Downtime baseline with classical run

DMOVE2S4 and DoDMO : This functionality was released with SUM2.0SP17 onwards, using this you can convert/move anyDB to S/4HANA in one step. SUM does not give name of this feature in dialog/user interface.

We need to install the additional application server for source on migration VM based on ECS cloud environment. Also, SUM will provide the option to move your ASCS instance on the migration server -

VinayShrimali_0-1726260134349.png

Since the migration is happening over network so Latency should be lower than 20ms and bandwidth needs to higher then 400mbps. You can plan to use benchmarking tool for testing the latency and transfer rate. After completing the first classical run, our downtime execution phase took ~90+ hrs which didn't met the downtime expectation -

VinayShrimali_0-1726265361081.png

Now we need to plan for next cycle using downtime-optimized DMO(DoDMO) to reduce the technical downtime. So, we installed the SUM toolbox in source environment (Ref. KBA - 3092738 ) for uptime table selection and Impact Analysis for DoDMO (Ref. KBA 2547309). 

We need to consider multiple factors before finalizing table list like - Table export duration in classical run, Table Change Rate, Source Database Size, etc.). Also, need to exclude tables due to technical restriction suggested by SUM TOOLBOX and SAP KBA 2547309

VinayShrimali_0-1726265530678.png

Now we have table list ready so select the following option and supply the list to SUM -

VinayShrimali_2-1726264188365.png

VinayShrimali_3-1726264296727.png

Since this method is working on record and replay method so uptime changes by end user are considered and delta will be recorded. This recorded data will be replayed followed by downtime table migration during execution phase. The uptime migration of BASIS table will happen in EU_CLONE_CP2STAB_RUN Phase and other tables will be migrated during EU_CLONE_MIG_OPTDMOP_INI_RUN phase. 

SUM triggers two replication process types:
                 R3load: used to replicate most tables
                 ABAP work processes: used for tables requiring collision handling (tables that get an import)

You can monitor the replication status in CRR control center -

VinayShrimali_1-1726265890792.png

Based on the uptime table selection and data footprint taken, we were able to migrate our 65-70% data during uptime migration. Below are the runtime of major SUM phases for DoDMO run -

VinayShrimali_2-1726267882319.png

So finally, we were able to save 72% of downtime compared to DMOVE2S4 classical run and able to reduce technical downtime from 94.5 hrs to 26.5 hrs for large database size of ~30 TB which is promising results to manage weekend downtime window -

VinayShrimali_0-1726295764295.png

You can consider following Sources to optimize your migration further -

Hope this blog will help many customers to plan their migration journey from On Premise to ECS Private cloud network using DoDMO and DMOVE2S4 procedure.

If this blog seems to be useful to you then please don't forget to put your comments

Happy Reading!!!

Regards,

Vinay Shrimali

Comment
5 Comments
Labels in this area