I have a DB2 z/OS source table, that is maintained by a LOAD job. There are multiple Steps in the Job. First it does a LOAD REPLACE and after that there are several LOAD RESUME steps. None of this is by default captured by the Log Stream task that is reading the source.
However these changes should be visible to Qlik Replicate. My expectation would be to have a reload of the table triggered after the LOAD REPLACE finished and the LOAD RESUME could be handled as mass inserts.
Yes, Qlik Replicate can detect these actions. By default, the affected table will be suspended. More details are available in the documentation under “Handling actions resulting in subtype 83.”
If you have suggestions or ideas for improving this behavior, please submit them through the Qlik Ideation.
Regards, Desmond
Help users find answers! Do not forget to mark a solution that worked for you! If already marked, give it a thumbs up!
Thank you for your answer. Just for the record I am still using qlik replicate 2024.11 but the documentation seems to be the same.
Actually I do not see the Warning in my log even though I saw that a LOAD did run on DB2 side. While I checked I saw that I have the set the internal parameter for the DB2 Endpoint to ifi306LogParsing=ERRORS and ifi306MessageLevel=1. I assume this skips these warning messages in my log. Do I have to chnage these parameters to get the Logs?
In our Production system, we are currently facing this scenario where LOAD RESUME YES and LOAD RESUME REPLACE activities are scheduled and executed from the source side for almost all tables on a daily basis. Since these utilities are happening every day at the source level, as per the current default behavior (IGNORE), this could potentially lead to data gaps unless a table reload is performed after each occurrence.
Given this, we would like to clarify: 1.Since these utilities are executed daily from source, does it mean we are potentially losing data every day unless manual reload is performed? 2.From an operational standpoint, performing daily reloads for multiple production tables is not feasible. 3.Is there any alternative recommended approach to handle frequent LOAD RESUME / REPLACE activities other than monitoring + reload? 4.If we enable the internal parameter db2LoadOption = SUSPEND, we understand it will only help in alerting (via table suspension), but it will not automatically capture missed data, and reload will still be required. Please confirm.
5. If we suspend this table, we need to perform resume or advance resume from the suspend timestamp. Can we get those LOAD RESUME and LOAD REPLACE records. If not what we need to do for avoide this data missing
From my understanding, both LOAD REPLACE and LOAD RESUME insert data without generating standard DML log records for each row. These bulk load operations bypass normal transactional logging, which means Qlik Replicate cannot capture them as incremental changes. That is why Qlik Replicate issues a warning and, by default, suspends the affected table. After such a load, a full refresh of the target is typically required before CDC can resume capturing ongoing changes.
Regards, Desmond
Help users find answers! Do not forget to mark a solution that worked for you! If already marked, give it a thumbs up!
We have validated LOAD RESUME and LOAD REPLACE in our lower environment. During our testing, we observed that we are not able to capture the data in the target Snowflake.
When using SHARELEVEL CHANGE with LOG YES+LOAD RESUME, the changes are being captured successfully by Replicate. LOAD RESUME + SHARELEVEL CHANGE + LOG YES → Changes captured in Target
For the LOAD REPLACE based on the below Qlik article Does the DB2 Native Endpoint capture changes when ... - Qlik Community - 1730439 Alternative for LOAD REPLACE → TRUNCATE + LOAD RESUME + SHARELEVEL CHANGE + LOG YES → Changes captured in Target
Could you please validate this behavior and confirm whether this approach is fully supported to use in Production? We would like to ensure there are no downstream risks or inconsistencies if we adopt this as the standard process.
When using SHARELEVEL CHANGE with LOG YES+LOAD RESUME, the changes are being captured successfully by Replicate. LOAD RESUME + SHARELEVEL CHANGE + LOG YES → Changes captured in Target
You are correct — this is expected behavior and is documented in the User Guide (see: All variations except SHRLEVEL CHANGE). When SHRLEVEL CHANGE is used together with LOG YES and LOAD RESUME, the LOAD utility records the loaded rows in the log as INSERT operations. As a result, Qlik Replicate captures these changes and applies them to the target.
Please note: We assume that the data loaded using the LOAD utility does not conflict with the existing data. If there are conflicts between the loaded data and the existing data, such as primary key violations, that would be a separate topic.
Hope this helps.
John.
Help users find answers! Do not forget to mark a solution that worked for you! If already marked, give it a thumbs up!
Could you please validate this behavior and confirm whether this approach is fully supported to use in Production? We would like to ensure there are no downstream risks or inconsistencies if we adopt this as the standard process.
