Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved


Chapter 4 Understanding Checkpoint Processing : Checkpoint Processing

Checkpoint Processing
What is a TIBCO Object Service Broker Checkpoint?
A TIBCO Object Service Broker checkpoint is the process that synchronizes the committed transactions held in the redolog and the affected pages held in the resident page manager buffers with journals and the physical Pagestore.
When is a Checkpoint Created?
 
System administrator action
The number of minutes elapsed since the last checkpoint reaches the limit set in the CHPTINTERVAL Data Object Broker parameter.
Activity on the database
The number of changed pages reaches the limit set in the CHPAGELIMIT Data Object Broker parameter.
The number of commits issued from Execution Environments connected to this Data Object Broker reaches the limit set in the CHTRANLIMIT Data Object Broker parameter.
Steps Performed by the Checkpoint Process
There are three major steps performed by the checkpoint process.
1.
The checkpoint process compresses all affected data pages in the resident page manager by removing the part of each page that does not contain data.
2.
The process calculates how much space is required to write the checkpoint to the active journal.
3.
The process checks to see if the active journal has enough space to hold the checkpoint, and finds one of the following conditions:
Refer to the following sections for more information.
Active Journal has Sufficient Space for Checkpoint
When the active journal has sufficient space to hold the checkpoint, the following occurs:
1.
2.
3.
4.
The journal pages written out in the checkpoint are now available for use by the continuous backup process. They are no longer considered to be part of the cached portion of the journal.
Active Journal has Insufficient Space for Checkpoint
When the active journal does not have sufficient space to hold the checkpoint, the following occurs:
1.
The journal is off-loaded to a spin file. The checkpoint process starts the spin01 or spin02 batch file/script, depending on which journal is active.
2.
3.
The number of spin files is checked against the SPINLIM environment variable to determine if a merge of the spin files is required.
4.
If a merge is required, the checkpoint process starts the spin03 batch file/script to merge all existing spin files into a master journal accumulation file (spinout.000).
5.
Only one checkpoint can be in progress at a time. If a segment is being varied offline while a checkpoint is in progress, its state is internally adjusted to indicate that it is not available for transactions, but it is actually put offline only after the next checkpoint (which propagates all related changes) is finished.
If a journal spin is forced during a checkpoint, it is also delayed until the checkpoint in progress is finished. The request for the checkpoint is ignored if the checkpoint is already in progress.
Completing Pending Transactions
At system startup, the active journal is checked to see if the last checkpoint completed. If it did not complete, the checkpoint is restarted using the cached portion of the journal. This portion contains the changed pages that were not physically written to the Pagestore. In addition, the redolog is checked and used to complete any pending transactions.
Checkpoint Process Illustration

Copyright © TIBCO Software Inc. All Rights Reserved
Copyright © TIBCO Software Inc. All Rights Reserved