OBIEE Usage Tracking

Question

Hi All,

I am currently exploring OBIEE Usage Tracking report and wanted to check few things.

There is a report which just gives 1 record and for most of the user the report run time i.e.Total Time Secs shows 1-2 secs.

However, I also see an entry for some user where it took 650+ secs to show the result. The report cannot have performance issue as its just basic report with 1 table.

Is there any specific reason it shows higher total time secs?

I know If the user submitting the query navigates away from the page before the query finishes, then the final fetch never happens, and a timeout value of 3600 is recorded. But that should not be the case here.

Is Usage Tracking not the full proof solution to find how long a report took to show results?

Any help would be appreciated.

Regards,

rmoff · Answer

Thank you. I understand your point. Is there any way to get the actual time taken using Usage Tracking.?

No.

user8590399 · Answer

Thank you. I understand your point. Is there any way to get the actual time taken using Usage Tracking.?

rmoff · Answer

Usage Tracking tells you how long the BI Server was working on the logical query, including holding open the ODBC cursor for the client (typically, Presentation Services).

The time in Usage Tracking often does match up what the end-user will experience, but not always. Things like reports paging through data etc will give a higher total time in Usage Tracking than the user experiences for the initial display of data.

Put it this way:

* If the users are complaining that the report took 650 seconds to return, and Usage Tracking says 650, then it took 650 
* If the users phone up and say their report takes 300 seconds to return, and Usage Tracking says 650, then it took 300
* If Usage Tracking says 650 and the users haven't reported anything, then it may or may not be 650 - you can't make that assumption

By looking at logs further up the line (eg sawlog with greater debug level) you can trace a specific query's response time through the stack. Even then, you can only time the point at which it departed the HTTP server (WLS) - if the user is on a slow network and/or slow-rendering browser then it make take even longer.