Enhancing Migration Efficiency Through Controlled SUM DMO Table Splitting

[Sandeep-kolakaluru]

Understanding Table Splitting in SUM DMO

In a DMO or Downtime Optimized DMO (doDMO) scenario, application table transfer occurs across specific SUM phases:

• EU_CLONE_CP2STAB_RUN – Uptime phase (DMO & doDMO)

• EU_CLONE_MIG_OPTDMO_INI_RUN – Uptime phase (doDMO only)

• EU_CLONE_MIG_DT_RUN – Downtime phase (DMO & doDMO)

The preparation and calculation of table split logic occurs in corresponding preparation phases, all of which operate during uptime. This design allows proactive configuration before the critical migration execution begins.

While standard SUM behavior is sufficient for most systems, extremely large tables may require enforced customization to ensure balanced workload distribution and better utilization of parallel R3load processes.

Real-Time Issue Faced

During S4HANA upgrade with migration, a large tables like BALDAT with table size of 150GB and other tables with large size consuming excessive time in the table splitting phase. 

As a result, SUM extended runtime and this behavior directly contributed to increased downtime (i.e. 28Hrs27mins) risk and inefficient resource utilization.

 

Strategic Intervention Applied

Instead of relying solely on default parameters, we introduced controlled overrides in SUM configuration files to optimize splitting behavior.

Table-Specific Custom Splitting

We explicitly defined split fields by creating the following configuration file:

<SUM_DIR>/abap/control/EUCLONEDEFS_ADD.LST
And added as shown in below screenshot.

Syntax used:

Inhibit splitting of a table:

<TABLENAME> nosplit

Split a table into a defined number of segments:

<TABLENAME> segmentsize=0.02

Note: The segmentsize value is calculated as 1 / <number_of_splits>.

For example, 0.02 represents 50 segments for the table.

This ensured SUM enforced controlled segmentation of the table into predefined buckets, enabling predictable workload distribution and stable split calculation behavior.

Results Achieved

Following this intervention:

• Large tables were processed in controlled parallel segments

• SUM phases stabilized significantly

• Overall downtime reduced measurably compared to earlier dry runs

• Resource utilization became more balanced and predictable

This strategic tweaking allowed us to ensure smoother system availability and meet strict business downtime SLAs.

Downtime without table splitting took 28Hrs27mins

Downtime with table splitting took 12Hrs27mins

Key Takeaways

• SUM default behavior is reliable but may not suit extreme data volumes.

• Manual parameter tuning should only be performed by experienced SAP consultants.

• Real-time log analysis is essential to identify root causes in splitting failures.

• Controlled split field definition can resolve non-ASCII and key field selectivity issues.

• Optimized parallelism improves both uptime processing and downtime efficiency.

Conclusion

This experience highlights how intelligent optimization of SAP SUM table splitting can play a crucial role in achieving successful S/4HANA upgrades. By leveraging advanced configuration parameters responsibly, we transformed a potential bottleneck into a controlled and efficient migration process.

For consultants handling large-scale systems with high-volume tables, understanding and applying these optimizations can be the difference between extended outages and seamless transitions.

Reference

This implementation approach is aligned with guidance from SAP Note 3386079 – SUM DMO scenarios: Manual Options for Table Splitting and Table Migration, which provides expert-level control options for influencing SUM table splitting and migration behavior.