How to optimize DMO performance to reduce downtime

If you want to reduce the downtime of a database migration run with DMO, the Software Update Manager (SUM) offers some features that you must know. A short introduction of those features is provided below. Some of the features help to let SUM optimize the table split, in best case to avoid a "tail" of a few R3load processes that extend the migration runtime (which is downtime). For that, we recommend to provide the duration files. Other features (like benchmarking and repetition option) can assist you to find the optimal number of R3load processes. If further downtime reduction is required, advanced downtime-optimization features like downtime-optimized DMO may have to be considered.

Finding the Optimal Number of R3load Processes

Note that on the UI, SUM proposes default values for the R3load processes (for uptime and downtime migration) which do NOT reflect the system data (like number of CPUs). You should always adapt those number of processes. It is not uncommon to have several hundred R3load processes, it only depends on the performance of the Application Server Instance host on which SUM is running. Finding the optimal number of R3load processes is the most important tuning task.

The optimal number of R3load processes use as much host resources (like CPU, memory) as possible, but still keeps enough remaining. So you monitor your network traffic and CPU load, you raise the number of R3load processes step by step, and always wait 10 to 15 seconds until they are started. When either the CPU load or the network traffic reach 80% to 90%, you have found the optimal number of R3load processes for this system landscape. Once you have determined the optimal number of R3load processes, you will keep this number fixed during the migration run on PRD.

To reduce the migration duration of a standard DMO run, we recommend to consider the following features of Software Update Manager:

  1. Use the Benchmarking option of SUM
  2. Provide the duration file of a DMO run to the next run
  3. Use the Migration Repetition Option of SUM to immediate repeat the migration part
  4. Consider using downtime-optimized DMO (uptime migration)

As a rule of thumb, it should be possible for a standard setup to reach a migration rate of around 300 GB/hour.

1. Use the Benchmarking option of SUM

Before you start a complete DMO test run, we highly recommend using the benchmarking tool to evaluate the migration rate for your system, to find the optimal number of R3load processes and to optimize the table splitting. 

2. Provide the duration file of a DMO run to the next run

A benchmarking run as well as a full DMO run will measure and note the real migration times per table. These information are stored in the duration file. Copy the duration file from one run to the download folder of the next run. SUM will then consider the table migration time (instead of the table size) for calculation of table split which is more appropriate.

3. Use the Migration Repetition Option of SUM to immediate repeat the migration part

For a complete DMO run, the migration will only happen after all the preparation steps are done. You may reset the DMO run to repeat the migration with adapted parameters, but it will take a while until the DMO run reaches the migration part. Instead, for a test run, you can tell SUM to directly repeat the migration after it finishes. Benefit is not only that you will directly have the next migration run, but SUM will also automatically use the duration files from the previous migration run for the new split calculation.

4. Consider using downtime-optimized DMO (uptime migration)

If you follow all those hints and still need to further reduce the migration downtime part, you may consider to use downtime-optimized DMO (also known as uptime migration). It is available for a migration targeting SAP HANA database.