BW Infopackage always runs for 7hrs (regardless of number of records)

[Former Member]

Hello Experts,

Good day. We have a BW system that is almost 1 year old. It is extracting data from ECC system.

I noticed that one of our Daily InfoPackage always runs for 7 hours every day. (even if there is only few records being loaded)

Here's an example screenshot:

               I checked the last 5 loads/days in the Infopackage Monitoring Screen.

               It ran for 7 hours when it loaded 400,000 records. But today there were only 19,000 records being loaded but it still ran for 7 hours.

         

Note:

• I moved the Infopackage schedule to a different time, when no other BW jobs are running, but it still ran for 7 hours.
• I checked the runtimes from last year, Last year the Infopackage only runs for 2-3 hours every day (regardless of the number of records being loaded) so this proves that the Infopackage runtime is not dependent on the number of records being loaded.

Question:

What other possible factors may be causing the Long Runtime of the infopackage?

Thank you for your time!

[RamanKorrapati · Accepted solution]

Hi,

Rather than checking at bw side, Have you checked ECC job logs of info pack?

please watch them and see at which step its taking more time.

You can compare last one year job logs randomly if system have old logs at SM37 source side.

From info pack monitor, menu Environment-->job overview-->job in the source system-->enter ecc user id and pass word. find your job there.

Is any changes applied at on data source level like enhancement?

is this is delta or full load info pack?

if its full load info pack then create new info pack and check it.

at info pack, Scheduler--> max wait time paramters, please check it.

Thanks

[Former Member · Accepted solution]

Thank you RK, I also wanted to check on the source system but we currently dont have access to Production ECC. But I will check with business if they did some data enhancements to the source tables.

As for the Loading Method, this is a Delta Infopackage.

Is it possible for Delta Loading to run longer than a Full Load? (is there a instance where in it will take longer to pull "new data/delta data" instead of full load?)

Thanks RK!

[RamanKorrapati · Accepted solution]

Hi,

Indexes also required built at source tables as said by Amit.

Additional - we need to set/check table - BWOM_SETTINGS as stated at SAP Note.

Please refer OSS Note - 382329 - Delta extractors CO: Poor performance.

Thanks

[Former Member]

Hi experts I have a follow up question:

1. Our Master Data Process Chain is the first to run in our Daily Loads.

Can I schedule our Cost Center Load (the 7 Hour Infopackage) to run earlier than master data?

Will it have any negative effects if I load this Cost Center Infopackage ahead or side by side with the master data loads?

2. Is there a System Cache for BW Loads? My BASIS colleague commented that its also possible the System Cache may be almost full which is why the Data Loading is now taking longer than before.

Thank you.

[RamanKorrapati]

Hi,

Best way is load master data and later trigger transaction data loads.

Ask basis team to cross check SM58 while running loads.

Even cross check Tx- SM50/51, whether required free application servers are there or not. if not then load will take more time to finish.

Thanks

[Former Member]

Hi Juan,

With datasource name it is almost evident that issue is with table COEP. The issue is lying with indexing of this table. In last year this table must have low data but now with time the data is growing and hence more time.

There is a SAP note which indicates that we should activate index~4 for table COEP. you can have a look at that.

But I think if you actiavte the index 4 for table COEP it will greatly enhance the performance.

See, in your current scenario you do not have index 4 activated in your database, so when you start the data load from BW the system tries to create and buffer the index everytime and takes everytime around 7 hrs. It will increase by the time you get more data in the table.

Also as Ram said it is a best practice that we load master data first and then transaction data.

I do not really believe that system chache is playing a significant role in performance.

Check Note: 382329 - Delta extractors CO: Poor performance

Regards

Amit

[Former Member]

Hello Juan,

What is your database type?

These notes would be relevant for Oracle

1118205    RSODSO_SETTINGS Maintain runtime parameter of D

547464     Nologging Option when creating indexes

and

87964     CO delta extractors: poor performance for Deltainit

82329     Delta extractors CO: Poor performance

Best regards, Andras

[Former Member]

Hi Juan,

Can you share the name of datasource? There could be a possibility that selections from some tables is taking time. So ideally if we know the name of datasource we can try to find the possible ase tables. If it was taking 2-3 hours last year and now 7 hours then I would think that data in that table is increasing and you have not applied secondary indexing. Check the job logs in SM37 for the infopckage and try to find the step where it took longer. Must be some selection on growing base table.

Please let us know.

Thanks

Amit

[Former Member]

Hi Amit,

The name of the datasource being used is:

Cost Centers: Actual Costs Using Delta Extraction (0CO_OM_CCA_9)

Thanks for your input, what will be the effect of Secondary Indexing?