Database Administrator's Guide

Checkpoint Requirements

FairCom DB periodically writes checkpoints to the transaction logs. Automatic recovery, rollback, and forward roll use the most recent checkpoint listed in the transaction start files as the starting point. This section explains the conditions that a checkpoint must meet to be used for these operations.

Forward Roll

A forward roll can only be started from a checkpoint that is logged when all of the following conditions are true:

1. No transactions are active.
2. No abort node list entries exist (except if using the ctrdmp utility and the forward roll starts from the begin dump checkpoint, in which case it is allowed).
3. No index buffers contain unflushed updates for committed transactions.
4. No data cache pages contain unflushed updates for committed transactions.

Due to these requirements, there is no guarantee that a checkpoint logged by calling CTCHKPNT() can be used as the starting point for a forward roll. If a forward roll is attempted from a checkpoint that does not meet these requirements, the forward roll fails with error 510 (RFCK_ERR, "active checkpoint at start of forward roll").

Three options are available for generating a checkpoint that can be guaranteed to be usable for a forward roll operation:

1. Perform a dynamic dump: This is probably the most commonly-used option to provide a starting point for a forward roll operation. The dynamic dump achieves a quiet transaction state and flushes all updated index buffers and data cache pages for transaction-controlled files. Then it writes a "begin dump" checkpoint to the transaction logs and allows transaction activity to resume. The dynamic dump writes the specified data and index files to the dump stream file, and then it writes an "end dump" checkpoint and copies the transaction logs (the logs containing these two checkpoints and all logs between these two logs) to the dump stream file. When the ctrdmp utility is run, it reads the data and index files from the dump stream file and recovers them to their state as of the begin dump checkpoint. If you include the !FORWARD_ROLL option in the dump restore script, ctrdmp creates a start file that points to the begin dump checkpoint, which can be renamed from an FCA extension to FCS to serve as the starting point for a forward roll.
2. Call ctQUIET(): Call ctQUIET() with a mode that ensures that the forward roll transaction state requirements are met. For example, use ctQTblockALL | ctQTflushAllFiles. While the server is quiesced, make a copy of the data files, index files, and transaction logs. The logs will contain a checkpoint that can be used to roll forward.
3. Shut down FairCom Server cleanly: Shut down FairCom Server cleanly so that all clients disconnect and all files are closed, and FairCom Server writes a clean final checkpoint to the transaction log. The message "Perform system checkpoint" in CTSTATUS.FCS indicates that the final checkpoint was written. For example:

   Wed Oct 5 10:04:01 2016

   - User# 00021 Server shutdown initiated

   Wed Oct 5 10:04:03 2016

   - User# 00021 Communications terminated

   Wed Oct 5 10:04:03 2016

   - User# 00021 Perform system checkpoint

   Wed Oct 5 10:04:03 2016

   - User# 00021 Server shutdown completed

A final checkpoint (logged at a clean server shutdown) should also have the required attributes. If a checkpoint does not conform to the conditions listed above, a forward roll beginning at such a checkpoint will fail with RFCK_ERR (510).

Rollback

Rollback can be started from any checkpoint. Starting with a point-in-time copy of the data files, index files, and transaction logs (acquired by using dynamic dump or ctQUIET() for example), rollback begins with the most recent checkpoint listed in the transaction start files. First, automatic recovery is performed to bring the files up to the state of the last committed transaction in the transaction logs, and then rollback undoes operations back to the requested point-in-time.

Calling CTCHKPNT

Although rollback can use any checkpoint, the checkpoint requirements for forward roll mean that a call to CTCHKPNT() is not guaranteed to be usable for forward roll. Note that each time a checkpoint is logged, the transaction start files are updated, so only the two most recent checkpoints will be listed in the two start files. The start files are used to provide the starting checkpoint position to forward roll and rollback. By calling CTCHKPNT() you are simply updating the start files more frequently. The two start files will never refer to more than two checkpoints at a time, and FairCom DB automatically writes checkpoints to the transaction logs periodically (typically at least three checkpoints per log).

Also remember that a forward roll or rollback requires more than just a starting checkpoint: the state of the data and index files must correspond to the current state of the transaction logs and the position of the starting checkpoint. To roll forward or back, you will need to have saved a point-in-time copy of the data files, index files, and transaction logs. Unless you save off this complete set of files when you call CTCHKPNT(), that checkpoint will not be useful in rolling forward or rolling back.