1

Goetschy AndréUBS AG, Switzerland

G08

Tuesday, October 03, 2006 • 4:45 p.m. – 05.45 p.m.

Platform: z/OS

DB2 V8 'SYSTEM-BACKUP/-RESTORE'

(Issues and Alternatives for UBS AG)

2

2

Purpose/Contents/TopicsThe purpose of this presentation is to show and explain the new DB2 Version 8 B/R featuresand compare them with the processes already in place at UBS AG to fulfill our requirements inthe area of

DB2 SYSTEM-BACKUP and –RESTORE

abbreviated 'DB2SBR' in this document which covers the following topics:• DB2SBR – Announcement• DB2SBR - Prerequisites and Requirements• New z/OS 1.5 DFSMS enhancements exploited by the DB2SBR utilities• DB2SBR - Sample Environment• The DB2 V8 DB2SBR Utilities• New Recovery Opportunities:

Scenario 1. Recovery to an arbitrary point in timeScenario 2. Recovery to the point in time of a backupScenario 3. Using backups from FlashCopy

• DB2SBR – Summary• SVCF – Purpose, Functions and Processing Modes• SVCF - Sample Environment• Comparison between DB2SBR and SVCF• DB2SBR – Pros./Cons.• SVCF – Pros./Cons.• Conclusion and Recommendations

3

3

The DB2 for z/OS environment at UBS (Mid. 2006)

InvestmentBanking

SSP WMUSWeehawken

Stamford London Asia

SharedGlobal

SharedDivisions

SharedData

LocalPlexes

The DB2 at UBS

85 TB of DB2data processedin // sysplexenvironments

65 DB2 sub-systems(4 SAP)

17 group-attachmembers

for Prod.:12 way

//-SYSPLEX (with GDPS)Legacy + SAP DB2's looselycoupled via DRDA

WM&BB IB

Wealth Management&Business Banking

UPl

ex(P

rod.)

DPl

exEPl

exFP

lex

GPl

exN

Plex

SPl

ex1

QPl

ex1

LPle

x1

JPle

x1IP

lex1

MPl

ex1

RPl

ex1

APl

ex2

APl

ex3

APl

ex4

Z990 with z/OS 1.6 ~ 70'000 MIPS

OPl

exTple

xPp

lex

GCU

Bple

x1Kple

x1

4

4

DB2SBR - Announcement

"Provides more improved usability, more easier, more flexible, less disruptive,faster backup/recovery at system-level instead of DB2 object-levelbackup/recovery (eg. traditional B/R based on DB2 Image-Copy)"

Two new utilities:

• BACKUP SYSTEM: Fast volume-level backups

• RESTORE SYSTEM: Fast volume-level restoreRecover to arbitrary point-in-time

5

5

DB2SBR - Prerequisites and Requirements

• DB2 z/OS Version 8 running in New Function Mode. (These utilities are not supported in Compatibility Mode.)

• z/OS 1.5 or above. • DASD control units that support the Flash Copy. • All the DB2 datasets, including the DB2 catalog, DB2 directory and DB2 logs, must

be DFSMS managed. • New DFSMS constructs for 'copy pools' and 'copy pool storage groups' must be

defined (details on the next 2 foils). • Different ICF catalogs for database copy pool and log copy pool.• Remote mirror for volumes defined in the copy pool storage group.

6

6

Creation of the mandatory DFSMS constructs (1 of 2)

Defining a 'Copy Pool' • Identify source Storage Groups to be 'copied' .• Define the Copy Pool Backup Storage Group(s). (via ISMF 'Backup Storage Group

Define' panel.)• Verify that there is a sufficient number of eligible(*) target volumes in the specified copy

pool backup storage group.

* An eligible target volume must meet the following requirements: • Have the same track format as the source volume/model. • Be the exact size of the source volume/model.

• Indicate its name on the associated source Pool Storage Group. (via ISMF 'Pool StorageGroup Define/Alter' panel.)

• Define Copy Pool(s). (via ISMF 'Copy Pool Define' panel.)CAUTION: Use the following DB2 naming convention when you define copy pools :

• DSN$locn-name$DB (database pool)• DSN$locn-name$LG (log pool)

7

7

Creation of the mandatory DFSMS constructs (2 of 2)

Keep enabled the Fast Replication Backup(Control and maintenance tasks)

• For DFSMShsm to copy each source volume in a storage group, enougheligible target volumes must exist in the copy pool backup storage group tosatisfy the needs of the number of specified backup versions.

• You should use the PREPARE keyword of DFSMShsm FRBACKUPcommand whenever there is a change in the fast replication environment.This PREPARE processing enables validation of the fast replicationenvironment outside the backup window.

• Changing any of the following definitions will change the fast replicationenvironment:

• The volumes in the pool or copy pool backup storage groupare changed or removed.

• The number of backup versions for DFSMShsm to maintainis changed.

• The storage groups defined to the copy pool have changed.

8

8

New z/OS 1.5 DFSMS enhancements exploited by the DB2SBR utilities (1 of 2)

• DFSMSdss (ADRDSSU)COPY FULL or COPY DATASET supports FASTREPlication (Flash Copy) to move data.

• DFSMShsmNew commands that internally uses ADRDSSU copy function with fast replication:

FRBACKUP COPYPOOL(cpname)FRRECOV COPYPOOL(cpname)FRRECOV TOVOL(volser) FROMCOPYPOOL(cpname)

9

9

New z/OS 1.5 DFSMS enhancements exploited by the DB2SBR utilities (2 of 2)

• 'Copy Pools'Are pools of DFSMS storage groups that can be backed up or restored with a single

command using the copy pool name. Two source pools are needed for the backup/restore system utilities.

1. Database Copy Pool for storage groups associated with the DB2 catalog, DB2 directory, DB2 objects and ICF catalog for DB2 objects.

2. Log Copy Pool for storage groups associated with the DB2 logs BSDS and ICF catalog

One target pool: the Copy Pool Backup Storage Group which is a DFSMS storage group that contains the target DASD volumes that will be used to back up the source volumes.

10

10

Copy Pool Backup Storage Group

Storage Group for

DB2 LogsBSDS

ICFCTLG

LOG001 LOG002 LOG003

Storage Group for

DB2 CatalogDB2 Directory

ICFCTLG

SYS001 SYS002 SYS003

Storage Group for

User Data

VOL001 VOL002 VOL003

Log Copy Pool Database Copy Pool

BK0001 BK0002 BK0003 BK0006 BK0007 BK0008 BK0009BK0004 BK0005

DB2SBR - Sample Environment

11

11

The DB2 V8 DB2SBR Utilities (1 of 2)

• BACKUP SYSTEM BACKUP SYSTEM DATA ONLY will backup only volumes defined in storage groups in the database copy pool.BACKUP SYSTEM FULL will backup the log and database copy poolBackup System utility will:

Update DFSMShsm control data sets with a token value to identify the backup. The token value is generated by DB2 and includes the Recovery Based Log Point value.Update the Backup History section of the BSDS and the header page ofDBD01 (Directory) with the Recovery Based Log Point (RBLP) . (The RBLP value is the most recent system checkpoint prior to the Backup System utility being run. The RBLP will be used as the starting point for applying log records during the log apply phase of the Restore System utility).Invoke DFSMShsm services (FRBACKUP) to backup the DB2 copy pools.

12

12

The DB2 V8 DB2SBR Utilities (2 of 2)

• RESTORE SYSTEMInvokes DFSMShsm services (FRRCOV) to recover the database copy pool. RESTORE SYSTEM will not restore log volumes, which the BACKUP SYSTEM FULL utility creates. After restoring the data, this utility can then recover to an arbitrary point in time. RESTORE SYSTEM automatically handles any creates, drops, and LOG NO events thatmight have occurred between the backup and the recovery point in time.

• DSNJU003 utility (New option for CRESTART statement):SYSPITR=log-truncation-pointSpecifies the log RBA or the log LRSN that represents the log truncation point for the point-in-time for system recovery. Before you run the RESTORE SYSTEM utility to recover data, you must use the SYSPITR option of DSNJU003. This option enables you to create a Conditional Restart Control Record (CRCR) to truncate the logs for system point-in-time recovery.

13

13

Scenario 1. Recovery to an arbitrary point in time (1 of 2)

To minimize the amount of business data that you lose when you recover, recover to an arbitrary point in time.

To recover to an arbitrary point in time, you must perform the following backup and recovery procedures:

Backup:

You must perform the following procedure before an event occurs that creates a need torecover your DB2 system:

Use BACKUP SYSTEM DATA ONLY to take the backup. You can also take a FULL backup, although it is not needed.

14

14

Recovery:If you have performed the appropriate backup procedures, you can use the followingprocedure to recover your DB2 system to an arbitrary point in time:

Stop the DB2 subsystem. If your system is a data sharing group, stop all members of the group.

Run DSNJU003 (change log inventory) with the CRESTART SYSPITR option specifying the log truncation point that corresponds to the point in time to which you want to recover the system. For data sharing systems, run DSNJU003 on all active members of the data-sharing group, and specify the same LRSN truncation point for each member.Note: If the point in time that you specify for recovery is prior to the oldest system backup, you must manually restore the volume backup from tape.

Start DB2. For data sharing systems, start all active members. ( they will be in 'recovery-pending' and 'access=maint' mode)

Submit the RESTORE SYSTEM utility job (= Restore to 'RBPL' + logapply to 'SYSPITR'. )

Stop + Start (all) DB2 (members) to remove the 'recovery-pending' and 'access=maint' mode

Scenario 1. Recovery to an arbitrary point in time (2 of 2)

15

15

Scenario 2. Recovery to the point in time of a backup (1 of 2)

Recovery to the point in time of a backup minimizes the amount of time that is requiredfor recovery. You can recover using backups that either the BACKUP SYSTEM utility or FlashCopycreate. Using backups from BACKUP SYSTEM to recover a DB2 system to the point in time of aback up that the BACKUP SYSTEM utility creates, you must perform the following backup andrecovery procedures:

Backup:

You must perform the following procedure before an event occurs that creates a need to recover your DB2 system.

Use BACKUP SYSTEM FULL to take the system backup. DFSMShsm can maintain up to 50 versions of system backups on disk at any given time.

16

16

Recovery:

If you have performed the appropriate backup procedures, you can use the following procedure to recover your DB2 system to the point in time of a backup:

Stop the DB2 subsystem. For data sharing systems, stop all members of the group.

Use the DFSMShsm command FRRECOV * COPYPOOL(cpname) GENERATION(gen) to restore the database and log copy pools that the BACKUP SYSTEM utility creates. In this command, cpname specifies the name of the copy pool, and gen specifies which versionof the copy pool is restored.

For data sharing systems, delete all CF structures that are owned by this group.

Start DB2. For data sharing systems, start all active members.

For data sharing systems, execute the GRECP and LPL recovery, which recovers the changed data that was stored in the coupling facility at the time of the backup.

Scenario 2. Recovery to the point in time of a backup (2 of 2)

17

17

Scenario 3. Using backups from FlashCopy (1 of 2)

To recover a DB2 system to the point in time of a backup that FlashCopy creates, you must perform the following backup and recovery procedures. For more information about the FlashCopyfunction, see z/OS DFSMS Advanced Copy Services.

Backup:

You must perform the following procedure before an event occurs that creates a need to recover your DB2 system:

Issue the DB2 command SET LOG SUSPEND to suspend logging and update activity, and to quiesce 32K page writes and data set extensions. For data sharing systems, issue the command to each member of the group. Use the FlashCopy function to copy all DB2 volumes. Include any ICF catalogs that are used by DB2, as well as active logs and BSDSs. Issue the DB2 command SET LOG RESUME to resume normal DB2 update activity. To save disk space, you can use DFSMSdss to dump the disk copies you just created to a lower-cost medium, such as tape.

18

18

Recovery:

If you have performed the appropriate backup procedures, you can use the following procedureto recover your DB2 system to the point in time of a backup:

Stop the DB2 subsystem. For data sharing systems, stop all members of the group. Use DFSMSdss RESTORE to restore the FlashCopy data sets to disk. See z/OS DFSMSdss Storage Administration Reference for more information. For data sharing systems, delete all CF structures that are owned by this group. Start DB2. For data sharing systems, start all active members. For data sharing systems, execute the GRECP and LPL recovery, which recovers the changed data that was stored in the coupling facility at the time of the backup.

Scenario 3. Using backups from FlashCopy (2 of 2)

19

19

DB2SBR - Summary

• The new utilities are Backup System and Restore System• Provides a robust backup and restore solution at the DB2 system level instead of the

DB2 object level • Provides functionality for backing up and restoring an entire DB2 subsystem utilizing

a DASD volume dump methodology • Vendor neutral environment (provided the DASD vendor supports the Flash Copy API)• Most beneficial in a DB2 z/OS ERP environment, such as SAP

Can be useful:• For any DB2 z/OS environment where Backup is done at system-level and Point-in-

time recovery and/or Conditional-Restart is affordable • For Disaster recovery • For Cloning of the DB2 subsystem

20

20

• SVCF (Switch Volumes Control Facility) has been developed and implemented by UFD Solutions AG in order to fulfill the requirements of UBS in the area of 'Massive-recovery' (2001-2003) and is still in place for the daily SPLIT and SYNC of our productive SAP DB2 subsystem.

• SVCF is a generator of HDS and EMC commands and utilities impacting the hardware which also performs various checks, needed to ensure consistency and processcompleteness, when operating the hardware.

• In this concept the product has been set up with JCL procedures and parameter members. It mainly uses the Mirror Device Configuration Table (MDCT) as input.

• Main functions : • SPLIT stop the copying of changed data from the source volume to the

target volume • SYNC re-establish the source and target volume pairs • RESTORE reverse/synchronize the volumesThe following modes are supported for these functions:

• EXECUTE = Generate and execute the relevant commands or utilities directly.

• GENJCL = Generate JCL for handling mirror volumes to be submitted it at later time.

• TEST = Simulate the execution for testing purposes

SVCF – Purpose, Functions and Processing Modes

21

21

• Mirroring of volumes is a storage-based hardware solution for duplicating logical volumes which reduces backup time and provides point-in-time recovery opportunities.

• SVCF is a batch Tool designed to handle groups of logical related, but vendor independent, volumes and their mirrors defined in one or more storage group(s).

• The SVCF functions allow to process/manipulate a big amount of volumes (HDS and/or EMC) together with one invocation step, without knowledge of vendor specific commands and utilities.

SVCF - Sample Environment KeyTools www.ubs.com/keytools

SVCF_process.ppt december, 2004

Site 1 Local Site 2 Remote

Source"L ive Version"

Target"Backup Version"

Shadow Image

BCV

Shadow Image

PPRC/SRDF

EMC HDSEMC HDS

VolumeVolume MirroringMirroring

MDCT

22

22

Comparison between DB2SBR and SVCF

Y (Parallel Jobs, sinceVersion 2)Y (Multitasking)Parallel processing

NYDFSMShsm, FRBACKUP/FRRECOV exploitation

None (already in place in UBS)

I= 6-8 PW, T= 2-3 PW ,E = 1PWEstimated effort to provide (Implem., Test and Educ.)

YNStorage Groups exploitation

NYBackup (of backup versions) to Tape

only 1up to 50Backup Versions

NYCopy Pool Storage Group exploitation

NYCopy Pool exploitation

Shadow image (HDS) / BCV (EMC)Flash CopyTechnology

NYCloning of the DB2 subsystem

Y (with GDPS)Y (GDPS or Backup on Tape)Disaster recovery

NYPoint-in-time recovery

YYRESTORE at SYSTEM-Level

YN'-Set Log Suspend' during Backup

Y (SPLIT Mirror using Stogroups)

Y (using Database Copy Pool)BACKUP SYSTEM DATA ONLY

YYBACKUP SYSTEM FULL

SVCFDB2SBRCharacteristics / issues

23

23

DB2SBR – Pros./Cons.

• PROS:Less disruptive backup ('-SET LOG SUSPEND' not required)System Backup/Restore with single commandsAutomatic selection of target volumes for backup (HSM)Multiple backup versions (up to 50)Backup volumes can be archived to tape (HSM outside of DB2)Recovery to any point in time is possible

• CONS:Additional administrative effort for Recovery (see 'recovery scenario 1-3')The restore of volumes added, removed or assigned to another storagegroup in another copy pool since the last backup, must be handledmanuallyRelatively big implementation, testing and education effort to provide(at UBS: 9-12 PW's)

24

24

SVCF – Pros./Cons.

• PROSVery fast backup (simply split of local mirror) Parallel executionEasy handling of new (additional) volumesNo additional administrative effortGDPS concept and solution availableAlready in place at UBS

• CONS:

Only one backup versionDisruptive Backup ('-SET LOG SUSPEND' required)Recovery only to the point in time of a backupFlash Copy not supported In case of restore, the volumes must be varied offline

25

25

Conclusion and Recommendations (1of 2)

• The new z/OS 15 DFSMS enhancements are very well exploited by DB2 Version 8and allows a quasi 'non disruptive' backup an entire DB2 subsystem at 'system-level'.

• However, the 'recover'-process is relatively complicated and error-prone and does not allow 'recover to current' ( work processes may be lost)

• The new DFSMShsm-commands (FRBACKUP and FRRECOV) could allow:- to simplify the SVCF process (exploit them, instead of generating EMC and/or

HDS commands and utilities)- to enhance the SVCF process (elimination of the 'SET LOG SUSPEND')

• As long UBS can afford '-SET LOG SUSPEND' for 'Massive Recovery' of its SAP subsystems, SVCF could stay as is.

• If SVCF is intended to be used for additional/other 'mirror handling' purposes at UBS, a 'face-lifting' of the process (by exploiting FRBACKUP and FRRECOV) should be taken into consideration.

26

26

Conclusion and Recommendations (2 of 2)

• If UBS has a urgent and real need for a quicker and less disruptive backupallowing a PIT recovery of its SAP and SSP DB2-Objects (eg. to begin of TEV) , an implementation of DB2SBR should be taken into consideration once we are in DB2 V8 NFM.

• The current IBM's ' DB2SBR' as well as the UBS's 'SVCF' can only processVOLUMES within Storagegroups constructs.

• IBM has announced that with DB2 V9 will allow 'DB2 SYSTEM-BACKUP and –RESTORE' at DATASET (Table-/index-space) LEVEL.

• Once we have this opportunity we will (for sure) go towards DB2SBR becausethis will considerably enhance and leverage our current tactical DB2 Backup/Recovery processes based on Image-Copy in our huge DB2 environment (Approx. 85 TB of mission critical DB2 data)

27

27

Goetschy AndréUBS AG, Switzerland

andre.goetschy@ubs.com

G08DB2 V8 'SYSTEM-BACKUP/-RESTORE'

(Issues and Alternatives for UBS AG)