Issue after implementing the ST03 Weekly Performance Data Correction

[Former Member]

Hello,

We had implemented the correction for ST03/ST03N Weekly performance data not displayed as per the Note 1443908 released by SAP in March 2010.

We implemented the correction in DEV and QA environments initially,tested the performance data for a couple of weeks and upon satisfied with the data displayed we had implented the correction in Production.

What we noticed in Production is the Average Response time (ms) of our Central and DB Instance computed in the Daily Performance data which was below or around 200ms for the last 4 months had jumped to above 230ms from the very next day and it continuously seems to be above 250ms since then for the last 2 weeks. Average Response time of all the App instances seems to be fine and we didn't find any creep.

So we are not clear if this correction puts a overhead on the system/database to recompute/recalculate and display the weekly performance data.

Our Production environment is

R/3 Release: SAP 3.0F

Database: Oracle 9.2.0.8

OS: HP-UX 11.23 B

and have 1 C&DB instance and 4 Application instances.

We are thinking of reverting the correction in production and see how the resopnse time are going to be.

Can anyone please suggest if similar issue was encountered in any of the environments and if this correction could be the cause of this issue.

Have a Good Day!

Thanks & Regards,

Vasu

[Former Member]

Hi All,

In continuation to my earlier post, we had reverted the corrections suggested in SAP Note: 1443908 relating to ST03 Weekly performance data in the function modules (SAPWL_ACCNT_GET_DIRECTORY, SAPWL_TABSTAT_GET_DIRECTORY, SAPWL_WORKLOAD_REORG) we noticed that the Radio buttons (This Week, Previous Week) are no more displayed in Performance Database --> Choose time period but the Weekly performance data report still seems to be running as we could get the weekly statistic for the current week from the function module SAPWL_ACCNT_GET_SYSTEM_USAGE.

We are still experiencing higher Average Response time (above 275ms) on C&DB Instance even after reverting the Weekly performance data code, so we are in a suspicion whether the Weekly statistics gathering is really switched off or not by SAP. Can you please share your thoughts on this and how to completely switch off the Weekly Statistics gathering by SAP.

I will be very thankful if you can suggest solution and appreciate your quick response.

Thanks & Regards,

Vasu

[markus_doehr2]

> We are still experiencing higher Average Response time (above 275ms) on C&DB Instance even after reverting the Weekly performance data code, so we are in a suspicion whether the Weekly statistics gathering is really switched off or not by SAP. Can you please share your thoughts on this and how to completely switch off the Weekly Statistics gathering by SAP.

So I'd either dig through the code and check what is being calculated or open an OSS call and let the support check. Your problem is too specific.

Markus

[markus_doehr2]

> What we noticed in Production is the Average Response time (ms) of our Central and DB Instance computed in the Daily Performance data which was below or around 200ms for the last 4 months had jumped to above 230ms from the very next day and it continuously seems to be above 250ms since then for the last 2 weeks. Average Response time of all the App instances seems to be fine and we didn't find any creep.

The question is: what is you goal?

I don't see any significance in the response time being 200 ms or 230 ms - this is VERY fast, basically no user will notice a difference.

The question also is: is this very light increase of the response time caused by the correction or caused by a higher system load?

Markus

[Former Member]

Hi Markus,

Thanks for your quick reply.

We have a mandate from customer to maintain the Average Response time (ms) of C&DB instance below or upto 200ms and we had the ART stable for the last 4 months but for the last 2 weeks the ART is almost above 250ms and it has even touched 300ms on two days which is causing concern to the customer and customer is asking if this is due to the correction imported into Production.

We had investigated in all the scenarios like user load, CPU load and found the load to be almost same as June'10.

Another activity we carried out is the total environment reboot as part of quarterly maintenance. But the response time was in 200ms limit in the first week after maintenance. We imported the correction in the next week and noticed the spike in response time from the very next day.

Your thoughts on this are highly appreciated.

Thanks & Regards,

Vasu

[markus_doehr2]

> Another activity we carried out is the total environment reboot as part of quarterly maintenance. But the response time was in 200ms limit in the first week after maintenance. We imported the correction in the next week and noticed the spike in response time from the very next day.

>

> Your thoughts on this are highly appreciated.

Honestly I doubt that this correction is the root cause of the statistical inaccuracy; I just thing that more data was taken into account because of the correction and hence they are now more exact than before.

I understand that response times are somewhat critical in sense of an SLA as being an ISP but discussing about statistical data instead of real time experience (performance problems) is tedious.

Maybe you should just wait after the next reboot cycle and see if that impreciseness persists after a few days. If that does not suffice for you I'd create an OSS call.

Markus

[former_member204746]

if you have people running big jobs in dialog, this will falsely impact your average response time.

also, maybe once badly designed Z ABAP development was implemented lately?