DB2 for z/os Disaster Recovery: A smorgasbord of solutions

Transcription

1 DB2 for z/os Disaster Recovery: A smorgasbord of solutions New England DB2 User Group April 26, 2005 Judy Ruby-Brown IBM Dallas Systems Center judyrb@us.ibm.com ATS - DB2 for z/os

2 List of Acronyms used in this Presentation D/R or DR - Disaster Recovery XRC - EXtended Remote Copy PPRC - Peer to Peer Remote Copy PPRC-XD - Peer to Peer Remote Copy Extended Distance GDPS - Geographically Dispersed Parallel Sysplex ESS - Enterprise Storage Server (a.k.a."shark") DFSMS - grouping of storage products SDM - System Data Mover (part of DFSMSdfp) DF/DSS - volume dumping utility - part of DFSMSdss FlashCopy - "instant" copy of data using ESS ESCON - Enterprise Systems Connection Architecture FICON - Fiber Connectivity Architecture (faster than ESCON0 LSS - Logical Storage Subsystem - part of a physical ESS (up to 256 volumes) LCU - Logical Control Unit (same as LSS) RTO - Recovery Time Objective (how long to recover) RPO - Recovery Point Objective (how much data loss) PTAM - (a.k.a. "Pickup Truck Access Method" - truck transport PITR Point in Time Recovery 2 ATS - DB2 for z/os

3 Agenda Background and Traditional D/R FlashCopy and other "instant copy" scenarios DB2 for z/os V8 enhancements Remote Copy Services Global Mirror XRC Metro Mirror PPRC GDPS Metro/Global Mirror Global Copy (PPRC-XD) Metro/Global Copy Global Mirror PPRC What to remember about this session (pages 75-86) Appendix: Tracker Site with DB2 V8 3 ATS - DB2 for z/os

4 References GDPS white paper and solution information available at: ƒ ƒ General Reference ƒ - See ƒ Implementing ESS Copy Services on with IBM eserver zseries, SG ƒconsistency Groups ƒdb2 for z/os Disaster Recovery, SG ƒdb2 for z/os V8 Administration Guide, Using Data Mirroring Faster + Easier = Improved DB2 Disaster Recovery (FlashCopy) 4 ATS - DB2 for z/os

5 What to remember about Traditional DB2 D/R Good (about 80% of customers use this) ƒleast costly No infrastructure at recovery site No network, ESCON costs ƒdb2 is completely available during backups not only UP, but can accept all updates Bad (Pains) ƒrequires complex procedures to be developed and maintained "People cost" is never measured ƒrequires deep DB2 recovery skills - Slight deviations can result in failure ƒup to 24 hours behind (RPO) or more Unless automated library - then may be less than an hour behind ƒlengthy Recovery multiple hours at best "days" at worst - due to infrequent image copy of application data ƒfor complete solution, must take archive logs D/R using image copies only doesn't work (inconsistent) - fails RPO 5 ATS - DB2 for z/os

6 What to remember about Traditional DB2 D/R (continued) Issues: Political conflict between systems and applications ƒsystems responsible for Catalog/Directory - "systems stuff ƒdbas/applications responsible for Application Recovery Full vs. Incremental copies - tape drive consumption Infrequent image copies do not meet RTO 6 ATS - DB2 for z/os

7 Data Loss (RPO) Advanced Technical Support Days 24 Hours Volume Dumps Data Loss and Recovery Time Conventional Transport "PTAM" Hours Some others we'll discuss Minutes Vaulting Seconds Remote Copy Minutes Remote Copy + Log Apply Hours RRDF (Logs) Day Recovery Time (RTO) 7 ATS - DB2 for z/os

8 FlashCopy Scenarios Eliminate complex procedures with -Set Log Suspend/Resume commands ATS - DB2 for z/os

9 FlashCopy - What it Does Time Copies a Volume..fast Source Target Copy data command issued Relationship starts Copy immediately available Write Read Read and write to both source and copy possible while b/g copy runs Background copy When copy is complete, relationship between source and target ends 9 ATS - DB2 for z/os

10 How Fast is it? FlashCopy 1 invoked through DFSMSdss - Logical processing ƒsource volume available Average 0.6 seconds per pair (for 128 pairs) (<90 sec.) ƒtarget volume available ƒbackground Copy ƒwithout other I/O workload 5 minutes for 4 pairs 30 minutes for 128 pairs ƒbased on preliminary measurements Real world experience - logical complete (FC 1) ƒone customer volumes in 5 minutes ƒa brokerage volumes in 10 minutes FlashCopy 2 about 10x faster than FlashCopy 1 15 DFSMShsm tasks each invoking DFSMSdss with 24 volumes to process in parallel ƒ volumes in THREE minutes (2100 cylinder data) 10 ATS - DB2 for z/os

11 Suspend/Resume Logging -SET LOG SUSPEND ƒtakes a system checkpoint (for a non-data sharing system) ƒexternalizes any unwritten log buffers to active log datasets ƒupdates the BSDS with the high written log RBA value ƒholds log write latch to suspend logging / update activities Writes a DSNJ372I message to indicate update activity has been suspended at the current log RBA value ƒdoes not come to a syncpoint V8 - Changes to -Set Log Suspend -SET LOG RESUME ƒresumes logging and update activity Deletes the DSNJ372I message from the console Why you must take backup after logging is suspended ƒensure entire subsystem -logs and databases - are consistent for a subsequent normal restart No complex procedures..looks like DB2 crashed 11 ATS - DB2 for z/os

12 A Picture is worth 1000 words Assumption: "PTAM" Transport - single site 2-3 Minutes A -Set Log Suspend FlashCopy - DB2 Cat/dir - Data - Logs -BSDS B -Set Log Resume Start tape dump of secondary copy for offsite 12 ATS - DB2 for z/os

13 Flavor 1: Restore FlashCopy - Start DB2 at B Analysis: Fast Restart - loss of data since FlashCopy Current DB2 D/R procedures eliminated Hour? Start DB2 Start new work Restore from Tape copies of FlashCopy - DB2 Cat/dir - Data - Logs -BSDS B Normal Restart All End of Restart 13 ATS - DB2 for z/os

14 Compare to Traditional DB2 D/R RPO is <24 hours behind in both cases ƒflashcopies and image copies/archives log transported daily No existing computing facility infrastructure is assumed in either case Traditional D/R RTO is 24 hours to be recovered and accepting new work. This scenario takes only DF/DSS restore time (1-2 hours?). New work is accepted after restart. Conclusion: This scenario provides 12X + improved RTO It requires no image copy decisions (full vs. incremental). It requires suspending log for a couple of minutes. It requires duplicate DASD for Flash (or other instant copy) It eliminates labor costs of manual procedures. It t offloads work from DB2 staff to storage systems staff! 14 ATS - DB2 for z/os

15 Flavor 2: Restore FlashCopy - Forward Apply Logs Analysis: Longer to come up - reduced data loss Complex DB2 D/R procedures required Hour Start DB2 Restore FlashCopy - DB2 Cat/dir - Data - Logs -BSDS B 15 hours of log C Conditional Endrba=C Defer All Example: Archive Logs directed to automated tape library at recovery site 15 ATS - DB2 for z/os

16 How to Apply Logs to FlashCopy V7 Recover the catalog/directory Recover SYSUTILX LOGONLY Rebuild 2 SYSUTILX indexes Display utilities and TERM Use Recover..LOGONLY to recover the catalog/directory in sequence Rebuild its indexes Recover user tablespaces LOGONLY (and indexes) Rebuild indexes without COPY YES Current as of last archive offsite ƒno data loss if logs XRC or PPRC to recoverysite This can take HOURS! V8 changes process with RESTORE SYSTEM LOGONLY utility eliminates need for these 2 pages 16 ATS - DB2 for z/os

17 Logonly Recovery Gotchas (V7) Exception to header page RBA update (all DB2 versions) 7 always open Catalog/Directory table spaces (no SYSLGRNX records) All directory DBD01, SCT02, SPT01, SYSUTILX, SYSLGRNX Catalog SYSCOPY, SYSGROUP If any of these are not actually updated, their header page RBAs are not updated either Symptom: Recover Logonly calls for old archives maybe off the BSDS You can t control / determine update activity for them Solution: Run Quiesce Utility against the 7 before Set Log Suspend Special code to update them You can Quiesce one at a time (to avoid contention) since the only purpose is to update the HPGRBRBA. Limits the amount of log to pass PQ79387 updates HGPRBRBA for COPY with SHRLEVEL CHANGE 17 ATS - DB2 for z/os

18 What to remember about FlashCopy and Log Suspend ƒgood Easy to implement for DB2 staff (storage staff establish) No DB2 complex recovery procedures (restore DFSMSdss dumps) RTO within a couple of hours Normal restart of DB2 No Infrequent and/or incremental image copy application issues No infrastructure needed at recovery site ƒbad Short outage to suspend and resume logging No update activity / log write latch held issue at time of low activity Data Sharing - shared data sets set to GRECP and recovery required (simple to do but lengthy if many shared data sets) Need duplicate DASD and FlashCopy license at local site Need sufficient tape drive to dump secondaries for transport RPO is still up to 24 hours behind Issues Vaulting archive tapes at vendor site makes RPO almost current elongating RTO (more log to pass) Restore System Logonly is one step recovery 18 ATS - DB2 for z/os

19 Do you need Set Log Suspend? Consistency Groups possible with Flashcopy 2 Using Web Interface you must Define FlashCopy Freeze Consistency Group task Define all the volume source and target pairs (not the LSS) Thousand? Volume level long time Execute FlashCopy Freeze Consistency Group task ELB issued for DASD writes until CG is created established With I/O suspended, establishes the relationship between pairs ELB released by Consistency Group Created task or timeout window (2 min) Normal I/O starts while ESS FC background copy continues Strong feeling Set Log Suspend method is faster Cleaner as logs buffers written/externalized etc. In V8 RBLP not set with CG only Restore System Logonly is not possible 19 ATS - DB2 for z/os

20 Data Loss (RPO) Advanced Technical Support Days Volume Dumps Data Loss and Recovery Time 24 Hours Conventional Transport "PTAM" Hours FlashCopy PTAM Minutes Vaulting Seconds Remote Copy Minutes Remote Copy + Log Apply Hours RRDF (Logs) Day Recovery Time (RTO) 20 ATS - DB2 for z/os

21 DB2 V8 System Point in Time Recovery for Disaster Recovery ATS - DB2 for z/os

22 System level PITR overview Provides an easier and less disruptive way for subsystem volume-level backup and recovery Primary Purpose is for local SAP Point in time Recovery But parts are very useful for DR Two new utilities provided with DB2 Version 8: ƒbackup SYSTEM ƒrestore SYSTEM Also new function in the SET LOG SUSPEND command ƒas an alternative to BACKUP SYSTEM 22 ATS - DB2 for z/os

23 BACKUP SYSTEM utility Use is for local system recovery, not DR preparation BACKUP SYSTEM utility ƒinvokes DHSMShsm services to take fast, (few minutes) minimally disruptive volume copies of the DB2 data and / or logs ƒno DB2 Quiesce point is required, nothing stops as in SET LOG SUSPEND ƒtwo flavors: FULL / DATA ONLY ƒtwo sets of Copy Pools (data and log) ƒbackup SYSTEM FULL copies both ƒbackup SYSTEM DATA copies data ƒautomates these previously manual processes ƒset Log Suspend operator command ƒmanual submission of FlashCopy jobs ƒtracking of completion of jobs ƒ-set Log Resume operator command 23 ATS - DB2 for z/os

24 When BACKUP SYSTEM is invoked, DB2.. Records the Recover Based Log Point (RBLP) in DBD01 VIP - Starting point for DB2 log apply in the RESTORE utility and is critical for DR scenarios when additional log is provided Invokes DFSMShsm for volume DASD-DASD copies of DB Copy Pool Invokes DFSMShsm for volume DASD-DASD copies of log Copy Pool DFSMShsm returns control to DB2 once logical copies have completed (several minutes) Backups performed in parallel Resumes quiesced activities Less disruptive than SET LOG SUSPEND Allows most updates during backup 24 ATS - DB2 for z/os

25 BACKUP SYSTEM BSDS COPY1 RBA1 COPY2 RBAh DBD01 page set RBLP Logscan start point TOKEN RBA1 RBAh RBAn COPY COPY1 COPY2 COPY3 'copy pool backup' SG1 DFSMShsm 'copy pool backup' SG2 COPY3 RBAn RBA1 RBAh RBAn C2 C6 C10 COPY1 COPY2 COPY3 LOG1 LOG2 FRBACKUP COPYPOOL(DSN$DSNDB0G$DB) token(rba1) RBLP: RBA1 RBLP: RBAh RBLP: RBAn c1 c2 c3 c4 c5 c6 c7 c8 c9 c10 c11 Backup System FULL Backup System FULL Backup System DATA ONLY DB2 DBs Logs ICF Catalog DB2 DBs Logs ICF Catalog DB2 DBs Logs ICF Catalog 'DB' copypool 'Log' copypool 'DB' copypool 'Log' copypool 'DB' copypool 'Log' copypool DSN$DSNDB0G$DB DSN$DSNDB0G$LG DSN$DSNDB0G$DB DSN$DSNDB0G$LG DSN$DSNDB0G$DB DSN$DSNDB0G$LG 25 ATS - DB2 for z/os

26 Disaster Recovery Activities BACKUP SYSTEM not directly useable for DR User can make tape copies of Database COPYPOOL and Log COPYPOOL (20.6 DR with DB2, SG ) Take offsite Flavor 1- At Recovery Site, restore tape copies of Database COPYPOOL and Log COPYPOOL and start DB2 Flavor 2 - If you have more archive log Restore tape copies of Database COPYPOOL and Log COPYPOOL Prepare to restart DB2 with conditions To recover to an arbitrary PIT. such as the last archive log in your automated library see the next 2 pages 26 ATS - DB2 for z/os

27 Flavor 2 Recovery Single subsystem Establish the Conditional Restart using a new option called SYSPITR.It is the RBA of the extra log you want to apply. It must be an actual log record, not a rounded up value. Get it either way:. RBA of last checkpoint Checkpoint queue of BSDS of the last archive log Latest complete checkpoint on last archive log (usually 2 nd one) Use its ENDRBA Or DSN1LOGP using RBASTART (last chkpt ENDRBA) SUMMARY(NO) DBID(FFFF) Output is RBA of last valid log record Also QUIESCE of a dummy t/s (SAP users) returns a valid RBA Using Change Log Inventory utility (DSNJU003) CRESTART CREATE SYSPITR=log-point (truncation RBA value) 27 ATS - DB2 for z/os

28 Flavor 2 Recovery Single subsystem Start DB2 ƒdb2 system enters into System Recover Pending mode Submit RESTORE SYSTEM LOGONLY utility ƒdb2 enters a restrictive state allowing no external access ƒdb2 reads the RBLP in the restored database volumes ƒdb2 starts at the RBLP and applies all extra log ƒautomatically no human hands Recycle DB2 to reset the System Recover Pending mode 28 ATS - DB2 for z/os

29 Flavor 2 Recovery Data Sharing Truncation point for data sharing is lowest LRSN common to all members (and subtract 1), exactly as in traditional DR. Then run on each member DSNJU003 Change Log Inventory with new option 'SYSPITR' ƒ CRESTART CREATE SYSPITR=log-point (truncation LRSN value) Stop all DB2 members Force all CF structures owned by this DB2 group Restart each non-dormant member Submit Restore System Logonly utility ƒ Similar to the steps as in the non-data sharing environment ƒrecycle DB2s to reset the System Recover Pending mode 29 ATS - DB2 for z/os

30 Log apply notes Handles table space CREATEs - will define data sets DROPs will delete data sets LOG NO events (Load or Reorg) If LOG NO, the associated object is entered into RECP or RBDP state. Table spaces and indexes with COPY YES attribute will be marked RECP and the indexes with COPY NO will be marked RBDP Any objects you "forgot" are placed in LPL when accessed Uses fast log apply (FLA) to recover objects in parallel (PQ93156) "Restart logic" applies log to all objects in one pass LOGAPSTG=0 disables, if >0, DB2 chooses value (500 MB) (PQ95164) FLA about 5x faster than no FLA 30 ATS - DB2 for z/os

31 Log Apply notes Log apply phase takes periodic checkpoints ƒforces modified data pages to DASD and trigger system checkpoint ƒupdates the DBD01 header page with the new RBLP value At the end of log apply phase ƒissues informational message if any object is marked RECP, RBDP or LPL during the log apply phase ƒreleases the PITR lock ƒreset the PITR state of each member ƒtake recovery actions for objects placed in exception state RESTORE SYSTEM utility is restartable ƒin data sharing, only that member which issued the original RESTORE SYSTEM can issue the restart request 31 ATS - DB2 for z/os

32 SET LOG SUSPEND / RESUME command (Optional) SET LOG LOGLOAD(0) checkpoint to minimize restart SET LOG SUSPEND ƒcan be used as an alternative to the BACKUP SYSTEM if it is not available ƒmore disruptive than BACKUP SYSTEM utility - takes log write latch as today ƒquiesce 32K page writes (if not 32K CI) and data set extensions only ƒacquires PITR lock in IX mode ƒissue this command from each member if in data sharing environment ƒupdates recovery based log point (RBLP) in DBD01 start of log apply ƒyou take backups of all DB2 data and logs using existing "instant" copy solution SET LOG RESUME Issue command to each member after establish (logical complete) ƒresumes logging ƒresumes 32K page writes and data set extensions ƒreleases the PITR lock 32 ATS - DB2 for z/os

33 Prerequisites z/os V1R5 or above DASD control units which support ESS Flashcopy APIs DB2 datasets must reside on SMS-managed volumes RESTORE SYSTEM LOGONLY supported under z/os 1.3 ƒassumes you have used -Set Log Suspend ƒmanually dumped volumes (as today) ƒmanually restored volumes (as today) ƒeliminates complex recovery procedures for Disaster Recovery ƒmust be in New Function Mode (completely migrated to V8 33 ATS - DB2 for z/os

34 What to remember about DB2 V8. V8 Useful for non-mirroring DR scenarios ƒgood BACKUP SYSTEM is simple one step backup allows most updates Even Log suspend less disruptive than V7 Future recovery point determined and saved in DB2 as RBLP Restore System Logonly simple and performs well Eliminates complexity for FlashCopy restore with log apply One step Recovery starting at RBLP and process all data set to current using restart type logic Faster than individual Recover XXX Logonly statements FLA 5X faster than without it For DR, no need for BACKUP SYSTEM / RESTORE SYSTEM h/w, s/w Image copies not usually required, unless Reorg/Load occurs since RBLP ƒbad BACKUP SYSTEM utility not directly useful for DR user must make own tape copies of COPYPOOL for transport 34 ATS - DB2 for z/os

35 Remote Copy or mirroring Technology XRC, PPRC (various flavors) GDPS Global Mirror/Copy ATS - DB2 for z/os

36 NETW ORK SITE 1 SITE 2 Advanced Technical Support Trends: Availability, D/R, and Technology Technology 24x7x52 $1M / MIPS $60 / disk MB Remote Copy bus_tran D/R RTO: 24-72H RPO: 24-72H 8x5x52 Availability RTO: 24-72H RPO: <24H RTO: <6H RPO: <5M $23K / MIPS $5 / disk MB RTO: <1H RPO: N/A 6/2002 USD $ 2.5K / MIPS $.10 / disk MB RTO: Recovery Time Objective RPO: Recovery Point Objective DB > 36 ATS - DB2 for z/os

37 DB2 Restart or Recovery? Operating System Applications Other Other AS/400's UNIX/NT S/390 UNIX/NT AS/400's Operations Staff Network Staff RS/6000 RS/6000 Data Applications Staff Management Control Telecom Network Physical Facilities Remote Copy Disaster Recovery storage solutions (XRC, PPRC, FlashCopy) are architected to provide: "DB2 Restart" - To start a DB2 and its applications following an outage without having to restore the database. This is a process measured in minutes. and avoid: "DB2 Recovery" - Use image copies and apply log changes to bring DB2 up to point of failure. This is a process measured in hours or even days. See Storage Management with DB2 for OS/390, SG , pp ATS - DB2 for z/os

38 Write Sequence Consistency and Data Integrity sequence integrity: In any operating system, the sequence in which updates are being made is what maintains the integrity of the data. If that sequence cannot be assured when doing copy services, data corruption is sure to occur. Examples: DB2 Database and Log VTOC and Catalog Index Components and Data Components Log Device Primary 1. Log Update 3. Mark Log Complete Secondary Database Device 2. Update Database 38 ATS - DB2 for z/os

39 Critical mirroring attribute recommended Specified on each volume pair If CRIT(YES) and I/O error on secondary volume DB2 does not fail Active log: DB2 marks current unavailable and switches to next pair BSDS: DB2 marks unavailable and switches to single BSDS Database objects: DB2 sets pages in LPL Result: loss of local availability degraded operation Local recovery required If CRIT(NO) and I/O error on secondary volume Primary volume doesn t return error condition DB2 continues to update PPRC knows, but DB2 is unaware of any secondary copy at all since it occurs in ESS subsystem itself. Recommendation: CRIT (NO) for DB2 39 ATS - DB2 for z/os

40 The "Rolling Disaster" In a real disaster (fire, explosion, earthquake), you can never expect your complex to fail at the same moment. Failures will be intermittent and gradual, and the disaster will occur over many seconds or even minutes. This is known as the Rolling Disaster. Remote Copy Services via integration with z/os and Parallel Sysplex, protects your data from being a mirror of a "dying scenario"i.e.., FREEZES at a known point instead of mirroring literally hundreds of time-offset failures in a short amount of time. You must be guaranteed a common end point among all volumes at the secondary site or you cannot recover DB2. Log Device Primary 1. 12:00 Log Update 3. 12:02 Mark Log Complete Secondary Disk fails at 12:03 Database Device 2. 12:01 Update Database Disk fails at 12:00 40 ATS - DB2 for z/os

41 Critical questions for the rest of presentation Are all the volumes at the recovery site at exactly the same point? That is, a consistent point or consistency group How frequent is the consistency group? How is it obtained? 41 ATS - DB2 for z/os

42 Various Mirroring Technologies and Scenarios XRC - asynchronous updates to both sites Local performance unaffected Recovery site "a tad" behind local no "rolling disaster" Global Mirror Metro/Global Mirror PPRC - synchronous updates to both sites No data loss - local performance okay w/i FICON range(103 km) "Rolling" Disaster exposure Metro Mirror (Synchronous) Global Copy (PPRC Extended Distance) Global Mirror (Asynchronous PPRC) GDPS - Geographically Dispersed Parallel Sysplex Uses PPRC technology to avoid "rolling disaster" Second site within sysplex timer distance (40 km) Operational CF, sysplex timer, and monitoring z/os image at recovery site with takeover capacity for local parallel sysplex Total site mirroring -lots of automation - IBM services 42 ATS - DB2 for z/os

43 EXtended Remote Copy (Global Mirror XRC) All DB2 DASD volumes are mirrored to a second site. ƒas one "consistency group" in one XRC Session ƒsystem Data Mover (SDM) at secondary site pulls updates and applies updated tracks ƒxrc-capable hardware required How it works: ƒall write I/Os to XRC primary devices timestamped by host source clock (Sysplex timer) Needed to sync across multiple Control Units/subsystems ƒconsistency group apply processing keeps all secondary DASD in CG at min time of all tracks in group Primary Host Idea is basis for Global Mirror PPRC we ll discuss later Primary ESS 4 Secondary ESS Secondary Host 43 ATS - DB2 for z/os

44 Operational Scenario - Disaster Recovery 12:00. Initial indication of disasterdisk systems start to fail. Applications fail DB2 System 11:59. Consistency group formed at SDM and written to journal System Data Mover (SDM) Recovery System Storage control 12:00. Duplex pair in SUSPENDED status 12:00. Entire XRC session suspends 12:15. XRECOVER session all data consistent as of 11:59 12:30. Start DB2 with data consistent. 12:55. Applications running Storage control 44 ATS - DB2 for z/os

45 DB2 XRC Restart Procedures 1. Perform XRC Specific Tasks XSUSPEND - breaks connection between control units XEND TSO command to terminate XRC XRECOVER TSO command to change secondary to primary volumes Brings all volumes to consistent recoverable state using SDM d/s Labels all secondaries with volser of primary volume Lists timestamp of point of consistency on query report 2. IPL z/os Images z/os Images from the local site 3. Force all DB2 structures at recovery site (GBPs, Lock, SCA) Failure to force most common reason for DR failure CF not synchronized with SDM 4. Prepare for restart Use local DSNZPARM members If using DDF, update LOCATION and LUNAME in BSDS(Change Log Inventory) 45 ATS - DB2 for z/os

46 DB2 XRC Restart Procedures Start all DB2 members Normal, not conditional restart Group restart will be performed - rebuild Lock/SCA Pages added to LPL during restart Shared data sets set to GRECP 6. After restart display all d/s in GRECP/LPL Display DB(*) SPACE(*) RESTRICT (GRECP,LPL) LIMIT(*) command 7. Start DB2 Directory/Catalog START DB(DSNDB01) SPACE(*) START DB(DSNDB06) SPACE(*) 8. Display and -TERM UTIL(*) - see next page for considerations -DIS UTIL(*) Run DIAGNOSE DISPLAY SYSUTILX (identify phase and object) -TERM UTIL(*) 9. Recover all restricted data sets START DB(xxx) SPACE(*) <90 objects in list/10 jobs per member LOGAPSTG=100 for FLAs 10. DB2 is available for new work 46 ATS - DB2 for z/os

47 Best Practice for GRECP/LPL Recovery DSNZPARM LOGAPSTG=100 Not online zparm Submit 10 start commands jobs/member Each start command processes 10MB log segment Start DB(dbname) sp(*) command format Precoded <70- data sets/command (max is 98) for growth If dbname has 100s page sets, wild card Start DB(dbname) sp(abcd*) Prioritize start order by critical applications/data base Do not issue individual data set commands Great contention on active log, even though both copies are used Can take a few minutes if <500 to perhaps an hour if ATS - DB2 for z/os

48 What to do about active Load/Reorg Utilities Process is opposite that in traditional DR in Administration Guide ƒbecause data is mirrored ƒsort work and other work data sets are not mirrored, so utilities must be terminated. LOAD ƒshrlevel CHANGE (V7) backs out to commit point; finish it at your convenience ƒ LOG(NO) SHRLEVEL NONE > RELOAD phase, data is okay - rebuild indexes Else Recover to start of utility (need "before" image copy at recovery site) CHKP may be set if RI relationships existi REORG SHRLEVEL NONE > RELOAD phase, data is okay - rebuild indexes < Start of RELOAD, data and indexes still okay. No further action = RELOAD phase, recover to utility start (need "before" image copy at recovery site) REORG (all other SHRLEVELs) < SWITCH phase, original data sets okay. No further action required = SWITCH phase, original data sets remain. No further action required > SWITCH phase, reorged data sets okay. Rebuild for NPI Logical Partitions may be necessary 48 ATS - DB2 for z/os

49 XRC Experience - How big? Customer wants to mirror 8000 volumes over 1800 miles Largest XRC production level benchmark- in Gburg in K volumes (mixed vendors, including ESS) CICS/VSAM and DB2 data sharing 48TB DASD (24 Primary/24 Secondary) 6400 MIPS Simulated workload of 15,000-40,000 Write IO/sec ƒresults Peak stress at 5 times current peak Delay times sec range - peak stress sec Distance is not a performance issue Scalable! 49 ATS - DB2 for z/os

50 What to remember about Global Mirror XRC Automatic data consistency Normal DB2 Restart - simplest procedure Data Sharing - shared data sets in GRECP Group Restart No performance penalty for distance Minimal impact on local DB2 performance Asynchronous process means secondaries lag slightly Rough ROT XRC consumes ¼ mips at recovery site vs. local site (Storage reps have tools for accuracy) Testing needs 3 rd copy of data to avoid exposure (FC) Scales well (number of volumes/distance between sites) 50 ATS - DB2 for z/os

51 How PPRC Works (Synchronous - Metro Mirror) DB2 Subsystem Primary storage control ESS Write (channel end) 2. Write to secondary 3. Write hit at secondary 4. Acknowledgment (Device End) Secondary storage control ESS 51 ATS - DB2 for z/os

52 When to use Metro Mirror PPRC No data loss between recovery system and primary DB2 system Can accept some performance impact to DB2 write I/O operations at the primary location Recovery is on an LSS/LCU basis DB2 SSID usually exceeds Distance within maximum ESCON/FICON limits 103 km (61 miles) for DASD 40km if parallel sysplex due to timer links 52 ATS - DB2 for z/os

53 Comparison of Global Mirrors - XRC and PPRC XRC DB2 Independent? Yes Yes Type of Solution Hardware/Software Hardware PPRC Design Point Recovery Is recovery data current? No effect on local performance Entire session (across ctl. units) Except bytes in transit Maintain data currency at secondary site LSS basis Secondary DASD fully current Copy Operation Asynchronous Synchronous Copy Distances any distance 103 km (61 mi) (channel extender) 53 ATS - DB2 for z/os

54 Advanced Technical Support GDPS -Single Site Workload SITE 1 SITE 2 CF1 CF2 1A 1B 1K P P P S S S One Sysplex with production systems in one site and monitoring system in other site Expendable workload in other site All primary data in one site; all secondary data in other site 54 ATS - DB2 for z/os

55 Why Metro Media PPRC works in GDPS FREEZE Policy Options FREEZE & GO Freeze secondary DASD configuration Allow DB2 to continue Optimize for remote restartability Least impact on local DB2 availability May lose data in case of real disaster FREEZE & STOP Freeze secondary DASD configuration Stop all z/os images Optimize for remote restartability May impact local DB2 availability No data loss on primary site disaster FREEZE & STOP Conditional Freeze secondary DASD configuration Determine reason for Suspend ƒif secondary HW problem then FREEZE & GO ƒother reason: FREEZE & STOP 55 ATS - DB2 for z/os

56 Unplanned Cross-Site Reconfiguration Unplanned Cross-Site Reconfiguration ANALYSIS FREEZE Customer business policies ƒfreeze & Go, Freeze & Stop, Freeze & Stop Conditional AUTOMATION ERROR EVENT ƒsysplex ƒdisk subsystem I/O consistent secondaries ƒacross multiple CUs ƒmultiple host systems SITUATION MANAGEMENT ƒconfirm recovery action ƒexecute Freeze policy ƒquiesce application systems or allow applications to continue ƒremove failed site systems from Parallel Sysplex ƒperform disk reconfiguration ƒperform CF reconfiguration ƒswitch Network ƒrestart workload 56 ATS - DB2 for z/os

57 Advanced Technical Support GDPS - Single Site Workload - Site 1 Failure SITE 1 SITE 2 CF1 CF2 1A 1B 1A 1B 1K P P P P P P Freeze and recover secondary DASD Stop expendable systems Restart DB2 & critical systems in site 2 (shared data in GRECP) 57 ATS - DB2 for z/os

58 GDPS Experience Achievements ƒ33 TB DASD ƒ11,000 PPRC volume pairs ƒit Austria 11-way Sysplex switched in 2 hours (2002) May, 2003 < 1.5 hours GDPS meets / exceeds requirements ƒdata current and consistent at recovery site ƒfreeze and Stop Conditional (DB2 GBPs duplexed across sites) ƒrecovery time less than expected 58 ATS - DB2 for z/os

59 What to remember about GDPS PPRC Provides near continuous application and data availability Planned reconfigurations (for hardware, software, site maintenance ) Unplanned reconfigurations (for site and other failure) Parallel Sysplex within ESCON/FICON distance In case of disaster Insures data consistency and integrity with no data loss Offers prompt, responsive disaster recovery Data Sharing considerations Data shared at the time (in the Group Buffer Pools in the Coupling Facility) is in GRECP following startup. Automation script can issue commands (range: min if 100s to hour if 10K) Hyperswap for HA configuration at local site requires GDPS or PPRC Hyperswap Manager (3/2005) PPRC all volumes locally (maybe same room) For control unit failure, can switch in seconds to secondary copy with no outage. 59 ATS - DB2 for z/os

60 Metro/Global Mirror - No Data Loss Distance PPRC & XRC Site 1 Site 1a Site 2 Dasd Farm Product. System K SDM K SDM & K Systems P K-System CNT limited distance XRC CNT unlimited distance K-System S S S Production System & application data PPRC P/P P/P Production System & application data S S 60 ATS - DB2 for z/os

61 PPRC Extended Distance (Global Copy) Concepts... Channel Extenders, DWDM ESCON links Distance links ƒnon-synchronous transfer of application updates to secondary ƒupdates to primary ESS PPRC-XD volume are considered complete prior to transmission to the secondary ESS volume ƒwrite updates to primary volume receive an immediate primary completion while in XD ƒupdates are continuously transferred to remote ESS in a nonsynchronous mode ƒgenerates a fuzzy copy at secondary volume until forced to synchronous (tracks not applied in local sequence) ƒpprc-xd data integrity for disaster recovery provided via DB2 operations ESCON links 61 ATS - DB2 for z/os

62 PPRC-XD 'Catchup' Methodology To obtain consistent copies for Disaster Recovery purposes: ƒpprc-xd mode can be transitioned to PPRC-SYNC (synchronous mode) PPRC-XD command estimatation of data/time to sync ƒ OR -SET LOG SUSPEND to stop DB2 logging - consistency WILL occur naturally ƒupon reaching full duplex mode (consistency) the PPRC pairs can be temporarily suspended followed by a FlashCopy on the secondary ESS to save the consistent point on a tertiary set then a resumption of PPRC-XD mode to resume mirroring ƒthis method produces a point-in-time consistent copy at the remote site suitable for DR PRIMARY SECONDARY TERTIARY VOL A CHAN EXT With PPRC-XD Asynchronous Transfer Over Long Distance CHAN EXT VOL B 3-FlashCopy VOL C Little Performance Impact Then "Go-to-sync' Then Duplex Then Suspended/Frozen 1-PPRC-XD 2-PPRC-SYNC Fuzzy Volume Consistent Application Consistent (by FREEZE) 62 ATS - DB2 for z/os

63 Creating a Consistent Point - Catchup methodology Automate the following: PRIMARY Vol A PPRC OVER LONG DISTANCE SECONDARY Sequence of Operation: 1. Establish PPRC Extended Distance pairs A-B volumes 2. Run in PPRC-XD mode until Consistent Copy needed at 2nd site 3. When Consistent Copy Needed: issue -SET LOG SUSPEND Or (not necessary for DB2) Issue Establish PPRC pair command to "Go Synchronous" Allow pairs to synchronize Performance degradation due to SYNC mode (n/a if #3) 4. Monitor for PPRC-SYNC being reported across all pairs, as updates dry up. That creates "Consistency Group" on the secondary volumes at 2nd site 5. CGROUP FREEZE (all LSSes) 6. Issue -SET LOG RESUME for DB2 to resume activity CHAN EXT CHAN EXT Vol B Vol C FlashCopy 63 ATS - DB2 for z/os

64 Creating a Consistent Check - Catchup methodology... Automate the following: PRIMARY SECONDARY Vol A CHAN EXT PPRC OVER CHAN EXT LONG Vol B Vol C DISTANCE FlashCopy Sequence of Operation (continued): 7. Issue PPRC CGROUP RUN command at primary site so that DB2 can write to DASD (note PPRC linkage to 2nd site is still SUSPENDed) 8. Issue FlashCopy B-C volumes at secondary site (no impact to host) 9. When FlashCopy is initialized, reestablish PPRC Paths 10. Reestablish PPRC Pairs in Extended Distance Mode 11. Go back to Step ATS - DB2 for z/os

65 Compare PPRC-XD to XRC for DB2 No running SDM required (consumes mips) Save at least one z/os license (SDM should be on a dedicated LPAR) Minimize z/os license cost if normal operation is DASD farm ƒipl and bring up z/os only for tests Bandwidth less than that for XRC Some % less, will be that far behind - key is your RTO You create your own "consistency group" ƒvia -SET LOG SUSPEND ƒand you catch up, as writes trickle to a stop ƒdaily CG vs XRC (continually) ƒrpo > XRC Distance unlimited and less $$$$ 65 ATS - DB2 for z/os

66 What to remember about PPRC-XD Good ƒlocal site response time negligible while in XD mode ƒno distance limitations ƒsimilar to XRC but lower cost and flexible bandwidth ƒcopies can finish faster than Set Log Suspend/FC scenario (catch up vs. full FC) ƒlocal site response time degradation while in "go to Sync" mode ƒbut -SET LOG SUSPEND makes "go to Sync" unnecessary Bad ƒone CG daily usually ƒ Go to sync degrades performance of other applications ƒissues ƒdata Currency = Time between FlashCopies ƒlog apply is iffy if local site loss, use FC data and tape archives to minimize RPO using Restore System Logonly, increasing RTO ƒrequires the -SET LOG SUSPEND to catch up ƒrequires SET LOG SUSPEND to capture RBLP in V8 for log apply. 66 ATS - DB2 for z/os

67 Metro/Global Copy Asynchronous Cascading PPRC 3 site long distance solution like Metro/Global Mirror where PPRC-XD between Intermediate and remote sites replaces XRC Same secondary volume serves as both target & source Metro Mirror PPRC relationship between Local and Intermediate sites Global Copy PPRC-XD between Intermediate and remote sites How Consistency is obtained (operational procedures) Freeze local pairs (CG enabled on LSS basis returns ELB while formed) Local- Intermediate pairs suspended until CG formed then resumed Intermediate does automatic catchup to remote site When 100% synced, FC to Tertiary DASD at remote site to capture POC Resync Local > Intermediate PPRC and continue GDPS needed for failover to Intermediate if Hyperswap Local Pairs Remote Pairs Host I/O Primary Local Site Primary Secondary Intermediate Site Global Copy Secondary Remote Site FC FlashCopy target 67 ATS - DB2 for z/os

68 Getting Consistent Point with no disruption to local DB2 FRE EZE zseries 1 Primary Local Site PPRC Sync SUSPEND Primary Secondary Intermediate Site PPRC-XD Secondary Remote Site RUN zseries I/O 2 Primary Local Site PPRC Sync SUSPEND Primary Secondary Intermediate Site PPRC-XD catch-up GO TO SYNC Secondary Remote Site zseries I/O 3 Primary Local Site PPRC Sync SUSPEND Primary Secondary Intermediate Site PPRC-XD Secondary Remote Site FlashCopy Tertiary zseries I/O 4 Primary Local Site PPRC Sync RESYNC Primary Secondary Intermediate Site PPRC-XD Secondary Remote Site Tertiary PiT copy 68 ATS - DB2 for z/os

69 Notes for previous slide 1. With CG enabled (ELB=2min). Primary LSS is frozen, paths are removed, PPRC pairs suspended all LSS secondary at same point 2. DB2 doesn t stop (ESS enqueues I/O briefly). Consistency Created (or RUN) starts I/Os to primary volumes. Secondary suspended consistent no new I/O received. Catch up process begins using XD from intermediate to remote site 3. When remote site is 100% synced, FC to create consistent point. 4. When FC relationships established, redefine paths from primary to secondary and resync local > intermediate sites. Updates now sent primary > intermediate and propagated to remote site by XD. DB2 restarts from last FC consistent point. No log apply. Consistency obtained without disruption, unlike PPRC-XD Global Copy 69 ATS - DB2 for z/os

70 Global Mirror PPRC Overview PRIMARY APPLICATION HOSTS REMOTE APPLICATION HOSTS PPRC 'A' PRIMARY CHAN EXT PPRC-XD OVER LONG DISTANCE CHAN EXT 0 PPRC B Secondary FLC Source FLC C Target Local Site FlashCopy Remote Site PPRC Extended Distance from local to remote site Automatic periodic consistent copies created at remote site Volume A uses change recording bitmap while consistency group is created All data sent to remote and inband FlashCopy at remote creates consistent data on volume C Designed to adjust to peak workloads without impacting local writes 70 ATS - DB2 for z/os

71 Global Mirror how it works PPRC Primary PPRC Secondary FlashCopy Source FlashCopy Target FlashCopy A PPRC-XD B C Local Site Remote Site Automatic Cycle in a Global Mirror Session 1. Create Consistency Group of volumes at local site A volumes 2. Send increment of consistent data to remote site B volumes 3. FlashCopy at the remote site B > C volumes 4. Continue PPRC-XD transfer and start step 1 after user specified time 71 ATS - DB2 for z/os

72 Global Mirror Unplanned Outage - Recovery 1. Issue FAILOVER to PPRC B volumes to establish B>A Volumes become SUSPENDed primaries 2. Check FlashCopy status (query each volume pair) Revert or commit current FlashCopy relationships depending on status 3. Fast Reverse Restore FlashCopy C>B After command is issued, the C volumes are not useable 4. Wait for background copy to complete 5. FlashCopy B>C with the same options used during the initial setup 6. DB2 restart occurs using the B volumes PRIMARY DB@ REMOTE DB2 FlashCopy PPRC 'A' PRIMARY CHAN EXT PPRC-XD OVER LONG DISTANCE CHAN EXT 0 PPRC B' Secondary FC source FLC Source C FC target FLC C Target Local Site Remote Site 72 ATS - DB2 for z/os

73 What to remember about Global Mirror Good Local site response time negligible No distance limitations Two site long distance disaster recovery and backup remote copy solution for zseries No rolling disaster Does not need GDPS for consistency at secondary site Consistency groups established / maintained every 3-5 seconds RPO Depends upon workload and bandwidth between the local and remote sites Consistency across volumes residing within multiple ESSs Avoid manual efforts in FlashCopy solutions or Global Copy solution Set Log Suspend FlashCopy Bad Limit is 8 ESSs in both sites Need 3X DASD space at remote site to test while preserving DR capability No TSO interface yet - important for z/os users. 73 ATS - DB2 for z/os

74 DS8000 Advanced Copy Services functions available on the ESS 800 are all available on the DS8000 (except for Metro/Global Copy) Statement of Direction (will be available on DS8000 and DS6000) Allow intermediate site to use Global Mirror to the remote site Provides data consistency in the event both the local and intermediate sites are lost in a disaster Local Pairs Remote Pairs Host I/O Primary Primary Secondary Global Mirror Secondary FC FlashCopy target Local Site Intermediate Site Remote Sit e 74 ATS - DB2 for z/os

75 What to Remember about this presentation The good, the bad, and the ugly ATS - DB2 for z/os

76 The Critical Question for DB2 staff Solution Traditional DR FlashCopy DR Restore Sys Logonly Global Mirror XRC Metro Mirror PPRC GBPS PPRC Metro/Global Mirror Global Copy (PPRC-XD) Metro/Global Copy Async. Cascading PPRC Global Mirror PPRC CG Frequency daily Daily or better as FC frequency Daily or better < seconds none n/a - synchronous < seconds Daily or better Daily or better 3-5 sec How CG is created You truncate log You Set Log cmd and FC You Set Log cmd and FC System Data Mover none GDPS freeze LSS unit command all LSS/LCU GDPS and System Data Mover You - Set Log cmd and FC You FC at remote site Global Mirror 76 ATS - DB2 for z/os

77 What to remember about this session Traditional DB2 DR Learning Points ƒgood DB2 always available lowest cost option - no infrastructure needed at recovery site ƒbad Complex - people cost to develop/test/maintain Customer may purchase tools or write them to assist Deep recovery skills needed at recovery site RTO/RPO may be 24 hours ƒissues User data recovery neglected by customer due to division of responsibility (systems vs. applications) - may increase RTO Vaulting archive tapes at vendor site reduces RPO to 'almost current' while elongating RTO (more log to pass) Due to complexity, customer inclined to play 'fool the auditor' 77 ATS - DB2 for z/os

78 What to remember about this session... FlashCopy and Log Suspend/Resume Learning Points ƒgood Easy to implement for DB2 staff (storage staff establish) No DB2 complex recovery procedures (restore DF/DSS dumps) RTO within a couple of hours Normal restart of DB2 No Infrequent and/or incremental image copy application issues No infrastructure needed at recovery site ƒbad Short outage to suspend and resume logging No update activity / log write latch held Perform at time of low activity Data Sharing - shared data sets set to GRECP and recovery required (simple to do but lengthy if many shared data sets) Need duplicate DASD and FlashCopy license at local site Need sufficient tape drive to dump secondaries for transport RPO is still up to 24 hours behind 78 ATS - DB2 for z/os

79 What to remember about this session... FlashCopy and -Log Suspend Issues Vaulting archive tapes at vendor site reduces RPO to 'almost current' while elongating RTO (more log to pass) RESTORE SYSTEM LOGONLY makes this viable 79 ATS - DB2 for z/os

80 What to remember about this session V8 Useful for non-mirroring DR scenarios ƒgood BACKUP SYSTEM is simple one step backup and allows most updates Even Log suspend less disruptive than V7 Future recovery point determined and saved in DB2 as RBLP Restore System Logonly eliminates complexity for FlashCopy restore with log apply One step Recovery starts at RBLP and process all data set restoration using restart type logic For DR, no need for BACKUP SYSTEM / RESTORE SYSTEM h/w, s/w Image copies not usually required, unless Reorg/Load occurs since RBLP ƒbad BACKUP SYSTEM utility not directly useful for DR user must make own tape copies of COPYPOOL for transport 80 ATS - DB2 for z/os

81 What to remember about this session... Global Mirror XRC Learning Points ƒgood Easy to implement for DB2 staff (storage staff establish) DB2 is fully available RPO current (within milliseconds) No DB2 complex recovery procedures Infrequent and/or incremental image copy application issues eliminated Current RTO - Normal restart of DB2 Elimination of "Rolling Disaster" Scales to any amount of DASD/distance not limited to DB2 data can be used for planned outage ƒbad Cost - Second site with one SDM required and duplicate DASD Data Sharing - shared data sets need GRECP and recovery (simple to do but lengthy if many shared data sets) Bandwidth required to achieve millisecond lag 81 ATS - DB2 for z/os

82 What to remember about this session... Global Mirror XRC Issues Poor Man's version - XRC only DB2 catalog/directory BSDS/Logs (rationale: keep the above current, perform PIT recovery for applications in traditional manner) cost consideration -less than full XRC - faster than Traditional DR - no data loss Leave it up to applications to recover (political) 82 ATS - DB2 for z/os

83 What to remember about this session... PPRC technology Rolling disaster exposure Time consistent secondaries with 1 LSS DB2s usually exceed 1 LSS If used for > 1 LSS, needs help GDPS (automation FREEZES all LSSs at first sign of interruption Global Copy (YOU create consistency group) Global Mirror (Master and Subordinate LSSs create consistency group every few seconds) 83 ATS - DB2 for z/os

84 What to remember about this session... GDPS Learning Points ƒgood DB2 staff minimally involved DB2 is fully available RPO current No DB2 complex procedures No Infrequent and/or incremental image copy application issues Current RTO Simple normal restart of DB2 Elimination of "Rolling Disaster" can be used for planned outage Can also be used for local CU/LSS micro code failure with Hyperswap Automation and Freeze policy implemented easily ƒbad Cost - Second site with full capacity with duplicate DASD (Sysplex timer and CF) For Data Sharing, all shared data sets set to GRECP and recovery required until CF Freeze. Simple scripted command but lengthy recovery if thousands of shared data sets Must be within ESCON/FICON distance (40KM - timer link limitation) IPL until Hyperswap (switches secondary to primary non-disruptively) 84 ATS - DB2 for z/os

85 What to remember about Global Copy PPRC-XD Good ƒlocal site response time negligible while in XD mode ƒno distance limitations ƒsimilar to XRC but lower cost and flexible bandwidth Bad ƒmanual Set Log Suspend creates the consistency point vs automatic in XRC and Global Mirror Issues ƒrpo = Time between FlashCopies but if loss of local site, you can use FC data and tape archives with Restore System Logonly to minimize RPO at expense of RTO (Flavor 2) Local site response time degradation while in "go to Sync" mode But -SET LOG SUSPEND eliminates "go to Sync" ƒthird set of DASD for DR copy ƒrequires the -SET LOG SUSPEND to catch up 85 ATS - DB2 for z/os

86 What to remember about Global Mirror PPRC Good Local site response time negligible No distance limitations Two site long distance disaster recovery and backup remote copy solution for zseries No rolling disaster Does not need GDPS for consistency at secondary site Consistency groups automatically established / maintained every 3-5 seconds RPO Depends upon workload and bandwidth between the local and remote sites Consistency across volumes residing within multiple ESSs Open system volumes can be included in CG Avoid manual efforts in FlashCopy solutions or Global Copy solution Set Log Suspend FlashCopy No need for Log Apply scenario CG is current simple restart Bad Limit is 8 ESSs in both sites Need additional copy of data to test (3/x DASD at remote site) 86 ATS - DB2 for z/os

87 Data Loss (RPO) Advanced Technical Support Days Volume Dumps Data Loss and Recovery Time 24 Hours FlashCopy PTAM Conventional Transport "PTAM" Hours Minutes Seconds GDPS, XRC, Global Mirror Minutes Tracker Site PPRC-XD Remote Remote Copy Copy + Log & Apply Log Apply Hours Vaulting RRDF (Logs) Day Recovery Time (RTO) 87 ATS - DB2 for z/os

88 IBM Software Group Tracker Site for DB2 V8 88 ATS - DB2 for z/os

89 Overview of Local and Tracker Site Local Site Tracker Site MVS1 MVS2 DBP1 Image Copies DBP1' Catalog Directory Data Archive Logs Catalog Directory Data LOGS BSDS LOGS BSDS "Tracker " is a active DB2 at the recovery site which can keep shadow copies of local site data close to current -can take over in case of disaster 89 ATS - DB2 for z/os

90 "Tracker Site" Recovery with DB2 V8 Advantages: Data sets may be recovered sooner than Traditional D/R Avoids extra bandwidth costs of 'mirroring' or shipping of log records (RRDF) Restore System Logonly used Can be data sharing or not Fewer image copy tapes may be transported Costs: A 'live' DB2 started up periodically to keep data sets current Level of currency: Same as traditional, better as more PTAM runs/day 90 ATS - DB2 for z/os

91 Keys to Tracker Site Scenario Continuous update to data through RESTORE SYSTEM LOGONLY V8 utility Objects in RBLP or RECP can be recovered before shutdown from image copies transmitted to recovery site ƒrestore System Logonly sets restart ENDRBA in header page ƒjust like Recovery t/s logonly Tracker site data can be no more or less than what is on local site's logs ƒtracker site DSNZPARM must have TRKRSITE=YES SITETYP=RECOVERYSITE (strong recommendation) ƒcrestart record ENDRBA as traditional except FORWARD=NO,BACKOUT=NO 91 ATS - DB2 for z/os

92 Restrictions on Tracker Site Must keep objects consistent with log data ƒno DDL, DCL, DML except SELECT ƒno archives ƒlimited utilities ƒcannot -TERM most utilities if in progress ƒdynamic SQL limited to queries ƒpractically no useful work 92 ATS - DB2 for z/os