Qlik and migratio to Db2 for z/os V13

[feal]

Good Morning

we are planning to migrate our Db2 for z/os data sharing group from V12 to V13: we will use Qlik Replicate November 2023 SR1 version.

Some application related  tables (and also SYSIBM:SYSTABLES catalog table ) have DATA CAPTURE CHANGES attribute.

From our analysis, it could be  advisable to stop all QLIK CDC tasks with impacted Endpoint DB2 for z/os  during migration Db2 CATMAIN phase and restart it after that operation

IF no other DDL will be  performed in the meantime on CDC enabled objects , is it possible to restart stopped CDC tasks  with “resume processing” without problems ?

Or is mandatory to  restart them with “reload target” ?

Another question . if for any reason , we might be forced to execute this scenario

1. Stop Qlik task task1 reading <table> 
2. ALTER TABLE <table> DATA CAPTURE NONE; COMMIT;
3. ALTER TABLE <table> DATA CAPTURE CHANGES;COMMIT;

           Qlik task1  must  be restarted in “reload target” ?

Let me know

regards

[john_wang]

Hello @feal ,

Thanks for reaching out to Qlik Community!

First of all, the Replicate tasks should be stopped completely during the DB2 upgrade as some system tables will be not available for Qlik Replicate, this will lead lock errors etc.

Regarding your questions:

---

IF no other DDL will be  performed in the meantime on CDC enabled objects , is it possible to restart stopped CDC tasks  with “resume processing” without problems ?

Or is mandatory to  restart them with “reload target” ?

---

During the DB2z system upgrade, rich information are recorded into the DB2 transaction log, they are probably are DDL and maybe DML. These information are not interested by Qlik Replicate tasks.

“resume processing” means Qlik Replicate startup again to capture changes from the latest broken point (which is before the DB2z upgrade), however the above DDL/DML are not interested at all, it take long time to analyze the BSDS and then discard the change events, this is not meaningful.

We may startup task by timestamp. For example the DB2 upgrade done and it's ready for the company applications access from 2:00AM, we may startup Replicate task from 2:00AM (a few minutes gaps ahead is much better, eg from 1:55AM). A sample:

Another question . if for any reason , we might be forced to execute this scenario

1. Stop Qlik task task1 reading <table> 
2. ALTER TABLE <table> DATA CAPTURE NONE; COMMIT;
3. ALTER TABLE <table> DATA CAPTURE CHANGES;COMMIT;

           Qlik task1  must  be restarted in “reload target” ?

---

That depends, not very sure what operations done between step 2 and 3. in general if the BSDS is available still, and the table structure was not changed, then no need to reload.

Together, we strongly suggest you conduct sanity tests on lower env (DEV/QA/TEST) prior to the PROD system upgrade. 

Hope this helps.

John.

[DesmondWOO · Accepted solution]

Hi @feal ,

If you execute "ALTER TABLE <table> DATA CAPTURE NONE;", DB2 only writes out partial before-image in log records. So if there are some changes made to the table before running the step 3: "ALTER TABLE <table> DATA CAPTURE CHANGES;", I would recommend to reload.

Regards,
Desmond

[feal]

Ok

Thank you

[feal]

Hi Desmond

thank you for your answer.

If we have a  Qlik CDC task (Full Load + CDC) with many tables and only a few of this need to be altered with DATA CAPTURE NONE and eventually with ALTER TABLE  DATA CAPTURE CHANGES;

have I to peform a "Reload Target" at task level or can I execute a reload at table level selecting impacted tables only instead  ?

However QLIK CDC task will be stopped in the middle of these ALTERs .

Let me know

regards

Alessandro

[DesmondWOO]

Hi @feal ,

Yes. You can reload a single table. Please find the steps below:
1. Click on the table name.
2. Click the Reload icon.

Regards,
Desmond