One of my users complained that she sometimes has very bad response time. On investigation I find some navigation steps have very high values for QTIMEOLAP (Time spent in OLAP processor -- ABAP). Usually the value for this query is less than 2 seconds.
Can anyone suggest what may cause this and how it can be prevented?
If you have time to check in your own system it would be interesting to know if you have similar occasional high values.
Sample values from RSDDSTAT using SE16:
QTIMEOLAPINIT 0.000000
QTIMEOLAP 2,845.250001
QTIMEDB 1.359375
QTIMEVARDP 0.000000
QTIMEUSER 0.000000
QTIMECLIENT 8.800782
TIMECHAVLREAD 0.035156
TIMEAUTHCHECK 0.000000
TALERTMON 0.000000
TIMEREST 0.000000
ODBOT 0.000000
ODBOTINIT 0.000000
ODBOTPREPAXES 0.000000
ODBOTREQDATA 0.000000
ODBOTPREDTST 0.000000
ODBOTFLATENING 0.000000
ODBONCALLS 0
ODBONBUFENTRIES 0
Hi Robert,
Wonder which version your are in: 30B?
Here are few SAP notes that talk about this issue: -
558191, 558117, 563608 and 309955.
At the current implementation, we too have a similar case where i find the QTIMEOLAP is high. We are on 30B SP 18.
Well do not know in your case but a very preliminary reason could be:
The BEx report would look somewhat like a operational / master data report where users would want to see all of all data without any filters, restriction etc than that of a traditional BEx report with summarised and slice dice analytical views.
So eventually fetching/transferring so many rows (like we have over 25K rows, 10+ CHAR and KF 😊 ) would definately need runtime memory before and after data at the OLAP processor level.
I am working on this. Will let you know if i get onto something concrete.
Cheers.
Hello Robert,
this might be related to the complexity of the query. Although you said there are only 69 cells, how are they defined? Is this a query with two structures or even cell calculations? An indication of the complexity is the size of the generated ABAP program (you can check it in transaction RSRT). For complex queries the ABAP can have several thousand lines. The long runtime is then caused when the report needs to be (re-)generated.
Regards
Marc
SAP NW RIG US BI
Add a comment