We are using Planning 188.8.131.52 with Essbase 184.108.40.206.000.
I am not sure whether it is suitable place to ask this problem. If this is the wrong place to post, please kindly let me know.
Our client encountered a lot of data cache full errors recently, but the cache is set as usual and no significant change in BRs discovered.
To better tune the cache settings and BR launch procedure, I would like to know the answers to below questions:
1. Is there any garbage collection mechanism related to Essbase cache?
If we encountered data cache full error, we can only feel confident before next BR execution after restart the application and see the cache return to 0. But I think it stupid because we shouldn't have to manually reset the cache. Is there any official document or explanation about cache release mechanism of Essbase cache?
2. How big is enough?
We set the data cache for this application as 4G and MEMSCALINGFACTOR 2, so it should be 8G total data cache assigned. I wondered is there any guideline about how big the cache should be regarding to the dimension size, fix range, calculation function and so on?
3. Do other operations also use up Essbase cache?
For example, opening a 5000-row ad-hoc excel form, 100 users submitting data at the same time...
Please help and thanks in advance for any answers!
There are lots of factors that could be contributing to the issue.
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!