Patches Concept

Patches Concept

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 12.1.0.2 might then be backported on top of 11.2.0.4 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 12.1.0.2 results in the version becoming 12.1.0.2.6. 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 12.1.0.1 , 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 10.2.0.4.4 which is the last base PSU for the 10.2.0.4 patchset. From 10.2.0.4.5 all PSUs are overlay PSUs, which means that in order to install, for example, 10.2.0.4.10, the user must first install 10.2.0.4.4 and then install 10.2.0.4.10 on top. The overlay PSU is cumulative down to the base PSU, which means that by installing 10.2.0.4.4 the user automatically gets all of the fixes in 10.2.0.4.3 and below, then by installing 10.2.0.4.10 all of the fixes in 10.2.0.4.9 down to 10.2.0.4.5 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 10.2.0.4.10 then the user would install 10.2.0.4.4 as usual and then require a merge overlay patch of 10.2.0.4.10 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 12.1.0.2.161018 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