Is the Redo File Missing?

exec DBMS_CAPTURE_ADM.ALTER_CAPTURE(capture_name => 'NYDATA1_CAPTURE', start_scn  =>  9794905, first_scn =>9794905);

Is the Capture process current?

In review, the redo scanning latency can be determined by reading the v$streams_capture view. How far behind the capture_message_create_time is with respect to current system date can be verified. This helps to understand the lag the system is experiencing.

Also, the difference between enqueue_time and enqueue_message_create_time of the v$streams_capture view can be used to determine the event queue latency for the Capture process.

Verify that the Capture Process is Enabled

A Capture process captures changes only when it is ENABLED. The DBA can check whether a Capture process is ENABLED, DISABLED, or ABORTED by querying the dba_capture data dictionary view.

Does Not Capture - Check Rules

The Capture process is up and running, but it fails to create any LCR events for propagation to destination. First, verify that the rules are properly defined. Rule Condition in dba_rules provides the full text of the rule. Ensure that the rule condition is valid. dba_streams_rules can also be queried to find out the rule condition and context.

The next issues to be examined are the related to Propagation.

Propagation Issues

Separate Queue in Case of Bi-directional Replication

When configuring bi-directional replication between two sites, use two queues at each site. To help minimize the spill over to disk, configure two queues at each site. Each site will have: