TM1 Forum

Whenever our tm1 server crashes, I notice that the tm1s.log is sitting there in logging directory holding the transactions happened after the last "Save Data". My question is, once the server is restarted, will these transactions be loaded into the RAM and the future transactions be appended to them until further "Save Data"? Our users complain that the transactions made between the last SaveData and the time the service was terminated are not loaded when the server was restarted after crash.
Appreciate your help!

These transactions should be automatically picked up and restored when server starts up, unless the log file itself is corrupted. Worst case scenario - you retrieve them and load manually (hopefully server crashes don't happen too often in your environment, because if they do, then that's your first priority to solve).

sophie wrote:Whenever our tm1 server crashes, I notice that the tm1s.log is sitting there in logging directory holding the transactions happened after the last "Save Data". My question is, once the server is restarted, will these transactions be loaded into the RAM and the future transactions be appended to them until further "Save Data"? Our users complain that the transactions made between the last SaveData and the time the service was terminated are not loaded when the server was restarted after crash.
Appreciate your help!

As QML said, the recovery happens automatically. However, TIs which continually zero out and refresh a cube (say from a general ledger system) usually turn off logging when they do so so that they don't create hugely bloated files. In that case, those values will never be in the log file, and won't show up again until the next time the interface runs.

I'd suggest getting the users who claim that some transactions are missing specify exactly which transactions they're referring to so that you can determine the source of those values. (That is, manual entry into a cube or an interface from another system.) If it's a manual entry, go through the log files to see whether you can see the original entry (and any subsequent entries to that combination of elements) and compare them to the current cube value.

In my case, the tm1s.log had entries from before the crash and the subsequent transactions were appended to the same log after the server restarted. The file got saved with timestamp during the next "Save Data". Hence I think, the file is not corrupt.

qml wrote:These transactions should be automatically picked up and restored when server starts up

Alan Kirk wrote:As QML said, the recovery happens automatically.

By this, I understand that the transactions should be loaded to memory from the tm1s.log along with other TM1 objects when the server restarts after crash. But this did not happen. What should I be doing to make sure the transactions are not lost?

sophie wrote:In my case, the tm1s.log had entries from before the crash and the subsequent transactions were appended to the same log after the server restarted. The file got saved with timestamp during the next "Save Data". Hence I think, the file is not corrupt.

qml wrote:These transactions should be automatically picked up and restored when server starts up

Alan Kirk wrote:As QML said, the recovery happens automatically.

By this, I understand that the transactions should be loaded to memory from the tm1s.log along with other TM1 objects when the server restarts after crash. But this did not happen. What should I be doing to make sure the transactions are not lost?

How do you know "this did not happen"? Did you do what I suggested, which is to look at specific entries in the log and compare them to the values in the cube? Did you determine where those entries are supposed to have come from?

In the vast majority of cases the reason that transactions are "lost" is that they were never in the log file in the first place, but you've given no indication that you've checked that.

Can you find .rej files for rejected items in same directory the log file is stored to?
Do you run a service? Running TM1 in foreground as application will usually lead to a prompt after each crash and if reload is cancelled, the data get pushed to the .rej file.

Gabor

Check }CubeProperties to see if logging is set to YES for the cube. If not, the transactions are not sent to tm1s.log.