<Insert Picture Here>

Oracle Patching and MaintenanceA practical guide for System Administrators

October 2009

Introduction

• Eleanor Meritt Sustaining Engineering

• Balaji Bashyam Customer Support

• Richard Miller EM Development

• Russell Green Development Infrastructure

THE FOLLOWING IS INTENDED TO OUTLINE OUR GENERAL PRODUCT DIRECTION. IT IS INTENDED FOR INFORMATION PURPOSES ONLY, AND MAY NOT BE INCORPORATED INTO ANY CONTRACT. IT IS NOT A COMMITMENT TO DELIVER ANY MATERIAL, CODE, OR FUNCTIONALITY, AND SHOULD NOT BE RELIED UPON IN MAKING PURCHASING DECISION. THE DEVELOPMENT, RELEASE, AND TIMING OF ANY FEATURES OR FUNCTIONALITY DESCRIBED FOR ORACLE'S PRODUCTS REMAINS AT THE SOLE DISCRETION OF ORACLE.

Patching: Be Proactive

• Preventative maintenance is key to a successful system• Our most successful customers take a proactive approach to

patching

• By being proactive you can• Avoid production issues

• Reduce support costs

• Get new fixes quickly

• Make proactive patching the cornerstone of your maintenance strategy

Objectives of this presentation

• Give you a clear understanding of Oracle’s patching terminology

• Help you develop a proactive patching and maintenance strategy

• Describe tools to help simplify the entire process

Oracle Support Basics

• Understanding Oracle’s Life Cycle Support Policy is a requirement for devising a good maintenance strategy

• It allows you to plan your upgrades

• It ensures you to stay on supported releases

• Oracle may not provide fixes for all releases

• You can have the best patching strategy in the world, but it won’t matter if Oracle is unable to provide you with patches

What version of the database should I choose?

• Which release has the longest life?

• Which releases do you understand the best?

• Which are the most stable in your environment?

• Which are certified with your 3rd party vendors?

• One size does not have to fit all – categorize your systems and decide which releases to use for each:

– Early adopters or non-critical systems can be used to gain experience for the enterprise with a recent release (eg.11.2)

– Where you want most of your systems where you want system having the best balance between release life, stability, and organizational experience, adopt a more mature release (eg. 10.2)

– Only consider staying on a legacy release for systems that are “bedded down” and not changing, and are likely to be retired – ie not worth the investment in upgrading

Error Correction policy

• Throughout the Premier Support period, patch sets are produced to fix known bugs that are discovered after GA.

• Successive patch sets are cumulative and improve quality over the lifetime of the release. For a given release, the most recent Patch Set is always the least risk option.

• We stop patching older patch sets once the new one is out for a year – it is important to be deployed on a currently supported Patch Set.

• Once a release goes into Extended Support• We will only patch the LAST patch set for the release• Extended Support is optional – but without it, no patches!

PremierPremier11.2.0.2 ExtendedExtendedGrace Period 1 year

PremierPremier11.2.0.4

PremierPremier11.2.0.3 ExtendedExtendedGrace Period 1 year

Patching Terminology

• There are several methods that may be employed to deliver fixes to a customer. The differences between these methods are often a source of confusion.

• Interim Patch• a single standalone patch also called a “one-off” or PSE

• Component or Configuration Bundle• a set of patches issued between patch sets

• target a specific product, component or Configuration

• e.g. RAC, Dataguard or Ebusiness Suite database release certification bundles

• Critical Patch Update (CPU)• a bundle of patches released quarterly, to fix security bugs

• Patch Set Update (PSU)• a bundle patches for high impact bugs encountered in the field

• includes the CPU and component / configuration bundle content

• guaranteed not to contain any changes to the optimizer or fixes which change application behaviour.

What level of confidence can I have?

• One-off patches• Basic Functional Testing• Install Testing• Reactive Only

• Patch Bundles (CPU, PSU, Component Bundles etc)• Complete Functional Testing• System Testing (intermediate)• Install Testing• Recommended for Proactive Patching

• Patch Sets• Complete Functional Testing• System Testing (comprehensive)• Upgrade Testing• Proactive Maintenance Vehicle

Proactive Patching Strategy

• So how do I know what to apply?

What should be my Patching Strategy• Proactive vs Reactive

• Reactive isn’t really a strategy• Hit a bug – apply a patch

• Don’t try the ‘Dim Sum’ patching methodology• It increases the possibility of patch conflicts• It increases risk due to untested patch combinations• It increases production time if new patches are needed

• Oracle recommends a Proactive patching strategy• Stay with supported patch sets

• Preferably be on the latest• Follow the Oracle patch recommendations• For simplest deployment – use PSU’s

• RAC rolling installable

• Only apply one-off patches when• You know that you are impacted by a bug

Help me to be proactive

• My Oracle Support (MOS)• Report on recommendations• Develop patching plans• Check for conflicts• Share experiences

• Downloads• Problems

Demo

My Oracle Support

Performance Management

Enterprise Manager

Provisioning & Patching

Problem Diagnosis

Unified View, Integrated InformationBetween My Oracle Support and Enterprise Manager

Oracle

Customer

DatabasesOperating Systems Middleware Applications

Problem/SRManagement

ConfigurationManagement

KnowledgeManagement

Problem/SRManagement

ConfigurationManagement

KnowledgeManagement

What other tools do you have?

• Database Replay• Real Application Testing

• Capture and replay known workloads

• SQL Performance Analyzer• Assess statement performance impact

• what statements improved or regressed

• Provide tuning recommendations for statements whose plans regressed

• SQL Plan Management• Records and evaluations SQL plans over time

• Create a baseline of accepted plans for a SQL statement

• Controlled Plan Evolution

Other Recommendations

• Before performing upgrades, always refer to the 10g and 11g Upgrade Companion documents. • My Oracle Support Notes 466181.1 and 601807.1• These documents include invaluable advice on best practices

for pre- and post-upgrade activities

Summary

• Make sure you understand the Life Cycle and Error correction policies

• Stay on currently supported releases• Upload your system configuration• Deploy Oracle recommended patches• Stay ahead of the curve – be proactive

Thank-you!

Any Questions?