Checkpointing

Checkpoints are used to keep a snapshot of the database. If a system failure occurs, TimesTen can use a checkpoint file and transaction log files to restore a database to its last transactionally consistent state.

Only the data that has changed since the last checkpoint operation is written to the checkpoint file. The checkpoint operation scans the database for blocks that have changed since the last checkpoint. It then updates the checkpoint file with the changes and removes any transaction log files that are no longer needed (those that have been declared as purgeable). See When Are Transaction Log Files Deleted?.

TimesTen provides two kinds of checkpoints:

• Non-Blocking Checkpoints

• Blocking Checkpoints

• Recovery From the Transaction Log and Checkpoint Files

TimesTen creates non-blocking checkpoints automatically.

For more information about checkpointing, see Checkpoint operations in the Oracle TimesTen In-Memory Database Operations Guide.

Non-Blocking Checkpoints

TimesTen initiates non-blocking checkpoints in the background automatically. Non-blocking checkpoints are also known as fuzzy checkpoints.

The frequency of these checkpoints can be adjusted by the application. Non-blocking checkpoints do not require any locks on the database, so multiple applications can asynchronously commit or roll back transactions on the same database while the checkpoint operation is in progress. See Setting and Managing Checkpoints in the Oracle TimesTen In-Memory Database Operations Guide.

Blocking Checkpoints

When using TimesTen Classic, an application can call the ttCkptBlocking built-in procedure to initiate a blocking checkpoint in order to construct a transaction-consistent checkpoint.

Blocking checkpoints acquire an exclusive database lock. While a blocking checkpoint operation is in progress, any other new transactions are put in a queue behind the checkpointing transaction. Thus, a long running transaction may cause other transactions to be held up. A long-running transaction could prevent a blocking checkpoint from acquiring the exclusive database lock, which could cause the checkpoint and all subsequent transactions to wait until the long-running transaction commits or rolls back (or the checkpoint request is canceled). No transaction log is needed to recover from a blocking checkpoint since the checkpoint record contains the information needed to recover.

See Setting and Managing Checkpoints in the Oracle TimesTen In-Memory Database Operations Guide.

Recovery From the Transaction Log and Checkpoint Files

During recovery, the latest checkpoint file is read into memory. All transactions that have been committed since the last checkpoint and whose log records are on the file system are rolled forward from the appropriate transaction log files.

Note that the transactions on the file system include all transactions that were committed durably as well as all transactions whose log records aged out of the in-memory transaction log buffer. Uncommitted or rolled-back transactions are not recovered.

• When using TimesTen Scaleout, there is a process to facilitate automatic recovery of the data from the checkpoint and transaction log files. See Recovering From Failure in the Oracle TimesTen In-Memory Database Scaleout User's Guide.

• When using TimesTen Classic, if a database becomes invalid or corrupted by a system or process failure, every connection to the database is invalidated. When an application reconnects to a failed database, the subdaemon allocates a new memory region for the database and recovers its data from the checkpoint and transaction log files.

For applications that require uninterrupted access to TimesTen Classic data in the event of failures, see Data Replication Within TimesTen Classic.