Simplify and Improve Database Administration by Leveraging IBM FlashCopy

By Ron Haupert
Senior Technologist, Rocket Software

In this article, Ron Haupert describes storage-aware database management tools on IBM® z/OS® systems. These tools integrate storage-based, fast-replication facilities with IBM DB2® and IMS systems to provide fast and non-disruptive DB2 backup and cloning solutions. Storage-aware database management tools improve DB2 backup, recovery, disaster recovery, and cloning solutions by using IBM FlashCopy® facilities to copy data, which saves time, host CPU resources, and I/O resources.

A new class of storage-aware data management tools is evolving that integrates FlashCopy fast-replication facilities with database management systems to provide fast and non-intrusive database system-level backup and cloning solutions. Storage-aware data management tools like the DB2 and IBM IMS® Cloning tools, and DB2 Recovery Expert for z/OS help simplify backup, recovery, and cloning strategies by using automation to coordinate database system operations with FlashCopy facilities. Data copy processes are performed efficiently in the storage processors, which saves host CPU and I/O resources.

Storage-aware data management tools provide facilities to link and coordinate application and data management organizations with business continuity and storage administrators. By using the FlashCopy tool to perform traditional data copy functions, you can implement new backup and recovery methods, simplify business continuity operations, perform automated cloning operations and transform tedious disaster recovery processes into efficient disaster restart procedures. Figure 1 shows how storage-aware data management tools can be used to integrate application and database administration domains with business continuity and storage administration domains.

Figure 1 Storage-aware database management tools

Storage-aware backup and recovery

Database system-level backup (SLB) methodologies have been used by some organizations for many years as an efficient and effective way to back up database systems. System-level backups have been created by storage organizations using full volume dumps and storage-based fast replication facilities. The backups are shipped offsite where they are used to provide the foundation for traditional DB2 or IBM IMS® disaster recovery procedures. These storage-based backups tend not to be used by DBAs (database administrators) to perform local or disaster recovery operations because it is difficult to coordinate the data restoration from volume backups with database recovery processes without supporting automation. The complexity associated with using volume backups and the familiarity of using DBMS and host-based copy methods has guided DB2 and IMS DBAs to use traditional image copy backups for local site recovery and for disaster recovery purposes.

IBM DB2 Recovery Expert on z/OS software is a storage-aware backup and recovery tool that resolves FlashCopy organizational and technology conflicts by allowing FlashCopy facilities to be exposed to DBAs in a transparent manner. Recovery Expert integrates FlashCopy facilities to automate and simplify backup and recovery processes. Database system-level backup methods are the foundation for these backup and recovery processes. DB2 system-level backups performed using FlashCopy have many operational advantages.

• Backup, recovery, and disaster recovery procedures are simplified, and backup processing and administration costs are reduced.
• Application availability is increased because DB2 systems can be backed up instantaneously without affecting running applications. Backup windows are eliminated and application processing windows can be extended.
• Processing costs are reduced because backups are performed in the storage processor without using host CPU or I/O resources.
• By using a storage-aware tool, you can discover DB2 systems, analyze storage processor configurations, and recommend configuration changes based on the data set layout and recovery requirements.
• You can coordinate FlashCopy operations with DB2 activities to back up DB2 systems. Backups can be validated at backup time to ensure all database resources are contained within the volumes being backed up.
• System-level backups can be used for multiple backup purposes and save storage resources. System-level backups can support local system recovery, application recovery, table and index space recovery, as well as provide offsite disaster restart support for DB2 systems.
• Automated system-level backup offload facilities can archive disk-based backups to tape. You can use the tape archive copies for subsequent local data recovery or for offsite disaster restart and recovery purposes.
• Data consistency is ensured during the backup process. Data consistency can be maintained across volumes by DB2 when using DB2 Backup System operations or by using DB2 Suspend operations. Storage-based consistency functions can also be used to maintain data consistency during the backup process.
• System-level backups reduce recovery time. DB2 systems, application databases, or application table and index spaces are restored instantaneously from a system-level backup using FlashCopy facilities while DB2 recovery operations are performed in parallel to the restoration process to minimize recovery time and reduce application down time.
• DB2 system-level backups provide an effective disaster restart business continuity solution that simplifies disaster recovery operations. Disaster recovery becomes as simple as restarting from a power failure.

Storage-aware backup and recovery requirements

Storage-aware backup and recovery products that implement a system-level backup methodology require a sophisticated storage integration infrastructure and metadata repository. These products leverage FlashCopy facilities from the leading mainframe storage vendors like IBM, EMC, and HDS by integrating FlashCopy facilities and exposing them to DB2 and IMS DBAs in a transparent manner.

Storage-aware database backup and recovery requirements include:

• DB2 system-level backup and restore operations are performed by invoking FlashCopy facilities. Backup and restore operations are performed instantaneously as perceived by the application and database system.
• Provide space-efficient FlashCopy support to allow multiple disk-based backups to be maintained while using a minimum amount of storage. Source and backup volume coordination and FlashCopy commands should be transparent to the user.
• DB2 system configuration facilities that discover database systems and determine where the volumes are located. These tools must identify database layout issues that can conflict with or inhibit a system-level backup approach. Storage-aware database backup and recovery tools should report on storage volume contents and optionally move data sets appropriately to support your system-level backup and recovery objectives.
• A complete DB2 system-level backup is performed by validating that all of the storage volumes used by the DB2 system are backed up. The backup must ensure that all appropriate catalogs are included in the backup so that recovery functions can be performed correctly.
• Support for DB2 system recovery, DB2 table and index recovery, or application recovery from a system-level backup. This requirement allows system-level backups to be used for local site system and application recovery, as well as disaster recovery purposes. DB2 table and index space recovery should use data-set level FlashCopy facilities to restore data sets from the system-level backup volumes to their source database volumes. Data recovery should be performed in parallel to the data set restoration process to reduce overall recovery time.
• Support for partial DB2 system-level backups that can be used for subsequent DB2 table and index space recovery. Partial system-level backups reduce storage utilization by backing up only specific application data by using system-level backup methodology.
• Provision for an integrated metadata repository that maintains information about the DB2 system, database volumes, backup volumes, backup time, corresponding log RBA values, and other related information. This information is used to maintain the system, perform database restore and recovery functions, and coordinate the use of storage resources.
• Support for tape offloading of disk-based system backups. The offloading processes must offer compression and encryption options that can be used during the archival process.
• Provision for local and remote disaster restart and disaster recovery support.

Storage-aware backup and recover process flow

Storage-aware, system-level backup solutions use volume-based FlashCopy operations to back up database systems. Volume-level backups have many operational advantages over data-set copy methods. Volume-based FlashCopy speed up the backup processes because it is executed quickly, can leverage storage-based consistency functions, and uses storage processor resources efficiently.

When the database system volumes are discovered and backup target volumes are associated, FlashCopy facilities are used to back up the database instantaneously without affecting running applications. Backup volume and associated database recovery information is stored in a metadata repository and used during recovery or backup offload processing. Figure 2-A shows a storage-aware backup and recovery facility that uses volume-based FlashCopy to create a system-level backup for DB2.

Figure 2 Storage-aware database backup and recovery   A - DB2 system-level backup created by using volume-based FlashCopy
   B - Disk-based system-level backup offloaded to tape
   C - Disk-based system-level backup used to restore a DB2 system
   D - DB2 application, or DB2 table and index space recovery from a system-level backup
   E - Restoring a DB2 system or database objects from an offloaded system-level backup

System-level backups on disk provide fast and effective restore and recovery operations. However, maintaining multiple backup generations on disk can be cost-prohibitive. Storage-aware backup and recovery products must have tape offload facilities to provide for long-term backup retention while allowing recovery to be performed from the archived copy. Figure 2-B depicts a system-level backup that is archived to tape by the storage-aware backup and recovery automation. The archived copy can be used for subsequent system, application, and database recovery, as well as table and index space recovery purposes.

Database system-level backups are restored from disk or tape automatically when recovery operations are required. The recovery process determines the optimal backup to restore that provides the most expeditious recovery. The recovery process determines whether to restore a disk-based system-level backup or whether to restore a system-level backup that has been archived to tape based on recovery scope and which restoration method provides the fastest recovery.

When recovering database systems by using a system-level backup that is on disk, FlashCopy facilities are used to restore the data at a volume level to expedite the restoration process. Database system recovery processes are performed in parallel while the data volumes are being restored. Database logs are used to roll forward the restored application data. Figure 2-C depicts a database system recovery operation where volume-based fast replication is used to restore database data.

When DB2 table and index spaces, or applications are recovered, appropriate corresponding data sets are restored from the system-level backup volumes by using data set FlashCopy facilities. Application recovery time is reduced because the data restoration process performed in the storage processor is done in parallel with the database recovery processes. That is, database logs are applied while data is being restored in the storage processor as a result of the data set FlashCopy operation. The parallel restore and recovery processing shortens overall recovery time and reduces application downtime during the recovery process. Figure 2-D depicts a DB2 application or DB2 table and index space recovery operation where data-set level fast replication is used to restore database data.

Disaster restart and recovery

A DB2 system-level backup simplifies disaster recovery operations and reduces recovery time objectives. DB2 system-level backups can be used to restart the database system at a point in time when the backup was performed. System-level backups can also be rolled forward using available database logs and recovery assets at your disaster recovery site.

A database system-level backup is a “restartable” copy. A restartable database copy has a dependent-write consistent data state from an I/O perspective. This data state is identical to that created by a power failure. A restartable database copy can be created by invoking database or storage-processor data consistency functions when a system-level backup is created. For example, a restartable copy can be created by suspending the DB2 system by using a DB2 suspend function or by using a storage-based consistency function while FlashCopy commands are executed to create a system-level backup.

Database recovery is performed implicitly during normal DB2 initialization to transform a dependent-write consistent data state into a transactionally consistent data state. Disaster recovery operations that use a system-level backup as input can use traditional database restart procedures at a disaster recovery site to recover their DB2 systems. Disaster recovery procedures can become as simple as restarting the DB2 system from a power failure. Thus, tedious disaster recovery operations can be transformed into an efficient disaster restart procedure. Using disaster restart procedures for disaster recovery operations simplifies the recovery process and reduces recovery time objectives at the disaster recovery site.

Offloading FlashCopy-based system-level backups to tape and then transporting the tapes to a disaster recovery site provides the foundation for a tape-based disaster restart solution. Tape-based disaster restart solutions simplify disaster recovery operations, reduce recovery time objectives, and provide similar advantages to storage-based business continuity solutions that use remote storage replication such as IBM PPRC (peer-to-peer remote copy). Tape-based disaster restart solutions can provide an excellent and cost-effective tertiary disaster recovery solution when implemented with PPRC Metro Mirror remote mirroring solutions.

System-level backup implementation considerations

The data set layout used for the DB2 system must be considered when planning a system-level backup methodology. Layout considerations include how the system-level backup will be used for recovery and disaster recovery purposes. DB2 system-level backups that are used to recover an entire DB2 system (system recovery) must have their recovery structures such as active logs, archive logs, and the DB2 Bootstrap data set isolated on separate volumes from those that support the system and application data sets. The separation of recovery structure data sets from system and application data sets ensures that DB2 system and application data can be restored from the backup volumes while using more recent recovery structure data sets on the source volumes to perform roll-forward recovery.

DB2 volumes used for system-level backup and recovery operations should not have other non-database data sets co-located on them. If other non-database data sets are co-located on the volumes, those data sets are backed up and restored when the DB2 system is restored. Restoring non-database data sets when the DB2 system is restored might not produce the desired recovery outcome.

DB2 systems that use a system-level backup methodology with the intent to recover only applications, or table and index spaces from the system-level backup do not require data-set separation. DB2 table and index space recovery use data set FlashCopy facilities to restore data so only appropriate data sets are restored from the system-level backup during recovery operations.

Storage-aware database cloning and refresh

Cloning database management systems allows production data to be used for testing, reporting, data warehouse loading, database utility processing, or other production offload tasks. Offloading these types of activities to a cloned database copy reduces production I/O contention and allows processing activities on a static copy of the data. Cloning database management systems by using storage-aware database utilities allows the cloning process to be simplified and automated to reduce cloning time and administration costs.

Cloning a database management system involves copying data, performing volume reconditioning and data set renaming processes, and updating the cloned DBMS metadata. Storage-aware database cloning automation coordinates these processes in a fast, efficient, and automated manner.

Storage-aware database cloning utilities such as the DB2 Cloning Tool and IMS Cloning Tool use FlashCopy to copy data quickly, speed up the cloning process, and reduce administration costs. Data is copied by using volume or data set-based FlashCopy facilities to reduce copy time and save host CPU and I/O resources. Data can be copied while the source database is running or stopped.

DB2 and IMS system cloning automation performs volume reconditioning and data set renaming on the copied volumes so they can be brought online to the same or to a different z/OS LPAR. Data set names are changed on the copied volumes so they can be accessed from the cloned DBMS without causing z/OS catalog conflicts. Volume reconditioning and data set renaming processes must be performed fast and efficiently to reduce overall DBMS cloning time.

After the volumes are copied, reconditioned, and data sets renamed, the cloned DBMS metadata must be adjusted to accommodate the copied data. For DB2 systems, the DB2 catalog, directory, BSDS, active logs, and optional disk-based archive log structures must be updated to reflect the new data set names in the cloned DB2 system. For IMS systems, the IMS RECONs, PROCLIBS, JCL, MDA members, and other similar data must be changed to reflect the cloned data set names. Figure 3-A shows storage-aware database cloning automation that uses volume-based fast replication to clone DB2 and IMS systems.

Figure 3 Storage-aware database cloning.   A - Database system cloned by using volume-based fast replication facilities
   B - IMS database and DB2 table and index space refresh use data-set level fast replication methods

Some database administration tasks require IMS databases or DB2 table and index spaces to be cloned or refreshed frequently. Database system cloning may be performed infrequently while DB2 table and index spaces or IMS databases may be refreshed into the cloned database system more frequently or on a periodic basis. Refreshing IMS databases or DB2 table and index spaces into previously cloned IMS or DB2 systems can reduce database system refresh time and costs by refreshing only the DB2 table and index spaces or IMS databases that must be refreshed.

Storage-aware database cloning tools allow refreshing of IMS databases or DB2 table and index spaces. Refresh automation steps include performing refresh compatibility validation, copying data by using data set-based FlashCopy facilites, and updating the target data pages to reflect the cloned DBMS metadata. IMS database and DB2 table and index space refresh automation coordinates these processes in a fast and efficient automated manner. Figure 3-B depicts IMS database or DB2 table and index space refresh automation using FlashCopy.

Conclusion

Database administrative functions can be simplified and improved by leveraging your storage system fast-replication facilities through storage-aware database management tools. Storage-aware database management tools integrate FlashCopy fast-replication facilities with database management systems to enable high availability though improved backup, recovery and disaster recovery procedures, and promote data accessibility by automating database cloning and refresh procedures. By using storage-aware database management tools, DBAs can use FlashCopy fast-replication facilities safely and transparently while simplifying data administrative processes and reducing CPU and I/O utilization.

Note: The information provided by the author of this document represents the views and experiences of the author. IBM has provided access to this document on the basis that it may provide usefully information to the recipients. However, as IBM has not in any respect validated nor necessarily agrees with the information provided, IBM does not accept any liability whatsoever in the use to which this information may be put.