SaveDataAll saves all TM1® data from server memory to disk and restarts the log file.

This function is valid in processes only.

This function is not available in processes on Planning Analytics Engine.

Using SaveDataAll in a Chore

SaveDataAll commits all changes a chore makes prior to calling the SaveDataAll function.

While a chore is running, it accumulates locks on the objects it accesses. The commit operation initiated by the SaveDataAll function temporarily releases all these locks. Once the commit is complete, SaveDataAll reacquires all the locks it had before so it can continue to access the objects it was working on.

There is a brief window during the commit operation where the locks are released and another user or TurboIntegrator process could delete objects the original chore was using. When the original chore attempts to reacquire the locks on those objects, the objects will not be available and the chore will cease processing. In this case, an error similar to the following is written to the Tm1s.log file:

844 WARN 2008-04-01 16:40:09,734 TM1.Server TM1ServerImpl::FileSave could
not reacquire lock on object with index 0x200002ca

Lock contention and using SaveDataAll at the end of TurboIntegrator processes

Using SaveDataAll as last command in a TurboIntegrator process can increase lock contention in TM1 TurboIntegrator processes.

In IBM® TM1 versions, SaveDataAll was often added to the end of a TurboIntegrator process that loads data with logging disabled. The SaveDataAll provided a way to write data from memory to disk directly after a successful import, so that the newly imported data would not be lost in case of a mishap, such as a server crash.

However, adding SaveDataAll as the last command can result in numerous TurboIntegrator import processes, each one with SaveDataAll as last command. This technique worked in TM1 Version 9.0 and older due to the previous lock model which used only the global write lock. At any given time in earlier versions only one write operation could take place. Therefore competing concurrent SaveDataAll operations never occurred from multiple concurrent write operations.

Version 9.1 and newer introduced a more granular lock-by-object model that enables concurrent write operations, if these write operations do not compete for the same resources. If they do compete for the same resources, a lock contention occurs forcing one of the processes to rollback. So now two TurboIntegrator import processes may run simultaneously if they do not share any objects, for example, if they import into two different cubes.

The TurboIntegrator function SaveDataAll relies on the transaction logfile tm1s.log and involves all objects within a data model. Therefore, two TurboIntegrator import processes, both using the function SaveDataAll, cannot run in parallel: one will be executed, the other one (and its TurboIntegrator process) will be forced to rollback. The same is true if the TurboIntegrator processes are part of chores: only one chore will proceed to execute the TurboIntegrator function SaveDataAll, the other chore will be forced to rollback.

A rollback is undesirable from a performance point of view, as it increases the total execution time of a TurboIntegrator process or chore. Competing concurrent SaveDataAll operations will always lead to a lock contention and to a rollback.

There are two possible solutions to avoid competing concurrent SaveDataAll operations:

  • Do not use the TurboIntegrator function SaveDataAll. Instead enable Cube Logging for the import cubes.
  • If enabling Cube Logging for the import cubes cannot be done for performance reasons, within the TM1 application there should be only one process calling the TurboIntegrator function SaveDataAll. Use a stand-alone, single, distinct chore to execute the SaveDataAll operation.