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: 
feal
Contributor III
Contributor III

Effects of a Db2 for z/os V13 UTS PBG to PBR2 conversion of a CDC Enables table

Good morning

We are planning to migrate Db2 for z/Os from V12 to V13 and eventually to migrate from UTS PBG to UTS PBR relative numbering (PBR2) some CDC enabled tables read from Qlik tasks

We noticed that this link on IBM

Converting tables from growth-based to range-based partitions - IBM Documentation

There is this point

  • If the table to be converted is defined with DATA CAPTURE CHANGES, and the data sets of the table space are defined, the number of partitions for the range-partitioning scheme must not be less than the maximum number of partitions for the PBG table space. This requirement avoids a situation where IFCID 0306 is unable to decompress log records associated with deleted partitions because the compression dictionaries no longer exist.

----

 

 

And this point

---

If the table to be converted is defined with DATA CAPTURE CHANGES and subscribed to data replication, consider taking one of following actions before starting the conversion:

  1. Use an ALTER TABLE statement with DATA CAPTURE NONE clause, so that the number of PBR partitions is no longer enforced to be equal or greater than the maximum number of partitions for the PBG.

 

I suppose that, after successfully performed UTS PBG->PBR2 conversion, ALTER TABLE … DATA CAPTURE CHANGES could be eventually set  but what can I do with Qlik impacted tasks ?  Reload target or other needed  actions at task/table definition ?

What is Qlik best practise  or suggestions to manage this situation ?

Let me know

regards

Labels (1)
4 Replies
SushilKumar
Support
Support

Hello @feal 

1.Request you to check Qlik help document for any limitation around using mentioned partition way or Strategies. 

2. If you made any Chages to Table Structure and which change the metadata, then it's always recommended to do the Full load so that QR also have the latest info in term of metadata data as Qlik replicate locate the columns or view on the basis of metadata Collected from Source  

Regards,

Sushil Kumar

 

feal
Contributor III
Contributor III
Author

Hi Sushil

 

thanks fot your answer : i check Qlik documentation but i found no information specific to UTS PBR handling (maybe only this deadls about partitions but there is no direct reference to PBR : Parallel Load | Qlik Enterprise Manager Help)

Have you additional info for this scenario ?

If no info , i suppose that the current  procedure for managing PBG->PBR of <table> migration could be this (if Qlik task is defined Full Load+CDC)

- ALTER TABLE <table> DATA CAPTURE NONE;

- change table form PBG->PBR

-- ALTER TABLE <table> DATA CAPTURE CHANGES;

- Reload table <table>

 

Can you confirm ? Or is is mandatory to perform a Full Load at task level , even if in the task may be other tables not impacted  ?

If Qlik CDC task is drfined CDC only i suppose that the last istruction will be unsuspend, is this correct ?

 

SushilKumar
Support
Support

Hello @feal 

This is motioned in the Qlik Help Doc 

Table segmentation by partitions or sub-partitions is not supported with the IBM DB2 for z/OS source endpoint.

Parallel Load | Qlik Replicate Help

Regards,

Sushil Kumar

feal
Contributor III
Contributor III
Author

Hello

 

the limitation you cited means that ; in the case of FULL LOAD, table will be loaded once entirely  (and all partitions in a single pass) and not its partitions in parallel, correct ?

 

Let me know

regards

A. Ferrario