![]() |
Copyright © TIBCO Software Inc. All Rights Reserved |
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.
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.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.The process calculates how much space is required to write the checkpoint to the active journal.The process checks to see if the active journal has enough space to hold the checkpoint, and finds one of the following conditions: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.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.
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).
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.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.
![]() |
Copyright © TIBCO Software Inc. All Rights Reserved |