Oracle Analytics Cloud and Server

In OBIEE12c report query is hitting twice to database

Received Response
41
Views
8
Comments
Ravi_Teja
Ravi_Teja ✭✭✭

as we all know query hits the database when we try to run the report. Also, again it's hitting the database when i try to export the results. Is there any way to restrict it?

Tagged:

Answers

  • Depending on the kind of export you do, not really. Because what you see on screen is maybe not enough for the export.

    If you enable caching you have more chances that the second query hit the cache and find a match and stops there.

  • Ravi_Teja
    Ravi_Teja ✭✭✭

    Thanks Gianni…Let me see in cache perspective.

  • Sumanth V -Oracle
    Sumanth V -Oracle ✭✭✭✭✭

    @Ravi_Teja - You can try the below settings to make sure cache is used and physical query is not re-run again on DB. Please be informed the below quoted is an example which handles the row limit upto 65000, if it's more then update the values accordingly.

    set the value of <DefaultRowsDisplayedInDownloadCSV> = <ResultRowLimit> -1000 in instanceconfig.xml.

    For example:

    <Table>

        ......
        <DefaultRowsDisplayedInDownloadCSV>64000</DefaultRowsDisplayedInDownloadCSV>

    </Table>


    .......


    <ODBC>
    <ResultRowLimit>65000</ResultRowLimit>
    </ODBC>

    Then, the presentation server cache can be hit and the physical query will not re-run on DB. 

  • Just keep in mind all the possible issues with cache: you need to manage it so that users see the right data at the right time and not a cached copy of old data instead.

    If you can live with the 2 queries, it would be "safer" as you don't have to expect side effects. As an alternative, if your plan is to export the analysis, why to display it? You could just have a download like or something like that…

  • Ravi_Teja
    Ravi_Teja ✭✭✭

    Agreed…currently it's on prem and we are migrating to cloud now so in cloud everything is based on the queries hit by the app and based on that cost will calculate. so i'm thinking all open possibilities to cut down it.

  • You mean that your database will charge you by the query?

    If that's the case, then you should definitely investigate caching in detail because you have no way to predict the behavior of your users, mostly if they are using OBIEE. Because it's an analytical platform and people expect to be able to query things again and again (maybe just refreshing the page, or when changing a parameter or whatever else).

  • Ravi_Teja
    Ravi_Teja ✭✭✭

    You mean that your database will charge you by the query? - YES, that's what we hear from vendor

  • Well, I would definitely look for a different database (even if it does involve an ETL step to copy the whole database content once a day to a database that you don't pay by the query). Because that's just against the usage of an analytical platform.

    But knowing that it's a decision you maybe can't really take at this point, time to dive into caching to try to cache as much as you can to limit queries.