If your users are missing cache, you might find the service request below helpful.
Description:
User1 one and User 2 have the same profile but User 2 is not hitting User 1′s cache even though the physical queries are exactly the same.
Cause
Customer had implemented data-level security. This resulted in different SQL for each user.
Solution
Cache hits are not based upon the physical queries.
They were using session variables in the connection pool login/password fields. Each different login has a different query, the issuer of the query is different, this results in the cache being specific to a user / session variable.
They modified the connection pool to use a shared login/password and this resulted in a cache hit.
Something else, I’ve found. I suggest always adding 1.00* when working with non-integers, just for sake of convenience.
(Customers.”Total Customers” / sum(Customers.”Total Customers”)) * 100
Cause
The problem was caused because that Integer Data Type values are involved in the calculation. If the calculation is performed on Integer values, then the correct answer is ’0′.
When a Grand Total is specified, then the Data Type is promoted to Double Precision. If the operation is performed on a Double Precision field, then non-zero values will be returned.
Solution
The solution to this issue and to ensure that non-zero values can always be returned in an OBI EE Report is by modifying the formula expression as follows: -
e.g. (1.0*Customers.”Total Customers” / sum(Customers.”Total Customers”)) * 100 or 1000*Customers.”Total Customers” / sum(Customers.”Total Customers”)
When viewing the properties of a fact column in OBIEE, there is a check box “data is dense” when aggregating by dimension is chosen. What does this check box do? I’m not sure if this only applies to multi-dimensional sources or not.
Solution
This is generally used for FIRST/LAST aggregation rules where data is dense across the time dimension, e.g. inventory values for every period. SQL generation is optimized in this case.
There’re a few well-written articles on about OBIEE caching configuration and strategies already. However, I’m posting a solution that I’ve found while investigating an unexpected behavior with tpl cache files disappearing for no reason (no updates in polling table, no manual purge, no BI services restart). Here’s the solution from Oracle:
The behavior was resolved when customer modified the refresh interval for the Repository variables that exist in their Repository.
When a dynamic repository variable is updated, cache is automatically purged. This is designed behavior. Cache will be invalidated (i.e. purged) whenever the initialization block that populates dynamic repository variable is refreshed. The reason that refreshing a variable purges cache is that if a variable was used in a calculation, and the variable changed, then cache would have invalid data. By purging cache when a variable changes, this problem is eliminated.
Since this is the designed functionality, Change Request 12-EOHPZ3 titled ‘Repository variable refresh purges cache’ exists on our database to address a product enhancement request. The workaround is to go through the dynamic repository variables and verify that the variables are being refreshed at the correct interval. If a variable needs to be refreshed daily, there may be a need to set up a cache seeding .bat file that runs after the dynamic variable has been updated. If the cache seeding .bat file runs prior to the refresh of the dynamic variable refresh, then the cache will be lost.
I think they should try to cover similar thing in OBIEE documentation.
Here’s an interesting chart I found
I guess it means two things – OBIEE is becoming more popular and job market outlook looks good for OBIEE consultants
