Skip to Content
avatar image
Former Member

DMO performance issues

Hi Boris

We are facing performance issues in the DMO. EU_CLONE_MIG_DT_RUN phase is running for more than 5 days now (with Downtime minimized strategy). It is a combined migration of NUC to UC, Oracle to HANA & EHP6 to EHP7. System details are given below.

Source system : ERP 6.06, NW 7.31, Non-Unicode, Oracle 12c (OLTP compressed), DB Size 4.5TB, HP rx6600, 4CPU (8 core, 1.6GHz), 64GB RAM, HPUX 11.31 & 2Gb Ethernet.

SUM Host : SUM is run in AAS, HP rx2600, 2CPU (4 core, 1.6GHz)), 32GB RAM, HPUX 11.31 & 2Gb Ethernet

Target system : ERP 6.07, NW 7.4, Unicdoe, HANA 2.0, HP BL460c G9, 2 CPU (28 core), 512GB RAM, SLES 12 SP2, 20Gb Ethernet

SUM version : 1.0 SP 21 (PL5)

R3load : 749 Patch 301

No. of R3load processes : 16 (80 to 90% CPU load in SUM host)

There is no resource bottleneck in CPU, Memory, Disk & Network in Source DB server, SUM host & Target HANA DB.

Cluster tables like RFBLG, CDCLS etc. are transferred at very slow rate.

In the export log, the PIPE time is very high compared to DB time as below (one example). DB time : 25668 sec & Pipe time : 41360 sec.

We are unable to figure out where exactly the issue is as there is no bottleneck in Hardware resource.

Can you pl help us to isolate the issue?



Add comment
10|10000 characters needed characters exceeded

  • Get RSS Feed

1 Answer

  • Jan 07, 2018 at 02:32 PM

    Looks like an issue regarding the sorting of the cluster tables.

    2383750 - DMO: How to speed up the export of cluster tables

    stop the DMO procedure and add parameter "/migrate/checkforgroupcluster = 1" in „SUM/abap/bin/SAPup_add.par“. Start the SUM again and verifiy the task file (*.TSK) D RFBLG Eg xeq and not D RFBLG Es xeq is active. Check also if all indexes on the tables are consistent and the statistics on oracle are up-to-date.

    With SUM 2.0 the cluster sorter is always switched on and no manual action is necessary.

    Add comment
    10|10000 characters needed characters exceeded