TM1 Server Crash

[Mark RMBC]

I have had problems with a TM1 server crashing and although I think I have resolved the issue I am hoping if anyone can help me understand why what I discovered would cause a TM1 server instance to crash.

To cut a long story short it appears as if a ragged or unbalanced dimension was causing the issue, so I had a dimension with no Top or All level. the highest level in the dimension is level 2 and there is a level 1 and 0. The dimension was ragged because all but one of the highest level parents is level 2, except one where the highest is level 1. I changed this ragged level to match all the others, so it had a level 2, 1 and 0 and this appears to have resolved the issue. Please note there is still no Top or All level in this dimension.

Not sure why this would resolve the issue as my understanding is that TM1 can handle ragged dimensions

I will attach a document which gives the slightly longer story

[Mark RMBC]

Please see attached

[tomok]

ITo cut a long story short it appears as if a ragged or unbalanced dimension was causing the issue

Ragged hierarchies are normal for TM1 and would not cause a server to crash. It is more likely you have some issues with rules and/or feeders causing the issue. BTW, a dimension with no Level 0 elements (leaf level elements) would be pretty much worthless as you would not be able to store any data in a cube using that dimension. Granted you could use rules to put data in an intersection of non-leaf level cells but you wouldn't be able to store anything.

[Mark RMBC]

Thanks for the Reply TOMOK,

I do have leaf level elements in the dimension.

Ok, if it isn't the ragged hierarchy what sort of rules or feeder issues can cause the server crash?

Just to help me when investigating!

cheers, Mark

[tomok]

I do have leaf level elements in the dimension.

Then by definition you have Level 0 elements because that's what a leaf element is.

Ok, if it isn't the ragged hierarchy what sort of rules or feeder issues can cause the server crash?

Overfeeding and running out of memory is the most common cause. I don't know anything about your model(s) so I can't offer any suggestions.

[Mark RMBC]

Hi TOMOK,

Not sure where I said there were no level 0 codes?

I get that you know nothing of my model and wasn't expecting you to pinpoint the exact cause.Just wanted to know if there are any usual culprits so I can focus on those initially.

You mentioned overfeeding as one thing, when reading up on this I came across circular referencing. So just wondered if there were any schoolboy errors that could lead to this

cheers, Mark

[EvgenyT]

You mentioned overfeeding as one thing, when reading up on this I came across circular referencing. So just wondered if there were any schoolboy errors that could lead to this

Don't think circular reference would normally crash the server, but blowing feeder stack and memory would.

Any server log messages would be helpful

[declanr]

Don't think circular reference would normally crash the server, but blowing feeder stack and memory would.

I have seen circular references and stack overflows give exactly the same server log messages so I think TM1 views them as the same thing.

[EvgenyT]

Well noted mate. What I meant is circular reference per se

[Mark RMBC]

Thanks for the replies.

There are no error messages in the Log unfortunately

One thing I do want to ask, is it a bad idea to use a specific consolidated element in a dimension as a feeder when this consolidated element gets deleted and then created again every time the dimension is updated (which is via a TI process). It should be noted that the deleted consolidated element will always exist, just that I took the approach of deleting all consolidated elements in the dimension and rebuilding the hierarchy. I do this by in the PROLOG looping across all elements in the dimension and if DTYPE is not N or not the very top level then delete the elements. In the same process I then rebuild the hierarchy.