Checkpointing guidelines

The aforementioned minimum time span between actually issuing checkpoints (see Controlling-checkpoint-frequency) can be modified during the QUICKSTART installation process. The assigned value should be set to include consideration of the following:

• Number of concurrent users of the same data,
• Actual numbers of and data usage habits of online and batch users,
• Amount of time your site can afford to dedicate to the execution of any necessary data backouts and subsequent re-executions of those transactions which were “lost” since the last checkpoint.

Recommendations

The following Checkpoint Frequency is recommended:

Scenario	Suggested Initial Checkpoint Frequency
Application does not perform database updates	every 5 minutes
Application updates database within batch window	every 30-60 seconds
Application updates database during online hours	every 5 seconds

When should checkpoints be issued

To ensure restartability, application programs should be designed to incorporate the Logical Unit of Work approach. This implies that invocations of the Checkpoint Routine should be requested at the “end” of a Logical Unit of Work. The application program can more easily resume execution during a restart if there is an opportunity to enter the processing at the “top” of a Logical Unit of Work loop. See Application-requirements-for-restartability for additional information regarding application program design to accommodate the Logical Unit of Work.

Checkpointing based on resource utilization

Some QUICKSTART customers have independently developed routines which measure the resource utilization levels of the application program's processing environment and notify the application program of the need to issue a checkpoint. QUICKSTART can best co-exist with such measurement routines if the application programs issue only “Forced checkpoint” requests to QUICKSTART, but only at the recommendation of such a measurement routine.