Checklist for data migration using Redirected Recovery
In many of my previous
blogs I mentioned that we (DBA team) use Redirected Recovery of Recovery Expert
for z/OS v3.2 for data migrations from one DB2 sub-system to another DB2 sub-system.
The data migration (using Redirected Recovery) is done in 3 phases.
Phase 1: Create Profiles and update Recovery
options in Recovery Expert
This is pretty straight-forward
process. We add all the Tablespaces in a database needed for data migration to
an Application profile. Usually, nothing can go wrong in this phase.
Phase 2: Execute Build JCL (that
builds/generates the data migration JCLs)
In the Build JCL, we
provide the following details to build/generate the data migration JCLs.
a)
Application profile
name (having the objects to be migrated)
b)
Timestamp for PIT
recovery
(Redirected Recovery can do only PIT recovery to another sub-system)
c)
PDS name (data
migration JCLs will be created in this PDS)
d)
Plan number for the
Recovery (its 29 for Redirected Recovery)
This job can fail for
many reasons and the frustrating part is that it’s not easy to find out the
reason for job failure. Most of the time we see just the ARYZ018E error message, with list of Objects that can’t be recovered. And, reason why the Objects are
recoverable will be not be provided in the job output.
After discussions with Rocket Software tool support team, got
the checklist to go through for Build job to be successful. The checklist provides
the details of Objects that can lead to failure of Build job. So, these Objects
will be excluded from data migration process. With the help of JCL and REXX, I automated the checklist.
The JCL will have multiple steps to verify the below.
1. Check whether all TS’ in the Source database has ICTYPE=’F’
entries in SYSCOPY for a given ICDATE. I use this SQL
query for verification.
SELECT
DBNAME
,NAME
FROM
SYSIBM.SYSTABLESPACE
WHERE
DBNAME=<dbname>
AND
NAME NOT IN
(SELECT
TSNAME
FROM SYSIBM.SYSCOPY
WHERE
DBNAME=<dbname>
AND
ICDATE=<date>)
WITH UR;
2. Check whether all Image copy datasets (of the TS’ got from
the above SQL query) are present in ICF catalog. I coded the below REXX routine for this verification.
LIST_PARA:
SAY '*****SYSCOPY ENTRIES NOT IN ICF
CATALOG*****'
DO I = 1
TO
INP.0
IC_DSN = STRIP(INP.I,"B")
X = OUTTRAP(LSTC.)
ADDRESS TSO "LISTCAT ENT('"IC_DSN"') "
X=OUTTRAP('OFF')
Y = STRIP(WORD(LSTC.1,1),"B")
IF Y <>
'NONVSAM'
THEN SAY IC_DSN NOT
FOUND IN ICF CATALOG
END
SAY '********************************************'
RETURN;
3. Check whether any Objects (of TS’ included in the
Application profile) are altered.
The CURRENT_VERSION of the TS can change for many reasons.
Redirected Recovery can’t migrate data from versioned TS to non-versioned TS. I
coded Objects’ structures comparison process to verify this.
Versioning can also be found using the below query.
Versioning can also be found using the below query.
SELECT
TS.DBNAME
,TS.NAME
,TB.NAME
,TS.OLDEST_VERSION
,TS.CURRENT_VERSION
,TB.VERSION
FROM
SYSIBM.SYSTABLESPACE TS
INNER JOIN
SYSIBM.SYSTABLES
TB ON
TS.DBNAME = TB.CREATOR AND
TS.DBNAME = TB.DBNAME AND
TS.NAME = TB.TSNAME
WHERE
TS.DBNAME='dbname' AND
TB.TYPE = 'T' AND
TS.CURRENT_VERSION <>
TB.VERSION;
4. PIT timestamp used in Build job must be greater than the
highest START_RBA for a given DBNAME and ICDATE. I use this SQL query to get the value.
SELECT
TIMESTAMP((MAX(START_RBA))||X'0001')
+
CURRENT
TIMEZONE
FROM SYSIBM.SYSCOPY
WHERE
DBNAME=<DBNAME>
AND
ICDATE=<DATE>
WITH UR;
Phase 3:
Execution of the data migration JCLs
This phase can go smooth if we follow the checklist.