Well, Catalog Crawling had always been the unexplored little area of OBIEE. A Google search on it returned me no results.OK Good, I thought, let myself write-up on it and here goes an intro of it….
It’s fundamentally wrong!!
Have you heard of Oracle Business Intelligence’s aggregate persistence wizard or worked on it lately? I think, it’s one poor guy whom most of the developers got wrong!!!
Let me try clearing some air about it…….
- Were you being tired of designing your aggregated data models?
- Were you having tough time generating dimensional surrogate keys?
- Are you thinking of how to go about loading the aggregates, even if you had the datamodel?
- Are you constantly being confronted by the task of updating the Metadata (.rpd), even if you have all the aggregates in place?
If you have any of the above issues, try OBIEE’s Aggregate Persistence Wizard.
To the Rescue!!!
With differing capacities of Integration and Production servers, most of the times developers miss an important perspective; How would their code scale in the production systems. I had such a situation, where I could bring in drastic improvements in my report retrieval times.
Ever wished, you had a way to override session level information with users selections? If you were one just like me looking forward to tune your reports further, you would just love the request variables in OBIEE 11g.
A Grand Total or Measures at different grains in an analysis is quite a common requirement for BI reports. If we are using Oracle Business Intelligence tool, it is quite smart and intelligent to combine multiple sub-queries for each request into a single query and fire it to the database. The database being robust (and supposed to be) and just because database guys have always been my best friends, I have been pretty happy to see this kind of intelligent query design, and all the query processing load being transferred to the database. However, we might have seen this might not be the case always (yes, even after enabling WITH clause in db features of the database).I have seen a case myself recently,when the BI Server thought of splitting the single request to multiple and joining the record sets in its engine.
We can force the BI Server to always try to keep it as a single query by adding the following parameter in your NQSConfig.ini
DISABLE_SUBREQUEST_CACHING = YES
So if you notice from this parameter, we can understand that the BI Server has a tendency to split queries and cache them individually and combine on demand, which I think is again another smart way of working on a request. So, it’s upto us to choose on this processing.
NOTE: This parameter is only to direct the BI Server not to split queries. So it means, you could still see some queries split up if the Server does not think if it can combine.
Hope you found this useful and till I catch up again, Adios.