.cub and feeder file are doubled in size

[Tamizharasi]

Hi

.cub file in our application of a sales cube got doubled, there two backups available(aug 11 and aug12){in PROD}
I tested by loading the source files of Aug 12 th on data backup of Aug 11. but there is no change in size of both .cub and .feeder of sales cube {dev}

Also i restarted and saved data
we tested for overfeeding also, there is nothing like that.

still there is no change.

can any one help me what is reaon of this?

[tomok]

Hi

.cub file in our application of a sales cube got doubled, there two backups available(aug 11 and aug12){in PROD}
I tested by loading the source files of Aug 12 th on data backup of Aug 11. but there is no change in size of both .cub and .feeder of sales cube {dev}

Also i restarted and saved data
we tested for overfeeding also, there is nothing like that.

still there is no change.

can any one help me what is reaon of this?

Only loaded data gets saved in the .cub file so feeders and/or rule calculated values have no bearing on it's size. Sounds like you just have twice as much data in the cube. Without knowing your dimensionality and processes around loading the cube I can't give you any guidance. Perhaps you loaded data into an element that didn't have data before, like a different version or time period, or you normally wipe out versions or time periods during the load and it didn't happen? You can always find out by right-clicking on the cube and choosing Export as Text Data. Make sure you check off Skip Consolidations, Skip Rule Calculated Values and Skip Zero/Blank Values. This will dump out only the actual loaded data in the cube. You should be able to tell by looking at the data what happened.

[Duncan P]

I doubt if this is your circumstance but just in case ...

If you have nulls on for the cube and you use ViewZeroOut in an import TI then it will write actual zeros to every cell in the view. These zeros will then get saved to the cube.

[BrianL]

I doubt if this is your circumstance but just in case ...

If you have nulls on for the cube and you use ViewZeroOut in an import TI then it will write actual zeros to every cell in the view. These zeros will then get saved to the cube.

FYI - As of 10.2 TM1 is capable of removing data from the cube rather than just storing zeroes. Even pre-10.2, zero values are not saved out to disk and would not affect the size of the .cub file.

Tamizharasi, are you seeing the cube memory grow, the .cub file has grown, the .feeder file has grown (if persistent feeders are enabled), or some combination of these. If it's the memory, you may find the }StatsByCube useful

[BariAbdul]

If you have nulls on for the cube and you use ViewZeroOut in an import TI then it will write actual zeros to every cell in the view. These zeros will then get saved to the cube

Sorry,If I am wrong here,as for as I understand TM1 sparse consolidation mechanism should simply ignore these zero or null values,So how come it gets saved to the cube? Thanks

[failurehappening]

Sorry,If I am wrong here,as for as I understand TM1 sparse consolidation mechanism should simply ignore these zero or null values,So how come it gets saved to the cube? Thanks

By default you're right, but it is possible to store these values in the cube using UNDEFVALS

http://www-01.ibm.com/support/knowledge ... _undefvals

[Tamizharasi]

I found the issue, user have entered value in the consolidated level of the cube, which is getting spread over all the cells, this is not visible in the architect and while exporting them in excel we found the values.

that why cube got its size as double.

Thanks for all your suggestions and information.

[BrianL]

Sorry,If I am wrong here,as for as I understand TM1 sparse consolidation mechanism should simply ignore these zero or null values,So how come it gets saved to the cube? Thanks

You are partially correct. For cells that have never had any data, there is nothing stored in memory (or in the .cub) file. Pre-10.2 though, once data is input to a cell, there will always be a value stored in memory for that cell. Including if the cell value is later deleted (set back to zero). TM1 would not save these zero values to the .cub file on disk, so the next time you restarted the server the zero values would be cleared out.

[Duncan P]

FYI - As of 10.2 TM1 is capable of removing data from the cube rather than just storing zeroes. Even pre-10.2, zero values are not saved out to disk and would not affect the size of the .cub file.

As far as I was aware, when UNDEFVALS was specified it was the undefval (4.94066e-324 - see here) that was not stored to disk, but when ViewZeroOut was used it wrote actual zeros regardless of the state of UNDEFVALS. This meant that the values written took space and were saved to disk. Has this changed recently?

I was under the impression that the enhancement you are referring to in 10.2 only removed from memory those values that wouldn't be saved to disk, in this case 4.94066e-324.

[BrianL]

As far as I was aware, when UNDEFVALS was specified it was the undefval (4.94066e-324 - see here) that was not stored to disk, but when ViewZeroOut was used it wrote actual zeros regardless of the state of UNDEFVALS. This meant that the values written took space and were saved to disk. Has this changed recently?

I was under the impression that the enhancement you are referring to in 10.2 only removed from memory those values that wouldn't be saved to disk, in this case 4.94066e-324.

Thanks for the correction Duncan. I wasn't thinking of UNDEFVALS when I wrote up my response.