Skip to Content

For optimizing the DMO downtime, we propose to use the duration files of a DMO run for the next run, so that the table split is based on the real migration times, instead of the table size – see blog “Optimizing DMO Performance“.
The duration files list only tables with migration times above a specific limit (tables with short migration times do not have to be considered for table split). We have now detected a small bug in the logic that considers the duration files the current SUM 1.0 SP 20. This may have the effect that the table split adaptation is not enhanced. The bug was already fixed in SUM 2.0 SP 00 and higher, and will be fixed in the SUM 1.0 SP 22 version.

Until then, to still optimize the table split, please consider the following approaches.

1) If you did not yet start the first DMO run:
Set the following parameter in SUM\abap\bin\SAPup_add.par so that all table migration times are considered in the duration files:

/clonepar/stattimelimit = 0

With this parameter, the SUM will create duration files after the migration which can be used to enhance the table split calculation for the subsequent DMO run.

2) If your DMO run has already finished the migration:
you can create new duration files which considers all table migration times with the following statements:

SAPup r3load writeduration durationsfile=MIGRATE_UT_DUR.XML limit=0 log/MIGRATE_UT_RUN.LOG

SAPup r3load writeduration durationsfile=MIGRATE_DT_DUR.XML limit=0 log/MIGRATE_DT_RUN.LOG

The created files (MIGRATE_*_DUR.XML) will be created in the directory in which you started the statements. These files can be used to enhance the table split calculation for the subsequent DMO run.

Boris Rubarth
Product Manager SUM, SAP SE

To report this post you need to login first.

1 Comment

You must be Logged on to comment or reply to a post.

Leave a Reply