Transactional log clearing

[Moh]

Good Morning Sir,i have read this IBM tech note and did not fully understand this

Run a save data all to clear out the transaction log.

Once the transaction log is cleared out the tm1 server will be back to a normal startup time.Is it means save data all clears old log file with new save data log.my second question is which takes longer TM1 server start up or shutting down,I think shutting down because it has to commit all data.please explain.

[Alan Kirk]

Good Morning Sir,i have read this IBM tech note and did not fully understand this

Run a save data all to clear out the transaction log.

Once the transaction log is cleared out the tm1 server will be back to a normal startup time.Is it means save data all clears old log file with new save data log.my second question is which takes longer TM1 server start up or shutting down,I think shutting down because it has to commit all data.please explain.

Yes, that Technote isn't wrong but it's not very well explained either. The writer almost seems to be suggesting that there should be a tm1s.log file at every startup, which I sincerely hope they didn't mean. This is the deal:
(a) When you write values into a cube then as long as the cube has logging turned on, the details of that transaction are written into a text file called tm1s.log. As more and more transactions are written, that file becomes larger and larger (as you would expect).
(b) When you do a data save on the server the cubes, which now include the results of all of the writes recorded in the tm1s.log file, are written to disk.
(c) Now that the changes are all tucked safely away in the .cub files on disk, the transactions that are in the tm1s.log file are no longer of any concern to us except for audit purposes; certainly the system no longer needs them. TM1 therefore saves the tm1s.log file under the filename tm1sYYYYMMDDHHmmSS.log, where YYYYMMDDHHmmSS is a timestamp representing the time that the save was done. A new, empty tm1s.log file is then created, ready to start the whole process again.
(d) A data save is also done when you shut the server down, except that no new tm1s.log file is created since the server will no longer be running after the save and therefore won't need a transaction log until you next start it up. When you start the server again a new, blank tm1s.log file is created.

So if a normal shutdown is done, there should be no tm1s.log file when you restart the server. Contrary to what the technote seems to imply, there will be nothing for the server to do with the file because it won't exist.

If the server crashes without having completed a data save, on the other hand, the tm1s.log file will still be in place. That tells TM1 that it needs to reload all of the transactions that occurred between the last successful data save (when the tm1s.log file was first created) and the time of the crash. It therefore reads all of the values from that log into the cubes.

If the tm1s.log file is very large, that can take a long time. That is what the Technote was referring to. However if the shutdown was normal, which should be the case in the overwhelming majority of cases, there will be no tm1s.log file to read.

In answer to your second question, it's a case of "how long is a piece of string?". The time that it takes for a server to start and stop will vary according to a number of things such as:
(a) Whether you use persistent feeders;
(b) Whether you are using multithreaded or single threaded startup; and
(c) How many cubes need to be saved to disk on shutdown.

If there have been few or no changes since the last data save was done, then the TM1 server will drop like a brick when you tell it to shut down. If many, many cubes and possibly .feeders files need to be written, it can take a very long time indeed.

[Moh]

Thank you for the detail explanation.