Confusion about Oracle Patches?

Whenever a bug is being detected and confirmed for fix, Oracle engineers raise a request for bug engineers / development to provide a patch for customer. There are different types of patch requests in order to fix the issue while making sure not to disturb already existing patch in the target environment. Few patches/patchsets are proactively recommended for security, stability, performance and environmental changes (i.e. DST) perspective.

Whenever someone asks me regarding patching I used to confuse a lot and read oracle documentation every time. When the question came again the same level of confusion appear pushing me into loop of reading and forgetting the concepts of patch terminologies. So this time I have decided to share my understanding so it would be easy to recall and enhance based on feedbacks and queries.

When a bug is detected in UNIX, the patch fix for this bug is given via object files. These object files have an extension of “.o” . These “.o” files are stored in an “archive library”. The patch contains Static Libraries and Shared Libraries. The Executables are generated using static libraries and linked using shared libraries. These Executables are generated on the fly in oracle binary, where the patch is being applied.

Whereas, in Windows there is no concept of “.o” files at all. There are only DLL’s (Dynamic Linked Libraries) and Executables in the library. The difference is that these Executables are generated at the patch shipment site, and not in the machine where patching to be done. So when customer applies a patch fix, the Oracle Executables those already exist in the target Oracle Home will be replaced with Oracle Executables from the patch. This action results in the older patch fix to be lost. This nature of patch applying in Windows makes it impossible to create individual patches for bug fixes. Instead, many patches are clubbed together and a “bundle patch” is released. All the Bundle patches in Windows are cumulative in a particular release. It means that fixes from previous Oracle security alerts and bundle patches are included.

Before jumping to types of patches/patchsets, let’s understand few terminologies related to patch.

Label – For internal references Oracle developers use a name or identifier for a set of changes (e.g. the fixing of a bug) in the source code; the output of a label is a set of C files (*.c, *.h etc)

PSE (Patch Set Exception) – PSE is created when Oracle ports a label to a specific platform, e.g. Linux x86_64, HPUX-IA etc; the output of a PSE is compiled C files (such as *.o files, or *.exe on Windows)

Interim Patch – Interim patches (official name for a one-off patch) are bug fixes that are made available to customers in response to specific bugs; to create an interim patch a label and a PSE is required, i.e. a fix or fixes in the source code and then the output of this when it is compiled. It requires a particular base release or patchset to be installed before it can be applied. These patches are not versioned and are generally made available in a future patchset as well as the next product release.

Conflict – When two or more bugfixes which modify the same source code files then only one can be applied, otherwise the code for the fixes will need to be “merged” to produce a new label.

Merge – A combination of labels prepared for two or more conflicting code fixes.

MLR (Merge Label Request) – A merge of two or more fixes requires two steps: a label for the new set of merged code (an MLR) followed by a PSE (for the platform it is required on)

Backport – Also known as an OOB or One-Off Backport, this is a change or fix in a later piece of code which is then retrospectively applied as a patch to an earlier level of the code e.g. a fix in might then be backported on top of and made available as an interim patch

BLR (Backport Label Request) – As with merges, a backport requires two phases: a new label (created by the BLR) and then a PSE

CPU (Critical Patch Update) – Also known as SPU (Security Patch Update); CPU is a bundle which is released quarterly and only includes security-related fixes. CPUs are usually cumulative, so a later CPU will contain all of the fixes from an earlier CPU for the same patchset. CPUs are “molecular” which means groups of related fixes (“molecules”) can be excluded if they conflict with existing patches.

Patch Set Update (PSU) – PSU contains critical bug fixes for its intended patchset. Initially they are cumulative, so they contain all fixes from previous PSUs for the same patchset – they also include the CPU released on the same date. So for example PSUJan2016 includes CPUJan2016. There are very specific rules about which fixes can be included in a PSU; nothing that affects optimizer query plans can be included, nor anything that requires a configuration change. Port-specific bugs also cannot be included. Application of a PSU will increment the last digit of the release number, e.g. PSUJan2016 for results in the version becoming A PSU can be applied on the SPU released at the same time or on any earlier SPU for the base release version as well as any earlier PSU or the base release version. SPUs are only created on the base release version. Once a PSU has been installed, the recommended way to get future security content is to apply subsequent PSUs. Reverting from PSU back to SPU, while possible, would require significant effort, and so is not advised.

Note: Starting with Oracle Database version , Oracle will only provide Patch Set Update (PSU) patches to meet the Critical Patch Update (CPU) program requirements for security patching. SPU (Security Patch Update) patches will no longer be available. Oracle has moved to this simplified model due to the popularity of the PSU patches.

Overlay Patch –When a one-off patch conflicts with the PSU, patch conflict resolution is achieved by providing a one-off patch of that fix or set of fixes that coexists with the PSU patch. This is accomplished with a prerequisite/overlay patch. The new one-off patch requires that the PSU be present in the Oracle Home. It cannot be applied if the PSU is not first applied. That is, the PSU is a prerequisite of the one-off patch. At apply time, instead of rolling back the conflicting PSU patch, OPatch installs the one-off patch’s files. That is, the one-off patch overlays the PSU. Prerequisite/overlay patches have the same 5-number version as the PSU.

Overlay PSU – During the lifecycle of a patchset, PSUs will normally be released every quarter. As the patchset reaches maturity it would be expected that there are less critical bugs which can be considered as candidates for inclusion in PSUs. At some point the number of bug fixes included in each PSU will reach a low enough number that it is no longer considered worthwhile to make the PSU cumulative. At this point the previous PSU becomes a baseline and all future PSUs are released as “overlay PSUs”. An example of this is which is the last base PSU for the patchset. From all PSUs are overlay PSUs, which means that in order to install, for example,, the user must first install and then install on top. The overlay PSU is cumulative down to the base PSU, which means that by installing the user automatically gets all of the fixes in and below, then by installing all of the fixes in down to are also included. If a conflict were to occur between an interim patch and the overlay PSU then a merge of the overlay PSU would be required. For example, if patch 999999 conflicted with then the user would install as usual and then require a merge overlay patch of merged with 999999. 

BP (Bundle Patch) – A set of patches which are released in what is effectively one large merge. Whereas merges are often created for a particular customer’s set of circumstances, a bundle patch is normally created by Development and Support to include a set of critical or recommended fixes. Bundles are much more thoroughly tested than merges and interim patches. They are also much more likely to cause conflicts because of their size. BPs are also iterative, cumulative and rolling in nature; These usually include only fixes, though some may include minor enhancements as well. Bundle patches includes all fixes available in PSUs plus additional fixes approved to include in that BP. Initially the concept for BP was to set a separate way of patching for exadata environments which is no longer valid and customers are free to choose PSU or BP on top of base release. Oracle recommends using either PSU or BP to avoid complexity and reduce conflicts. BPs used to be released more frequently than PSUs till Oct 2015 and both PSU and BPs used to have a two digit number to identify. From Jan 2016 PSUs and BPs almost release at same interval.  As of Dec 2016 while updating this blog BP release was while PSU release was also same for 12c. Here 161018 represents (18 Oct 2016) date of release i.e. 161018 stands for 18 Oct 2016 release date for this BP.

Note: Important point wrt PSU & BP is that BP cannot be applied on top of a previous quarter’s PSU and vice versa. If you want to switch techniques and for example start applying DBBPs instead of PSUs you’ll need to un-install the old conflicting PSU patches first.

DST Patch– These types of patches are periodically released by Oracle when there are changes in the Daylight Saving Time. Oracle recommends to use the latest (version-4) Oracle time zone files. These patches usually available as a one-off patch or as part of patch bundles.

Diagnostic Patch – Also known as test Patch, Fix Verification Binary (FVB), e-fix; an interim patch created specifically to diagnose a problem and not to fix a bug.

RAC Rolling Patch -With this patching method, there is no downtime. Each node would be patched and brought up while all the other nodes are up and running, resulting in no disruption of the system. See MOS Doc: 244241.1 for more information

Disclaimer: Whatever we discussed in this blog is of generic oracle technological overview based on our experiences in day to day operational work as well as reading from oracle online documentations. Our aim is to explore alternative ways to achieve the high availability and to share knowledge with everyone who is looking for it.


One Response to Confusion about Oracle Patches?

  1. Added additional points with respect to recent changes in Oracle Patch naming conventions.

Share Your Comment

Please log in using one of these methods to post your comment: Logo

You are commenting using your account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Pierre blog

Pierre Forstmann Oracle Database blog


Oracle databases, storage and the high-performance world of flash memory

Future Veterans

Ramblings about Oracle

Ranjeet Srivastava

Smile! You’re at the best blog ever

Kevin Closson's Blog: Platforms, Databases and Storage

Platform, Database and Storage Topics

Real Life Database / SQL Experiences : An Oracle Blog from Vivek Sharma

Being an Oracle Professional, I like to share all my Real Life Performance Tuning Challenges and Experiences. The Content and Views on this site are my own and not necessarily those of Oracle. While, I write on my real life experiences, the resolutions mentioned are solely mine. Comments / Criticisms are always a welcome.

Frits Hoogland Weblog

IT Technology; Oracle, linux, TCP/IP and other stuff I find interesting


Dominic Brooks on Oracle Performance, Tuning, Data Quality & Sensible Design ... (Now with added Sets Appeal)

ASM Support Guy

Just Another Crazy Oracle DBA

Exadata Certification

Just Another Crazy Oracle DBA

Carlos Sierra's Tools and Tips

Tools and Tips for Oracle Performance and SQL Tuning

Sangram keshari's Oracle Blog

The Fusion Middleware Administration & Database Administration Blog

Amit Saraswat

Just Another Crazy Oracle DBA

Oracle Scratchpad

Just another Oracle weblog

The Tom Kyte Blog

Just Another Crazy Oracle DBA

Hemant's Oracle DBA Blog

Just Another Crazy Oracle DBA

Uwe Hesse

about Database Technology

Richard Foote's Oracle Blog

Focusing Specifically On Oracle Indexes, Database Administration and Some Great Music

%d bloggers like this: