Casebook: DB2 backup, recovery and cloning for SAP environments · 2019-11-12 · SAP Labs in Walldorf and St.Leon-Rot and works on all aspects of the usage of DB2 for z/OS for SAP

SAP DEVELOPER NETWORK | sdn.sap.com BUSINESS PROCESS EXPERT COMMUNITY | bpx.sap.com © 2008 SAP AG 1

Casebook: 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, automated and fast recovery to current and to a prior points 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. 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. Additionally, 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.

Author(s): Christian Heimlich, IBM Deutschland GmbH

Armin-Robert Kompalka, IBM Deutschland GmbH

Ludger Quatmann, IBM Deutschland GmbH

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

Company: IBM

Created on: October 24, 2008

Document version: Final version 1



Author Bio 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. He can be reached at [email protected].

Ludger Quatmann is a consultant certified IT specialist who joined IBM in 1978. He holds a Bachelor’s degree in electrical engineering from University of Osnabrück (Germany). Over the years, he has had various responsibilities as z/OS and DB2 for zOS 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. He can be reached at [email protected].

Armin Kompalka is a Senior IT specialist working for IBM Software Group Germany with DB2 Tools on zSeries. 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. Armin can be reached at [email protected].

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

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

mailto:[email protected]







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. Heidrun can be reached at [email protected].

Mary Siart is IBM 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 27 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. Mary can be reached at [email protected].




Table of Contents Table of Contents.........................................................................................................................................................4 Table of Figures ...........................................................................................................................................................6 Acknowledgements......................................................................................................................................................9

1. Introduction......................................................................................................................................10 2. General SAP Requirements for Database Backup, Recovery and Cloning ...................................11 3. History of DB2 backup technologies for SAP..................................................................................12 4. Overview of Strategic DB2 Backup/Recovery/Cloning Solution for SAP........................................14

Base Technology of BACKUP SYSTEM and RESTORE SYSTEM Utilities ..............................................................14 DB2 Cloning Tool for z/OS.........................................................................................................................................17 DB2 Recovery Expert for z/OS ..................................................................................................................................18

5. Setup for Sample SAP Use Cases..................................................................................................20 Setup of SAP and DB2 Systems................................................................................................................................20 DFSMShsm Definitions..............................................................................................................................................23 Tape Definitions .........................................................................................................................................................26 Configuration of DB2 Recovery Expert for z/OS ........................................................................................................27 Configuring the DB2 Cloning Tool..............................................................................................................................34

6. Representative SAP Use Cases .....................................................................................................36 7. DB2 Data Sharing & SAP ABAP-Only & DASD Use Case .............................................................37

Backup to DASD Using BACKUP SYSTEM...............................................................................................................37 Incremental Backup to DASD using BACKUP SYSTEM ...........................................................................................38 RESTORE SYSTEM with Backup on DASD: PIT Recovery Specifying SYSPITRT ..................................................41 Verifying DB2 Restore with an SAP System in Use Cases........................................................................................49 Backing up the $LG Copy Pool Prior to System Level Recovery ...............................................................................51 RESTORE SYSTEM with Backup on DASD: Recover to Current..............................................................................53 Changing a Log Truncation in the BSDS ...................................................................................................................60 Restoring the $LG Copy Pool Using the FRBACKUP Copy.......................................................................................64 Recovering Individual Tablespace Using RECOVER Utility with System-Level Backup on DASD............................67 Recovery to Point in Time of Backup Using DFSMShsm FRRECOV ........................................................................72 Restoring Individual Volumes.....................................................................................................................................77 Cloning Based on Copy on DASD with DB2 Cloning Tool Using FlashCopy.............................................................80

8. DB2 single subsystem, SAP ABAP+Java and DASD Use Case ..................................................101 Backup to DASD Using BACKUP SYSTEM and DB2 Recovery Expert ..................................................................101 Federated Recovery of Multiple DB2 Systems to the Same Point in Time ..............................................................101 Cloning Based on Copy on DASD with DB2 Cloning Tool (SAP Doublestack System ABAP+Java).......................102 SAP Activities While and After Cloning ....................................................................................................................112

9. Tape Use Case .............................................................................................................................123 Backup to Tape Using BACKUP SYSTEM DUMP Option .......................................................................................123 Backup to Tape Using BACKUP SYSTEM DUMPONLY Option..............................................................................124 RESTORE SYSTEM with Backup on Tape: PIT Recovery Specifying SYSPITRT ..................................................128 Recovering individual tablespace using RECOVER utility with system-level backup on tape..................................136 Recovery to Point in Time of Backup on Tape Using DFSMSdss............................................................................136 Cloning Based on Copy on Tape with DB2 Cloning Tool.........................................................................................141

10. DB2 Recovery Expert Use Case...................................................................................................153 Validation of copy pools ...........................................................................................................................................153



System-Level Backup on DASD with RE .................................................................................................................160 System-Level Backup RE on Tape Using HSM Copy Pool Attribute VERSIONS=0................................................161 Resetting COPYP status with BACKUP SYSTEM and RE ......................................................................................169 RE Backup and Offload Reports ..............................................................................................................................170 Restore with Recovery Expert..................................................................................................................................173 Restore from Offload................................................................................................................................................174 Restore Data only / PIT............................................................................................................................................176 RE Deallocates ICF catalogs before FRRECOV and Creates SYSPITR/ SYSPITRT for All Members ...................179 RE automatically removes CF structures.................................................................................................................179 Timestamp to LRSN Utility .......................................................................................................................................181 RE Object Recovery: Recovering Tablespace with Data Sets that Have Moved to a Different Volume ..................183 RE Automatically Restores Underlying Datasets .....................................................................................................186 Drop Recovery .........................................................................................................................................................188 Restore and PIT Recovery on Object-Level with Recovery Expert GUI...................................................................192

11. Summary .......................................................................................................................................205 12. Appendix........................................................................................................................................206

Recovery Expert configuration details......................................................................................................................206 List of relevant APARs .............................................................................................................................................223 Related Content and Links.......................................................................................................................................224



Table of Figures Figure 1: Evolution of Backup and Recovery Technology of DB2....................................................................13 Figure 2: Points in Time Available with the RECOVER Utility..........................................................................13 Figure 3: Beginning Stages of FlashCopy Process..........................................................................................14 Figure 4: Incremental FlashCopy .....................................................................................................................15 Figure 5: Relationship Between the Different FlashCopy Groups....................................................................16 Figure 6: Relationship Between System z and Flash Copy .............................................................................17 Figure 7: Setup of Sample SAP System on IBM System z ..............................................................................22 Figure 8: Recovery Expert Sample Configuration ............................................................................................28 Figure 9: General DB2 Administration Panel....................................................................................................32 Figure 10: DB2 Recovery Expert Initial Configuration......................................................................................33 Figure 11: Recovery Expert Started Tasks in LPAR COB1 .............................................................................34 Figure 12: Screen print of the Conditional Restart Control card of member SN61 after the DSNJU003 job had

been run for all three members. ................................................................................................................44 Figure 13: Checkpoint queue for SN61 showing the approximate GMT time and LRSN for the checkpoint.

This helps to validate the truncation time being used in the conditional restart........................................45 Figure 14: Screen print of the Conditional Restart Control card of member SN61 after the DSNJU003 job had

been run for all three members, indicating no log truncation will occur ....................................................56 Figure 15: Single-object recovery sample use Case........................................................................................69 Figure 16: Overview of all Clients Including the Newly Added Clients.............................................................69 Figure 17: Client Copy/Transport Log Analysis Screen ...................................................................................70 Figure 17: Display View “Clients”: Overview ....................................................................................................71 Figure 18: Difference between the steps and the order of the steps of performing a PITR as compared to a

baseline recovery. .....................................................................................................................................73 Figure 19: Data Set List Utility – Volume COBD11 ..........................................................................................88 Figure 20: Data Sets on Volume COBD11.......................................................................................................89 Figure 21: Data Sets on Volume COBF11 .......................................................................................................90 Figure 22: Data Sets on Volume COBC11.......................................................................................................91 Figure 23: SAPinst Option Selected for the Database Export (Java).............................................................113 Figure 24: SAPinst Option for Using Database-Specific Tools ......................................................................113 Figure 25: Database Export Phases Carried Out by SAPinst ........................................................................114 Figure 26: SAPinst Option Selected for Target System Installation...............................................................114 Figure 27: Target System Installation Phases Carried Out by SAPinst .........................................................115 Figure 28: TSLE4 Entry Confirmation.............................................................................................................117 Figure 29: Transaction SM21 – System Log ..................................................................................................118 Figure 30: SAP Initial Consistency Check ......................................................................................................118 Figure 31: Defining the Cloned System in STMS...........................................................................................119 Figure 32: Logging On to the Cloned System ................................................................................................119 Figure 33: System Overview – Cloned System..............................................................................................119



Figure 34: DB02 Check – Cloned System......................................................................................................120 Figure 35: DB02 Check – Source System......................................................................................................120 Figure 36: Transaction DB02 – Cloned System Check..................................................................................121 Figure 37: Transaction DB02 – Source System Check..................................................................................121 Figure 38: Transaction RZ10 - Successful .....................................................................................................122 Figure 39: Cloned SAP System Initial Screen................................................................................................122 Figure 40: Screen print of the Conditional Restart Control card of member SN61 after the DSNJU003 job had

been run for all three members. ..............................................................................................................131 Figure 41: Checkpoint queue for SN61 showing the approximate GMT time and LRSN for the checkpoint.

This helps to validate the truncation time being used in the conditional restart......................................132 Figure 42: Offline Vary of the Systems...........................................................................................................142 Figure 43: Creation of New Volumes for DBN6..............................................................................................142 Figure 44: Restoring Jobs on DBN6 from Tape .............................................................................................143 Figure 45: Restarting DBN6 and Starting SAP N61 .......................................................................................145 Figure 46: Running Cloning Jobs for the DBNC Data Sharing Group ...........................................................145 Figure 47: System Backup Setup Screen.......................................................................................................153 Figure 48: First Data Analysis of ALIAS DSN911 – Screen 1 ........................................................................154 Figure 49: First Data Analysis of ALIAS DSN911 – Screen 2 ........................................................................154 Figure 50: Logs Defined Under ALIAS DSN911.............................................................................................155 Figure 51: Second Data Analysis of ALIAS DSN911 – Screen 1...................................................................156 Figure 52: Second Data Analysis of ALIAS DSN911 – Screen 2...................................................................156 Figure 53: Analysis of DB2 Volumes – Screen 1 ...........................................................................................157 Figure 54: Analysis of DB2 Volumes – Screen 2 ...........................................................................................158 Figure 55: Entering the New Volume COBD22 ..............................................................................................159 Figure 56: A Typical Backup Profile ...............................................................................................................161 Figure 57: Specification of the DB2 Offload Options – Screen 1 ...................................................................161 Figure 58: Specification of the DB2 Offload Options – Screen 2 ...................................................................162 Figure 59: Building the Backup Job................................................................................................................163 Figure 60: Backing Up the Recovery Expert Repository ................................................................................164 Figure 61: Specifying Perform Offload = Yes .................................................................................................165 Figure 62: Missing Mapping Between Source and Target Volumes ..............................................................168 Figure 63: Checking the Copy Pool Listing ....................................................................................................169 Figure 64: Restore System Display ................................................................................................................173 Figure 65: Restoring from an Offloaded Backup ............................................................................................174 Figure 66: Typical RE Restore Summary Report ...........................................................................................176 Figure 67: Selecting a Recovery Based on a Time Stamp.............................................................................177 Figure 68: RE Assistance in Selecting Timestamps.......................................................................................178 Figure 69: Selecting the Timestamp to DB2 LRSN Utility ..............................................................................181 Figure 70: Generating an LRSN by a Timestamp ..........................................................................................182



Figure 71: Object Profile for Tablespace TEST4............................................................................................183 Figure 72: Update Recovery Options Available..............................................................................................184 Figure 73: Dropped Objects Displayed in Red ...............................................................................................188 Figure 74: Selecting the Objects You Want to Recover .................................................................................189 Figure 75: Plan to Recover Selected Objects.................................................................................................190 Figure 76: Objects to Be Recovered ..............................................................................................................191 Figure 77: Setting Up a Recovery Job............................................................................................................192 Figure 78: Selecting Member SN61 ...............................................................................................................193 Figure 79: Selection of Point-in-Time .............................................................................................................194 Figure 80: Selecting a Point in Time...............................................................................................................195 Figure 81: Selecting Recovery History Events ...............................................................................................195 Figure 82: Selecting History Events Log Points .............................................................................................196 Figure 83: Selecting Recovery Plans .............................................................................................................197 Figure 84: Assistance by Object Selection .....................................................................................................198 Figure 85: Assistance in PIT Selection...........................................................................................................199 Figure 86: Examples of Different Recovery Plans..........................................................................................200 Figure 87: Detailed Structure of a Recovery Plan ..........................................................................................201 Figure 88: Generated JCL View .....................................................................................................................202 Figure 89: Unsuccessful Validation ................................................................................................................203 Figure 90: Application of Using undo SQL .....................................................................................................204



Acknowledgements Thanks to the following people. This documentation would not be possible without their contribution. Also, specific thanks to Mary Siart, Heidrun Wietzorek and Armin Kompalka for their outstanding dedication to complete this documentation.

Hans Baessler, SAP AG

Reggie Culpepper, Mainstar Corporation

Bill Franklin, IBM Silicon Valley Lab

Maik Gasterstaedt, IBM Deutschland

Rainer Himmelsbach, IBM Deutschland Research and Development

Thomas Hubbard, Rocket Software

Jennifer Johnson, SAP AG

Laura Kunioka-Weis, IBM Silicon Valley Lab

Christian Michel, IBM Deutschland Research and Development

Albert Rodi, IBM Americas Sales and Distribution

Helmut Schilling, IBM Deutschland Research and Development

Glenn Wilcock, IBM Tucson Lab

Emil Wolf, IBM Deutschland Research and Development

Jochen Wolter, SAP AG

Karola Wunderlich, IBM Deutschland Research and Development



1. Introduction Among the key capabilities of database systems relevant for SAP applications are non-disruptive and efficient backup, automated and fast recovery and point-in-time recovery, 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 the whitepaper also apply to a number of non-SAP applications. The whitepaper first discusses the general SAP requirements in the areas of backup, recovery and database system cloning. It then describes the history of DB2 backup technologies that in the past were used by many SAP customers and how this has evolved 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. After describing this strategic solution at a high level, some use cases are defined that are typical for SAP customers. 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 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 Boeblingen Lab.



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

SAP applications basically use the database system to store their data 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 re-instated with minimal disruption in operations after any kind of hardware, software, operational or environmental error or outage. These processes are a crucial factor that determine system availability and reliability. Therefore, your IT experts must first develop a solid understanding of these processes, then carefully assess their requirements. Using skillful planning, they can then develop use these procedures to provide the maxiumum 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 the same way.

In SAP environments, it is common to create clones of SAP systems, which themselves include clones of the database system. 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 mass testing.

Moreover, cloning of database systems can become crucially important 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.

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

• Unobtrusive data backup processes

• Minimized recovery downtime both at database system and object levels

• Ability to easily undo logical application errors

• Integrated disaster recovery solution

• Database system cloning

• Federated recovery of multiple database systems to current and to a prior points in time



3. History of DB2 backup technologies for SAP Since the early days of DB2 in the 1980s, backup and recovery utilities were provided within the product and worked seamlessly with DBM1, RDS and media manager components of DB2.

The higher the system availability requirements, database change rate and size, the more advanced hardware and software resources and the more demanding the backup and recovery procedures must be. It is important to bear in mind that an SAP database includes all the table spaces, indexes and DB2 catalog and directory entries (practically all the catalog and directory table spaces and indexes) that are pertinent to the SAP system.

From the viewpoint of operational and semantical integrity, an SAP database as a whole needs to be considered as being a single unit of recovery. In other words, if a single SAP tablespace needs to be recovered to a point in time, all other SAP table spaces and indexes need to be either also recovered to the same point in time, or already be at the state that existed at the point in time. A prior point in time recovery is an example of when the entire SAP database might need to be recovered, while a recovery to the current state is an example of when only damaged table spaces and indexes must be recovered, since the rest of the data is already at the current level.

There is also a distinction between the major maintenance strategies in classical or legacy database landscapes, and SAP ERP and other SAP offerings.

In this area, there is a demand for the following:

• Non-disruptive database maintenance including backup and recovery

• Very large databases which takes a lot of time and server resources to complete a full, instant and consistent backup

• Very fast and complete backups for multifunctional usage (traditional backup, cloning for test, development, integration, shadow copy for analysis environments)

In this context, more hardware-related functions are exploited by DB2, in particular snapshot, mirroring and flashcopy technology from IBM and other vendor storage subsystems.

The two types of online backups are object-based and volume-based.

Object-based backups are image copies of DB2 tablespaces, partitions and selected indexes. Volume-based backups are copies of the volumes on which DB2 objects reside.

Figure 1 shows the evolution of the backup and recovery technology of DB2, from the inbuild image copy feature in DB2 Version 1 to the incremental flashcopy of today:



Figure 1: Evolution of Backup and Recovery Technology of DB2 In addition to this base technology, tools and utilities provide more management capabilities to integrate and automate these processes in a customer’s complex and heterogeneous production environment. Some of these tools are DB2 Recovery Expert, DB2 Cloning Tool, SAP CCMS, Tivoli enterprise console.

Storage-related backup technologies have significant advantages regarding speed, continuous availability, TCO control (by reducing CPU cycles) and maintenance complexity minimization (by being fully integrated in the existing IBM System z system managed storage (SMS) architecture). Traditional image copies are not totally replaced today, but they are only required in specific cases. Some DB2 utilities need single object backup for the internal database integrity. But the evolution continues to go on …

However, the traditional DB2 RECOVER utility needed to be enhanced with system-level functionality: the RESTORE SYSTEM utility, which DB2 introduced with V8.

The RECOVER utility is a versatile DB2 utility. It allows you to recover DB2 objects of various granularities: table space, index, table space partition, individual data set, individual page. As shown in Figure 2, the RECOVER utility can recover data to different points in time.

Figure 2: Points in Time Available with the RECOVER Utility The RESTORE SYSTEM utility has offered similar functions at system level since DB2 V8. It provides all operations documented above by utilizing z/OS DFSMShsm functionality under the control of DB2.



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

Disaster recovery in a DB2 for z/OS environment is addressed using GDPS. This topic is beyond the scope of this document. The remaining SAP requirements are fundamentally based on standard backups created by the DB2 BACKUP SYSTEM utility. The counter-part that allows highly automated recovery to a prior or current point in time is the DB2 RESTORE SYSTEM utility.

Base Technology 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 with the 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. 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. Figure 3 depicts the state when the relationship of the source and target volumes has been established, but no data was physically copied yet.

Figure 3: 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 V2 has introduced 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 copy changed tracks to the backup volumes overriding the initial full base backup.

The advantages of incremental FlashCopy are:

• Considerably reduction of the elapsed time of the 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 IOs have a lower priority than other IO operations. While a volume can usually be in up to 12 FlashCopy relationships concurrently,



only a single FlashCopy target can be incremental. Besides DS8000, EMC and HDS also provide support for FlashCopy and can be used for DB2 BACKUP SYSTEM and RESTORE SYSTEM.

Figure 4 visualizes incremental FlashCopy. Note that incremental FlashCopy also supports copying the changed tracks back from the target to the source. However, this does not apply to DB2’s exploitation of incremental FlashCopy.

Figure 4: Incremental FlashCopy DFSMShsm is a component of the z/OS operating system. It is based on the DFSMSdss component of z/OS that provides lower level access to the disk. DFSMShsm provides 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 center around 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. z/OS 1.8 has introduced support for the setting VERSIONS=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 changed tracks on the source volumes are copied to the target volumes. 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 Reference.

Figure 5 visualizes the relationship between the following: 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 backup copy pool needs to have twice as many volumes as the source copy pool.



Copy pool CP1

Storage group Src2Type:

POOL

CopyPool Backup name:

CPB1

Storage group Src1Type:

POOL


CPB1

Storage group CPB1Type:

COPY POOL BACKUP


N/A

Figure 5: 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. This utility has been optimized for SAP; it is the primary utility for making DB2 backups in SAP environments. However, 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 $DB containing all application data and the DB2 catalog and directory and corresponding ICF catalogs

• A copy pool for the log called $LG containing the DB2 log data sets, BSDS and corresponding ICF catalogs

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

Starting with DB2 9, BACKUP SYSTEM also allows you to dump existing or new backups to tape. Additionally, it is capable of exploiting incremental FlashCopy, which DFSMShsm supports as of z/OS 1.8. 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. SAP CCMS provides support for the BACKUP SYSTEM utility as described in SAP Note 1225355. Figure 6 summarizes the relationship between FlashCopy, DFSMSdss, DFSMShsm and DB2 BACKUP SYSTEM.



DB2 BACKUP SYSTEM

DFSMShsm Fast

Replication Services

DFSMSdss

DS8000 FlashCopy

DB2 BACKUP SYSTEM

DFSMShsm Fast

Replication Services

DFSMSdss

DS8000 FlashCopy

processesprocesses

processesprocesses

performsperforms

performsperforms

DB2 subsystem or

data sharing group

Copy pool

FlashCopy call

Efficiently copy data

DB2 subsystem or

data sharing group

Copy pool

FlashCopy call

Efficiently copy data

System z

Figure 6: Relationship Between System z and Flash Copy 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. If database systems need to be recovered to the point in time when a backup was created, this can be easily achieved by restoring the volumes of the DB2 database using DFSMShsm or DFSMSdss commands and subsequently restarting the DB2 subsystem. In any case, 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.

DB2 Cloning Tool for z/OS The IBM DB2 Cloning Tool for z/OS provides a fast and simple cloning solution to improve performance and reduce the total cost of ownership of a DB2 system.

The DB2 Cloning Tool provides access to cloned data using a very fast and sophisticated technique to rename the cloned data, as well as to alter and correct any inconsistencies in 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.

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

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 IBM DB2® Recovery Expert for z/OS® provides a simple, self-managing recovery solution that enables database recovery operations with minimal disruption. These features provide an intelligent analysis of altered, incorrect or missing database assets that include tables, indexes, and data. DB2 Recovery Expert for z/OS also automates the process of rebuilding these assets to a specified point in time, often without taking the database or the business operations offline. IBM DB2 Recovery Expert for z/OS v2.1 introduces System Backup and Restore Services that allow you to back up and restore entire DB2 subsystems using the advanced techniques provided by storage subsystems. System Backup and Restore Services use the DB2 BACKUP SYSTEM utility, IBM FlashCopy® facilities, or TimeFinder/Mirror and TimeFinder/Snap facilities to provide full backups of DB2 data and logs on a DB2 subsystem.

DB2 Recovery Experts supports:

• Application recovery

• Drop recovery

• Single or multiple objects

• Dependency analysis

• Quiet point analysis

• Fast replication support

• IBM DS8000 and FlashCopy

• EMC TimeFinder/Snap

• TimeFinder Core including TimeFinder Mirror or TimeFinder consistency group option

• DB2 Backup System and Restore System utilities

• Disaster Recovery

The following is a partial list of the tasks that DB2 Recovery Expert accomplishes:

• Automates manual tasks

• Ensures all source data of a DB2 subsystem is included

• Ensures source data is correctly separated

• Performs validation for each system backup

• Ensures backups are recoverable

• Includes additional functionality beyond basic DB2 Utilities

• Easy-to-use GUI and TSO ISPF interface

• Recovers from a specific generation of backup either on tape or disk

• Automatically and efficiently handles all tape processing when restoring the DB2 system or individual objects from a system level backup on tape

• Automates the process of disconnecting and ICF catalogs in use by DB2

• Automates the process of deletion of CF structures during Restore

• Automates reset of COPYP status during Backup

• Automates restoration of underlying datasets of tablespace

• Restores an object or predefined groups of objects from the most appropriate backup image copy

• Extends capability to restore objects from a system-level backup to DB2 V8



• Uses native hardware interfaces to enhance DB2’s backup and recovery capabilities



5. Setup for Sample SAP Use Cases Setup of SAP and DB2 Systems Within the Sysplex COB several LPARs are defined. One LPAR is used for zVM Linux guests, which are used for the SAP application servers. Since one SAP database is organized in data sharing, there are three additional LPARs for the SAP databases.

For testing the DB2 BACKUP SYSTEM and RESTORE SYSTEM and the tools DB2 Cloning and Recovery Expert together with an SAP application, two different SAP systems with different characteristics are available:

Characteristics of SAP system D91 • SAP ERP 2005 SR2 (fat client) • ABAP plus Java stack • Unicode • DB2 in non data sharing mode

Characteristics of SAP system N61

• SAP NetWeaver 2004s SR2 (fat client) • ABAP stack only • Non-Unicode • DB2 in data sharing mode with three DB2 members

Each SAP system has one central instance as an application server, and each central instance is located in a separate Linux for System z guest. The current installed level is Suse Linux for z System SLES10 Support Package 2. The SAP application servers for the cloned databases have been installed initially from SAP CDs with SAP NetWeaver 7.0 SR3 and SAP ERP 6.0 SR3 (thin client). The LPARs for the database systems are equipped with z/OS 1.9.

For SAP system N61, DB2 runs in data sharing mode, therefore each DB2 member is defined in its own LPAR.

For the backup and restore activities a Copy Pool Backup is created for each SAP system with minimum size like the source database. For the cloning test activities another DB2 subsystem is defined and a volume pool for the target database is defined for each SAP system. The connection between Linux for System z and the database is established by HiperSockets LAN. The volume pools are accessible from each LPAR with a database (from COB1, COB2 and COB3).



LPAR VMCOB z/VM 5.3, 16GB Storage, 4 CPs, VDISKs for zLinux swap vols

SAP Application Server:zLinux Guest = ihlscob1

SAP NetWeaver 2004s SR2SAPSID = N61DB ID = DBN6


SAP ERP 2005 SR2SAPSID = D91DB ID = D911


SAP NetWeaver 7.0 SR3SAPSID = NC1DB ID = DBNC


SAP ERP 6.0 SR3SAPSID = D9KDB ID = D91K

Copy Pool Backupfor DB2 SGname

DBN6

Copy Pool Backupfor DB SSID D911

Copy Poolfor DB2 SGname

DBN6

Source


DBN6

Source


DBNC

Clone


DBNC

Clone

Copy PoolDB SSID = D91K

Clone


Clone

Copy PoolDB SSID = D911

Source


Source

LPAR COB2z/OS 1.9, 4CP, 1zIIP, 2GB stor, zFS, DB2 V9

DB2 Source DBData-Sharing SystemDB2 SGname = DBN6DB2 Member = SN62

Cloning DBData-Sharing System

DB2 SGname = DBNCDB2 Member = SNC2






DB2

Source DBNon-Data-Sharing Syst.DB System ID = D911

Source DBData-Sharing SystemDB2 SGname = DBN6DB2 Member = SN61

Cloning DBNon-Data-Sharing Syst.DB System ID = D91K




DB2














Volume Pools

System COB on z9, DAN2

CF

TapeTape TapeTape

HiperSocket LAN

Figure 7 depicts this setup in detail:



LPAR VMCOB z/VM 5.3, 16GB Storage, 4 CPs, VDISKs for zLinux swap vols


SAP NetWeaver 2004s SR2SAPSID = N61DB ID = DBN6


SAP ERP 2005 SR2SAPSID = D91DB ID = D911


SAP NetWeaver 7.0 SR3SAPSID = NC1DB ID = DBNC


SAP ERP 6.0 SR3SAPSID = D9KDB ID = D91K

Copy Pool Backupfor DB2 SGname

DBN6

Copy Pool Backupfor DB SSID D911


DBN6

Source


DBN6

Source


DBNC

Clone


DBNC

Clone


Clone


Clone


Source


Source










DB2







DB2














Volume Pools

System COB on z9, DAN2

CF

TapeTape TapeTape

HiperSocket LAN

Figure 7: Setup of Sample SAP System on IBM System z



DFSMShsm Definitions With z/OS V1.5, the SMS (Storage Management Subsystem) was enhanced to include constructs like copy pool and types of storage groups like copy pool backup. This enhancement enables 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 and storage pools that are included in the copy pools need to be disjoint.

Before setting up the HSM copy pool environment, please check with your z/OS system administration to ensure that the dedicated VTOC catalog for the DB2 objects is defined with multi-level-alias. You can only separate the datasets from log/BSDS and user-data to multiple copy pools with this configuration. You can check this in the SYS1.PARMLIB or define it dynamically using command < F CATALOG,ALIASLEVEL(2)>. However, if you define it dynamically, you must add this definition later to the PARMLIB command-list-file to ensure persistent usage.

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(COBD21) PURGE - VTOC(072,0,3645) - INDEX(000,1,1079) - OWNERID(COBDATA) STGR ...

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

DB2 imposes a certain naming convention for the copy pools that it uses:

DSN$<locn-name>$<cp-type>

where: • DSN is the unique DB2 product identifier • $ is a fixed character delimiter • <locn-name> is the DB2 location name • $ is a fixed character delimiter • <cp-type> is the copy pool type. Use DB for database and LG for log

The copy pool names in this test system have been created regarding those naming convention out of DSN$, plus DB location name (which consist of sysplex name and DB2 system ID) and plus the copy pool type DB or LG.

Copy Pool Definition in ISMF - selection P for ‘Copy Pool - Specify Pool Storage Groups for Copies’ :

# BACKUP AUTO DUMP STORAGE STORAGE COPY POOL NAME VERSIONS DUMP CLASS GRP NAME GRP NAME -------------(2)-------------- --(3)--- (4)- --(9)--- --(14)-- --(15)-- DSN$COBDBN6$DB 1 YES DB2DUMP1 DB2D1 -------- DSN$COBDBN6$LG 1 YES DB2DUMP1 DB2D1L DB2D1M DSN$COBD911$DB 1 YES DB2DUMP1 DB2D2 -------- DSN$COBD911$LG 1 YES DB2DUMP1 DB2D2L DB2D2M



Due to dual logging, there are two volumes defined for $LG copy pool, one for the log datasets and the BSDS (bootstrap datasets). This configuration was chosen since there was no guaranteed space defined in the SMS in the workshop environment. Also, it is beneficial to be able to locate the different log datasets on different volumes under SMS control.

Storage Group Definition in ISMF - selection 6 for ’Storage Group - Specify Volume Names and Free Space Thresholds’ :

STORGRP OSMC EXTEND CP BCKP NAME SYSTEM OVERFLOW SG NAME SG NAME --(2)--- --(40)-- --(41)-- --(42)-- --(43)-- DB2D1 -------- NO -------- DB2F1 DB2D1L -------- NO -------- DB2F1L DB2D1M -------- NO -------- DB2F1M DB2D2 -------- NO -------- DB2F2 DB2D2L -------- NO -------- DB2F2L DB2D2M -------- NO -------- DB2F2M DB2D3 -------- NO -------- DB2F1

With these definitions, the source pools and the copy pool backup are connected to each other.

Each storage group includes at least one or more volume. For example, the connection of storage groups and volumes of DB2 subsystem D911 and its database data ($DB) is defined as follows:

D SMS,SG(DB2D1),LISTVOL IGD002I 15:28:49 DISPLAY SMS 823 STORGRP TYPE SYSTEM= 1 2 3 4 DB2D1 POOL + + + + VOLUME UNIT SYSTEM= 1 2 3 4 STORGRP NAME COBD11 2411 + + + + DB2D1 COBD12 2412 + + + + DB2D1 COBD13 2413 + + + + DB2D1 COBD14 2414 + + + + DB2D1 COBD15 2415 + + + + DB2D1 COBD16 2416 + + + + DB2D1 ***************************** LEGEND ***************************** . THE STORAGE GROUP OR VOLUME IS NOT DEFINED TO THE SYSTEM + THE STORAGE GROUP OR VOLUME IS ENABLED - THE STORAGE GROUP OR VOLUME IS DISABLED * THE STORAGE GROUP OR VOLUME IS QUIESCED D THE STORAGE GROUP OR VOLUME IS DISABLED FOR NEW ALLOCATIONS ONLY Q THE STORAGE GROUP OR VOLUME IS QUIESCED FOR NEW ALLOCATIONS ONLY > THE VOLSER IN UCB IS DIFFERENT FROM THE VOLSER IN CONFIGURATION

The connection of storage groups and volumes of DB2 subsystem D911 and its database log ($LG) are defined as follows:

STORGRP TYPE SYSTEM= 1 2 3 4 DB2D1L POOL + + + + VOLUME UNIT SYSTEM= 1 2 3 4 STORGRP NAME COBD1L 2441 + + + + DB2D1L



and

STORGRP TYPE SYSTEM= 1 2 3 4 DB2D1M POOL + + + + VOLUME UNIT SYSTEM= 1 2 3 4 STORGRP NAME COBD1M 2443 + + + + DB2D1M

Finally, combining the DB2 information with storage and volume pool information of both DB2 systems, and their information about source, backup and target/clone pools, the following system table can be shown:

DB2 Information Source System Backup Data Target System Source System Backup Data Target System DB2 Group Name DBN6 DBNCSSID D911 D91K SN61, SN62, SN63 SNC1, SNC2, SNC3

Volumes Catalog Identifier (VCAT) DSN911 DSN91K

DBN6.SN61DBN6.SN62DBN6.SN63

DBNC.SNC1DBNC.SNC2DBNC.SNC3

Pools Information Source Copy Pool Copy Pool Backup Target Copy Pool Source Copy Pool Copy Pool Backup Target Copy Pool on different box

DB2 Log Pool DB2D2LDB2D2M

DB2F2LDB2F2M

DB2C2LDB2C2M

DB2D1LDB2D1M

DB2F1LDB2F1M

DB2C1LDB2C1M

DB2 Log Volumes COBD2L COBD2M

COBF2L COBF2M

COBC2L COBC2M

COBD1L COBD1M

COBF1L COBF1M

COBD1L -> COBC1LCOBD1M -> COBC1M

DB2 Data Pool DB2D2 DB2F2 DB2C2 DB2D1 DB2F1 DB2C1DB2 Data Volumes COBD21-28 COBF21-28 COBC21-28 COBD11-16 COBF11-16 COBD11-16 -> COBC11-16

Non Data Sharing System Data Sharing System

-

For more detailed information about the DFSMShsm Fast Replication function and FlashCopy, see the IBM Redbook DFSMShsm Fast Replication Technical Guide (SG24-7069-00) at http://w3.itso.ibm.com/abstracts/sg247069.html?Open



Tape Definitions We decided to work with manual tape processing (no scratch pool, no tape robot) for the test scenario. In a production system, this is quite unusual. However, this method was sufficient for the test cases of the workshop.

The hardware is a 3592 Enterprise Tape System (3592-J1A). Tape addresses are 1A50 and 1A51, and as tape media, Media5 was written with EFMT1 (Enterprise Format 1), which compresses to 900 GB.

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

/*************************************************************/ /*-------------- COMPACTING, BLOCKING -----------------------*/ /*************************************************************/ SETSYS COMPACTPERCENT(40) SETSYS OBJECTNAMES(OBJ,OBJECT,LOAD,LOADLIB,LINKLIB) SETSYS SOURCENAMES(ASM,COBOL,FORT,PL1,SRC,SCRLIB,SRCE,CNTL,JCL) SETSYS COMPACT(NOTAPEBACKUP) SETSYS COMPACT(DASDBACKUP) SETSYS COMPACT(NOTAPEMIGRATE) SETSYS COMPACT(DASDMIGRATE) SETSYS OPTIMUMDASDBLOCKING SETSYS EXPORTESDS(CIMODE) SETSYS USERUNITTABLE(T3592RZ) *1 SETSYS TAPEHARDWARECOMPACT ... /*************************************************************/ /* TAPE HANDLING */ /*************************************************************/ SETSYS DEFERMOUNT SETSYS INPUTTAPEALLOCATION(NOWAIT) SETSYS MAXSINGLEFILEBLOCKS(11421) SETSYS UNITNAME(T3592RZ) SETSYS MIGUNITNAME(T3592RZ) SETSYS ML2RECYCLEPERCENT(30) SETSYS RECYCLEOUTPUT(BACKUP(T3592RZ) - MIGRATION(T3592RZ)) SETSYS RECYCLEPERCENT(30) SETSYS RECYCLETAPEALLOCATION(NOWAIT) SETSYS MAXRECYCLETASKS(1) SETSYS MOUNTWAITTIME(30) SETSYS SELECTVOLUME(DUMP(SPECIFIC)) SETSYS OUTPUTTAPEALLOCATION(NOWAIT) SETSYS TAPEDELETION(HSMTAPE) SETSYS TAPEFORMAT(SINGLEFILE) SETSYS TAPEINPUTPROMPT(BACKUPTAPES(NO) - DUMPTAPES(NO) - MIGRATIONTAPES(NO)) SETSYS TAPEUTILIZATION(UNITTYPE(T3592RZ) PERCENTFULL(95)) SETSYS PARTIALTAPE(REUSE) /*************************************************************/ /* DUMP */ /*************************************************************/



SETSYS AUTODUMPSTART(0000,0000,0000) SETSYS VOLUMEDUMP(CC) SETSYS DUMPIO(4,4) SETSYS MAXDUMPTASKS(2) DEFINE DUMPCYCLE(NNNNNYY CYCLESTARTDATE(2003/09/22)) DEFINE DUMPCLASS(STANDARD - AUTOREUSE - FREQUENCY(10) - STACK(1) - NORESET - UNIT(T3592RZ) - TAPEEXPIRATIONDATE(99365) - RETENTIONPERIOD(42) - VTOCCOPIES(3) - ) DEFINE DUMPCLASS(DB2DUMP1 - AUTOREUSE - DATASETRESTORE - FREQUENCY(1) - STACK(25) - *2 NORESET - TAPEEXPIRATIONDATE(99365) - RETENTIONPERIOD(5) - *3 UNIT(T3592RZ) - VTOCCOPIES(3) - ) ADDVOL COB003 UNIT(3590-1) DUMP (DUMPCLASS(DB2DUMP1)) *4 ADDVOL COB004 UNIT(3590-1) DUMP (DUMPCLASS(DB2DUMP1)) ADDVOL COB005 UNIT(3590-1) DUMP (DUMPCLASS(DB2DUMP1)) ...

*1 This is the Enterprise format, which is also the esoteric name in HCD.

*2 The Stack should be adapted regarding the tape size. During the workshop large tapes have been used, called IBM TotalStorage – Enterprise Tape Cartridge 3592.

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

*4 COB003, COB004 and COB005 are tape names in the workshop environment. Each tape used for the backup was defined in this way for HSM.

Configuration of DB2 Recovery Expert for z/OS Figure 8 shows the configuration of Recovery Expert (RE) in a Sysplex environment with a Data Sharing Group consisting of three members (SN61, SN62, SN63) in three different LPARs and one Non Data Sharing DB2(D911).



Figure 8: Recovery Expert Sample Configuration The following RE components are required for the environment:

RE Server DB2RESV1: Manages and controls all RE that are performed on behalf of user requests. At least one instance of the server must run to manage all of the DB2 subsystems and data sharing groups and to support all of the DB2 RE user clients. The DB2 RE server, clients, and agents communicate with each other to perform the recovery functions.

RE Agents DB2REAG1, DB2REAG2, DB2REAG3: The agents provide access to database and system services, in support of the DB2 Recovery Expert for z/OS server and remote clients. One instance of the agent must run on every system or logical partition (LPAR) that hosts DB2 subsystems or data sharing groups that you want to access with DB2 RE. Each agent communicates with the RE server.

RE RBA capture utility DB2RERB2, DB2RERB2, DB2RERB3: Optional RBA capture utility to track RBAs and their associated timestamps. This tool makes it easier to identify the RBA/LRSN to which to the system must be restored.

Schema level repository for DB2 D911 and DB2 Group DSN6: An archive to hold object definitions and alterations to object definitions. A schema level repository must exist for each DB2 or data sharing group that should be managed by RE. The repository must be updated periodically.

System backup and restore services repository: One set of VSAM files to store information necessary for tracking information related to system level backups and DB2 subsystem definitions. One set of VSAM files can keep all the information for the DB2 subsystems and data sharing groups.

ISPF Interface: Assists with setting the options used when creating and using system level backups managed by RE.

GUI Windows Client: GUI with menus that make recoveries to a point in time current, quick and precise.

Non-DS DB2D911

DS DB2 DBN6 SN61

LPAR1 COB1

Recovery ExpertAgent

DB2REAG1

Recovery Expert RBA CaptureDB2RERB1

Recovery Expert Server

DB2RESV1

DS DB2 DBN6 SN62

LPAR2 COB2


DB2REAG2


DS DB2 DBN6 SN63

LPAR3 COB3


DB2REAG3


clientclient 9.152.25.225:5889

Schema Level Repository

D911

SBRS

RepositoryVSAM

Schema Level Repository

DBN6

ISPFISPF



Recovery Expert Address Space and Related Ports

LPAR COB1 COB2 COB3

Server DB2RESV1

Agent DB2REAG1 DB2REAG2 DB2REAG3

RBA Capture DB2RERB1 DB2RERB2 DB2RERB3

Client Listener Ports 5889

Agent Listener Ports 5888

Server Ports 5888 5888 5888

Start/ Stop Recovery Expert Address Spaces Start Server: S DB2RESV1 on LPAR COB1 Stop Server: P DB2RESV1 on LPAR COB1 Start Agents: S DB2REAG1/ 2/ 3 on the related LPAR Stop Agents: P DB2REAG1/ 2/ 3 on the related LPAR Start RBA Captures: S DB2RERB1/ 2/ 3 on the related LPAR Stop RBA Captures: P DB2RERB1/ 2/ 3 on the related LPAR

Repositories Each DB2 subsystem requires one Recovery Expert Schema Level Repository. We defined one for DB2 subsystem D911 and one for DBN6.

Update schema level repository (SLR) The related update jobs for the SLR are:

DB2TOOLS.DB2RE.V210.DBN6.SARYSAMP(ARYSJ002) DB2TOOLS.DB2RE.V210.D911.SARYSAMP(ARYSJ002)

The System backup and restore services (SBRS) component of Recovery Expert is shared by all agents across the Sysplex. We created it only once and assigned it to a shared disk with the following dataset names:

DB2TOOLS.DB2RE.SYSBACK.BACKUP DB2TOOLS.DB2RE.SYSBACK.DATA DB2TOOLS.DB2RE.SYSBACK.INDEX DB2TOOLS.DB2RE.SYSBACK.OBJS DB2TOOLS.DB2RE.SYSBACK.OBJS.DATA



DB2TOOLS.DB2RE.SYSBACK.OBJS.INDEX DB2TOOLS.DB2RE.SYSBACK.SSIDS DB2TOOLS.DB2RE.SYSBACK.SSIDS.DATA DB2TOOLS.DB2RE.SYSBACK.SSIDS.INDEX DB2TOOLS.DB2RE.SYSBACK.VOLS DB2TOOLS.DB2RE.SYSBACK.VOLS.DATA DB2TOOLS.DB2RE.SYSBACK.VOLS.INDEX DB2TOOLS.DB2RE.SYSBOBJ.BACKUP DB2TOOLS.DB2RE.SYSBVOL.BACKUP DB2TOOLS.DB2RE.SYSSSID.BACKUP

The dataset names must be defined in the System Backup Recovery Services options section of the configuration file and the ARYV210 CLIST calling the Recovery Experts System Backup Recovery Services.

Excerpt of configuration statements for DB2 subsystem D911:

* System Backup Recovery Services Options * UPDATE RBR DEVICE = SYSALLDA *UPDATE RBR EMC LOAD1 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX *UPDATE RBR EMC LOAD2 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX *UPDATE RBR EMC LOAD3 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX *UPDATE RBR EMC LOAD4 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX *UPDATE RBR FDR LOAD1 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX *UPDATE RBR FDR LOAD2 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX UPDATE RBR PROF REPO = DB2TOOLS.DB2RE.PROFILES UPDATE RBR MAPS REPO = DB2TOOLS.DB2RE.PROFILE.MAPS UPDATE RBR CATS REPO = DB2TOOLS.DB2RE.PROFILE.CATS UPDATE RBR SYSBK REPO = DB2TOOLS.DB2RE.SYSBACK UPDATE RBR BKUP VOLS = DB2TOOLS.DB2RE.SYSBACK.VOLS UPDATE RBR BKUP SSID = DB2TOOLS.DB2RE.SYSBACK.SSIDS UPDATE RBR BKUP OBJS = DB2TOOLS.DB2RE.SYSBACK.OBJS UPDATE RBR REPORT REPO = DB2TOOLS.DB2RE.BREPORT UPDATE RBR OFFLD REPO = DB2TOOLS.DB2RE.OFFOPTS UPDATE RBR PARMLIB = DB2TOOLS.DB2RE.V210.D911.SARYSAMP UPDATE RBR PARMLIB MBR = ARY#PARM

The Control File There is one control file for all DB2 subsystems defined in the sysplex that contains all DB2 subsystem specific information. The control file is maintained by the ARY#UTIL utility of Recovery Expert. A sample job is available in the SAMPLIB of Recovery Expert. To separate the definitions of each DB, we created for every DB2 subsystem its own control file definition member. In the Utility job, we concatenated the members and SYSIN DD.

Example of Utility job:

//PCFUPDT EXEC PGM=ARY#UTIL,PARM='SETUP',REGION=4M //STEPLIB DD DISP=SHR,DSN=SYS1.DB2RE.V210.SARYLOAD //SYSUDUMP DD SYSOUT=* //DB2PARMS DD DISP=SHR,DSN=DB2TOOLS.DB2RE.V210.CONTROL //* //* REPORTS //*



//SYSOUT DD SYSOUT=*,RECFM=FBA,LRECL=133 SYSIN REPORT //SYSPRINT DD SYSOUT=*,RECFM=FBA,LRECL=133 PCF REPORT //* //* CONTROLS //* //SYSIN DD DISP=SHR,DSN=DB2TOOLS.DB2RE.V210.D911.SARYSAMP(CNTLD911) // DD DISP=SHR,DSN=DB2TOOLS.DB2RE.V210.DBN6.SARYSAMP(CNTLSN61) // DD DISP=SHR,DSN=DB2TOOLS.DB2RE.V210.DBN6.SARYSAMP(CNTLSN62) // DD DISP=SHR,DSN=DB2TOOLS.DB2RE.V210.DBN6.SARYSAMP(CNTLSN63) // DD DISP=SHR,DSN=DB2TOOLS.DB2RE.V210.DBN6.SARYSAMP(CNTLDBN6)

You can find the control file samples in the appendix.

Care should be taken when you define the control file:

You receive the error message ARYE005E when

UPDATE ARY DSN PREFIX = &USERID

is longer then 17 characters.

The length will be not checked by utility so the error appears when the Recovery Expert is used.

Quotes cause an allocation error and must be not used. See the following statement in ARYSJ001 for each subsystem:

UPDATE LAS DSN PREFIX = DB2TOOLS.DB2RE.V210

RBR BACKUP AND RECOVERY FOR DB2 Parameters The RBR_BACKUP_AND_RECOVERY_FOR_DB2 member name is ARY#PARM. The members are located in

DB2TOOLS.DB2RE.V210.D911.SARYSAMP

DB2TOOLS.DB2RE.V210.SN61.SARYSAMP

To reset the COPY Pending Status with BACKUP SYSTEM we changed two parameters in the parameter member ARY#PARM:

RESET_COPY_PENDING_TS Y(yes)

RESET_COPY_PENDING_IX Y(yes)

If these are set to Y (yes), all copy pending table and index spaces included in the back-up will have the COPYP reset.



Start ISPF Recovery Expert Interface There is procedure ARYV21 in the samplib of Recovery Expert. In our example, we call the procedure from our general DB2 administration panel.

Enter TSO ARYV21 in the DB2 Administration menu:

Figure 9: General DB2 Administration Panel



Start Recovery Expert GUI Interface After the GUI was started from the Start menu, enter the host name or IP address and port of a RE as follows:

9.152.24.225:5889

where 9.152.25.225 is the IP address and 5889 is the port number:

Figure 10: DB2 Recovery Expert Initial Configuration

Customization Jobs D911 and DBN6 The installation is based on directly customizing and executing the jobs provided in the product library SARYSAMP. To keep the customization jobs separated for each DB2, we created a dedicated samplib for each DB2 and data sharing group:

DB2TOOLS.DB2RE.V210.DBN6.SARYSAMP DB2TOOLS.DB2RE.V210.D911.SARYSAMP

The RE server, agents and RBA capture require specific configuration files that are included in the DD of the related RE startup jobs/ procedures. We created one central Parameter Library for Recovery Expert Agents, Server and RBA Capture:

DB2TOOLS.DB2RE.V210.CONFIG

The library contains all required configuration members for the RE server, agents and RBA capture (for configuration member, see the Appendix) :

CFGACOB1 CFGACOB2 CFGACOB3 CFGSCOB1 RBRSSB2 RBRSSB3 RBRSSID

The following is an example of Recovery Expert Started Tasks in LPAR COB1:



Figure 11: Recovery Expert Started Tasks in LPAR COB1

Configuring the DB2 Cloning Tool To clone a DB2 subsystem, the following items must be performed in advance:

1. Set up the target DB2 subsystem definitions so that the target DB2 subsystem can be started. For more information about setting up a DB2 subsystem, see the various IBM DB2 UDB for z/OS Administration Guides.

2. Set the special maintenance mode ZPARM in advance to allow the DB2 catalog to be updated when the target DB2 subsystem is brought up in maintenance mode.

3. Set the DB2 Cloning Tool command, DB2SQL by using a Plan and Bind to automate the generation and issuance of all required DB2 SQL statements to update the DB2 catalog.

The configuration of the DB2 Cloning Tool relies on the following data sets.

The System Libraries are:

SYS1.DB2CT.V210.SCKZLOAD SYS1.DB2CT.V210.SCKZBASE SYS1.DB2CT.V210.SCKZDBRM

Jobs can be found:

DB2TOOLS.DBN6.SYS1.DB2CT.V210.SCKZJC DB2TOOLS.D911.SYS1.DB2CT.V210.SCKZJC

Parameter Files can be found:

DB2TOOLS.DBN6.SYS1.DB2CT.V210.SCKZPARM DB2TOOLS.D911.SYS1.DB2CT.V210.SCKZPARM



In the use cases, the following jobs were run for subsystem D911 and for data sharing group DBN6.

• CKZIMRG (INIMERGE)

• CKZDBIND (Bind)

No parameter was changed in the sample jobs.



6. Representative SAP Use Cases The following sections discuss SAP use cases that are typical for a number of scenarios when running an SAP system. The use cases demonstrate how to combine certain backup, recovery and cloning activities.



7. DB2 Data Sharing & SAP ABAP-Only & DASD Use Case

The first use case addresses a DB2 data sharing group serving an SAP ABAP-only system. Also, it considers backups on DASD only.

This use case starts off by creating a full backup on DASD using the standard DB2 BACKUP SYSTEM utility. Subsequently, an incremental FlashCopy relationship is established and an incremental backup taken using BACKUP SYSTEM.

As a next step, a system-level recovery is performed to a prior point in time using the RESTORE SYSTEM utility. For this task, the new DB2 9 SYSPITRT option is used, which allows you to specify a GMT timestamp as the recovery target point. Subsequently, RESTORE SYSTEM is again used – this time to recover the complete DB2 subsystem to the current point in time. Then, a single tablespace is recovered – DB2 uses the system-level backup created earlier as basis for this recovery. The last recovery test of this use case natively restores the volumes of the DB2 data sharing group using the DFSMShsm FRRECOV command.

By now restarting the data sharing group, you complete the recovery to the point in time at which the backup was taken.

Finally, the backup on DASD is used as source for cloning the data sharing group into a new data sharing group. The DB2 Cloning Tool is used to automate and facilitate a number of steps necessary to create the clone. A mechanism to clone DB2 subsystems is described in the SAP System Copy Guide.

Backup to DASD Using BACKUP SYSTEM The first step of this use case is to create a standard backup using the DB2 BACKUP SYSTEM utility.

BACKUP SYSTEM internally invokes FlashCopy to create a new backup on DASD. The logical part of the copy is created in a matter of seconds. In this phase, a relationship is established between the source volumes in the DB2 copy pools – in which the original data sets used by DB2 are located – and the volumes in the copy pool backup storage group. Later, the physical creation of the copy in the backup storage groups is asynchronously performed via a background IO process. Depending on the size of the database, this phase of FlashCopy processing may take minutes or hours.

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 option.

//BACKS00A JOB (DE03557),CH,NOTIFY=BOEBLD1.DB2ADM3, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M /*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //************************************************************** //* STEP BACKUP: RUN BACKUP SYSTEM DATASHARING SN61 //************************************************************** //BACKUP EXEC DSNUPROC,SYSTEM=SN61, // UID='DB2ADM',LIB=SYS1.DSN.V910.SDSNLOAD //SYSIN DD * BACKUP SYSTEM FULL /*

The HSM LIST COPYPOOL command can be used to check the status of the backups created by HSM fast replication services. The option SELECT(FRSTATE(FAILED)) of this command can be used to check whether the backups created by fast replication services for DB2 BACKUP SYSTEM completed successfully.



The option SELECT(DUMPSTATE(PARTIAL)) of this command lists dump versions that did not complete successfully. A similar command, which works on the device level and not on the copy pool level, is the TSO command FCQUERY.

For more information about FCQUERY, see http://www.ibm.com/support/docview.wss?uid=isg3S1001398.

The following job output indicates the processing of the BACKUP SYSTEM utility execution. You can see in the following output example that first the data copy pool and then the log copy pool is copied. The internal token that is passed from DB2 to HSM is also displayed. This token can be used to identify certain backup versions in HSM.

14:06:38.86 DSNUGUTC - BACKUP SYSTEM FULL 14:06:40.58 DSNUVBBD - BACKUP SYSTEM UTILITY FOR DATA STARTING, M COPYPOOL = DSN$COBDBN6$DB TOKEN = X'E2D5F6F1C2978AD490CA08D9C29779B65135'. 14:06:42.40 DSNUVBBD - BACKUP SYSTEM UTILITY FOR DATA COMPLETED SUCCESSFULLY, COPYPOOL = DSN$COBDBN6$DB TOKEN = X'E2D5F6F1C2978AD490CA08D9C29779B65135' ELAPSED TIME = 00:00:01. 14:06:42.40 DSNUVBBD - BACKUP SYSTEM UTILITY FOR LOGS STARTING, COPYPOOL = DSN$COBDBN6$LG TOKEN = X'E2D5F6F1C2978AD490CA08D9C29779B65135'. 14:06:42.94 DSNUVBBD - BACKUP SYSTEM UTILITY FOR LOGS COMPLETED SUCCESSFULLY, COPYPOOL = DSN$COBDBN6$LG TOKEN = X'E2D5F6F1C2978AD490CA08D9C29779B65135' ELAPSED TIME = 00:00:00. 14:09:27.14 DSNUVBBD - BACKUP SYSTEM UTILITY COMPLETED, ELAPSED TIME = 00:02:46. 14:09:27.94 DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=0

Incremental Backup to DASD using BACKUP SYSTEM The following excerpt of a JCL job shows an invocation of the BACKUP SYSTEM utility that establishes an incremental FlashCopy relationship.

//BACKUP EXEC DSNUPROC,SYSTEM=SN61, // UID='DB2ADM',LIB=SYS1.DSN.V910.SDSNLOAD //SYSIN DD * BACKUP SYSTEM ESTABLISH FCINCREMENTAL /*

The following job output indicates the processing of the BACKUP SYSTEM utility execution. Note that as part of BACKUP SYSTEM processing, DB2 recognizes that a previously taken backup is incomplete and therefore automatically deletes this backup version. Also, be aware that an incremental FlashCopy relationship is only established for the data copy pool of DB2. The backups created for DB2’s log copy pool are always full FlashCopy backups.

09:12:15.36 DSNUGUTC - BACKUP SYSTEM FULL ESTABLISH FCINCREMENTAL 09:12:17.04 DSNUVBBD - AN INCOMPLETE BACKUP SYSTEM HISTORY ENTRY HAS BEEN FOUND IN THE BSDS INDICATING AN INVALID DATA AND LOG VERSION IN COPYPOOL = DSN$COBDBN6$DB FOR TOKEN = X'E2D5F6F1C29B3A202B94C5CBC29B38FA967700'. DFSMSHSM WILL BE CALLED TO DELETE VERSION. 09:12:17.55 DSNUVBBD - BACKUP SYSTEM UTILITY FOR DATA STARTING, COPYPOOL = DSN$COBDBN6$DB TOKEN = X'E2D5F6F1C29ED4388D5B2A46C29ED30F6510'. 09:12:19.26 DSNUVBBD - THE SYSTEM LEVEL BACKUP TAKEN IS AN INCREMENTAL FLASHCOPY OF THE DATABASE

http://www.ibm.com/support/docview.wss?uid=isg3S1001398



09:12:19.26 DSNUVBBD - BACKUP SYSTEM UTILITY FOR DATA COMPLETED SUCCESSFULLY, COPYPOOL = DSN$COBDBN6$DB TOKEN = X'E2D5F6F1C29ED4388D5B2A46C29ED30F6510' ELAPSED TIME = 00:00:01. 09:12:19.26 DSNUVBBD - BACKUP SYSTEM UTILITY FOR LOGS STARTING, COPYPOOL = DSN$COBDBN6$LG TOKEN = X'E2D5F6F1C29ED4388D5B2A46C29ED30F6510'. 09:12:19.75 DSNUVBBD - BACKUP SYSTEM UTILITY FOR LOGS COMPLETED SUCCESSFULLY, COPYPOOL = DSN$COBDBN6$LG TOKEN = X'E2D5F6F1C29ED4388D5B2A46C29ED30F6510' ELAPSED TIME = 00:00:00. 09:15:04.11 DSNUVBBD - BACKUP SYSTEM UTILITY COMPLETED, ELAPSED TIME = 00:02:46. 09:15:16.99 DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=0

When the BACKUP SYSTEM utility completes processing, a backup has been logically completed by FlashCopy and registered within DB2 and HSM. However, the physical background copy typically continues copying the volumes, which may take multiple hours depending on the size of the database. To check the activity of the physical FlashCopy background processing, you use the HSM QUERY COPYPOOL command.

In the following sample output of HSM QUERY COPYPOOL, you can see that two storage groups of the DB2 log copy pool are currently being copied. For the DB2 data copy pool, all volumes have successfully been copied as none of the volumes is being physically copied by an active FlashCopy background copy.

ARC1820I THE FOLLOWING VOLUMES IN COPY POOL DSN$COBDBN6$LG, VERSION 020, HAVE ARC1820I (CONT.) AN ACTIVE FLASHCOPY BACKGROUND COPY ARC1820I (CONT.) SGNAME FR-PRIMARY FR-BACKUP ARC1820I (CONT.) DB2D1L COBD1L COBF1L ARC1820I (CONT.) DB2D1M COBD1M COBF1M ARC1821I NONE OF THE VOLUMES IN COPY POOL DSN$COBDBN6$DB, VERSION 021, HAVE AN ARC1821I (CONT.) ACTIVE FLASHCOPY BACKGROUND COPY

The following lists the output of the HSM LIST COPYPOOL command in this state for the copy pool DSN$COBDBDBN6$DB. Note that the previous backup with version #19, which was taken on June 27, indicates INCREMENTAL=N while the latest backup indicates that the incremental FlashCopy relationship has been successfully established.

VERSION VTOCENQ DATE TIME FASTREPLICATIONSTATE DUMPSTATE 020 N 2008/06/30 09:12:17 RECOVERABLE NONE TOKEN(C)=C'SN61BÆM.ý$.ãBÆL.Á.' TOKEN(H)=X'E2D5F6F1C29ED4388D5B2A46C29ED30F6510' TOTAL NUM OF VOLUMES=00006,INCREMENTAL=Y SGNAME SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET DB2D1 COBD11 - COBF11 COBD12 - COBF12 COBD13 - COBF13 COBD14 - COBF14 DB2D1 COBD15 - COBF15 COBD16 - COBF16 VERSION VTOCENQ DATE TIME FASTREPLICATIONSTATE DUMPSTATE 019 N 2008/06/27 10:02:09 NONE ALLCOMPLETE TOKEN(C)=C'SN61Bº.E¡Ïb.Bº.Žei' TOKEN(H)=X'E2D5F6F1C29B19C5AA77820EC29B18BE8589' TOTAL NUM OF VOLUMES=00006,INCREMENTAL=N SGNAME SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET DB2D1 COBD11 - ****** COBD12 - ****** COBD13 - ****** COBD14 - ****** DB2D1 COBD15 - ****** COBD16 - ******



Then BACKUP SYSTEM is again invoked – without any options. The new backup is automatically an incremental FlashCopy backup that copies changed tracks from the DB2 data and log copy pools to the backup storage group overriding the existing copy. The reason for this is the following:

• An incremental FlashCopy relationship was previously established for the backup in the copy pool backup storage group

• There is a single backup version in that backup storage group

The following JCL excerpt indicates the BACKUP SYSTEM invocation:

//BACKUP EXEC DSNUPROC,SYSTEM=SN61, // UID='DB2ADM',LIB=SYS1.DSN.V910.SDSNLOAD //SYSIN DD * BACKUP SYSTEM /*

The following job output indicates the processing of the BACKUP SYSTEM utility execution:

10:15:39.22 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = DB2ADM 10:15:39.26 DSNUGTIS - PROCESSING SYSIN AS EBCDIC 10:15:39.27 DSNUGUTC - BACKUP SYSTEM FULL 10:15:40.92 DSNUVBBD - BACKUP SYSTEM UTILITY FOR DATA STARTING, COPYPOOL = DSN$COBDBN6$DB TOKEN = X'E2D5F6F1C29EE263B9E97B84C29EE0A4C931'. 10:15:44.18 DSNUVBBD - THE SYSTEM LEVEL BACKUP TAKEN IS AN INCREMENTAL FLASHCOPY OF THE DATABASE 10:15:44.18 DSNUVBBD - BACKUP SYSTEM UTILITY FOR DATA COMPLETED SUCCESSFULLY, COPYPOOL = DSN$COBDBN6$DB TOKEN = X'E2D5F6F1C29EE263B9E97B84C29EE0A4C931' ELAPSED TIME = 00:00:03. 10:15:44.18 DSNUVBBD - BACKUP SYSTEM UTILITY FOR LOGS STARTING, COPYPOOL = DSN$COBDBN6$LG TOKEN = X'E2D5F6F1C29EE263B9E97B84C29EE0A4C931'. 10:15:44.55 DSNUVBBD - BACKUP SYSTEM UTILITY FOR LOGS COMPLETED SUCCESSFULLY, COPYPOOL = DSN$COBDBN6$LG TOKEN = X'E2D5F6F1C29EE263B9E97B84C29EE0A4C931' ELAPSED TIME = 00:00:00. 10:18:30.55 DSNUVBBD - BACKUP SYSTEM UTILITY COMPLETED, ELAPSED TIME = 00:02:49. 10:18:43.06 DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=0

The following lists the output of the HSM LIST COPYPOOL command in this state for copy pool DSN$COBDBDBN6$DB.

Note that the backup with version #20 does not exist anymore as it was overwritten by the latest incremental backup. Therefore, the latest backup has version #21 and a new corresponding token number, which was passed by DB2 BACKUP SYSTEM for the last invocation. The incremental FlashCopy relationship is still persistent. This is indicated by INCREMENTAL=Y.

VERSION VTOCENQ DATE TIME FASTREPLICATIONSTATE DUMPSTATE 021 N 2008/06/30 10:15:40 RECOVERABLE NONE TOKEN(C)=C'SN61BÆSÄŸZ#dBÆ\uI.' TOKEN(H)=X'E2D5F6F1C29EE263B9E97B84C29EE0A4C931' TOTAL NUM OF VOLUMES=00006,INCREMENTAL=Y SGNAME SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET DB2D1 COBD11 - COBF11 COBD12 - COBF12 COBD13 - COBF13 COBD14 - COBF14 DB2D1 COBD15 - COBF15 COBD16 - COBF16



VERSION VTOCENQ DATE TIME FASTREPLICATIONSTATE DUMPSTATE 019 N 2008/06/27 10:02:09 NONE ALLCOMPLETE TOKEN(C)=C'SN61Bº.E¡Ïb.Bº.Žei' TOKEN(H)=X'E2D5F6F1C29B19C5AA77820EC29B18BE8589' TOTAL NUM OF VOLUMES=00006,INCREMENTAL=N SGNAME SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET DB2D1 COBD11 - ****** COBD12 - ****** COBD13 - ****** COBD14 - ****** DB2D1 COBD15 - ****** COBD16 - ******

RESTORE SYSTEM with Backup on DASD: PIT Recovery Specifying SYSPITRT The Restore System utility is used to perform a point-in-time recovery (PITR). After the log truncation point is established in the BSDS, Restore System restores the appropriate copy of the DSN$location_name$DB copy pool and applies log records to bring the DB2 system up to the log truncation point.

The CRESTART statement of the Change Log Inventory program, DSNJU003, is used to establish the log truncation point. The SYSPITR option is used when providing a RBA or a LRSN for the log truncation point, and SYSPITRT is used when providing a date and time of day as the log truncation point. The time is based on GMT and not local time. If the DB2 system to be restored is a data sharing system, then the log truncation point must be established in each member’s BSDSs.

In this PITR test a three member DB2 data sharing group was used; SN61, SN62 and SN63.

Recommendation

If DB2 data sharing has been enabled, and some of the members are passive and used as secondary members in support of data base server failover, it is important to run an ARCHIVE LOG SCOPE(GROUP) prior to bringing the DB2 group down for recovery. This is to ensure that all of the DB2 members have written out the most current LRSN, and the recover-to-time is not limited by members with low to no activity. This is also true when using date and time as the log truncation point.

HSM List Copy Pool Command Prior to performing any type of recovery that will use the Backup System copies that are maintained by HSM, you can use an HSM command. With this command, you can obtain information about which backups HSM has registered and whether or not they are usable in a recovery.

Sample HSM List Copy Pool Command Job:

//CPYLST8D JOB (DE03557),CH,NOTIFY=BOEBLD1.DB2ADM1, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M /*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //* //************************************************** //* LIST COPYPOOL //************************************************** //* //STEP1 EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSIN DD * HSEND LIST COPYPOOL(DSN$COBDBN6$DB)



/*

Sample HSM List Copy Pool Job Output: The Restore System utility uses the following HSM copy to perform the restore of the DSN$location_name$DB copy pool. As indicated, this backup copy was created using an incremental FlashCopy.

COPYPOOL=DSN$COBDBN6$DB VERSION VTOCENQ DATE TIME FASTREPLICATIONSTATE DUMP 021 N 2008/06/30 10:15:40 RECOVERABLE NONE TOKEN(C)=C'SN61BÆSÄ¾Z#dBÆ\uI ' TOKEN(H)=X'E2D5F6F1C29EE263B9E97B84C29EE0A4C931'

TOTAL NUM OF VOLUMES=00006,INCREMENTAL=Y

Steps for Performing a PITRT: 1. Once you have determined that a point-in-time recovery needs to take place, execute the ARCHIVE

LOG SCOPE(GROUP) command to force an archive of all DB2 members.

2. After all of the DB2 members have finished archiving, bring them down.

3. As a best practice, we recommend to have processes for backing up the DSN$location_name$LG copy pool and be able to restore it back to its current status. This provides you to recover the system to its status prior to any recovery actions. If the log truncation point is not the point in time to which the system needs to return, the DSN$location_name$LG can be restored and a new log truncation point can be established. For more information, see section Backing up the $LG Copy Pool Prior to System Level Recovery.

4. Work with the business owners or end-users to determine the date and time to which the system must be returned. Remember the time used in the conditional restart is GMT time and not local time. It is necessary to convert the local time to which the system must be returned to GMT time.

Example

In this test, it was determined the system needed to go back to the local time of 10:48:00. The test system is 2 hours ahead of GMT, so the GMT time specified will be 08:48:00.

5. Run the DSNJU003 program and establish a point-in-time recovery based on date and time using a date and time format in the conditional restart control card, and the new parameter SYSPITRT. Do this for all members of the data sharing group:

CRESTART CREATE,SYSPITRT=2008179084800

Timestamp format: CRESTART CREATE,SYSPITRT=YYYYJJJHHMMSS

Sample Change Log Inventory Job Using SYSPITRT: //CONDS11C JOB (DE#03557),'NATIVE',NOTIFY=&SYSUID, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M //* //CRCR01B EXEC PGM=DSNJU003,REGION=016M,COND=(4,LT) //STEPLIB DD DISP=SHR,DSN=SYS1.DSN.SN61.SDSNEXIT // DD DISP=SHR,DSN=SYS1.DSN.V910.SDSNLOAD //SYSPRINT DD SYSOUT=* //SYSUT1 DD DISP=SHR,DSN=DBN6.SN61.BSDS01 //SYSUT2 DD DISP=SHR,DSN=DBN6.SN61.BSDS02 //SYSIN DD *



CRESTART CREATE,SYSPITRT=2008179084800 /* //CRCR02B EXEC PGM=DSNJU003,REGION=016M,COND=(4,LT) //STEPLIB DD DISP=SHR,DSN=SYS1.DSN.SN62.SDSNEXIT // DD DISP=SHR,DSN=SYS1.DSN.V910.SDSNLOAD //SYSPRINT DD SYSOUT=* //SYSUT1 DD DISP=SHR,DSN=DBN6.SN62.BSDS01 //SYSUT2 DD DISP=SHR,DSN=DBN6.SN62.BSDS02 //SYSIN DD * CRESTART CREATE,SYSPITRT=2008179084800 /* //CRCR03B EXEC PGM=DSNJU003,REGION=016M,COND=(4,LT) //STEPLIB DD DISP=SHR,DSN=SYS1.DSN.SN63.SDSNEXIT // DD DISP=SHR,DSN=SYS1.DSN.V910.SDSNLOAD //SYSPRINT DD SYSOUT=* //SYSUT1 DD DISP=SHR,DSN=DBN6.SN63.BSDS01 //SYSUT2 DD DISP=SHR,DSN=DBN6.SN63.BSDS02 //SYSIN DD * CRESTART CREATE,SYSPITRT=2008179084800 /*

As displayed in Figure 12, the ENDTIME is the date-time provided and the truncation LRSN is C29B24049700. In Figure 13, the approximate GMT time is found on the checkpoint queue and we can see the END CHECKPOINT LRSN of C29B23EBB0E5 is close to the truncation LRSN being used. This is a good way to validate the truncation point established in the conditional restart.

If you have determined that the DB2 system was not taken back to the point-in-time desired by the customer, and that there is a need to redo the PITR, see section Changing a Log Truncation in the BSDS.



Figure 12: Screen print of the Conditional Restart Control card of member SN61 after the DSNJU003 job had been run for all three members.



Figure 13: Checkpoint queue for SN61 showing the approximate GMT time and LRSN for the checkpoint. This helps to validate the truncation time being used in the conditional restart.

6. Before the DB2 members can be restarted, all of the XCF structures for this DB2 data sharing group must be deallocated. This is done by issuing a SETXCF FORCE command. Typically, if all of the DB2 members were shutdown normally and did not come down hard, the only two structures needing deallocation are the LOCK1 and SCA structures.

SETXCF FORCE,STRUCTURE,STRNAME=DBN6_LOCK1 SETXCF FORCE,STRUCTURE,STRNAME=DBN6_SCA

Issue a D XCF,STR command to ensure that all of the coupling facility structures for this data sharing group have been deallocated.

DBN6_GBP0 -- -- NOT ALLOCATED DBN6_GBP16K0 -- -- NOT ALLOCATED DBN6_GBP2 -- -- NOT ALLOCATED DBN6_GBP3 -- -- NOT ALLOCATED DBN6_GBP32K -- -- NOT ALLOCATED DBN6_GBP40 -- -- NOT ALLOCATED DBN6_GBP8K0 -- -- NOT ALLOCATED DBN6_LOCK1 -- -- NOT ALLOCATED DBN6_SCA -- -- NOT ALLOCATED

7. Restart all DB2 members for this data sharing group. The start of each member causes an outstanding reply to be written to SYSLOG asking if you are sure about the conditional restart and the truncation point. In this test, there were three DB2 members, so there were also outstanding replies from the start of the first two members asking for the start of another member. This outstanding reply is addressed when the remaining members are started.

DSNR050I -SN61 DSNRRPRC DB2 STARTED IN SYSTEM RECOVER PENDING MODE



DSNR002I -SN61 RESTART COMPLETED DSNY014I -SN61 DSNYSTRT DB2 WAS STARTED WITH ACCESS(MAINT) DSN9022I -SN61 DSNYASCP 'START DB2' NORMAL COMPLETION DSNR050I -SN62 DSNRRPRC DB2 STARTED IN SYSTEM RECOVER PENDING MODE DSNR002I -SN62 RESTART COMPLETED DSNY014I -SN62 DSNYSTRT DB2 WAS STARTED WITH ACCESS(MAINT) DSN9022I -SN62 DSNYASCP 'START DB2' NORMAL COMPLETION DSNR050I -SN63 DSNRRPRC DB2 STARTED IN SYSTEM RECOVER PENDING MODE DSNR002I -SN63 RESTART COMPLETED DSNY014I -SN63 DSNYSTRT DB2 WAS STARTED WITH ACCESS(MAINT) DSN9022I -SN63 DSNYASCP 'START DB2' NORMAL COMPLETION

As seen in the messages above, all three members were started in ‘RECOVER PENDING MODE’ and ‘ACCESS(MAINT)’. The only thing that can connect to any of these DB2 members when they are started in this status is the Restore System utility. If it is has been determined that the DB2 system was not taken back to the point-in-time desired by the customer, and there is a need to redo the PITR, see section Changing a Log Truncation in the BSDS.

8. If this is a DB2 data sharing group, bring down all but one member. Only one member needs to be up to run the Restore System utility, and all members need to be stopped and restarted after the PITR is complete. You must start and stop all members to bring them up in normal mode and allow normal usage of all DB2 members.

9. Prior to running the Restore System utility, it is necessary to deallocate the ICF catalog(s) that are in the DSN$location_name$DB copy pool. Remember that during a PITR, the DSN$location_name$LG copy pool is not restored. The BSDS and active logs remain as they were at the time the DB2 members were brought down in order to perform the PITR. The ICF catalogs are deallocated using the MODIFY command. It is necessary to deallocate the ICF catalog(s) in all LPARs in the parallel sysplex.

RO *ALL,F CATALOG,UNALLOCATE(SYS1.USERCAT.DBN6) IEE421I RO *ALL,F CATALOG,UNALLO 995 SYSNAME RESPONSES --------------------------------------------------- COB1 IEC351I CATALOG ADDRESS SPACE MODIFY COMMAND ACTIVE IEC352I CATALOG ADDRESS SPACE MODIFY COMMAND COMPLETED COB2 IEC351I CATALOG ADDRESS SPACE MODIFY COMMAND ACTIVE IEC352I CATALOG ADDRESS SPACE MODIFY COMMAND COMPLETED COB3 IEC351I CATALOG ADDRESS SPACE MODIFY COMMAND ACTIVE IEC352I CATALOG ADDRESS SPACE MODIFY COMMAND COMPLETED

10. If there are any program products with a started task running that have allocated data sets in the DSN$location_name$DB copy pool, shut them down. If you do not shut them down, the restore to the volume with the allocated data set(s) will fail.

11. Submit the Restore System utility job on the LPAR with the running DB2 member. The Restore System utility restores the volumes in the the DSN$location_name$DB copy pool and performs the log apply to bring the data in the DB2 data base up to the truncated log point.

Sample Restore System Utility Job: //RESTS04A JOB (DE03557),CH,NOTIFY=BOEBLD1.DB2ADM1, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M /*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //* //************************************************************** //* STEP BACKUP: RUN BACKUP SYSTEM DATASHARING SN61



//************************************************************** //RESTORE EXEC DSNUPROC,SYSTEM=SN61, // UID='DB2ADM',LIB=SYS1.DSN.V910.SDSNLOAD //DSNUPROC.SYSIN DD * RESTORE SYSTEM /*

12. After the Restore System utility starts to run, you can issue an HSM command to see the status of the background copies and the FlashCopy relationships.

Sample HSEND Job: //HSENDS05 JOB (DE03557),CH,NOTIFY=&SYSUID, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M //*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //* //STEP1 EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * HSEND QUERY COPYPOOL(DSN$COBDBN6$LG) HSEND QUERY COPYPOOL(DSN$COBDBN6$DB) //

Sample HSEND Job Output: As displayed in the following messages, none of the volumes in the DSN$location_name$LG copy pool have an active FlashCopy Background copy running. All of the volumes that are running a FlashCopy background copy are in DSN$location_name$DB copy pool.

ARC1821I NONE OF THE VOLUMES IN COPYPOOL DSN$COBDBN6$LG, VERSION 018, HAVE AN ARC1821I (CONT.) ACTIVE FLASHCOPY BACKGROUND COPY ARC1820I THE FOLLOWING VOLUMES IN COPYPOOL DSN$COBDBN6$DB, VERSION 019, HAVE ARC1820I (CONT.) AN ACTIVE FLASHCOPY BACKGROUND COPY ARC1820I (CONT.) SGNAME FR-PRIMARY FR-BACKUP ARC1820I (CONT.) DB2D1 COBD11 COBF11 ARC1820I (CONT.) DB2D1 COBD12 COBF12 ARC1820I (CONT.) DB2D1 COBD13 COBF13 ARC1820I (CONT.) DB2D1 COBD14 COBF14 ARC1820I (CONT.) DB2D1 COBD15 COBF15 ARC1820I (CONT.) DB2D1 COBD16 COBF16 IKJ56250I JOB HSENDS05(JOB03046) SUBMITTED

Sample Restore System Utility Job Output Messages: DSNU050I 179 12:00:56.03 DSNUGUTC - RESTORE SYSTEM DSNU1606I 179 12:00:56.34 DSNUVBRD - RESTORE SYSTEM UTILITY STARTING, COPYPOOL = DSN$COBDBN6$DB TOKEN = X'E2D5F6F1C29B19C5AA77820EC29B18BE8589'. DSNU1627I 179 12:00:57.71 DSNUVBRD - RESTORE SYSTEM PRE-LOG APPLY COMPLETED SUCCESSFULLY, COPYPOOL = DSN$COBDBN6$DB TOKEN = X'E2D5F6F1C29B19C5AA77820EC29B18BE8589' ELAPSED TIME = 00:00:01. DSNU1604I -SN61 179 12:00:57.97 DSNUVARL - RESTORE SYSTEM PHASE LOG APPLY STARTED AT LOG POINT = X'C29B18BE8589'.



DSNU1635I -SN61 179 12:05:19.88 DSNUVARL - THE RBA RANGE FOR THE LAST CHECKPOINT ISSUED DURING THE LOGAPPLY PHASE OF THE RESTORE SYSTEM UTILITY IS START_RBA = X'C29B3453C2C7' END_RBA = X' C29B354CBB6C' FOR MEMBER SN61 DSNU1628I 179 12:05:19.89 DSNUVBRD - RESTORE SYSTEM PHASE LOG APPLY COMPLETED, ELAPSED TIME = 00:04:22. DSNU010I 179 12:05:19.90 DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=0

Note

If the Restore System utility cannot restore all of the volumes in the DSN$location_name$DB copy pool, then the restore system job ends with an RC = 8 and the log apply phase is not executed. The Restore System job output messages below indicate a failure in the restore being performed by HSM. Due to the restore failure, the log apply phase did not run.

DSNU000I 183 14:09:10.83 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = DB2ADM DSNU1044I 183 14:09:10.88 DSNUGTIS - PROCESSING SYSIN AS EBCDIC DSNU050I 183 14:09:10.89 DSNUGUTC - RESTORE SYSTEM DSNU1606I 183 14:09:11.19 DSNUVBRD - RESTORE SYSTEM UTILITY STARTING, COPYPOOL = DSN$COBDBN6$DB TOKEN = X'E2D5F6F1C29EFFC466A5298EC29EFF39F831'. DSNU1631I 183 14:09:13.10 DSNUVBRD - RESTORE SYSTEM UTILITY FAILED BECAUSE THE CALL TO DFSMSHSM FAILED WITH RC = X'00000008' REASON = X'00000008'. SEE THE HSM ACTIVITY LOG FOR HSM MESSAGES INDICATING THE CAUSE OF THE ERROR. DSNU012I 183 14:09:13.10 DSNUGBAC - UTILITY EXECUTION TERMINATED, HIGHEST RETURN CODE=8

If not all of the volumes are successfully restored, this can be seen in the HSM JESMSGLG. For more information on how to restore individual volumes, see section Restoring Individual Volumes. ARC1803E THE FOLLOWING 00001 VOLUME(S) FAILED DURING ARC1803E (CONT.) FAST REPLICATION RECOVERY OF COPY POOL DSN$COBDBN6$DB ARC1803E (CONT.) COBD14 ARC1805I THE FOLLOWING 00005 VOLUME(S) WERE ARC1805I (CONT.) SUCCESSFULLY PROCESSED BY FAST REPLICATION RECOVERY ARC1805I (CONT.) OF COPY POOL DSN$COBDBN6$DB ARC1805I (CONT.) COBD11 ARC1805I (CONT.) COBD12 ARC1805I (CONT.) COBD13 ARC1805I (CONT.) COBD15 ARC1805I (CONT.) COBD16 ARC1802I FAST REPLICATION RECOVERY HAS COMPLETED FOR ARC1802I (CONT.) COPY POOL DSN$COBDBN6$DB, AT 14:09:13 ON 2008/07/01, ARC1802I (CONT.) FUNCTION RC=0008, MAXIMUM VOLUME RC=0008

13. After the restore of the DSN$location_name$DB and the log apply have completed successfully, issue the following commands to ensure all DB2 objects are in a normal status.

-ssid DISPLAY DATABASE(DSNDB01) SPACENAM(*) RESTRICT -ssid DISPLAY DATABASE(DSNDB06) SPACENAM(*) RESTRICT -ssid DISPLAY DATABASE(*) SPACENAM(*) RESTRICT



14. Once it is clear that all DB2 objects are in a normal status, bring down the running DB2 member and restart all members in the group. It is not necessary for all of the background IO to be complete to make the DB2 system or members available for normal usage.

If it has been determined that the DB2 system was not taken back to the customer’s desired point-in-time, and there is a need to redo the PITR, see section Changing a Log Truncation in the BSDS.

Recommendation

Once it has been determined that the system has been returned to the point-in-time that was needed, and all of the background IO from the restore has completed, run a new Backup System utility to ensure a new recovery point. Use the HSEND QUERY job to verify that all background IO is complete.point.

Verifying DB2 Restore with an SAP System in Use Cases To verify the data consistency of an SAP system after restore action in the use cases, the timestamp for a recovery was chosen at a time while a client copy (local client copy) was running. A client is an organizational unit - and from technical perspective a complete unit - in the SAP system. While a local client copy is running, 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 restore at a certain point in time was successful, the SAP application should recognize the incomplete client copy. In addition, it should be possible to restart the client copy from the moment of the point in time recovery.

The verification of the recovery to a PIT as described above was done with the following sequence: 1. Backup System to DASD of SAP Application N61 was done at 11:23 a.m. 2. The client copy from client 000 into client 105 started at 10:40 am and finished successfully at 10:55

a.m.:

The DB2 Restore was done with a timestamp at 10:48 a.m., while client copy was running. The SAP application was started and while entering the transaction for local client copy (SCCL), the SAP system recognized the uncompleted client copy:



Restart of client copy finished successfully:

The log of client copies lists both client copies. Due to the database restore to a data state of 10:48 a.m., the SAP application shows this client copy as ‘Canceled’. The restarted client copy at 12:17 is then shown as ‘Successfully Completed’. The log also shows that the first ‘canceled’ client copied data from 4640 tables and the second successful completed run copied data from an additional 1484 tables.



Any other kind of backup and restore scenario was validated with the same method:

• Run a client copy in the SAP application • Then restore the database with a timestamp while the client copy was running and restart the SAP

application. The expected result is that the SAP system recognizes the incomplete client copy and that it is able to restart the client copy from ‘breakup’ until successful completion.

Backing up the $LG Copy Pool Prior to System Level Recovery When preparing to perform a PITR, we strongly recommended as a best practice that you back up the DSN$location_name$LG copy pool prior to establishing any log truncation points. When performing a system-level PITR, the DSN$location_name$LG copy pool is not restored, in contrast to the DSN$location_name$DB copy pool. After the log truncation has been established and the DB2 system conditionally restarted, the DSN$location_name$DB copy pool is restored during the execution of the Restore System utility to its status at the time of a prior Backup System utility copy. It is a best practice to ensure the DB2 system can always be taken back to the way it looked before any recovery actions. It is only necessary to backup the DSN$location_name$LG copy pool in order to provide a way back. This provides the ability to correct or change a log truncation point and redo the PITR. This includes another arbitrary point-in-time or to current point-in-time.

The HSM FRBACKUP command is used to provide the backup for the DSN$location_name$LG copy pool.

Steps for Performing a $LG Backup Prior to Point in Time Recovery: 1. If the current backup version on DASD has not been dumped to tape, run a Backup System utility

DUMPONLY. The dump to tape must be complete prior to creating the backup for the DSN$location_name$LG using this procedure. For more information, see section Backup to Tape Using BACKUP SYSTEM DUMPONLY Option.

2. Bring the following down: SAP system, DB2 system, DB2 members.



3. Run the HSM FRBACKUP job.

Sample HSM FRBACKUP JCL:

//FRBACKUP JOB (DE03557),CH,NOTIFY=&SYSUID, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M /*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //* //********************************************************* //* JOB DESCRIPTION //********************************************************* //* //STEP1 EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * HSEND FRBACKUP COPYPOOL(DSN$COBD911$LG) EXECUTE //

Sample HSM Started Task Messages: Once the HSM FRBACKUP command has been issued, the actions being taken by HSM can be viewed in the HSM started task’s JESMSGLG

ARC1801I FAST REPLICATION BACKUP IS STARTING FOR COPY 681 ARC1801I (CONT.) POOL DSN$COBD911$LG, AT 19:39:37 ON 2008/08/20 ARC1805I THE FOLLOWING 00002 VOLUME(S) WERE 690 ARC1805I (CONT.) SUCCESSFULLY PROCESSED BY FAST REPLICATION BACKUP OF ARC1805I (CONT.) COPYPOOL DSN$COBD911$LG ARC1805I (CONT.) COBD2L ARC1805I (CONT.) COBD2M ARC1802I FAST REPLICATION BACKUP HAS COMPLETED FOR 693 ARC1802I (CONT.) COPYPOOL DSN$COBD911$LG, AT 19:39:37 ON 2008/08/20, ARC1802I (CONT.) FUNCTION RC=0000, MAXIMUM VOLUME RC=0000

4. Execute the HSM List Copypool Command

Use the HSM List Copypool to verify the copy that has been made for backing up the DSN$location_name$LG copy pool.


//CPYLST8D JOB (DE03557),CH,NOTIFY=BOEBLD1.DB2ADM1, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M /*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //* //************************************************** //* LIST COPY POOL //************************************************** //* //STEP1 EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSIN DD * HSEND LIST COPYPOOL(DSN$COBD911$LG)



/*

Sample HSM List Copy Pool Job Output: As indicated in the copy pool list below, the copy created by executing the HSM FRBACKUP command is the current copy on DASD in the backup copy pool for DSN$COBD911$LG. There is no token assigned. However, one could have been assigned when running the FRBACKUP command. The Backup System utility copy prior to this copy was dumped to tape before the FRBACKUP was executed. As indicated, it is no longer available on DASD, but could be restored from tape.

-- DFSMShsm CONTROL DATASET --COPYPOOL--LISTING --------- AT 19:43:37 ON 08/08/ COPYPOOL=DSN$COBD911$LG VERSION VTOCENQ DATE TIME FASTREPLICATIONSTATE DUMPSTATE 021 Y 2008/08/20 19:39:37 RECOVERABLE NONE TOKEN(C)=C'' TOKEN(H)=X'' TOTAL NUM OF VOLUMES=00002,INCREMENTAL=N SGNAME SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET DB2D2L COBD2L - COBF2L DB2D2M COBD2M - COBF2M VERSION VTOCENQ DATE TIME FASTREPLICATIONSTATE DUMPSTATE 020 N 2008/08/20 08:37:04 NONE ALLCOMPLETE TOKEN(C)=C'D911B ³R G> ' TOKEN(H)=X'C4F9F1F1C2DEEB74040BFAD9007014C76E39' TOTAL NUM OF VOLUMES=00002,INCREMENTAL=N SGNAME SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET DB2D2L COBD2L - ****** DB2D2M COBD2M - ******

5. Now that the DSN$location_name$LG copy pool is backed up, proceed to the point-in-time recovery procedure. It is safe to establish a log truncation point in the current BSDS’s. If the DB2 system is restarted with the wrong log truncation point, the BSDSs and active logs can be restored to the way they looked at the time the DB2 system was brought down for the PITR.

RESTORE SYSTEM with Backup on DASD: Recover to Current The Restore System utility is used to perform a point-in-time recovery (PITR). After the log truncation point is established in the BSDS, Restore System restores the appropriate copy of the DSN$location_name$DB copypool and applies log records to bring the DB2 system up to the log truncation point.

Typically, a PITR is performed due to data corruption through a rogue application process, or maybe an SAP transport, which can contain code and data changes, applied at the wrong time. This is a logical error. In the event of a DASD failure, which is a physical error, the installation may be looking at hours and hours of single object recoveries to get back the DB2 objects that were made unavailable due to the DASD failure. This becomes more significant as the DASD geometries get larger and larger. It may be more expedient to perform a system level recovery, and recover the whole system instead of thousands of single objects.

The support to use Restore System utility to perform a system level recover to current was provided with APAR PK51979 for DB2 9. The CRESTART statement of the Change Log Inventory program, DSNJU003, is used to establish the SYSPITR option using FFFFFFFFFFFF to indicate no actual log truncation is taking place. This specification is used for both data sharing and non data sharing DB2 systems.



In this PITR, test a three member DB2 data sharing group was used: SN61, SN62 and SN63.

Recommendation

If DB2 data sharing has been enabled and some of the members are passive and used as secondary members in support of database server failover, it is important to run an ARCHIVE LOG SCOPE(GROUP) prior to bringing the DB2 group down for recovery. This is to ensure all of the DB2 members have written out the most current LRSN, and the recover-to-time is not limited by members with low to no activity. This is also true when using date and time as the log truncation point.

HSM List Copypool Command Prior to performing any type of recovery that use the Backup System copies that are maintained by HSM, you can use the HSM command to determine which backups HSM has registered and whether or not they are usable in a recovery.

Sample HSM List Copypool Command Job:

//CPYLST8D JOB (DE03557),CH,NOTIFY=BOEBLD1.DB2ADM1, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M /*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //* //************************************************** //* LIST COPYPOOL //************************************************** //* //STEP1 EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSIN DD * HSEND LIST COPYPOOL(DSN$COBDBN6$DB) /*

Sample HSM List Copypool Job Output: The Restore System utility is using the following HSM copy to perform the restore of the DSN$location_name$DB copy pool. As indicated, this backup copy was created using an incremental FlashCopy.


TOTAL NUM OF VOLUMES=00006,INCREMENTAL=Y

Steps for Performing a System Level Recovery to Current: 1. Once it has been determined that a point-in-time recovery needs to take place, execute the ARCHIVE





3. Run the DSNJU003 program and establish a recover-to-current using the parameter SYSPITR. Do this for all members of the data sharing group.

CRESTART CREATE,SYSPITR=FFFFFFFFFFFF

Sample Change Log Inventory Job Using SYSPITR for Recover-to-Current: //CONDS11C JOB (DE#03557),'NATIVE',NOTIFY=&SYSUID, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M //* //CRCR01B EXEC PGM=DSNJU003,REGION=016M,COND=(4,LT) //STEPLIB DD DISP=SHR,DSN=SYS1.DSN.SN61.SDSNEXIT // DD DISP=SHR,DSN=SYS1.DSN.V910.SDSNLOAD //SYSPRINT DD SYSOUT=* //SYSUT1 DD DISP=SHR,DSN=DBN6.SN61.BSDS01 //SYSUT2 DD DISP=SHR,DSN=DBN6.SN61.BSDS02 //SYSIN DD * CRESTART CREATE,SYSPITR=FFFFFFFFFFFF /* //CRCR02B EXEC PGM=DSNJU003,REGION=016M,COND=(4,LT) //STEPLIB DD DISP=SHR,DSN=SYS1.DSN.SN62.SDSNEXIT // DD DISP=SHR,DSN=SYS1.DSN.V910.SDSNLOAD //SYSPRINT DD SYSOUT=* //SYSUT1 DD DISP=SHR,DSN=DBN6.SN62.BSDS01 //SYSUT2 DD DISP=SHR,DSN=DBN6.SN62.BSDS02 //SYSIN DD * CRESTART CREATE,SYSPITR=FFFFFFFFFFFF /* //CRCR03B EXEC PGM=DSNJU003,REGION=016M,COND=(4,LT) //STEPLIB DD DISP=SHR,DSN=SYS1.DSN.SN63.SDSNEXIT // DD DISP=SHR,DSN=SYS1.DSN.V910.SDSNLOAD //SYSPRINT DD SYSOUT=* //SYSUT1 DD DISP=SHR,DSN=DBN6.SN63.BSDS01 //SYSUT2 DD DISP=SHR,DSN=DBN6.SN63.BSDS02 //SYSIN DD * CRESTART CREATE,SYSPITR=FFFFFFFFFFFF /*

As can be seen in Figure 14 no log truncation was specified and no log truncation will take place. However, the DB2 data sharing group is still in System Level Recovery Mode Restart. This means the only operation that can run in the DB2 system is the Restore System utility.



Figure 14: Screen print of the Conditional Restart Control card of member SN61 after the DSNJU003 job had been run for all three members, indicating no log truncation will occur

4. If this recovery is taking place because of DASD physical errors, ensure the DASD volume(s) with the physical error(s) have been replaced or repaired. The Restore System looks for the same VOLSER(s) as the damaged volumes in order to restore the data.



Issue a D XCF,STR command to validate that all of the coupling facility structures for this data sharing group have been deallocated.


6. Restart all DB2 members for this data sharing group. The start of each member will cause an outstanding reply to be written to SYSLOG asking if you are sure about the conditional restart. When



performing a system level recovery to current, the outstanding reply will indicate a SYSPITR restart with no log truncation.

From System Log: DSNY001I -SN61 SUBSYSTEM STARTING DSNJ127I -SN61 SYSTEM TIMESTAMP FOR BSDS= 08.182 11:05:06.68 DSNJ256I -SN61 DSNJW006 CONDITIONAL RESTART RECORD 505 INDICATES SYSPITR RESTART WITH NO LOG TRUNCATION *61 DSNJ011I -SN61 CONDITIONAL RESTART RECORD 0007 CREATED AT 08.182 11:06 WAS FOUND. REPLY Y TO USE, N TO CANCEL

In this test there were three DB2 members, so there were also outstanding replies from the start of the first two members asking for the start of another member. This outstanding reply will be addressed when the remaining members are started

DSNR050I -SN61 DSNRRPRC DB2 STARTED IN SYSTEM RECOVER PENDING MODE DSNR002I -SN61 RESTART COMPLETED DSNY014I -SN61 DSNYSTRT DB2 WAS STARTED WITH ACCESS(MAINT) DSN9022I -SN61 DSNYASCP 'START DB2' NORMAL COMPLETION DSNR050I -SN62 DSNRRPRC DB2 STARTED IN SYSTEM RECOVER PENDING MODE DSNR002I -SN62 RESTART COMPLETED DSNY014I -SN62 DSNYSTRT DB2 WAS STARTED WITH ACCESS(MAINT) DSN9022I -SN62 DSNYASCP 'START DB2' NORMAL COMPLETION DSNR050I -SN63 DSNRRPRC DB2 STARTED IN SYSTEM RECOVER PENDING MODE DSNR002I -SN63 RESTART COMPLETED DSNY014I -SN63 DSNYSTRT DB2 WAS STARTED WITH ACCESS(MAINT) DSN9022I -SN63 DSNYASCP 'START DB2' NORMAL COMPLETION

As seen in the messages above, all three members were started in ‘RECOVER PENDING MODE’ and ‘ACCESS(MAINT)’. The only thing that can connect to any of these DB2 members when they are started in this status is the Restore System utility.

7. If this is a DB2 data sharing group, bring down all but one member. Only one member needs to be up to run the Restore System utility, and all members will need to be stopped and restarted any way after the PITR is complete. The stopping and starting of all members is necessary to bring them up in normal mode and allow normal usage of all DB2 members.

8. Prior to running the Restore System utility, it is necessary to deallocate the ICF catalog(s) that are in the DSN$location_name$DB copy pool. Remember, during a PITR the DSN$location_name$LG copy pool is not being restored. The BSDS and active logs will remain as they were at the time the DB2 members were brought down in order to perform the PITR. The ICF catalogs are deallocated using the MODIFY command. It is necessary to deallocate the ICF catalog(s) in all LPARs in the parallel sysplex.


9. If there are any program products with a started task running that have allocated data sets in the DSN$location_name$DB copy pool, shut them down or the restore to the volume with the allocated data set(s) will fail.



10. Submit the Restore System utility job on the LPAR with the running DB2 member. The Restore System utility will restore the volumes in the DSN$location_name$DB copy pool and perform the log apply to bring the data in the DB2 data base up to current.

Sample Restore System Utility Job:

//RESTS05A JOB (DE03557),CH,NOTIFY=BOEBLD1.DB2ADM1, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M /*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //* //************************************************************** //* STEP BACKUP: RUN BACKUP SYSTEM DATASHARING SN61 //************************************************************** //RESTORE EXEC DSNUPROC,SYSTEM=SN61, // UID='DB2ADM',LIB=SYS1.DSN.V910.SDSNLOAD //DSNUPROC.SYSIN DD * RESTORE SYSTEM /*

11. After the Restore System utility starts to run, a HSM command can be issued to see what the status is of the background copies and the FlashCopy relationships.

Sample HSEND Job:

//HSENDS05 JOB (DE03557),CH,NOTIFY=&SYSUID, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M //*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //* //STEP1 EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * HSEND QUERY COPYPOOL(DSN$COBDBN6$LG) HSEND QUERY COPYPOOL(DSN$COBDBN6$DB) //

Sample HSEND Job Output: As can be seen in the following messages, none of the volumes in the DSN$location_name$LG copy pool have an active FlashCopy Background copy running. All of the volumes with a FlashCopy background copy running are in DSN$location_name$DB copy pool.

ARC1821I NONE OF THE VOLUMES IN COPY POOL DSN$COBDBN6$LG, VERSION 018, HAVE AN ARC1821I (CONT.) ACTIVE FLASHCOPY BACKGROUND COPY ARC1820I THE FOLLOWING VOLUMES IN COPY POOL DSN$COBDBN6$DB, VERSION 021, HAVE ARC1820I (CONT.) AN ACTIVE FLASHCOPY BACKGROUND COPY ARC1820I (CONT.) SGNAME FR-PRIMARY FR-BACKUP ARC1820I (CONT.) DB2D1 COBD11 COBF11 ARC1820I (CONT.) DB2D1 COBD12 COBF12 ARC1820I (CONT.) DB2D1 COBD13 COBF13 ARC1820I (CONT.) DB2D1 COBD14 COBF14 ARC1820I (CONT.) DB2D1 COBD15 COBF15 ARC1820I (CONT.) DB2D1 COBD16 COBF16



Sample Restore System Utility Job Output Messages:

DSNU050I 182 11:32:23.28 DSNUGUTC - RESTORE SYSTEM DSNU1606I 182 11:32:23.48 DSNUVBRD - RESTORE SYSTEM UTILITY STARTING, COPYPOOL = DSN$COBDBN6$DB TOKEN = X'E2D5F6F1C29EE263B9E97B84C29EE0A4C931'. DSNU1627I 182 11:32:25.85 DSNUVBRD - RESTORE SYSTEM PRE-LOG APPLY COMPLETED SUCCESSFULLY, COPYPOOL = DSN$COBDBN6$DB TOKEN = X'E2D5F6F1C29EE263B9E97B84C29EE0A4C931' ELAPSED TIME = 00:00:02. DSNU1604I -SN61 182 11:32:26.00 DSNUVARL - RESTORE SYSTEM PHASE LOG APPLY STARTED AT LOG POINT = X'C29EE0A4C931'. DSNU1635I -SN61 182 11:35:11.80 DSNUVARL - THE RBA RANGE FOR THE LAST CHECKPOINT ISSUED DURING THE LOGAPPLY PHASE OF THE RESTORE SYSTEM UTILITY IS START_RBA = X'C29EF38B7B55' END_RBA = X'C29EF42943B9' FOR MEMBER SN61 DSNU1628I 182 11:35:11.82 DSNUVBRD - RESTORE SYSTEM PHASE LOG APPLY COMPLETED, ELAPSED TIME = 00:02:45. DSNU010I 182 11:35:11.86 DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=0

Sample Restore System Utility Job Output Messages of Failed Restore:

DSNU000I 183 14:09:10.83 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = DB2ADM DSNU1044I 183 14:09:10.88 DSNUGTIS - PROCESSING SYSIN AS EBCDIC DSNU050I 183 14:09:10.89 DSNUGUTC - RESTORE SYSTEM DSNU1606I 183 14:09:11.19 DSNUVBRD - RESTORE SYSTEM UTILITY STARTING, COPYPOOL = DSN$COBDBN6$DB TOKEN = X'E2D5F6F1C29EFFC466A5298EC29EFF39F831'. DSNU1631I 183 14:09:13.10 DSNUVBRD - RESTORE SYSTEM UTILITY FAILED BECAUSE THE CALL TO DFSMSHSM FAILED WITH RC = X'00000008' REASON = X'00000008'. SEE THE HSM ACTIVITY LOG FOR HSM MESSAGES INDICATING THE CAUSE OF THE ERROR. DSNU012I 183 14:09:13.10 DSNUGBAC - UTILITY EXECUTION TERMINATED, HIGHEST RETURN CODE=8

If not all of the volumes are successfully restored, you can see this in the HSM JESMSGLG. For more information about restoring individual volumes, see section Restoring Individual Volumes.

Sample HSM JESMSGLG Messages: ARC1803E THE FOLLOWING 00001 VOLUME(S) FAILED DURING ARC1803E (CONT.) FAST REPLICATION RECOVERY OF COPY POOL DSN$COBDBN6$DB ARC1803E (CONT.) COBD14 ARC1805I THE FOLLOWING 00005 VOLUME(S) WERE ARC1805I (CONT.) SUCCESSFULLY PROCESSED BY FAST REPLICATION RECOVERY ARC1805I (CONT.) OF COPY POOL DSN$COBDBN6$DB ARC1805I (CONT.) COBD11 ARC1805I (CONT.) COBD12

If the Restore System utility can not restore all of the volumes in the DSN$location_name$DB copy pool, then the restore system job will end with a RC = 8 and the log apply phase is not executed. The Restore System job output messages below indicate a failure in the restore being performed by HSM. Due to the restore failure the log apply phase did not run.



ARC1805I (CONT.) COBD13 ARC1805I (CONT.) COBD15 ARC1805I (CONT.) COBD16 ARC1802I FAST REPLICATION RECOVERY HAS COMPLETED FOR ARC1802I (CONT.) COPY POOL DSN$COBDBN6$DB, AT 14:09:13 ON 2008/07/01, ARC1802I (CONT.) FUNCTION RC=0008, MAXIMUM VOLUME RC=0008

12. After the Restore System utility has completed successfully, issue the following commands to ensure all DB2 objects are in a normal status.


13. Once it is clear that all DB2 objects are in a normal status, bring down the running DB2 member and

restart all members in the group. It is not necessary for all of the background IO to have completed to make the DB2 system or members available for normal usage.

Recommendation

Once it has been determined that the system has been returned to the point-in-time that was needed, and all of the background IO from the restore has completed, run a new Backup System utility to ensure a new recovery point. Use the HSEND QUERY job to verify that all background IO has completed.

Changing a Log Truncation in the BSDS We recommend that you have a procedure for changing the log truncation value, in the event that the log truncation point that was created via the Change Log Inventory utility (DSNJU003) is not the right point-in-time. This section describes three procedures for changing the log truncation point.

The correct procedure for changing the log truncation point is determined by which step in the point-in-time recovery procedure it was determined that the log truncation point was not the correct one:

1. CRESTART CANCEL Change Log Inventory utility, DSNJU003, has already been run to establish a log truncation point, but the DB2 system has not been restarted yet.

2. RERUN DSNJU003 CRESTART Change Log Inventory utility, DSNJU003, has already been run to establish a log truncation point, the DB2 system has been restarted, but the Restore System utility has not been run yet.

3. RESTORE DSN$location_name$LG COPY POOL

a. Change Log Inventory utility, DSNJU003, has already been run to establish a log truncation point, the DB2 system has been restarted, and the Restore System utility has already run.

b. Change Log Inventory utility, DSNJU003, has already been run to establish a log truncation point, the DB2 system has been restarted, the Restore System utility has run, and SAP has already been started.

Steps for Using DSNJU003 CRESTART CANCEL

This procedure assumes that the following requirements are fulfilled:

o APAR PK51979 has been applied.

o Change Log Inventory utility, DSNJU003, has been run to establish a log truncation point

o The DB2 system has not been restarted.



1. Submit a Change Log Inventory job using the CANCEL option of the CRESTART statement:

Sample CRESTAR CANCEL JCL: //CONDN20B JOB (DE#03557),'NATIVE',NOTIFY=&SYSUID, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M TYPRUN=SCAN //* //CRCR01B EXEC PGM=DSNJU003,REGION=016M,COND=(4,LT) //* //STEPLIB DD DISP=SHR,DSN=SYS1.DSN.D911.SDSNEXIT // DD DISP=SHR,DSN=SYS1.DSN.V910.SDSNLOAD //SYSPRINT DD SYSOUT=* //SYSUT1 DD DISP=SHR,DSN=DSN911.D911.BSDS01 //SYSUT2 DD DISP=SHR,DSN=DSN911.D911.BSDS02 //SYSIN DD * CRESTART CANCEL /*

Sample Change Log Inventory Job Output Messages: CRESTART CANCEL DSNJ411I DSNRJRCR CRESTART CANCEL FOR CRCRID = 0001, DDNAME = SYSUT1 DSNJ411I DSNRJRCR CRESTART CANCEL FOR CRCRID = 0001, DDNAME = SYSUT2 DSNJ225I CRESTART OPERATION COMPLETED SUCCESSFULLY DSNJ200I DSNJU003 CHANGE LOG INVENTORY UTILITY PROCESSING COMPLETED SUCCESSFUL

2. Run the BSDS print map utility, DSNJU004, to validate the cancel:

Sample BSDS Print Map Job Output Messages: CONDITIONAL RESTART CONTROL RECORD 18:26:28 AUGUST 20, 2008 **** ACTIVE CRCR RECORD **** NO CRCR RECORDS ARE ACTIVE **** CRCR IDENTIFIER 0001 USE COUNT 0 RECORD STATUS CRCR NOT ACTIVE CRCR NOT USED PROCESSING STATUS FORWARD = YES BACKOUT = YES SYSPITR SYSTEM LEVEL RECOVERY MODE RESTART STARTRBA NOT SPECIFIED ENDRBA NOT SPECIFIED ENDLRSN NOT SPECIFIED ENDTIME 20082331152410 TRUNCATION STCK (FROM ENDTIME) C2DF32032544 EARLIEST REQUESTED RBA 000000000000 FIRST LOG RECORD RBA 000000000000 ORIGINAL CHECKPOINT RBA 000000000000 NEW CHECKPOINT RBA (CHKPTRBA) SCAN REQUIRED



CRCR CREATED 18:17:25 AUGUST 20, 2008 RESTART PROGRESS STARTED ENDED ======= ===== CURRENT STATUS REBUILD NO NO FORWARD RECOVERY PHASE NO NO BACKOUT RECOVERY PHASE NO NO

3. Establish new log truncation point and return to PITR procedure.



Steps for Re-Running DSNJU003 CRESTART: This procedure assumes that the following requirements are fulfilled:


o The DB2 system has successfully restarted using the log truncation point.

o The Restore System utility has not been run yet.

1. Bring the DB2 system down.

2. Run the BSDS Print Map utility, DSNJU004, in order to record the current BSDS.

3. Run the Change Log Inventory utility, DSNJU003, with the new log truncation point.

4. Run another BSDS Print Map utility, DSNJU004, in order to validate the new log truncation point:

Sample BSDS Print Map Job Output Messages: As indicated in the conditional restart control record, this new control record is the second control record created for this DB2 system, it is active, and it has not been used.

CONDITIONAL RESTART CONTROL RECORD 20:43:15 AUGUST 20, 2008 **** ACTIVE CRCR RECORD **** CRCR IDENTIFIER 0002 USE COUNT 0 RECORD STATUS CRCR ACTIVE CRCR NOT USED PROCESSING STATUS FORWARD = YES BACKOUT = YES SYSPITR SYSTEM LEVEL RECOVERY MODE RESTART STARTRBA NOT SPECIFIED ENDRBA NOT SPECIFIED ENDLRSN NOT SPECIFIED ENDTIME 20082331306510 TRUNCATION STCK (FROM ENDTIME) C2DF4296FF0C EARLIEST REQUESTED RBA 000000000000 FIRST LOG RECORD RBA 000000000000 ORIGINAL CHECKPOINT RBA 000000000000 NEW CHECKPOINT RBA (CHKPTRBA) SCAN REQUIRED CRCR CREATED 20:39:10 AUGUST 20, 2008 RESTART PROGRESS STARTED ENDED ======= ===== CURRENT STATUS REBUILD NO NO FORWARD RECOVERY PHASE NO NO BACKOUT RECOVERY PHASE NO NO

5. Restart the DB2 system and return to the PITR procedure.



Restoring the $LG Copy Pool Using the FRBACKUP Copy If you determine that the log truncation point used to return the DB2 system back to a prior point-in-time does not meet the customer’s needs the DSN$location_name$LG copy pool can be restored and a new log truncation point can be established. This assumes that you have followed the best practice of backing up the DSN$location_name$LG copy pool prior to a PITR.

HSM List Copy Pool Command Prior to performing any type of recovery that uses the copies that are maintained by HSM, a HSM command can be used in order to see what backups HSM has registered and whether or not they are usable in a recovery.

Sample HSM List Copy Pool Command Job: //CPYLST8D JOB (DE03557),CH,NOTIFY=BOEBLD1.DB2ADM1, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M /*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //* //************************************************** //* LIST COPYPOOL //************************************************** //* //STEP1 EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSIN DD * HSEND LIST COPYPOOL(DSN$COBD911$LG)

/*

Sample HSM List Copy Pool Job Output: As displayed in the copy pool list below, the copy created by executing the HSM FRBACKUP command is the current copy on DASD in the backup copy pool for DSN$COBD911$LG. The HSM FRRECOV command uses this copy for restoring the DSN$COBD911$LG copy pool.

-- DFSMShsm CONTROL DATASET --COPY POOL--LISTING --------- AT 19:43:37 ON 08/08/ COPYPOOL=DSN$COBD911$LG VERSION VTOCENQ DATE TIME FASTREPLICATIONSTATE DUMPSTATE 021 Y 2008/08/20 19:39:37 RECOVERABLE NONE TOKEN(C)=C'' TOKEN(H)=X'' TOTAL NUM OF VOLUMES=00002,INCREMENTAL=N SGNAME SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET DB2D2L COBD2L - COBF2L DB2D2M COBD2M - COBF2M VERSION VTOCENQ DATE TIME FASTREPLICATIONSTATE DUMPSTATE 020 N 2008/08/20 08:37:04 NONE ALLCOMPLETE TOKEN(C)=C'D911B ³R G> ' TOKEN(H)=X'C4F9F1F1C2DEEB74040BFAD9007014C76E39' TOTAL NUM OF VOLUMES=00002,INCREMENTAL=N SGNAME SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET



DB2D2L COBD2L - ****** DB2D2M COBD2M - ******



Steps for Restoring the DSN$location_name$LG Copy Pool This procedure assumes that the following requirements have been fulfilled:


o The DB2 system has successfully restarted using the log truncation point.

o The Restore System utility has been run, and the SAP system may have been restarted.

1. Bring SAP and DB2 system or members down.

2. Deallocate ICF catalog in DSN$location_name$LG copy pool:

RO *ALL,F CATALOG,UNALLOCATE(SYS1.USERCAT.DSN911L)

IEE421I RO *ALL,F CATALOG,UNALLO 612 SYSNAME RESPONSES --------------------------------------------------- COB1 IEC351I CATALOG ADDRESS SPACE MODIFY COMMAND ACTIVE IEC352I CATALOG ADDRESS SPACE MODIFY COMMAND COMPLETED COB2 IEC351I CATALOG ADDRESS SPACE MODIFY COMMAND ACTIVE IEC352I CATALOG ADDRESS SPACE MODIFY COMMAND COMPLETED COB3 IEC351I CATALOG ADDRESS SPACE MODIFY COMMAND ACTIVE IEC352I CATALOG ADDRESS SPACE MODIFY COMMAND COMPLETED COB4 IEC351I CATALOG ADDRESS SPACE MODIFY COMMAND ACTIVE IEC353I CATALOG ADDRESS SPACE MODIFY UNSUCCESSFUL IEC353I CATALOG SPECIFIED NOT

3. Identify any program products that may have any of the volumes in the DSN$location_name$LG copy pool allocated and stop them in order to make the volumes available for restore. In our test system, it was necessary to bring down the Recovery Expert started tasks in order to successfully restore the volumes in our DSN$COBD911$LG copy pool.

4. Run HSM FRRECOV for the DSN$location_name$LG.

Sample HSM FRRECOV Command Job: //HSMRECN6 JOB (DE03557),CH,NOTIFY=&SYSUID, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M //*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //* //STEP1 EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * HSEND FRRECOV COPYPOOL(DSN$COBD911$LG) VERIFY(Y) /*

Note

VERIFY(Y|N) is an optional parameter that is used to ensure that no source volumes in the copy pool are in an existing FlashCopy relationship. If one or more volumes are in an existing FlashCopy relationship, the recover fails. VERIFY(Y) is the default.



Sample HSM Started Task Messages: Once the HSM FRRECOV commands have been issued, the actions being taken by HSM can be viewed in the HSM stared task’s JESMSGLG.

ARC1801I FAST REPLICATION RECOVERY IS STARTING FOR 952 ARC1801I (CONT.) COPYPOOL DSN$COBD911$LG, AT 22:19:05 ON 2008/08/20 ARC1805I THE FOLLOWING 00002 VOLUME(S) WERE 961 ARC1805I (CONT.) SUCCESSFULLY PROCESSED BY FAST REPLICATION RECOVERY ARC1805I (CONT.) OF COPY POOL DSN$COBD911$LG ARC1805I (CONT.) COBD2L ARC1805I (CONT.) COBD2M ARC1802I FAST REPLICATION RECOVERY HAS COMPLETED FOR 964 ARC1802I (CONT.) COPYPOOL DSN$COBD911$LG, AT 22:19:06 ON 2008/08/20, ARC1802I (CONT.) FUNCTION RC=0000, MAXIMUM VOLUME RC=0000

5. Once all of the volumes in the DSN$location_name$LG copy pool have been successfully processed by fast replication recovery, run a BSDS print map, DSNJU004, and validate there are no active conditional restart cards. It is not necessary to wait for the background copy IO to complete.

If there is an active conditional restart card and it is not the log truncation that is needed, use CRESTART CANCEL to mark it as not active.

6. Establish the new log truncation point using DSNJU003 and return to PITR procedure.

Recovering Individual Tablespace Using RECOVER Utility with System-Level Backup on DASD The online RECOVER utility recovers data to the current state or to a previous point in time by restoring a copy and then applying log records. You can recover data from image copies of an object or from a system-level backup that contain changes to the object. This feature was introduced in Version 9, 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.

To make these features available, please check the DSNZAPRM panel DSNTIP6 for

RESTORE_RECOVER_FROMDUMP = YES always from dump

SYSTEM_LEVEL_BACKUP = YES use system-level backup as recovery base for RECOVER

You can override this setting by executing the RECOVER utility statement with the FROMDUMP keyword. Furthermore, the new DB2 9 options TOLOGPOINT and RESTOREBEFORE have to be taken into account and checked, which option is appropriate for which recovery purpose.

No options are necessary for a single object recovery to current.

//DSNUPROC.SYSIN DD * RECOVER TABLESPACE A201X994.XSAP /* //

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 table space, 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.



The following specific information from the IBM DB2 Utility Guide describes the options:

FROMDUMP Specifies that only dumps of the database copy pool are used for the restore of the data sets. DUMPCLASS (dcl) Indicates the DFSMShsm dump class to use to restore the data sets.The FROMDUMP and DUMPCLASS options that you specify for the RECOVER utility override the RESTORE/RECOVER FROM DUMP and DUMPCLASS NAME install options that you specify on installation panel DSNTIP6.

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 table space, 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.

RESTOREBEFORE X'byte-string' Specifies that RECOVER is to search for an image copy, concurrent copy, or system-level backup (if yes has been specified for SYSTEM-LEVEL BACKUPS on install panel DSNTIP6) with an RBA or LRSN value earlier than the specified X'byte-string' value to use in the RESTORE phase. To avoid specific image copies, concurrent copies, or system-level backups with matching or more recent RBA or LRSN values in START_RBA, the RECOVER utility applies the log records and restores the object to its current state or the specified TORBA or TOLOGPOINT value. The RESTOREBEFORE value is compared with the RBA or LRSN value in the START_RBA column in the SYSIBM.SYSCOPY record for those copies. For system-level backups, the RESTOREBEFORE value is compared with the data complete LRSN. If you specify a TORBA or TOLOGPOINT value with the RESTOREBEFORE option, the RBA or LRSN value for RESTOREBEFORE must be lower than the specified TORBA OR TOLOGPOINT value. If you specify RESTOREBEFORE, you cannot specify TOCOPY, TOLASTCOPY, or TOLASTFULLCOPY.

A single SAP table has to be recovered to a previous state without affecting the parallel workload. It is assumed that a major logical error occurred when entering customer data, so the business decision is:

recover single object to achieve again a logically consistent state.

The appropriate SAP object is tablespace A201X994.XSAP.

Use case • Backup system full • Add new clients to an SAP system • For test purposes, run the Client Copy and system-level backup in parallel. • Perform single object recovery to log point of previous backup system. After single object recovery from

HSM copy pool backup storage group, the recently entered client numbers should not exist in T000 The following diagram visualizes the use case.



Backup System HSMDB2 backup

Added clients resettet

SAPDefine new

clients

Restore single object

Original DB2

Original DB2

Original DB2

t0

t1

t3

SAP Client Copy

t2

Figure 15: Single-object recovery sample use Case

Three clients 401, 402 and 403 have been added before the SAP Client Copy was started:

Figure 16: Overview of all Clients Including the Newly Added Clients



Client Copy run

Figure 17: Client Copy/Transport Log Analysis Screen The selected TOLOGPOINT X'C2A7DB00B6FF' was an END CHECKPOINT LRSN and is identified in the DB2 BSDS data set.

Recover Single Object Joblog: DSNU050I 189 15:15:33.77 DSNUGUTC - RECOVER TABLESPACE A201X994.XSAP TOLOGPOINT X'C2A7DB00B6FF' DSNU185I -SN61 189 15:15:33.88 DSNUGSRI - THE VSAM DATA SET DOES NOT EXIST FOR INDEXSPACE A201X994.SWNRCOLS DSNU185I -SN61 189 15:15:33.88 DSNUGSRI - THE VSAM DATA SET DOES NOT EXIST FOR INDEXSPACE A201X994.SWNRDELS .... .... DSNU185I -SN61 189 15:15:33.88 DSNUGSRI - THE VSAM DATA SET DOES NOT EXIST FOR INDEXSPACE A201X994.T77ALESO DSNU1520I 189 15:15:34.79 DSNUCBMT - THE RECOVERY BASE FOR TABLESPACE A201X994.XSAP IS THE SYSTEM LEVEL BACKUP WITH DATE = 20080707, TIME 123542, AND TOKEN X'E2D5F6F1C2A7CEBCB44B218BC2A7CE35746A' DSNU1527I 189 15:15:38.31 DSNUCBMT - TABLESPACE A201X994.XSAP WAS SUCCESSFULLY RESTORED FROM A FLASHCOPY, ELAPSED TIME=00:00:03 DSNU831I -SN61 189 15:15:34.96 DSNUCARS - ALL INDEXES OF A201X994.XSAP ARE IN REBUILD PENDING DSNU578I -SN61 189 15:15:38.40 DSNUCALA - SYSLGRNX INFORMATION FOR MEMBER SN63 DSNU513I -SN61 189 15:15:38.40 DSNUCALA - RECOVER UTILITY LOG APPLY RANGE IS RBA 00180ABBDA75 LRSN C2A7CE35746A TO RBA 0018132FBB12 LRSN C2A7D44EF612 DSNU1510I 189 15:15:39.62 DSNUCBLA - LOG APPLY PHASE COMPLETE, ELAPSED TIME = 00:00:01 DSNU500I 189 15:15:40.00 DSNUCBDR - RECOVERY COMPLETE, ELAPSED TIME=00:00:06 DSNU010I 189 15:15:40.04 DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=4



DSNU185I csect-name THE VSAM DATA SET DOES NOT EXIST FOR obj-type obj-qual.obj-name part part-number Explanation: The VSAM data set(s) for the specified object has not been defined yet because the object was created with DEFINE NO. Severity: 0 (informational) System action: The utility skips the object that was created with DEFINE NO, and processing continues.

After the single object recovery, the client copy from 000 into 108 is displayed, but not the new entered clients in table T000:

Figure 18: Display View “Clients”: Overview In a subsequent step, the indexes associated with the tablespace only need to be rebuilt if they were not specified as part of the RECOVER TABLESPACE statement. Therefore, if you have set the COPY YES attribute for indexes, we recommend that you recover both tablespace and indexes at the same time to prevent index rebuild:

DSNU000I 189 15:54:23.59 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = DB2ADM1.RBLD1DSNU1044I 189 15:54:23.63 DSNUGTIS - PROCESSING SYSIN AS EBCDICDSNU050I 189 15:54:23.75 DSNUGUTC - REBUILD INDEX(ALL) TABLESPACE A201X994.XSAPDSNU185I -SN61 189 15:54:23.75 DSNUCINT - THE VSAM DATA SET DOES NOT EXIST FOR INDEXSPACE A201X994.SWNRCOLS

...

...

DSNU395I 189 15:54:24.88 DSNUCRIB - INDEXES WILL BE BUILT IN PARALLEL, NUMBER OF TASKS = 37

DSNU397I 189 15:54:24.88 DSNUCRIB - NUMBER OF TASKS CONSTRAINED BY VIRTUAL STORAGE BELOW

DSNU555I -SN61 189 15:54:45.33 DSNUCRUL - UNLOAD PHASE STATISTICS - NUMBER OF RECORDS PROCESSED=30770DSNU705I 189 15:54:45.45 DSNUCRIB - UNLOAD PHASE COMPLETE - ELAPSED TIME=00:00:20

DSNU394I -SN61 189 15:54:45.61 DSNURBXC - SORTBLD PHASE STATISTICS - NUMBER OF KEYS=68 FOR INDEX

SAPR3.SWN_SETTINGSSTß0

DSNU394I -SN61 189 15:54:46.43 DSNURBXC - SORTBLD PHASE STATISTICS - NUMBER OF KEYS=88 FOR INDEX SAPR3.SXMSCONFDFß0

DSNU394I -SN61 189 15:54:47.36 DSNURBXC - SORTBLD PHASE STATISTICS - NUMBER OF KEYS=72 FOR INDEX



SAPR3.T247ß0

...

...

DSNU391I 189 15:54:48.35 DSNUCRIB - SORTBLD PHASE STATISTICS. NUMBER OF INDEXES = 60

DSNU392I 189 15:54:48.35 DSNUCRIB - SORTBLD PHASE COMPLETE, ELAPSED TIME = 00:00:02

DSNU010I 189 15:54:48.69 DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=0

The final quality check is a display of the database status:

--SN61 DIS DB(*) SP(*) RESTRICT DSNT365I -SN61 NO DATABASES FOUND

Recovery to Point in Time of Backup Using DFSMShsm FRRECOV Some times there is a need to ‘baseline’ the data in the DB2 data base. In other words, restore the system back to the way it looked at the time the Backup System utility copy was obtained. This means that both the DSN$location_name$DB and the DSN$location_name$LG copy pools will be restored. In this case the Restore System utility is not used, but instead HSM commands are used to restore the appropriate copy of the DSN$location_name$DB and the DSN$location_name$LG copy pools. There is no log apply phase. Once the restore of these two copy pools is complete, the DB2 system is started through normal start procedures and will go through normal DB2 restart processing.

As can be seen in Figure 19 when performing a ‘baseline’ recovery the steps are quiet different from performing a system level PITR.

Establish log truncationswith DSNJU003

If Data Sharing, deallocate groups

coupling facilitystructures

Start DB2 system. if Data Sharing, start

All members.

Deallocate ICFcatalogs in

$DB copypool

Run Restore System Utility to restore $DB copypool

and perform Logapply

Deallocate ICFcatalogs in

$DB and $LGcopypools

Execute HSM FRRECOV command

For $DB and $LG

If Data Sharing, deallocate groups

coupling Facilitystructures

Start DB2 system, if Data Sharing, start

All members inACCESS(MAINT).

Identify and resolveany objects in

restricted status.

Start DB2, if Data Sharing,

start all members in normal mode

System Level PITR System Baseline Recovery



Figure 19: Difference between the steps and the order of the steps of performing a PITR as compared to a baseline recovery.

HSM List Copypool Command Prior to performing any type of recovery that uses the Backup System copies maintained by HSM, an HSM command can be used to display which backups HSM has registered and whether or not they are usable as a recovery.

Sample HSM List Copypool Command Job: //CPYLST8D JOB (DE03557),CH,NOTIFY=BOEBLD1.DB2ADM1, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M /*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //* //************************************************** //* LIST COPYPOOL //************************************************** //* //STEP1 EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSIN DD * HSEND LIST COPYPOOL(DSN$COBDBN6$DB) HSEND LIST COPYPOOL(DSN$COBDBN6$LG)

/*

Sample HSM List Copypool Job Output: The HSM FRRECOV commands will be using the following HSM copy to perform the restore of the DSN$location_name$DB and the DSN$location_name$LG copy pools.


TOTAL NUM OF VOLUMES=00006,INCREMENTAL=N

COPYPOOL=DSN$COBDBN6$LG VERSION VTOCENQ DATE TIME FASTREPLICATIONSTATE DUMP 019 N 2008/06/30 10:15:40 RECOVERABLE NONE TOKEN(C)=C'SN61BÆSÄ¾Z#dBÆ\uI ' TOKEN(H)=X'E2D5F6F1C29EE263B9E97B84C29EE0A4C931'

TOTAL NUM OF VOLUMES=00002,INCREMENTAL=N

Steps for Performing a System Level Recovery to Point in Time of Backup: 1. Bring SAP and DB2 system or members down. 2. Prior to running the HSM FRRECOV job, it is necessary to deallocate the ICF catalog(s) in the

DSN$location_name$DB and the DSN$location_name$LG copy pools. In this recovery the BSDSs and active logs, as well as, all of the data objects will be restored back to the way they looked at the time the Backup System copy was obtained. The ICF catalogs are deallocated using the Modify command. It is necessary to deallocate the ICF catalog(s) in all LPARs in the parallel sysplex.

RO *ALL,F CATALOG,UNALLOCATE(SYS1.USERCAT.DBN6)



IEE421I RO *ALL,F CATALOG,UNALLO SYSNAME RESPONSES --------------------------------------------------- COB1 IEC351I CATALOG ADDRESS SPACE MODIFY COMMAND ACTIVE IEC352I CATALOG ADDRESS SPACE MODIFY COMMAND COMPLETED COB2 IEC351I CATALOG ADDRESS SPACE MODIFY COMMAND ACTIVE IEC352I CATALOG ADDRESS SPACE MODIFY COMMAND COMPLETED COB3 IEC351I CATALOG ADDRESS SPACE MODIFY COMMAND ACTIVE IEC352I CATALOG ADDRESS SPACE MODIFY COMMAND COMPLETED RO *ALL,F CATALOG,UNALLOCATE(SYS1.USERCAT.DBN6L) IEE421I RO *ALL,F CATALOG,UNALLO SYSNAME RESPONSES --------------------------------------------------- COB1 IEC351I CATALOG ADDRESS SPACE MODIFY COMMAND ACTIVE IEC352I CATALOG ADDRESS SPACE MODIFY COMMAND COMPLETED COB2 IEC351I CATALOG ADDRESS SPACE MODIFY COMMAND ACTIVE IEC352I CATALOG ADDRESS SPACE MODIFY COMMAND COMPLETED COB3 IEC351I CATALOG ADDRESS SPACE MODIFY COMMAND ACTIVE IEC352I CATALOG ADDRESS SPACE MODIFY COMMAND COMPLETED

3. If there are any program products with a started task running that have allocated data sets in the DSN$location_name$DB or the DSN$location_name$LG copy pools, shut them down or the restore to the volume with the allocated data set(s) will fail.

4. Submit HSM FRRECOV job. In the sample job, the batch TSO program IKJEFT01 is being executed in order to execute the HSM FRRECOV commands.

Sample HSM FRRECOV Command Job: //HSMREC06 JOB (DE03557),CH,NOTIFY=&SYSUID, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M //*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //* //STEP1 EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * HSEND FRRECOV COPYPOOL(DSN$COBDBN6$DB) VERIFY(Y) HSEND FRRECOV COPYPOOL(DSN$COBDBN6$LG) VERIFY(Y) /*

Note

VERIFY(Y|N) is an optional parameter that is used to ensure that no source volumes in the copy pool are in an existing FlashCopy relationship. If one or more volumes are in an existing FlashCopy relationship, the recover fails. VERIFY(Y) is the default.

5. After HSM FRRECOV job has been submitted, a HSM command can be issued to see the status of the

background copies and the FlashCopy relationships.

Sample HSEND Job: //HSENDS05 JOB (DE03557),CH,NOTIFY=&SYSUID, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M



//*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //* //STEP1 EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * HSEND QUERY COPYPOOL(DSN$COBDBN6$LG) HSEND QUERY COPYPOOL(DSN$COBDBN6$DB) //

Sample HSEND Job Output: As displayed in the following messages, all of the volumes in the DSN$location_name$DB and the DSN$location_name$LG copy pools have an active FlashCopy Background copy running. In this case, the background copy is going from the FR-BACKUP volumes to the FR-PRIMARY volumes.

ARC1820I THE FOLLOWING VOLUMES IN COPYPOOL DSN$COBDBN6$LG, VERSION 022, HAVE ARC1820I (CONT.) AN ACTIVE FLASHCOPY BACKGROUND COPY ARC1820I (CONT.) SGNAME FR-PRIMARY FR-BACKUP ARC1820I (CONT.) DB2D1L COBD1L COBF1L ARC1820I (CONT.) DB2D1M COBD1M COBF1M ARC1820I THE FOLLOWING VOLUMES IN COPYPOOL DSN$COBDBN6$DB, VERSION 023, HAVE ARC1820I (CONT.) AN ACTIVE FLASHCOPY BACKGROUND COPY ARC1820I (CONT.) SGNAME FR-PRIMARY FR-BACKUP ARC1820I (CONT.) DB2D1 COBD11 COBF11 ARC1820I (CONT.) DB2D1 COBD12 COBF12 ARC1820I (CONT.) DB2D1 COBD13 COBF13 ARC1820I (CONT.) DB2D1 COBD14 COBF14 ARC1820I (CONT.) DB2D1 COBD15 COBF15 ARC1820I (CONT.) DB2D1 COBD16 COBF16 IKJ56250I JOB HSENDS05(JOB06253) SUBMITTED

Sample HSM FRRECOV Command Job Output Messages: IEF142I HSMREC06 STEP1 - STEP WAS EXECUTED - COND CODE 0000 IEF285I DB2ADM1.HSMREC06.JOB03147.D0000102.? SYSOUT IEF285I DB2ADM1.HSMREC06.JOB03147.D0000101.? SYSIN IEF373I STEP/STEP1 /START 2008179.1424 IEF374I STEP/STEP1 /STOP 2008179.1424 CPU 0MIN 00.01SEC SRB 0M IEF375I JOB/HSMREC06/START 2008179.1424 IEF376I JOB/HSMREC06/STOP 2008179.1424 CPU 0MIN 00.01SEC SRB 0M READY HSEND FRRECOV COPYPOOL(DSN$COBDBN6$DB) VERIFY(Y) ARC1007I COMMAND REQUEST 00000350 SENT TO DFSMSHSM READY HSEND FRRECOV COPYPOOL(DSN$COBDBN6$LG) VERIFY(Y) ARC1007I COMMAND REQUEST 00000351 SENT TO DFSMSHSM READY END

Sample HSM Started Task Messages: Once the HSM FRRECOV commands have been issued, the actions being taken by HSM can be viewed in the HSM stared task’s JESMSGLG.

ARC1801I FAST REPLICATION RECOVERY IS STARTING FOR ARC1801I (CONT.) COPYPOOL DSN$COBDBN6$DB, AT 16:14:54 ON 2008/07/03



ARC1805I THE FOLLOWING 00006 VOLUME(S) WERE ARC1805I (CONT.) SUCCESSFULLY PROCESSED BY FAST REPLICATION RECOVERY ARC1805I (CONT.) OF COPYPOOL DSN$COBDBN6$DB ARC1805I (CONT.) COBD11 ARC1805I (CONT.) COBD12 ARC1805I (CONT.) COBD13 ARC1805I (CONT.) COBD14 ARC1805I (CONT.) COBD15 ARC1805I (CONT.) COBD16 ARC1802I FAST REPLICATION RECOVERY HAS COMPLETED FOR ARC1802I (CONT.) COPYPOOL DSN$COBDBN6$DB, AT 16:14:58 ON 2008/07/03, ARC1802I (CONT.) FUNCTION RC=0000, MAXIMUM VOLUME RC=0000 ARC1801I FAST REPLICATION RECOVERY IS STARTING FOR ARC1801I (CONT.) COPYPOOL DSN$COBDBN6$LG, AT 16:14:58 ON 2008/07/03 ARC1805I THE FOLLOWING 00002 VOLUME(S) WERE ARC1805I (CONT.) SUCCESSFULLY PROCESSED BY FAST REPLICATION RECOVERY ARC1805I (CONT.) OF COPYPOOL DSN$COBDBN6$LG ARC1805I (CONT.) COBD1L ARC1805I (CONT.) COBD1M ARC1802I FAST REPLICATION RECOVERY HAS COMPLETED FOR ARC1802I (CONT.) COPYPOOL DSN$COBDBN6$LG, AT 16:14:58 ON 2008/07/03, ARC1802I (CONT.) FUNCTION RC=0000, MAXIMUM VOLUME RC=0000

Sample HSM JESMSGLG messages of Failed Restore: As displayed in the HSM JESMSGLG messages below, not all of the volumes were successfully restored. For more information, see the section Restoring Individual Volumes for instructions to restore individual volumes.

ARC1803E THE FOLLOWING 00001 VOLUME(S) FAILED DURING ARC1803E (CONT.) FAST REPLICATION RECOVERY OF COPY POOL DSN$COBDBN6$DB ARC1803E (CONT.) COBD14 ARC1805I THE FOLLOWING 00005 VOLUME(S) WERE ARC1805I (CONT.) SUCCESSFULLY PROCESSED BY FAST REPLICATION RECOVERY ARC1805I (CONT.) OF COPY POOL DSN$COBDBN6$DB ARC1805I (CONT.) COBD11 ARC1805I (CONT.) COBD12 ARC1805I (CONT.) COBD13 ARC1805I (CONT.) COBD15 ARC1805I (CONT.) COBD16 ARC1802I FAST REPLICATION RECOVERY HAS COMPLETED FOR ARC1802I (CONT.) COPY POOL DSN$COBDBN6$DB, AT 14:09:13 ON 2008/07/01, ARC1802I (CONT.) FUNCTION RC=0008, MAXIMUM VOLUME RC=0008

6. After the restore of the DSN$location_name$DB and the DSN$location_name$LG have completed successfully, the DB2 system or members are ready to be restarted.

It is not necessary to wait for all of the background IO to complete before the DB2 members can be restarted. However, before starting any of the DB2 members, all of the XCF structures for this DB2 data sharing group must be deallocated. This is done by issuing a SETXCF FORCE command. Typically, if all of the DB2 members were shutdown normally and did not come down hard, the only two structures needing deallocation are the LOCK1 and SCA structures.






7. Restart all DB2 members for this data sharing group in ACCESS(MAINT). The copy that was restored is a ‘crash’ consistent copy. Therefore, all of the DB2 members go through normal restart processes that are executed when DB2 abends.

8. After all of the DB2 members have restarted, issue the following commands to ensure all DB2 objects

are in a normal status.


9. Once it is clear that all DB2 objects are in a normal status, bring down and restart all members in the group in normal access mode. It is not necessary for all of the background IO to have completed to make the DB2 system or members available for normal usage.

Recommendation

Once it has been determined that the system has been returned to the point-in-time that was needed, and all of the background IO from the restore has completed, run a new Backup System utility to ensure a new recovery point. Use the HSEND QUERY job to verify that all background IO has completed.

Restoring Individual Volumes When running the Restore System utility, the HSM FRRECOV command, or DFSMSdss Restore, there can be occurrences of volumes not being restored successfully. This occurs when a data set on a volume to be restored is allocated and being used by a running process.

The Restore System utility, the HSM FRRECOV command, or DFSMSdss Restore may be restoring hundreds of volumes. It is not necessary to repeat the restore on all of these volumes when one or two volumes were not restored successfully. It is necessary to identify what caused the failed volume restores. While researching the failed restores, the background copy IO (or in the case of a DFSMSdss Restore the copy IO) is executed for the successfully restored volumes.

After resolving the issue that caused the failed volume restores, the HSM FRRECOV command or DFSMSdss Restore is used at the volume level to complete the volume restores.

• If using HSM FRRECOV TOVOLUME to complete the failed individual volume restores for a Restore System utility PITR, the DB2 system should not be stopped or brought down.

• If using HSM FRRECOV TOVOLUME to complete the failed individual volume restores for an HSM FRRECOV PITR, and the DB2 system is down, it can remain down.

• If using DFSMSdss Restore to complete the failed individual volume restores for a HSM FRRECOV PITR or a DFSMSdss Restore PITR, and the DB2 system is down, it can remain down.



Sample HSM FRRECOV TOVOLUME JCL when Backup is on DASD: //HSMRECN6 JOB (DE03557),CH,NOTIFY=&SYSUID, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M //*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //* //STEP1 EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * HSEND FRRECOV TOVOLUME(COBD14) FROMCOPYPOOL(DSN$COBDBN6$DB)

/*

Sample HSM FRRECOV TOVOLUME JCL when Backup is on Tape dump: //HSMRECN6 JOB (DE03557),CH,NOTIFY=&SYSUID, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M //*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //* //STEP1 EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSTSIN DD * HSEND FRRECOV TOVOLUME(COBD14) FROMCOPYPOOL(DSN$COBDBN6$DB) FROMDUMP

/*

Sample DFSMSdss Restore JCL: //RESTAPS2 JOB (DE03557),CH,NOTIFY=BOEBLD1.DB2ADM1, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M TYPRUN=SCAN /*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //* //STEP1 EXEC PGM=ADRDSSU //SYSPRINT DD SYSOUT=* //TAPE1 DD UNIT=T3592RZ,VOL=SER=COB006, // LABEL=(1,SL),DISP=(OLD,KEEP), // DSN=HSMCOB.DMP.DB2DUMP1.VCOBD11.D08242.T232314 //DASD1 DD UNIT=3390,VOL=SER=COBD11,DISP=OLD //SYSIN DD * RESTORE INDDNAME(TAPE1) OUTDDNAME(DASD1) PURGE ADMIN

Restoring Using HSM FRRECOV:

If the system level recovery is a baseline recovery, meaning HSM FRRECOV was being used to restore both the DSN$location_name$DB and DSN$location_name$LG copy pools, then return to the recovery procedure in section Recovery to Point in Time of Backup Using DFSMShsm FRRECOV to continue the recovery procedure.

Restoring Individual Volumes for a HSM FRRECOV PITR:

If the system level recovery is a baseline recovery, meaning HSM FRRECOV was being used to restore both the DSN$location_name$DB and DSN$location_name$LG copy pools, then after the successful restore of



the individual volumes, return to the recovery procedure in section Recovery to Point in Time of Backup Using DFSMShsm FRRECOV to continue the recovery procedure.

Restoring Individual Volumes for a Restore System Utility PITR:

If the system level recovery is a Restore System PITR, the log apply phase of the recovery still needs to be executed after the successful restore of the individual volumes. Run the Restore System utility using the LOGONLY option.

Sample Restore System LOGONLY JCL: //RESTN20A JOB (DE03557),CH,NOTIFY=BOEBLD1.DB2ADM1, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M /*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //* //************************************************************** //* STEP BACKUP: RUN BACKUP SYSTEM DATASHARING SN61 //************************************************************** //RESTORE EXEC DSNUPROC,SYSTEM=SN61, // UID='DB2ADM',LIB=SYS1.DSN.V910.SDSNLOAD //DSNUPROC.SYSIN DD * RESTORE SYSTEM LOGONLY /*

When the LOGONLY has completed successfully, return to the chapter RESTORE SYSTEM with backup on DASD: PIT recovery specifying SYSPITRT or RESTORE SYSTEM with backup on TAPE: PIT recovery specifying SYSPITRT to complete the system level recovery.

Restoring Individual Volumes for a DFSMSdss Restore PITR: If the system level recovery is a baseline recovery from a tape dump, then DFSMSdss was being used to restore both the DSN$location_name$DB and DSN$location_name$LG copy pools. After the successful restore of the individual volumes, return to the recovery procedure in section Recovery to Point in Time of Backup on Tape Using DFSMSdss to continue the recovery procedure.



Cloning Based on Copy on DASD with DB2 Cloning Tool Using FlashCopy This test case is based on a user-managed flash copy from a backup. The reason why the DB2 Cloning Tool is not used to do the actual copy is that DB2 Cloning Tool would clone from production volumes to the target system. We wanted to establish independence from the production system and clone instead from a backup. The cloning pairs however remain COBDnn as original data source and COBCnn as target. The Flash Copy is done from COBFnn to COBCnn.

Description of the Environment In the following example, the original data source is COBD1, the copied source from the backup system is COBFC1 and the target is COBCL1.

We use user-managed Flash Copy from COBF* to COBC* because the Cloning Tool would take COBD* as the Source

For this example, we made the following assumptions:

1. All volumes are in the same DASD subsystem device 2. Non-incremental Backup; FC relationships from Backup copy are withdrawn after background I/O is

complete 3. NOCOPY cannot be used 4. User manages FlashCopy between Backup system copy volumes and Cloning Target volumes 5. FC relationship between Backup Copy and Target DB2 system volumes exist until background copy

is complete 6. DB2 Cloning Tool is available



In addition, we made the following assumptions for the DB2 Cloning Tool:

1. DB2 Cloning Tool journal file and the CATWORK-DSN data sets are available. This is created during

the COPY job using 'DATA-MOVER(PGM(NONE))' parameter. 'DATA-MOVER(PGM(NONE))' implies that target volumes have already been created. The COPY job backs up the source ICF catalog information needed to rename and catalog the target system data sets during the RENAME job.

2. The ICF catalog data sets cloned to the target volumes will be used by the COPY job for externalizing the source ICF catalog information when the following keyword is used:

USERCATALOGS ( sourcecat1 [ ( volser1 ) ] targetcat1 - [ , sourcecatn [ ( volsern ) ] targetcatn ] )

Sample statement:

//CKZIN DD * COPY - DATA-MOVER(PGM(NONE)) - VOLPAIRS-DDN(VOLPAIRS) - USERCATALOGS(SYS1.USERCAT.DBN6 (COBD14) SYS1.USERCAT.DBNC - SYS1.USERCAT.DBN6L (COBD1L) SYS1.USERCAT.DBNCL) - CATWORK-DSN(DB2ADM1.DBN6.WRK.* ) -

Prepare DB2 First, one must define the USERCAT & ALIAS for the new subsystems. For a sample job, see section Cloning Based on Copy on DASD with DB2 Cloning Tool (SAP Doublestack system ABAP+Java).

Cloning Tool Jobs Backup System has already been carried out (Created COBF*)

Mapping needs to be from COBD* to COBC* because all the entries in COBF* are the same as in COBD*

For example: SYS1.VTOCIX.VCOBD11 and SYS1.VVDS.VCOBD11.

The following is a list of the cloning tool jobs. For more information about the individual jobs, see List of Cloning Tool Jobs in Detail.

• FINDUCATS (CKZFUCAT) for original data source COBD1*

• COPY (CKZCOPY) : the actual copy was done with Flash Copy using COBF* (Result from Backup System) as the source. This COPY job creates the journal and captures catalog data – DATA-MOVER(PGM(NONE))

• VOLOPTION (CKZVOLOP) CLIP to rename volumes

• Do native Copy with Flash Copy from COBF* to COBC* (For more information, see Verify Correct Flash Copy.)

• Run RENAME (CKZREN)

• DB2UPDATE (CKZDUPT): Update first target DB2 member (CKZDUPD2) : Update 2nd Member (CKZDUPD2) : Update 3rd Member Check result with BSDSPRINT

• DB2START (CKZDSTA): Start target DB2s in maintenance mode with changed ZPARMs ( DEFER YES & SPRMCTU SETC ‘I’ ) Start each member in its own LPAR COB1/2/3 and use different jobs



• Run DB2FIX (CKZDFIX): Fix catalog and directory page spaces in LPL, GRECP status (Note: This might only run on the LPAR where the logs have been used at the time of the COPY) We had to STOP DB2 and rerun the DB2UPDATE (first Job) with DBD01ONLY Parameter again. The reason was that SNDB01 was restricted, so some changes might have been applied to regress our previous changes. Start DB2 in Maintenace mode again with apecial ZPARM. and an extra DB2FIX catalog

• DB2SQL (CKZDSQL): Update target DB2 catalog

• Run DB2FIX (CKZDFIX): (Fix application pages spaces in LPL, GRECP status)

• DB2STOP (CKZDSTO): Run DB2STOP – (Stop target in maintenance mode)

• DB2START (CKZDSTA) Run DB2START – (Start target normally)

List of Cloning Tool Jobs in Detail

FINDUCATS FINDUCATS identifies which ICF User catalogs point at data sets on the source volumes to be copied. The COPY step requires pairs of source/target user ICF catalogs to be specified. FINDUCATS does not negate this need. It is intended to be run prior to the initial setup -- and possibly on an occasional basis -- to make sure the user catalogs that should be specified for the COPY step have not changed.

Changes to Sample Job CKZFUCAT for Source COBD1*: //CKZFINDU JOB ,'FINDUCATS',CLASS=A,MSGCLASS=H,NOTIFY=&SYSUID /*JOBPARM SYSAFF=COB1 //******************************************************************** //* COPYRIGHT 2001 - 2006 MAINSTAR SOFTWARE CORPORATION * //* ALL RIGHTS RESERVED * //******************************************************************** //S1 EXEC PGM=CKZ00010,REGION=6M //STEPLIB DD DISP=SHR,DSN=SYS1.DB2CT.V210.SCKZLOAD //CKZINI DD DISP=SHR, // DSN=DB2TOOLS.DBN6.SYS1.DB2CT.V210.SCKZPARM(CKZINI) //CKZPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //ABNLIGNR DD DUMMY DO NOT REMOVE IF USING ABENDAID //CKZIN DD * FINDUCATS - FROM-STORAGEGROUP(DB2D1*)

Output of changed Sample Job CKZFUCAT: CKZ41086I STORAGE GROUPS/MASKS FOR KEYWORD: FROM-STORAGEGROUP DB2D1* CKZ41087I 8 VOLSERS DERIVED FOR KEYWORD: FROM-STORAGEGROUP COBD1L COBD1M COBD11 COBD12 COBD13 COBD14 COBD15 COBD16 ….. CKZ41136I VOLSER USERCATALOG NAME ALIAS NAME OR H COBD1L ** SYS1.CATALOG.VCOBLIB SYS1.DSN



SYS1.USERCAT.DBN6L **BCS ON VOL** DBN6.SN61 DBN6.SN62 DBN6.SN63 COBD1M SYS1.USERCAT.DBN6L DBN6.SN61 DBN6.SN62 DBN6.SN63 COBD11 ** SYS1.CATALOG.VCOBLIB DBN6.DSNDBD COBD12 ** SYS1.CATALOG.VCOBLIB DBN6.DSNDBD COBD13 ** SYS1.CATALOG.VCOBLIB DBN6.DSNDBD COBD14 ** SYS1.CATALOG.VCOBLIB DBN6.DSNDBD SYS1.USERCAT.DBN6 **BCS ON VOL** COBD15 ** SYS1.CATALOG.VCOBLIB DBN6.DSNDBD COBD16 ** SYS1.CATALOG.VCOBLIB DBN6.DSNDBD

COPY The COPY step initiates volume copies, and concurrently backs up the source ICF catalog data relevant to the data sets on the source volumes being copied. In our case, the actual copy was done with Flash Copy using COBF* (Result from Backup System) as the source. Therefore, we run the job with the option DATA-MOVER(PGM(NONE)). 'DATAMOVER(PGM(NONE))' implies that target volumes have already been created. The COPY command in this case only backs up the source ICF catalog information needed to rename and catalog the target volume data sets. Optionally, it relabels the target volumes and varies them online for RENAME processing. The COPY should be done immediately after the SPLIT. Source ICF catalogs can also be cloned and read from the target volume. This is necessary because of the possible time difference between the backup and the actual source, e.g. if the backup is already a couple of days old. The Cloning Tool COPY job in our scenario creates the journal and captures catalog data.

Changes to Sample Job CKZCOPY: //CKZCOPYA JOB (DE03557),CH,NOTIFY=&SYSUID, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M //*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //* //******************************************************************** //* COPYRIGHT 2001 - 2006 MAINSTAR SOFTWARE CORPORATION * //* ALL RIGHTS RESERVED * //******************************************************************** //S0 EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DEL DB2ADM1.DBN6.JRNL DEL DB2ADM1.DBN6.WRK.UCATBKUP.* SET MAXCC=0 //S1 EXEC PGM=CKZ00010,REGION=8M //STEPLIB DD DISP=SHR,DSN=SYS1.DB2CT.V210.SCKZLOAD //CKZINI DD DISP=SHR, // DSN=DB2TOOLS.DBN6.SYS1.DB2CT.V210.SCKZPARM(CKZINI) //VOLPAIRS DD DSN=DB2TOOLS.VOLPAIRS.CNTL(DBN6C),DISP=SHR //CKZPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=*



//ABNLIGNR DD DUMMY DO NOT REMOVE IF USING ABENDAID //******************************************************************** //* C A U T I O N //* THE JOURNAL DATA SET MUST BE CATALOGED FOR SUBSEQUENT USE BY THE //* RENAME STEP AND OPTIONALLY THE COPYCHECK AND BCSCLEAN STEPS. //* A UNIQUE JOURNAL DATASET MUST BE USED FOR EACH DISTINCT //* DB2 CLONING TOOL PROCESS. //******************************************************************** //JOURNAL DD DSN=DB2ADM1.DBN6.JRNL, // DISP=(,CATLG),UNIT=SYSALLDA, // RECORG=KS,KEYLEN=64,KEYOFF=0, // LRECL=600,SPACE=(CYL,(10,10)) //CKZIN DD * COPY - DATA-MOVER(PGM(NONE)) - VOLPAIRS-DDN(VOLPAIRS) - USERCATALOGS(SYS1.USERCAT.DBN6 SYS1.USERCAT.DBNC - SYS1.USERCAT.DBN6L SYS1.USERCAT.DBNCL) - CATWORK-DSN(DB2ADM1.DBN6.WRK.* ) - JOURNAL-DDN(JOURNAL) //********************************************************************

Output of changed Sample Job CKZCOPY: IDCAMS SYSTEM SERVICES T DEL DB2ADM1.DBN6.JRNL IDC0550I ENTRY (D) DB2ADM1.DBN6.JRNL.DATA DELETED IDC0550I ENTRY (I) DB2ADM1.DBN6.JRNL.INDEX DELETED IDC0550I ENTRY (C) DB2ADM1.DBN6.JRNL DELETED IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0 DEL DB2ADM1.DBN6.WRK.UCATBKUP.* IDC0550I ENTRY (A) DB2ADM1.DBN6.WRK.UCATBKUP.BKP00001 DELETED IDC0550I ENTRY (A) DB2ADM1.DBN6.WRK.UCATBKUP.BKP00002 DELETED IDC0550I ENTRY (A) DB2ADM1.DBN6.WRK.UCATBKUP.SRT00001 DELETED IDC0550I ENTRY (A) DB2ADM1.DBN6.WRK.UCATBKUP.SRT00002 DELETED IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0 SET MAXCC=0 IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0 DB2 CLONING TOOL CKZINI INFORMATION MODULE INFORMATION REL: V2R1M0 REL: V2R1M0 DATE: 02 OCT 2007 CKZ01020I PROGRAM: CKZ01CIO 20070816 17.19 VERS=1.0 REV=34 COPY - DATA-MOVER(PGM(NONE)) - VOLPAIRS-DDN(VOLPAIRS) - USERCATALOGS(SYS1.USERCAT.DBN6 SYS1.USERCAT.DBNC - SYS1.USERCAT.DBN6L SYS1.USERCAT.DBNCL) - CATWORK-DSN(DB2ADM1.DBN6.WRK.* ) - JOURNAL-DDN(JOURNAL)



CKZ02001I 10.20.35 COPY PROCESS STARTED - PROGRAM REV=57 CKZ02087I 8 VOLUME PAIRS FOR KEYWORD: VOLPAIRS-DDN COBD1L COBC1L COBD1M COBC1M COBD11 COBC11 COBD12 COBC12 COBD13 COBC13 COBD14 COBC14 COBD15 COBC15 COBD16 COBC16 CKZ02088I VOLUME SERIAL(S) TO BE USED FOR SOURCE COBD1L COBD1M COBD11 COBD12 COBD13 COBD14 COBD15 COBD16 TOTAL NUMBER: 8 CKZ02088I VOLUME SERIAL(S) TO BE USED FOR TARGET COBC1L COBC1M COBC11 COBC12 COBC13 COBC14 COBC15 COBC16 TOTAL NUMBER: 8 CKZ02085I DSNS FOR KEYWORD: USERCATALOGS SYS1.USERCAT.DBN6 SYS1.USERCAT.DBNC SYS1.USERCAT.DBN6L SYS1.USERCAT.DBNCL CKZ03501I 10.20.35 CHECK USERCATALOGS STARTED - PROGRAM REV=6 CKZ03501I 10.20.35 CHECK USERCATALOGS COMPLETED; RETURN CODE=0 CKZ03501I 10.20.35 CHECK USERCATALOGS STARTED - PROGRAM REV=6 CKZ03501I 10.20.35 CHECK USERCATALOGS COMPLETED; RETURN CODE=0 CKZ02089I TARGET VOLUMES WILL NOT BE CHECKED FOR EMPTY CKZ02048I OPTIONS IN EFFECT FOR THIS EXECUTION: CONCURRENT_EXECUTIONS: N CKZ02030I DSS LEVEL=X'03010900' CKZ02043I ANTRQST LEVEL=12; ESSRVCS LEVEL=104 CKZ02101I 10.20.36 VOLUME COPY STARTED - PROGRAM REV=45 CKZ02131I PRE-COPIED VOLUME PAIRS ACCEPTED: SOURCE TARGET COBD1L COBC1L COBD1M COBC1M COBD11 COBC11 COBD12 COBC12 COBD13 COBC13 COBD14 COBC14 COBD15 COBC15 COBD16 COBC16 CKZ02101I 10.20.36 VOLUME COPY COMPLETED; RETURN CODE=0 CKZ02201I 10.20.36 BCS BACKUP STARTED - PROGRAM REV=27 CKZ02241I BCS=SYS1.USERCAT.DBN6 WILL BE BACKED UP TO DSN=DB2ADM1.DBN6.WRK.UCATBK CKZ02241I BCS=SYS1.USERCAT.DBN6L WILL BE BACKED UP TO DSN=DB2ADM1.DBN6.WRK.UCATB CKZ02230I BCS BACKUP TASK COMPLETED; RETURN CODE=0 SYSOUT DD=BKP00001 CKZ02230I BCS BACKUP TASK COMPLETED; RETURN CODE=0 SYSOUT DD=BKP00002 CKZ02201I 10.20.37 BCS BACKUP COMPLETED; RETURN CODE=0 CKZ02001I 10.20.37 COPY PROCESS COMPLETED; RETURN CODE=0 CKZ01009I DB2 CLONING TOOL EXECUTION COMPLETE. HIGHEST RETURN CODE WAS 0



VOLOPTION The VOLOPTION command is needed when the COPY command is run at one site and the RENAME command is run at another. VOLOPTION CLIP clips the volumes to the corresponding target volume serials. This is necessary prior to cataloguing and renaming the datasets at the target site, which is done later by the RENAME step.

Our VOLOPTION CLIP job changes volume names from COBD* to COBC*.

Changes to Sample Job CKZVOLOP: //CKZIN DD * VOLOPTIONS CLIP - JOURNAL-DDN(JOURNAL)

Output of changed Sample Job CKZVOLOP: VOLOPTIONS CLIP - JOURNAL-DDN(JOURNAL) CKZ42001I 17.48.09 VOLOPTIONS STARTED - PROGRAM REV=22 CKZ42020I CURRENT JOURNAL VOLUME PAIRS: COBD1L COBC1L 2449 COBD1M COBC1M 2445 COBD11 COBC11 2431 COBD12 COBC12 2432 COBD13 COBC13 2433 COBD14 COBC14 2434 COBD15 COBC15 2435 COBD16 COBC16 2436 CKZ42101I 17.48.09 VOLOPTIONS CLIP STARTED - PROGRAM REV=18 CKZ42141I VOLUME SERIAL: COBD1L DEVICE NUMBER: 4A8B IS NOW OFFLINE CKZ42141I VOLUME SERIAL: COBD1M DEVICE NUMBER: 4A8D IS NOW OFFLINE CKZ42141I VOLUME SERIAL: COBD11 DEVICE NUMBER: 4D11 IS NOW OFFLINE CKZ42141I VOLUME SERIAL: COBD12 DEVICE NUMBER: 4D12 IS NOW OFFLINE CKZ42141I VOLUME SERIAL: COBD13 DEVICE NUMBER: 4D13 IS NOW OFFLINE CKZ42141I VOLUME SERIAL: COBD14 DEVICE NUMBER: 4D14 IS NOW OFFLINE CKZ42141I VOLUME SERIAL: COBD15 DEVICE NUMBER: 4D15 IS NOW OFFLINE CKZ42141I VOLUME SERIAL: COBD16 DEVICE NUMBER: 4D16 IS NOW OFFLINE CKZ03101I 17.48.09 CLIP TARGET(S) STARTED - PROGRAM REV=25 CKZ03103I DDNAME=SYS00001 ALLOCATED FOR DSN=**TEMPORARY ICKIN DSN CKZ03103I DDNAME=SYS00002 ALLOCATED FOR DSN=**TEMPORARY ICKOUT DSN CKZ03140I DEVICE NUMBER: 4A8B SUCCESSFULLY CHANGED TO VOLUME SERIAL: COBC1L CKZ03141I VOLUME SERIAL: COBC1L DEVICE NUMBER: 4A8B IS NOW ONLINE CKZ03140I DEVICE NUMBER: 4A8D SUCCESSFULLY CHANGED TO VOLUME SERIAL: COBC1M CKZ03141I VOLUME SERIAL: COBC1M DEVICE NUMBER: 4A8D IS NOW ONLINE CKZ03140I DEVICE NUMBER: 4D11 SUCCESSFULLY CHANGED TO VOLUME SERIAL: COBC11 CKZ03141I VOLUME SERIAL: COBC11 DEVICE NUMBER: 4D11 IS NOW ONLINE CKZ03140I DEVICE NUMBER: 4D12 SUCCESSFULLY CHANGED TO VOLUME SERIAL: COBC12 CKZ03141I VOLUME SERIAL: COBC12 DEVICE NUMBER: 4D12 IS NOW ONLINE CKZ03140I DEVICE NUMBER: 4D13 SUCCESSFULLY CHANGED TO VOLUME SERIAL: COBC13 CKZ03141I VOLUME SERIAL: COBC13 DEVICE NUMBER: 4D13 IS NOW ONLINE CKZ03140I DEVICE NUMBER: 4D14 SUCCESSFULLY CHANGED TO VOLUME SERIAL: COBC14 CKZ03141I VOLUME SERIAL: COBC14 DEVICE NUMBER: 4D14 IS NOW ONLINE CKZ03140I DEVICE NUMBER: 4D15 SUCCESSFULLY CHANGED TO VOLUME SERIAL: COBC15 CKZ03141I VOLUME SERIAL: COBC15 DEVICE NUMBER: 4D15 IS NOW ONLINE



CKZ03140I DEVICE NUMBER: 4D16 SUCCESSFULLY CHANGED TO VOLUME SERIAL: COBC16 CKZ03141I VOLUME SERIAL: COBC16 DEVICE NUMBER: 4D16 IS NOW ONLINE CKZ03101I 17.48.10 CLIP TARGET(S) COMPLETED; RETURN CODE=0 CKZ42101I 17.48.10 VOLOPTIONS CLIP COMPLETED; RETURN CODE=0 CKZ42001I 17.48.10 VOLOPTIONS COMPLETED; RETURN CODE=0 CKZ01009I DB2 CLONING TOOL EXECUTION COMPLETE. HIGHEST RETURN CODE WAS 0

Flash Copy Do a native Copy with Flash Copy from COBF* to COBC* (For more information, see Verify Correct Flash Copy.)

Job Example FCCOPYS: /FCCOPY0B JOB (DE03557),CH,NOTIFY=&SYSUID, / MSGCLASS=X,MSGLEVEL=(1,1), / TIME=120,CLASS=A,REGION=0M /*ROUTE XEQ BOECOB1 *JOBPARM SYSAFF=COB1 /* /* DB2 FLASHCOPY /FLASHCOP EXEC PGM=ADRDSSU /SYSPRINT DD SYSOUT=X /SYSUDUMP DD SYSOUT=X,OUTLIM=3000 /SYSIN DD * PARALLEL COPY FULL INDYNAM (COBF11) OUTDYNAM (COBC11) DUMPCONDITIONING ADMIN - PURGE COPY FULL INDYNAM (COBF12) OUTDYNAM (COBC12) DUMPCONDITIONING ADMIN - PURGE COPY FULL INDYNAM (COBF13) OUTDYNAM (COBC13) DUMPCONDITIONING ADMIN - PURGE COPY FULL INDYNAM (COBF14) OUTDYNAM (COBC14) DUMPCONDITIONING ADMIN - PURGE COPY FULL INDYNAM (COBF15) OUTDYNAM (COBC15) DUMPCONDITIONING ADMIN - PURGE COPY FULL INDYNAM (COBF16) OUTDYNAM (COBC16) DUMPCONDITIONING ADMIN - PURGE COPY FULL INDYNAM (COBF1L) OUTDYNAM (COBC1L) DUMPCONDITIONING ADMIN - PURGE COPY FULL INDYNAM (COBF1M) OUTDYNAM (COBC1M) DUMPCONDITIONING ADMIN - PURGE * /



Verify Correct Flash Copy Check the number of datasets on each volume. The screenshots below show only Volume COB*11 in all 3 environments.

1. Environment D (source system)

Figure 20: Data Set List Utility – Volume COBD11



Figure 21: Data Sets on Volume COBD11



2. Environment F (environment of the backup system)

Figure 22: Data Sets on Volume COBF11



3. Environment – C (target system)

Figure 23: Data Sets on Volume COBC11



RENAME This step renames and catalogs target volume data sets. The SAFE option, a keyword of the RENAME command, is recommended to rerun the RENAME step to correct problems caused by mistakes such as incorrectly specified rename masks. Note that you can run the job with SIMULATE before you do the actual rename.

Changes in Sample Job CKZREN: /CKZIN DD * RENAME - SAFE - VOLBKUP-DDN(VOLBKUP) - MAX-TASKS(5) - JOURNAL-DDN(JOURNAL) - RECATALOG(Y) - DATACLAS(SOURCE) - MGMTCLAS(SOURCE) - STORCLAS(SOURCE) - NOTRENAMED(DELETE,RC(0)) - RENAME-MASKS( - SYS1.DSN.SN61.** SYS1.DSN.SNC1.** - SYS1.DSN.SN62.** SYS1.DSN.SNC2.** - SYS1.DSN.SN63.** SYS1.DSN.SNC3.** - DBN6.SN61.** DBNC.SNC1.** - DBN6.SN62.** DBNC.SNC2.** - DBN6.SN63.** DBNC.SNC3.** - DBN6.** DBNC.** - )

Output of changed Sample Job CKZREN:

CKZ10001I 10.21.46 RENAME PROCESS STARTED - PROGRAM REV=43 CKZ10085I DSNS FOR KEYWORD: RENAME-MASKS DBN6.** DBNC.** DBN6.SN61.** DBNC.SNC1.** DBN6.SN62.** DBNC.SNC2.** DBN6.SN63.** DBNC.SNC3.** SYS1.DSN.SN61.** SYS1.DSN.SNC1.** SYS1.DSN.SN62.** SYS1.DSN.SNC2.** SYS1.DSN.SN63.** SYS1.DSN.SNC3.** …. …. CKZ11032I VOLUME BACKUP STARTED FOR COBC1L CKZ11032I VOLUME BACKUP COMPLETED FOR COBC1L CKZ11030I VOLUME CONVERSION STARTED FOR COBD1L/COBC1L CKZ11032I VOLUME BACKUP STARTED FOR COBC1M CKZ11032I VOLUME BACKUP COMPLETED FOR COBC1M CKZ11030I VOLUME CONVERSION STARTED FOR COBD1M/COBC1M CKZ11032I VOLUME BACKUP STARTED FOR COBC11 CKZ11032I VOLUME BACKUP COMPLETED FOR COBC11 CKZ11030I VOLUME CONVERSION STARTED FOR COBD11/COBC11



…. …. CKZ11032I VOLUME BACKUP STARTED FOR COBC15 CKZ11032I VOLUME BACKUP COMPLETED FOR COBC15 CKZ11030I VOLUME CONVERSION STARTED FOR COBD15/COBC15 CKZ11030I VOLUME CONVERSION COMPLETED FOR COBD11/COBC11; RETURN CODE=0 DATA SET CKZ11032I VOLUME BACKUP STARTED FOR COBC16 CKZ11032I VOLUME BACKUP COMPLETED FOR COBC16 CKZ11030I VOLUME CONVERSION STARTED FOR COBD16/COBC16 CKZ11030I VOLUME CONVERSION COMPLETED FOR COBD12/COBC12; RETURN CODE=0 DATA SET CKZ11030I VOLUME CONVERSION COMPLETED FOR COBD13/COBC13; RETURN CODE=0 DATA SET CKZ11030I VOLUME CONVERSION COMPLETED FOR COBD14/COBC14; RETURN CODE=0 DATA SET CKZ11030I VOLUME CONVERSION COMPLETED FOR COBD15/COBC15; RETURN CODE=0 DATA SET CKZ11030I VOLUME CONVERSION COMPLETED FOR COBD16/COBC16; RETURN CODE=0 DATA SET CKZ11401I 10.25.04 VOLUME CLEANUP STARTED - PROGRAM REV=26 CKZ11435I PROCESSING VOLSER=COBC1L CKZ11435I PROCESSING VOLSER=COBC14 CKZ11401I 10.25.06 VOLUME CLEANUP COMPLETED; RETURN CODE=0 CKZ11034I TOTAL BYTES WRITTEN TO VOLBKUP DDNAME=VOLBKUP ; 23,203,936 CKZ11031I VOLUME CONVERSION TOTAL DATA SETS: 11502 CKZ11001I 10.25.06 VOLUME UPDATES COMPLETED; RETURN CODE=4 CKZ10001I 10.25.06 RENAME PROCESS COMPLETED; RETURN CODE=4 CKZ01009I DB2 CLONING TOOL EXECUTION COMPLETE. HIGHEST RETURN CODE WAS 4 …. …. KZ11102I RENAMING VTOC ENTRIES ON VOLUME: COBC1L KZ11112W DATA SET MATCHES NO RENAME MASK: SYS1.USERCAT.DBN6L KZ11112W DATA SET MATCHES NO RENAME MASK: SYS1.USERCAT.DBN6L.CATINDEX KZ11102I RENAMING VTOCIX ENTRIES ON VOLUME: COBC1L KZ11301I 10.22.23 VVDS UPDATE STARTED FOR VOLUME: COBC1L - PROGRAM REV=41 KZ11303I DDNAME=VDCOBC1L ALLOCATED FOR DSN=SYS1.VVDS.VCOBC1L KZ11342W USER CATALOG NOT IN CATALOG LIST - COMPONENT NAME=SYS1.DSN.SN61.DBRMLIB KZ11342W BCS=SYS1.CATALOG.VCOBLIB KZ11342W USER CATALOG NOT IN CATALOG LIST - COMPONENT NAME=SYS1.DSN.SN61.DSNDMEP KZ11342W BCS=SYS1.CATALOG.VCOBLIB KZ11342W USER CATALOG NOT IN CATALOG LIST - COMPONENT NAME=SYS1.DSN.SN61.DSNZPAR KZ11342W BCS=SYS1.CATALOG.VCOBLIB KZ11342W USER CATALOG NOT IN CATALOG LIST - COMPONENT NAME=SYS1.DSN.SN61.RUNLIB. KZ11342W BCS=SYS1.CATALOG.VCOBLIB KZ11342W USER CATALOG NOT IN CATALOG LIST - COMPONENT NAME=SYS1.DSN.SN61.SDSNEXI KZ11342W BCS=SYS1.CATALOG.VCOBLIB KZ11342W USER CATALOG NOT IN CATALOG LIST - COMPONENT NAME=SYS1.DSN.SN61.SRCLIB. KZ11342W BCS=SYS1.CATALOG.VCOBLIB KZ11342W USER CATALOG NOT IN CATALOG LIST - COMPONENT NAME=SYS1.DSN.SN62.DBRMLIB KZ11342W BCS=SYS1.CATALOG.VCOBLIB KZ11342W USER CATALOG NOT IN CATALOG LIST - COMPONENT NAME=SYS1.DSN.SN62.DSNDMEP KZ11342W BCS=SYS1.CATALOG.VCOBLIB KZ11342W USER CATALOG NOT IN CATALOG LIST - COMPONENT NAME=SYS1.DSN.SN62.DSNZPAR



KZ11342W BCS=SYS1.CATALOG.VCOBLIB KZ11342W USER CATALOG NOT IN CATALOG LIST - COMPONENT NAME=SYS1.DSN.SN62.RUNLIB. KZ11342W BCS=SYS1.CATALOG.VCOBLIB KZ11342W USER CATALOG NOT IN CATALOG LIST - COMPONENT NAME=SYS1.DSN.SN62.SDSNEXI KZ11342W BCS=SYS1.CATALOG.VCOBLIB KZ11342W USER CATALOG NOT IN CATALOG LIST - COMPONENT NAME=SYS1.DSN.SN62.SRCLIB. KZ11342W BCS=SYS1.CATALOG.VCOBLIB KZ11342W USER CATALOG NOT IN CATALOG LIST - COMPONENT NAME=SYS1.DSN.SN63.DBRMLIB KZ11342W BCS=SYS1.CATALOG.VCOBLIB KZ11342W USER CATALOG NOT IN CATALOG LIST - COMPONENT NAME=SYS1.DSN.SN63.DSNDMEP KZ11342W BCS=SYS1.CATALOG.VCOBLIB KZ11342W USER CATALOG NOT IN CATALOG LIST - COMPONENT NAME=SYS1.DSN.SN63.DSNZPAR KZ11342W BCS=SYS1.CATALOG.VCOBLIB KZ11342W USER CATALOG NOT IN CATALOG LIST - COMPONENT NAME=SYS1.DSN.SN63.RUNLIB. KZ11342W BCS=SYS1.CATALOG.VCOBLIB KZ11342W USER CATALOG NOT IN CATALOG LIST - COMPONENT NAME=SYS1.DSN.SN63.SDSNEXI KZ11342W BCS=SYS1.CATALOG.VCOBLIB KZ11342W USER CATALOG NOT IN CATALOG LIST - COMPONENT NAME=SYS1.DSN.SN63.SRCLIB. KZ11342W BCS=SYS1.CATALOG.VCOBLIB KZ11312W DATA SET MATCHES NO RENAME MASK: SYS1.USERCAT.DBN6L.CATINDEX KZ11312W DATA SET MATCHES NO RENAME MASK: SYS1.USERCAT.DBN6L KZ11301I 10.22.34 VVDS UPDATE COMPLETED; RETURN CODE=4 KZ11101I 10.22.34 VOLUME UPDATE COMPLETED; RETURN CODE=4 F1DSCB COUNT=37 KZ11101I 10.22.40 VOLUME UPDATE STARTED - PROGRAM REV=38 KZ11101I 10.22.40 VOLUME UPDATE STARTED - PROGRAM REV=38 KZ11102I RENAMING VTOC ENTRIES ON VOLUME: COBC1M KZ11102I RENAMING VTOCIX ENTRIES ON VOLUME: COBC1M KZ11301I 10.23.05 VVDS UPDATE STARTED FOR VOLUME: COBC1M - PROGRAM REV=41 KZ11303I DDNAME=VDCOBC1M ALLOCATED FOR DSN=SYS1.VVDS.VCOBC1M KZ11301I 10.23.20 VVDS UPDATE COMPLETED; RETURN CODE=0 …. …. KZ11301I 10.24.55 VVDS UPDATE STARTED FOR VOLUME: COBC16 - PROGRAM REV=41 KZ11303I DDNAME=VDCOBC16 ALLOCATED FOR DSN=SYS1.VVDS.VCOBC16 KZ11301I 10.25.04 VVDS UPDATE COMPLETED; RETURN CODE=0 KZ11101I 10.25.04 VOLUME UPDATE COMPLETED; RETURN CODE=0 F1DSCB COUNT=1855 ******************************** Bottom of Data ******************************

DB2UPDATE The DB2UPDATE command makes the necessary DB2 changes to reflect the renamed data sets. DB2UPDATE updates the DB2 directory and the DB2 boot strap data sets (BSDSs).

• DB2 directory updates – the VCATNAME, and optionally, the DB2 storage group names are updated.

• BSDS updates – the DB2 catalog name, and ‘active’ log data set names are updated. Optionally, the ARCHIVE data set names and volume serial numbers in the BSDS are updated.

If data sharing is used, the target DB2 XCF structures need to be deallocated. The DB2-XCFCLEAN(Y) keyword, the default, is used to instruct DB2UPDATE to deallocate the target DB2 XCF structures. If this



keyword is set to (N), the target DB2 XCF structures need to be manually deallocated prior to starting the target DB2 subsystem.

Update first Target DB2 Member. This is a complete update.

Changes to Sample Job CKZDUPD: /********************************************************* /BSDS01 DD DISP=OLD,DSN=DBNC.SNC1.BSDS01 /BSDS02 DD DISP=OLD,DSN=DBNC.SNC1.BSDS02 /DBD01 DD DISP=OLD, / DSN=DBNC.DSNDBC.DSNDB01.DBD01.I0001.A001 /CKZIN DD * DB2UPDATE - DB2-HLQS(DBN6,DBNC) - DB2-GROUP(DBN6,DBNC) - DB2-MEMBERS(SN61,SNC1 - SN62,SNC2 - SN63,SNC3) - DDF(LOCATION(COBDBNC) - PORT(5120) - RESPORT(5121) - LUNAME(IPXAANC1) - ) - DB2-XCFCLEAN(Y) - JOURNAL-DDN(JOURNAL) /*********************************************************

Output of changed Sample Job CKZDUPD: CKZ22085I PAIRS FOR KEYWORD: DB2-HLQS DBN6 DBNC CKZ22085I PAIRS FOR KEYWORD: DB2-MEMBERS SN61 SNC1 SN62 SNC2 SN63 SNC3 CKZ22086I VALIDATING KEYWORD: DDF CKZ22030I OPTIONS IN EFFECT FOR THIS EXECUTION: DB2-NAME: DB2-XCFCLEAN: Y DDF-NOT-UPDATED: RC(4) HLQ-NOT-UPDATED: RC(4) SIMULATION: N CKZ22101I 10.26.50 BSDS UPDATING STARTED - PROGRAM REV=39 CKZ22130I PROCESSING BSDS01 CKZ22130I PROCESSING BSDS02 CKZ22101I 10.26.51 BSDS UPDATING COMPLETED; RETURN CODE=0 CKZ22201I 10.26.51 LINEAR FILE UPDATING STARTED - PROGRAM REV=42 CKZ22230I PROCESSING DDNAME: DBD01



CKZ22231I THE FILE'S ENDING RBA IS: 000046448640 X'02C4C000' CKZ22242I DBD01 CHANGED RECORDS: 9030 CHANGED FIELDS: 40622 CKZ22201I 10.27.14 LINEAR FILE UPDATING COMPLETED; RETURN CODE=0 CKZ22301I 10.27.14 DB2 XCF CLEAN UP STARTED - PROGRAM REV=14 CKZ22320I XCF STRUCTURES FOR DB2 DATA SHARING GROUP DBNC : DBNC_LOCK1 DBNC_SCA DBNC_GBP8K0 DBNC_GBP16K0 DBNC_GBP32K DBNC_GBP0 DBNC_GBP2 DBNC_GBP3 DBNC_GBP40 CKZ22322I THE FOLLOWING XCF STRUCTURES WILL HAVE FAILED CONNECTIONS REMOVED: DBNC_LOCK1 CKZ22323I THE FOLLOWING XCF STRUCTURES WILL BE DEALLOCATED: DBNC_LOCK1 DBNC_SCA CKZ22334I XCF STRUCTURES CLEANED UP CKZ22350I XCF MEMBERS FOR DB2 DATA SHARING GROUP DBNC : DB2INMVSSNC1 DB2INMVSSNC2 DB2INMVSSNC3 CKZ22354I XCF MEMBERS CLEANED UP CKZ22301I 10.27.15 DB2 XCF CLEAN UP COMPLETED; RETURN CODE=0 CKZ22001I 10.27.15 DB2UPDATE COMPLETED; RETURN CODE=0 CKZ01009I DB2 CLONING TOOL EXECUTION COMPLETE. HIGHEST RETURN CODE WAS 0

******************************** Bottom of Data **************************

Update 2nd Member (BSDS only).

Changes to Sample Job CKZDUPD2 (for 2nd Member): /********************************************************* /BSDS01 DD DISP=OLD,DSN=DBNC.SNC2.BSDS01 /BSDS02 DD DISP=OLD,DSN=DBNC.SNC2.BSDS02 /CKZIN DD * DB2UPDATE - BSDSONLY - DB2-HLQS(DBN6,DBNC) - DB2-GROUP(DBN6,DBNC) - DB2-MEMBERS(SN61,SNC1 -



SN62,SNC2 - SN63,SNC3) - DDF(LOCATION(COBDBNC) - PORT(5120) - RESPORT(5122) - LUNAME(IPXABNC2) - ) - JOURNAL-DDN(JOURNAL) / ******************************** Bottom of Data

Update 3rd Member (BSDS only).

Changes to Sample Job CKZDUPD2 (for 3rd Member): /********************************************************* /BSDS01 DD DISP=OLD,DSN=DBNC.SNC3.BSDS01 /BSDS02 DD DISP=OLD,DSN=DBNC.SNC3.BSDS02 /CKZIN DD * DB2UPDATE - BSDSONLY - DB2-HLQS(DBN6,DBNC) - DB2-GROUP(DBN6,DBNC) - DB2-MEMBERS(SN61,SNC1 - SN62,SNC2 - SN63,SNC3) - DDF(LOCATION(COBDBNC) - PORT(5120) - RESPORT(5123) - LUNAME(IPXACNC3) - ) - JOURNAL-DDN(JOURNAL) / ******************************** Bottom of Data

Check Result with BSDSPRINT

Job Example BSDSPRIN: ********************************* Top of Data ************** /BSDSS11A JOB (DE03557),CH,NOTIFY=&SYSUID, / MSGCLASS=X,MSGLEVEL=(1,1), / TIME=120,CLASS=A,REGION=0M *ROUTE XEQ BOECOB1 *JOBPARM SYSAFF=COB1 /* /********************************************************* /* JOB DESCRIPTION /********************************************************* /* /*********************************************************** /SN61GRP4 EXEC PGM=DSNJU004 /STEPLIB DD DSN=SYS1.DSN.SN61.SDSNEXIT,DISP=SHR / DD DSN=SYS1.DSN.V910.SDSNLOAD,DISP=SHR /SYSPRINT DD SYSOUT=*



/GROUP DD DSN=DBN6.SN61.BSDS01,DISP=SHR /SYSIN DD * MEMBER * * / ******************************** Bottom of Data ************

DB2START DB2START (CKZDSTA): Start Target DB2s in Maintenance Mode with changed ZPARMs (DEFER YES & SPRMCTU SETC ‘I’)

Start each Member in its own LPAR COB1/2/3 (with different jobs)

Changes to Sample Job CKZDSTA (for 1st Member): /CKZIN DD * DB2START - DB2-SSID(SNC1) - SPECIAL - DSNZPARM(DSNZSPEC) /

Changes to Sample Job CKZDSTA (for 2nd Member): /CKZIN DD * DB2START DB2-SSID(SNC2) SPECIAL DSNZPARM(DSNZSPEC) /

Changes to Sample Job CKZDSTA (for 3rd Member): /CKZIN DD * DB2START DB2-SSID(SNC3) SPECIAL DSNZPARM(DSNZSPEC) /

DB2FIX Run DB2FIX to fix catalog and directory page spaces in LPL, GRECP status

(Note: This might only run on the LPAR where the logs have been used at the time of the COPY).

Changes to Sample Job CKZDFIX: /CKZIN DD * DB2FIX - DB2-SSID(SNC1) - DATABASES(DB2)

We had to STOP DB2 and rerun the DB2UPDATE (first Job) with DBD01ONLY Parameter once again. The reason for this was that DSNDB01 was restricted, and therefore some changes might have been applied to



regress our previous changes. Subsequently, Start DB2 in maintenace mode again with special ZPARM and an extra DB2FIX catalog.

DB2UPDATE - DBD01ONLY - DB2-HLQS(DBN6,DBNC) - DB2-GROUP(DBN6,DBNC) - DB2-MEMBERS(SN61,SNC1 - SN62,SNC2 - SN63,SNC3) - DDF(LOCATION(COBDBNC) - PORT(5120) - RESPORT(5121) - ) - DB2-XCFCLEAN(Y) - JOURNAL-DDN(JOURNAL)

DB2SQL In this step, we update the target DB2 catalog.

Changes to Sample Job CKZDSQL: /CKZIN DD * DB2SQL - DB2-SSID(SNC1) - LISTSQL(Y) - JOURNAL-DDN(JOURNAL)

DB2FIX Run DB2FIX: (Fix application pages spaces in LPL, GRECP status)

Changes to Sample Job CKZDFIX: /CKZIN DD * DB2FIX - DB2-SSID(SNC1) - DATABASES(APPLICATION)

DB2STOP DB2STOP: Run DB2STOP – (Stop target in maintenance mode)

Changes to Sample Job CKZDSTO: /CKZIN DD * DB2STOP - DB2-SSID(SNC1)

DB2START DB2START: Run DB2START – (Start target normally)



Changes to Sample Job CKZDSTA: //CKZIN DD * DB2START - DB2-SSID(SNC1) -

NORMAL

At this point, the cloned DB2 data sharing group is ready and can be used.



8. DB2 single subsystem, SAP ABAP+Java and DASD Use Case

This use case assumes that a single DB2 subsystem is used. The system is not in data sharing mode. As in the previous use case, the backup is written to the disk subsystem (DASD). In contrast to the previous use case, the SAP system contains both an ABAP stack and a Java stack.

Depending on the SAP release, the SAP Java stack imposes restrictions on the schema name used for the database tables accessed by the Java applications. Therefore, the cloning steps in this section take these considerations into account. Also, be aware that some SAP Java applications may store some data - for example, configuration data that may not change often - in the file system of the application server. If this is the case, a point-in-time recovery would need to take these files into consideration. Continuous data protection approaches could be used for these files.

Backup to DASD Using BACKUP SYSTEM and DB2 Recovery Expert As a first step in this use case, a full backup to DASD is created. This step is very similar to taking a backup for a DB2 data sharing group, which was described in the previous chapter. For a detailed description on how to make a full backup of a data sharing group with DB2 Recovery Expert, see section System-Level Backup on DASD with RE.

Federated Recovery of Multiple DB2 Systems to the Same Point in Time If multiple SAP systems logically belong together and you need to perform a point in time recovery due to application errors, all related SAP systems would need to be recovered to ensure that the systems remain consistent. As it is often not an option to perform a PIT recovery in DB2 production systems - since this would mean that clean data is lost - a federated PIT recovery is typically performed in test or clone systems. Then, the recovered data in these systems can selectively be propagated to the DB2 production systems to fix the logically corrupted data in these systems and to keep the other clean data.

One approach that implicitly allows a federated point in time recovery is to consolidate all related SAP systems in the same database using MCOD.

If you do not run an MCOD configuration, you can still perform a federated point in time recovery if all DB2 subsystems run on the same Sysplex and you use DB2 9. DB2 9 introduces the clause ENDTIME for the DSNJU003 utility, which serves to specify the recovery target point of the RESTORE SYSTEM utility.

As the timestamp used for the DB2 log entries relies on the same Sysplex Timer or Server Time Protocol (STP), you can perform a federated recovery to any prior point in time after carrying out the following steps:

1. Specify the same timestamp for DSNJU003 on all affected DB2 subsystems, which do not need to be part of the same data sharing group. The timestamp is specified in GMT format. A sample control statement is as follows: CRESTART CREATE,SYSPITRT=2008179084800

2. Subsequently run RESTORE SYSTEM for each DB2 subsystem or data sharing group.



Cloning Based on Copy on DASD with DB2 Cloning Tool (SAP Doublestack System ABAP+Java) Cloning a DB2 data sharing group is fairly similar to cloning a DB2 subsystem. Therefore, the description in this section is not as detailed as in the earlier section that discusses cloning a data sharing group in detail. However, this use case assumes that an SAP doublestack system is served by the DB2 subsystem. This imposes some additional steps and considerations that are described in the next section.

Description of the Environment The environment is basically the same as in the previous test case. This time it is not a data sharing environment. The original data source is COBD2nn, the copied source from the backup system is COBFC2nn and the target is COBC2nn where ‘nn’ indicates a volume for the $LG or $DB copy pool.

We use user managed Flash Copy from COBF* to COBC* because Cloning Tool would take COBD* as the Source

Prepare DB2 for Cloning First, one must define the USERCAT & ALIAS for the new subsystem DSN91K

Job Example:

//CRTUCATA JOB (DE03557),CH,NOTIFY=&SYSUID, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M //*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //*



//*MODLOG DB2 D91K DEFINE USERCAT NEW DSN91K AND ALIAS //* //DEFUCAT EXEC PGM=IDCAMS //* //SYSPRINT DD SYSOUT=* //SYSIN DD * DEFINE - USERCATALOG( - ICFCATALOG - STORCLAS(SMS) - NAME(SYS1.USERCAT.DSN91K) - CYL(60 2) - ECSHR - ) DEFINE ALIAS (NAME(DSN91K) RELATE(SYS1.USERCAT.DSN91K)) //* //DEFUCA1 EXEC PGM=IDCAMS //* //SYSPRINT DD SYSOUT=* //SYSIN DD * DEFINE - USERCATALOG( - ICFCATALOG - STORCLAS(SMS) - NAME(SYS1.USERCAT.DSN91KL) - CYL(6 2) - ECSHR - ) DEFINE ALIAS (NAME(DSN91K.ARCHLOG1) RELATE(SYS1.USERCAT.DSN91KL)) DEFINE ALIAS (NAME(DSN91K.LOGCOPY1) RELATE(SYS1.USERCAT.DSN91KL)) DEFINE ALIAS (NAME(DSN91K.LOGCOPY2) RELATE(SYS1.USERCAT.DSN91KL)) DEFINE ALIAS (NAME(DSN91K.D91K) RELATE(SYS1.USERCAT.DSN91KL)) //*

CREATE new ZPARM Create a new DSNZPARM with DEFER YES and SPRMCTU SETC ‘I’. The name of the new ZPARM is DSNZSPEC.

RUN FlashCopy from COBF* to COBC* Flash Copy was run from Backup System (COBF*)

Job example:

//FCCOPYNB JOB (DE03557),CH,NOTIFY=&SYSUID, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M //*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //* //* DB2 FLASHCOPY //FLASHCOP EXEC PGM=ADRDSSU //SYSPRINT DD SYSOUT=X //SYSUDUMP DD SYSOUT=X,OUTLIM=3000



//SYSIN DD * PARALLEL COPY FULL INDYNAM (COBF21) OUTDYNAM (COBC21) DUMPCONDITIONING ADMIN - PURGE COPY FULL INDYNAM (COBF22) OUTDYNAM (COBC22) DUMPCONDITIONING ADMIN - PURGE COPY FULL INDYNAM (COBF23) OUTDYNAM (COBC23) DUMPCONDITIONING ADMIN - PURGE COPY FULL INDYNAM (COBF24) OUTDYNAM (COBC24) DUMPCONDITIONING ADMIN - PURGE COPY FULL INDYNAM (COBF25) OUTDYNAM (COBC25) DUMPCONDITIONING ADMIN - PURGE COPY FULL INDYNAM (COBF26) OUTDYNAM (COBC26) DUMPCONDITIONING ADMIN - PURGE COPY FULL INDYNAM (COBF27) OUTDYNAM (COBC27) DUMPCONDITIONING ADMIN - PURGE COPY FULL INDYNAM (COBF28) OUTDYNAM (COBC28) DUMPCONDITIONING ADMIN – PURGE COPY FULL INDYNAM (COBF2L) OUTDYNAM (COBC2L) DUMPCONDITIONING ADMIN - PURGE COPY FULL INDYNAM (COBF2M) OUTDYNAM (COBC2M) DUMPCONDITIONING ADMIN - PURGE //

If the job runs long then the relationship of the Backup System Job is still intact (Background I/Os taking place) and the Flash Copy Job cannot establish a new connection but drives I/Os instead. However, the result is still correct.

Verify correct Flash Copy Check number of datasets on each volume.

Cloning Tool jobs to be run FINDUCATS: This job identifies which ICF User catalogs point at data sets on the source volumes to be copied. The COPY step requires pairs of source/target user ICF catalogs to be specified. FINDUCATS does not negate this need. It is intended to be run prior to the initial setup -- and possibly on an occasional basis -- to make sure the user catalogs that should be specified for the COPY step have not changed.

CKZFUCAT for Source COBD2*

Changes to Sample Job CKZFUCAT: //CKZIN DD * FINDUCATS - FROM-STORAGEGROUP(DB2D2*) //* FROM-VOLSER(COBD1*)

Copy This COPY Job creates the Journal and captures catalog data.

COPY (CKZCOPY): the actual copy was done with Flash Copy using COBF* (Result from Backup System) as the source –> DATA-MOVER(PGM(NONE))

Changes to Sample Job CKZCOPY: //CKZCOPY JOB (DE03557),CH,NOTIFY=&SYSUID,



// MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M //*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //******************************************************************** //* COPYRIGHT 2001 - 2006 MAINSTAR SOFTWARE CORPORATION * //* ALL RIGHTS RESERVED * //******************************************************************** //S0 EXEC PGM=IDCAMS //SYSPRINT DD SYSOUT=* //SYSIN DD * DEL DB2TOOLS.D911.JRNL DEL DB2TOOLS.D911.WRK.UCATBKUP.* SET MAXCC=0 //S1 EXEC PGM=CKZ00010,REGION=8M //STEPLIB DD DISP=SHR,DSN=SYS1.DB2CT.V210.SCKZLOAD //CKZINI DD DISP=SHR, // DSN=DB2TOOLS.D911.SYS1.DB2CT.V210.SCKZPARM(CKZINI) //VOLPAIRS DD DSN=DB2TOOLS.VOLPAIRS.CNTL(D911K),DISP=SHR //CKZPRINT DD SYSOUT=* //SYSUDUMP DD SYSOUT=* //ABNLIGNR DD DUMMY DO NOT REMOVE IF USING ABENDAID //******************************************************************** //* C A U T I O N //* THE JOURNAL DATA SET MUST BE CATALOGED FOR SUBSEQUENT USE BY THE //* RENAME STEP AND OPTIONALLY THE COPYCHECK AND BCSCLEAN STEPS. //* A UNIQUE JOURNAL DATASET MUST BE USED FOR EACH DISTINCT //* DB2 CLONING TOOL PROCESS. //******************************************************************** //JOURNAL DD DSN=DB2TOOLS.D911.JRNL, // DISP=(,CATLG),UNIT=SYSALLDA, // RECORG=KS,KEYLEN=64,KEYOFF=0, // LRECL=600,SPACE=(CYL,(10,10)) //CKZIN DD * COPY - DATA-MOVER(PGM(NONE)) - VOLPAIRS-DDN(VOLPAIRS) - USERCATALOGS(SYS1.USERCAT.DSN911 SYS1.USERCAT.DSN91K - SYS1.USERCAT.DSN911L SYS1.USERCAT.DSN91KL) - CATWORK-DSN(DB2TOOLS.D911.WRK.* ) - JOURNAL-DDN(JOURNAL) //********************************************************************

VOLPAIRS This is a list of the VOLPAIRS dataset from the VOLPAIRS DD STATEMENT above:

EDIT DB2TOOLS.VOLPAIRS.CNTL(D911K) - 000001 COBD21 COBC21 000002 COBD22 COBC22 000003 COBD23 COBC23 000004 COBD24 COBC24 000005 COBD25 COBC25 000006 COBD26 COBC26 000007 COBD27 COBC27 000008 COBD28 COBC28



000009 COBD2L COBC2L 000010 COBD2M COBC2M

Output of changed Sample Job CKZCOPY: SYSPRINT S0 (part from job output)

********************************* TOP OF DATA ********************************** IDCAMS SYSTEM SERVICES TIME: 11:55:28 DEL DB2TOOLS.D911.JRNL IDC0550I ENTRY (D) DB2TOOLS.D911.JRNL.DATA DELETED IDC0550I ENTRY (I) DB2TOOLS.D911.JRNL.INDEX DELETED IDC0550I ENTRY (C) DB2TOOLS.D911.JRNL DELETED IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0 DEL DB2TOOLS.D911.WRK.UCATBKUP.* IDC0550I ENTRY (A) DB2TOOLS.D911.WRK.UCATBKUP.BKP00001 DELETED IDC0550I ENTRY (A) DB2TOOLS.D911.WRK.UCATBKUP.BKP00002 DELETED IDC0550I ENTRY (A) DB2TOOLS.D911.WRK.UCATBKUP.SRT00001 DELETED IDC0550I ENTRY (A) DB2TOOLS.D911.WRK.UCATBKUP.SRT00002 DELETED IDC0001I FUNCTION COMPLETED, HIGHEST CONDITION CODE WAS 0 SET MAXCC=0 IDC0002I IDCAMS PROCESSING COMPLETE. MAXIMUM CONDITION CODE WAS 0 ******************************** BOTTOM OF DATA ********************************

CKZPRINT S1 (part from job output)

CKZ02001I 11.55.29 COPY PROCESS STARTED - PROGRAM REV=57 CKZ02087I 10 VOLUME PAIRS FOR KEYWORD: VOLPAIRS-DDN COBD2L COBC2L COBD2M COBC2M COBD21 COBC21 COBD22 COBC22 COBD23 COBC23 COBD24 COBC24 COBD25 COBC25 COBD26 COBC26 COBD27 COBC27 COBD28 COBC28 CKZ02088I VOLUME SERIAL(S) TO BE USED FOR SOURCE COBD2L COBD2M COBD21 COBD22 COBD23 COBD24 COBD25 COBD26 COBD27 COBD28 TOTAL NUMBER: 10 CKZ02088I VOLUME SERIAL(S) TO BE USED FOR TARGET COBC2L COBC2M COBC21 COBC22 COBC23 COBC24 COBC25 COBC26 COBC27 COBC28 TOTAL NUMBER: 10 CKZ02085I DSNS FOR KEYWORD: USERCATALOGS SYS1.USERCAT.DSN911 SYS1.USERCAT.DSN91K SYS1.USERCAT.DSN911L SYS1.USERCAT.DSN91KL CKZ03501I 11.55.29 CHECK USERCATALOGS STARTED - PROGRAM REV=6



CKZ03501I 11.55.29 CHECK USERCATALOGS COMPLETED; RETURN CODE=0 CKZ03501I 11.55.29 CHECK USERCATALOGS STARTED - PROGRAM REV=6 CKZ03501I 11.55.29 CHECK USERCATALOGS COMPLETED; RETURN CODE=0 CKZ02089I TARGET VOLUMES WILL NOT BE CHECKED FOR EMPTY CKZ02048I OPTIONS IN EFFECT FOR THIS EXECUTION: CONCURRENT_EXECUTIONS: N CKZ02030I DSS LEVEL=X'03010900' CKZ02043I ANTRQST LEVEL=12; ESSRVCS LEVEL=104 CKZ02101I 11.55.30 VOLUME COPY STARTED - PROGRAM REV=45 CKZ02131I PRE-COPIED VOLUME PAIRS ACCEPTED: SOURCE TARGET COBD2L COBC2L COBD2M COBC2M COBD21 COBC21 COBD22 COBC22 COBD23 COBC23 COBD24 COBC24 COBD25 COBC25 COBD26 COBC26 COBD27 COBC27 COBD28 COBC28 CKZ02101I 11.55.30 VOLUME COPY COMPLETED; RETURN CODE=0 CKZ02201I 11.55.30 BCS BACKUP STARTED - PROGRAM REV=27 CKZ02241I BCS=SYS1.USERCAT.DSN911 WILL BE BACKED UP TO DSN=DB2TOOLS.D911.WRK.UCA CKZ02241I BCS=SYS1.USERCAT.DSN911L WILL BE BACKED UP TO DSN=DB2TOOLS.D911.WRK.UC CKZ02230I BCS BACKUP TASK COMPLETED; RETURN CODE=0 SYSOUT DD=BKP00001 CKZ02230I BCS BACKUP TASK COMPLETED; RETURN CODE=0 SYSOUT DD=BKP00002 CKZ02201I 11.55.32 BCS BACKUP COMPLETED; RETURN CODE=0 CKZ02001I 11.55.32 COPY PROCESS COMPLETED; RETURN CODE=0 CKZ01009I DB2 CLONING TOOL EXECUTION COMPLETE. HIGHEST RETURN CODE WAS 0 ******************************** BOTTOM OF DATA ********************************

BKP00001 S1 (part from job output)

********************************* TOP OF DATA ********************************** CKZ04001I 11.55.30 BCS BACKUP STARTED - PROGRAM REV=25 CKZ04003I DDNAME=SYS00010 ALLOCATED FOR DSN=DB2TOOLS.D911.WRK.UCATBKUP.BKP00001 CKZ04003I DDNAME=SYS00011 ALLOCATED FOR DSN=SYS1.USERCAT.DSN911 CKZ04033I IDCAMS VERIFY FOR BCS WAS SUCCESSFUL CKZ04034I IDCAMS EXAMINE INDEXTEST FOR BCS WAS SUCCESSFUL CKZ04035I NUMBER OF RECORDS READ FROM BCS: 69301 CKZ04036I NUMBER OF RECORDS WRITTEN TO BACKUP: 69301 CKZ04001I 11.55.31 BCS BACKUP COMPLETED; RETURN CODE=0 ******************************** BOTTOM OF DATA ********************************





BKP00002 S1 (part from job output)

********************************* TOP OF DATA ********************************** CKZ04001I 11.55.31 BCS BACKUP STARTED - PROGRAM REV=25 CKZ04003I DDNAME=SYS00013 ALLOCATED FOR DSN=DB2TOOLS.D911.WRK.UCATBKUP.BKP00002 CKZ04003I DDNAME=SYS00014 ALLOCATED FOR DSN=SYS1.USERCAT.DSN911L CKZ04033I IDCAMS VERIFY FOR BCS WAS SUCCESSFUL CKZ04034I IDCAMS EXAMINE INDEXTEST FOR BCS WAS SUCCESSFUL CKZ04035I NUMBER OF RECORDS READ FROM BCS: 32 CKZ04036I NUMBER OF RECORDS WRITTEN TO BACKUP: 32 CKZ04001I 11.55.31 BCS BACKUP COMPLETED; RETURN CODE=0 ******************************** BOTTOM OF DATA ********************************

RENAME Run RENAME

The following pair does not need to be included:

SYS1.DSN.D911.** SYS1.DSN.D91K.**

SYS1.DSN.D911.** is at another volume – new one for D91K gets rebuilt, so no mapping is necessary

Changes to Sample Job CKZREN: //CKZIN DD * RENAME - SAFE - VOLBKUP-DDN(VOLBKUP) - MAX-TASKS(5) - JOURNAL-DDN(JOURNAL) - RECATALOG(Y) - DATACLAS(SOURCE) - MGMTCLAS(SOURCE) - STORCLAS(SOURCE) - NOTRENAMED(DELETE,RC(0)) - RENAME-MASKS( DSN911.D911.** DSN91K.D91K.** - DSN911.** DSN91K.** - ) //**************************************************************

Note: Error Messages that might come up when volumes are missing in the VOLPAIR list



Error message 1

CKZ14030I BCS UPDATE FAILED ; RETURN CODE=8 SYSOUT DD=BCM00001 FOR TARGET BCS=SYS1.USERCAT.DSN91K CKZ14142E BCS ENTRY PARTIALLY ON SOURCE VOLUME SERIALS; BCS KEY DSN=DSN911.DSNDBC.A020XAAJ.PA0000.I0001.A001

Error message 2

CKZ14101I 15.21.48 BCS UPDATE STARTED - PROGRAM REV=43 ** SIMULATION ** CKZ14103I DDNAME=BCS00001 ALLOCATED FOR DSN=SYS1.USERCAT.DSN91K CKZ14103I DDNAME=SRT00001 ALLOCATED FOR DSN=DB2TOOLS.D911.WRK.UCATBKUP.SRT00001 CKZ14141I BCS ENTRY NOT ON SOURCE VOLUME SERIALS; BCS KEY=DSN911.DSNDBC.ADBDCH. CKZ14141I BCS ENTRY NOT ON SOURCE VOLUME SERIALS; BCS KEY=DSN911.DSNDBC.A000XAA CKZ14141I BCS ENTRY NOT ON SOURCE VOLUME SERIALS; BCS KEY=DSN911.DSNDBC.A000XAA CKZ14141I BCS ENTRY NOT ON SOURCE VOLUME SERIALS; BCS KEY=DSN911.DSNDBC.A000XAA CKZ14141I BCS ENTRY NOT ON SOURCE VOLUME SERIALS; BCS KEY=DSN911.DSNDBC.A000XAA CKZ14141I BCS ENTRY NOT ON SOURCE VOLUME SERIALS; BCS KEY=DSN911.DSNDBC.A000XAA CKZ14141I BCS ENTRY NOT ON SOURCE VOLUME SERIALS; BCS KEY=DSN911.DSNDBC.A000XAA CKZ14141I BCS ENTRY NOT ON SOURCE VOLUME SERIALS; BCS KEY=DSN911.DSNDBC.A000XAA CKZ14141I BCS ENTRY NOT ON SOURCE VOLUME SERIALS; BCS KEY=DSN911.DSNDBC.A000XAA . . . CKZ14103I DDNAME=BCS00002 ALLOCATED FOR DSN=SYS1.USERCAT.DSN91KL CKZ14103I DDNAME=SRT00002 ALLOCATED FOR DSN=DB2TOOLS.D911.WRK.UCATBKUP.SRT00002 CKZ14141I BCS ENTRY NOT ON SOURCE VOLUME SERIALS; BCS KEY=DSN911.ARCHLOG1.D0818 CKZ14141I BCS ENTRY NOT ON SOURCE VOLUME SERIALS; BCS KEY=DSN911.ARCHLOG1.D0818 CKZ14141I BCS ENTRY NOT ON SOURCE VOLUME SERIALS; BCS KEY=DSN911.ARCHLOG1.D0818 CKZ14141I BCS ENTRY NOT ON SOURCE VOLUME SERIALS; BCS KEY=DSN911.ARCHLOG1.D0818 CKZ14141I BCS ENTRY NOT ON SOURCE VOLUME SERIALS; BCS KEY=DSN911.ARCHLOG1.D0818 CKZ14141I BCS ENTRY NOT ON SOURCE VOLUME SERIALS; BCS KEY=DSN911.ARCHLOG1.D0818 CKZ14141I BCS ENTRY NOT ON SOURCE VOLUME SERIALS; BCS KEY=DSN911.ARCHLOG1.D0818 CKZ14141I BCS ENTRY NOT ON SOURCE VOLUME SERIALS; BCS KEY=DSN911.ARCHLOG1.D0818 CKZ14141I BCS ENTRY NOT ON SOURCE VOLUME SERIALS; BCS KEY=DSN911.ARCHLOG1.D0818 CKZ14141I BCS ENTRY NOT ON SOURCE VOLUME SERIALS; BCS KEY=DSN911.ARCHLOG1.D0818 CKZ14141I BCS ENTRY NOT ON SOURCE VOLUME SERIALS; BCS KEY=DSN911.ARCHLOG1.D0818

In this use case, the Archive Logs were not renamed. So the error messages concerning the ARCHLOG datasets are o.k. In general, it is possible however to rename Archive logs on DASD and in the BSDS with DB2 Cloning Tool.

DB2UPDATE Run DB2UPDATE

Changes to Sample Job CKZDUPD: //CKZIN DD * DB2UPDATE - DB2-HLQS(DSN911,DSN91K) - DDF(LOCATION(COBD91K) - PORT(5912) - RESPORT(5112) - LUNAME(IPXAA912) -



) - DB2-XCFCLEAN(Y) - JOURNAL-DDN(JOURNAL)

DB2START Run DB2START: Start Target DB2s in Maintenance Mode with changed ZPARMs DSNZSPEC ( DEFER YES & SPRMCTU SETC ‘I’)

Changes to Sample Job CKZDSTA:

//CKZIN DD * DB2START - DB2-SSID(D91K) - SPECIAL - DSNZPARM(DSNZSPEC) //*************************************************

The following appears if the start was successful:

CKZ25540I START COMMAND: -D91K START DB2 PARM(DSNZSPEC) ACCESS(MAINT) CKZ25538I WAITING FOR DB2 TO START CKZ25537I DB2 HAS STARTED CKZ25501I 12.07.47 DB2START COMPLETED; RETURN CODE=0

DB2FIX Run DB2FIX: Fix catalog and directory page spaces in LPL, GRECP status (Note: For Data sharing this might only run on the LPAR where the logs have been used at the time of the COPY)

Changes to Sample Job CKZDFIX: //CKZIN DD * DB2FIX - DB2-SSID(D91K) - DATABASES(DB2)

DB2SQL Run DB2SQL to update target DB2 catalog

Changes to Sample Job CKZDSQL: //CKZIN DD * DB2SQL - DB2-SSID(D91K) - LISTSQL(Y) - JOURNAL-DDN(JOURNAL)

DB2FIX Before DB2FIX is invoked, it should be ensure that the RENAME and DB2UPDATE steps were previously run without the SIMULATE keyword. Then DB2FIX can be run. It fixes application pages spaces in LPL and GRECP status.



Changes to Sample Job CKZDFIX: //CKZIN DD * DB2FIX - DB2-SSID(D91K) - DATABASES(APPLICATION)

DB2STOP Run DB2STOP to stop target in maintenance mode.

Changes to Sample Job CKZDSTO: //CKZIN DD * DB2STOP - DB2-SSID(D91K)

DB2START Run DB2START to start target normally

Changes to Sample Job CKZDSTA): //CKZIN DD * DB2START - DB2-SSID(D91K) - NORMAL

SAP Activities While and After Cloning

Activities While Cloning The source SAP system is an SAP ECC 6.00 SR2 ABAP + JAVA Unicode installation. We installed a central system as the application server with a DB2 Connect fat client for the database connection.

For the target database system, we initially installed a new SAP ERP 7.00 SR3 ABAP + Java Unicode application server from CD. We installed a central system as the application server with the DB2 Connect (THIN client) for the database connection. The DB2 schema names were not changed.

For the ABAP stack, it is possible to create a target system with the DB2 cloning method.

In contrast to the ABAP stack, the database content export for the Java stack can be done with database-specific methods. Additionally, an export/import for the Java Engine has to be executed from the SAP Installation Master CD to archive SDM and application-specific file system content.

For more information about the system copy, see SAP System Copy Guide for SAP NetWeaver 7.0 SR3.



The following are screens shots of the steps that we followed in the SAP installation tool:

Step 1:

We selected the following option on the SAP Installation Master CD to export the JAVA stack from the source system

Figure 24: SAPinst Option Selected for the Database Export (Java) Step 2:

After selecting the export option, we selected the database copy with database specific tools:

Figure 25: SAPinst Option for Using Database-Specific Tools

Note

With this selection combination (export plus the database specific tools method) SAPinst exports only the



elements for the Java stack

Figure 26: Database Export Phases Carried Out by SAPinst

Step 3:

We selected the following option from SAP Installation Master CD to install the SAP application server on the target system:

Figure 27: SAPinst Option Selected for Target System Installation



The following displays the phases involved in the target system installation:

Figure 28: Target System Installation Phases Carried Out by SAPinst



Activities after Cloning: After starting the target/cloned SAP application, there are several application definitions which have to be adapted in the new system. Some major follow-up activities and their SAP transactions are listed here:

• *Automatic Instance Entry and Operating system entry in table TSLE4 with first logon into cloned system

• *SICK – SAP Initial Consistency Check

• SLICENSE - Install an SAP license key for the cloned SAP system

• *DB02 – Tables and Indexes check

• *STMS - Update Transport Management System

• SM59 - Adapt or even delete RFC Destination / RFC Connections

• DB13 – Maintain weekly planning for database jobs (DBA Planning Calender)

• *RZ10 – Import and maintain SAP profiles

• SU01 and SUxx - Review the SAP UsersIDs and their authorities

• SM37 - Maintain the schedule of background jobs

• SPAD/SP12 – spool and printer administration

For more information on follow-up activities, see SAP System Copy Guide (Heterogeneous System Copy), section Follow-Up Activities.

The follow-up activities preceded by an asterisk (*) were used to check the cloned systems during the workshop:



Checking Cloned SAP System Consistency: Following the list of steps indicated above, we verified the consistency of the cloned system.

Step 1:

The instance was entered in TSLE4

Figure 29: TSLE4 Entry Confirmation Step 2:

We checked the SAP System Log (transaction SM21)



Figure 30: Transaction SM21 – System Log As displayed in the above figure, the ABAP Stack started fine. Errors in SAP System Log show that the CCMS definitions are not yet set up correctly.

Step 3:

The transaction SICK check was successful:

Figure 31: SAP Initial Consistency Check

Step 4:

We then defined the cloned SAP system D9K in STMS (Transport Management System) as a standalone SAP system:



Figure 32: Defining the Cloned System in STMS

Figure 33: Logging On to the Cloned System

Figure 34: System Overview – Cloned System



Step 5:

Transaction DB02 – DB Checks for missing unique indexes indicates that there is one table without a unique index:

Figure 35: DB02 Check – Cloned System

Step 6:

This check shows that the same index is missing in the source SAP system D91:

Figure 36: DB02 Check – Source System



Step 7:

Transaction DB02 – DB Checks for ABAP Dictionary <-> Database is successful, since the cloned and source systems are identical:

Figure 37: Transaction DB02 – Cloned System Check

Figure 38: Transaction DB02 – Source System Check



Step 8:

Transaction RZ10 shows that the import profiles were successful:

Figure 39: Transaction RZ10 - Successful

Step 9: We logged on to cloned SAP system from a Web browser and checked the system information:

Figure 40: Cloned SAP System Initial Screen



9. Tape Use Case The tape use case extends the previously described use cases by dumping backups from the copy pool backup storage groups to tape and restoring them from tape as part of the database recovery. When discussing database recovery based on backups on tape, both a DB2 system-level recovery using the RESTORE SYSTEM utility and a tablespace recovery using the RECOVER utility are covered. Moreover, a database backup that was dumped to tape is used as the source of DB2 cloning activities.

Backup to Tape Using BACKUP SYSTEM DUMP Option In this step, a full backup is taken with the dump option. Therefore, not only does DB2 create a backup on DASD in the copy pool backup storage group, it also dumps the backup to tape. The backup is dumped to the dumpclass DB2DUMP1, which was defined earlier. We recommend that you define a new dumpclass for the DB2 BACKUP SYSTEM and RESTORE SYSTEM processing. You can then tailor this dumpclass for the specific needs in this context, which is discussed in more details in section ‘Tape Definitions’.

//BACKS00A JOB (DE03557),CH,NOTIFY=BOEBLD1.DB2ADM3, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M /*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //************************************************************** //* STEP BACKUP: RUN BACKUP SYSTEM DATASHARING SN61 //************************************************************** //BACKUP EXEC DSNUPROC,SYSTEM=SN61, // UID='DB2ADM',LIB=SYS1.DSN.V910.SDSNLOAD //SYSIN DD * BACKUP SYSTEM FULL DUMP DUMPCLASS(DB2DUMP1)

/* The job log of this BACKUP SYSTEM processing is as follows:

10:02:08.05 DSNUGUTC - BACKUP SYSTEM FULL DUMP DUMPCLASS(DB2DUMP1) 10:02:09.66 DSNUVBBD - BACKUP SYSTEM UTILITY FOR DATA STARTING, COPYPOOL = DSN$COBDBN6$DB TOKEN = X'E2D5F6F1C29B19C5AA77820EC29B18BE8589'. 10:02:11.29 DSNUVBBD - BACKUP SYSTEM UTILITY FOR DATA COMPLETED SUCCESSFULLY, COPYPOOL = DSN$COBDBN6$DB TOKEN = X'E2D5F6F1C29B19C5AA77820EC29B18BE8589' ELAPSED TIME = 00:00:01. 10:02:11.29 DSNUVBBD - BACKUP SYSTEM UTILITY FOR LOGS STARTING, COPYPOOL = DSN$COBDBN6$LG TOKEN = X'E2D5F6F1C29B19C5AA77820EC29B18BE8589'. 10:02:12.21 DSNUVBBD - BACKUP SYSTEM UTILITY FOR LOGS COMPLETED SUCCESSFULLY, COPYPOOL = DSN$COBDBN6$LG TOKEN = X'E2D5F6F1C29B19C5AA77820EC29B18BE8589' ELAPSED TIME = 00:00:00. 10:05:21.67 DSNUVBBD - BACKUP SYSTEM UTILITY COMPLETED, ELAPSED TIME = 00:03:12. 10:05:22.16 DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=0

The dump process is indicated in the HSM started task log as follows:

The following messages in the HSM started task log indicates a situation in which volume COBD1L has successfully been dumped to tape. Subsequently, the next full volume dump for volume COBD1M is starting.



ARC0637I DUMP COPY OF VOLUME COBD1L COMPLETE, DCLASS=DB2DUMP1, EXPDT=2008/07/02 ARC0623I FULL VOLUME DUMP OF VOLUME COBD1L ENDING AT 10:09:08, PROCESSING ARC0623I (CONT.) SUCCESSFUL ARC0622I FULL VOLUME DUMP STARTING ON VOLUME COBD1M(SMS) AT 10:09:08 ON ARC0622I (CONT.) 2008/06/27, SYSTEM COB1, TASK ID=ARCDVOL2 , TO DUMP CLASS(ES)= ARC0622I (CONT.) DB2DUMP1

At this stage, the HSM LIST COPYPOOL for the DB2 data copy pool returns the following output. A partial dump state is indicated, which means that the backup has not completely been dumped to tape yet.

COPYPOOL=DSN$COBDBN6$DB VERSION VTOCENQ DATE TIME FASTREPLICATIONSTATE DUMPSTATE 019 N 2008/06/27 10:02:09 RECOVERABLE PARTIAL TOKEN(C)=C'SN61Bº.E¡Ïb.Bº.Žei' TOKEN(H)=X'E2D5F6F1C29B19C5AA77820EC29B18BE8589' TOTAL NUM OF VOLUMES=00006,INCREMENTAL=N SGNAME SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET DB2D1 COBD11 - COBF11 COBD12 - COBF12 COBD13 - COBF13 COBD14 - COBF14 DB2D1 COBD15 - COBF15 COBD16 - COBF16

Some minutes later, when all the volumes have successfully been dumped to tape, the same HSM LIST COPYPOOL command returns the following information. The timestamp specified in the TIME column does not change as this timestamp reflects the creation time of the backup.

COPYPOOL=DSN$COBDBN6$DB VERSION VTOCENQ DATE TIME FASTREPLICATIONSTATE DUMPSTATE 019 N 2008/06/27 10:02:09 RECOVERABLE ALLCOMPLETE TOKEN(C)=C'SN61Bº.E¡Ïb.Bº.Žei' TOKEN(H)=X'E2D5F6F1C29B19C5AA77820EC29B18BE8589' TOTAL NUM OF VOLUMES=00006,INCREMENTAL=N

Backup to Tape Using BACKUP SYSTEM DUMPONLY Option DB2 also supports dumping backups to tape that were previously created by BACKUP SYSTEM and initially not dumped to tape. Let us consider the following case in which first BACKUP SYSTEM FULL was invoked without the DUMP option. The messages in the HSM started task (JESMSGLG) list this backup as follows:

ARC1801I FAST REPLICATION BACKUP IS STARTING FOR COPY ARC1801I (CONT.) POOL DSN$COBD911$DB, AT 08:37:00 ON 2008/08/20, ARC1801I (CONT.) TOKEN=X'C4F9F1F1C2DEEB74040BFAD9007014C76E39' ARC1805I THE FOLLOWING 00008 VOLUME(S) WERE ARC1805I (CONT.) SUCCESSFULLY PROCESSED BY FAST REPLICATION BACKUP OF ARC1805I (CONT.) COPY POOL DSN$COBD911$DB ARC1805I (CONT.) COBD21 ARC1805I (CONT.) COBD22 ARC1805I (CONT.) COBD23 ARC1805I (CONT.) COBD24 ARC1805I (CONT.) COBD25 ARC1805I (CONT.) COBD26 ARC1805I (CONT.) COBD27 ARC1805I (CONT.) COBD28 ARC1802I FAST REPLICATION BACKUP HAS COMPLETED FOR ARC1802I (CONT.) COPY POOL DSN$COBD911$DB, AT 08:37:04 ON 2008/08/20, ARC1802I (CONT.) FUNCTION RC=0000, MAXIMUM VOLUME RC=0000



ARC1801I FAST REPLICATION BACKUP IS STARTING FOR COPY ARC1801I (CONT.) POOL DSN$COBD911$LG, AT 08:37:04 ON 2008/08/20, ARC1801I (CONT.) TOKEN=X'C4F9F1F1C2DEEB74040BFAD9007014C76E39' ARC1805I THE FOLLOWING 00002 VOLUME(S) WERE ARC1805I (CONT.) SUCCESSFULLY PROCESSED BY FAST REPLICATION BACKUP OF ARC1805I (CONT.) COPY POOL DSN$COBD911$LG ARC1805I (CONT.) COBD2L ARC1805I (CONT.) COBD2M ARC1802I FAST REPLICATION BACKUP HAS COMPLETED FOR ARC1802I (CONT.) COPY POOL DSN$COBD911$LG, AT 08:37:05 ON 2008/08/20, ARC1802I (CONT.) FUNCTION RC=0000, MAXIMUM VOLUME RC=0000

The LIST COPYPOOL command shows that the backups for the DB2 data and log copy pools only reside on DASD and not on dump as the dump state is NONE:

COPYPOOL=DSN$COBD911$DB VERSION VTOCENQ DATE TIME FASTREPLICATIONSTATE DUMPSTATE 021 N 2008/08/20 08:37:00 RECOVERABLE NONE TOKEN(C)=C'D911B ³R G> ' TOKEN(H)=X'C4F9F1F1C2DEEB74040BFAD9007014C76E39' TOTAL NUM OF VOLUMES=00008,INCREMENTAL=N SGNAME SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET DB2D2 COBD21 - COBF21 COBD22 - COBF22 COBD23 - COBF23 COBD24 - COBF24 DB2D2 COBD25 - COBF25 COBD26 - COBF26 COBD27 - COBF27 COBD28 - COBF28 COPYPOOL=DSN$COBD911$LG VERSION VTOCENQ DATE TIME FASTREPLICATIONSTATE DUMPSTATE 020 N 2008/08/20 08:37:04 RECOVERABLE NONE TOKEN(C)=C'D911B ³R G> ' TOKEN(H)=X'C4F9F1F1C2DEEB74040BFAD9007014C76E39' TOTAL NUM OF VOLUMES=00002,INCREMENTAL=N SGNAME SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET DB2D2L COBD2L - COBF2L DB2D2M COBD2M - COBF2M

Next, the BACKUP SYSTEM utility is invoked to dump this backup to tape. This is accomplished by submitting the following job:

//BACKN17A JOB (DE03557),CH,NOTIFY=BOEBLD1.DB2ADM1, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M /*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //* //************************************************************** //* STEP BACKUP: RUN BACKUP SYSTEM DATASHARING SN61 //************************************************************** //* BACKUP EXEC DSNUPROC,SYSTEM=SN61, //BACKUP EXEC DSNUPROC,SYSTEM=D911, // UID='DB2ADM',LIB=SYS1.DSN.V910.SDSNLOAD //DSNUPROC.SYSIN DD * BACKUP SYSTEM FULL DUMPONLY DUMPCLASS(DB2DUMP1) /*



The job output of this BACKUP SYSTEM DUMPONLY invocation is as follows. A token number is not assigned to the DUMPONLY copy, because it is not a new recovery point, but a dump of an existing recovery on DASD. The HSM logging of the DASD backup is updated to indicate it has been dumped to tape. So, the new tape dump inherits the token of the DASD backup.

15:14:19.55 DSNUGUTC - OUTPUT START FOR UTILITY, UTILID = DB2ADM 15:14:19.62 DSNUGTIS - PROCESSING SYSIN AS EBCDIC 15:14:19.62 DSNUGUTC - BACKUP SYSTEM FULL DUMPONLY DUMPCLASS(DB2DUMP1) 15:14:19.63 DSNUVBBD - BACKUP SYSTEM UTILITY FOR DATA STARTING, COPYPOOL = DSN$COBD911$DB TOKEN = X'000000000000000000000000000000000000'. 15:14:19.64 DSNUVBBD - BACKUP SYSTEM UTILITY FOR DATA COMPLETED SUCCESSFULLY, COPYPOOL = DSN$COBD911$DB TOKEN = X'000000000000000000000000000000000000' ELAPSED TIME = 00:00:00. 15:14:19.64 DSNUVBBD - BACKUP SYSTEM UTILITY FOR LOGS STARTING, COPYPOOL = DSN$COBD911$LG TOKEN = X'000000000000000000000000000000000000'. 15:14:19.64 DSNUVBBD - BACKUP SYSTEM UTILITY FOR LOGS COMPLETED SUCCESSFULLY, COPYPOOL = DSN$COBD911$LG TOKEN = X'000000000000000000000000000000000000' ELAPSED TIME = 00:00:00. 15:14:19.64 DSNUVBBD - BACKUP SYSTEM UTILITY COMPLETED, ELAPSED TIME = 00:00:00. 15:14:19.64 DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=0

The dump process is indicated in the HSM started task log as follows:

ARC1801I FAST REPLICATION DUMPONLY IS STARTING FOR 813 ARC1801I (CONT.) COPY POOL DSN$COBD911$DB, AT 15:14:19 ON 2008/08/20 ARC1801I FAST REPLICATION DUMPONLY IS STARTING FOR 821 ARC1801I (CONT.) COPY POOL DSN$COBD911$LG, AT 15:14:19 ON 2008/08/20 ARC0622I FULL VOLUME DUMP STARTING ON VOLUME 822 ARC0622I (CONT.) COBD2L(SMS) AT 15:14:19 ON 2008/08/20, SYSTEM COB1, ARC0622I (CONT.) TASK ID=ARCDVOL2 , TO DUMP CLASS(ES)= DB2DUMP1 ARC0622I FULL VOLUME DUMP STARTING ON VOLUME 823 ARC0622I (CONT.) COBD21(SMS) AT 15:14:19 ON 2008/08/20, SYSTEM COB1, ARC0622I (CONT.) TASK ID=ARCDVOL1 , TO DUMP CLASS(ES)= DB2DUMP1 ARC0353I TAPE VOLUME COB012 SUCCESSFULLY ADDED TO 824 ARC0353I (CONT.) DFSMSHSM'S RACF TAPE VOLUME SET IEC501A M 1A51,COB011,SL,COMP,HSM,HSM,HSMCOB.DMP.DB2DUMP1.VCOBD2L.D08233.T043708 IEC501A M 1A50,COB012,SL,COMP,HSM,HSM,HSMCOB.DMP.DB2DUMP1.VCOBD21.D08233.T003708

The last two messages indicate that a tape mount is requested. After the mount requests are satisfied, the following messages are displayed:

IEC705I TAPE ON 1A51,COB011,SL,COMP,HSM,HSM,HSMCOB.DMP.DB2DUMP1.VCOBD2L.D08233.T ADR734I (001)-T0MI (03), 2008.233 15:19:04 CONCURRENT COPY 834 INITIALIZATION SUCCESSFUL FOR VOLUME COBF2L. SERIALIZATION FOR THIS DATA IS RELEASED IF DFSMSDSS HELD IT. THE INTERMEDIATE RETURN CODE IS 0000. IEC705I TAPE ON 1A50,COB012,SL,COMP,HSM,HSM,HSMCOB.DMP.DB2DUMP1.VCOBD21.D08233.T ADR734I (001)-T0MI (03), 2008.233 15:19:24 CONCURRENT COPY 836 INITIALIZATION SUCCESSFUL FOR VOLUME COBF21. SERIALIZATION FOR THIS DATA IS RELEASED IF DFSMSDSS HELD IT. THE INTERMEDIATE RETURN CODE IS 0000.



After the dump has started, in this scenario LIST COPYPOOL reports partial dump state for the backup of the data copy pool and complete dump state for the log copy pool. Also, it indicates the token number that was initially assigned to the backup by BACKUP SYSTEM FULL:

COPYPOOL=DSN$COBD911$DB VERSION VTOCENQ DATE TIME FASTREPLICATIONSTATE DUMPSTATE 021 N 2008/08/20 08:37:00 RECOVERABLE PARTIAL TOKEN(C)=C'D911B ³R G> ' TOKEN(H)=X'C4F9F1F1C2DEEB74040BFAD9007014C76E39' TOTAL NUM OF VOLUMES=00008,INCREMENTAL=N SGNAME SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET DB2D2 COBD21 - COBF21 COBD22 - COBF22 COBD23 - COBF23 COBD24 - COBF24 DB2D2 COBD25 - COBF25 COBD26 - COBF26 COBD27 - COBF27 COBD28 - COBF28

COPYPOOL=DSN$COBD911$LG VERSION VTOCENQ DATE TIME FASTREPLICATIONSTATE DUMPSTATE 020 N 2008/08/20 08:37:04 RECOVERABLE ALLCOMPLETE TOKEN(C)=C'D911B ³R G> ' TOKEN(H)=X'C4F9F1F1C2DEEB74040BFAD9007014C76E39' TOTAL NUM OF VOLUMES=00002,INCREMENTAL=N SGNAME SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET DB2D2L COBD2L - COBF2L DB2D2M COBD2M - COBF2M

When the dump is complete, the dump state changes to ALLCOMPLETE for both data and log copy pool:

COPYPOOL=DSN$COBD911$DB VERSION VTOCENQ DATE TIME FASTREPLICATIONSTATE DUMPSTATE 021 N 2008/08/20 08:37:00 RECOVERABLE ALLCOMPLETE TOKEN(C)=C'D911B ³R G> ' TOKEN(H)=X'C4F9F1F1C2DEEB74040BFAD9007014C76E39' TOTAL NUM OF VOLUMES=00008,INCREMENTAL=N SGNAME SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET DB2D2 COBD21 - COBF21 COBD22 - COBF22 COBD23 - COBF23 COBD24 - COBF24 DB2D2 COBD25 - COBF25 COBD26 - COBF26 COBD27 - COBF27 COBD28 - COBF28

COPYPOOL=DSN$COBD911$LG VERSION VTOCENQ DATE TIME FASTREPLICATIONSTATE DUMPSTATE 020 N 2008/08/20 08:37:04 RECOVERABLE ALLCOMPLETE TOKEN(C)=C'D911B ³R G> ' TOKEN(H)=X'C4F9F1F1C2DEEB74040BFAD9007014C76E39' TOTAL NUM OF VOLUMES=00002,INCREMENTAL=N SGNAME SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET DB2D2L COBD2L - COBF2L DB2D2M COBD2M - COBF2M



RESTORE SYSTEM with Backup on Tape: PIT Recovery Specifying SYSPITRT The Restore System utility is used to perform a point-in-time recovery (PITR). After the log truncation point is established in the BSDS, Restore System restores the appropriate copy of the DSN$location_name$DB copy pool and applies log records to bring the DB2 system up to the log truncation point.

The CRESTART statement of the Change Log Inventory program, DSNJU003, is used to establish the log truncation point. The SYSPITR option is used when providing a RBA or a LRSN for the log truncation point, and SYSPITRT is used when providing a date and time of day as the log truncation point. The time is based on GMT and not local time. If the DB2 system to be restored is a data sharing system, then the log truncation point must be established in each member’s BSDSs.

In this PITR test, a three member DB2 data sharing group was used; SN61, SN62 and SN63.

Recommendation

If DB2 data sharing has been enabled, and some of the members are passive and used as secondary members in support of data base server failover, it is important to run an ARCHIVE LOG SCOPE(GROUP) prior to bringing the DB2 group down for recovery. This is to ensure all of the DB2 members have had current LRSNs written out, and the recover-to-time won’t be limited by members with low to no activity. This is also true when using date and time as the log truncation point.

HSM List Copy Pool Command Prior to performing any type of recovery that uses the Backup System copies maintained by HSM, a HSM command can be used to determine which backups HSM has registered and whether or not they are usable for a recovery. In this case, the restore is being done using a tape dump of a Backup System utility copy.


//CPYLST8D JOB (DE03557),CH,NOTIFY=BOEBLD1.DB2ADM1, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M /*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //* //************************************************** //* LIST COPYPOOL //************************************************** //* //STEP1 EXEC PGM=IKJEFT01 //SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSIN DD * HSEND LIST COPYPOOL(DSN$COBDBN6$DB) /*

Sample HSM List Copy Pool Job Output: The Restore System utility uses the following HSM copy to perform the restore from dump of the DSN$loction_name$DB copy pool.

-- DFSMShsm CONTROL DATASET --COPY POOL--LISTING --------- AT 10:16:07



COPYPOOL=DSN$COBDBN6$DB VERSION VTOCENQ DATE TIME FASTREPLICATIONSTATE DUMPSTATE 019 N 2008/06/27 10:02:09 RECOVERABLE ALLCOMPLETE TOKEN(C)=C'SN61Bº E¡Ïb Bº ´ei' TOKEN(H)=X'E2D5F6F1C29B19C5AA77820EC29B18BE8589' TOTAL NUM OF VOLUMES=00006,INCREMENTAL=N

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. DFDSS support suggests setting up DASDVOL in the following way to bypass the problem without giving an undue level of access to all datasets. Any id that has the OPERATIONS attribute will inherit DASDVOL authority.

The following RACF commands should be issued:

SETROPTS GENERIC(DASDVOL)

REDEFINE DASDVOL * UACC(ALTER)

SETROPTS CLASSACT(DASDVOL)

SETROPTS GENERIC(DASDVOL) REFRESH

If there are still authorization problems, it is recommended to open an IBM problem ticket to get instructions from support center.

Steps for Performing a PITRT 1. Once it has been determined that a point-in-time recovery needs to take place, execute the ARCHIVE



3. It is recommended as a best practice to have processes for backing up the DSN$location_name$LG copy pool and being able to restore it back to its current status. This provides a way back to the status of the system prior to any recovery actions. If the log truncation point is not where the system needs to return, the DSN$location_name$LG can be restored and a new log truncation point can be established. For more information, see section Backing up the $LG Copy Pool Prior to System Level Recovery.

4. Working with the business owners, or end-users, determine the date and time for which the system must be returned. Remember the time used in the conditional restart is GMT time and not local time. It is necessary to compute the GMT time that represents the local time for which the system must be returned.

In this test, it was determined that the system needed to go back to the local time of 10:48:00. The test system is 2 hours ahead of GMT, so the GMT time specified is 08:48:00.

5. Run the DSNJU003 program and establish a point-in-time recovery based on date and time using a date and time format in the conditional restart control card, as well as using the new parameter SYSPITRT. Do this for all members of the data sharing group.

CRESTART CREATE,SYSPITRT=YYYYJJJHHMMSS

CRESTART CREATE,SYSPITRT=2008179084800



Sample Change Log Inventory Job Using SYSPITRT: //CONDS11C JOB (DE#03557),'NATIVE',NOTIFY=&SYSUID, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M //* //CRCR01B EXEC PGM=DSNJU003,REGION=016M,COND=(4,LT) //STEPLIB DD DISP=SHR,DSN=SYS1.DSN.SN61.SDSNEXIT // DD DISP=SHR,DSN=SYS1.DSN.V910.SDSNLOAD //SYSPRINT DD SYSOUT=* //SYSUT1 DD DISP=SHR,DSN=DBN6.SN61.BSDS01 //SYSUT2 DD DISP=SHR,DSN=DBN6.SN61.BSDS02 //SYSIN DD * CRESTART CREATE,SYSPITRT=2008179084800 /* //CRCR02B EXEC PGM=DSNJU003,REGION=016M,COND=(4,LT) //STEPLIB DD DISP=SHR,DSN=SYS1.DSN.SN62.SDSNEXIT // DD DISP=SHR,DSN=SYS1.DSN.V910.SDSNLOAD //SYSPRINT DD SYSOUT=* //SYSUT1 DD DISP=SHR,DSN=DBN6.SN62.BSDS01 //SYSUT2 DD DISP=SHR,DSN=DBN6.SN62.BSDS02 //SYSIN DD * CRESTART CREATE,SYSPITRT=2008179084800 /* //CRCR03B EXEC PGM=DSNJU003,REGION=016M,COND=(4,LT) //STEPLIB DD DISP=SHR,DSN=SYS1.DSN.SN63.SDSNEXIT // DD DISP=SHR,DSN=SYS1.DSN.V910.SDSNLOAD //SYSPRINT DD SYSOUT=* //SYSUT1 DD DISP=SHR,DSN=DBN6.SN63.BSDS01 //SYSUT2 DD DISP=SHR,DSN=DBN6.SN63.BSDS02 //SYSIN DD * CRESTART CREATE,SYSPITRT=2008179084800 /*

As can be seen in Figure 41, the ENDTIME is the date-time provided and the truncation LRSN is C29B24049700. In Figure 42, the approximate GMT time is found on the checkpoint queue. We can see that the END CHECKPOINT LRSN of C29B23EBB0E5 is close to the truncation LRSN being used. This is a good way to validate the truncation point established in the conditional restart.

If it has been determined that the DB2 system was not taken back to the point-in-time desired by the customer, and there is a need to redo the PITR, see section Changing the Log Truncation in the BSDS.



Figure 41: Screen print of the Conditional Restart Control card of member SN61 after the DSNJU003 job had been run for all three members.



Figure 42: Checkpoint queue for SN61 showing the approximate GMT time and LRSN for the checkpoint. This helps to validate the truncation time being used in the conditional restart.





7. Restart all DB2 members for this data sharing group. The start of each member causes an outstanding reply to be written to SYSLOG asking if you are sure about the conditional restart and the truncation point. In this test there were three DB2 members, therefore there were also outstanding replies from the start of the first two members asking for the start of another member. This outstanding reply will be addressed when the remaining members are started.

DSNR050I -SN61 DSNRRPRC DB2 STARTED IN SYSTEM RECOVER PENDING MODE



DSNR002I -SN61 RESTART COMPLETED DSNY014I -SN61 DSNYSTRT DB2 WAS STARTED WITH ACCESS(MAINT) DSN9022I -SN61 DSNYASCP 'START DB2' NORMAL COMPLETION DSNR050I -SN62 DSNRRPRC DB2 STARTED IN SYSTEM RECOVER PENDING MODE DSNR002I -SN62 RESTART COMPLETED DSNY014I -SN62 DSNYSTRT DB2 WAS STARTED WITH ACCESS(MAINT) DSN9022I -SN62 DSNYASCP 'START DB2' NORMAL COMPLETION DSNR050I -SN63 DSNRRPRC DB2 STARTED IN SYSTEM RECOVER PENDING MODE DSNR002I -SN63 RESTART COMPLETED DSNY014I -SN63 DSNYSTRT DB2 WAS STARTED WITH ACCESS(MAINT) DSN9022I -SN63 DSNYASCP 'START DB2' NORMAL COMPLETION

As seen in the messages above, all three members were started in ‘RECOVER PENDING MODE’ and ‘ACCESS(MAINT)’. The only thing that can connect to any of these DB2 members when they are started in this status is the Restore System utility. If it has been determined that the DB2 system was not taken back to the point-in-time desired by the customer, and there is a need to redo the PITR, see section Changing the Log Truncation in the BSDS.

8. If this is a DB2 data sharing group, bring down all but one member. Only one member needs to be up to run the Restore System utility, and all members need to be stopped and restarted after the PITR is complete. You need to stop and start all members to bring them up in normal mode and allow normal usage of all DB2 members.

9. Prior to running the Restore System utility, it is necessary to deallocate the ICF catalog(s) that are in the DSN$location_name$DB copy pool. Note that during a PITR, the DSN$location_name$LG copy pool is not restored. The BSDS and active logs remain as they were at the time the DB2 members were brought down in order to perform the PITR. The ICF catalogs are deallocated using the MODIFY command. It is necessary to deallocate the ICF catalog(s) in all LPARs in the parallel sysplex.


10. If there are any program products with a started task running that have allocated data sets in the DSN$location_name$DB copy pool, shut them down or the restore them to the volume with the allocated data set(s) fail.

11. Submit the Restore System utility job on the LPAR with the running DB2 member. The Restore System utility will restore the volumes in the DSN$location_name$DB copy pool and perform the log apply to bring the data in the DB2 data base up to the truncated log point.



Sample Restore System From Dump Utility Job //RESTS04D JOB (DE03557),CH,NOTIFY=BOEBLD1.DB2ADM1, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M /*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //* //************************************************************** //* STEP BACKUP: RUN BACKUP SYSTEM DATASHARING SN61 //************************************************************** //RESTORE EXEC DSNUPROC,SYSTEM=SN61, // UID='DB2ADM',LIB=SYS1.DSN.V910.SDSNLOAD //DSNUPROC.SYSIN DD * RESTORE SYSTEM FROMDUMP /*

12. As displayed in the messages of the Restore System job, there is a mount request.

IRR010I USERID DB2ADM1 IS ASSIGNED TO THIS JOB. ICH70001I DB2ADM1 LAST ACCESS AT 17:57:29 ON FRIDAY, JUNE 27, 2008 $HASP373 RESTS04D STARTED - INIT 1 - CLASS A - SYS COB1 IEF403I RESTS04D - STARTED - TIME=18.07.55 IEF233D M 1A51,COB006,,RESTS04D,DSNUPROC, 385 HSMCOB.DMP.DB2DUMP1.VCOBD11.D08179.T090210, OR RESPOND TO IEF455D MESSAGE *60 IEF455D MOUNT COB006 ON 1A51 FOR RESTS04D DSNUPROC OR REPLY 'NO'

After the tape volume has been mounted, there are IEC and ICK messages indicating which volumes are being restored:

IEC604I VTOC CONVERT ROUTINE ENTERED ON 2411,COBD11,DOS,DEVMAN ICK502I BUILDIX FUNCTION STARTED ICK503I 2411 REQUEST RECEIVED TO CONVERT VTOC TO IXFORMAT ICK504I 2411 VTOC FORMAT IS CURRENTLY OSFORMAT, REQUEST ACCEPTED ICK513I 2411 BUILDIX PROCESSING COMPLETED: VTOC IS NOW IN IXFORMAT IEC604I VTOC CONVERT ROUTINE ENTERED ON 2412,COBD12,DOS,DEVMAN ICK502I BUILDIX FUNCTION STARTED ICK503I 2412 REQUEST RECEIVED TO CONVERT VTOC TO IXFORMAT ICK504I 2412 VTOC FORMAT IS CURRENTLY OSFORMAT, REQUEST ACCEPTED ICK513I 2412 BUILDIX PROCESSING COMPLETED: VTOC IS NOW IN IXFORMAT IEC604I VTOC CONVERT ROUTINE ENTERED ON 2413,COBD13,DOS,DEVMAN ICK502I BUILDIX FUNCTION STARTED ICK503I 2413 REQUEST RECEIVED TO CONVERT VTOC TO IXFORMAT ICK504I 2413 VTOC FORMAT IS CURRENTLY OSFORMAT, REQUEST ACCEPTED ICK513I 2413 BUILDIX PROCESSING COMPLETED: VTOC IS NOW IN IXFORMAT . .



Sample Restore System Utility Job Output Messages ADR013I (002)-CLTSK(01), 2008.179 18:35:11 TASK COMPLETED WITH RETURN CODE 0000 ADR012I (SCH)-DSSU (01), 2008.179 18:35:11 DFSMSDSS PROCESSING COMPLETE. HIGHEST RETURN CODE IS 0000 DSNU422I 179 18:35:11.64 DSNUVBRD - END OF DFSMS MESSAGE DSNU1627I 179 18:35:11.64 DSNUVBRD - RESTORE SYSTEM PRE-LOG APPLY COMPLETED SUCCESSFULLY, COPYPOOL = DSN$COBDBN6$DB TOKEN = X'E2D5F6F1C29B19C5AA77820EC29B18BE8589' ELAPSED TIME = 00:27:15. DSNU1604I -SN61 179 18:35:11.79 DSNUVARL - RESTORE SYSTEM PHASE LOG APPLY STARTED AT LOG POINT = X'C29B18BE8589'. DSNU1635I -SN61 179 18:36:51.88 DSNUVARL - THE RBA RANGE FOR THE LAST CHECKPOINT ISSUED DURING THE LOGAPPLY PHASE OF THE RESTORE SYSTEM UTILITY IS START_RBA = X'C29B8C71CD83' END_RBA = X'C29B8CD10135' FOR MEMBER SN61 DSNU1628I 179 18:36:51.88 DSNUVBRD - RESTORE SYSTEM PHASE LOG APPLY COMPLETED, ELAPSED TIME = 00:01:40. DSNU010I 179 18:36:51.90 DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=0

Sample Restore System Utility Job Output Messages of Failed Restore

If the Restore System utility can not restore all of the volumes in the DSN$location_name$DB copy pool, then the restore system job will end with a RC = 8 and the log apply phase is not executed. The Restore System job output messages below indicate a failure in the restore being performed by HSM. The messages also indicate the restore processing is ending at the volume that could not be restored. That means volumes following the failed restore volume are not restored. Also, the log apply phase did not run.

JOBNAME STEPNAME PROCSTEP RC RESTS10D RESTORE DSNUPROC 08 ADR306E (002)-SBRTN(01), UNABLE TO RESTORE THE VOLUME BECAUSE OUTPUT VOLUME COBD14 IS IN USE. TASK IS TERMINATED ADR006I (002)-STEND(02), 2008.190 12:25:06 EXECUTION ENDS ADR013I (002)-CLTSK(01), 2008.190 12:25:06 TASK COMPLETED WITH RETURN CODE 0008 ADR012I (SCH)-DSSU (01), 2008.190 12:25:06 DFSMSDSS PROCESSING COMPLETE. HIGHEST RETURN CODE IS 0008 FROM: TASK 002 DSNU422I 190 12:25:06.12 DSNUVBRD - END OF DFSMS MESSAGE DSNU012I 190 12:25:06.13 DSNUGBAC - UTILITY EXECUTION TERMINATED, HIGHEST RETURN CODE=8

For more information about restoring individual volumes, see section Restoring Individual Volumes.

13. After the restore of the DSN$location_name$DB and the log apply have completed successfully, issue the following commands to ensure all DB2 objects are in a normal status.


14. Once it is clear that all DB2 objects are in a normal status, bring down the running DB2 member and restart all members in the group.If you have determined that the DB2 system was not taken back to the point-in-time desired by the customer, and that there is a need to redo the PITR, see section Changing the Log Truncation in the BSDS.



Recommendation

Once it has been determined that the system has been returned to the point-in-time that was needed, run a new Backup System utility to ensure a new recovery point.

Recovering individual tablespace using RECOVER utility with system-level backup on tape This test case is similar to recovering a single tablespace using a system-level backup on DASD. The major difference is to add the FROMDUMP keyword for the RECOVER utility. This forces DB2 to perform a single object recovery based on a system-level backup on tape. If the FROMDUMP keyword is not specified, DB2 exclusively considers backup on DASD. The job log is as follows:

Recovery to Point in Time of Backup on Tape Using DFSMSdss Sometimes there is a need to ‘baseline’ the data in the DB2 data base. In other words, it is necessary to restore the system back to the state that it was in at the time the Backup System utility copy was obtained. This means that both the DSN$location_name$DB and the DSN$location_name$LG copy pools are restored. In this case, the Restore System utility is not used. Also, DFSMShsm has a single task for recovering from a dump tape which means DFSMShsm FRRECOV is only used at the volume level and not the system level. So, when performing a recovery from tape to the point-in-time of the backup, native DFSMSdss restore commands are used. There is no log apply phase. Once the restore of these two copy pools are complete, the DB2 system is started through normal start procedures and go through normal DB2 restart processing.

Messages from SYSLOG: The Backup System utility job, which created the tape dump, does wait for dump processing to complete and therefore does not include any DFSMShsm messages in its output in regards to the tape dump data sets being created. The information needed to create the DFSMSdss restore job can be obtained from IEC205I messages written to the system log. From these messages, the data set names and file sequence of the volume dumps can be obtained.

IEC205I SYS00693,HSM,HSM,FILESEQ=1, COMPLETE VOLUME LIST, DSN=HSMCOB.DMP.DB2DUMP1.VCOBD11.D08242.T232314,VOLS=COB006

DSNU050I 190 18:00:26.90 DSNUGUTC - RECOVER TABLESPACE A201X994.XSAP TOLOGPOINT X'C2A955EE1E18' FROMDUMP DSNU185I -SN61 190 18:00:27.19 DSNUGSRI - THE VSAM DATA SET DOES NOT EXIST FOR INDEXSPACE A201X994.SWNRCOLS DSNU185I -SN61 190 18:00:27.19 DSNUGSRI - THE VSAM DATA SET DOES NOT EXIST FOR INDEXSPACE A201X994.SWNRDELS .... .... DSNU1520I 190 18:00:28.61 DSNUCBRT - THE RECOVERY BASE FOR TABLESPACE A201X994.XSAP IS THE SYSTEM LEVEL BACKUP WITH DATE = 20080708, TIME 172903, AND TOKEN X'E2D5F6F1C2A9522969AEAFD9C2A9514E5176' DSNU1527I 190 18:09:28.19 DSNUCBRT - TABLESPACE A201X994.XSAP WAS SUCCESSFULLY RESTORED FROM A DUMP COPY, ELAPSED TIME=00:08:59 DSNU831I -SN61 190 18:00:28.60 DSNUCARS - ALL INDEXES OF A201X994.XSAP ARE IN REBUILD PENDING DSNU578I -SN61 190 18:09:28.28 DSNUCALA - SYSLGRNX INFORMATION FOR MEMBER SN63 DSNU513I -SN61 190 18:09:28.28 DSNUCALA - RECOVER UTILITY LOG APPLY RANGE IS RBA 000000000000 LRSN C2A9514E5176 TO RBA 0018309EDC4E LRSN C2A955670659 DSNU1510I 190 18:09:28.36 DSNUCBLA - LOG APPLY PHASE COMPLETE, ELAPSED TIME = 00:00:00 DSNU500I 190 18:09:28.82 DSNUCBDR - RECOVERY COMPLETE, ELAPSED TIME=00:09:01

DSNU010I 190 18:09:28.83 DSNUGBAC - UTILITY EXECUTION COMPLETE, HIGHEST RETURN CODE=4



IEC205I SYS00693,HSM,HSM,FILESEQ=2, COMPLETE VOLUME LIST, DSN=HSMCOB.DMP.DB2DUMP1.VCOBD12.D08242.T232314,VOLS=COB006 IEC205I SYS00693,HSM,HSM,FILESEQ=3, COMPLETE VOLUME LIST, DSN=HSMCOB.DMP.DB2DUMP1.VCOBD13.D08242.T232314,VOLS=COB006 IEC205I SYS00693,HSM,HSM,FILESEQ=4, COMPLETE VOLUME LIST, DSN=HSMCOB.DMP.DB2DUMP1.VCOBD14.D08242.T232314,VOLS=COB006 IEC205I SYS00693,HSM,HSM,FILESEQ=5, COMPLETE VOLUME LIST, DSN=HSMCOB.DMP.DB2DUMP1.VCOBD15.D08242.T232314,VOLS=COB006 IEC205I SYS00693,HSM,HSM,FILESEQ=6, COMPLETE VOLUME LIST, DSN=HSMCOB.DMP.DB2DUMP1.VCOBD16.D08242.T232314,VOLS=COB006

RACF Authorization Required When restoring the DSN$location_name$DB or the DSN$location_name$LG copy pools, 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. DFDSS support suggests setting up DASDVOL in the following way to bypass the problem without giving an undue level of access to all datasets. Any id that has the OPERATIONS attribute will inherit DASDVOL authority.

The following RACF commands should be issued:

SETROPTS GENERIC(DASDVOL)

REDEFINE DASDVOL * UACC(ALTER)

SETROPTS CLASSACT(DASDVOL)

SETROPTS GENERIC(DASDVOL) REFRESH

A second option to providing the appropriate RACF authorization to avoid the ICF catalog from becoming re-allocated during the restore is to use the ADMIN keyword on the RESTORE statement. The userid of the DFSMSdss Restore job must have read access to the applicable RACF FACILITY-class profile in order to avoid the access checking to the data sets and ICF catalog.

The restore control card must include the ADMIN keyword in order to avoid the access checking to the data sets and ICF catalog, causing the re-allocation of the ICF catalog and the volume restore to fail.

//SYSIN DD * RESTORE INDDNAME(TAPE1) OUTDDNAME(DASD1) PURGE ADMIN RESTORE INDDNAME(TAPE2) OUTDDNAME(DASD2) PURGE ADMIN RESTORE INDDNAME(TAPE3) OUTDDNAME(DASD3) PURGE ADMIN RESTORE INDDNAME(TAPE4) OUTDDNAME(DASD4) PURGE ADMIN RESTORE INDDNAME(TAPE5) OUTDDNAME(DASD5) PURGE ADMIN RESTORE INDDNAME(TAPE6) OUTDDNAME(DASD6) PURGE ADMIN /*

ADMINISTRATOR Keyword To act as a DFSMSdss-authorized storage administrator, specify the ADMINISTRATOR keyword on the appropriate DFSMSdss command. If you are not authorized to use the ADMINISTRATOR keyword, the command is ended with an error message. Otherwise, access checking to data sets and catalogs is bypassed.

To use the ADMINISTRATOR keyword, all of the following must be true:

• FACILITY class is active

• Applicable FACILITY-class profile is defined

• You have READ access to that profile



Steps for Performing a System Level Recovery to Point in Time of Backup: 1. Bring SAP and DB2 system or members down.

2. Prior to running the DFSMSdss job, it is necessary to deallocate the ICF catalog(s) in the DSN$location_name$DB and the DSN$location_name$LG copy pools. In this recovery, the BSDSs and active logs, as well as all of the data objects, are restored back to the way they looked at the time the Backup System copy was obtained. The ICF catalogs are deallocated using the MODIFY command. It is necessary to deallocate the ICF catalog(s) in all LPARs in the parallel sysplex.

RO *ALL,F CATALOG,UNALLOCATE(SYS1.USERCAT.DBN6) IEE421I RO *ALL,F CATALOG,UNALLO SYSNAME RESPONSES --------------------------------------------------- COB1 IEC351I CATALOG ADDRESS SPACE MODIFY COMMAND ACTIVE IEC352I CATALOG ADDRESS SPACE MODIFY COMMAND COMPLETED COB2 IEC351I CATALOG ADDRESS SPACE MODIFY COMMAND ACTIVE IEC352I CATALOG ADDRESS SPACE MODIFY COMMAND COMPLETED COB3 IEC351I CATALOG ADDRESS SPACE MODIFY COMMAND ACTIVE IEC352I CATALOG ADDRESS SPACE MODIFY COMMAND COMPLETED RO *ALL,F CATALOG,UNALLOCATE(SYS1.USERCAT.DBN6L) IEE421I RO *ALL,F CATALOG,UNALLO SYSNAME RESPONSES --------------------------------------------------- COB1 IEC351I CATALOG ADDRESS SPACE MODIFY COMMAND ACTIVE IEC352I CATALOG ADDRESS SPACE MODIFY COMMAND COMPLETED COB2 IEC351I CATALOG ADDRESS SPACE MODIFY COMMAND ACTIVE IEC352I CATALOG ADDRESS SPACE MODIFY COMMAND COMPLETED COB3 IEC351I CATALOG ADDRESS SPACE MODIFY COMMAND ACTIVE IEC352I CATALOG ADDRESS SPACE MODIFY COMMAND COMPLETED

3. If there are any program products with a started task running that have allocated data sets in the DSN$location_name$DB or the DSN$location_name$LG copy pools, you must shut them down or the restore to the volume with the allocated data set(s) will fail.

4. Submit the DFSMSdss job.

Sample DFSMSdss Restore Job //RESTAPS2 JOB (DE03557),CH,NOTIFY=BOEBLD1.DB2ADM1, // MSGCLASS=X,MSGLEVEL=(1,1), // TIME=120,CLASS=A,REGION=0M TYPRUN=SCAN /*ROUTE XEQ BOECOB1 /*JOBPARM SYSAFF=COB1 //* //STEP1 EXEC PGM=ADRDSSU //SYSPRINT DD SYSOUT=* //TAPE1 DD UNIT=T3592RZ,VOL=SER=COB006, // LABEL=(1,SL),DISP=(OLD,KEEP), // DSN=HSMCOB.DMP.DB2DUMP1.VCOBD11.D08242.T232314 //DASD1 DD UNIT=3390,VOL=SER=COBD11,DISP=OLD //TAPE2 DD UNIT=AFF=TAPE1,VOL=SER=COB006, // LABEL=(2,SL),DISP=(OLD,KEEP), // DSN=HSMCOB.DMP.DB2DUMP1.VCOBD12.D08242.T232314 //DASD2 DD UNIT=3390,VOL=SER=COBD12,DISP=OLD //TAPE3 DD UNIT=AFF=TAPE2,VOL=SER=COB006, // LABEL=(3,SL),DISP=(OLD,KEEP), // DSN=HSMCOB.DMP.DB2DUMP1.VCOBD13.D08242.T232314



//DASD3 DD UNIT=3390,VOL=SER=COBD13,DISP=OLD //TAPE4 DD UNIT=AFF=TAPE3,VOL=SER=COB006, // LABEL=(4,SL),DISP=(OLD,KEEP), // DSN=HSMCOB.DMP.DB2DUMP1.VCOBD14.D08242.T232314 //DASD4 DD UNIT=3390,VOL=SER=COBD14,DISP=OLD //TAPE5 DD UNIT=AFF=TAPE4,VOL=SER=COB006, // LABEL=(5,SL),DISP=(OLD,KEEP), // DSN=HSMCOB.DMP.DB2DUMP1.VCOBD15.D08242.T232314 //DASD5 DD UNIT=3390,VOL=SER=COBD15,DISP=OLD //TAPE6 DD UNIT=AFF=TAPE5,VOL=SER=COB006, // LABEL=(6,SL),DISP=(OLD,KEEP), // DSN=HSMCOB.DMP.DB2DUMP1.VCOBD16.D08242.T232314 //DASD6 DD UNIT=3390,VOL=SER=COBD16,DISP=OLD //SYSIN DD * RESTORE INDDNAME(TAPE1) OUTDDNAME(DASD1) PURGE ADMIN RESTORE INDDNAME(TAPE2) OUTDDNAME(DASD2) PURGE ADMIN RESTORE INDDNAME(TAPE3) OUTDDNAME(DASD3) PURGE ADMIN RESTORE INDDNAME(TAPE4) OUTDDNAME(DASD4) PURGE ADMIN RESTORE INDDNAME(TAPE5) OUTDDNAME(DASD5) PURGE ADMIN RESTORE INDDNAME(TAPE6) OUTDDNAME(DASD6) PURGE ADMIN /*

Sample DFSMSdss Job Output Messages PAGE 0001 5695-DF175 DFSMSDSS V1R09.0 DATA SET SERVICES 2008.247 16:19 - RESTORE INDDNAME(TAPE1) OUTDDNAME(DASD1) PURGE ADMIN ADR101I (R/I)-RI01 (01), TASKID 001 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' RESTORE INDDNAME(TAPE2) OUTDDNAME(DASD2) PURGE ADMIN ADR101I (R/I)-RI01 (01), TASKID 002 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' RESTORE INDDNAME(TAPE3) OUTDDNAME(DASD3) PURGE ADMIN ADR101I (R/I)-RI01 (01), TASKID 003 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' RESTORE INDDNAME(TAPE4) OUTDDNAME(DASD4) PURGE ADMIN ADR101I (R/I)-RI01 (01), TASKID 004 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' RESTORE INDDNAME(TAPE5) OUTDDNAME(DASD5) PURGE ADMIN ADR101I (R/I)-RI01 (01), TASKID 005 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' RESTORE INDDNAME(TAPE6) OUTDDNAME(DASD6) PURGE ADMIN ADR101I (R/I)-RI01 (01), TASKID 006 HAS BEEN ASSIGNED TO COMMAND 'RESTORE ' ADR109I (R/I)-RI01 (01), 2008.247 16:19:30 INITIAL SCAN OF USER CONTROL STATEMENTS COMPLETED ADR016I (001)-PRIME(01), RACF LOGGING OPTION IN EFFECT FOR THIS TASK ADR006I (001)-STEND(01), 2008.247 16:19:30 EXECUTION BEGINS ADR780I (001)-TDFP (01), THE INPUT DUMP DATA SET BEING PROCESSED IS IN FULL VOLUME FORMAT AND WAS CREATED BY DFSMSDSS VERSION 1 RELEASE 9 MODIFICATION LEVEL 0 ADR808I (001)-TDFP (01), THE INPUT DUMP DATA SET BEING PROCESSED WAS CREATED FROM A CONDITIONED VOLUME ADR866I (001)-SB213(01), UNABLE TO RENAME VTOC INDEX ON VOLUME COBD11 DIAGNOSTIC INFORMATION: 040E0033 ADR006I (001)-STEND(02), 2008.247 16:33:40 EXECUTION ENDS ADR013I (001)-CLTSK(01), 2008.247 16:33:40 TASK COMPLETED WITH RETURN CODE 0000

Sample DFSMSdss Restore Job Output Messages of Failed Restore As displayed in the DFSMSdss Restore job messages below, not all of the volumes are successfully restored. For more information about restoring individual volumes, see section Restoring Individual Volumes.



*IEF233A M 1A50,COB012,,RESTAPE2,STEP7, HSMCOB.DMP.DB2DUMP1.VCOBD27.D08186.T364909 IEF234E K 1A50,COB012,PVT,RESTAPE2,STEP7 -JOBNAME STEPNAME PROCSTEP RC -RESTAPE2 STEP7 08 . . . UNABLE TO RESTORE THE VOLUME BECAUSE OUTPUT VOLUME COBD27 IS IN USE. TASK IS TERMINATED 2008.190 12:28:16 EXECUTION ENDS 2008.190 12:28:16 TASK COMPLETED WITH RETURN CODE 0008

5. After successfuly restoring DSN$location_name$DB and the DSN$location_name$LG, the DB2 system or members are ready to be restarted.

However, before starting any of the DB2 members, all of the XCF structures for this DB2 data sharing group must be deallocated. This is done by issuing a SETXCF FORCE command. Typically, if all of the DB2 members were shutdown normally and did not come down hard, the only two structures needing deallocation are the LOCK1 and SCA structures.




6. Restart all DB2 members for this data sharing group in ACCESS(MAINT). The copy that was restored is a ‘crash’ consistent copy, so all of the DB2 members will go through normal restart processes that are executed when DB2 abends.

7. After all of the DB2 members have restarted, issue the following commands to ensure all DB2 objects

are in a normal status. -ssid DISPLAY DATABASE(DSNDB01) SPACENAM(*) RESTRICT -ssid DISPLAY DATABASE(DSNDB06) SPACENAM(*) RESTRICT -ssid DISPLAY DATABASE(*) SPACENAM(*) RESTRICT

8. Once it is clear that all DB2 objects are in a normal status, bring down and restart all members in the group in normal access mode.

Recommendation

Once it has been determined that the system has been returned to the point-in-time that was needed, run a new Backup System utility to ensure a new recovery point.



Cloning Based on Copy on Tape with DB2 Cloning Tool This step creates a clone of a DB2 system based on a backup of the DB2 source system that resides on tape. The following description assumes that DB2 Recovery Expert is used to create a system-level backup and internally invokes the BACKUP SYSTEM. However, this description also applies if you directly use BACKUP SYSTEM to get a backup of the DB2 source system and dump the backup to tape.

Description of the Environment In this step, a backup to tape with Recovery Expert was taken and used as a source for DB2 subsystem cloning with DB2 cloning tool.

The user ID DB2ADM1 is connected to RACF group DATMGT. This group has read access to RACF class FACILITY for the profile STGADMIN.**. Alternatively, to avoid the entire DATMGT group having this powerful privilege, this privilege could have been also assigned directly to the user ID DB2ADM1.

Recovery Expert Backup to DASD Inclusive Tape Dump We created a backup to DASD with Recovery Expert (RE) including a tape dump of DBN6. • RE profile “SN61 DB2 BACKUP SYSTEM” was used. For more information on Recovery Expert profiles

see the corresponding chapter. • RE creates the job with the syntax:

Step 1 creates the Backup to DASD: //ARYIN DD * BACKUP DB2ADM4."SN61 DB2 BACKUP SYSTEM"

Step 2 creates the backup to tape: //ARYIN DD *

OFFLOAD DB2ADM4."SN61 DB2 BACKUP SYSTEM" GENERATION LAST-BACKUP

In parallel we ran the DB2 Cloning Tool COPY job to create the journals and capture the catalog data.

COPY (Sample Job CKZCOPY) After Recovery Expert finished the backup to DASD and before inserting the tape for the tape dump, the job COPY job was submitted with the option DATA-MOVER(PGM(NONE)) because the data movement was done outside of DB2 Cloning Tool.

Changes to Sample Job CKZCOPY: //CKZIN DD * COPY - DATA-MOVER(PGM(NONE)) - VOLPAIRS-DDN(VOLPAIRS) - USERCATALOGS(SYS1.USERCAT.DBN6 SYS1.USERCAT.DBNC - SYS1.USERCAT.DBN6L SYS1.USERCAT.DBNCL) - CATWORK-DSN(DB2ADM4.DBN6.WRK.* ) - JOURNAL-DDN(JOURNAL)

Upon successful completion of the COPY job, we inserted the first tape and RE continued with the tape dump. Tape volumes COB006 and COB007 were created successfully:

• Tape COB006 contains the $DB data. • Tape COB007 contains the $LG data.

We reused the cloning target DBNC.



The following are the steps that we carried out:

1. Bring the DBN6 and DBNC data sharing groups down

2. Vary the Original Volumes offline for both the DBN6 and the DBNC data sharing groups.

– COBD1L and COBD1M for the logging

– COBD11 through COBD16 for the data

– COBC1L and COBC1M for the logging

– COBC11 through COBC16 for the data

Figure 43: Offline Vary of the Systems

3. Create New Volumes for the current DBN6 data sharing system.

• COBD1L and COBD1M for the logging

• COBD11 through COBD16 for the data

Figure 44: Creation of New Volumes for DBN6

Run the DFDSS Restore Jobs • One restore job for $LG

• One restore job for $DB

These jobs use tape volumes COB006 and COB007.

• Created tape dump of DBN6



Figure 45: Restoring Jobs on DBN6 from Tape As shown in the following sample jobs, we put the restore of volume with the ICF data at the end in order to avoid previously experienced restore failures:

Job example for the restore from tape with the $LG: /RESTAPS1 JOB (DE03557),CH,NOTIFY=BOEBLD1.DB2ADM1, / MSGCLASS=X,MSGLEVEL=(1,1), / TIME=120,CLASS=A,REGION=0M TYPRUN=SCAN *ROUTE XEQ BOECOB1 *JOBPARM SYSAFF=COB1 /* /STEP1 EXEC PGM=ADRDSSU /SYSPRINT DD SYSOUT=* /TAPE1 DD UNIT=T3592RZ,VOL=SER=COB007, / LABEL=(2,SL),DISP=(OLD,KEEP), / DSN=HSMCOB.DMP.DB2DUMP1.VCOBD1M.D08242.T242314 /DASD1 DD UNIT=3390,VOL=SER=COBD1M,DISP=OLD /TAPE2 DD UNIT=AFF=TAPE1,VOL=SER=COB007, / LABEL=(1,SL),DISP=(OLD,KEEP), / DSN=HSMCOB.DMP.DB2DUMP1.VCOBD1L.D08242.T242314 /DASD2 DD UNIT=3390,VOL=SER=COBD1L,DISP=OLD /SYSIN DD * RESTORE INDDNAME(TAPE1) OUTDDNAME(DASD1) PURGE ADMIN RESTORE INDDNAME(TAPE2) OUTDDNAME(DASD2) PURGE ADMIN

*

Job example for the restore from tape with the $DB: /RESTAPS2 JOB (DE03557),CH,NOTIFY=BOEBLD1.DB2ADM1, / MSGCLASS=X,MSGLEVEL=(1,1), / TIME=120,CLASS=A,REGION=0M TYPRUN=SCAN *ROUTE XEQ BOECOB1 *JOBPARM SYSAFF=COB1 /* /STEP1 EXEC PGM=ADRDSSU /SYSPRINT DD SYSOUT=* /TAPE1 DD UNIT=T3592RZ,VOL=SER=COB006, / LABEL=(1,SL),DISP=(OLD,KEEP),



/ DSN=HSMCOB.DMP.DB2DUMP1.VCOBD11.D08242.T232314 /DASD1 DD UNIT=3390,VOL=SER=COBD11,DISP=OLD /TAPE2 DD UNIT=AFF=TAPE1,VOL=SER=COB006, / LABEL=(2,SL),DISP=(OLD,KEEP), / DSN=HSMCOB.DMP.DB2DUMP1.VCOBD12.D08242.T232314 /DASD2 DD UNIT=3390,VOL=SER=COBD12,DISP=OLD /TAPE3 DD UNIT=AFF=TAPE2,VOL=SER=COB006, / LABEL=(3,SL),DISP=(OLD,KEEP), / DSN=HSMCOB.DMP.DB2DUMP1.VCOBD13.D08242.T232314 /DASD3 DD UNIT=3390,VOL=SER=COBD13,DISP=OLD /TAPE4 DD UNIT=AFF=TAPE3,VOL=SER=COB006, / LABEL=(4,SL),DISP=(OLD,KEEP), / DSN=HSMCOB.DMP.DB2DUMP1.VCOBD14.D08242.T232314 /DASD4 DD UNIT=3390,VOL=SER=COBD14,DISP=OLD /TAPE5 DD UNIT=AFF=TAPE4,VOL=SER=COB006, / LABEL=(5,SL),DISP=(OLD,KEEP), / DSN=HSMCOB.DMP.DB2DUMP1.VCOBD15.D08242.T232314 /DASD5 DD UNIT=3390,VOL=SER=COBD15,DISP=OLD /TAPE6 DD UNIT=AFF=TAPE5,VOL=SER=COB006, / LABEL=(6,SL),DISP=(OLD,KEEP), / DSN=HSMCOB.DMP.DB2DUMP1.VCOBD16.D08242.T232314 /DASD6 DD UNIT=3390,VOL=SER=COBD16,DISP=OLD /SYSIN DD * RESTORE INDDNAME(TAPE1) OUTDDNAME(DASD1) PURGE ADMIN RESTORE INDDNAME(TAPE2) OUTDDNAME(DASD2) PURGE ADMIN RESTORE INDDNAME(TAPE3) OUTDDNAME(DASD3) PURGE ADMIN RESTORE INDDNAME(TAPE4) OUTDDNAME(DASD4) PURGE ADMIN RESTORE INDDNAME(TAPE5) OUTDDNAME(DASD5) PURGE ADMIN RESTORE INDDNAME(TAPE6) OUTDDNAME(DASD6) PURGE ADMIN * /

Re-clip New Volumes to Change the Volsers from COBDxx to COBCxx VOLOPTION CLIP: Clips the online source volumes to the target volumes. VOLOPTIONS is intended for situations where the DB2 Cloning Tool COPY step is run at one site (SITEA) and the DB2 Cloning Tool RENAME step is run at another site (SITEB). VOLOPTIONS LIST, CLIP, and UPDATE are intended to support such scenarios.

Changes to Sample Job CKZVOLOP: //CKZIN DD * VOLOPTIONS CLIP - JOURNAL-DDN(JOURNAL)

Vary the Original Volumes for DBN6 Online • COBD1L, COBD1M, COBD11 – COBD16

Start DBN6 Data Sharing Group and SAP N61 Now, the DBN6 data sharing group can be restarted and SAP N61 can be started.



Figure 46: Restarting DBN6 and Starting SAP N61

Run All of the Cloning Jobs for the DBNC Data Sharing Group Those jobs are identical to the ones we used for cloning from DASD. Once those are complete, the DBNC data sharing group can be restarted. You can also start the SAP system using this data sharing group.The Original Volumes for the DBNC group are still offline.

Figure 47: Running Cloning Jobs for the DBNC Data Sharing Group

RENAME Run RENAME. This step renames and catalogs target volume data sets. The SAFE option, a keyword of the RENAME command, is recommended to rerun the RENAME step to correct problems caused by mistakes such as incorrectly specified rename masks. Note that you can run the job with SIMULATE before you do the actual rename.

Changes to Sample Job CKZREN: First Run with SIMULATE option, then without.

//CKZIN DD * RENAME - SIMULATE - SAFE - VOLBKUP-DDN(VOLBKUP) - MAX-TASKS(5) - JOURNAL-DDN(JOURNAL) - RECATALOG(Y) -



DATACLAS(SOURCE) - MGMTCLAS(SOURCE) - STORCLAS(SOURCE) - NOTRENAMED(DELETE,RC(0)) - RENAME-MASKS( - SYS1.DSN.SN61.** SYS1.DSN.SNC1.** - SYS1.DSN.SN62.** SYS1.DSN.SNC2.** - SYS1.DSN.SN63.** SYS1.DSN.SNC3.** - DBN6.SN61.** DBNC.SNC1.** - DBN6.SN62.** DBNC.SNC2.** - DBN6.SN63.** DBNC.SNC3.** - DBN6.** DBNC.** - )



DB2UPDATE Update first Target DB2 Member: complete update

Changes to Sample Job CKZDUPD:

First Run with SIMULATE, then without.

//BSDS01 DD DISP=OLD,DSN=DBNC.SNC1.BSDS01 //BSDS02 DD DISP=OLD,DSN=DBNC.SNC1.BSDS02 //DBD01 DD DISP=OLD, // DSN=DBNC.DSNDBC.DSNDB01.DBD01.I0001.A001 //CKZIN DD * DB2UPDATE - SIMULATE - DB2-HLQS(DBN6,DBNC) - DB2-GROUP(DBN6,DBNC) - DB2-MEMBERS(SN61,SNC1 - SN62,SNC2 - SN63,SNC3) - DDF(LOCATION(COBDBNC) - PORT(5120) - RESPORT(5121) - LUNAME(IPXAANC1) - ) - DB2-XCFCLEAN(Y) - JOURNAL-DDN(JOURNAL)

Update 2nd Member: update BSDS only

Changes to Sample Job CKZDUPD2 (for 2nd Member):

//BSDS01 DD DISP=OLD,DSN=DBNC.SNC2.BSDS01 //BSDS02 DD DISP=OLD,DSN=DBNC.SNC2.BSDS02 //CKZIN DD * DB2UPDATE - BSDSONLY - DB2-HLQS(DBN6,DBNC) - DB2-GROUP(DBN6,DBNC) - DB2-MEMBERS(SN61,SNC1 - SN62,SNC2 - SN63,SNC3) - DDF(LOCATION(COBDBNC) - PORT(5120) - RESPORT(5122) - LUNAME(IPXABNC2) - ) - JOURNAL-DDN(JOURNAL) //

Update 3rd Member



Sample Job: (CKZDUPD2) update BSDS only, as with Member 2

Check Result with BSDSPRINT

Job Example:

********************************* Top of Data ************** /BSDSS11A JOB (DE03557),CH,NOTIFY=&SYSUID, / MSGCLASS=X,MSGLEVEL=(1,1), / TIME=120,CLASS=A,REGION=0M *ROUTE XEQ BOECOB1 *JOBPARM SYSAFF=COB1 /* /********************************************************* /* JOB DESCRIPTION /********************************************************* /* /*********************************************************** /SN61GRP4 EXEC PGM=DSNJU004 /STEPLIB DD DSN=SYS1.DSN.SN61.SDSNEXIT,DISP=SHR / DD DSN=SYS1.DSN.V910.SDSNLOAD,DISP=SHR /SYSPRINT DD SYSOUT=* /GROUP DD DSN=DBN6.SN61.BSDS01,DISP=SHR /SYSIN DD * MEMBER * * / ******************************** Bottom of Data ************

DB2START Start Target DB2s in Maintenance Mode (Sample Jobs CKZDSTA 1/2/3) with changed ZPARMs ( DEFER YES & SPRMCTU SETC ‘I’) Start each Member in it’s own LPAR COB1/2/3 -> different jobs

Changes to Sample Job CKZDSTA for 1st Member: //CKZIN DD * DB2START - DB2-SSID(SNC1) - SPECIAL - DSNZPARM(DSNZSPEC)

Changes to Sample Job CKZDSTA for 2nd Member: //CKZIN DD * DB2START - DB2-SSID(SNC2) - SPECIAL - DSNZPARM(DSNZSPEC) //

Changes to Sample Job CKZDSTA for 3rd Member: //CKZIN DD *



DB2START - DB2-SSID(SNC3) - SPECIAL - DSNZPARM(DSNZSPEC) //

Run DB2FIX Fix catalog and directory page spaces in LPL, GRECP status

(Note: This might only run on the LPAR where the logs have been used at the time of the COPY)

The first run of DB2FIX failed as we had experienced before. The reason for the failure was that DSNDB01 was restricted. Therefore, some changes might have been applied to regress our previous changes.

Changes to Sample Job CKSFIXD: //CKZIN DD * DB2START DB2-SSID(SNC2) SPECIAL DSNZPARM(DSNZSPEC)

Output of changed Sample Job CKSFIXD: CKZ23538I 15.43.45 PAGE SPACE(S) FIXED; DATABASE(DSNDB06 ) SPACENAM(* ) CKZ23526W DSNDB01.DBD01 IS IN RESTRICTED STATUS; DB2UPDATE NEEDS TO BE RUN AGAIN CKZ23501I 15.43.45 DB2FIX COMPLETED; RETURN CODE=16

We had to STOP DB2 and to rerun the DB2UPDATE (first Job) with DBD01ONLY Parameter again. Then Start DB2 in Maintenace mode again with special ZPARM and an extra DB2FIX catalog.

Stop DB2 members Job example for 1st member:

//CKZIN DD * DB2STOP - DB2-SSID(SNC1)

The other DB2 members have been stopped the same way.

Rerun DB2UPDATE Rerun DB2UPDATE with DBD01ONLY (first Run with SIMULATE, then without)

Changes to Sample Job CKZDUPD2: //BSDS01 DD DISP=OLD,DSN=DBNC.SNC1.BSDS01 //BSDS02 DD DISP=OLD,DSN=DBNC.SNC1.BSDS02 //DBD01 DD DISP=OLD, // DSN=DBNC.DSNDBC.DSNDB01.DBD01.I0001.A001 //CKZIN DD * DB2UPDATE - SIMULATE - DBD01ONLY - DB2-HLQS(DBN6,DBNC) -



DB2-GROUP(DBN6,DBNC) - DB2-MEMBERS(SN61,SNC1 - SN62,SNC2 - SN63,SNC3) - DDF(LOCATION(COBDBNC) - PORT(5120) - RESPORT(5121) - LUNAME(IPXAANC1) - ) - DB2-XCFCLEAN(Y) - JOURNAL-DDN(JOURNAL) //

New Successful DB2FIX Changes to Sample Job CKSFIXD:

//CKZIN DD * DB2FIX - DB2-SSID(SNC1) - DATABASES(DB2)



DB2SQL (CKZDSQL): Update Target DB2 Catalog Changes to Sample Job CKZDSQL: (First Run with SIMULATE, then without)

//CKZIN DD * DB2SQL - SIMULATE - DB2-SSID(SNC1) - LISTSQL(Y) - JOURNAL-DDN(JOURNAL)

Run DB2FIX (CKZDFIX ): (Fix application pages spaces in LPL, GRECP status) Changes to Sample Job CKZDFIX

(First Run with SIMULATE, then without)

//CKZIN DD * DB2FIX - DB2-SSID(SNC1) - DATABASES(APPLICATION)

DB2STOP (CKZDSTO ): Run DB2STOP – (Stop target in maint. mode) Changes to Sample Job CKZDSTO for 1st DB2 Member:

/CKZIN DD * DB2STOP - DB2-SSID(SNC1)

2nd and 3rd Member have been stopped in the same way with the according member name.

DB2START (CKZDSTA ) Run DB2START – (Start target normally) Changes to Sample Job CKZDSTA for 1st DB2 Member:

//CKZIN DD * DB2START - DB2-SSID(SNC1) NORMAL

2nd and 3rd Member have been started in the same way with the according member name.

The cloning szenario from tape has been checked with to an installation of SAP NW 7.0 SR3 application server with ABAP stack only, non-Unicode and with the DB2 Connect (thin client) for the database



connection. The DB2 schema names were not changed. The SAP application was started and the same transaction as for the cloning scenario from DASD were successfully executed.



10. DB2 Recovery Expert Use Case This use case focuses on DB2 Recovery Expert functions in the area of system-level backup and recovery that complements and augments the base functions provided by DB2 standard utilities. This technology is useful in SAP environments.

Validation of copy pools Using the Analysis and Setup function of DB2 Recover Expert, you can easily analyze if the DASD, catalogs, BSDS, Logs and Data of DB2 subsystem follow the configuration guidelines to effectively use the DB2 Backup and Restore utilities.

We start the analysis for Backup method DB2:

Figure 48: System Backup Setup Screen The result of the analysis is that the subsystem configuration is not optimal. The message Subsystem configuration allows only full restore (data and logs) tells us that System Backup and Restore Services can back up and restore the subsystem, but log/BSDS and object data sets are mixed on the same devices. Only a full restore (both log and data volumes) is available.

We can see that we have data, log and other data in SYS1.USERCAT.DSN911. To obtain more specific information, we displayed the content of ALIAS DSN911 in SYS1.USERCAT.DSN911.



Figure 49: First Data Analysis of ALIAS DSN911 – Screen 1

Figure 50: First Data Analysis of ALIAS DSN911 – Screen 2



Under ALIAS DSN911 there are the DSN911.LOGCOPY2.* logs defined.

Figure 51: Logs Defined Under ALIAS DSN911 To have an optimal configuration, we separated the logs from DB2 data. After a second analysis with Recovery Expert, the system tells us that we can use BACKUP and RESTORE without restrictions. However, other non-DB2 data will be backed up and restored – which creates additional overhead. In the MESSAGE line, we get the information that there is also non-DB2 data on the pools that will be backed up and restored.



Figure 52: Second Data Analysis of ALIAS DSN911 – Screen 1

Figure 53: Second Data Analysis of ALIAS DSN911 – Screen 2



In addition, we checked the content of the DB2 volumes. For example, we analyzed which datasets are on volume COBD2L, since the Recovery Expert displayed the message that there is data on the volume that is not related to the DB2 subsystem.

Figure 54: Analysis of DB2 Volumes – Screen 1



On this screen, we can see which datasets are on volume COBD2L.

Figure 55: Analysis of DB2 Volumes – Screen 2 In the Volume Dataset List Display, we see that there are no DB2 Susbystem-related datasets on the volume beginning with high level qualifier SYS1.DSN.D911*. The missing segregation of the datasets can lead to difficulties when a complete subsystem restore is required. For more information, see section RESTORE SYSTEM with Backup on DASD: PIT Recovery Specifying SYSPITRT.

Moving Datasets with Recovery Expert If the analyzed DB2 does not follow the specific requirements that your database system must meet in order to use the system-level backup and restore method, it is possible for the DB2 Recovery Expert to assist you in creating new catalogs and aliases, moving and renaming log and BSDS data sets, as well as moving and renaming DB2 object data sets. For example, you can use line commands to generate jobs for moving data sets from one volume to another. The generated jobs contain all the necessary steps to move DB2 datasets, for example stop tablespace, copy with ADRDSSU, start tablespace and update Recovery Expert Analysis status indicator. However, it is possible to move complete volumes with the product. On the following panel, we enter under the column volume the new volume COBD22 to which the dataset should be moved.



Figure 56: Entering the New Volume COBD22 In the example, tablespace TEST4 is moved from volume COBD23 to volume COBD22. However, DFSMS moves the data sets according to its own definitions given by the storage administrator (in your installation). Therefore, the new volume may differ from the OUTDYNAM parameter of ADRDSSU.

//DB2ADM2R JOB (DE#03557),'REEXPRT',NOTIFY=&SYSUID, // REGION=0K, // MSGCLASS=H, // CLASS=A /*JOBPARM SYSAFF=COB1 //******************************************************************** //* STOP THE SPACES * //******************************************************************** //ARYSTOP EXEC PGM=IKJEFT01,DYNAMNBR=20 //STEPLIB DD DISP=SHR,DSN=SYS1.DSN.D911.SDSNEXIT // DD DISP=SHR,DSN=SYS1.DSN.V910.SDSNLOAD //SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSIN DD * DSN SYSTEM(D911) -STOP DB(DSN00010) SPACENAM(TEST4 ) /* //******************************************************************** //* MOVE THE FILES * //******************************************************************** //ARYMOVE EXEC PGM=ADRDSSU,REGION=016M,COND=(4,LT) //SYSPRINT DD SYSOUT=* //SYSIN DD * COPY DATASET(INCLUDE(DSN911.DSNDBC.DSN00010.TEST4.I0001.A001 )) -



OUTDYNAM(COBD22) - TGTALLOC(SOURCE) FASTREPLICATION(PREFERRED) - DELETE CATALOG /* //******************************************************************** //* START THE SPACES * //******************************************************************** //ARYSTART EXEC PGM=IKJEFT01,DYNAMNBR=20 //STEPLIB DD DISP=SHR,DSN=SYS1.DSN.D911.SDSNEXIT // DD DISP=SHR,DSN=SYS1.DSN.V910.SDSNLOAD //SYSTSPRT DD SYSOUT=* //SYSPRINT DD SYSOUT=* //SYSTSIN DD * DSN SYSTEM(D911) -START DB(DSN00010) SPACENAM(TEST4 ) /* //**************************************************************** //* UPDATE ANALYSIS STATUS INDICATOR * //**************************************************************** //UPDSTAT EXEC PGM=ARY#SUPD,COND=(4,LT),PARM=(D911) //STEPLIB DD DISP=SHR,DSN=SYS1.DB2RE.V210.SARYLOAD //ARYMOVER DD DISP=SHR,DSN=DB2TOOLS.DB2RE.MOVDATA //SYSPRINT DD SYSOUT=*

System-Level Backup on DASD with RE With Recovery Expert DB2 Backup and Restore can be easily managed. Manual interventions for running BACKUPS and RESTORES like reset COPYP status, remove Coupling Facility (CF) structures, unallocated ICF catalogs, etc. are managed by DB2 Recovery Expert. The Backup and Restore services component can be used for creating and managing system level backups. Recovery Expert tracks the BACKUPS in its own repository and offers the user easy-to-manage recovery / restore operations with minimal disruption.

Before a backup can be performed, a backup profile has to be specified. In the examples, we used the DB2 Backup method using the DB2 Backup utility with HSM services. The source/ target volume mapping are done automatically by DB2 Recovery Expert. The Enable Object Restore option allows Recovery Expert to save information to its repository about object data sets that allows objects to be individually restored. The next panel shows a typical backup profile.



Figure 57: A Typical Backup Profile The backup job can be built based on the defined Backup profiles. With Recovery Expert, a System-level backup on tape of the Backup job can be carried out using HSM copy pool attributes.

System-Level Backup RE on Tape Using HSM Copy Pool Attribute VERSIONS=0 The backup job can include an offload step of the backup that will be created. Additionally, you can make a backup of the Recovery Expert’s repository. For the offload, the DFSMShsm dump class that was specified in the backup profile is used.

The next two panels show the specification of the DB2 offload options in the backup profile:

Figure 58: Specification of the DB2 Offload Options – Screen 1



Figure 59: Specification of the DB2 Offload Options – Screen 2



Build the Backup Job When backup profiles have been created, you can enter the B Line Command to create a backup job:

Figure 60: Building the Backup Job



When building the backup job, you can optionally backup the Recovery Expert repository and offload the backups to tape as part of the backup job:

Figure 61: Backing Up the Recovery Expert Repository The JCL dataset that will contain the JCL build by Recovery Expert must have a LRECL of 80. Otherwise, the following error occurs :

IEC036I 002-A0,IFG0553B,DB2ADM4,BASIC,SYS00142,9667,COBSM3,HEIKES.BRC.JCL IEA995I SYMPTOM DUMP OUTPUT SYSTEM COMPLETION CODE=002 REASON CODE=000000A0 TIME=09.08.14 SEQ=01703 CPU=0000 ASID=00CF PSW AT TIME OF ERROR 075C1000 80DF9D06 ILC 2 INTC 0D ACTIVE LOAD MODULE ADDRESS=00DF8000 OFFSET=00001D06 NAME=IFG0199B DATA AT PSW 00DF9D00 - 41003846 0A0DB20A 00509808 AR/GR 0: 00000000/00000000_00DF9F10 1: 00000000/00000000_A4002000 2: 00000000/00000000_001667F4 3: 00000000/00000000_00DF96CA 4: 00000000/00000000_0088E180 5: 00000000/00000000_00E10000 6: 00000000/00000000_0088E4BC 7: 00000000/00000000_0088E514 8: 00000000/00000000_0088E4DC 9: 00000000/00000000_00890C90 A: 00000000/00000000_00FBBBA8 B: 00000000/00000000_00166854 C: 00000000/00000000_8E17BA20 D: 00000000/00000000_00DF8B80 E: 00000000/00000000_00DF9B2C F: 00000002/00000010_000000A0

If the offload fails and the Perform Offload was specified, it is not possible to create another backup until the offload of the backup that failed has been completed. The ISPF Restore System Display of Recovery Expert shows you the status of the Offload. The staus can also be checked with the HSM command: HSEND LIST CP(copypoolname) allvols ods(HLQ.dsn)



This command produces the following list under the ODS parameter-defined dataset: -- DFSMShsm CONTROL DATASET --COPY POOL--LISTING --------- AT 14:23:07 ON 08/07/ COPYPOOL=DSN$COBD911$DB VERSION VTOCENQ DATE TIME FASTREPLICATIONSTATE DUMPSTATE 010 N 2008/07/24 16:34:00 RECOVERABLE FAILED TOKEN(C)=C'D911B¨[¶ø³®þ.>..Y5' TOKEN(H)=X'C4F9F1F1C2BD63B670FAAF8E006E1116E8F5' TOTAL NUM OF VOLUMES=00008,INCREMENTAL=N SGNAME SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET SOURCE - TARGET DB2D2 COBD21 - COBF21 COBD22 - COBF22 COBD23 - COBF23 COBD24 - COBF24 DB2D2 COBD25 - COBF25 COBD26 - COBF26 COBD27 - COBF27 COBD28 - COBF28

The DUMPSTATE in the example indicates that the OFFLOAD failed. With Recovery Expert ,an explicit OFFLOAD can be started out of the ISPF Restore System Display.

Implicit Offload If the offload option is specified when building the Backup Job, the backup runs in two phases.

• Offload to the mapped disk

• Offload from the mapped disk to tape

The data is dumped to the dump class specified in the Backup profile.

On the next panel we specified Perform Offload=Y.

Figure 62: Specifying Perform Offload = Yes



The following generated job contains an additional offload step after the backup:

//ARYBACK EXEC PGM=ARY§MAIN,REGION=016M,COND=(4,LT) //* //STEPLIB DD DISP=SHR,DSN=SYS1.DB2RE.V210.SARYLOAD // DD DISP=SHR,DSN=SYS1.DSN.D911.SDSNEXIT // DD DISP=SHR,DSN=SYS1.DSN.V910.SDSNLOAD //DB2PARMS DD DISP=SHR,DSN=DB2TOOLS.DB2RE.V210.CONTROL //ARYBPROF DD DISP=SHR,DSN=DB2TOOLS.DB2RE.PROFILES //ARYBOFFL DD DISP=SHR,DSN=DB2TOOLS.DB2RE.OFFOPTS //ARYBPMAP DD DISP=SHR,DSN=DB2TOOLS.DB2RE.PROFILE.MAPS //ARYBPCAT DD DISP=SHR,DSN=DB2TOOLS.DB2RE.PROFILE.CATS //ARYSBACK DD DISP=SHR,DSN=DB2TOOLS.DB2RE.SYSBACK //ARYSBOBJ DD DISP=SHR,DSN=DB2TOOLS.DB2RE.SYSBACK.OBJS //ARYSBVOL DD DISP=SHR,DSN=DB2TOOLS.DB2RE.SYSBACK.VOLS //ARYSBSSD DD DISP=SHR,DSN=DB2TOOLS.DB2RE.SYSBACK.SSIDS //ARYBREPT DD DISP=SHR,DSN=DB2TOOLS.DB2RE.BREPORT //SYSOUT DD SYSOUT=* //ARYOUT DD SYSOUT=* //ARY#REPT DD SYSOUT=* //ARYSNAPO DD SYSOUT=* //ARY#PARM DD DSN=DB2TOOLS.DB2RE.V210.D911.SARYSAMP(ARY#PARM),DISP=SHR //ARYIN DD * BACKUP DB2ADM4."D911 DB2 BACKUP SYSTEM" /* //** * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * //ARYJOFFL EXEC PGM=ARY§MAIN,REGION=016M,COND=(4,LT) //* //STEPLIB DD DISP=SHR,DSN=SYS1.DB2RE.V210.SARYLOAD // DD DISP=SHR,DSN=SYS1.DSN.D911.SDSNEXIT // DD DISP=SHR,DSN=SYS1.DSN.V910.SDSNLOAD //DB2PARMS DD DISP=SHR,DSN=DB2TOOLS.DB2RE.V210.CONTROL //ARYBPROF DD DISP=SHR,DSN=DB2TOOLS.DB2RE.PROFILES //ARYBOFFL DD DISP=SHR,DSN=DB2TOOLS.DB2RE.OFFOPTS //ARYBPMAP DD DISP=SHR,DSN=DB2TOOLS.DB2RE.PROFILE.MAPS //ARYBPCAT DD DISP=SHR,DSN=DB2TOOLS.DB2RE.PROFILE.CATS //ARYSBACK DD DISP=SHR,DSN=DB2TOOLS.DB2RE.SYSBACK //ARYSBOBJ DD DISP=SHR,DSN=DB2TOOLS.DB2RE.SYSBACK.OBJS //ARYSBVOL DD DISP=SHR,DSN=DB2TOOLS.DB2RE.SYSBACK.VOLS //ARYSBSSD DD DISP=SHR,DSN=DB2TOOLS.DB2RE.SYSBACK.SSIDS //ARYBREPT DD DISP=SHR,DSN=DB2TOOLS.DB2RE.BREPORT //ARY#REPT DD SYSOUT=* //SYSOUT DD SYSOUT=* //ARYOUT DD SYSOUT=* //ARYSNAPO DD SYSOUT=* //ARY#PARM DD DSN=DB2TOOLS.DB2RE.V210.D911.SARYSAMP(ARY#PARM),DISP=SHR //ARYIN DD * OFFLOAD DB2ADM4."D911 DB2 BACKUP SYSTEM" GENERATION LAST-BACKUP

Explicit Offload When backups are not immediately offloaded during the backup phase, Recovery Expert provides through the ISPF interface the possibility to select a specific system level backup for offloading to tape. Therefore, it is possible to split the backup and offload processing into independent tasks.



Validation To make DB2 backup and restore more thorough and less error-prone, validation checking is included in the setup process of the backup profiles. The validation checking authenticates the volumes for the subsystem, checks the locations of the user data, logs, and user catalogs ,and performs other validations to ensure the backup can proceed and that the resulting backup is usable.

After a backup profile has been created, the first backup job is a profile setup. It is a validation process performed by System Backup and Restore Services before a backup of a subsystem can be taken. Note: The second run is without the SETUP parameter and creates the backup.

//ARYBACK EXEC PGM=ARY§MAIN,REGION=016M,COND=(4,LT) //* //STEPLIB DD DISP=SHR,DSN=SYS1.DB2RE.V210.SARYLOAD // DD DISP=SHR,DSN=SYS1.DSN.D911.SDSNEXIT // DD DISP=SHR,DSN=SYS1.DSN.V910.SDSNLOAD //DB2PARMS DD DISP=SHR,DSN=DB2TOOLS.DB2RE.V210.CONTROL //ARYBPROF DD DISP=SHR,DSN=DB2TOOLS.DB2RE.PROFILES //ARYBOFFL DD DISP=SHR,DSN=DB2TOOLS.DB2RE.OFFOPTS //ARYBPMAP DD DISP=SHR,DSN=DB2TOOLS.DB2RE.PROFILE.MAPS //ARYBPCAT DD DISP=SHR,DSN=DB2TOOLS.DB2RE.PROFILE.CATS //ARYSBACK DD DISP=SHR,DSN=DB2TOOLS.DB2RE.SYSBACK //ARYSBOBJ DD DISP=SHR,DSN=DB2TOOLS.DB2RE.SYSBACK.OBJS //ARYSBVOL DD DISP=SHR,DSN=DB2TOOLS.DB2RE.SYSBACK.VOLS //ARYSBSSD DD DISP=SHR,DSN=DB2TOOLS.DB2RE.SYSBACK.SSIDS //ARYBREPT DD DISP=SHR,DSN=DB2TOOLS.DB2RE.BREPORT //SYSOUT DD SYSOUT=* //ARYOUT DD SYSOUT=* //ARY#REPT DD SYSOUT=* //ARYSNAPO DD SYSOUT=* //ARY#PARM DD DSN=DB2TOOLS.DB2RE.V210.D911.SARYSAMP(ARY#PARM),DISP=SHR //ARYIN DD * BACKUP DB2ADM4."D911 DB2 BACKUP SYSTEM" SETUP

/*

Result without Error with Setup ********************************* TOP OF DATA ********************************** ARYS001I - Recovery Expert for DB2 z/OS Starting. Version 02.01.016 ARYS162I - Parmlib used for this execution ARYS003I - Control Cards: ARYS004I - BACKUP DB2ADM4."D911 DB2 BACKUP SYSTEM" ARYS004I - SETUP ARYS004I - ARYS013I - Backup profile DB2ADM4.D911 DB2 BACKUP SYSTEM was read from the repos ARYS038I - Performing profile volume map validation... ARYS039I - Volume map validation complete. ARYS075I - Performing subsystem source volume validation... ARYS190W - Volume COBSM2 is not included in this backup. It contains only ARCHI ARYS190W - Volume COBSM3 is not included in this backup. It contains only ARCHI ARYS190W - Volume COBSM4 is not included in this backup. It contains only ARCHI ARYS190W - Volume COBSMS is not included in this backup. It contains only ARCHI ARYS076I - Subsystem source volume validation complete. All source volumes are ARYS079I - Profile setup is complete. Remove the "SETUP" control card to run th ARYS002I - Recovery Expert for DB2 z/OS complete. RC=004. ******************************** BOTTOM OF DATA ********************************



An automatic validation can be always processed before a backup is created. If the validation finds a problem, the backup ends with the Return Code that was customized, as well as information about the problem. In the example below, there is no mapping between source volume COBD25 and a target volume.

Figure 63: Missing Mapping Between Source and Target Volumes



When we check the copy pool listing created by the HSEND LIST CP command, we can see that there is no target volume for COBD25 defined. That is the reason why the backup stopped in the validation phase.

Figure 64: Checking the Copy Pool Listing

Resetting COPYP status with BACKUP SYSTEM and RE After the system backup Recovery Expert resets the copy pending status of the tablespaces and indexspaces so that they are no longer in copy pending status. You can turn off/ on the reset pending function of the product. This can be done in the product PARMLIB( e.g. DB2TOOLS.DB2RE.V210.D911.SARYSAMP(ARY#PARM) ) member by setting: RESET_COPY_PENDING_TS N/Y RESET_COPY_PENDING_IX N/Y



RE Backup and Offload Reports During backup, Recovery Expert writes reports to the job's output DDs and in the products repository. The information can be viewed on the ISPF Backup Report Display and contains valuable information about the backups and choosing the right backup in case of a restore. The information is divided into the following:

• Backup Summary Report

• Backup Volume Detail Report

• Volume Offload Summary Report

• Volume Offload Detail Report

Recovery Expert for DB2 z/OS

Backup Summary Report

Utility Executed:......... Backup

Profile Name:............. DB2ADM4.D911 DB2 BACKUP SYSTEM

DB2 Subsystem:............ D911

DB2 Version:.............. 0910

Backup Type:.............. IBM System Level Backup

Backup Contains:.......... Object Data and Log Data

Partial Backup:........... No

Nbr of Volumes:........... 0010

HSM Backup Token:......... C4F9F1F1C2C7248757A314D9006F65A95288

Backup RBA:............... 006F65A98747

Last Checkpoint RBA:...... 006F65A986D9

Backup Date:.............. 08/01/2008

Backup Time:.............. 10:44:37

Consistency Method:....... IBM System Level Backup

Supports Object Restore:.. Yes

I/O Suspend Time:......... 2008-08-01-10.44.33.579818

I/O Resume Time:.......... 2008-08-01-10.45.03.858446

Backup Elapsed:........... 30.27 Seconds




Backup Volume Detail Report

<-Source Volumes-> <-Targets-> <--------Data Types-------->

Volser Ucb# Devtyp Volser Ucb# Obj OCat ALog ACat RLog RCat

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

COBD21 2420 3390-7 COBF21 2428 Yes No No No No No

COBD22 2421 3390-7 COBF22 2429 Yes No No No No No

COBD23 2422 3390-7 COBF23 242A Yes No No No No No

COBD24 2423 3390-7 COBF24 242B Yes No No No No No

COBD25 2424 3390-7 COBF25 242C Yes No No No No No

COBD26 2425 3390-7 COBF26 242D Yes No No No No No

COBD27 2426 3390-7 COBF27 242E Yes Yes No No No No

COBD28 2427 3390-7 COBF28 242F Yes No No No No No

COBD2L 2442 3390-9 COBF2L 2448 No No Yes Yes No Yes

COBD2M 2446 3390-9 COBF2M 244D No No Yes No No No




Volume Offload Summary Report

Utility Executed:......... Offload

Profile Name:............. DB2ADM4.D911 DB2 BACKUP SYSTEM

Offload Date:............. 08/01/2008

Offload Time:............. 10:50:19

Data Mover:............... DFSMShsm

Compress:................. N/A

Generation:............... 0001

Nbr Of Volumes:........... 0010


Volume Offload Detail Report

<---DB2---> <----Tape---->

Volser Ucb# Type Offloaded to Filename FileSeq Volser

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

COBD21 2420 LP HSMCOB.DMP.DB2DUMP1.VCOBD21.D08214.T344410 001 COB005








COBD2L 2442 LP HSMCOB.DMP.DB2DUMP1.VCOBD2L.D08214.T374410 001 COB008

COBD2M 2446 LP HSMCOB.DMP.DB2DUMP1.VCOBD2M.D08214.T374410 002 COB008



Restore with Recovery Expert The Restore System Display shows the information on all the system-level backups that have been taken with Recovery Expert. From here, the user can specify the Backup and the volumes that contain DB2 object data or both Log and Data volumes to be restored. Detailed information about the Backups can be displayed by selecting a specific backup and viewing the detailed reports that have been saved in the Recovery Expert’s repository.

In the columns On Disk and On Offload, the user can indicate where the Backup is available. If a Backup is available on both, disk and offload, the restore selects the version from disk. The restore generated by DB2 Recovery Expert includes all necessary steps for a successful restore, for example choosing correct RBA on 4K boundary, volume map validation, managing vary volumes offline / online, disconnecting user catalogs, restore volumes. If restoring both Data and Logs, you cannot select a timestamp recovery point.

If a Backup that was created by RE Backup is on an Offload volume and on disk, Recovery Expert automatically restores the version from disk.

The next panel displays the backups created with Recovery Expert and how to select one for the SYSTEM RESTORE.

Figure 65: Restore System Display



Restore from Offload If the On Disk column on the ISPF Restore System Display is set to No, the restore is taken using the offloaded backup. On the next panel, a backup is selected that is only available On Offload. No specific recovery point is selected. The RBA / LRSN associated with the backup is chosen.

Figure 66: Restoring from an Offloaded Backup DB2 Recovery Expert generates a job with three steps that perform the system-level restore. The first step stops the DB2 subsystem,the second step performs the system-level restore with all necessary activities:

• Completing volume map validation

• Varying volumes offline

• Waiting for volumes to go offline and retry when vary offline was not possible

• Disconnecting user catalogs

• Varying volumes online

• Restoring volumes from offloaded backup

• Creating a restore summary report

The third step starts DB2 again.



The following is a typical RE Restore JOBLOG: 10:01:18 ARYS001I - Recovery Expert for DB2 z/OS Starting. Version 02.01.020

10:01:18 ARYS162I - Parmlib used for this execution

10:01:18 ARYS003I - Control Cards:

10:01:18 ARYS004I - RESTORE DB2ADM4."D911 DB2 BACKUP SYSTEM"

10:01:18 ARYS004I - GENERATION 01

10:01:18 ARYS004I - DATE 08/07/2008

10:01:18 ARYS004I - TIME 11:54:05

10:01:18 ARYS004I - RESTORE-LOGS

10:01:18 ARYS004I -

10:01:18 ARYS123I - Backup DB2ADM4.D911 DB2 BACKUP SYSTEM generation 01 was read

10:01:18 ARYS013I - Backup profile DB2ADM4.D911 DB2 BACKUP SYSTEM was read from

10:01:18 ARYS038I - Performing profile volume map validation...

10:01:18 ARYS039I - Volume map validation complete.

10:01:18 ARYS137I - Varying volumes offline.

10:01:50 ARYS136I - Disconnecting user catalogs.

10:01:50 ARYS217I - User catalog SYS1.USERCAT.DSN911 disconnected.

10:01:52 ARYS217I - User catalog SYS1.USERCAT.DSN911L disconnected.

10:01:54 ARYS094I - Volser COBD2L is still online.

10:01:54 ARYS095I - Waiting 06 seconds for volumes to go offline...

10:02:00 ARYS137I - Varying volumes online.

10:02:03 ARYS004I - Restoring volumes from offloaded backup...

10:18:01 ARYS277I - Task 01 - Volser COBD21 was restored from HSMCOB.DMP.DB2DUMP








11:45:55 ARYS277I - Task 01 - Volser COBD2L was restored from HSMCOB.DMP.DB2DUMP

11:47:49 ARYS277I - Task 01 - Volser COBD2M was restored from HSMCOB.DMP.DB2DUMP

11:47:49 ARYS002I - Recovery Expert for DB2 z/OS complete. RC=000.



The following is a typical RE Restore summary Report:

Figure 67: Typical RE Restore Summary Report However, it can take a while when restoring a large amount of data from backup volumes. There is always a danger that some of the source volumes will be reused by other processes during the restore. In that case, the restore abends with RC=8 and messages ARYS248E - Task 01 - Error invoking ADRDSSU.

ADR405E (001)-DYNA (02), DYNAMIC ALLOCATION OF VOLUME COBD2L FAILED. ERROR CODE0218.

Restore Data only / PIT Instead of restoring both Log and Data volumes, it is also possible to restore only those volumes that contain DB2 object data. The user can choose an RBA/LRSN to which he wants to restore.

A “Select a Recovery Point” option helps the user to select an appropriate RBA/LRSN out of archive log points, DB2 checkpoints and by Recovery Expert Captured Timestamp/RBA since the backup has been taken. For restoring Data and Logs, it is not possible to select a Timestamp Recovery Point or change the Recover to RBA/LRSN.



On the following panel, we select a recovery based on a timestamp.

Figure 68: Selecting a Recovery Based on a Time Stamp



On the next panel, we show how RE can assist to select timestamps and associated log RBAs and/or LRSNs recorded at start and end checkpoints, archive log records, etc.

Figure 69: RE Assistance in Selecting Timestamps



RE Deallocates ICF catalogs before FRRECOV and Creates SYSPITR/ SYSPITRT for All Members When you select restore, Recovery Expert generates three jobs in your specified JCL library:

1. Stop DB2

Run DSNJU003 to insert a conditional restore record with selected RBA/LRSN.

For Data Sharing, a DSNJU003 step for all members of a group is created and all

members must be stopped manually.

2. DB2 Restore

DB2 Start:

When DB2 starts, you must respond to the following question with Yes.

XXXX CONDITIONAL RESTART RECORD INDICATES TRUNCATION

AT RBA XXXXXXXXXXXX. REPLY Y OR N

For Data Sharing, all members must be started manually.

3. DSNUTILB System Restore utility with LOGONLY parameter

RE automatically removes CF structures When an RE restore is running for a Data Sharing system, a command is issued to clear the coupling facility structures of the data sharing systems.

SETXCF FORCE,STRUCTURE,STRNAME=DBN6_LOCK1

IXC579I NORMAL DEALLOCATION FOR STRUCTURE DBN6_LOCK1 IN 173

COUPLING FACILITY 002094.IBM.51.0000000163CF

PARTITION: 2F CPCID: 00

HAS BEEN COMPLETED.

PHYSICAL STRUCTURE VERSION: C2BB6E4A 31FCAE4E

INFO116: 132C2080 01 2800 0000000F

TRACE THREAD: 000470E5.

IXC353I THE SETXCF FORCE REQUEST FOR STRUCTURE 174

DBN6_LOCK1 WAS COMPLETED:

STRUCTURE DELETED BUT ALSO RESULTED IN DELETED CONNECTION(S)

SETXCF FORCE,STRUCTURE,STRNAME=DBN6_SCA

IXC579I NORMAL DEALLOCATION FOR STRUCTURE DBN6_SCA IN 176

COUPLING FACILITY 002094.IBM.51.0000000163CF

PARTITION: 2F CPCID: 00

HAS BEEN COMPLETED.

PHYSICAL STRUCTURE VERSION: C2BB6E49 0C04A84C

INFO116: 132C2080 01 2800 0000000E

TRACE THREAD: 000470EA.

IXC353I THE SETXCF FORCE REQUEST FOR STRUCTURE 177



DBN6_SCA WAS COMPLETED:

STRUCTURE WAS DELETED

However, when DB2 is restarted, you must verify the status of the databases ( for example, GRECP, RECP status) and set with the related DB2 commands or DB2 recover utility, as in the following example:

-SN61 DIS DB(*) RESTRICT

DSNT360I -SN61 ***********************************

DSNT361I -SN61 * DISPLAY DATABASE SUMMARY 378

* RESTRICTED

DSNT360I -SN61 ***********************************

DSNT362I -SN61 DATABASE = DSNDB01 STATUS = RW 380

DBD LENGTH = 14200

DSNT397I -SN61 381

NAME TYPE PART STATUS PHYERRLO PHYERRHI CATALOG PIECE

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

SYSLGRNX TS RW,GRECP

******* DISPLAY OF DATABASE DSNDB01 ENDED **********************

-SN61 STA DB(DSNDB01) SPACE(SYSLGRNX)



Timestamp to LRSN Utility There is an additional Timestamp to the LRSN utility in RE available when a Restore should be built. The user can enter the date and time to which the system is to be recovered. This feature can be used for data sharing subsystems when you are only restoring data.

You can enter the timestamp in either GMT or local time. The utility then determines the appropriate restore LRSN based on the timestamp.

On the following panel, the Timestamp to LRSN Utility is selected by entering Y.

Figure 70: Selecting the Timestamp to DB2 LRSN Utility



The following panel shows how an LRSN can be generated by a local or GMT timestamp.

Figure 71: Generating an LRSN by a Timestamp



RE Object Recovery: Recovering Tablespace with Data Sets that Have Moved to a Different Volume It is possible to do object recovery based on DB2 system backups. To achieve this, you must define object profiles that contain the objects or object groups that have to be recovered together. Objects can be recovered from system-level backups. If system-level backups are not available, or if not available from the appropriate DB2 image copies and apply logs.

Based on an object profile, you can specify recovery options, recovery resources, RBA/ LRSN, etc. for the objects in the profile. An example of a recovery option would be the recovery point-in-time. Subsequently, you can generate the recovery job.

The following panel shows an object profile for tablespace TEST4.

Figure 72: Object Profile for Tablespace TEST4



If the Update Recovery options are selected, the user can choose from different options, for example offload, parallel task, tape units, rebuild IX, etc:

Figure 73: Update Recovery Options Available The job that is generated contains Start DB in utility state, Recover, Rebuild IX. as in the the following example:

//START#UT EXEC PGM=IKJEFT01,DYNAMNBR=20,COND=(4,LT)

//STEPLIB DD DISP=SHR,DSN=SYS1.DSN.SN61.SDSNEXIT

// DD DISP=SHR,DSN=SYS1.DSN.V910.SDSNLOAD

//SYSTSPRT DD SYSOUT=*

//SYSPRINT DD SYSOUT=*

//SYSTSIN DD *

DSN SYSTEM(SN61)

-STA DB(DSN00004) SP(TEST4) PART(001) ACCESS(UT)

-STA DB(DSN00004) SP(TEST4ABC) ACCESS(UT)

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

//RCVRFRIC EXEC PGM=DSNUTILB,REGION=016M,COND=(4,LT),

// PARM=(SN61,'UT1')

//*





//SYSOUT DD SYSOUT=*

//UTPRINT DD SYSOUT=*



//*

//SYSIN DD *

RECOVER

TABLESPACE DSN00004.TEST4 DSNUM(001)

TOLOGPOINT X'C2DCB70BB575'

PARALLEL(04)

TAPEUNITS(02)

REUSE

LOCALSITE

/*

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

//REBUILD EXEC PGM=DSNUTILB,REGION=016M,COND=(4,LT),

// PARM=(SN61,'UT1')

//*





//UTPRINT DD SYSOUT=*

//*

//SYSIN DD *

REBUILD

INDEX ("SAPR3"."TEST4ABC_#_T90"

)

SORTDEVT SYSALLDA

SORTNUM 6

SORTKEYS

/*

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

//START#RW EXEC PGM=IKJEFT01,DYNAMNBR=20,COND=(4,LT)



//SYSTSPRT DD SYSOUT=*


//SYSTSIN DD *

DSN SYSTEM(SN61)

-STA DB(DSN00004) SP(TEST4) PART(001) ACCESS(RW)

-STA DB(DSN00004) SP(TEST4ABC) ACCESS(RW)

/*



RE Automatically Restores Underlying Datasets If the underlying dataset of the tablespace that has to be recovered does not exist ( for example, because it was deleted ) Recovery Expert is able to fix that situation by doing an object restore from the last DB2 system backup and then starting the normal recovery process as described before:

//RECOBJST EXEC PGM=ARY§MAIN,REGION=016M,COND=(4,LT)

//*

//STEPLIB DD DISP=SHR,DSN=SYS1.DB2RE.V210.SARYLOAD

// DD DISP=SHR,DSN=SYS1.DSN.SN61.SDSNEXIT


//DB2PARMS DD DISP=SHR,DSN=DB2TOOLS.DB2RE.V210.CONTROL

//ARYBPROF DD DISP=SHR,DSN=DB2TOOLS.DB2RE.PROFILES

//ARYBOFFL DD DISP=SHR,DSN=DB2TOOLS.DB2RE.OFFOPTS

//ARYBPMAP DD DISP=SHR,DSN=DB2TOOLS.DB2RE.PROFILE.MAPS

//ARYBPCAT DD DISP=SHR,DSN=DB2TOOLS.DB2RE.PROFILE.CATS

//ARYSBACK DD DISP=SHR,DSN=DB2TOOLS.DB2RE.SYSBACK

//ARYSBOBJ DD DISP=SHR,DSN=DB2TOOLS.DB2RE.SYSBACK.OBJS

//ARYSBVOL DD DISP=SHR,DSN=DB2TOOLS.DB2RE.SYSBACK.VOLS

//ARYSBSSD DD DISP=SHR,DSN=DB2TOOLS.DB2RE.SYSBACK.SSIDS

//ARYBREPT DD DISP=SHR,DSN=DB2TOOLS.DB2RE.BREPORT

//ARY#REPT DD SYSOUT=*


//ARYOUT DD SYSOUT=*

//ARYSNAPO DD SYSOUT=*

//ARY#PARM DD DSN=DB2TOOLS.DB2RE.V210.D911.SARYSAMP(ARY#PARM),DISP=SHR

//ARYIN DD *

ORESTORE "DB2ADM4"."SN61 DB2 BACKUP SYSTEM"

GENERATION 01

DATE 08/20/2008

TIME 11:10:36

MAX-TASKS 04

START-SPACE-MODE NONE

LOCAL-SITE

TABLESPACE DSN00004.TEST4 PARTITION 001

ARYS001I - Recovery Expert for DB2 z/OS Starting. Version 02.01.020

ARYS162I - Parmlib used for this execution

ARYS003I - Control Cards:

ARYS004I - ORESTORE "DB2ADM4"."SN61 DB2 BACKUP SYSTEM"

ARYS004I - GENERATION 01

ARYS004I - DATE 08/20/2008

ARYS004I - TIME 11:10:36

ARYS004I - MAX-TASKS 04



ARYS004I - START-SPACE-MODE NONE

ARYS004I - LOCAL-SITE

ARYS004I - TABLESPACE DSN00004.TEST4 PARTITION 001

ARYS004I -

ARYS123I - Backup DB2ADM4.SN61 DB2 BACKUP SYSTEM generation 01 was read from the repository

ARYS013I - Backup profile DB2ADM4.SN61 DB2 BACKUP SYSTEM was read from the repository

ARYS004I -

ARYS320I - Tablespace DSN00004.TEST4 partition 1 has been stopped.

ARYS004I -

ARYS004I - Existing object datasets have been deleted.

ARYS004I -

ARYS322I - Dataset DBN6.DSNDBC.DSN00004.TEST4.I0001.A001 was restored via DFSMSdss copy

ARYS330I - Volume: COBD15 Tracks: 00000045

ARYS004I -

ARYS291I - Tablespace DSN00004.TEST4 partition 1 was successfully restored.

ARYS004I -

ARYS002I - Recovery Expert for DB2 z/OS complete. RC=000.

If the underlying dataset of a tablespace that has to be restored or recovered have been moved between volumes, dependent on the timestamp of the restore and the PIT definition, the new location of the dataset will remain unaffected.



Drop Recovery RE can rebuild database assets that have been accidentally dropped and therefore do not exist in the DB2 system catalog. However, it is important to keep the RE schema level repository up-to-date. The sample job ARYSJ002 can be found in the samplib. In the GUI of Recovery Expert, the dropped objects are displayed in red.:

Figure 74: Dropped Objects Displayed in Red



To recover the object and its dependent objects, the root object must be selected for recovery. Subsequently, you must specify the point in time to which you want to recover:

Figure 75: Selecting the Objects You Want to Recover



RE generates the following recovery plan by which the dropped objects are recreated. All relevant objects are recovered together, thereby maintaining the integrity of your data. IBM DB2 Recovery Expert for z/OS restores all missing objects related to the objects selected for recovery. By default, Recovery Expert for z/OS always recovers missing objects related to DB2 object dependencies.

Figure 76: Plan to Recover Selected Objects



The following screen shows the objects to be recovered:

Figure 77: Objects to Be Recovered



Restore and PIT Recovery on Object-Level with Recovery Expert GUI Point in Time Recovery for DB2 subsystems or on DB2 Object level can be also carried out with the Recovery Expert GUI. For system recovery, a Data Sharing member or DB2 subsystem must be selected, as well as a timestamp with the explicit option to specify a timestamp. Sometimes it is not easy to find an appropriate timestamp. RE allows you to perform log analysis to determine periods of time during which there is no activity for an object or set of objects. After selecting a recovery timestamp, the JCL for the Restore is built.

Unlike with the jobs generated by recovery experts ISPF interface, the user must ensure that many requirements are fullfilled, including the following:

• the related DB2 subsystem is stopped

• the generated DSNJU003 job that is updating the BSDS with a SYSPITR CRCR entry runs on all related DB2 subsystems

• all CF structures that the Data Sharing group owns are deleted, etc.

The next RE GUI example demonstrates how to setup a recovery for an object set for the data sharing group DBN6:

Figure 78: Setting Up a Recovery Job



To recover the complete group, member SN61 was selected.

Figure 79: Selecting Member SN61



Then the point in time is selected.

Figure 80: Selection of Point-in-Time To help to find recoverable points, RE can help to select a timestamp from a definition level of any selected object, a recovery history event related to any selected object, or a quiet time for all selected objects.

The next two GUIs demonstrate these two fucntions.



Figure 81: Selecting a Point in Time The following GUI shows how recovery history events like image copies can be selected.

Figure 82: Selecting Recovery History Events



The following GUI shows how recovery history events log points can be selected.

Figure 83: Selecting History Events Log Points



The recovery plans generated by RE can be selected for execution.

Figure 84: Selecting Recovery Plans With the GUI, it is possible to recover objects specified by object patterns. Recovery Expert generates one or more recovery plans for the selected objects with a cost estimation factor. Each plan can be selected to review its details.

Unlike normal DB2 recovery scenarios, Recovery Expert can incorporate REDO/ UNDO processing in the recovery plans.

When the recovery plans have been generated, Recovery Expert gives a detailed overview of each recovery step in the recovery plans. All objects that are involved in the recovery are shown together with the generated plans.



For object recovery, RE helps to specify objects, a group of objects and their depending objects.

Figure 85: Assistance by Object Selection



However, RE assists the user in selecting a PIT to which you want to recover.

Figure 86: Assistance in PIT Selection



The following are examples of different recovery plans:

Figure 87: Examples of Different Recovery Plans



The following is the detailed structure of a recovery plan:

Figure 88: Detailed Structure of a Recovery Plan



The generated JCL of the recovery plan can be viewed, changed and exported in your JCL library.

Figure 89: Generated JCL View When several recovery plans have been generated, the Validate function gives users the ability to verify if the recovery plan is valid. This checks whether the conditions that applied when the plans were generated still apply. For example, the existence of expected image copy data sets is checked. The existence of expected DB2 objects is also checked (to ensure that objects which were dropped at the time of generation are still dropped and objects which existed still exist). This validation is not a full simulation, that is, it is not a guarantee that the plan will run successfully; some resources may appear to exist but actually do not (such as a cataloged tape that is not physically available) or you may not have authorization to access some resources.



In the example below, the validation of recovery plan 3 failed because the dataset of the image copy of tablespace TEST4 DB2ADM2.SN61.IC.DSN00004.TEST41 was deleted. Since Recovery Expert generated six recovery plans, it is possible to use another recovery plan.

Figure 90: Unsuccessful Validation



Since the validation of recovery plan 1 was successful and the cost factor is low, it is recommended that the user apply plan 1 for the recovery with undo SQL.

Figure 91: Application of Using undo SQL



11. Summary This document provided hands-on tips and tricks for using DB2 utilities and tools for backup, recovery and cloning in SAP environments. In addition, it covered how to take advantage of the latest technical capabilities of these tools. Moreover, a particular focus was 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.



12. Appendix Recovery Expert configuration details

ARYV210 CLIST for Recovery Experts System Backup Recovery Services

PROC 0 RBRLVL(SYS1.DB2RE.V210)

RBRLOAD1(SYS1.DB2RE.V210.SARYLOAD)

MLIB(SARYMENU)

PLIB(SARYPENU)

SLIB(SARYSLIB)

LLIB(SARYLOAD)

DB2CNTFL(DB2TOOLS.DB2RE.V210.CONTROL)

RBRBPROF(DB2TOOLS.DB2RE.PROFILES)

RBRBPMAP(DB2TOOLS.DB2RE.PROFILE.MAPS)

RBRBPCAT(DB2TOOLS.DB2RE.PROFILE.CATS)

RBRSBACK(DB2TOOLS.DB2RE.SYSBACK)

RBRSBVOL(DB2TOOLS.DB2RE.SYSBACK.VOLS)

RBRSBSSD(DB2TOOLS.DB2RE.SYSBACK.SSIDS)

RBRSBOBJ(DB2TOOLS.DB2RE.SYSBACK.OBJS)

RBRPOBJS(DB2TOOLS.DB2RE.OBJECTS)

RBRBREPT(DB2TOOLS.DB2RE.BREPORT)

RBRBOFFL(DB2TOOLS.DB2RE.OFFOPTS)

RBRMOVER(DB2TOOLS.DB2RE.MOVDATA)

RBRSSRBA(DB2TOOLS.DB2RE.SSID.RBA)

RBRBUPRE(DB2TOOLS.DB2RE)

RBRBUSUF(BACKUP(+1))

EMCLOAD1()

EMCLOAD2()

EMCLOAD3()

FDRLOAD1()

FDRLOAD2()

PARMLDSN(DB2TOOLS.DB2RE.V210.D911.SARYSAMP)

PARMLMBR(ARY#PARM)

ISPMLIB1()

ISPMLIB2()

ISPMLIB3()

ISPTLIB1()



ISPTLIB2()

ISPTLIB3()

ISPLLIB1()

ISPLLIB2()

ISPLLIB3()

SCFDD()

ARYVER(V2R1)

USERIND(ARY)

The ARYV210 CLIST is located in

SYS4.ADM.PRODADD.SADBCLST

Customization Jobs D911 and DBN6 DB2TOOLS.DB2RE.V210.DBN6.SARYSAMP

DB2TOOLS.DB2RE.V210.D911.SARYSAMP

Parameter Library for Recovery Expert Agents and RBA Capture DB2TOOLS.DB2RE.V210.CONFIG

Configuration Members:

CFGACOB1

CFGACOB2

CFGACOB3

CFGSCOB1

RBRSSB2

RBRSSB3

RBRSSID

DB2 Recovery Expert Control File samples * *------------------------------------------------------------------- * Sample statement for Group DBN6. *------------------------------------------------------------------- * SET DB2 SSID = DBN6 * � * *------------------------------------------------------------------- * Sample statements for Member SN61 of Group DBN6. *-------------------------------------------------------------------



* SET DB2 SSID = SN61 UPDATE DB2 ZPARMS = DSNZPARM UPDATE DB2 BOOTSTRAP1 = DBN6.SN61.BSDS01 UPDATE DB2 BOOTSTRAP2 = DBN6.SN61.BSDS02 UPDATE DB2 LOADLIB1 = SYS1.DSN.SN61.SDSNEXIT UPDATE DB2 LOADLIB2 = SYS1.DSN.V910.SDSNLOAD *UPDATE DB2 LOADLIB3 = *UPDATE DB2 LOADLIB4 = *UPDATE DB2 LOADLIB5 = * *------------------------------------------------------------------- * Sample statements to add/update ARY product plans *------------------------------------------------------------------- * SET DB2 SSID = SN61 SET PRODUCT CFG = NULL SET PRODUCT VER = NULL * UPDATE ARY PLAN1 = ARYPLAN1 DISPLAY DATA EXTRACT UPDATE ARY PLAN2 = ARYPLAN2 SCHEMA LEVEL REPOSITORY LOAD UPDATE ARY PLAN3 = ARYPLAN3 RECOVERY PLAN GENERATION UPDATE ARY PLAN4 = ARYPLAN4 JCL GENERATION AND SQL EXEC UPDATE ARY PLAN5 = ARYPLAN5 LOG ANALYSIS SERVICES * *------------------------------------------------------------------- * Sample statements to add/update product message library *------------------------------------------------------------------- * UPDATE ARY MSGLIBRARY = SYS1.DB2RE.V210.SARYMENU * *------------------------------------------------------------------- * Sample statements to add/update log services options *------------------------------------------------------------------- * UPDATE ARY ARCHLOG1 = Y USE ARCHIVE LOG 1 UPDATE ARY ARCHLOG2 = N USE ARCHIVE LOG 2 UPDATE ARY ACTLOGPRI = Y ACTIVE LOG PRIORITY * *------------------------------------------------------------------- * Sample statements to add/update data set prefix generation *------------------------------------------------------------------- * * The DSN PREFIX maximum length is 17 characters. If NULL * is specified then user id is used as data set prefix. Use &USERID * in the prefix to insert user id. Example: TEST.&USERID will * generate a data set prefix of 'TEST.MYID' where the user id is * 'MYID'. * *UPDATE ARY DSN PREFIX = DB2TOOLS.DB2RE.&USERID UPDATE ARY DSN PREFIX = &USERID * *------------------------------------------------------------------- * Sample statements to turn on/off recovery options *------------------------------------------------------------------- * UPDATE ARY RCVR AUTHS = Y RECOVER DB2 OBJECT AUTHORIZATIONS * *-------------------------------------------------------------------



* Sample statements to add/update schema level repository data * capture options. *------------------------------------------------------------------- * UPDATE SLR LOAD AUTHS = Y N = DB2 authorizations are * not saved in schema level * repository. * *------------------------------------------------------------------- * Sample statements to add/update interproduct communication * options. *------------------------------------------------------------------- * UPDATE IPC IPC_GROUPER = N Y = Enable Grouper-related * table recovery. * *------------------------------------------------------------------- * Sample statements to add/update table activity quiet time * repository names. *------------------------------------------------------------------- * * EACH QT OWNER/NAME IS A 45 CHAR MAXIMUM LENGTH. THESE OBJECTS WILL * BE CREATED AUTOMATICALLY WHEN THE QUIET TIME REPORT/CAPTURE JCL * IS RUN IF THEY DO NOT ALREADY EXIST. DDL TO CREATE THESE OBJECTS * IS PROVIDED IN ARYDDL7 AND ARYDDL8 SAMPLE DDL MEMBERS. * * XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX UPDATE QT GRP TBOWNER = SYSTOOLS UPDATE QT GRP TBNAME = ARYQTG UPDATE QT GRP IXOWNER = SYSTOOLS UPDATE QT GRP IXNAME = ARYQTGX UPDATE QT ENTRY OWNER = SYSTOOLS UPDATE QT ENTRY NAME = ARYQT * XXXXXXXX (MAX LENGTH FOR DB AND TS IS 8) UPDATE QT DATABASE = SYSTOOLS UPDATE QT TABLESPACE = ARYTSQT * *------------------------------------------------------------------- * Sample statements to add/update log analysis services ROWDATA * VSAM data set attributes. *------------------------------------------------------------------- * * The ROWDATA VSAM data set is dynamically created by the log * analysis services when creating SQL from the log. * * The DSN PREFIX maximum length is 21 characters. The following * set of product controls are required and must be properly set * to ensure proper log data recoveries. The VOLSERS statement * value can be set to blanks, if required. A maximum of 3 volsers * can be specified. * UPDATE LAS DSN PREFIX = DB2TOOLS.DB2RE.V210 UPDATE LAS VOLSERS = UPDATE LAS DATA AUNIT = C UPDATE LAS DATA PQTY = 00005 UPDATE LAS DATA SQTY = 00005 UPDATE LAS INDEX AUNIT = C UPDATE LAS INDEX PQTY = 00005 UPDATE LAS INDEX SQTY = 00005



* *------------------------------------------------------------------- * Sample statements to add/update character conversion information *------------------------------------------------------------------- * * Schema Level Repository Unicode data conversion information. * These values should not be changed. The IBM DB2 Recovery Expert * z/OS components require the following CCSID conversions to be * defined on the target systems. * UPDATE CCS SLR TECHNQ = ER CHARACTER CONVERSION TECHNIQUE UPDATE CCS SLR SBCS = 00037 EBCDIC UPDATE CCS SLR DBCS = 01200 UNICODE UT-16 UPDATE CCS SLR MIXED = 01208 UNICODE UT-8 * * Product output Unicode data conversion information. * UPDATE CCS ARY TECHNQ = ER CHARACTER CONVERSION TECHNIQUE UPDATE CCS ARY SBCS = 00037 EBCDIC UPDATE CCS ARY DBCS = 01200 UNICODE UT-16 UPDATE CCS ARY MIXED = 01208 UNICODE UT-8 * *------------------------------------------------------------------- * Sample statements to add/update default data set information *------------------------------------------------------------------- * * File tailoring work data set allocation. * UPDATE FTW DEVICE = SYSALLDA DEVICE TYPE UPDATE FTW ALCUNIT = C C=CYLS, T=TRACKS UPDATE FTW PQTY = 00001 PRIMARY QTY UPDATE FTW SQTY = 00001 SECONDARY QTY *UPDATE FTW SMSDC = xxxxxxxx SMS DATA CLASS *UPDATE FTW SMSSC = xxxxxxxx SMS STORAGE CLASS *UPDATE FTW SMSMC = xxxxxxxx SMS MANAGEMENT CLASS * * Image copy output data set allocation defaults. * UPDATE ICF DEVICE = SYSALLDA DEVICE TYPE UPDATE ICF ALCUNIT = C C=CYLS, T=TRACKS UPDATE ICF PQTY = 00001 PRIMARY QTY UPDATE ICF SQTY = 00001 SECONDARY QTY *UPDATE ICF SMSDC = xxxxxxxx SMS DATA CLASS *UPDATE ICF SMSSC = xxxxxxxx SMS STORAGE CLASS *UPDATE ICF SMSMC = xxxxxxxx SMS MANAGEMENT CLASS *UPDATE ICF MULTIVOL = xxx *UPDATE ICF EXPIREDT = xxxxxxx EXPIRATION DATE *UPDATE ICF RETPERIOD = xxxxxxx RETENTION PERIOD *UPDATE ICF FILENUM = xxxx LABEL FILE NUMBER * * Recovery output data set allocation defaults. * UPDATE RDA DEVICE = SYSALLDA DEVICE TYPE UPDATE RDA ALCUNIT = C C=CYLS, T=TRACKS UPDATE RDA PQTY = 00001 PRIMARY QTY UPDATE RDA SQTY = 00001 SECONDARY QTY *UPDATE RDA SMSDC = xxxxxxxx SMS DATA CLASS *UPDATE RDA SMSSC = xxxxxxxx SMS STORAGE CLASS *UPDATE RDA SMSMC = xxxxxxxx SMS MANAGEMENT CLASS



*UPDATE RDA MULTIVOL = xxx *UPDATE RDA EXPIREDT = xxxxxxx EXPIRATION DATE *UPDATE RDA RETPERIOD = xxxxxxx RETENTION PERIOD *UPDATE RDA FILENUM = xxxx LABEL FILE NUMBER * * System Backup Recovery Services * * IPC_RBR = Y - Generate recovery plans from system level backups * IPC_RBR = N - No recovery plans based on system backups created * UPDATE IPC IPC_RBR = Y Y=generate system level backup * * System Backup Recovery Services Options * UPDATE RBR DEVICE = SYSALLDA *UPDATE RBR EMC LOAD1 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX *UPDATE RBR EMC LOAD2 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX *UPDATE RBR EMC LOAD3 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX *UPDATE RBR EMC LOAD4 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX *UPDATE RBR FDR LOAD1 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX *UPDATE RBR FDR LOAD2 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX UPDATE RBR PROF REPO = DB2TOOLS.DB2RE.PROFILES UPDATE RBR MAPS REPO = DB2TOOLS.DB2RE.PROFILE.MAPS UPDATE RBR CATS REPO = DB2TOOLS.DB2RE.PROFILE.CATS UPDATE RBR SYSBK REPO = DB2TOOLS.DB2RE.SYSBACK UPDATE RBR BKUP VOLS = DB2TOOLS.DB2RE.SYSBACK.VOLS UPDATE RBR BKUP SSID = DB2TOOLS.DB2RE.SYSBACK.SSIDS UPDATE RBR BKUP OBJS = DB2TOOLS.DB2RE.SYSBACK.OBJS UPDATE RBR REPORT REPO = DB2TOOLS.DB2RE.BREPORT UPDATE RBR OFFLD REPO = DB2TOOLS.DB2RE.OFFOPTS UPDATE RBR PARMLIB = DB2TOOLS.DB2RE.V210.D911.SARYSAMP UPDATE RBR PARMLIB MBR = ARY#PARM * � * *------------------------------------------------------------------- * Sample statements for Member SN62 of Group DBN6. *------------------------------------------------------------------- * SET DB2 SSID = SN62 UPDATE DB2 ZPARMS = DSNZPARM UPDATE DB2 BOOTSTRAP1 = DBN6.SN62.BSDS01 UPDATE DB2 BOOTSTRAP2 = DBN6.SN62.BSDS02 UPDATE DB2 LOADLIB1 = SYS1.DSN.SN62.SDSNEXIT UPDATE DB2 LOADLIB2 = SYS1.DSN.V910.SDSNLOAD *UPDATE DB2 LOADLIB3 = *UPDATE DB2 LOADLIB4 = *UPDATE DB2 LOADLIB5 = * *------------------------------------------------------------------- * Sample statements to add/update ARY product plans *------------------------------------------------------------------- * SET DB2 SSID = SN62 SET PRODUCT CFG = NULL SET PRODUCT VER = NULL *



UPDATE ARY PLAN1 = ARYPLAN1 DISPLAY DATA EXTRACT UPDATE ARY PLAN2 = ARYPLAN2 SCHEMA LEVEL REPOSITORY LOAD UPDATE ARY PLAN3 = ARYPLAN3 RECOVERY PLAN GENERATION UPDATE ARY PLAN4 = ARYPLAN4 JCL GENERATION AND SQL EXEC UPDATE ARY PLAN5 = ARYPLAN5 LOG ANALYSIS SERVICES * *------------------------------------------------------------------- * Sample statements to add/update product message library *------------------------------------------------------------------- * UPDATE ARY MSGLIBRARY = SYS1.DB2RE.V210.SARYMENU * *------------------------------------------------------------------- * Sample statements to add/update log services options *------------------------------------------------------------------- * UPDATE ARY ARCHLOG1 = Y USE ARCHIVE LOG 1 UPDATE ARY ARCHLOG2 = N USE ARCHIVE LOG 2 UPDATE ARY ACTLOGPRI = Y ACTIVE LOG PRIORITY * *------------------------------------------------------------------- * Sample statements to add/update data set prefix generation *------------------------------------------------------------------- * * The DSN PREFIX maximum length is 17 characters. If NULL * is specified then user id is used as data set prefix. Use &USERID * in the prefix to insert user id. Example: TEST.&USERID will * generate a data set prefix of 'TEST.MYID' where the user id is * 'MYID'. * *UPDATE ARY DSN PREFIX = DB2TOOLS.DB2RE.&USERID UPDATE ARY DSN PREFIX = &USERID * *------------------------------------------------------------------- * Sample statements to turn on/off recovery options *------------------------------------------------------------------- * UPDATE ARY RCVR AUTHS = Y RECOVER DB2 OBJECT AUTHORIZATIONS * *------------------------------------------------------------------- * Sample statements to add/update schema level repository data * capture options. *------------------------------------------------------------------- * UPDATE SLR LOAD AUTHS = Y N = DB2 authorizations are * not saved in schema level * repository. * *------------------------------------------------------------------- * Sample statements to add/update interproduct communication * options. *------------------------------------------------------------------- * UPDATE IPC IPC_GROUPER = N Y = Enable Grouper-related * table recovery. * *------------------------------------------------------------------- * Sample statements to add/update table activity quiet time * repository names.



*------------------------------------------------------------------- * * EACH QT OWNER/NAME IS A 45 CHAR MAXIMUM LENGTH. THESE OBJECTS WILL * BE CREATED AUTOMATICALLY WHEN THE QUIET TIME REPORT/CAPTURE JCL * IS RUN IF THEY DO NOT ALREADY EXIST. DDL TO CREATE THESE OBJECTS * IS PROVIDED IN ARYDDL7 AND ARYDDL8 SAMPLE DDL MEMBERS. * * XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX UPDATE QT GRP TBOWNER = SYSTOOLS UPDATE QT GRP TBNAME = ARYQTG UPDATE QT GRP IXOWNER = SYSTOOLS UPDATE QT GRP IXNAME = ARYQTGX UPDATE QT ENTRY OWNER = SYSTOOLS UPDATE QT ENTRY NAME = ARYQT * XXXXXXXX (MAX LENGTH FOR DB AND TS IS 8) UPDATE QT DATABASE = SYSTOOLS UPDATE QT TABLESPACE = ARYTSQT * *------------------------------------------------------------------- * Sample statements to add/update log analysis services ROWDATA * VSAM data set attributes. *------------------------------------------------------------------- * * The ROWDATA VSAM data set is dynamically created by the log * analysis services when creating SQL from the log. * * The DSN PREFIX maximum length is 21 characters. The following * set of product controls are required and must be properly set * to ensure proper log data recoveries. The VOLSERS statement * value can be set to blanks, if required. A maximum of 3 volsers * can be specified. * UPDATE LAS DSN PREFIX = DB2TOOLS.DB2RE.V210 UPDATE LAS VOLSERS = UPDATE LAS DATA AUNIT = C UPDATE LAS DATA PQTY = 00005 UPDATE LAS DATA SQTY = 00005 UPDATE LAS INDEX AUNIT = C UPDATE LAS INDEX PQTY = 00005 UPDATE LAS INDEX SQTY = 00005 * *------------------------------------------------------------------- * Sample statements to add/update character conversion information *------------------------------------------------------------------- * * Schema Level Repository Unicode data conversion information. * These values should not be changed. The IBM DB2 Recovery Expert * z/OS components require the following CCSID conversions to be * defined on the target systems. * UPDATE CCS SLR TECHNQ = ER CHARACTER CONVERSION TECHNIQUE UPDATE CCS SLR SBCS = 00037 EBCDIC UPDATE CCS SLR DBCS = 01200 UNICODE UT-16 UPDATE CCS SLR MIXED = 01208 UNICODE UT-8 * * Product output Unicode data conversion information. * UPDATE CCS ARY TECHNQ = ER CHARACTER CONVERSION TECHNIQUE UPDATE CCS ARY SBCS = 00037 EBCDIC



UPDATE CCS ARY DBCS = 01200 UNICODE UT-16 UPDATE CCS ARY MIXED = 01208 UNICODE UT-8 * *------------------------------------------------------------------- * Sample statements to add/update default data set information *------------------------------------------------------------------- * * File tailoring work data set allocation. * UPDATE FTW DEVICE = SYSALLDA DEVICE TYPE UPDATE FTW ALCUNIT = C C=CYLS, T=TRACKS UPDATE FTW PQTY = 00001 PRIMARY QTY UPDATE FTW SQTY = 00001 SECONDARY QTY *UPDATE FTW SMSDC = xxxxxxxx SMS DATA CLASS *UPDATE FTW SMSSC = xxxxxxxx SMS STORAGE CLASS *UPDATE FTW SMSMC = xxxxxxxx SMS MANAGEMENT CLASS * * Image copy output data set allocation defaults. * UPDATE ICF DEVICE = SYSALLDA DEVICE TYPE UPDATE ICF ALCUNIT = C C=CYLS, T=TRACKS UPDATE ICF PQTY = 00001 PRIMARY QTY UPDATE ICF SQTY = 00001 SECONDARY QTY *UPDATE ICF SMSDC = xxxxxxxx SMS DATA CLASS *UPDATE ICF SMSSC = xxxxxxxx SMS STORAGE CLASS *UPDATE ICF SMSMC = xxxxxxxx SMS MANAGEMENT CLASS *UPDATE ICF MULTIVOL = xxx *UPDATE ICF EXPIREDT = xxxxxxx EXPIRATION DATE *UPDATE ICF RETPERIOD = xxxxxxx RETENTION PERIOD *UPDATE ICF FILENUM = xxxx LABEL FILE NUMBER * * Recovery output data set allocation defaults. * UPDATE RDA DEVICE = SYSALLDA DEVICE TYPE UPDATE RDA ALCUNIT = C C=CYLS, T=TRACKS UPDATE RDA PQTY = 00001 PRIMARY QTY UPDATE RDA SQTY = 00001 SECONDARY QTY *UPDATE RDA SMSDC = xxxxxxxx SMS DATA CLASS *UPDATE RDA SMSSC = xxxxxxxx SMS STORAGE CLASS *UPDATE RDA SMSMC = xxxxxxxx SMS MANAGEMENT CLASS *UPDATE RDA MULTIVOL = xxx *UPDATE RDA EXPIREDT = xxxxxxx EXPIRATION DATE *UPDATE RDA RETPERIOD = xxxxxxx RETENTION PERIOD *UPDATE RDA FILENUM = xxxx LABEL FILE NUMBER * * System Backup Recovery Services * * IPC_RBR = Y - Generate recovery plans from system level backups * IPC_RBR = N - No recovery plans based on system backups created * UPDATE IPC IPC_RBR = Y Y=generate system level backup * * System Backup Recovery Services Options * UPDATE RBR DEVICE = SYSALLDA *UPDATE RBR EMC LOAD1 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX *UPDATE RBR EMC LOAD2 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX *UPDATE RBR EMC LOAD3 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX *UPDATE RBR EMC LOAD4 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX



*UPDATE RBR FDR LOAD1 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX *UPDATE RBR FDR LOAD2 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX UPDATE RBR PROF REPO = DB2TOOLS.DB2RE.PROFILES UPDATE RBR MAPS REPO = DB2TOOLS.DB2RE.PROFILE.MAPS UPDATE RBR CATS REPO = DB2TOOLS.DB2RE.PROFILE.CATS UPDATE RBR SYSBK REPO = DB2TOOLS.DB2RE.SYSBACK UPDATE RBR BKUP VOLS = DB2TOOLS.DB2RE.SYSBACK.VOLS UPDATE RBR BKUP SSID = DB2TOOLS.DB2RE.SYSBACK.SSIDS UPDATE RBR BKUP OBJS = DB2TOOLS.DB2RE.SYSBACK.OBJS UPDATE RBR REPORT REPO = DB2TOOLS.DB2RE.BREPORT UPDATE RBR OFFLD REPO = DB2TOOLS.DB2RE.OFFOPTS UPDATE RBR PARMLIB = DB2TOOLS.DB2RE.V210.D911.SARYSAMP UPDATE RBR PARMLIB MBR = ARY#PARM * � * *------------------------------------------------------------------- * Sample statements for Member SN63 of Group DBN6. *------------------------------------------------------------------- * SET DB2 SSID = SN63 UPDATE DB2 ZPARMS = DSNZPARM UPDATE DB2 BOOTSTRAP1 = DBN6.SN63.BSDS01 UPDATE DB2 BOOTSTRAP2 = DBN6.SN63.BSDS02 UPDATE DB2 LOADLIB1 = SYS1.DSN.SN63.SDSNEXIT UPDATE DB2 LOADLIB2 = SYS1.DSN.V910.SDSNLOAD *UPDATE DB2 LOADLIB3 = *UPDATE DB2 LOADLIB4 = *UPDATE DB2 LOADLIB5 = * *------------------------------------------------------------------- * Sample statements to add/update ARY product plans *------------------------------------------------------------------- * SET DB2 SSID = SN63 SET PRODUCT CFG = NULL SET PRODUCT VER = NULL * UPDATE ARY PLAN1 = ARYPLAN1 DISPLAY DATA EXTRACT UPDATE ARY PLAN2 = ARYPLAN2 SCHEMA LEVEL REPOSITORY LOAD UPDATE ARY PLAN3 = ARYPLAN3 RECOVERY PLAN GENERATION UPDATE ARY PLAN4 = ARYPLAN4 JCL GENERATION AND SQL EXEC UPDATE ARY PLAN5 = ARYPLAN5 LOG ANALYSIS SERVICES * *------------------------------------------------------------------- * Sample statements to add/update product message library *------------------------------------------------------------------- * UPDATE ARY MSGLIBRARY = SYS1.DB2RE.V210.SARYMENU * *------------------------------------------------------------------- * Sample statements to add/update log services options *------------------------------------------------------------------- * UPDATE ARY ARCHLOG1 = Y USE ARCHIVE LOG 1 UPDATE ARY ARCHLOG2 = N USE ARCHIVE LOG 2 UPDATE ARY ACTLOGPRI = Y ACTIVE LOG PRIORITY



* *------------------------------------------------------------------- * Sample statements to add/update data set prefix generation *------------------------------------------------------------------- * * The DSN PREFIX maximum length is 17 characters. If NULL * is specified then user id is used as data set prefix. Use &USERID * in the prefix to insert user id. Example: TEST.&USERID will * generate a data set prefix of 'TEST.MYID' where the user id is * 'MYID'. * *UPDATE ARY DSN PREFIX = DB2TOOLS.DB2RE.&USERID UPDATE ARY DSN PREFIX = &USERID * *------------------------------------------------------------------- * Sample statements to turn on/off recovery options *------------------------------------------------------------------- * UPDATE ARY RCVR AUTHS = Y RECOVER DB2 OBJECT AUTHORIZATIONS * *------------------------------------------------------------------- * Sample statements to add/update schema level repository data * capture options. *------------------------------------------------------------------- * UPDATE SLR LOAD AUTHS = Y N = DB2 authorizations are * not saved in schema level * repository. * *------------------------------------------------------------------- * Sample statements to add/update interproduct communication * options. *------------------------------------------------------------------- * UPDATE IPC IPC_GROUPER = N Y = Enable Grouper-related * table recovery. * *------------------------------------------------------------------- * Sample statements to add/update table activity quiet time * repository names. *------------------------------------------------------------------- * * EACH QT OWNER/NAME IS A 45 CHAR MAXIMUM LENGTH. THESE OBJECTS WILL * BE CREATED AUTOMATICALLY WHEN THE QUIET TIME REPORT/CAPTURE JCL * IS RUN IF THEY DO NOT ALREADY EXIST. DDL TO CREATE THESE OBJECTS * IS PROVIDED IN ARYDDL7 AND ARYDDL8 SAMPLE DDL MEMBERS. * * XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX UPDATE QT GRP TBOWNER = SYSTOOLS UPDATE QT GRP TBNAME = ARYQTG UPDATE QT GRP IXOWNER = SYSTOOLS UPDATE QT GRP IXNAME = ARYQTGX UPDATE QT ENTRY OWNER = SYSTOOLS UPDATE QT ENTRY NAME = ARYQT * XXXXXXXX (MAX LENGTH FOR DB AND TS IS 8) UPDATE QT DATABASE = SYSTOOLS UPDATE QT TABLESPACE = ARYTSQT * *-------------------------------------------------------------------



* Sample statements to add/update log analysis services ROWDATA * VSAM data set attributes. *------------------------------------------------------------------- * * The ROWDATA VSAM data set is dynamically created by the log * analysis services when creating SQL from the log. * * The DSN PREFIX maximum length is 21 characters. The following * set of product controls are required and must be properly set * to ensure proper log data recoveries. The VOLSERS statement * value can be set to blanks, if required. A maximum of 3 volsers * can be specified. * UPDATE LAS DSN PREFIX = DB2TOOLS.DB2RE.V210 UPDATE LAS VOLSERS = UPDATE LAS DATA AUNIT = C UPDATE LAS DATA PQTY = 00005 UPDATE LAS DATA SQTY = 00005 UPDATE LAS INDEX AUNIT = C UPDATE LAS INDEX PQTY = 00005 UPDATE LAS INDEX SQTY = 00005 * *------------------------------------------------------------------- * Sample statements to add/update character conversion information *------------------------------------------------------------------- * * Schema Level Repository Unicode data conversion information. * These values should not be changed. The IBM DB2 Recovery Expert * z/OS components require the following CCSID conversions to be * defined on the target systems. * UPDATE CCS SLR TECHNQ = ER CHARACTER CONVERSION TECHNIQUE UPDATE CCS SLR SBCS = 00037 EBCDIC UPDATE CCS SLR DBCS = 01200 UNICODE UT-16 UPDATE CCS SLR MIXED = 01208 UNICODE UT-8 * * Product output Unicode data conversion information. * UPDATE CCS ARY TECHNQ = ER CHARACTER CONVERSION TECHNIQUE UPDATE CCS ARY SBCS = 00037 EBCDIC UPDATE CCS ARY DBCS = 01200 UNICODE UT-16 UPDATE CCS ARY MIXED = 01208 UNICODE UT-8 * *------------------------------------------------------------------- * Sample statements to add/update default data set information *------------------------------------------------------------------- * * File tailoring work data set allocation. * UPDATE FTW DEVICE = SYSALLDA DEVICE TYPE UPDATE FTW ALCUNIT = C C=CYLS, T=TRACKS UPDATE FTW PQTY = 00001 PRIMARY QTY UPDATE FTW SQTY = 00001 SECONDARY QTY *UPDATE FTW SMSDC = xxxxxxxx SMS DATA CLASS *UPDATE FTW SMSSC = xxxxxxxx SMS STORAGE CLASS *UPDATE FTW SMSMC = xxxxxxxx SMS MANAGEMENT CLASS * * Image copy output data set allocation defaults. *



UPDATE ICF DEVICE = SYSALLDA DEVICE TYPE UPDATE ICF ALCUNIT = C C=CYLS, T=TRACKS UPDATE ICF PQTY = 00001 PRIMARY QTY UPDATE ICF SQTY = 00001 SECONDARY QTY *UPDATE ICF SMSDC = xxxxxxxx SMS DATA CLASS *UPDATE ICF SMSSC = xxxxxxxx SMS STORAGE CLASS *UPDATE ICF SMSMC = xxxxxxxx SMS MANAGEMENT CLASS *UPDATE ICF MULTIVOL = xxx *UPDATE ICF EXPIREDT = xxxxxxx EXPIRATION DATE *UPDATE ICF RETPERIOD = xxxxxxx RETENTION PERIOD *UPDATE ICF FILENUM = xxxx LABEL FILE NUMBER * * Recovery output data set allocation defaults. * UPDATE RDA DEVICE = SYSALLDA DEVICE TYPE UPDATE RDA ALCUNIT = C C=CYLS, T=TRACKS UPDATE RDA PQTY = 00001 PRIMARY QTY UPDATE RDA SQTY = 00001 SECONDARY QTY *UPDATE RDA SMSDC = xxxxxxxx SMS DATA CLASS *UPDATE RDA SMSSC = xxxxxxxx SMS STORAGE CLASS *UPDATE RDA SMSMC = xxxxxxxx SMS MANAGEMENT CLASS *UPDATE RDA MULTIVOL = xxx *UPDATE RDA EXPIREDT = xxxxxxx EXPIRATION DATE *UPDATE RDA RETPERIOD = xxxxxxx RETENTION PERIOD *UPDATE RDA FILENUM = xxxx LABEL FILE NUMBER * * System Backup Recovery Services * * IPC_RBR = Y - Generate recovery plans from system level backups * IPC_RBR = N - No recovery plans based on system backups created * UPDATE IPC IPC_RBR = Y Y=generate system level backup * * System Backup Recovery Services Options * UPDATE RBR DEVICE = SYSALLDA *UPDATE RBR EMC LOAD1 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX *UPDATE RBR EMC LOAD2 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX *UPDATE RBR EMC LOAD3 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX *UPDATE RBR EMC LOAD4 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX *UPDATE RBR FDR LOAD1 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX *UPDATE RBR FDR LOAD2 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX UPDATE RBR PROF REPO = DB2TOOLS.DB2RE.PROFILES UPDATE RBR MAPS REPO = DB2TOOLS.DB2RE.PROFILE.MAPS UPDATE RBR CATS REPO = DB2TOOLS.DB2RE.PROFILE.CATS UPDATE RBR SYSBK REPO = DB2TOOLS.DB2RE.SYSBACK UPDATE RBR BKUP VOLS = DB2TOOLS.DB2RE.SYSBACK.VOLS UPDATE RBR BKUP SSID = DB2TOOLS.DB2RE.SYSBACK.SSIDS UPDATE RBR BKUP OBJS = DB2TOOLS.DB2RE.SYSBACK.OBJS UPDATE RBR REPORT REPO = DB2TOOLS.DB2RE.BREPORT UPDATE RBR OFFLD REPO = DB2TOOLS.DB2RE.OFFOPTS UPDATE RBR PARMLIB = DB2TOOLS.DB2RE.V210.D911.SARYSAMP UPDATE RBR PARMLIB MBR = ARY#PARM * � * *------------------------------------------------------------------- * Sample statements for Non Data Sharing DB2 D911.



*------------------------------------------------------------------- * SET DB2 SSID = D911 UPDATE DB2 ZPARMS = DSNZPARM UPDATE DB2 BOOTSTRAP1 = DSN911.BSDS01 UPDATE DB2 BOOTSTRAP2 = DSN911.BSDS02 UPDATE DB2 LOADLIB1 = SYS1.DSN.D911.SDSNEXIT UPDATE DB2 LOADLIB2 = SYS1.DSN.V910.SDSNLOAD *UPDATE DB2 LOADLIB3 = *UPDATE DB2 LOADLIB4 = *UPDATE DB2 LOADLIB5 = * *------------------------------------------------------------------- * Sample statements to add/update ARY product plans *------------------------------------------------------------------- * SET DB2 SSID = D911 SET PRODUCT CFG = NULL SET PRODUCT VER = NULL * UPDATE ARY PLAN1 = ARYPLAN1 DISPLAY DATA EXTRACT UPDATE ARY PLAN2 = ARYPLAN2 SCHEMA LEVEL REPOSITORY LOAD UPDATE ARY PLAN3 = ARYPLAN3 RECOVERY PLAN GENERATION UPDATE ARY PLAN4 = ARYPLAN4 JCL GENERATION AND SQL EXEC UPDATE ARY PLAN5 = ARYPLAN5 LOG ANALYSIS SERVICES * *------------------------------------------------------------------- * Sample statements to add/update product message library *------------------------------------------------------------------- * UPDATE ARY MSGLIBRARY = SYS1.DB2RE.V210.SARYMENU * *------------------------------------------------------------------- * Sample statements to add/update log services options *------------------------------------------------------------------- * UPDATE ARY ARCHLOG1 = Y USE ARCHIVE LOG 1 UPDATE ARY ARCHLOG2 = N USE ARCHIVE LOG 2 UPDATE ARY ACTLOGPRI = Y ACTIVE LOG PRIORITY * *------------------------------------------------------------------- * Sample statements to add/update data set prefix generation *------------------------------------------------------------------- * * The DSN PREFIX maximum length is 17 characters. If NULL * is specified then user id is used as data set prefix. Use &USERID * in the prefix to insert user id. Example: TEST.&USERID will * generate a data set prefix of 'TEST.MYID' where the user id is * 'MYID'. * *UPDATE ARY DSN PREFIX = DB2TOOLS.DB2RE.&USERID UPDATE ARY DSN PREFIX = &USERID * *------------------------------------------------------------------- * Sample statements to turn on/off recovery options *------------------------------------------------------------------- * UPDATE ARY RCVR AUTHS = Y RECOVER DB2 OBJECT AUTHORIZATIONS *



*------------------------------------------------------------------- * Sample statements to add/update schema level repository data * capture options. *------------------------------------------------------------------- * UPDATE SLR LOAD AUTHS = Y N = DB2 authorizations are * not saved in schema level * repository. * *------------------------------------------------------------------- * Sample statements to add/update interproduct communication * options. *------------------------------------------------------------------- * UPDATE IPC IPC_GROUPER = N Y = Enable Grouper-related * table recovery. * *------------------------------------------------------------------- * Sample statements to add/update table activity quiet time * repository names. *------------------------------------------------------------------- * * EACH QT OWNER/NAME IS A 45 CHAR MAXIMUM LENGTH. THESE OBJECTS WILL * BE CREATED AUTOMATICALLY WHEN THE QUIET TIME REPORT/CAPTURE JCL * IS RUN IF THEY DO NOT ALREADY EXIST. DDL TO CREATE THESE OBJECTS * IS PROVIDED IN ARYDDL7 AND ARYDDL8 SAMPLE DDL MEMBERS. * * XXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXXX UPDATE QT GRP TBOWNER = SYSTOOLS UPDATE QT GRP TBNAME = ARYQTG UPDATE QT GRP IXOWNER = SYSTOOLS UPDATE QT GRP IXNAME = ARYQTGX UPDATE QT ENTRY OWNER = SYSTOOLS UPDATE QT ENTRY NAME = ARYQT * XXXXXXXX (MAX LENGTH FOR DB AND TS IS 8) UPDATE QT DATABASE = SYSTOOLS UPDATE QT TABLESPACE = ARYTSQT * *------------------------------------------------------------------- * Sample statements to add/update log analysis services ROWDATA * VSAM data set attributes. *------------------------------------------------------------------- * * The ROWDATA VSAM data set is dynamically created by the log * analysis services when creating SQL from the log. * * The DSN PREFIX maximum length is 21 characters. The following * set of product controls are required and must be properly set * to ensure proper log data recoveries. The VOLSERS statement * value can be set to blanks, if required. A maximum of 3 volsers * can be specified. * UPDATE LAS DSN PREFIX = DB2TOOLS.DB2RE.V210 UPDATE LAS VOLSERS = UPDATE LAS DATA AUNIT = C UPDATE LAS DATA PQTY = 00005 UPDATE LAS DATA SQTY = 00005 UPDATE LAS INDEX AUNIT = C UPDATE LAS INDEX PQTY = 00005



UPDATE LAS INDEX SQTY = 00005 * *------------------------------------------------------------------- * Sample statements to add/update character conversion information *------------------------------------------------------------------- * * Schema Level Repository Unicode data conversion information. * These values should not be changed. The IBM DB2 Recovery Expert * z/OS components require the following CCSID conversions to be * defined on the target systems. * UPDATE CCS SLR TECHNQ = ER CHARACTER CONVERSION TECHNIQUE UPDATE CCS SLR SBCS = 00037 EBCDIC UPDATE CCS SLR DBCS = 01200 UNICODE UT-16 UPDATE CCS SLR MIXED = 01208 UNICODE UT-8 * * Product output Unicode data conversion information. * UPDATE CCS ARY TECHNQ = ER CHARACTER CONVERSION TECHNIQUE UPDATE CCS ARY SBCS = 00037 EBCDIC UPDATE CCS ARY DBCS = 01200 UNICODE UT-16 UPDATE CCS ARY MIXED = 01208 UNICODE UT-8 * *------------------------------------------------------------------- * Sample statements to add/update default data set information *------------------------------------------------------------------- * * File tailoring work data set allocation. * UPDATE FTW DEVICE = SYSALLDA DEVICE TYPE UPDATE FTW ALCUNIT = C C=CYLS, T=TRACKS UPDATE FTW PQTY = 00001 PRIMARY QTY UPDATE FTW SQTY = 00001 SECONDARY QTY *UPDATE FTW SMSDC = xxxxxxxx SMS DATA CLASS *UPDATE FTW SMSSC = xxxxxxxx SMS STORAGE CLASS *UPDATE FTW SMSMC = xxxxxxxx SMS MANAGEMENT CLASS * * Image copy output data set allocation defaults. * UPDATE ICF DEVICE = SYSALLDA DEVICE TYPE UPDATE ICF ALCUNIT = C C=CYLS, T=TRACKS UPDATE ICF PQTY = 00001 PRIMARY QTY UPDATE ICF SQTY = 00001 SECONDARY QTY *UPDATE ICF SMSDC = xxxxxxxx SMS DATA CLASS *UPDATE ICF SMSSC = xxxxxxxx SMS STORAGE CLASS *UPDATE ICF SMSMC = xxxxxxxx SMS MANAGEMENT CLASS *UPDATE ICF MULTIVOL = xxx *UPDATE ICF EXPIREDT = xxxxxxx EXPIRATION DATE *UPDATE ICF RETPERIOD = xxxxxxx RETENTION PERIOD *UPDATE ICF FILENUM = xxxx LABEL FILE NUMBER * * Recovery output data set allocation defaults. * UPDATE RDA DEVICE = SYSALLDA DEVICE TYPE UPDATE RDA ALCUNIT = C C=CYLS, T=TRACKS UPDATE RDA PQTY = 00001 PRIMARY QTY UPDATE RDA SQTY = 00001 SECONDARY QTY *UPDATE RDA SMSDC = xxxxxxxx SMS DATA CLASS *UPDATE RDA SMSSC = xxxxxxxx SMS STORAGE CLASS



*UPDATE RDA SMSMC = xxxxxxxx SMS MANAGEMENT CLASS *UPDATE RDA MULTIVOL = xxx *UPDATE RDA EXPIREDT = xxxxxxx EXPIRATION DATE *UPDATE RDA RETPERIOD = xxxxxxx RETENTION PERIOD *UPDATE RDA FILENUM = xxxx LABEL FILE NUMBER * * System Backup Recovery Services * * IPC_RBR = Y - Generate recovery plans from system level backups * IPC_RBR = N - No recovery plans based on system backups created * UPDATE IPC IPC_RBR = Y Y=generate system level backup * * System Backup Recovery Services Options * UPDATE RBR DEVICE = SYSALLDA *UPDATE RBR EMC LOAD1 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX *UPDATE RBR EMC LOAD2 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX *UPDATE RBR EMC LOAD3 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX *UPDATE RBR EMC LOAD4 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX *UPDATE RBR FDR LOAD1 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX *UPDATE RBR FDR LOAD2 = XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX.XXXXXXXX UPDATE RBR PROF REPO = DB2TOOLS.DB2RE.PROFILES UPDATE RBR MAPS REPO = DB2TOOLS.DB2RE.PROFILE.MAPS UPDATE RBR CATS REPO = DB2TOOLS.DB2RE.PROFILE.CATS UPDATE RBR SYSBK REPO = DB2TOOLS.DB2RE.SYSBACK UPDATE RBR BKUP VOLS = DB2TOOLS.DB2RE.SYSBACK.VOLS UPDATE RBR BKUP SSID = DB2TOOLS.DB2RE.SYSBACK.SSIDS UPDATE RBR BKUP OBJS = DB2TOOLS.DB2RE.SYSBACK.OBJS UPDATE RBR REPORT REPO = DB2TOOLS.DB2RE.BREPORT UPDATE RBR OFFLD REPO = DB2TOOLS.DB2RE.OFFOPTS UPDATE RBR PARMLIB = DB2TOOLS.DB2RE.V210.D911.SARYSAMP UPDATE RBR PARMLIB MBR = ARY#PARM * �



List of relevant APARs DB2 for z/OS APARs:

• PK51979

• PK67026

• PK59406

• PK63968

DB2 Recovery Expert for z/OS APARs:

• PK68446

• PK68494

• PK68510

• PK69860

• PK70216

• PK71142



Related Content and Links SAP Community Network

http://www.sdn.sap.com

SAP on DB2 for z/OS https://www.sdn.sap.com/irj/sdn/db2

SAP on DB2 for z/OS redbooks

Enhancing SAP by using DB2 9 for z/OS, SG24-7239 http://www.redbooks.ibm.com/abstracts/sg247239.html?Open

DB2 UDB for z/OS V8 – Through the Looking Glass and What SAP Found There, SG24-7088 http://www.redbooks.ibm.com/abstracts/sg247088.html?Open

Disk Storage DS8000 http://www.ibm.com/systems/storage/disk/ds8000/

DFSMShsm Fast Replication Services and DS8000 redbooks

IBM TotalStorage Productivity Center for Replication Using DS8000. SG24-7596-00. http://www.redbooks.ibm.com/redpieces/abstracts/sg247596.html?Open

IBM Storage System DS8000 Architecture and Implementation, SG24-6786-04 http://www.redbooks.ibm.com/abstracts/sg246786.html?Open

DFSMShsm Fast Replication Technical Guide, SG24-7069 http://www.redbooks.ibm.com/abstracts/sg247069.html?Open

z/OS V1R8 DFSMS Technical Update, SG24-7435 http://www.redbooks.ibm.com/abstracts/sg247435.html?Open

FlashCopy query (FCQUERY) command http://www.ibm.com/support/docview.wss?uid=isg3S1001398

IBM System Storage Business Continuity IBM System Storage Business Continuity: Part 1 Planning Guide. SG24-6547-03. http://www.redbooks.ibm.com/abstracts/sg246547.html?Open

IBM System Storage Business Continuity: Part 2 Solutions Guide. SG24-6548-00. http://www.redbooks.ibm.com/abstracts/sg246548.html?Open

IBM System Storage Business Continuity Solutions Overview. SG24-6684-01. http://www.redbooks.ibm.com/abstracts/sg246684.html?Open

System z10 http://www.ibm.com/systems/z/

DB2 for z/OS http://www.ibm.com/software/data/db2/zos/

DB2 9 for z/OS: Backup and Recovery I/O Related Performance Considerations, REDP-4452-0 http://www.redbooks.ibm.com/abstracts/redp4452.html?Open

DB2 Cloning Tool for z/OS

http://www-306.ibm.com/software/data/db2imstools/db2tools/db2ct-zos/

http://www.sdn.sap.com/

http://www.ibm.com/systems/storage/disk/ds8000/

http://www.redbooks.ibm.com/redpieces/abstracts/sg247596.html?Open

http://www.ibm.com/support/docview.wss?uid=isg3S1001398

http://www.redbooks.ibm.com/abstracts/sg246547.html?Open



http://www.ibm.com/systems/z/

http://www.ibm.com/software/data/db2/zos/

http://www-306.ibm.com/software/data/db2imstools/db2tools/db2ct-zos/



DB2 Recovery Expert for z/OS

http://www-306.ibm.com/software/data/db2imstools/db2tools/db2re-zos/ DB2 Recovery Expert for z/OS Whitepaper ftp://ftp.software.ibm.com/software/data/db2imstools/db2tools/pdf/DB2_Recovery_Expert_White_Paper-March_2008.pdf Optimizing Restore and Recovery Solutions with DB2 Recovery Expert for z/OS V2.1 SG24-7606-00 http://www.redbooks.ibm.com/abstracts/sg247606.html?Open SAP System Copy Guide http://service.sap.com/instguides

http://www-306.ibm.com/software/data/db2imstools/db2tools/db2re-zos/

ftp://ftp.software.ibm.com/software/data/db2imstools/db2tools/pdf/DB2_Recovery_Expert_White_Paper-March_2008.pdf

ftp://ftp.software.ibm.com/software/data/db2imstools/db2tools/pdf/DB2_Recovery_Expert_White_Paper-March_2008.pdf


http://service.sap.com/instguides



Copyright © 2008 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, Outlook, and PowerPoint are registered trademarks of Microsoft Corporation.

IBM, DB2, DB2 Universal Database, OS/2, Parallel Sysplex, MVS/ESA, AIX, S/390, AS/400, OS/390, OS/400, iSeries, pSeries, xSeries, zSeries, System i, System i5, System p, System p5, System x, System z, System z9, z/OS, AFP, Intelligent Miner, WebSphere, Netfinity, Tivoli, Informix, i5/OS, POWER, POWER5, POWER5+, OpenPower and PowerPC are trademarks or registered trademarks of IBM Corporation.

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 Sun Microsystems, Inc.

JavaScript is a registered trademark of Sun Microsystems, Inc., used under license for technology invented and implemented by Netscape.

MaxDB is a trademark of MySQL AB, Sweden.

SAP, R/3, mySAP, mySAP.com, xApps, xApp, SAP NetWeaver, 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 in several other countries all over the world. 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.

These materials are provided “as is” without a warranty of any kind, either express or implied, including but not limited to, the implied warranties of merchantability, fitness for a particular purpose, or non-infringement.

SAP shall not be liable for damages of any kind including without limitation direct, special, indirect, or consequential damages that may result from the use of these materials.

SAP does not warrant the accuracy or completeness of the information, text, graphics, links or other items contained within these materials. SAP has no control over the information that you may access through the use of hot links contained in these materials and does not endorse your use of third party web pages nor provide any warranty whatsoever relating to third party web pages.

Any software coding and/or code lines/strings (“Code”) included in this documentation are only examples and are not intended to be used in a productive system environment. The Code is only intended better explain and visualize the syntax and phrasing rules of certain coding. SAP does not warrant the correctness and completeness of the Code given herein, and SAP shall not be liable for errors or damages caused by the usage of the Code, except if such damages were caused by SAP intentionally or grossly negligent.

Casebook: DB2 backup, recovery and cloning for SAP environments · 2019-11-12 · SAP Labs in Walldorf and St.Leon-Rot and works on all aspects of the usage of DB2 for z/OS for SAP

Documents