Apps Patches

---

There are several kinds of patches that you may end up having to apply to a part of your Oracle E-Business Suite installation. There are database patches that will take you to the next bug fix release (changing the last number in the number string), there are Apache and Forms and Reports patches that upgrade your services to a new release level or in some way enhance performance of the services, and there are Apps patches. Apps patches are usually product family specific, and are usually applied by means of ADPATCH, and are driver driven and therefore each applied like the other.

There are, of course, other patches that will impact your life. OS patches on any or all of your servers, OS patches that get applied to the client that may affect the way that JInitiator performs, and browser patches that may affect the way that the browser interprets the information being sent to it by the application.

Application patches come in many sizes, each with its own name and purpose. These are outlined first, before we discuss how to handle them.

One-Off Patches

One-off or stand-alone individual patches are created to fix a particular bug. You often have to have an active iTAR to get a one-off patch (at least until the bug becomes widely recognized). Even then the easiest way to find the patch is to have Oracle Support point you to the bug number or the patch number (usually the same number in the case of a one-off patch). These patches are usually not very big.

Minipack

A minipack patch (referred to as a patch set in Release 10.7) is a larger cumulative patch. These patches are released for a particular product family and consolidate most, if not all, of the bug fixes (one-off patches) accumulated within the family up to a certain point. These patches are created periodically (depending on the product family), are named using a letter suffixed to the product family name (this is what Oracle Support is referencing when they ask if you are on FND.E or AP.F), and are cumulative in nature (AP.F would include all fixes from AP.A, AP.B, AP.C, AP.D, AP.E, and any fixes released between the release of AP.E and the starting of building the minipack AP.F). A minipack usually means that you only have to apply one patch instead of dozens. However, you may have to apply the patch on every node of a multi-node installation. The patch may have to be downloaded and applied on different OS platforms. If you have multiple language sets enabled, you may have to apply different versions of the same patch with different language bases to bring your entire product family to the correct point with each language.

A minipack usually provides additional functionality; it does more than just fix bugs.

Previous releases often required a client side patch and a server side patch when installing a patch set or minipack. Oracle 11i allows you to install a single patch that will provide all changes to all portions of the application. One caveat to that is that if you have different nodes in a multi-node installation, you will need to apply the patch to each node. If these nodes are on different OSs, you will need to download the appropriate version of each patch for each of the OSs in your configurations, unless the patch is generic.

Family Pack

A family pack is a group of minipacks for related products, bundled together for simplicity and logical installation plus the possible addition of one-off fixes that may have been released between the release of the previous minipack and the bundling of the family pack. Family packs follow the same ideas as minipacks (e.g., cumulative, named with a letter, released periodically), however the naming convention varies somewhat. Their naming convention incorporates the release number, the patch's family, and the letter as well as the abbreviation that references this as a family pack (i.e., PF). For instance, 11i.OM_PF.D would refer to the Order Management Family Pack D for 11i, the 11i and the PF being the major delimiters referencing the new family pack installation.

Family Consolidated Upgrade Patch

A Family Consolidated Upgrade Patch (FCUP, pronounced F-CUP) is a prerequisite patch for an upgrade. It usually includes performance improvements, bug fixes for processes that will be run in the patch that is to be run following the Consolidated Patch, any additional tablespaces, resizing information for existing tablespaces, or transfer of existing data dictionary managed tablespaces into locally managed tablespaces. If there are FCUPs required for an upgrade patch, they will be included in the release notes for that upgrade patch.

Maintenance Pack

A maintenance pack is a collection of minipacks bundled together into a significant zip file, which can usually be ordered on a collection of CDs. Maintenance packs were referred to as release updates in Release 10. The end result of applying this patch will be to change the third digit of the release string in the Application release number (e.g., 11.5.6 or 11.5.8). A maintenance pack allows you to install all minipacks with a single set of drivers. Oracle's convention of rolling all previous patches of a similar type into the latest patch is followed here and all prior maintenance pack changes are rolled up into the latest maintenance pack. Typically the purpose of a maintenance pack is to roll up all bug fixes since the previous maintenance pack into a consolidated package; however, (as is the case with the 11.5.8 version) there are occasions when additional functionality is rolled into the patch as well.

NLS (National Language Sets) Patches

When you have incorporated multiple languages in your implementation, on occasion you will need to install additional patches for each additional language installed. The American patch always needs to be applied first, followed by any NLS versions of the same patch. When you install the American version, you will need to make sure that you set the NLS_LANG variable to American_America <CHARACTER_SET> (substitute your appropriate character set for the CHARACTER_SET variable). Be sure to carefully read all README files that may contain reference to the need to install NLS patches and may provide special instructions needed during those installs.

While NLS patches are often needed, they are not always required. If the patch is a one-off patch that is simply fixing a stored procedure that may be in error or creating a new stored procedure, there is little likelihood that you will need a NLS version. If there are significant changes to Forms or Reports or if you are installing a minipack, family pack, or maintenance pack, you will likely find that you need to install an NLS version of that patch. If you have any doubts about the need to apply an NLS patch, contact Oracle Support to double-check.

The ADPATCH utility has added 11i functionality to alert you that you may need an NLS patch for a patch that you are installing. This is a handy feature. If it raises the possibility, you may need to double-check to see if there is an NLS version that needs to be installed. ADPATCH may alert you erroneously; so take the necessary steps to double-check the need to install one. Do not automatically assume that ADPATCH knows exactly what it is talking about.

Minor Release

A minor release needs to be added to the list of patches in the increasing size and complexity list that we have started here, even though it is important to make note that a minor release is not a true patch. A patch is typically installed either using Adpatch or simple steps set forth in a README. A minor release is similar to a maintenance pack in that it usually ships on a single set of CDs for each different OS involved in your implementation. Unlike a maintenance pack that takes the third number in the release string to a higher number, a minor release changes the second number (e.g., moving from 10.7 to 11.0 to 11.5). A minor release requires the use of AutoUpgrade or Rapid Install to accomplish the installation. A minor release's primary purpose is to add functionality or change the infrastructure of the implementation and is the basis for the supported versions of the applications as referenced in the support matrix.

Patch Naming

There is some logic put into the naming of patches. The names include the patch number (also often cross-referenced as bug number), release for which the patch was created (11i, 11.0, 10), and the OS (for OS specific patches) for which the patches are created. Therefore, p2250399_11i_AIX would be the patch number 2250399 created for Apps 11i as implemented on the AIX OS. OS-specific versions are usually released for Tru64, HP-UX, Sun Solaris, Intel Linux, Windows NT/2000, or AIX.

---