FlashCopy and DB2 for z/OS

Florence Dubois
IBM DB2 for z/OS Development
flodubois@uk.ibm.com
FlashCopy and DB2 for z/OS

© 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

© 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 RestoreVolume-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
Flash
Copy
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
Flash
Copy
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
Flash
Copy
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)
Flash
Copy
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)
Flash
Copy
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) Flash
Copy
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
isMay
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

FlashCopy and DB2 for z/OS

Recommended

Recommended

More Related Content

What's hot

What's hot (20)

Viewers also liked

Viewers also liked (16)

Similar to FlashCopy and DB2 for z/OS

Similar to FlashCopy and DB2 for z/OS (20)

Recently uploaded

Recently uploaded (20)

FlashCopy and DB2 for z/OS