FlashCopy and DB2 for z/OS

Florence Dubois IBM DB2 for z/OS Development [email protected]

FlashCopy and DB2 for z/OS

mailto:[email protected]

© Copyright IBM Corporation 2015. All rights reserved.

U.S. Government Users Restricted Rights - Use, duplication or disclosure restricted by GSA ADP Schedule Contract with IBM

Corp.

THE INFORMATION CONTAINED IN THIS DOCUMENT HAS NOT BEEN SUBMITTED TO ANY FORMAL IBM TEST AND IS

DISTRIBUTED AS IS. THE USE OF THIS INFORMATION OR THE IMPLEMENTATION OF ANY OF THESE TECHNIQUES IS A

CUSTOMER RESPONSIBILITY AND DEPENDS ON THE CUSTOMER’S ABILITY TO EVALUATE AND INTEGRATE THEM INTO THE

CUSTOMER’S OPERATIONAL ENVIRONMENT. WHILE IBM MAY HAVE REVIEWED EACH ITEM FOR ACCURACY IN A SPECIFIC

SITUATION, THERE IS NO GUARANTEE THAT THE SAME OR SIMILAR RESULTS WILL BE OBTAINED ELSEWHERE. ANYONE

ATTEMPTING TO ADAPT THESE TECHNIQUES TO THEIR OWN ENVIRONMENTS DO SO AT THEIR OWN RISK.

ANY PERFORMANCE DATA CONTAINED IN THIS DOCUMENT WERE DETERMINED IN VARIOUS CONTROLLED LABORATORY

ENVIRONMENTS AND ARE FOR REFERENCE PURPOSES ONLY. CUSTOMERS SHOULD NOT ADAPT THESE PERFORMANCE

NUMBERS TO THEIR OWN ENVIRONMENTS AS SYSTEM PERFORMANCE STANDARDS. THE RESULTS THAT MAY BE OBTAINED

IN OTHER OPERATING ENVIRONMENTS MAY VARY SIGNIFICANTLY. USERS OF THIS DOCUMENT SHOULD VERIFY THE

APPLICABLE DATA FOR THEIR SPECIFIC ENVIRONMENT.

Trademarks

IBM, the IBM logo, ibm.com, DB2, FlashCopy, GDPS, Redbooks, System z and z/OS are trademarks of International Business Machines

Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A

current list of IBM trademarks is available on the Web at “Copyright and trademark information” at www.ibm.com/legal/copytrade.shtml.

Disclaimer/Trademarks

2

http://www.ibm.com/legal/copytrade.shtml

http://www.ibm.com/legal/copytrade.shtml

© 2015 IBM Corporation

Agenda

• FlashCopy overview

• FlashCopy outside of DB2’s control

• FlashCopy and DB2 for z/OS utilities

• FlashCopy and IBM Remote Copy Services

3


FlashCopy Overview

• IBM FlashCopy (FC)

– Optional licensed feature available on IBM disk storage systems as well as non-IBM

• Creates an instant copy of a volume or a dataset at a specific point-in-time

– Initial logical FC phase (also called establish)

• After the logical FC, read and write activity are possible on both source and target devices

– Physical FC phase (also called background copy)

• Advantages

– Can copy huge volumes of data very quickly (seconds to a few minutes)

– Minimal disruption for the running applications

– Copy process is offloaded to the storage subsystem -> opportunity to lower host CPU

4

Copy FC

NoCopy FC

Incremental FC

Space-efficient FC

Consistency Group FC

Remote Pair FC

Fast Reverse Restore Volume-level FC

Dataset-level FC

FlashCopy Overview …

S

T

1

0

0

0

0

1

0

Establish phase – Logical FlashCopy A FlashCopy relationship between source and target is established within seconds A bitmap tracks the relationship between source and target tracks No writes are allowed to the volumes during this phase

S

T

1

0

0

0

0

1

0

Read and write activity are possible on both the source and target devices

Writes to the source will cause a ‘copy-on-write’ (a.k.a. on-demand copy) if the track has not been copied to the target – done asynchronously when the write is destaged onto disk Reads of tracks on the target that have not been copied from the source will be redirected to the source

S

T

1

0

0

0

0

1

0

Background copy phase – Physical FlashCopy (optional) Copy tracks from the source to the target When all tracks have been copied to the target volume, the FC relationship automatically ends unless the persistent FC option was specified

5



• Distributed interfaces

– Command-line interface (DS CLI)

– Web-based graphical user interface (DS Storage Manager GUI)

– IBM TotalStorage Productivity Center for Replication (TPC-R)

• Additional interfaces for z/OS users

– TSO commands

– ICKDSF

– ANTRQST application programming interface (API)

– IBM System Storage FlashCopy Manager

– DFSMSdss

6

Interface used by DB2 for z/OS utilities Invoked either directly via the DFSMSdss COPY command or via DFSMShsm Fast Replication commands (FRBACKUP/FRRECOV)

Whether dss COPY calls FC depends on the FASTREPLICATION keyword PREFERRED (default) – use FC if possible, otherwise ‘traditional’ COPY REQUIRED – if FC cannot be used, COPY fails NONE – always use ‘traditional’ COPY



• Volume-level FC

– Source and target must be on the same physical disk subsystem (within any LSS)

– Require one target volume per source volume

– Target volume must be the same size or bigger than the source volume

– Target and source must have the same logical track format

– A source volume can have up to 12 target volumes (multiple relationship FC)

– Any target volume can only be in one FC relationship at a time

• Dataset-level FC

– All types of z/OS data sets are supported (sequential, partitioned, VSAM data sets)

– No location restriction – can copy to same volume

– Source and target data set must be fully contained on the same physical control unit

– At any point-in-time, a data set can be only a source or a target

• Special considerations apply when combining FC with Remote Copy Services

– Will be discussed later in this presentation

7



• Full background COPY (default for ‘standard’ FC)

– All tracks from the source are copied to the target

– Option available for volume and dataset level FC

– 1:1 space requirements

– FC relationship ends as soon as all data is copied (unless it is defined as persistent)

– How long the actual physical copy takes depends on

• The amount of data being copied

• The number of background copy processes that are occurring

• The other activities on the ESS

– Background copy task runs at a lower priority than normal I/O, so as not to affect the normal

application I/O processing

8

Volume-level FC

Dataset-level FC



• NOCOPY

– Suppresses the background copy

• Only copy source tracks before they are updated for the first time after FC (‘copy-on-write’)

– Option available for volume and dataset level FC

– 1:1 space requirements

• Still require one target volume per source volume for volume-level FC

– Relationship will last until it is explicitly withdrawn or until all data in the source volume has

been modified

– Target volume becomes unusable if the relationship is withdrawn before all of the source

tracks are copied to the target

• Track data on the target device is unpredictable

– Typical usage: Transient copy e.g. backup to be dumped immediately to tape

9

FCNOCOPY option on the DFSMSdss COPY command

Volume-level FC

Dataset-level FC



• Incremental volume-level FC

– Option available only for volume-level FC

– ‘Refresh’ target volume

• Copy only source tracks that have changed since the last incremental FC was taken

– Advantages

• Minimize I/O impact of the background physical copy

• Considerably reduce elapsed time of the physical copy

– Incremental FC g DB2 Incremental IC

• Initial incremental FC invocation results in a full background copy

• Subsequent incremental FC result in ‘delta’ copy

• Resulting backup is always a ‘full’ backup

– 1:1 space requirements (one target volume per source volume)

– Restriction: Only one target can be defined as incremental FC

• DS8870 Release 7.4 supports Multiple Incremental FC: up to 12 targets from a single source

– Relationship will last until it is explicitly withdrawn

10

FCINCREMENTAL on DFSMSdss COPY command

Volume-level FC



• Space Efficient FlashCopy

– Separate optional licensed feature – can coexist with ‘standard’ FC

– Volume-level only and background copy is not allowed (always NOCOPY)

– Uses ‘virtual’ Space Efficient volumes as target volumes and a repository

• Only uses the space needed for updates to the source volume (thin provisioning)

11

FCSETGTOK(FAIL) option on DFSMSdss COPY command

Volume-level FC



• Space Efficient FlashCopy …

– Attractive cost proposition but trade-offs in terms of performance and function

• FlashCopy SE has additional overhead compared to standard FC

– FlashCopy SE is optimised for use cases where about 5% of the source volume is updated during

the life of the relationship

– Typical use case: transient backup to be dumped immediately to tape

• Creating more than one FlashCopy SE relationship for a source volume increases the overhead

because each first change to a source track has to be copied several times

– Should keep the number of concurrent FlashCopy SE relationships to a minimum

• FlashCopy SE cannot be used in conjunction with Remote Pair FlashCopy

– Requires careful planning

• Essential to size the repository properly

– Amount of space that is needed depends on two factors

» The data change rate on the source volumes

» The lifetime of the FlashCopy SE relationship

– Cannot expand the repository capacity after it is created

12

Volume-level FC



• Fast Reverse Restore (FRR)

– Option to restore a FC source from its FC target without having to wait for completion of the

background copy operation

– Only available for full volume FC

– It is possible to have multiple FC targets and use FRR to restore any ONE of them

• But before using FRR on one of the relationships, all other FC relationships must be withdrawn –

otherwise the FRR request will fail

– Once FRR completes, the content of the DASD backup volume becomes invalid

– Can be used for standard FC and FlashCopy SE

– Restriction: Cannot be used in conjunction with Remote Pair FlashCopy

13

FCFASTREVERSERESTORE option on DFSMSdss COPY

Volume-level FC


FlashCopy Outside of DB2’s Control

• Typical usage scenarios

– Local or remote point-in-time backup of the entire system

• Mass data recovery

• Plan B for Disaster Recovery

• Protection during DASD mirror resynchronisation

– Testing capability for Disaster Recovery

– Quick cloning of the environment

• Test or QA

• ‘Forensic’ system to investigate data corruption

• Business analytics

• Important planning consideration

– Must ensure that the ICF user catalogs stay synchronized with the data

• ICF user catalog(s) for DB2-related system and application data must be part of the FC

• Recommendation: Do not share these ICF user catalog with non-DB2 data

14


FlashCopy – System-Level Recovery Outside of DB2’s Control …

• Backup

– Need to guarantee the I/O consistency of the FlashCopy backup

– Option 1: Use DB2 command -SET LOG SUSPEND to temporarily ‘freeze’ DB2 update activity

• After all volumes have completed the FC Establish phase, issue -SET LOG RESUME

– Option 2: Use Consistency Group FC

• Hold off write I/O to the source volumes until FC establish is completed for all volumes

– Volumes are put in extended long busy state until the CGCREATED command is issued or a

timeout is reached (2 minutes by default) not 100% transparent to the applications!

• Use option FCCGVERIFY on CGCREATE to determine if the copy is consistent

• Advantage: Can include non-DB2 data in the backup

• Recovery

– Need to use DB2 warm restart recovery to re-establish application consistency

• FlashCopy backup is a ‘fuzzy’ copy - Cannot be used as-is

– For data sharing systems, must delete all CF structures before the DB2 restart

– With Option 1, can also use RESTORE SYSTEM LOGONLY to bring the system forward (requires

-SET LOG SUSPEND to set RBLP – starting point for the recovery)

FCCGFREEZE option on DFSMSdss COPY

15


FlashCopy – Application-Level Recovery outside of DB2’s control

• Scope

– Pool of volumes containing all objects for one application + associated ICF catalog

• No DB2 warm restart recovery to re-establish application consistency

– Application consistency must be established at the time of the backup

• Start all table spaces to be copied in read only (RO) status

• Run a QUIESCE with WRITE(YES) on all table spaces to be copied

• FlashCopy

• Start all table spaces in read-write (RW) status

16


FlashCopy and DB2 for z/OS Utilities

• IBM DB2 for z/OS utilities makes more and more use of FlashCopy

17

V8 • BACKUP SYSTEM

• RESTORE SYSTEM

• Dataset FC support for CHECK INDEX SHRLEVEL CHANGE

V9 • Incremental FC for BACKUP SYSTEM

• Dataset FC for RECOVER with system-level backup (SLB) as input

• Dataset FC for CHECK DATA SHRLEVEL CHANGE and CHECK LOB SHRLEVEL CHANGE

V10 • Dataset FC for COPY

• Dataset FC for inline copy in REORG TABLESPACE, REORG INDEX, REBUILD INDEX, LOAD

• FC image copies with consistency and no application outage (SHRLEVEL CHANGE)

• FCIC accepted as input to RECOVER, COPYTOCOPY, DSN1COPY, DSN1COMP, DSN1PRNT


FlashCopy and DB2 for z/OS Utilities …

• BACKUP SYSTEM

– Fast and minimally-disruptive system-level backup (SLB)

• No need to suspend the logs or hold off write I/Os

– Allows most updates

– Automatically suspends data set creation, deletion, rename and extend operations

• Very simple from an operational perspective

– SLB can be used for

• Recovery of the entire system to the time of the backup (manual procedures)

• Recovery of the entire system to a PIT after backup (RESTORE SYSTEM)

• Recovery of individual DB2 table spaces and indexes (RECOVER)

18

Volume-level FC

BACKUP SYSTEM hsm FRBACKUP

BACKUP SYSTEM will always fail if FC cannot be used

FlashCopy

dss COPY … FASTREPLICATION(REQUIRED)



• BACKUP SYSTEM …

– Requires careful planning and strong collaboration between DB2 and Storage teams

• All volumes containing DB2 data sets must be SMS managed

– Including the DB2 catalog/directory, logs and BSDS, and all user data

• DB2 logs & BSDS must be separated from the rest of the DB2 data sets

– Own pool of volumes defined in a separate SMS storage groups

• Need to define 2 Copy Pools (data and log) and at least 1 Copy Pool Backup Pool

• Must ensure that the ICF user catalogs stay synchronized with the data

– Must have separate ICF user catalogs for data and logs

» ICF user catalog(s) for data must reside in the data copy pool

» ICF user catalog for logs must reside in the log copy pool

– Do not share ICF user catalog with non-DB2 data

– Strong recommendation to check the setup on an on-going basis

19




– hsm VERSIONS parameter controls how many backup generations are kept on DASD

• If VERSIONS>0 (default) |

• If VERSIONS=0 | (if available) SLB on TAPE

– Having the backup on DASD is key to fast recovery

• For mass recovery following data corruption, the base for recovery may be 48-72h old

• Customers with very aggressive SLAs will need to keep more than one SLB on DASD

– Only one SLB can benefit from incremental FC

• If you keep more than 1 SLB on DASD, the other generations will use full background copy

20

Copy FC

NoCopy FC

Incremental FC

Space-efficient FC




– Support for incremental FC was introduced in DB2 9 for z/OS

• Controlled at the DB2 utility level

• BACKUP SYSTEM ESTABLISH FCINCREMENTAL

– Need to use this keyword only once – when the relationship is established for one version,

subsequent invocations can be done using BACKUP SYSTEM

• BACKUP SYSTEM END FCINCREMENTAL

– Support for FlashCopy SE was introduced by APAR OA30816

• DFSMShsm selects Space Efficient target volumes if available

• Support is transparent to DB2 (any version)

21




– Two flavours

• DATA ONLY – FRBACKUP of the database copy pool only (DB2 catalog + all user objects)

• FULL – FRBACKUP of the database copy pool followed by FRBACKUP of the log copy pool

– BACKUP SYSTEM DATA ONLY is sufficient for RESTORE SYSTEM and RECOVER

• RESTORE SYSTEM does not restore the log copy pool

– An SLB taken with BACKUP SYSTEM FULL cannot be used as-is to recover the entire system

at the time of the backup (common misconception)

• Cannot just restore the data and log copy pools using FRRECOV and restart DB2

• The log copy pool is ‘very’ fuzzy and cannot be used as-is

– No consistent point across active log COPY1 and COP2, logs from different DB2 data sharing

members, log stripes if VSAM striping is used

• Before restarting DB2, need to truncate all the logs to the same point in time (conditional restart)

22



• RESTORE SYSTEM

– Point-in-time recovery from SLB

• Can be any point after the time of the backup

• Recovery is for the entire system or data sharing group

• Very simple from an operational perspective

– DFSMShsm support for was introduced in z/OS 1.12

• Allows RESTORE SYSTEM before the background copy is complete

• Support is transparent to DB2

– ‘Allow Fast Reverse Restore’ set in the copy pool definition and recorded for each backup

• Once FRR completes, the original DASD backup volumes becomes invalid

– First thing to do if VERSIONS=1: take another backup for protection

23

RESTORE SYSTEM hsm FRRECOV

RESTORE SYSTEM will always fail if FC cannot be used

FlashCopy

dss COPY … FASTREPLICATION(REQUIRED)

Volume-level FC

Fast Reverse Restore



• RECOVER using SLB as input

– Can recover a single object or list of objects using an SLB

• Set ZPARM SYSTEM_LEVEL_BACKUPS=YES to allow SLB to be considered for object recovery

– RECOVER to point in time or to current

– COPY YES indexes can be included in this recovery

– RECOVER from SLB uses hsm default for dataset-level recovery

FASTREPLICATION(PREFERRED)

• By default, if FC cannot be used, RECOVER from SLB will use ‘standard’ I/O

– e.g. if the physical background copy is not complete, ‘traditional’ copy is used

• Can be overwritten in DFSMShsm

– Specify the SETSYS FR(DSR(NONE|REQUIRED)) command in ARCCMDxx

– Issue SETSYS FR(DSR(NONE|REQUIRED)) command after DFSMShsm is started

24

RECOVER hsm FRRECOV FASTREPLICATION(PREFERRED) dss COPY

FlashCopy

Standard I/O

Dataset-level FC



• RECOVER from SLB as input …

– Space restriction for object-level RECOVER from SLB if data sets to be recovered have

moved to a different set of volumes since the SLB

• Typical cases

– Recovery to a point in time before an online REORG

– Storage administrator decides to move datasets around to defrag volumes

– Migrate to new DASD subsystem

• Pre z/OS 1.11: object-level RECOVER from SLB was not possible

• z/OS 1.11: object-level RECOVER from SLB is allowed if …

– DFSMShsm option to capture ICF catalog information is turned ON (not the default)

» ‘CAPTURE CATALOG INFORMATION FOR DATA SET RECOVERY’ must be set to ‘R’

(REQUIRED) in the copy pool definition

– There is enough space on the original volumes to restore the dataset

– DB2 10 RECOVER is used in case the object was moved via REORG (I/J name switch)

• z/OS 2.1: If unable to recover the data set to the original volume, the most eligible volume with the

most free space within the storage group will be selected



• FC image copies (FCIC)

– FCIC created with COPY, REORG, LOAD, REBUILD INDEX, REORG INDEX

– Significant CPU & elapsed time reduction for large page sets

– Allows creating a transaction-consistent image copy with COPY SHRLEVEL CHANGE

– Partition-level inline image copy

– Taking an inline FCIC can reduce the outage window for online REORG

– FCIC accepted as input to RECOVER, COPYTOCOPY, DSN1COPY, DSN1PRNT

• But cannot UNLOAD directly from FCIC

– Use COPYTOCOPY to create a sequential copy that can then serve as input to UNLOAD

– New ZPARMs & utility options

26

TEMPLATE FCCOPY DSN MYHLQ.&DB..&SN..N&DSNUM..&UQ. COPY TABLESPACE DBNAME.TSNAME FLASHCOPY(YES|CONSISTENT) FCCOPYDDN(FCCOPY)

FCCOPYDDN = HLQ.&&DB..&&SN..N&&DSNUM..&&UQ. (default template for the FCIC data set name) FLASHCOPY_COPY = NO|YES FLASHCOPY_LOAD = NO|YES FLASHCOPY_REBUILD_INDEX = NO|YES FLASHCOPY_REORG_INDEX = NO|YES FLASHCOPY_REORG_TS = NO|YES

Dataset-level FC



• FC image copies (FCIC) …

– COPY always uses dss default FASTREPLICATION(PREFERRED)

• COPY always succeeds

– If FC cannot be used, COPY will be done using ‘standard’ I/O

– Exception: FASTREPLICATION(REQUIRED) is used for inline FCIC in online REORG

• Taking a FCIC can reduce the outage window for REORG

• FCIC at part-level is created after the switch phase and before the dedrain - only have to wait for

logical copy to be complete

• Eliminates inline copy processing -> no need to copy pages at each log iteration

• If FC cannot be used, REORG utility will work but will leave the object in COPYPEND status

27

COPY dss COPY … FASTREPLICATION(PREFERRED)

FlashCopy

Standard I/O



• RECOVER using FCIC as input

• DB2 ZPARM REC_FASTREPLICATION

• PREFERRED (default) >> RECOVER will use ‘standard’ I/O if FC cannot be used

• REQUIRED >> RECOVER will fail if FC cannot be used

• NONE >> Always use standard I/O

– Restriction: If the FCIC dataset was migrated by hsm, RECOVER will not use it

• Error message DSNU1562I

• RECOVER will look for an alternate local copy first and then for an older image copy

• Work-around: Add a first step to recall the FCIC dataset before the RECOVER executes

28

RECOVER dss COPY … FASTREPLICATION(PREFERRED)

FlashCopy

Standard I/O

Dataset-level FC



• CHECK INDEX|DATA|LOB SHRLEVEL CHANGE

– CHECK is a critical tool in case of data corruption

– FC support allows you to run the CHECK utilities non disruptively

• Drain writers for target data and indexes (usual drain parameters supported) Read/Only

• Copy datasets to shadows using DFSMSdss COPY commands

DB2 ZPARM CHECK_FASTREPLICATION

– PREFERRED (default V9) >> Standard I/O will be used if FC cannot be used

– REQUIRED (default V10) >> CHECK will fail if FC cannot be used recommended

DB2 ZPARM UTIL_TEMP_STORCLAS to specify the storage class for shadow data sets

• After logical complete for datasets, dedrain target data and indexes Read/Write

• CHKP/ACHKP/AUXW no longer set if errors detected (not reset either)

– Look for messages and generated REPAIR statements

CHECK dss COPY … FASTREPLICATION(REQUIRED) FlashCopy

Dataset-level FC

29


FlashCopy and IBM Remote Copy Services

• IBM Remote Copy Services

– Metro Mirror – MM (a.k.a. PPRC)

– z/OS Global Mirror – zGM (a.k.a. XRC)

– Global Copy – GC (a.k.a. PPRC-XD)

– Global Mirror – GM

• Restrictions when combining copy services functions with FlashCopy

30

Device is May

become

(1) If using Remote Pair FlashCopy (2) FC V2 Data Set FlashCopy only (3) FC V2 Multiple relationships

MM or GC Primary

MM or GC Secondary

zGM Primary

zGM Secondary

GM Primary

GM Secondary

FC Source FC

Target Incremental

FC Source Incremental

FC Target

FlashCopy Source

Yes Yes Yes Yes Yes Yes Yes (2,3) Yes (2) Yes (3) No

FlashCopy Target

Yes (1) No No No No No Yes (2) Yes (2) No No


FlashCopy and IBM Remote Copy Services …

• Incremental FC

– Restriction: A device that is the source of an Incremental FlashCopy cannot be used as

FlashCopy target

– Incremental FC relationship is persistent (remains after background copy is done)

– What does this mean for the DB2 utilities?

• If Incremental FC is used for SLB, RECOVER from SLB or from FCIC will always use ‘standard’ I/O

– Unless the last delta background copy has completed, AND you manually withdraw the

incremental FC relationship beforehand

• RESTORE SYSTEM automatically terminates the relationship

31


FlashCopy and Remote Copy Services …

• FlashCopy and Global Mirror or z/OS Global Mirror (XRC)

– Restriction: A FlashCopy target cannot be established on a device that is part of a Global

Mirror or z/OS Global Mirror volume pair

– What does this mean for the DB2 utilities?

• BACKUP SYSTEM

• Object-level RECOVER from SLB

– Standard I/O (slower) is always used when restoring data from a system-level backup

• RESTORE SYSTEM

– If SLB is on DASD, need to disable mirroring before running RESTORE SYSTEM

» But can use a system level backup on tape

32

P1 S1

The copy pool backup must be defined outside of GM or zGM mirror

P2

GM/zGM

Tape mirroring



• FlashCopy and Global Mirror or z/OS Global Mirror (XRC) …

– What does it mean for the DB2 utilities? …

• CHECK INDEX|DATA|LOB SHRLEVEL CHANGE

– Use ZPARM UTIL_TEMP_STORCLAS to specify a pool of volumes that are not mirrored

– Set CHECK_FASTREPLICATION=REQUIRED

» CHECK will fail if FC cannot be used

• FlashCopy image copies

– Use SMS to allocate the image copy dataset on a pool of volumes that are not mirrored

» Otherwise, image copy is still taken, but will always use standard I/O

• RECOVER using FlashCopy image copies

– Standard I/O is always used when recovering from a FlashCopy image copy

33

P1 S1

Must use an SMS volume pool defined outside of GM or zGM mirror for CHECK shadow datasets and FCIC datasets

GM/zGM

P2



• FlashCopy and Metro Mirror

– By default, same restrictions as with GM and zGM

– Solution: Remote Pair FC, aka Preserve Mirror FC

• FC commands issued at the primary site are ‘mirrored’ at the secondary site

• Avoids the physical movement of data and can avoid the MM pair going into Duplex Pending

• Maintaining Full Duplex is key for Hyperswap customers and for Disaster Recovery

– Must set FCTOPPRCPrimary(PresMirReq) on DFSMSdss COPY command

» The MM pair must not go into a ‘duplex pending’ state as a result of a FC operation

» This is the option GDPS customers should always use

S1

S2

P1 Metro Mirror - Duplex

P2 Metro Mirror - Duplex

34



• NOTES: Remote Pair FC and DFSMSdss COPY command

– If you don’t specify FCTOPPRCPrimary

• A PPRC primary volume is not eligible to become a FlashCopy target volume

– Default for DFSMSdss COPY command

– Same restrictions as with Global Mirror and z/OS Global Mirror

– FCTOPPRCPrimary(PresMirNone)

• If the target volume is a Metro Mirror primary device, the pair will go into a ‘duplex pending’ state as

a result of a FlashCopy operation

– This is the default if sub-keyword is not specified

– FCTOPPRCPrimary(PresMirPref)

• If the target volume is a Metro Mirror primary device, the pair may go into a ‘duplex pending’ state

as a result of a FlashCopy operation

– FCTOPPRCPrimary(PresMirReq)

• If the target volume is a Metro Mirror primary device, the pair must not go into a ‘duplex pending’

state as a result of a FlashCopy operation

– This is the option GDPS customers should always use

35



• NOTES: Remote Pair FC and DB2 for z/OS utilities

– DB2 utilities using DFSMShsm (BACKUP SYSTEM, RESTORE SYSTEM, RECOVER from SLB)

• Preserve mirror attribute is set at the Copy Pool level via the SMS definition panel

– FRBACKUP to PPRC Primary Vols allowed (NO|PN|PP|PR)

– FRRECOV to PPRC Primary Vols allowed (NO|PN|PP|PR)

– Default (NO): FCTOPPRCPrimary will not be passed to DFSMSdss

» Metro Mirror primary devices cannot be used as FlashCopy target volumes

– Other DB2 utilities using DFSMSdss (CHECK DATA, CHECK INDEX, CHECK LOB, COPY, REORG TABLESPACE,

REORG INDEX, REBUILD INDEX, LOAD, RECOVER)

• Preserve mirror attribute is set via ZPARM

– APAR PM26762: FLASHCOPY_PPRC (blank|NONE|PREFERRED|REQUIRED)

– blank (default V9) >> FCTOPPRCPrimary will not be passed to DFSMSdss

– REQUIRED (default V10) >> If the target volume is a Metro Mirror primary device and preserve

mirror cannot be used, the utility will use standard I/O

» Unless …

» ZPARM CHECK_FASTREPLICATION = REQUIRED >> CHECK will fail

» ZPARM REC_FASTREPLICATION = REQUIRED >> RECOVER will fail

36



• FlashCopy and Metro Mirror …

– Additional considerations for users of BACKUP SYSTEM

• FlashCopy SE and Remote Pair FlashCopy are mutually exclusive

– Must define the VERSION 0 copy pool backup outside of MM

• Fast Reverse Restore and Remote Pair FlashCopy are mutually exclusive

– In MM configuration with Remote Pair FC, need to wait for background copy to complete

before running RESTORE SYSTEM

– Can use incremental FC to reduce the elapsed time of the physical background copy

37

If using incremental FC for SLB, RECOVER from SLB or from FCIC will always use ‘standard’ I/O



• FlashCopy and a 3-site Metro-Global Mirror or Metro-z/OS Global Mirror configuration

– Similar restrictions to those for GM and zGM – even with Remote Pair FC

• SLB and FCIC need to be taken on volumes outside of GM or zGM

• RECOVER using SLB or FCIC will always use ‘standard’ I/O

• RESTORE SYSTEM cannot be done unless the GM or zGM mirror is disabled

38

S1

S2

P1

P2

GM T1

MM

Tape mirroring

MM


Summary

• FlashCopy opens up a whole new world of possibilities

– Local or remote backups

– Enhanced testing capability

– Quick cloning of the environment

– Increased availability for DB2 utilities

• Need careful planning and preparation

– Must involve DB2 and storage specialists

– Require a clear definition and understanding of the recovery objectives to drive the

implementation (number of versions on DASD, usage of tape, etc.)

– Must understand options, restrictions and trade-offs (esp. when using DASD mirroring)

• Require strong collaboration between teams on an on-going basis

– Develop processes and governance around the solution

– Investigate tooling to support the solution

• IBM Recover Expert for z/OS, IBM Cloning Tool

39

Technology

FlashCopy and DB2 for z/OS