How to reduce long extraction time - Generic extractor based on view

[Former Member]

Hello. The previous thread about this error was closed without any answer.

I'm in the same configuration.

"Using a generic extractor (Delta enabled on confirmation date) based on view to load data from ECC6 to BI.

Now my issue is that the delta extraction is running for a long time (around 1 hr) even if the data volume is very small

While checking the job overview in source system i saw that the job is hanging at the below step for almost 1 hr."

1 LUWs confirmed and 1 LUWs to be deleted with function module MF RSC2_QOUT_CONFIRM_DATA.

I am not understanding why this is happening.

Here is the log of the job:

30.05.2011 03:58:11 Job started

30.05.2011 03:58:11 Step 001 started (program SBIE0001, variant &0000000166864, user ID ALEREMOTE)

30.05.2011 03:58:11 Asynchronous transmission of info IDoc 2 in task 0001 (0 parallel tasks)

30.05.2011 03:58:11 DATASOURCE = 0CO_OM_WBS_6

30.05.2011 03:58:11 *************************************************************************

30.05.2011 03:58:11 * Current Values for Selected Profile Parameters *

30.05.2011 03:58:11 *************************************************************************

30.05.2011 03:58:11 * abap/heap_area_nondia......... 4000000000 *

30.05.2011 03:58:11 * abap/heap_area_total.......... 8000000000 *

30.05.2011 03:58:11 * abap/heaplimit................ 100000000 *

30.05.2011 03:58:11 * zcsa/installed_languages...... DEFS *

30.05.2011 03:58:11 * zcsa/system_language.......... E *

30.05.2011 03:58:11 * ztta/max_memreq_MB............ 2047 *

30.05.2011 03:58:11 * ztta/roll_area................ 6500000 *

30.05.2011 03:58:11 * ztta/roll_extension........... 2000000000 *

30.05.2011 03:58:11 *************************************************************************

30.05.2011 03:58:11 1 LUWs confirmed and 1 LUWs to be deleted with function module RSC2_QOUT_CONFIRM_DATA

30.05.2011 05:02:53 Call customer enhancement BW_BTE_CALL_BW204010_E (BTE) with 171 records

30.05.2011 05:02:53 Result of customer enhancement: 171 records

30.05.2011 05:02:53 Call customer enhancement EXIT_SAPLRSAP_001 (CMOD) with 171 records

30.05.2011 05:02:53 Result of customer enhancement: 171 records

30.05.2011 05:02:53 Asynchronous send of data package 1 in task 0002 (1 parallel tasks)

30.05.2011 05:02:53 IDOC: Info IDoc 2, IDoc No. 4667050, Duration 00:00:00

30.05.2011 05:02:53 IDoc: Start = 30.05.2011 03:58:11, End = 30.05.2011 03:58:11

30.05.2011 05:02:53 tRFC: Data Package = 1, TID = AC11082D38B44DE308DD028A, Duration = 00:00:00, ARFCSTATE = RECORDED

30.05.2011 05:02:53 tRFC: Start = 30.05.2011 05:02:53, End = 30.05.2011 05:02:53

30.05.2011 05:02:53 Altogether, 0 records were filtered out through selection conditions

30.05.2011 05:02:53 Asynchronous transmission of info IDoc 3 in task 0003 (0 parallel tasks)

30.05.2011 05:02:53 IDOC: Info IDoc 3, IDoc No. 4667051, Duration 00:00:00

30.05.2011 05:02:53 IDoc: Start = 30.05.2011 05:02:53, End = 30.05.2011 05:02:53

30.05.2011 05:02:53 Synchronized transmission of info IDoc 4 (0 parallel tasks)

30.05.2011 05:02:53 IDOC: Info IDoc 4, IDoc No. 4667052, Duration 00:00:00

30.05.2011 05:02:53 IDoc: Start = 30.05.2011 05:02:53, End = 30.05.2011 05:02:53

30.05.2011 05:02:53 Job finished

Thanks for your help.

Yann

[Former Member · Accepted solution]

Hi Yann,

Sorry but this 0CO_OM_WBS_6 seems a std extractor. on CO* tables. You may have not created indices on these tables to run all datasources faster.

This is the note on that. Note 382329 - Delta extractors CO: Poor performance

Edited by: Parth Kulkarni on May 30, 2011 12:05 PM

[Former Member · Accepted solution]

Parth Kulkarni,

following the note and the other thread, I've check the index 4 of the table COEP.

Here is what I got:

Index ID COEP - 4

Short text MANDT/TIMESTMP/OBJNR, Index for Delta read method (CO-PA)

Last changed SAP 04.01.2010

Status Active Saved

Does not exist in the database

-

---

DB index nme

Not defined as DB index in the ABAP Dictionary

Is the fact that it doesn't exist in the database a problem ?

Is the fact that it is active is good enough ?

By the way thanks for your speedy reply !

Yann

Edited by: Yann GOFFIN on May 30, 2011 1:35 PM

[former_member186445 · Accepted solution]

"does not exist in the database" is indeed a problem. ask your bc people to create the index.

M.

[Former Member · Accepted solution]

Problem solved.

Indeed the activation of the 4th index of the table COEP reduce tremendously the delay:

31.05.2011 04:14:51 1 LUW confirmées et 1 LUW à supprimer avec le MF RSC2_QOUT_CONFIRM_DATA

31.05.2011 04:17:20 Appel de l'extension client BW_BTE_CALL_BW204010_E (BTE) avec 54.441 enregistrements.

Thanks a lot.

[Former Member]

resolution: activation of the 4th index of the table COEP.

[Former Member]

I do not say that i am giving a solution but is it possible for you to create a program with the join conditions as in the Join on which the data source has been created..

The execution time may well give you hint & even de-bugging the program will tell you of why is the delay.

Please try this out if possible.

It maybe the join conditions that need to be re-defined or it maybe something else.

*Well i failed to see that, but it is a standard extractor. Maybe the note would help you out.

Edited by: Vishal Sanghvi on May 30, 2011 12:22 PM