Performance issues with daily bucket

[Former Member]

Hi Experts.

I´m facing a serious performance issue when extracting data from APO to BW.

The main problem is with 9AMALORE and 9ARE aggregates. The extraction takes about 9 hours and uses astonishing 70% memory resources.

I´ve tried many ways to do this extraction, like changing block sizes at /SAPAPO/SDP_EXTR (all possible combinations as large sizes, small sizes etc.), I also tried to make a parallel extraction (with infopackages settings), but each infopackage takes as many memory as the original one without restrictions, but the version.

These problems do not happen for monthly bucket or other aggregates.

Suggestions are very welcome.

Regards,

TP

[Former Member]

Hi,

generally speaking, poor performance in data extraction can have many reasosn:

1- The PSA table of data source is big

2- Unperformant ABAP coding in transformation (this is not the case since you are using system generated extractor)

3- Check the data package size for extraction in transaction code: RSCUSTV6. These settings can be overrules in infor package. Depending on hardware size of your system you can maintain these paramteres in RSCUSTV6. I our system the parameters has been set to::

Frequency of status IDOC: 10

Package size: 50000

Partition size: 1000000

I hope this helps

Regards

Aban

[Former Member]

Hi TP,

MALORE extraction can indeed be very resource and time consuming.

I found that the latest release works better... in which version are you?

check that you have all relevant OSS notes in place:e.g. 1404514, 1111351, 1073080, 1062866, 1012134

Also have a look at note 409641.

Other ideas that might help:

1. Did you try to set a parallel profile on the datasource directly instead of infopackages?

(I think it is possible from version 5.0...)

Normally splitting with infopackages is quite efficient... but it does not seems to be the case for you. Note that even if you have to run in infopackages in series instead of in parallel, you might found that the overall time is reduce. (because the system has less data to read each time). you can for example cut your extraction in 8 package and run then in 2 parallel runs...

2. Did you use the flag "do not extract null values" on the datasource? This flag can very efficient (as long as you do not use ODS object with delta)

3. If possible reduce the daily extraction to a smaller horizon (short term only) and run weekly extraciton for long term.

Good luck

Julien

[Former Member]

Hi Julien,

Thanks for your quick response and valuable tips.

I saw the SAP notes you´ve recommended. Some of them do not apply. We´re currently on SCM release 510

Notes that I implemented: 1356666 and 1404514, but they didn´t work as expected.

Regarding your questions:

1. Did you try to set a parallel profile on the datasource directly instead of infopackages?

A1: Yes but it´s not possible for this specific case (MALORE), I don´t recall the SAP note but I read one that mentioned this.

2. Did you use the flag "do not extract null values" on the datasource? This flag can very efficient (as long as you do not use ODS object with delta)

A2: Yes, and it´s very helpful;

3. If possible reduce the daily extraction to a smaller horizon (short term only) and run weekly extraction for long term.

A3: In this case, user needs to see all months of a specific planning version. Generally, each version has 7 months (With daily orders data), so I can´t reduce the horizon of this extraction;

• In addition, I have an OSS still in processing (now it is at development level). I hope to have a good outcome to share with this forum.

Regards,

TP

[Former Member]

HI

Do you have any status on this problem.

I'm facing exactly the same

BR

Thomas

[Former Member]

Hi Thomas.

I solved this problem. I don´t have memory or performance issues.

SAP created the note that improved a lot extraction from aggregates 9AMALORE, 9AMALO, 9ARE, and so on.

It is now released to public under number 1408193. Notice that you need to enable extraction suppressing records ( /SAPAP/SDP_EXTR -> Datasource properties)

The most important thing is to identify characteristics that you can use as filters.

In my case extraction of 9AMALORE was the most difficult. SAP recommended using parallelization with infopackages. So as long as I just use production resources I created 3 infopackages restricting ARNAME. Just this simple procedure reduced dramatically memory consumption and time of extraction.

That´s basically this Thomas, if you need more details, I´ll be glad to provide them to you.

Regards,

TP

[Former Member]

HI T.P.

Thank you for your reply.

I have an additional from the curious "APO guys":

Has the changes to the planning area any impact other places in APO. I do of course not want to disturb the daily runs etc.

(I believe not since this is related to the extraction from APO, but to be sure)

Best regards

Thomas