Thanks for the details. What exact version? This issue is rather odd as clearly the task has connected to the source a couple of times already. Therefor the connect string is useable and so on.
While the Redo is managed by the CDB (containter DB), the task never needs to mention that. It needs only provide the PDB (Pluggable) info as you did. Fine.
The log text indicates "The connection to the source database reestablished ", but did it really, in the right place? Does the task continue or stop? I guess since you indicate not identifying changes it did not work as expect, but did it stop?
That error message "Cannot connect to server" ... oradcdc_io.c:733 is a message I've seen from ASM implementations, but you do not have that. The first double-single-quote is a null ASM connection string the second set of single quotes where supposed to contain the ASM Username, which here is not available/needed. At the very least this error message does not fit the context and was simply cloned from pre-existing ASM connection code path, at the worst Replicate ended up in the wrong (ASM) context.
Kindly submit a proper support case and perhaps point that out. Be sure to add the task JSON and the complete reptask_xxx.log.
Now why would the connection being create to open the binary log files fail when the same credentials worked before. There is a minor change it was a resource restriction on the source server. Maybe there is something in the LISTENER LOG on the source to help see what went wrong at the reported time (2023-01-12T13:13:21)?
The Service name provided is relatively long at 47 characters. Maye some component (OCI, TNS, Replicate) mishandled that? Can you try using a short 'nickname' perhaps using TNSnames?
Good luck!
Hein,
