3 Plan for Patching

1. Set the ORACLE_HOME to the directory to be patched. For example:

   export ORACLE_HOME=/u01/app/idm/products/app/idm
   

2. Go to the OPatch directory and execute. For example:

   cd $ORACLE_HOME/OPatch
   

3. Check the output for text like the following:

   OPatch Version: 11.1.0.8.0
   OPatch succeeded.
   

1. Go to My Oracle Support (support.oracle.com) and select the Patches and Updates tab.
2. Select search by “Patch Name or Number” and enter the number 6880880 in the search field, and choose the operating system as show in the following figure. The same number (6880880) works for all operating systems and OPatch versions.

   Figure 3-1 Patch Search window

   
   
   Description of "Figure 3-1 Patch Search window"
   
3. Click Search.

   The Patch Search result appears as shown in the following figure:

   Figure 3-2 Patch Search Results

   
   
   Description of "Figure 3-2 Patch Search Results"
   
4. Select the most recent version of OPatch for the relevant release to display Readme and Download options.
5. Click the Read Me to read additional installation instructions.
6. Click Download and follow the installation instructions in the Readme text.

As mentioned previously, Oracle Fusion Applications includes both technical patches (which affect the underlying Middleware components) and functional patches (which affect the Fusion Applications product families).

Patches are release-specific; patch bundles designated for 11.1.10 cannot be applied to 11.1.9, nor to 11.1.11 versions of Oracle Fusion Applications. Furthermore, functional patches are released per product family. For example, HCM, SCM, and CRM each have their own functional patch bundles for a given release.

Patch planning is focused on functional and technical patches. IDM patching is normally handled either automatically or manually during upgrades, and is discussed in the Oracle Fusion Applications Upgrade Guide. There is a rare circumstance in which a patching strategy may be applied to Identity Management, as described in the Apply Identity Management (IDM) Patches section. Otherwise, IDM patching is not handled in this guide.

The following are some of the tools and strategies for assessing the effect that patching will have on a production environment:

• READMEs: The Patch READMEs describe the bug fixes and system areas addressed by the patch.

• Test Environments: Applying the patch on a test or patching environment and performing subsequent regression tests will help determine the timing and impact of a patch on a given Oracle Fusion Applications installation, and permit targeted planning for patching subsequent environments.

• Reports: The Patch Impact Report is available for functional patches. For more information, see the Patch Impact Report section.

It is important to document the patching plan and outcomes, to enhance team coordination and knowledge transfer, and to be used for future reference in system maintenance. Every organization creates its own documentation standards. A Patch Tracking Sheet is one way of centralizing information about the patches applied to a Fusion Applications environment. In general, the tracking sheet can be generated in almost any word editor or spreadsheet software, or even as a hard copy on paper. The basic and most minimal information which should be tracked and retained as follows:

• Requestor of the patch

• Patch Number

• Description of the patch

• Date Applied

• Target Environment

• Time Taken to Apply

• Issues Experienced

• Special Instructions

• Comments

• Oracle Service Request # (if applicable)

• Stay Current: Stay as current as possible with patching. Patches are cumulative, so if they are delayed, the system downtime for installation can expand considerably. On the other hand, patching disrupts normal system activities and patch releases can be frequent, so discernment is required. The best practice is to establish a cadence that minimizes the amount of downtime taken to apply the various patches while maximizing the uptake of key patches for the organization. 

• Patch in Order: Technical patches (P4FA) are always installed before functional patches. Patches are release-specific, cumulative, and sequential.

• Plan Outage Windows: Technical patching always requires that users exit the system, tasks and jobs be stopped, and the servers be taken offline. This comprises a true outage window. Functional patches can sometimes be applied as hot patches, in which no servers are shut down, users may remain in the system, and there is a defined time frame to allow background processes and jobs to complete before the patch is launched. In these cases, the “outage” is minimal. Some functional patches inhabit a grey area of online patching, in which servers remain up, but no users, transactions, or tasks are allowed. Have a clear understanding of which patching mode will be in use for any given patching session.

• Use a patching test environment: At a minimum, test patches on a non-production system to determine the necessary timing, analyze the patching effects and perform regression testing before applying the patch to a production system. Some organizations, in addition to test, dev, and prod environments, also establish a dedicated patch environment.

• Ensure communication: Establish an advisory forum with stakeholders and schedule notifications with all affected parties.

• Document the plan: Use tracking sheets and other systems to ensure that the patching team is coordinated and that patches are documented for future reference.