A common phrase in the IT world is ‘How long will it take to recover ?’, the typical answer being ‘it depends’. This question is certainly well-known among Db2 for z/OS DBAs, as this group has the responsibility to safeguard companies most precious data assets. The duration of each unplanned outage has a direct impact on a company’s revenue. Therefore, almost all companies have a Service Level Agreement in place that defines how long it should take – at a maximum - to recover lost data assets. The time allowed for IT to complete a recovery process from begin to end is commonly referred to as ‘Recovery Time Objective’ (RTO). The most obvious factors that can make a difference between a fast and a long-running recovery exercise in Db2 for z/OS are:
- Number and size of objects to be recovered
- Availability of recent image copies
- Amount of Db2 for z/OS log data that needs to be read and applied
- Storage devices (and, if applicable, number of available tape stations) used to store both image copies and Db2 for z/OS log data
The best way to understand if you currently meet your RTO is to actually perform a recovery. But you can’t recover your data assets in place as this would cause an outage for your Db2 for z/OS dependent workloads.
A common approach to determine if RTO goals could be met had been to either simulate recovery operation based on a subset of data or to perform a ‘redirected recovery’ to different target objects. While these are good approaches, there are pitfalls that may prevent you from drawing the right conclusions:
- Recovering subsets of data don’t tell you if you’ll have all required resources both in terms of real storage and DASD capacity available to actually perform a real-life recovery
- Redirected recovery requires a support by a vendor solution and uses different code paths compared to what you’d use in a real-life recovery situation, leaving you with an incorrect – and possibly worst case - estimate for your RTO only
- Both approaches have in common that you can’t validate if there would be any potential issues with a real-life recovery
If all these challenges sound familiar to you, we recommend to investigate Db2 for z/OS PTF UI72057: this enhancement requires Db2 12 for z/OS Function Level 500 and allows you to recover your data assets into shadow objects, using all the resources that would be use for a real-life, in-place recovery scenario by the Db2 for z/OS RECOVER utility.
The syntax is shown in the following example:
RECOVER TABLESPACE target-db.target-ts DSNUM x FROM
source-db.source-ts DSNUM x
or
RECOVER TABLESPACE target-db.target-ts FROM
source-db.source-ts
With this enhancement, the Db2 for z/OS RECOVER utility would act exactly as it would for an in-place recovery, the only difference being that the target of the recovery operation is not the recovered object itself, but a shadow object that is not accessed by your existing workloads.
As this PTF provides a first step to enhance the Db2 for z/OS RECOVER utility to comprehensively perform redirected recoveries to shadow objects, there are additional information to be aware of:
- You need to ensure the correct definition of the target object exits before you invoke the RECOVER utility. This includes attributes that determine the table space type and organization, page size, DSSIZE, SEGSIZE (for non-LOB TS), MEMBER CLUSTER and CCSID. If you want to perform a redirected recovery for a partitioned-by-growth table space, MAXPARTITIONS must be equal or larger than the number of partitions of the source table space.
- Image copies and log records from the source will be applied to the target. Both Sequential image copies and FlashCopy Image Copies are supported.
- Source objects will remain available for R/W access
- Target objects won‘t be available for R/W access until RECOVER completes
- Recovery point can be to current or to a prior point in time
- Uncommitted work at the recovery point will be backed out for the target table space
- Indexes are currently set to REBUILD pending (support for index spaces will be delivered via APAR PH27268)
- Only universal table spaces are supported
- Target objects must reside in the same Db2 for z/OS subsystem or Data Sharing group
If you’re a user of IBM Db2 Recovery Expert for z/OS, this solution has also been enhanced with PTFs UI70358, UI70359 and UI71307 to support this new option of the RECOVER utility.
In summary, this new feature of the RECOVER utility allows you to exactly assess the duration of a real-life, in place recovery. With this information at hand, you can now tell if you would be able to meet your RTO in case you have to recover your most valuable data in a production subsystem.
#Db2Toolsforz/OS