DB2 for z/os. Best Practices. FlashCopy and DB2 for z/os. Florence Dubois DB2 for z/os Development 2014 IBM Corporation

Transcription

1 DB2 for z/os Best Practices FlashCopy and DB2 for z/os Florence Dubois DB2 for z/os Development

2 Disclaimer/Trademarks Copyright IBM Corporation 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 2

3 Agenda FlashCopy overview FlashCopy outside of DB2 s control FlashCopy and DB2 for z/os utilities FlashCopy and IBM Remote Copy Services 3

4 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 Volume-level FC Copy FC Space-efficient FC Fast Reverse Restore Dataset-level FC NoCopy FC Incremental FC Consistency Group FC Remote Pair FC 4

5 FlashCopy Overview S 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 1 0 T Read and write activity are possible on both the source and target devices S T 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 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 S T 5

6 FlashCopy Overview 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 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 6

7 FlashCopy Overview 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

8 FlashCopy Overview 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 Volume-level FC Dataset-level FC 8

9 FlashCopy Overview 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 FCNOCOPY option on the DFSMSdss COPY command 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 Volume-level FC Dataset-level FC 9

10 FlashCopy Overview 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 DB2 Incremental IC Initial incremental FC invocation results in a full background copy Subsequent incremental FC result in delta copy Overrides the previous version 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 Relationship will last until it is explicitly withdrawn FCINCREMENTAL on DFSMSdss COPY command Volume-level FC 10

11 FlashCopy Overview Space Efficient FlashCopy FCSETGTOK(FAIL) option on DFSMSdss COPY command 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) Volume-level FC 11

12 FlashCopy Overview 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 Volume-level FC 12

13 FlashCopy Overview 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 FCFASTREVERSERESTORE option on DFSMSdss COPY Restriction: Cannot be used in conjunction with Remote Pair FlashCopy Volume-level FC 13

14 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

15 FlashCopy Outside of DB2 s Control Backup Need to guarantee the I/O consistency of the FlashCopy backup Option 1: Use the DB2 commands -SET LOG SUSPEND / -SET LOG RESUME Temporarily freeze all DB2 update activity After all volumes have completed the FC Establish phase, issue -SET LOG RESUME Option 2: Use Consistency Group FC FCCGFREEZE option on DFSMSdss COPY 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 the timeout value is reached (2 minutes with default settings) Not 100% transparent to the applications! Use option FCCGVERIFY on CGCREATE to determine if the copy is consistent Recovery Need to use DB2 warm restart recovery to re-establish application consistency FlashCopy backup is a fuzzy copy - Cannot be used as-is With Option 1, can also use RESTORE SYSTEM LOGONLY to bring the system forward in time (requires -SET LOG SUSPEND to set the RBLP) 15

16 FlashCopy and DB2 for z/os Utilities IBM DB2 for z/os utilities makes more and more use of FlashCopy V8 V9 V10 BACKUP SYSTEM RESTORE SYSTEM Dataset FC support for CHECK INDEX SHRLEVEL CHANGE 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 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 16

17 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) Volume-level FC BACKUP SYSTEM hsm FRBACKUP dss COPY FASTREPLICATION(REQUIRED) Flash Copy BACKUP SYSTEM will always fail if FC cannot be used 17

18 FlashCopy and DB2 for z/os Utilities 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 18

19 FlashCopy and DB2 for z/os Utilities BACKUP SYSTEM hsm VERSIONS parameter controls how many backup generations are kept on DASD If VERSIONS>0 Copy FC (default) Incremental FC If VERSIONS=0 NoCopy FC Space-efficient FC (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 19

20 FlashCopy and DB2 for z/os Utilities BACKUP SYSTEM 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) 20

21 FlashCopy and DB2 for z/os Utilities BACKUP SYSTEM 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 21

22 FlashCopy and DB2 for z/os Utilities 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 Volume-level FC RESTORE SYSTEM hsm FRRECOV dss COPY FASTREPLICATION(REQUIRED) Flash Copy RESTORE SYSTEM will always fail if FC cannot be used DFSMShsm support for Fast Reverse Restore 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 22

23 FlashCopy and DB2 for z/os Utilities Dataset-level FC Flash Copy RECOVER hsm FRRECOV FASTREPLICATION(PREFERRED) dss COPY Standard I/O 23

24 FlashCopy and DB2 for z/os Utilities 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 24

25 FlashCopy and DB2 for z/os Utilities 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 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 Dataset-level FC 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 TEMPLATE FCCOPY DSN MYHLQ.&DB..&SN..N&DSNUM..&UQ. COPY TABLESPACE DBNAME.TSNAME FLASHCOPY(YES CONSISTENT) FCCOPYDDN(FCCOPY) 25

26 FlashCopy and DB2 for z/os Utilities FC image copies (FCIC) COPY dss COPY FASTREPLICATION(PREFERRED) Flash Copy Standard I/O 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 will work but will leave the object in COPYPEND status 26

27 FlashCopy and DB2 for z/os Utilities RECOVER using FCIC as input Dataset-level FC RECOVER dss COPY FASTREPLICATION(PREFERRED) Flash Copy Standard I/O 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 27

28 FlashCopy and DB2 for z/os Utilities Dataset-level FC CHECK dss COPY FASTREPLICATION(REQUIRED) Flash Copy 28

29 FlashCopy and IBM Remote Copy Services Device is May become 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 FlashCopy Target Yes Yes Yes Yes Yes Yes Yes (2,3) Yes (2) Yes (3) No Yes (1) No No No No No Yes (2) Yes (2) No No (1) If using Remote Pair FlashCopy (2) FC V2 Data Set FlashCopy only (3) FC V2 Multiple relationships 29

30 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 30

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 P1 GM/zGM S1 The copy pool backup must be defined outside of GM or zgm mirror P2 Tape mirroring 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 31

32 FlashCopy and Remote Copy Services FlashCopy and Global Mirror or z/os Global Mirror (XRC) What does it mean for the DB2 utilities? P1 GM/zGM S1 P2 Must use an SMS volume pool defined outside of GM or zgm mirror for CHECK shadow datasets and FCIC datasets 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 32

33 FlashCopy and IBM Remote Copy Services 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 P1 Metro Mirror - Duplex S1 P2 Metro Mirror - Duplex 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 33

34 FlashCopy and Remote Copy Services 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 MM 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 MM 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 MM 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 34

35 FlashCopy and Remote Copy Services 35

36 FlashCopy and IBM Remote Copy Services 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 a Metro Mirror 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 If using incremental FC for SLB, RECOVER from SLB or from FCIC will always use standard I/O 36

37 FlashCopy and IBM Remote Copy Services 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 P1 MM S1 GM T1 P2 MM Tape mirroring 37

38 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 38