Understanding the Patching Process

The Insider’s Guide to
Patching at Oracle
Thomas Kyte
http://asktom.oracle.com/

Program Agenda
 What happens at Oracle before you get your patch?
 How should you test a patch?
 How do you minimize downtimes?
 What’s new in the patching realm?
 Q&A

Level Set
 Patch Set
– a maintenance release containing all bugs fixed for a given production
version during a time period. May contain limited new functionality
 Interim Patch
– a single standalone patch also called a “one-off” or PSE
 Security Patch Update
– a collection of patches released quarterly, to fix security bugs. Also known
as a CPU (Critical Patch Update)
Patch Types

Level Set
 Patch Set Update (PSU)
– A quarterly collection of patches for high impact bugs encountered in the
field
– includes the SPU content
– guaranteed not to contain any changes to the optimizer or fixes which
change application behaviour.
– May span multiple stack components, for example: Grid Infrastructure and
Database
Patch Types

Level Set
 Bundle Patch (BP)
– A collection of fixes to address bugs in a given feature, product, or
configuration. For example: Windows BP, Exadata BP
– BP’s are super sets of PSU’s. They may contain as yet unproven in the
field content
– May span multiple stack components. For example: Exadata Quarterly Full
Stack Download patches.
Patch Types

Product Maintenance
Process Overview

What Happens at Oracle before I get my patch?
Maintenance Cycle Overview
 Fix Coded against customer
reported release (tested)
 Patch generated against
customer reported release
Bug FixedBug Reported Patch Created
 Fix Coded against current
development release
 Peer Code reviewed
 Tests Run
 Fix Merged in current
development release (tested)
 Fix merged to open Patch
Set releases (tested)
 Bug Report Opened
 Problem Diagnosed

Oracle Testing Overview

 These tests are grouped together based on functional areas to
regression test all database features. For example: Optimizer.
 The number of functional tests is constantly increasing. For example:
11gR2 has 80% more tests than 10gR2, 10gR2 has 40% more tests
than 10gR1.
 New version of latest development release created daily and full set of
functional regression tests run against it.
 All new code changes must pass functional regression tests before
merging to development releases.
Functional Testing

 Push the Database and Exadata to their limits for scalability, high
availability, reliability and performance
- Number of concurrent users, parallel degree, cursors, partitions, disks,
standby systems, redo apply rate, complex topology, etc.
 Also pushing the machine limit
- Memory, CPU, I/O, network
 High concurrency Oracle proprietary workloads stressing many
components together
 Many real world customer workloads for real world testing
 Heavy destructive testing under high load: software and hardware
System Testing

 Performance Atomics regression testing
– Test performance of simple SQL statements with instruction tracing and
memory allocation of every structure
 Feature performance testing
 Product Stack performance testing ensures upper layer Oracle product
stacks don’t regress in performance with every database release
– Fusion Middleware, Ebusiness Suite, Siebel, Peoplesoft, Fusion
Applications
 Workload based performance regression testing
Performance Testing

 Customer Beta Testing
 Certification Testing
 Installation, Upgrade & Downgrade Testing
 Internal Deployments
Other Testing

Testing Summary by Patch Type
Interim Patch PSU, SPU, Bundle Patch Set
Functional
• Area regression tests
• Bug fix verification
 Complete set of functional
regression tests
• Complete set of functional
regression tests
Stress • None
 Subset of stress tests
targeted based on content
• Full stress testing
Performance  None
 Workload based
performance regression
testing
• Full set of performance tests
Other
 Install testing in
unpatched environment
 Installation using EM
CC Patching
 Install testing in clean
environment
 “Upgrading” from previous
PSU, SPU, Bundles
 Installation using EM CC
Patching
 Install & Upgrade testing –
many scenarios
 Internal Deployments
 Certification testing

Our Maintenance Strategy
Recommendations for
Customers

Establish a Maintenance Strategy
 Being proactive is the best strategy.
 But you also need to figure out what aspects of your database system
are the most important for you.
 Grade each of these according to importance:
– New Features
– Certifications
– Stability
– Supportability
Be Proactive

 10.2.0.5 –stable release, but it’s in Extended Support. Supportability
will soon be an issue. Lack of new certifications, no new features.
 11.2.0.4 – Best bet if you want access to latest production features,
PSU’s, SPU’s, BP’s. 11.2.0.3 is currently most active release in the
field today since 11.2.0.4 was release just this week.
 Prior 11g releases – 11.1.0.7, 11.2.0.1, 11.2.0.2 and now 11.2.0.3 are of
lower quality than 11.2.0.4. Production of PSU’s, SPU’s and BP’s on
11.2.0.1 and 11.2.0.2 has stopped.
Decide on a Database Release

 Older releases
– Lack of access to current interim patches, PSU’s, SPU’s ,etc.
 Custom combinations
– Avoid proliferation of interim patches. These create unique environments
and make problem diagnosis more difficult. Can also lead to the need for
yet more unique patch merges.
What to Avoid

Testing Recommendations by Patch Type
Interim Patch PSU, SPU Bundle Patch Patch Set
Install • Yes  Yes  Yes • Yes
Bug Verification • Where possible
 Where possible and
relevant
 Where possible and
relevant
• Where possible and
relevant
Basic admin
activities, basic
application flows
and basic load
tests
 Not required  Optional  Desired • Yes
Full Application
functional flows,
full performance
tests, heavy load
tests
 Not required  Not required  Not required  Required

Patching for High
Availability

Patch the Standby ‘First’
 Patch the Standby
 Test Changes!!!!
 Switchover
Application Tier
Data Guard
• Production up after Switchover
• Run any patch SQL
• Patch original Primary home
Post Switchover

Out-of-Place Patching
DB
Instance
Apply Patches
Patches
Applied
Minimal Downtime
Database
Home
Clone Home
Cloned
Database
Home

Rolling Real Application Zero Downtime
 Zero Downtime Rolling Patch
Orchestration across RACs
 Patch support for GI (or Clusterware)
to both GI and RAC OH in a Node in
a rolling fashion

Online Patching aka Hot Patching
Patched
Shared
Library
 Apply Shared Library
 Map into text Area
 Use new patched functions
Increases memory footprint
Patch offline on next downtime
P1 or diagnostic patches

Patching Notes…

References
 RDBMS Online Patching Aka Hot Patching [ID 761111.1]
 Composite Patches for Oracle Products [Video] [ID 1376691.1]
 Oracle Patch Assurance - Data Guard Standby-First Patch Apply [ID
1265700.1]
 Minimal downtime patching via cloning 11gR2 ORACLE_HOME
directories [ID 1136544.1]
 Rolling Patch - OPatch Support for RAC [ID 244241.1]
https://support.oracle.com

Graphic Section Divider

Understanding the Patching Process

More Related Content

What's hot

Similar to Understanding the Patching Process

More from Connor McDonald

Recently uploaded

In this document

Understanding the Patching Process