Best Practices for DB2 Software Maintenance John J. Campbell DB2 for z/OS Development [email protected] Michael Dewert DB2 for z/OS Development [email protected]

© 2010 IBM Corporation

Disclaimer/Trademarks 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, and ibm.com are trademarks or registered trademarks of International Business Machines Corp., registered in many jurisdictions worldwide. Other product and service names might be trademarks of IBM or other companies. A current list of IBM trademarks is available on the Web at “Copyright and trademark information” at www.ibm.com/legal/copytrade.shtml.

© 2010 IBM Corporation

2

Common Problem Areas


No HIPERs or PE fixes applied since the last preventative service drop




Greater risk of outage caused by missing HIPER or PE fix




Incidents occur where HIPER available and not applied for many months




Possibility of long prerequisite chain when having to apply emergency corrective service




Delay in exploiting new availability functions




Delay in applying DB2 serviceability enhancements to prevent outages




Long time to roll out a new DB2 code level across production




Long time to roll out of a new DB2 code level




Not able to 'roll out' all residual HIPERs on a monthly basis




No safety net to catch user error in not spotting critical HIPERs

© 2010 IBM Corporation

3

Maintenance Trade-Off





Must balance for severity vs. risk –

Problems encountered vs. problems avoided

–

Potential for PTF in Error (PE)

–

Application work load type

–

Windows available for installing service

Need adaptive service strategy that is adjusted based on –

Experience over previous 12-18 months

–

Attitude to risk in changing environment and exploiting new function

–

DB2 product and service plans

© 2010 IBM Corporation

4

Recommendations


Change Management process should balance the risk of making “no change” vs. making “a change”




Develop processes/procedures and technical changes to implement ‘rolling’ maintenance outside of heavily constrained change windows




–

Separate SDSNLOAD per DB2 member

–

Separate ICF User Catalog Alias per DB2 member

Apply preventative maintenance every 3 months – one example –

Two “major” and two “minor” releases

–

Refresh of the base every 6 months (“major”)

–

Each base should be based on latest quarterly RSU

–

In addition, two mini packages covering HIPERs and PEs in between (“minor”)

–

Exploit Enhanced HOLDDATA to identify and pull all HIPERs and PE fixes

© 2010 IBM Corporation

5

Recommendations


Aim for company wide certification of new release/maintenance – Shared test environment with collaborative use by systems programmer, DBA, and all the application teams – Additional ‘insurance policy’ before starting to roll out new DB2 maintenance package




Have single “master’” SMP/E environment as base




Have one additional SMP/E environment to match each DB2 application environment




Certification testing based on “master” before starting to promote new maintenance to Test and Production environments




Assign additional manpower to perform the tasks

© 2010 IBM Corporation

6

Benefits of separated DB2 maintenance environments


No ‘one size fits all’




Can be more aggressive on applying maintenance to specific DB2 environment(s)




Whilst protecting the stability of other DB2 application environments




Very flexible proven approach that meets application development requirements to use new functions




Supports the migration of new DB2 releases perfectly as DB2 application environments can be treated independently

© 2010 IBM Corporation

7

Replicate application workloads Replicating application workloads is key to achieving high availability using the foundation of z/OS Parallel Sysplex and active-active DB2 Data Sharing.


Make sure all application workloads are replicated




Need multiple instances of same application across multiple systems




Remove system/transaction affinities from rogue applications




Avoid single system point of failures (e.g., single CICS region)




Provides fault tolerant application processing




Reduces need for planned outages to roll in service




Should also improve application throughput and scalability

© 2010 IBM Corporation

8