Skip to main content
Announcements
Have questions about Qlik Connect? Join us live on April 10th, at 11 AM ET: SIGN UP NOW
cancel
Showing results for 
Search instead for 
Did you mean: 
Zenith_Ian
Contributor II
Contributor II

replicate not managing to identify changes on OCI database

i  have managed to get the encryption keys to be accepted and we can connect to the source database (pluggable DB) to load in the records successfully to a target server, but when it comes to identifying changes i am hitting a new challenge  the message is 

Cannot connect to server ''(user '', Redo Thread 1, OCIthread 0) [1020414] (oradcdc_io.c:733)

i have added a more detailed set of log entries as attachment but am wondering if this is somehow connecting to the container database, rather than the pluggable database (where the source data is), and if so - would i then need to create an attunity user (ARUSER) on the container DB as well to match what is set up on PDB ??

attached are 2 screenshots of connection setup as reference

Labels (1)
1 Reply
Heinvandenheuvel
Specialist II
Specialist II

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,