Technology Blogs by SAP
Learn how to extend and personalize SAP applications. Follow the SAP technology blog for insights into SAP BTP, ABAP, SAP Analytics Cloud, SAP HANA, and more.
Showing results for 
Search instead for 
Did you mean: 

Stringent project timelines and limited resources sometimes make it difficult to have multiple mock-runs in HANA migration projects before actual production migration execution.

As we already know, having mock-run on exact replica of production system not only helps to determine & plan production down timelines but also highlights performance bottlenecks we may encounter during actual production system migration. These identified performance bottlenecks, when identified in advance, can be resolved with some expert fine-tuning and resultant improved performance can be tested again in next mock-run. Hence with reduced production downtime, overall timelines can be improved significantly.

But for scenarios, where there is lesser time or limited resources causing hurdle in executing multiple mock-runs, SUM tool provides a really helpful solution to execute multiple iterations of only one specific downtime step (EU_CLONE_MIG_DT_RUN) in single migration mock-run.

This, not only allows you to do fine-tuning of identified performance bottlenecks, but also iteration of step during same run, with just one click of a button, would give you outcome of tuning you did to improve downtime. Let’s discuss a bit more technical down here on HOW it actually works & HOW to do it in real time:

In ‘Extraction’ phase of SUM-DMO, when PREP_INPUT/MIG2NDDB_INI step is executing at 2% progress, tool stops at known dialog screen asking for migration key. On the same screen, there available an option of ‘Test Cycle’ to Enable Migration Repetition Option (see below).

When you select above option & move ahead with migration process, everything works as usual till downtime phase.

At 67%, when tool finishes EU_CLONE_MIG_DT_RUN, it stops at dialog asking if you want to run iteration of same phase or not.

At this point, you can explore migration logs in details, work on identified performance bottlenecks and do any possible fine-tuning identified during first execution of EU_CLONE_MIG_DT_RUN.

Very common areas of improvement to look at this point are:

  1. Checking throughput of source database & tuning it to improve more.
  2. Looking at disk i/o of source/target database system & giving improvement suggestions
  3. Checking network transfer bit rate & latency between Source DB server -> DMO App server -> Target HANA DB server
  4. Optimizing number of R3load processes by looking at CPU/memory utilization in first run
  5. Resolving time consuming errors encountered during downtime execution in advance

After optimizing all possible areas to improve downtime furthermore, repetition of downtime phase can be triggered from above mentioned screen.

Once this repetition is triggered, SUM tool executes SQL scripts, automatically generated at ..\SUM\abap\var\ location with name ‘MIGRATE_DT_UNDO*.TQL

Log file shows following actions will be triggered automatically on target HANA DB schema as part of ‘UNDO’ operation:

  1. Application tables truncated
  2. Primary keys dropped
  3. Indexes dropped

This ‘UNDO’ operation is very quick, hardly takes any significant time & leaves target HANA schema in same state as it was at the time of start of phase EU_CLONE_MIG_DT_RUN. And after this, iteration of mentioned phase is restarted by SUM tool.

Once phase is completed, tool again stops at same dialog, asking to repeat it again for another iteration or continue to next phase of migration process.

In this way, SUM tool allows you to:

     Repeat downtime phase as many times you want to repeat it

     Try out all your tuning or tweaking of parameters to improve overall downtime of migration

     Efforts/time required to repeat full-fledged mock run can be pretermitted

This functionality not only saves plenty of time, consumed by full repetitions (end-to-end) of SUM-DMO process, but also provides you an opportunity to analyze downtime logs in details and do performance tuning in mock-run.