CDC Guide for Linux, UNIX, and Windows

10.5
- 10.5.6
- 10.5.5
- 10.5.4
- 10.5.3
- 10.5.2
- 10.5.1
- 10.4.1
- 10.4.0 HotFix 1
- 10.4.0

Back Next

Checkpointing In-flight Transactions

Checkpointing periodically persists the state of in-flight transactions to disk or tables.

If a PowerExchange Express capture process stops and is then warm started, Express CDC uses the checkpoint information to resume the processing of outstanding transactions from the last recorded checkpoint. By using a checkpoint, Express CDC avoids time-consuming reprocessing of large amounts of redo log to rebuild the state of all transactions that were active when the process stopped.

You can store state information for in-flight transactions in file-system files or in three Oracle tables. For file-based storage, ensure that the user ID under which Express CDC runs is granted the appropriate permissions to create the files. For table-based storage, ensure that the database user has the appropriate permissions to create and update the tables. You can manually create the tables or allow Express CDC to automatically create them. On first initialization of a CDC process after checkpointing is enabled, Express CDC automatically creates the tables if they do not already exist. If you need to manually create the tables, you can use the DDL statements that documented here: DDL Statements for Manually Creating State Tables for Checkpointing.

To configure checkpointing, you must specify the CHECKPOINT statement and STATESTORAGE statement in the PowerExchange Express CDC configuration file. If you want to encrypt the spill files that contain checkpointed data, you can optionally set the SPILLENCRYPTPASS or SPILLENCRYPTEPASS parameter in the OPTIONS statement.

Before you begin configuring checkpointing, review the following usage considerations, which might affect your configuration choices:

Checkpointing occurs only for in-flight translations. Transactions cannot be checkpointed if they contain incomplete operations.

DPL transactions are not checkpointed.

All completed operations in a transaction must be spilled to disk before they can be checkpointed.

Checkpointing is incompatible with and replaces the AGEOUT parameter in the OPTIONS statement. Unlike the AGEOUT parameter, checkpointing guarantees lossless restarts.

Transactions older than the age specified by the COMPLETEDEVENTSAGE parameter can be forced to spill to disk to facilitate checkpointing.

Transaction age is calculated as the difference between the transaction start time and the time of the last event that the transaction manager processed.

You can disable the force spilling of very large transactions by using the MAXCHKPTSIZE parameter in the CHECKPOINT statement. This strategy might help reduce resource usage during large batch cycles.

If resources become restricted, the transactions might still be spilled to disk, in which case they can be checkpointed then.

Checkpoints are not written if they do not progress the restart point. A transaction that has data on stack will block checkpointing until the stack is cleared.

Checkpoints are not taken until the PowerExchange Consumer API (CAPI) progresses the restart point beyond the checkpoint restart point. On an idle system, Informatica recommends that you set the COMPLETEDEVENTSAGE parameter in the CHECKPOINT statement to the same value as in the RSTRADV parameter in OPTIONS statement.

To avoid the overhead of maintaining LOB data in the database, Express CDC always copies spill files to disk during checkpoint processing.

If you configure frequent checkpointing or decrease the COMPLETEDEVENTSAGE value, performance might be degraded and the storage required for spill files might increase.

PowerExchange Express CDC notifies the PowerExchange Logger when a checkpoint event occurs. The next read request that Express CDC receives serves as an acknowledgement from the PowerExchange Logger and triggers cleanup processing of expired checkpoint data.

When a restart occurs, the checkpoint data is loaded and validated. The most recent, valid checkpoint with a restart point that is less than or equal to the PowerExchange Logger restart point is used to rebuild the state of all outstanding transactions at the time of that checkpoint. The actual restart point is substituted with the highest SCN of all transactions checkpointed.

If a suitable, valid checkpoint is not available for a restart, the restart point reverts to the restart point of the PowerExchange Logger.

When you cold start the PowerExchange Logger, the checkpoint data is cleared.

When determining whether to encrypt the spill files, consider that checkpointing tends to increase the number and retention of spill files.

Express CDC Considerations

DDL Statements for Manually Creating State Tables for Checkpointing

Download Guide

Watch

Comments

Communities

Knowledge Base

Success Portal