Advice for controlling cube growth

Hello,

We have a twelve-dimensional cube that was initially set up by an Infor Consultant in 2015 (prior to my involvement with the business). Over the years this cube has grown exponentially - over the past year or so it has ballooned from around 8GB to 30GB. I do not really use Infor BI, so I'm not fully aware of the cube's usage; however, the lead analyst convinces me the volume of data loaded and number of elements have remained fairly static over this time.

Our webserver has 32GB RAM, so as you can imagine is straining under the load of the cube (97%+ RAM utilisation). I calculate we should have around 70GB of RAM at this stage, but it's not feasible for us to throw more memory at the problem. When the analyst adds new elements to the hierarchies the RAM utilisation drops to around 50% until the routine backup runs.

My initial thoughts are to redesign and partition the cube into specific use cases; however, this will involve significant overhead in redesigning reports, etc. Could anyone offer any advice on this situation?

Kind regards,

Carl Slater

Find more posts tagged with

Infor EPM Discussions

Comments

akopczewski

There are probably numerous ways of addressing the problem. Most of them will focus on splitting cube into subcubes. I presume you have time dimension and probably store all data since 2015. If you won't change historic data, I would simply create several copies of a cube for each historic year/month even. Than in your main cube wrote couple of rules like this: Target: TIME:2015 Source: DB ('MAIN_CUBE_2015', !TIME, !PRODUCTS, etc.).
Another important thing would be changing OLAP settings. You would like to change cube loading to listed and list only main cube. This way, if noone ask about 2015, cube will be offline, not taking up RAM until someone ask for it on report.
No changes on report needed. In 12.0.7 there is option to automatically unload unused cubes from memory. In 11.0 you need to use API for that or scheduled restart of OLAP service at night.

Maybe you have other dimension that could be used to split cube insted of time, like: version, scenario.

Nick Gladkov

Thanks, Carl and Artur. First thing I would go to InforXtreme and talk with them - if you say you didn't add many new elements and/or data - then you should not have this situation. The critical thing here would be to check how memory is used, how server releases it, possible optimisation, etc. But even before that - check the latest patches - I know that with earlier versions there were situations when cube was not releasing memory and it was fixed in the later patches.

All of it, support consultants can help you with.

Nick Gladkov | Senior Product Manager, Infor d/EPM | Infor

unknown

Thank you for your advice Artur and Nick. After some investigation it turns out data has been loaded into high level elements using Application Studio, meaning the data has been distributed across base level elements. In practice, the data should have been loaded against specific base level elements. This has had the undesired effect of taking up an awful lot of disk space and subsequently memory.

I will find a way to resolve this, but it's going to be time consuming!

Thanks again

Carl

zsolt-pinter

Hi Carl,

One thing to be looking into is the number of values that you have on the cubes. Currently the limitation for a cube is 2 billion values. we have a similar situation, we are having 2 cubes with many dimensions, and they have more than 1 billion values currently. So we will soon start discussions how we could break it down into smaller cubes with less dimensions, as we usually don't analyze everything against everything.

An idea may be to look into whether you have any operation on place that would write back or splash a lot of 0s. That would be something that would make your cube growing very fast, without adding real value. If this is the case, those processes could be changed to avoud the writeback of the 0s, or we also have a script running periodically that cleans out all 0 values from the cube.

Hope it helps,

Zsolt

Copyright © 2025 Infor. All rights reserved.