Lesson 5 of 5
Tuning DMO with repeated runs
9 min
Listen to this lesson
DMO runtimes are not fixed properties of a system. They depend on the number of R3load processes, the table splits, the network, the hardware on both sides and the data. SAP's tuning guidance boils it down to a clear task: find the optimum number of R3load processes and feed SUM the measured table durations so it can split tables well. Both need repeated runs.
SAP's recommended procedure
- Benchmark, export only, 100 percent of tablesShows bottlenecks in the source database; the log shows the total size to migrate
- Benchmark, export and import, about 10 percent of tablesFirst impression of the migration rate
- Vary R3load processesUse the test cycle option to repeat the migration quickly and find the optimum
- Run DMO with the duration fileReuse the benchmarking duration file so SUM optimizes table splits
- Fix the optimumKeep the best number of R3loads constant for the complete procedure
The benchmarking tool estimates migration duration without building a shadow system, so it can run early and often against a copy of the source. The test cycle (migration repetition) option lets the team repeat only the downtime migration for a test run, instead of starting the whole procedure from scratch, which makes experimenting with process counts affordable. During the procedure the number of R3load processes can also be adapted on the fly from the SUM Utilities menu.
A rule of thumb, used carefully
SAP's 2022 tuning deck gives a rule of thumb: a migration rate of about 300 GB per hour should be possible in a standard setup, with roughly 8 additional hours for the update part, which together give a first estimate of technical downtime. For Contoso's 4.2 TB, that suggests about 14 hours of migration. Treat it as a planning starting point only: conversions add data conversion steps, and real systems have skewed tables, slow storage or network limits. The benchmark and the mock runs replace the rule of thumb with measurements.
| Run | R3load processes | Migration phase | What changed |
|---|---|---|---|
| Benchmark (10 percent) | Varied 40 to 120 | Rate measured | Optimum found near 96 |
| Mock 1 | 64 | 19 h | No duration file; default splits |
| Mock 2 | 96 | 13 h | Duration file from mock 1; statistics refreshed |
| Dress rehearsal | 96 | 12.5 h | Duration file from mock 2; no other changes |
Check the data, not just the clock
A fast migration that loses rows is worthless. SUM offers table count and table comparison checks, which compare row counts (and, depending on the option, content checksums) between source and target. Run them in mock runs and decide in advance which comparison the production run will use, since thorough comparisons cost time. They prove the technical transfer; the business comparisons from the process owners prove the converted data still means the same thing.
Tuning has a natural end. Once two consecutive runs with the same settings produce migration times within a small band, more experiments usually buy minutes while adding risk. At that point freeze the settings, keep the duration file from the last run for production, and spend the remaining effort on the manual steps around SUM, where Contoso's rehearsals showed most of the variance.
What would you do?
In mock 2, Contoso's migration phase is faster, but CPU on the source database host sits at 100 percent while the target SAP HANA host is mostly idle. Kenji suggests adding another 40 R3load processes. What should Sam do?
- Tuning means finding the optimum number of R3load processes and giving SUM measured table durations.
- Benchmark first: export only at 100 percent for bottlenecks, export and import at about 10 percent for the rate.
- Use the test cycle option to repeat only the migration; keep the optimum fixed for the full procedure.
- The 300 GB per hour rule of thumb is a starting point; table comparisons prove the data arrived.
Check your understanding · not graded
Lesson check
1. What does SAP say the benchmarking tool focuses on?
2. What is the purpose of the export-only benchmark with 100 percent of tables?
3. What does the test cycle option allow?
4. What do SUM's table count and table comparison checks prove?