SaveDataAll on 9.4 FP2

[dludwig]

We recently upgraded to TM1 9.4 FP2 and are getting the following error message when executing the 'SaveDataAll' function within a chore:

Error: Prolog procedure line (27): SaveDataAll failed. See tm1server.log for more information


The information in the tm1server.log shows the following:
912 WARN 2010-03-27 05:02:49.250 TM1.Server TM1ServerImpl::FileSave could not reacquire lock on object with index 0x20000010
912 WARN 2010-03-27 05:02:49.250 TM1.Server TM1ServerImpl::FileSave could not reacquire lock on object with index 0x40000001
912 ERROR 2010-03-27 05:02:49.266 TM1.Process Process "ServerSaveData": : Execution was aborted. Error file: <TM1ProcessError_20100327050249_ServerSaveData.log>

Everything seems to save just fine and from some other reading I have done this doesn't seem to be a major error. However, has anybody found a way to prevent this from happening? Does anybody have experience with this behavior?

[rkaif]

Try recreating your Chores. In some instances after the upgrade you need to re-do your Chores

[dludwig]

I rebuilt the chore yesterday but we still received the same error messages. Is anybody else experiencing the same thing? In our chore we have a bunch of TI jobs that run then we have a TI job that executes the 'SaveDataAll' and then a bunch more TI jobs run all in the same chore.


thanks...

[AWILDE]

Hi,

We upgraded to 9.4 FP2 about 3 weeks ago and I got a report of the same problem from a user yesterday, it has worked fine till now. I have ran the process as admin and it works fine. I have tested as the user and they keep getting the same problem the process is being executed but the data is not being saved at the end.

[mattgoff]

Per a recent exchange I had with support, SaveDataAll has to be in a process all by itself in a chore by itself. This is an artifact of the new locking scheme (why, I have no idea). Leaving SaveDataAll as part of other processes or in chores can result in a Rollback loop. I scrubbed all of them out of my processes and chores and replaced them with a single one that runs nightly.

On a related note, the new locking scheme also seems to have problems with overlapping chores. My guess is they're being over-conservative (or have a bug in) their collision detection algorithms.

Matt

[highlnder8]

Thanks for bringing this up.

It's strange, but I created some new TI Processes at the end of March and they worked fine with SaveDataAll, but just last week I started getting this error too.

What a pain.

[Martin Ryan]

I got in bright and early to a client (running 9.1 SP 3) this morning to test some stuff I moved live last night and have been sat here for half an hour waiting for the SaveDataAll to finish because it keeps rolling back and trying again. I noticed last night as well when I manually kicked off a Save Data that it took about five goes to get it done.

I think there are other chores at play that are trying to get kicked off in the midst of the SaveData. In particular we have a chore that fires off some email reports every hour. Is that likely to be the source of the problem? Any other thoughts on roll back in 9.1.3?

Martin

[Martin Erlmoser]

check if you find *.*$ files in your databasedir

[Martin Ryan]

I do indeed, that's how I know there's a roll back. The $ files show up while the save data all occurs, then they disappear, then reappear (several times) then when save data finally succeeds they disappear proper (or rather overwrite the previous cub file).

Martin

[hyd_ladka]

It's strange, but I created some new TI Processes at the end of March and they worked fine with SaveDataAll, but just last week I started getting this error too.

I have recently started facing this.
There is a TI Process which updates metadata and data. There is a SaveDataAll Function written in the Epilog tab.
This has been set up few months back and no further change was done.
There is also a chore for SaveDataAll which runs for every 1 hour. Its an independent isolated process.

After running the TI process (for loading data), it says the process is aborted and shows the SaveDataAll Failed message in the error log file.

My Question is. when it did not happen for last few months, what could be the reason for this to suddenly pop up and how do we identify it?
I am pretty sure that the problem is with the function SaveDataall written in epilog, because on commenting the same, the aborted message does not appear.
Kindly Help.

By the way, all this is in 9.5.2

Thanks
Raj

[Duncan P]

This is the official advice on the matter - https://www-304.ibm.com/support/docview ... wg21459718. It at least explains why it is happening. It doesn't explain how you got away with it till now.

[Andy Key]

There is a SaveDataAll Function written in the Epilog tab.

Assuming you are talking about a process that only contains SaveDataAll, then the latest advice I got from IBM is to put the SaveDataAll on the Prolog tab rather than the Epilog. This is by word of mouth, so don't expect any of the references you find on the website to have been updated, but moving it to the Prolog helps stop corruption of the log files with missing double quotes.

If you are talking about a process that does metadata updates, data updates then a SaveDataAll in the Epilog, then obviously moving it to the Prolog is daft, but you should probably then be taking note of the resolutions in the link on Duncan's post.

[David Usherwood]

I raised a PMR on this, albeit concerning CX95 aka TM1 951 - 50670 019 866 .
I had severe difficulty communicating to IBM Support that since (in our, extreme, situation) we restarted the server after the process completed, separating the SaveDataAll into a separate chore wasn't really possible. They also insisted that we had other users on the server when we don't. I found myself telling the Head of IT at the client that I did not agree with IBM's advice.
In practice, the problem was sporadic, and hasn't recurred for a while. We do disable the separate, timed SDA chore - but we have been running the batch process for 18 months without this issue affecting us. Weird.