E-Business Suite patching is very broad topic. I’m going to cover just a fraction of this vast theme, one that I believe is often overlooked. I decided to split it into two logical parts.
Part 1) Oracle E-Business Suite patch terminology
- patch type hierarchy
- patch naming convention
- naming differences between 11i and R12
Part 2) Querying patches, patchsets, family packs
- how to check if a patch was applied
- what patchset am I on?
- what family pack am I on?
- is there a newer patchset/family pack?
This blog could also be called “Oracle EBS patch evolution theory.” Like any other theory, it can be challenged and proven wrong. I tried to make it unbiased based purely on my experience and to present it in the way that makes sense in context of general patching activities.
Patch hierarchy in 11i
EBS patch taxonomy consists of a number of species. Here is a list of those which I recognize to be valid in the long-term. The exact naming may vary over the years, but the names used here are as they are commonly understood by Apps DBAs.
- One-off PatchesThe One-off patch category was common in the older versions R11 (11.0.x) and early releases of 11i. Typically, they fix single or isolated set of bugs. They are less and less common these days. Unless they fix a very critical and isolated bug, Oracle won’t release patches as standalone, but will consolidate them into larger bundles.
- Product Patchsets (formerly known as Minipacks)Standalone patchsets were common in early releases of 11i. They can enhance functionality and typically fix a large number of bugs for a single product. Once a patchset is applied, it increments the patchset level of a product (the product is sometimes also referred to as module). There are around 200 products integrated in EBS, and each product has specific patchset level. For most products, patchsets are no longer distributed as standalone (which means you won’t be able to download them from metalink), but are grouped into Family Packs.
- Rollup PatchesRoll-up patches are a special kind that started to become more common as 11i matured. They are collection of bugfixes for a specific product and relate to specific patchset level. They are released outside of a patchset release cycle. If a particular patchset turns out to be buggy it can have several roll-up patches, which are usually cumulative. These patches are sometimes referred to as a number after a patchset letter, as in case of 11i.AD.I.4. (I will elaborate on the naming in next section.)
- Family PacksAs the complexity and dependencies between individual products increased, it became more and more difficult to release isolated patchsets for each product. Oracle grouped all interrelated products into families fulfilling a specific functional purpose. Family packs are seta of product patchsets for a particular family (such as Financials, Project Suite, Applications Technology, and so on). The family pack’s advantage is that the patchset levels were tested together, and should therefore be more stable and require fewer pre-requisites. Despite that fact, applying a family pack is a major change to the system, and should be rolled out carefully.
- Consolidated UpdatesAs the EBS product matured in version 11i, Oracle started to release consolidated updates. These are huge updates similar to maintenance packs. They introduce change the fourth version number. You can think of it as a set of compatible family packs. The best-known consolidated update is CU2 which upgrades your system to version 220.127.116.11.
- Maintenance Packs (in R12 Release Update Packs)Maintenance packs deliver a new version of a product. Unlike major release upgrades, maintenance packs change the release number, which is the third number in a version name (for 11i). They are still considered patches, but the changes they introduce are system-wide. Often they also bring in brand new products.
Patch naming conventions
Every patch, irrespective of kind, has an identifier in form of a seven-digit number, that particular identifier corresponds with a bug number. The bug can be just a placeholder for the consolidation of other patches that are eventually merged into a bigger patchset, family pack etc.
For one-off patches, the 7-digit number is their only identifier.
There are around 200 products in E-Business Suite, and each product has a specific product name and product abbreviation. The Patchset level naming convention has an alternative to the patch number for easier identification. It consists of version number, product abbreviation, and a letter.
For example: 11i.FND.H refers to patchset H for product FND for version 11i and it can be found under patch number 3262159.
Family packs add an additional component to the short name which is “_PF” after the product name abbreviation.
For example: the Application Technology family pack is referred to as 11i.ATG_PF.H (which corresponds with patch number 3438354), and the Financial suite family pack is referred to as 11.FIN_PF.G etc.
Consolidated updates were introduced after release 11.5.10. They append another number after the version number. So consolidated update 2 is referred to as 18.104.22.168 or simply CU2 (or as patch number 3480000).
Maintenance packs are the last piece in the puzzle. Their alternative names are same as the version number, so it’s 11.5.9, 11.5.10 etc.
Changes with R12 and new facts in the patch naming conventions
R12 introduces some new terms—codeline and codelevel—and changes the meaning of several established terms.
- codelineThis refers to a point release. Every codeline delivers a unique set of features. So release 12.0 is a understood as codeline A; release 12.1 is understood as codeline B; release 12.2 will be understood as codeline C, and so on.
- codelevelCodelevel can resemble patchset level from 11i. For each codeline, there can be a set of updates, which deliver mostly bugfixes and reflects the particular product codelevel after the codeline letter.For example: R12.AP.A.4 means Account Payables product on codeline A (Release 12.0) on codelevel 4 (Part of release 12.0.4).
The important thing to understand is that if you install a specific R12 release such as 12.0.4, all products will not only be on the same codeline (A), but also on the same codelevel (4). Further updates for a specific codelevel are delivered in form of delta updates. So instead of going from 12.AD.A.4 to 12.AD.A.5 as you’d expect from 11i, you’d go from 12.AD.A.4 to 12.AD.A.4.delta1, 12.AD.A.4.delta2, and so on. The codelevel is incremented via Release Update Packs.
- Release Update PacksWhat was formerly known as a maintenance pack is now called a Release Update Pack with short name of RUP. This could be confused with another RUP (Roll-Up) as it was used in context of 11i. RUPs actually upgrade all products to higher codelevel. These point release upgrades can introduce substantial changes to the system, therefore need to be carefully planned.For example: RUP2 is equivalent to R12.0.2, RUP6 is equivalent to R12.0.6 etc.
The final note for R12 is that patch numbers no longer have to be unique: the same patch can be released in multiple shapes for different codelevels.
As you can see, the terminology that Oracle uses to refer to EBS patches can be quite dynamic. There may even be some deviations and anomalies to the above described terminology, but they are usually short lived. If you gain a good understanding of these terms, you will better understand patch READMEs and be able to complete pre-patch analysis reliably. Depending on your version, be flexible and always think about patches in the context of your particular release and of the date when that particular patch README was written.
I haven’t mentioned special kinds of patches such as Critical Patch Updates, pre-upgrade patches, legislative patches, and documentation patches. These are are part of special purpose patches category, and they stand outside of the above outlined classification.
In the next part, I’ll show you how to check if a specific patch was applied, and how to find out patchset levels and family pack patch levels.
Share this article
2 Responses to “Oracle E-Business Suite Patch Taxonomy, Part 1”
Leave a Reply