Bharath's Tech Blog

Post-migration verification, Redirected Recovery

In my previous blog, I mentioned about the concern we have whether the data got copied from source to target or not, and also mentioned the 4 ideas/approaches we came up with for the verification.

After internal team discussion, we decided to implement the below approach.

• Take backups of target after data migration is done, and compare source’s COPYPAGESF (from SYSCOPY) with target’s COPYPAGESF (from SYSCOPY) 

This is how I implemented the approach.
This process will be executed after data migration.

1. Create image copies for the Target database.
2. Execute a JCL that has 3 steps

• First step executes a SELECT query on source's SYSIBM.SYSCOPY to get data (based on the ICDATE we used for data migration) from these columns into a PS file.

DBNAME
TSNAME
ICDATE
ICTIME
DSNAME
DSNUM
COPYPAGESF

• Second step executes SELECT query on target's SYSIBM.SYSCOPY to get data (for the image copies created just before starting this process) from the same columns mentioned above into a PS file.
• Third step executes a REXX routine (I coded) that will compare the PS files generated in above  mentioned steps.

This approach is chosen as our backup strategy.

• Reading source’s SYSTABLESPACESTATS data into a personal Table on daily basis, and comparing the data in personal Table with target’s real-time stats data (when needed)

This approach is bit complicated to implement, as we need to get the RTS details at the time of image copies done for the databases.
This approach can be implemented in 2 ways.

1. Schedule a job that extracts the details from SYSTABLESPACESTATS and loads into a user-defined Table. This job will be triggered by the image copies jobs. 

          The main concerns with this way of implementation are

• Elaborate planning as the schedule of image copy jobs has to be changed.
• RTS details may be of not much use for verification if image copies are not SHARELEVEL REFERENCE

    2. In our Mainframes setup, RTS details are externalized every 30 minutes. So, a job can be executed every 25 minutes, which extracts the details from SYSTABLESPACESTATS and loads into a user-defined Table. 

          The main concerns with this way of implementation are

• Time constraint. If the extract job runs long due to low priority in the system, then we may miss the RTS details.
• We may be getting too many details than needed, as RTS details get loaded every 30 minutes.