There’s a bug in OBIEE 10.3.1.2 that renders time-series OBIEE function AGO useless if you’re using Filter on Logical Table Source (Content – WHERE). Apparently, the query generating AGO doesn’t pick it up and as a result – you will not see correct report. It might affect you in many ways if you’re using the LTS filters. The fix that Oracle suggested was to upgrade to 10.3.1.4, however, it’s not possible at the moment. We’ve created database views applying necessary filters there. Performance-wise we got a hit, but our business intelligence server is showing correct data.
Applies to:
Business Intelligence Server Enterprise Edition – Version: 7.9.5 [AA 1900] – Release: V7
Information in this document applies to any platform.
Symptoms
The user is modelling Time Series functionality (Todate) with aggregated dimensions and aggregated facts using BI Server 10.1.3.3.2.
You have created aggregate tables. You have both Logical Dimension and Fact tables mapped to the Aggregate tables.
In Answers you have built a report using the Dimension Hierarchy, which has the measures Sales and Sales YTD. When you drilldown in the report, the measures show the correct figures, until you get to the lowest level where the Sales YTD results are incorrect.
Cause
The cause of this incorrect aggregation when you drilldown to the lowest level of the hierarchy has been determined to be an incorrect sql being generated. The incorrect sql generated lacks the
SUM..GROUP BY
The main difference is that when you are at the lowest level of the aggregate table it doesn’t use “SUM..GROUP BY” in it’s core query.
The issue has been determined to be a Bug, as per Engineering who reviewed the issue.
Solution
However a workaround was provided for this specific customer scenario that resolved the issue. With the implementation below which engineering tested and verified the SUM and Group by was generated in the sql when drilling into the lowest level of the hierarchy.
”
I created a dimension that I just created in the business model and added the additional dimension to the content filter for the problem fact source. That resulted in SQL generation with a SUM clause. My workaround was used just for the problem query submitted. I did not even join the new dimension to the fact table.
So I would recommend creating a virtual dimension in the physical and business model layers. It should not be exposed in the presentation catalog.
“
Mark Rittman has written a very thorough useful guide on using Subversion for version control in OBIEE. I think this sort of strategy would be very appropriate for a large-scale project with many OBIEE developers. I’m personally using regular abundant backups of my project files, however, it might not be intuitive to someone else. I wonder how much effort does it take to maintain version notes?
David Kwan posted a very nice OBIEE caching article – To Cache or Not to Cache That is The Question. I found it very interesting and worth reading. From myself, I’d like to add that in some situations using cache is necessary – for example – a relatively static Dashboard report (maybe updated monthly) from a very large table. I am positive that it’s not worth it for a BI server or a database to waster resources running it for every user over and over.
I’m getting close to a 100 unique visitors daily. I’d really appreciate if you could take a minute and leave a comment about yourself – how did you find the blog? do you like it? how could I improve? did you find information you were looking for? do you check it daily / weekly? Please leave a comment – and let me know (just add “don’t publish”) if you don’t want your comment to be published.
Thank you in advance.