DB2 for z/os Design for High Availability

Transcription

1 Session: A09 DB2 for z/os Design for High Availability John J. Campbell DB2 for z/os Development IBM Silicon Valley Lab 7 November :00 a.m. 12:00 a.m. Platform: DB2 for z/os 1

2 Agenda Availability Issues Reduce planned & unplanned downtime Manage to Service Level Agreement Service strategy Data sharing Planned outage reduction evolution V6, V7, V8, V9 Virtual storage management Restart Recovery Outage analysis and miscellaneous 2 2

3 What can go wrong in Continuous Availability? Users Applications Operations Database Administration Systems Administration Software defects Data Integrity Performance Locking & concurrency Continuous Operations 3 What can go wrong, go wrong, go wrong... Almost everything. Many problems and mistakes can be tolerated, but compounding into two, three or four mistakes is when we have outages. Without some help at every level, and a concern for high availability, we provide some potential for problems. The key to success is having a service level agreement that can be used to justify costs when needed and the commitment of everyone. One of the key tradeoffs for continuous availability is data integrity. The first priority for DB2 is data integrity, and there are situations where an outage results from the need for data integrity. With DB2, customers can achieve availability of 3 nines or roughly three hours of downtime per year with excellent planning and implementation. 3

4 Reducing planned & unplanned downtime Planned downtime Data sharing Utilities Online ZPARMs Schema evolution Extending boundaries & removing limitations Improved concurrency & outage granularity Unplanned downtime Service strategy Data sharing Improved restart processing Faster, less disruptive recovery Automatic recovery Better fault toleration 4 4

5 Managing to Service Level Agreement Manage Set availability criteria - balance needs & costs Use criteria to determine procedures Invest in adequate test environments Majority of outages unlikely to be due to IBM software defects Major improvements in IBM testing CCE CST Test & staging environments still required Practice operation and recovery If not meeting criteria, then tune Education for skills and time to do the job Stay reasonably current with DB2 releases & fixes 5 The key for managing is a service level agreement and the resources needed to meet that agreement. High availability requires some spare resources. The availability criteria provide objectives that can help determine the needed processes. See Application Design Guidelines for details on most of these points. Everyone gets to practice recovery at some point. The practice is more difficult if the application is down. The only real way to determine if criteria are being met is to test and the second benefit is practice. Doing something right the very first time is unusual. A number of DB2 fixes and improvements in new versions are helpful for higher availability. While you don't want to be too current on service, being far behind has outage costs too. Isolation for high availability or high impact work loads will help improve availability. Common problems include long running units of recovery and not enough image copies. Set a standard. Warn programmers and then begin to cancel work which could impact the service level. There are enough options now so that committing every few seconds has little impact upon performance. Monitor to be sure copies are frequent enough. All batch work should be designed for running with other work to avoid the need for a batch window. System affinities should be avoided or eliminated when possible. 5

6 Service Strategy Stay reasonably current with DB2 releases & fixes Recommended process: Consolidated Service Test levels Upgrade service 3-4 times / year Examine HIPERs and PEs regularly PE% Old Bugs Stage through test to dev to prod Review PEs before migrating to prod Months Revisit & fine-tune based on experience, but avoid knee-jerk reactions Aggressive exploiter of new function or problems encountered are rediscoveries be more current Conservative use of DB2 function or encountering new defects consider stepping back slightly 6 The key points for a service strategy is that there are good guidelines, but the timing requires judgement more than simple rules. These scales are not the same. You must provide the judgement and balance. Timing for moving preventive service into production is a carefully judged balance between the potential problems caused by PTFs containing an error (PEs) and the potential to encounter problems that could be avoided by applying the maintenance in a more timely fashion. About 70% of PEs are found within four months after the PTF is closed. Currently, about 4 PEs are found every month in the much large volume of APARs (over 100 per month). The blue bars reflect the percentage of PEs yet to be found. The systems programming work load and the availability of windows for installing service can affect the implementation timing. The process we recommend for service is to upgrade the service levels four times a year. The suggested process is to choose a PUT level for all service, then a one or two month later level for hipers and PE fixes. Stage that level through the development systems to the production ones. Some of the additional testing done by Consolidated Service Test may be helpful as a recommended service level. Over a longer period of time, it may be useful to match your levels with those of the CST, across the operating system and key subsystems. 6

7 Leveraging the platform Benefit from traditional platform robustness Synergy with hardware, z/os & storage subsystems Parallel sysplex 64 bit virtual Hardware compression WLM GDPS Hyperswap System level backup & restore 7 The key points for a service strategy is that there are good guidelines, but the timing requires judgement more than simple rules. These scales are not the same. You must provide the judgement and balance. Timing for moving preventive service into production is a carefully judged balance between the potential problems caused by PTFs containing an error (PEs) and the potential to encounter problems that could be avoided by applying the maintenance in a more timely fashion. About 70% of PEs are found within four months after the PTF is closed. Currently, about 4 PEs are found every month in the much large volume of APARs (over 100 per month). The blue bars reflect the percentage of PEs yet to be found. The systems programming work load and the availability of windows for installing service can affect the implementation timing. The process we recommend for service is to upgrade the service levels four times a year. The suggested process is to choose a PUT level for all service, then a one or two month later level for hipers and PE fixes. Stage that level through the development systems to the production ones. Some of the additional testing done by Consolidated Service Test may be helpful as a recommended service level. Over a longer period of time, it may be useful to match your levels with those of the CST, across the operating system and key subsystems. 7

8 Planned outages Data sharing Schema evolution Utility improvements Online ZPARMs Extending boundaries & removing limitations Locking enhancements Other 8 8

9 Data sharing Goal: Continuous availability across any planned or unplanned outage of any single hardware or software element Work dynamically routed away from down member Rolling updates Software upgrades ZPARM updates Non-disruptive CF upgrades Rebuild CF structures to alternate CF Invest to gain full benefit of data sharing Remove application affinities Ensure even distribution of workload to minimize capacity issues DB2 Group X DB2A DB2B DB2n "spare" DB

10 CF Duplexing GBP duplexing available since V5. Recommendation: use it. Duplexing for Lock and SCA available in V7 Uses z/os "system managed" CF duplexing CF1 CF2 which became GA in Feb '04 Useful to remove Internal Coupling Facility (ICF) as a single point of failure Performance impact will depend mostly on DB2A DB2B... DB2n intensity of CF lock requests for your application and distance between CFs Pre-requisites: z/os 1.2 or above plus maintenance See CFDUPLEXING PSP Bucket CFCC level 12 driver 3G (zseries), or CFCC level 11 driver 26 (9672) CF-to-CF links

11 GDPS PPRC HyperSwap Site failover DB2 data sharing group must still be recycled to recover CF structures New technology under development to avoid having to recycle DB2 members DASD failover New GDPS HyperSwap Manager announced 2/15/05 Entry level GDPS offering Keep data available to end user apps during disk subsystem maintenance or failure DASD failure is transparent to DB2 GDPS HyperSwap prerequisites Disk subsystems that support PPRC level 3 (extended query) IBM Tivoli System Automation for GDPS/PPRC HyperSwap Manager swap_manager.html P UCB application PPRC UCB Near continuous availability for DASD failures or site failures 11 S 11

12 Data sharing availability enhancements V6 STOP DB2 CASTOUT(NO) Faster shutdown processing V7 RESTART(LIGHT) Persistent structure size changes V8 New locking protocol 2 Reduce false lock contention on parent L-locks Remove requirement for RELEASE(DEALLOCATE) in data sharing Improved concurrency for partitioned tablespaces (LOCKPART YES) RESTART(LIGHT) changed to wait for resolution of indoubt URs V9 Auto-GRECP recovery after restart Auto-GRECP recovery for other GBP failures since V

13 Other data sharing availability benefits Better data availability during postponed abort UR processing Reliance on retained locks rather than setting RESTP on whole objects Further improved in V9 for segmented tablespaces See restart section Faster restart times, even with Fast Log Apply See restart section 13 13

14 V6 planned outage enhancements Alter limitkey for repartitioning Alter VARCHAR length Set LOGLOAD parameter online Parallel index build REORG LOAD REBUILD INDEX 14 14

15 V7 planned outage enhancements Online ZPARM changes Add new workfiles dynamically Avoid STOP/START of workfile database Alter LOCKSIZE for most catalog objects Online REORG enhancements FASTSWITCH to avoid dataset rename Parallel BUILD2 phase Online LOAD RESUME Real Time Statistics Simplified data management Positioning for future autonomic enhancements CANCEL THREAD NOBACKOUT 15 15

16 V8 planned outage enhancements Extending boundaries Max partitions from 254 to 4096 Number of active logs from 31 to 93 Archive logs increased from 2,000 to 20,000 Additional online ZPARMs Automatic space management Sliding secondary allocation quantity size New pagesets: No need for PRIQTY/SECQTY Existing pagesets: Alter PRIQTY/SECQTY to -1 & REORG 16 16

17 V8 planned outage enhancements Schema evolution Add new partition Rotate partitions Alter data types Add index columns Add/drop clustering indexes Alter indexes to not padded Remove requirement for partitioning index Data partitioned secondary indexes Eliminate BUILD2 phase of REORG if no NPIs exist Eliminate LOAD PART contention Reduce datasharing overhead 17 17

18 V8 planned outage enhancements Online REORG enhancements REBALANCE on REORG SHRLEVEL NONE/REFERENCE DISCARD on REORG SHRLEVEL CHANGE REORG SHRLEVEL REFERENCE on all catalog tables SHRLEVEL CHANGE always allowed for non-linked tablespaces Insert/update/delete through indexes in RBDP/RECP 18 18

19 V9 outage enhancements LOB locking reduction No longer accumulated for UR readers LOB REORG SHRLEVEL REFERENCE REORG SHRLEVEL CHANGE REFERENCE BUILD2 phase elimination Cloned tables Allow fast replacement of production data without renames or rebinds Partition by growth Eliminate need for partitioning key and key range specification Avoid re-ipl for EARLY code changes 19 19

20 Virtual Storage Management Background DBM1 "out of storage" is one of the leading causes of customer reported outages Abend 04E/00E20003 or 04E/00E20016 Several drivers: Bigger machines, higher workload volumes Increasing use of dynamic SQL New Java and Websphere workloads Over-allocation of buffer pools, threads Massive number of open datasets (with compression) Largest consumers of DBM1 virtual include: Buffer pools EDM pool Local dynamic statement cache Thread storage Compression dictionaries DB2 has several enhancements to allow you to control virtual storage usage 20 20

21 Virtual Storage Management - tuning tips If you are running short of DBM1 virtual, consider one or more of the following: Monitor & plot IFCID 225 data Monitor INFO APAR II10817 and apply recommended maintenance Use data space buffer pools if running on a 64 bit machine Use hiperpools if not on a 64 bit machine Scale back usage of RELEASE(DEALLOCATE) Version 8 removes need for REL(DEAL) to avoid XES lock contention Set CTHREAD and MAXDBAT defensively Set CONTSTOR=YES Reduce number of open compressed datasets Run IRLM PC=YES, reduce ECSA With Version 8 PC=NO no longer an option Consider making more use of data sharing to spread the work Consider implementing Version 8 64bit virtual 21 IFCID DBM1 storage summary Snapshot at each DB2 statistics interval Activated via Stats Class 6, or Zparm SMFSTAT IFCID DBM1 storage detail Mostly used for serviceability Supported by DB2 Performance Monitor / Expert Some recent related APARs: Ensure PQ76942 applied Enhanced in V7 apars PQ73385 to reflect actual MVS memory map for DBM1 PQ91101 for improved statement cache and real storage statistics 21

22 DB2 64 bit evolution V8 Why 64-bit? Needed for DB2 to continue to scale on a single OS image More concurrent threads Bigger buffer pools Large memory exploitation DBM1 and IRLM are 64bit address spaces in Version 8 The following data areas are moved above the 2GB "bar" Buffer pools, BM control blocks Castout buffers RID pool EDM DBD cache (OBDs) Global dynamic stmt cache Sort pool Trace tables (Global, Lock, BB) Accounting blocks Compression dictionaries IRLM locks Max buffer pool size is lifted to 1 TB New PGFIX(YES) option can give significant performance benefits Data space pools, hiper pools are eliminated - easier management 22 The biggest impact of the zseries architecture on DB2 is the ability to have large real memory support. Prior to the zseries, customers were limited to 2 GB real storage due to the 31-bit addressing of the S/390 architecture. The real storage limit of 2 GB is a leading performance inhibitor for many high end customers. Another leading performance inhibitor is the 2 GB virtual storage limit for the main DB2 (DBM1) address space. Moving virtual pool buffers to hiperpools offers some relief, but many customers need more. If you have zseries & OS/390 V2R10 or z/os, use V6 buffer pools in data spaces, but not otherwise. See Sessions M02, M07 & V7 Performance Topics red book. There will be many more steps as real and virtual memory sizes increase, moving more above the line and above the bar. See the Roadmap, GM , updated June 2002 ibm.com/servers/eserver/zseries/library/ 22

23 DB2 64 bit evolution Degree of relief of 64 bit virtual in V8 will vary Continued virtual storage constraint relief in V9 More areas moved above the 2Gb bar WLM-managed bufferpool sizing 64 bit evolution does not eliminate need to manage virtual storage in DBM1 address space Continue to monitor IFCID 225 data 23 The biggest impact of the zseries architecture on DB2 is the ability to have large real memory support. Prior to the zseries, customers were limited to 2 GB real storage due to the 31-bit addressing of the S/390 architecture. The real storage limit of 2 GB is a leading performance inhibitor for many high end customers. Another leading performance inhibitor is the 2 GB virtual storage limit for the main DB2 (DBM1) address space. Moving virtual pool buffers to hiperpools offers some relief, but many customers need more. If you have zseries & OS/390 V2R10 or z/os, use V6 buffer pools in data spaces, but not otherwise. See Sessions M02, M07 & V7 Performance Topics red book. There will be many more steps as real and virtual memory sizes increase, moving more above the line and above the bar. See the Roadmap, GM , updated June 2002 ibm.com/servers/eserver/zseries/library/ 23

24 Restart processing elapsed time factors Whether group restart is required in datasharing How far back in the DB2 recovery log the last checkpoint was taken The number of log records written from the last checkpoint for outstanding units of recovery (URs) Whether objects are deferred for restart log apply processing Whether postponed abort is used (LBACKOUT) How many datasets need to be opened for restart log apply Whether any indoubt URs exist Log scan time 24 24

25 Best Practices for Restart Checkpoint frequently (2-5 minutes the closer to two minutes, the better) Don t have any long running URs Resolve indoubts as quickly as possible Consider deferred restart for selected objects Limiting backout of long-running URs. Set LBACKOUT to AUTO Reduce the number of datasets open for write access Use dual-logging, put each log/bsds in different ICF catalog and make sure inflight/inabort/indoubt URs are covered by logs on DASD Exploit ARM 25 25

26 Restart availability enhancements V6 Consistent restart LBACKOUT & BACKODUR Fast Log Apply LOGAPSTG V7 -RECOVER POSTPONED CANCEL RESTART(LIGHT) V8 Additional messages indicating logapply progress V9 Simplified & faster restart: Avoid reacquiring some pageset P-locks More robust restart: Avoid some internal inconsistency errors Improve performance by avoiding acquiring some pageset P-locks for GBPdep pagesets and open the pagesets as early in restart as possible Automatic GRECP recovery at end of restart Support table level granularity of retained locks for PA URs 26 26

27 Restart enhancements Maintenance stream PQ55308 Allow restart in MAINT mode if DBD01 inconsistency PQ61328 Avoid MAINT mode during disaster recovery PQ73038 Automatically resynch BSDS timestamp mismatches on restart PK01245 Add progress & diagnostic messages during restart Hang conditions Log read progress PK19417 Toleration of DBET inconsistencies during restart DSNR055I = DSNRTIMR RESTART SUSPENDED SINCE 13:09:26.72 IN DSNTLSUS UQ92436 DSNR056I = DSNRTIMR RESTART SUSPENDED ON IRLM REQUEST. ONE HOLDER OF RESOURCE IS SUBSYSTEM V81B. SERVICE INFO: IRLM FUNC 02, RESOURCE 0C00000D DSNR057I = DSNRTIMR RESOURCE INFORMATION: DBID = 322, OBID = 322, PART =

28 Consistent restart The problem: Long running URs which must be backed out at system restart The solution: Allow some backouts to run AFTER restart is completed Two new install parameters: LIMIT BACKOUT (LBACKOUT) BACKOUT DURATION (BACKODUR) Multiplier for LOGLOAD - max number of records to be read during restart's backward log scan phase Ensures that short URs are backed out at restart Catalog/directory changes always fully backed out URs marked Postponed-Abort, objects marked RESTP or AREST V7: Allow RECOVER POSTPONED CANCEL Note: V8 CHKFREQ default changed to 500,000 from 50,000 Adjust BACKODUR accordingly 28 Restart time for a failed DB2 system is highly variable and depends on the activity that is going on at the time of the failure. Long running jobs that do infrequent commits contribute to lengthy restart times. DB2 cannot resume with new work until all in-flight and in-abort units of recovery are backed out. Backing out a long-running unit of recovery (UR) can be very time-consuming. Performing the backout as part of DB2 restart keeps the DB2 subsystem out of commission until the restart completes or until it is cancelled and a conditional or cold restart is performed in its place. In DB2 V6, some or all backout processing can be postponed until after DB2 restart completes and is ready again to accept new work. This allows a more consistent restart. 28

29 Restart performance IRWW total restart time in seconds Effect of fast log apply on restart performance Effect of data sharing on restart performance V3 V4/V5 V6 V6 & FLA V7 0 Non-datasharing Datasharing 29 29

30 Checkpointing and long running URs To checkpoint based on logrecs or time? Checkpointing based on number of log records written will give most consistent restart times Consider checkpointing based on time interval when you have varying logging rates through time and restart time requirements are flexible Checkpoint every 2-5 minutes is a good general recommendation -SET LOG command can dynamically change checkpoint interval LOGLOAD for # log records CHKTIME for time interval (V7) -DISPLAY LOG shows checkpoint frequency and status Last 100 checkpoints are recorded in the BSDS Use DSNJU004 (Print Log Map) to display 30 DSNJU004 can be executed while DB2 is running Frequent system checkpoints will also improve GBP recovery time (GRECP). This is important for GBPs that aren't duplexed or for DR failover scenarios. DB2 members which do not update frequently will not checkpoint frequently if based on # log records and can thus cause longer GBP recovery times. Checkpointing based on a time interval solves this problem. A good general recommendation is to set up to checkpoint every 2-5 minutes. A value in this range typically balances performance vs. availability tradeoffs. 30

31 Checkpointing and long running URs Identifying Long Running URs Problems caused by long running URs: Long restart times (use of Postponed Abort can mitigate this) Long lock hold time can impact concurrency Reduces effectiveness of lock avoidance checking Prevents online Reorg and other utilities from running Zparms control when DB2 issues long-running UR warnings: UR CHECK FREQ, message DSNR035I (V5) number of checkpoints that a UR has not committed UR LOG WRITE CHECK, message DSNJ031I (V7) number of log records that a UR has not committed More granularity than UR CHECK FREQ IFCID 0313 written, if active, when long-runner detected Use IFCID 0313 to keep a history of problematic URs Use UR CHECK FREQ for most accurate warning of restart impact Use UR LOG WRITE CHECK to accurately identify applications that write a lot of log records DB2 Accounting reports can also help identify these V8: LONG-RUNNING READER THRESHOLD Zparm Write IFCID 0313 when long-running reader detected 31 31

32 Data recovery Recovery is running RECOVER utility to recover one or more objects The restore phase copies the data from the appropriate backup. If there are incremental backups, then they are also processed during this phase. The time for this phase is dependent upon: Size of the objects (if flash copies cannot be used) Media of the backups (tape, slow disk, fast disk, flashed copies) The log apply phase positions the log to the point at which the backup was taken, and using a range index on the log (SYSLGRNX), scans the portions of the log when the objects were open for write access. The time for this phase is dependent upon: The amount of log data that has to be scanned for applicable log records The number of log records that need to be applied Whether archive logs are needed, and whether archive logs reside on disk or tape 32 32

33 Best practices for recovery Reduce COPY cycle time Use SHRLEVEL CHANGE unless consistent copies required Take dual image copies to avoid image copy fallback Consider incremental COPY Perform regular MERGECOPY of incremental copies Consider COPY YES for indexes Use DASD to write image copies and manage by DFSMS Keep at least hours of recovery log on DASD Large, dual active logs Use VSAM striping for active logs Avoid access to archive log datasets Write archive log to DASD and manage by DFSMS Reorganize SYSLGRNX Large BP0 (at least 10,000 buffers) for recovering the cat/dir Use ESA Compression Be careful prior to V8 due to virtual storage considerations 33 33

34 Best practices for recovery Maximize exploitation of Fast Log Apply Set LOGAPSTG to 100 Default is 100 in V8, 0 in V7 Avoid recovering >100 pagesets per RECOVER job Spread recoveries across members of the datasharing group Minimize logapply Consider lowering PCLOSEN and/or PCLOSET thresholds Defaults are 5 & 10 Better SYSLGRNX granularity Prioritise pagesets and split those with like update activity into separate RECOVER jobs May avoid logapply altogether Do not delay critical data availability due to recovery of less critical data 34 34

35 Recovery enhancements by release V6 FLA COPY YES for indexes V7 COPYTOCOPY Allow retry of log read requests V8 Non-disruptive LPL recovery Write claim instead of drain Automatic LPL recovery BACKUP & RESTORE SYSTEM Up to 10,000 archive logs recorded in BSDS per copy Up to 93 active logs per copy V9 Point in time recovery with consistency INDOUBT URs rolled back also Automatic GRECP recovery after restart Convert archive logs from BDAM to BSAM Allow striping/compression 35 35

36 Recovery enhancements maintenance LOGRANGES NO option for RECOVER PQ75398 Avoid need to stop SYSLGRNX when SYSLGRNX information undesirable Don t set RBDP/PSRBDP on index LPL recovery failure PK14962 Avoid need to rebuild index due to temporary error condition 36 36

37 System Level PIT Recovery Easier, more flexible, less disruptive, faster recovery Handle large numbers of table spaces & indexes Two new utilities introduced in V8: BACKUP SYSTEM: Fast volume-level backups DB2 databases and logs Data sharing group scope z/os V1R5, DFSMShsm Fast Replicate, DFSMSdss, & FlashCopy required (FlashCopy Version 2 recommended) RESTORE SYSTEM To an arbitrary point-in-time with consistency Handles creates, drops, LOG NO events 37 37

38 Disaster Recovery Different strategies based on cost limitations & RTO requirements PTAM Tracker Replication Mirroring Long recovery time: Cheaper Significant manual intervention Recoveries required Short recovery time More costly More automated Simple restart GRECP recovery still required Automated in V

39 Disaster Recovery Maintenance stream PQ61328 Avoid unnecessary MAINT mode during disaster recovery PQ Do not fail restart on PIT recovery if prior checkpoint not found on log CRESTART CREATE,ENDRBA= E1000 DSNJ407I DSNRJFCK WARNING - NO VALID CHECKPOINT RBA FOUND. LOG WILL BE SCANNED AT RESTART DSNJ411I DSNRJRCR CRESTART CREATE FOR CRCRID = 0007, DDNAME = SYSUT1 DSNJ407I DSNRJFCK WARNING - NO VALID CHECKPOINT RBA FOUND. LOG WILL BE SCANNED AT RESTART DSNJ411I DSNRJRCR CRESTART CREATE FOR CRCRID = 0007, DDNAME = SYSUT2 DSNJ200I DSNJU003 CHANGE LOG INVENTORY UTILITY PROCESSING COMPLETED SUCESSFULLY 39 39

40 Outage analysis Look beyond defect resolution Provide enhancements to availability & serviceability based on real issues Improve internal testing Enhancements implemented in maintenance stream where benefit outweighs risk 40 40

41 Improved Data Integrity Checking LOBs CHECK DATA to unmark invalid LOBs Improved availability, PQ77366 (V7) LOB space reuse tracking Improved diagnostic logging for data corruption, PQ77368 (V7) COPY CHECKPAGE enhanced for LOBs in PQ74793 DSN1LOGP CHECK(DATA) option Check for regressed data page problems by analyzing the log V8 NFM: enhanced to also handle indexes via CHECK(INDEX ALL) CHECK INDEX option to check integrity of non-leaf pgs (V8) CHECK INDEX SHRLEVEL CHANGE V8 APAR PQ92749 CHECK DATA SHRLEVEL CHANGE V9 CHECK LOB SHRLEVEL CHANGE V

42 DB2 Version 8 Availability Post-GA Utilities performance enhancements PQ Unload Performance PQ RUNSTATS non-padded index performance improvement PQ DB2 Cross Loader performance improvement PQ DB2 UTILITIES Performance Enhancement: UT Serial Lock PQ LOAD PART REPLACE parallelism performance PQ RUNSTATS DSTATS Performance PQ96628: Online REORG claim/drain deadlock avoidance PQ Online CHECK INDEX PQ Crossloader support for larger LOBs Upcoming: LOAD/UNLOAD support for larger LOBs 42 42

43 DB2 Version 8 Availability Post-GA Locking and concurrency PQ Lock Avoidance for Singleton Select with ISO(CS) and CURRENTDATA(YES) PQ INSERT performance enhancement to help avoid need for REORG - not yet delivered Manageability PQ Allow Cancel Rollback after log data set access error PQ DISPLAY ARCHIVE enhancement to show DASD archive log read and also HSM RECALL waits PQ System Point-In-Time or Disaster Recovery - scan log for prior checkpoint when log truncation is prior to last checkpoint in the BSDS queue 43 43

44 DB2 Version 8 Availability Post-GA RAS and monitoring enhancements PQ DISPLAY THREAD SERVICE(WAIT) PK01230 DIS THD SERVICE(WAIT) boost enhancement PQ New EXPLAIN STMTCACHE ALL option, results written to DSN_STATEMENT_CACHE_TABLE PQ Improve statement cache and real storage statistics PQ DDF/RRSAF Accounting Rollup Enhancements PQ Add new criteria for DSNACCOR Stored Procedure to recommend RUNSTATS PQ99524 Prevent DB2 failure when stored procedures are cancelled PQ Compress stack storage when it gets large PQ99159 Prevent DB2 failure on castout errors PK15590 Improved internal tracing during restart 44 44

45 DB2 Version 8 Availability Post-GA RAS contd. PK19972 DSN1COPY CHECK enhancement for LOBs PK22723 DSN1LOGP CHECK 66% performance improvement PK22926 Prevent DB2 failure on index LPL recovery errors PK10307 & PK14694 Quarantine damaged virtual storage PK19417 Toleration of DBET inconsistencies during restart PK19328 Prevent IRLM failure due to bad input PK01245 Add diagnostic messages for restart hang conditions PK01751 Prevent lock escalation by MODIFY utility PK27611 Prevent log RBA rollover 45 45

46 DB2 Future Availability Continued focus on reduction of both planned and unplanned outages Continued Online Schema enhancements Faster, more consistent & robust DB2 restart WLM synergy for system robustness at high utilization Continued VSCR enhancements Utility enhancements E.g. REORG LOB SHRLEVEL(CHANGE) Improved synergy with DFSMS Broken page recovery enhancements Further Outage Analysis items 46 46

47 Availability Summary Substantial improvements in new DB2 versions Understand and exploit capabilities Service Level Agreements differ substantially Availability is dependent upon your database, application & subsystem design & practices Understand and avoid capacity issues Much more information available SG DB2 for OS/390 and Continuous Availability SG DB2 V8 Performance Topics SG DB2 for z/os Design Guidelines for High Performance and Availability DB2 for z/os & OS/390 Web: Access or Download PDF files ibm.com/software/db2zos then click Library 47 DB2 for your e-business reliable, scalable, and available Many businesses already use DB2 for their e-business. They depend on the reliability, scalability, and availability of DB2 to serve their worldwide customers around the clock, seven days a week. Version 7 offers many improvements for electronic commerce. If you have not yet deployed your business on the Web, now is the best time to start. A number of enhancements in Version 7 of DB2 for z/os & OS/390 help you improve availability and make the process simpler. Some parts of this presentation are more like looking into a crystal ball than at measurements. This crystal ball is cloudy, and gets fuzzier the farther we look into the future. Our plans include much more change and much more risk than ever before. The only near certainty is that there will be changes. Our best guess is that fewer than 10% of the items will change their delivery time. I would expect some new items to come in, some to come early, and others to deliver in stages. More will have major changes in their design. 47

48 Session A09 DB2 for z/os Design for High Availability John J. Campbell DB2 for z/os Development 48 48