}hold cubes and issues with savedata (9.1.4)
Posted: Tue Sep 22, 2009 8:45 am
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
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