on 04-30-2004 6:57 AM
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
It appears that this is due to a program error described in note 750551 'Very long times for QTIMEOLAP'.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
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
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Marc,
Thank you very much for your response; in a few lines you have explained more about this field than I had previously found after many hours of investigation.
I found the ABAP program in RSRT, it is under a thousand lines (966), and the query is not particularly complicated (statistics below). The generate date shown in the heading of the code shows 12 May 2004 but there have been several instances of high values in qtimeolap since then. Curiously there were alot yesterday (6 over a hundred seconds, many over ten seconds), today there has been nothing over five seconds.
Statistics Number
InfoCubes concerned with MultiCube 1
FEMS Number (Selection Groups) 11
Number of Elements in Structure 1 26
Selection Lines 57
Columns in Memory Table SP 10
Free Chars 12
Basic Key Figures 1
Formula Components 22
Hierarchies 0
Hierarchy Node 0
Variables 6
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.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
Hi Anil,
Thanks for your response. Interestingly we are also on 3.0B SP18.
I've checked that the number of rows being returned is not very large, here are some details from ST03: notice there are only 69 cells and that DB time is under 2 seconds.
It will probably be a couple of weeks before I can devote much time to investigate this further. If you find the explanation in the mean time please let us know.
Good luck,
Rob
InfoCube Name 0OPA_C11
Name of Query CO_0OPA_C11_Q001
Total Runtime (s) 788.1
OLAP Runtime (s) 778.5
OLAP Time / Total Runtime (%) 98.78
Database Runtime (s) 1.5
Database Runtime / Total Runtime (%) 0.19
Frontend Runtime (s) 8.2
Frontend Runtime / Total Runtime (%) 1.04
Number of Cells 69
Number Formatted 14
Ratio of Formattings to Number of Cells 0.2
User | Count |
---|---|
84 | |
25 | |
12 | |
9 | |
6 | |
6 | |
5 | |
5 | |
4 | |
4 |
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.