Hi Brains Trust,

When re-ordering cube dimensions today via Architect (don't have access to alternative UI for reordering) using the system determined order (-50% indicative improvement) the cube was successfully re-ordered, i.e. no error when applying.

When the cube data was saved however the file size went from approx. 6MB (I know why bother) to 47GB, yes GB. 

Other cubes were reordered without issue.

TM1 11.8.01100.20

Microsoft Windows Server 2016 Standard Server 10.0.14393 Build 14393 (x86_64)

Any suggestions why this might have occurred? Cube / Element Data?

Thanks in advance

Hi Joshua,

When I have to reorganize cube after a hudge delete of incorrect data, I need to :

  Launch a savedataAll (and waiting ..... waiting....)

  Stop TM1

  Delete feeders files

  Restart TM1.

  TM1 process all feeders with cube containing only "good" data

Then all the "garbage" consumption is cleared and size dramatically reduce

Perhaps could you try ?

Regards,

Philippe

Hi Brains Trust,

When re-ordering cube dimensions today via Architect (don't have access to alternative UI for reordering) using the system determined order (-50% indicative improvement) the cube was successfully re-ordered, i.e. no error when applying.

When the cube data was saved however the file size went from approx. 6MB (I know why bother) to 47GB, yes GB. 

Other cubes were reordered without issue.

TM1 11.8.01100.20

Microsoft Windows Server 2016 Standard Server 10.0.14393 Build 14393 (x86_64)

Any suggestions why this might have occurred? Cube / Element Data?

Thanks in advance

Hi Brains Trust,

When re-ordering cube dimensions today via Architect (don't have access to alternative UI for reordering) using the system determined order (-50% indicative improvement) the cube was successfully re-ordered, i.e. no error when applying.

When the cube data was saved however the file size went from approx. 6MB (I know why bother) to 47GB, yes GB. 

Other cubes were reordered without issue.

TM1 11.8.01100.20

Microsoft Windows Server 2016 Standard Server 10.0.14393 Build 14393 (x86_64)

Any suggestions why this might have occurred? Cube / Element Data?

Thanks in advance

Hi Joshua,

You could do reordering dimensions in a cube in PAW Workbench as well.

Best regards,

Hi Brains Trust,

When re-ordering cube dimensions today via Architect (don't have access to alternative UI for reordering) using the system determined order (-50% indicative improvement) the cube was successfully re-ordered, i.e. no error when applying.

When the cube data was saved however the file size went from approx. 6MB (I know why bother) to 47GB, yes GB. 

Other cubes were reordered without issue.

TM1 11.8.01100.20

Microsoft Windows Server 2016 Standard Server 10.0.14393 Build 14393 (x86_64)

Any suggestions why this might have occurred? Cube / Element Data?

Thanks in advance

Hi Brains Trust,

When re-ordering cube dimensions today via Architect (don't have access to alternative UI for reordering) using the system determined order (-50% indicative improvement) the cube was successfully re-ordered, i.e. no error when applying.

When the cube data was saved however the file size went from approx. 6MB (I know why bother) to 47GB, yes GB. 

Other cubes were reordered without issue.

TM1 11.8.01100.20

Microsoft Windows Server 2016 Standard Server 10.0.14393 Build 14393 (x86_64)

Any suggestions why this might have occurred? Cube / Element Data?

Thanks in advance

Hi Joshua,

Just out curiosity, did you try changing the order back and if so does the file size go back down to approximately those 6MBs?

Also, how many dimensions does this cube have?

Cheers,  

Hi Brains Trust,

When re-ordering cube dimensions today via Architect (don't have access to alternative UI for reordering) using the system determined order (-50% indicative improvement) the cube was successfully re-ordered, i.e. no error when applying.

When the cube data was saved however the file size went from approx. 6MB (I know why bother) to 47GB, yes GB. 

Other cubes were reordered without issue.

TM1 11.8.01100.20

Microsoft Windows Server 2016 Standard Server 10.0.14393 Build 14393 (x86_64)

Any suggestions why this might have occurred? Cube / Element Data?

Thanks in advance

Hi Hubert,

I instead opted to revert the cube back from a backup. It has 6 dimensions. 

Hi Joshua,

Just out curiosity, did you try changing the order back and if so does the file size go back down to approximately those 6MBs?

Also, how many dimensions does this cube have?

Cheers,  

Hi Brains Trust,

When re-ordering cube dimensions today via Architect (don't have access to alternative UI for reordering) using the system determined order (-50% indicative improvement) the cube was successfully re-ordered, i.e. no error when applying.

When the cube data was saved however the file size went from approx. 6MB (I know why bother) to 47GB, yes GB. 

Other cubes were reordered without issue.

TM1 11.8.01100.20

Microsoft Windows Server 2016 Standard Server 10.0.14393 Build 14393 (x86_64)

Any suggestions why this might have occurred? Cube / Element Data?

Thanks in advance

Sorry Joshua, have to ask, if you'd reorder again to the order you chose, does it blow up the file again?

And if so, would it be a model (cube with supporting assets) you could share with IBM to study what might be off (6MB to 47GB can't be right IMHO).

Hi Hubert,

I instead opted to revert the cube back from a backup. It has 6 dimensions. 

Hi Joshua,

Just out curiosity, did you try changing the order back and if so does the file size go back down to approximately those 6MBs?

Also, how many dimensions does this cube have?

Cheers,  

Hi Brains Trust,

When re-ordering cube dimensions today via Architect (don't have access to alternative UI for reordering) using the system determined order (-50% indicative improvement) the cube was successfully re-ordered, i.e. no error when applying.

When the cube data was saved however the file size went from approx. 6MB (I know why bother) to 47GB, yes GB. 

Other cubes were reordered without issue.

TM1 11.8.01100.20

Microsoft Windows Server 2016 Standard Server 10.0.14393 Build 14393 (x86_64)

Any suggestions why this might have occurred? Cube / Element Data?

Thanks in advance

I in fact did it twice (applied reordering) as I thought perhaps the issue was caused by something other than that specific operation; same result each time. I was contemplating trying to reproduce in non-prod environment as well, but haven't done so yet.

Shouldn't be a problem in terms of sharing, cube is not sensitive per se, but let me confirm. 

Thanks for your assistance.

Sorry Joshua, have to ask, if you'd reorder again to the order you chose, does it blow up the file again?

And if so, would it be a model (cube with supporting assets) you could share with IBM to study what might be off (6MB to 47GB can't be right IMHO).

Hi Hubert,

I instead opted to revert the cube back from a backup. It has 6 dimensions. 

Hi Joshua,

Just out curiosity, did you try changing the order back and if so does the file size go back down to approximately those 6MBs?

Also, how many dimensions does this cube have?

Cheers,  

Hi Brains Trust,

When re-ordering cube dimensions today via Architect (don't have access to alternative UI for reordering) using the system determined order (-50% indicative improvement) the cube was successfully re-ordered, i.e. no error when applying.

When the cube data was saved however the file size went from approx. 6MB (I know why bother) to 47GB, yes GB. 

Other cubes were reordered without issue.

TM1 11.8.01100.20

Microsoft Windows Server 2016 Standard Server 10.0.14393 Build 14393 (x86_64)

Any suggestions why this might have occurred? Cube / Element Data?

Thanks in advance

OK, so, I tried to reproduce in our non-prod environment (refreshed last week). The file size inflated as per prod, except instead of 47GB, it went to 70GB. 

I in fact did it twice (applied reordering) as I thought perhaps the issue was caused by something other than that specific operation; same result each time. I was contemplating trying to reproduce in non-prod environment as well, but haven't done so yet.

Shouldn't be a problem in terms of sharing, cube is not sensitive per se, but let me confirm. 

Thanks for your assistance.

Sorry Joshua, have to ask, if you'd reorder again to the order you chose, does it blow up the file again?

And if so, would it be a model (cube with supporting assets) you could share with IBM to study what might be off (6MB to 47GB can't be right IMHO).

Hi Hubert,

I instead opted to revert the cube back from a backup. It has 6 dimensions. 

Hi Joshua,

Just out curiosity, did you try changing the order back and if so does the file size go back down to approximately those 6MBs?

Also, how many dimensions does this cube have?

Cheers,  

Hi Brains Trust,

When re-ordering cube dimensions today via Architect (don't have access to alternative UI for reordering) using the system determined order (-50% indicative improvement) the cube was successfully re-ordered, i.e. no error when applying.

When the cube data was saved however the file size went from approx. 6MB (I know why bother) to 47GB, yes GB. 

Other cubes were reordered without issue.

TM1 11.8.01100.20

Microsoft Windows Server 2016 Standard Server 10.0.14393 Build 14393 (x86_64)

Any suggestions why this might have occurred? Cube / Element Data?

Thanks in advance

Hi Joshua, sounds like an issue we also faced in previous version. After Upgrading to version 2.0.9.16 this issue did not occur again. Here is the related APAR: https://www.ibm.com/support/pages/apar/PH46586

https://www.ibm.com/support/pages/system/files/inline-files/ibm_fixlist_planning_analytics_20916-2.pdf

OK, so, I tried to reproduce in our non-prod environment (refreshed last week). The file size inflated as per prod, except instead of 47GB, it went to 70GB. 

I in fact did it twice (applied reordering) as I thought perhaps the issue was caused by something other than that specific operation; same result each time. I was contemplating trying to reproduce in non-prod environment as well, but haven't done so yet.

Shouldn't be a problem in terms of sharing, cube is not sensitive per se, but let me confirm. 

Thanks for your assistance.

Sorry Joshua, have to ask, if you'd reorder again to the order you chose, does it blow up the file again?

And if so, would it be a model (cube with supporting assets) you could share with IBM to study what might be off (6MB to 47GB can't be right IMHO).

Hi Hubert,

I instead opted to revert the cube back from a backup. It has 6 dimensions. 

Hi Joshua,

Just out curiosity, did you try changing the order back and if so does the file size go back down to approximately those 6MBs?

Also, how many dimensions does this cube have?

Cheers,  

Hi Brains Trust,

When re-ordering cube dimensions today via Architect (don't have access to alternative UI for reordering) using the system determined order (-50% indicative improvement) the cube was successfully re-ordered, i.e. no error when applying.

When the cube data was saved however the file size went from approx. 6MB (I know why bother) to 47GB, yes GB. 

Other cubes were reordered without issue.

TM1 11.8.01100.20

Microsoft Windows Server 2016 Standard Server 10.0.14393 Build 14393 (x86_64)

Any suggestions why this might have occurred? Cube / Element Data?

Thanks in advance

Hi Dominic,

This does indeed seem related, was there a root cause identified?

It mentions string cube, does this mean the measures contained only strings? 

Hi Joshua, sounds like an issue we also faced in previous version. After Upgrading to version 2.0.9.16 this issue did not occur again. Here is the related APAR: https://www.ibm.com/support/pages/apar/PH46586

https://www.ibm.com/support/pages/system/files/inline-files/ibm_fixlist_planning_analytics_20916-2.pdf

OK, so, I tried to reproduce in our non-prod environment (refreshed last week). The file size inflated as per prod, except instead of 47GB, it went to 70GB. 

I in fact did it twice (applied reordering) as I thought perhaps the issue was caused by something other than that specific operation; same result each time. I was contemplating trying to reproduce in non-prod environment as well, but haven't done so yet.

Shouldn't be a problem in terms of sharing, cube is not sensitive per se, but let me confirm. 

Thanks for your assistance.

Sorry Joshua, have to ask, if you'd reorder again to the order you chose, does it blow up the file again?

And if so, would it be a model (cube with supporting assets) you could share with IBM to study what might be off (6MB to 47GB can't be right IMHO).

Hi Hubert,

I instead opted to revert the cube back from a backup. It has 6 dimensions. 

Hi Joshua,

Just out curiosity, did you try changing the order back and if so does the file size go back down to approximately those 6MBs?

Also, how many dimensions does this cube have?

Cheers,  

Hi Brains Trust,

When re-ordering cube dimensions today via Architect (don't have access to alternative UI for reordering) using the system determined order (-50% indicative improvement) the cube was successfully re-ordered, i.e. no error when applying.

When the cube data was saved however the file size went from approx. 6MB (I know why bother) to 47GB, yes GB. 

Other cubes were reordered without issue.

TM1 11.8.01100.20

Microsoft Windows Server 2016 Standard Server 10.0.14393 Build 14393 (x86_64)

Any suggestions why this might have occurred? Cube / Element Data?

Thanks in advance

I think it affects cubes, having one ore more string element in measure dimension. In our case we had both numeric and string elements in measure dimension. I do not have any further information on root cause. 

Hi Dominic,

This does indeed seem related, was there a root cause identified?

It mentions string cube, does this mean the measures contained only strings? 

Hi Joshua, sounds like an issue we also faced in previous version. After Upgrading to version 2.0.9.16 this issue did not occur again. Here is the related APAR: https://www.ibm.com/support/pages/apar/PH46586

https://www.ibm.com/support/pages/system/files/inline-files/ibm_fixlist_planning_analytics_20916-2.pdf

OK, so, I tried to reproduce in our non-prod environment (refreshed last week). The file size inflated as per prod, except instead of 47GB, it went to 70GB. 

I in fact did it twice (applied reordering) as I thought perhaps the issue was caused by something other than that specific operation; same result each time. I was contemplating trying to reproduce in non-prod environment as well, but haven't done so yet.

Shouldn't be a problem in terms of sharing, cube is not sensitive per se, but let me confirm. 

Thanks for your assistance.

Sorry Joshua, have to ask, if you'd reorder again to the order you chose, does it blow up the file again?

And if so, would it be a model (cube with supporting assets) you could share with IBM to study what might be off (6MB to 47GB can't be right IMHO).

Hi Hubert,

I instead opted to revert the cube back from a backup. It has 6 dimensions. 

Hi Joshua,

Just out curiosity, did you try changing the order back and if so does the file size go back down to approximately those 6MBs?

Also, how many dimensions does this cube have?

Cheers,  

Hi Brains Trust,

When re-ordering cube dimensions today via Architect (don't have access to alternative UI for reordering) using the system determined order (-50% indicative improvement) the cube was successfully re-ordered, i.e. no error when applying.

When the cube data was saved however the file size went from approx. 6MB (I know why bother) to 47GB, yes GB. 

Other cubes were reordered without issue.

TM1 11.8.01100.20

Microsoft Windows Server 2016 Standard Server 10.0.14393 Build 14393 (x86_64)

Any suggestions why this might have occurred? Cube / Element Data?

Thanks in advance