This is my scenario: I have a logstream task with source endpoint SAP Application DB and target endpoint the log stream. Then another task with the source as the log stream and as target Redshift. SAP Application DB >> Log Stream >> Redshift I store the logs on the Logstream for a larger time that the time SAP source endpoint stores it on its server. So I have more control over it. And I use the __ct tables for change tracking. When a delete statement does not affect any row in the target table, the table is suspended. I can't avoid table suspension due to parallelizing apply changes on target. So, general error policy is not available to me and the task policy can only suspend table (I can't ignore the record).
My question is: When a table is suspended for example because of a delete statement, and I reload it. The table is full loaded even if the log stream task has not been reloaded? Usually a full load of the log stream task and then of the task replicating changes to redshift will reload the entire table, but it is needed? If I reload the table suspended, no rows will be missing, it will be exactly equal to the source table and then star applying changes? Or do I need to reload also the losgtream task?
I can't test this on my current environment right now, that's why Im asking.
LS --> Target (Redshift) (FULL LOAD from direct source and changes from LS audit files)
If you have a table suspended in the Child\Replicate task then just reload the table in the Child\Replicate task is enough and no need to perform any activity on the Logstream task.
LS --> Target (Redshift) (FULL LOAD from direct source and changes from LS audit files)
If you have a table suspended in the Child\Replicate task then just reload the table in the Child\Replicate task is enough and no need to perform any activity on the Logstream task.
