Skip to main content
Announcements
Qlik Introduces a New Era of Visualization! READ ALL ABOUT IT
cancel
Showing results for 
Search instead for 
Did you mean: 
AKV0524
Contributor III
Contributor III

Qlik Replicate CDC job failed after SAP Application Upgrade

Hi Team,

There was an SAP Application upgrade happened and which took 40 hours and backend database is Oracle. Log retention policy is 12 hours at database side. After SAP upgrade when we resume our Qlik replicate CDC it got failed with error log redo sequence doesn't exits.

There is an option to resume the task using advance run option by giving timestamp but it is not correct because on the database side redo logs will be there only for 12 hours and SAP Application took 40 hours. it may be possible when we resume the CDC job it will miss any prior to 12 hours logs.

As Qlik Replicate task didn't resume so we had perform full reload again and it took around 3 days because we are pulling total 600+ tables and some tables are very huge.

There is one option i find by changing the retention policy to 48 hrs temporarily before the such outage start to avoid the complete reloads.

Is there any way we can avoid doing full reload again when such upgrade happened on source side.

 

Thanks

Amit

Labels (2)
1 Solution

Accepted Solutions
Dana_Baldwin
Support
Support

Hi @AKV0524 

The only way to avoid a full load is to increase the redo/archivelog retention policy before such an extended downtime, to ensure that no logs are purged during the downtime. Replicate has no other means of capturing the source changes to process to the target without the redo/archivelog files being available to read. That is the only way you will be able to do a normal resume of the tasks.

Starting from timestamp skipping over the downtime may introduce risk if there are changes made during this time that need to be pushed to the target, either DML or DDL.

Thanks,

Dana

View solution in original post

2 Replies
Dana_Baldwin
Support
Support

Hi @AKV0524 

The only way to avoid a full load is to increase the redo/archivelog retention policy before such an extended downtime, to ensure that no logs are purged during the downtime. Replicate has no other means of capturing the source changes to process to the target without the redo/archivelog files being available to read. That is the only way you will be able to do a normal resume of the tasks.

Starting from timestamp skipping over the downtime may introduce risk if there are changes made during this time that need to be pushed to the target, either DML or DDL.

Thanks,

Dana

AKV0524
Contributor III
Contributor III
Author

Hi Dana,

 

Thanks for suggestion, so increasing the log retention policy is the only correct resolution for this type of issue.

Going future will implement this when such of outage happen

 

Thanks

Amit