Casebook - 2012 Edition: Tightly Integrated DB2 Backup ...

SAP COMMUNITY NETWORK SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com

© 2011 SAP AG 1

Casebook - 2012 Edition:

Tightly Integrated DB2 Backup,

Recovery and Cloning

for SAP Environments

Applies to:

SAP solutions running on DB2 for z/OS.

Summary

Among the key capabilities of database systems relevant for SAP applications are non-disruptive and efficient backup methods, automated and fast recovery to current and to a prior point in time, and fast and flexible system cloning. As a strategic solution, DB2 for z/OS provides the integrated BACKUP SYSTEM and RESTORE SYSTEM utilities, which internally rely on DS8000 FlashCopy and z/OS DFSMShsm technology. Variations of FlashCopy like incremental FlashCopy, space-efficient FlashCopy, and data set FlashCopy address different requirements. Moreover, the Remote Pair FlashCopy functionality aims at seamlessly reconciling the DB2 backup strategy with a Metro Mirror approach for data mirroring as basis for disaster recovery solutions like GDPS. The DB2 Cloning Tool and the DB2 Recovery Expert for z/OS can be used to further facilitate, automate and accelerate many of the tasks.

This document provides hands-on tips and tricks for using the above mentioned DB2 utilities and tools in SAP environments in the most beneficial way. It is based on latest SAP and IBM technologies including SAP NetWeaver 7.31, DB2 10 for z/OS, z/OS 1.13, DB2 Cloning Tool 3.1, DB2 Recovery Expert 2.2, and DS8800. It covers how to take advantage of the latest technical capabilities of these tools and, therefore, presents an update of the previous Casebook on this topic back to 2008. The use cases also apply to previous SAP NetWeaver releases. A particular focus is set on demonstrating the interplay of these components to ensure seamless backup, recovery and cloning solutions for SAP customers. This useful information is intended to help customers to easily implement and manage their specific solutions. Last but not least, many operational samples are provided, which are the result of a workshop that took place at the IBM System z Technology Center for SAP applications at the IBM Boeblingen Lab.

Authors: Werner Bauer, IBM Deutschland GmbH

Christine Gaul-Gaensslen, IBM Deutschland Research & Development GmbH

Peter Hartmann, IBM Deutschland GmbH

Christian Heimlich, IBM Deutschland GmbH

Armin-Robert Kompalka, IBM Deutschland GmbH

Ludger Quatmann, IBM Deutschland GmbH

Joachim Rese, IBM Deutschland Research & Development GmbH

Albert Rodi, IBM Sales & Distribution, STG Sales

Heike Schmidt, IBM Deutschland Research & Development GmbH

Johannes Schuetzner, IBM Deutschland Research & Development GmbH

Mary Siart, IBM Sales & Distribution, STG Sales

Heidrun Wietzorek, IBM Deutschland GmbH

Roland Wolf, IBM Deutschland GmbH

Casebook - 2012 Edition: Tightly Integrated DB2 Backup, Recovery and Cloning for SAP Environments


© 2012 SAP AG 2

Company: IBM

Created on: March 1, 2012

Author Bio

Werner Bauer was an IBM Certified Consulting IT Specialist in Germany. He has 30 years of experience in storage software and hardware as well with IBM S/390® and IBM z/OS. His areas of expertise include disaster recovery solutions based on IBM enterprise disk storage subsystems. Werner is a frequent speaker at storage conferences and European GUIDE and SHARE meetings. He also contributed extensively to various DS8000® Redbooks publications. He holds a degree in Economics from the University of Heidelberg and in Mechanical Engineering from FH Heilbronn, Germany. You can reach him at [email protected]

Christine Gaul-Gaensslen does technical marketing in the IBM System z Technology Center for SAP Applications at IBM Deutschland Research & Development in Boeblingen. laboratory. She joined IBM in 1985, and has been working with SAP on System z since 1996. She works with customers, organizes events and extensively contributed to various brochures on running SAP applications on IBM DB2 for z/OS and System z. You can reach her at [email protected].

Peter Hartmann is working as IT specialist for DB2. He joined IBM in 2003. He works tightly with DB2 for z/OS customers and all kinds of customer projects with regard to DB2 for z/OS. You can reach him at [email protected].

Christian Heimlich is a senior certified IT architect who joined IBM in 1984. He holds various responsibilities as application programmer and in database administration for IBM internal financial and HR systems. After 10 years as a systems engineer for large customers in the retail, transportation and financial services industries, he moved on to design and implement accounting and data warehouse solutions. In 1999 he became the lead architect in IBM Systems for the SAP core banking projects for European customers, and currently he is working in a worldwide assignment for SAP on System z core banking projects. You can reach him at [email protected].

Armin Kompalka is a Senior IT specialist working for IBM Software Group Germany with DB2 Tools on System z. He has over 20 years of experience in DB2, IMS, CICS system programming and distributed database administration on various Unix platforms. He joined IBM in 2000, after working 6 years for BMC as a technical DB2 tools specialist. Before that, he worked as DB/DC Systems programmer for DUN & BRADSTREET. You can reach him at [email protected].

Ludger Quatmann is a consultant certified IT specialist who joined IBM in 1978. He holds a Bachelor’s degree in electrical engineering from University of Osnabrueck, Germany. Over the years, he has had various responsibilities as z/OS and DB2 for z/OS system programmer and DB2 database administration for IBM and different customers. He worked as an SAP certified Basis Consultant, doing a lot of performance analysis within different industries. You can reach him at [email protected].

mailto:[email protected]








© 2012 SAP AG 3

Joachim Rese is a senior software engineer at the IBM Boeblingen Laboratory in Germany. He is a member of the joint SAP/IBM platform team and belongs to the IBM System z Technology Center for SAP applications. For many years, Joachim has been the lead developer for SAP BW on DB2 for z/OS. He has 15 years of experience in the field of SAP on DB2 for z/OS. Joachim holds master degrees in Mathematics and Computer Science from the University of Paderborn, Germany. You can reach him at [email protected].

Albert Rodi is an IT Specialist in Advanced Technical Services. Since 1997 he has been working with SAP on the System z platform, with a focus on infrastructure setup, perfor-mance, server configuration, installation planning customer sessions, System Health checks, and z/OS setup. He has almost 35 years of experience with IBM and in the past has worked as an application developer, development team leader, systems engineer, and in an application development practice. He has held these positions in Sterling Forest, Cary NC, Philadelphia, and his current home in Dallas. He has a degree in Mathematics from Herbert H. Lehman College in New York City. You can reach him at [email protected].

Heike Schmidt has been working for IBM since 1986, starting as an application programmer for IBM internally. Since 1998 she has been working as an SAP Basis Specialist, running functional tests on IBM platforms and supporting as first level support for upcoming SAP basis problems inside IBM (SAP Customer Competence Center) and she was involved in several SAP projects and benchmarks for customers. Since 2007 she belongs to IBM System z Technology Center for SAP applications in the Boeblingen Lab, where she focuses on z/OS and Linux on System z certification for SAP applications. You can reach her at [email protected].

Johannes Schuetzner divides his time between the IBM Boeblingen Lab and the SAP Labs in Walldorf and St.Leon-Rot and works on all aspects of the usage of DB2 for z/OS for SAP applications. Johannes studied Computer Science at the University of Stuttgart and at the University of Connecticut, Storrs. He belongs to the IBM System z Technology Center for SAP applications and is a Senior Technical Staff Member for SAP on DB2 for z/OS. You can reach him at [email protected].

Mary Siart is IBM Senior Certified Technical Sales Specialist in IBM Americas Sales and Distribution, and provides technical sales support for SAP using System z. She is also an IBM Certified Database Administrator for both DB2 V8.1 and DB2 9 for z/OS. She has 31 years of extensive experience in the IT industry, specializing mainly in the data management areas. Mary has been working with SAP on System z since 1996. Her primary focus has been to assist customers in leveraging IBM technology and features to develop an SAP infrastructure running on System z, which provides high availability and continuous operation. You can reach her at [email protected].







© 2012 SAP AG 4

Heidrun Wietzorek is a senior technical sales specialist. She joined IBM in 1984 and worked many years as a systems engineer for DB2. Her projects included database administration and data warehousing for financial institutes in southern Germany. After spending some years in the marketing organization she joined the technical sales force for DB2 tools on z/OS. You can reach her at [email protected].

Roland Wolf is a Certified IT Specialist in Germany. He has worked for IBM for 25 years and has 18 years of experience with high-end disk storage hardware in System z and Open Systems environments. He is working in Field Technical Sales Support for storage systems. His areas of expertise include performance analysis and disaster recovery solutions in enterprises utilizing the unique capabilities and features of the IBM disk storage servers, DS8000 and XIV. He has contributed to various IBM Redbooks publications including ESS, DS80000 architecture, and DS8000 Copy Services. He holds a Ph.D. in Theoretical Physics. You can reach him at

[email protected].





© 2012 SAP AG 5

Table of Contents

Overview of Base Technologies of BACKUP SYSTEM and RESTORE SYSTEM Utilities ......................... 12

DS8000 FlashCopy Functions and Options .................................................................................................. 17

Data Set FlashCopy ...................................................................................................................................... 20

DASD Volume Setup ..................................................................................................................................... 20

Performance Considerations ........................................................................................................................ 21

FlashCopy Consistency Groups ................................................................................................................... 21

Space-Efficient Volumes and Space-Efficient FlashCopy ............................................................................ 21

FlashCopy Fast Reverse Restore ................................................................................................................. 23

FlashCopy onto a Metro Mirror Primary Volume .......................................................................................... 24

Remote Pair FlashCopy (also known as Preserve Mirror) ............................................................................ 24

Compatibility Matrix of FlashCopy Options ................................................................................................... 26

DB2 BACKUP SYSTEM and DFSMShsm FRBACKUP ............................................................................... 26 DUMP to Tape ........................................................................................................................................................... 27

DB2 Cloning Tool for z/OS ............................................................................................................................ 28

DB2 Recovery Expert for z/OS ..................................................................................................................... 29

Setup of SAP and DB2 Systems ................................................................................................................... 31 Recommended APARs .............................................................................................................................................. 31

DB2 and DFSMS Required Configuration for FlashCopy Based Database Backups .................................. 32

DB2 BSDS .................................................................................................................................................... 35

ACS Routines and Data Set Allocation ......................................................................................................... 35

Sample SMS Setup for SAP ......................................................................................................................... 35

Setup of Test Environment ........................................................................................................................... 37

DFSMS Setup and Definitions ...................................................................................................................... 39 ACS Routines ............................................................................................................................................................ 42

Tape Definitions ......................................................................................................................................................... 43

Copy Pools used by DB2’s BACKUP SYSTEM Utility .................................................................................. 44

Space-Efficient Volumes to enable DB2 BACKUP SYSTEM for Space-Efficient FlashCopy ...................... 49

Invoking and Monitoring BACKUP SYSTEM and HSM Fast Replication Services ...................................... 52

Restoring a DB2 System-Level Backup using HSM FRRECOV .................................................................. 56

Invoke BACKUP SYSTEM from SAP DBA Cockpit ...................................................................................... 57

Use SAP DBA Cockpit to Retrieve Information on Available System-Level Backups .................................. 57

Verifying DB2 Recovery or Restore with an SAP System in the Use Cases ................................................ 58

BACKUP SYSTEM using Incremental FlashCopy ........................................................................................ 61

Incremental Backups using Fast Reverse Restore (FRR) ............................................................................ 63

Recovery of Single Tables or Indexes from a System-Level Backup ........................................................... 70 Scenario 1: Base example ......................................................................................................................................... 70

Scenario 2: Some unusual error situations ................................................................................................................ 72

Scenario 3: Recovery of single objects while incremental system-level FlashCopy relationship exists ..................... 76

Scenario 4: Parallel processing .................................................................................................................................. 78

BACKUP SYSTEM and Growing or Shrinking of SAP Systems .................................................................. 80 Adding volumes ......................................................................................................................................................... 81



© 2012 SAP AG 6

Removing volumes .................................................................................................................................................... 81

DB2 10 Object-Level FlashCopy for Inline Image Copies in Combination with BACKUP SYSTEM ............ 81

BACKUP SYSTEM with Mirrored Volumes (PPRC and RPFC) ................................................................... 84 Setup lab environment ............................................................................................................................................... 85

Setup Summary ......................................................................................................................................................... 85

Run RPFC testcase ................................................................................................................................................... 86

Ensuring Volumes always Remain in Full Duplex Mode with BACKUP SYSTEM and PPRC ..................... 92

DB2 system-level recovery when a table was reorganized between SLB and recovery target point ........... 93

Use DB2 Recovery Expert for Recoverability Health Checks....................................................................... 99

Use DB2 Recovery Expert to Create Image Copies from System-Level Backups ..................................... 103 Using DB2 Recovery Expert to create image copies from system-level backups .................................................... 103

Using fast replication methods to back up objects ................................................................................................... 107

DB2 10 Backward Recovery while Incremental FlashCopy Relationships Exist ........................................ 111

Federated Database Recovery to any Point in Time for related SAP Systems .......................................... 113

BACKUP SYSTEM using Space-Efficient FlashCopy with NOCOPY (VERSION=0) ................................ 114 Sample job invocation of DB2 BACKUP SYSTEM ................................................................................................... 114

Recovering Single Table Using RECOVER Utility with Space-Efficient DASD .......................................... 116

DB2 10 Object-Level Recovery from FlashCopy Image Copy while SE FlashCopy Relationship Exists... 119

DB2 10 Object-Level Recovery from FC Image Copy after SE FC Relationship has been Withdrawn ..... 123

DB2 RESTORE SYSTEM with z/OS 1.12 Fast Reverse Restore ............................................................. 124

Verifying RESTORE SYSTEM, especially the Cases Restore from Tape and "not logged" Points ........... 129

Recover Single-Object Based on System-Level Backup and Exploiting Archive Logs .............................. 131

Embedded Nearline Storage – Taking Aged Table Partitions out of HSM Copy Pool ............................... 134

Refresh Development System from large SAP BW Productive System ..................................................... 137

Preparation to run the Cloning Stored Procedure ....................................................................................... 140

ABAP Sample Program to invoke the Cloning Tool Stored Procedure ...................................................... 142

Use Case: DB2 Subsystem Cloning Based on a Previously Taken System-Level Backup ...................... 143 Parameter files for cloning stored procedure CLONE_SS: ...................................................................................... 144

Cloning JCL jobs generated by the cloning stored procedure .................................................................................. 146

Troubleshooting ....................................................................................................................................................... 151

Use Case: DB2 Subsystem Cloning using FlashCopy Consistency Group .............................................. 153 Cloning config files for cloning stored procedure CLONE_SS: ................................................................................ 153

Generated Jobs ....................................................................................................................................................... 154

Troubleshooting ....................................................................................................................................................... 155

Use Case: DB2 Subsystem Cloning based on a System-Level Backup on Tape ...................................... 156 Restore system-level backup on tape to other volumes on disk .............................................................................. 156

Create Cloning Tool journal and reclip target volumes ............................................................................................ 158

Cloning steps generated by cloning stored procedure ............................................................................................. 160

Generated Jobs ....................................................................................................................................................... 160

Use Case: Cloning of DB2 Data Sharing Groups ....................................................................................... 168 Data sharing config files ........................................................................................................................................... 168

Generated Jobs ....................................................................................................................................................... 170



© 2012 SAP AG 7

Table of Figures

Figure 1. Integrated DB2 Backup and Recovery Solution for SAP .................................................................. 12

Figure 2. Beginning Stages of FlashCopy Process .......................................................................................... 13

Figure 3. Incremental FlashCopy ..................................................................................................................... 14

Figure 4. Relationship between the Different FlashCopy Groups .................................................................... 15

Figure 5.System-level backup solution based on volume-level FlashCopy ..................................................... 16

Figure 6. Object-level backups based on data set FlashCopy, introduced with DB2 10.................................. 16

Figure 7. FlashCopy behavior for full copy and nocopy ................................................................................... 18

Figure 8.Using bitmaps to keep track of updated CKD tracks for source volume ............................................ 19

Figure 9. Interplay of BACKUP SYSTEM and FlashCopy Image Copy ........................................................... 20

Figure 10. Repository and space-efficient volumes ......................................................................................... 22

Figure 11. Space requirements for classic FlashCopy compared to repository ............................................... 23

Figure 12. Situation before fast reverse restore ............................................................................................... 23

Figure 13. Faster recovery with fast reverse restore ........................................................................................ 24

Figure 14. FlashCopy before RPFC: volumes in duplex pending state while copying ..................................... 25

Figure 15. HyperSwap is always possible with RPFC: volumes remain in full duplex state ............................ 26

Figure 16. SMS group types: Pool and Copy Pool Backup ............................................................................. 27

Figure 17. Dump to tape ................................................................................................................................... 28

Figure 18. Sample SMS Configuration – Option #1 ......................................................................................... 33

Figure 19. Sample SMS Configuration – Option #2 ......................................................................................... 34

Figure 20. Test Environment 1: Backup, Recovery and DR Scenarios ........................................................... 37

Figure 21. Test Environment 2: Minimum Backup and Recovery/Restore Scenarios ..................................... 38

Figure 22. Test Environment 3: Backup Cloning .............................................................................................. 38

Figure 23. Test Environment 4: Recovery Expert and Cloning Scenarios, with Data Sharing ........................ 39

Figure 24. Overview RPFC testing environment .............................................................................................. 86

Figure 25. Timeline for single-object recovery ................................................................................................ 118

Figure 26. Single-Object Recovery Exploiting Archive Logs .......................................................................... 131

Figure 27. Embedded Nearline Storage for SAP BW on DB2 for z/OS ......................................................... 138

Figure 28. Cloning in an IBM System z environment, using the DB2 Cloning Tool ....................................... 139

Figure 29. Product parameter file WIETZ.JCL.PDS(CKZPPARM) ................................................................ 144

Figure 30. Cloning parameter file WIETZ.JCL.PDS (CKZCPARM) ............................................................... 145

Figure 31. DB2 system parameter file WIETZ.JCL.PDS (DB2SYS)) ............................................................. 146

Figure 32. Cloning parameter file WIETZ.JCL.PDS(CKZCPAR2) ................................................................. 154

Figure 33. Generated cloning job WIETZ.CLONE4.JCL(ST001) ................................................................... 170






© 2012 SAP AG 9

Acknowledgements

Thanks to the following people. This documentation would not be possible without their contributions.

Yufen Davis, IBM Tucson Lab

Florence Dubois, IBM UK

Harald Duvenbeck, IBM Deutschland Research and Development

Bill Franklin, IBM Silicon Valley Lab

Jeff Josten, IBM Silicon Valley Lab

Dr. Bernd Kohler, SAP AG

Laura Kunioka-Weis, IBM Silicon Valley Lab

Ralf Marks, IBM Deutschland GmbH

Thomas Raith, IBM Deutschland Research and Development

Haakon Roberts, IBM Silicon Valley Lab

Tage Serup, L.A. International

Steve Speller, Rocket Software

Dietmar Stemmler, IBM Deutschland Research and Development

Jeff Suarez, IBM Tucson Lab

Glenn Wilcock, IBM Tucson Lab

Petra Wood, SAP AG

Karola Wunderlich, IBM Deutschland Research and Development



© 2012 SAP AG 10

1. Introduction

Among the key capabilities of database systems relevant for SAP applications are non-disruptive and efficient backup methods, automated and fast recovery and point-in-time recovery (PITR), and fast system cloning. As strategic solutions, DB2 for z/OS provides the integrated BACKUP SYSTEM and RESTORE SYSTEM utilities, which internally rely on DS8000 FlashCopy and z/OS DFSMShsm technology. The DB2 Cloning Tool and the DB2 Recovery Expert for z/OS can be used to further facilitate, automate and accelerate many of the tasks. This document provides hands-on tips and tricks for using the above mentioned DB2 utilities and tools in SAP environments in the most beneficial way. In addition, it covers how to take advantage of the latest technical capabilities of these tools. Moreover, a particular focus is set on demonstrating the interplay of these components to ensure seamless backup, recovery and cloning solutions for SAP customers. This useful information is intended to help customers implementing and managing their specific solutions. The observations and recommendations in this whitepaper also apply to a number of non-SAP applications. The Casebook first discusses the general SAP requirements in the areas of backup, recovery and database system cloning. After describing the DB2 backup and recovery solution at a high level, the fundamental FlashCopy functionality and its variations are introduced. This is followed by a description of the test environment that was used to run the end-to-end tests. Subsequently, the basic operations and commands to take a system-level backup and to monitor its execution are described. Then different use cases are defined that are typical for different SAP customer scenarios like high-end SAP production systems, SAP test environments and SAP homogeneous system copy. For each use case, typical configurations of how to use the different utilities and tools are described to match the needs of the specific use case. Also, detailed tips and tricks are given. The use cases are based on the latest IBM technologies including DB2 10 for z/OS, z/OS 1.13 and DS8800. Use cases related to older technologies are covered in the SAP Casebook for DB2 Backup, Recovery and Cloning from 2008. The 2008 document also describes the history of DB2 backup technologies that had been used by many SAP customers in the past and how its evolution into the standard DB2 BACKUP SYSTEM and RESTORE SYSTEM utilities, which natively embed the FlashCopy technology of DS8000 or equivalent functionality of other disk vendors. The operational samples provided here are the result of a workshop that took place at the IBM System z Technology Center for SAP applications at the IBM Germany Research & Development Lab in Boeblingen in November and December 2011.



© 2012 SAP AG 11

2. General SAP Requirements for Database Backup, Recovery and Cloning

SAP applications basically use the database system to store their data while ensuring the transactional integrity of the data. This is similar to many other applications. However, some aspects of how SAP uses database systems may be different from other applications.

Backup and recovery are processes that ensure that an SAP database can be restored with minimal disruption in operations after any kind of hardware, software, operational, or environmental error or outage. These processes are crucial since they determine system availability and reliability. Therefore, your IT experts must first develop a solid understanding of these processes, and then carefully assess their requirements. Using skillful planning, they can then develop their use of these procedures to provide the maximum benefit for their SAP on DB2 z/OS environment.

Typically, SAP does not define foreign key relationships at the database level. The knowledge about which tables semantically belong together and hence always need to be recovered at the same time is embedded within the SAP application programs. Therefore, database systems that hold SAP data usually need to be recovered in their entirety. Recovering just a subset of the tables would break the transactional integrity of the system.

There are a few exceptions to this general rule. For example, single tables can be recovered when a specific SAP transport can be pinpointed that has logically corrupted the data of one or a few tables. However, SAP support always needs to be consulted in cases like these to ensure that no data is compromised as part of the recovery activities.

If SAP business transactions span multiple SAP applications (or systems), the database systems used by these SAP systems always need to be recovered using the same point-in-time to which they are recovering.

In SAP environments, it is common to create clones of SAP systems, which themselves include clones of the database system. This activity is called SAP homogeneous system copy. For example, test or training systems are created by cloning production systems. The database content of these cloned test systems may be periodically refreshed by the SAP production systems to ensure that the latest level of the production system is covered by functional or stress testing.

Moreover, cloning of database systems can become crucial if data is logically corrupted by user errors or errors in application programs. In this scenario, the root cause of the logical data corruption would typically be analyzed in a clone of the database system of the SAP production system, which is sometimes called a forensic analysis system or a break-fix system.

The following list summarizes the basic SAP requirements for database systems in the area of backup, recovery and cloning:

Unobtrusive database backup processes

Minimized recovery downtime both at database system and object levels

Ability to easily undo logical application errors

Integrated disaster recovery solution

Online and fast database system cloning

Federated recovery of multiple database systems to current or prior point in time

Database backup solution going hand-in-hand with the disaster recovery solution.



© 2012 SAP AG 12

3. Overview of Strategic DB2 Backup/Recovery/Cloning Solution for SAP

To address the SAP requirements on backup, recovery and cloning, DB2 provides standard utilities that were particularly designed for these scenarios. These utilities are BACKUP SYSTEM, RESTORE SYSTEM and RECOVER. These utilities allow you to create non-disruptive backups based on FlashCopy technology and to restore either the entire DB2 system or specific tables. These utilities are supplemented by the DB2 Cloning Tool to create online clones of DB2 subsystems.

Figure 1 summarizes the latest DB2 backup and recovery solution for SAP. The diagram on the left-hand side shows the main components of the DB2 backup approach. On the right-hand side, you can see how DB2 recovers either the complete DB2 system or a single table.

Figure 1. Integrated DB2 Backup and Recovery Solution for SAP

Overview of Base Technologies of BACKUP SYSTEM and RESTORE SYSTEM Utilities

The DB2 BACKUP SYSTEM utility is a standard utility available with DB2. BACKUP SYSTEM inconspicuously invokes DS8000 FlashCopy to seamlessly and efficiently create database backups. It invokes FlashCopy via the z/OS DFSMShsm fast replication services.

A FlashCopy image is an instantaneous copy of a set of data, taken at a particular point in time. When FlashCopy is started, the relationship between source and target of all volumes is established within seconds. This is done by creating the necessary metadata like a pointer table including a bitmap for the target. Changes are tracked on track level. Once the relationship has been established, DB2 or applications can update data content without compromising the validity of the backup. FlashCopy technology makes sure that before a source volume is updated, the original state of the volume is copied to the target volumes using the bitmap table.

System z

DB2 RESTORE

SYSTEM

Single SAP system per DB2 system

Tap

e

DB2

RECOVER

Ta

ble

System z

DB2 BACKUP SYSTEM

z/OS DFSMS

Single SAP system per DB2 system

DS8000

FlashCopy

• Full

• Incremental

• Space efficient

Tap

e

DS8000

FlashCopy

z/OS DFSMS



© 2012 SAP AG 13

Figure 2 depicts the state when the relationship of the source and target volumes has been established, but no data was physically copied yet. With current technology source and target volume need to be in the same physical box.

Figure 2. Beginning Stages of FlashCopy Process

While DS8000 FlashCopy can generally be performed at volume or data set level - by copying data from the source volume to a target volume and preserving the image - BACKUP SYSTEM always invokes FlashCopy at volume level. FlashCopy technology also provides incremental FlashCopy. The initial incremental FlashCopy invocation creates a full base backup and starts recording modifications to keep track of changed volumes. Subsequent invocations of incremental FlashCopy only copies changed tracks to the backup volumes overriding the initial full base backup.

The advantages of incremental FlashCopy are:

Considerable reduction of the elapsed time during a physical copy

Minimization of the I/O impact of FlashCopy on concurrent data access

Note, however, that the impact of FlashCopy is generally fairly low as FlashCopy I/Os have a lower priority than other I/O operations. While one volume can usually be in up to 12 FlashCopy relationships concurrently, only a single FlashCopy target can be incremental. Besides the IBM DS8000 product family there are other storage vendors like EMC and HDS who offer products that support the FlashCopy APIs, and can also be used for DB2 BACKUP SYSTEM and RESTORE SYSTEM.

t0 t0 t0 t0 t0 t0

data

source target

data

1 1 1 1 1 1

bitmap

FlashCopy established at time t0 (time-zero)

timet0

Background copy will copy all time-zero data from source to target



© 2012 SAP AG 14

Figure 3 visualizes incremental FlashCopy.

Figure 3. Incremental FlashCopy

A further option is space-efficient FlashCopy, which reduces the size of the backup. It is described in more detail below.

DFSMShsm is a component of the z/OS operating system. Its functionalities, which are related to this Casebook, are mainly based on the DFSMSdss component of z/OS that provides lower level access to the disk. DFSMShsm offers t fast replication services. This technology is intended to allow DB2 or other middleware products to efficiently copy and restore sets of storage groups without having to worry about the details of the disk subsystems. The fast replication services use the concept of a copy pool, which is a defined set of storage groups that contain data that DFSMShsm can backup and recover collectively. The copies are written to a copy pool backup storage group.

A VERSIONS attribute that is associated with each copy pool specifies the number of backup generations that are kept in the backup storage group on disk. There is also an option to set VERSIONS to 0. The effect of this setting is that backups are not fully materialized in the backup storage group, which allows you to create tape backups without backup on disk (FlashCopy NOCOPY mode). Only tracks on the source volumes that are being changed are copied to the target volumes prior to the change. However, the size of the backup storage group still needs to be at least as large as the source copy pools. For more information about copy pools, see the IBM manual z/OS DFSMSdfp Storage Administration.

DB2 invokes the FlashCopy functionality from DS8000 via the fast replication services of z/OS DFSMShsm. The basic construct of these services is the copy pool. A copy pool is a set of SMS storage groups (up to 256) that are processed as a unit. A copy pool backup storage group is associated with every copy pool and contains one or more backups of the copy pool. The fast replication services provide a number of commands that can be invoked from DB2 or from other programs. The main commands are as follows:

FRBACKUP creates a copy for each volume in a copy pool. This command invokes the ADRDSSU COPY FULL function with the parallel option and completes when the fast replication relationships of the volumes have been established. Its TOKEN parameter identifies the version

FRRECOV recovers the backup that is specified by the TOKEN back to the source volumes.

Figure 4 visualizes the relationship between the storage group, copy pool and copy pool backup storage group. In this example, it is assumed that the VERSIONS attribute of the copy pool CP1 is set to 2. Therefore, the storage group copy pool backup needs to have twice as many volumes as the source copy pool. You can also share a storage group copy pool backup for multiple copy pools if the FRBACKUP command is executed on the same z/OS LPAR.

As of z/OS 1.13, you can also consider using a single storage group copy pool backup among multiple copy pools that are backed up on multiple z/OS LPARs.

Initial Incremental FlashCopyBackground copy with change

recording enabled

Initial copy Copy changed data

Incremental FlashCopyCopies only changed data



© 2012 SAP AG 15

Figure 4. Relationship between the Different FlashCopy Groups

BACKUP SYSTEM works in an online fashion and allows concurrent applications to continue to access the database for read and write operations. It creates a crash-consistent system-level backup whose consistent state is established during recovery. This utility has been optimized for SAP since it addresses the need to take system-level non-disruptive backups and since the backups that it creates can restore both the entire DB2 system or single table to an arbitrary prior point in time. It represents the primary utility for making DB2 backups in SAP environments. Nevertheless, it can also be used in non-SAP environments. All DB2 data sets must be SMS-managed data sets and be part of DB2 DFSMShsm copy pools. BACKUP SYSTEM requires that you define two copy pools:

A copy pool for the data called DSN$location_name$DB containing all application data and the DB2 catalog and directory and corresponding ICF catalogs.

A copy pool for the log called DSN$location_name$LG containing the DB2 log data sets, BSDS, (optionally) DB2 libraries and corresponding ICF catalogs.

This utility gives you the option to either copy the $DB copy pool only, or to copy both copy pools. The latter is required if you would like to clone the DB2 at system-level or if you would like to restore DB2 in its totality to the point in time when the last backup was created. If you would like to restore the DB2 system or an object to an arbitrary point in time, the first option is sufficient.

Furthermore, BACKUP SYSTEM allows you to dump existing or new backups to tape. Additionally, it is capable of exploiting incremental FlashCopy. Therefore, BACKUP SYSTEM is evolving into a single point of control allowing you to accomplish more and more FlashCopy and backup-related tasks directly from within DB2. The SAP DBA Cockpit also provides support for the BACKUP SYSTEM utility as described in SAP Note 1225355. Error! Reference source not found.The following figures summarize the relationship between FlashCopy, DFSMSdss, DFSMShsm and DB2 BACKUP SYSTEM.

Copy pool CP1

Storage group Src2

Type:

POOL

Copy pool backup storage group name:

CPB1

Storage group Src1

Type:

POOL


CPB1

Storage group CPB1

Type:

COPY POOL BACKUP


N/A



© 2012 SAP AG 16

Figure 5.System-level backup solution based on volume-level FlashCopy

With DB2 10 the system-level backup solution has been complemented by additional object-level backups that can be used for inline image copies of DB2 utilities.

Figure 6. Object-level backups based on data set FlashCopy, introduced with DB2 10

The RESTORE SYSTEM utility of DB2 recovers the system to either an arbitrary prior or current point in time. It automatically determines the best backup available to minimize the elapsed time of a recovery, DB2 always recovers or restarts consistently. This means that after a recovery or restart, there is never uncommitted data and all data that was committed before the recovery target point is preserved.

Federated database recoveries of multiple DB2 subsystems -- which do not need to belong to the same data sharing group -- and database system cloning activities are based on the same backups that are created by the BACKUP SYSTEM utility.

Besides restoring entire DB2 subsystems, the backups created by BACKUP SYSTEM can also be used by the DB2 RECOVER utility to recover a single table space, partition or a set of table spaces. So the system-level backups can be used for both purposes.

Starting with DB2 10, DB2 object-level utilities can create FlashCopy image copies by invoking data set-level FlashCopy. The BACKUP SYSTEM utility always invokes FlashCopy via DFSMShsm whereas the object-level utilities such as COPY and REORG invoke FlashCopy directly via DFSMSdss. The FlashCopy image copies can nicely complement the DB2 backup approach based on BACKUP SYSTEM and RESTORE SYSTEM since they allow customers to take advantage of FlashCopy for the inline image copies that are

System z

BACKUP SYSTEM

z/OS DFSMShsm Fast Replication Services

z/OS DFSMSdss

FlashCopy (full, incre-mental, space efficient)

DB2 subsystem /

data sharing group

hsm copy pool

Volume-level FlashCopy

Efficiently copies data

DS8000

Tape

DB2 via hsm

DB2 via dss

processes

processes

invokes

System z

Object-level utilities (COPY, REORG, REBUILD, ...)

z/OS DFSMSdss

FlashCopy (full)

Data set-level FlashCopy

Efficiently copies data

DS8000

Single tablespace,

partition or index

processes

invokes



© 2012 SAP AG 17

required by utilities like online REORG, or for image copies which are required after not logged actions. That way you can fully exploit FlashCopy for all backup purposes.

DS8000 FlashCopy Functions and Options

Most modern storage subsystems offer a function to create a snapshot of data in a very short time. DFSMS supports snapshot functionality from different storage subsystems from different vendors, but it is optimized for the use of FlashCopy, IBM’s snapshot functionality of the DS8000 storage subsystem. During the tests DS8000 systems were used. Note that FlashCopy can only be used if this function is licensed for the storage subsystem. There is also a space-efficient FlashCopy functionality which requires a different license.

We distinguish two types of FlashCopy:

Volume FlashCopy The DB2 BACKUP SYSTEM and RESTORE SYSTEM utilities work on complete volume level and require FlashCopy.

Data set FlashCopy FlashCopy on this level is conditional and based on the parameter setting, like FASTREPLICATION(PREFERRED).

There are several ways how FlashCopy can be established: DS8000 GUI or Command Line Interface (DSCLI), TSO commands, or DFSMSdss and DFSMShsm. We used DB2’s BACKUP SYSTEM utility which calls DFSMShsm which in turn calls DFSMSdss to do the FlashCopy. DB2’s BACKUP SYSTEM utility is based on VOLUME level FlashCopy. During the NIP (Nucleus Initialization Phase) z/OS reads the device characteristics of the storage subsystem, so DFSMS “knows” if FlashCopy is available or not. In general, DFSMS uses FlashCopy if it is available but uses a conventional copy if the function is not available or if FlashCopy cannot be used. DB2 BACKUP SYSTEM and FRBACKUP require FlashCopy. If it is not available, the backup will fail. Note that FlashCopy can only be used if target volumes are available within the same storage subsystem as the source volume. For DB2 object-level backup and recovery, if you want the system to use FlashCopy and to fail if this is not possible, you can use the FASTREPLICATION(REQired) parameter instead of the default FASTREPLICATION(PREFerred). For volume copy we can further distinguish the target volume type as:

a normal volume which requires the same amount of storage as the source volume; or

a space-efficient volume which requires a repository where only the changed data are stored. FlashCopy onto a space-efficient volume must be explicitly allowed, but this is handled automatically by the utility.

FlashCopy source and target volume are related. In one case, this relationship ends automatically (full copy, see below), but in all other cases the relation lasts until it is withdrawn. FlashCopy always consists of two parts:

The logical copy completes in a few milliseconds by just copying pointers to the data and establishing bitmaps for each track. After the logical copy is complete, the target volume is available for reads and writes. The physical copy process can be different depending on the options chosen.

When a FlashCopy relationship is established, you have to specify how FlashCopy should work. You can do different types of FlashCopy:

Full copy: After the logical copy is completed, a background process starts and copies all data from the source to the target, track by track. If there is an update on the source that was not yet copied, the data that is going to be updated is copied immediately (“copy-on-write”) before the update takes place on the source. In that case, the sequential background copy continues until all data is copied from source to the target. Note that this “copy-on-write” is done during the de-staging process of the



© 2012 SAP AG 18

data from the write cache (NVS, non-volatile storage) to the disks. Since a write is a cache hit, this copy-on-write has no direct influence on performance. When all data has been copied, the relationship between source and target ends. To keep track of which Count Key data (CKD) tracks have already been copied to the target volume the storage subsystem maintains a bitmap for the target volume for each track. This bit indicates where the valid track can be found, on the source or target volume.

NOCOPY: When you do a FlashCopy NOCOPY - for example in DFSMSdss by specifying the FCNOCOPY parameter - there is no proactive background copy task. If there is an update on the source, the data that is going to be updated is copied (“copy-on-write”) before the update on the source takes place. This is true only for the first update, subsequent updates of the same data are not copied. The relationship between source and target does not end until all data is modified (copied) or the relationship is withdrawn by a command. If the BACKUP SYSTEM utility is used with the DUMP or DUMPONLY option, the FlashCopy target volumes are dumped to tape and the FlashCopy relationship is terminated (withdrawn). A reverse FlashCopy is possible, but after the reverse FlashCopy completes, the FlashCopy relationship is withdrawn. Since the original FlashCopy target volume was only partly filled with data, the volume is no longer usable, and it must be reinitialized. If DFSMShsm does the “withdrawal”, it automatically triggers the initialization process.

The next figure shows the FlashCopy behavior for full copy and nocopy

Figure 7. FlashCopy behavior for full copy and nocopy

When a read operation is issued to a FlashCopy target volume, the actual read is performed from the source volume or target volume depending on the bit in the bitmap representing the track. If the track was not yet copied, the data is fetched from the source. All this is transparent to z/OS.

Source FlashCopy command issued

Copy is immediately available

(but target volume is physically

empty)

DB2 reads and writes from source

only.

Note that DS8000 can read from

and write to both source and

target copy

For FULL copy, background copy

starts.

For NOCOPY, only changed

tracks are copied on write.

When copy is complete for a

FULL copy, relationship between

source and target ends

Target

(empty)

Bitmap

Tim

e

Write

Read



© 2012 SAP AG 19

Incremental: When incremental FlashCopy is used for the first time - for example by specifying the FCINCREMENTAL parameter in DFSMSdss -, a first initial full copy is done. Subsequent incremental FlashCopy functions just copy the data that has changed since the last incremental FlashCopy. The DS8000 keeps track of the changed CKD tracks by maintaining bitmaps for the source and the target in non-volatile storage about the tracks that have changed. If some data of a track were changed, a bit is set to indicate that this whole track needs to be copied when a new incremental FlashCopy is started.

Error! Reference source not found. shows how bitmaps for both the source and the target volume are sed to keep track of updated CKD tracks. If an incremental FlashCopy is performed, the bitmaps of the source and target volume are “OR”ed and all tracks that are different between source and target are copied from the new source to the new target. The source volume can only be in one incremental relationship.

Note that in this environment, there won't be any write updates to the target volume since it is a backup volume.

Figure 8.Using bitmaps to keep track of updated CKD tracks for source volume

If a volume is the target of a FlashCopy relationship and is also intended to be the source of another FlashCopy relationship, this is referred to as cascaded FlashCopy relationship. In certain situations, this relationship can play a role, e.g. if you want to restore a data set for a DB2 object-level recovery while a volume-level FlashCopy relationship exists from DB2 source volumes to DB2 target volumes. Note that DS8000 does not support cascaded FlashCopy relationships.

Bitmap Bitmap

Source Target

Incremental

FlashCopy

no I/O

Resync

Write

The initial incremental

FlashCopy copies everything

in the background.

Writes to source are tracked

in a bitmap.

With next incremental

FlashCopy the tracks that are

marked in the bitmap are

copied to target (resync).

...next incremental FlashCopy ...

t (time)

First incremental FlashCopy ...



© 2012 SAP AG 20

Figure 9. Interplay of BACKUP SYSTEM and FlashCopy Image Copy

Data Set FlashCopy

For z/OS, the IBM DS8000 storage subsystem also supports Data Set FlashCopy. DFSMSdss uses FlashCopy for data sets by default a) if the FlashCopy function is available, b) the target data set can be allocated within the same storage subsystem, and c) the data set is not modified during the FlashCopy. In some cases DFSMSdss decides that it must modify the data set during a copy, for example to increase the control area (CA) size. In this case DFSMSdss will not use FlashCopy even if you request it.

Neither incremental FlashCopy or Space-efficient FlashCopy are not supported for Data Set FlashCopy.

DASD Volume Setup

If you want to use FlashCopy operations on data set level (RECOVER of single objects from a system-level backup (SLB), see Recovery of Single Tables or Indexes from a System-Level Backup on page 70), pay attention to two special administration data sets on each DASD volume.

The first data set is the VTOC (=Volume Table Of Contents). This one needs to be large enough to accommodate all data sets which are on the volume. The VTOC should have a VTOC index for better performance. The index can be created during ICKDSF INIT.

The second and the more performance critical data set is the VVDS (=VSAM Volume Data Set). It contains a VVR (=VSAM Volume Record) for every VSAM data set on the volume or a NVR (Non-VSAM Volume Record) for each SMS-managed Non-VSAM data set on the volume. The VVDS is always named SYS1.VVDS.V<volser> and can be pre-allocated. Its size should be roughly adjusted to the number of data sets which are on the volume. The VVDS is an entry sequenced VSAM data set, and is managed by the CATALOG address space (refer to CAS MODIFY commands, like VCLOSE, etc.). The VVDS of source and target volume must be read completely by DFSMSdss during physical data set copy operations. Therefore the VVDS should not be over-allocated from a performance perspective, if it is allocated explicitly by the user and not implicitly by system. Also, DASD volumes should be appropriately initialized before they are included in a copy pool. A very large, but empty VVDS should be reset or decreased.

DB2 copy pools

BACKUP SYSTEM

Invokes volume-level

FlashCopy

Storage group

Type:

COPY POOL BACKUP

RECOVER Invokes data set-level FlashCopy



© 2012 SAP AG 21

Performance Considerations

The different ways to set up FlashCopy can also have impact on your production performance.

Full copy: With full copy the background copy task keeps the disk drives (source and target) as well as the device adapter quite busy for some time until the background copy task completes. The background copy task has a low priority, but it could negatively impact production I/Os, mainly for reads. Full copy should be used if you want to create test systems, for example.

NOCOPY: A NOCOPY FlashCopy does not have a background copy task. However, as updates to the source are handled as “copy-on-writes”, each first write to a source track causes a background copy of that track. Since writes are cache hits and the de-staging process from cache to disk is asynchronous, this copy-on-write has no influence on the response time to the host – as long as the disks are not overloaded. For space-efficient volumes, there is the additional overhead of maintaining tables to keep track of where the data is copied within the repository. NOCOPY or space-efficient should be used if the copy is created to dump the data to tape. If you do not need the copy on disk after the dump completed, you should withdraw the source to target relationship to minimize any performance impacts for your production. BACKUP SYSTEM DUMP withdraws the FlashCopy relationship automatically.

INCREMENTAL: Incremental FlashCopy has the least performance impact. After the initial copy has completed, further FlashCopy functions copy only tracks that had been modified on the source volume, which is usually only a small fraction of the total capacity. If data is modified on the source volume, only a bit is set in the DS8000 bitmap for the source volume to indicate that the source track was modified. So incremental FlashCopy is virtually as efficient as full FlashCopy but further benefits from the reduced amount of data that needs to be copied. You should consider using incremental FlashCopy if you need to create copy on a periodic basis and the interval is not too long. For example, if you create a copy daily or every other day, then using incremental FlashCopy works very well.

FlashCopy Consistency Groups

Normally your database will not fit on just one volume. To take a FlashCopy of several volumes with write consistency between the volumes, consistency groups can be used. Actually there is not really a group. For each FlashCopy establish command a parameter is passed that causes the storage subsystem to stop write I/O to the FlashCopy source volume. In case of DFSMSdss this parameter is FCCGFREEZE (or just FCFREEZE). As FlashCopy commands for several FlashCopy source/target volume pairs are sent to the storage subsystem (e.g. by DFSMSdss COPY), one source volume after the other is write disabled, thus entering a “Long Busy” state. Write I/Os to volumes that are write disabled hang. Write I/Os to not yet flashcopied volumes that depend on the completion of I/Os to already flashed volumes (dependent I/Os) are not started. This preserves database integrity.

The volumes are frozen until the “LongBusy” timer expires (by default after 120 seconds). Since you do not want to wait so long with write I/Os stopped, your last command after the series of COPY commands should be a command to end the “LongBusy” state. When all volume copy operations have completed, you can use the DFSMSdss CGCREATED command to allow I/O activity to resume on the frozen volumes. This command must be sent to just one volume within one LCU (Logical Control Unit) to unfreeze all volumes within this LCU. The command must be sent to all LCUs that have FlashCopy source volumes.

If DB2’s BACKUP SYSTEM utility is used, Consistency Groups are not used since DB2 can produce consistent data with the help of the logs. In some DB2 cloning cases, it may be attractive to use FlashCopy Consistency Groups to circumvent cascaded FlashCopy relationships.

Space-Efficient Volumes and Space-Efficient FlashCopy

When a DS8000 is configured, logical volumes are created within the DS8000. The first step, however, is to create RAID arrays and format these arrays be creating EXTENTS which have the size of a 3390 Model 1. Many EXTENTS of several arrays make up an Extent Pool. When a logical volume is defined, for example a 3390 Model 27, several extents - in this case 27 - are taken from the Extent Pool utilizing as many arrays as



© 2012 SAP AG 22

possible. This is called Storage Pool Striping because the logical volume is distributed to many physical disk drives. The Extents for the volume are allocated on physical storage when the logical volume is created There is yet another type of volume, called space-efficient volume. To be able to define space-efficient volumes, the storage administrator must define a special volume within an Extent Pool, a so called Repository. A Repository has a real capacity which is allocated on physical disk when it is created, and a virtual capacity. Within the Repository the storage administrator can define virtual volumes called space-efficient volumes. While the space for the Repository is allocated when it is created, space for space-efficient volumes within the Repository does not consume space when these volumes are defined. Only when data is written to these volumes will data be written to the Repository as well

Figure 10. Repository and space-efficient volumes

The sum of defined capacity can be larger than the capacity available within the Repository. The capacity of the Repository is usually much smaller than the source volume capacity. Hence there are much more I/Os going to the Repository compared to the source volumes. You need fast disk drives to cope with this higher I/O density and you should dump the data to tape immediately. Otherwise your production performance may suffer.

For z/OS, normal provisioned volumes and space-efficient volumes just look the same. Only with the IDCAMS LISTDATA SPACEEFFICIENTVOL command you can see that a volume is thin provisioned. No explicit action needs to be taken with DFSMShsm. In a VERSIONS=0 environment, HSM will automatically allow space-efficient volumes to be selected as target volumes.

However, space-efficient volumes are not recommended for normal production volumes. They can be used as target volumes for FlashCopy full copy operations. FlashCopy to space-efficient volumes must be explicitly allowed. In DFSMSdss you can allow this with the FCSESTGOK(FAILrelation) option (FlashCopy Space Efficient Storage OK). In case this option is used and the Repository is full, the target volume is discarded and copy-on-write stopped

Extent

Pool

Arrays

Repository for

space-efficient

volumes

striped across

arrays

normal

Volume

Virtual repository capacity

Used

tracks

Allocated tracks

Space-

efficient

volume



© 2012 SAP AG 23

Figure 11. Space requirements for classic FlashCopy compared to repository

FlashCopy Fast Reverse Restore

Usually, a FlashCopy backup can only be used for a recovery when its physical background copy has completed. Depending on the size of the data that is copied, this may take some time and with Space-efficient FlashCopy, this state is never reached. Fast reverse restore (FRR) provides the capability to reverse the direction of an existing FlashCopy relationship and restore the source volume to the point-in-time state when it was last flashed to the target volume without waiting for the background copy to complete. Once a fast reverse restore has completed, the contents of the backup volume, which is the original FlashCopy target volume, becomes invalid. This allows DB2 to recover much quicker in case the physical background copy of FlashCopy has not yet completed before RESTORE SYSTEM or FRRECOV is invoked. z/OS 1.12 introduced DFSMShsm support for fast reverse restore of a copy pool in both COPY and NOCOPY modes. FRR is also supported for space-efficient DASD and Incremental copy.

There is a new HSM copy pool setting to enable FRR. However, fast reverse restore cannot be used in combination with Remote Pair FlashCopy. Figure 12 visualizes the situation when fast reverse restore is not used:

Figure 12. Situation before fast reverse restore

Source

volumes

Classic

FlashCopy

target volumes

Source

volumes

Repository IBM

FlashCopy SE

virtual target

volumes

Space needed for

FlashCopy targets

Space needed for

FlashCopy targets

Copy Pool Application

Initiate

FlashCopyFlashCopy

Relationships

Established

Disk

Recovery

Available

Background Copy

Time



© 2012 SAP AG 24

With the introduction of fast reverse restore, the recovery can be faster as the following figure shows:

Figure 13. Faster recovery with fast reverse restore

FlashCopy onto a Metro Mirror Primary Volume

Some customers want to mirror all data including the volumes at the primary site that are used as FlashCopy target volumes e.g. for backup. This makes sense when HyperSwap is used, and primary and secondary sites are exchanged. In this case it is desirable to have the complete environment on both sites. This also requires FlashCopy target volumes to be mirrored. FlashCopy onto Metro Mirror primary volumes must be explicitly allowed. In DFSMSdss, for example, one has to specify the FCTOPPRCPrimary(option) parameter.

As an option you can specify how the FlashCopy will be handled. On older microcode levels the synchronicity between the FlashCopy target volumes at the primary site and the secondary site could not be preserved. The volume pair status changed from DUPLEX to PENDING whenever the background copy process between the FlashCopy source and target volumes was active and the writes to the FlashCopy target volumes were transferred across the remote mirroring links to the secondary site.

Remote Pair FlashCopy (also known as Preserve Mirror)

Disaster recovery technologies like GDPS usually operate at site level. If one site goes down, the other site takes over. Consequently, it can be attractive to design data centers in a symmetric fashion and also to mirror database backups from one site to the other. Even before the introduction of Remote Pair FlashCopy (RPFC) it was possible to take a FlashCopy backup while the FlashCopy target volumes are the source of a PPRC data mirroring relationship (note that PPRC is also known as Metro Mirror). However, these volumes were in duplex pending state while the FlashCopy relationship persisted. The existence of duplex pending volumes can prevent GDPS from doing a HyperSwap.

Copy Pool Application

Initiate

FlashCopy

FC

Relationships

Established

Disk

Recovery

Available !!

Background Copy

Time



© 2012 SAP AG 25

Figure 14. FlashCopy before RPFC: volumes in duplex pending state while copying

With RPFC, the volumes always remain in full duplex state. Therefore, HyperSwap is always possible. Rather than performing the physical background copy of FlashCopy on the primary site and mirroring the changed volumes of the FlashCopy backup to the secondary site, RPFC ships the FlashCopy command to the secondary site. Then the physical background copy is performed locally on the primary site and on the secondary site (see next figure).

To avoid the physical movement of data from the Metro Mirror primary to the Metro Mirror secondary when the Metro Mirror primary becomes the target of a FlashCopy, an inband FlashCopy command is generated to trigger a FlashCopy operation on the remote site rather than mirroring the data associated with the operation. When a FlashCopy command is received to FlashCopy from Local A to Local B, a similar command is generated and sent to FlashCopy from Remote A to Remote B.

The following conditions are required to establish Remote Pair FlashCopy:

Both the Local A / Remote A and the Local B / Remote B Metro Mirror pairs are in full duplex state

The Remote A and Remote B volumes are in the same Storage Facility Image (SFI).

Metro Mirror

(PPRC)

Local Storage Server

Local ALocal A

Local BLocal B

Remote Storage Server

Remote BRemote B

full duplex

duplex pending

while copying

FlashCopy



© 2012 SAP AG 26

Figure 15. HyperSwap is always possible with RPFC: volumes remain in full duplex state

With RPFC you can specify whether you want the old method with the PMN parameter (Preserve Mirror No), or whether you want to preserve the duplex state or fail the command with the PMR parameter (Preserve Mirror Required), or whether the system should TRY to preserve the mirror with the PMP parameter (Preserve Mirror Preferred). Note that not all storage subsystems support FlashCopy onto remote mirror primary volumes.

Compatibility Matrix of FlashCopy Options

The following table shows which FlashCopy options can be used in combination. Note that FRR and RPFC cannot be used together.

FlashCopy Flavor Supported by Fast Reverse Restore (FFR)

Supported by Remote Pair FlashCopy (RPFC)

Full FlashCopy Yes Yes

Incremental FlashCopy Yes Yes

Space-efficient FlashCopy Yes No

Data set FlashCopy No Yes

DB2 BACKUP SYSTEM and DFSMShsm FRBACKUP

The DB2 BACKUP SYSTEM utility and DFSMShsm (which is called by the utility) work on storage pools. There is a copy pool storage group for the source volumes and a copy pool backup storage group for the FlashCopy target volumes.

Metro Mirror

Local Storage Server

Local ALocal A

Local BLocal B

Remote Storage Server

Remote ARemote A

Remote BRemote B

full duplex

full duplex

FlashCopy

FlashCopy

FlashCopy



© 2012 SAP AG 27

Figure 16. SMS group types: Pool and Copy Pool Backup

FlashCopy attributes are associated with the copy pools. If VERSIONS=0 is specified for the copy pool, FlashCopy NOCOPY relations are established between volumes of the copy pool storage group and volumes of the copy pool backup storage group. The volume pairing is automatically done by DFSMShsm. It is important that for each volume size in the source copy pool there is also a volume available in the target copy pool backup

If NOCOPY is used, then the purpose of the copy pool backup storage group is to move the data to tape. The volumes in the copy pool backup storage group can be standard volumes or space-efficient volumes. Do not mix normal and space-efficient volumes in a copy pool backup storage group since DFSMShsm does not distinguish between these different types of volumes.

If fully provisioned FlashCopy target volumes are requested, VERSIONS=1 or more up to VERSIONS=85 can be specified. For example, with VERSIONS=2 you would need at least twice as many volumes in the copy pool backup storage group, and the first backup would use the first half of the volumes and the second backup would use the second half of the volumes. The next backup would overwrite the first set of volumes and so on.

From a performance point of view and if you intend to keep the latest backup also on disk, incremental FlashCopy would be the best choice. A source volume can only be in one incremental relationship. Hence you have to specify VERSIONS=1 for the copy pool and the parameter ESTABLISH FCINCREMENTAL in the BACKUP SYSTEM utility The first invocation of an incremental FlashCopy will do a full copy, but subsequent backups will copy only modified data until you specify END FCINCREMENTAL. Note that you may also specify VERSIONS > 1, but then only one of the backup versions is incremental and the other backups are full.

DUMP to Tape

With the BACKUP SYSTEM utility, you can also specify that the copied volumes are dumped to tape immediately or in a separate step.

If a volume were to be completely copied by FlashCopy, the VOLSER of the source volume would also be copied and the target volume could no longer be online in the same system as there would be two identical

SG1 SG2 SG3

SMS Group Type: Copy Pool Backup

SMS Group Type: Pool

Up to 256 storage

groups (SG) per

copy pool

Used to specify

candidate target

backup volumes for

DFSMShsm fast

replication requests

Backup Pool: CPB1 Backup Pool: CPB2



© 2012 SAP AG 28

VOLSERs. DFSMS has the concept of using DUMPCONDITIONING for FlashCopy. With DUMPCONDITIONING all data except the VOLSER is copied and the VOLSER of the source volume is written somewhere on the target. When the volume is written to tape, it gets the original VOLSER.

When the DUMP is complete, and this is not an incremental copy or space-efficient backup copy pool, the relationship between the source and the target volume is withdrawn. The FlashCopy relationship will persist beyond the completion of the tape dump in the incremental copy and space-efficient backup copy pool configurations. If space-efficient volumes are used, space in the Repository is released for the volume.

Figure 17. Dump to tape

DB2 Cloning Tool for z/OS

The IBM DB2 Cloning Tool for z/OS provides a fast and simple cloning solution that can clone both entire DB2 subsystems and data sharing groups and DB2 tablespaces in an automated and efficient manner.

The DB2 Cloning Tool provides access to cloned data using a fast and sophisticated technique to rename the cloned data, as well as to alter and adapt the target catalog, VTOC, VTOCIX, and VVDS. The DB2 Cloning Tool also updates DB2 internal control information by modifying the directory, BSDS, and internal catalog. Starting with DB2 Cloning Tool 3.1, it provides a DB2 stored procedure called CLONE_SS that allows you to automate the cloning process. Internally, it generates JCL jobs that accomplish certain tasks like the renaming of data sets and executes them in the right sequence.

The following is a partial list of the tasks that the DB2 Cloning Tool accomplishes:

Automates DB2 cloning

Efficiently fixes VOLSER conflicts

Renames and catalogs the data sets of the DB2 cloning target system

Updates all DB2 internal control information (for example, storage groups)

Supports different methods for copying volumes, including the BACKUP SYSTEM utility and FlashCopy Consistency Group

Vol. A

VTOC.A

VVDS.A

Vol. B

VTOC.B

VVDS.B

DFSMSdss

COPY FULL with parameter

DUMPCONDITIONING

optional NOCOPY

Dump

Tape

Vol. A

VTOC.A

VVDS.A

DUMP

FULL

FCWITHDRAW

“Conditioned

Volume“

RESTORE

COPYVOLID

volume

RESTORE

DATASET



© 2012 SAP AG 29

Can reduce the number of data sharing members

Can change a data sharing group to a single DB2 subsystem

DB2 Recovery Expert for z/OS

DB2 Recovery Expert for z/OS V2.2 provides a simple, self-managing recovery solution that allows database recovery operations with minimal disruption. It augments the standard DB2 backup and recovery solution that is based on the BACKUP SYSTEM, RESTORE SYSTEM and RECOVER utilities. DB2 Recovery Expert for z/OS enables intelligent analysis of altered, incorrect, or missing database assets, including table spaces, tables,indexes, and data. It automates the process of rebuilding these assets to a specified point in time, often without taking the database or the business operations offline. DB2 Recovery Expert promotes high availability solutions that companies require for 24x7 operations, and integrated with storage systems, it performs system-level backups instantaneously and without affecting running applications. Valuable host CPU and I/O time is saved by using the storage processor to make the copy instead of z/OS. DB2 Recovery Expert:

Provides backup and recovery solutions that automate and integrate sophisticated storage processor capabilities to:

o Backup data instantaneously to a consistent copy of production without sacrificing availability; and

o Reduce CPU and I/O costs by using the storage processor to copy the data instead of z/OS; and

o Execute fast replication in a safe and transparent manner on behalf of the DBA; and

o Provide the restore of a database or database objects in parallel with the restoration process to minimize recovery time and reduce application down time.

Supports recovery of dropped objects including data to a point in time before the drop.

Reads and analyzes the DB2 log to find quiet times or points of consistency for single or groups of objects.

Can generate SQL-based recoveries to roll-forward or back-out changes to individual tables or groups of objects. This type of recovery is not supported by standard DB2 recovery tools.

Supports recovering an object or application set of objects to a prior version, even if the object’s DDL has changed. A recovery can be performed back to a prior version of an application if the need arises.

Enables recovery to a point in time, given an object to be recovered, including rolling data changes backward or forward to provide for the most efficient recovery.

Analyzes all recovery assets and presents several recovery plans or methods with an estimated cost for each method allowing the user to choose the most appropriate and cost efficient method.

Restores an entire subsystem to a prior point in time from system-level backups created within DB2 Recovery Expert.

Allows for parallel processing of recovery tasks using multiple jobs to reduce elapsed time when performing a recovery.

Coordinates tape usage of recovery jobs to keep repeated tape mounts to a minimum and speed up recovery jobs.

Leverages a cost calculation method that uses estimated metrics to identify more efficient recovery plans.



© 2012 SAP AG 30

Identifies the primary reason why a recovery method is not supported for a particular object.

Provides the option to restore indexes defined as COPY YES from their associated image copies. Restoring an index from an image copy is generally faster than rebuilding it.

Optionally creates image copies of COPY YES indexes after the recovery took place.

Allows enhanced control of image copy processing by accepting up to four image copy data set masks. Includes additional file attributes such as device type, unit type, quantities, SMS information, information, tape information, expiration date, and retention period.

Includes enhancements to the Log Analysis advisor to filter on additional object types including object patterns. This improves the usability of log based quiet time analysis, allowing users to find quiet times and points of consistency.

Includes a recoverability health check report that runs against a system-level backup. This report shows all objects that will need to be recovered with an image copy and all tablespaces that may be unrecoverable after a system restore is performed using the selected system backup.

Automatically determines objects that are not restored properly after a System Restore and produces the JCL necessary to recover/rebuild those objects using image copies.

Performs mapping of DB2 source volumes to ranges of target volumes automatically across all storage platforms. This eliminates the need to update backup profiles when DB2 grows and occupies new volumes.

Optionally drives the encryption process to encrypt a system backup that is being offloaded to tape.

Automatically includes table spaces that have any RI relationship to the selected table space when building recovery JCL from an object profile using the ISPF interface.

Takes advantage of the DFSMSdss backup method to create a DB2 system backup. This method offers the following benefits:

o Creates DB2 system backups without requiring Fast Replication hardware.

o Creates system backups with Fast Replication hardware that does not support Flash but can be driven by DFSMSdss.

Includes a new report that shows all the DB2 table spaces and index spaces included in the system backup.

Creates image copies for a group of DB2 objects using a system-level backup as input. These image copies can be registered in the DB2 system catalog table SYSIBM.SYSCOPY, therefore allowing the copies to be used by any utility that can process DB2 image copies.

Provides support for Database Relationship Analyzer (DRA). This replaces support for DB2 Grouper in prior DB2 Recovery Expert releases. DRA allows grouping of DB2 tables based on the following types of relationships:

o Relationships defined in the DB2 Catalog (such as DB2-defined RI, package, and triggers)

o Trace analysis (SQL Trace relationships)

o Non-enforced RI (user-specified relationships)

Generates UNDO or REDO SQL to recover objects that contain XML or LOB columns to selected points in time.



© 2012 SAP AG 31

4. Setup for SAP Use Cases

Setup of SAP and DB2 Systems

The system landscape used for the test activities described in this Casebook was located in a single z/OS LPAR on System z. The name of the LPAR was SAPK and its z/OS level was 1.13.

On each LPAR several DB2 subsystems were installed with DB2 Version 10. Test activities like Backup & Recovery/Restore, PPRC, and most of DB2 Cloning activities were executed on DB2 non-data sharing systems. Test activities with Recovery Expert and certain tests with the DB2 Cloning tool were done on a DB2 data sharing system.

The SAP release of all systems was SAP NetWeaver 7.31, with kernel release 7.20. The SAP application server instances ran in AIX clusters with AIX Version 6.1.

Screenshot 1. SAP Component information in SAPGUI

Recommended APARs

The following APARs are recommended to be applied:

DB2 APAR PM55830

DB2 APAR PM55252

DB2 APAR PM52212

DB2 APAR PM54179

DB2 APAR PM53237

DB2 APAR PM55092

DB2 APAR PM51093

DB2 APAR PM55070

DB2 APAR PM56535

DB2 APAR PM45458

DB2 APAR PM58947

z/OS APAR OA38169

DB2 Cloning Tool APAR PM53613

DB2 Cloning Tool APAR PM55254



© 2012 SAP AG 32

Two DS8000 boxes were used for the tests, one DS8300 and one DS8800 box. The DS8300 box was the primary disk subsystem and the DS8800 box was the PPRC target. The microcode levels of these boxes were as follows:

DS8300: EC level 69.33.29.0

DS8800: EC level 86.10.139.0

DB2 and DFSMS Required Configuration for FlashCopy Based Database Backups

The DB2 Utilities BACKUP SYSTEM and RESTORE SYSTEM were introduced with DB2 V8. The combination of DB2 and the DFSMShsm API for FlashCopy provides an integrated DB2 process for backing up and restoring an SAP Data Base without any disruptions to the availability of the SAP system.

DFSMShsm provides a volume level fast replication through the API. For each source volume a relationship is established with a target volume. The copy is carried out in the background and results in a crash-consistent copy of the source as it appeared at the time the backup was invoked.

System level copies of the data and logs are taken for the HSM copy pools that are used by the DB2 system. These copy pools contain the SMS storage groups of the DB2 data sets. Besides defining the copy pools, it is also required to define copy pool backup storage groups that contain the backups for the copy pools. All data must be SMS managed.

The BACKUP SYSTEM exploits HSM Fast Replication Services to create an instantaneous and consistent backup. The information is kept track within DB2 and the HSM control data set. There is no downtime and DB2 is the single point of control. The RESTORE SYSTEM utility is used when it is desired that the SAP Data Base be recovered to a specific point in time. Otherwise the DFSMShsm recovery command (FRRECOV) can be used to return the data to the state it was in at the time of the backup. The recovery target point is established in the DB2 BSDS using the change inventory utility (DSNJU003), and using recorded backup points in DB2 the RESTORE SYSTEM utility restores the data to the previous backup and then applies log records to bring the data to the point in time.

To build a configuration that supports this type of backup there are some basic requirements that need to be satisfied. DB2 requires the usage of two DFSMShsm copy pools. A copy pool consists of one or more SMS storage groups. The first copy pool is for SAP user data and DB2 Catalog/Directory data and must be named DSN$loc-name$DB. The second copy pool is for DB active logs, and BSDS data sets. This pool must be named DSN$loc-name$LG. The loc-name is the DB2 DDF location name for the subsystem or data sharing group.

The ICF user catalogs for the data sets must reside on a volume within the given copy pool, which means there must be a separate ICF user catalog for the data assigned to the DSN$loc-name$DB and the DSN$loc-name$LG copy pools. This is important because during a RESTORE SYSTEM, DB2 restores only the DSN$loc-name$DB copy pool and not the DSN$loc-name$LG copy pool. If the active logs and BSDS data sets were restored to the point of the backup, subsequent updates will be lost and rolling forward on the log records would not be possible.

RESTORE SYSTEM runs while DB2 is active. Besides the tablespaces and index spaces it also restores the ICF catalog. However, this is only allowed if the catalog is not allocated, and if no open data sets for this catalog exist. Therefore, the ICF catalog entries of log and BSDS data set – which are open if DB2 is up - must be separated by the tablespaces and index spaces.

The placement of the DB2 libraries is very important to ensure the successful usage of the RESTORE SYSTEM utility. DO NOT place the DB2 system libraries in a SMS storage group that will be included in the DSN$loc-name$DB copy pool.

If the installation standard is to maintain separate DB2 system libraries for each DB2 subsystem, then place these libraries in an SMS storage group that will be assigned to the DSN$loc-name$LG copy pool. If they are in the DSN$loc-name$DB copy pool, then the restore of the volume containing the DB2 system libraries will fail during the restore of the DSN$loc-name$DB copy pool. This is because the RESTORE SYSTEM utility resides in DB2’s DSNLOAD, and there is a conflict between the systems libraries being allocated at the time of the volume restore.



© 2012 SAP AG 33

It is also necessary to setup an SMS Copy Pool Backup Storage Group in order to define the candidate target volumes that will receive the data from the source volumes.

It is not necessary in this environment to copy the DB2 Archive Logs – place them in a separate SMS Storage Group.

Enable the capture catalog capability on the ISMF panel for the HSM copy pools so that DB2 and HSM can perform a recovery of single objects even if they were moved to other volumes. In addition make sure to configure the other copy pool parameters like Preserve Mirror Required according to your system configuration.

To prepare the dumping to tape of system-level backups, create a dedicated dumpclass for fast replication services, which is not used for other volumes.

Figure 18. Sample SMS Configuration – Option #1

DB2 Active Logs

DB2 BSDS

DB2 Load Libraries

ICFCAT DB2LG1.CAT

SMS Storage Group DB2LG1

Copy Pool DSN$DB2XXX$LG

ICFCAT DB2DATA.CAT

DB2 Catalog

DB2 Directory

SMS Storage Group DB2CAT

ICFCAT DB2DATA.CAT

SAP Data

Copy Pool DSN$DB2xxx$DB

Copy Pool Backup Storage Group

DB2DATA

SMS Storage Group DB2USER


DB2LOG

Requirements: 1. There must be separate ICF user catalogs for the data assigned to the DSN$loc-name$DB and

the DSN$loc-name$LG copy pools. 2. The ICF user catalogs for the data sets must reside on a volume within the given copy pool to

ensure it is backed up with the data sets. 3. DO NOT place the DB2 system libraries in an SMS storage group that will be included in the

DSN$loc-name$DB copy pool. 4. Extended Format Addressability must be used in the SMS data class for the SAP and DB2

catalog and directory VSAM data sets. 5. Each SAP System (SID) requires a separate set of Storage Groups. 6. Enable capture catalog for the DSN$loc-name$DB and the DSN$loc-name$LG copy pools. 7. Create a dedicated dumpclass for fast replication services



© 2012 SAP AG 34

The key points of this setup are:

1. Three distinct SMS Storage Groups have been established (this is accomplished through the DFSMS application available via ISPF).

2. Two different ICF Catalogs have been allocated. Even though the Catalog and Directory are in their own SMS Storage Group they share the ICF Catalog with the SAP Data VSAM Data Sets.

3. Even though the DB2 Catalog and Directory share the same SMS copy pool and ICF Catalog they are in different SMS Storage Groups to ensure they are separated.

4. The DB2 logs belong to a single SMS Storage Group. In order to ensure the highest availability we want Log Copy1 for each data set to be on a different volume than Log Copy 2 for the same data set. This also applies to the two BSDS data sets. This means that we must take the additional step of using SMS Guaranteed Space to force the data sets to be on separate volumes.

Figure 19. Sample SMS Configuration – Option #2

In this configuration we used two distinct SMS Storage Groups to allocate the DB2 logs and BSDS, a storage group for LOGCOPY1 and a storage group for LOGCOPY2. We would then have a separate set of DASD Volumes for each group and let SMS keep the data sets separated for us.

DB2 LOGCOPY1 Active Logs

DB2 BSDS01

DB2 Load Libraries

ICFCAT DB2LG1.CAT


ICFCAT DB2DATA.CAT

DB2 Catalog

DB2 Directory

SMS Storage Group DB2CAT

ICFCAT DB2DATA.CAT

SAP Data

Copy Pool DSN$DB2xxx$DB


DB2DATA

SMS Storage Group DB2USER


ICFCAT DB2LG1.CAT

DB2 LOGCOPY2 Active Logs

DB2 BSDS02

Copy Pool DSN$DB2XXX$LG


DB2LOG



© 2012 SAP AG 35

DB2 BSDS

A special issue with the DB2 BSDS (bootstrap data set) was that a single level alias cannot distinguish between the VSAM cluster name and the alias name:

Log data sets have (2) qualifiers prior to applying the High Level Qualifier: LOGCOPY1.DSnn

But prior to applying the High Level Qualifier the BSDS data sets have only (1) qualifier: BSDS01 or BSDS02

This causes an ACS and ICF Catalog isolation issue when we wanted to place the Logs and BSDS into a separate SMS Storage Group and ICF Catalog.

For BSDS we could have an ICF Catalog Alias and VSAM Data set Cluster Name that are identical.

Both are VSAM entities and will cause confusion as they must be distinguishable.

Therefore the solution is:

Make the BSDS data sets a (3) level data set name, e.g. PE1.DB2.BSDS01

OR

Change the High Level Qualifier for the BSDS and Logs to a unique value, e.g. PE11L.

Now our ICF Catalog Alias is PE11L and is a single level and can be identified by the ACS routine and used for catalog isolation.

ACS Routines and Data Set Allocation

DFSMS provides multiple ACS routines to allow it to make decisions on where to allocate a data set based on various decision points. These are SMS constructs that allows DFSMS to understand the characteristics for each data set that DB2 wants to create. A separate ACS routine is invoked for each SMS class assignment during the allocation process..

The following constructs are part of the allocation process:

Data Class This class decides the data set attributes. For SAP Extended Format Addressability must be used to allow data sets > 4 GB to be allocated. Starting with DB2 10, the DB2 Catalog and Directory must also include Extended Format in the Data Class. The Dynamic Volume Count should be set to 5 as well. Dynamic Volume Count is used during allocation processing to determine the maximum number of volumes a data set can span.

Storage Class This class is used to establish for example Guaranteed Space, that is space on a specific volume or volumes. This ensures that specific data sets are placed on the exact DASD volumes where they are required to be. This could be used for example to keep copies of the DB2 Active Logs on separate volumes for higher availability.

Management Class This class is used to define the migration criteria off the primary volumes. For example, the DB2 Archive Logs may be kept on DASD volumes for a week and then migrated off to tape. Storage Group This structure represents a list of DASD Volumes that are candidates for data set placement.

Sample SMS Setup for SAP

Here is an example of how to setup the SMS constructs to support an SAP System with a SYSTEM ID (SID) = PE1. This could represent a production ECC environment that will utilize DB2 BACKUP SYSTEM and RESTORE SYSTEM as the backup and recovery strategy.



© 2012 SAP AG 36

SMS Storage Group

Data Sets Data Set Name ICF Catalog name Catalog ALIAS SMS Management

Class

SMS Storage Class

Guaranteed Space

Migration

PE1CATSG DSNDB01, DSNDB06, DSNDB07, RUNLIB, SRCLIB, DBRMLIB

PE1.xxxxxxxxxx PE11.xxxxxxxxxx PE1A.xxxxxxxxxx

PE1DB2.SAPDB2.CATALOG PE1 PE11 PE1A

NULL SCNGS NO NO

PE1SAPSG SAP DB2 VSAM Data sets for tablespaces, indexspaces

PE1UA.xxxxxxxxxx PE1USR.SAPDB2.CATALOG PE1U NULL SCNGS NO NO

PE1ICSG DB2 Image Copy Data sets

PE1IC.xxxxxxxxxx PE1IC.SAPDB2.CATALOG PE1IC PE1ICMC SCNGS NO Online for 1 week

PE1ARCSG DB2 Archive Log Data sets

PE11.xxxxxxxxxx PE1A.xxxxxxxxxx

PE1LOG.SAPDB2.CATALOG PE11.ARCHLOG1 PE11.ARCHLOG2 PE1A.ARCHLOG1 PE1A.ARCHLOG2

PE1ARMC SCNGS NO Online for 2 weeks

DB2 Active Log Data sets Option (1) – One Storage Group

This setup uses one SMS Storage Group for the DB2 Active Logs, but the data set placement must be established through the use of Guaranteed Space.

SMS Storage Group


Class

SMS Storage Class

Guaranteed Space

Migration

PE1LOGSG DB2 Active Log Datasets DB2 BSDS Datasets DSNLOAD DSNMACS DSNEXIT

PE11.LOGCOPY1.DSnn PE11.LOGCOPY2.DSnn PE1A.LOGCOPY1.DSnn PE1A.LOGCOPY2.DSnn PE11.DB2.BSDS01 PE11.DB2.BSDS02 PE1A.DB2.BSDS01 PE1A.DB2.BSDS02 PE11.DB2.DSNLOAD PE11.DB2.DSNMACS PE11.DB2.DSNEXIT PE1A.DB2.DSNLOAD PE1A.DB2.DSNMACS PE1A.DB2.DSNEXIT

PE1LOG.DB2.CATALOG PE11.LOGCOPY1 PE11.LOGCOPY2PE11.DB2 PE11 PE1A.LOGCOPY1 PE1A.LOGCOPY2PE1A.DB2 PE1A

NULL SCGS YES NO



© 2012 SAP AG 37

DB2 Active Log Data sets Option (2) – Two Storage Groups

This setup uses two SMS Storage Group for the DB2 Active Logs, and the data set placement for each log copy is handled by SMS.

SMS Storage Group


Class

SMS Storage Class

Guaranteed Space

Migration

PE1LG1SG DB2 Active Log Datasets DB2 BSDS Datasets DSNLOAD DSNMACS DSNEXIT

PE11.LOGCOPY1.DSnn PE1A.LOGCOPY1.DSnn PE11.DB2.BSDS01 PE1A.DB2.BSDS01 PE11.DB2.DSNLOAD PE11.DB2.DSNMACS PE11.DB2.DSNxxxx

PE1LOG.DB2.CATALOG PE11.LOGCOPY1 PE11.DB2 PE11 PE1A.LOGCOPY1 PE1A.DB2 PE1A

NULL SCNGS NO NO

PE1LG2SG DB2 Active Log Datasets DB2 BSDS Datasets DSNLOAD DSNMACS DSNEXIT

PE11.LOGCOPY2.DSnn PE1A.LOGCOPY2.DSnn PE11.DB2.BSDS02 PE1A.DB2.BSDS02 PE1A.DB2.DSNLOAD PE1A.DB2.DSNMACS PE1A.DB2.DSNxxxx

PE1LOG.DB2.CATALOG PE11.LOGCOPY2 PE11.DB2 PE11 PE1A.LOGCOPY2 PE1A.DB2 PE1A

NULL SCNGS NO NO

Setup of Test Environment

There are several test environments which have been used in our test activities:

Test environment 1 is intended to be a high-end configuration for your crucial SAP applications. Therefore, all volumes are mirrored using PPRC. In support of GDPS, the copy pool backup storage groups are also mirrored.

Figure 20. Test Environment 1: Backup, Recovery and DR Scenarios

DB2 10 subsystem with SAP NetWeaver 7.31 on z/OS 1.13

Copy pool

DSN$DDFDB21$LG

DB2 B A C K U P S Y S T E M

With incremental FlashCopy

Copy pool VERSIONS = 1

Copy pool

DSN$DDFDB21$DB

Storage group DB2DGL

Type:

POOL

CopyPool Backup name:

DB2FAL

Volumes:

SAPDGL

Storage group DB2DG

Type:

POOL


DB2FA

Volumes:

SAPDG1-3

Storage group DB2FG

Type:

COPY POOL BACKUP


N/A

Volumes:

SAPFG1-3

Storage group DB2FGL

Type:

COPY POOL BACKUP


N/A

Volumes:

SAPFGL

DS8300: DS8K2 DS8800: DS8K3

Copy pool

DSN$DDFDB21$LG

Copy pool

DSN$DDFDB21$DB


Type:

POOL


DB2FAL

Volumes:

SAPDGL

Storage group DB2DG

Type:

POOL


DB2FA

Volumes:

SAPDG1-3

Storage group DB2FG

Type:

COPY POOL BACKUP


N/A

Volumes:

SAPFA1+2


Type:

COPY POOL BACKUP


N/A

Volumes:

SAPFAL

PPRCPPRC

PPRCPPRC

PPRCPPRC

RPFC

For data: 3 Mod 27 volumes

For log: 1 Mod 9 volume

PPRCPPRC



© 2012 SAP AG 38

Test environment 2 represents an SAP non-production environment. Therefore, it is an environment that can take advantage of space-efficient FlashCopy.

Figure 21. Test Environment 2: Minimum Backup and Recovery/Restore Scenarios

Test environment 3 was built for activities with DB2 Recovery Expert and DB2 cloning activities.

The following figure visualizes the cloning relationship for the cloning use cases with data sharing.


Copy pool

DSN$DDFDB22$LG


With space-efficient FlashCopy

NOCOPY: VERSIONS=0

Copy pool

DSN$DDFDB22$DB

Storage group DB2DIL

Type:

POOL


DB2FIL

Volumes:

SAPDIL

Storage group DB2DI

Type:

POOL


DB2FI

Volumes:

SAPDI1-3

Storage group DB2FI

Type:

COPY POOL BACKUP


N/A

Volumes:

SAPFI1-3

Storage group DB2FIL

Type:

COPY POOL BACKUP


N/A

Volumes:

SAPFIL

DS8300: DS8K2

Tape: VTS




Copy pool

DSN$DDFDB21$LG


With incremental FlashCopy


Copy pool

DSN$DDFDB21$DB

Storage group DB2FG

Type:

COPY POOL BACKUP


N/A

Volumes:

SAPFG1-3

DS8300: DS8K2 DS8800: DS8K3

DB2 Cloning Tool

DB2 10 single subsystem with SAP NetWeaver 7.31 on z/OS 1.13

Copy pool

DSN$DDFDB24$LG

Copy pool

DSN$DDFDB24$DB

Storage group DB2CJL

Type:

POOL


DB2FJL

Volumes:

SAPCJL

Storage group DB2CJ

Type:

POOL


DB2FJ

Volumes:

SAPCJ1-3



FlashCopyFlashCopy


Type:

COPY POOL BACKUP


N/A

Volumes:

SAPFGL

Tape: VTS


Type:

POOL


DB2FAL

Volumes:

SAPDGL

Storage group DB2DG

Type:

POOL


DB2FA

Volumes:

SAPDG1-3

Figure 22. Test Environment 3: Backup Cloning



© 2012 SAP AG 39

Figure 23. Test Environment 4: Recovery Expert and Cloning Scenarios, with Data Sharing

DFSMS Setup and Definitions

The SMS component of z/OS (Storage Management Subsystem) includes constructs like copy pool and types of storage groups like copy pool backup. These features enable DFSMShsm to know which volumes, target and source, should be processed for fast replication.

To use DFSMShsm fast replication for DB2 BACKUP SYSTEM and RESTORE SYSTEM, it is a prerequisite to separate the database data and the database log of a DB2 system into different DFSMShsm copy pools. Therefore, the volumes being used for the database data and database logs need to be in separate SMS storage groups.

Because of naming conventions of the DB2 environment, a separate high level qualifier was created for the BSDS, the archive log data sets, the active log data sets and the DB2 code.

Here an example for DB2 subsystem DB21:

Data sets beginning with DB21.** point to SYS1.USERCAT.DB21

The database data copy pool ($DB??) contains the following objects:

DB2 Catalog data sets

Data sets for SAP tables and SAP indexes

ICF catalog related to these DB2 data sets

Data sets beginning with DB21L.** point to SYS1.USERCAT.DB21L

DB2 10 data sharing with SAP NetWeaver 7.31 on z/OS 1.13

Copy pool

DSN$DDFDB23$LG


With incremental & full FlashCopy


Copy pool

DSN$DDFDB23$DB

Storage group DB2DJL

Type:

POOL


DB2FJL

Volumes:

SAPDJL

Storage group DB2DJL

Type:

POOL


DB2FJL

Volumes:

SAPDJL

DS8300: DS8K2

FlashCopyFlashCopy

Tape: VTS



Storage group DB2DJ

Type:

POOL


DB2FJ

Volumes:

SAPDJ1-3

Storage group DB2DJ

Type:

POOL


DB2FJ

Volumes:

SAPDJ1-3

DB2 10 data sharing with SAP NetWeaver 7.31 on z/OS 1.13

Copy pool

DSN$DDFDB25$LG

Copy pool

DSN$DDFDB25$DB

Storage group DB2CJ2L

Type:

POOL

Volumes:

SAPCJM

Storage group DB2CJ2

Type:

POOL

Volumes:

SAPCJA-C

Storage group DB2CJ2

Type:

POOL

Volumes:

SAPCJA-C

Storage group DB2FJL

Type:

COPY POOL BACKUP


N/A

Volumes:

SAPFJL+M

Storage group DB2FJ

Type:

COPY POOL BACKUP


N/A

Volumes:

SAPFJ1-6

DB2 Cloning ToolDB2 Recovery Expert


Type:

POOL

Volumes:

SAPCJM


Type:

POOL

Volumes:

SAPCJM

FlashCopy

Tape: VTS



© 2012 SAP AG 40

The database log copy pool ($LG??) contains the following objects:

BSDS (bootstrap data set)

DB2 log data sets

DB2 library data sets

ICF catalog related to these DB2 data sets.

As a standard configuration, the DB2 work file tablespaces can be kept within the $DB copy pool to simplify the setup. The advantage of this approach, which was taken for the test cases in this Casebook, is that no additional manual steps are required during a point-in-time recovery (PITR). As a drawback, the backups are somewhat larger since the work file tablespaces are implicitly copied as part of the BACKUP SYSTEM processing.

If the work file tablespaces are excluded from the $DB copy pool, their ICF catalog also needs to be excluded from $DB. As an advantage, this approach results in smaller backups. A drawback is that it needs to be checked whether work file tablespaces were dropped in DB2 between the PIT target point and current by analyzing the consistency between DB2 catalog and VSAM catalog after the RESTORE SYSTEM has completed. This checking should be done when DB2 is still in access(maint) mode. If so, dropping work file tablespaces should be usually a rare event.

The SMS volumes have been defined for the test system as follows (job extraction for one volume as an example):

...

//INIT EXEC PGM=ICKDSF

//*

//SYSPRINT DD SYSOUT=*

//SYSIN DD *

INIT UNIT(4D20) NVFY VOLID(SAPDG1) PURGE -

VTOC(072,0,3645) -

INDEX(000,1,1079) -

OWNERID(SAPDATA) STGR

...

Each volume of the DB2 subsystem was defined in this way.

While DFSMShsm can work with different copy pools, the copy pools used by DB2’s BACKUP SYSTEM utility are fixed. There is just one copy pool for the data and just one copy pool for the logs and the names for the copy pools are predefined.

The copy pool names need to be:

DSN$<DB2 location name>$DB – for the data

DSN$<DB2 location name>$LG - for the logs

The copy pool names for the test systems have been created adhering to those naming conventions.



© 2012 SAP AG 41

The following table gives an overview about naming conventions and storage definitions:

SAP SID DB1 DB2 SSID DB21

Copy Pool SMS Storage Group

Volsers PPRC Primary Addresses

DS8000 Comments

DSN$DDFDB21$DB DB2DG SAPDG1 8E00 DS8K2 PPRC Source

SAPDG2 8E01

SAPDG3 8E02

Backup Copy Pool DB2FG SAPFG1 8E10

SAPFG2 8E11

SAPFG3 8E12

DSN$DDFDB21$LG DB2DGL SAPDGL 8E20

Backup Copy Pool DB2FGL SAPFGL 8E21

PPRC Secondary Addresses

DS8000

DSN$DDFDB21$DB DB2DG SAPDH1 7E00 (of 8E00) DS8K3 PPRC Target

SAPDH2 7E01 (of 8E01)

SAPDH3 7E02 (of 8E02)

Backup Copy Pool DB2FG SAPFH1 7E10 (of 8E10)

SAPFH2 7E11 (of 8E11)

SAPFH3 7E12 (of 8E12)

DSN$DDFDB21$LG DB2DGL SAPDHL 7E20 (of 8E20)

Backup Copy Pool DB2FGL SAPFHL 7E21 (of 8E21)



Volsers Addresses DS8000 Comments

DSN$DDFDB22$DB DB2DI SAPDI1 8E03 DS8K2

SAPDI2 8E04

SAPDI3 8E05

Backup Copy Pool DB2FI SAPFI1 8E33 Space-Efficient Pool

SAPFI2 8E34 Repository = 64GB

SAPFI3 8E35

DSN$DDFDB22$LG DB2DIL SAPDIL 8E28

Backup Copy Pool DB2FIL SAPFIL 8E38



© 2012 SAP AG 42

SAP SID DB3 DB2 SSID Group DS23 with DB2 members S231 and S232



DSN$DDFS231$DB DB2DJ SAPDJ1 8E06 DS8300 Source for cloning

SAPDJ2 8E07

SAPDJ3 8E08

Backup Copy Pool DB2FJ SAPFJ1 8E16

SAPFJ2 8E17

SAPFJ3 8E18

SAPFJ4 8E19

SAPFJ5 8E1A

SAPFJ6 8E1B

DSN$DDF S231$LG DB2DJL SAPDJL 8E22

Backup Copy Pool DB2FJL SAPFJL 8E23

SAPFJM 8E24


DSN$DDFDB24$DB DB2CJ SAPCJA 8E13 clone target

SAPCJB 8E14

SAPCJC 8E15

DSN$DDFDB24$LG DB2CJL SAPCJM 8E29

SAP SID DB5

DB2 SSID Group DS25 with DB2 members S251 and S252 Copy Pool SMS

Storage Group


DSN$DDFS251$DB DB2CJ2 SAPCJA 8E13 DS8K2 clone target

SAPCJB 8E14

SAPCJC 8E15

DSN$DDFS251$LG DB2CJ2L SAPCJM 8E29

ACS Routines

The following ACS routines were defined to make sure that the DB2 data sets for the different DB2 subsystems end up in the intended stogroup:

FILTLIST DB2DGL INCLUDE(DB21L.**,

'SYS1.USERCAT.DB21L')

FILTLIST DB2DG INCLUDE(DB21.**,

'SYS1.USERCAT.DB21')

EXCLUDE(DB21.ARCHLOG%.**)

FILTLIST DB2DIL INCLUDE(DB22L.**,


FILTLIST DB2DI INCLUDE(DB22.**,





© 2012 SAP AG 43

FILTLIST DB2DJL INCLUDE(DB23L.**,


FILTLIST DB2DJ INCLUDE(DB23.**,



FILTLIST DB2CJL INCLUDE(DB24L.**,


FILTLIST DB2CJ INCLUDE(DB24.**,



FILTLIST DB2CJL2 INCLUDE(DB25L.**,


FILTLIST DB2CJ2 INCLUDE(DB25.**,



Tape Definitions

For the test environments, a VTS was used. This means:

DFSMSrmm is used (a full function tape management system)

use of scratch pool

tape robot TS7740 with logical tapes written on Media9 with EFMT3 (Enterprise Format 3), which compresses up to 3TB

Tape and dump class definitions for HSM, in member ARCCMDxx are shown in the example below. The most important definitions are in bold and underlined:

Following dump class was defined. Note that it is not recommended to share a dump class between fast replication services and regular volumes. Also, be aware that the VTOCCOPIES parameter is not used for fast replication services

DEFINE DUMPCLASS(DB2DP03M -

AUTOREUSE -

DATASETRESTORE -

FREQUENCY(1) -

STACK(1) - *1

NORESET -

TAPEEXPIRATIONDATE(99365) -

RETENTIONPERIOD(100) -

*2

)

...

*1 Stack1 for virtual tape storage.

*2 For the test environment, a retention period of 3 months was sufficient. In a production system, the retention period must be adapted to the company’s regular period rules for the expiration of tapes.

Here an example from a storage class routine, which writes the HSM-Volume-dumps into VTS:

FILTLIST TS7740DSN INCLUDE(*.DMP.*.V*.D*.T*)

WHEN (&DSN = &TS7740DSN) DO SET &STORCLAS = 'TS7740' EXIT END

It is not necessary to enter the unit in the dump definition, because above query returns the dump data set name. E.g. one of the dump data set in our environment is:

“SAP.DMP.DB2DP03M.VSAPDI2.D11311.T402811”



© 2012 SAP AG 44

5. Monitoring and Operating DB2 BACKUP SYSTEM and FlashCopy

The goal of this chapter is to describe the setup that is required to run the DB2 BACKUP SYSTEM utility and to elaborate in detail how to invoke and monitor system-level backups. Different commands at DB2 and z/OS DFSMS level can be used for this purpose. Also, this chapter shows you how to invoke BACKUP SYSTEM from the SAP DBA Cockpit and how to retrieve a list of available backups from the DBA Cockpit.

Copy Pools used by DB2’s BACKUP SYSTEM Utility

While DFSMShsm can work with different copy pools, the copy pools used by DB2’s BACKUP SYSTEM utility are fixed. There is just one copy pool for the data and just one copy pool for the logs and the names for the copy pools are predefined.

The copy pool names need to be:

DSN$<DB2 location name>$DB – for the data

DSN$<DB2 location name>$LG - for the logs

To manage DFSMShsm copy pools, go to ISMF in TSO by entering “I” on the start panel:

----------- SYSTEM MASTER APPLICATION MENU ------------------------------------

OPTION ===>

testm :

L LOCAL - Products, TOOLS and Utilities system : SAPK

U USER - USER SELECTION PANEL node : SAP9

P PDF - ISPF/Program Development Facility runs at: DAN1/LP4=SAPK

SD SDSF - System Display and Search Facility mtype : 2094-728

SM SMP/E - SMP/E Dialogs sysres : 13BRES

R RACF - Resource Access Control Facility mvs rel: Z/OS 01.13.0

I ISMF - Interactive Storage Management Facility dfsms : 03.01.13.00

IP IPCS - Interactive Problem Control Facility jes : JES2 Z/OS1.13

PM RMF - Performance Monitor RMF Rel.===> 130 vtam : 6.1.D

S DFSORT - Data Facility Sort applid : TSOK

PP PPs - IBM Program Products term.ad: TCPK0047

H HCD - Lang : ENG Trace ===> N Y/N racf : Z/OS 01.13.0

E ESCM - ESCON MANAGER DIALOG tso : 3.13.0

IC ICF - Information Center Facility ispf : ISPF 6.3

userid : SCHUETZ

O OMVS - Open Edition time : 14:16

DB DB2 - DB2 date : 2011/12/15

MQ MQM - MQSeries ip addr: 192.168.216.30

X EXIT - Terminate ISPF using list/log defaults jdate : 2011.349

F1=HELP F2=SPLIT F3=END F4=RETURN F5=RFIND F6=RCHANGE

F7=UP F8=DOWN F9=SWAP lis F10=LEFT F11=RIGHT F12=RETRIEVE

Screenshot 2. System Master Application Menu

If you are not yet configured to be storage administrator in ISMF, enter “0” on the ISMF primary menu to enable yourself to view copy pools:



© 2012 SAP AG 45

------------------------------------------------------------------------------

ISMF PRIMARY OPTION MENU - z/OS DFSMS V1 R13

Select one of the following options and press Enter:

0 ISMF Profile - Change ISMF User Profile

1 Data Set - Perform Functions Against Data Sets

2 Volume - Perform Functions Against Volumes

3 Management Class - Specify Data Set Backup and Migration Criteria

4 Data Class - Specify Data Set Allocation Parameters

5 Storage Class - Specify Data Set Performance and Availability

9 Aggregate Group - Specify Data Set Recovery Parameters

L List - Perform Functions Against Saved ISMF Lists

R Removable Media Manager - Perform Functions Against Removable Media

X Exit - Terminate ISMF

Enter Selection or Command ===>

F1=Help F2=Split F3=End F4=Return F7=Up F8=Down F9=Swap

F10=Left F11=Right F12=Cursor

Screenshot 3. ISMF Primary Option Menu – z/OS DFSMS V1 R13

Then enter “0” to select your user mode:

------------------------------------------------------------------------------

ISMF PROFILE OPTION MENU

Select one of the following options and Press Enter:

0 User Mode Selection

1 Logging and Abend Control

2 ISMF Job Statement

3 DFSMSdss Execute Statement

4 ICKDSF Execute Statement

5 Data Set Print Execute Statement

6 IDCAMS Execute Statement

X Exit

Enter Selection or Command ===>



------------------------------------------------------------------------------

Screenshot 4. ISMF Profile Option Menu

On the following panel, you have the option to select either end user “1” or storage administrator “2”. If you select storage administrator, you can then later manage HSM copy pools:



© 2012 SAP AG 46

------------------------------------------------------------------------------

USER MODE ENTRY PANEL

Specify the following:

User Mode . . 2 (To specify your choice of session, type in a:

1 For an End User (EU)

2 For a Storage Administrator (SA)

in the User Mode Field and Press Enter to

Verify Your Selection.)

Note: You must Exit and Reenter ISMF after

Changing the User Mode Field in Order

to View and Use Your Selected Session.

Command ===>



Screenshot 5. User Mode Entry Panel

Going back to the ISMF primary menu, choose “P” to view the currently defined copy pools:

ISMF PRIMARY OPTION MENU - z/OS DFSMS V1 R13

0 ISMF Profile - Specify ISMF User Profile

1 Data Set - Perform Functions Against Data Sets

2 Volume - Perform Functions Against Volumes

3 Management Class - Specify Data Set Backup and Migration Criteria

4 Data Class - Specify Data Set Allocation Parameters

5 Storage Class - Specify Data Set Performance and Availability

6 Storage Group - Specify Volume Names and Free Space Thresholds

7 Automatic Class Selection - Specify ACS Routines and Test Criteria

8 Control Data Set - Specify System Names and Default Criteria

9 Aggregate Group - Specify Data Set Recovery Parameters

10 Library Management - Specify Library and Drive Configurations

11 Enhanced ACS Management - Perform Enhanced Test/Configuration Management

C Data Collection - Process Data Collection Function

G Report Generation - Create Storage Management Reports

L List - Perform Functions Against Saved ISMF Lists

P Copy Pool - Specify Pool Storage Groups for Copies

R Removable Media Manager - Perform Functions Against Removable Media

Selection or Command ===>



Screenshot 6. ISMF Primary Option Menu - z/OS DFSMS V1 R13



© 2012 SAP AG 47

If you select “P” and then confirm on the next panel “ACTIVE” for the CDS name and asterisk for the copy pool name, you can list all copy pools that exist so far:

COPY POOL LIST

Columns 3-1

CDS Name : ACTIVE

Enter Line Operators below:

LINE # BACKUP AUTO DUMP SYS LAST MOD LAST DATE TIME

OPERATOR COPY POOL NAME VERSIONS DUMP OR SYS GRP USERID MODIFIED MODIF

---(1)---- -------------(2)-------------- --(3)--- (4)- ---(5)---- --(6)--- ---(7)---- ---(8)-

DSN$DDFDB21$DB 1 NO -------- KARO 2011/11/23 14:52

DSN$DDFDB21$LG 1 NO -------- KARO 2011/11/23 14:53





DSN$DDFD6M0$DB 1 NO -------- KARO 2010/04/21 16:11

DSN$DDFD6M0$LG 1 NO -------- KARO 2010/04/21 16:12

DSN$DDFD8E0$DB 1 NO -------- KARO 2011/11/03 13:59

DSN$DDFD8E0$LG 1 NO -------- KARO 2011/11/03 13:59

DSN$DDFD990$DB 1 NO -------- KARO 2011/12/01 16:33

DSN$DDFD990$LG 1 NO -------- KARO 2011/11/03 14:00

DSN$DDFFT54$DB 0 NO -------- KARO 2011/06/24 14:49

Command ===>

F1=Help F2=Split F3=Exit F4=Return F7=Up F8=Down F9=Swap F10=Left F11=Right F12=Cancel

Screenshot 7. Copy Pool List

If you scroll to the right on this panel, you can see different attributes of the copy pools that are quite important. The attributes FCTOPPRC-FRBACKUP and FCTOPPRC-FRRECOV specify how FlashCopy invocations interact with PPRC mirrored volumes. You can control whether the PPRC relationship must be preserved, i.e. they always remain in full-duplex mode, or whether this is just preserved or not needed. The options are:

PMNO (do not target PPRC primary volumes),

PMPREF (target PPRC volumes preferred), or

PMREQ (target PPRC primary volumes required).

In the example below, PMNO was selected.

The CATINFO attribute specifies whether, as part of backing up a copy pool, you would like to also have the associated ICF catalogs copied automatically. We highly recommend taking advantage of this by specifying REQUIRED since this allows DB2 to recover individual tablespaces or indexes even if one of their underlying data sets has moved to another volume between the time of a backup and the time of the recovery.

Finally, the ALLOW-FCFRR attribute allows you to specify whether FlashCopy should be able to reverse the direction of the physical background copy in case it is needed to restore a backup while the physical background copy of the FlashCopy backup is still running.

This option is particularly interesting with space-efficient FlashCopy since the physical copy background process can persist.

COPY POOL LIST



© 2012 SAP AG 48

CDS Name : ACTIVE


LINE FCTOPPRC FCTOPPRC ALLOW STORAGE

OPERATOR COPY POOL NAME FRBACKUP FRRECOV CATINFO FCFRR GRP NAME

---(1)---- -------------(2)-------------- --(14)-- --(15)-- --(16)--- (17)- --(18)--

DSN$DDFDB21$DB PMNO PMNO REQUIRED NO DB2DG

DSN$DDFDB21$LG PMNO PMNO REQUIRED NO DB2DGL

DSN$DDFDB22$DB ------ ------ REQUIRED YES DB2DI

DSN$DDFDB22$LG ------ ------ REQUIRED YES DB2DIL

DSN$DDFDB23$DB ------ ------ NO YES DB2DJ

DSN$DDFDB23$LG ------ ------ NO NO DB2DJL

DSN$DDFD6M0$DB ------ ------ NO NO DB2DT

DSN$DDFD6M0$LG ------ ------ NO NO DB2DTL

DSN$DDFD8E0$DB ------ ------ NO NO DB2DD

DSN$DDFD8E0$LG ------ ------ NO NO DB2DDL

DSN$DDFD990$DB ------ ------ NO NO DB2DE

DSN$DDFD990$LG ------ ------ NO NO DB2DEL

DSN$DDFFT54$DB ------ ------ NO NO DB2DU

Command ===>

F1=Help F2=Split F3=Exit F4=Return F7=Up F8=Down F9=Swap F10=Left F11=Ri

Screenshot 8. Copy Pool List (scrolled to the right)

In ISMF, you can also view the copy pool backup storage groups. These groups contain the FlashCopy target volumes. A copy backup storage group is associated with a normal storage group.

------------------------------------------------------------------------------

STORAGE GROUP LIST

Entries 13-21 of 77

Data Columns 40-45 of 48

CDS Name : ACTIVE


LINE STORGRP OSMC EXTEND CP BCKP BREAK MIGR

OPERATOR NAME SYSTEM OVERFLOW SG NAME SG NAME POINT HI TRK

---(1)---- --(2)--- --(40)-- --(41)-- --(42)-- --(43)-- -(44)- -(45)-

DB2DDL -------- NO -------- DB2FDL ----- 85

DB2DE -------- NO -------- DB2FE ----- 85

DB2DEL -------- NO -------- DB2FEL ----- 85

DB2DG -------- NO -------- DB2FG ----- 85

DB2DGL -------- NO -------- DB2FGL ----- 85

DB2DI -------- NO -------- DB2FI ----- 85

DB2DIL -------- NO -------- DB2FIL ----- 85

DB2DJ -------- NO -------- DB2FJ ----- 85

DB2DJL -------- NO -------- DB2FJL ----- 85

------------------------------------------------------------------------------

STORAGE GROUP LIST



© 2012 SAP AG 49

Entries 29-37 of 77


CDS Name : ACTIVE


LINE STORGRP SG VIO VIO AUTO

OPERATOR NAME TYPE MAXSIZE UNIT MIGRATE

---(1)---- --(2)--- -------(3)------ --(4)-- (5)- --(6)---

DB2FDL COPY POOL BACKUP ------- ---- --------

DB2FE COPY POOL BACKUP ------- ---- --------

DB2FEL COPY POOL BACKUP ------- ---- --------

DB2FG COPY POOL BACKUP ------- ---- --------

DB2FGL COPY POOL BACKUP ------- ---- --------

DB2FI COPY POOL BACKUP ------- ---- --------

DB2FIL COPY POOL BACKUP ------- ---- --------

DB2FJ COPY POOL BACKUP ------- ---- --------

DB2FJL COPY POOL BACKUP ------- ---- --------

Screenshot 9. Storage Group List

Space-Efficient Volumes to enable DB2 BACKUP SYSTEM for Space-Efficient FlashCopy

It is transparent to DB2 whether space-efficient FlashCopy is exploited under the cover. To enable BACKUP SYSTEM for space-efficient FlashCopy, the target volumes in the copy pool backup storage group need to be defined to be space-efficient. In our case, the SAPFI<x> volumes were defined to be space-efficient volumes. This can be verified by the following command:

//* -------------------------------------------------------------- ***

//* LISTDATA EXAMPLE QUERYING FLASHCOPY SPACE EFFICIENT VOLUMES ***

//* -------------------------------------------------------------- ***

//LDATA3 EXEC PGM=IDCAMS

//V01 DD UNIT=3390,DISP=SHR,VOL=SER=SAPFI1


//SYSIN DD *

LISTDATA SPACEEFFICIENTVOL VOLUME(SAPFI1) UNIT(3390) LEGEND

/*

//* -------------------------------------------------------------- ***

2107 STORAGE CONTROL

SPACE EFFICIENT VOLUME REPORT

STORAGE FACILITY IMAGE ID 002107.932.IBM.75.0000000AVPD1

SUBSYSTEM ID X'8E00'

..........STATUS...........

REPOSITORY REPOSITORY

DEVICE VOLSER SPACE CONSUMED SIZE EXT POOL ID SIZE

8E33 SAPFI1 23 32760 0000 80851

8E34 SAPFI2 32 32760 0000 80851

8E35 SAPFI3 9 32760 0000 80851

8E36 SAPFI4 502 32760 0000 80851

8E38 SAPFIL 32 10017 0000 80851

TOTAL NUMBER OF SPACE EFFICIENT VOLUME(S): 5

Compare the SPACE CONSUMED with the SIZE of the volume.



© 2012 SAP AG 50

These are the volumes of our test systems as defined within the DS8000. Note that the last volumes in the list are space-efficient volumes. This is also indicated by the storage type TSE (Track Space Efficient) in the output of the LSCKDVOL command of DSCLI. Device SAPFI4 already has some data, which leads to 502 utilized cylinders in the space-efficient repository. Note the total capacity of 80851 cylinders that are available in the concerned repository.

The following output describes the meaning of two heading fields from the previous example:

Repository space consumed is the actual number of cylinders which are used within the repository for the concerned volume.

Repository size has the total number of available space within the concerned repository.

REPOSITORY SPACE CONSUMED

- AMOUNT OF SPACE IN THE REPOSITORY VOLUME CURRENTLY CONSUMED BY THE DEVICE.

FOR CKD DEVICES, THE VALUE REPRESENTS THE NUMBER OF CYLINDERS.

REPOSITORY SIZE - SIZE OF THE REPOSITORY VOLUME FOR THE EXTENT POOL.

FOR CKD EXTENT POOLS, THE SIZE OF THE REPOSITORY VOLUME IS REPORTED IN

NUMBER OF CYLINDERS.

The next example shows an ICKDSF INIT example which allocates some space for VTOC and VTOC INDEX data sets on volume SAPFI3.

INIT UNIT(4700) DEVTYP(33903) NOVERIFY VOLID(SAPFI3) -

VTOC(02,00,450) INDEX(0,1,29)

The next example shows the volume SAPFI4 with its data sets which actually take space out of the repository. The only data set which does not appear in this ISPF 3.4 listing is the VTOC data set. The actual number of utilized 502 cylinders within the repository assembles from these 3 data sets listed here in. Note that the scope of used space in the repository is cylinders. E.g., for the VTOCIX data set this will round up to 2 cylinders or 30 tracks.

DSLIST - Data Sets on volume SAPFI4 Row 1 of 3

Total Tracks: 7530 non-x: 7724 Data Sets: 3 non-x: 3

-------------------------------------------------------------------------------

Command - Enter "/" to select action Tracks %Used XT

-------------------------------------------------------------------------------

SYS1.VTOCIX.D#47BF 29 100 1

WB.D#47BF 7006 97 12

WB.LDATA 495 10 2

***************************** End of Data Set list ****************************

The device addresses used by z/OS usually are different from the DS8000 internal addresses. To find out the relation between z/OS and DS8000’s internal address use the D M=DEV command:

D M=DEV(8E33)

IEE174I 10.26.45 DISPLAY M 195

DEVICE 8E33 STATUS=ONLINE

CHP 64 65 66 67

ENTRY LINK ADDRESS 0E 0E 12 12

DEST LINK ADDRESS 15 15 21 21



© 2012 SAP AG 51

PATH ONLINE Y Y Y Y

CHP PHYSICALLY ONLINE Y Y Y Y

PATH OPERATIONAL Y Y Y Y

MANAGED N N N N

CU NUMBER 8E00 8E00 8E00 8E00

MAXIMUM MANAGED CHPID(S) ALLOWED: 0

DESTINATION CU LOGICAL ADDRESS = 0E

SCP CU ND = 002107.932.IBM.75.0000000AVPD1.0300

SCP TOKEN NED = 002107.900.IBM.75.0000000AVPD1.0E00

SCP DEVICE NED = 002107.900.IBM.75.0000000AVPD1.0E33

In the last line above the last number, in our example 0E33, is the DS8000 internal address of z/OS’s address 8E33.

Nickname ID VOLSER Status MTM # Mod1 # Cylinders Storage Allocation Pool

Vol-B/R/C-8E00 0E00 SAPDG1 Normal 3390-9 30 32,760 Standard EP_CKD_P0



Vol-B/R/C-8E03 0E03 SAPDI1 Normal 3390-9 30 32,760 Standard EP_CKD_P0



Vol-B/R/C-8E06 0E06 SAPDJ1 Normal 3390-9 30 32,760 Standard EP_CKD_P0



Vol-B/R/C-8E09 0E09 SAPCJ1 Normal 3390-9 30 32,760 Standard EP_CKD_P0

Vol-B/R/C-8E0A 0E0A SAPCJ2 Normal 3390-9 30 32,760 Standard EP_CKD_P0

Vol-B/R/C-8E0B 0E0B SAPCJ3 Normal 3390-9 30 32,760 Standard EP_CKD_P0

Vol-B/R/C-8E0C 0E0C SAPDV1 Normal 3390-9 30 32,760 Standard EP_CKD_P0

Vol-B/R/C-8E0D 0E0D SAPDV2 Normal 3390-9 30 32,760 Standard EP_CKD_P0

Vol-B/R/C-8E0E 0E0E SAPDV3 Normal 3390-9 30 32,760 Standard EP_CKD_P0

Vol-B/R/C-8E0F 0E0F FR8E0F Normal 3390-9 30 32,760 Standard EP_CKD_P0

Vol-B/R/C-8E10 0E10 SAPFG1 Normal 3390-9 30 32,760 Standard EP_CKD_P0



Vol-B/R/C-8E13 0E13 FR8E13 Normal 3390-9 30 32,760 Standard EP_CKD_P0



Vol-B/R/C-8E16 0E16 SAPFJ1 Normal 3390-9 30 32,760 Standard EP_CKD_P0




Vol-B/R/C-8E1A 0E1A SAPFJ5 Normal 3390-9 30 32,760 Standard EP_CKD_P0

Vol-B/R/C-8E1B 0E1B SAPFJ6 Normal 3390-9 30 32,760 Standard EP_CKD_P0

Vol-B/R/C-8E1C 0E1C SAPCV1 Normal 3390-9 30 32,760 Standard EP_CKD_P0

Vol-B/R/C-8E1D 0E1D SAPCV2 Normal 3390-9 30 32,760 Standard EP_CKD_P0

Vol-B/R/C-8E1E 0E1E SAPCV3 Normal 3390-9 30 32,760 Standard EP_CKD_P0

Vol-B/R/C-8E1F 0E1F FR8E1F Normal 3390-9 30 32,760 Standard EP_CKD_P0

Vol-B/R/C-8E20 0E20 SAPDGL Normal 3390-9 9 10,017 Standard EP_CKD_P0

Vol-B/R/C-8E21 0E21 SAPFGL Normal 3390-9 9 10,017 Standard EP_CKD_P0



© 2012 SAP AG 52

Vol-B/R/C-8E22 0E22 SAPDJL Normal 3390-9 9 10,017 Standard EP_CKD_P0

Vol-B/R/C-8E23 0E23 SAPFJL Normal 3390-9 9 10,017 Standard EP_CKD_P0

Vol-B/R/C-8E24 0E24 SAPFJM Normal 3390-9 9 10,017 Standard EP_CKD_P0

Vol-B/R/C-8E25 0E25 SAPCJL Normal 3390-9 9 10,017 Standard EP_CKD_P0

Vol-B/R/C-8E26 0E26 SAPDVL Normal 3390-9 9 10,017 Standard EP_CKD_P0

Vol-B/R/C-8E27 0E27 SAPCVL Normal 3390-9 9 10,017 Standard EP_CKD_P0

Vol-B/R/C-8E28 0E28 SAPDIL Normal 3390-9 9 10,017 Standard EP_CKD_P0


Vol-B/R/C-8E2A 0E2A Normal 3390-9 9 10,017 Standard EP_CKD_P0

Vol-B/R/C-8E2B 0E2B Normal 3390-9 9 10,017 Standard EP_CKD_P0

Vol-B/R/C-8E2C 0E2C Normal 3390-9 9 10,017 Standard EP_CKD_P0

Vol-B/R/C-8E2D 0E2D Normal 3390-9 9 10,017 Standard EP_CKD_P0

Vol-B/R/C-8E2E 0E2E Normal 3390-9 9 10,017 Standard EP_CKD_P0

Vol-B/R/C-8E2F 0E2F Normal 3390-9 9 10,017 Standard EP_CKD_P0

Vol-SpaceEf-8E30 0E30 FR8E30 Normal 3390-9 30 32,760 TSE EP_CKD_P0



Vol-SpaceEf-8E33 0E33 SAPFI1 Normal 3390-9 30 32,760 TSE EP_CKD_P0





Vol-SpaceEf-8E38 0E38 SAPFIL Normal 3390-9 9 10,017 TSE EP_CKD_P0


Our environment was not optimized for performance. In a real production environment you would distribute your production volumes and the FlashCopy target volumes across odd and even LCUs to take the full benefit of the DS8000 resources. A DS8000 server contains two Power servers. Every volume is managed by one server. Volumes of a n even LCU are managed by one server and volumes of an odd LCU are managed by the other server. So by exploiting both odd and even LCUs you take advantage of the entire power of the DS8000 box.

Invoking and Monitoring BACKUP SYSTEM and HSM Fast Replication Services

Once the HSM copy pools and the associated copy pool backup storage groups have been set up for DB2, you can invoke BACKUP SYSTEM to create a system-level backup. Here is an example for a JCL job to invoke BACKUP SYSTEM:

//SCHUETZR JOB USER=SCHUETZ,CLASS=B,MSGCLASS=X,

// MSGLEVEL=(1,1)

/*JOBPARM SYSAFF=SAPK

//*--------------------------------------------------

//BACKUPS EXEC DSNUPROC,SYSTEM=DB21,

// UID='SCHUETZSLB',LIB='DB21L.V100.SDSNLOAD'

//SYSIN DD *

BACKUP SYSTEM DUMP DUMPCLASS(DB2DP03M)

/*



© 2012 SAP AG 53

In this example, BACKUP SYSTEM is invoked with the DUMP option. This results in DB2 invoking HSM FRBACKUP to create a system-level backup using FlashCopy and in addition dumping this backup immediately to tape using the specified DUMPCLASS.

The JCL job output for this job contains the following with an indication of return code 0:

BACKUP SYSTEM DUMP DUMPCLASS(DB2DP03M)

DSNU000I 342 10:09:28.59 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = SCHUETZSLB

DSNU1044I 342 10:09:28.62 DSNUGTIS - PROCESSING SYSIN AS EBCDIC

DSNU050I 342 10:09:28.62 DSNUGUTC - BACKUP SYSTEM DUMP DUMPCLASS(DB2DP03M)

DSNU1600I 342 10:09:28.70 DSNUVBBD - BACKUP SYSTEM UTILITY FOR DATA STARTING,

COPYPOOL = DSN$DDFDB21$DB

TOKEN = X'C4C2F2F1C8CA14F4EB0B7589000F33803DA1'.

DSNU1614I 342 10:10:00.89 DSNUVBBD - BACKUP SYSTEM UTILITY FOR DATA COMPLETED

SUCCESSFULLY,


TOKEN = X'C4C2F2F1C8CA14F4EB0B7589000F33803DA1'

DATA COMPLETE LRSN = X'000F3383E3FE'

ELAPSED TIME = 00:00:32.

DSNU1600I 342 10:10:00.89 DSNUVBBD - BACKUP SYSTEM UTILITY FOR LOGS STARTING,

COPYPOOL = DSN$DDFDB21$LG

TOKEN = X'C4C2F2F1C8CA14F4EB0B7589000F33803DA1'.

DSNU1614I 342 10:10:02.54 DSNUVBBD - BACKUP SYSTEM UTILITY FOR LOGS COMPLETED

SUCCESSFULLY,


TOKEN = X'C4C2F2F1C8CA14F4EB0B7589000F33803DA1'

DATA COMPLETE LRSN = X'000F3383E3FE'


DSNU1602I 342 10:10:03.31 DSNUVBBD - BACKUP SYSTEM UTILITY COMPLETED, ELAPSED TIME =

00:00:34.

DSNU010I 342 10:10:03.32 DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=0

By executing the HSM query copypool and list copypool commands, you can monitor and review the success of the backups. To submit these commands in TSO, enter P on the initial TSO panel and then 6 (TSO commands):

----------------------- ISPF/PDF PRIMARY OPTION MENU -----------------------

OPTION ===>

USERID - SCHUETZ

0 ISPF PARMS - Specify terminal and user parameters TIME - 15:27

1 BROWSE - Display source data or output listings TERMINAL - 3278

2 EDIT - Create or change source data PF KEYS - 12

3 UTILITIES - Perform utility functions

4 FOREGROUND - Invoke language processors in foreground

5 BATCH - Submit job for language processing

6 COMMAND - Enter TSO Command, CLIST, or REXX exec

7 DIALOG TEST - Perform dialog testing

8 LM UTILITIES- Perform library administrator utility functions

9 IBM PRODUCTS- Additional IBM program development products

10 SCLM - Software Configuration and Library Manager

D2 DB2I 4.2 - Perform DB2 interactive functions (DSN2)






© 2012 SAP AG 54


C CHANGES - Display summary of changes for this release

T TUTORIAL - Display information about ISPF/PDF

X EXIT - Terminate ISPF using log and list defaults



Screenshot 10. ISPF/PDF Primary Option Menu

This brings you to the following panel where you can enter the HSM commands:

-------------------------- TSO COMMAND PROCESSOR -----------------------------

ISPF COMMAND ===>

ENTER NEW TSO-COMMAND OR POSITION CURSOR ON COMMAND TO BE EXECUTED

===> listcat level('db25')

===> hsend frbackup copypool(dsn$ddfdb22$db)

===> hsend frbackup copypool(dsn$ddfdb22$db) withdraw

===> hsend query copypool(dsn$ddfdb21$db)

===> hsend list copypool(dsn$ddfdb21$db)

===> hsend frdelete copypool(dsn$ddfdb21$LG) all



Screenshot 11. TSO Command Processor

If you submit “hsend query copypool(dsn$ddfdb21$lg)” on this panel, you can see whether the physical background copy for that copy pool is still active. In our case, it is not and the following message is therefore returned:

ARC1821I NONE OF THE VOLUMES IN COPY POOL DSN$DDFDB21$LG, VERSION 037, HAVE AN

ARC1821I (CONT.) ACTIVE FLASHCOPY BACKGROUND COPY

***

To find out technical details of this backup like the HSM token, which was assigned to it, submit the command “hsend list copypool(dsn$ddfdb21$lg)” term”:

COPYPOOL=DSN$DDFDB21$LG ,ALLOWPPRCP FRB=PN FRR=PN

VER=037,VTOCENQ=N,MADE ON 2011/12/08 AT 10:10:01,FRS=RECOVERABLE ,DPS=ALLCOMPLETE

TKN(C)=C'DB21H::4:::i :::::'

TKN(H)=X'C4C2F2F1C8CA14F4EB0B7589000F33803DA1'

TOTAL NUM OF VOLUMES=00001,INCREMENTAL=N,CATINFO=Y,FCFRR=N,RECOVERYINCOMPLETE=N

SGNAME=DB2DGL SOURCE=SAPDGL TARGET=SAPFGL


To investigate the status of the backup that was dumped to tape, you can submit the command “hsend list copypool(dsn$ddfdb21$lg) dumpvols”:

-- DFSMShsm CONTROL DATASET --COPY POOL--LISTING --------- AT 10:16:09 ON 11/12/08 FOR

SYSTEM=SAPK

COPYPOOL=DSN$DDFDB21$LG



© 2012 SAP AG 55

ALLOWPPRCP FRB=PN FRR=PN

VERSION VTOCENQ DATE TIME FASTREPLICATIONSTATE DUMPSTATE

037 N 2011/12/08 10:10:01 RECOVERABLE ALLCOMPLETE

TOKEN(C)=C'DB21H 4 i ß'

TOKEN(H)=X'C4C2F2F1C8CA14F4EB0B7589000F33803DA1'


DUMPCLASS REQUIRED DUMPSTATE VOLSSUC EXPDATE AVAILABLE

DB2DP03M Y COMPLETE 00001 2012/03/17 Y

HWCOMP ENCRYPT ENCTYPE RSAKEY/KPWD

NO NONE ********* *******************************************************

*********

SOURCE DUMPVOLS DEVICE TYPE

SAPDGL WA5808 3490

FILE SEQ=00, DSNAME=SAP.DMP.DB2DP03M.VSAPDGL.D11342.T011010


033 N 2011/11/24 17:10:15 NONE ALLCOMPLETE

TOKEN(C)=C'DB21H Q 2B '

TOKEN(H)=X'C4C2F2F1C8B8D8CB30E16504000EBAF2C244'





NO NONE ********* *******************************************************

*********



Be aware that the output of this command is not directly returned but it is rather written to the HSM started task. To view it, go to SD;ST on the TSO main panel and then select HSM for the LPAR on which it was executed:

Display Filter View Print Options Search Help

-------------------------------------------------------------------------------------------------------

SDSF STATUS DISPLAY ALL CLASSES LINE 1-21 (22)

COMMAND INPUT ===> SCROLL ===> CSR

NP JOBNAME JobID Owner Prty Queue C Pos SAff ASys Status PrtDest

HSM STC05260 HSMUSER 15 EXECUTION SAPB SAPB LOCAL

HSM STC05261 HSMUSER 15 EXECUTION SAPM SAPM LOCAL

HSM STC05262 HSMUSER 15 EXECUTION SAPI SAPI LOCAL

HSM STC05264 HSMUSER 15 EXECUTION SAPD SAPD LOCAL

HSM STC05265 HSMUSER 15 EXECUTION SAPN SAPN LOCAL

HSM STC05267 HSMUSER 15 EXECUTION SAPH SAPH LOCAL

HSM STC05268 HSMUSER 15 EXECUTION SAPJ SAPJ LOCAL

HSM STC05270 HSMUSER 15 EXECUTION SAPT SAPT LOCAL

? HSM STC05818 HSMUSER 15 EXECUTION SAPK SAPK LOCAL

HSM STC06168 HSMUSER 15 EXECUTION SAP9 SAP9 LOCAL

HSM STC06802 HSMUSER 15 EXECUTION SAPF SAPF LOCAL



© 2012 SAP AG 56

F1=HELP F2=SPLIT F3=END F4=RETURN F5=IFIND F6=BOOK F7=UP F8=DOWN F9=SWAP lis F10=LEFT

In our case, the LPAR is SAPK. By specifying ? on that line, you get a list of the different DDNAMEs for HSM on this LPAR. The output of the list copypool commands is kept in an SYS<number> entry. The number is every increasing. Be aware that HSM error messages or warnings, which are raised as part of the processing of FRBACKUP and FRRECOV on behalf of DB2 BACKUP SYSTEM and RESTORE SYSTEM, are written to JESMSGLG.

SDSF JOB DATA SET DISPLAY - JOB HSM (STC05818) DATA SET DISPLAYED


NP DDNAME StepName ProcStep DSID Owner C Dest Rec-Cnt Page-C

JESJCLIN 1 HSMUSER 0 2

JESMSGLG 2 HSMUSER 0 787

JESJCL JES2 3 HSMUSER 0 33

JESYSMSG 4 HSMUSER 0 598

$INTTEXT JES2 5 HSMUSER A 16

MSYSOUT HSM 101 HSMUSER F 0

SYS00001 HSM 104 HSMUSER A 0


SYS00003 HSM 106 HSMUSER A LOCAL 3






SYS00179 HSM 142 HSMUSER X LOCAL 28







F1=HELP F2=SPLIT F3=END F4=RETURN F5=IFIND F6=BOOK F7=UP F8=DOWN

Restoring a DB2 System-Level Backup using HSM FRRECOV

In SAP test systems, it can be quite convenient to restore a DB2 system to the point in time when a system-level backup was taken. This way a test can be repeated in a DB2 environment that was exactly the same like in the previous run. To accomplish this, you basically need to restore the backup using the FRRECOV command of the HSM fast replication services and then just restart the DB2 subsystem. Keep in mind, this means restoring both the $DB and $LG copy pools back to the versions with the same tokens. Note that you should only do this in test environments with backups that were taken when there was virtually no activity. If the BSDS is more current than the log, DB2 would not start up. Also for data sharing groups or for system with striped log data sets, inconsistencies between the log data sets may happen due to the multiple FlashCopy invocations done by BACKUP SYSTEM. If you perform a conditional DB2 restart, all of these situations are resolved.

The following job is an example how to restore the latest backups of the $LG and $DB copy pools. Before submitting this job, the ICF catalogs located on these copy pools should be unallocated using the /F CATALOG,UNALLOCATE(catalog) command. HSM unallocates the catalogs for you if they have been listed in the copy pool definition.


// MSGLEVEL=(1,1),REGION=0M


//*

//STEP1 EXEC PGM=IKJEFT01



© 2012 SAP AG 57

//SYSTSPRT DD SYSOUT=*

//SYSTSIN DD *

HSEND FRRECOV CP(DSN$DDFDB21$LG) VERIFY(Y)

HSEND FRRECOV CP(DSN$DDFDB21$DB) VERIFY(Y)

/*

Invoke BACKUP SYSTEM from SAP DBA Cockpit

To periodically schedule to take a system-level backup, you can use the Planning Calendar in the SAP DBA Cockpit. For example, you can schedule it on a daily basis. The SAP Notes 1225355 and 1362838 describe this in more detail. The following screenshot shows you an example where BACKUP SYSTEM was scheduled to be executed on November 7 at 15:56:17:

Screenshot 12. DBA Planning Calendar in the SAP DBA Cockpit

Use SAP DBA Cockpit to Retrieve Information on Available System-Level Backups

The SAP DBA Cockpit allows you to view the history of available system-level backups in DB2. It accomplishes this by invoking the DB2 utility DSNJU004 (BSDS Print Map) via stored procedure ADMIN_JOB_SUBMIT and parsing its output. SAP Note 1417621 covers this topic.

The following screenshot shows the backup status before the backup from the previous example was taken. The screenshot is from 15:37:19 on November 7:



© 2012 SAP AG 58

Screenshot 13. BACKUP SYSTEM Utility History – before BACKUP SYSTEM

The next screenshot shows you the backup history at 15:58:33, which was after the invocation of BACKUP SYSTEM at 15:56:17:

Screenshot 14. BACKUP SYSTEM Utility History – after invocation of BACKUP SYSTEM

Verifying DB2 Recovery or Restore with an SAP System in the Use Cases

To verify the data consistency of an SAP system after a recovery or a restore action in the use cases, the timestamp for a recovery was chosen at a time before an SAP client copy (local client copy) was running. A client is an organizational unit - and from technical perspective a complete unit - in the SAP system. With a



© 2012 SAP AG 59

local client copy the client-dependent data is copied within one SAP system, which means there is read and write activity in the database for a certain period of time. If the recovery or restore was done at a certain time before the client copy, the SAP application should list one client less in the client list.

For example for test scenario “system recovery with log apply” the client copy from client 001 into client 102 was the latest workload.

Screenshot 15. Client Copy /Transport Log Analysis

After the successful recovery the client 102 did not exist anymore, which is OK (because point in time recovery was at a timestamp when the new client 102 did not exist):



© 2012 SAP AG 60

Screenshot 16. Display View "Clients": Overview

After a Restore or Recovery test the data consistency of the SAP Application was checked as well with some SAP transactions like:

SM21 : check SAP System Log, there should be no errors in relation to the database or about data inconsistency

ST22 : there are no ABAP Runtime Errors

SICK : no errors

SM12 : check if there are no hanging updates

SM13 : check if there are no hanging enqueue requests

Entering some data into the database, e.g. with SCC4 insert a new client number into table T000

Any other kind of restore or recovery scenario, except the object level recovery was validated with the same method:

run a client copy in the SAP application

then restore/recover the database with a timestamp before the client copy was running and restart the SAP application. New client should not exist anymore.

run some SAP transactions

For the object level (or single object) recovery a user written ABAP program was used to enter data into a newly created table. Considering SAP naming convention those table names must have the initial letter ‘z’. After backup some data with 1000 lines have been inserted into this table.

Then a recovery/restore was issued with a timestamp after backup and before those lines had been inserted. Checking then the ‘z’-table from SAP Application, the lines are gone.



© 2012 SAP AG 61

6. High-End SAP Production Use Cases

This chapter discusses use cases that are often typical for high-end SAP production systems that process large volumes of transactions. In these environments, it is crucial to avoid or minimize the impact of taking a backup on the performance of the SAP transactions. Also, it is key that backups are non-disruptive and are also available on a secondary site for disaster recovery purposes. Some key technologies for these scenarios are incremental FlashCopy and Remote Pair FlashCopy. Note that the use cases discussed here can also apply to other SAP environments like test environments.

BACKUP SYSTEM using Incremental FlashCopy

The DB2 BACKUP SYSTEM utility can also trigger incremental FlashCopy on the volume level. If there are more than 1 VERSIONS captured, the incremental backup is followed up by VERSIONS-1 full backups.

E.g. if 2 VERSIONS are captured then full and incremental backups rotate:

Screenshot 17. Copy Pool Display

This is due to the fact that not more than 1 incremental relationship can exist. Be aware that the appropriate BACKUP SYSTEM commands must in sync with the order of the versions.

From scratch BACKUP SYSTEM utility is run with the following parameters:

DSNU050I 325 15:30:56.80 DSNUGUTC - BACKUP SYSTEM DATA ONLY ESTABLISH FCINCREMENTAL


COPYPOOL = DSN$DDFS231$DB

TOKEN = X'E2F2F3F1C8B4FD1B09C5726CC8B4FBD416A3'.



© 2012 SAP AG 62

DSNU1639I 325 15:31:17.96 DSNUVBBD - THE SYSTEM LEVEL BACKUP TAKEN IS AN INCREMENTAL

FLASHCOPY OF THE DATABASE COPYPOOL

DSNU1614I 325 15:31:17.96 DSNUVBBD - BACKUP SYSTEM UTILITY FOR DATA COMPLETED

SUCCESSFULLY,


TOKEN = X'E2F2F3F1C8B4FD1B09C5726CC8B4FBD416A3'

DATA COMPLETE LRSN = X'C8B4FD2B0792'


A subsequent BACKUP SYSTEM with the same parameters fails because already an incremental relationship exists:

DSNU050I 325 15:32:22.22 DSNUGUTC - BACKUP SYSTEM DATA ONLY ESTABLISH FCINCREMENTAL



TOKEN = X'E2F2F3F1C8B4FD6C777AFD61C8B4FC46878A'.

DSNU1630I 325 15:32:43.00 DSNUVBBD - BACKUP SYSTEM UTILITY FAILED, BECAUSE

FCINCREMENTAL WAS SPECIFIED BUT THE INCREMENTAL FLASHCOPY COULD NOT BE PROCESSED

DSNU1631I 325 15:32:43.00 DSNUVBBD - BACKUP SYSTEM UTILITY FAILED BECAUSE THE CALL TO

DFSMSHSM FAILED WITH RC = X'00000006' REASON = X'0000003E'.

SEE THE HSM ACTIVITY LOG FOR HSM MESSAGES INDICATING THE CAUSE OF THE ERROR.

HSM issues the following messages:

ARC1801I FAST REPLICATION BACKUP IS STARTING FOR COPY

ARC1801I (CONT.) POOL DSN$DDFS231$DB, AT 15:32:22 ON 2011/11/21,

ARC1801I (CONT.) TOKEN=X'E2F2F3F1C8B4FD6C777AFD61C8B4FC46878A'

ARC1806E FAST REPLICATION BACKUP HAS FAILED FOR COPY

ARC1806E (CONT.) POOL DSN$DDFS231$DB, RC=0062

ARC1802I FAST REPLICATION BACKUP HAS COMPLETED FOR

ARC1802I (CONT.) COPY POOL DSN$DDFS231$DB, AT 15:32:43 ON 2011/11/21,

ARC1802I (CONT.) FUNCTION RC=0006, MAXIMUM VOLUME RC=0000, CAPTURE

ARC1802I (CONT.) CATALOG RC=0000

The same is true if BACKUP SYSTEM should end such an incremental relationship by:

DSNU050I 325 16:13:47.70 DSNUGUTC - BACKUP SYSTEM DATA ONLY END FCINCREMENTAL



TOKEN = X'E2F2F3F1C8B506AECADF4E44C8B505A9CA9A'.

DSNU1630I 325 16:14:07.91 DSNUVBBD - BACKUP SYSTEM UTILITY FAILED, BECAUSE

FCINCREMENTAL WAS SPECIFIED BUT THE INCREMENTAL FLASHCOPY COULD NOT BE PROCESSED

DSNU1631I 325 16:14:07.91 DSNUVBBD - BACKUP SYSTEM UTILITY FAILED BECAUSE THE CALL TO

DFSMSHSM FAILED WITH RC = X'00000006' REASON = X'0000003E'.


Again BACKUP SYSTEM must address the correct version to end the FCINCREMENTAL copy.



© 2012 SAP AG 63

There are two methods to detect whether a system-level backup (SLB) is an INCREMENTAL one or not:

1) Output of “HSEND LIST COPYPOOL(DSN$DDFS231$DB)

-- DFSMShsm CONTROL DATASET --COPY POOL--LISTING --------- AT 16:13:41 ON 11/11/21 FOR SYSTEM=SAPK

COPYPOOL=DSN$DDFS231$DB

ALLOWPPRCP FRB=NO FRR=NO


005 N 2011/11/21 15:40:51 RECOVERABLE NONE

TOKEN(C)=C'S231H©ÿéÝª -H©Úb¯'

TOKEN(H)=X'E2F2F3F1C8B4FF51BA9A4060C8B4FE82BC12'

TOTAL NUM OF VOLUMES=00003,INCREMENTAL=Y,CATINFO=Y,FCFRR=Y,RECOVERYINCOMPLETE=N

SGNAME SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET SOURCE – TARGET

DB2DJ SAPDJ1 - SAPFJ1 SAPDJ2 - SAPFJ2 SAPDJ3 - SAPFJ3



TOKEN(C)=C'S231H©Ú º6{÷H©Ü:4}'

TOKEN(H)=X'E2F2F3F1C8B4FE059BF6C0E1C8B4FC7AF4D0'

TOTAL NUM OF VOLUMES=00003,INCREMENTAL=N,CATINFO=Y,FCFRR=Y,RECOVERYINCOMPLETE=N

SGNAME SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET

DB2DJ SAPDJ1 - SAPFJ4 SAPDJ2 - SAPFJ5 SAPDJ3 - SAPFJ6

----- END OF -- COPY POOL -- LISTING -----

2) Output of DSNJU004:

BACKUP SYSTEM UTILITY HISTORY

SUBSYSTEM ID S231

13:34:30 DECEMBER 12, 2011

START STCK DATA COMPLETE DATA/LOG COMPLETE

DATA LOG RBLP LRSN DATE LTIME LOCATION NAME

---------------- ---------------- ------------ ------------ -------------------- -----------

C8B4FF51BA9A4060 0000000000000000 C8B4FE82BC12 C8B4FF63867E 2011/11/21 15:41:11 DDFS231

TOKEN = E2F2F3F1C8B4FF51BA9A4060C8B4FE82BC12 TYPE=I

Z/OS 1.13

C8B4FE059BF6C0E1 0000000000000000 C8B4FC7AF4D0 C8B4FE179486 2011/11/21 15:35:23 DDFS231

TOKEN = E2F2F3F1C8B4FE059BF6C0E1C8B4FC7AF4D0

Z/OS 1.13

C8B4FD1B09C5726C 0000000000000000 C8B4FBD416A3 C8B4FD2B0792 2011/11/21 15:31:17 DDFS231

TOKEN = E2F2F3F1C8B4FD1B09C5726CC8B4FBD416A3 TYPE=I

Z/OS 1.13

Such an existing relationship has also influence on a RECOVER on such a system-level backup (SLB), because cascaded FlashCopy is not yet implemented and possible.

Incremental Backups using Fast Reverse Restore (FRR)

Prior to z/OS 1.12 and the Fast Reverse Restore feature, a SLB on DASD could not be used for a system level recovery until the Background copies had completed and any Flash Copy relationships were had to be withdrawn.



© 2012 SAP AG 64

In order to use Fast Reverse Restore (FRR) for a given copy pool, it must be activated in the copy pool definition.

-----------------------------------------------------------------------------

COPY POOL LIST

Entries 1-8 of 16


DS Name : ACTIVE


LINE FCTOPPRC ALLOW

OPERATOR COPY POOL NAME FRRECOV CATINFO FCFRR

---(1)---- -------------(2)-------------- --(15)-- --(16)--- (17)-

DSN$DDFDB21$DB PMNO REQUIRED YES

DSN$DDFDB21$LG PMNO REQUIRED YES

The initial Backup System Full enabling incremental FlashCopy, will copy all of the data to the backup copy pool. Subsequent executions of the Backup System utility will only copy the tracks that have changed. This eliminates the physical IO for copying tracks that haven’t changed. In order to maintain any given copy as a recovery point after other backups have run, it will be necessary to dump it to tape. A source copy pool can only maintain one incremental relationship at a time. All other FlashCopy relationships would need to be full relationships, or a data set FlashCopy.

The following is the JCL and control statement used to establish the incremental FlashCopy.

//BACKS13A JOB (DE03557),CH,NOTIFY=MARY,

// MSGCLASS=X,MSGLEVEL=(1,1),

// TIME=120,CLASS=A,REGION=0M

//*ROUTE XEQ BOECOB1


//***************************************************

//* STEP BACKUP: RUN BACKUP SYSTEM DATASHARING DB21

//***************************************************

//BACKUP EXEC DSNUPROC,SYSTEM=DB21,

// UID='MARY',LIB=DB21L.V100.SDSNLOAD

//SYSIN DD *

BACKUP SYSTEM FULL ESTABLISH FCINCREMENTAL

/*

After the backup was taken, the copy pool was listed using the following:

//HSMLST0K JOB (DE03557),CH,NOTIFY=MARY,




//*




//SYSTSIN DD *

HSEND LIST COPYPOOL(DSN$DDFDB21$DB) DUMPVOLS

HSEND LIST COPYPOOL(DSN$DDFDB21$LG) DUMPVOLS



© 2012 SAP AG 65

/*

The copy pool lists are found as HSM started task output. As can be seen for copy pool DSN$DDFDB21$DB this is version 31, it has a FASTREPLICATIONSTATE of RECOVERABLE, it was an incremental copy and FlashCopy Fast Reverse Restore (FCFRR) was established. The dump to tape was not requested during this execution of the Backup System utility, so the DUMPSTATE is NONE.

The DSN$DDFDB21$LG copy pool will always be a complete FlashCopy. The incremental designation is only used for the $DB copy pool. The dump to tape was not requested during this execution of the Backup System utility, so the DUMPSTATE is NONE.

COPYPOOL=DSN$DDFDB21$DB




TOKEN(C)=C'DB21I S r $'

TOKEN(H)=X'C4C2F2F1C91EFF2C68E28E990013DC9A5B'











After the Backup System job has completed, the background I/O copies the data from the source volumes to the target volumes. Using the HSM QUERY command the following shows the volumes in an active background copy and the percent complete for each volume.

If there was a need to Restore either copy pool prior to the background I/O completing, this would be supported because FlashCopy Fast Replication Restore (FCFRR) was activated for the current system-level backup.

ARC1820I THE FOLLOWING VOLUMES IN COPY POOL DSN$DDFDB21$LG, VERSION 046, HAVE

ARC1820I (CONT.) AN ACTIVE FLASHCOPY BACKGROUND COPY

ARC1820I (CONT.) SGNAME FR-PRIMARY FR-BACKUP PCT-COMP

ARC1820I (CONT.) DB2DGL SAPDGL SAPFGL 067

ARC1820I THE FOLLOWING VOLUMES IN COPY POOL DSN$DDFDB21$DB, VERSION 031, HAVE





© 2012 SAP AG 66

ARC1820I (CONT.) DB2DG SAPDG1 SAPFG1 048



IKJ56250I JOB HSENDS01(JOB00860) SUBMITTED

***

The backup is dumped to tape, using the following control statement.

BACKUP SYSTEM FULL DUMPONLY DUMPCLASS(DB2DP03M)

The copy pool list now indicates this backup has been dumped to tape; DUMPSTATE ALLCOMPLETE.















After the background I/O has completed, the HSM QUERY command would show there are no longer any volumes in an active background copy. However, this does not mean there are no longer any persistent FlashCopy relationships.

ARC1821I NONE OF THE VOLUMES IN COPY POOL DSN$DDFDB21$LG, VERSION 046, HAVE AN


ARC1821I NONE OF THE VOLUMES IN COPY POOL DSN$DDFDB21$DB, VERSION 031, HAVE AN


IKJ56250I JOB HSENDK01(JOB05489) SUBMITTED

***

In order to see the persistent FlashCopy relationships the TSO FCQUERY command is used.

//FCQUERY JOB (DE03557),CH,NOTIFY=MARY,





//*



© 2012 SAP AG 67

//************************************************

//* FCQUERY DEVN(NNNN)

//************************************************

//*




//SYSTSIN DD *

FCQUERY DEVN(8E00)

FCQUERY DEVN(8E01)

FCQUERY DEVN(8E02)

FCQUERY DEVN(8E20)

/*

As can be seen in the following FCQUERY output report, devices 8E00, 8E01 and 8E02 each have one active FlashCopy relationship (ACT=1). Device 8E20 is not in an active FlashCopy relationship, because this volume is in the DSN$DDFDB21$LG copy pool for which incremental copy is not an option.

Every one of the volumes is in a remote mirror session as a primary device (PC=P), none of them are in a z/OS Global Mirror session (XC=N), nor in a Concurrent Copy (CC=N), or have non revertible status (RV=N).

Also, neither the source volumes listed nor their backup copy pool targets are space-efficient DASD (SE=NN).

FCQUERY DEVN(8E00)

ANTF0420I FCQUERY Formatted -3

DEVN SSID LSS CCA CU SERIAL ACT MAX XC PC CC RV SE SEQNUM

8E00 8E00 0E 00 2107 0000000AVPD1 1 65534 N P N N NN 00000000

ANTF0001I FCQUERY COMMAND COMPLETED FOR DEVICE 8E00, COMPLETION CODE: 00

READY

FCQUERY DEVN(8E01)



8E01 8E00 0E 01 2107 0000000AVPD1 1 65534 N P N N NN 00000000


READY

FCQUERY DEVN(8E02)



8E02 8E00 0E 02 2107 0000000AVPD1 1 65534 N P N N NN 00000000


READY

FCQUERY DEVN(8E20)



8E20 8E00 0E 20 2107 0000000AVPD1 0 65534 N P N N NN 00000000


READY

END

After running an SAP client copy a new system-level backup is obtained. This time the control statement does not need to request incremental, because it was established in the prior Backup System execution. As can be seen from the copy list:

The version numbers for both copy pools are incremented by one

The DSN$DDFDB21$DB copy pool backup is an incremental copy



© 2012 SAP AG 68

Both can be used in a Fast Reverse Restore (FCFRR)

Neither one was dumped to tape





TOKEN(C)=C'DB21I .'

TOKEN(H)=X'C4C2F2F1C91FFFB6360380240014181FFA'






TOKEN(C)=C'DB21I .'

TOKEN(H)=X'C4C2F2F1C91FFFB6360380240014181FFA'


Each system-level backup taken using the Backup System utility is recorded in the Backup System Utility History section of the BSDS. As can be seen in the entries for the last two backups, the Type for both of these were incremental backups; TYPE=I.

BACKUP SYSTEM UTILITY HISTORY SUBSYSTEM ID DB21 17:34:52 FEBRUARY 14, 2012 START STCK DATA COMPLETE DATA/LOG COMPL DATA LOG RBLP LRSN DATE LTI ---------------- ---------------- ------------ ------------ ---------------- C91FFFB636038024 C91FFFD3FD4F47D9 0014181FFA00 001418204B22 2012/02/14 18:1 TOKEN = C4C2F2F1C91FFFB6360380240014181FFA00 TYPE=I Z/OS 1.13 CAT=YES C91EFF2C68E28E99 C91EFF5AB8C8C759 0013DC9A5B00 0013DC9D7DD7 2012/02/13 23:0 TOKEN = C4C2F2F1C91EFF2C68E28E990013DC9A5B00 TYPE=I Z/OS 1.13 CAT=YES

The change inventory utility (DSNJU003) was used to establish a conditional restart for DB21 to bring the system to current, no log truncation. The conditional restart control recover from the BSDS indicates that DB21 is in SYSPITR SYSTEM LEVEL RECOVERY MODE RESTART WITH NO LOG TRUNCATION.

//CONDSE01 JOB (DE03557),'NATIVE',NOTIFY=&SYSUID, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M /*JOBPARM SYSAFF=SAPK //* //CRCR01B EXEC PGM=DSNJU003,REGION=016M,COND=(4,LT) //STEPLIB DD DISP=SHR,DSN=DB21L.V100.SDSNEXIT // DD DISP=SHR,DSN=DB21L.V100.SDSNLOAD //SYSPRINT DD SYSOUT=* //SYSUT1 DD DISP=SHR,DSN=DB21L.BSDS01 //SYSUT2 DD DISP=SHR,DSN=DB21L.BSDS02 //SYSIN DD * CRESTART CREATE,SYSPITR=FFFFFFFFFFFF /*



© 2012 SAP AG 69

CONDITIONAL RESTART CONTROL RECORD 17:37:55 FEBRUARY 14, 2012 **** ACTIVE CRCR RECORD **** CRCR IDENTIFIER 0D10 USE COUNT 0 RECORD STATUS CRCR ACTIVE CRCR NOT USED PROCESSING STATUS FORWARD = YES BACKOUT = YES SYSPITR SYSTEM LEVEL RECOVERY MODE RESTART WITH NO LOG TRUNCATION

After DB21 was restarted the Restore System ran successfully. From the Restore System job output, we see the last system-level backup (version 32) was used in restoring the DSN$DDFDB21$DB copy pool prior to the log apply.

18:42:08.04 DSNUGUTC - RESTORE SYSTEM 18:42:08.04 DSNUVBRD - RESTORE SYSTEM UTILITY STARTING, COPYPOOL = DSN$DDFDB21$DB TOKEN = X'C4C2F2F1C91FFFB6360380240014181FFA00'. DSNUVBRD - RESTORE SYSTEM PRE-LOG APPLY COMPLETED SUCCESSFULLY, COPYPOOL = DSN$DDFDB21$DB TOKEN = X'C4C2F2F1C91FFFB6360380240014181FFA00' ELAPSED TIME = 00:00:02.

The started task JESMSGLG will have the HSM messages indicating the unallocation of the appropriate ICF user catalog (assuming the user ICF catalogs were defined for the source copy pool at the time of the backup) and the restore of the volumes in the copy pool using fast replication recovery.

18.42.08

ARC1801I FAST REPLICATION RECOVERY IS STARTING FOR

ARC1801I (CONT.) COPY POOL DSN$DDFDB21$DB, AT 18:42:08 ON 2012/02/14

F CATALOG,UNALLOCATE(SYS1.USERCAT.DB21 )

ARC1805I THE FOLLOWING 00003 VOLUME(S) WERE

ARC1805I (CONT.) SUCCESSFULLY PROCESSED BY FAST REPLICATION RECOVERY

ARC1805I (CONT.) OF COPY POOL DSN$DDFDB21$DB

ARC1805I (CONT.) SAPDG1



ARC1802I FAST REPLICATION RECOVERY HAS COMPLETED FOR

ARC1802I (CONT.) COPY POOL DSN$DDFDB21$DB, AT 18:42:10 ON 2012/02/14,

ARC1802I (CONT.) FUNCTION RC=0000, MAXIMUM VOLUME RC=0000

The DB21MSTR JESMSGLG will have information on the log apply phase.

DSNI040I -DB21 DSNIRSTR RESTORE SYSTEM UTILITY

PROCESSING LOG RANGE FROM RBA 0014181FFA00 TO 00141893E5D8

DSNI028I -DB21 DSNIFLAF THE NUMBER OF QUALIFIED

LOG RECORDS READ DURING THE FAST LOG APPLY PROCESS IS 20597

AND THE NUMBER OF FAST LOG APPLY BUFFERS PROCESSED ARE 1



© 2012 SAP AG 70

The system level recovery process, causes the incremental copy status for DSN$DDFDB21$DB to be withdrawn and the copy that was used during the Restore System utility to be invalidated.

The output from the TSO FCQUERY command, shows there are no longer any FlashCopy relationships for the DSN$DDFDB21$DB copy pool (ACT=0). The next time the Backup System utility is executed, incremental FlashCopy would need to be reestablished.

READY FCQUERY DEVN(8E00) ANTF0420I FCQUERY Formatted -3 DEVN SSID LSS CCA CU SERIAL ACT MAX XC PC CC RV SE SEQNUM 8E00 8E00 0E 00 2107 0000000AVPD1 0 65534 N P N N NN 00000000 ANTF0001I FCQUERY COMMAND COMPLETED FOR DEVICE 8E00, COMPLETION CODE: 00 READY FCQUERY DEVN(8E01) ANTF0420I FCQUERY Formatted -3 DEVN SSID LSS CCA CU SERIAL ACT MAX XC PC CC RV SE SEQNUM 8E01 8E00 0E 01 2107 0000000AVPD1 0 65534 N P N N NN 00000000 ANTF0001I FCQUERY COMMAND COMPLETED FOR DEVICE 8E01, COMPLETION CODE: 00 READY FCQUERY DEVN(8E02) ANTF0420I FCQUERY Formatted -3 DEVN SSID LSS CCA CU SERIAL ACT MAX XC PC CC RV SE SEQNUM 8E02 8E00 0E 02 2107 0000000AVPD1 0 65534 N P N N NN 00000000 ANTF0001I FCQUERY COMMAND COMPLETED FOR DEVICE 8E02, COMPLETION CODE: 00 READY END

Recovery of Single Tables or Indexes from a System-Level Backup

Since DB2 9, the RECOVER utility can consider also system-level backups (SLB) as a base for restoring a single object: Either tablespace or index space if index is defined with COPY YES. This feature is enabled by the DSNZPARM SYSTEM_LEVEL_BACKUPS.

There are two main differences between a recovery with SLB and a recovery with normal sequential image copies:

If the RECOVER fails on the selected SLB, then RECOVER does not do an automatic fallback.

If the RECOVER includes a list of objects, then RECOVER processes the restores in sequential mode, even if the keyword PARALLEL is specified and is indicated by an appropriate message:

DSNU427I 318 13:53:56.09 DSNUCBMT - OBJECTS WILL BE PROCESSED IN PARALLEL,

NUMBER OF OBJECTS = 30

APAR PM55092 addresses this restriction.

The following topics list examples of RECOVER of single objects on an SLB, and what should be considered. They are all executed in “Test Environment 3”.

Scenario 1: Base example

A BACKUP SYSTEM on the data pool is taken:



© 2012 SAP AG 71

DSNU050I 319 12:13:27.95 DSNUGUTC - BACKUP SYSTEM DATA ONLY



TOKEN = X'E2F2F3F1C8AD45C6475DC5AEC8AD4460EF57'.

DSNU1614I 319 12:13:48.72 DSNUVBBD - BACKUP SYSTEM UTILITY FOR DATA COMPLETED SUCCESSFULLY,


TOKEN = X'E2F2F3F1C8AD45C6475DC5AEC8AD4460EF57'

DATA COMPLETE LRSN = X'C8AD45D8FA67'


DSNU1602I 319 12:13:53.06 DSNUVBBD - BACKUP SYSTEM UTILITY COMPLETED, ELAPSED TIME = 00:00:24.

Afterwards a RECOVER to current on some objects is scheduled:

DSNU1520I 319 12:27:49.81 DSNUCBMT - THE RECOVERY BASE FOR TABLESPACE HARTDB.HARTTS1 IS THE

SYSTEM LEVEL BACKUP WITH DATE = 20111115, TIME 121348, AND TOKEN

X'E2F2F3F1C8AD45C6475DC5AEC8AD4460EF57'

DSNU1527I 319 12:27:58.98 DSNUCBMT - TABLESPACE HARTDB.HARTTS1 DSNUM 1 WAS SUCCESSFULLY RESTORED

FROM A FLASHCOPY, ELAPSED TIME=00:00:09

…

DSNU513I -S231 319 12:28:09.00 DSNUCALA - RECOVER UTILITY LOG APPLY RANGE IS RBA 0006E786B601 LRSN

C8AD4536F878 TO RBA 0006E786D732 LRSN C8AD4536F9DE

Consider also that beginning with DB2 V10 REPORT RECOVERY includes the SLB into its output listing:

DSNU582I -S231 319 12:37:58.16 DSNUPPCP - REPORT RECOVERY TABLESPACE HARTDB.HARTTS1

SYSCOPY ROWS

AND SYSTEM LEVEL BACKUPS

…

TIMESTAMP = 2011-11-15-12.12.04.844256, TYPE = SLB, RBLP =C8AD4460EF57

TOKEN = E2F2F3F1C8AD45632E510CECC8AD4460EF57,MEMBER NAME = S231,DATA COMPLETE

LRSN=C8AD4575C7D5

…

DB2 converts the RECOVER statements into appropriate FRRECOV statements on object level.

Appropriate messages showed in the HSM message log:

ARC1801I FAST REPLICATION DATA SET RECOVERY IS

ARC1801I (CONT.) STARTING FOR DATA SET

ARC1801I (CONT.) DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001, AT 13:58:07 ON

ARC1801I (CONT.) 2011/11/15

ARC1861I THE FOLLOWING 0001 DATA SET(S) WERE

ARC1861I (CONT.) SUCCESSFULLY PROCESSED DURING FAST REPLICATION DATA

ARC1861I (CONT.) SET RECOVERY:

ARC1861I (CONT.) DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001, COPYPOOL=DSN$DDFS231$DB, DEVTYPE=DASD

ARC1802I FAST REPLICATION DATA SET RECOVERY HAS

ARC1802I (CONT.) COMPLETED FOR DATA SET


ARC1802I (CONT.) 2011/11/15, FUNCTION RC=0000, MAXIMUM DATA SET RC=0000

HSM converts these FRRECOV commands into appropriate DFDSS COPY commands. These commands can be found in the HSM backup log:



© 2012 SAP AG 72

ARC0640I GDSN01 - ADR035I (SCH)-PRIME(06), INSTALLATION EXIT ALTERED BYPASS FAC CLASS CHK DEFAULT TO

YES

ARC0640I GDSN01 - COPY DS(INC(DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001 )) -

ARC0640I GDSN01 - PHYSINDY(SAPFJ6) OUTDYNAM(SAPDJ3) -

ARC0640I GDSN01 - BYPASSACS(DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001 ) -

ARC0640I GDSN01 - ALLDATA(*) ALLEXCP REPLACEU CANCELERROR -

ARC0640I GDSN01 - FORCECP(0) PROCESS(SYS1) -

ARC0640I GDSN01 - STORCLAS(DB2DJ ) -

ARC0640I GDSN01 - MGMTCLAS(DB2 ) -

ARC0640I GDSN01 - DEBUG(FRMSG(DTL)) -

ARC0640I GDSN01 - FASTREPLICATION(NONE )

ARC0640I GDSN01 - ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'COPY '

If FASTREPLICATION(NONE) is specified, the following message is issued to indicate this:

ARC0640I GDSN01 - ADR918I (001)-DDDS (01), FAST REPLICATION COULD NOT BE USED FOR THIS

COPY TASK, RETURN CODE 7

If FASTREPLICATION(REQUIRED) and FASTREPLICATION(PREFERRED) is used and FlashCopy is really used, it is indicated by:

ARC0640I GDSN01 - ADR806I (001)-T0MI (03),

DATA SET DB23.DSNDBC.HARTDB.HARTTS2.I0001.A001 COPIED USING A FAST REPLICATION

FUNCTION

One of the parameters which can be influenced is FASTREPLICATION by setting and querying it by the appropriate SETSYS command:

HSEND SETSYS FASTREPLICATION(DATASETRECOVERY(NONE))

HSEND Q SETSYS

ARC0101I QUERY SETSYS COMMAND STARTING ON HOST=D

…

ARC1823I MAXCOPYPOOL (FRBACKUP TASKS=0015, FRRECOV TASKS=0015, DSS TASKS=0024),

ARC1823I (CONT.) FASTREPLICATION(DATASETRECOVERY=NONE FCRELATION=EXTENT

ARC1823I (CONT.) VOLUMEPAIRMESSAGES=YES)

…

ARC0101I QUERY SETSYS COMMAND COMPLETED ON HOST=D

The other keyword which is decisive in a PPRC environment is the FCTOPPRCP keyword (Preserve Mirror). For considerations of this keyword refer to section Ensuring Volumes always Remain in Full Duplex Mode with BACKUP SYSTEM and PPRC on page 92.

Scenario 2: Some unusual error situations

A BACKUP SYSTEM on the data pool is taken and the following topics describe some problem situations:

Volumes are offline

The volumes, on which the latest SLB is located, are varied OFFLINE.

RECOVER issues the following messages:

DSNU050I 319 13:42:16.70 DSNUGUTC - RECOVER TABLESPACE HARTDB.HARTTS1 TABLESPACE HARTDB.HARTTS2



X'E2F2F3F1C8AD45C6475DC5AEC8AD4460EF57'



© 2012 SAP AG 73

DSNU1522I 319 13:42:16.84 DSNUCBMT - THE DFSMSHSM CALL TO RESTORE TABLESPACE HARTDB.HARTTS1 DSNUM

1

FAILED WITH RC = X'0000005D' AND REASON CODE = X'00000042'

SEE THE JOB LOG FOR DFSMSHSM MESSAGES INDICATING THE CAUSE OF THE ERROR

DSNU562I -S231 319 13:42:16.85 DSNUGSRX - TABLESPACE HARTDB.HARTTS1 IS IN RECOVER PENDING

Consider also that even there is no real recovery done on the tablespace object it is set to RECP. There is also an existing requirement to relief this (MR0809072057).

In HSM message log the following messages could be found:




ARC1801I (CONT.) 2011/11/15

ARC0624I PHYSICAL DATA SET COPY OF VOLUME

ARC0624I (CONT.) DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001 TERMINATED

ARC0624I (CONT.) PRIOR TO COMPLETION, DFSMSDSS FAILING RC = 8

ARC1860I THE FOLLOWING 0001 DATA SET(S) FAILED DURING

ARC1860I (CONT.) FAST REPLICATION DATA SET RECOVERY:

ARC1860I (CONT.) DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001, COPYPOOL=DSN$DDFS231$DB,

DEVTYPE=DASD, VOLUME=SAPDJ3, ARC1166, RC=0008





HSM backup log has:

ARC1801I FAST REPLICATION DATA SET RECOVERY IS STARTING FOR DATA SET

DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001, AT 13:42:16 ON 2011/11/15

ARC1860I THE FOLLOWING 0001 DATA SET(S) FAILED DURING FAST REPLICATION DATA SET RECOVERY:


DEVTYPE=DASD, VOLUME=SAPDJ3, ARC1166, RC=0008

ARC1802I FAST REPLICATION DATA SET RECOVERY HAS COMPLETED FOR DATA SET

DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001, AT 13:42:16 ON 2011/11/15, FUNCTION RC=0008,

MAXIMUM DATA SET RC=0093

Original data set is deleted

Before RECOVER utility runs, the object is completely deleted. Since z/OS 1.11 HSM captures also the catalog information for the copied objects. This can be configured at the appropriate COPY POOL definition panel:



© 2012 SAP AG 74

Screenshot 18. Copy Pool Display

During the restore HSM knows by this catalog capture feature on which backup volume the object resides. And hence RECOVER is able to run successfully.

The target volume is set to DISNEW

Before the RECOVER utility runs, the object is completely deleted. DFDSS specifies the target volumes during recovery, but it overrides the DISNEW (=disable new) status of the target volume.

The target volume is full

HSM generates DFDSS COPY commands in which the target volume is explicitly specified:

ARC0640I GDSN01 - ADR035I (SCH)-PRIME(06), INSTALLATION EXIT ALTERED BYPASS FAC CLASS CHK

DEFAULT TO YES










ARC0640I GDSN01 - ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'COPY

'



© 2012 SAP AG 75

If the target volume SAPDJ2 is full, RECOVER utility issues the following messages:

DSNU050I 325 15:13:12.12 DSNUGUTC - RECOVER TABLESPACE HARTDB.HARTTS1 TABLESPACE

HARTDB.HARTTS2

DSNU1520I 325 15:13:12.18 DSNUCBMT - THE RECOVERY BASE FOR TABLESPACE HARTDB.HARTTS1

IS THE SYSTEM LEVEL BACKUP WITH DATE = 20111121, TIME 143801, AND TOKEN

X'E2F2F3F1C8B4F131F8FFB729C8B4F0349F0C'

DSNU1522I 325 15:13:14.56 DSNUCBMT - THE DFSMSHSM CALL TO RESTORE TABLESPACE

HARTDB.HARTTS1 DSNUM 1



DSNU562I -S231 325 15:13:14.56 DSNUGSRX - TABLESPACE HARTDB.HARTTS1 IS IN RECOVER

PENDING

And in HSM backup log there are the appropriate DFDSS messages which indicate such a problem:

ARC0640I GDSN01 - ADR709E (001)-VDSS (01),

AN ERROR OCCURRED IN THE STORAGE MANAGEMENT SUBSYSTEM WHILE ALLOCATING DATA SET

ARC0640I GDSN01 - DB23.DSNDBD.HARTDB.HARTTS1.I0001.A001. SMS MESSAGES FOLLOW.

ARC0640I GDSN01 - IGD17365I EXTENT REDUCTION FAILED FOR DATA SET

ARC0640I GDSN01 - DB23.DSNDBD.HARTDB.HARTTS1.I0001.A001

ARC0640I GDSN01 - ADR809I (001)-VDSS (01), ADDITIONAL DIAGNOSTIC DATA FOR PRECEDING

MESSAGE:

ARC0640I GDSN01 - SC=DB2DJ MC=DB2 DC=XVSAMS

ARC0640I GDSN01 - REQPRI=0000000003TRK REQSEC=0000000015TRK

REQVOLS=01

ARC0640I GDSN01 - ADR801I (001)-DDDS (01),

From the above examples it may sometimes seem difficult to track down the correct and complete problem by the return and reason codes. Two procedures may help to tackle the real cause of the problem:

Issue FRRECOV directly

The RECOVER utility internally converts the RECOVER statement to appropriate FRRECOV commands. They can also be scheduled directly to HSM:

HSEND FRRECOV DSNAME(DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001) REPLACE

FROMCOPYPOOL(DSN$DDFS231$DB) FR(PREFERRED) VERSION(1)

This FRRECOV results in the following DFDSS Copy statements:

ARC0640I GDSN01 - ADR035I (SCH)-PRIME(06), INSTALLATION EXIT ALTERED BYPASS FAC CLASS

CHK DEFAULT TO YES









ARC0640I GDSN01 - FASTREPLICATION(PREFERRED)



© 2012 SAP AG 76

Run DFDSS directly

HSM internally converts the FRRECOV statement to appropriate DFDSS COPY commands. They can also be scheduled directly to DFDSS:

//DFDSSCMD EXEC PGM=ADRDSSU PARM='TYPRUN=NORUN'


//SYSIN DD *

COPY DS(INC(DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001 )) -

PHYSINDY(SAPFJ3) OUTDYNAM(SAPDJ3) -

BYPASSACS(DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001 ) -

ALLDATA(*) ALLEXCP REPLACEU CANCELERROR -

FORCECP(0) PROCESS(SYS1) -

STORCLAS(DB2DJ ) -

MGMTCLAS(DB2 ) -

DEBUG(FRMSG(DTL)) -

FASTREPLICATION(NONE )

Be aware that this job does not run if the input data set has not been pre-allocated. HSM can cope with not allocated data sets by using the information collected during catalog capture.

Scenario 3: Recovery of single objects while incremental system-level FlashCopy relationship exists

The following examples are based on the incremental FlashCopy backup scenario, which is described in section BACKUP SYSTEM using Incremental FlashCopy on page 61. Three cases can occur if such an incremental relationship exists:

FASTREPLICATION (DATASETRECOVERY (NONE))

RECOVER runs on objects and issues the following messages:




X'E2F2F3F1C8B4FF51BA9A4060C8B4FE82BC12'








DSNU1511I -S231 325 15:57:53.99 DSNUCALA - FAST LOG APPLY WAS NOT USED FOR RECOVERY

…

HSM generates the following DFDSS COPY commands:


YES




© 2012 SAP AG 77










FASTREPLICATION (DATASETRECOVERY (PREFERRED))

RECOVER issues the same messages as in the previous example and hence it runs. Also, HSM generates nearly the same statement except for the FASTREPLICATION parameter:


YES









ARC0640I GDSN01 - FASTREPLICATION(PREFERRED)


…

ARC0640I GDSN01 - ADR442I (001)-PPRVS(01), DATA SET DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001

PREALLOCATED, IN CATALOG SYS1.USERCAT.DB23, ON VOLUME(S):

ARC0640I GDSN01 - SAPDJ2

ARC0640I GDSN01 - ADR918I (001)-PCVSM(04),

FAST REPLICATION COULD NOT BE USED FOR DATA SET DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001, RETURN

CODE 9

ARC0640I GDSN01 - VOLUME SAPFJ2 WAS REJECTED FOR QFRVOLS VOLUME REASON

CODE B - FULL VOL FC

TARGET RELATION

ARC0640I GDSN01 - VOLUME SAPDJ2 WAS REJECTED FOR QFRVOLS VOLUME REASON

CODE C - FULL VOL FC

SOURCE RELATION

ARC0640I GDSN01 - ADR801I (001)-DDDS (01),

2011.325 16:00:05 DATA SET FILTERING IS COMPLETE. 1 OF 1 DATA SETS WERE SELECTED: 0 FAILED

SERIALIZATION

ARC0640I GDSN01 - AND 0 FAILED FOR OTHER REASONS

ARC0640I GDSN01 - ADR454I (001)-DDDS (01), THE FOLLOWING DATA SETS WERE SUCCESSFULLY PROCESSED

ARC0640I GDSN01 - CLUSTER NAME DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001

ARC0640I GDSN01 - COMPONENT NAME DB23.DSNDBD.HARTDB.HARTTS1.I0001.A001

Due to the PREFERRED specification, the copy is done without using FlashCopy. The ADR918I message is issued to explain that FlashCopy was not used because the volumes were already in full volume FlashCopy relationships..



© 2012 SAP AG 78

FASTREPLICATION (DATASETRECOVERY (REQUIRED))

RECOVER now does not run because two FlashCopy relations cannot exist at one time.






1




HSM issues the following messages:


YES









ARC0640I GDSN01 - FASTREPLICATION(REQUIRED )


ARC0640I GDSN01 - ADR109I (R/I)-RI01 (01), 2011.325 16:03:55 INITIAL SCAN OF USER CONTROL STATEMENTS

COMPLETED

ARC0640I GDSN01 - ADR050I (001)-PRIME(02), DFSMSDSS INVOKED VIA CROSS MEMORY APPLICATION INTERFACE

ARC0640I GDSN01 - ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK

ARC0640I GDSN01 - ADR006I (001)-STEND(01), 2011.325 16:03:55 EXECUTION BEGINS

ARC0640I GDSN01 - ADR442I (001)-PPRVS(01), DATA SET DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001

PREALLOCATED, IN CATALOG SYS1.USERCAT.DB23, ON VOLUME(S):

ARC0640I GDSN01 - SAPDJ2

ARC0640I GDSN01 - ADR918I (001)-PCVSM(04),

FAST REPLICATION COULD NOT BE USED FOR DATA SET DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001, RETURN

CODE 9

ARC0640I GDSN01 - VOLUME SAPFJ2 WAS REJECTED FOR QFRVOLS VOLUME REASON

CODE B - FULL VOL FC TARGET RELATION

ARC0640I GDSN01 - VOLUME SAPDJ2 WAS REJECTED FOR QFRVOLS VOLUME REASON

CODE C - FULL VOL FC SOURCE RELATION

ARC0640I GDSN01 - ADR938E (001)-PCVSM(04),

FASTREPLICATION(REQUIRED) WAS SPECIFIED BUT FAST REPLICATION COULD NOT BE USED FOR DATA SET

ARC0640I GDSN01 - DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001

…

ARC0640I GDSN01 - ADR470W (001)-DDDS (04), NO DATA SETS SELECTED FOR PROCESSING

Scenario 4: Parallel processing

This scenario shows the implications of the missing cascaded FlashCopy support. During execution timeframe of a BACKUP SYSTEM, a parallel RECOVER on an SLB fails with the following messages. The RECOVER addresses the previously created SLB:



© 2012 SAP AG 79




X'E2F2F3F1C8B5E62A86262429C8B5E52E546A'


1

FAILED WITH RC = X'00000042' AND REASON CODE = X'0000001C'



The already active BACKUP SYSTEM creates the following SLB:




TOKEN = X'E2F2F3F1C8B5E69C583E5CAEC8B5E5A0C556'.



TOKEN = X'E2F2F3F1C8B5E69C583E5CAEC8B5E5A0C556'

DATA COMPLETE LRSN = X'C8B5E6AD8E66'



HSM has the following messages in its message log:

ARC1801I FAST REPLICATION BACKUP IS STARTING FOR COPY

ARC1801I (CONT.) POOL DSN$DDFS231$DB, AT 08:55:38 ON 2011/11/22,

ARC1801I (CONT.) TOKEN=X'E2F2F3F1C8B5E69C583E5CAEC8B5E5A0C556'




ARC1801I (CONT.) 2011/11/22

ARC1860I THE FOLLOWING 0001 DATA SET(S) FAILED DURING

ARC1860I (CONT.) FAST REPLICATION DATA SET RECOVERY:

ARC1860I (CONT.) DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001, COPYPOOL=DSN$DDFS231$DB, DEVTYPE=DASD,

VOLUME=SAPDJ2, ARC1866, RC=28





ARC1805I THE FOLLOWING 00003 VOLUME(S) WERE

ARC1805I (CONT.) SUCCESSFULLY PROCESSED BY FAST REPLICATION BACKUP OF

ARC1805I (CONT.) COPY POOL DSN$DDFS231$DB

…

It is expected that the execution of BACKUP SYSTEM and RECOVER is coordinated by the user. Therefore, it is not allowed to run these utilities in parallel.

Flipping the example and running first a RECOVER and then trying to run BACKUP SYSTEM results in the following messages:

BACKUP SYSTEM:




© 2012 SAP AG 80



TOKEN = X'E2F2F3F1C8D20F8645AF636CC8D20F174AAD'.

DSNU1631I 348 18:27:46.32 DSNUVBBD - BACKUP SYSTEM UTILITY FAILED BECAUSE THE CALL TO DFSMSHSM

FAILED WITH RC = X'00000006' REASON = X'0000001C'.


DSNU012I 348 18:27:47.04 DSNUGBAC - UTILITY EXECUTION TERMINATED, HIGHEST RETURN CODE=8

And the appropriate messages in the HSM message log are:




ARC1801I (CONT.) 2011/12/14





DEVTYPE=DASD








ARC1801I (CONT.) 2011/12/14

ARC1806E FAST REPLICATION BACKUP HAS FAILED FOR COPY

ARC1806E (CONT.) POOL DSN$DDFS231$DB, RC=0028

ARC1802I FAST REPLICATION BACKUP HAS COMPLETED FOR

ARC1802I (CONT.) COPY POOL DSN$DDFS231$DB, AT 18:27:46 ON 2011/12/14,






DEVTYPE=DASD





BACKUP SYSTEM and Growing or Shrinking of SAP Systems

Over time, SAP systems may grow of the system is becoming more active. For example, a SAP banking system may process more and more business partners and accounts. In other cases, a SAP system may shrink due to a more aggressive archiving of SAP data. This dynamic nature of SAP systems may require you to add volumes to the HSM copy pools or to remove volumes. In both cases, you should create a new system-level backup right after you have expanded or contracted the copy pool. That way you have a new backup available that can be directly used in case of a later recovery to a point in time after the expansion / contraction.



© 2012 SAP AG 81

Adding volumes

If you need to add volumes to a copy pool, corresponding action need to be taken for its backup storage group if you do not exploit Space-efficient FlashCopy. For example, if you rely on incremental FlashCopy and add two volumes to the copy pool, then two volumes need to be added per backup generation that is kept in the backup storage group. Later, if it turns out that the DB2 subsystem needs to be recovered to a prior point in time before these volumes were added, remove these volumes from the copy pool (or use ICKDSF.to initialize them) and then perform a regular DB2 system-level recovery using RESTORE SYSTEM. In order to identify these volumes, you should keep track of the evolution of the copy pool and storage group definition.

Removing volumes

If the size of an SAP system has been reduced, you may be able to contain the data in fewer volumes. Volumes that do not contain any data anymore may then be removed from the copy pool. However, the existing backups still contain these volumes. So if there is a reason to later restore such a backup, it would not fit into the copy pool anymore. To address this situation, you can do the following:

Keep track of when volumes were removed from a copy pool

Removes these volumes also from the corresponding backup storage group

If a backup with more volumes needs to be restored, then add volumes to the copy pool again

DB2 10 Object-Level FlashCopy for Inline Image Copies in Combination with BACKUP SYSTEM

One of the new features in DB2 10 is the use of data set level FlashCopy for image copy, also known as FCIC. Not only is this a faster way of obtaining an image copy, but it offloads copy processing from the host to the DASD subsystem. FCIC can be used for obtaining an inline image copy during an online REORG. Reference the DB2 Utility guide for information on requirements and restrictions on using FCIC. Also, reference the DB2 installation for guidance on setting up the DB2 system parameters in support of using FCIC. There are two of ways to request that FlashCopy be used for the inline image copy. 1. Specify the FlashCopy option by using DB2 subsystem parameters

FLASHCOPY_COPY specifies if FlashCopy is the default when running image copy

FLASHCOPY_REORG_TS specifies if FlashCopy is the default for inline copy during REORG

FLASHCOPY_REBUILD_INDEX specifies if FlashCopy is the default for inline copy during REBUILD

FLASHCOPY_REORG_INDEX specifies if FlashCopy is the default for inline copy during REORG

FCCOPYDDN provides the template for the data set name of the image copy 2. Utility control statement parameters FLASHCOPY_REORG_TS subsystem parameter to YES, which specifies that REORG TABLESPACE is to use FLASHCOPY(YES) by default. The value that you specify for the FLASHCOPY option in the REORG TABLESPACE statement always overrides the value for the FLASHCOPY_REORG_TS subsystem parameter. Optionally, you can also specify FCCOPYDDN in the REORG TABLESPACE statement. Use this option to specify a template for the FlashCopy image copy. If you do not specify the FCCOPYDDN option in the REORG TABLESPACE statement, the utility uses the value from the FCCOPYDDN subsystem parameter. Restriction: The data sets that you specify for the FlashCopy image copy must be on FlashCopy Version 2 disk volumes. The table spaces DSN00011.REPOSRC and DSN00011.LFSEE2O5 were REORG’d using SHRLEVEL CHANGE and the inline image copies were obtained using the new FlashCopy Image copy (FCIC) feature available in DB2 10. In our testing we used the DB2 subsystem parameters for making FlashCopy the default and providing the template for the image copy data set name:



© 2012 SAP AG 82

FCCOPYDDN=DB22IC.&&DB..&&SN..N&&DSNUM..&&UQ.,

FLASHCOPY_COPY=YES,

FLASHCOPY_REORG_TS=YES,

FLASHCOPY_REBUILD_INDEX=YES,

FLASHCOPY_REORG_INDEX=YES,

FLASHCOPY_LOAD=YES Be aware of the different fast replication options used by the different DB2:

COPY utility: FASTREPLICATION PREFERRED

REORG utility: FASTREPLICATION REQUIRED (since APAR PM34776)

REBUILD utility: FASTREPLICATION PREFERRED

LOAD utility: FASTREPLICATION PREFERRED

RECOVER utility: As controlled by DB2ZPARM REC_FASTREPLICATION

CHECK utilities: As controlled by DB2 ZPARM CHECK_FASTREPLICATION At the time the online REORGs were executed, the DSN$DDFDB22$LG and DSN$DDFDB22$DB copy pools were in FlashCopy relationships with their copy pool backup storage groups.




ARC1820I (CONT.) DB2DIL SAPDIL SAPFIL 001




ARC1820I (CONT.) DB2DI SAPDI1 SAPFI1 002




***

The current backup for DSN$DDFDB22$DB is available to be used in a Fast Replication Restore process. COPYPOOL=DSN$DDFDB22$DB



TOKEN(C)=C'DB22I G7 §/a 3 "'

TOKEN(H)=X'C4C2F2F2C906C7F73D7C61810012F3BF8C7F'





NO NONE ********* ****************************************


SAPDI1 WA4989 3490

FILE SEQ=00, DSNAME=SAP.DMP.DB2DP03M.VSAPDI1.D12025.T494916

SAPDI2 WA4286 WA4288 3490


SAPDI3 WA4284 3490


So, while the DSN$DDFDB22$DB copy pool was in an existing FlashCopy relationship the tablespaces DSN00011.REPOSRC and DSN00011.LFSEE2O5 were REORG’d using SHRLEVEL CHANGE. As can be seen in the JCL and utility control statement below, only the base tablespace belonging to a LOB was specified in the REORG. However, both the base and LOB tablespaces were REORG’d.



© 2012 SAP AG 83

//REORG25A JOB (DE03557),CH,NOTIFY=MARY,


// TIME=120,CLASS=A,REGION=0M TYPRUN=SCAN

/*JOBPARM SYSAFF=SAPC

//STEP1 EXEC DSNUPROC,UID=MARY.REORG,UTPROC=,SYSTEM=DB22

//STEPLIB DD DSN=DB22L.V100.SDSNLOAD,DISP=SHR

//SYSIN DD *

REORG TABLESPACE DSN00011.REPOSRC LOG NO

DRAIN ALL

RETRY 5

RETRY_DELAY 5

SHRLEVEL CHANGE MAPPINGTABLE MYMAPPING_TABLE

/*

The following HSM messages are included in the REORG job output. The ADR030I message provides the COPY statement used when image copying both the base tablespace and LOB tablespace. As can be seen Fast Replication is specified as required, FR(REQ). The ADR806I messages indicate fast replication was used for obtaining the inline image copies.

ADR030I (SCH)-PRIME( 0), DCB VALUES HAVE BEEN MODIFIED FOR SYSPRINT.

COPY DATASET(INCLUDE( -

DB22.DSNDBC.DSN00011.REPOSRC.I0001.A001 , -

DB22.DSNDBC.DSN00011.LFSEE2O5.I0001.A001 )) -

RENAMEU( -

(DB22.DSNDBC.DSN00011.REPOSRC.I0001.A001 , -

DB22IC.DSN00011.REPOSRC.N00001.DNRT1E8S ) -

(DB22.DSNDBC.DSN00011.LFSEE2O5.I0001.A001 , -

DB22IC.DSN00011.LFSEE2O5.N00001.DNRT1E81 )) -

REPUNC ALLDATA(*) ALLEXCP CANCELERROR SHARE FR(REQ) -

VOLCOUNT(ANY) TGTALLOC(SRC) -

WRITECHECK TOLERATE(ENQF)

.

.

.

ADR711I (001)-NEWDS(01), DATA SET DB22.DSNDBC.DSN00011.REPOSRC.I0001.A001 HAS BEEN

ALLOCATED WITH NEWNAME DB22IC.DSN00011.REPOSRC.N00001.DNRT1E8S USING STORCLAS SMS,

DATACLAS XVSAMS, AND MGMTCLAS DB2

ADR806I (001)-T0MI (03), DATA SET DB22.DSNDBC.DSN00011.REPOSRC.I0001.A001 COPIED USING A

FAST REPLICATION FUNCTION

ADR711I (001)-NEWDS(01), DATA SET DB22.DSNDBC.DSN00011.LFSEE2O5.I0001.A001 HAS BEEN

ALLOCATED WITH NEWNAME DB22IC.DSN00011.LFSEE2O5.N00001. DNRT1E81 USING STORCLAS SMS, DATACLAS XVSAMS, AND MGMTCLAS DB2

ADR806I (001)-T0MI (03), DATA SET DB22.DSNDBC.DSN00011.LFSEE2O5.I0001.A001 COPIED USING A


After the REORG the Report Recovery utility was executed for DSN00011.REPOSRC. You can see from the job output below the recovery record for the SLB followed by the REORG and then the Full Copy. Notice the IC BACK for the Full Copy indicates FlashCopy (FC).

TIMESTAMP = 2012-01-25-16.50.19.231118, TYPE = SLB ,

TOKEN = C4C2F2F2C906C7F73D7C61810012F3BF8C7F , MEMBER NAME =

TIMESTAMP = 2012-01-25-19.47.02.604436, IC TYPE = *W*, SHR LVL = , DSNUM

DEV TYPE = , IC BACK = , STYPE = , FILE SEQ

LOW DSNUM = 0000, HIGH DSNUM = 0000, OLDEST VERSION = 0000, LOGICAL PART

JOBNAME = REORG25A, AUTHID = MARY , COPYPAGESF = -1.0E+00



© 2012 SAP AG 84

NPAGESF = -1.0E+00 , CPAGESF = -1.0E+00

DSNAME = DSN00011.REPOSRC , MEMBER NAME =

TIMESTAMP = 2012-01-25-19.47.03.133331, IC TYPE = F , SHR LVL = R, DSNUM

DEV TYPE = , IC BACK = FC, STYPE = T, FILE SEQ

LOW DSNUM = 0001, HIGH DSNUM = 0001, OLDEST VERSION = 0000, LOGICAL PART

JOBNAME = REORG25A, AUTHID = MARY , COPYPAGESF = -1.0E+00


DSNAME = DB22IC.DSN00011.REPOSRC.N00001.DNRT1E8S , MEMBER NAME =

BACKUP SYSTEM with Mirrored Volumes (PPRC and RPFC)

In chapter 3, the benefits of Remote Pair FlashCopy (RPFC) were described when mirroring volumes. In this use case, you can see how to enable this functionality. The implementation and setup of RPFC needs a detailed planning:

1. DS8000: the appropriate feature is installed in the disk subsystem by the matching firmware. For DS8300 the level 4.33 is needed, for the latest DS8800 we recommend to have 6.1.* or later firmware implemented.

2. z/OS: with z/OS 1.11 and later, all required features are implemented, installations with e.g. z/OS 1.9 need some PTFs to enable “preserve mirror” and “Enable FlashCopy” to a PPRC Primary Volume.

3. DB2: no specific enhancements are needed, when on the latest DB2 10 software level.

The activation of RPFC can be performed through different interfaces:

1. DFDSS Job and ADRDSSU: //COPY01 EXEC PGM=ADRDSSU


//DASD1 DD UNIT=3390,VOL=SER=SLC400,DISP=OLD

//DASD2 DD UNIT=3390,VOL=SER=SLC401,DISP=OLD

COPY DS(INCLUDE(USER.TEST.DATA)) –

INDDNAME(DASD1) –

OUTDDNAME(DASD2) –

FASTREP(REQ) –

FCTOPPRCP(PMR) –

DEBUG(FRMSG(DETAILED))

The following figure shows the syntax of the HSM FCESTABLISH command.



© 2012 SAP AG 85

2. ISMF interface within TSO/ISPF dialog session (expert display modus is ON)

Screenshot 19. ISMF Primary Option Menu

Setup lab environment

In this testing series, the ISMF option was chosen to document the options and monitor the implementation. The “Copy pool list” option shows the following definition, however for the final run, the option was changed to “PR”:

Screenshot 20. ISMF backup copy pool preserve mirror options

The ISMF help information shows the different options, which are allowed for FRBACKUP processing:

Screenshot 21. ISMF Primary Option Menu - Help

Setup Summary

Carefully check the DS8K firmware prerequisites

Maintain the z/OS and DB2 10 software level



© 2012 SAP AG 86

Configure HSM to exploit RPFC, there is no additional configuration in Subsystem level needed:

o None – Use “old way” (primary goes duplex pending, and transfers all target tracks)

o Preferred – Use Preserve Mirror (inband FLC to secondary) if possible (e.g., secondary FLC source and target are in same box), otherwise, use “old way”

o Required – This option is preferred with DB2: Fail FLC establish if it is not possible to establish FLC on primary without causing FLC target on primary to go duplex pending. (i.e., cannot use “old way”)

Run RPFC testcase

For an overview and reviving the previously shown infrastructure, here is the layout of the disk- and storage organization for RPFC preserved mirror in the DB21 subsystem:

Figure 24. Overview RPFC testing environment

The testcase after successful configuration of the RPFC in HSM is a simple task by executing a straightforward DB2 BACKUP SYSTEM FULL testing scenario.

Following the setup, the standard DB2 backup utility with the option “full” was submitted.

//SAPDEBS JOB CLASS=A,REGION=0M, 00001000

// MSGLEVEL=(1,1),MSGCLASS=X,NOTIFY=&SYSUID 00003000

/*JOBPARM SYSAFF=* 00004004

//* 00005000

//*******DB2 BACKUP SYSTEM ************************************* 00006000

//BACKUP EXEC DSNUPROC,SYSTEM=DB21, 00007001

//DSNUPROC.SYSIN DD * 00009001

DB21_A

DB2DG1. SAPDG1

2. SAPDG2

3. SAPDG3

DB2DGL1. SAPDGL

CopyPool data/log

DB2FG1. SAPFG1

2. SAPFG2

3. SAPFG3

DB2FGL1. SAPFGL

Backup CopyPool

data/log

…1. SAPDH1

2. SAPDH2

3. SAPDH3

…1. SAPDHL

PPRC CopyPool

data/log

…1. SAPFH1

2. SAPFH2

3. SAPFH3

…1. SAPFHL

RPFC Backup

CopyPool data/log

DB21_B



© 2012 SAP AG 87

BACKUP SYSTEM FULL 00009101

/* 00009201

// 00009301

Typically, the DB2 job log gives within very short response time the result including the information of the HSM token. The DB2 Job execution time is just the time needed for DB2, HSM preparation and validation. It does not include the FC background processing times. For this, more HSM and SYSLOG information (fcquery poolname, etc.) need to be applied:

Screenshot 22. Result DB2 backup system utility

Obtaining DFSMShsm fast replication backup information, you can use the QUERY, LIST , and REPORT commands, or the ARCXTRCT macro to obtain information regarding the fast replication backup versions that DFSMShsm is managing.

Monitoring the HSM log now shows the detail of the FC background process ( as documented in several chapters before) by assigning the token for HSM and DB2 reporting all steps and HSM “ARC*” messages.

Finally the flow of information by the DB2 BACKUP SYSTEM utility in the RPFC environment at primary site is the same on the secondary site, however, in a loosely coupled and asynchronous sequence. As physical data are not transferred from primary site to secondary site via PPRC, only the FC command is sent to the secondary site and executes independently. The difference can be identified by reporting and monitoring the secondary site offline volumes with the HSM FC query commands. Again, there are multiple choices as mentioned above. In addition, some customers may also include the DS8K, GDPS or TPC-R – GUIs.

Here the FC query for primary and secondary site volumes, displaying the status and the progress of the background copy process.

Job 599 FCquery prim_site all pairs Job 602 FCquery sec_site all pairs

FCQUERY DEVN('8E00') SHOWRELS(ALL) ANTF0421I FCQUERY Relationship 1 DEVN SSID LSS CCA CU SERIAL ACT MAX XC PC CC RV SE SEQNUM 8E00 8E00 0E 00 2107 0000000AVPD1 7 65534 N P N N NN 00000000 RELATIONSHIP DETAIL STARTING TRACK: 00000000 DEVICE LONG BUSY FOR CG: NO WRITE INHIBITED: NO --------------------------------------------------- PARTNER SOURCE TARGET S F C C P C T S F P LSS CCA SSID START START O V O A R R W E S M --- --- ---- -------- -------- - - - - - - - - - - 0E 10 8E00 00000001 00000001 Y N Y N N N Y N N N NO. OF TRACKS: 0000274F TRACKS TO COPY: 0000274F ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06

FCQUERY DEVN('7E00') SHOWRELS(ALL) ANTF0421I FCQUERY Relationship 1 DEVN SSID LSS CCA CU SERIAL ACT MAX XC PC CC RV SE SEQNUM 7E00 7E00 0E 00 2107 0000000CCTA1 1 65534 N S N N NN 00000000 RELATIONSHIP DETAIL STARTING TRACK: 00000000 DEVICE LONG BUSY FOR CG: NO WRITE INHIBITED: NO --------------------------------------------------- PARTNER SOURCE TARGET S F C C P C T S F P LSS CCA SSID START START O V O A R R W E S M --- --- ---- -------- -------- - - - - - - - - - - 0E 10 7E00 03640000 03640000 Y N Y Y N N Y N N S NO. OF TRACKS: 00020BC3 TRACKS TO COPY: 0000A2B3 ANTF0001I FCQUERY COMMAND COMPLETED FOR DEVICE 7E00, COMPLETION CODE: 00



© 2012 SAP AG 88

0E 10 8E00 03640000 03640000 Y N Y N N N Y N N N NO. OF TRACKS: 00020BC3 TRACKS TO COPY: 00020BC3 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 10 8E00 266E0002 266E0002 Y N Y N N N Y N N N NO. OF TRACKS: 00000279 TRACKS TO COPY: 00000279 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 10 8E00 26980006 26980006 Y N Y N N N Y N N N NO. OF TRACKS: 0000019B TRACKS TO COPY: 0000019B ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 10 8E00 26B3000D 26B3000D Y N Y N N N Y N N N NO. OF TRACKS: 0000001E TRACKS TO COPY: 0000001E ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 10 8E00 26B60000 26B60000 Y N Y N N N Y N N N NO. OF TRACKS: 0000A30B TRACKS TO COPY: 0000A30B ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 10 8E00 31950000 31950000 Y N Y N N N Y N N N NO. OF TRACKS: 00000168 TRACKS TO COPY: 00000168 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 ANTF0001I FCQUERY COMMAND COMPLETED FOR DEVICE 8E00, COMPLETION CODE: 00 READY FCQUERY DEVN('8E10') SHOWRELS(ALL) ANTF0421I FCQUERY Relationship 1 DEVN SSID LSS CCA CU SERIAL ACT MAX XC PC CC RV SE SEQNUM 8E10 8E00 0E 10 2107 0000000AVPD1 7 65534 N P N N NN 00000000 RELATIONSHIP DETAIL STARTING TRACK: 00000000 DEVICE LONG BUSY FOR CG: NO WRITE INHIBITED: NO --------------------------------------------------- PARTNER SOURCE TARGET S F C C P C T S F P LSS CCA SSID START START O V O A R R W E S M --- --- ---- -------- -------- - - - - - - - - - - 0E 00 8E00 00000001 00000001 N N Y N N N Y N N N NO. OF TRACKS: 0000274F TRACKS TO COPY: 0000274F ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 00 8E00 03640000 03640000 N N Y N N N Y N N N NO. OF TRACKS: 00020BC3 TRACKS TO COPY: 00020BC3 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 00 8E00 266E0002 266E0002 N N Y N N N Y N N N NO. OF TRACKS: 00000279 TRACKS TO COPY: 00000279 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 00 8E00 26980006 26980006 N N Y N N N Y N N N NO. OF TRACKS: 0000019B TRACKS TO COPY: 0000019B ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 1 0E 00 8E00 26B3000D 26B3000D N N Y N N N Y N N N NO. OF TRACKS: 0000001E TRACKS TO COPY: 0000001E ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 00 8E00 26B60000 26B60000 N N Y N N N Y N N N NO. OF TRACKS: 0000A30B TRACKS TO COPY: 0000A30B ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 00 8E00 31950000 31950000 N N Y N N N Y N N N NO. OF TRACKS: 00000168 TRACKS TO COPY: 00000168 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 ANTF0001I FCQUERY COMMAND COMPLETED FOR DEVICE 8E10, COMPLETION CODE: 00 READY FCQUERY DEVN('8E01') SHOWRELS(ALL) ANTF0421I FCQUERY Relationship 1 DEVN SSID LSS CCA CU SERIAL ACT MAX XC PC CC RV SE SEQNUM 8E01 8E00 0E 01 2107 0000000AVPD1 15 65534 N P N N NN 00000000 RELATIONSHIP DETAIL STARTING TRACK: 00000000 DEVICE LONG BUSY FOR CG: NO WRITE INHIBITED: NO --------------------------------------------------- PARTNER SOURCE TARGET S F C C P C T S F P LSS CCA SSID START START O V O A R R W E S M --- --- ---- -------- -------- - - - - - - - - - - 0E 11 8E00 00000001 00000001 Y N Y Y N N Y N N N NO. OF TRACKS: 000021DC TRACKS TO COPY: 00001985 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 11 8E00 02C70000 02C70000 Y N Y N N N Y N N N NO. OF TRACKS: 0000004A TRACKS TO COPY: 0000004A ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 11 8E00 02CC0000 02CC0000 Y N Y N N N Y N N N

READY FCQUERY DEVN('7E10') SHOWRELS(ALL) ANTF0421I FCQUERY Relationship 1 DEVN SSID LSS CCA CU SERIAL ACT MAX XC PC CC RV SE SEQNUM 7E10 7E00 0E 10 2107 0000000CCTA1 1 65534 N S N N NN 00000000 RELATIONSHIP DETAIL STARTING TRACK: 00000000 DEVICE LONG BUSY FOR CG: NO WRITE INHIBITED: NO --------------------------------------------------- PARTNER SOURCE TARGET S F C C P C T S F P LSS CCA SSID START START O V O A R R W E S M --- --- ---- -------- -------- - - - - - - - - - - 0E 00 7E00 03640000 03640000 N N Y Y N N Y N N S NO. OF TRACKS: 00020BC3 TRACKS TO COPY: 0000A243 ANTF0001I FCQUERY COMMAND COMPLETED FOR DEVICE 7E10, COMPLETION CODE: 00 READY FCQUERY DEVN('7E01') SHOWRELS(ALL) ANTF0421I FCQUERY Relationship 1 DEVN SSID LSS CCA CU SERIAL ACT MAX XC PC CC RV SE SEQNUM 7E01 7E00 0E 01 2107 0000000CCTA1 1 65534 N S N N NN 00000000 RELATIONSHIP DETAIL STARTING TRACK: 00000000 DEVICE LONG BUSY FOR CG: NO WRITE INHIBITED: NO --------------------------------------------------- PARTNER SOURCE TARGET S F C C P C T S F P LSS CCA SSID START START O V O A R R W E S M --- --- ---- -------- -------- - - - - - - - - - - 0E 11 7E00 033F0000 033F0000 Y N Y Y N N Y N N S NO. OF TRACKS: 000278C7 TRACKS TO COPY: ANTF0001I FCQUERY COMMAND COMPLETED FOR DEVICE 7E01, COMPLETION CODE: 00



© 2012 SAP AG 89

NO. OF TRACKS: 00000292 TRACKS TO COPY: 00000292 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 11 8E00 02F80000 02F80000 Y N Y N N N Y N N N NO. OF TRACKS: 0000011C TRACKS TO COPY: 0000011C ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 11 8E00 030B0000 030B0000 Y N Y N N N Y N N N NO. OF TRACKS: 0000030B TRACKS TO COPY: 0000030B ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 11 8E00 033F0000 033F0000 Y N Y N N N Y N N N NO. OF TRACKS: 000278C7 TRACKS TO COPY: 000278C7 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 11 8E00 2D6E0008 2D6E0008 Y N Y N N N Y N N N NO. OF TRACKS: 0000009C TRACKS TO COPY: 0000009C ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 11 8E00 2D790000 2D790000 Y N Y N N N Y N N N NO. OF TRACKS: 00000ABF TRACKS TO COPY: 00000ABF ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 11 8E00 2E300007 2E300007 Y N Y N N N Y N N N NO. OF TRACKS: 00000006 TRACKS TO COPY: 00000006 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 11 8E00 2E310000 2E310000 Y N Y N N N Y N N N NO. OF TRACKS: 00000E69 TRACKS TO COPY: 00000E69 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 11 8E00 2F270000 2F270000 Y N Y N N N Y N N N NO. OF TRACKS: 00000661 TRACKS TO COPY: 00000661 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 11 8E00 2F940000 2F940000 Y N Y N N N Y N N N NO. OF TRACKS: 000003A1 TRACKS TO COPY: 000003A1 1 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 11 8E00 2FD20000 2FD20000 Y N Y N N N Y N N N NO. OF TRACKS: 00000463 TRACKS TO COPY: 00000463 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 11 8E00 301D0000 301D0000 Y N Y N N N Y N N N NO. OF TRACKS: 00005C01 TRACKS TO COPY: 00005C01 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 11 8E00 36400000 36400000 Y N Y N N N Y N N N NO. OF TRACKS: 00000267 TRACKS TO COPY: 00000267 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 ANTF0001I FCQUERY COMMAND COMPLETED FOR DEVICE 8E01, COMPLETION CODE: 00 READY FCQUERY DEVN('8E11') SHOWRELS(ALL) ANTF0421I FCQUERY Relationship 1 DEVN SSID LSS CCA CU SERIAL ACT MAX XC PC CC RV SE SEQNUM 8E11 8E00 0E 11 2107 0000000AVPD1 15 65534 N P N N NN 00000000 RELATIONSHIP DETAIL STARTING TRACK: 00000000 DEVICE LONG BUSY FOR CG: NO WRITE INHIBITED: NO --------------------------------------------------- PARTNER SOURCE TARGET S F C C P C T S F P LSS CCA SSID START START O V O A R R W E S M --- --- ---- -------- -------- - - - - - - - - - - 0E 01 8E00 00000001 00000001 N N Y Y N N Y N N N NO. OF TRACKS: 000021DC TRACKS TO COPY: 0000196D ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 01 8E00 02C70000 02C70000 N N Y N N N Y N N N NO. OF TRACKS: 0000004A TRACKS TO COPY: 0000004A ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 01 8E00 02CC0000 02CC0000 N N Y N N N Y N N N NO. OF TRACKS: 00000292 TRACKS TO COPY: 00000292 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 01 8E00 02F80000 02F80000 N N Y N N N Y N N N NO. OF TRACKS: 0000011C TRACKS TO COPY: 0000011C ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 01 8E00 030B0000 030B0000 N N Y N N N Y N N N NO. OF TRACKS: 0000030B TRACKS TO COPY: 0000030B ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 01 8E00 033F0000 033F0000 N N Y N N N Y N N N NO. OF TRACKS: 000278C7 TRACKS TO COPY: 000278C7 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 01 8E00 2D6E0008 2D6E0008 N N Y N N N Y N N N NO. OF TRACKS: 0000009C TRACKS TO COPY: 0000009C ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14

READY FCQUERY DEVN('7E11') SHOWRELS(ALL) ANTF0421I FCQUERY Relationship 1 DEVN SSID LSS CCA CU SERIAL ACT MAX XC PC CC RV SE SEQNUM 7E11 7E00 0E 11 2107 0000000CCTA1 1 65534 N S N N NN 00000000 RELATIONSHIP DETAIL STARTING TRACK: 00000000 DEVICE LONG BUSY FOR CG: NO WRITE INHIBITED: NO --------------------------------------------------- PARTNER SOURCE TARGET S F C C P C T S F P LSS CCA SSID START START O V O A R R W E S M --- --- ---- -------- -------- - - - - - - - - - - 1 0E 01 7E00 033F0000 033F0000 N N Y Y N N Y N N S NO. OF TRACKS: 000278C7 TRACKS TO COPY: ANTF0001I FCQUERY COMMAND COMPLETED FOR DEVICE 7E11, COMPLETION CODE: 00



© 2012 SAP AG 90

11:29:06 0E 01 8E00 2D790000 2D790000 N N Y N N N Y N N N NO. OF TRACKS: 00000ABF TRACKS TO COPY: 00000ABF ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 01 8E00 2E300007 2E300007 N N Y N N N Y N N N NO. OF TRACKS: 00000006 TRACKS TO COPY: 00000006 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 01 8E00 2E310000 2E310000 N N Y N N N Y N N N NO. OF TRACKS: 00000E69 TRACKS TO COPY: 00000E69 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 01 8E00 2F270000 2F270000 N N Y N N N Y N N N NO. OF TRACKS: 00000661 TRACKS TO COPY: 00000661 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 01 8E00 2F940000 2F940000 N N Y N N N Y N N N 1 NO. OF TRACKS: 000003A1 TRACKS TO COPY: 000003A1 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 01 8E00 2FD20000 2FD20000 N N Y N N N Y N N N NO. OF TRACKS: 00000463 TRACKS TO COPY: 00000463 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 01 8E00 301D0000 301D0000 N N Y N N N Y N N N NO. OF TRACKS: 00005C01 TRACKS TO COPY: 00005C01 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 01 8E00 36400000 36400000 N N Y N N N Y N N N NO. OF TRACKS: 00000267 TRACKS TO COPY: 00000267 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 ANTF0001I FCQUERY COMMAND COMPLETED FOR DEVICE 8E11, COMPLETION CODE: 00 READY FCQUERY DEVN('8E02') SHOWRELS(ALL) ANTF0421I FCQUERY Relationship 1 DEVN SSID LSS CCA CU SERIAL ACT MAX XC PC CC RV SE SEQNUM 8E02 8E00 0E 02 2107 0000000AVPD1 8 65534 N P N N NN 00000000 RELATIONSHIP DETAIL STARTING TRACK: 00000000 DEVICE LONG BUSY FOR CG: NO WRITE INHIBITED: NO --------------------------------------------------- PARTNER SOURCE TARGET S F C C P C T S F P LSS CCA SSID START START O V O A R R W E S M --- --- ---- -------- -------- - - - - - - - - - - 0E 12 8E00 00000001 00000001 Y N Y Y N N Y N N N NO. OF TRACKS: 000018A8 TRACKS TO COPY: 000000F1 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 12 8E00 02AF000A 02AF000A Y N Y Y N N Y N N N NO. OF TRACKS: 000000A9 TRACKS TO COPY: 00000044 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 12 8E00 02BB0000 02BB0000 Y N Y N N N Y N N N NO. OF TRACKS: 000000EF TRACKS TO COPY: 000000EF ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 12 8E00 02CB0000 02CB0000 Y N Y Y N N Y N N N NO. OF TRACKS: 00000059 TRACKS TO COPY: 00000059 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 12 8E00 02D10000 02D10000 Y N Y N N N Y N N N NO. OF TRACKS: 00000068 TRACKS TO COPY: 00000068 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 12 8E00 02D80000 02D80000 Y N Y N N N Y N N N NO. OF TRACKS: 000006F7 TRACKS TO COPY: 000006F7 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 12 8E00 034F0000 034F0000 Y N Y N N N Y N N N NO. OF TRACKS: 000222D8 TRACKS TO COPY: 000222D8 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 12 8E00 296B0000 296B0000 Y N Y N N N Y N N N NO. OF TRACKS: 000075E4 TRACKS TO COPY: 000075E4 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 ANTF0001I FCQUERY COMMAND COMPLETED FOR DEVICE 8E02, COMPLETION CODE: 00 READY FCQUERY DEVN('8E12') SHOWRELS(ALL) ANTF0421I FCQUERY Relationship 1 DEVN SSID LSS CCA CU SERIAL ACT MAX XC PC CC RV SE SEQNUM 8E12 8E00 0E 12 2107 0000000AVPD1 8 65534 N P N N NN 00000000 RELATIONSHIP DETAIL STARTING TRACK: 00000000 DEVICE LONG BUSY FOR CG: NO WRITE INHIBITED: NO

READY FCQUERY DEVN('7E02') SHOWRELS(ALL) ANTF0421I FCQUERY Relationship 1 DEVN SSID LSS CCA CU SERIAL ACT MAX XC PC CC RV SE SEQNUM 7E02 7E00 0E 02 2107 0000000CCTA1 1 65534 N S N N NN 00000000 RELATIONSHIP DETAIL STARTING TRACK: 00000000 DEVICE LONG BUSY FOR CG: NO WRITE INHIBITED: NO --------------------------------------------------- PARTNER SOURCE TARGET S F C C P C T S F P LSS CCA SSID START START O V O A R R W E S M --- --- ---- -------- -------- - - - - - - - - - - 0E 12 7E00 034F0000 034F0000 Y N Y N N N Y N N S NO. OF TRACKS: 000222D8 TRACKS TO COPY: ANTF0001I FCQUERY COMMAND COMPLETED FOR DEVICE 7E02, COMPLETION CODE: 00 READY FCQUERY DEVN('7E12') SHOWRELS(ALL) ANTF0421I FCQUERY Relationship 1 DEVN SSID LSS CCA CU SERIAL ACT MAX XC PC CC RV SE SEQNUM 7E12 7E00 0E 12 2107 0000000CCTA1 1 65534 N S N N NN 00000000 RELATIONSHIP DETAIL STARTING TRACK: 00000000 DEVICE LONG BUSY FOR CG: NO WRITE INHIBITED: NO



© 2012 SAP AG 91

--------------------------------------------------- 1 PARTNER SOURCE TARGET S F C C P C T S F P LSS CCA SSID START START O V O A R R W E S M --- --- ---- -------- -------- - - - - - - - - - - 0E 02 8E00 00000001 00000001 N N Y Y N N Y N N N NO. OF TRACKS: 000018A8 TRACKS TO COPY: 000000C1 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 02 8E00 02AF000A 02AF000A N N Y Y N N Y N N N NO. OF TRACKS: 000000A9 TRACKS TO COPY: 00000014 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 02 8E00 02BB0000 02BB0000 N N Y N N N Y N N N NO. OF TRACKS: 000000EF TRACKS TO COPY: 000000EF ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 02 8E00 02CB0000 02CB0000 N N Y Y N N Y N N N NO. OF TRACKS: 00000059 TRACKS TO COPY: 00000059 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 02 8E00 02D10000 02D10000 N N Y N N N Y N N N NO. OF TRACKS: 00000068 TRACKS TO COPY: 00000068 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 02 8E00 02D80000 02D80000 N N Y N N N Y N N N NO. OF TRACKS: 000006F7 TRACKS TO COPY: 000006F7 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 02 8E00 034F0000 034F0000 N N Y N N N Y N N N NO. OF TRACKS: 000222D8 TRACKS TO COPY: 000222D8 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 0E 02 8E00 296B0000 296B0000 N N Y N N N Y N N N NO. OF TRACKS: 000075E4 TRACKS TO COPY: 000075E4 ESTABL: 2011/11/14 11:29:06 LAST INCR: 2011/11/14 11:29:06 ANTF0001I FCQUERY COMMAND COMPLETED FOR DEVICE 8E12, COMPLETION CODE: 00 READY FCQUERY DEVN('8E20') SHOWRELS(ALL) ANTF0421I FCQUERY Relationship 1 DEVN SSID LSS CCA CU SERIAL ACT MAX XC PC CC RV SE SEQNUM 8E20 8E00 0E 20 2107 0000000AVPD1 0 65534 N P N N NN 00000000 RELATIONSHIP DETAIL STARTING TRACK: 00000000 DEVICE LONG BUSY FOR CG: NO WRITE INHIBITED: NO --------------------------------------------------- NO RELATIONSHIPS FOUND FOR SPECIFIED DEVICE OR STARTING ADDRESS ANTF0001I FCQUERY COMMAND COMPLETED FOR DEVICE 8E20, COMPLETION CODE: 00 READY FCQUERY DEVN('8E21') SHOWRELS(ALL) ANTF0421I FCQUERY Relationship 1 DEVN SSID LSS CCA CU SERIAL ACT MAX XC PC CC RV SE SEQNUM 8E21 8E00 0E 21 2107 0000000AVPD1 0 65534 N P N N NN 00000000 RELATIONSHIP DETAIL STARTING TRACK: 00000000 DEVICE LONG BUSY FOR CG: NO WRITE INHIBITED: NO --------------------------------------------------- NO RELATIONSHIPS FOUND FOR SPECIFIED DEVICE OR STARTING ADDRESS ANTF0001I FCQUERY COMMAND COMPLETED FOR DEVICE 8E21, COMPLETION CODE: 00 READY END

--------------------------------------------------- PARTNER SOURCE TARGET S F C C P C T S F P LSS CCA SSID START START O V O A R R W E S M --- --- ---- -------- -------- - - - - - - - - - - 0E 02 7E00 034F0000 034F0000 N N Y N N N Y N N S NO. OF TRACKS: 000222D8 TRACKS TO COPY: ANTF0001I FCQUERY COMMAND COMPLETED FOR DEVICE 7E12, COMPLETION CODE: 00 READY FCQUERY DEVN('7E20') SHOWRELS(ALL) ANTF0421I FCQUERY Relationship 1 DEVN SSID LSS CCA CU SERIAL ACT MAX XC PC CC RV SE SEQNUM 7E20 7E00 0E 20 2107 0000000CCTA1 1 65534 N S N N NN 00000000 RELATIONSHIP DETAIL STARTING TRACK: 00000000 DEVICE LONG BUSY FOR CG: NO WRITE INHIBITED: NO --------------------------------------------------- PARTNER SOURCE TARGET S F C C P C T S F P LSS CCA SSID START START O V O A R R W E S M --- --- ---- -------- -------- - - - - - - - - - - 0E 21 7E00 00A20000 00A20000 Y N Y Y N N Y N N S NO. OF TRACKS: 0001DDFA TRACKS TO COPY: ANTF0001I FCQUERY COMMAND COMPLETED FOR DEVICE 7E20, COMPLETION CODE: 00 READY FCQUERY DEVN('7E21') SHOWRELS(ALL) ANTF0421I FCQUERY Relationship 1 DEVN SSID LSS CCA CU SERIAL ACT MAX XC PC CC RV SE SEQNUM 7E21 7E00 0E 21 2107 0000000CCTA1 1 65534 N S N N NN 00000000 RELATIONSHIP DETAIL STARTING TRACK: 00000000 DEVICE LONG BUSY FOR CG: NO WRITE INHIBITED: NO 1--------------------------------------------------- PARTNER SOURCE TARGET S F C C P C T S F P LSS CCA SSID START START O V O A R R W E S M --- --- ---- -------- -------- - - - - - - - - - - 0E 20 7E00 00A20000 00A20000 N N Y Y N N Y N N S NO. OF TRACKS: 0001DDFA TRACKS TO COPY: 000059E0 ANTF0001I FCQUERY COMMAND COMPLETED FOR DEVICE 7E21, COMPLETION CODE: 00 END

Table 1. FC query the background copy progress primary and secondary disk

This verified the successful completion of the background copy process on the secondary site within the PPRC and the mirrored backup environment.

In real-life customer implementations with GDPS or TPC-R system automation solutions for disaster recovery processing, detailed testing of the failover scenarios is highly recommended.



© 2012 SAP AG 92

Ensuring Volumes always Remain in Full Duplex Mode with BACKUP SYSTEM and PPRC

When using GDPS as disaster recovery solution for your data centers, it is often important to ensure that the disk volumes are permanently mirrored and that HyperSwap can kick in basically at any time when needed.

This ensures that the secondary site can take over in case of a disaster. As described in section Copy Pools used by DB2’s BACKUP SYSTEM Utility on page 44, there are settings in the HSM copy pool and within DB2 that allow you to control whether RPFC is used to prevent volumes going into duplex-pending mode.

If you would like to have a safety net that ensures FlashCopy is always invoked with RPFC and never without it, you can create a user exit for ADRDSSU. To accomplish this, you need to enable the ADRUIXIT exit. In our case, we used the following job:

//*MODLOG USERMOD LDFP003 ADRUIXIT SET FORCE PRESMIRREQ

//*

//SMPREAP EXEC PGM=GIMSMP

//*

//SMPOUT DD SYSOUT=*

//SMPRPT DD SYSOUT=*

//SMPCSI DD DSN=SYS4.S13CRES.CSI,DISP=OLD

//SMPPTFIN DD *

++USERMOD(LDFP003).

++VER (Z038) FMID(HDZ1B10).

++VER (Z038) FMID(HDZ1C10).

++VER (Z038) FMID(HDZ1D10).

++SRC (ADRUIXIT) DISTLIB(ASAMPLIB).

*

* MODULE NAME = ADRUIXIT

* FORCE PRESMIRREQ:

* SPECIFIES THAT IF THE TARGET

* VOLUME IS A METRO MIRROR PRIMARY DEVICE, THE

* PAIR MUST NOT GO INTO A DUPLEX PENDING STATE

* AS THE RESULT OF A FLASHCOPY OPERATIONS.

*********************************************************************

ADRUIXIT CSECT

ADRUIXIT AMODE 31

ADRUIXIT RMODE 24

STM 14,12,12(13) SAVE REGISTERS

USING ADRUIXIT,15 ADDRESSABILITY TO ADRUIXIT

USING ADRUFOB,1 ADDRESSABILITY TO ADRUFO

SR 2,2 ZERO REGISTER 2

CH 2,UFFUNCT CHECK ENTRY TYPE

BNE FUNCENT BRANCH TO FUNCTION ENTRY

SR 3,3 PARM CHANGE ENTRY, SAVE RC 0

B FINISH FINISHED

FUNCENT LH 2,UFBDYOFF GET OFFSET TO UFOFUNCT

AR 2,1 CALCULATE ADDRESS OF UFOFUNCT

USING UFOFUNCT,2 ADDRESSABILITY TO UFOFUNCT

NI UFO8FLGS,X'FF'-(UFOPMPRE+UFOPMNON+UFPMREQ)

OI UFO8FLGS,UFOPMREQ PRESERVE MIRROR PRESMIRREQ

LA 3,4 SAVE RETURN CODE 4

DROP 1 DONE USING 1 FOR ADRUFO

DROP 2 DONE USING 2 FOR UFOFUNCT

DROP 15 DONE USING 15 FOR ADRUIXIT

FINISH LR 15,3 SET RETURN CODE

L 14,12(,13) RESTORE REGISTER 14

LM 0,12,20(13) RESTORE REGISTERS 0 THRU 12



© 2012 SAP AG 93

BR 14 RETURN

ADRUFO INCLUDE ADRUFO CONTROL BLOCK

END

//SMPCNTL DD *

SET BDY(GLOBAL).

REJECT

S(LDFP003)

BYPASS(APPLYCHECK,ACCEPTCHECK)

.

RESETRC.

SET BDY(GLOBAL).

RECEIVE

S(LDFP003)

.

SET BDY(T13CRES).

APPLY

S(LDFP003)

REDO

.

In ADRUIXIT, you need to set the following parameters:

UFOPMPRE = OFF;

UFOPMNON = OFF;

UFOPMREQ = ON;

In the HSM log, you can then see the following messages that indicate that the user exit converted a FlashCopy call from PMNO to PMR:

ARC0640I ARCFRTM - ADR050I (002)-PRIME(02), DFSMSDSS INVOKED VIA CROSS MEMORY

APPLICATION INTERFACE

ARC0640I ARCFRTM - ADR035I (002)-PRIME(1A), INSTALLATION EXIT ALTERED

FCTOPPRCPRIMARY(PRESMIRREQ) OPTION

ARC0640I ARCFRTM - ADR035I (002)-PRIME(1C), INSTALLATION EXIT ALTERED

FCTOPPRCPRIMARY(PRESMIRNONE) OPTION

DB2 system-level recovery when a table was reorganized between SLB and recovery target point

In this scenario, the complete SAP/DB2 system is supposed to be recovered to a prior point in time or to current. One or more tables were reorganized though between the point in time when the BACKUP SYSTEM utility was called and the recovery target point in time. Therefore, these tables are not recovered automatically as part of the RESTORE SYSTEM processing. The following scenario shows you how you can restore your complete system to the desired point in time.

In this scenario, a system-level backup is taken at 11:28am:


DSNU050I 356 11:28:48.69 DSNUGUTC - BACKUP SYSTEM FULL



TOKEN = X'C4C2F2F1C8DBC0CCE1F82304000FC98B1832'.



TOKEN = X'C4C2F2F1C8DBC0CCE1F82304000FC98B1832'

DATA COMPLETE LRSN = X'000FC98F4A30'




© 2012 SAP AG 94

DSNU1600I 356 11:29:20.29 DSNUVBBD - BACKUP SYSTEM UTILITY FOR LOGS STARTING,



DSNU1614I 356 11:29:21.46 DSNUVBBD - BACKUP SYSTEM UTILITY FOR LOGS COMPLETED SUCCESSFULLY,



DATA COMPLETE LRSN = X'000FC98F4A30'




As a next step, the SAP table SNAP is reorganized at 11:31. As part of the execution of the online REORG utility, an inline image copy is taken:

Screenshot 23. Display Details of Action

Later, a decision is taken to restore the entire SAP/DB2 system to current. The last valid system-level backup is the one that was taken at 11:28. Therefore, as a next step, a conditional restore control record is defined using the DB2 DSNJU003 utility. This JCL job is as follows:




//*

//CRCR01B EXEC PGM=DSNJU003,REGION=016M,COND=(4,LT)

//STEPLIB DD DISP=SHR,DSN=DB21L.V100.SDSNEXIT

// DD DISP=SHR,DSN=DB21L.V100.SDSNLOAD


//SYSUT1 DD DISP=SHR,DSN=DB21L.BSDS01


//SYSIN DD *

CRESTART CREATE,SYSPITR=FFFFFFFFFFFF

/*



© 2012 SAP AG 95

This job completes successfully. Its job output is as follows:

CRESTART CREATE,SYSPITR=FFFFFFFFFFFF 00120007

DSNJCNVB CONVERSION PROGRAM HAS RUN DDNAME=SYSUT1

DSNJCNVB CONVERSION PROGRAM HAS RUN DDNAME=SYSUT2

CRESTART CREATE,SYSPITR=FFFFFFFFFFFF 00120007

DSNJ408I DSNRJFCK CHECKPOINT RBA FOUND, RBA = 000FCA4E8000, TIME = 10:46:43 DECEMBER 22, 2011

DSNJ411I DSNRJRCR CRESTART CREATE FOR CRCRID = 0D0C, DDNAME = SYSUT1

DSNJ408I DSNRJFCK CHECKPOINT RBA FOUND, RBA = 000FCA4E8000, TIME = 10:46:43 DECEMBER 22, 2011

DSNJ411I DSNRJRCR CRESTART CREATE FOR CRCRID = 0D0C, DDNAME = SYSUT2

DSNJ225I CRESTART OPERATION COMPLETED SUCCESSFULLY

DSNJ200I DSNJU003 CHANGE LOG INVENTORY UTILITY PROCESSING COMPLETED SUCCESSFULLY

Note that the timestamp indicating 10:46am is in UTC which corresponds to 11:46 local time. After restarting DB2 in maintenance mode, the RESTORE SYSTEM utility is invoked as follows:

//SCHUETZR JOB USER=SCHUETZ,CLASS=A,MSGCLASS=X,



//RESTORE EXEC DSNUPROC,SYSTEM=DB21,

// UID='GAUL',LIB=DB21L.V100.SDSNLOAD

//DSNUPROC.SYSIN DD *

RESTORE SYSTEM

/*

The output of this job is as follows:

RESTORE SYSTEM 00130004

DSNU000I 356 11:52:00.01 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = MARY


DSNU050I 356 11:52:00.05 DSNUGUTC - RESTORE SYSTEM

DSNU1606I 356 11:52:00.05 DSNUVBRD - RESTORE SYSTEM UTILITY STARTING,



DSNU1627I 356 11:52:03.13 DSNUVBRD - RESTORE SYSTEM PRE-LOG APPLY COMPLETED SUCCESSFULLY,




DSNU1604I -DB21 356 11:52:03.43 DSNUVARL - RESTORE SYSTEM PHASE LOG APPLY STARTED AT LOG POINT

= X'000FC98B1832'.

DSNU1629I -DB21 356 11:53:12.75 DSNUVARL - DB2 PUT ONE OR MORE OBJECTS INTO THE RECOVER-PENDING

STATE, THEREBUILD-PENDING STATE,

OR THE LOGICAL PAGE LIST DURING THE LOG APPLY PHASE.

DSNU1635I -DB21 356 11:53:12.75 DSNUVARL - THE RBA RANGE FOR THE LAST CHECKPOINT ISSUED DURING

THE LOGAPPLY PHASE OF

THE RESTORE SYSTEM UTILITY IS START_RBA = X'000FCA5136D2' END_RBA = X'000FCA81202A'

DSNU1628I 356 11:53:12.75 DSNUVBRD - RESTORE SYSTEM PHASE LOG APPLY COMPLETED, ELAPSED TIME =

00:01:09.


Note that the job completes with return code 4, and message DSNU1629I indicating that RESTORE SYSTEM left objects in recover-pending or rebuild-pending state.



© 2012 SAP AG 96

By submitting the following DB2 command, you can identify the objects in these states. This implies that at the time of the BACKUP SYSTEM no other object was in recover-pending state, which is normally the case.

12:02:36.73 SCHUETZ 00000290 -DB21 DISPLAY DB(*) SPACENAM(*) RESTRICT(RECP)

12:02:36.73 STC07285 00000080 DSNT360I -DB21 ***********************************

12:02:36.73 STC07285 00000080 DSNT361I -DB21 * DISPLAY DATABASE SUMMARY 370

370 00000080 * RESTRICTED

12:02:36.73 STC07285 00000080 DSNT360I -DB21 ***********************************

12:02:36.73 STC07285 00000080 DSNT362I -DB21 DATABASE = DSN07230 STATUS = RW

372

372 00000080 DBD LENGTH = 4028

12:02:36.73 STC07285 00000080 DSNT397I -DB21 373

373 00000080 NAME TYPE PART STATUS PHYERRLO

PHYERRHI CATALOG PIECE

373 00000080 -------- ---- ----- ----------------- -------- -------

- -----

373 00000080 SNAP TS 0001 RW,RECP

373 00000080 SNAP TS RW,RECP

373 00000080 ******* DISPLAY OF DATABASE DSN07230

ENDED ************

To recover the SNAP tablespace, you can go to the SAP DBA Cockpit to recover this object:

Screenshot 24. DBA Planning Calendar



© 2012 SAP AG 97

Here is the detail panel for the scheduling of the recover job:

Screenshot 25. Display Details of Action

Using the DB2 catalog browser from SAP DBA Cockpit or some equivalent mechanism, you can see that two indexes have been defined for table SNAP:

Screenshot 26. SAP DBA Cockpit - DB2 catalog browser



© 2012 SAP AG 98

These indexes are exactly the ones that are in rebuild-pending status and still need to be rebuilt:

12:02:36.73 STC07285 00000080 DSN9022I -DB21 DSNTDDIS 'DISPLAY DATABASE' NORMAL COMPLETION

12:04:04.81 SCHUETZ 00000290 -DB21 DISPLAY DB(*) SPACENAM(*) RESTRICT(RBDP)

12:04:04.81 STC07285 00000080 DSNT360I -DB21 ***********************************

12:04:04.81 STC07285 00000080 DSNT361I -DB21 * DISPLAY DATABASE SUMMARY 377

377 00000080 * RESTRICTED

12:04:04.81 STC07285 00000080 DSNT360I -DB21 ***********************************

12:04:04.81 STC07285 00000080 DSNT362I -DB21 DATABASE = DSN07230 STATUS = RW 379

379 00000080 DBD LENGTH = 4028

12:04:04.81 STC07285 00000080 DSNT397I -DB21 380

380 00000080 NAME TYPE PART STATUS PHYERRLO PHYERRHI CATALOG PIECE

380 00000080 -------- ---- ----- ----------------- -------- -------- -----

380 00000080 SNAPH0 IX L0001 RW,RBDP,PSRBD

380 00000080 SNAPH0 IX L* RW,RBDP,PSRBD

380 00000080 SNAPHDSX IX L0001 RW,RBDP,PSRBD

380 00000080 SNAPHDSX IX L* RW,RBDP,PSRBD

380 00000080 ******* DISPLAY OF DATABASE DSN07230 ENDED *************

12:04:04.81 STC07285 00000080 DSNT360I -DB21 ***********************************

12:04:04.81 STC07285 00000080 DSNT362I -DB21 DATABASE = SAPR3 STATUS = RW 382

382 00000080 DBD LENGTH = 36332

12:04:04.82 STC07285 00000080 DSNT397I -DB21 383

383 00000080 NAME TYPE PART STATUS PHYERRLO PHYERRHI CATALOG PIECE

383 00000080 -------- ---- ----- ----------------- -------- -------- ------

383 00000080 QX000102 IX RW,RBDP

383 00000080 ******* DISPLAY OF DATABASE SAPR3 ENDED *************

12:04:04.82 STC07285 00000080 DSN9022I -DB21 DSNTDDIS 'DISPLAY DATABASE' NORMAL COMPLETION

These indexes can be rebuilt using the Planning Calendar from SAP DBA Cockpit:



© 2012 SAP AG 99

Screenshot 27. SAP DBA Cockpit: DBA Planning Calendar

The following output of the REBUILD INDEX utility is displayed in the DBA Cockpit:

Screenshot 28. SAP DBA Cockpit: REBUILD INDEX output

Use DB2 Recovery Expert for Recoverability Health Checks

You can use DB2 Recovery Expert to create a recoverability health check report through the ISPF interface. With the health check report, you can determine the objects that may be unrecoverable after a system restore is performed. So you can check this before you actually run the system restore.

Health check will find objects on which a LOG NO utility was performed after the RBA/LRSN of the system-level backup and before the RBA/LRSN you want the DB2 subsystem to restore to. Because the log cannot be applied across the LOG NO utility point, an image copy or a system-level backup (SLB) will be necessary to recover those objects.

The report contains two sections. The first section shows any tablespaces that had a utility with LOG NO performed on them, but that are recoverable to the selected recovery point. The second section lists the tablespaces that DB2 will be unable to recover using an SLB due to an execution of a LOG NO utility, and lists the event that caused them to be unrecoverable. For health check reports generated in batch, the associated image copy data sets can optionally be validated to determine if they still exist and can be opened. For a multi-volume data set on tape, only the first volume is validated. Indexes defined as COPY YES will appear in the health check Recoverable Objects report if an image copy of the index is found. If an image copy is not found, or is invalidated by a REBUILD INDEX utility, the index will not appear in the Unrecoverable Objects report because it can be rebuilt.

Go to the “System Restore and Offload” panel by choosing option 2 from the main menu.

On the “Restore System Display” panel tab down to the system-level backup and use the line command H for Health Check.



© 2012 SAP AG 100

Screenshot 29. Restore System Display

After you enter the H command, the “Health Check Options” pop up should appear. If you would like to validate that each image copy data set still exists, choose the health check in batch.



© 2012 SAP AG 101

Screenshot 30. Restore System Display - Health Check Options

The following health check report shows that we have no objects in recover pending status.

Screenshot 31. Health Check Report.

In case that you restore data only, you are able to choose an additional step generated after the Log Apply step that will generate a separate job that can be executed after the System Restore to

1. Identify all objects in Recover Pending or Rebuild Pending status and

2. Create JCL jobs to perform either a RECOVER or REBUILD utility for those objects



© 2012 SAP AG 102

Screenshot 32. Restore System Display - Options Data Only / Data and Logs

After selecting the “Restore Only Data “ and “Resolve Recover/Rebuild Pending Objects” options, the following jobs will be generated by DB2 Recovery Expert:

Conditional restart:

This job contains the JCL for the DSNJU003 change log inventory utility. The SYSPITR keyword is included to specify the restoration point.

Restore system:

This job invokes the DB2 RESTORE SYSTEM utility to restore the subsystem volumes to the recovery point.

Log restore:

This job restores the logs to the specified RBA/LRSN via the RESTORE SYSTEM utility.

Recover/Rebuild Pending:

If the Resolve Recover/Rebuild Pending Objects was selected, this member name will be used to build Recover/Rebuild pending job.



© 2012 SAP AG 103

Screenshot 33. Restore System Display - Build Restore Job

Use DB2 Recovery Expert to Create Image Copies from System-Level Backups

With IBM DB2 Recovery Expert, you are able to create DB2 image copies based on DB2 Recovery Expert object profiles or from DB2 system-level backups.

Using DB2 Recovery Expert to create image copies from system-level backups

You can make DB2 image copies from DB2 system-level backups if object restore is enabled. You enable the object restore function in the Backup Profile ISPF panel setting Enable Object Restore to “Y”. See panel below.

The image copies will be registered in the DB2 system catalog table SYSIBM.SYSCOPY, therefore allowing the image copies to be used by any DB2 utility that can process DB2 image copies.

You can make image copies of tablespaces and indexes defined with COPY YES that were included in the backup.

Mostly a backup offloaded to tape can also be used. However, if FDR is used to offload the backup, that offloaded backup cannot be used to make image copies.

All image copies will be for a single partition. If a non-partitioned object has grown to multiple data sets, all data sets will be included in the image copy. The image copies are registered as SHRLEVEL CHANGE copies. The start RBA will be recorded as the RBLP (from DSNJU004 output) RBA/LRSN value associated with a system backup.

DB2 maintains this RBA in the header page of DSNDB01; every log record lower than this RBA or LRSN has been applied and externalized to disk. The PIT_RBA will be set to the backup RBA associated with the system-level backup. No log records higher than this value are applied to the tablespaces and indexes in the system backup.



© 2012 SAP AG 104

Screenshot 34. View Backup Profile

On the “Restore System Display” panel you specify an “I” line command at the system-level backup that will be the source for your new DB2 Image Copy.

Screenshot 35. Restore System Display



© 2012 SAP AG 105

Then you can select the object profile that is related to the object for which you want create the copy. Type an “S” line command for that object profile.

Screenshot 36. Object Profile Selection

On the next panel, you can define Job header, Job name etc.. Enter Y to update the image copy options to be used when creating image copies from a system-level backup.



© 2012 SAP AG 106

Screenshot 37. Object Profile Selection – Build Image Copy Job

The image copy options screen allows you to define parameters for the creation of image copies from a system-level backup such as data set information, storage location, and tape options. If using SMS, which is required with DB2 10, take care of specifying the following parameters on the panel:

Data Class

Storage Class

Management Class

Work Volumes

Work Storage Class

You should double check the specifications with your storage administrator. Some potential pitfalls are for example:

The size of the selected storage class is too small

Not all volumes specified are enabled

The work volume is on a non-SMS volume, etc.,

You would then get the error messages ADR380E, ADR455W and ARYS408I in the generated image copy job.

Screenshot 38. Image Copy Options

In the job log of the generated job, you see the RBA/LRSN information of the image copy and that it was registered in SYSIBM.SYSCOPY. An important point to remember is that the image copy date and time, as recorded in SYSIBM.SYSCOPY, will always be the date and time of the corresponding system-level backup.



© 2012 SAP AG 107

Screenshot 39. Image Copy - Joblog

Using fast replication methods to back up objects

You can create an object profile that can be used to drive EMC Snap data set or IBM Data set FlashCopy to create backups for individual or groups of tablespaces and indexes using fast replication. There are two types of object level backups that can use fast replication:

Traditional image copies that will be registered in SYSIBM.SYSCOPY and usable by any recovery tool or other process that uses image copies. These image copies can be placed on TAPE or DASD and will be the same physical file format as all traditional image copies (i.e. flat files). These image copies are created by DB2 Recovery Expert issuing fast replication to copy the DB2 tablespace or index data set, then reading the VSAM copy to create a traditional image copy.

VSAM type copies that will be registered in the DB2 Recovery Expert internal repository. These backups will be usable for recovery purposes only when DB2 Recovery Expert is generating recovery JCL. These copies will be in VSAM format and can only reside on DASD. When DB2 Recovery Expert is directed to generate recovery JCL, it will use these VSAM type backups for recovery purposes to generate a fast replication restore of the data set followed by a log apply step to bring the object to the desired recovery point. This type of recovery will be faster than recovery from a traditional image copy because it will use fast replication to restore the data set. The log apply phase will take place in parallel with the data set restore, also reducing recovery time.

For both types of fast replication copies, users can specify either share level change or share level reference copies to be created. For SAP workloads, share level change copies are typically used. For share level reference copies, DB2 Recovery Expert will place the objects in read only mode, run a QUIESCE utility to flush all the changes for these objects to disk, perform the fast replication to copy the data sets of the selected objects, and then place the objects back in read write mode. If the user requested traditional copies be made, the VSAM fast replication copy of the data sets will be read and traditional format image copies will be written and logged in the SYSCOPY table. This will significantly reduce the amount of time the object is unavailable for updates for a share level reference copy because it is only unavailable for the amount of time it takes to copy the object data set(s) using fast replication. For share level change copies, the object data set(s) are just copied using fast replication, nothing is done to prevent DB2 from updating the object data



© 2012 SAP AG 108

sets during the copy. A recovery using this type of copy usually requires applying log records to bring the object(s) to a point of consistency.

To create a DB2 image copy based on an object profile, enter “I” as line command in front of the related object profile.

Screenshot 40. Creating a DB2 image copy

Select Image Copy (IC) Options “Y” to open the image copy options panel.



© 2012 SAP AG 109

Screenshot 41. Select that you want to edit Image Copy (IC) Options

On the following Image copy options panel we request a sharelevel reference VSAM Image Copy. This means that DB2 Recovery Expert will place the related objects of the object profile in read only mode. Then the it runs a QUIESCE utility to flush all the changes for these objects to disk.

With the Register VSAM copy “Y” option we specify that the VSAM copy will be registered in the DB2 Recovery Expert Image Copy table.



© 2012 SAP AG 110

Screenshot 42. Image Copy Options

In the job log of the DB2 Recovery Expert Image Copy job you can see that the tablespace was quiesced and an entry in the VSAM_SYSCOPY table was made.

Screenshot 43. Joblog of the DB2 Recovery Expert Image Copy job



© 2012 SAP AG 111

On the screen below you see the newly registered image copy in the DB2 Recovery Expert VSAM_SYSCOPY table.

Screenshot 44. Image Copy in the DB2 Recovery Expert table VSAM_SYSCOPY

DB2 10 Backward Recovery while Incremental FlashCopy Relationships Exist

DB2 10 introduced a new single object recovery feature that enables the backout of committed work from the current state of the object. In some circumstances, recovering to a point in time by backing out work can be faster than recovering to a point in time by restoring a copy of the data and applying the logs forward. When the RECOVER utility performs a point-in-time recovery by backing out committed work, the recovery is a point-in-time recovery with consistency, because any work that was uncommitted at the point in time to which the data is being recovered is also backed out. When the recovery is complete, the data is left in a transaction consistent state. The RECOVER utility cannot perform a backout recovery to a point in time that is earlier than the timestamp of the latest SQL ALTER record in SYSIBM.SYSCOPY for the object being recovered. This situation is reported by DB2 message DSNU556I. You also cannot perform a backout recovery to a point-in-time that is earlier than the completion time of a previous backout recovery. Before running the RECOVERY utility with the BACKOUT YES option, run the REPORT utility with the RECOVER option on the object being recovered to identify events that might prevent you from recovering the object by backout to a given point in time.

In this test the DSN$DDFDB22$DB and DSN$DDFDB22$LG copy pools were in persistent FC relationships with their backup copy pools. This can be seen from the output of the HSM FCQUERY command:

ARC1820I THE FOLLOWING VOLUMES IN COPY POOL DSN$DDFDB22$LG, VERSION 006, HAVE ARC1820I (CONT.) AN ACTIVE FLASHCOPY BACKGROUND COPY ARC1820I (CONT.) SGNAME FR-PRIMARY FR-BACKUP PCT-COMP ARC1820I (CONT.) DB2DIL SAPDIL SAPFIL 011



© 2012 SAP AG 112

ARC1820I THE FOLLOWING VOLUMES IN COPY POOL DSN$DDFDB22$DB, VERSION 003, HAVE ARC1820I (CONT.) AN ACTIVE FLASHCOPY BACKGROUND COPY ARC1820I (CONT.) SGNAME FR-PRIMARY FR-BACKUP PCT-COMP ARC1820I (CONT.) DB2DI SAPDI1 SAPFI1 002 ARC1820I (CONT.) DB2DI SAPDI2 SAPFI2 002 ARC1820I (CONT.) DB2DI SAPDI3 SAPFI3 001 ***

To test the new Recover Backout function, a number of new SAP users were added to the SAP DB2 system. 1. A system checkpoint was initiated using the DB2 command that follows.

-DB22 SET LOG LOGLOAD(0) 2. New users added via SAP transactions 3. A system checkpoint was initiated using the DB2 command that follows.

-DB22 SET LOG LOGLOAD(0) 4. BSDS print was obtained using DSNJU004 utility. The information for the DB2 system checkpoints

was found on the Checkpoint Queue in the BSDS print map.

TIME OF CHECKPOINT 14:44:42 NOVEMBER 09, 2011 Second initiated DB2 system checkpoint BEGIN CHECKPOINT RBA 000C6A98C616 END CHECKPOINT RBA 000C6A99C000 END CHECKPOINT STCK C8A5E9CC1F54 TIME OF CHECKPOINT 14:44:14 NOVEMBER 09, 2011 First initiated DB2 system checkpoint BEGIN CHECKPOINT RBA 000C6A976E27 ‘PRIOR CHECKPOINT RBA’ in Recover job output END CHECKPOINT RBA 000C6A98778E TOLOGPOINT used in recovery jobs END CHECKPOINT STCK C8A5E9B1BC47

5. Performed RECOVER BACKOUT for DSN09198.USR01 and DSN09202.USR02 back to END CHECKPOINT RBA 000C6A98778E. Below are messages from the DSN09198.USR01 recovery job.

As can be seen in the messages the BACKOUT function is being used. The output includes information on how many committed units-of-recovery were backed out. It provides information on the LOG undos that were accomplished during the backout. The job completes with a return code= 4 because the indexes are in rebuild-pending status.

DSNUGUTC - RECOVER TABLESPACE DSN09198.USR01 TOLOGPOINT X'000C6A98778E' BACKOUT DSNUCAIN - RECOVER BACKOUT ANALYSIS PROCEEDING FROM CURRENT LOGPOINT OF X'000C6B52597C' DSNUCALA - RECOVER TABLESPACE DSN09198.USR01 START DSNUCARS - INDEX SAPR3.USR01ß0 IS IN REBUILD PENDING DSNUCARS - INDEX SAPR3.USR01ß001 IS IN REBUILD PENDING DSNUCARS - INDEX SAPR3.USR01ß002 IS IN REBUILD PENDING DSNUCARS - INDEX SAPR3.USR01ß003 IS IN REBUILD PENDING DSNUCARS - ALL INDEXES OF DSN09198.USR01 ARE IN REBUILD PENDING DSNUCALC - LOGCSR IS STARTED FOR MEMBER , PRIOR CHECKPOINT RBA = X'000C6A976E27' DSNUCALC - LOGCSR IS FINISHED FOR MEMBER , ELAPSED TIME = 00:00:00 DSNUCALC - LOGCSR PHASE COMPLETE, ELAPSED TIME = 00:00:00 DSNUCALC - RECOVER UTILITY DETECTS THE FOLLOWING ACTIVE URS: INFLIGHT = 0, INABORT = 0, INDOUBT = 0, POSTPONED ABORT = 0 COMMITTED = 11, ABORTED = 0 . . . DSNUCALU - LOGUNDO IS STARTED FOR MEMBER DSNUCACL - RECOVER LOGUNDO STATUS: LOG RECORD AT RBA X'000C6B0A38CC' TO RBA X'000C6AA72BF9' ON MEMBER DSNUCACL - RECOVER LOGUNDO STATUS: LOG RECORD AT RBA X'000C6AEFF12A' TO RBA X'000C6AA72BF9' ON MEMBER DSNUCACL - RECOVER LOGUNDO STATUS: LOG RECORD AT RBA X'000C6AC98284' TO RBA X'000C6AA72BF9' ON MEMBER DSNUCALU - LOGUNDO IS FINISHED FOR MEMBER , ELAPSED TIME = 00:00:00 DSNUCALU - LOGUNDO PHASE COMPLETE, ELAPSED TIME = 00:00:00 CBDR - RECOVERY COMPLETE, ELAPSED TIME=00:00:00 GBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=4

6. A display for restricted objects provided the following:



© 2012 SAP AG 113

DSNT360I -DB22 ***********************************

DSNT361I -DB22 * DISPLAY DATABASE SUMMARY

* RESTRICTED

DSNT360I -DB22 ***********************************

DSNT362I -DB22 DATABASE = DSN09198 STATUS = RW

DBD LENGTH = 8066

DSNT397I -DB22

NAME TYPE PART STATUS PHYERRLO PHYERRHI CAT

-------- ---- ----- ----------------- -------- -------- ---

USR01H0 IX L0001 RW,RBDP*

USR01H0 IX L* RW,RBDP*



USR012SX IX L0001 RW,RBDP*

USR012SX IX L* RW,RBDP*

USR01DVX IX L0001 RW,RBDP*

USR01DVX IX L* RW,RBDP*


DBD LENGTH = 8066

DSNT397I -DB22

NAME TYPE PART STATUS PHYERRLO PHYERRHI CATALOG PIECE

-------- ---- ----- ----------------- -------- -------- -------- -----





USR010ZY IX L0001 RW,RBDP*

USR010ZY IX L* RW,RBDP*

******* DISPLAY OF DATABASE DSN09202 ENDED **********************

7. Ran rebuilds for all the above listed indexes and verified no more objects were in a restricted status.

At the completion of the test it was validated that all of the new users had been removed from the SAP DB2 system. To complete the test, additional users were added to ensure the add user function was still working in the SAP system.

Federated Database Recovery to any Point in Time for related SAP Systems

Business Suite applications are often not isolated systems but part of business processes. For example, an SAP ERP system may be connected to SAP SCM through SAP NetWeaver PI. Business processes can span these applications. If data is logically corrupted – for example by external tools – there may be the need to undo a whole business process. As multiple SAP systems and databases are involved, this means that a federated recovery of related databases needs to be performed that consistently recovers all affected systems to the same point in time. As it is usually not acceptable to perform a recovery to a prior point in time for entire SAP production systems, as this would mean that committed and clean data gets lost, this task would best be accomplished in database clones of the production systems. Then the corrected data can be brought back into the SAP production systems.

To accomplish this task, DB2 allows you to specify the recovery target point as a GMT timestamp. The time-stamps of all DB2 systems that run on the same IBM Parallel Sysplex are derived from the same time information, which is based on the Server Time Protocol. Therefore, the log records of the different DB2 systems are properly sequenced in time. A federated point-in-time recovery of all DB2 systems that are involved in a business process that needs to be undone, is thus viable. Using the same approach, you can also create a consistent set of SAP system clones on another Sysplex that represent the identical prior point in time.

In the following example, the two SAP systems DB1 and DB2 should be recovered to the same prior point in time, which is 11:09:07.3 am on January 16. Therefore, the corresponding DB2 subsystems DB21 and DB22 are independently recovered to this point in time. Since they run on the same Sysplex and hence share the same timing sequence, this results in both DB2 subsystems being federatively recovered. The DSNJU003 job to specify the conditional restart record for DB21 is as follows:




© 2012 SAP AG 114



//*







//SYSIN DD *

CRESTART CREATE,SYSPITRT=20120161109073

/*

The DSNJU003 job to specify the conditional restart record for DB22 is equivalent.




//*







//SYSIN DD *

CRESTART CREATE,SYSPITRT=20120161109073

/*

The remaining steps to complete the PIT recovery for DB21 and DB22 using RESTORE SYSTEM are as described earlier.

7. SAP Non-Production System Use Cases

This chapter describes some DB2 backup and recovery use cases that are more typical for SAP test systems. A potential performance impact of taking a backup may be acceptable in these environments. A key technology for these scenarios can be space-efficient FlashCopy.

BACKUP SYSTEM using Space-Efficient FlashCopy with NOCOPY (VERSION=0)

Space-Efficient FlashCopy is similar to standard FlashCopy with Version = 0 defined for the data or log copy pools. In other words, there is no background copy taking place after the FlashCopy relationships have been established. The only source volume tracks that are copied are the source tracks that are changing. That is the reason why it is important to dump the SLB backup to tape.

Along with dumping the SLB to tape, it is also highly recommended that FlashCopy Fast Reverse Restore (FCFRR) feature be turned on for the data and log copy pools.

Sample job invocation of DB2 BACKUP SYSTEM

The following excerpt shows a sample invocation of the BACKUP SYSTEM utility from a JCL job. As it is intended to take a backup of both the data and log copy pools, BACKUP SYSTEM is invoked with the FULL and DUMP options. The DUMP option is being used in order to create a full copy of both the data and log copy pools.



© 2012 SAP AG 115

With Space-Efficient DASD, the only tracks that are copied on to target DASD defined in the Repository are the source tracks that are being changed. A copy of the track to be changed is obtained prior to the actual change. In order to have a complete copy of this SLB that can be used as a source or input to other processes, a tape dump must be created. However, if Fast Reverse Restore (FRR) has been specified for the copy pool, then a copy pool restore can be accomplished using the Repository copy of the changed tracks.

//BACKSE30 JOB (DE03557),CH,NOTIFY=MARY,




//*

//*****************************************************

//* STEP BACKUP: RUN BACKUP SYSTEM DB22

//*****************************************************

//BACKUP EXEC DSNUPROC,SYSTEM=DB22,

// UID='MARY',LIB=DB22L.V100.SDSNLOAD


BACKUP SYSTEM FULL DUMP DUMPCLASS(DB2DP03M)

/*

After the Backup System utility has run, there will be a persistent FlashCopy relationship established for all of the volumes in the data and log copy pools. With subsequent executions of the Backup System utility the percent of the source volumes that have been copied over to the Space-Efficient Repository will change.

As can be seen in the HSM messages below, 88% of the active log was had been copied over to backup volume in the Repository, SAPFIL, and the data copy pool does not have any volumes in a FlashCopy relationship. This is because there had been a system level recovery performed in DB2 system DB22.





ARC1821I NONE OF THE VOLUMES IN COPY POOL DSN$DDFDB22$DB, VERSION ***, HAVE AN



***

After a new backup has been obtained the HSM messages below show the FlashCopy relationship has been updated for the active log to show only 1% copied over to SAPFIL. The HSM messages also show a persistent FlashCopy relationship with the data copy pool and their target volumes in the Space-Efficient Repository.












***



© 2012 SAP AG 116

When looking at the copy pool listings there are a couple of things to notice. Even though this is Space-Efficient DASD and there isn’t a full copy of the copy pools in the backup copy pool, the “Fastreplicationstate” indicates RECOVERABLE from the Repository. This is because the FlashCopy Fast Reverse Restore (FCFRR) feature was turned on for the copy pool.





TOKEN(C)=C'DB22H e C% ü? '

TOKEN(H)=X'C4C2F2F2C8B185B672C36C8B000CD06FE19A'


0












Recovering Single Table Using RECOVER Utility with Space-Efficient DASD

The online RECOVER utility recovers data to the current state or to a previous point in time by restoring a copy and then applying log records. You can recover data from image copies of an object or from a system-level backup that contain changes to the object. This feature was introduced in Version 9 of DB2 for z/OS, also known as “single object recovery” from “full backup” and enables customers to optimize the maintenance effort, reduce server capacity by avoiding “image copy” in many cases and speed and simplify recovery processes.

Single object recovery is applicable from disk or from tape system backups. However, in order to perform a single object recovery with a SLB obtained using Space-Efficient DASD, the restore of the tablespace must be done from the tape dump.

To make these features available, please check the DSNZAPRM panel DSNTIP6 for

SYSTEM_LEVEL_BACKUP = YES use system-level backup as recovery base for RECOVER

RESTORE_RECOVER_FROMDUMP = YES / NO the default is NO

You can override this setting by executing the RECOVER utility statement with the FROMDUMP keyword. Furthermore, the TOLOGPOINT and RESTOREBEFORE options have to be taken into account and check which option is appropriate for the current recovery procedure.

No options are necessary for a single object recovery to current.


RECOVER TABLESPACE A201X994.XSAP

/*

//



© 2012 SAP AG 117

TOLOGPOINT X'byte-string' specifies a point on the log to which RECOVER is to recover. Specify either an RBA or an LRSN value. The LRSN is a string of 12 hexadecimal characters and is reported by the DSN1LOGP utility.

For a NOT LOGGED tablespace, the value must be a recoverable point.

Uncommitted work by units of recovery that are active at the specified LRSN or RBA will be backed out by RECOVER, leaving each object in a consistent state.

Prior to z/OS 1.11 there were limitations in using an SLB for a single object recovery. If any of the following utilities had been run since the SLB was obtained, then using the SLB as a recovery base would be prohibited.

REORG TABLESPACE

REORG INDEX

REBUILD INDEX

LOAD REPLACE

RECOVER from image copy or concurrent copy

A new feature called Capture Catalog was introduced with z/OS1.11. This feature is set up for the source copy pool in the DFSMShsm definition for the copy pool. With the Capture Catalog feature turned on, the limitations stated above are eliminated.

COPY POOL LIST

Entries 1-9 of 16


CDS Name : ACTIVE


LINE FCTOPPTC ALLOW

OPERATOR COPY POOL NAME FRRECOV CATINFO FCFRR

---(1)---- -------------(2)-------------- --(15)-- --(16)--- (17)-

DSN$DDFDB21$DB PMNO REQUIRED NO

DSN$DDFDB21$LG PMNO REQUIRED NO

DSN$DDFDB22$DB ------ REQUIRED YES

DSN$DDFDB22$LG ------ REQUIRED YES

DSN$DDFDB23$DB ------ REQUIRED YES

DSN$DDFDB23$LG ------ NO NO

DSN$DDFD6M0$DB ------ NO NO

DSN$DDFD6M0$LG ------ NO NO

DSN$DDFD8E0$DB ------ NO NO

Command ===> Scroll = PAGE

F1=Help F2=Split F3=Exit F4=Return F7=Up F8=Down F9=Swap

F10=Left F11=Right F12=Cancel


The following is an example of recovering a single object to a point-in-time during which the object was being reorganized and using a SLB as the most current recovery base. The test was run in DB22, and as can be seen in the screen shot above, the CATINFO (Capture Catalog) feature has been implemented for both DSN$DDFDB22$DB and DSN$DDFDB22$LG copy pools.

A job was started inserting rows into table SAPR3. ZZZ_LARGE_TABLE at point T2 on the following timeline. While the insert job was running, an online REORG was initiated at point T3. The online REORG along with an inline image copy successfully completed at point T5. The insert job completed after the online REORG at point T6.



© 2012 SAP AG 118

It was decided to recover DSN02334.ZZZRLARG to a point in time prior to the completion of the online REORG at point T4 on the following timeline.

Figure 25. Timeline for single-object recovery

T1 = The LRSN for the system-level backup. The backup was dumped to tape.

T2 = Beginning of insert activity into table SAPR3. ZZZ_LARGE_TABLE

T3 = Beginning of the online REORG.

T4 = Recover to point for tablespace DSN02334.ZZZRLARG

T5 = Completion of the online REORG

T6 = Completion of the insert activity into table SAPR3. ZZZ_LARGE_TABLE

T7 = Problem with tablespace DSN02334.ZZZRLARG requiring recovery.

When it has been determined that a tablespace must be recovered, it is recommended that the Report Recovery utility be used to identify what will be used as a recovery base and which log record data sets will be used to recover the tablespace to the recover to point in time.

The recover-to-point for tablespace DSN02334.ZZZRLARG (T4) was determined to be RBA 0011BB504D52. The following Recover statement was provided in the recovery job.

RECOVER TABLESPACE DSN02334.ZZZRLARG TOLOGPOINT X'0011BB504D52' FROMDUMP

The FROMDUMP option is required because this environment is using Space-Efficient DASDs for the backup copy pool. If the backup copy pool is using full volumes and at least one version of backup is maintained in the backup copy pool, then the above recovery could run from the DASD version in the backup copy pool.

The Report Recovery job provided the following information:

TIMESTAMP = 2012-01-17-15.38.05.027901, TYPE = SLB

TOKEN = C4C2F2F2C8FCA8E8CE4E97E30011B7F75C6C

RBLP =0011B7F75C6C

, DATA COMPLETE LRSN =0011B7F9C230

As can be seen in the information from the Report Recovery job, the SLB with the DATA COMPLETE LRSN = 0011B7F9C230 would be used for a Recovery to RBA 0011BB504D52

The recovery job reported the SLB as the recovery base.

THE RECOVERY BASE FOR TABLESPACE DSN02334.ZZZRLARG IS THE SYSTEM LEVEL BACKUP

WITH DATE = 20120117, TIME 153805, AND TOKEN X'C4C2F2F2C8FCA8E8CE4E97E30011B7F75C6C'

TABLESPACE DSN02334.ZZZRLARG DSNUM 1 WAS SUCCESSFULLY RESTORED FROM A DUMP COPY,



© 2012 SAP AG 119

INDEX SAPR3.ZZZ_LARGE_TABLEß0 IS IN REBUILD PENDING

ALL INDEXES OF DSN02334.ZZZRLARG ARE IN REBUILD PENDING

RECOVER UTILITY LOG APPLY RANGE IS RBA 0011B95EEBF4 LRSN 0011B95EEBF4 TO

RBA 0011BB504D52 LRSN 0011BB504D52

RECOVER UTILITY LOG APPLY AT LOGPOINT 0011BA0F5640

APPLY PHASE COMPLETE, ELAPSED TIME = 00:00:00

DB2 10 Object-Level Recovery from FlashCopy Image Copy while SE FlashCopy Relationship Exists

One of the new features in DB2 10 is the use of data set level FlashCopy for image copy. Not only is this a faster way of obtaining an image copy, but it offloads copy processing from the host to the DASD subsystem.

When querying the DSN$DDFDB22$LG and DSN$DDFDB22$DB copy pools we see both have active FlashCopy relationships, which are persistent because space-efficient DASD is being used in the backup copy pool.

The following JCL and commands were used to obtain the FlashCopy relationship status information.

//HSENDS17 JOB (DE03557),CH,NOTIFY=&SYSUID,




//*

//* SELECT(FRSTATE(FAILED))

//* USED TO CHECK WHETHER THE BACKUPS CREATED BY FAST REPLICATION

//* SERVICES FOR DB2 BACKUP SYSTEM COMPLETED SUCCESSFULLY

//* SELECT(DUMPSTATE(PARTIAL))

//* USED TO LISTS DUMP VERSIONS THAT DID NOT COMPLETE SUCCESSFULLY.

//*



//SYSTSIN DD *

HSEND QUERY COPYPOOL(DSN$DDFDB22$LG)

HSEND QUERY COPYPOOL(DSN$DDFDB22$DB)

//

Output from the query copy pool job:











***

There are two of ways to request that FlashCopy be used for image copy.

1. Specify the FlashCopy option by using DB2 subsystem parameters a. FLASHCOPY_COPY specifies if FlashCopy is the default when running image copy b. FCCOPYDDN provides the template for the data set name of the image copy



© 2012 SAP AG 120

2. Utility control statement parameters

When the FlashCopy subsystem parameters are enabled as the default behavior, you do not need to specify the FlashCopy options in the utility control statement. However, if you specify the FlashCopy options in both the subsystem parameters and the utility control statement parameters, the specifications in the utility control statement override the specifications of the subsystem parameters.

There is another DB2 subsystem parameter that will specify the system default for whether or not FASTREPLICATION should be used during a single-object recovery. This is the REC_FASTREPLICATION parameter. The options are NONE, PREFERRED, or REQUIRED.

NONE – Standard I/O will be used to restore the FlashCopy image copy

PREFERRED – If FlashCopy support is available and fast replication can be established, fast replication will be used to restore the FlashCopy image copy. If not, then standard I/O will be used.

REQUIRED – If FlashCopy cannot be used, the restore will fail.

The tablespace DSN03915.FUNCTION was image copied using the new FlashCopy Image copy (FCIC) feature available in DB2 10. In our testing we used the DB2 subsystem parameters for making FlashCopy the default and providing the template for the image copy data set name.

FCCOPYDDN=DB22IC.&&DB..&&SN..N&&DSNUM..&&UQ.,

FLASHCOPY_COPY=YES,

Image Copy job:

//IMAGECP3 JOB (DE03557),CH,NOTIFY=MARY,


// TIME=120,CLASS=A,REGION=0M TYPRUN=SCAN



//IMAGECPY EXEC DSNUPROC,SYSTEM=DB22,UID=MARY02



//SYSABEND DD SYSOUT=*

//SYSIN DD *

COPY TABLESPACE DSN02334.ZZZRLARG SHRLEVEL CHANGE

/*

In the output of the image copy job there will be a number of ADR messages. Among them you will see the following.

ADR711I (001)-NEWDS(01) DATA SET DB22.DSNDBC.DSN02334.ZZZRLARG.I0001.A001 HAS BEEN

ALLOCATED WITH NEWNAME DB22IC.DSN02334.ZZZRLARG.N00001.DNGU4B0I USING STORCLAS SMS,

DATACLAS XVSAMS, AND MGMTCLAS DB2

ADR806I (001)-T0MI DATA SET DB22.DSNDBC.DSN02334.ZZZRLARG.I0001.A001 COPIED USING A


ADR454I (001)-DDDS THE FOLLOWING DATA SETS WERE SUCCESSFULLY PROCESSED

DB22.DSNDBC.DSN02334.ZZZRLARG.I0001.A001

If you look at the rows in SYSCOPY, you see the image copy backup for the full copy is identified as FlashCopy backups by the ICBACKUP column. Even if FlashCopy is identified as the ICBACKUP, you need



© 2012 SAP AG 121

to look at the image copy job output to see if fast replication was actually used. See ADR806I message above.

SELECT DBNAME, TSNAME, ICTYPE, ICBACKUP, TIMESTAMP

FROM SYSIBM.SYSCOPY

WHERE TSNAME = 'ZZZRLARG' AND ICTYPE = 'F' ;

L DBNAME TSNAME ICTYPE ICBACKUP TIMESTAMP

* * * * *

- -------- -------- ------ -------- --------------------------

DSN02334 ZZZRLARG F FC 2012-01-23-22.55.32.305757

DSN02334 ZZZRLARG F FC 2012-01-18-23.54.41.784999

DSN02334 ZZZRLARG F 2012-01-17-16.00.45.504146

DSN02334 ZZZRLARG F 2011-12-08-15.40.45.457207

DSN02334 ZZZRLARG F 2011-12-01-16.05.39.060682

DSN02334 ZZZRLARG F FC 2011-11-14-16.30.43.448968

DSN02334 ZZZRLARG F FC 2011-11-14-15.53.15.336363

DSN02334 ZZZRLARG F FC 2011-11-14-15.09.32.924676

DSN02334 ZZZRLARG F FC 2011-11-14-14.04.37.964008

DSN02334 ZZZRLARG F FC 2011-11-14-12.35.06.038454

Recovering DSN02334.ZZZRLARG using the FlashCopy image copy

By using the copy pool query job above, we see both the DSN$DDFDB22$LG and DSN$DDFDB22$DB copy pools are still in a persistent FlashCopy relationship. Again, this is due to the use of space-efficient DASD for the backup copy pool.












***

Even though the FlashCopy image copy (FCIC) can be used to recover the tablespace, fast replication will not be used. This is because the DSN$DDFDB22$DB copy pool is in a FlashCopy relationship. However, the tablespace will still be recovered successfully. Below is the JCL used to recover DSN02334.ZZZRLARG.

//RECVR23C JOB (DE03557),CH,NOTIFY=MARY,





//REPORT EXEC DSNUPROC,SYSTEM=DB22,UID=MARY02




//SYSIN DD *

RECOVER TABLESPACE DSN02334.ZZZRLARG TOLASTFULLCOPY



© 2012 SAP AG 122

/*

Job output from the Recovery job is provided below. We see ADR messages indicating the image copy data set created in the image copy job above will be used in the recovery. Message ADR918I states Fast Replication could not be used for the image copy data set. However, the restore is still completed. The reason fast replication couldn’t be used is indicated by the last message IGD17268I, stating the 3 volumes in the SMS storage group DB2DI were already in a FlashCopy relationship. This is because of the space-efficient DASD being used in the backup copy pool.

The recovery job completes with a return code = 4 because the index is left in rebuild pending.

Recovery job output:

DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = MARY02

DSNUGTIS - PROCESSING SYSIN AS EBCDIC

DSNUGUTC - RECOVER TABLESPACE DSN02334.ZZZRLARG TOLASTFULLCOPY

.

.

.

ADR442I (001)-PREVS(03), DATA SET DB22IC.DSN02334.ZZZRLARG.N00001.DNGU4B0I PREALLOCATED WITH

NEW NAME

DB22.DSNDBC.DSN02334.ZZZRLARG.I0001.A001, IN CATALOG SYS1.USERCAT.DB22, ON VOLUME S): SAPDI1

ADR390I (001)-PREVS(08), DATA SET DB22.DSNDBC.DSN02334.ZZZRLARG.I0001.A001 WILL BE SCRATCHED

FROM SAPDI1 BECAUSE OF UNMATCHED SIZE. IT WILL BE REALLOCATED

ADR918I (001)-VDSS (01), FAST REPLICATION COULD NOT BE USED FOR DATA SET

DB22IC.DSN02334.ZZZRLARG.N00001.DNGU4B0I, RETURN CODE 15

IGD17070I DATA SET DB22.DSNDBC.DSN02334.ZZZRLARG.I0001.A001

ALLOCATED SUCCESSFULLY WITH 1 STRIPE(S).

IGD17172I DATA SET DB22.DSNDBC.DSN02334.ZZZRLARG.I0001.A001

IS ELIGIBLE FOR EXTENDED ADDRESSABILITY

IGD17330I DATA SET DB22.DSNDBC.DSN02334.ZZZRLARG.I0001.A001 WAS

ALLOCATED ON VOLUME(S) WHICH ARE NOT ELIGIBLE FOR FAST REPLICATION.

PREFERRED FAST REPLICATION WAS SPECIFIED BY THE CALLER.

IGD17290I THERE WERE 1 CANDIDATE STORAGE GROUPS OF WHICH THE FIRST 1

WERE ELIGIBLE FOR VOLUME SELECTION.

THE CANDIDATE STORAGE GROUPS WERE:DB2DI

IGD17267I THE FOLLOWING (1) CANDIDATE STORAGE GROUPS WERE

INELIGIBLE FOR PREFERRED FAST REPLICATION BECAUSE THEY DID NOT HAVE

A SUFFICIENT NUMBER (1) OF ELIGIBLE FAST REPLICATION VOLUMES: DB2DI

IGD17268I 3 VOLUMES WERE NOT USED FOR FAST REPLICATION BECAUSE

OF FULL VOL FC SOURCE RELATION

.

.

.

DSNU566I 023 22:37:17.86 DSNUCBMT - RESTORE OF TABLESPACE DSN02334.ZZZRLARG

FROM DATA SET DB22IC.DSN02334.ZZZRLARG.N00001.DNGU4B0I COMPLETED, ELAPSED TIME=00:00:01

DSNU830I -DB22 023 22:37:16.68 DSNUCARS - INDEX SAPR3.ZZZ_LARGE_TABLEß0 IS IN REBUILD PENDING

DSNU831I -DB22 023 22:37:16.68 DSNUCARS - ALL INDEXES OF DSN02334.ZZZRLARG ARE IN REBUILD

PENDING

DSNU500I 023 22:37:18.02 DSNUCBDR - RECOVERY COMPLETE, ELAPSED TIME=00:00:01




© 2012 SAP AG 123

DB2 10 Object-Level Recovery from FC Image Copy after SE FC Relationship has been Withdrawn

The persistent FlashCopy (FC) relationship for DSN$DDFDB22$LG and DSN$DDFDB22$DB copy pools were withdrawn prior to running the recovery for tablespace DSN02334.ZZZRLARG

The JCL and HSM command used to withdraw the FlashCopy relationships follows.

//FRBACKUP JOB (DE03557),CH,NOTIFY=&SYSUID,





//*

//*****************************************************

//* JOB DESCRIPTION

//*****************************************************

//*



//SYSTSIN DD *

HSEND FRBACKUP CP(DSN$DDFDB22$LG) WITHDRAW

HSEND FRBACKUP CP(DSN$DDFDB22$DB) WITHDRAW

As can be seen from the HSM system log messages, the FlashCopy relationships were withdrawn and the most current SLB can no longer be used from the space-efficient (SE) DASD. However, this SLB was dumped to tape and if needed the FROMDUMP option could be used with a Restore or Recovery process.

ARC1833I WITHDRAW COMPLETED FOR COPY POOL 860

ARC1833I (CONT.) DSN$DDFDB22$LG, BACKUP VERSION NUMBER 24 WAS

ARC1833I (CONT.) INVALIDATED

ARC1831I BACKUP VERSION NUMBER 24 OF COPY POOL 861

ARC1831I (CONT.) DSN$DDFDB22$LG WAS DELETED SUCCESSFULLY

ARC1833I WITHDRAW COMPLETED FOR COPY POOL 874

ARC1833I (CONT.) DSN$DDFDB22$DB, BACKUP VERSION NUMBER 17 WAS

ARC1833I (CONT.) INVALIDATED

ARC1831I BACKUP VERSION NUMBER 17 OF COPY POOL 875

ARC1831I (CONT.) DSN$DDFDB22$DB WAS DELETED SUCCESSFULLY

The Report Recovery utility was used to identify the most recent copy that will be used in recovering DSN02334.ZZZRLARG. As can be seen the ICTYPE is a full copy and FlashCopy was used when obtaining this copy.

TIMESTAMP = 2012-01-23-22.55.32.305757, IC TYPE = F , SHR LVL = C, DSNUM

DEV TYPE = , IC BACK = FC, STYPE = N, FILE SEQ

LOW DSNUM = 0001, HIGH DSNUM = 0001, OLDEST VERSION = 0000, LOGICAL PART =

JOBNAME = IMAGECP6, AUTHID = MARY , COPYPAGESF = -1.0E+00


DSNAME = DB22IC.DSN02334.ZZZRLARG.N00001.DNOTX4YB , MEMBER NAME =

Following is the JCL and command to recover DSN02334.ZZZRLARG

//RECVR25A JOB (DE03557),CH,NOTIFY=MARY,






© 2012 SAP AG 124


//RECOVER EXEC DSNUPROC,SYSTEM=DB22,UID=MARY02




//SYSIN DD *

RECOVER TABLESPACE DSN02334.ZZZRLARG TOLASTFULLCOPY

/*

The following are messages from the recovery job output. The ADR030I message provides the COPY statement used for restoring from the image copy. The very last parameter is FR(PREF), meaning that Fast Replication is the preferred method for restoring from the image copy. In the ADR messages following the COPY statement, we see ADR806I indicating that fast replication was used,

DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = MARY02

DSNUGTIS - PROCESSING SYSIN AS EBCDIC

DSNUGUTC - RECOVER TABLESPACE DSN02334.ZZZRLARG TOLASTFULLCOPY

.

.

.

-ADR030I (SCH)-PRIME( 0), DCB VALUES HAVE BEEN MODIFIED FOR SYSPRINT.


DB22IC.DSN02334.ZZZRLARG.N00001.DNOTX4YB )) -

RENAMEU( -

(DB22IC.DSN02334.ZZZRLARG.N00001.DNOTX4YB , -

DB22.DSNDBC.DSN02334.ZZZRLARG.I0001.A001 )) -

ALLDATA(*) ALLEXCP CANCELERROR SHARE -


REPUNC TOLERATE(ENQF) DEBUG(FRMSG(DTL)) FR(PREF)

.

.

ADR442I (001)-PREVS(01), DATA SET DB22IC.DSN02334.ZZZRLARG.N00001.DNOTX4YB

PREALLOCATED WITH NEW NAME

DB22.DSNDBC.DSN02334.ZZZRLARG.I0001.A001, IN CATALOG SYS1.USERCAT.DB22, ON VOLUME(S):

SAPDI3

ADR806I (001)-T0MI (03), DATA SET DB22IC.DSN02334.ZZZRLARG.N00001.DNOTX4YB COPIED

USING A FAST REPLICATION FUNCTION

ADR454I (001)-DDDS (01), THE FOLLOWING DATA SETS WERE SUCCESSFULLY PROCESSED

DB22IC.DSN02334.ZZZRLARG.N00001.DNOTX4YB

DB2 RESTORE SYSTEM with z/OS 1.12 Fast Reverse Restore

Prior to z/OS 1.12 and the Fast Reverse Restore feature, there were limitations when an SLB on DASD could be used for a system level recovery. These limitations were as follows:

Background copies had to be completed and any Flash Copy relationships had to be withdrawn.

If version = 0 was defined for the copy pool, there wasn’t any background copy created on the backup copy pool DASD. The FlashCopy relationships weren’t withdrawn until the tape dumps were completed. Any system level recoveries had to be accomplished using the dump copy.

If space-efficient DASD is being used for the backup copy pool the behavior is similar to version = 0 copy pool definitions. z/OS 1.11 automatically initializes space-efficient backup volumes when a dump to tape has completed.



© 2012 SAP AG 125

In order to use Fast Reverse Restore (FRR) for a given copy pool, it must be activated in the copy pool definition.

In the screenshot below the ALLOW FCFRR has been activated for three different copy pools.


If FCFRR was activated for a given SLB, it will be indicated in output copy pool listing. To obtain a copy pool list use the following JCL:

//HSMLST12 JOB (DE03557),CH,NOTIFY=MARY,




//*

//**************************************************

//* LIST COPYPOOL

//* SELECT(FRSTATE(FAILED))

//* USED TO CHECK WHETHER THE BACKUPS CREATED BY FAST REPLICATION

//* SERVICES FOR DB2 BACKUP SYSTEM COMPLETED SUCCESSFULLY

//* SELECT(DUMPSTATE(PARTIAL))

//* USED TO LISTS DUMP VERSIONS THAT DID NOT COMPLETE SUCCESSFULLY.

//* DUMPVOLS

//* USED TO GET LIST OF DUMP VOLUMES FROM COMPLETED DUMP

//**************************************************

//*




//SYSTSIN DD *

HSEND LIST COPYPOOL(DSN$DDFDB22$DB) DUMPVOLS



© 2012 SAP AG 126

HSEND LIST COPYPOOL(DSN$DDFDB22$LG) DUMPVOLS

/*

The backup copy pools for DSN$DDFDB22$DB and DSN$DDFDB22$LG are space-efficient DASD. As can be seen in the output from the copy pool list below, even though there isn’t a full copy of the source copy pools in the backup copy pools, the FASTREPLICATIONSTATE for the most current copies are marked as RECOVERABLE. This is because the FCFRR feature was specified for the source copy pools prior to the backup being obtained.

















The FlashCopy relationships for the above copy pools can be queried the using HSM HSEND QUERY command.



//SYSTSIN DD *

HSEND QUERY COPYPOOL(DSN$DDFDB22$LG)

HSEND QUERY COPYPOOL(DSN$DDFDB22$DB)

The output from the HSM copy pool query shows that the source copy pools are in a relationship with the backup copy pool. This is a space-efficient backup copy pool, so these relationships are persistent. However, the only time changed tracks are written to the backup copy pool is when either the Backup System utility or FRBACKUP are executed in order to create a new backup copy.













© 2012 SAP AG 127


***

It is recommended to force an active log archive across all DB2 members using the DB2 ARCHIVE LOG command prior to stopping DB2. After DB2 is stopped and the point-in-time to which the DB2 system is being returned has been determined, it is highly recommended that the $LG copy pool be backed up using HSM FRBACKUP prior to running the change inventory job (DSNJU003) to establish the SYSPITR or SYSPITRT conditional restart card. This will enable a return to the active log environment and its status prior to the change inventory job being executed, using the HSM FRRECOV command.

In order to use the DB2 Restore System utility to perform a FRR system level restore using the backup copy pool DASD in the Space Efficient and version = 0 configurations, make sure the following APARs are installed:

APAR - PM53237

APAR - OA38169

If they are not installed and the DB2 Restore System utility is used in performing an FRR restore it will fail with a return code = 8 and provide the following messages:

DSNU1637I 312 10:58:20.99 DSNUVBRD - RESTORE SYSTEM UTILITY FAILED BECAUSE NO

FLASHCOPY IS AVAILABLE

DSNU1631I 312 10:58:20.99 DSNUVBRD - RESTORE SYSTEM UTILITY FAILED BECAUSE THE CALL

TO DFSMSHSM FAILED WITH RC = X'00000000' SEE THE HSM ACTIVITY LOG FOR HSM MESSAGES

INDICATING THE CAUSE OF THE ERROR.

Without the above listed APARs you can still perform a FRR system level restore using the HSM FRRECOV command.

//FRRCSE25 JOB (DE03557),CH,NOTIFY=&SYSUID,





//*



//SYSTSIN DD *

HSEND FRRECOV CP(DSN$DDFDB22$DB) VERIFY(Y)

/*

The following messages are written to the HSM started task’s JESMSGLG. Notice in the messages below that HSM is issuing the unallocate message for the ICF user catalog for the objects in the DSN$DDFDB22$DB copy pool prior to trying and restoring the volumes using FRR. This is necessary or the restore to the volume containing the ICF user catalog will fail.

Prior to z/OS 1.11 and the Capture Catalog feature, it was necessary to enter the unallocate command manually. As long as the user ICF catalogs in the copy pool are listed in the catalog information section of the copy pool definition, HSM will have the information needed to issue the unallocated command. The ‘Capture Catalog Information for Data Ser Recovery’ can be turned off by setting it to ‘N’, but the user ICF catalog data set names must be listed.



© 2012 SAP AG 128

Notice the ARC1851I message indicating that current backup in the backup copy pool has been invalidated. Even though this backup would not be available for any subsequent FRR restores, the tape dump copy is still valid and a FROMDUMP restore could be used if necessary.

ARC1801I FAST REPLICATION RECOVERY IS STARTING FOR 905

ARC1801I (CONT.) COPY POOL DSN$DDFDB22$DB, AT 21:23:15 ON 2011/11/21

F CATALOG,UNALLOCATE(SYS1.USERCAT.DB22 )

.

.

.

ARC1838I INITIALIZATION ATTEMPT OF COPY POOL BACKUP 922

ARC1838I (CONT.) STORAGE GROUP VOLUME SAPFI1 HAS COMPLETED, RC=0000,

ARC1838I (CONT.) RSN=0000

.

.

.




.

.

.




ARC1851I BACKUP VERSION 0011 FOR COPY POOL 934

ARC1851I (CONT.) DSN$DDFDB22$DB WAS INVALIDATED, RC=0002

ARC1805I THE FOLLOWING 00003 VOLUME(S) WERE 935

ARC1805I (CONT.) SUCCESSFULLY PROCESSED BY FAST REPLICATION RECOVERY

ARC1805I (CONT.) OF COPY POOL DSN$DDFDB22$DB

ARC1805I (CONT.) SAPDI1



ARC1802I FAST REPLICATION RECOVERY HAS COMPLETED FOR 939

ARC1802I (CONT.) COPY POOL DSN$DDFDB22$DB, AT 21:23:19 ON 2011/11/21,


After the restore of the DSN$DDFDB22$DB copy pool has successfully completed, as seen in the HSM messages, and the DB2 system has been restarted, the DB2 Restore System utility is executed using a RESTORE SYSTEM LOGONLY system level recovery.

From the DB22MSTR JESMSGLG we see the number of log records read during the fast log apply in order to complete the system level recovery to the point-in-time established in the BSDS with the change inventory job (DSNJU003).

DSNI028I -DB22 DSNIFLAF THE NUMBER OF QUALIFIED

LOG RECORDS READ DURING THE FAST LOG APPLY PROCESS IS 1336590

AND THE NUMBER OF FAST LOG APPLY BUFFERS PROCESSED ARE 2

If you query the FlashCopy relationships of the copy pools after the system level recovery, you will see the DSN$DDFDB22$LG copy pool is still in a persistent relationship with its backup copy pool. However, the DSN$DDFDB22$DB copy pool is no longer in a FlashCopy relationship. This relationship will be reestablished when the next backup is obtained.



© 2012 SAP AG 129





ARC1821I NONE OF THE VOLUMES IN COPY POOL DSN$DDFDB22$DB, VERSION ***, HAVE AN



***

The copy pool list shows this version of the backup is no longer available for fast replication. However, the dump copy of this backup is still available and usable.

















Verifying RESTORE SYSTEM, especially the Cases Restore from Tape and "not logged" Points

Using DB2 Restore System when recovering a DB2 system has a number of advantages. It performs the recovery at the system level, which means there is no need to run hundreds or thousands of single object recoveries. The log records are only read once, which means it isn’t necessary to support access to the log records from many concurrently running recovery jobs.

One of the challenges with system level recovery is providing for the proper identification of objects that had a “not logged” type of process take place against the object during the log apply phase of the system level recovery, such as online REORG. The DB2 Restore System utility will place these objects into the appropriate restricted status and will provide a message indicating that one or more objects has been put into recover-pending or rebuild-pending status.

DSNUVARL - RESTORE SYSTEM PHASE LOG APPLY STARTED AT LOG POINT = X'0012F3BF8C7F'

DSNUVARL - DB2 PUT ONE OR MORE OBJECTS INTO THE RECOVER-PENDING STATE, THE

REBUILD-PENDING STATE,OR THE LOGICAL PAGE LIST DURING THE LOG APPLY PHASE.

At the end of any system level recovery you should do the following: 1. Stop and restart the DB2 system. This will place the DB2 system back in “normal” operational mode. This will also ensure the correct contents of the ICF user catalog for the data sets in the $DB copy pool is being used and is in sync with the DB2 Catalog and Directory.



© 2012 SAP AG 130

2. Execute the following displays · DIS DB(DSNDB01) SP(*) RESTRICT · DIS DB(DSNDB06) SP(*) RESTRICT · DIS DB(*) SP(*) RESTRICT · DIS UTIL(*)

Based on the DSNUVARL message above there will be some objects showing up in recover-pending or rebuild-pending. The objects that are in recover-pending had online REORGs run after the SLB was obtained and the REORGs completed prior to the point-in-time to which this DB2 system was returned. Make sure any utilities that are registered are terminated prior to recovering or rebuilding any of the objects in a restricted status.

DSNT360I -DB22 ***********************************

DSNT361I -DB22 * DISPLAY DATABASE SUMMARY

* RESTRICTED

DSNT360I -DB22 ***********************************


DBD LENGTH = 8066

DSNT397I -DB22

NAME TYPE PART STATUS PHYERRLO PHYERRHI

-------- ---- ----- ----------------- -------- --------

REPOSRC TS 0001 RW,RECP

REPOSRC TS RW,RECP

LFSEE2O5 LS RW,RECP

IREPOSDA IX RW,RBDP

REPOSRCH IX L0001 RW,RBDP,PSRBD

REPOSRCH IX L* RW,RBDP,PSRBD

REPO1YXE IX L0001 RW,RBDP,PSRBD

REPO1YXE IX L* RW,RBDP,PSRBD

******* DISPLAY OF DATABASE DSN00011 ENDED *******

DSNT360I -DB22 ***********************************


DBD LENGTH = 8066

DSNT397I -DB22

NAME TYPE PART STATUS PHYERRLO PHYERRHI

-------- ---- ----- ----------------- -------- --------

SMIMCONT TS 0001 RW,RECP

SMIMCONT TS RW,RECP

SMIM1YDE IX L0001 RW,RBDP,PSRBD

SMIM1YDE IX L* RW,RBDP,PSRBD

******* DISPLAY OF DATABASE DSN00014 ENDED *******

One of the features that is new in DB2 10 is the use of data set level FlashCopy in obtaining image copies, also referred to as FCIC. In the case of the objects above FCICs were obtained during the online REORG jobs and were used to recover the table spaces listed above. The ADR030I message in recovery job output provides the COPY statement used by the recover utility when restoring from the FCIC. As you can see Fast Replication was preferred, FR(PREF). The ADR806I messages in the recovery job output reports that fast replication was used when recovering the table spaces.

ADR030I (SCH)-PRIME( 0), DCB VALUES HAVE BEEN MODIFIED FOR SYSPRINT.




© 2012 SAP AG 131

DB22IC.DSN00011.REPOSRC.N00001.DNRT1E8S , -

DB22IC.DSN00011.LFSEE2O5.N00001.DNRT1E81 )) -

RENAMEU( -

(DB22IC.DSN00011.REPOSRC.N00001.DNRT1E8S , -

DB22.DSNDBC.DSN00011.REPOSRC.J0001.A001 ) -

(DB22IC.DSN00011.LFSEE2O5.N00001.DNRT1E81 , -

DB22.DSNDBC.DSN00011.LFSEE2O5.J0001.A001 )) -

ALLDATA(*) ALLEXCP CANCELERROR SHARE -


REPUNC TOLERATE(ENQF) DEBUG(FRMSG(DTL)) FR(PREF)

.

.

.

ADR806I (001)-T0MI (03), DATA SET DB22IC.DSN00011.REPOSRC.N00001.DNRT1E8S COPIED


ADR806I (001)-T0MI (03), DATA SET DB22IC.DSN00011.LFSEE2O5.N00001.DNRT1E81 COPIED


Recover Single-Object Based on System-Level Backup and Exploiting Archive Logs

As the Backup System, Restore System and Recovery utilities have been evolving to take advantage of new hardware and system software functions, it is important to ensure that single-object recovery still provides the ability to use archive logs if required.

The following example describes the use of a system-level backup as the recovery base for a single-object recovery. It shows how both active and archive log data sets are used to apply the log in combination with a system-level backup. The same applies to system-level recovery when both active and archive log data sets need to be processed. In the use case, the log apply phase depended on using some log records that had been archived.

Figure 26. Single-Object Recovery Exploiting Archive Logs

During the execution of a SAP process, the active logs were archived by using the DB2 ARCHIVE LOG command a number of times to ensure that the active logs at the beginning of the execution of the SAP process had been reused. So, any recovery action requiring log records created at the beginning of the SAP process would need to be read from archive log data sets.

The object being recovered in this test was tablespace DSN04173.DDLOG.

If can be seen from the timeline above that the TOLOGPOINT was 000C68617770, which follows is the ENDRBA for the log apply.

The various ARCHIVE LOG command executions are indicated on the timeline with the STARTRBA of the archive log data set being created.

The timeline also shows the range of RBAs in which the log records had to be read from an archive log data set. Even though the logs records between 000C602FD000 and 000C63FE5FFF had been archived (see



© 2012 SAP AG 132

last archive in ARCHIVE LOG COPY1 DATA SETS below) these log records were still in the active logs data sets.

ACTIVE LOG COPY 1 DATA SETS START RBA/TIME END RBA/TIME -------------------- -------------------- 000C602FD000 000C63FE5FFF 2011.313 09:14:46.2 2011.313 09:21:33.7 000C63FE6000 000C67149FFF 2011.313 09:21:33.7 2011.313 09:25:04.2 000C6714A000 000C93069FFF 2011.313 09:25:04.2 ........ ..........

ARCHIVE LOG COPY 1 DATA SETS START RBA/TIME END RBA/TIME DATE LTIME -------------------- -------------------- -------- ----- 000C4DA5F000 000C559EEFFF 2011.313 10:08 2011.312 15:26:45.9 2011.313 09:07:54.9 000C559EF000 000C5AB1EFFF 2011.313 10:10 2011.313 09:07:54.9 2011.313 09:10:46.6 000C5AB1F000 000C602FCFFF 2011.313 10:14 2011.313 09:10:46.6 2011.313 09:14:46.2 000C602FD000 000C63FE5FFF 2011.313 10:21 2011.313 09:14:46.2 2011.313 09:21:33.7

Also, from the BSDS print map can be seen the list of SLB along with recovery base log point (RBLP), token information that is also recorded in HSM, z/OS level, catalog capture status, and LRSNs related to start and completion of the SLB. In this test the SLB listed below is used as the recovery base for tablespace DSN04173.DDLOG because this is the most recent copy recorded in SYSCOPY created for this object prior to the TOLOGPOINT of 000C68617770.

BACKUP SYSTEM UTILITY HISTORY SUBSYSTEM ID DB22 20:09:41 FEBRUARY 01, 2012 START STCK DATA COMPLETE DATA/LOG COMPLETE DATA LOG RBLP LRSN DATE LTIME ---------------- ---------------- ------------ ------------ --------------- C8A4C00318FB464E C8A4C01B8A7621CE 000C4E79C448 000C4E7C18A7 2011/11/08 17:32:52 TOKEN = C4C2F2F2C8A4C00318FB464E000C4E79C448 Z/OS 1.13 .CAT=YES

The recovery jobs was run with the following utility control statement. The FROMDUMP was required because this system is using Space Efficient DASD for the Backup Copy Pool, so a full backup of the tablespace in not in the Backup Copy Pool, but is on the tape dump of the SLB.

RECOVER TABLESPACE DSN04173.DDLOG TOLOGPOINT X'000C68617770' REUSE FROMDUMP

In the recovery job output it can be seen that the SLB listed above from the BSDS print map is used as the recovery base.

THE RECOVERY BASE FOR TABLESPACE DSN04173.DDLOG IS THE SYSTEM LEVEL BACKUP WITH DATE = 20111108, TIME 173252, AND TOKEN X'C4C2F2F2C8A4C00318FB464E000C4E79C448' TABLESPACE DSN04173.DDLOG DSNUM 1 WAS SUCCESSFULLY RESTORED FROM A DUMP COPY, ELAPSED TIME=00:00:54

The recovery job output indicates the indexes for the tablespace are left in REBUILD PENDING and ends the recovery job with a return code = 4.

INDEX SAPR3.DDLOGß0 IS IN REBUILD PENDING INDEX SAPR3.DDLOGßDB2 IS IN REBUILD PENDING



© 2012 SAP AG 133

ALL INDEXES OF DSN04173.DDLOG ARE IN REBUILD PENDING

The recovery job output provides information on the RBA and LRSN range being used in the log apply phase in order to complete the recovery of the object to the designated TOLOGPOINT. As can be seen the start RBA is the RBLP from the SLB used as the recovery base.

RECOVER UTILITY LOG APPLY RANGE IS RBA 000C4E79C448 LRSN 000C4E79C448 TO RBA 000C68617770 LRSN 000C68617770 LOG APPLY PHASE COMPLETE, ELAPSED TIME = 00:00:03 PRIOR CHECKPOINT RBA = X'000C68605977' DSNUCALC - LOGCSR IS FINISHED FOR MEMBER , ELAPSED TIME = 00:00:00 DSNUCALC - LOGCSR PHASE COMPLETE, ELAPSED TIME = 00:00:00

The following HSM messages can be found in the HSM started task JESMSGLG. If there were any problems with the restore of the data set, the message would also be included in this log.

ARC1801I FAST REPLICATION DATA SET RECOVERY IS 317 ARC1801I (CONT.) STARTING FOR DATA SET ARC1801I (CONT.) DB22.DSNDBC.DSN04173.DDLOG.I0001.A001, AT 13:01:21 ON ARC1801I (CONT.) 2011/11/09 IEC501A M 1B11,WA0960,SL,COMP,HSM,HSM,SAP.DMP.DB2DP03M.VSAPDI1.D11312.T253217 ARC1861I THE FOLLOWING 0001 DATA SET(S) WERE 321 ARC1861I (CONT.) SUCCESSFULLY PROCESSED DURING FAST REPLICATION DATA ARC1861I (CONT.) SET RECOVERY: ARC1861I (CONT.) DB22.DSNDBC.DSN04173.DDLOG.I0001.A001, COPYPOOL=DSN$DDFDB22$DB, ARC1802I FAST REPLICATION DATA SET RECOVERY HAS 323 ARC1802I (CONT.) COMPLETED FOR DATA SET ARC1802I (CONT.) DB22.DSNDBC.DSN04173.DDLOG.I0001.A001, AT 13:02:16 ON ARC1802I (CONT.) 2011/11/09, FUNCTION RC=0000, MAXIMUM DATA SET RC=0000 IEF234E K 1B11,WA0960,PVT,HSM,HSM



© 2012 SAP AG 134

8. Embedded Nearline Storage for 100 TB SAP BW systems

Embedded Nearline Storage – Taking Aged Table Partitions out of HSM Copy Pool

Nearline storage is a data container that resides between online storage and archive. Applications can still read data in nearline storage but usually experience limitations in term of performance and / or availability for update operations. Nearline storage solutions are individual systems separated from the database that holds the application data. Thus, the data in nearline storage may reside on more affordable disks. .

This chapter presents an approach to take data out of the regular backup procedure while the data remains within DB2 and available for read access. This is done without moving the data to a different system so that no new ETL processes need to be established and no new systems need to be created. This approach is called embedded Nearline Storage.

While this approach may also apply to other SAP applications, the focus is on the SAP NetWeaver Business Warehouse (SAP BW), because at most sites such systems are the largest systems within the SAP landscape. They may grow to sizes in the range of 100 TB. Most of the data in an SAP BW system reside in PSA (persistent storage area) tables, active data tables for data store objects and e-fact tables. PSA tables are always range-partitions. Active data tables and e-fact tables are partitioned if the corresponding data store object or infocube, respectively, is partitioned. The partitioning is usually done based on a column that represents a timeline. The indexes on these tables are all partitioned so they are DPSIs. There is no global index (NPI) on such a table. The partitions that hold older data are never updated. Thus, there is an opportunity to take these table partitions out of the regular backup procedure. If these partitions make up 60 TB out of the 100 TB for example, this would reduce the size of every system-level backup on disk and tape by 60 TB (even if Space-efficient FlashCopy is not used, which only helps reducing the size of backups on disk).

One way to take partitions out of the regular backup is to move the data to an external nearline storage system. However, this approach adds complexity to the SAP BW solution since an additional component is introduced and ETL processes are required to feed this system. An alternative approach is to keep all the SAP BW data within the DB2 system but to relocate the underlying data sets of the table partitions that contain aged data outside of the HSM copy pools of the DB2 system. That way the size of the database backups on disk and tape is reduced while all the data in the aged partitions can still be accessed. The SAP BW queries are executed as usual and if needed new statistics could also be collected for such table partitions using the standard DB2 Runstats utility. No additional databases need to be monitored. Such an approach is described in detail in the following. The disk footprint of the DB2 system can be further reduced by enabling the automatic HSM offload to tape for the data sets that contain aged data. According to an HSM policy, data sets that were not accessed for a specified period of time are automatically offloaded to tape freeing up disk space. Besides reducing the size of backups on disk and tape, this capability can further reduce the size of the actual SAP BW system from 100 TB to about 40 TB in the example above.

As an example demonstrating embedded Nearline Storage, let us consider the e-fact table of infocube JOCUBE. The table name is /BIC/EJOCUBE. The following SQL query retrieves its partition layout:

SELECT PRT.PARTITION, PRT.LOGICAL_PART,

PRT.STORNAME, PRT.VCATNAME, PRT.IPREFIX,

PRT.CARD, PRT.LIMITKEY

FROM SYSIBM.SYSTABLES TAB, SYSIBM.SYSTABLEPART PRT

WHERE TAB.TSNAME = PRT.TSNAME AND

TAB.DBNAME = PRT.DBNAME AND

TAB.CREATOR = CURRENT SQLID AND

TAB.NAME = '/BIC/EJOCUBE'

ORDER BY LOGICAL_PART



© 2012 SAP AG 135

The table has 5 partitions, one for each year 2009 to 2012 and an overflow partition:

PARTITION LOGICAL_PART STORNAME VCATNAME IPREFIX CARD LIMITKEY

1 1 SYSDEFLT DB21 J 5.000 200912 2 2 SYSDEFLT DB21 I 5.000 201012 3 3 SYSDEFLT DB21 I 5.000 201112 4 4 SYSDEFLT DB21 I 0 201212 5 5 SYSDEFLT DB21 I 0 2147483647

The table resides in table space FBICFEJO.DSN04225.

Since the data for year 2009 will not be updated anymore, partition 1 is intended to be excluded from the regular backup procedure. To do so, proceed as follows:

1. Verify that APAR PM59420 is installed and configure DSN6SPRM as described in the APAR so thatDB21X is the read-only VCAT.

2. Revoke RACF ALTER privilege for data sets with VCAT DB21X from the user ID that is associated with the DB2 address spaces (DB21USER in this example)

3. Define a new storage group SAPSTOGP and assign VCAT DB21X to it.

4. Stop table partition 1: -STOP DB(DSN04225) SPACENAM(FBICFEJO) PART(1)

5. Copy the underlying data set of partition 1 to high level qualifier DB21X. Please note that the instance qualifier (IPREFIX) is J, thus the data set name is DB21.DSNDBC.DSN04225.FBICFEJO.J0001.A001 See below for information about how to exploit DFSMSdss fast replication for data set copy.

6. Alter the storage group: ALTER TABLESPACE DSN04225.FBICFEJO ALTER PARTITION 1 USING STOGROUP

SAPSTOGP

7. Restart the table partition: -START DB(DSN04225) SPACENAM(FBICFEJO) PART(1)

8. Take an image copy of partition 1

9. Delete data set DB21.DSNDBC.DSN04225.FBICFEJO.J0001.A001

Afterwards the result set of the SQL query above reads like this:

PARTITION LOGICAL_PART STORNAME VCATNAME IPREFIX CARD LIMITKEY

1 1 SAPSTOGP DB21X J 5.000 200912 2 2 SYSDEFLT DB21 I 5.000 201012 3 3 SYSDEFLT DB21 I 5.000 201112 4 4 SYSDEFLT DB21 I 0 201212 5 5 SYSDEFLT DB21 I 0 2147483647

Once a table partition is taken out of the HSM copy pool, it will not be included in a system backup anymore. The single image copy taken for it is sufficient since SAP BW does not allow updates to the aged data in that partition anymore. To ensure that the partition is really not updated anymore and that attempts to do so become visible, the RACF ALTER privilege of the underlying data set is revoked.



© 2012 SAP AG 136

In the test environment the DB2 subsystem DB21 runs under user id DB21USER. Therefore data set profile DB21X.** of the RACF configuration is changed such that user DB21USER has READ access only.

INFORMATION FOR DATASET DB21X.** (G)

...

ID ACCESS

-------- -------

DB21USER READ

DB2USER ALTER

SYSMGT ALTER

DB2MGMT ALTER

DB2 opens any data set with ACCESS(ALTER) unless APAR PM59420is applied. This APAR enables DB2 to open the data sets with a specified HLQ with ACCESS(RO).

Any update to a partition that resides in storage group SAPSTOGP will terminate with the following SQL error:

DSNT408I SQLCODE = -904, ERROR: UNSUCCESSFUL EXECUTION CAUSED BY AN

UNAVAILABLE RESOURCE. REASON 00C20106, TYPE OF RESOURCE 00000220, AND

RESOURCE NAME DB21X.DSNDBC.DSN04225.FBICFEJO.I0001.A002

In order to exploit the DFSMSdss fast replication feature, program ADRDSSU with option FASTREPLICATION(PREFERED) can be used. Here is an example of the according JCL job:

//DFDSSCP1 JOB (xxxxxxx),CH,NOTIFY=<user>,





//DFDSSCMD EXEC PGM=ADRDSSU PARM='TYPRUN=NORUN'


//SYSIN DD *


DB21.DSNDBC.DSN04225.FBICFEJO.J0001.A001 )) -

RENAMEU( -

(DB21.DSNDBC.DSN04225.FBICFEJO.J0001.A001 , -

DB21X.DSNDBC.DSN04225.FBICFEJO.J0001.A001 )) -

REPUNC ALLDATA(*) ALLEXCP CANCELERROR SHARE -

WRITECHECK TOLERATE(ENQF) VOLCOUNT(ANY) -

FASTREPLICATION(PREFERRED)

//*

If the copy runs successfully, the job output looks as follows:

ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'COPY ' ADR109I (R/I)-RI01 (01), 2012.002 17:15:04 INITIAL SCAN OF USER CONTROL STATEMENTS COMPLETED ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK ADR006I (001)-STEND(01), 2012.002 17:15:04 EXECUTION BEGINS ADR711I (001)-NEWDS(01), DATA SET DB21.DSNDBC.DSN04225.FBICFEJO.J0001.A001 HAS BEEN ALLOCATED WITH NEWNAME DB21X.DSNDBC.DSN04225.FBICFEJO.J0001.A004 USING STORCLAS SMS, DATACLAS XVSAMS, AND MGMTCLAS DB2 ADR806I (001)-T0MI (03), DATA SET DB21.DSNDBC.DSN04225.FBICFEJO.J0001.A001 COPIED USING A FAST REPLICATION FUNCTION ADR801I (001)-DDDS (01), 2012.002 17:15:05 DATA SET FILTERING IS COMPLETE. 1 OF 1 DATA SETS WERE SELECTED: 0 FAILED SERIALIZATION AND 0 FAILED FOR OTHER REASONS ADR454I (001)-DDDS (01), THE FOLLOWING DATA SETS WERE SUCCESSFULLY PROCESSED DB21.DSNDBC.DSN04225.FBICFEJO.J0001.A001 ADR006I (001)-STEND(02), 2012.002 17:15:05 EXECUTION ENDS



© 2012 SAP AG 137

ADR013I (001)-CLTSK(01), 2012.002 17:15:05 TASK COMPLETED WITH RETURN CODE 0000 ADR012I (SCH)-DSSU (01), 2012.002 17:15:05 DFSMSDSS PROCESSING COMPLETE. HIGHEST RETURN CODE IS 0000

After a RESTORE SYSTEM you need to perform the following additional task:

If the system is restored to a point in time prior to moving the partition out of the standard SMS storage group, steps 3 to 9 must be performed again.

If the system is restored to a point in time using a backup that has been taken after the partition has been moved, nothing needs to be done.

If the system is restored to a point in time after the partition has been moved using a backup that has been taken before that partition has been moved, the copied data set does not reside in the ICF catalog anymore. Therefore, you must re-catalog the data set.

If the system is completely recovered (from a disaster) using a backup that has been taken after the partition has been moved, the image copy taken in step 8 must be restored as well.

After a partition has been moved outside of the HSM copy pools by above described procedure, you cannot perform any update operation on that partition anymore, which is intended. This includes REORGs. You can however run the RUNSTATS utility on that partition. Also, adding a new column with default value as performed by the following statement is possible:

ALTER TABLE “/BIC/EJOCUBE” ADD COLUMN “NEW_KEYFIGURE” DECIMAL(17,2) NOT NULL WITH DEFAULT 0

Thus, structure changes of that table within the SAP data dictionary can be transported to the system.

In exceptional cases, there may be a need to update a partition that have been moved outside of the HSM copy pool, for example to delete the data. To allow update operation again, the partition needs to be moved back to the HSM copy pool. To achieve this, perform steps 4 to 9 above, but switch high level qualifies DB21 and DB21X appropriately and use storage group SYSDEFLT in step 6. After these steps have been finished, any update operation can be performed on the partition.

Refresh Development System from large SAP BW Productive System

It is good practice to keep a productive SAP system and the applicable development system alike. To achieve this, the development system is often refreshed on a regular basis. I.e. the productive system is cloned. However, cloning an entire productive SAP BW system regularly is usually not feasible due to its size. Also, storing the same data twice would cost a high amount of DASD resources. With the embedded nearline storage approach just described, it is possible to significantly reduce the size of a SAP BW clone. The idea is to reuse the data sets of the aged table partitions, which were moved outside of the HSM copy pools in the SAP BW source system, in the SAP BW target system. Therefore, they do not consume any additional space for the target system. This is possible because these data sets cannot be updated or changed from either the cloning source or target systems; the data is read-only. In the example above, this would result in additional savings of 60 TB. This approach is visualized in the following figure.

Once a partition has been taken out of the HSM copy pool as described under “Embedded Nearline Storage – Taking Aged Table Partitions out of HSM Copy Pool” on page 134, the underlying data set can be shared between two DB2 systems for read-only access. This way the data is stored only once and thus a lot of DASD space is saved. Furthermore, if one of these DB2 systems is refreshed from the other, the data sets do not need to be copied.



© 2012 SAP AG 138

This approach is followed in the example with table /BIC/EJOCUBE. The original table resides in DB2 system DB21. System DB21 is cloned to DB24 using DB2 Cloning Tool based on a system-level backup taken for DB21 before. The actual cloning procedure does not need to be changed. That way the data sets under the read-only VCAT are not copied to the clone target. The DB2 catalog for the target refers to the data sets under this VCAT. The only additional step necessary is to adapt the RACF configuration so that the user ID that is associated with the DB2 target system (in this case DB24USER) has READ privilege for the data sets under this VCAT.

DB2 10 SSID DB21: Production system

Copy pool

DSN$DDFDB21$LG

VCAT DB21L

sms storage

group DB2DJL

Copy pool

DSN$DDFDB21$DB

DB2 stogroup SYSDEFLT

VCAT DB21

sms storage

group DB2DJ

sms storage

group DB2DJ

Part 2 Part 3 ...

DB2 stogroup SAPSTOGP

VCAT DB21X

Part 1sms storage

group standard

sms storage

group standard

DB2 BACKUP SYSTEM

DB2 Catalog:Table INFO_CUBE1

(range-partitioned)

DB2 10 SSID DB24: Test system (SAPK, cloned from DB21)

Copy pool

DSN$DDFDB24$LG

VCAT DB24L

sms storage

group DB2CJL

Copy pool

DSN$DDFDB24$DB


VCAT DB24

sms storage

group DB2CJ

sms storage

group DB2CJ

Part 2 Part 3 ...


(range-partitioned)

read-only

DB2 Cloning Tool

DB2 10 SSID DB24: Test system (SAPK, cloned from DB21)

Copy pool

DSN$DDFDB24$LG

VCAT DB24L

sms storage

group DB2CJL

Copy pool

DSN$DDFDB24$DB


VCAT DB24

sms storage

group DB2CJ

sms storage

group DB2CJ

Part 2 Part 3 ...


(range-partitioned)

DB2 Cloning ToolStorage group DB2FJL

Type:

COPY POOL BACKUP

Storage group DB2FJ

Type:

COPY POOL BACKUP

Storage group DB2FJL

Type:

COPY POOL BACKUP

Storage group DB2FJ

Type:

COPY POOL BACKUP

Figure 27. Embedded Nearline Storage for SAP BW on DB2 for z/OS



© 2012 SAP AG 139

9. Online and Automated DB2 Subsystem Cloning

In SAP environments, it is a common and frequent task to clone entire database systems. The database clones are typically created as part of SAP homogeneous system copies. While the homogeneous system copy could be created using SAP import and SAP export methods to copy the data, they are usually created by cloning the entire database since this is a lot faster, especially for large systems. The homogeneous system copies serve different purposes like periodically refreshing a SAP test system from production or like creating a forensic analysis system for a SAP production system. The SAP Landscape Virtualization Manager can automate the SAP post-processing steps of the system copy, but it relies on database means for an efficient cloning of the database.

DB2 Cloning Tool 3.1 introduces a stored procedure called CLONE_SS that is intended to be a single-stop shop for the cloning of DB2 subsystems or DB2 data sharing groups. Since it is a stored procedure, it can be invoked from any application that can submit SQL statements. It provides a great level of flexibility regarding the following aspects of the cloning:

How data is copied o For example, using FlashCopy o If FlashCopy is used, source and target need to be in same storage box o Supports different storage providers: DS8000, EMC, HDS

How DB2 names from source system are adapted to target system o For example, WLM application environment names for DB2 stored procedures

How DB2 configuration for target system is changed o For example, from data sharing to single subsystem

Internally, the cloning stored procedure exploits the DB2 admin task scheduler, which was introduced as part of DB2 9 for z/OS. This standard component of the DB2 server needs to be activated in order for the stored procedure to work. The stored procedure supports the cloning of DB2 9 and DB2 10 subsystems. The following figure visualizes the overall picture of this approach. Be aware that the cloning stored procedure does not need to run in the DB2 subsystem that is the source of the cloning relationship. It can be executed in any DB2 subsystem that runs in the same Sysplex like the source and target systems.

Figure 28. Cloning in an IBM System z environment, using the DB2 Cloning Tool

IBM System z196

LPAR SAP1

Source

DB2 Subsystem

IBM System Storage DS8800

LPAR SAP2

Target

DB2 Subsystem

Source

Storage Groups

Backup Storage Groups

Target

Storage Groups

DB2 BACKUP SYSTEMDB2 Cloning Tool

- Copy Volumes

DB2 Admin

Scheduler and

DB2 Cloning Tool

stored procedure

DB2 Cloning Tool

- Rename data sets

- Update DB2 Catalog …



© 2012 SAP AG 140

The basic idea of the cloning stored procedure is to separate duties. In a joint effort of storage administrators, DB2 administrators and z/OS administrators, the cloning relationships are defined and set up. They know how to initially configure the environment. Once the initial preparation has completed, the SAP basis administrators can periodically trigger to clone a system. They know when it is time to refresh a clone.

Preparation to run the Cloning Stored Procedure

The following steps need to be taken to prepare the cloning of a DB2 subsystem via the stored procedure:

1. SMP/E installation of DB2 Cloning Tool

2. APF-authorization of DB2 Cloning Tool libraries

3. For DB2 subsystem in which cloning stored procedure is supposed to run:

a. Bind packages of DB2 Cloning Tool (job CKZDBIND)

b. Create stored procedure CLONE_SS (job CKZDEFSP)

c. If not done before - configure DB2 admin task scheduler i. Set up address space used by admin task scheduler (<SSID>ADMT) ii. Set DB2 ZPARM ADMTPROC iii. Run DB2 job to enable PassTickets for admin task scheduler (DSNTIJRA) iv. APF authorization for DSNADMT0

d. Grant required privileges for user ID calling stored procedure

EXECUTE privilege for CLONE_SS

EXECUTE privilege for SYSPROC.ADMIN_TASK_ADD

MONITOR1 privilege

4. For each DB2 source system:

a. Bind packages of DB2 Cloning Tool (job CKZDBIND)

5. For each DB2 target system:

a. Prepare disk configuration for DB2 target system

Set up SMS storage groups, data classes and management classes

Configure ACS routines

1. Define DB2 target system to z/OS

Define DB2 SSID [in our test system, in SYS1.PARMLIB(IEFSSNDB)]

Create started task JCL proclibs [in our test system, they are located in SYS4.PROCLIB.DB2]

b. Define ICF user catalogs for the data sets of the DB2 target system

c. WLM policies for DB2 target

d. RACF data set rules, TSO IDs and RACF secondary authorization group

e. Set up DSNZPARM files for DB2 target based on DSNZPARM from DB2 source

i. One ZPARM file for general use of DB2 target as copy of DSNZPARM from source

ii. One special ZPARM file for DB2 target as copy of DSNZPARM from source with a few changes_

1. Change macro DSN6SPRM from RESTART, ALL to DEFER, ALL 2. Change macro DSN6SPRC to &SPRMCTU SETC ’1’ to allow DB2 Catalog

updates



© 2012 SAP AG 141

3. Specify user ID used by CLONE_SS as install SYSADM (SYSADM or SYSADM2)

f. Grant required privileges to the user ID that will run the cloning steps:

Update privilege on z/OS ICF user catalogs for source & target

Install SYSADM for DB2 target

FlashCopy privileges (read access for RACF profiles STGADMIN.ANT.ESFC.**)

To control and configure the actual cloning processes, DB2 Cloning Tool provides you with three config files that are read by the cloning stored procedure. They control what it exactly does. These config files are as follows:

Product parameter file (PPARM)

DB2 system parameter file (SPARM)

Cloning parameter file (CPARM)

The product parameter file basically specifies the libraries of the DB2 Cloning Tool that should be used. The DB2 system parameter file specifies details about the DB2 source and target systems like SDSNLOAD library, LPAR on which they are running and DDF ports. The cloning parameter file allows you to control how the cloning task is accomplished. For example, you can configure the user ID under which the JCL jobs are executed that are generated by the cloning stored procedure. Also you can control the way the data is copied from DB2 source to target and whether a system-level backup of the DB2 source is used as source for the cloning task. These files will be discussed in more details in the following sections that describe different cloning scenarios.

When the cloning stored procedure runs to create the DB2 cloning target, you can monitor the progress by either going to SD;ST in TSO to see the status of the generated JCL jobs. Alternatively, you can submit the following SQL query on the DB2 subsystem on which the stored procedure runs. The following example shows you the status when the stored procedure has completed running. You can execute this query in SPUFI, for example

select * from table (dsnadm.admin_task_status()) as T;

---------+---------+---------+-----------+---------+---------+---------+---------+---------+-

TASK_NAME STATUS NUM_INVOCATIONS START_TIMESTAMP MAXRC

---------+---------+---------+-----------+---------+---------+---------+---------+---------+-

SCHUETZ_CLONE1_ST001 ---------- --------------- ---------------------

SCHUETZ_CLONE1_ST002 ---------- --------------- ---------------------

SCHUETZ_CLONE1_ST003 COMPLETED 1 2011-11-01-15.36.31.0 0

















© 2012 SAP AG 142

ABAP Sample Program to invoke the Cloning Tool Stored Procedure

The following ABAP report is an example how you may invoke the cloning stored procedure. As you can see, it mainly consists of the call of the stored procedure. Depending on whether you would like to prepare the cloning process or whether you actually would like to accomplish the cloning, you can specify a different parameter for the input parameter TYPE_INPUT. To initially generate the JCL jobs and to add them to the DB2 admin task scheduler, call the stored procedure with input parameter TYPE_INPUT = BUILD. You can then review the JCL jobs and also adapt them if you would like. When you then invoke the stored procedure with TYPE_INPUT = CLONE, the previously generated JCL jobs are executed in the right sequence by the admin task scheduler. If everything runs smoothly, the stored procedure returns with RC = 0. If not, RC 4 or 8 is returned along with an error message that hints at the issue preventing success.

REPORT ZJS_CALL_CLONE_SS. data: sp_exists type i, sp_name(30) type c, message_txt(160) type c, ret_code(8) type c, split_rest(1024) type c, returncode type i, outmessage(1331) type c, ind0 type int2, ind1 type int2, ind2 type int2, ind3 type int2, ind4 type int2, ind5 type int2, ind6 type int2, ind7 type int2, ind8 type int2, sql_stmt type string, result_ref type ref to data, sqlerr_ref type ref to cx_sy_native_sql_error, type_input(10) type c value 'CLONE', pparmdsn(44) type c value 'WIETZ.JCL.PDS', pparmmem(8) type c value 'CKZPPARM', sparmdsn(44) type c value 'WIETZ.JCL.PDS', sparmmem(8) type c value 'DB2SYS', cparmdsn(44) type c value 'WIETZ.JCL.PDS', cparmmem(8) type c value 'CKZCPARM'. *Documentation for Cloning Tool TYPE parameters: *The TYPE parameter identifies what function the stored procedure is to perform: *BUILD Builds JCL jobs and adds tasks to the DB2 administrative task scheduler *BUILDJCL Builds JCL jobs *CLONE Runs the initial cloning *RECLONE Stops the target DB2 systems, runs BCSCLEAN to clean up from a previous * cloning and then runs the cloning *REMOVE Deletes all JCL and removes tasks from the DB2 administrative task scheduler *CLEAN Stops the target DB2 systems and runs BCSCLEAN * Initialize returncode = 9900. * Check if CLONE_SS exists sp_name = 'CLONE_SS'."#EC NOTEXT perform check_stoproc_exists using sp_name changing sp_exists outmessage. if sp_exists = 0. raise DSNACCSI_NOT_INSTALLED. endif. COMMIT WORK. write : / 'Calling CKZTOOLS.CLONE_SS...'. try. EXEC SQL.



© 2012 SAP AG 143

EXECUTE PROCEDURE CKZ.CLONE_SS (IN :TYPE_INPUT :ind0, IN :PPARMDSN :ind1, IN :PPARMMEM :ind2, IN :SPARMDSN :ind3, IN :SPARMMEM :ind4, IN :CPARMDSN :ind5, IN :CPARMMEM :ind6, OUT :returncode :ind7, OUT :outmessage :ind8) ENDEXEC. IF sy-subrc = 0. write : / 'CKZTOOLS.CLONE_SS called successfully'. write: / returncode. write: / outmessage. else. write : / 'Error calling CKZTOOLS.CLONE_SS...'. write: / sy-subrc. ENDIF. catch CX_SY_NATIVE_SQL_ERROR into sqlerr_ref. * Entries to system log (SM21) already written: just leave ROLLBACK WORK. raise SQL_ERROR. endtry. COMMIT WORK. FORM check_stoproc_exists USING value(sp_name) TYPE c CHANGING sp_exists TYPE i message_text TYPE c. DATA: stoproc_occur TYPE i. EXEC SQL. SELECT COUNT(specificname) INTO :stoproc_occur from sysibm.sysroutines where name = :sp_name and routinetype = 'P' ENDEXEC. IF stoproc_occur = 0. message_text = 'Stored procedure #1 does not exist.'(002). REPLACE '#1' WITH sp_name INTO message_text. CALL FUNCTION 'RSLG_WRITE_SYSLOG_ENTRY' EXPORTING sl_message_area = 'D3' sl_message_subid = '2' pre_param_long = message_text. sp_exists = 0. ELSE. sp_exists = 1. ENDIF. ENDFORM. "check_stoproc_exists

Use Case: DB2 Subsystem Cloning Based on a Previously Taken System-Level Backup

In this use case, the idea is to use a previously taken system-level backup as source for the cloning process. Since this kind of backup is taken in an online fashion by the BACKUP SYSTEM utility, the cloning process has no impact on the DB2 source system and is therefore also an online operation. To simplify the creation



© 2012 SAP AG 144

of the DB2 Cloning Tool JCL jobs, we use the cloning stored procedure to generate and run these jobs. As an alternative, these jobs can also be configured manually if preferred.

In the following example, the following steps were taken:

Invoked BACKUP SYSTEM FULL in DB2 subsystem DB21, which completed with RC=0

Invoked the Cloning Tool stored procedure CLONE_SS specifying the last system-level backup of DB21 as source for the cloning

The Cloning Tool then copies the volumes of the backup storage groups of DB21 to the volumes of the DB2 subsystem DB24 using FlashCopy

The Cloning Tool renames the data sets of DB21 and changes the HLQ from DB21 to DB24. It also takes care of updating VTOC and VVDS.

Then the Cloning Tool updates the catalog and directory of DB24.

Parameter files for cloning stored procedure CLONE_SS:

The three config files that control the cloning stored procedure are as follows in this use case:

Product parameter file (PPARM) - CKZPPARM o WIETZ.JCL.PDS(CKZPPARM)

DB2 system parameter file (SPARM) - CKZSPARM o WIETZ.JCL.PDS(DB2SYS) for Source DB21 – Target DB24

Cloning parameter file (CPARM) CKZCPARM o WIETZ.JCL.PDS (CKZCPARM) for Source DB21 – Target DB24

There should be no need to change the product parameter file frequently as it basically specifies some library name of the DB2 Cloning Tool. The following values were specified:

* EXAMPLE OF THE SUBSYSTEM CLONING STORED PROCEDURE PRODUCT

* PARAMETER FILE

CKZINI = SYS1.DB2CT.V310.SCKZPARM(CKZINI#)

SCKZLOAD = SYS1.DB2CT.V310.SCKZLOAD

SCKZPARM = SYS1.DB2CT.V310.SCKZPARM

Figure 29. Product parameter file WIETZ.JCL.PDS(CKZPPARM)

In the following cloning parameter file, you can see how we configured the cloning process. Some data set names were specified that are used to internally store the JCL jobs and related information. As user ID for the cloning steps, WIETZ is specified (note that the password is anonymized here). The job card for the JCL jobs to be generated is specified in the lines JOBCARD1 and JOBCARD2. Since the goal is to use an existing system-level backup as source for the cloning, the keyword DB2SLB is specified for the parameter SOURCE-VOLUMES. Using the parameter SOURCE-TOKEN, it is possible to indicate the backup generation that should be used as source for the cloning. This option can be important if more than one backup version is kept in the HSM copy pool backup storage group on DASD. In this case here, the keyword LAST is specified to indicate the use of the latest system-level backup. Under parameter TO-STORAGEGROUP, the storage groups that should be used for the DB2 target system are specified. The source and target user catalogs are specified in parameter USERCATALOGS. In the next section of the config file, you can control how the data sets are mapped from source to target. Since we do not want the user catalog data sets from the source to intervene in the target system, we map them to HLQ GARBAGE. Specifying RECATALOG = Y has shown to work well in our environment. Finally, the DB2 source and target SSID and HLQ pairs and the mapping of the WLM application environments for DB2 stored procedures are specified.



© 2012 SAP AG 145

* EXAMPLE OF THE SUBSYSTEM CLONING STORED PROCEDURE CLONING

* PARAMETER FILE - NON DS TO NON DS - DB21 - DB24

JCL-DSN = WIETZ.CLONE1.JCL

STATUS-DSN = WIETZ.CLONE1.STATUS

WORK-PREFIX = WIETZ.CLONE1.WRK

TASK-PREFIX = WIETZ_CLONE1

CLONING-TYPE = ONLINE

USERID = WIETZ

PASSWORD = xxxxxxx

*

JOBCARD1 = //CKZCLON1 JOB ,'CKZ CLONING 1',CLASS=B,MSGCLASS=X,

JOBCARD2 = // NOTIFY=&SYSUID

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

* COPY PARAMETERS FOR CLONING DB21 TO DB24

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

SOURCE-VOLUMES = DB2SLB

SOURCE-TOKEN = LAST

SOURCE-LOCATION = DDFDB21

TO-STORAGEGROUP = DB2CJ DB2CJL

USERCATALOGS = SYS1.USERCAT.DB21 SYS1.USERCAT.DB24

SYS1.USERCAT.DB21L SYS1.USERCAT.DB24L

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

* RENAME PARAMETERS FOR CLONING DB21 TO DB24

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

RENAME-MASKS = DB21.** DB24.**

DB21L.** DB24L.**

SYS1.USERCAT.** GARBAGE.**

RECATALOG = Y

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

* DB2 PARAMETERS FOR CLONING SUBSYSTEM DB21 TO DB24

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

DB2-SUBSYSTEM-PAIR = DB21 DB24

DB2-HLQS = DB21 DB24

LISTSQL = Y

WLM-ENVIRONMENT-MASKS = DB21* DB24*

Figure 30. Cloning parameter file WIETZ.JCL.PDS (CKZCPARM)

As a variation, if you would like to use another system-level backup as source for the cloning (and not the last one), then you can specify the token of that backup for the SOURCE-TOKEN parameter. To give you an idea, please consider the following sample output of the list copypool command for DB2 subsystem DB21:

hsend list copypool(dsn$ddfdb21$lg) term


VER=035,VTOCENQ=N,MADE ON 2011/12/01 AT 12:58:39,FRS=RECOVERABLE ,DPS=NONE

TKN(H)=X'C4C2F2F1C8C16D9A160F5A89000F18888DDC'

If this is the backup that should be the source of the cloning process, then specify the following value for SOURCE-TOKEN:

SOURCE-TOKEN = X'C4C2F2F1C8C16D9A160F5A89000F18888DDC'



© 2012 SAP AG 146

In the following DB2 system parameter file, configuration details of the DB2 source and target systems are specified like the z/OS LPAR in which they are running. For the DB2 target system, a number of parameters need to be set like SDSNLOAD and SDSNEXIT, the BSDS data sets and the DDF port. For the DB2 target system, you need to specify the previously prepared normal and special ZPARM files.

* PARAMETER FILE

* CONTAINING ALL RELEVANT DB2 SUBSYSTEMS

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

* SOURCE DB2 DB21 (NON DATA SHARING)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

SSID = DB21

SDSNLOAD = DB21L.V100.SDSNLOAD

EXEC-SYSTEM = SAPK

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

* TARGET DB2 DB24 (NON DATA SHARING)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

SSID = DB24


SDSNEXIT = DB24L.V100.SDSNEXIT

BSDS01 = DB24L.BSDS01

BSDS02 = DB24L.BSDS02

SYSVCAT = DB24

SPECIAL-DSNZPARM = DSNZPARN

NORMAL-DSNZPARM = DB24PARM

EXEC-SYSTEM = SAPK

DDF-IPV4 = 192.168.216.30

DDF-LOCATION = DDFDB24

DDF-LUNAME = SAPDB24

DDF-PORT = 9727

DDF-RESPORT = 9728

Figure 31. DB2 system parameter file WIETZ.JCL.PDS (DB2SYS))

Cloning JCL jobs generated by the cloning stored procedure

The following list of JCL job extracts is intended to give you an idea about how the jobs generated by the cloning stored procedure look like. If you are familiar with the DB2 Cloning Tool you will probably recognize them.

DB2STOP

This job stops the DB2 target system if it already exists and still running.

----------------------------------------------

BROWSE WIETZ.CLONE1.JCL(ST001)

//CKZIN DD *

DB2STOP -

DB2-ALREADY-STOPPED(RC(0)) -

DB2-SSID(DB24)

//*



© 2012 SAP AG 147

BCSCLEAN

This job cleans up the internal journal of the Cloning Tool, which is used to pass configuration information from one cloning job to another.

-----------------------------------------------


//CKZIN DD *

BCSCLEAN -

JOURNAL-DDN(JOURNAL)

//*

DB2GETBACKINFO

This job determines the latest system-backup level that is available.

-------------------------------------------------


//CKZIN DD *

DB2GETBACKINFO -

LAST -

LOCATION(DDFDB21 ) -

USERCATALOGS( -

SYS1.USERCAT.DB21 SYS1.USERCAT.DB21L -

) -

BACKINFO-DDN(BACKINFO) -

WORK-DDN(HSMLIST)

//*

BACKINFO-REFORMAT

This job reformats the backup information and prepares the copying of the volumes from source to target.

--------------------------------------------------


// SPACE=(CYL,(1,1))

//CKZIN DD *

BACKINFO-REFORMAT -


VOLPAIRS-DDN(VOLPAIRS) -

FROM-VOLSER-DDN(FRVOLSER) -

USERCATALOGS( -

SYS1.USERCAT.DB21 SYS1.USERCAT.DB24 -

SYS1.USERCAT.DB21L SYS1.USERCAT.DB24L -

) -

USERCATALOGS-DDN(UCATS)

//*

COPY

The following jobs actually copy the volumes from source to target

----------------------------------------------------


//CKZIN DD *

COPY -

DATA-MOVER(PGM(NONE)) -




© 2012 SAP AG 148

USERCATALOGS-DDN(UCATS) -

CATWORK-DSN(WIETZ.CLONE1.WRK.*) -


//*

-----------------------------------------------


//CKZIN DD *

COPY -


TO-STORAGEGROUP( -

DB2CJ DB2CJL -

) -

NOUSERCATALOGS -


//*

VOLOPTIONS and RENAME

These jobs deal with renaming the data sets to the new HLQ. They are then recataloged in the ICF catalogs of the target system.

-------------------------------------------------------------

BROWSE WIETZ.CLONE1.JCL(ST007) Line 000

//SYSIN DD *

DEL WIETZ.CLONE1.WRK.NEWTGTS

SET MAXCC=0

//REXXNTGT EXEC PGM=IRXJCL,REGION=2M,PARM='CKZRNTGT'

//SYSEXEC DD DISP=SHR,DSN=SYS1.SCKZPARM

//SYSTSIN DD DUMMY

//SYSTSPRT DD DUMMY

//SYSPRINT DD SYSOUT=*,DCB=(LRECL=132,RECFM=VBA,BLKSIZE=0)

//CKZIN DD DISP=SHR,DSN=WIETZ.CLONE1.WRK.VOLPLIST

//NUCIN DD DISP=SHR,DSN=WIETZ.CLONE1.WRK.NUC.VOLPLIST

//NEWTGT DD DSN=WIETZ.CLONE1.WRK.NEWTGTS,

// DISP=(,CATLG),UNIT=SYSALLDA,

// DSORG=PS,RECFM=FB,LRECL=80,BLKSIZE=0,


//*

----------------------------------------------


//CKZIN DD *

VOLOPTIONS UPDATE -

NEWTARGETS-DDN(NEWTGTS) -


//*

-----------------------------------------


//CKZIN DD *

RENAME -



© 2012 SAP AG 149

SAFE -

VOLBKUP-DDN(VOLBKUP) -

RENAME-MASKS( -

DB21.** DB24.** -

DB21L.** DB24L.** -

SYS1.USERCAT.** GARBAGE.** -

) -

RECATALOG(Y) -


//*

******************************** Bottom of Data ***

DB2UPDATE, DB2ALTERBSDS and DB2FIX

The following jobs update the BSDS data sets and catalog and directory of the DB2 target. The parameter SLB-START in start 11 results in a conditional restart to be performed for the DB2 target system.

---------------------------------------------------


//CKZIN DD *

DB2UPDATE -

DB2-NAME(S001) -

DB2-HLQS( -

DB21 DB24 -

) -

DDF( -

IPV4(192.168.216.30) -

LOCATION(DDFDB24) -

PORT(9727) -

RESPORT(9728) -

) -

HLQ-NOT-UPDATED(RC(22)) -


//*

---------------------------------------


//CKZIN DD *

DB2ALTERBSDS -

DB2-NAME(S001) -

SLB-START -


//*


//CKZIN DD *

DB2FIX -

DB2-SSID(DB24) -

DSNDB01-DBD01-STARTED( RC(5)) -

MEMBERS-AND-DBD01(RC(21)) -

MEMBERS-NEED-STARTING(RC(22)) -

WAIT-AND-DBD01( RC(23)) -

WAIT( 5, RC(24)) -

DATABASES(DB2)



© 2012 SAP AG 150

//*

//IF1 IF (DB2FIXDB.RC EQ 5 ) THEN

.

.

.

//CKZIN DD *

DB2STOP -

DB2-SSID(DB24)

//*

//IF2 IF (DB2STOP.RC LE 4 ) THEN

.

.

.

//CKZIN DD *

DB2UPDATE -

DBD01ONLY -

DB2-NAME(S001) -

DB2-HLQS( -

DB21 DB24 -

) -

DDF( -

IPV4(192.168.216.30) -

LOCATION(DDFDB24) -

PORT(9727) -

RESPORT(9728) -

) -



//*

//IF3 IF (DB2UPDD.RC LE 4 ) THEN

.

.

.

//CKZIN DD *

DB2START -

DB2-SSID(DB24) -

DSNZPARM(DSNZPARN) -

REPLY-TO-RESTART-WTOR(Y) -

SPECIAL

//*

//IF3 ENDIF

//IF2 ENDIF

//IF1 ENDIF

DB2SQL, DB2FIX, DB2STOP, DB2START

The following jobs finally adapt the WLM application environment names and start up the DB2 target system.

-----------------------------------------------


//CKZIN DD *

DB2SQL -

DB2-NAME(S001) -

DB2-SSID(DB24) -



© 2012 SAP AG 151

LISTSQL(Y) -

WLM-ENVIRONMENT-MASKS( -

DB21* DB24* -

) -


//*

-----------------------------------------------


//CKZIN DD *

DB2FIX -

DB2-SSID(DB24) -

MEMBERS-NEED-STARTING( RC(22)) -

WAIT( 5, RC(24)) -

DATABASES(APPLICATION)

//*

------------------------------------------------


//CKZIN DD *

DB2STOP -

DB2-SSID(DB24)

//*

-----------------------------------------------


//CKZIN DD *

DB2START -

DB2-SSID(DB24) -

DSNZPARM(DB24PARM) -

NORMAL

//*

Troubleshooting

The following information may help you with troubleshooting if certain conditions are met.

APF authorization missing

In step 12 of the cloning process, you may receive an IRLM abend if some DB2 target libraries are not APF-authorized. The abend looks as follows:

SAPK 11313 15:10:34.44 STC07077 00000090 IEF450I DB24IRLM DB24IRLM - ABEND=S047 U0000

REASON=00000000 128

128 00000090 TIME=15.10.34

SDSF STATUS DISPLAY ALL CLASSES LINE 1-1 (1)


NP JOBNAME JobID Owner Prty Queue C Pos SAff ASys Status

DB24IRLM STC06953 DB24USER 1 PRINT 552

In DB24IRLM:

14.57.00 STC06953 IEF695I START DB24IRLM WITH JOBNAME DB24IRLM IS ASSIGNED TO USER

DB24USER, GROUP STCGROUP

14.57.00 STC06953 $HASP373 DB24IRLM STARTED

14.57.00 STC06953 IEF403I DB24IRLM - STARTED - TIME=14.57.00



© 2012 SAP AG 152

14.57.00 STC06953 IEF188I PROBLEM PROGRAM ATTRIBUTES ASSIGNED

14.57.00 STC06953 IEA995I SYMPTOM DUMP OUTPUT 994

994 SYSTEM COMPLETION CODE=047

994 TIME=14.57.00 SEQ=22363 CPU=0000 ASID=0154

994 PSW AT TIME OF ERROR 078D1000 80007232 ILC 2 INTC 6B

994 ACTIVE LOAD MODULE ADDRESS=000071D0 OFFSET=00000062

994 NAME=DXRRLM00

994 DATA AT PSW 0000722C - 58101000 0A6BEB0F C6D80096

994 GR 0: FD00002B 1: 0000000C

994 2: 00000040 3: 008E8AD4

994 4: 00000000 5: 008FF890

994 6: 008D2FC8 7: FD000000

994 8: 008FC130 9: 008E3CB0

994 A: 00000000 B: 008FF890

994 C: 000083B8 D: 000083D4

994 E: 000083D4 F: 800071D0

994 END OF SYMPTOM DUMP

14.57.00 STC06953 IEF450I DB24IRLM DB24IRLM - ABEND=S047 U0000 REASON=00000000 995

IGD104I DB24L.V100.SDXRRESL RETAINED, DDNAME=STEPLIB

IEF373I STEP/ /START 2011313.1457

IEF032I STEP/ /STOP 2011313.1457

CPU: 0 HR 00 MIN 00.05 SEC SRB: 0 HR 00 MIN 00.00 SEC

VIRT: 60K SYS: 204K EXT: 4K SYS: 9632K

IEF375I JOB/DB24IRLM/START 2011313.1457

IEF033I JOB/DB24IRLM/STOP 2011313.1457


- DB24IRLM X 1 1s 00 0768K

m STARTING DB24IRLM

m DB24IRLM PROC

, m DXRRLM00: STARTINGb 15 15k ID24 1 LOCAL 5 1 0 YES 7 NO YES

0i 0K 4096Ml 0360 00

> STEPLIBÄ DB24L.V100.SDXRRESL SHR

IGD104I DB24L.V100.SDXRRESL RETAINED, DDNAME=STEPLIB

IEF373I STEP/ /START 2011313.1457

IEF032I STEP/ /STOP 2011313.1457


VIRT: 60K SYS: 204K EXT: 4K SYS: 9632K

IEF375I JOB/DB24IRLM/START 2011313.1457

IEF033I JOB/DB24IRLM/STOP 2011313.1457


- DB24IRLM X 1 1s 00 0768K

m STARTING DB24IRLM

m DB24IRLM PROC

, m DXRRLM00: STARTINGb 15 15k ID24 1 LOCAL 5 1 0 YES 7 NO YES

0i 0K 4096Ml 0360 00

> STEPLIBÄ DB24L.V100.SDXRRESL SHR

Step 5 of the cloning process: Copy job ‘hangs’

If the copy job does not complete, try to recycle HSM. Look at available messages before the stop. Then issue the following commands to recycle HSM:

/p HSM

/s HSM



© 2012 SAP AG 153

Use Case: DB2 Subsystem Cloning using FlashCopy Consistency Group

In the previous use case, an existing system-level backup is used as the source as input to the cloning stored procedure. Since the BACKUP SYSTEM utility operates in an online fashion, this means that this cloning approach is non-disruptive to the DB2 source system. However, DS8000 does not support cascading FlashCopy relationships of a volume. This means that a given volume cannot be the target of a FlashCopy relationship and at the same time the source of another FlashCopy relationship. Therefore, if you use FlashCopy for the copy step of the cloning tool, this step can only start working when the physical background copy of the FlashCopy task that was initiated by the DB2 BACKUP SYSTEM utility has completed. Depending on the size of the DB2 system, this may take some time. If you have a need to have a very fast online clone of your DB2 source system, one option is to use incremental FlashCopy for the system-level backups of this system. If there is a reason not to exploit incremental FlashCopy, another option is to exploit FlashCopy Consistency Group. As described under FlashCopy Consistency Groups on page 21 in this book, every volume that is part of such a group is suspended. Since this is happening at disk level, this is a very fast process though and may be in the range of 2 msec per volume. When all the volumes of the group are suspended, then the suspension can be released.

The DB2 Cloning Tool and the cloning stored procedure support the use of FlashCopy Consistency Group for the cloning process. If this option is selected, then the SET LOG SUSPEND command of DB2 is not issued. To make sure that the volumes of the Consistency Group have successfully been suspended establishing a consistent point, the FCCGVERIFY option of the FlashCopy command can be used. If the consistency cannot be ensured, then ADRDSSU returns an error code because the CGCREATE option of FlashCopy to create the Consistency Group fails. If this happens, this return code of ADRDSSU to Cloning Tool should cause this step of the cloning process to fail, which stops the cloning process. This is the default way the cloning stored procedure is working. It can be configured in the CKZINI data set of the Cloning Tool for the COPY jobs (field MAX_RC in the :DSN_PRODUCT_PERF section).

Cloning config files for cloning stored procedure CLONE_SS:

The only different cloning config file compared to the previous use case is the cloning parameter file (CKZCPARM). This file is described in more detail below. The two other config files (product parameter file and DB2 system parameter file) are identical.

Cloning parameter file (CPARM) CKZCPARM

The following cloning parameter file is very similar to the corresponding file of the previous use case. However, DM-CONSISTENT = Y is specified this time, which cause the cloning stored procedure to copy the volumes from DB2 source to DB2 target using FlashCopy Consistency Group. As data-moving program, ADRDSSU is specified for the DM-PGM parameter. Another interesting parameter, which is independent of the copy method, is MAX-TASKS = 10. This parameter controls the number of parallel jobs that rename the data sets. Since this step usually takes the most time of the cloning steps, it can make sense to accomplish this task using parallel tasks.

********************************* Top of Data *******************

* SUBSYSTEM CLONING STORED PROCEDURE CLONING

* PARAMETER FILE





CLONING-TYPE = ONLINE *

USERID = WIETZ

PASSWORD = xxxxxxxx



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

* COPY PARAMETERS FOR CLONING DB21 TO DB24

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



© 2012 SAP AG 154

FROM-STORAGEGROUP = DB2DG DB2DGL

SOURCE-LOCATION = DDFDB21

TO-STORAGEGROUP = DB2CJ DB2CJL



DM-PGM = ADRDSSU

DM-CHECKVTOC = Y

DM-CONSISTENT = Y

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

RENAME-MASKS = DB21.** DB24.**

DB21L.** DB24L.**


MAX-TASKS = 10

RECATALOG = Y

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

* DB2 PARAMETERS FOR CLONING SUBSYSTEM DB21 TO DB24

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

DB2-SUBSYSTEM-PAIR = DB21 DB24

DB2-HLQS = DB21 DB24

LISTSQL = Y


Figure 32. Cloning parameter file WIETZ.JCL.PDS(CKZCPAR2)

Generated Jobs

The JCL jobs that the cloning stored procedure generates for this use case are very similar to the previous use case. Therefore, they should not all be repeated here again. We would like to highlight the main differences only. The major differences are in the following jobs:

COPY

For the COPY job, which is the third step of the cloning process, you can see that ADRDSSU is specified as data mover program and that the CONSISTENT(YES) option is specified. This results in FlashCopy Consistency Group to be invoked.

//CKZIN DD *

COPY -

DATA-MOVER( -

PGM(ADRDSSU) -

CHECKVTOC -

CONSISTENT(YES) -

FASTREP(REQ) -

) -

FROM-STORAGEGROUP( -

DB2DG DB2DGL -

) -

TO-STORAGEGROUP( -

DB2CJ DB2CJL -

) -

USERCATALOGS( -



) -



© 2012 SAP AG 155



//*

RENAME

Note the parameter MAX-TASKS(10) for this step, which results in 10 parallel tasks to be spawned to minimize the elapsed time for the renaming of the DB2 data sets.

//CKZIN DD *

RENAME -

SAFE -


RENAME-MASKS( -

DB21.** DB24.** -

DB21L.** DB24L.** -


) -

MAX-TASKS(10) -

RECATALOG(Y) -


//*

Troubleshooting

If it is not possible for ADRDSSU to invoke FlashCopy and when you still want to create a consistency group, then the volumes would be copied the traditional way. The consistency group timer can then be hit when it expires. If you run into this situation, you would see a job output along the following lines:

CKZ03001I 10.22.36 COPY STARTED - PROGRAM REV=30

CKZ03003I DDNAME=SYS00020 ALLOCATED FOR DSN=**TEMPORARY DSSIN DSN

CKZ03003I DDNAME=SYS00021 ALLOCATED FOR DSN=**TEMPORARY DSSOUT DSN

PAGE 0001 5695-DF175 DFSMSDSS V1R12.0 DATA SET SERVICES 2011.319 10:22

CGCREATE FCCGVFY(SAPDGL) ACCVOL( -

SAPDGL -

)

ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'CGCREATE '

ADR109I (R/I)-RI01 (01), 2011.319 10:22:36 INITIAL SCAN OF USER CONTROL STATEMENTS

COMPLETED

ADR050I (001)-PRIME(01), DFSMSDSS INVOKED VIA APPLICATION INTERFACE

ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK

ADR006I (001)-STEND(01), 2011.319 10:22:36 EXECUTION BEGINS

ADR837E (001)-CGCR (01), FLASHCOPY CONSISTENCY GROUP TIMER HAS EXPIRED FOR LSS WHERE

VOLUME SAPDGL RESIDES

ADR840W (001)-CGCR (01), CGCREATE PROCESSING COMPLETED. I/O ACTIVITY HAS RESUMED ON

THE FOLLOWING SPECIFIED VOLUMES

AND OTHER PREVIOUSLY FROZEN VOLUMES IN THE SAME LOGICAL

SUBSYSTEM

SAPDGL

ADR006I (001)-STEND(02), 2011.319 10:22:36 EXECUTION ENDS

ADR013I (001)-CLTSK(01), 2011.319 10:22:36 TASK COMPLETED WITH RETURN CODE 0008

ADR012I (SCH)-DSSU (01), 2011.319 10:22:36 DFSMSDSS PROCESSING COMPLETE. HIGHEST

RETURN CODE IS 0008 FROM:

TASK 001

CKZ03021E ADRDSSU COPY FAILED; R15:0008

CKZ03001I 10.22.36 COPY COMPLETED; RETURN CODE=8



© 2012 SAP AG 156

To prevent running into this issue, ensure that the invocation of ADRDSSU COPY fails if FlashCopy cannot be used.

Use Case: DB2 Subsystem Cloning based on a System-Level Backup on Tape

In this use case, a DB2 system-level backup that has been offloaded to tape should be used as the source for the cloning process. As a precursor to the actual cloning steps performed by the cloning stored

procedure, some additional steps are required to restore a backup from tape for cloning purposes. These steps are described in the following section.

Restore system-level backup on tape to other volumes on disk

Determine tape volumes and data sets of DB2 backup

Using HSM list copypool commands, you can determine the tape volumes and data sets of the DB2 backup. This command needs to be issued for both the $DB and $LG copy pools.

hsend list copypool(dsn$ddfdb21$db) dumpvols

-- DFSMShsm CONTROL DATASET --COPY POOL--LISTING --------- AT 15:54:58 ON 11/11/24





TOKEN(C)=C'DB21H u = h '

TOKEN(H)=X'C4C2F2F1C8B00A2214A4BA8B000D7E438832'





NO NONE ********* ****************************************


SAPDG1 WA1270 3490

FILE SEQ=00, DSNAME=SAP.DMP.DB2DP03M.VSAPDG1.D11321.T360217

SAPDG2 WA0909 3490


SAPDG3 WA0861 3490


hsend list copypool(dsn$ddfdb21$lg) dumpvols

-- DFSMShsm CONTROL DATASET --COPY POOL--LISTING --------- AT 15:57:29 ON 11/11/24





TOKEN(C)=C'DB21H u = h '

TOKEN(H)=X'C4C2F2F1C8B00A2214A4BA8B000D7E438832'





© 2012 SAP AG 157



NO NONE ********* *****************************************


SAPDGL WA3602 3490


Use IDCAMS to catalog tape data sets for the dump

To prepare a clean restore from dump, it is recommended to catalog the tape data sets using IDCAMS.

//RENAVSAM EXEC PGM=IDCAMS,REGION=500K


//SYSIN DD *

DEF NVSAM(NAME('SAP.DMP.DB2DP03M.VSAPDG1.D11321.T360217') -

VOL(WA1270) -

DEVT(3490))


VOL(WA0909) -

DEVT(3490))


VOL(WA0861) -

DEVT(3490))

DEF NVSAM(NAME('SAP.DMP.DB2DP03M.VSAPDGL.D11321.T060317') -

VOL(WA3602) -

DEVT(3490))

/*

List data sets for validation

In TSO, you can go to 3.4 to check whether the tape data sets have successfully been cataloged.

DSLIST - Data Sets Matching SAP.DMP.DB2DP03M.VSAPDG3*

Command - Enter "/" to select action

----------------------------------------------------------

SAP.DMP.DB2DP03M.VSAPDGL.D11321.T060317

SAP.DMP.DB2DP03M.VSAPDG1.D11321.T360217



Use ADRDSSU to restore tape volumes to specified disk volumes

Using ADRDSSU, you can restore the tape data sets to other volumes on disk. This way there is no impact on the volumes of the DB2 source system, which in turn means that the cloning from tape is an online operation as well. The following jobs restore the volumes from disk directly onto the volumes that are intended for the DB2 target system of the cloning relationship.

//STEP1 EXEC PGM=ADRDSSU


//TAPE1 DD DSN=SAP.DMP.DB2DP03M.VSAPDG1.D11321.T360217,

// DISP=(OLD,KEEP)



© 2012 SAP AG 158


// DISP=(OLD,KEEP)


// DISP=(OLD,KEEP)

//TAPE4 DD DSN=SAP.DMP.DB2DP03M.VSAPDGL.D11321.T060317,

// DISP=(OLD,KEEP)

//SYSIN DD *

RESTORE FULL -

INDDNAME (TAPE1) -

OUTDYNAM (SAPCJ1) -

COPYVOLID -

PURGE -

ADMIN

RESTORE FULL -

INDDNAME (TAPE2) -

OUTDYNAM (SAPCJ2) -

COPYVOLID -

PURGE -

ADMIN

RESTORE FULL -

INDDNAME (TAPE3) -

OUTDYNAM (SAPCJ3) -

COPYVOLID -

PURGE -

ADMIN

RESTORE FULL -

INDDNAME (TAPE4) -

OUTDYNAM (SAPCJL) -

COPYVOLID -

PURGE -

ADMIN

/*

RACF authorization required During the restore of the DSN$<location_name>$DB copy pool, the ICF catalog for the data sets in the copy pool is on one of the copy pool volumes. Without the right authorization, access checking to the data sets and ICF catalog takes place, causing the ICF catalog to be re-allocated prior to restoring the volume on which it resides. This causes the restore for the volume containing the ICF catalog to fail. Therefore, it is suggested setting up DASDVOL in the following way to bypass the issue without giving an undue level of access to all datasets. Any user ID that has the OPERATIONS attribute will inherit DASDVOL authority. The following RACF commands should be issued:

SETROPTS GENERIC(DASDVOL)

REDEFINE DASDVOL * UACC(ALTER)

SETROPTS CLASSACT(DASDVOL)

SETROPTS GENERIC(DASDVOL) REFRESH

Create Cloning Tool journal and reclip target volumes

Since we already restored the volumes from dump to the volumes of the DB2 target system on disk, the cloning tool does not need to take care of this step. However, the following cloning steps require some information on these volumes and the data sets on it. This information is gathered by the following job and then stored in a journal file. Since the option DATA-MOVER(PGM(NONE)) is specified, this step does not copy any data. The effect of the VOLPAIRSDEVN option is to clip the volumes, i.e. adjust the VVDS and SYSVTOC names on the target volumes.



© 2012 SAP AG 159

//CLOCLIP1 JOB ,'CKZ CLONING 2',CLASS=B,MSGCLASS=X,

// NOTIFY=&SYSUID

//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//* GENERATED: 2011-11-15 15:20:53

//* TASK NAME: COPY OF WIETZ_CLONE3_ST004

//* JCL DSN: COPY OF WIETZ.CLONE3.JCL(ST004)

//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


//S0 EXEC PGM=IDCAMS


//SYSIN DD *

DEL SCHUETZ.CLOCLIP.WRK.JRNL

DEL SCHUETZ.CLOCLIP.WRK.UCATBKUP.*

DEL SCHUETZ.CLOVOLP.CNTL

SET MAXCC=0

//COPY EXEC PGM=CKZ00010,REGION=6M

//STEPLIB DD DISP=SHR,DSN=SYS1.DB2CT.V310.SCKZLOAD

//CKZINI DD DISP=SHR,

// DSN=SYS1.DB2CT.V310.SCKZPARM(CKZINI#)

//ABNLIGNR DD DUMMY

//CKZPRINT DD SYSOUT=*

//JOURNAL DD DSN=SCHUETZ.CLOCLIP.WRK.JRNL,


// RECORG=KS,KEYLEN=64,KEYOFF=0,

// LRECL=600,SPACE=(CYL,(10,10))

//VOLPAIRD DD DSN=SCHUETZ.JOB.CNTL(VOLPAIRD),

// DISP=SHR

//CKZIN DD *

COPY -

DATA-MOVER( -

PGM(NONE) -

) -

VOLPAIRSDEVN-DDN(VOLPAIRD) -

USERCATALOGS( -



) -

CATWORK-DSN(SCHUETZ.CLOCLIP.WRK.*) -


//*

//

As an input data set, this job requires a data set that lists the mapping of the volumes from source and target and the volume address. In this case, the contents of data set SCHUETZ.JOB.CNTL(VOLPAIRD) is as follows:

SAPDG1 SAPCJ1 8E09

SAPDG2 SAPCJ2 8E0A

SAPDG3 SAPCJ3 8E0B

SAPDGL SAPCJL 8E25



© 2012 SAP AG 160

Cloning steps generated by cloning stored procedure

In this scenario we used the cloning stored procedure to generate the JCL jobs and then adapted them manually in order to use the previously restored volumes and accomplish the remaining tasks. Note that this manual adaptation is required only once. For every new refresh of the clone, these steps can be reused.

The cloning parameter file for this use case is as follows. The other two config files are as in the other use cases.

* EXAMPLE OF THE SUBSYSTEM CLONING STORED PROCEDURE CLONING 00000104

* PARAMETER FILE 00000204

* 00000304

* FROM TAPE NON DS TO NON DS - DB21 - DB24 00000410

JCL-DSN = WIETZ.CLONE3.JCL 00000604

STATUS-DSN = WIETZ.CLONE3.STATUS 00000704

WORK-PREFIX = WIETZ.CLONE3.WRK 00000804

TASK-PREFIX = WIETZ_CLONE3 00000904

CLONING-TYPE = ONLINE 00001004

USERID = WIETZ 00003004

PASSWORD =xxxxxxxx 00004004

* 00005004

JOBCARD1 = //CKZCLON1 JOB ,'CKZ CLONING 2',CLASS=B,MSGCLASS=X, 00006004

JOBCARD2 = // NOTIFY=&SYSUID 00007004

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 00100004

* COPY PARAMETERS FOR CLONING DB21 TO DB24 00110004

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 00120004

FROM-VOLSER = SAPDG1 SAPDG2 SAPDG3 SAPDGL 00140004

TO-VOLSER = SAPCJ1 SAPCJ2 SAPCJ3 SAPCJL 00200004

USERCATALOGS = SYS1.USERCAT.DB21 SYS1.USERCAT.DB24 00250004

SYS1.USERCAT.DB21L SYS1.USERCAT.DB24L 00260004

DM-PGM = ADRDSSU 00280008

DM-FCNOCOPY = Y 00314009

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 00390004

* RENAME PARAMETERS FOR CLONING DB21 TO DB24 00400004

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 00410004

RENAME-MASKS = DB21.** DB24.** 00420004

DB21L.** DB24L.** 00430004

SYS1.USERCAT.** GARBAGE.** 00440004

MAX-TASKS = 10 00530004

RECATALOG = Y 00590004

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 00710004

* DB2 PARAMETERS FOR CLONING SUBSYSTEM DB21 TO DB24 00720004

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 00730004

DB2-SUBSYSTEM-PAIR = DB21 DB24 00740004

DB2-HLQS = DB21 DB24 00750004

LISTSQL = Y 00780004

WLM-ENVIRONMENT-MASKS = DB21* DB24* 00820004

Generated Jobs

The following are the generated JCL jobs after they have been adapted. As you can see, the SIMULATE parameter was added to the early jobs to prevent that they are actually running. These jobs are not needed since the volumes from the DB2 source were already restored to the volumes of the DB2 target.



© 2012 SAP AG 161

ST001 DB2STOP of Target DB2

//CKZIN DD *

DB2STOP -


DB2-SSID(DB24) -

SIMULATE

//*

ST002 BCSCLEAN

//CKZIN DD *

BCSCLEAN -

JOURNAL-DDN(JOURNAL) –

SIMULATE

//*

ST003 DB2SETLOG SUSPEND

//CKZIN DD *

DB2SETLOG -

DB2-SSID(DB21) -

SUSPEND -

SIMULATE

//*

ST004 Delete Work Data sets

//CKZCLON1 JOB ,'CKZ CLONING 2',CLASS=B,MSGCLASS=X,

// NOTIFY=&SYSUID

//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//* GENERATED: 2011-11-21 13:57:11

//* TASK NAME: WIETZ_CLONE3_ST004

//* JCL DSN: WIETZ.CLONE3.JCL(ST004)

//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



//SYSIN DD *

DEL WIETZ.CLONE3.WRK.JRNL

DEL WIETZ.CLONE3.WRK.UCATBKUP.*

SET MAXCC=0

//*

ST005 DB2SETLOG RESUME

Note: We manually set this step to SIMULATE because this step was run outside of Cloning Tool.



© 2012 SAP AG 162

//CKZIN DD *

DB2SETLOG -

DB2-SSID(DB21) -

RESUME -

SIMULATE

//*

ST006 RENAME

This step is the first one of the generated jobs that is actually executed again.


// NOTIFY=&SYSUID

//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//* GENERATED: 2011-11-21 13:57:11



//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



//SYSIN DD *

DEL WIETZ.CLONE3.WRK.BCSRECS

DEL WIETZ.CLONE3.WRK.VOLBKUP

SET MAXCC=0

//

//

//

//RENAME EXEC PGM=CKZ00010,REGION=0M




//ABNLIGNR DD DUMMY


//DRSTATS DD SYSOUT=*

//SORTMSG DD SYSOUT=*

//JOURNAL DD DISP=SHR,DSN=SCHUETZ.CLOCLIP.WRK.JRNL

//SORTWK01 DD UNIT=SYSALLDA,SPACE=(CYL,(10,10))






//BCSRECS DD DSN=WIETZ.CLONE3.WRK.BCSRECS,

// UNIT=SYSALLDA,DISP=(,CATLG),

// SPACE=(CYL,(10,10))

//VOLBKUP DD DSN=WIETZ.CLONE3.WRK.VOLBKUP,

// UNIT=SYSALLDA,DISP=(,CATLG),

// SPACE=(CYL,(40,40))

//CKZIN DD *

RENAME -

SAFE -


RENAME-MASKS( -



© 2012 SAP AG 163

DB21.** DB24.** -

DB21L.** DB24L.** -


) -

MAX-TASKS(10) -

RECATALOG(Y) -

JOURNAL-DDN(JOURNAL) -

//*

ST007 DB2UPDATE


// NOTIFY=&SYSUID

//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//* GENERATED: 2011-11-21 13:57:11



//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//DB2UPDP EXEC PGM=CKZ00010,REGION=6M


// DD DISP=SHR,DSN=DB24L.V100.SDSNEXIT




//ABNLIGNR DD DUMMY



//BSDS01 DD DISP=OLD,DSN=DB24L.BSDS01

//BSDS02 DD DISP=OLD,DSN=DB24L.BSDS02

//DBD01 DD DISP=OLD,DSN=DB24.DSNDBC.DSNDB01.DBD01.I0001.A001

//CKZIN DD *

DB2UPDATE -

DB2-NAME(S001) -

DB2-HLQS( -

DB21 DB24 -

) -

DDF( -

IPV4(192.168.216.30) -

LOCATION(DDFDB24) -

LUNAME(SAPDB24) -

PORT(9727) -

RESPORT(9728) -

) -



//*

ST008 DB2START Target with special ZPARM


// NOTIFY=&SYSUID



© 2012 SAP AG 164

/*JOBPARM S=SAPK

//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//* GENERATED: 2011-11-21 13:57:11



//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//DB2STAS EXEC PGM=CKZ00010,REGION=6M






//ABNLIGNR DD DUMMY


//CKZIN DD *

DB2START -

DB2-SSID(DB24) -


SPECIAL

//*

ST009 DB2FIX & rerun DB2UPDATE with DBD01ONLY parameter


// NOTIFY=&SYSUID

/*JOBPARM S=SAPK

//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//* GENERATED: 2011-11-21 13:57:11



//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//DB2FIXDB EXEC PGM=CKZ00010,REGION=6M






//ABNLIGNR DD DUMMY


//CKZIN DD *

DB2FIX -

DB2-SSID(DB24) -





WAIT( 5, RC(24)) -

DATABASES(DB2)

//*


//DB2STOP EXEC PGM=CKZ00010,REGION=6M





© 2012 SAP AG 165




//ABNLIGNR DD DUMMY


//CKZIN DD *

DB2STOP -

DB2-SSID(DB24)

//*


//DB2UPDD EXEC PGM=CKZ00010,REGION=6M






//ABNLIGNR DD DUMMY


//JOURNAL DD DISP=SHR,DSN=WIETZ.CLONE3.WRK.JRNL

//DBD01 DD DISP=SHR,DSN=DB24.DSNDBC.DSNDB01.DBD01.I0001.A001

//CKZIN DD *

DB2UPDATE -

DBD01ONLY -

DB2-NAME(S001) -

DB2-HLQS( -

DB21 DB24 -

) -

DDF( -

IPV4(192.168.216.30) -

LOCATION(DDFDB24) -

LUNAME(SAPDB24) -

PORT(9727) -

RESPORT(9728) -

) -



//*








//ABNLIGNR DD DUMMY


//CKZIN DD *

DB2START -

DB2-SSID(DB24) -


SPECIAL

//*

//IF3 ENDIF

//IF2 ENDIF



© 2012 SAP AG 166

//IF1 ENDIF

ST010 DB2SQL


// NOTIFY=&SYSUID

/*JOBPARM S=SAPK

//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//* GENERATED: 2011-11-21 13:57:11



//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//DB2SQL EXEC PGM=CKZ00010,REGION=6M






//ABNLIGNR DD DUMMY



//CKZIN DD *

DB2SQL -

DB2-NAME(S001) -

DB2-SSID(DB24) -

LISTSQL(Y) -


DB21* DB24* -

) -


//*

ST011 DB2FIX


// NOTIFY=&SYSUID

/*JOBPARM S=SAPK

//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//* GENERATED: 2011-11-21 13:57:11



//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//DB2FIXAP EXEC PGM=CKZ00010,REGION=6M






//ABNLIGNR DD DUMMY


//CKZIN DD *

DB2FIX -

DB2-SSID(DB24) -


WAIT( 5, RC(24)) -



© 2012 SAP AG 167


//*

ST012 DB2STOP


// NOTIFY=&SYSUID

/*JOBPARM S=SAPK

//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//* GENERATED: 2011-11-21 13:57:11



//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *







//ABNLIGNR DD DUMMY


//CKZIN DD *

DB2STOP -

DB2-SSID(DB24)

//*

ST013 DB2START NORMAL


// NOTIFY=&SYSUID

/*JOBPARM S=SAPK

//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//* GENERATED: 2011-11-21 13:57:11



//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//DB2STAN EXEC PGM=CKZ00010,REGION=6M






//ABNLIGNR DD DUMMY


//CKZIN DD *

DB2START -

DB2-SSID(DB24) -


NORMAL

//*

This completes the online cloning use case that is based on a system-level backup on tape as a source.



© 2012 SAP AG 168

Use Case: Cloning of DB2 Data Sharing Groups

In this use case, a complete DB2 data sharing group with two members is supposed to be cloned. An existing system-level backup should be used as source for the cloning process. In addition to the considerations for the cloning of single DB2 subsystems, the following steps need to be taken into account:

Since every DB2 member has its own active log data sets, there is an exposure that some log records are missing due to a timing window related to the different FlashCopy calls. This is described in DB2 APAR PK89645. To resolve this exposure, it is strongly recommended to perform a conditional restart of the DB2 target data sharing group with the Data Complete LRSN log record. The DB2 Cloning Tool automatically takes care of this.

The renaming steps need to consider the DB2 libraries for each DB2 member

The target DB2 XCF structures should be de-allocated prior to the first starting of the target DB2 subsystem.

The special DB2 ZPARM file will need to be set up for each target member.

If you want the work database names in the target DB2 system to include a target member identifier, the work databases will need to be manually dropped and created with the desired names.

In this use case, the DB2 data sharing group DB23 is cloned to the data sharing group DB25. Both groups have two members.

Data sharing config files

The cloning config file is as follows. Note that the order of the rules for the renaming masks is important as they are processed top down.





CLONING-TYPE = ONLINE

USERID = WIETZ

PASSWORD = xxxxxxxx

*



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

* COPY PARAMETERS FOR CLONING S23 TO DB24

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

SOURCE-VOLUMES = DB2SLB

SOURCE-TOKEN = LAST

SOURCE-LOCATION = DDFS231

TO-STORAGEGROUP = DB2CJ2 DB2CJ2L

*



* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *


* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

RENAME-MASKS = DB23L.V100.S231.** DB25L.V100.S251.**

DB23L.V100.S232.** DB25L.V100.S252.**

DB23L.S231.** DB25L.S251.**

DB23L.S232.** DB25L.S252.**

DB23L.** DB25L.**

DB23.** DB25.**



© 2012 SAP AG 169


RECATALOG = Y

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

* DB2 PARAMETERS FOR CLONING DATA SHARING GROUP DB23 TO DB25

** * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

DB2-GROUP-PAIR = DB23 DB25

SSID-PAIRS = S231 S251 S232 S252

DB2-HLQS = DB23 DB25 DB23L DB25L

DATASHR-ATTR = SAME

LISTSQL = Y


The DB2 cloning product information config file is as before Note that every DB2 member needs to be considered in the DB2 system parameter config file:

* PARAMETER FILE

* CONTAINING ALL RELEVANT DB2 SUBSYSTEMS

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

* SOURCE DB2 DB23 (DATA SHARING)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

SSID = S231

GROUP = DB23

MEMBER = S231


EXEC-SYSTEM = SAPK

*

SSID = S232

GROUP = DB23

MEMBER = S232


EXEC-SYSTEM = SAPK

*

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

* TARGET DB2 DB25 (FIRST DS, THEN NON-DS)

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

SSID = S251

GROUP = DS25

MEMBER = S251


SDSNEXIT = DB25L.V100.S251.SDSNEXIT

BSDS01 = DB25L.S251.BSDS01


SYSVCAT = DB25

SPECIAL-DSNZPARM = DB25SPEC

NORMAL-DSNZPARM = DB25PARM

EXEC-SYSTEM = SAPK

DDF-IPV4 = 192.168.216.30

DDF-LOCATION = DDFS251

DDF-PORT = 9722

DDF-RESPORT = 9723

*

SSID = S252

GROUP = DS25

MEMBER = S252




© 2012 SAP AG 170

SDSNEXIT = DB25L.V100.S252.SDSNEXIT



SYSVCAT = DB25

SPECIAL-DSNZPARM = S252SPEC

NORMAL-DSNZPARM = S252PARM

EXEC-SYSTEM = SAPK

DDF-IPV4 = 192.168.216.30

DDF-LOCATION = DDFS252

DDF-PORT = 9725

DDF-RESPORT = 9724

Generated Jobs

The generated cloning jobs are as follows:

DB2STOP (both members)

There are separate jobs to stop the DB2 members of the target data sharing group.

//CKZIN DD *

DB2STOP -


DB2-SSID(S252)

//*

Figure 33. Generated cloning job WIETZ.CLONE4.JCL(ST001)


//CKZIN DD *

DB2STOP -


DB2-SSID(S251)

//*


BCSCLEAN

The cleanup job needs to be executed only once.

//BCSRECS DD DISP=OLD,DSN=WIETZ.CLONE4.WRK.BCSRECS

//CKZIN DD *

BCSCLEAN -


//*


DB2GETBACKINFO

The backup information is retrieved once for the entire source data sharing group.

********************************* Top of Data **********************************


// NOTIFY=&SYSUID



© 2012 SAP AG 171

//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//* GENERATED: 2011-12-16 09:42:40



//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



//SYSIN DD *

DEL WIETZ.CLONE4.WRK.BACKINFO

DEL WIETZ.CLONE4.WRK.HSMLIST

SET MAXCC=0

//DB2GETBI EXEC PGM=CKZ00010,REGION=6M




//ABNLIGNR DD DUMMY


//BACKINFO DD DSN=WIETZ.CLONE4.WRK.BACKINFO,



//HSMLIST DD DSN=WIETZ.CLONE4.WRK.HSMLIST,



//CKZIN DD *

DB2GETBACKINFO -

LAST -

LOCATION(DDFS231 ) -

USERCATALOGS( -

SYS1.USERCAT.DB23 SYS1.USERCAT.DB23L -

) -


WORK-DDN(HSMLIST)

//*


BACKINFO-REFORMAT

********************************* Top of Data **********************************


// NOTIFY=&SYSUID

//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//* GENERATED: 2011-12-16 09:42:40



//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



//SYSIN DD *

DEL WIETZ.CLONE4.WRK.VOLPAIRS

DEL WIETZ.CLONE4.WRK.FRVOLSER

DEL WIETZ.CLONE4.WRK.UCATS

SET MAXCC=0

//BKINRFMT EXEC PGM=CKZ00010,REGION=6M



© 2012 SAP AG 172




//ABNLIGNR DD DUMMY


//BACKINFO DD DISP=SHR,DSN=WIETZ.CLONE4.WRK.BACKINFO

//VOLPAIRS DD DSN=WIETZ.CLONE4.WRK.VOLPAIRS,



//FRVOLSER DD DSN=WIETZ.CLONE4.WRK.FRVOLSER,



//UCATS DD DSN=WIETZ.CLONE4.WRK.UCATS,



//CKZIN DD *

BACKINFO-REFORMAT -




USERCATALOGS( -



) -

USERCATALOGS-DDN(UCATS)

//*


COPY

********************************* Top of Data **********************************


// NOTIFY=&SYSUID

//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//* GENERATED: 2011-12-16 09:42:40



//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



//SYSIN DD *

DEL WIETZ.CLONE4.WRK.JRNL

DEL WIETZ.CLONE4.WRK.UCATBKUP.*

DEL WIETZ.CLONE4.WRK.VOLPLIST

SET MAXCC=0

//COPY1 EXEC PGM=CKZ00010,REGION=6M




//ABNLIGNR DD DUMMY


//VOLPAIRS DD DISP=SHR,DSN=WIETZ.CLONE4.WRK.VOLPAIRS

//UCATS DD DISP=SHR,DSN=WIETZ.CLONE4.WRK.UCATS

//JOURNAL DD DSN=WIETZ.CLONE4.WRK.JRNL,



© 2012 SAP AG 173


// RECORG=KS,KEYLEN=64,KEYOFF=0,

// LRECL=600,SPACE=(CYL,(10,10))

//VOLPLIST DD DSN=WIETZ.CLONE4.WRK.VOLPLIST,


// RECFM=FB,LRECL=80,BLKSIZE=0,


//CKZIN DD *

COPY -

DATA-MOVER(PGM(NONE)) -


USERCATALOGS-DDN(UCATS) -



//*


COPY

This job copies the volumes from the backup of the source data sharing group to the volumes of the target data sharing group.

//CKZIN DD *

COPY -


TO-STORAGEGROUP( -

DB2CJ2 DB2CJ2L -

) -

NOUSERCATALOGS -


//*


Work Data set

********************************* Top of Data *********************


// NOTIFY=&SYSUID

//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//* GENERATED: 2011-12-16 09:42:40



//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *



//SYSIN DD *

DEL WIETZ.CLONE4.WRK.NEWTGTS

SET MAXCC=0

//REXXNTGT EXEC PGM=IRXJCL,REGION=2M,PARM='CKZRNTGT'

//SYSEXEC DD DISP=SHR,DSN=SYS1.DB2CT.V310.SCKZPARM

//SYSTSIN DD DUMMY

//SYSTSPRT DD DUMMY

//SYSPRINT DD SYSOUT=*,DCB=(LRECL=132,RECFM=VBA,BLKSIZE=0)



© 2012 SAP AG 174

//CKZIN DD DISP=SHR,DSN=WIETZ.CLONE4.WRK.VOLPLIST

//NUCIN DD DISP=SHR,DSN=WIETZ.CLONE4.WRK.NUC.VOLPLIST

//NEWTGT DD DSN=WIETZ.CLONE4.WRK.NEWTGTS,


// DSORG=PS,RECFM=FB,LRECL=80,BLKSIZE=0,


//*


VOLOPTIONS UPDATE

The update of the volumes needs to be done only once, so independent of the number of DB2 members in the data sharing group.

********************************* Top of Data ***********************


// NOTIFY=&SYSUID

//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//* GENERATED: 2011-12-16 09:42:40



//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//VOLOPTS EXEC PGM=CKZ00010,REGION=6M




//ABNLIGNR DD DUMMY



//NEWTGTS DD DISP=SHR,DSN=WIETZ.CLONE4.WRK.NEWTGTS

//CKZIN DD *

VOLOPTIONS UPDATE -

NEWTARGETS-DDN(NEWTGTS) -


//*


RENAME

For the rename job, it is crucial to specify the rename masks in the right order since they are processed top down. Therefore, the more specific rules need to be specified first.

//CKZIN DD *

RENAME -

SAFE -


RENAME-MASKS( -

DB23L.V100.S231.** DB25L.V100.S251.** -

DB23L.V100.S232.** DB25L.V100.S252.** -

DB23L.S231.** DB25L.S251.** -

DB23L.S232.** DB25L.S252.** -

DB23L.** DB25L.** -



© 2012 SAP AG 175

DB23.** DB25.** -


) -

RECATALOG(Y) -


//*


DB2UPDATE

The first DB2UPDATE job adjusts the data sharing group and member information and updates the BSDS for the first member.

//CKZIN DD *

DB2UPDATE -

DB2-NAME(G001) -

DB2-HLQS( -

DB23 DB25 -

DB23L DB25L -

) -

DDF( -

IPV4(192.168.216.30) -

LOCATION(DDFS251) -

PORT(9722) -

RESPORT(9723) -

) -

DB2-GROUP(DS23 DS25 ) -

DB2-MEMBERS( -

S231 S251 -

S232 S252 -

) –



//*


DB2UPDATE BSDSONLY

The second DB2UPDATE job only updates the BSDS of the second member.

//CKZIN DD *

DB2UPDATE -

BSDSONLY -

DB2-NAME(G001) -

DB2-HLQS( -

DB23 DB25 -

DB23L DB25L -

) -

DDF( -

IPV4(192.168.216.30) -

LOCATION(DDFS252) -

PORT(9725) -

RESPORT(9724) -

) -



© 2012 SAP AG 176


DB2-MEMBERS( -

S231 S251 -

S232 S252 -

) -



//*


DB2ALTERBSDS

There is a DB2ALTERBSDS job per member of the data sharing group

//CKZIN DD *

DB2ALTERBSDS -

DB2-NAME(G001) -

DB2-MEMBER(S251 ) -

SLB-START -


//*


DB2ALTERBSDS -

DB2-NAME(G001) -

DB2-MEMBER(S252 ) -

SLB-START -


//*


DB2START (special ZPARM)

Each DB2 member of the target data sharing group is started with the special ZPARM file.


// NOTIFY=&SYSUID

/*JOBPARM S=SAPK

//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//* GENERATED: 2012-02-17 15:48:17



//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//DB2STASW EXEC PGM=CKZ00010,REGION=6M


// DD DISP=SHR,DSN=DB25L.V100.S251.SDSNEXIT






© 2012 SAP AG 177

//ABNLIGNR DD DUMMY


//CKZIN DD *

DB2START -

DB2-SSID(S251) -

DSNZPARM(DB25SPEC) -


SPECIAL

//*



// NOTIFY=&SYSUID

/*JOBPARM S=SAPK

//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//* GENERATED: 2011-12-16 09:42:40



//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//DB2STASL EXEC PGM=CKZ00010,REGION=6M






//ABNLIGNR DD DUMMY


//CKZIN DD *

DB2START -

DB2-SSID(S252) -

DSNZPARM(S252SPEC) -


SPECIAL

//*

//DB2STOSL EXEC PGM=CKZ00010,REGION=6M






//ABNLIGNR DD DUMMY


//CKZIN DD *

DB2STOP -

DB2-SSID(S252)

//*




© 2012 SAP AG 178

DB2FIX


// NOTIFY=&SYSUID

/*JOBPARM S=SAPK

//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//* GENERATED: 2012-02-17 15:48:17



//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *

//DB2FIXDB EXEC PGM=CKZ00010,REGION=6M






//ABNLIGNR DD DUMMY


//CKZIN DD *

DB2FIX -

DB2-SSID(S251) -





WAIT( 5, RC(24)) -

DATABASES(DB2)

//*








//ABNLIGNR DD DUMMY


//CKZIN DD *

DB2STOP -

DB2-SSID(S251)

//*


//DB2UPDD EXEC PGM=CKZ00010,REGION=6M






//ABNLIGNR DD DUMMY



//DBD01 DD DISP=SHR,DSN=DB25.DSNDBC.DSNDB01.DBD01.I0001.A001

//CKZIN DD *

DB2UPDATE -



© 2012 SAP AG 179

DBD01ONLY -

DB2-NAME(G001) -

DB2-HLQS( -

DB23 DB25 -

DB23L DB25L -

) -

DDF( -

IPV4(192.168.216.30) -

LOCATION(DDFS251) -

PORT(9722) -

RESPORT(9723) -

) -


DB2-MEMBERS( -

S231 S251 -

S232 S252 -

) -



//*








//ABNLIGNR DD DUMMY


//CKZIN DD *

DB2START -

DB2-SSID(S251) -

DSNZPARM(DB25SPEC) -


SPECIAL

//*

//IF3 ENDIF

//IF2 ENDIF

//IF1 ENDIF


DB2SQL

//CKZIN DD *

DB2SQL -

DB2-NAME(G001) -

DB2-SSID(S251) -

LISTSQL(Y) -


DB23* DB25* -

) -




© 2012 SAP AG 180

//*


DB2FIX

//CKZIN DD *

DB2FIX -

DB2-SSID(S251) -


WAIT( 5, RC(24)) -


//*


DB2STOP

//CKZIN DD *

DB2STOP -

DB2-SSID(S251)

//*


DB2START both members

Finally, both DB2 members of the target data sharing group are started.

//CKZIN DD *

DB2START -

DB2-SSID(S251) -


NORMAL

//*


//CKZIN DD *

DB2START -

DB2-SSID(S252) -

DSNZPARM(S252PARM) -

NORMAL

//*


This completes the online cloning of a data sharing group based on a system-level backup on disk.



© 2012 SAP AG 181

Related Content

DB2 10 for z/OS

Managing DFSMShsm default settings when using the BACKUP SYSTEM, RESTORE SYSTEM, and RECOVER utilities http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.db2z10.doc.admin/src/tpc/db2z_managedefaultsutilities.htm

z/OS

DFSMShsm Storage Administration Reference, z/OS V1R12.0 DFSMShsm Storage Administration SC35-0421-12 http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=/com.ibm.zos.r12.arcf000/frb2.htm

DFSMShsm Fast Replication Technical Guide, October 2011, SG24-7069-01 http://www.redbooks.ibm.com/abstracts/sg247069.html

Redbooks and Redpieces

IBM Redbook: z/OS V1.12 DFSMS Technical Update http://www.redbooks.ibm.com/redbooks/pdfs/sg247895.pdf

IBM Redbook: DFSMShsm Fast Replication Technical Guide http://www.redbooks.ibm.com/redbooks/pdfs/sg247069.pdf

IBM Redbook: Running SAP Solutions with DB2 10 for z/OS on zEnterprise http://www.redbooks.ibm.com/redbooks/pdfs/sg247978.pdf

IBM Redpaper: IBM System Storage DS8000: Remote Pair FlashCopy (Preserve Mirror) http://www.redbooks.ibm.com/redpapers/pdfs/redp4504.pdf

IBM System Storage DS8000: Architecture and Implementation http://www.redbooks.ibm.com/redbooks/pdfs/sg248886.pdf

SAP SDN documents

SAP Business Suite on IBM System z Reference Architecture for System Infrastructure

Casebook: DB2 backup, Recovery and Cloning for SAP Environments (October 2008)

http://publib.boulder.ibm.com/infocenter/dzichelp/v2r2/index.jsp?topic=/com.ibm.db2z10.doc.admin/src/tpc/db2z_managedefaultsutilities.htm




http://publib.boulder.ibm.com/infocenter/zos/v1r12/index.jsp?topic=/com.ibm.zos.r12.arcf000/frb2.htm




http://www.redbooks.ibm.com/abstracts/sg247069.html

http://www.redbooks.ibm.com/abstracts/sg247069.html

http://www.redbooks.ibm.com/abstracts/sg247895.html?Open


http://www.redbooks.ibm.com/redpieces/abstracts/sg247978.html?Open

http://www.redbooks.ibm.com/abstracts/redp4504.html?Open


http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/7071c07f-d0d1-2c10-47a8-b19735a31850

http://www.sdn.sap.com/irj/scn/index?rid=/library/uuid/e0b13d2b-0a89-2b10-918b-bc7aff0a1905



© 2012 SAP AG 182

Copyright

© Copyright 2012 SAP AG. All rights reserved.

No part of this publication may be reproduced or transmitted in any form or for any purpose without the express permission of SAP AG. The information contained herein may be changed without prior notice.

Some software products marketed by SAP AG and its distributors contain proprietary software components of other software vendors.

Microsoft, Windows, Excel, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, System i, System i5, System p, System p5, System x, System z, System z10, System z9, z10, z9, z114, z196, iSeries, pSeries, xSeries, zSeries, eServer, zEnterprise, z/VM, z/OS, i5/OS, S/390, OS/390, OS/400, AS/400, PowerVM, Power Architecture, POWER, POWER6, POWER7, POWER8, OpenPower, PowerPC, BatchPipes, BladeCenter, FlashCopy, DS8000, System Storage, GDPS, Geographically Dispersed Parallel Sysplex, GPFS, HACMP, HiperSockets, HyperSwap, RETAIN, DB2 Connect, RACF, Redbooks, Parallel Sysplex, MVS, AIX, Intelligent Miner, WebSphere, Netfinity, Tivoli and Informix are trademarks or registered trademarks of IBM Corporation.

Linux is the registered trademark of Linus Torvalds in the U.S. and other countries.

Adobe, the Adobe logo, Acrobat, PostScript, and Reader are either trademarks or registered trademarks of Adobe Systems Incorporated in the United States and/or other countries.

Oracle is a registered trademark of Oracle Corporation.

UNIX, X/Open, OSF/1, and Motif are registered trademarks of the Open Group.

Citrix, ICA, Program Neighborhood, MetaFrame, WinFrame, VideoFrame, and MultiWin are trademarks or registered trademarks of Citrix Systems, Inc.

HTML, XML, XHTML and W3C are trademarks or registered trademarks of W3C®, World Wide Web Consortium, Massachusetts Institute of Technology.

Java is a registered trademark of Oracle Corporation.

JavaScript is a registered trademark of Oracle Corporation, used under license for technology invented and implemented by Netscape.

SAP, R/3, SAP NetWeaver, Duet, PartnerEdge, ByDesign, SAP Business ByDesign, and other SAP products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of SAP AG in Germany and other countries.

Business Objects and the Business Objects logo, BusinessObjects, Crystal Reports, Crystal Decisions, Web Intelligence, Xcelsius, and other Business Objects products and services mentioned herein as well as their respective logos are trademarks or registered trademarks of Business Objects S.A. in the United States and in other countries. Business Objects is an SAP company.

All other product and service names mentioned are the trademarks of their respective companies. Data contained in this document serves informational purposes only. National product specifications may vary.

These materials are subject to change without notice. These materials are provided by SAP AG and its affiliated companies ("SAP Group") for informational purposes only, without representation or warranty of any kind, and SAP Group shall not be liable for errors or omissions with respect to the materials. The only warranties for SAP Group products and services are those that are set forth in the express warranty statements accompanying such products and services, if any. Nothing herein should be construed as constituting an additional warranty.

Casebook - 2012 Edition: Tightly Integrated DB2 Backup ...

Documents

Transcript of Casebook - 2012 Edition: Tightly Integrated DB2 Backup ...