Small CubeView Failing

[CraigWebb301]

Hi,

I am encountering very strange behaviour within the cubeviewer environment in 10.2.2.

I have a cube comprising of 12 dims, the largest of the 2 containing 900,000+ (incident ID) and 80,000+ (Time) elements. The cube has no rules whatsoever.

For a specific month, there are 8000 incident flags populated, thus to pull an all N-level view for all dimension, i would expect that only 8100 rows be returned.
If i attempt to generate the view however, i receive the usual memory limit exceeded.

The MaximumViewSize parameter is currently set to 2.5GB (2500)
The log file displays the al_alloc() error and lists the required pool size for the view at 2.6GB.

I have manipulated the view in a few ways, such as :
*selected a consolidation of all time elements with the N-level Incident ID codes, zeros suppressed - view worked, return 8100 records.
*selected a consolidation of all time elements with the N-level Incident ID codes, zeros unsuppressed - view worked, return 900,000+ records.
*selected a consolidation of all incident ID elements with the N-level time elements, zeros suppressed - view worked, return 5000+ records.
*selected a consolidation of all incident ID elements with the N-level time elements, zeros unsuppressed - view worked, return 80,000+ records.

All of these combinations worked fine, however the combination of N-Level for both fails everytime.

Increasing the MaximumviewSize to 5GB worked, however when attempting to load the same view in a report takes very long.

Any ideas welcome

[CraigWebb301]

Still no luck.

Tried the following so far to no avail:
* Re-ordered dimensions to cut the cube size to 200MB.
* Replaced all Time elements with a basic numeric value code using alias swap to test if ':' in element names cause problems.
* Increased the MaximumViewSize to 5GB. View has been running for 25minutes with no response yet.

[Gabor]

Have you tried to put your elements of the large dims in a subset to build the view? From time to time that solved similar issues for me in the past.
My latest observation of this kind of behaviour is, a 50.000 elements picklist based on a dim is unusable in Perspectives (Web is fine due to default paging), but if you make it a subset of that dim then it's working fine.

Coming back to your issue, the cube order is important and you can't trust the automatic feature to do it.

[Duncan P]

I think it would help if you said exactly what dimensions there are, and in the view that's failing if you said exactly what was on rows, columns and pages, and if you have anything other than time and incident on rows or columns to give an indication of the structure of those dimensions and what is selected.

All of these things will have a significant impact on what TM1 generates under the covers to service your view.

Also you should be able to get a cube cell count from the stats cube.

[CraigWebb301]

I have created a new cube which contains only the following dimensions:
* Time dimension (elements hh:mm:ss.00000 E.G. 08:43:23.00000)
* Incident ID (element ##### E.G. 984576)
* Measures (Incident Flag)

I exported the months information i am working with to a CMA, then imported into this new cube. Total incident flag count = 8178.
Creating a view will a dynamic level 0 subset for each dimension fails regardless of the dimension order. (row or column)

Total cube size is only 1026KB.

[Duncan P]

Again, what's on rows, what's on columns and what's on pages?

If you have time on columns and incident on rows then from your earlier view results I would expect a view of 40500000 cells, which is very different from 8178.

And also have you tried it with static subsets? Or have you created new dimensions without any of the consolidations and tried it from a cube using those?