How to avoid "Changes are not being captured" when Log Stream Staging task encounter error?
We use the replicate workflow: One Log Stream Staging task capture to log stream staging folder, then two task replicate to target database. When there is some maintenance in source db or some network issues, Log Stream Staging task encounter error, then two replicate will encounter "Changes are not being captured" . Then replicate will loss some data.
We need to reload all tables.
How to avoid "Changes are not being captured"?
By the way, the source db is Oracle active standby.
The warningchanges are not being capturedmay be caused by 2 things:
Reason 1
Valid scenario, where parent/log stream tasks actually did not receive any data from the source, for example, if the changes currently happening on the source are not related to the tables in the task.
Reason 2
Error scenario, where parent/log stream task encountered an issue and parent/log stream task continues to run without throwing an error. Check the staging task if there is an error during the same time frame when you received the warning on the replication task.
For the second scenario, please open a support case for assistance.
I'm seeking some clarification on Reason 1. I'll set up a simplified scenario to see if I'm understanding fully or not. Your feedback is appreciated.
Oracle Source: TableA, TableB, TableC Log Stream Task: TableB, TableC Running Replication Task 1: TableB Running with Apply Changes on Replication Task 2: TableC Running with Apply Changes on
Interpretation: TableA has a row inserted. The Log Stream task notices source activity and looks to see if any actions are required. During this time, the Log Stream's source incoming transaction counter is incremented by one. This notifies Replication Task 1 and 2 that a source change transaction is pending and their counters are increased by one. Once the source system commits its change the Log stream determines that the change is not of interest, decrements the incoming changes counter by one. The two replication tasks then record a warning that "Changes are not being processed" and decrement their incoming change transaction counters by one.
Note: Understanding that the timing of interactions between the Log Stream and Replication task may not be illustrated accurately.
I guess my questions are:
(1) Why log a Warning in the Replication task instead of the Log Stream task? (2) Why have the message "Changes are not being processed" that gives an Admin heart failure? An Informational log entry like "Source system changes unrelated to this task were not processed" would be more meaningful and less frightening. (3) Does this Warning message only occur when using Log Streams/Replication task combinations?
