cancel
Showing results for 
Search instead for 
Did you mean: 

Very High QTIMEOLAP

Former Member
0 Kudos

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

Accepted Solutions (0)

Answers (3)

Answers (3)

Former Member
0 Kudos

It appears that this is due to a program error described in note 750551 'Very long times for QTIMEOLAP'.

former_member93896
Active Contributor
0 Kudos

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

Former Member
0 Kudos

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

Former Member
0 Kudos

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.

Former Member
0 Kudos

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