This content has been marked as final. Show 3 replies
There are lots of factors that could be contributing to the issue.1 person found this helpful
What is the exact error message you are getting, I assume it is "Error "1006023: Data cache is full. Please increase the data cache size for database [databaseName]."
Do you get it with running every rule, do you get the same error if run as a calc script from essbase.
What is the block size and dimensionality (no of members, dense/sparse), other cache cfg settings, database size, what sort of calculation is causing the error.
Is essbase 32/64bit (assume 64bit with such large cache sizes), which OS, memory, have you tried not using memscalingfactor and decreasing the cache to see if it is an issue with memscalingfactor, I know there can sometimes be issues with using it probably the reason why it has now been removed so you would need to rule it out.
For 11.1.1.x then it is worth reading the documentation on Optimizing Essbase Caches - "http://docs.oracle.com/cd/E12825_01/epm.111/esb_dbag/frameset.htm?pt09.htm"
Thank you John,
We have found that it is the entity dimension that should be responsible to this problem.
I remember we have encountered this kind of problem before when we aggregate an application with the entity dimension hierarchy mixed with shared and stored instances of the same level 0 members. To put it simple, there are three members under "Entity" dimension member, which represents different view of entity hierarchies of same level 0 members. the first one has stored level 0 entity members while the other two have shared ones. And at that time, our client added another hierarchy with shared level 0 members, but they did not put this tree under "Entity" dimension member directly, but rather put it under the first child of "Entity", which is the one with stored level 0 members.
It is a little bit confusing to describe the situation only by text. Anyway, at that time, the first hierarchy had both stored and shared instances of the same group of level 0 members. And the data cache is always full when aggregating. and after we moved the forth hierarchy to another tree so under that hierarchy the level 0 members are all shared instances, the aggregation worked flawlessly.
I wondered why this happened and consider this is related to detailed calculation logic of Essbase. May you shed some light on this topic? Thank you with all my heart!
After reviewing the Entity architecture, we found that it's the mixture of store/shared instance that caused the problem.