Bharath's Tech Blog

Personal experience with working of MODIFY RECOVERY on non-GDS LP copy

In Feb 1st week of this year, we were asked by Application team to migrate data between 2 databases which are on different Db2 sub-systems (source database is on Prod and target database is on QA), using the backups (for source database) created on 27-Dec-2017.

These are the details about our backup strategy in Prod.

1. All Tablespaces in Prod database are backed up daily (ICTYPE='F' only).
2. LP are on DISK and LB are on TAPE
3. Previous day's LP datasets are deleted before creating current day's LP backups.
4. LB datasets are GDS and GDGLIMIT is 45 

These are the details about our MODIFY RECOVERY job in Prod

1. Job is executed on quarterly basis.
2. This is the syntax used in MODIFY RECOVERY job.                                                     RETAIN GDGLIMIT LAST (3)

I found that all the entries are gone from SYSCOPY for the date 27-Dec-2017, for the source database in Prod. The MODIFY RECOVERY job was executed on 6-Jan-2018.

My initial thought was that 27-Dec-2017 falls within 45 days and entries for LB backups have to be present in SYSCOPY as the GDGLIMIT is 45.

I realized after some digging that there was an oversight from my side in understanding the syntax used in our MODIFY RECOVERY job.

In the daily backup setup, LP copies are written to DISK and are non-GDS. As the LP copies are non-GDS, GDGLIMIT parameter was ignored by Db2 and just recent 3 records were retained in SYSCOPY for LP and LB copies.

To avoid such issues in future, we decided to change the syntax in MODIFY RECOVERY job to DELETE AGE (45). With this new syntax, all records that are older than 45 days will be deleted from SYSCOPY.

More details about MODIFY RECOVERY utility can be found here.