This procedure performs a blocking checkpoint operation. A checkpoint operation saves the in-memory image of a database to files, known as checkpoint files. This checkpoint requires exclusive access to the database, and so may cause other applications to be blocked from the database while the checkpoint is in progress.

To perform a nonblocking checkpoint, use the ttCkpt procedure.

No log is needed to recover when blocking checkpoints are used. TimesTen uses the log, if present, to bring the database up to date after recovery.

Required Privilege

This procedure requires the ADMIN privilege.

Usage in TimesTen Scaleout and TimesTen Classic

This procedure is supported in TimesTen Classic but not supported in TimesTen Scaleout.

Related Views

This procedure has no related views.


ttCkptBlocking([timeout], [retries])


ttCkptBlocking has these optional parameters:

Parameter Type Description



The time (in seconds) that ttCkptBlocking should wait to get a database lock before timing out. The value of timeout can be between 0 and one million, inclusively. If not specified, the checkpoint never times out.



The number of times that ttCkptBlocking should attempt to get a database lock, if timeouts occur. The value of retries can be between 0 and 10, inclusive. If not specified, defaults to zero.

Result Set

ttCkptBlocking returns no results.


CALL ttCkptBlocking();
CALL ttCkptBlocking(1,10);


Because the checkpoint takes place at commit or rollback, the call to ttCkptBlocking always succeed. At commit or rollback, any problems with the checkpoint operation, such as a lack of disk space or a timeout, result in a warning being returned to the application. Checkpoint problems are not reflected as errors, since the commit or rollback of which they are a part can succeed even if the checkpoint fails. Warnings are reflected in ODBC with the return code SQL_SUCCESS_WITH_INFO.

For more information on checkpoints, see Transaction Management in Oracle TimesTen In-Memory Database Operations Guide.