0pm_om_opa2

[Former Member]

Hello Everybody,

This is regarding the upload (delta) Data source 0PM_OM_OPA_2. ( Plant maintenace module, maintenace order costs and allocation) In the Production environment we were trying to extract data (for INIT) and we were continuously getting dump in R3(-458-long transaction time in table COVP). (selection parameters were 001.2004 to 016.9999 for the FISCPER and '20'for CURTYPE.).

As the above failed we have done INIT controlling area (KOKRS) wise and was able to complete the same in reasonable time.

When we started delta upload , first delta was successful and has taken appx 4.5 hours. Next day during second delta it has again given long transaction dump (-458 for table COVP) in R3 after 6 hours.

It is clear that Delta is taking too long a time, which may cause a dump again.

Is there any reason why this 0pm_om_opa2 delta extraction is taking such long time and giving dump? Can any body suggest a solution.

Thanks in advance

Rajesh

[Former Member]

You may want to check table COEP indexes. You need an index (I think it's 3 or 4) that contains the field TIMESTMP. Check if the index is active and exists on the database.

Best regards

Dirk

[Former Member]

Thanks Mr. Dirk,

<b>It is Index 4. We have alreday created this index and after that only the delta INIT was successful</b>. However further Delta is causing a long transaction dump in <b>R3(COVP)</b> as said earlier.

Here is the steps

1.We have successfully completed all delta initialization.

2.After that the first delta update it took around 5 hours and completed succesfully.

3.There after we are unable to perform delta. It is causing Long transaction dump in R3(COVP).

Is it due to large amount of data.? Is there any other methods to do this

Thanks for your help

Regards

Rajesh KK

[Former Member]

It depends on the amount of data in your system. But when the delta init was successful and you don't wait a month until you start the delta the runtime should be no problem (or do you have half a million records per day?)

I would suggest doing an SQL trace with transaction ST01 on table COVP, COEP to see if the index 4 is found. When the extraction doesn't use index 4 you might want to create an OSS message and let the performance specialists at SAP check it.

Best regards

Dirk

[Former Member]

I've had another idea. Sometimes performance problems are caused in the BW. You may want to load the delta into the PSA only and mark the box 'Update Subsequently Into Data Targets'.

This helps especially if you load lots of new records where SID creation takes a lot of time.

Best regards

Dirk