Transaction MRI7 & FV60 Db. Req. Time very high in STAD

[Former Member]

Greetings,

We are having very slow response time on the above mentioned transactions. For the past days the maximum Db Req. Time experienced by some users are as follows in tx STAD:

MIR7 - Db Req. Time = 7, 433,017

FV60 - Db Req. Time = 62,305

As you can image these users are complaining because they have to meet the payment run closing date.

We have run the table statics for all tables used by these transactions in DB20. Transaction OS01 ping results in average of 121ms. Normal command prompt ping also results in good response time. I tried to follow most of the suggestions mentioned in this forum to no avail.

Is there any thing we can do from the basis side? I need a quick fix.

[Former Member · Accepted solution]

Hi,

Use transaction ST05 to generate SQL traces and look at execution plans for the longest requests.

You will see if the rightindexes are choosen and if a new index could speed up the performance.

Regards,

Olivier

[Former Member · Accepted solution]

Hi,

I have provided some of my personal recommendations as per the experience. Hope some of them will help you in resolving the issue.

I guess you use Oracle

In case of Oracle database please check if you have all parameters recommendation set properly as per note 830576, make sure that you installed all additional patches into your system per note 871096, please check also if the environment variables for oracle database are set as per note 830578.

Latest optimizer/Merge fix patch - Note 981875.

As you mentioned the statistics are updated for the tables but did you check the size of the tables which were used.

And did you try to simulate it by a small agreement and big agreement and check hows the performance and what are the additional load/tables are being accessed.

Do you follow SAP archiving strategie:

Wether archive of your IDOCs happens on a regular basis (for details see Note 40088) because sometimes it may also cause load.Check the size of table EDIDC and if possible create index on suitable selective fields..

You can see the size of tables and indexes and see if reorganise of these tables can help.

SAP Note 332677: Reorganizing degenerated Indexes.

Some SAP NOTES:

790680 MM IV: Performance during check for duplicated

754076 MIRO/MIR7: Performance when entering an invoice

752408 MIRO/MIR7: Performance

389359 MIRO: Performance problems check double invoice

134660 Logistics Invoice Verification: Performance (RBKP)

-SAP Note 311089 which describes how to aggregate your POs with very long histories.

- please refer to the following notes:

756292 Consulting: Performance MIRO Enter

158519 Performance optimization in logistics invoice veriflets start with the first point:

Thank you

[Former Member]

Hope you have looked at sap buffer sizes like program buffer.