Replicate stop and resume task period

[guilherme-matte]

Hello team

I would like to know a bit more on how to know how long I can stop a task and resume it without the necessity to reload it whenever using CDC.

I've asked something similar already, but would like to know more on how to estimate it considering that server, database, versions and all other information is known. 

Is this generally calculated? Perhaps trial and error or might exist a rule of thumb that would help estimating it?

Kind regards!

[kng]

Hello team,

Please do check on the below article by our TSE which gives you more information on time taken to stop and start the task.

https://community.qlik.com/t5/Official-Support-Articles/Qlik-Replicate-Task-Stop-timeout-occurred/ta...

In general you can resume the task once it has been stopped

If the schema or a filter was changed after the task stopped, the task should be reloaded as opposed to resumed.

Please find more information regarding the different run options in the link below:
Phttps://help.qlik.com/en-US/replicate/May2022/Content/Global_Common/Content/SharedEMReplicate/Tasks%20at%20Runtime/monitor_run_buttons.htm#Using%20the%20Run%20button%20options

In general you can resume the task once it has been stopped

Let me know if this helps or this is what you are looking for

Regards,
Shivananda

[Heinvandenheuvel · Accepted solution]

For a task to be able to resume (cdc) after a stop all that should be needed is access to to each and every transaction log since the stop time, archived or live. The DB type, and possibly customer chosen backup strategy defines how this plays out MS SQL: - T-backups + current Tlog  + backupmediafamily + backupset information, Oracle ARCH log + REDO + V$ARCHIVED_LOG information, and so on. Often a log backup can be provided 'just in time. I believe that for some databases Replicate has a hard time converting the last transaction (LSN, SCN,...) indicator to a starting point. You can try Run Advanced - Tables already loaded - Start by timestamp in those cases. 

Now whether you 'can' do it, does not necessarily mean that you 'should' do it. When looking at days of redo to be applied adding up to many many gigabytes of data, approaching the source DB size perhaps, it may be more efficient to just reload.

My totally non-scientific guess is that it is 10 times more total work (source, replicate, target) per row to update it to the current state (deleted?) than it is to re-load (not doing anything for a deleted row, doing just 1 insert instead of insert + multiple update for a row creates, and updated multiple times, during the task-down period).

Be sure to have access to the last (initial?) reload time and approx source DB size at that reload time to make a sound decision.

Hein.