Estimating Recovery Time Objective with IBM Db2 Recovery Expert
Db2 for z/OS offers a powerful feature known as redirected RECOVER, which is widely used to test, measure, and validate recoverability. This feature enables you to recover a production table space or index into a separate copy while your production workload continues to run uninterrupted.
Some organizations leverage this feature to recover a significant subset—often 10-25%—of their production tables, tracking the runtime for these recoveries. Based on these partial recoveries, they can extrapolate the time required for a full recovery, helping to establish a more accurate Recovery Time Objective (RTO).
How Db2 Recovery Expert Can Help
Db2 Recovery Expert simplifies and automates the recovery process. It helps in building recovery jobs by:
- Generating DDL for the target objects of a redirected recovery
- Creating JCLs to execute redirected RECOVER for table spaces and COPY YES indexes
- Building jobs for utilities such as REBUILD INDEX, REPAIR, and CHECK DATA
In the example below, a database recovery job was created to run four parallel recovery jobs across two LPARs.
While you can manually submit and monitor these jobs, Db2 Recovery Expert provides additional automation by allowing you to submit, monitor, and even restart jobs in case of a failure.
Breakdown of Recovery Jobs
- DDL Creation: The first job in the process generates the necessary DDL for the recovery.
- Partition-Level Recoveries and Index Rebuilds: Jobs 2 through 5 handle partition-level recoveries and the rebuilding of indexes.
- Space-Level Recoveries and Utility Execution: Jobs 6 through 9 handle space-level recoveries, non-partitioned index (NPI) rebuilds, and execution of utilities such as REPAIR and CHECK DATA.
- Final Verification: The 10th job makes the copy read/write (R/W), enabling the application team to verify the data.
High-Level Statistics and New Features
During the recovery process, Db2 Recovery Expert provides real-time statistics, such as the total amount of data recovered and CPU/zIIP consumption (APAR PH59033 from January 2024). Additionally, recent enhancements (APARs PH63415 and PH61218 from October 2024) introduced more detailed utility-level information on both the overall statistics panel and the job-level statistics panel.
These updates rely on Db2 for z/OS V13 utility history (V13 FL501) to offer deeper insights into the recovery process. Below is an example screenshot showcasing this enhanced information.
This screen also provides key high-level statistics, such as the total amount of data recovered and the CPU and zIIP usage. With the release of APARs PH63415 and PH61218 in October 2024, additional utility-level details have been added to both the overall statistics panel and the job-level statistics panel. These enhancements are powered by Db2 for z/OS V13 utility history (V13 FL501), giving you more granular insights into the recovery process.
The screenshot below illustrates these updates in action.
To estimate RTO, you can use the elapsed time, data recovered, and recovery rate. Start by measuring the time it takes to recover a specific amount of data during a recovery test. Then, calculate the recovery rate (data recovered per unit of time). Db2 Recovery will calculate both the amount of data recovered and the recovery rate by utility. Using these rates, you can extrapolate how long it would take to recover the entire database. For example, if you recover 100GB in 2 hours, your recovery rate is 50GB per hour. If your total dataset is 500GB, the estimated RTO would be 10 hours.
You can compare recovery time to rebuild time to determine whether switching the indexes to "COPY YES" would be beneficial. Detailed statistics should be reviewed for each index to make an informed decision.
#IBMChampion
#ibmchampions-featured-library-home #Db2Tools#db2rezos #db2z/os