InfoSphere Data Replication for DB2 for z/OS V10.02.01 ... · PDF file© 2013 IBM...

© 2013 IBM Corporation1

InfoSphere Data Replication for DB2 for z/OS V10.02.01 (IIDR 10.2.1)

Q Replication Migration, Coexistence, Fallback considerations

July 2015

Jayanti MahapatraIBM Data [email protected]

mailto:[email protected]


InfoSphere Data Replication for DB2 for z/OS V10.02.01

● Program Number update: 5655-DRP● Q and SQL Replication new FMIDs:

– HAAWA21 - Q and SQL Replication Common Base– JAAWA24 - Q Capture and EP– JAAWA25 - Q Apply– JAAWA26 - SQL Replication

Note: Please get Replication 10.2.1 APAR PI42263

Require DB2 V10 APAR PI36900 and PI42170


● Version-independent names – no change across versions:– ASNQCAP (old name: ASNQC101)

– ASNQAPP (old name: ASNQA101)

– ASNMON (old name: ASNAM101)

– ASNTDIFF (old name: ASNRD101)

– ASNQEXP (old name: ASNQE101)

● Need to bind - SASNSAMP(ASNQBNDL)

Need to add plan name to the IBMQREP_IGNTRAN: INSERT INTO !ASH.IBMQREP_IGNTRAN (PLANNAME, IGNTRANTRC) VALUES ('ASNQAPP','N');

Plan Name Changes for V10.02.01


● ASNQCAP - Q Capture

● ASNQAPP - Q Apply

● ASNMON - Monitor

● ASNTRC - ASN trace

● ASNBPXB - BPX batch sample job

→ Many of the old samples have been removed.

SASNSAMP Job Name Changes for V10.02.01


IIDR 10.2.1 uses longer and different format LSNsQ and SQL Capture LSN format(prior to 1021) saves LSN in 10 byte format.

● 2 bytes hex zeros, 6 byte RBA/LRSN, 2 bytes for duplicate LSNs, data sharing and updates transformed to delete/insert pairs

– In data sharing the LSN will look like the following:

0000:CC02:8C7C:CBDB:0001

– In non Data Sharing:

0000:6C22:0150:0000:0000

IIDR 10.2.1 always saves and displays LSN values using a 16 byte format (includes some Replication-specific metadata) for all supported DB2 levels:

● 10 byte RBA/LRSN, 4 bytes hex zeros , 2 bytes for duplicate LSNs, data sharing and updates transformed to delete/insert pairs.

– In data sharing the LSN will look like the following:

00CC:028C:7CCB:DB00:0000:0000:0000:0001

– In non data sharing the LSN will look like the following: 0000:0000:0000:6C22:0150:0000:0000:0000


IIDR 10.2.1 uses longer and different format LSNs

The length all LSN values in 1021 must be 16

Some of the control table data also need to be migrated.

Q replication saves very few LSNs that needs to be migrated.

SQL Capture migration involves changing LSN values in many control tables and CD tables.

SQL Replication migration involves running a few scripts.


Recommended DB2 APARs● PM05503 - lifts restrictions for Alter Table Set Data Type when table is defined with change data capture.PM98429 -

Compression dictionary enhancements for replication.

● PM51663 and PM89162 - keeps data capture bit on during reorg of SYSIBM.SYSTABLESPACE, SYSIBM.SYSCOLUMNS, and SYSIBM.SYSTABLES

● PM90568 - IFI 306 LOG READ DBID/PSID FILTERING SUPPORT

● PM61324 - prevent ABEND04E for Qrep when NUMPARTS changed to smaller value

● PM84298 – Q Capture received RC00C90063 for an unavailable dictionary after migrating to V10 NFM.

● PM84864 - IFI306 READS RETURNS THE WRONG LOG RANGE. (HIPER)

● PI09978 - DB2 V11 IFI 306 RETURNS AN INVALID XID OFFSET IF THE BEGIN-UR LOG RECORD WAS WRITTEN BY A V10 DATA SHARING MEMBER

● PI36900 - IFI READ ABENDS0C4 PIC04 RC04 IN DSNIDLGR OFFSET2F6E DURING LOG RECORD DECOMPRESSION (DB2 V10)

● PI36052 - ABEND04E RC00C90101 IN DSNIFDCI ERQUAL 5123 AND MSGDSNJ113E GOT BY QREP AFTER A REORG OF A COMPRESSED TABLESPACE IN DB2 V11 CM

● PI41630 and PI42170 - SOME DB2 LOG RECORDS ARE NOT REPLICATED IN V11

● PI21358 - QREP MIGHT RETURN RC00C90064 IF THE DICTIONARY IS BUILT BY INSERT ON ANOTHER MEMBER.


Q Replication


• !CSH.IBMQREP_SENDQUEUES HEARTBEAT_INTERVAL unit changed to milli seconds

Migration job SASNSAMP(ASNQ1021) will change the unit:

HEARTBEAT_INTERVAL = HEARTBEAT_INTERVAL *1000;

• The LSN column values for !CSH.IBMQREP_COLVERSION and !CSH.IBMQREP_TABVERSION will be converted to support the new 16 byte LSN format

• Q Capture supports COMPATIBILITY=1001 or higher. So must migrate your Q Applies to 1001 in z and LUW before migrating Q Capture to 1021.

Some important Changes in SASNSAMP(ASNQ1021)


Migrating from arch_level 1001 to 1021

– Use migration scripts from 1001 to 1021(ASNQ1021)

– Migration script will alter add some new columns to existing control tables

– ARCH_LEVEL will be updated to 1021

– COMPATIBILITY must stay as 1001 if there are any LUW Q Apply for this Q Capture. The COMAPTIBITY can only be 1021 if all Applies for this Q Capture is in z/OS with QApply ARCH_LEVEL 1021 .

– Q Capture 1021 can be warm started using 1001 (APAR PM94614 or higher) restart message

– Need V10 APAR PM96954 or higher for easy fallback

– LUW Apply must be V10.1 FP4 or V10.5 FP4 for CCD targets

Note: Please get Replication 10.2.1 APAR PI42263

Migrating to V10.2.1 (arch_level 1021)


Q Capture ARCH_LEVEL 1021:

LUW Apply must be V10.1 FP4 or V10.5 FP5

IBMQREP_CAPPARMS COMPATIBILITY must be 1001

Restrictions:

RENAME column will not be supported

DROP column will not be supported

No option to bypass Alter column at target

Q Capture 1021 and Q Apply LUW


Migrating from arch_level 0907 to 1021 is supported

– Use migration scripts (ASNQMZ10) and the others below

Migrating from arch_level 100z to 1021

– Use migration scripts from 100z to 1001(ASNQ1001)


– Start Q Capture with lsn= or override_restartq=y option the first time you start Q Capture on 1021 (run asnqmfmt for the RESTARTQ to get these values.)

Migrating from arch_level 1001 to 1021


– Q Capture 1021 can be warm started using 1001 (APAR PM94614) or higher) restart message

– Pre PM94614, you have to use lsn= or override_restartq=y option the first time you start Q Capture on 1021

Migrating to V10.2.1 (arch_level 1021)


Migration Requirement for CCD tables (Q Replication 1021)

• Q Apply CCD targets IBMSNAP_COMMITSEQ and IBMSNAP_INTENTSEQ columns length must(*) be altered to VARCHAR(16), sample job SASNSAMP(ASNQCCDA)

• Alter CCD targets IBMSNAP_UOWID column length to VARCHAR(12) sample job SASNSAMP(ASNQCCDA)

• Optionally, Q Apply CCD targets IBMSNAP_COMMITSEQ and IBMSNAP_INTENTSEQ data migration – SASNSAMP(ASNQCCDD)

• Optionally, CCD targets IBMSNAP_UOWID data migration to the new format. Sample job SASNSAMP(ASNQCCDD)

→ CCD table length can be altered prior to going to 1021 (APAR PM94614 or higher) and with LUW V10.1 FP4 or V10.5 FP4 or higher

1021 APAR PI34752 will provide an run time parm TOLERATE_LSN_TRUNC=Y option to allow 10 byte IBMSNAP_COMMITSEQ, IBMSNAP_INTENTSEQ and IBMSNAP_UOWID for CCDs LUW 10.5 FP5 with a SB will provide the same option


Migrating CCD for 1021● You need to change your applications reading the CCDs tables to do

the following● Tolerate CHAR(10) FOR BIT DATA column length for

IBMSNAP_COMMITSEQ and IBMSNAP_INTENTSEQ● Tolerate VARCHAR(16) FOR BIT DATA column length for

IBMSNAP_COMMITSEQ and IBMSNAP_INTENTSEQ and the data is only 10 bytes

● Tolerate VARCHAR(16) FOR BIT DATA column length for IBMSNAP_COMMITSEQ and IBMSNAP_INTENTSEQ and the data is 16 bytes

● Once you are in LUW V 10.1 FP4 or V10.5 FP5 or z/OS V10 APAR PM94614 or higher and your applications reading these CCDs are changed to tolerate 16 byte or 10 byte IBMSNAP_COMMITSEQ and IBMSNAP_INTENTSEQ you should alter the CCDs length for IBMSNAP_COMMITSEQ and IBMSNAP_INTENTSEQ to VARCHAR(16) FOR BIT DATA

CCD Migration


SQL and Q Apply CCD target columns IBMSNAP_COMMITSEQ and IBMSNAP_INTENTSEQ must(*) be altered to VARCHAR(16) FOR BIT DATA.

You can alter lengths when you migrate to V10.1 FP4 or V10.5 FP5

– ASN.IBMSNAP_SUBS_MEMBR TARGET_STRUCTURE of 3 or 9 for CCD (SQL Rep)

– !ASH.IBMQREP_TARGETS TARGET_TYPE of 2 for CCD (Q Rep)

– At target you need to alter CCD tables. Need to find the CCD names

– ALTER TABLE AA080598."T1CCD" ALTER COLUMN IBMSNAP_COMMITSEQ SET DATA TYPE VARCHAR(16) ALTER COLUMN IBMSNAP_INTENTSEQ SET DATA TYPE VARCHAR(16);

– Alter nick name

– http://www-01.ibm.com/support/knowledgecenter/SSEPGG_10.5.0/com.ibm.db2.luw.sql.ref.doc/doc/r0002164.html

10.5 FP5 with SB will provide an run time parm TOLERATE_LSN_TRUNC=Y option to allow 10 byte IBMSNAP_COMMITSEQ, IBMSNAP_INTENTSEQ and IBMSNAP_UOWID for CCDs

Federated CCD target migration for 1021


Nickname can be altered or dropped and recreated after "IBMSNAP_INTENTSEQ" and "IBMSNAP_COMMITSEQ" columns are altered

Old nick name

ALTER NICKNAME CREATOR.CCD1 ALTER COLUMN "IBMSNAP_INTENTSEQ" LOCAL TYPE CHARACTER (10) FOR BIT DATA;

ALTER NICKNAME CREATOR.CCD1 ALTER COLUMN "IBMSNAP_COMMITSEQ" LOCAL TYPE CHARACTER (10) FOR BIT DATA;

Change to :

ALTER NICKNAME CREATOR.CCD1 ALTER COLUMN "IBMSNAP_INTENTSEQ" LOCAL TYPE VARCHAR (16) FOR BIT DATA;

ALTER NICKNAME CREATOR.CCD1 ALTER COLUMN "IBMSNAP_COMMITSEQ" LOCAL TYPE VARCHAR(16) FOR BIT DATA;

Federated CCD target migration for 1021(1)


If you see -302 after altering the IBMSNAP_INTENTSEQ and IBMSNAP_COMMITSEQ, you will have to drop and create nick names as shown below

1)select 'drop nickname schema.'||substr(tabname,1,28)||';' from syscat.tables where type ='N' and tabname like 'T%' and owner ='SCHEMA';

2)select 'CREATE NICKNAME SCHEMA.'||substr(tabname,1,28)||' for target_server.'||'target_schema.'||substr(tabname,1,28)||';' from syscat.tables where type ='N' and tabname like 'T%' and owner ='SCHEMA';

3)select 'ALTER NICKNAME SCHEMA.'||tabname||' alter column IBMSNAP_INTENTSEQ LOCAL TYPE Varchar(16) for bit data;' from syscat.columns where colname like 'IBMSNAP_INT%' and length= 10 and tabname like 'T%';

4)select 'ALTER NICKNAME SCHEMA.'||tabname||' alter column IBMSNAP_COMMITSEQ LOCAL TYPE Varchar(16) for bit data;' from syscat.columns where colname like 'IBMSNAP_COMM%' and length= 10 and tabname like 'T%';

Federated CCD target migration for 1021 (2)


1021 Q Apply storproc target update

● You must (*) modify your storproc to change SRC_CMT_LSN from CHAR(10) to VARCHAR(16) FOR BIT DATA

* Note: Storproc SRC_CMT_LSN length can be altered prior to going to 1021(APAR PM94614 or higher) and with LUW V10.1 FP4 or V10.5 FP5

1021 APAR PI34752 will provide an run time parm TOLERATE_LSN_TRUNC=Y option to allow 10 byte SRC_CMT_LSN in storproc LUW 10.5 FP5 with a SB will provide the same option


1021 Q replication EP message update

● Transaction_identifier (urid) stays 10 if you are running with DB2 V10 or prior. It will be 12 bytes if you are running in DB2 V11

● Commit_lsn changes from 10 bytes to 16 bytes for all DB2 releases . You might need to change your applications to handle this change.


Migrating to 1001 or 1021– Use migration sample job to verify that the 1001 replication

control table structures are ready to be migrated to 1021 This sample ships with 1021 in member SASNSAMP(ASNV1001)

– Ask support to provide you with these(*) samples. These samples are shipped in 1021 APAR PI42263 SASNSAMP

– ASNVREOR(*) to check if any replicated table needs to be reorged

– ASNVMON(*) to check the ASNMON tables

– ASNV1021(*) to check all new columns and tables in 1021 after you migrated to 1021 for Q replication

Migration Verification Tool for Q Replication


Compatibility/Coexistence 1001 and 1021 (Q Replication)

• Compatibility 1001: IBMQREP_CAPPARMS COMPATIBILITY='1001' or '0907' or '0905' depending on the lowest ARCH_LEVEL of the Q Apply (luw or z) this Q Capture on z is sending changes to

• Compatibility 1021: IBMQREP_CAPPARMS COMPATIBILITY='1001' or '1021' depending on the lowest ARCH_LEVEL of the Q Apply (luw or z) this Q Capture on z is sending changes to

• Coexistence: Q Capture 1021 can co-exist with Q Apply 1001 if the IBMQREP_CAPPARMS COMPATIBILITY is set to 1001

• Coexistence: Q Capture 1001 can co-exist with Q Apply 1021 if the IBMQREP_CAPPARMS COMPATIBILITY is set to 1001


Falling back to 100z or 1001 from 1021 or 1001

• Q Capture 1001 or 1021 supports falling back to Q Capture 100z using the Q Capture lsn= or override_restartq option (you will need to come up with the lsn value...)

• Q Capture 1021 supports falling back to Q Capture 1001(APAR PM94614 or higher) without the requirement to use the Q Capture lsn= or override_restartq option. Job name SASNSAMP(ASNQFALL)

→ Q Capture 1001 only supports DB2 V10 or below (not V11).

• Q Apply 1021 supports falling back to Q Apply 1001 or 100z

→ Q Apply 1001 supports DB2 V11 or below.

InfoSphere Data Replication for DB2 for z/OS V10.02.01 ... · PDF file© 2013 IBM...

Documents

Transcript of InfoSphere Data Replication for DB2 for z/OS V10.02.01 ... · PDF file© 2013 IBM...