}hold cubes and issues with savedata (9.1.4)

[Jeroen Eynikel]

Hi all,

we are using TM1 9.1sp4 and I am seeing some issues, that may or may not be related.

1: somehow the system seems to be creating }hold cubes itself. I.e. I see them appearing from time to time,
'}Hold_USERNAME_Cubename. Now I am certain that the username referred to in the cubename did not apply any holds, but since the }Hold has a username in its description it must have been triggered by something the user was doing. Anyone have any idea when and why these }hold cubes are being created?

2: I am seeing issues with a savedataall command in TI.
In load processes with a savedataall on the end* the savedataall fails from time to time (causing an abort of the process). So far everytime it failed I also noted the existence of one or more of these }hold cubes. Delete them and then restart the server => load process and savedata work again. I do not know whether the removal of the }hold plays a role in this - I delete them as a precaution. Just deleting the }hold cube (using TI) is definitely not enough, a restart is necessary.

(* the ones where I have seen it trigger other processes themself. So you get TI 1 (executed by the user) that runs a few other TI's (performing the various loads) and when control is returned to TI1 it executes a savedataall in the epilog))


In the message log we get a dozen messages like:

3796 WARN timestamp TM1.Server TM1ServerImpl::FileSave could not reacquire lock on object with index blabla


It is pretty weird as as far as I can tell a TI process that does nothing else but a savedataall (we have a chore running every 2 hours doing just a savedataall), or a manual savedata seem not to suffer from the problem.

Right now I have removed the savedataall statements from all the load processes. I still have a chore running that performs a savedata every 2 hours so I figure the risk is limited - provided this chore is not going to start to fail as well.

Now has anyone else experienced similar issues in 9.1sp4? Can I count on at least the chore with just a savedataall remaining to work without problems? Is there a fixpack for this somewhere / Is it fixed in 9.4? Is a 9.4 FP2 server compatible with 9.1 clients? (I.e. I will consider upgrading as the current situation makes me feel very uneasy - but it is a huge pain if we also have to upgrade the clients).

Thanks for your input,

Jeroen

[frosterrj]

I see the save data all error (cant get lock yada yada) in chores occasionally, but could never really tell why since its usually at the end of a chore - what else is running preventing the lock? No users on system for sure.

There is an FP 1 for 9.1.4. Just got the info from IBM today. Some specific mention of the fixing the save data all errors.
From the Fixed Issues log:
ICC#/Insight ID Summary
11-85057221 TM1 SaveDataAll in chore fails with messages in log file.

and what about this gem (!):
11-81784235 Physical memory consumed is reduced considerably.

no telling if that applies to 64 or 32 bit install. There are 64 and 32 bit packages though.

there is also something about hold cubes

Just about to post a general question on if any has seen any regressions AFTER the FP1 is applied.

Good luck


The zip files are in the IBM FTP download area.

[shorsted]

Hi

I've just also replied to the thread about 9.1.4 FP1 (we are 64 bit) but thought I would mention here (as I did not there) that we did also experience the Save Data problems, and also ended up removing all SaveDatas from our processes except our one SaveDataAll process which runs every hour

Since updating to FP1 we haven't tried putting the SaveDatas back into other processes but we did recently have a system health check from Cognos and they recommended keeping them separate as we are doing. They also recommended using a chore with only one process that in turn execute multiple processes instead of putting multiple processes into a chore - something we were also already doing

Glad to report our health check was all clear but we are still having the odd (once a month?) crash of the server

Regards
Sarah

[frosterrj]

Wow! I feel lucky! We have 2 nightly chores, one with 68 processes and one with 46, both with SaveDataAll processes in the middle and end, and we almost never (knock wood) have those issues. I would die if each of my processes had to be in its own chore. Kind of defeats the purpose of a chore.

Robert

[shorsted]

Robert

Sorry, I may have phrased that wrongly.

Instead of having one chore that calls say 5 processes, we have one process that uses ExecuteProcess within it to call the other processes, this one process is then added into a chore and scheduled.

As alot of our chores only run one process anyway, its not such a biggie

Regards
Sarah

[jim wood]

Does anybody know if the same Save Data issue applies to version 9.1.3?

[BigDSter]

Just seen this error bounce up quite a few times while running a savedataall at the end of a chore, this is on 32 bit 9.4 MR1 FP1 on a 64 bit server

492 WARN 2009-12-10 11:34:05.596 TM1.Server TM1ServerImpl::FileSave could not reacquire lock on object with index 0x20000056

A chore containing just savedataall worked fine after.

Thinking I might go to hourly savedataall and remove the ones in the chores ... bit of an effort