Optimizing DMO Process During SAP S/4HANA Conversion
When performing a system conversion to SAP S/4HANA using the Database Migration Option (DMO) of the Software Update Manager (SUM), minimizing downtime is one of the most critical success factors. This article explains a real-world case study of how downtime was optimized during a large-scale DMO project.
Project Overview
Source Database: Oracle, 5 TB (Linux)Target Database: SAP HANA, 1.5 TB (Linux)Objective: Conversion to SAP S/4HANA using DMO (DMOVES4)Focus Area: Table split optimization and downtime reduction
SAP Downtime Optimization App
The SAP Downtime Optimization App proved extremely useful for analyzing and comparing different DMO runs.
After each DMO execution, SUM prompts for uploading the UPGANA.XML file. The app provides a detailed visualization of runtime distribution, helping identify performance bottlenecks and slow-moving tables.
First Conversion Run — Baseline Benchmark
The initial DMO run was performed as a benchmark, using the standard migrate<*>dur.xml configuration file generated by SUM.
However, the downtime exceeded 3 days, primarily due to a long tail in table migration.
SUM (via SAPup) determines this “long tail” when R3load pair utilization drops significantly — meaning a few large tables remain while others complete early, leaving many processes idle.
Observation:
Total downtime: ~3 days 2 hours (worst case)Bottleneck: Large tables without proper splitting
Second Conversion Run — Table Split Optimization
In the second DMO run, we reused the previous migrate<*>dur.xml file and performed manual table splitting for approximately 20 large tables based on SAP Note 3386079 – SUM DMO scenarios: Manual Options for Table Splitting and Table Migration.
Example of Split Configuration:
SWW_PROPERTIES segmentsize=0.02
SRMPROTOCOL segmentsize=0.01
/IWFND/L_MET_COL segmentsize=0.01
PYD_D_AL segmentsize=0.01
SWWCNTP0 segmentsize=0.01
INDX segmentsize=0.01
PPOIX segmentsize=0.02
PCL2 segmentsize=0.02
SXMSCLUP segmentsize=0.02
PCL4 segmentsize=0.02
P2RX_RT segmentsize=0.02
BALDAT segmentsize=0.02
DBTABLOG segmentsize=0.02
SWWLOGHIST segmentsize=0.02
COEP segmentsize=0.02
PPOPX segmentsize=0.02
FMIFIIT segmentsize=0.02
FMGLFLEXA segmentsize=0.02
SOFFCONT1 segmentsize=0.02
By adjusting segment sizes and applying parallel R3load tuning, we achieved a significant reduction in downtime.
Key Learnings
Use SAP Downtime Optimization App:
Continuously analyse each DMO run using UPGANA.XML to identify bottlenecks.Technical table data clean up.Update database statistics + oracle database parameter optimizations.Table Splitting is Critical:
Manually split large tables based on SAP Notes to balance R3load utilization.Reuses migrate<*>dur.xml Files:
Helps SUM optimize load distribution in subsequent runs.Monitor Long Tail Impact:
Reduce idle R3load threads by ensuring even data distribution.Iterative Optimization:
Multiple DMO test runs yield the best performance tuning results.
Outcome
Through manual table splitting and iterative fine-tuning, we achieved substantial downtime optimization — reducing total conversion downtime from nearly 3 days to under 11 hours.
This practical approach not only enhanced efficiency but also provided valuable insight into how DMO behaves with large datasets, enabling smoother go-lives for future projects.
References
SAP Note 3386079 – SUM DMO scenarios: Manual Options for Table Splitting and Table Migration936441 – Oracle settings for R3load based system copy1634908 – Reduce the number of entries from table SOFFCONT11918774 – Performance issues when running an SAP InstallationSAP Downtime Optimization App
Optimizing DMO Process During SAP S/4HANA ConversionWhen performing a system conversion to SAP S/4HANA using the Database Migration Option (DMO) of the Software Update Manager (SUM), minimizing downtime is one of the most critical success factors. This article explains a real-world case study of how downtime was optimized during a large-scale DMO project.Project OverviewSource Database: Oracle, 5 TB (Linux)Target Database: SAP HANA, 1.5 TB (Linux)Objective: Conversion to SAP S/4HANA using DMO (DMOVES4)Focus Area: Table split optimization and downtime reductionSAP Downtime Optimization AppThe SAP Downtime Optimization App proved extremely useful for analyzing and comparing different DMO runs.After each DMO execution, SUM prompts for uploading the UPGANA.XML file. The app provides a detailed visualization of runtime distribution, helping identify performance bottlenecks and slow-moving tables.First Conversion Run — Baseline BenchmarkThe initial DMO run was performed as a benchmark, using the standard migrate<*>dur.xml configuration file generated by SUM.However, the downtime exceeded 3 days, primarily due to a long tail in table migration.SUM (via SAPup) determines this “long tail” when R3load pair utilization drops significantly — meaning a few large tables remain while others complete early, leaving many processes idle. Observation:Total downtime: ~3 days 2 hours (worst case)Bottleneck: Large tables without proper splitting Second Conversion Run — Table Split OptimizationIn the second DMO run, we reused the previous migrate<*>dur.xml file and performed manual table splitting for approximately 20 large tables based on SAP Note 3386079 – SUM DMO scenarios: Manual Options for Table Splitting and Table Migration.Example of Split Configuration:SWW_PROPERTIES segmentsize=0.02 SRMPROTOCOL segmentsize=0.01 /IWFND/L_MET_COL segmentsize=0.01 PYD_D_AL segmentsize=0.01 SWWCNTP0 segmentsize=0.01 INDX segmentsize=0.01 PPOIX segmentsize=0.02 PCL2 segmentsize=0.02 SXMSCLUP segmentsize=0.02 PCL4 segmentsize=0.02 P2RX_RT segmentsize=0.02 BALDAT segmentsize=0.02 DBTABLOG segmentsize=0.02 SWWLOGHIST segmentsize=0.02 COEP segmentsize=0.02 PPOPX segmentsize=0.02 FMIFIIT segmentsize=0.02 FMGLFLEXA segmentsize=0.02 SOFFCONT1 segmentsize=0.02By adjusting segment sizes and applying parallel R3load tuning, we achieved a significant reduction in downtime. Key LearningsUse SAP Downtime Optimization App:Continuously analyse each DMO run using UPGANA.XML to identify bottlenecks.Technical table data clean up.Update database statistics + oracle database parameter optimizations.Table Splitting is Critical:Manually split large tables based on SAP Notes to balance R3load utilization.Reuses migrate<*>dur.xml Files:Helps SUM optimize load distribution in subsequent runs.Monitor Long Tail Impact:Reduce idle R3load threads by ensuring even data distribution.Iterative Optimization:Multiple DMO test runs yield the best performance tuning results.OutcomeThrough manual table splitting and iterative fine-tuning, we achieved substantial downtime optimization — reducing total conversion downtime from nearly 3 days to under 11 hours.This practical approach not only enhanced efficiency but also provided valuable insight into how DMO behaves with large datasets, enabling smoother go-lives for future projects.ReferencesSAP Note 3386079 – SUM DMO scenarios: Manual Options for Table Splitting and Table Migration936441 – Oracle settings for R3load based system copy1634908 – Reduce the number of entries from table SOFFCONT11918774 – Performance issues when running an SAP InstallationSAP Downtime Optimization App Read More Technology Blog Posts by SAP articles
#SAP
#SAPTechnologyblog
