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
SAP COMMUNITY NETWORK
© 2011 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
1
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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 4acme@web.de
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 chrgaul@de.ibm.com.
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 peterhar@de.ibm.com.
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 christian.heimlich@de.ibm.com.
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 KOMPALKA@de.ibm.com.
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
ludger.quatmann@de.ibm.com.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
2
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
rese@de.ibm.com.
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, performance, 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
arodi@us.ibm.com.
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 heike_schmidt@de.ibm.com.
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 schuetzner@de.ibm.com.
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 mesiart@us.ibm.com.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
3
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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 wietzo@de.ibm.com.
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
rolwolf@de.ibm.com.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
4
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
5
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
6
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
Figure 34. Generated cloning job WIETZ.CLONE4.JCL(ST002) ...................................................................170
Figure 35. Generated cloning job WIETZ.CLONE4.JCL(ST003) ...................................................................170
Figure 36. Generated cloning job WIETZ.CLONE4.JCL(ST004) ...................................................................171
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
7
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
Figure 37. Generated cloning job WIETZ.CLONE4.JCL(ST005) ...................................................................172
Figure 38. Generated cloning job WIETZ.CLONE4.JCL(ST006) ...................................................................173
Figure 39. Generated cloning job WIETZ.CLONE4.JCL(ST007) ...................................................................173
Figure 40. Generated cloning job WIETZ.CLONE4.JCL(ST008) ...................................................................174
Figure 41. Generated cloning job WIETZ.CLONE4.JCL(ST009) ...................................................................174
Figure 42. Generated cloning job WIETZ.CLONE4.JCL(ST010) ...................................................................175
Figure 43. Generated cloning job WIETZ.CLONE4.JCL(ST011) ...................................................................175
Figure 44. Generated cloning job WIETZ.CLONE4.JCL(ST012) ...................................................................176
Figure 45. Generated cloning job WIETZ.CLONE4.JCL(ST013) ...................................................................176
Figure 46. Generated cloning job WIETZ.CLONE4.JCL(ST014) ...................................................................176
Figure 47. Generated cloning job WIETZ.CLONE4.JCL(ST015) ...................................................................177
Figure 48. Generated cloning job WIETZ.CLONE4.JCL(ST016) ...................................................................177
Figure 50. Generated cloning job WIETZ.CLONE4.JCL(ST018) ...................................................................180
Figure 51. Generated cloning job WIETZ.CLONE4.JCL(ST019) ...................................................................180
Figure 52. Generated cloning job WIETZ.CLONE4.JCL(ST020) ...................................................................180
Figure 53. Generated cloning job WIETZ.CLONE4.JCL(ST021) ...................................................................180
Figure 54. Generated cloning job WIETZ.CLONE4.JCL(ST022) ...................................................................180
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
8
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
9
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
10
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
11
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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.
System z
System z
Single SAP system
per DB2 system
Single SAP system
per DB2 system
Table
DB2 BACKUP SYSTEM
SYSTEM
RECOVER
z/OS DFSMS
Tape
DS8000
DB2
Tape
z/OS DFSMS
DB2 RESTORE
DS8000
FlashCopy
•
Full
•
Incremental
•
Space efficient
FlashCopy
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
12
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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.
FlashCopy established at time t0 (time-zero)
time
t0
bitmap
1
source
1
1
1
t0
t0
t0
1
target
data
t0
1
t0
data
t0
Background copy will copy all time-zero data from source to target
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
13
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
Figure 3 visualizes incremental FlashCopy.
Initial Incremental FlashCopy
Incremental FlashCopy
Background copy with change
recording enabled
Copies only changed data
Initial copy
Copy changed data
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
14
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
Copy pool CP1
Storage group Src1
Storage group Src2
Type:
Type:
POOL
POOL
Copy pool backup storage
group name:
CPB1
Copy pool backup storage
group name:
CPB1
Storage group CPB1
Type:
COPY POOL BACKUP
Copy pool backup storage group name:
N/A
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
15
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
System z
BACKUP SYSTEM
processes
z/OS DFSMShsm Fast
Replication Services
processes
DB2 subsystem /
data sharing group
invokes
z/OS DFSMSdss
hsm copy pool
Volume-level FlashCopy
DB2 via hsm
FlashCopy (full, incre-
Efficiently copies data
mental, space efficient)
DB2 via dss
DS8000
Tape
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.
System z
Object-level utilities
(COPY, REORG,
REBUILD, ...)
z/OS DFSMSdss
processes
Single tablespace,
partition or index
invokes
FlashCopy (full)
Data set-level FlashCopy
Efficiently copies data
DS8000
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 systemlevel 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 objectlevel 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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
16
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
17
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
Source
Target
(empty)
Bitmap
FlashCopy command issued
Time
Copy is immediately available
(but target volume is physically
empty)
Read
DB2 reads and writes from source
only.
Note that DS8000 can read from
and write to both source and
target copy
Write
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
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
18
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments

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.
First incremental FlashCopy ...
Bitmap
Bitmap
Source
Target
The initial incremental
FlashCopy copies everything
in the background.
Incremental
FlashCopy
Write
Writes to source are tracked
in a bitmap.
no I/O
...next incremental FlashCopy ...
With next incremental
FlashCopy the tracks that are
marked in the bitmap are
copied to target (resync).
Resync
t
(time)
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
19
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
Storage group
DB2 copy pools
Type:
COPY POOL BACKUP
BACKUP SYSTEM
Invokes volume-level
FlashCopy
RECOVER
Invokes data set-level FlashCopy
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
20
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
21
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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 spaceefficient 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
Virtual repository capacity
Allocated tracks
Used
tracks
Extent
Pool
Spaceefficient
volume
Arrays
Repository for
space-efficient
volumes
striped across
arrays
normal
Volume
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
22
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
Source
volumes
Source
volumes
Classic
FlashCopy
target volumes
Repository
IBM
FlashCopy SE
virtual target
volumes
Space needed for
FlashCopy targets
Space needed for
FlashCopy targets
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 Spaceefficient 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:
Copy Pool Application
Background Copy
Time
Initiate
FlashCopy
FlashCopy
Relationships
Established
Disk
Recovery
Available
Figure 12. Situation before fast reverse restore
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
23
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
With the introduction of fast reverse restore, the recovery can be faster as the following figure shows:
Copy Pool Application
Background Copy
Initiate
FlashCopy
FC
Relationships
Established
Time
Disk
Recovery
Available !!
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
24
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
Local Storage Server
Remote Storage Server
Local A
Metro Mirror
FlashCopy
(PPRC)
full duplex
Local B
Remote B
duplex pending
while copying
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).
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
25
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
Local Storage Server
Local A
Remote Storage Server
full duplex
Remote A
FlashCopy
FlashCopy
Local B
Metro Mirror
full duplex
FlashCopy
Remote B
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
26
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
SMS Group Type: Pool
SG1
SG2
Backup Pool: CPB1
SG3
Backup Pool: CPB2
Up to 256 storage
groups (SG) per
copy pool
Used to specify
candidate target
backup volumes for
DFSMShsm fast
replication requests
SMS Group Type: Copy Pool Backup
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
27
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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.
Vol. A
VTOC.A
VVDS.A
DFSMSdss
COPY FULL with parameter
DUMPCONDITIONING
optional NOCOPY
Vol. B
VTOC.B
VVDS.B
“Conditioned
Volume“
DUMP
FULL
FCWITHDRAW
RESTORE
COPYVOLID
volume
RESTORE
DATASET
Dump
Tape
Vol. A
VTOC.A
VVDS.A
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
28
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments

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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
29
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments

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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
30
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
31
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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 crashconsistent 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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
32
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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.
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
SMS Storage Group DB2LG1
SMS Storage Group DB2CAT
SMS Storage Group DB2USER
ICFCAT DB2LG1.CAT
ICFCAT DB2DATA.CAT
ICFCAT DB2DATA.CAT
DB2 Active Logs
DB2 BSDS
DB2 Load Libraries
DB2 Catalog
DB2 Directory
SAP Data
Copy Pool DSN$DB2xxx$DB
Copy Pool DSN$DB2XXX$LG
Copy Pool Backup Storage Group
DB2LOG
Copy Pool Backup Storage Group
DB2DATA
Figure 18. Sample SMS Configuration – Option #1
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
33
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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.
SMS Storage Group DB2LG1
ICFCAT DB2LG1.CAT
DB2 LOGCOPY1 Active Logs
DB2 BSDS01
DB2 Load Libraries
SMS Storage Group DB2CAT
SMS Storage Group DB2USER
ICFCAT DB2DATA.CAT
ICFCAT DB2DATA.CAT
DB2 Catalog
DB2 Directory
SAP Data
SMS Storage Group DB2LG2
Copy Pool DSN$DB2xxx$DB
ICFCAT DB2LG1.CAT
DB2 LOGCOPY2 Active Logs
DB2 BSDS02
Copy Pool Backup Storage Group
DB2DATA
Copy Pool DSN$DB2XXX$LG
Copy Pool Backup Storage Group
DB2LOG
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
34
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
35
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
SMS Storage
Group
Data Sets
Data Set Name
ICF Catalog name
Catalog ALIAS
SMS
SMS
Guaranteed
Management Storage
Space
Class
Class
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
PE1LOGSG
Data Sets
DB2 Active Log
Datasets
DB2 BSDS Datasets
DSNLOAD
DSNMACS
DSNEXIT
Data Set Name
ICF Catalog name
Catalog ALIAS
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.LOGCOPY2
PE11.DB2
PE11
PE1A.LOGCOPY1
PE1A.LOGCOPY2
PE1A.DB2
PE1A
SAP COMMUNITY NETWORK
© 2012 SAP AG
SMS
SMS
Guaranteed
Management Storage
Space
Class
Class
NULL
SCGS
YES
Migration
NO
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
36
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
Data Sets
Data Set Name
ICF Catalog name
Catalog ALIAS
SMS
SMS
Guaranteed
Management Storage
Space
Class
Class
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.
DS8300: DS8K2
DS8800: DS8K3
For data: 3 Mod 27 volumes
For log: 1 Mod 9 volume
DB2 10 subsystem with SAP NetWeaver 7.31 on z/OS 1.13
Copy pool
Copy pool
Copy pool
Copy pool
DSN$DDFDB21$DB
DSN$DDFDB21$LG
DSN$DDFDB21$DB
DSN$DDFDB21$LG
Storage group
DB2DG
Storage group
DB2DGL
Type:
Type:
POOL
PPRC
Storage group
DB2DG
Storage group
DB2DGL
Type:
Type:
POOL
CopyPool Backup name:
POOL
CopyPool Backup name:
DB2FA
DB2FAL
Volumes:
Volumes:
SAPDGL
POOL
CopyPool Backup name:
DB2FA
PPRC
Volumes:
SAPDG1-3
CopyPool Backup name:
DB2FAL
Volumes:
SAPDG1-3
SAPDGL
DB2 B A C K U P S Y S T E M
With incremental FlashCopy
Copy pool VERSIONS = 1
RPFC
Storage group DB2FG
Storage group DB2FGL
Type:
Type:
COPY POOL BACKUP
CopyPool Backup name:
N/A
Volumes:
SAPFG1-3
PPRC
COPY POOL BACKUP
N/A
SAPFGL
Storage group DB2FGL
Type:
Type:
COPY POOL BACKUP
CopyPool Backup name:
Volumes:
Storage group DB2FG
CopyPool Backup name:
PPRC
N/A
Volumes:
SAPFA1+2
COPY POOL BACKUP
CopyPool Backup name:
N/A
Volumes:
SAPFAL
Figure 20. Test Environment 1: Backup, Recovery and DR Scenarios
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
37
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
Test environment 2 represents an SAP non-production environment. Therefore, it is an environment that
can take advantage of space-efficient FlashCopy.
DS8300: DS8K2
DB2 10 subsystem with SAP NetWeaver 7.31 on z/OS 1.13
Copy pool
Copy pool
DSN$DDFDB22$DB
DSN$DDFDB22$LG
Storage group
DB2DI
Storage group
DB2DIL
Type:
Type:
POOL
For data: 3 Mod 27 volumes
For log: 1 Mod 9 volume
POOL
CopyPool Backup name:
CopyPool Backup name:
DB2FI
DB2FIL
Volumes:
Volumes:
SAPDI1-3
SAPDIL
DB2 B A C K U P S Y S T E M
With space-efficient FlashCopy
NOCOPY: VERSIONS=0
Storage group DB2FI
Storage group DB2FIL
Type:
Type:
COPY POOL BACKUP
COPY POOL BACKUP
CopyPool Backup name:
Tape: VTS
CopyPool Backup name:
N/A
N/A
Volumes:
Volumes:
SAPFI1-3
SAPFIL
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.
DB2 Cloning Tool
DS8300: DS8K2
DS8800: DS8K3
DB2 10 subsystem with SAP NetWeaver 7.31 on z/OS 1.13
DB2 10 single subsystem with SAP NetWeaver 7.31 on z/OS 1.13
Copy pool
Copy pool
Copy pool
Copy pool
DSN$DDFDB21$DB
DSN$DDFDB21$LG
DSN$DDFDB24$DB
DSN$DDFDB24$LG
Storage group
DB2DG
Storage group
DB2DGL
Storage group
DB2CJ
Type:
Type:
Type:
POOL
POOL
POOL
CopyPool Backup name:
CopyPool Backup name:
DB2FA
SAPDG1-3
Volumes:
SAPCJ1-3
SAPDGL
CopyPool Backup name:
DB2FJL
Volumes:
Volumes:
Type:
POOL
CopyPool Backup name:
DB2FJ
DB2FAL
Volumes:
Storage group
DB2CJL
SAPCJL
DB2 B A C K U P S Y S T E M
With incremental FlashCopy
Copy pool VERSIONS = 1
FlashCopy
Storage group DB2FG
Storage group DB2FGL
Type:
Type:
COPY POOL BACKUP
CopyPool Backup name:
N/A
Volumes:
SAPFG1-3
FlashCopy
For data: 3 Mod 27 volumes
For log: 1 Mod 9 volume
COPY POOL BACKUP
CopyPool Backup name:
N/A
Tape: VTS
Volumes:
SAPFGL
The following
figure
visualizes the 3:
cloning
relationship
for the cloning use cases with data sharing.
Figure
22. Test
Environment
Backup
Cloning
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
38
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
DB2 Recovery Expert
DB2 Cloning Tool
DS8300: DS8K2
DB2 10 data sharing with SAP NetWeaver 7.31 on z/OS 1.13
DB2 10 data sharing with SAP NetWeaver 7.31 on z/OS 1.13
Copy pool
Copy pool
Copy pool
Copy pool
DSN$DDFDB23$DB
DSN$DDFDB23$LG
DSN$DDFDB25$DB
DSN$DDFDB25$LG
Storage group
DB2DJ
Storage group
DB2DJL
Type:
Type:
POOL
POOL
CopyPool Backup name:
CopyPool Backup name:
DB2FJ
DB2FJL
Volumes:
Storage
Storagegroup
group
DB2CJ2L
DB2CJ2L
Type:
Type:
Type:
POOL
POOL
POOL
Volumes:
Volumes:
Volumes:
Volumes:
SAPDJ1-3
Storage group
DB2CJ2
SAPCJM
SAPCJM
SAPCJA-C
SAPDJL
DB2 B A C K U P S Y S T E M
With incremental & full FlashCopy
Copy pool VERSIONS = 2
FlashCopy
Storage group DB2FJ
Storage group DB2FJL
Type:
Type:
COPY POOL BACKUP
CopyPool Backup name:
COPY POOL BACKUP
CopyPool Backup name:
N/A
FlashCopy
Tape:
Tape:VTS
VTS
N/A
Volumes:
For data: 3 Mod 27 volumes
For log: 1 Mod 9 volume
Volumes:
SAPFJ1-6
SAPFJL+M
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
39
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
40
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
The following table gives an overview about naming conventions and storage definitions:
SAP SID
DB1
DB2 SSID
Copy Pool
DB21
SMS
Volsers PPRC Primary
Storage
Addresses
Group
DB2DG SAPDG1
8E00
SAPDG2
8E01
SAPDG3
8E02
DB2FG SAPFG1
8E10
SAPFG2
8E11
SAPFG3
8E12
DB2DGL SAPDGL
8E20
DB2FGL SAPFGL
8E21
DSN$DDFDB21$DB
Backup Copy Pool
DSN$DDFDB21$LG
Backup Copy Pool
DSN$DDFDB21$DB
DSN$DDFDB21$LG
Backup Copy Pool
DB2DG SAPDH1
SAPDH2
SAPDH3
DB2FG SAPFH1
SAPFH2
SAPFH3
DB2DGL SAPDHL
DB2FGL SAPFHL
SAP SID
DB2
DB2 SSID
Copy Pool
DB22
SMS
Volsers
Storage
Group
DB2DI SAPDI1
SAPDI2
SAPDI3
DB2FI SAPFI1
SAPFI2
SAPFI3
DB2DIL SAPDIL
DB2FIL SAPFIL
Backup Copy Pool
DSN$DDFDB22$DB
Backup Copy Pool
DSN$DDFDB22$LG
Backup Copy Pool
SAP COMMUNITY NETWORK
© 2012 SAP AG
DS8000 Comments
DS8K2 PPRC Source
PPRC
DS8000
Secondary
Addresses
7E00 (of 8E00) DS8K3 PPRC Target
7E01 (of 8E01)
7E02 (of 8E02)
7E10 (of 8E10)
7E11 (of 8E11)
7E12 (of 8E12)
7E20 (of 8E20)
7E21 (of 8E21)
Addresses
8E03
8E04
8E05
8E33
8E34
8E35
8E28
8E38
DS8000 Comments
DS8K2
Space-Efficient Pool
Repository = 64GB
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
41
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
SAP SID
DB3
DB2 SSID
Group DS23 with DB2 members S231 and S232
Copy Pool
DSN$DDFS231$DB
Backup Copy Pool
DSN$DDF S231$LG
Backup Copy Pool
SMS
Volsers
Storage
Group
DB2DJ SAPDJ1
SAPDJ2
SAPDJ3
DB2FJ SAPFJ1
SAPFJ2
SAPFJ3
SAPFJ4
SAPFJ5
SAPFJ6
DB2DJL SAPDJL
DB2FJL SAPFJL
SAPFJM
Addresses
8E06
8E07
8E08
8E16
8E17
8E18
8E19
8E1A
8E1B
8E22
8E23
8E24
DS8000 Comments
DS8300 Source for cloning
SAP SID
DB4
DB2 SSID
DSN$DDFDB24$DB
DSN$DDFDB24$LG
DB24
DB2CJ SAPCJA
SAPCJB
SAPCJC
DB2CJL SAPCJM
SAP SID
DB5
DB2 SSID
Copy Pool
Group DS25 with DB2 members S251 and S252
SMS
Volsers
Addresses
DS8000 Comments
Storage
Group
DB2CJ2 SAPCJA
8E13
DS8K2 clone target
SAPCJB
8E14
SAPCJC
8E15
DSN$DDFS251$DB
DSN$DDFS251$LG
DB2CJ2L SAPCJM
8E13
8E14
8E15
8E29
clone target
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
FILTLIST DB2DG
FILTLIST DB2DIL
FILTLIST DB2DI
SAP COMMUNITY NETWORK
© 2012 SAP AG
INCLUDE(DB21L.**,
'SYS1.USERCAT.DB21L')
INCLUDE(DB21.**,
'SYS1.USERCAT.DB21')
EXCLUDE(DB21.ARCHLOG%.**)
INCLUDE(DB22L.**,
'SYS1.USERCAT.DB22L')
INCLUDE(DB22.**,
'SYS1.USERCAT.DB22')
EXCLUDE(DB22.ARCHLOG%.**)
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
42
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
FILTLIST DB2DJL
FILTLIST DB2DJ
FILTLIST DB2CJL
FILTLIST DB2CJ
FILTLIST DB2CJL2
FILTLIST DB2CJ2
INCLUDE(DB23L.**,
'SYS1.USERCAT.DB23L')
INCLUDE(DB23.**,
'SYS1.USERCAT.DB23')
EXCLUDE(DB23.ARCHLOG%.**)
INCLUDE(DB24L.**,
'SYS1.USERCAT.DB24L')
INCLUDE(DB24.**,
'SYS1.USERCAT.DB24')
EXCLUDE(DB24.ARCHLOG%.**)
INCLUDE(DB25L.**,
'SYS1.USERCAT.DB25L')
INCLUDE(DB25.**,
'SYS1.USERCAT.DB25')
EXCLUDE(DB25.ARCHLOG%.**)
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) NORESET TAPEEXPIRATIONDATE(99365) RETENTIONPERIOD(100) *2
)
...
*1
*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”
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
43
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
F7=UP
F2=SPLIT
F8=DOWN
F3=END
F4=RETURN
F9=SWAP lis F10=LEFT
F5=RFIND
F11=RIGHT
F6=RCHANGE
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:
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
44
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
-----------------------------------------------------------------------------ISMF PRIMARY OPTION MENU - z/OS DFSMS V1 R13
Select one of the following options and press Enter:
0
1
2
3
4
5
9
L
R
X
ISMF Profile
Data Set
Volume
Management Class
Data Class
Storage Class
Aggregate Group
List
Removable Media Manager
Exit
-
Change ISMF User Profile
Perform Functions Against Data Sets
Perform Functions Against Volumes
Specify Data Set Backup and Migration Criteria
Specify Data Set Allocation Parameters
Specify Data Set Performance and Availability
Specify Data Set Recovery Parameters
Perform Functions Against Saved ISMF Lists
Perform Functions Against Removable Media
Terminate ISMF
Enter Selection or Command ===>
F1=Help
F2=Split
F3=End
F10=Left
F11=Right F12=Cursor
F4=Return
F7=Up
F8=Down
F9=Swap
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
1
2
3
4
5
6
X
User Mode Selection
Logging and Abend Control
ISMF Job Statement
DFSMSdss Execute Statement
ICKDSF Execute Statement
Data Set Print Execute Statement
IDCAMS Execute Statement
Exit
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 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:
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
45
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
-----------------------------------------------------------------------------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 ===>
F1=Help
F2=Split
F10=Left
F11=Right
F3=End
F12=Cursor
F4=Return
F7=Up
F8=Down
F9=Swap
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 ===>
F1=Help
F2=Split
F3=End
F4=Return F7=Up
F8=Down
F9=Swap
F10=Left
F11=Right F12=Cursor
Screenshot 6. ISMF Primary Option Menu - z/OS DFSMS V1 R13
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
46
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
VERSIONS
DUMP
OR SYS GRP
USERID
MODIFIED
MODIF
-------------(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$DDFDB22$DB
0
NO
--------
KARO
2011/12/01
16:30
DSN$DDFDB22$LG
0
NO
--------
KARO
2011/12/01
16:31
DSN$DDFDB23$DB
2
NO
--------
KARO
2011/11/22
11:17
DSN$DDFDB23$LG
2
NO
--------
KARO
2011/11/08
10:42
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
OPERATOR
---(1)----
COPY POOL NAME
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
47
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
CDS Name : ACTIVE
Enter Line Operators below:
LINE
FCTOPPRC
FCTOPPRC
ALLOW
STORAGE
FRBACKUP
FRRECOV
CATINFO
FCFRR
GRP NAME
-------------(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
OPERATOR
---(1)----
COPY POOL NAME
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
Enter Line Operators below:
LINE
OPERATOR
---(1)----
STORGRP
NAME
--(2)--DB2DDL
DB2DE
DB2DEL
DB2DG
DB2DGL
DB2DI
DB2DIL
DB2DJ
DB2DJL
OSMC
SYSTEM
--(40)-----------------------------------------------------------------
OVERFLOW
--(41)-NO
NO
NO
NO
NO
NO
NO
NO
NO
EXTEND
SG NAME
--(42)-----------------------------------------------------------------
CP BCKP
SG NAME
--(43)-DB2FDL
DB2FE
DB2FEL
DB2FG
DB2FGL
DB2FI
DB2FIL
DB2FJ
DB2FJL
BREAK
POINT
-(44)-------------------------------------
MIGR
HI TRK
-(45)85
85
85
85
85
85
85
85
85
-----------------------------------------------------------------------------STORAGE GROUP LIST
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
48
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
Entries 29-37 of 77
Data Columns 3-6 of 48
CDS Name : ACTIVE
Enter Line Operators below:
LINE
OPERATOR
---(1)----
STORGRP
NAME
--(2)--DB2FDL
DB2FE
DB2FEL
DB2FG
DB2FGL
DB2FI
DB2FIL
DB2FJ
DB2FJL
SG
TYPE
-------(3)-----COPY POOL BACKUP
COPY POOL BACKUP
COPY POOL BACKUP
COPY POOL BACKUP
COPY POOL BACKUP
COPY POOL BACKUP
COPY POOL BACKUP
COPY POOL BACKUP
COPY POOL BACKUP
VIO
MAXSIZE
--(4)--------------------------------------------------------
VIO
UNIT
(5)----------------------------
AUTO
MIGRATE
--(6)------------------------------------------------------------------
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
//SYSPRINT DD SYSOUT=*
//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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
49
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
Total Tracks:
Row 1 of 3
7530 non-x:
7724 Data Sets:
3 non-x:
3
------------------------------------------------------------------------------Command - Enter "/" to select action
Tracks %Used
XT
------------------------------------------------------------------------------SYS1.VTOCIX.D#47BF
WB.D#47BF
WB.LDATA
29
100
1
7006
97
12
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
ENTRY LINK ADDRESS
0E
0E
DEST LINK ADDRESS
15
15
SAP COMMUNITY NETWORK
© 2012 SAP AG
66
12
21
67
12
21
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
50
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
Allocation Pool
ID
VOLSER
Status
MTM
# Mod1 # Cylinders
Vol-B/R/C-8E00
0E00
SAPDG1
Normal
3390-9
30
Vol-B/R/C-8E01
0E01
SAPDG2
Normal
3390-9
Vol-B/R/C-8E02
0E02
SAPDG3
Normal
3390-9
Vol-B/R/C-8E03
0E03
SAPDI1
Normal
Vol-B/R/C-8E04
0E04
SAPDI2
Normal
Vol-B/R/C-8E05
0E05
SAPDI3
Vol-B/R/C-8E06
0E06
SAPDJ1
Vol-B/R/C-8E07
0E07
Vol-B/R/C-8E08
0E08
Vol-B/R/C-8E09
Vol-B/R/C-8E0A
Storage
32,760
Standard
EP_CKD_P0
30
32,760
Standard
EP_CKD_P0
30
32,760
Standard
EP_CKD_P0
3390-9
30
32,760
Standard
EP_CKD_P0
3390-9
30
32,760
Standard
EP_CKD_P0
Normal
3390-9
30
32,760
Standard
EP_CKD_P0
Normal
3390-9
30
32,760
Standard
EP_CKD_P0
SAPDJ2
Normal
3390-9
30
32,760
Standard
EP_CKD_P0
SAPDJ3
Normal
3390-9
30
32,760
Standard
EP_CKD_P0
0E09
SAPCJ1
Normal
3390-9
30
32,760
Standard
EP_CKD_P0
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-8E11
0E11
SAPFG2
Normal
3390-9
30
32,760
Standard
EP_CKD_P0
Vol-B/R/C-8E12
0E12
SAPFG3
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-8E14
0E14
FR8E14
Normal
3390-9
30
32,760
Standard
EP_CKD_P0
Vol-B/R/C-8E15
0E15
FR8E15
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-8E17
0E17
SAPFJ2
Normal
3390-9
30
32,760
Standard
EP_CKD_P0
Vol-B/R/C-8E18
0E18
SAPFJ3
Normal
3390-9
30
32,760
Standard
EP_CKD_P0
Vol-B/R/C-8E19
0E19
SAPFJ4
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
51
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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-8E29
0E29
FR8E29
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
9
10,017
Standard
EP_CKD_P0
Normal
3390-9
Vol-SpaceEf-8E30 0E30
FR8E30
Normal
3390-9
30
32,760
TSE
EP_CKD_P0
Vol-SpaceEf-8E31 0E31
FR8E31
Normal
3390-9
30
32,760
TSE
EP_CKD_P0
Vol-SpaceEf-8E32 0E32
FR8E32
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-8E34 0E34
SAPFI2
Normal
3390-9
30
32,760
TSE
EP_CKD_P0
Vol-SpaceEf-8E35 0E35
SAPFI3
Normal
3390-9
30
32,760
TSE
EP_CKD_P0
Vol-SpaceEf-8E36 0E36
FR8E36
Normal
3390-9
30
32,760
TSE
EP_CKD_P0
Vol-SpaceEf-8E37 0E37
FR8E37
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
Vol-SpaceEf-8E39 0E39
FR8E39
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)
/*
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
52
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
DSNU000I
342
DSNU1044I
342
DSNU050I
342
DSNU1600I
342
DUMP DUMPCLASS(DB2DP03M)
10:09:28.59 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = SCHUETZSLB
10:09:28.62 DSNUGTIS - PROCESSING SYSIN AS EBCDIC
10:09:28.62 DSNUGUTC - BACKUP SYSTEM DUMP DUMPCLASS(DB2DP03M)
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,
COPYPOOL = DSN$DDFDB21$DB
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,
COPYPOOL = DSN$DDFDB21$LG
TOKEN = X'C4C2F2F1C8CA14F4EB0B7589000F33803DA1'
DATA COMPLETE LRSN = X'000F3383E3FE'
ELAPSED TIME = 00:00:01.
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):
----------------------OPTION ===>
0
1
2
3
4
5
6
7
8
9
10
D2
D3
D4
D5
ISPF PARMS BROWSE
EDIT
UTILITIES
FOREGROUND BATCH
COMMAND
DIALOG TEST LM UTILITIESIBM PRODUCTSSCLM
DB2I 4.2
DB2I 4.2
DB2I 4.1
DB2I 4.2
-
SAP COMMUNITY NETWORK
© 2012 SAP AG
ISPF/PDF PRIMARY OPTION MENU
-----------------------
USERID
Specify terminal and user parameters
TIME
Display source data or output listings TERMINAL
Create or change source data
PF KEYS
Perform utility functions
Invoke language processors in foreground
Submit job for language processing
Enter TSO Command, CLIST, or REXX exec
Perform dialog testing
Perform library administrator utility functions
Additional IBM program development products
Software Configuration and Library Manager
Perform DB2 interactive functions (DSN2)
Perform DB2 interactive functions (DSN3)
Perform DB2 interactive functions (DSN4)
Perform DB2 interactive functions (DSN5)
-
SCHUETZ
15:27
3278
12
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
53
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
D6 DB2I 4.2
- Perform DB2 interactive functions (DSN6)
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
F1=HELP
F2=SPLIT
F3=END
F4=RETURN
F5=RFIND
F7=UP
F8=DOWN
F9=SWAP lis F10=LEFT
F11=RIGHT
F6=RCHANGE
F12=RETRIEVE
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
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 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
COPYPOOL=DSN$DDFDB21$LG
,ALLOWPPRCP FRB=PN FRR=PN
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
54
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
ALLOWPPRCP FRB=PN FRR=PN
VERSION
VTOCENQ
037
N
TOKEN(C)=C'DB21H
DATE
TIME
2011/12/08
10:10:01
4
i
FASTREPLICATIONSTATE
DUMPSTATE
RECOVERABLE
ALLCOMPLETE
ß'
TOKEN(H)=X'C4C2F2F1C8CA14F4EB0B7589000F33803DA1'
TOTAL NUM OF VOLUMES=00001,INCREMENTAL=N,CATINFO=Y,FCFRR=N,RECOVERYINCOMPLETE=N
DUMPCLASS
REQUIRED
DB2DP03M
DUMPSTATE
Y
VOLSSUC
COMPLETE
EXPDATE
00001
AVAILABLE
2012/03/17
Y
HWCOMP
ENCRYPT
ENCTYPE
RSAKEY/KPWD
NO
NONE
*********
*******************************************************
*********
SOURCE
DUMPVOLS
SAPDGL
WA5808
DEVICE TYPE
3490
FILE SEQ=00, DSNAME=SAP.DMP.DB2DP03M.VSAPDGL.D11342.T011010
VERSION
VTOCENQ
033
N
DATE
TIME
2011/11/24
17:10:15
TOKEN(C)=C'DB21H Q
FASTREPLICATIONSTATE
DUMPSTATE
NONE
ALLCOMPLETE
2B '
TOKEN(H)=X'C4C2F2F1C8B8D8CB30E16504000EBAF2C244'
TOTAL NUM OF VOLUMES=00001,INCREMENTAL=N,CATINFO=Y,FCFRR=N,RECOVERYINCOMPLETE=N
DUMPCLASS
REQUIRED
DB2DP03M
DUMPSTATE
Y
VOLSSUC
COMPLETE
EXPDATE
00001
AVAILABLE
2012/03/03
Y
HWCOMP
ENCRYPT
ENCTYPE
RSAKEY/KPWD
NO
NONE
*********
*******************************************************
*********
SOURCE
DUMPVOLS
DEVICE TYPE
FILE SEQ=00, DSNAME=SAP.DMP.DB2DP03M.VSAPDGL.D11328.T151017
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 ===>
NP
?
SCROLL ===> CSR
JOBNAME
JobID
SAff
HSM
STC05260 HSMUSER
ASys Status
PrtDest
15 EXECUTION
SAPB
SAPB
LOCAL
HSM
HSM
STC05261 HSMUSER
15 EXECUTION
SAPM
SAPM
LOCAL
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
Owner
Prty Queue
C
Pos
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
55
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
COMMAND INPUT ===>
SCROLL ===> CSR
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
SYS00002 HSM
105 HSMUSER A
742
SYS00003 HSM
106 HSMUSER A LOCAL
3
SYS00004 HSM
107 HSMUSER A LOCAL
84
SYS00011 HSM
108 HSMUSER A
0
SYS00047 HSM
109 HSMUSER A LOCAL
84
SYS00068 HSM
112 HSMUSER A LOCAL
97
SYS00153 HSM
135 HSMUSER A LOCAL
83
SYS00179 HSM
142 HSMUSER X LOCAL
28
SYS00180 HSM
143 HSMUSER X LOCAL
24
SYS00184 HSM
144 HSMUSER X LOCAL
28
SYS00185 HSM
145 HSMUSER X LOCAL
24
SYS00188 HSM
146 HSMUSER X LOCAL
34
SYS00189 HSM
147 HSMUSER X LOCAL
30
SYS00214 HSM
148 HSMUSER A
0
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 systemlevel 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.
//SCHUETZR JOB USER=SCHUETZ,CLASS=B,MSGCLASS=X,
//
MSGLEVEL=(1,1),REGION=0M
/*JOBPARM SYSAFF=SAPK
//*
//STEP1 EXEC PGM=IKJEFT01
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
56
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
//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:
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
57
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
58
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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):
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
59
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
60
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
DSNU1600I
325 15:30:56.80 DSNUGUTC - BACKUP SYSTEM DATA ONLY ESTABLISH FCINCREMENTAL
325 15:30:57.21 DSNUVBBD - BACKUP SYSTEM UTILITY FOR DATA STARTING,
COPYPOOL = DSN$DDFS231$DB
TOKEN = X'E2F2F3F1C8B4FD1B09C5726CC8B4FBD416A3'.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
61
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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,
COPYPOOL = DSN$DDFS231$DB
TOKEN = X'E2F2F3F1C8B4FD1B09C5726CC8B4FBD416A3'
DATA COMPLETE LRSN = X'C8B4FD2B0792'
ELAPSED TIME = 00:00:20.
A subsequent BACKUP SYSTEM with the same parameters fails because already an incremental
relationship exists:
DSNU050I
DSNU1600I
325 15:32:22.22 DSNUGUTC - BACKUP SYSTEM DATA ONLY ESTABLISH FCINCREMENTAL
325 15:32:22.60 DSNUVBBD - BACKUP SYSTEM UTILITY FOR DATA STARTING,
COPYPOOL = DSN$DDFS231$DB
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
ARC1801I
ARC1801I
ARC1806E
ARC1806E
ARC1802I
ARC1802I
ARC1802I
ARC1802I
FAST REPLICATION BACKUP IS STARTING FOR COPY
(CONT.) POOL DSN$DDFS231$DB, AT 15:32:22 ON 2011/11/21,
(CONT.) TOKEN=X'E2F2F3F1C8B4FD6C777AFD61C8B4FC46878A'
FAST REPLICATION BACKUP HAS FAILED FOR COPY
(CONT.) POOL DSN$DDFS231$DB, RC=0062
FAST REPLICATION BACKUP HAS COMPLETED FOR
(CONT.) COPY POOL DSN$DDFS231$DB, AT 15:32:43 ON 2011/11/21,
(CONT.) FUNCTION RC=0006, MAXIMUM VOLUME RC=0000, CAPTURE
(CONT.) CATALOG RC=0000
The same is true if BACKUP SYSTEM should end such an incremental relationship by:
DSNU050I
DSNU1600I
325 16:13:47.70 DSNUGUTC - BACKUP SYSTEM DATA ONLY END FCINCREMENTAL
325 16:13:48.06 DSNUVBBD - BACKUP SYSTEM UTILITY FOR DATA STARTING,
COPYPOOL = DSN$DDFS231$DB
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'.
SEE THE HSM ACTIVITY LOG FOR HSM MESSAGES INDICATING THE CAUSE OF THE ERROR.
Again BACKUP SYSTEM must address the correct version to end the FCINCREMENTAL copy.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
62
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
VERSION
VTOCENQ
005
N
DATE
TIME
2011/11/21
15:40:51
FASTREPLICATIONSTATE
DUMPSTATE
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
DB2DJ
SAPDJ1 - SAPFJ1
SAPDJ2 - SAPFJ2
SAPDJ3 - SAPFJ3
VERSION
VTOCENQ
004
N
DATE
TIME
2011/11/21
15:35:03
TOKEN(C)=C'S231H©Ú
SOURCE – TARGET
FASTREPLICATIONSTATE
DUMPSTATE
RECOVERABLE
NONE
º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
DB2DJ
SAPDJ1 - SAPFJ4
SAPDJ2 - SAPFJ5
SAPDJ3 - SAPFJ6
SOURCE - TARGET
----- 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
LOG
DATA COMPLETE
RBLP
LRSN
DATA/LOG COMPLETE
DATE
LTIME
LOCATION NAME
----------------
----------------
------------
------------
--------------------
-----------
C8B4FF51BA9A4060
0000000000000000
C8B4FE82BC12
C8B4FF63867E
2011/11/21
15:41:11
DDFS231
2011/11/21
15:35:23
DDFS231
2011/11/21
15:31:17
DDFS231
TOKEN = E2F2F3F1C8B4FF51BA9A4060C8B4FE82BC12
TYPE=I
Z/OS 1.13
C8B4FE059BF6C0E1
0000000000000000
C8B4FC7AF4D0
C8B4FE179486
TOKEN = E2F2F3F1C8B4FE059BF6C0E1C8B4FC7AF4D0
Z/OS 1.13
C8B4FD1B09C5726C
0000000000000000
C8B4FBD416A3
C8B4FD2B0792
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
63
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
Data Columns 15-17 of 47
DS Name : ACTIVE
Enter Line Operators below:
LINE
OPERATOR
---(1)----
COPY POOL NAME
-------------(2)-------------DSN$DDFDB21$DB
DSN$DDFDB21$LG
FCTOPPRC
FRRECOV
--(15)-PMNO
PMNO
CATINFO
--(16)--REQUIRED
REQUIRED
ALLOW
FCFRR
(17)YES
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
/*JOBPARM SYSAFF=SAPK
//***************************************************
//* 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,
//
MSGCLASS=X,MSGLEVEL=(1,1),
//
TIME=120,CLASS=A,REGION=0M
/*JOBPARM SYSAFF=SAPK
//*
//STEP1 EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSTSIN DD *
HSEND LIST COPYPOOL(DSN$DDFDB21$DB) DUMPVOLS
HSEND LIST COPYPOOL(DSN$DDFDB21$LG) DUMPVOLS
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
64
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
/*
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
ALLOWPPRCP FRB=PN FRR=PN
VERSION VTOCENQ
DATE
TIME
FASTREPLICATIONSTATE DUMPSTATE
031
N
2012/02/13
23:04:36
RECOVERABLE
NONE
TOKEN(C)=C'DB21I
S r
$'
TOKEN(H)=X'C4C2F2F1C91EFF2C68E28E990013DC9A5B'
TOTAL NUM OF VOLUMES=00003,INCREMENTAL=Y,CATINFO=Y,FCFRR=Y,RECOVERYINCOMPLETE=N
DUMPCLASS
DB2DP03M
REQUIRED
Y
DUMPSTATE
COMPLETE
VOLSSUC
00003
EXPDATE
2012/05/23
AVAILABLE
Y
COPYPOOL=DSN$DDFDB21$LG
ALLOWPPRCP FRB=PN FRR=PN
VERSION VTOCENQ
DATE
TIME
FASTREPLICATIONSTATE DUMPSTATE
046
N
2012/02/13
23:05:25
RECOVERABLE
NONE
TOKEN(C)=C'DB21I
S r
$'
TOKEN(H)=X'C4C2F2F1C91EFF2C68E28E990013DC9A5B'
TOTAL NUM OF VOLUMES=00001,INCREMENTAL=N,CATINFO=Y,FCFRR=Y,RECOVERYINCOMPLETE=N
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
ARC1820I
ARC1820I
ARC1820I
ARC1820I
ARC1820I
ARC1820I
THE FOLLOWING VOLUMES IN COPY POOL DSN$DDFDB21$LG, VERSION 046, HAVE
(CONT.) AN ACTIVE FLASHCOPY BACKGROUND COPY
(CONT.) SGNAME
FR-PRIMARY FR-BACKUP PCT-COMP
(CONT.) DB2DGL
SAPDGL
SAPFGL
067
THE FOLLOWING VOLUMES IN COPY POOL DSN$DDFDB21$DB, VERSION 031, HAVE
(CONT.) AN ACTIVE FLASHCOPY BACKGROUND COPY
(CONT.) SGNAME
FR-PRIMARY FR-BACKUP PCT-COMP
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
65
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
ARC1820I (CONT.) DB2DG
SAPDG1
SAPFG1
ARC1820I (CONT.) DB2DG
SAPDG2
SAPFG2
ARC1820I (CONT.) DB2DG
SAPDG3
SAPFG3
IKJ56250I JOB HSENDS01(JOB00860) SUBMITTED
***
048
047
075
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.
COPYPOOL=DSN$DDFDB21$DB
ALLOWPPRCP FRB=PN FRR=PN
VERSION VTOCENQ
DATE
TIME
FASTREPLICATIONSTATE DUMPSTATE
031
N
2012/02/13
23:04:36
RECOVERABLE
ALLCOMPLETE
TOKEN(C)=C'DB21I
S r
$'
TOKEN(H)=X'C4C2F2F1C91EFF2C68E28E990013DC9A5B'
TOTAL NUM OF VOLUMES=00003,INCREMENTAL=Y,CATINFO=Y,FCFRR=Y,RECOVERYINCOMPLETE=N
COPYPOOL=DSN$DDFDB21$LG
ALLOWPPRCP FRB=PN FRR=PN
VERSION VTOCENQ
DATE
TIME
FASTREPLICATIONSTATE DUMPSTATE
046
N
2012/02/13
23:05:25
RECOVERABLE
ALLCOMPLETE
TOKEN(C)=C'DB21I
S r
$'
TOKEN(H)=X'C4C2F2F1C91EFF2C68E28E990013DC9A5B'
TOTAL NUM OF VOLUMES=00001,INCREMENTAL=N,CATINFO=Y,FCFRR=Y,RECOVERYINCOMPLETE=N
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 (CONT.) ACTIVE FLASHCOPY BACKGROUND COPY
ARC1821I NONE OF THE VOLUMES IN COPY POOL DSN$DDFDB21$DB, VERSION 031, HAVE AN
ARC1821I (CONT.) ACTIVE FLASHCOPY BACKGROUND COPY
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,
//
MSGCLASS=X,MSGLEVEL=(1,1),
//
TIME=120,CLASS=A,REGION=0M
//*ROUTE
XEQ
BOECOB1
/*JOBPARM SYSAFF=SAPK
//*
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
66
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
//************************************************
//* FCQUERY DEVN(NNNN)
//************************************************
//*
//STEP1 EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//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
8E00 8E00 0E 00 2107 0000000AVPD1
ANTF0001I FCQUERY COMMAND COMPLETED
READY
FCQUERY DEVN(8E01)
ANTF0420I FCQUERY Formatted -3
DEVN SSID LSS CCA CU
SERIAL
8E01 8E00 0E 01 2107 0000000AVPD1
ANTF0001I FCQUERY COMMAND COMPLETED
READY
FCQUERY DEVN(8E02)
ANTF0420I FCQUERY Formatted -3
DEVN SSID LSS CCA CU
SERIAL
8E02 8E00 0E 02 2107 0000000AVPD1
ANTF0001I FCQUERY COMMAND COMPLETED
READY
FCQUERY DEVN(8E20)
ANTF0420I FCQUERY Formatted -3
DEVN SSID LSS CCA CU
SERIAL
8E20 8E00 0E 20 2107 0000000AVPD1
ANTF0001I FCQUERY COMMAND COMPLETED
READY
END
ACT
MAX XC PC CC RV SE SEQNUM
1 65534 N P N N NN 00000000
FOR DEVICE 8E00, COMPLETION CODE: 00
ACT
MAX XC PC CC RV SE SEQNUM
1 65534 N P N N NN 00000000
FOR DEVICE 8E01, COMPLETION CODE: 00
ACT
MAX XC PC CC RV SE SEQNUM
1 65534 N P N N NN 00000000
FOR DEVICE 8E02, COMPLETION CODE: 00
ACT
MAX XC PC CC RV SE SEQNUM
0 65534 N P N N NN 00000000
FOR DEVICE 8E20, COMPLETION CODE: 00
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
67
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments


Both can be used in a Fast Reverse Restore (FCFRR)
Neither one was dumped to tape
COPYPOOL=DSN$DDFDB21$DB
ALLOWPPRCP FRB=PN FRR=PN
VERSION VTOCENQ
DATE
TIME
FASTREPLICATIONSTATE DUMPSTATE
032
N
2012/02/14
18:12:20
RECOVERABLE
NONE
TOKEN(C)=C'DB21I
.'
TOKEN(H)=X'C4C2F2F1C91FFFB6360380240014181FFA'
TOTAL NUM OF VOLUMES=00003,INCREMENTAL=Y,CATINFO=Y,FCFRR=Y,RECOVERYINCOMPLETE=N
COPYPOOL=DSN$DDFDB21$LG
ALLOWPPRCP FRB=PN FRR=PN
VERSION VTOCENQ
DATE
TIME
FASTREPLICATIONSTATE DUMPSTATE
047
N
2012/02/14
18:12:52
RECOVERABLE
NONE
TOKEN(C)=C'DB21I
.'
TOKEN(H)=X'C4C2F2F1C91FFFB6360380240014181FFA'
TOTAL NUM OF VOLUMES=00001,INCREMENTAL=N,CATINFO=Y,FCFRR=Y,RECOVERYINCOMPLETE=N
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
RBLP
LRSN
---------------- ---------------- ------------ -----------C91FFFB636038024 C91FFFD3FD4F47D9 0014181FFA00 001418204B22
TOKEN = C4C2F2F1C91FFFB6360380240014181FFA00
Z/OS 1.13 CAT=YES
C91EFF2C68E28E99 C91EFF5AB8C8C759 0013DC9A5B00 0013DC9D7DD7
TOKEN = C4C2F2F1C91EFF2C68E28E990013DC9A5B00
Z/OS 1.13 CAT=YES
DATA/LOG COMPL
DATE
LTI
---------------2012/02/14 18:1
TYPE=I
2012/02/13
TYPE=I
23:0
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
/*
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
68
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
ARC1805I (CONT.) SAPDG2
ARC1805I (CONT.) SAPDG3
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
69
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
ANTF0420I
DEVN SSID
8E00 8E00
ANTF0001I
READY
FCQUERY
ANTF0420I
DEVN SSID
8E01 8E00
ANTF0001I
READY
FCQUERY
ANTF0420I
DEVN SSID
8E02 8E00
ANTF0001I
READY
END
DEVN(8E00)
FCQUERY Formatted -3
LSS CCA CU
SERIAL
ACT
MAX XC PC CC RV SE SEQNUM
0E 00 2107 0000000AVPD1
0 65534 N P N N NN 00000000
FCQUERY COMMAND COMPLETED FOR DEVICE 8E00, COMPLETION CODE: 00
DEVN(8E01)
FCQUERY Formatted -3
LSS CCA CU
SERIAL
ACT
MAX XC PC CC RV SE SEQNUM
0E 01 2107 0000000AVPD1
0 65534 N P N N NN 00000000
FCQUERY COMMAND COMPLETED FOR DEVICE 8E01, COMPLETION CODE: 00
DEVN(8E02)
FCQUERY Formatted -3
LSS CCA CU
SERIAL
ACT
MAX XC PC CC RV SE SEQNUM
0E 02 2107 0000000AVPD1
0 65534 N P N N NN 00000000
FCQUERY COMMAND COMPLETED FOR DEVICE 8E02, COMPLETION CODE: 00
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:
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
70
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
DSNU050I
319 12:13:27.95 DSNUGUTC - BACKUP SYSTEM DATA ONLY
DSNU1600I
319 12:13:28.31 DSNUVBBD - BACKUP SYSTEM UTILITY FOR DATA STARTING,
COPYPOOL = DSN$DDFS231$DB
TOKEN = X'E2F2F3F1C8AD45C6475DC5AEC8AD4460EF57'.
DSNU1614I
319 12:13:48.72 DSNUVBBD - BACKUP SYSTEM UTILITY FOR DATA COMPLETED SUCCESSFULLY,
COPYPOOL = DSN$DDFS231$DB
TOKEN = X'E2F2F3F1C8AD45C6475DC5AEC8AD4460EF57'
DATA COMPLETE LRSN = X'C8AD45D8FA67'
ELAPSED TIME = 00:00:20.
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.) DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001, AT 13:58:16 ON
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:
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
71
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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 -
DSNU1520I
319 13:42:16.73 DSNUCBMT - THE RECOVERY BASE FOR TABLESPACE HARTDB.HARTTS1
RECOVER TABLESPACE HARTDB.HARTTS1 TABLESPACE HARTDB.HARTTS2
IS THE
SYSTEM LEVEL BACKUP WITH DATE = 20111115, TIME 121348, AND TOKEN
X'E2F2F3F1C8AD45C6475DC5AEC8AD4460EF57'
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
72
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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 FAST REPLICATION DATA SET RECOVERY IS
ARC1801I (CONT.) STARTING FOR DATA SET
ARC1801I (CONT.) DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001, AT 13:42:16 ON
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
ARC1802I FAST REPLICATION DATA SET RECOVERY HAS
ARC1802I (CONT.) COMPLETED FOR DATA SET
ARC1802I (CONT.) DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001, AT 13:42:16 ON
ARC1802I (CONT.) 2011/11/15, FUNCTION RC=0008, MAXIMUM DATA SET RC=0093
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:
ARC1860I (CONT.) DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001, COPYPOOL=DSN$DDFS231$DB,
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:
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
73
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
DEFAULT TO YES
ARC0640I GDSN01
ARC0640I GDSN01
ARC0640I GDSN01
ARC0640I GDSN01
ARC0640I GDSN01
ARC0640I GDSN01
ARC0640I GDSN01
ARC0640I GDSN01
ARC0640I GDSN01
ARC0640I GDSN01
'
- ADR035I (SCH)-PRIME(06), INSTALLATION EXIT ALTERED BYPASS FAC CLASS CHK
- COPY DS(INC(DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001
)) - PHYSINDY(SAPFJ5) OUTDYNAM(SAPDJ2) - BYPASSACS(DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001
) - ALLDATA(*) ALLEXCP REPLACEU CANCELERROR - FORCECP(0) PROCESS(SYS1) - STORCLAS(DB2DJ
) - MGMTCLAS(DB2
) - DEBUG(FRMSG(DTL)) - FASTREPLICATION(NONE
)
- ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'COPY
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
74
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
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 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)
FROMCOPYPOOL(DSN$DDFS231$DB)
FR(PREFERRED) VERSION(1)
REPLACE
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 - COPY DS(INC(DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001
)) ARC0640I GDSN01 - PHYSINDY(SAPFJ3) 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(PREFERRED)
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
75
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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'
//SYSPRINT DD SYSOUT=*
//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:
DSNU050I
325 15:57:48.80 DSNUGUTC -
DSNU1520I
325 15:57:48.97 DSNUCBMT - THE RECOVERY BASE FOR TABLESPACE HARTDB.HARTTS1
RECOVER TABLESPACE HARTDB.HARTTS1 TABLESPACE HARTDB.HARTTS2
IS THE
SYSTEM LEVEL BACKUP WITH DATE = 20111121, TIME 154111, AND TOKEN
X'E2F2F3F1C8B4FF51BA9A4060C8B4FE82BC12'
DSNU1527I
325 15:57:51.49 DSNUCBMT - TABLESPACE HARTDB.HARTTS1 DSNUM 1 WAS SUCCESSFULLY RESTORED
FROM A FLASHCOPY, ELAPSED TIME=00:00:02
DSNU1520I
325 15:57:51.49 DSNUCBMT - THE RECOVERY BASE FOR TABLESPACE HARTDB.HARTTS2
IS THE
SYSTEM LEVEL BACKUP WITH DATE = 20111121, TIME 154111, AND TOKEN
X'E2F2F3F1C8B4FF51BA9A4060C8B4FE82BC12'
DSNU1527I
325 15:57:53.93 DSNUCBMT - TABLESPACE HARTDB.HARTTS2 DSNUM 1 WAS SUCCESSFULLY RESTORED
FROM A FLASHCOPY, ELAPSED TIME=00:00:02
DSNU1511I -S231 325 15:57:53.99 DSNUCALA - FAST LOG APPLY WAS NOT USED FOR RECOVERY
…
HSM generates the following DFDSS COPY commands:
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
)) -
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
76
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
ARC0640I GDSN01 -
PHYSINDY(SAPFJ2) OUTDYNAM(SAPDJ2) -
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 '
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:
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(SAPFJ2) OUTDYNAM(SAPDJ2) -
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(PREFERRED)
)) ) -
ARC0640I GDSN01 - ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'COPY '
…
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
ARC0640I GDSN01 -
COMPONENT NAME DB23.DSNDBD.HARTDB.HARTTS1.I0001.A001
DB23.DSNDBC.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..
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
77
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
FASTREPLICATION (DATASETRECOVERY (REQUIRED))
RECOVER now does not run because two FlashCopy relations cannot exist at one time.
DSNU050I
325 16:03:55.52 DSNUGUTC -
DSNU1520I
325 16:03:55.54 DSNUCBMT - THE RECOVERY BASE FOR TABLESPACE HARTDB.HARTTS1
RECOVER TABLESPACE HARTDB.HARTTS1 TABLESPACE HARTDB.HARTTS2
IS THE
SYSTEM LEVEL BACKUP WITH DATE = 20111121, TIME 154111, AND TOKEN
X'E2F2F3F1C8B4FF51BA9A4060C8B4FE82BC12'
DSNU1522I
325 16:03:57.96 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 325 16:03:57.97 DSNUGSRX - TABLESPACE HARTDB.HARTTS1 IS IN RECOVER PENDING
HSM issues the following messages:
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(SAPFJ2) OUTDYNAM(SAPDJ2) -
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(REQUIRED )
)) ) -
ARC0640I GDSN01 - ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'COPY '
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:
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
78
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
DSNU050I
326 08:55:43.79 DSNUGUTC - RECOVER TABLESPACE HARTDB.HARTTS1 TABLESPACE HARTDB.HARTTS2
DSNU1520I
326 08:55:43.90 DSNUCBMT - THE RECOVERY BASE FOR TABLESPACE HARTDB.HARTTS1
IS THE
SYSTEM LEVEL BACKUP WITH DATE = 20111122, TIME 085400, AND TOKEN
X'E2F2F3F1C8B5E62A86262429C8B5E52E546A'
DSNU1522I
326 08:55:43.92 DSNUCBMT - THE DFSMSHSM CALL TO RESTORE TABLESPACE HARTDB.HARTTS1 DSNUM
1
FAILED WITH RC = X'00000042' AND REASON CODE = X'0000001C'
SEE THE JOB LOG FOR DFSMSHSM MESSAGES INDICATING THE CAUSE OF THE ERROR
DSNU562I
-S231 326 08:55:43.94 DSNUGSRX - TABLESPACE HARTDB.HARTTS1 IS IN RECOVER PENDING
The already active BACKUP SYSTEM creates the following SLB:
DSNU050I
326 08:55:37.89 DSNUGUTC - BACKUP SYSTEM DATA ONLY
DSNU1600I
326 08:55:38.26 DSNUVBBD - BACKUP SYSTEM UTILITY FOR DATA STARTING,
COPYPOOL = DSN$DDFS231$DB
TOKEN = X'E2F2F3F1C8B5E69C583E5CAEC8B5E5A0C556'.
DSNU1614I
326 08:55:59.15 DSNUVBBD - BACKUP SYSTEM UTILITY FOR DATA COMPLETED SUCCESSFULLY,
COPYPOOL = DSN$DDFS231$DB
TOKEN = X'E2F2F3F1C8B5E69C583E5CAEC8B5E5A0C556'
DATA COMPLETE LRSN = X'C8B5E6AD8E66'
ELAPSED TIME = 00:00:20.
DSNU1602I
326 08:56:03.62 DSNUVBBD - BACKUP SYSTEM UTILITY COMPLETED, ELAPSED TIME = 00:00:25.
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 FAST REPLICATION DATA SET RECOVERY IS
ARC1801I (CONT.) STARTING FOR DATA SET
ARC1801I (CONT.) DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001, AT 08:55:43 ON
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
ARC1802I FAST REPLICATION DATA SET RECOVERY HAS
ARC1802I (CONT.) COMPLETED FOR DATA SET
ARC1802I (CONT.) DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001, AT 08:55:43 ON
ARC1802I (CONT.) 2011/11/22, FUNCTION RC=0008, MAXIMUM DATA SET RC=0066
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:
DSNU050I
348 18:27:45.97 DSNUGUTC - BACKUP SYSTEM DATA ONLY
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
79
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
DSNU1600I
348 18:27:46.32 DSNUVBBD - BACKUP SYSTEM UTILITY FOR DATA STARTING,
COPYPOOL = DSN$DDFS231$DB
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'.
SEE THE HSM ACTIVITY LOG FOR HSM MESSAGES INDICATING THE CAUSE OF THE ERROR.
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 FAST REPLICATION DATA SET RECOVERY IS
ARC1801I (CONT.) STARTING FOR DATA SET
ARC1801I (CONT.) DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001, AT 18:27:41 ON
ARC1801I (CONT.) 2011/12/14
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.) DB23.DSNDBC.HARTDB.HARTTS1.I0001.A001, AT 18:27:44 ON
ARC1802I (CONT.) 2011/12/14, FUNCTION RC=0000, MAXIMUM DATA SET RC=0000
ARC1801I FAST REPLICATION DATA SET RECOVERY IS
ARC1801I (CONT.) STARTING FOR DATA SET
ARC1801I (CONT.) DB23.DSNDBC.HARTDB.HARTTS2.I0001.A001, AT 18:27:44 ON
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,
ARC1802I (CONT.) FUNCTION RC=0006, MAXIMUM VOLUME RC=0000
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.HARTTS2.I0001.A001, COPYPOOL=DSN$DDFS231$DB,
DEVTYPE=DASD
ARC1802I FAST REPLICATION DATA SET RECOVERY HAS
ARC1802I (CONT.) COMPLETED FOR DATA SET
ARC1802I (CONT.) DB23.DSNDBC.HARTDB.HARTTS2.I0001.A001, AT 18:27:46 ON
ARC1802I (CONT.) 2011/12/14, FUNCTION RC=0000, MAXIMUM DATA SET RC=0000
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
80
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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:
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
81
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments






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 THE FOLLOWING VOLUMES IN COPY POOL DSN$DDFDB22$LG, VERSION 026, HAVE
ARC1820I (CONT.) AN ACTIVE FLASHCOPY BACKGROUND COPY
ARC1820I (CONT.) SGNAME
FR-PRIMARY FR-BACKUP PCT-COMP
ARC1820I (CONT.) DB2DIL
SAPDIL
SAPFIL
001
ARC1820I THE FOLLOWING VOLUMES IN COPY POOL DSN$DDFDB22$DB, VERSION 018, 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
007
ARC1820I (CONT.) DB2DI
SAPDI3
SAPFI3
002
IKJ56250I JOB HSENDS24(JOB10864) SUBMITTED
***
The current backup for DSN$DDFDB22$DB is available to be used in a Fast Replication Restore process.
COPYPOOL=DSN$DDFDB22$DB
VERSION VTOCENQ
DATE
TIME
FASTREPLICATIONSTATE DUMPSTATE
018
N
2012/01/25
16:49:49
RECOVERABLE
ALLCOMPLETE
TOKEN(C)=C'DB22I G7 §/a 3 "'
TOKEN(H)=X'C4C2F2F2C906C7F73D7C61810012F3BF8C7F'
TOTAL NUM OF VOLUMES=00003,INCREMENTAL=N,CATINFO=Y,FCFRR=Y,RECOVERYINCOMPLETE=N
DUMPCLASS
DB2DP03M
REQUIRED
Y
HWCOMP
NO
DUMPSTATE
COMPLETE
ENCRYPT
NONE
VOLSSUC
00003
ENCTYPE
*********
EXPDATE
2012/05/04
AVAILABLE
Y
RSAKEY/KPWD
****************************************
SOURCE
DUMPVOLS
DEVICE TYPE
SAPDI1
WA4989
3490
FILE SEQ=00, DSNAME=SAP.DMP.DB2DP03M.VSAPDI1.D12025.T494916
SAPDI2
WA4286 WA4288
3490
FILE SEQ=00, DSNAME=SAP.DMP.DB2DP03M.VSAPDI2.D12025.T494916
SAPDI3
WA4284
3490
FILE SEQ=00, DSNAME=SAP.DMP.DB2DP03M.VSAPDI3.D12025.T494916
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
82
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
//REORG25A JOB (DE03557),CH,NOTIFY=MARY,
//
MSGCLASS=X,MSGLEVEL=(1,1),
//
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
FAST REPLICATION FUNCTION
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
TIMESTAMP
DEV TYPE
LOW DSNUM
JOBNAME
,
, MEMBER NAME =
= 2012-01-25-19.47.02.604436, IC TYPE = *W*, SHR LVL = , DSNUM
=
,
IC BACK =
,
STYPE
= , FILE SEQ
= 0000,
HIGH DSNUM = 0000,
OLDEST VERSION = 0000,
LOGICAL PART
= REORG25A,
AUTHID =
MARY
,
COPYPAGESF = -1.0E+00
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
83
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
NPAGESF
DSNAME
= -1.0E+00
= DSN00011.REPOSRC
TIMESTAMP
DEV TYPE
LOW DSNUM
JOBNAME
NPAGESF
DSNAME
=
=
=
=
=
=
,
CPAGESF = -1.0E+00
, MEMBER NAME =
2012-01-25-19.47.03.133331, IC TYPE = F , SHR LVL = R, DSNUM
,
IC BACK = FC,
STYPE
= T, FILE SEQ
0001,
HIGH DSNUM = 0001,
OLDEST VERSION = 0000,
LOGICAL PART
REORG25A,
AUTHID =
MARY
,
COPYPAGESF = -1.0E+00
-1.0E+00
,
CPAGESF = -1.0E+00
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
//SYSPRINT DD SYSOUT=*
//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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
84
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
85
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments

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:
DB21_A
DB21_B
PPRC CopyPool
data/log
CopyPool data/log
DB2DG
…
1.
2.
3.
1.
2.
3.
SAPDG1
SAPDG2
SAPDG3
DB2DGL
…
1.
1.
SAPDGL
SAPDH1
SAPDH2
SAPDH3
SAPDHL
RPFC Backup
CopyPool data/log
Backup CopyPool
data/log
DB2FG
…
1.
2.
3.
1.
2.
3.
SAPFG1
SAPFG2
SAPFG3
DB2FGL
…
1.
1.
SAPFGL
SAPFH1
SAPFH2
SAPFH3
SAPFHL
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
//
00003000
MSGLEVEL=(1,1),MSGCLASS=X,NOTIFY=&SYSUID
/*JOBPARM SYSAFF=*
00004004
//*
00005000
//*******DB2 BACKUP SYSTEM *************************************
00006000
//BACKUP EXEC DSNUPROC,SYSTEM=DB21,
00007001
//DSNUPROC.SYSIN
00009001
DD
SAP COMMUNITY NETWORK
© 2012 SAP AG
*
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
86
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
87
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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('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('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('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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
88
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
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
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
89
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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('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('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('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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
90
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
--------------------------------------------------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
--------------------------------------------------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('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('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('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
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
1
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
91
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
92
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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:
DSNU1044I
356 11:28:48.69 DSNUGTIS - PROCESSING SYSIN AS EBCDIC
DSNU050I
356 11:28:48.69 DSNUGUTC -
DSNU1600I
356 11:28:48.73 DSNUVBBD - BACKUP SYSTEM UTILITY FOR DATA STARTING,
BACKUP SYSTEM FULL
COPYPOOL = DSN$DDFDB21$DB
TOKEN = X'C4C2F2F1C8DBC0CCE1F82304000FC98B1832'.
DSNU1614I
356 11:29:20.29 DSNUVBBD - BACKUP SYSTEM UTILITY FOR DATA COMPLETED SUCCESSFULLY,
COPYPOOL = DSN$DDFDB21$DB
TOKEN = X'C4C2F2F1C8DBC0CCE1F82304000FC98B1832'
DATA COMPLETE LRSN = X'000FC98F4A30'
ELAPSED TIME = 00:00:31.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
93
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
DSNU1600I
356 11:29:20.29 DSNUVBBD - BACKUP SYSTEM UTILITY FOR LOGS STARTING,
COPYPOOL = DSN$DDFDB21$LG
TOKEN = X'C4C2F2F1C8DBC0CCE1F82304000FC98B1832'.
DSNU1614I
356 11:29:21.46 DSNUVBBD - BACKUP SYSTEM UTILITY FOR LOGS COMPLETED SUCCESSFULLY,
COPYPOOL = DSN$DDFDB21$LG
TOKEN = X'C4C2F2F1C8DBC0CCE1F82304000FC98B1832'
DATA COMPLETE LRSN = X'000FC98F4A30'
ELAPSED TIME = 00:00:01.
DSNU1602I
356 11:29:22.33 DSNUVBBD - BACKUP SYSTEM UTILITY COMPLETED, ELAPSED TIME = 00:00:33.
DSNU010I
356 11:29:22.33 DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=0
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:
//SCHUETZR JOB USER=SCHUETZ,CLASS=B,MSGCLASS=X,
//
MSGLEVEL=(1,1),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
/*
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
94
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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,
//
MSGLEVEL=(1,1),REGION=0M
/*JOBPARM SYSAFF=SAPK
//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
DSNU1044I
356 11:52:00.04 DSNUGTIS - PROCESSING SYSIN AS EBCDIC
DSNU050I
356 11:52:00.05 DSNUGUTC -
DSNU1606I
356 11:52:00.05 DSNUVBRD - RESTORE SYSTEM UTILITY STARTING,
RESTORE SYSTEM
COPYPOOL = DSN$DDFDB21$DB
TOKEN = X'C4C2F2F1C8DBC0CCE1F82304000FC98B1832'.
DSNU1627I
356 11:52:03.13 DSNUVBRD - RESTORE SYSTEM PRE-LOG APPLY COMPLETED SUCCESSFULLY,
COPYPOOL = DSN$DDFDB21$DB
TOKEN = X'C4C2F2F1C8DBC0CCE1F82304000FC98B1832'
ELAPSED TIME = 00:00:03.
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.
DSNU010I
356 11:53:12.76 DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=4
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
95
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
12:02:36.73 STC07285 00000080
12:02:36.73 STC07285 00000080
370 00000080
12:02:36.73 STC07285 00000080
12:02:36.73 STC07285 00000080
372
372 00000080
12:02:36.73 STC07285 00000080
373 00000080
PHYERRHI CATALOG PIECE
373 00000080
- ----373 00000080
373 00000080
373 00000080
ENDED
************
-DB21 DISPLAY DB(*) SPACENAM(*) RESTRICT(RECP)
DSNT360I -DB21 ***********************************
DSNT361I -DB21 * DISPLAY DATABASE SUMMARY 370
*
RESTRICTED
DSNT360I -DB21 ***********************************
DSNT362I -DB21
DATABASE = DSN07230 STATUS = RW
DBD LENGTH = 4028
DSNT397I -DB21 373
NAME
TYPE PART STATUS
PHYERRLO
-------- ---- ----- ----------------- -------- ------SNAP
TS
0001 RW,RECP
SNAP
TS
RW,RECP
******* DISPLAY OF DATABASE DSN07230
To recover the SNAP tablespace, you can go to the SAP DBA Cockpit to recover this object:
Screenshot 24. DBA Planning Calendar
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
96
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
97
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
12:04:04.81 SCHUETZ
-DB21 DISPLAY DB(*) SPACENAM(*) RESTRICT(RBDP)
00000290
-DB21 DSNTDDIS 'DISPLAY DATABASE' NORMAL COMPLETION
12:04:04.81 STC07285 00000080
DSNT360I
-DB21 ***********************************
12:04:04.81 STC07285 00000080
DSNT361I
-DB21 *
377 00000080
*
DISPLAY DATABASE SUMMARY 377
RESTRICTED
12:04:04.81 STC07285 00000080
DSNT360I
-DB21 ***********************************
12:04:04.81 STC07285 00000080
DSNT362I
-DB21
DATABASE = DSN07230
379 00000080
12:04:04.81 STC07285 00000080
STATUS = RW 379
DBD LENGTH = 4028
DSNT397I
-DB21 380
380 00000080
NAME
TYPE PART
380 00000080
-------- ---- ----- ----------------- -------- -------- -----
STATUS
PHYERRLO PHYERRHI CATALOG
380 00000080
SNAPH0
IX
380 00000080
SNAPH0
IX
380 00000080
SNAPHDSX IX
380 00000080
SNAPHDSX IX
380 00000080
******* DISPLAY OF DATABASE DSN07230 ENDED
L0001 RW,RBDP,PSRBD
L*
RW,RBDP,PSRBD
L0001 RW,RBDP,PSRBD
L*
RW,RBDP,PSRBD
*************
12:04:04.81 STC07285 00000080
DSNT360I
-DB21 ***********************************
12:04:04.81 STC07285 00000080
DSNT362I
-DB21
382 00000080
12:04:04.82 STC07285 00000080
PIECE
DATABASE = SAPR3
STATUS = RW 382
DBD LENGTH = 36332
DSNT397I
-DB21 383
383 00000080
NAME
383 00000080
-------- ---- ----- ----------------- -------- -------- ------
383 00000080
QX000102 IX
383 00000080
******* DISPLAY OF DATABASE SAPR3
12:04:04.82 STC07285 00000080
DSN9022I
TYPE PART
STATUS
PHYERRLO PHYERRHI CATALOG
PIECE
RW,RBDP
ENDED
*************
-DB21 DSNTDDIS 'DISPLAY DATABASE' NORMAL COMPLETION
These indexes can be rebuilt using the Planning Calendar from SAP DBA Cockpit:
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
98
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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 systemlevel 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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
99
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
100
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
101
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
102
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
103
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
104
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
105
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
106
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
107
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
108
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
109
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
110
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
ARC1820I
ARC1820I
ARC1820I
THE FOLLOWING VOLUMES IN COPY POOL DSN$DDFDB22$LG, VERSION 006, HAVE
(CONT.) AN ACTIVE FLASHCOPY BACKGROUND COPY
(CONT.) SGNAME
FR-PRIMARY FR-BACKUP PCT-COMP
(CONT.) DB2DIL
SAPDIL
SAPFIL
011
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
111
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
ARC1820I
ARC1820I
ARC1820I
ARC1820I
ARC1820I
ARC1820I
***
THE FOLLOWING VOLUMES IN COPY POOL DSN$DDFDB22$DB, VERSION 003, HAVE
(CONT.) AN ACTIVE FLASHCOPY BACKGROUND COPY
(CONT.) SGNAME
FR-PRIMARY FR-BACKUP PCT-COMP
(CONT.) DB2DI
SAPDI1
SAPFI1
002
(CONT.) DB2DI
SAPDI2
SAPFI2
002
(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
BEGIN CHECKPOINT RBA
END CHECKPOINT RBA
END CHECKPOINT STCK
TIME OF CHECKPOINT
BEGIN CHECKPOINT RBA
END CHECKPOINT RBA
END CHECKPOINT STCK
14:44:42 NOVEMBER 09, 2011  Second initiated DB2 system checkpoint
000C6A98C616
000C6A99C000
C8A5E9CC1F54
14:44:14 NOVEMBER 09, 2011  First initiated DB2 system checkpoint
000C6A976E27  ‘PRIOR CHECKPOINT RBA’ in Recover job output
000C6A98778E  TOLOGPOINT used in recovery jobs
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:
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
112
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
DSNT360I
DSNT361I
DSNT360I
DSNT362I
DSNT397I
NAME
-------USR01H0
USR01H0
USR01H00
USR01H00
USR012SX
USR012SX
USR01DVX
USR01DVX
DSNT362I
-DB22 ***********************************
-DB22 * DISPLAY DATABASE SUMMARY
*
RESTRICTED
-DB22 ***********************************
-DB22
DATABASE = DSN09198 STATUS = RW
DBD LENGTH = 8066
-DB22
TYPE PART STATUS
PHYERRLO PHYERRHI CAT
---- ----- ----------------- -------- -------- --IX
L0001 RW,RBDP*
IX
L*
RW,RBDP*
IX
L0001 RW,RBDP*
IX
L*
RW,RBDP*
IX
L0001 RW,RBDP*
IX
L*
RW,RBDP*
IX
L0001 RW,RBDP*
IX
L*
RW,RBDP*
-DB22
DATABASE = DSN09202
DBD LENGTH = 8066
STATUS = RW
DSNT397I -DB22
NAME
TYPE PART STATUS
PHYERRLO PHYERRHI CATALOG PIECE
-------- ---- ----- ----------------- -------- -------- -------- ----USR02H0 IX
L0001 RW,RBDP*
USR02H0 IX
L*
RW,RBDP*
USR02H00 IX
L0001 RW,RBDP*
USR02H00 IX
L*
RW,RBDP*
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 timestamps 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:
//SCHUETZR JOB USER=SCHUETZ,CLASS=B,MSGCLASS=X,
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
113
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
//
MSGLEVEL=(1,1),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,SYSPITRT=20120161109073
/*
The DSNJU003 job to specify the conditional restart record for DB22 is equivalent.
//SCHUETZR JOB USER=SCHUETZ,CLASS=B,MSGCLASS=X,
//
MSGLEVEL=(1,1),REGION=0M
/*JOBPARM SYSAFF=SAPK
//*
//CRCR01B EXEC PGM=DSNJU003,REGION=016M,COND=(4,LT)
//STEPLIB DD DISP=SHR,DSN=DB22L.V100.SDSNEXIT
//
DD DISP=SHR,DSN=DB22L.V100.SDSNLOAD
//SYSPRINT DD SYSOUT=*
//SYSUT1
DD DISP=SHR,DSN=DB22L.BSDS01
//SYSUT2
DD DISP=SHR,DSN=DB22L.BSDS02
//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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
114
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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,
//
MSGCLASS=X,MSGLEVEL=(1,1),
//
TIME=120,CLASS=A,REGION=0M
/*JOBPARM SYSAFF=SAPK
//*
//*****************************************************
//* STEP BACKUP: RUN BACKUP SYSTEM DB22
//*****************************************************
//BACKUP EXEC DSNUPROC,SYSTEM=DB22,
//
UID='MARY',LIB=DB22L.V100.SDSNLOAD
//DSNUPROC.SYSIN DD *
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.
ARC1820I THE FOLLOWING VOLUMES IN COPY POOL DSN$DDFDB22$LG, VERSION 012, HAVE
ARC1820I (CONT.) AN ACTIVE FLASHCOPY BACKGROUND COPY
ARC1820I (CONT.) SGNAME
FR-PRIMARY FR-BACKUP PCT-COMP
ARC1820I (CONT.) DB2DIL
SAPDIL
SAPFIL
088
ARC1821I NONE OF THE VOLUMES IN COPY POOL DSN$DDFDB22$DB, VERSION ***, HAVE AN
ARC1821I (CONT.) ACTIVE FLASHCOPY BACKGROUND COPY
IKJ56250I JOB HSENDS22(JOB10293) SUBMITTED
***
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.
ARC1820I THE FOLLOWING VOLUMES IN COPY POOL DSN$DDFDB22$LG, VERSION 013, HAVE
ARC1820I (CONT.) AN ACTIVE FLASHCOPY BACKGROUND COPY
ARC1820I (CONT.) SGNAME
FR-PRIMARY FR-BACKUP PCT-COMP
ARC1820I (CONT.) DB2DIL
SAPDIL
SAPFIL
001
ARC1820I THE FOLLOWING VOLUMES IN COPY POOL DSN$DDFDB22$DB, VERSION 011, HAVE
ARC1820I (CONT.) AN ACTIVE FLASHCOPY BACKGROUND COPY
ARC1820I (CONT.) SGNAME
FR-PRIMARY FR-BACKUP PCT-COMP
ARC1820I (CONT.) DB2DI
SAPDI1
SAPFI1
001
ARC1820I (CONT.) DB2DI
SAPDI2
SAPFI2
001
ARC1820I (CONT.) DB2DI
SAPDI3
SAPFI3
001
IKJ56250I JOB HSENDS22(JOB10298) SUBMITTED
***
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
115
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
When looking at the copy pool listings there are a couple of things to notice. Even though this is SpaceEfficient 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.
COPYPOOL=DSN$DDFDB22$DB
ALLOWPPRCP FRB=NO FRR=NO
VERSION VTOCENQ
DATE
TIME
FASTREPLICATIONSTATE DUMPSTATE
011
N
2011/11/18
21:20:49
RECOVERABLE
ALLCOMPLETE
TOKEN(C)=C'DB22H e C%
ü? '
TOKEN(H)=X'C4C2F2F2C8B185B672C36C8B000CD06FE19A'
TOTAL NUM OF VOLUMES=00003,INCREMENTAL=N,CATINFO=Y,FCFRR=Y,RECOVERYINCOMPLETE=N
0
DUMPCLASS
REQUIRED
DUMPSTATE
VOLSSUC
EXPDATE
AVAILABLE
DB2DP03M
Y
COMPLETE
00003
2012/02/26
Y
COPYPOOL=DSN$DDFDB22$LG
ALLOWPPRCP FRB=NO FRR=NO
VERSION VTOCENQ
DATE
TIME
FASTREPLICATIONSTATE DUMPSTATE
013
N
2011/11/18
21:21:18
RECOVERABLE
ALLCOMPLETE
TOKEN(C)=C'DB22H e C%
ü? '
TOKEN(H)=X'C4C2F2F2C8B185B672C36C8B000CD06FE19A'
TOTAL NUM OF VOLUMES=00001,INCREMENTAL=N,CATINFO=Y,FCFRR=Y,RECOVERYINCOMPLETE=N
DUMPCLASS
DB2DP03M
REQUIRED
Y
DUMPSTATE
COMPLETE
VOLSSUC
00001
EXPDATE
2012/02/26
AVAILABLE
Y
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 systemlevel 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.
//DSNUPROC.SYSIN DD *
RECOVER TABLESPACE A201X994.XSAP
/*
//
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
116
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
Data Columns 15-17 of 47
CDS Name : ACTIVE
Enter Line Operators below:
LINE
OPERATOR
---(1)----
COPY POOL NAME
-------------(2)-------------DSN$DDFDB21$DB
DSN$DDFDB21$LG
DSN$DDFDB22$DB
DSN$DDFDB22$LG
DSN$DDFDB23$DB
DSN$DDFDB23$LG
DSN$DDFD6M0$DB
DSN$DDFD6M0$LG
DSN$DDFD8E0$DB
Command ===>
F1=Help
F2=Split
F10=Left
F11=Right
F3=Exit
F12=Cancel
F4=Return
FCTOPPTC
FRRECOV
--(15)-PMNO
PMNO
------------------------------------
F7=Up
ALLOW
CATINFO
FCFRR
--(16)--- (17)REQUIRED
NO
REQUIRED
NO
REQUIRED
YES
REQUIRED
YES
REQUIRED
YES
NO
NO
NO
NO
NO
NO
NO
NO
Scroll = PAGE
F8=Down
F9=Swap
Screenshot 45. Copy Pool List
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
117
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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,
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
118
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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,
//
MSGCLASS=X,MSGLEVEL=(1,1),
//
TIME=120,CLASS=A,REGION=0M
/*JOBPARM SYSAFF=SAPK
//*
//* 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.
//*
//STEP1 EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSTSIN DD *
HSEND QUERY COPYPOOL(DSN$DDFDB22$LG)
HSEND QUERY COPYPOOL(DSN$DDFDB22$DB)
//
Output from the query copy pool job:
ARC1820I
ARC1820I
ARC1820I
ARC1820I
ARC1820I
ARC1820I
ARC1820I
ARC1820I
ARC1820I
ARC1820I
***
THE FOLLOWING VOLUMES IN COPY POOL DSN$DDFDB22$LG, VERSION 007, HAVE
(CONT.) AN ACTIVE FLASHCOPY BACKGROUND COPY
(CONT.) SGNAME
FR-PRIMARY FR-BACKUP PCT-COMP
(CONT.) DB2DIL
SAPDIL
SAPFIL
002
THE FOLLOWING VOLUMES IN COPY POOL DSN$DDFDB22$DB, VERSION 004, HAVE
(CONT.) AN ACTIVE FLASHCOPY BACKGROUND COPY
(CONT.) SGNAME
FR-PRIMARY FR-BACKUP PCT-COMP
(CONT.) DB2DI
SAPDI1
SAPFI1
001
(CONT.) DB2DI
SAPDI2
SAPFI2
001
(CONT.) DB2DI
SAPDI3
SAPFI3
001
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
119
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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,
//
MSGCLASS=X,MSGLEVEL=(1,1),
//
TIME=120,CLASS=A,REGION=0M TYPRUN=SCAN
//*ROUTE
XEQ
BOECOB1
/*JOBPARM SYSAFF=SAPK
//IMAGECPY EXEC DSNUPROC,SYSTEM=DB22,UID=MARY02
//STEPLIB DD DSN=DB22L.V100.SDSNLOAD,DISP=SHR
//SYSPRINT DD SYSOUT=*
//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
FAST REPLICATION FUNCTION
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
120
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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.
ARC1820I THE FOLLOWING VOLUMES IN COPY POOL DSN$DDFDB22$LG, VERSION 024, HAVE
ARC1820I (CONT.) AN ACTIVE FLASHCOPY BACKGROUND COPY
ARC1820I (CONT.) SGNAME
FR-PRIMARY FR-BACKUP PCT-COMP
ARC1820I (CONT.) DB2DIL
SAPDIL
SAPFIL
007
ARC1820I THE FOLLOWING VOLUMES IN COPY POOL DSN$DDFDB22$DB, VERSION 017, HAVE
ARC1820I (CONT.) AN ACTIVE FLASHCOPY BACKGROUND COPY
ARC1820I (CONT.) SGNAME
FR-PRIMARY FR-BACKUP PCT-COMP
ARC1820I (CONT.) DB2DI
SAPDI1
SAPFI1
001
ARC1820I (CONT.) DB2DI
SAPDI2
SAPFI2
001
ARC1820I (CONT.) DB2DI
SAPDI3
SAPFI3
001
IKJ56250I JOB HSENDS24(JOB06334) SUBMITTED
***
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,
//
MSGCLASS=X,MSGLEVEL=(1,1),
//
TIME=120,CLASS=A,REGION=0M
//*ROUTE
XEQ
BOECOB1
/*JOBPARM SYSAFF=SAPC
//REPORT EXEC DSNUPROC,SYSTEM=DB22,UID=MARY02
//STEPLIB DD DSN=DB22L.V100.SDSNLOAD,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSABEND DD SYSOUT=*
//SYSIN DD *
RECOVER TABLESPACE DSN02334.ZZZRLARG TOLASTFULLCOPY
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
121
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
/*
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 spaceefficient 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
DSNU010I
023 22:37:18.03 DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=4
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
122
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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,
//
MSGCLASS=X,MSGLEVEL=(1,1),
//
TIME=120,CLASS=A,REGION=0M
//*ROUTE
XEQ
BOECOB1
/*JOBPARM SYSAFF=SAPC
//*
//*****************************************************
//*
JOB DESCRIPTION
//*****************************************************
//*
//STEP1 EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//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
ARC1833I
ARC1833I
ARC1831I
ARC1831I
ARC1833I
ARC1833I
ARC1833I
ARC1831I
ARC1831I
WITHDRAW COMPLETED FOR COPY POOL 860
(CONT.) DSN$DDFDB22$LG, BACKUP VERSION NUMBER 24 WAS
(CONT.) INVALIDATED
BACKUP VERSION NUMBER 24 OF COPY POOL 861
(CONT.) DSN$DDFDB22$LG WAS DELETED SUCCESSFULLY
WITHDRAW COMPLETED FOR COPY POOL 874
(CONT.) DSN$DDFDB22$DB, BACKUP VERSION NUMBER 17 WAS
(CONT.) INVALIDATED
BACKUP VERSION NUMBER 17 OF COPY POOL 875
(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
DEV TYPE
LOW DSNUM
JOBNAME
NPAGESF
DSNAME
=
=
=
=
=
=
2012-01-23-22.55.32.305757, IC TYPE = F , SHR LVL = C, DSNUM
,
IC BACK = FC,
STYPE
= N, FILE SEQ
0001,
HIGH DSNUM = 0001,
OLDEST VERSION = 0000,
LOGICAL PART =
IMAGECP6,
AUTHID =
MARY
,
COPYPAGESF = -1.0E+00
-1.0E+00
,
CPAGESF = -1.0E+00
DB22IC.DSN02334.ZZZRLARG.N00001.DNOTX4YB
, MEMBER NAME =
Following is the JCL and command to recover DSN02334.ZZZRLARG
//RECVR25A JOB (DE03557),CH,NOTIFY=MARY,
//
MSGCLASS=X,MSGLEVEL=(1,1),
//
TIME=120,CLASS=A,REGION=0M
//*ROUTE
XEQ
BOECOB1
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
123
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
/*JOBPARM SYSAFF=SAPC
//RECOVER EXEC DSNUPROC,SYSTEM=DB22,UID=MARY02
//STEPLIB DD DSN=DB22L.V100.SDSNLOAD,DISP=SHR
//SYSPRINT DD SYSOUT=*
//SYSABEND DD SYSOUT=*
//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.
COPY DATASET(INCLUDE( DB22IC.DSN02334.ZZZRLARG.N00001.DNOTX4YB )) RENAMEU( (DB22IC.DSN02334.ZZZRLARG.N00001.DNOTX4YB , DB22.DSNDBC.DSN02334.ZZZRLARG.I0001.A001 )) ALLDATA(*) ALLEXCP CANCELERROR SHARE VOLCOUNT(ANY) TGTALLOC(SRC)
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
124
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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.
Screenshot 46. Copy Pool List
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,
//
MSGCLASS=X,MSGLEVEL=(1,1),
//
TIME=120,CLASS=A,REGION=0M
/*JOBPARM SYSAFF=SAPC
//*
//**************************************************
//*
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
//**************************************************
//*
//STEP1 EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//SYSPRINT DD SYSOUT=*
//SYSTSIN DD *
HSEND LIST COPYPOOL(DSN$DDFDB22$DB) DUMPVOLS
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
125
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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.
COPYPOOL=DSN$DDFDB22$DB
VERSION VTOCENQ
DATE
TIME
FASTREPLICATIONSTATE DUMPSTATE
011
N
2011/11/18
21:20:49
RECOVERABLE
ALLCOMPLETE
TOKEN(C)=C'DB22H e C%
ü? '
TOKEN(H)=X'C4C2F2F2C8B185B672C36C8B000CD06FE19A'
TOTAL NUM OF VOLUMES=00003,INCREMENTAL=N,CATINFO=Y,FCFRR=Y,RECOVERYINCOMPLETE=N
DUMPCLASS
DB2DP03M
REQUIRED
Y
DUMPSTATE
COMPLETE
VOLSSUC
00003
EXPDATE
2012/02/26
AVAILABLE
Y
COPYPOOL=DSN$DDFDB22$LG
VERSION VTOCENQ
DATE
TIME
FASTREPLICATIONSTATE DUMPSTATE
013
N
2011/11/18
21:21:18
RECOVERABLE
ALLCOMPLETE
TOKEN(C)=C'DB22H e C%
ü? '
TOKEN(H)=X'C4C2F2F2C8B185B672C36C8B000CD06FE19A'
TOTAL NUM OF VOLUMES=00001,INCREMENTAL=N,CATINFO=Y,FCFRR=Y,RECOVERYINCOMPLETE=N
DUMPCLASS
DB2DP03M
REQUIRED
Y
DUMPSTATE
COMPLETE
VOLSSUC
00001
EXPDATE
2012/02/26
AVAILABLE
Y
The FlashCopy relationships for the above copy pools can be queried the using HSM HSEND QUERY command.
//STEP1 EXEC
//SYSTSPRT DD
//SYSTSIN DD
HSEND QUERY
HSEND QUERY
PGM=IKJEFT01
SYSOUT=*
*
COPYPOOL(DSN$DDFDB22$LG)
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.
ARC1820I THE FOLLOWING VOLUMES IN COPY POOL DSN$DDFDB22$LG, VERSION 013, HAVE
ARC1820I (CONT.) AN ACTIVE FLASHCOPY BACKGROUND COPY
ARC1820I (CONT.) SGNAME
FR-PRIMARY FR-BACKUP PCT-COMP
ARC1820I (CONT.) DB2DIL
SAPDIL
SAPFIL
006
ARC1820I THE FOLLOWING VOLUMES IN COPY POOL DSN$DDFDB22$DB, VERSION 011, 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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
126
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
IKJ56250I JOB HSENDS22(JOB10426) SUBMITTED
***
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,
//
MSGCLASS=X,MSGLEVEL=(1,1),
//
TIME=120,CLASS=A,REGION=0M
//*ROUTE
XEQ
BOECOB1
/*JOBPARM SYSAFF=SAPC
//*
//STEP1 EXEC PGM=IKJEFT01
//SYSTSPRT DD SYSOUT=*
//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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
127
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
.
.
.
ARC1838I INITIALIZATION ATTEMPT OF COPY POOL BACKUP 927
ARC1838I (CONT.) STORAGE GROUP VOLUME SAPFI2 HAS COMPLETED, RC=0000,
ARC1838I (CONT.) RSN=0000
.
.
.
ARC1838I INITIALIZATION ATTEMPT OF COPY POOL BACKUP 932
ARC1838I (CONT.) STORAGE GROUP VOLUME SAPFI3 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
ARC1805I (CONT.) SAPDI2
ARC1805I (CONT.) SAPDI3
ARC1802I FAST REPLICATION RECOVERY HAS COMPLETED FOR 939
ARC1802I (CONT.) COPY POOL DSN$DDFDB22$DB, AT 21:23:19 ON 2011/11/21,
ARC1802I (CONT.) FUNCTION RC=0000, MAXIMUM VOLUME RC=0000
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
128
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
ARC1820I THE FOLLOWING VOLUMES IN COPY POOL DSN$DDFDB22$LG, VERSION 013, HAVE
ARC1820I (CONT.) AN ACTIVE FLASHCOPY BACKGROUND COPY
ARC1820I (CONT.) SGNAME
FR-PRIMARY FR-BACKUP PCT-COMP
ARC1820I (CONT.) DB2DIL
SAPDIL
SAPFIL
008
ARC1821I NONE OF THE VOLUMES IN COPY POOL DSN$DDFDB22$DB, VERSION ***, HAVE AN
ARC1821I (CONT.) ACTIVE FLASHCOPY BACKGROUND COPY
IKJ56250I JOB HSENDS22(JOB10488) SUBMITTED
***
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.
COPYPOOL=DSN$DDFDB22$DB
VERSION
011
VTOCENQ
N
DATE
TIME
2011/11/18
21:20:49
TOKEN(C)=C'DB22H e
C%
ü?
FASTREPLICATIONSTATE
DUMPSTATE
NONE
ALLCOMPLETE
'
TOKEN(H)=X'C4C2F2F2C8B185B672C36C8B000CD06FE19A'
TOTAL NUM OF VOLUMES=00003,INCREMENTAL=N,CATINFO=Y,FCFRR=N,RECOVERYINCOMPLETE=N
DUMPCLASS
REQUIRED
DB2DP03M
DUMPSTATE
Y
COMPLETE
VOLSSUC
00003
EXPDATE
2012/02/26
AVAILABLE
Y
COPYPOOL=DSN$DDFDB22$LG
VERSION
013
VTOCENQ
N
DATE
TIME
2011/11/18
21:21:18
TOKEN(C)=C'DB22H e
C%
ü?
FASTREPLICATIONSTATE
DUMPSTATE
RECOVERABLE
ALLCOMPLETE
'
TOKEN(H)=X'C4C2F2F2C8B185B672C36C8B000CD06FE19A'
TOTAL NUM OF VOLUMES=00001,INCREMENTAL=N,CATINFO=Y,FCFRR=Y,RECOVERYINCOMPLETE=N
DUMPCLASS
DB2DP03M
REQUIRED
Y
DUMPSTATE
COMPLETE
VOLSSUC
EXPDATE
AVAILABLE
00001
2012/02/26
Y
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
129
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
DSNT361I
-DB22 ***********************************
-DB22 * DISPLAY DATABASE SUMMARY
*
RESTRICTED
DSNT360I -DB22 ***********************************
DSNT362I -DB22
DATABASE = DSN00011 STATUS = RW
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 ***********************************
DSNT362I -DB22
DATABASE = DSN00014 STATUS = RW
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.
COPY DATASET(INCLUDE( -
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
130
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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 VOLCOUNT(ANY) TGTALLOC(SRC)
REPUNC TOLERATE(ENQF) DEBUG(FRMSG(DTL))
FR(PREF)
.
.
.
ADR806I (001)-T0MI (03), DATA SET DB22IC.DSN00011.REPOSRC.N00001.DNRT1E8S COPIED
USING A FAST REPLICATION FUNCTION
ADR806I (001)-T0MI (03), DATA SET DB22IC.DSN00011.LFSEE2O5.N00001.DNRT1E81 COPIED
USING A FAST REPLICATION FUNCTION
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
131
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
START RBA/TIME
-------------------000C602FD000
2011.313 09:14:46.2
000C63FE6000
2011.313 09:21:33.7
000C6714A000
2011.313 09:25:04.2
SETS
END RBA/TIME
-------------------000C63FE5FFF
2011.313 09:21:33.7
000C67149FFF
2011.313 09:25:04.2
000C93069FFF
........ ..........
ARCHIVE LOG COPY 1 DATA SETS
START RBA/TIME
END RBA/TIME
-------------------- -------------------000C4DA5F000
000C559EEFFF
2011.312 15:26:45.9 2011.313 09:07:54.9
000C559EF000
000C5AB1EFFF
2011.313 09:07:54.9 2011.313 09:10:46.6
000C5AB1F000
000C602FCFFF
2011.313 09:10:46.6 2011.313 09:14:46.2
000C602FD000
000C63FE5FFF
2011.313 09:14:46.2 2011.313 09:21:33.7
DATE
-------2011.313
LTIME
----10:08
2011.313
10:10
2011.313
10:14
2011.313
10:21
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
132
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
133
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
134
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
The table has 5 partitions, one for each year 2009 to 2012 and an overflow partition:
PARTITION LOGICAL_PART STORNAME VCATNAME IPREFIX
1
2
3
4
5
1
2
3
4
5
SYSDEFLT
SYSDEFLT
SYSDEFLT
SYSDEFLT
SYSDEFLT
DB21
DB21
DB21
DB21
DB21
J
I
I
I
I
CARD LIMITKEY
5.000
5.000
5.000
0
0
200912
201012
201112
201212
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
1
2
3
4
5
1
2
3
4
5
SAPSTOGP
SYSDEFLT
SYSDEFLT
SYSDEFLT
SYSDEFLT
DB21X
DB21
DB21
DB21
DB21
J
I
I
I
I
CARD LIMITKEY
5.000
5.000
5.000
0
0
200912
201012
201112
201212
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
135
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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>,
//
MSGCLASS=X,MSGLEVEL=(1,1),
//
TIME=120,CLASS=A,REGION=0M
//*ROUTE
XEQ
BOECOB1
/*JOBPARM SYSAFF=SAPK
//DFDSSCMD EXEC PGM=ADRDSSU PARM='TYPRUN=NORUN'
//SYSPRINT DD SYSOUT=*
//SYSIN
DD *
COPY DATASET(INCLUDE( 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
ADR109I
ADR016I
ADR006I
ADR711I
NEWNAME
(R/I)-RI01 (01),
(R/I)-RI01 (01),
(001)-PRIME(01),
(001)-STEND(01),
(001)-NEWDS(01),
TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'COPY '
2012.002 17:15:04 INITIAL SCAN OF USER CONTROL STATEMENTS COMPLETED
RACF LOGGING OPTION IN EFFECT FOR THIS TASK
2012.002 17:15:04 EXECUTION BEGINS
DATA SET DB21.DSNDBC.DSN04225.FBICFEJO.J0001.A001 HAS BEEN ALLOCATED WITH
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
136
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
137
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
DB2 Cloning Tool
DB2 stogroup SAPSTOGP
VCAT DB21X
read-only
sms storage
Part 1
DB2
DB24:
TestTest
system
DB210
10SSID
SSID
DB24:
system
(SAPK,
from
DB21)
(SAPK,cloned
cloned
from
DB21)
group standard
DB2 Catalog:
Table INFO_CUBE1
(range-partitioned)
Copy pool
DSN$DDFDB21$DB
DSN$DDFDB24$DB
DSN$DDFDB24$DB
DB2stogroup
stogroup SYSDEFLT
DB2
SYSDEFLT
DB2 stogroup SYSDEFLT
Copy pool
VCAT DB21
DB2
DB2Catalog:
Catalog:
Copy pool
pool
Copy
VCATDB24
DB24
VCAT
Table
TableINFO_CUBE1
INFO_CUBE1
(range-partitioned)
(range-partitioned)
Copy pool
pool
Copy
sms storage
DSN$DDFDB21$LG
smsstorage
storage
sms
DSN$DDFDB24$LG
DSN$DDFDB24$LG
group DB2DJ
VCAT DB21L
group DB2CJ
DB2CJ
group
VCATDB24L
DB24L
VCAT
smsstorage
storage
sms
sms storage
Part 2
Part 3
...
group DB2DJL
Part
Part22
Part
Part33
......
group DB2CJL
DB2CJL
group
DB2 BACKUP SYSTEM
Storage group DB2FJ
Storage group DB2FJL
Type:
Type:
COPY POOL BACKUP
DB2 Cloning Tool
COPY POOL BACKUP
Figure 27. Embedded Nearline Storage for SAP BW on DB2 for z/OS
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
138
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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.
IBM System z196
LPAR SAP2
LPAR SAP1
DB2 Admin
Scheduler and
DB2 Cloning Tool
stored procedure
Target
DB2 Subsystem
Source
DB2 Subsystem
DB2 Cloning Tool
- Rename data sets
- Update DB2 Catalog …
IBM System Storage DS8800
Source
Storage Groups
Backup
Storage Groups
DB2 BACKUP SYSTEM
Target
Storage Groups
DB2 Cloning Tool
- Copy Volumes
Figure 28. Cloning in an IBM System z environment, using the DB2 Cloning Tool
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
139
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
140
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
SCHUETZ_CLONE1_ST004
COMPLETED
1
2011-11-01-15.36.43.0
0
SCHUETZ_CLONE1_ST005
COMPLETED
1
2011-11-01-15.36.54.0
0
SCHUETZ_CLONE1_ST006
COMPLETED
1
2011-11-01-15.37.05.0
0
SCHUETZ_CLONE1_ST007
COMPLETED
1
2011-11-01-15.37.07.0
0
SCHUETZ_CLONE1_ST008
COMPLETED
1
2011-11-01-15.37.18.0
0
SCHUETZ_CLONE1_ST009
COMPLETED
1
2011-11-01-15.37.19.0
0
SCHUETZ_CLONE1_ST010
COMPLETED
1
2011-11-01-15.48.54.0
0
SCHUETZ_CLONE1_ST011
COMPLETED
1
2011-11-01-15.49.45.0
0
SCHUETZ_CLONE1_ST012
COMPLETED
1
2011-11-01-15.49.46.0
0
SCHUETZ_CLONE1_ST013
COMPLETED
1
2011-11-01-15.50.16.0
0
SCHUETZ_CLONE1_ST014
COMPLETED
1
2011-11-01-15.50.27.0
0
SCHUETZ_CLONE1_ST015
COMPLETED
1
2011-11-01-15.50.57.0
0
SCHUETZ_CLONE1_ST016
COMPLETED
1
2011-11-01-15.54.08.0
0
SCHUETZ_CLONE1_ST017
COMPLETED
1
2011-11-01-15.54.29.0
0
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
141
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
sp_name(30)
message_txt(160)
ret_code(8)
split_rest(1024)
returncode
outmessage(1331)
ind0
ind2
ind4
ind6
ind8
sql_stmt
result_ref
sqlerr_ref
type_input(10)
pparmdsn(44)
pparmmem(8)
sparmdsn(44)
sparmmem(8)
cparmdsn(44)
cparmmem(8)
type
type
type
type
type
type
type
type
type
type
type
type
type
type
type
type
type
type
type
type
type
type
i,
c,
c,
c,
c,
i,
c,
int2,
ind1
int2,
ind3
int2,
ind5
int2,
ind7
int2,
string,
ref to data,
ref to cx_sy_native_sql_error,
c value 'CLONE',
c value 'WIETZ.JCL.PDS',
c value 'CKZPPARM',
c value 'WIETZ.JCL.PDS',
c value 'DB2SYS',
c value 'WIETZ.JCL.PDS',
c value 'CKZCPARM'.
type
type
type
type
int2,
int2,
int2,
int2,
*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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
142
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
143
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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 TOSTORAGEGROUP, 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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
144
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
* 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
COPYPOOL=DSN$DDFDB21$LG
,ALLOWPPRCP FRB=PN FRR=PN
VER=035,VTOCENQ=N,MADE ON 2011/12/01 AT 12:58:39,FRS=RECOVERABLE
TKN(H)=X'C4C2F2F1C8C16D9A160F5A89000F18888DDC'
,DPS=NONE
If this is the backup that should be the source of the cloning process, then specify the following value for
SOURCE-TOKEN:
SOURCE-TOKEN
SAP COMMUNITY NETWORK
© 2012 SAP AG
= X'C4C2F2F1C8C16D9A160F5A89000F18888DDC'
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
145
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
SDSNLOAD
= DB24L.V100.SDSNLOAD
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)
//*
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
146
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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.
----------------------------------------------BROWSE
WIETZ.CLONE1.JCL(ST002)
//CKZIN
DD *
BCSCLEAN
JOURNAL-DDN(JOURNAL)
//*
DB2GETBACKINFO
This job determines the latest system-backup level that is available.
------------------------------------------------BROWSE
WIETZ.CLONE1.JCL(ST003)
//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.
-------------------------------------------------BROWSE
WIETZ.CLONE1.JCL(ST004)
//
SPACE=(CYL,(1,1))
//CKZIN
DD *
BACKINFO-REFORMAT BACKINFO-DDN(BACKINFO) 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
---------------------------------------------------BROWSE
WIETZ.CLONE1.JCL(ST005)
//CKZIN
DD *
COPY
DATA-MOVER(PGM(NONE)) VOLPAIRS-DDN(VOLPAIRS) -
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
147
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
USERCATALOGS-DDN(UCATS) CATWORK-DSN(WIETZ.CLONE1.WRK.*) JOURNAL-DDN(JOURNAL)
//*
----------------------------------------------BROWSE
WIETZ.CLONE1.JCL(ST006)
//CKZIN
DD *
COPY
FROM-VOLSER-DDN(FRVOLSER) TO-STORAGEGROUP( DB2CJ DB2CJL ) NOUSERCATALOGS JOURNAL-DDN(JOURNAL)
//*
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,
//
SPACE=(CYL,(1,1))
//*
---------------------------------------------BROWSE
WIETZ.CLONE1.JCL(ST008)
//CKZIN
DD *
VOLOPTIONS UPDATE NEWTARGETS-DDN(NEWTGTS) JOURNAL-DDN(JOURNAL)
//*
----------------------------------------BROWSE
WIETZ.CLONE1.JCL(ST009)
//CKZIN
DD *
RENAME
-
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
148
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
SAFE VOLBKUP-DDN(VOLBKUP) RENAME-MASKS( DB21.** DB24.** DB21L.** DB24L.** SYS1.USERCAT.** GARBAGE.**
) RECATALOG(Y) JOURNAL-DDN(JOURNAL)
-
//*
******************************** 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.
--------------------------------------------------BROWSE
WIETZ.CLONE1.JCL(ST010)
//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)) JOURNAL-DDN(JOURNAL)
//*
--------------------------------------BROWSE
WIETZ.CLONE1.JCL(ST011)
//CKZIN
DD *
DB2ALTERBSDS
DB2-NAME(S001) SLB-START JOURNAL-DDN(JOURNAL)
//*
BROWSE
WIETZ.CLONE1.JCL(ST013)
//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)
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
149
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
//*
//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) ) HLQ-NOT-UPDATED(RC(22)) JOURNAL-DDN(JOURNAL)
//*
//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.
----------------------------------------------BROWSE
WIETZ.CLONE1.JCL(ST014)
//CKZIN
DD *
DB2SQL
DB2-NAME(S001) DB2-SSID(DB24) -
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
150
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
LISTSQL(Y) WLM-ENVIRONMENT-MASKS( DB21* DB24* ) JOURNAL-DDN(JOURNAL)
//*
----------------------------------------------BROWSE
WIETZ.CLONE1.JCL(ST015)
//CKZIN
DD *
DB2FIX
DB2-SSID(DB24) MEMBERS-NEED-STARTING( RC(22)) WAIT( 5, RC(24)) DATABASES(APPLICATION)
//*
-----------------------------------------------BROWSE
WIETZ.CLONE1.JCL(ST016)
//CKZIN
DD *
DB2STOP
DB2-SSID(DB24)
//*
----------------------------------------------BROWSE
WIETZ.CLONE1.JCL(ST017)
//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 APFauthorized. 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)
COMMAND INPUT ===>
SCROLL ===> CSR
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
151
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
14.57.00 STC06953
14.57.00 STC06953
994
994
994
994
994
994
994
994
994
994
994
994
994
994
994
14.57.00 STC06953
IEF188I PROBLEM PROGRAM ATTRIBUTES ASSIGNED
IEA995I SYMPTOM DUMP OUTPUT 994
SYSTEM COMPLETION CODE=047
TIME=14.57.00 SEQ=22363 CPU=0000 ASID=0154
PSW AT TIME OF ERROR 078D1000
80007232 ILC 2 INTC 6B
ACTIVE LOAD MODULE
ADDRESS=000071D0 OFFSET=00000062
NAME=DXRRLM00
DATA AT PSW 0000722C - 58101000 0A6BEB0F C6D80096
GR 0: FD00002B
1: 0000000C
2: 00000040
3: 008E8AD4
4: 00000000
5: 008FF890
6: 008D2FC8
7: FD000000
8: 008FC130
9: 008E3CB0
A: 00000000
B: 008FF890
C: 000083B8
D: 000083D4
E: 000083D4
F: 800071D0
END OF SYMPTOM DUMP
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
CPU:
0 HR 00 MIN 00.05 SEC
SRB:
0 HR 00 MIN 00.00 SEC
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
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
CPU:
0 HR 00 MIN 00.05 SEC
SRB:
0 HR 00 MIN 00.00 SEC
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
152
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
JCL-DSN
= WIETZ.CLONE2.JCL
STATUS-DSN
= WIETZ.CLONE2.STATUS
WORK-PREFIX = WIETZ.CLONE2.WRK
TASK-PREFIX = WIETZ_CLONE2
CLONING-TYPE = ONLINE
USERID
= WIETZ
PASSWORD = xxxxxxxx
JOBCARD1 = //CKZCLON1 JOB ,'CKZ CLONING 2',CLASS=B,MSGCLASS=X,
JOBCARD2 = //
NOTIFY=&SYSUID
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* COPY PARAMETERS FOR CLONING DB21 TO DB24
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
SAP COMMUNITY NETWORK
© 2012 SAP AG
*
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
153
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
FROM-STORAGEGROUP = DB2DG DB2DGL
SOURCE-LOCATION
= DDFDB21
TO-STORAGEGROUP
= DB2CJ DB2CJL
USERCATALOGS = SYS1.USERCAT.DB21 SYS1.USERCAT.DB24
SYS1.USERCAT.DB21L SYS1.USERCAT.DB24L
DM-PGM
= ADRDSSU
DM-CHECKVTOC
= Y
DM-CONSISTENT
= Y
* * * * * * * * * * * * * * * * * * * * * * * * * * *
* RENAME PARAMETERS FOR CLONING DB21 TO DB24
* * * * * * * * * * * * * * * * * * * * * * * * * * *
RENAME-MASKS
= DB21.**
DB24.**
DB21L.**
DB24L.**
SYS1.USERCAT.** GARBAGE.**
MAX-TASKS
= 10
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 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( SYS1.USERCAT.DB21 SYS1.USERCAT.DB24 SYS1.USERCAT.DB21L SYS1.USERCAT.DB24L ) -
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
154
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
CATWORK-DSN(WIETZ.CLONE2.WRK.*) JOURNAL-DDN(JOURNAL)
//*
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 VOLBKUP-DDN(VOLBKUP) RENAME-MASKS( DB21.** DB24.** DB21L.** DB24L.** SYS1.USERCAT.** GARBAGE.**
) MAX-TASKS(10) RECATALOG(Y) JOURNAL-DDN(JOURNAL)
//*
-
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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
155
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
COPYPOOL=DSN$DDFDB21$DB
ALLOWPPRCP FRB=PN FRR=PN
VERSION VTOCENQ
DATE
TIME
FASTREPLICATIONSTATE DUMPSTATE
016
N
2011/11/17
17:02:36
NONE
ALLCOMPLETE
TOKEN(C)=C'DB21H
u
= h '
TOKEN(H)=X'C4C2F2F1C8B00A2214A4BA8B000D7E438832'
TOTAL NUM OF VOLUMES=00003,INCREMENTAL=N,CATINFO=Y,FCFRR=N,RECOVERYINCOMPLETE=N
DUMPCLASS
DB2DP03M
REQUIRED
Y
HWCOMP
NO
DUMPSTATE
COMPLETE
ENCRYPT
NONE
VOLSSUC
00003
ENCTYPE
*********
EXPDATE
2012/02/25
AVAILABLE
Y
RSAKEY/KPWD
****************************************
SOURCE
DUMPVOLS
DEVICE TYPE
SAPDG1
WA1270
3490
FILE SEQ=00, DSNAME=SAP.DMP.DB2DP03M.VSAPDG1.D11321.T360217
SAPDG2
WA0909
3490
FILE SEQ=00, DSNAME=SAP.DMP.DB2DP03M.VSAPDG2.D11321.T360217
SAPDG3
WA0861
3490
FILE SEQ=00, DSNAME=SAP.DMP.DB2DP03M.VSAPDG3.D11321.T360217
hsend list copypool(dsn$ddfdb21$lg) dumpvols
-- DFSMShsm CONTROL DATASET --COPY POOL--LISTING --------- AT 15:57:29 ON 11/11/24
COPYPOOL=DSN$DDFDB21$LG
ALLOWPPRCP FRB=PN FRR=PN
VERSION VTOCENQ
DATE
TIME
FASTREPLICATIONSTATE DUMPSTATE
019
N
2011/11/17
17:03:06
NONE
ALLCOMPLETE
TOKEN(C)=C'DB21H
u
= h '
TOKEN(H)=X'C4C2F2F1C8B00A2214A4BA8B000D7E438832'
TOTAL NUM OF VOLUMES=00001,INCREMENTAL=N,CATINFO=Y,FCFRR=N,RECOVERYINCOMPLETE=N
DUMPCLASS
REQUIRED
SAP COMMUNITY NETWORK
© 2012 SAP AG
DUMPSTATE
VOLSSUC
EXPDATE
AVAILABLE
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
156
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
DB2DP03M
Y
HWCOMP
NO
COMPLETE
ENCRYPT
NONE
00001
ENCTYPE
*********
2012/02/25
Y
RSAKEY/KPWD
*****************************************
SOURCE
DUMPVOLS
DEVICE TYPE
SAPDGL
WA3602
3490
FILE SEQ=00, DSNAME=SAP.DMP.DB2DP03M.VSAPDGL.D11321.T060317
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
//SYSPRINT DD SYSOUT=*
//SYSIN DD *
DEF NVSAM(NAME('SAP.DMP.DB2DP03M.VSAPDG1.D11321.T360217')
VOL(WA1270) DEVT(3490))
DEF NVSAM(NAME('SAP.DMP.DB2DP03M.VSAPDG2.D11321.T360217')
VOL(WA0909)
DEVT(3490))
DEF NVSAM(NAME('SAP.DMP.DB2DP03M.VSAPDG3.D11321.T360217')
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
SAP.DMP.DB2DP03M.VSAPDG2.D11321.T360217
SAP.DMP.DB2DP03M.VSAPDG3.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
//SYSPRINT DD SYSOUT=*
//TAPE1 DD DSN=SAP.DMP.DB2DP03M.VSAPDG1.D11321.T360217,
//
DISP=(OLD,KEEP)
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
157
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
//TAPE2 DD DSN=SAP.DMP.DB2DP03M.VSAPDG2.D11321.T360217,
//
DISP=(OLD,KEEP)
//TAPE3 DD DSN=SAP.DMP.DB2DP03M.VSAPDG3.D11321.T360217,
//
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
REDEFINE
SETROPTS
SETROPTS
GENERIC(DASDVOL)
DASDVOL * UACC(ALTER)
CLASSACT(DASDVOL)
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
158
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
//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)
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
/*JOBPARM SYSAFF=SAPK
//S0
EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//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,
//
DISP=(,CATLG),UNIT=SYSALLDA,
//
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( SYS1.USERCAT.DB21 SYS1.USERCAT.DB24 SYS1.USERCAT.DB21L SYS1.USERCAT.DB24L ) CATWORK-DSN(SCHUETZ.CLOCLIP.WRK.*) JOURNAL-DDN(JOURNAL)
//*
//
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
SAPDG2
SAPDG3
SAPDGL
SAPCJ1
SAPCJ2
SAPCJ3
SAPCJL
8E09
8E0A
8E0B
8E25
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
159
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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
* PARAMETER FILE
*
* FROM TAPE NON DS TO NON DS - DB21 - DB24
JCL-DSN
= WIETZ.CLONE3.JCL
STATUS-DSN
= WIETZ.CLONE3.STATUS
WORK-PREFIX = WIETZ.CLONE3.WRK
TASK-PREFIX = WIETZ_CLONE3
CLONING-TYPE = ONLINE
USERID
= WIETZ
PASSWORD =xxxxxxxx
*
JOBCARD1 = //CKZCLON1 JOB ,'CKZ CLONING 2',CLASS=B,MSGCLASS=X,
JOBCARD2 = //
NOTIFY=&SYSUID
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* COPY PARAMETERS FOR CLONING DB21 TO DB24
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
FROM-VOLSER
= SAPDG1 SAPDG2 SAPDG3 SAPDGL
TO-VOLSER
= SAPCJ1 SAPCJ2 SAPCJ3 SAPCJL
USERCATALOGS = SYS1.USERCAT.DB21 SYS1.USERCAT.DB24
SYS1.USERCAT.DB21L SYS1.USERCAT.DB24L
DM-PGM
= ADRDSSU
DM-FCNOCOPY
= Y
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* RENAME PARAMETERS FOR CLONING DB21 TO DB24
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
RENAME-MASKS
= DB21.**
DB24.**
DB21L.**
DB24L.**
SYS1.USERCAT.** GARBAGE.**
MAX-TASKS
= 10
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*
* *
* *
* *
* *
* *
* *
00000104
00000204
00000304
00000410
00000604
00000704
00000804
00000904
00001004
00003004
00004004
00005004
00006004
00007004
00100004
00110004
00120004
00140004
00200004
00250004
00260004
00280008
00314009
00390004
00400004
00410004
00420004
00430004
00440004
00530004
00590004
00710004
00720004
00730004
00740004
00750004
00780004
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
160
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
ST001 DB2STOP of Target DB2
//CKZIN
DD *
DB2STOP
DB2-ALREADY-STOPPED(RC(0)) 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)
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//S0
EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
161
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
//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.
//CKZCLON1 JOB ,'CKZ CLONING 2',CLASS=B,MSGCLASS=X,
//
NOTIFY=&SYSUID
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//* GENERATED: 2011-11-21 13:57:11
//* TASK NAME: WIETZ_CLONE3_ST006
//* JCL DSN:
WIETZ.CLONE3.JCL(ST006)
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//S0
EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN
DD *
DEL WIETZ.CLONE3.WRK.BCSRECS
DEL WIETZ.CLONE3.WRK.VOLBKUP
SET MAXCC=0
//
//
//
//RENAME
EXEC PGM=CKZ00010,REGION=0M
//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=*
//DRSTATS DD SYSOUT=*
//SORTMSG DD SYSOUT=*
//JOURNAL DD DISP=SHR,DSN=SCHUETZ.CLOCLIP.WRK.JRNL
//SORTWK01 DD UNIT=SYSALLDA,SPACE=(CYL,(10,10))
//SORTWK02 DD UNIT=SYSALLDA,SPACE=(CYL,(10,10))
//SORTWK03 DD UNIT=SYSALLDA,SPACE=(CYL,(10,10))
//SORTWK04 DD UNIT=SYSALLDA,SPACE=(CYL,(10,10))
//SORTWK05 DD UNIT=SYSALLDA,SPACE=(CYL,(10,10))
//SORTWK06 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 VOLBKUP-DDN(VOLBKUP) RENAME-MASKS( -
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
162
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
DB21.** DB24.** DB21L.** DB24L.** SYS1.USERCAT.** GARBAGE.**
) MAX-TASKS(10) RECATALOG(Y) JOURNAL-DDN(JOURNAL) -
-
//*
ST007 DB2UPDATE
//CKZCLON1 JOB ,'CKZ CLONING 2',CLASS=B,MSGCLASS=X,
//
NOTIFY=&SYSUID
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//* GENERATED: 2011-11-21 13:57:11
//* TASK NAME: WIETZ_CLONE3_ST007
//* JCL DSN:
WIETZ.CLONE3.JCL(ST007)
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//DB2UPDP EXEC PGM=CKZ00010,REGION=6M
//STEPLIB DD DISP=SHR,DSN=SYS1.DB2CT.V310.SCKZLOAD
//
DD DISP=SHR,DSN=DB24L.V100.SDSNEXIT
//
DD DISP=SHR,DSN=DB24L.V100.SDSNLOAD
//CKZINI
DD DISP=SHR,
//
DSN=SYS1.DB2CT.V310.SCKZPARM(CKZINI#)
//ABNLIGNR DD DUMMY
//CKZPRINT DD SYSOUT=*
//JOURNAL DD DISP=SHR,DSN=SCHUETZ.CLOCLIP.WRK.JRNL
//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) ) HLQ-NOT-UPDATED(RC(22)) JOURNAL-DDN(JOURNAL)
//*
ST008 DB2START Target with special ZPARM
//CKZCLON1 JOB ,'CKZ CLONING 2',CLASS=B,MSGCLASS=X,
//
NOTIFY=&SYSUID
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
163
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
/*JOBPARM S=SAPK
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//* GENERATED: 2011-11-21 13:57:11
//* TASK NAME: WIETZ_CLONE3_ST008
//* JCL DSN:
WIETZ.CLONE3.JCL(ST008)
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//DB2STAS EXEC PGM=CKZ00010,REGION=6M
//STEPLIB DD DISP=SHR,DSN=SYS1.DB2CT.V310.SCKZLOAD
//
DD DISP=SHR,DSN=DB24L.V100.SDSNEXIT
//
DD DISP=SHR,DSN=DB24L.V100.SDSNLOAD
//CKZINI
DD DISP=SHR,
//
DSN=SYS1.DB2CT.V310.SCKZPARM(CKZINI#)
//ABNLIGNR DD DUMMY
//CKZPRINT DD SYSOUT=*
//CKZIN
DD *
DB2START
DB2-SSID(DB24) DSNZPARM(DSNZPARN) SPECIAL
//*
ST009 DB2FIX & rerun DB2UPDATE with DBD01ONLY parameter
//CKZCLON1 JOB ,'CKZ CLONING 2',CLASS=B,MSGCLASS=X,
//
NOTIFY=&SYSUID
/*JOBPARM S=SAPK
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//* GENERATED: 2011-11-21 13:57:11
//* TASK NAME: WIETZ_CLONE3_ST009
//* JCL DSN:
WIETZ.CLONE3.JCL(ST009)
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//DB2FIXDB EXEC PGM=CKZ00010,REGION=6M
//STEPLIB DD DISP=SHR,DSN=SYS1.DB2CT.V310.SCKZLOAD
//
DD DISP=SHR,DSN=DB24L.V100.SDSNEXIT
//
DD DISP=SHR,DSN=DB24L.V100.SDSNLOAD
//CKZINI
DD DISP=SHR,
//
DSN=SYS1.DB2CT.V310.SCKZPARM(CKZINI#)
//ABNLIGNR DD DUMMY
//CKZPRINT DD SYSOUT=*
//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)
//*
//IF1 IF (DB2FIXDB.RC EQ 5 ) THEN
//DB2STOP EXEC PGM=CKZ00010,REGION=6M
//STEPLIB DD DISP=SHR,DSN=SYS1.DB2CT.V310.SCKZLOAD
//
DD DISP=SHR,DSN=DB24L.V100.SDSNEXIT
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
164
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
//
DD DISP=SHR,DSN=DB24L.V100.SDSNLOAD
//CKZINI
DD DISP=SHR,
//
DSN=SYS1.DB2CT.V310.SCKZPARM(CKZINI#)
//ABNLIGNR DD DUMMY
//CKZPRINT DD SYSOUT=*
//CKZIN
DD *
DB2STOP
DB2-SSID(DB24)
//*
//IF2 IF (DB2STOP.RC LE 4 ) THEN
//DB2UPDD EXEC PGM=CKZ00010,REGION=6M
//STEPLIB DD DISP=SHR,DSN=SYS1.DB2CT.V310.SCKZLOAD
//
DD DISP=SHR,DSN=DB24L.V100.SDSNEXIT
//
DD DISP=SHR,DSN=DB24L.V100.SDSNLOAD
//CKZINI
DD DISP=SHR,
//
DSN=SYS1.DB2CT.V310.SCKZPARM(CKZINI#)
//ABNLIGNR DD DUMMY
//CKZPRINT DD SYSOUT=*
//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) ) HLQ-NOT-UPDATED(RC(22)) JOURNAL-DDN(JOURNAL)
//*
//IF3 IF (DB2UPDD.RC LE 4 ) THEN
//DB2STAS EXEC PGM=CKZ00010,REGION=6M
//STEPLIB DD DISP=SHR,DSN=SYS1.DB2CT.V310.SCKZLOAD
//
DD DISP=SHR,DSN=DB24L.V100.SDSNEXIT
//
DD DISP=SHR,DSN=DB24L.V100.SDSNLOAD
//CKZINI
DD DISP=SHR,
//
DSN=SYS1.DB2CT.V310.SCKZPARM(CKZINI#)
//ABNLIGNR DD DUMMY
//CKZPRINT DD SYSOUT=*
//CKZIN
DD *
DB2START
DB2-SSID(DB24) DSNZPARM(DSNZPARN) SPECIAL
//*
//IF3 ENDIF
//IF2 ENDIF
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
165
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
//IF1
ENDIF
ST010 DB2SQL
//CKZCLON1 JOB ,'CKZ CLONING 2',CLASS=B,MSGCLASS=X,
//
NOTIFY=&SYSUID
/*JOBPARM S=SAPK
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//* GENERATED: 2011-11-21 13:57:11
//* TASK NAME: WIETZ_CLONE3_ST010
//* JCL DSN:
WIETZ.CLONE3.JCL(ST010)
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//DB2SQL
EXEC PGM=CKZ00010,REGION=6M
//STEPLIB DD DISP=SHR,DSN=SYS1.DB2CT.V310.SCKZLOAD
//
DD DISP=SHR,DSN=DB24L.V100.SDSNEXIT
//
DD DISP=SHR,DSN=DB24L.V100.SDSNLOAD
//CKZINI
DD DISP=SHR,
//
DSN=SYS1.DB2CT.V310.SCKZPARM(CKZINI#)
//ABNLIGNR DD DUMMY
//CKZPRINT DD SYSOUT=*
//JOURNAL DD DISP=SHR,DSN=SCHUETZ.CLOCLIP.WRK.JRNL
//CKZIN
DD *
DB2SQL
DB2-NAME(S001) DB2-SSID(DB24) LISTSQL(Y) WLM-ENVIRONMENT-MASKS( DB21* DB24* ) JOURNAL-DDN(JOURNAL)
//*
ST011 DB2FIX
//CKZCLON1 JOB ,'CKZ CLONING 2',CLASS=B,MSGCLASS=X,
//
NOTIFY=&SYSUID
/*JOBPARM S=SAPK
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//* GENERATED: 2011-11-21 13:57:11
//* TASK NAME: WIETZ_CLONE3_ST011
//* JCL DSN:
WIETZ.CLONE3.JCL(ST011)
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//DB2FIXAP EXEC PGM=CKZ00010,REGION=6M
//STEPLIB DD DISP=SHR,DSN=SYS1.DB2CT.V310.SCKZLOAD
//
DD DISP=SHR,DSN=DB24L.V100.SDSNEXIT
//
DD DISP=SHR,DSN=DB24L.V100.SDSNLOAD
//CKZINI
DD DISP=SHR,
//
DSN=SYS1.DB2CT.V310.SCKZPARM(CKZINI#)
//ABNLIGNR DD DUMMY
//CKZPRINT DD SYSOUT=*
//CKZIN
DD *
DB2FIX
DB2-SSID(DB24) MEMBERS-NEED-STARTING( RC(22)) WAIT( 5, RC(24)) -
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
166
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
DATABASES(APPLICATION)
//*
ST012 DB2STOP
//CKZCLON1 JOB ,'CKZ CLONING 2',CLASS=B,MSGCLASS=X,
//
NOTIFY=&SYSUID
/*JOBPARM S=SAPK
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//* GENERATED: 2011-11-21 13:57:11
//* TASK NAME: WIETZ_CLONE3_ST012
//* JCL DSN:
WIETZ.CLONE3.JCL(ST012)
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//DB2STOP EXEC PGM=CKZ00010,REGION=6M
//STEPLIB DD DISP=SHR,DSN=SYS1.DB2CT.V310.SCKZLOAD
//
DD DISP=SHR,DSN=DB24L.V100.SDSNEXIT
//
DD DISP=SHR,DSN=DB24L.V100.SDSNLOAD
//CKZINI
DD DISP=SHR,
//
DSN=SYS1.DB2CT.V310.SCKZPARM(CKZINI#)
//ABNLIGNR DD DUMMY
//CKZPRINT DD SYSOUT=*
//CKZIN
DD *
DB2STOP
DB2-SSID(DB24)
//*
ST013 DB2START NORMAL
//CKZCLON1 JOB ,'CKZ CLONING 2',CLASS=B,MSGCLASS=X,
//
NOTIFY=&SYSUID
/*JOBPARM S=SAPK
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//* GENERATED: 2011-11-21 13:57:11
//* TASK NAME: WIETZ_CLONE3_ST013
//* JCL DSN:
WIETZ.CLONE3.JCL(ST013)
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//DB2STAN EXEC PGM=CKZ00010,REGION=6M
//STEPLIB DD DISP=SHR,DSN=SYS1.DB2CT.V310.SCKZLOAD
//
DD DISP=SHR,DSN=DB24L.V100.SDSNEXIT
//
DD DISP=SHR,DSN=DB24L.V100.SDSNLOAD
//CKZINI
DD DISP=SHR,
//
DSN=SYS1.DB2CT.V310.SCKZPARM(CKZINI#)
//ABNLIGNR DD DUMMY
//CKZPRINT DD SYSOUT=*
//CKZIN
DD *
DB2START
DB2-SSID(DB24) DSNZPARM(DB24PARM) NORMAL
//*
This completes the online cloning use case that is based on a system-level backup on tape as a source.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
167
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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.
JCL-DSN
= WIETZ.CLONE4.JCL
STATUS-DSN
= WIETZ.CLONE4.STATUS
WORK-PREFIX = WIETZ.CLONE4.WRK
TASK-PREFIX = WIETZ_CLONE4
CLONING-TYPE = ONLINE
USERID
= WIETZ
PASSWORD = xxxxxxxx
*
JOBCARD1 = //CKZCLON4 JOB ,'CKZ CLONING 4',CLASS=B,MSGCLASS=X,
JOBCARD2 = //
NOTIFY=&SYSUID
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* COPY PARAMETERS FOR CLONING S23 TO DB24
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
SOURCE-VOLUMES
= DB2SLB
SOURCE-TOKEN
= LAST
SOURCE-LOCATION = DDFS231
TO-STORAGEGROUP
= DB2CJ2 DB2CJ2L
*
USERCATALOGS = SYS1.USERCAT.DB23 SYS1.USERCAT.DB25
SYS1.USERCAT.DB23L SYS1.USERCAT.DB25L
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
* RENAME PARAMETERS FOR CLONING DB23 TO DB25
* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
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.**
SAP COMMUNITY NETWORK
© 2012 SAP AG
*
*
*
*
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
168
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
SYS1.USERCAT.** GARBAGE.**
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
WLM-ENVIRONMENT-MASKS = DB23*
DB25*
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
SDSNLOAD
= DB23L.V100.SDSNLOAD
EXEC-SYSTEM
= SAPK
*
SSID
= S232
GROUP
= DB23
MEMBER
= S232
SDSNLOAD
= DB23L.V100.SDSNLOAD
EXEC-SYSTEM
= SAPK
*
* * * * * * * * * * * * * * * * * * * * * *
* TARGET DB2 DB25 (FIRST DS, THEN NON-DS)
* * * * * * * * * * * * * * * * * * * * * *
SSID
= S251
GROUP
= DS25
MEMBER
= S251
SDSNLOAD
= DB25L.V100.SDSNLOAD
SDSNEXIT
= DB25L.V100.S251.SDSNEXIT
BSDS01
= DB25L.S251.BSDS01
BSDS02
= DB25L.S251.BSDS02
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
SDSNLOAD
= DB25L.V100.SDSNLOAD
SAP COMMUNITY NETWORK
© 2012 SAP AG
* * * * * * * * * *
* * * * * * * * * *
* * * * * * * * * *
* * * * * * * * * *
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
169
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
SDSNEXIT
= DB25L.V100.S252.SDSNEXIT
BSDS01
= DB25L.S252.BSDS01
BSDS02
= DB25L.S252.BSDS02
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-ALREADY-STOPPED(RC(0)) DB2-SSID(S252)
//*
Figure 33. Generated cloning job WIETZ.CLONE4.JCL(ST001)
//CKZPRINT DD SYSOUT=*
//CKZIN
DD *
DB2STOP
DB2-ALREADY-STOPPED(RC(0)) DB2-SSID(S251)
//*
Figure 34. Generated cloning job WIETZ.CLONE4.JCL(ST002)
BCSCLEAN
The cleanup job needs to be executed only once.
//BCSRECS DD DISP=OLD,DSN=WIETZ.CLONE4.WRK.BCSRECS
//CKZIN
DD *
BCSCLEAN
JOURNAL-DDN(JOURNAL)
//*
Figure 35. Generated cloning job WIETZ.CLONE4.JCL(ST003)
DB2GETBACKINFO
The backup information is retrieved once for the entire source data sharing group.
********************************* Top of Data **********************************
//CKZCLON4 JOB ,'CKZ CLONING 4',CLASS=B,MSGCLASS=X,
//
NOTIFY=&SYSUID
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
170
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//* GENERATED: 2011-12-16 09:42:40
//* TASK NAME: WIETZ_CLONE4_ST004
//* JCL DSN:
WIETZ.CLONE4.JCL(ST004)
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//S0
EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//SYSIN
DD *
DEL WIETZ.CLONE4.WRK.BACKINFO
DEL WIETZ.CLONE4.WRK.HSMLIST
SET MAXCC=0
//DB2GETBI 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=*
//BACKINFO DD DSN=WIETZ.CLONE4.WRK.BACKINFO,
//
DISP=(,CATLG),UNIT=SYSALLDA,
//
SPACE=(CYL,(1,1))
//HSMLIST DD DSN=WIETZ.CLONE4.WRK.HSMLIST,
//
DISP=(,CATLG),UNIT=SYSALLDA,
//
SPACE=(CYL,(1,1))
//CKZIN
DD *
DB2GETBACKINFO
LAST LOCATION(DDFS231
) USERCATALOGS( SYS1.USERCAT.DB23 SYS1.USERCAT.DB23L ) BACKINFO-DDN(BACKINFO) WORK-DDN(HSMLIST)
//*
Figure 36. Generated cloning job WIETZ.CLONE4.JCL(ST004)
BACKINFO-REFORMAT
********************************* Top of Data **********************************
//CKZCLON4 JOB ,'CKZ CLONING 4',CLASS=B,MSGCLASS=X,
//
NOTIFY=&SYSUID
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//* GENERATED: 2011-12-16 09:42:40
//* TASK NAME: WIETZ_CLONE4_ST005
//* JCL DSN:
WIETZ.CLONE4.JCL(ST005)
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//S0
EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//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
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
171
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
//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=*
//BACKINFO DD DISP=SHR,DSN=WIETZ.CLONE4.WRK.BACKINFO
//VOLPAIRS DD DSN=WIETZ.CLONE4.WRK.VOLPAIRS,
//
DISP=(,CATLG),UNIT=SYSALLDA,
//
SPACE=(CYL,(1,1))
//FRVOLSER DD DSN=WIETZ.CLONE4.WRK.FRVOLSER,
//
DISP=(,CATLG),UNIT=SYSALLDA,
//
SPACE=(CYL,(1,1))
//UCATS
DD DSN=WIETZ.CLONE4.WRK.UCATS,
//
DISP=(,CATLG),UNIT=SYSALLDA,
//
SPACE=(CYL,(1,1))
//CKZIN
DD *
BACKINFO-REFORMAT BACKINFO-DDN(BACKINFO) VOLPAIRS-DDN(VOLPAIRS) FROM-VOLSER-DDN(FRVOLSER) USERCATALOGS( SYS1.USERCAT.DB23 SYS1.USERCAT.DB25 SYS1.USERCAT.DB23L SYS1.USERCAT.DB25L ) USERCATALOGS-DDN(UCATS)
//*
Figure 37. Generated cloning job WIETZ.CLONE4.JCL(ST005)
COPY
********************************* Top of Data **********************************
//CKZCLON4 JOB ,'CKZ CLONING 4',CLASS=B,MSGCLASS=X,
//
NOTIFY=&SYSUID
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//* GENERATED: 2011-12-16 09:42:40
//* TASK NAME: WIETZ_CLONE4_ST006
//* JCL DSN:
WIETZ.CLONE4.JCL(ST006)
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//S0
EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//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
//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=*
//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,
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
172
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
//
DISP=(,CATLG),UNIT=SYSALLDA,
//
RECORG=KS,KEYLEN=64,KEYOFF=0,
//
LRECL=600,SPACE=(CYL,(10,10))
//VOLPLIST DD DSN=WIETZ.CLONE4.WRK.VOLPLIST,
//
DISP=(,CATLG),UNIT=SYSALLDA,
//
RECFM=FB,LRECL=80,BLKSIZE=0,
//
SPACE=(CYL,(1,1))
//CKZIN
DD *
COPY
DATA-MOVER(PGM(NONE)) VOLPAIRS-DDN(VOLPAIRS) USERCATALOGS-DDN(UCATS) CATWORK-DSN(WIETZ.CLONE4.WRK.*) JOURNAL-DDN(JOURNAL)
//*
Figure 38. Generated cloning job WIETZ.CLONE4.JCL(ST006)
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
FROM-VOLSER-DDN(FRVOLSER) TO-STORAGEGROUP( DB2CJ2 DB2CJ2L ) NOUSERCATALOGS JOURNAL-DDN(JOURNAL)
//*
Figure 39. Generated cloning job WIETZ.CLONE4.JCL(ST007)
Work Data set
********************************* Top of Data *********************
//CKZCLON4 JOB ,'CKZ CLONING 4',CLASS=B,MSGCLASS=X,
//
NOTIFY=&SYSUID
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//* GENERATED: 2011-12-16 09:42:40
//* TASK NAME: WIETZ_CLONE4_ST008
//* JCL DSN:
WIETZ.CLONE4.JCL(ST008)
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//S0
EXEC PGM=IDCAMS
//SYSPRINT DD SYSOUT=*
//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)
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
173
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
//CKZIN
//NUCIN
//NEWTGT
//
//
//
//*
DD DISP=SHR,DSN=WIETZ.CLONE4.WRK.VOLPLIST
DD DISP=SHR,DSN=WIETZ.CLONE4.WRK.NUC.VOLPLIST
DD DSN=WIETZ.CLONE4.WRK.NEWTGTS,
DISP=(,CATLG),UNIT=SYSALLDA,
DSORG=PS,RECFM=FB,LRECL=80,BLKSIZE=0,
SPACE=(CYL,(1,1))
Figure 40. Generated cloning job WIETZ.CLONE4.JCL(ST008)
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 ***********************
//CKZCLON4 JOB ,'CKZ CLONING 4',CLASS=B,MSGCLASS=X,
//
NOTIFY=&SYSUID
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//* GENERATED: 2011-12-16 09:42:40
//* TASK NAME: WIETZ_CLONE4_ST009
//* JCL DSN:
WIETZ.CLONE4.JCL(ST009)
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//VOLOPTS 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 DISP=SHR,DSN=WIETZ.CLONE4.WRK.JRNL
//NEWTGTS DD DISP=SHR,DSN=WIETZ.CLONE4.WRK.NEWTGTS
//CKZIN
DD *
VOLOPTIONS UPDATE NEWTARGETS-DDN(NEWTGTS) JOURNAL-DDN(JOURNAL)
//*
Figure 41. Generated cloning job WIETZ.CLONE4.JCL(ST009)
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 VOLBKUP-DDN(VOLBKUP) RENAME-MASKS( DB23L.V100.S231.** DB25L.V100.S251.**
DB23L.V100.S232.** DB25L.V100.S252.**
DB23L.S231.** DB25L.S251.** DB23L.S232.** DB25L.S252.** DB23L.** DB25L.** -
SAP COMMUNITY NETWORK
© 2012 SAP AG
-
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
174
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
DB23.** DB25.** SYS1.USERCAT.** GARBAGE.**
) RECATALOG(Y) JOURNAL-DDN(JOURNAL)
-
//*
Figure 42. Generated cloning job WIETZ.CLONE4.JCL(ST010)
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
) –
HLQ-NOT-UPDATED(RC(22)) JOURNAL-DDN(JOURNAL)
//*
) -
Figure 43. Generated cloning job WIETZ.CLONE4.JCL(ST011)
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) ) -
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
175
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
DB2-GROUP(DS23
DS25
DB2-MEMBERS( S231
S251
S232
S252
) HLQ-NOT-UPDATED(RC(22)) JOURNAL-DDN(JOURNAL)
) -
//*
Figure 44. Generated cloning job WIETZ.CLONE4.JCL(ST012)
DB2ALTERBSDS
There is a DB2ALTERBSDS job per member of the data sharing group
//CKZIN
DD *
DB2ALTERBSDS
DB2-NAME(G001) DB2-MEMBER(S251
) SLB-START JOURNAL-DDN(JOURNAL)
//*
Figure 45. Generated cloning job WIETZ.CLONE4.JCL(ST013)
DB2ALTERBSDS
DB2-NAME(G001) DB2-MEMBER(S252
) SLB-START JOURNAL-DDN(JOURNAL)
//*
Figure 46. Generated cloning job WIETZ.CLONE4.JCL(ST014)
DB2START (special ZPARM)
Each DB2 member of the target data sharing group is started with the special ZPARM file.
//CKZCLON4 JOB ,'CKZ CLONING 4',CLASS=B,MSGCLASS=X,
//
NOTIFY=&SYSUID
/*JOBPARM S=SAPK
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//* GENERATED: 2012-02-17 15:48:17
//* TASK NAME: WIETZ_CLONE4_ST015
//* JCL DSN:
WIETZ.CLONE4.JCL(ST015)
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//DB2STASW EXEC PGM=CKZ00010,REGION=6M
//STEPLIB DD DISP=SHR,DSN=SYS1.DB2CT.V310.SCKZLOAD
//
DD DISP=SHR,DSN=DB25L.V100.S251.SDSNEXIT
//
DD DISP=SHR,DSN=DB25L.V100.SDSNLOAD
//CKZINI
DD DISP=SHR,
//
DSN=SYS1.DB2CT.V310.SCKZPARM(CKZINI#)
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
176
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
//ABNLIGNR DD DUMMY
//CKZPRINT DD SYSOUT=*
//CKZIN
DD *
DB2START
DB2-SSID(S251) DSNZPARM(DB25SPEC) REPLY-TO-RESTART-WTOR(Y) SPECIAL
//*
Figure 47. Generated cloning job WIETZ.CLONE4.JCL(ST015)
//CKZCLON4 JOB ,'CKZ CLONING 4',CLASS=B,MSGCLASS=X,
//
NOTIFY=&SYSUID
/*JOBPARM S=SAPK
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//* GENERATED: 2011-12-16 09:42:40
//* TASK NAME: WIETZ_CLONE4_ST016
//* JCL DSN:
WIETZ.CLONE4.JCL(ST016)
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//DB2STASL EXEC PGM=CKZ00010,REGION=6M
//STEPLIB DD DISP=SHR,DSN=SYS1.DB2CT.V310.SCKZLOAD
//
DD DISP=SHR,DSN=DB25L.V100.S252.SDSNEXIT
//
DD DISP=SHR,DSN=DB25L.V100.SDSNLOAD
//CKZINI
DD DISP=SHR,
//
DSN=SYS1.DB2CT.V310.SCKZPARM(CKZINI#)
//ABNLIGNR DD DUMMY
//CKZPRINT DD SYSOUT=*
//CKZIN
DD *
DB2START
DB2-SSID(S252) DSNZPARM(S252SPEC) REPLY-TO-RESTART-WTOR(Y) SPECIAL
//*
//DB2STOSL EXEC PGM=CKZ00010,REGION=6M
//STEPLIB DD DISP=SHR,DSN=SYS1.DB2CT.V310.SCKZLOAD
//
DD DISP=SHR,DSN=DB25L.V100.S252.SDSNEXIT
//
DD DISP=SHR,DSN=DB25L.V100.SDSNLOAD
//CKZINI
DD DISP=SHR,
//
DSN=SYS1.DB2CT.V310.SCKZPARM(CKZINI#)
//ABNLIGNR DD DUMMY
//CKZPRINT DD SYSOUT=*
//CKZIN
DD *
DB2STOP
DB2-SSID(S252)
//*
Figure 48. Generated cloning job WIETZ.CLONE4.JCL(ST016)
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
177
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
DB2FIX
//CKZCLON4 JOB ,'CKZ CLONING 4',CLASS=B,MSGCLASS=X,
//
NOTIFY=&SYSUID
/*JOBPARM S=SAPK
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//* GENERATED: 2012-02-17 15:48:17
//* TASK NAME: WIETZ_CLONE4_ST017
//* JCL DSN:
WIETZ.CLONE4.JCL(ST017)
//* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * *
//DB2FIXDB EXEC PGM=CKZ00010,REGION=6M
//STEPLIB DD DISP=SHR,DSN=SYS1.DB2CT.V310.SCKZLOAD
//
DD DISP=SHR,DSN=DB25L.V100.S251.SDSNEXIT
//
DD DISP=SHR,DSN=DB25L.V100.SDSNLOAD
//CKZINI
DD DISP=SHR,
//
DSN=SYS1.DB2CT.V310.SCKZPARM(CKZINI#)
//ABNLIGNR DD DUMMY
//CKZPRINT DD SYSOUT=*
//CKZIN
DD *
DB2FIX
DB2-SSID(S251) 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)
//*
//IF1 IF (DB2FIXDB.RC EQ 5 ) THEN
//DB2STOP EXEC PGM=CKZ00010,REGION=6M
//STEPLIB DD DISP=SHR,DSN=SYS1.DB2CT.V310.SCKZLOAD
//
DD DISP=SHR,DSN=DB25L.V100.S251.SDSNEXIT
//
DD DISP=SHR,DSN=DB25L.V100.SDSNLOAD
//CKZINI
DD DISP=SHR,
//
DSN=SYS1.DB2CT.V310.SCKZPARM(CKZINI#)
//ABNLIGNR DD DUMMY
//CKZPRINT DD SYSOUT=*
//CKZIN
DD *
DB2STOP
DB2-SSID(S251)
//*
//IF2 IF (DB2STOP.RC LE 4 ) THEN
//DB2UPDD EXEC PGM=CKZ00010,REGION=6M
//STEPLIB DD DISP=SHR,DSN=SYS1.DB2CT.V310.SCKZLOAD
//
DD DISP=SHR,DSN=DB25L.V100.S251.SDSNEXIT
//
DD DISP=SHR,DSN=DB25L.V100.SDSNLOAD
//CKZINI
DD DISP=SHR,
//
DSN=SYS1.DB2CT.V310.SCKZPARM(CKZINI#)
//ABNLIGNR DD DUMMY
//CKZPRINT DD SYSOUT=*
//JOURNAL DD DISP=SHR,DSN=WIETZ.CLONE4.WRK.JRNL
//DBD01
DD DISP=SHR,DSN=DB25.DSNDBC.DSNDB01.DBD01.I0001.A001
//CKZIN
DD *
DB2UPDATE
-
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
178
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
DBD01ONLY 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
) HLQ-NOT-UPDATED(RC(22)) JOURNAL-DDN(JOURNAL)
) -
//*
//IF3 IF (DB2UPDD.RC LE 4 ) THEN
//DB2STAS EXEC PGM=CKZ00010,REGION=6M
//STEPLIB DD DISP=SHR,DSN=SYS1.DB2CT.V310.SCKZLOAD
//
DD DISP=SHR,DSN=DB25L.V100.S251.SDSNEXIT
//
DD DISP=SHR,DSN=DB25L.V100.SDSNLOAD
//CKZINI
DD DISP=SHR,
//
DSN=SYS1.DB2CT.V310.SCKZPARM(CKZINI#)
//ABNLIGNR DD DUMMY
//CKZPRINT DD SYSOUT=*
//CKZIN
DD *
DB2START
DB2-SSID(S251) DSNZPARM(DB25SPEC) REPLY-TO-RESTART-WTOR(Y) SPECIAL
//*
//IF3 ENDIF
//IF2 ENDIF
//IF1 ENDIF
Figure 49. Generated cloning job WIETZ.CLONE4.JCL(ST017)
DB2SQL
//CKZIN
DD *
DB2SQL
DB2-NAME(G001) DB2-SSID(S251) LISTSQL(Y) WLM-ENVIRONMENT-MASKS( DB23* DB25* ) JOURNAL-DDN(JOURNAL)
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
179
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
//*
Figure 50. Generated cloning job WIETZ.CLONE4.JCL(ST018)
DB2FIX
//CKZIN
DD *
DB2FIX
DB2-SSID(S251) MEMBERS-NEED-STARTING( RC(22)) WAIT( 5, RC(24)) DATABASES(APPLICATION)
//*
Figure 51. Generated cloning job WIETZ.CLONE4.JCL(ST019)
DB2STOP
//CKZIN
DD *
DB2STOP
DB2-SSID(S251)
//*
-
Figure 52. Generated cloning job WIETZ.CLONE4.JCL(ST020)
DB2START both members
Finally, both DB2 members of the target data sharing group are started.
//CKZIN
DD *
DB2START
DB2-SSID(S251) DSNZPARM(DB25PARM) NORMAL
//*
Figure 53. Generated cloning job WIETZ.CLONE4.JCL(ST021)
//CKZIN
DD *
DB2START
DB2-SSID(S252) DSNZPARM(S252PARM) NORMAL
//*
Figure 54. Generated cloning job WIETZ.CLONE4.JCL(ST022)
This completes the online cloning of a data sharing group based on a system-level backup on disk.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
180
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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/s
rc/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.ht
m

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)
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
181
Casebook - 2012 Edition:
Tightly Integrated DB2 Backup, Recovery and Cloning
for SAP Environments
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.
SAP COMMUNITY NETWORK
© 2012 SAP AG
SDN - sdn.sap.com | BPX - bpx.sap.com | BA - boc.sap.com | UAC - uac.sap.com
182