TM 1 restrictions
TM 1 restrictions
Hi everybody!
Does TM 1 have any restrictions for developing, such as:
- the element name length
- dimension (cube, etc.) name lenght
- quantity of elements in dimension
and so on.
Thx
Does TM 1 have any restrictions for developing, such as:
- the element name length
- dimension (cube, etc.) name lenght
- quantity of elements in dimension
and so on.
Thx
-
- MVP
- Posts: 3652
- Joined: Fri Mar 13, 2009 11:14 am
- OLAP Product: TableManager1
- Version: PA 2.0.x
- Excel Version: Office 365
- Location: Switzerland
Re: TM 1 restrictions
Pre 9.4 Unicode release string limits were 255 characters. I'm pretty sure but not 100% that this would have also applied to element names, dimension names, cube names, process names, etc.
With the latest release the sky is the limit for string lengths. (But from a practical perspective really the more concise and meaningful the better ...)
Number of dimensions in a cube: it used to be 16 quite a few versions back but is now 256 I think, but again from a practical perspective any more than 20 and the cube becomes too unwieldy to manage.
Number of elements in a dimension: 2 billion is the number bandied about as the theoretical maximum. Dimensions of several hundred thousand are reasonably common with quite acceptable performance. Once you get to the level of a few million elements in a dimension you are likely to come up against practical limitations, i.e. performance issues, so the theoretical limit is probably exactly that, theoretical.
With the latest release the sky is the limit for string lengths. (But from a practical perspective really the more concise and meaningful the better ...)
Number of dimensions in a cube: it used to be 16 quite a few versions back but is now 256 I think, but again from a practical perspective any more than 20 and the cube becomes too unwieldy to manage.
Number of elements in a dimension: 2 billion is the number bandied about as the theoretical maximum. Dimensions of several hundred thousand are reasonably common with quite acceptable performance. Once you get to the level of a few million elements in a dimension you are likely to come up against practical limitations, i.e. performance issues, so the theoretical limit is probably exactly that, theoretical.
Re: TM 1 restrictions
Thanks a lot
- Olivier
- Community Contributor
- Posts: 159
- Joined: Thu Jun 26, 2008 5:46 am
- OLAP Product: TM1
- Version: Tm1 10.2.2fp4 -> 2.09
- Excel Version: Excel 2013 - 2019
- Location: Sydney
Re: TM 1 restrictions
Hi Everybody,
Did anybody found restriction on maximum cube size ?
We are having a 5.5gig cube in our a live environment.
I am suspecting it to be causes for instability for the server.
Anybody have found any restriction regarding cube size itself ?
Kind Regards,
Olivier
Did anybody found restriction on maximum cube size ?
We are having a 5.5gig cube in our a live environment.
I am suspecting it to be causes for instability for the server.
Anybody have found any restriction regarding cube size itself ?
Kind Regards,
Olivier
HTH
Olivier
Olivier
-
- MVP
- Posts: 3652
- Joined: Fri Mar 13, 2009 11:14 am
- OLAP Product: TableManager1
- Version: PA 2.0.x
- Excel Version: Office 365
- Location: Switzerland
Re: TM 1 restrictions
5.5 GB is not a large cube these days. There is absolutely no reason why cube size or data volume per se should cause any instability (unless you are sailing close to the wind in terms of physical RAM availability on the server.)
Unless you are short of RAM on the box itself the cause of stability issues are going to be elsewhere.
Unless you are short of RAM on the box itself the cause of stability issues are going to be elsewhere.
- Olivier
- Community Contributor
- Posts: 159
- Joined: Thu Jun 26, 2008 5:46 am
- OLAP Product: TM1
- Version: Tm1 10.2.2fp4 -> 2.09
- Excel Version: Excel 2013 - 2019
- Location: Sydney
Re: TM 1 restrictions
We have plenty of RAM available (Over 30 Gigs) but the design of the model itself is a bit weak.
This main heavy cube is pulling hundred of rules around it and Feeders haven't been defined half of the time.
On most of heavy weekly duty day, we regurlarly observe a server crash with not much logging indications
or in best cases an attribute corruption will occur at some point.( usually fixed by importing xdi in).
I have been observing/maintaining this model for a while now, but i can't identified clearly the area which is impacting the stability.
And so couldn't the Cognos senior consultants who came to document this system a while ago...
All they did was underligning the complex design and suggested simplifications (which do not clearly establish the source of the crashes...)
That s why from the corner,
i am questionning the capacity of Tm1 to handle cubes that prior versions couldn't even dream of as the limitation at the time was 4 Gig all together.
And by extension i believe the design should take this into consideration when building a model.
Is that possible that even advertising supporting unlimited amount of RAM the software has difficulties handling heavy cubes containing gigs of rules calculations ?
I am anyway ready to accept that it can also only be combination of poor design, heavy activity and cube size that trigger the issue and not the size of the cube on it's own...
That is why iam asking the gurus if they are used to handle cube comparable in size ( 5.5g or more...).
Thanks for your input.
Kind regards,
Olivier
This main heavy cube is pulling hundred of rules around it and Feeders haven't been defined half of the time.
On most of heavy weekly duty day, we regurlarly observe a server crash with not much logging indications
or in best cases an attribute corruption will occur at some point.( usually fixed by importing xdi in).
I have been observing/maintaining this model for a while now, but i can't identified clearly the area which is impacting the stability.
And so couldn't the Cognos senior consultants who came to document this system a while ago...
All they did was underligning the complex design and suggested simplifications (which do not clearly establish the source of the crashes...)
That s why from the corner,
i am questionning the capacity of Tm1 to handle cubes that prior versions couldn't even dream of as the limitation at the time was 4 Gig all together.
And by extension i believe the design should take this into consideration when building a model.
Is that possible that even advertising supporting unlimited amount of RAM the software has difficulties handling heavy cubes containing gigs of rules calculations ?
I am anyway ready to accept that it can also only be combination of poor design, heavy activity and cube size that trigger the issue and not the size of the cube on it's own...
That is why iam asking the gurus if they are used to handle cube comparable in size ( 5.5g or more...).
Thanks for your input.
Kind regards,
Olivier
HTH
Olivier
Olivier
Re: TM 1 restrictions
Hi!
As our consultants said there is restriction in Windows - It can't use for processing ANY jobs more then 2 Gigs of RAM.
But there is existing "mystical" ways that System Administrators can advise you
As our consultants said there is restriction in Windows - It can't use for processing ANY jobs more then 2 Gigs of RAM.
But there is existing "mystical" ways that System Administrators can advise you
-
- Community Contributor
- Posts: 125
- Joined: Wed May 28, 2008 1:22 pm
- OLAP Product: TM1, Cognos Express,..
- Version: 9.1.4 FP1
- Excel Version: 2010
- Location: Vienna
- Contact:
Re: TM 1 restrictions
only 32bit has the 2/3gig limitIRIV wrote:Hi!
As our consultants said there is restriction in Windows - It can't use for processing ANY jobs more then 2 Gigs of RAM.
But there is existing "mystical" ways that System Administrators can advise you
the mystical way would be installing a 64bit os
- Steve Vincent
- Site Admin
- Posts: 1054
- Joined: Mon May 12, 2008 8:33 am
- OLAP Product: TM1
- Version: 10.2.2 FP1
- Excel Version: 2010
- Location: UK
Re: TM 1 restrictions
and 32bit is limited to around 3.2gb-ish if you tweak the system config. nothing mystical tho, it's abounding all over the internets if you care to search for something like "windows 32bit 3gb switch"
If this were a dictatorship, it would be a heck of a lot easier, just so long as I'm the dictator.
Production: Planning Analytics 64 bit 2.0.5, Windows 2016 Server. Excel 2016, IE11 for t'internet
Production: Planning Analytics 64 bit 2.0.5, Windows 2016 Server. Excel 2016, IE11 for t'internet
-
- Posts: 3
- Joined: Wed Aug 07, 2013 3:41 pm
- OLAP Product: TM1
- Version: 10.1
- Excel Version: windows 7
Re: TM 1 restrictions
I have a model which has cube size of Cube cell count is 7.5 10 to the power E+36. We have lot of performance issues.
There are almost 10 such cubes.
Need inputs on what should be maximum cube cell count size in a TM1 model.
There are almost 10 such cubes.
Need inputs on what should be maximum cube cell count size in a TM1 model.
-
- MVP
- Posts: 3652
- Joined: Fri Mar 13, 2009 11:14 am
- OLAP Product: TableManager1
- Version: PA 2.0.x
- Excel Version: Office 365
- Location: Switzerland
Re: TM 1 restrictions
How about supplying some useful information. How large are the cubes in memory? How large are the cubes on disk?nik1608nik wrote:I have a model which has cube size of Cube cell count is 7.5 10 to the power E+36. We have lot of performance issues.
There are almost 10 such cubes.
Need inputs on what should be maximum cube cell count size in a TM1 model.
The theoretical number of cells that could potentially be populated is completely irrelevant since TM1 doesn't bother building the tries unless populated and the inherent handling of sparsity is very good.
What matters is the number of populated leaf cells and fed cells and the memory consumption per cell. The ratio of in memory size vs on disk size is also a potential indicator of model efficiency or inefficiency.
Does the model have lots of leaf rule calculations vs pure data? Are the performance issues restricted to the rule calculations or overall? Are rules properly fed?
Please place all requests for help in a public thread. I will not answer PMs requesting assistance.