Propagation Schedule Stuck in Pending State

The next issues to be examined are the apply related issues as well as their possible solutions.

Apply Issues

Is the Apply Process Encountering Contention?

The Apply process has multiple Apply servers. Apply servers apply DML and DDL changes to database objects at a destination database. The parallelism Apply process parameter specifies the number of Apply servers that may concurrently apply transactions. For example, if parallelism is set to four, an Apply process uses a total of four Apply servers.

An Apply server can encounter contention when it must wait for a resource that is being used by another session. Contention may result from logical dependencies. For example, when an Apply server tries to apply a change to a row that a user has locked, the Apply server must wait for the user. Contention also may result from physical dependencies. For example, an Interested Transaction List (ITL) contention results when two transactions that are being applied, which may not be logically dependent, are trying to lock the same block on disk. This kind of contention can be monitored by looking at the waiting states it generates. When there is a wait, Apply process writes to the alert log file and an Apply process file. This information helps to pinpoint the exact problem area.

Waiting for an Event That is Not Related to Another Session

An example of an event that is not related to another session is a log file sync event.  This is when redo information must be flushed because of a commit or rollback.