Skip to Content
author's profile photo Former Member
Former Member

Very High QTIMEOLAP

Posted on Apr 30, 2004 at 05:57 AM 12 Views

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

BW Business Explorer (SAP BEx)
Add comment
10|10000 characters needed characters exceeded

3 Answers

  • author's profile photo Former Member
    Former Member
    Posted on May 17, 2004 at 01:11 PM

    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.

    Add comment
    10|10000 characters needed characters exceeded

    • Former Member
      May 18, 2004 at 04:49 AM

      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

  • author's profile photo Marc Bernard
    Marc Bernard
    Posted on Jun 08, 2004 at 04:31 AM

    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 comment
    10|10000 characters needed characters exceeded

    • Former Member
      Jun 08, 2004 at 05:55 AM

      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

  • author's profile photo Former Member
    Former Member
    Posted on Jul 19, 2004 at 12:33 AM

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

    Add comment
    10|10000 characters needed characters exceeded