Patching Procedures

How patches are applied to an Oracle E-Business Suite system depends in part on the various strategies or options that may be chosen. In some cases, existing features of the system may determine how patches are applied.

This chapter covers the following topics:

• Preparing for Patching
• Performing Interactive Patching
• Performing Non-Interactive Patching
• Patching NLS Systems
• Applying Patches to a Multi-Node System
• Reducing Downtime
• Keeping Patches Current
• Analyzing Applied Patches
• Backing Out Patches

Preparing for Patching

For patches that have manual steps, the patch readme file instructs you to use Oracle Patch Application Assistant (PAA) to create customized instructions for your system. PAA consolidates and displays only the relevant manual steps for all the patches you want to apply, including steps that you have completed. It also automatically merges the contents of individual patch readme files for a merged patch.

Creating Customized Instructions for Patching Using PAA

Requirement: How do I know which manual steps associated with a patch apply to my system?

Sorting through the manual steps in a patch readme file to determine which ones apply to your system can be time-consuming. The Patch Application Assistant allows you to create a customized set of steps to that apply to your unique instance. Using the information on this list reduces the possibility of performing steps that are not necessary or that have been completed previously during the application of another patch.

When you download and unzip a patch, it delivers a static README.html file that advises you if the patch requires manual steps. If manual steps are required, you can generate a list of the steps by running a Perl script (admsi.pl) to initiate PAA. Once you have generated the list, use the PAA interface to see a full list of steps, or only those steps that apply to your system.

After successfully performing each manual step, you can record that it was completed. When applying patches in the future, this information is displayed in the PAA interface so that you can see which manual steps you have already performed. Unless specified otherwise, you can previously completed steps.

To run PAA

1. Download the patch that you want to apply and set (source) your environment. On UNIX systems, you must also set the environment variable DISPLAY to an active and authorized display.

   For instructions on setting your environment, see: Running AD Utilities, Oracle E-Business Suite Maintenance Utilities.

2. Run the admsi.pl script to generate customized installation instructions.

   $ admsi.pl
   

   The Oracle Patch Application Assistant welcome page appears:

   Oracle Patch Application Assistant Welcome Page

   

   You can select:

   • View instance-specific instructions for a new patch.

   • View generic instructions as shipped by Oracle for a new patch - to view all the generic manual steps for a particular patch, including the completed steps.

   • Look at all incomplete tasks from previous patches - to view all the manual steps that have not been completed from previous patches.

3. Select View instance-specific instructions for a new patch. Enter the APPS password, and select the location where the patch is staged. Click Next.

   The Summary of Installation Instructions page appears:

   Oracle Patch Application Assistant Summary of Installation Instructions Page

   

   This page summarizes all the manual steps for the patch, grouped into the following categories: Preparation Tasks, Pre-Install Tasks, Apply the Patch, Post-Install Tasks, Finishing Tasks, and Additional Information. This page displays only those categories in which there are manual steps.

4. Click the plus-sign icon in each category for more detailed information. For example, if you click the plus-sign icon next to Best Practices, the Preparation Tasks screen appears with the tasks suggested for preparing your system for patching.

   Oracle Patch Application Assistant Preparation Tasks Page

   

5. After you have completed all the manual steps in a category, check the Completed box to record the completion status in the database, then click Next. If a patch that you apply in the future contains any of the same manual steps, it will be marked as completed to inform you that you do not have to perform that task again.

   After you have completed all manual steps in all categories, the system returns you to the Summary of Installation Instructions page.

   Oracle Patch Application Assistant Summary of Installation Instructions Page

   

   Note the column of Completed boxes that corresponds to each task in a category. Check marks appear in the boxes for which you have completed manual steps.

6. Click Save to record tasks completed in the database. Click Cancel to exit PAA.

Performing Interactive Patching

Patches and updates to the Oracle E-Business Suite file system or database are applied using AutoPatch, which identifies the servers set up during your installation and performs the actions required by the patch on each APPL_TOP. In a shared application tier file system, changes made during patching sessions on one node are immediately available on all nodes.

You can apply a patch interactively or non-interactively. Interactive patching - the "normal" patching method - means that you supply all the information that AutoPatch needs by responding to a series of prompts. You can also apply a patch non-interactively to avoid having to respond to some of the AutoPatch prompts and to accommodate special types of patches. See: AutoPatch and Performing Non-Interactive Patching.

To ensure optimal performance and reduce downtime during patching sessions, AutoPatch requires that you enable Maintenance mode when you apply a patch. Enabling this feature shuts down the Workflow Business Events System and sets up function security so that Oracle E-Business Suite functions are unavailable to users. This provides a clear separation between normal runtime operation and system downtime for patching.

When the patching session is complete, you can disable Maintenance mode, allowing users full access to the newly updated system.

Note: When Maintenance mode is disabled, you can run AutoPatch by using options=hotpatch on the command line, if necessary. However, doing so can cause a significant degradation of performance.

See: Preparing your System for Patching.

Applying a Patch Interactively

Requirement: How do I apply a patch?

After you have determined that you need to patch your system, download the patch and use AutoPatch to apply it. Apply the unified driver to all APPL_TOPs. AutoPatch determines which actions are required for the current APPL_TOP.

Patches may require prerequisite patches and manual steps. Use PAA to generate customized instructions. These instructions contain all the required manual steps that are specific to your system.

Note: Some of the installation instructions generated by PAA may specify pre-install mode. If so, follow the instructions in Pre-Install Mode.

Caution: It is very important that you back up the file system and database before you apply large patches (such as release update packs, product family release update packs, or pre-upgrade patches). If the patching process fails when running the database portion of the unified driver, you will not be able to back out the patch. You must restart the patching process with a restored backup of the file system and database.

To apply a patch

This procedure describes the typical steps for applying a patch. Subsequent procedures describe command line options that change the default behavior of AutoPatch.

1. Log in as applmgr (Applications file system owner) and set the environment:

   UNIX:

   The environment file is typically APPS<CONTEXT_NAME>.env, and is located under the APPL_TOP. From a Bourne, Korn, or Bash shell, enter the following:

   $ . APPS<CONTEXT_NAME>.env
   

   Windows:

   Run %APPL_TOP%\envshell.cmd using either Windows Explorer or the Run command from the Start menu. This creates a Command Prompt window that contains the required environment settings for Oracle E-Business Suite. Run all subsequent commands in this Command Prompt window.

   If you are running on a Windows platform, ensure that all necessary tools are installed properly. In addition, all %JAVA_TOP% and %JAVA_TOP%\loadjava.zip files are included in the set CLASSPATH statement of %APPL_TOP%\admin\adovars.cmd.

2. Create a patch top directory, if it does not already exist. Download the patch into a staging directory and unzip the patch into the patch top directory. Do not use the patch subdirectory under the <PROD>_TOP directories as your patch top directory.

3. Change directory to the patch top directory where you unzipped the patch.

4. Review the readme file in the patch top directory.

   Review the readme file (README.txt or README.html). It contains an abstract of the patch. If the patch contains manual steps, the readme file will contain instructions for running Oracle Patch Application Assistant (PAA) to generate customized manual steps for your system.

5. If indicated in the patch readme, run PAA to generate customized instructions for applying the patch. You will need to provide the location of your patch top directory and the applmgr password.

   $ admsi.pl
   

   Perform the manual steps contained in the customized instructions generated by PAA. Additional steps may also be detailed depending on the patch, the state of your system, and the products you have installed.

   Perform the following steps, in addition to the steps detailed in the customized instructions, to apply the patch.

6. Shut down services.

   Run the adstpall.sh script to shut down the services appropriate to your system. You will need to provide the applmgr user name and password.

   Note: For more information on patching a multi-node system, see: Applying Patches to a Multi-Node System.

   UNIX:

   $ adstpall.sh
   

   Windows:

   C:\> adstpall.cmd
   

   Note: You must complete all tasks associated with applying a patch before you access Oracle E-Business Suite.

7. Enable Maintenance Mode.

   Use the Change Maintenance Mode menu (Option 1) of AD Administration to enable Maintenance mode. See: Enable Maintenance Mode.

8. Start AutoPatch.

   Use the adpatch command to start AutoPatch from the patch top directory (the directory where you downloaded the patch files). You can customize the way AutoPatch runs by adding arguments to the command line. See Command Line Arguments.

9. Respond to the AutoPatch prompts. You are prompted for the following information required to apply the patch:

   • Name of the APPL_TOP where you want to apply the patch

   • Log file name: Select a name for the log file, for example, u<patchnum>.log

   • Email where you want to receive notifications

   • Batch size (default is 1000)

   • Database name

   • Patch top directory where you unzipped the patch

   • Driver file name: Provide the name of the driver file located in the patch top directory, for example, u<patchnum>.drv

10. Apply the driver.

    At the AutoPatch prompt for the driver name, specify the name of the driver.

11. Review customizations.

    Customized files are registered on the OAM Register Flagged Files page. If AutoPatch displays a message indicating that previously registered, customized files will be replaced by the patch, review those files in the Register Flagged Files page to determine if the customizations need to be reregistered or removed. See: Register Flagged Files.

12. After AutoPatch exits, review the log files.

    Review the AutoPatch log file after the application of each driver file for warnings or errors. The log file (named u<patchnum>.log in step 9 is located in <APPL_TOP>/admin/<SID>/log. In addition, some patch tasks may create separate log files in the same directory. If the patching process used multiple workers, each worker creates its own log file. You can also use the View Log Files feature in Timing Reports to view the files. See: Log Files and View Log Files.

13. Preallocate space for packages, functions, and sequences (optional).

    If AutoPatch has modified Oracle E-Business Suite database objects, you may want to run ADXGNPIN.sql and ADXGNPNS.sql to allocate space ("pin") for new packages and sequences in the Oracle System Global Area. These scripts are located in AD_TOP/sql.

    See: Pre-allocating Space for Packages and Functions, Oracle E-Business Suite Maintenance Procedures.

14. Disable Maintenance Mode.

    Use the Change Maintenance Mode menu (Option 2) of AD Administration to disable Maintenance mode.

15. Restart server processes.

    After verifying that the patch was applied successfully, start all services. Once the services are running, you can allow users to access the system again.

    UNIX:

    $ adstrtal.sh
    

    Windows:

    C:\> adstrtal.cmd
    

    See: Stopping or Starting Application Tier Services, Oracle E-Business Suite Maintenance Procedures.

16. Delete or archive AutoPatch backup files (optional).

    After you have tested the patched system, you can delete the backup copies of files from the patch top directories to recover disk space, as necessary. Oracle recommends archiving these files if you have space available.

    See: Compressing, Archiving, and Deleting Files, Oracle E-Business Suite Maintenance Procedures.

Applying Unified Drivers

Requirement: I received a patch that contains a unified driver. However, the instructions state that I run only the database portion of the patch.

Certain procedures, such as patching with a staged APPL_TOP, may require you to apply only the database portion of a unified driver. In these cases, use command line options to tell AutoPatch which portions of the patch to omit.

Important: AutoPatch will apply all portions of the patch except those that you specifically omit on the command line.

To apply only a portion of a unified driver

1. Follow the instructions in Steps 1 through to 7 in Applying a Patch Interactively.

2. Enter the adpatch command as indicated in Step 8, adding the following options on the command line: nocopyportion,nogenerateportion. The command line syntax should look like this:

   $ adpatch options=nocopyportion,nogenerateportion
   

   See: Command Line Arguments.

3. At the prompt for the driver name, specify the unified (u) driver. AutoPatch runs the driver, applying only the database portion of the patch.

4. Respond to the AutoPatch prompts. See: AutoPatch.

5. Finish applying the patch as directed in Steps 12 through to 16 in Applying a Patch Interactively.

Testing a Patch Before Applying It

Requirement: How do I test the effects of a patch on my system before I apply it?

One way to see how applying a patch will affect your system is to first apply it on a test system. If you do not, or cannot, use a test system, you can apply the patch on your production system using the AutoPatch test mode argument (apply=no). AutoPatch lists the actions it will take, but does not actually perform any of the actions.

In test mode, AutoPatch reads and validates the patch driver file, reads product file driver files, extracts object modules from product libraries (for version checking), performs version checking, and runs AutoConfig (in test mode). It does not, however, update the database or file system. See: AutoConfig Test Mode, Oracle E-Business Suite Maintenance Utilities.

To determine how a patch will affect the files in your system, use the Patch Impact Analysis Report in Patch Wizard. See: Determining Patch Impact on System Files.

To test a patch

1. Follow the steps in Applying a Patch Interactively.

2. When directed to run AutoPatch, add the test mode argument to the command line:

   $ adpatch apply=no
   

3. Complete steps 11 and 12 in Applying a Patch Interactively. You must also complete steps 14 and 15 if you shut down your servers and enabled Maintenance mode before you ran AutoPatch.

Enabling Password Validation

Requirement: How can I validate passwords before I apply a patch?

To reduce the time it takes to apply a patch, AutoPatch (by default) does not validate Oracle schema passwords. If you need to enable password validation, you can do so by supplying the validate option (options=validate) on the command line when you run AutoPatch.

If you are applying multiple patches, you should use AD Merge Patch to combine the patches (where compatible) so that you apply them in a single AutoPatch session. In this case, you need to validate passwords only once. See: Creating a Merged Patch.

If you have several patches that cannot be merged, you can save time by turning on the validate option only for the application of the first patch, and then leaving it off for the subsequent patches.

To validate passwords

1. Follow the instructions in Applying a Patch Interactively.

2. When directed to run AutoPatch, use the validate command. It should look like this:

   $ adpatch options=validate
   

3. Complete the remaining steps in Applying a Patch Interactively.

Applying Emergency Patches

Requirement: Can I apply a patch without shutting down system services?

If an emergency patch can be applied without shutting down services, the customized instructions generated by PAA will explicitly state so. If the customized instructions do not explicitly state this, assume that you need to shut down services and enable Maintenance mode before applying the patch.

Tip: You can always apply documentation patches (Oracle E-Business Suite Online Help) without shutting down services.

To apply an emergency patch

1. Apply the patch on a test version of your production database. Make sure the test copy is recent so that it closely approximates your production system.

2. Run AutoPatch using options=hotpatch and apply the patch. You may not have to shut down the server processes. See: AutoPatch Options.

Performing Non-Interactive Patching

You can apply patches interactively or non-interactively. Interactive patching means that you supply basic information that AutoPatch needs by responding to a series of prompts. See: Performing Interactive Patching.

Applying a patch non-interactively substantially reduces the need for user intervention when AutoPatch processes patching tasks. You create a defaults file that contains much of the information you would have supplied at the AutoPatch prompts. Then, when you run AutoPatch, you specify the name of the defaults file, the location of the patch top directory, the name of a driver file, and other parameters on the command line. AutoPatch performs the remaining actions based on the information in the defaults file.

Caution: You should always back up the file system and database before you apply large patches such as release update packs (RUPs), product family RUPs, or pre-upgrade patches.

Applying a Patch Non-Interactively

Requirement: How do I apply a patch non-interactively?

Instead of responding to AutoPatch prompts each time you initiate a patching session, you can store the responses in a defaults file. Then you specify the name of the defaults file when you run patches non-interactively. As it runs, AutoPatch uses the responses to complete the information for the corresponding prompts, and completes patch processing with little or no user intervention.

To set up a non-interactive patching session, first create and save a defaults file by using the defaultsfile=<defaults file name> argument when you run AutoPatch. This causes the information you provide at the prompts, and other pertinent information, to be captured and saved.

Note: AutoConfig automatically creates a defaults file (adalldefaults.txt) each time it runs. This file can be used as a template to create a customized defaults file. However, we recommend that you create the defaults file as described in this procedure.

To apply a patch non-interactively

1. Create the defaults file.

   Start AutoPatch, using the defaultsfile= argument, and specify the file name and the path to the defaults file. This creates a defaults file for the current environment.

   UNIX:

   The file must be under the $APPL_TOP/admin/<SID> directory, where <SID> is the database name (ORACLE_SID/TWO_TASK). For example:

   $ adpatch defaultsfile=$APPL_TOP/admin/testdb1/adpatchdef.txt
   

   Windows:

   The file must be under the %APPL_TOP%\admin\<SID> directory, where <SID> is the database name (LOCAL). For example:

   C:\> adpatch defaultsfile=%APPL_TOP%\admin\testdb1\adpatchdef.txt
   

2. Run AutoPatch to the point where it prompts for the directory where the Oracle E-Business Suite patch has been unloaded. Enter abort at this prompt.

3. Verify that the defaults file exists.

4. Run AutoPatch non-interactively to apply a single patch driver, all drivers, or any of the other procedures in this section.

Applying a Single Patch Driver

Requirement: How do I apply a single patch driver non-interactively?

If you have created a defaults file, specify AutoPatch to run non-interactively and specify the location and name of the defaults file and the driver.

To apply a single patch driver

1. Create the defaults file as described in Applying a Patch Non-Interactively.

2. Follow steps 1 through to 7 in Applying a Patch Interactively.

3. Run the AutoPatch command, adding the following arguments: location of the defaults file (defaultsfile=), a name for the log file (logfile=), location of the patch top directory (patchtop=), name of the driver file (driver=), number of workers to use for applying the patch (workers=), and interactive=no.

   For example, if the defaults file is APPL_TOP/admin/testdb1/def.txt, the driver file is u1234567.drv for patch 1234567 (located in APPL_TOP/patches/1234567), you will use three parallel workers, and the AutoPatch log file name is 1234567.log, you would enter the following.

   UNIX:

   $ adpatch defaultsfile=$APPL_TOP/admin/testdb1/def.txt \
   logfile=1234567.log

   patchtop=$APPL_TOP/patches/1234567 driver=u1234567.drv \
   workers=3 interactive=no
   

   Windows:

   C:\> adpatch defaultsfile=%APPL_TOP%\admin\testdb1\def.txt logfile=1234567.log patchtop=%APPL_TOP%\patches\1234567 driver=u1234567.drv workers=3 interactive=no
   

4. Perform the remaining steps in Applying a Patch Interactively (as necessary).

Applying a Non-Standard Patch

Requirement: I need to apply a patch that was not created with the standard patch naming convention. I would like to apply it non-interactively.

A non-standard patch is one where the structure is standard, but the naming convention is not. That is, the last component of the patch directory is not a 6- to 8-digit number, or the patch driver files are not named *<patchnum>.drv, or both. Most merged patches are non-standard because of the way they are named.

To apply a non-standard patch

1. Create the defaults file as described in Applying a Patch Non-Interactively.

2. Follow steps 1 through to 7 in Applying a Patch Interactively.

3. Run the AutoPatch command as described in Applying a Single Patch Driver. For the driver=<values> argument, use a comma-separated list of the patch driver names.

4. Perform the remaining steps in Applying a Patch Interactively (as necessary).

Restarting a Non-Interactive AutoPatch Session

Requirement: AutoPatch failed with an error while I was applying patches non-interactively. I have resolved the issue that caused the error and want to restart the failed session.

When AutoPatch is running non-interactively and encounters an error, it exits to the operating system and reports a failure. The restart argument is intended specifically for this circumstance. When AutoPatch sees the restart=yes argument, it assumes that there is an old session, and expects to find one. If it cannot, it will fail. Do not specify restart=yes to start a new AutoPatch session.

To restart a non-interactive AutoPatch session

1. Look through the log files, diagnose the error, and fix it.

2. Use the same command line options that you used initially, but add restart=yes. As an illustration, the following command can be used to restart the previous example given of Applying a Single Patch Driver.

   UNIX:

   $ adpatch defaultsfile=$APPL_TOP/admin/testdb1/def.txt \
   logfile=1234567.log patchtop=$APPL_TOP/patches/1234567 \
   driver=u1234567.drv workers=3 interactive=no restart=yes
   

   Windows:

   C:\> adpatch defaultsfile=%APPL_TOP%\admin\testdb1\def.txt logfile=1234567.log patchtop=%APPL_TOP%\patches\1234567 driver=u1234567.drv workers=3 interactive=no restart=yes
   

   Warning: Do not omit any of the original command line arguments, as this could change the behavior of AutoPatch and cause unpredictable results.

Abandoning a Non-Interactive AutoPatch Session

Requirement: AutoPatch failed with an error while I was applying patches non-interactively. I do not want to restart the failed session, but would rather apply another patch non-interactively.

When you specify interactive=no on the AutoPatch command line, AutoPatch expects that there is no existing failed session. AutoPatch aborts if it finds restart files from a failed session. Running AutoPatch with the interactive=no and restart=yes command line arguments restarts the previously incomplete session.

To start a completely new AutoPatch session when there is an existing failed session, specify interactive=no and abandon=yes on the AutoPatch command line. With this command, AutoPatch deletes the restart files and any leftover database information from the failed session.

Caution: If you use the abandon=yes argument, you cannot subsequently restart the failed session as the restart files are no longer available. Do not specify abandon=yes if you might want to restart the session later.

To abandon a non-interactive AutoPatch session

1. Verify that you do not want to restart the previous failed session.

2. Start AutoPatch with the abandon=yes option:

   UNIX:

   $ adpatch defaultsfile=$APPL_TOP/admin/testdb1/def.txt \
   logfile=7654321.log patchtop=$APPL_TOP/patches/7654321 \
   driver=c7654321.drv workers=3 interactive=no abandon=yes
   

   Windows:

   C:/> adpatch defaultsfile=%APPL_TOP%\admin\testdb1\def.txt logfile=7654321.log patchtop=%APPL_TOP%\patches\7654321 driver=c7654321.drv workers=3 interactive=no abandon=yes
   

Patching NLS Systems

These patching procedures apply regardless of whether you are running American English (US) and one additional language, or American English (US) and several additional languages. If your system uses multiple languages, you can use AD Merge Patch to create merged patches in the following ways:

• A single, merged patch that contains all languages (including US).

• One merged patch for US and a second merged patch for all other languages.

• A separate merged patch for each language.

Each of these options has advantages and disadvantages. The first option is the simplest to apply because there is only one patch involved. However, it requires the longest system downtime of the three options, as the patch can be large. The second option is relatively easy to apply, and allows you to bring US users back online while you apply the patch for non-US languages. The third option is the most difficult to apply, but allows you to bring users for various non-US languages back online in a phased approach, which could be useful for multi-national corporations in some situations. Oracle generally recommends the second option because it provides the best compromise between easy application and minimum downtime.

When merging multiple language patches, AD Merge Patch converts the character set according to the NLS_LANG variable in the Oracle E-Business Suite environment file. If you changed your character set since the initial installation, you might need to update the NLS_LANG variable. If this variable is not set properly, run OAM AutoConfig to update the Oracle E-Business Suite context with the correct character set information, then run the AutoConfig script to recreate the Oracle E-Business Suite environment file. Reset the environment using the new environment file before merging patches.

See: AD Merge Patch, and Managing Configuration Parameters, Oracle E-Business Suite Maintenance Utilities.

Applying a Single Patch to an NLS Installation

Requirement: I need to apply a single patch to an Oracle E-Business Suite NLS installation.

If an Oracle E-Business Suite system contains languages other than American English (US), the recommended method is to apply the US patch first and then apply the translation patch for each installed language. If you have installed more than one additional language, you can merge all the translation patches and apply them as a single, merged NLS patch.

You can also merge US patches with the additional language patches. However, depending on your downtime window and your system topology, it may be necessary to keep the US and non-US patches separate. See: Applying an Emergency NLS Patch.

To apply a single patch to an NLS installation

This procedure assumes that you will apply US and language patches separately.

1. Use AutoPatch to apply the patch driver of the US patch.

2. Use AutoPatch to apply the patch drivers of each NLS patch. If you have merged the individual NLS patches for a system that runs multiple languages, apply the driver for the merged NLS patch. See: Applying a Patch Interactively.

Applying Multiple Patches to an NLS Installation

Requirement: I need to apply several patches to an Oracle E-Business Suite NLS installation.

If an Oracle E-Business Suite system contains multiple languages other than American English (US) and you are applying multiple patches for each language, the recommended method is to merge all US patches into a single patch and all patches for every non-US language into a single patch. Then apply the merged US patch followed by the merged language patch.

You can also merge US patches with the additional language patches or merge each language in separate language-specific patches. Depending on your downtime window and your system topology, it may be necessary to keep the US and non-US patches separate. This procedure assumes that you will apply US and language patches separately.

See: Applying an Emergency NLS Patch.

To apply multiple patches to an NLS installation

This example assumes the system has American English, French, and German installed.

1. Use AD Merge Patch to merge the US (American English) patches into a single patch.

2. Use AD Merge Patch to merge the French and German patches into a single NLS patch.

3. Use AutoPatch to apply all drivers of the merged US patch.

4. Use AutoPatch to apply all drivers of the merged NLS patch.

Applying an Emergency NLS Patch

Requirement: I do not want to shut down my system to apply all the translation patches.

When applying a patch that requires a language translation, you can defer the application of the database portion of the translation driver until after you have applied the other drivers. This allows the system to be available to all users during the time the language translation is being applied. Remember that you can merge NLS patches if you have several to apply.

See: Creating a Merged Patch.

To apply an emergency NLS patch

1. Shut down the system (all services) and log off users.

2. Enable Maintenance Mode.

3. Apply the US copy portion of the unified driver to all servers.

4. Apply the US database portion of the unified driver to the administration server.

5. Apply the US generate portion of the unified driver to all servers.

6. Disable Maintenance Mode.

7. Bring up the system and allow US users to log on.

8. Apply the translation copy portion of the unified driver to all servers using options=hotpatch on the command line.

9. Apply the translation generate portion of the unified driver to all servers using options=hotpatch on the command line. See: AutoPatch Options.

10. Allow translation users to log on.

11. Apply the translation database portion of the unified driver to the administration server using options=hotpatch on the command line.

Applying Patches to a Multi-Node System

In a multi-node system, servers are installed on more than one node. The core technology directories (admin, ad, au, and fnd) and all product directories are installed under the APPL_TOP on all nodes, except for any node that contains only a database.

Oracle E-Business Suite Release 12 introduced the concept of unified APPL_TOPs. On a multi-node system, exactly the same files are stored on every APPL_TOP. This architectural enhancement allows you to switch the function of a node easily if another node fails, by starting the application services on a different machine, with only minimal changes to the overall configuration. When maintaining this type of system, patches will perform the same tasks in the file system, but the database actions will be performed only once.

Alternatively, a system can be configured to share an APPL_TOP in situations where failover is not a concern. In a shared application tier file system, the APPL_TOP, COMMON_TOP, OracleAS 10.1.2 Oracle home, and OracleAS 10.1.3 Oracle home file systems are installed on a shared disk resource that is mounted on each node in the system. Any changes made to a shared file system environment are immediately available on all nodes.

For more information, see: Managing Distributed Installations, Installing Oracle E-Business Suite; Shared Application Tier File System, Oracle E-Business Suite Concepts; My Oracle Support Knowledge Document 384248.1, Sharing the Application Tier File System in Oracle E-Business Suite Release 12; and Patching the APPL_TOP in a Shared Application Tier File System.

Running a Unified Driver on Multiple Nodes

Requirement: How do I run a unified driver patch on a multi-node system?

Apply the unified driver to all APPL_TOPs. AutoPatch determines which actions in the unified driver are required for the current APPL_TOP.

To apply a unified driver on multiple nodes

1. Complete Steps 1 through to 9 in Applying a Patch Interactively.

2. Apply the unified driver on the node where the administration server is located.

3. Apply the unified driver on the node where the concurrent processing server is located.

4. Start the concurrent managers.

5. Apply the unified driver on the remaining nodes in the application tier.

6. Disable Maintenance mode.

   Use the Change Maintenance Mode menu of AD Administration to disable Maintenance mode. See: Changing Maintenance Mode, Oracle E-Business Suite Maintenance Utilities.

7. Start other services and restart the Web services, if necessary.

Patching the APPL_TOP in a Shared Application Tier File System

Requirement: How do I apply patches to a system with a shared application tier file system configuration?

A traditional multi-node system requires the application tier file system on each node. In a shared application tier file system, the APPL_TOP, COMMON_TOP, 10.1.2 Oracle home, and 10.1.3 Oracle home file systems are installed on a shared disk resource mounted to each node in the system. These nodes can be used to provide standard application tier services, such as forms, Web, and concurrent processing. Any changes, including patching, made to a shared file system are immediately visible on all nodes.

Although it is possible to apply patches from any node, Oracle recommends you choose one node as primary and apply all patches from this node. When you choose a primary node, AutoPatch and AutoConfig log files are consistently written to the same location.

You can further reduce patching downtime by employing more than one node when applying patches. See: Distributing the Processing Tasks.

To patch the APPL_TOP in a shared application tier file system

For the APPL_TOP of a shared application tier file system, apply the patch once, as outlined in Applying a Patch Interactively.

Reducing Downtime

This section contains procedures designed to help reduce the time it takes to apply patches, and consequently reduce the time your system is offline and unavailable to users.

Creating a Merged Patch

Requirement: I need to apply several patches. Is there any way to reduce the time it takes to apply them?

You can merge multiple patches into a single patch by using AD Merge Patch. This AD command line utility merges multiple AutoPatch-compatible patches into a single, integrated patch. After the merged patch is created, you use AutoPatch to apply it in a single operation. Applying a merged patch reduces the time it takes to complete the patching process. See: AD Merge Patch.

In general, you can safely merge any Oracle E-Business Suite patch with another Oracle E-Business Suite patch. Patches can and should be merged with their listed prerequisite patches to make patch application easier.

Note: AD Merge Patch can merge patches for a specific platform with a generic patch, or patches with different source character sets. It cannot merge patches of different releases, different parallel modes, or different platforms. AD Merge Patch notifies you if you try to merge incompatible patches.

Patches that affect the Applications DBA (AD) product must be handled separately. AD patches can be merged with other AD patches, but AD patches and non-AD patches cannot be merged because AD patches may change the AutoPatch utility itself. Merged AD patches must be created separately and applied before you apply non-AD patches.

When merging patches on systems that use languages other than American English, different considerations apply. For information about merging and applying NLS patches, see Applying Multiple Patches to an NLS Installation.

Use either the command-line procedure or the OAM (Web-based) procedure to create a merged patch.

Command-line procedure

1. Set the environment to indicate the location of the configuration parameter that define your system:

   UNIX:

   The environment file is typically APPS<CONTEXT_NAME>.env, and is located under the APPL_TOP. From a Bourne, Korn, or Bash shell, enter the following:

   $ . APPS<CONTEXT_NAME>.env
   

   Windows:

   Run %APPL_TOP%\envshell.cmd using either Windows Explorer or the Run command from the Start menu. This creates a Command window that contains the required environment settings for Oracle E-Business Suite. Run all subsequent commands in this Command window.

2. Create directories.

   AD Merge Patch merges the set of files in individual patches under a source directory according to file revision and copies them to a destination directory. Run AD Merge Patch from the parent directory of the source directory. The destination directory should be located in the same parent directory.

   In the patch top area, create a source directory and a destination directory. Choose any name for these directories.

   For information on setting up the directories, see: Source and Destination Directories.

3. Download patches.

   Download all the patches you want to merge to the source directory.

4. Review the patch readme files.

   Some patches require special attention and additional steps if the patch is to be merged. Carefully review the readme file and follow the instructions.

5. Run AD Merge Patch.

   The merged patch is created in the destination directory. Run AD Merge Patch and supply the arguments for the destination directory name, and the source directory name.

   $ admrgpch -s <source directory> -d <destination directory>
   

   You can specify the merged patch name with -merge_name <name>, or accept the default.

   You can merge patches before you unzip them by running AD Merge Patch with the -manifest command line argument. You must initially create a manifest file, which lists only the zip files. AD Merge Patch unzips these files into the source directory and includes them, along with any existing files in the source directory, in the merged patch. To use a manifest file, add the -manifest argument to the command line.

   $ admrgpch -s <source directory> -d <destination directory> \
   -merge_name <name> [-manifest <manifest filename>]

   For example, if you have four patches named 1234561, 1234562, 1234563, and 1234564 located in the source directory /d01/patch_merge/source, and the destination directory is /d01/patch_merge/destination. To create a merged patch named "merge99", you would use commands similar to the following:

   UNIX:

   $ cd /d01/patch_merge
   $ admrgpch -s /d01/patch_merge/source \
   -d /d01/patch_merge/destination \
   -merge_name merge99
   

   Windows:

   C:\> cd \d01\patch_merge
   C:\> admrgpch -s d:\patch_merge\source -d d:\patch_merge\destination -merge_name merge99

   For more information on creating a manifest file, see: Merging Zipped Patches.

   Tip: If you do not want to create a manifest file, unzip all the patches to be merged into the source directory and omit the manifest file argument.

6. Check AD Merge Patch log files.

   After AD Merge Patch runs, check the admrgpch.log file for errors. The file is located in the current working directory (where AD Merge Patch was run).

7. Apply the patch.

   After a merged patch is created, apply it just like a single patch, either interactively or non-interactively. If you apply it non-interactively, follow the instructions for Applying a Non-Standard Patch.

OAM (Web-based) procedure

1. Access the Oracle Applications Manager.

   Follow the instructions in Accessing Patch Wizard to access OAM.

2. From the Patch Wizard Tasks table, click the Tasks icon corresponding to Download Patches.

   The Download Patches page appears.

   Download Patches Page - Top

   

3. Enter the patch numbers of the patches you want to merge in the Patch List field.

4. In the Merge Options area, select Automatically merge downloaded patches. Also, specify the merged patch name and the merging strategy in this section. Click OK to begin downloading and merging the patches.

Deferring the Upload of Patch Information

Requirement: Is there any task in the AutoPatch process that I can defer until after the system downtime?

AutoPatch uploads patch history information to the database automatically each time it successfully applies a patch. The time required for the upload may be substantial depending on the size of the patch. You can defer this task during the AutoPatch session and upload the patch history information while the Oracle E-Business Suite system is in use.

When you defer the uploading of patch history information to the database, AutoPatch writes it to the patch information files:

• javaupdates<YYYYMMDDhhmiss>.txt, which contains information about changes to Java files

• adpsv<YYYYMMDDhhmiss>.txt, which contains information about changes to all files except Java files

Both files are located in the APPL_TOP/admin/<SID> directory. After the AutoPatch session is complete and the Oracle E-Business Suite system is back online, run AutoPatch with the uploadph=y argument to upload the contents of the patch information files to the database.

To defer the upload of patch information

1. Perform preparatory patch steps. See: Applying a Patch Interactively.

2. Apply the patch by running AutoPatch with the defer patch history information upload option. See: phtofile AutoPatch option.

   $ adpatch options=phtofile
   

3. After the patch session is complete, disable Maintenance mode, restart all services and allow users to access the system.

4. Run AutoPatch with the upload patch history information argument. See: uploadph AutoPatch option

   $ adpatch uploadph=y
   

   AutoPatch uploads the patch history information to the database and exits.

Distributing the Processing Tasks

Requirement: How can I use the processing capacity on the other nodes in my system when I apply a patch?

Creating a multi-node system with a shared application tier file system saves patching time because you apply patches only once, on the primary node. However, when applying a patch that includes a large number of processes that affect the database, you can reduce the downtime even further by distributing the worker processes across multiple servers on multiple nodes.

This distributed AD feature of AutoPatch and AD Controller allows you to assign workers to run not only on the primary node but also on the secondary nodes that share the application tier file system.

See: Distributing Processing Tasks Across Nodes, Oracle E-Business Suite Maintenance Utilities.

To distribute processing tasks

1. Start AutoPatch on the primary node with the following command options:

   $ adpatch workers=<total number of workers> \
   localworkers=<number of workers on primary node>
   

   For example, this command runs an AutoPatch session with three workers on the primary node and five workers on a remote note:

   $ adpatch workers=8 localworkers=3
   

2. Start an interactive AD Controller session on each of the secondary nodes that will run workers by using the distributed=y argument.

   $ adctrl distributed=y
   

3. On each secondary node, AD Controller prompts for the range of workers to start. For example, to start workers 5 through 8 on a node, enter "5-8" in response to the "Enter the worker range" prompt.

   Enter the worker range: 5-8
   

   Note: Workers must be in contiguous groups. For example, you cannot start workers 4, 6, 8 on one node, and 5, 7, 9 on another.

Using a Staged Applications System

Requirement: How can I reduce the time my system is down when I apply large patches?

A staged Oracle E-Business Suite system represents an exact copy (clone) of your production system, including all APPL_TOPs as well as a copy of the production database. You can apply patches to a staged system while the production system remains in operation. Then you connect the staged system to the production system, update the database, and synchronize the APPL_TOPs.

The downtime for the production system begins only after all patches have been successfully applied to the staged system, and you have tested the newly patched environment.

Note: The AD codelevels of the staged system and the production system must be identical. You cannot use a staged system to apply AD release update packs (RUPs) or new product patches associated with a pre-upgrade patch.

After the patches are applied to the staged system, and the production system is updated, you must export applied patches information from the staged system and import it to the production system. This ensures that the OAM patch history database in the production system is up-to-date and that you can continue to use patch-related features.

There are several phases to creating a staged system, patching it, and updating the production system.

Complete Prerequisite Tasks

A staged system must be an exact duplicate of the production system. Each physical APPL_TOP in the production system must exist in the staged system. Note the following conditions:

• The APPL_TOPs in the staged system must have the same name as the APPL_TOPs in the production system to ensure consistency of the patching history in the production system. When patch history data is imported from the staged system to the production system, each system must have the same APPL_TOP names.

• The database in the staged system should have a different <SID> to avoid accidental connections to the production system. Passwords, ports, and any process or service-related parameters can be changed to further reduce risks.

• You must have different Oracle E-Business Suite system names for the staged and the production systems. AutoPatch will correct the historical information.

Complete the following tasks:

1. Update the production system snapshot.

   Verify that your system current view snapshot is up-to-date by running the Maintain Current Snapshot task in AD Administration. Run the task on all APPL_TOPs in your system. See: Maintain Applications Files Tasks, Oracle E-Business Suite Maintenance Utilities.

2. Create the staged system.

   Create a clone of the production database, the application tier components, and each APPL_TOP to use as the staged system. See: Cloning, Oracle E-Business Suite Maintenance Procedures.

Apply Patches to the Staged System

You patch the staged system in the same way that you patch any other system by using AutoPatch to apply the patch drivers. See AutoPatch and Performing Interactive Patching for details. If you need to apply more than one patch, consider merging the patches to further reduce downtime.

Important: Do not apply any other patches to the production system during this process. If you do, you will have to recreate the staged system.

Apply Patches to the Production System

After the patching is complete on the staged system, you are ready to update the production system.

1. Enable a connection from the staged system to the production system.

   Add the production system information to the tnsnames file on the staged system. Update the s_ifile AutoConfig variable in the APPL_TOP context file on the staged system to "<AS Oracle Home>/network/admin/globaltns.ora". For instructions on updating configuration parameters and variables, see: Managing Configuration Parameters, Oracle E-Business Suite Maintenance Procedures.

2. Shut down the production system.

   On the production system, set the environment, shut down all services, and enable Maintenance mode.

3. Update the production database.

   On the staged system, set the environment, then run AutoPatch to apply patches to the production system.

   For each patch, apply the driver for the patch with the options=nocopyportion,nogenerateportion options to the AutoPatch start command, adpatch. Make sure the database name in the AutoPatch prompt is correct.

4. Update the production APPL_TOPs.

   Synchronize all the production APPL_TOPs with the staged APPL_TOPs. To minimize downtime, you can complete this task while the production database is being updated. For example, on UNIX you can either do a simple copy with cp, or use utilities such as rdist, rcp, or zip.

   Note these conditions:

   • If your staged system contains multiple APPL_TOPs, you must synchronize each one to the respective APPL_TOP on the production system.

   • If you share a single APPL_TOP, you need to synchronize only one APPL_TOP.

   • The COMMON_TOP directory, which may reside outside the APPL_TOP, must be updated for each APPL_TOP.

Certain configuration files, log directories, and environment scripts are specific to an APPL_TOP. You do not have to copy the following files and directories when you copy the APPL_TOP:

• $APPL_TOP/admin/<SID>

• $FND_TOP/out

• $FND_TOP/log

• $COMMON_TOP/html/_pages

• $APPL_TOP/log/

If you use the rdist utility, you can use a distfile to exclude these files. Run AutoConfig on the production APPL_TOP to configure the environment.

Create a Complete Production Patch History

At this point, the copy and generate portions of the patch history for patches applied to the staged system are stored in the staged system database, and the database portion of the patch history is stored in both the staged system database and the production system database. To create a complete copy of the patch history on the production system, use the adphmigr.pl utility to load the applied patches information from the copy and generate portions of all patches into the production database.

For each patch applied to the staged system, you must export patch history for each APPL_TOP in the staged system and import it for the corresponding APPL_TOP in the production system. Users do not have to log off the production system while you perform the import and export tasks. Finish consolidating the production system patch history before you apply any additional patches to it, or before you use any patch-related Oracle Applications Manager (OAM) features.

1. Export applied patches information.

   From the staged APPL_TOP, run the adphmigr.pl script (located in <AD_TOP>/bin). Enter adphmigr.pl -help to see all valid options for running the utility. Oracle recommends you export patch history separately for each APPL_TOP, as you will need to import it separately.

   Specify nodatabaseportion=y on the command line to ensure that the patch history data for the database portion of the patches applied is not exported. For example:

   $ perl $AD_TOP/bin/adphmigr.pl userid=apps/apps \
   startdate='2003/10/10 00:00:00' enddate='2003/14/10 00:00:00' \
   appsystemname=stage appltopname=tafnwl nodatabaseportion=Y
   

   You can obtain the appsystemname and the appltopname by looking up the values of s_atName and s_systemname in the AutoConfig-generated environment XML file.

2. Verify export data.

   The script generates two data files for each run of AutoPatch on the staged APPL_TOP, one for java updates and one for all other patch actions. Check adphmigr.log to ensure the data files represent the patch runs you wish to export, and that the start and end times specified did not include any unwanted AutoPatch runs.

3. Import applied patches information.

   For each APPL_TOP in the production system, copy the data files extracted for the corresponding APPL_TOP in the staged system to the <APPL_TOP>/admin/<SID> directory. The next time you run AutoPatch in this APPL_TOP, it will automatically upload these files.

   To load the files immediately, run AutoPatch interactively, answer the prompts until you are prompted for the name of the patch driver file. At that point, exit AutoPatch by entering abort at the patch driver file prompt.

   Important: The FNDLOAD method of transferring patch history is no longer recommended. The adphmigr.pl script method is easier to use and more efficient.

Keeping Patches Current

Each time you apply a patch, AutoPatch stores the associated information in the Oracle Applications Manager (OAM) patch history database. The OAM Patch Wizard and Applied Patches tools provide graphical user interfaces that you can use to query the database for a complete history of patches applied to your system, to search for the patches you have already applied, and to determine existing patches that should be applied to keep your system current. Patch Wizard determines which recommended patches you should apply to your system, and the impact of applying these patches.

Before running Patch Wizard, you must set up My Oracle Support credentials. You must also set up preferences and filters that govern the way you download patches. To see how to complete these one-time tasks, as well as learn about navigating the Patch Wizard pages and submitting requests, see: Patch Wizard.

Creating a List of Recommended Patches

Requirement: How do I determine if there are patches that I have not yet applied?

Patch Wizard creates a list of patches by comparing the patches in the patch history database against a list of recommended patches in a Patch Information Bundle file downloaded from My Oracle Support. It then determines which of the recommended patches you should apply to your system and reports the contents of the patch and the files that it will update when applied.

It does not report on all available patches, but only patches at the current codeline, such as high-priority patches, and those that update your system to a new codeline (pre-upgrade patches).

To see a list of patches recommended for your system

1. Access Oracle Applications Manager.

   Follow the instructions in Accessing Patch Wizard to access OAM. All procedures in this section begin with the Site Map.

2. Access the Patch Wizard home page.

   From the Site Map (Maintenance tab), click Patch Wizard under the Patching and Utilities heading.

   Site Map Page

   

   The Patch Wizard home page appears.

3. Submit a request for recommended patches.

   From the Recommend Patches page, select a patch filter. Use the magnifying glass icon to see a list of available patch filters.

   Recommend Patches Page - Top

   

   After you have entered the request information, click OK. The results of your request are shown in the Results section of the Patch Wizard main page. You can also schedule the request for a future date.

4. Track the status of your request.

   From the main page, you can track the status of your recommended patch request. Click the Job Status icon for the Recommend/Analyze Patches task.

   Job Status Page

   

   The Job Status page displays summary information. If you click the Show/Hide icon corresponding to your request ID, the page displays more details. For more information about the fields and functions on this page, see: Patch Wizard.

Downloading Recommended Patches

Requirement: How do I use Patch Wizard to download patches?

Patch Wizard can download patches based on either the list created by the "recommend patches" request or any list of patches entered in the Download Patches page.

The Download Patches page prompts you for information about the patches to download, then downloads them directly from My Oracle Support. The Merge Options section of this page defines how patches should be merged after they are downloaded.

To download patches using Patch Wizard

1. Access Oracle Applications Manager.

   Follow the instructions in Accessing Patch Wizard to access OAM. All procedures in this section begin with the Site Map.

2. Access the Patch Wizard home page.

   From the Site Map (Maintenance tab), click Patch Wizard under the Patching and Utilities heading.

   Site Map Page

   

   The Patch Wizard home page appears.

   Patch Wizard Home Page

   

3. Submit a request to download patches.

   Click the Tasks icon for Download Patches. The Download Patches page appears.

   Download Patches Page - Top

   

   On this page, list the patches you want to download in the Patch List field.

   Another option is to click the Details icon for a recommended patch request in the Results section of the Patch Wizard home page.

   Patch Wizard Home Page - Recommended Patches Results

   

   The Recommended Patches Results page for the recommended patch request appears.

   Recommended Patches Results Page

   

   Select any number of recommended patches on this page and click the Download button. This populates the Patch List field in the Download Patches page with the selected patch numbers.

4. Set download options.

   On the Download Patches page, set Merge options and indicate information about languages and platforms. If you choose to automatically merge patches while downloading, specify the merged patch name and the merging strategy. You can select the languages and platform of the patches to download. When you provide information in this section of the page, Patch Wizard only downloads patches that match the selected languages and platform. You can also schedule the download for a future date.

5. Submit request.

   After you have entered the patch information, click OK.

6. Track the status of your request.

   From the main page, you can track the status of your patch request. Click the Job Status icon for Download Patches.

   Job Status Page

   

   The Job Status page displays. If you click the Show/Hide icon corresponding to you request ID, the page displays more details. For more information about the fields and functions on this page, see: Patch Wizard.

Determining Patch Impact on System Files

Requirement: Before I apply a patch, can I see which system files will be affected?

Patch Wizard provides a Patch Impact Summary page that shows the impact of a specific patch if applied to your system. It contains the following information: Patch Impact Analysis, Direct Impact Summary, and Indirect Impact Summary. By reviewing these results, you can see detailed information about files included in a patch, as well as the effect a specific patch will have on your existing system files. For example, you can see information about total files in the patch, the number and type of files that will be installed, and which existing files will be changed. See: Patch Wizard.

To view the information on the Patch Impact Summary page

1. Access Oracle Applications Manager.

   Follow the instructions in Accessing Patch Wizard to access OAM. All procedures in this section begin with the Site Map.

2. Access the Patch Wizard home page.

   From the Site Map (Maintenance tab), click Patch Wizard under the Patching and Utilities heading.

   Site Map Page

   

3. View recommended patches results.

   From the home page, click the Details icon for an item in the Results section.

   Recommended Patches Results Page

   

   The Recommended Patches Results page for the recommended patch request appears.

   Recommended Patches Results Page

   

4. Access the Patch Impact Analysis page.

   Clicking the Impact icon in the Recommended Patches Results page opens the Patch Impact Analysis page for the selected patch.

   Patch Impact Analysis Page

   

   Many of the line items on this page are links to detailed information about the impact of the patch on the system. For example, the File Types Installed value is a link to a page that lists the file types and the number of unchanged, changed, and new files in the file system as a result of applying the selected patch.

Creating Patch Recommendations Without an Internet Connection

Requirement: How do I use the features of creating patch recommendations if I do not have access to an Internet connection?

You can run Patch Wizard without access to an Internet connection, if necessary, by downloading the Patch Information Bundle to a system which has Internet access. Once the download is complete, copy the Patch Information Bundle file to the Patch Wizard's staging directory. Then run Patch Wizard as you normally would based on the files you copied to the staging directory.

To create recommendations without using an Internet connection

1. Download the Patch Information Bundle to a system which has Internet access.

2. Set up a staging directory on a system that does not have Internet access. Patch Wizard must be able to read from and write to this staging directory.

3. Copy the Patch Information Bundle zip file to the staging directory. The zip file must be copied to a system that can access the Patch Wizard staging directory. If the staging directory is on a local disk, the zip file must be copied to the system where you run Patch Wizard. If the staging directory is on a shared (network) disk, it can be copied to any system with access to the shared disk.

4. Run Create Recommendations as you normally would from this point.

Analyzing Applied Patches

As you apply patches, AutoPatch records the actions in the Oracle E-Business Suite patch history database. You can query this database using the Oracle Applications Manager (OAM) Applied Patches feature, which provides easy access to reports based on your search criteria.

Note: Patch information s is not stored in the database if the patch is applied in pre-install mode or test mode. Also, if patch application does not run successfully to completion, the associated information is neither uploaded to the patch history database nor available in the Applied Patches feature.

You enter search criteria on a search patches page, either Simple Search or Advanced Search. A summary report is displayed at the bottom of the search page.

Several detailed reports are also available, including Timing Details, Files Copied, Bug Fixes, and Action Summary. Most of these detailed reports have a standard layout. The top portion displays the criteria that were used for the search, and the bottom portion displays the results of the search.

See also Applied Patches in the OAM Help system.

Determining If a Patch Was Applied

Requirement: Can I determine if a specific patch has been applied to my Oracle E-Business Suite system?

To determine which patches were applied, enter a patch ID in the Applied Patch Check area of the Software Updates page. You can perform a simple search by entering an ID or a series of IDs separated by commas.

To determine if a patch was applied

1. Access Oracle Applications Manager.

   Follow the instructions in Accessing Patch Wizard to access OAM.

2. Access the Software Updates page.

   From the Applications Dashboard, click the Software Updates tab. The Software Updates page appears.

   Software Updates Page

   

3. Enter a patch ID.

   In the Applied Patch Check area of the Software Updates page, enter a patch ID or a series of IDs separated by commas. Your queried ID appears in the corresponding column depending on whether it has been applied.

Searching for Patch Details

Requirement: What information is available on the Patch Details report? How do I create the report?

From any Patch Summary report, you can click the Details icon for a selected row to open the Patch Details report, which displays summary information carried over from the Results portion of either the Simple Search or Advanced Search page.

This report also contains more specific information about the patch, including:

• Name of the driver file and the date and time it was applied

• Command line options used to run the file

• Platform of the driver file

• Location where the driver was run

• Report on whether a codelevel was introduced, and if so, which one

From the Patch Details page, you can also access additional information about a patch, including timing details, files copied, bug fixes, and a summary of actions performed.

See: Applied Patches. See also Applied Patches in the OAM Help.

To review patch details

1. Access Oracle Applications Manager.

   Follow the instructions in Accessing Patch Wizard to access OAM.

2. Create a Patch Summary report.

   From the Site Map (Maintenance tab), click Applied Patches under the Patching and Utilities heading. From either the Simple Search or Advanced Search page, enter a patch number or a date range to create a Patch Summary report. Click Go.

3. Select the patch.

   Click the Details icon in any selected row of the Patch Summary report. The Patch Details report appears.

   Patch Details Report

   

   The report displays patch details such as driver files, start and end dates, and platform. It also provides access to other patch details related to the driver files, such as files copied and bug fixes. You can select a driver from the list, and click one of the additional detail buttons to see other reports.

4. View additional details.

   As an example of the details that are available for a selected driver, click Files Copied.

   Files Copied Report

   

   For each file, the Files Copied report shows the product short name, the directory where the file was copied, the name of the file, and the version number. To view other information associated with the driver file, click the Patch Details link at the top of the page to return to the previous page.

   As another example, click the Bug Fixes button.

   Bug Fixes Report

   

   The Bug Fixes report lists all bug fixes included in the selected driver file. It contains the bug number, the associated product, and whether the bug fix was applied. If the fix was not applied, the Remarks column explains why.

5. View the Action Summary report.

   You can create a report that summarizes the actions of a selected driver file. Click the Patch Details link at the top of the page to return to the Patch Details page. (You can also access the Action Summary report by clicking the bug fix number on the Bug Fixes report.)

   From the Patch Details page, select a driver and click the Action Summary button.

   Action Summary Report

   

   The Action Summary report shows more information about the driver and its actions. For definitions of the column headings, see Action Summary.

   If the driver selected contains a database portion, the Patch Summary report shows the driver actions, such as sql and exec. If the driver performed actions on the database, the Details icon is active. Click it to see the Action Details report.

Searching for Translation Patches

Requirement: My Oracle E-Business Suite system operates in multiple languages. I want to make sure translation patches have been applied successfully.

If a patch has an associated translation patch, you apply the translation patch separately. AutoPatch stores information in the patch history database about all translation patches you apply.

To search for translation patches

1. Access the Oracle Applications Manager.

   Follow the instructions in Accessing Patch Wizard to access OAM.

2. Access the Simple Search page.

   Site Map Page

   

   From the Site Map (Maintenance tab), click Applied Patches under the Patching and Utilities heading. The Simple Search page appears.

   Enter the search criteria. For details about using the Simple Search page, see: Determining If a Patch Was Applied, or click the OAM Help button.

3. Specify the patch.

   On the Simple Search page, enter the ID of the translation patch in the Patch field. Click Go.

4. Review the Patch Summary report

   All applications of the patch are displayed. If multiple translations were applied, there will be multiple rows. The Language column shows the languages applied.

   Applied Patches Page - Simple Search

   

Viewing Applied Patches in a Report Format

Requirement: Can I review applied patches information without the OAM screens?

There may be times when you want to view applied patch history without running the Oracle Applications Manager. For example, you may need to view large amounts of data, or you may just need a list of patches without the detail provided in the OAM Patch History reports. In these cases, you can run command line scripts that list all patches applied in each AutoPatch session, all files affected by a patch, or all patches applied within a certain date range. The scripts, and a description of the reports they produce, are listed in the following table.

Patch Report Scripts

Script Name	Report Content	Output Format
adphrept.sql	Lists patches applied in individual AutoPatch sessions, and includes details.	XML
adfhrept.sql	Displays information about files changed by patches.	XML
adpchlst.sql	Lists patches applied in a given date range.	Text

The XML reports produced by adphrept.sql and adfhrept.sql can either be processed as XML or viewed as HTML.

To run a report that provides a listing of applied patches, follow the appropriate instructions in this section.

To see a list of all completed AutoPatch sessions with patch details

Run the adphrept.sql script (located in <AD_TOP>/patch/115/sql). This script produces an XML report showing individual AutoPatch sessions. If a patch was applied more than once, this report lists each application of the patch. If a merged patch was applied, it lists the merged patch by patch name. It does not list the individual patches within the merged patch.

To run adphrept.sql, use the following parameters:

<query_depth> <bug_number or ALL> <bug_product or ALL> \
<start_date_from (mm/dd/rr or ALL)> <end_date_to (mm/dd/yyyy or ALL)> \
<patchname/ALL> <patchtype/ALL> <level/ALL> <language/ALL> \
<appltop/ALL> <limit to forms server? (Y/N)> \
<limit to web server? (Y/N)> \
<limit to node server? (Y/N)> \
<limit to admin server? (Y/N)> \
<only patches that change DB? (Y/N)> <report_name>.xml

For <query_depth>, specify 1 (details of patches only), 2 (details of patches and their bug fixes only), or 3 (details of patches, bug fixes, and bug actions).

At the command prompt, enter the report command and enter values for the parameters and prompts. For example, to see complete patch details for AutoPatch sessions that were run during January 2009, enter the following, using the mm/dd/yyyy date format:

UNIX:

$ cd $AD_TOP/patch/115/sql
$ sqlplus <APPS username>/<APPS password> \
@adphrept.sql 3 ALL ALL 01/01/2009 01/31/2009 \
ALL ALL ALL ALL ALL N N N N N jan09.xml

Windows:

C:>\ cd %AD_TOP%\patch\115\sql
C:>\ sqlplus <APPS username>/<APPS password> @adphrept.sql 3 ALL ALL 01/01/2009 01/31/2009 ALL ALL ALL ALL ALL N N N N N jan09.xml

The <AD_TOP>/html directory contains the adpchrep.xsl style sheet for displaying the XML output file in HTML format. To view the XML file as HTML, copy both the adpchrep.xsl style sheet and XML output report to a directory accessible by a browser. Open the directory in your browser and click the XML filename.

To display information about files changed by patches

Run the adfhrept.sql script (located in <AD_TOP>/patch/115/sql) to produce an XML report named adfilerep.xml. Use the following parameters:

<filename> <latest file version only? (Y/N) \
<start_date (mm/dd/rr or ALL)> <end_date (mm/dd/yyyy or ALL)> \
<patchtype/ALL> <language/ALL> \
<appltop/ALL> <limit to forms server? (Y/N)> \
<limit to web server? (Y/N)> \
<only patches that change DB? (Y/N)>

At the command prompt, enter the report command and enter values for the parameters and prompts. For example, to see the complete file version history for admorgb.pls considering only patches applied in January 2008, enter the following, using mm/dd/yyyy format:

UNIX:

$ cd $AD_TOP/patch/115/sql
$ sqlplus <APPS username>/<APPS password> \
@adfhrept.sql admorgb.pls N 01/01/2008 01/31/2008 \
ALL ALL ALL N N N N N

Windows:

C:>\ cd %AD_TOP%\patch\115\sql
C:>\ sqlplus <APPS username>/<APPS password> @adfhrept.sql admorgb.pls  N 01/01/2008 01/31/2008 ALL ALL ALL N N N N N

The <AD_TOP>/html directory contains the adfilerep.xsl style sheet for displaying the XML output file in HTML format. To view the XML file as HTML, copy both the adfilerep.xsl style sheet and XML output report to a directory accessible by a browser. Open the directory in your browser and click on the XML filename.

To see a list of all patches in a given date range

The adpchlst.sql report (located in <AD_TOP>/patch/115/sql) produces a list (adpchlst.lst) of all patches in a date range, without patch detail. It differs from adphrept.sql in two ways: it lists a patch only once regardless of how many times it was applied, and it lists individual patches included within a merged patch. For example, if you combine patches 123, 124, and 125 in a merged patch called merged1, the report lists patches 123, 124, and 125, but not merged1.

At the command prompt, enter the report command and enter the date parameters in mm/dd/yyyy format. For example, to see a list of patches applied in October 2008, enter the following:

UNIX:

$ cd $AD_TOP/patch/115/sql
$ sqlplus <APPS username>/<APPS password> \
@adpchlst.sql 10/01/2008 10/31/2008

Windows:

C:>\ cd %AD_TOP%\patch\115\sql
C:>\ sqlplus <APPS username>/<APPS password> @adpchlst.sql 10/01/2008 10/31/2008

Monitoring Patches in Progress

Requirement: Can I monitor the progress of a patch while it is being applied?

Depending on the size and complexity of a patch, it may take from several minutes to several hours to completely apply it to your system. It is useful to know what a patch is currently doing and how long individual steps are taking.

When applying patches, the Oracle E-Business Suite system is in Maintenance mode and the application tier services, including the Web server, are shut down. This prevents access to Oracle E-Business Suite and Oracle Applications Manager. In order to access the Timing Reports to track an in-progress patching session, the Web server must be started in restricted mode and OAM accessed through a restricted mode URL.

When using Timing Reports to track an in-progress patching session, the timing report displays the most recently performed tasks. Use the Refresh icon to get the latest running tasks.

To monitor patches in progress

1. Set up the ad_monitor user account. Use the ad_monitor user account to log in to OAM in restricted mode.

   • Log in to SQL*Plus as SYSTEM.

   • Unlock the ad_monitor user.

     SQL> alter user ad_monitor account unlock;
     

   • Log in to SQL*Plus as the ad_monitor user and reset the password. The default password is 'lizard'.

2. Shut down all application tier services.

3. Enable Maintenance mode.

4. Start the Web server in restricted mode. The script to start and stop this service is in the $COMMON_TOP/admin/scripts/<CONTEXT_NAME> directory.

   UNIX:

   $ adaprstctl.sh start
   

   Windows:

   C:\> adaprstctl.cmd start
   

5. Run AutoPatch to start the patch session.

6. Access OAM through the restricted mode URL:

   <host>:<port>/servlets/weboamLocal/oam/oamLogin
   

7. Log in to OAM as the ad_monitor user.

8. Navigate to the Timing Reports (Navigation: Sitemap > Maintenance > Patching and Utilities > Timing Reports).

   See: Timing Reports.

9. When the patching session is complete, shut down the restricted mode Web server.

   UNIX:

   $ adaprstctl.sh stop
   

   Windows:

   C:\> adaprstctl.cmd stop
   

10. Disable Maintenance mode.

11. Restart all services.

You can also monitor the progress of the patching process by reviewing:

• AutoPatch messages

  As AutoPatch runs, it displays messages on the screen about the status and progress of the patching process.

• Patch log files

  AutoPatch creates log files in the current directory. Each log file contains information about completed patching actions. See: Log and Restart Files, Oracle E-Business Suite Maintenance Utilities.

• Worker status

  For jobs run in parallel, use AD Controller to view the status of the concurrent manager and workers assigned to process jobs. See: Reviewing Worker Status, Oracle E-Business Suite Maintenance Procedures and AD Controller, Oracle E-Business Suite Maintenance Utilities.

Analyzing Patches Without an Internet Connection

Requirement: How do I analyze specific patches if I do not have access to an Internet connection?

You can run Patch Wizard to analyze specific patches without access to an Internet connection, if necessary, by downloading the patches to a system which has Internet access. Once the download is complete, copy the patches to the Patch Wizard's staging directory. Then run Patch Wizard as you normally would based on the files you copied to the staging directory.

To analyze specific patches without using an Internet connection

1. Download the patch zip file(s) to a system which has Internet access.

2. Set up a staging directory on a system that does not have Internet access. Patch Wizard must be able to read from and write to this staging directory.

3. Copy the patch zip file(s) to the <staging directory>/ad directory, if the downloaded patch is an AD product patch. Otherwise, copy the patch zip file(s) to <staging directory>/nonad directory. The zip file(s) must be copied to a system that can access the Patch Wizard staging directory. If the staging directory is on a local disk, the zip file(s) must be copied to the system where you run Patch Wizard. If the staging directory is on a shared (network) disk, it can be copied to any system with access to the shared disk.

4. Run Analyze Specific Patches as you normally would from this point.

Backing Out Patches

Although you can back out patches that you have applied to your Oracle E-Business Suite system and restore it to its pre-patched state, Oracle recommends you use this course of action only if you have no other choice.

Note: There is no automated method of backing out patches.

Restoring from a Failed Copy Section of a Unified Driver

Requirement: The copy portion of a unified driver failed during a patching procedure. I need to restore my system.

You should always test the application of a patch several times on a test system, particularly if the patch is a release update pack (RUP), product family RUP, or pre-upgrade patch. After the test application is successful, apply the patch on the production system.

Before applying a large number of patches, a release update pack (RUP), product family RUP, or a pre-upgrade patch, back up the Oracle E-Business Suite file system and database.

To restore from a failed copy section of a unified driver

1. Determine the cause of the failure.

   In many cases, the issue can be resolved and the patching process restarted at the point of failure.

2. Determine the actions of the copy portion of a unified driver.

   If there is no feasible method of resolving the issue, review the log files and the copy portion of a unified driver to determine the files copied by the patch and the update actions performed.

3. Restore files.

   If a file in the patch top directory is a more recent version than the product's current file, AutoPatch backs up the current file into a subdirectory of the patch top directory. If <patches> is the patch top directory, <system_name> is the Applications system name, <APPL_TOP_name> is the APPL_TOP name, and <prod> is the name of the product being patched, AutoPatch backs up:

   <PROD>_TOP/<subdir(s)>/<old_file_name> 
   

   to

   <patches>/backup/<system_name>/<appl_top_name>/<prod>/<subdir(s)>/<old_file_name>
   

   Note: The Oracle E-Business Suite system name and the APPL_TOP name are determined when you run Rapid Install.

   Use these backup files to restore the files on the Oracle E-Business Suite system. If the patch is large and you copied many files, restore the entire file system with the backup you created before you applied the patch. If you restore the entire file system you do not have to perform Steps 4 through to 7.

4. Relink files.

   If the copy portion of the unified driver includes actions to relink files, determine the files affected and relink them using AD Administration or, for AD programs, use AD Relink. See: Oracle E-Business Suite Maintenance Utilities.

5. Restore Java files.

   If the patch included Java updates, restore the Oracle E-Business Suite Java files by running the following command from the <patches>/backup/ <system_name>/<appl_top_name> directory.

   $ adjava -mx256m oracle.apps.ad.jri.adjcopy @undoScript.cmd
   

6. Generate JAR files.

   If Java files are included in the patch, generate JAR files using AD Administration. See: AD Administration, Oracle E-Business Suite Maintenance Utilities.

7. Generate other files.

   If there are forms, reports, graphics, or message files included in the patch, generate these files using AD Administration. See: Managing Files, Oracle E-Business Suite Maintenance Procedures.

Restoring from a Failed Database Portion of a Unified Driver

Requirement: Can I restore my system after a failed database portion of a unified driver?

There is no general method of backing out changes a patch makes to the Oracle E-Business Suite database. To avoid the need to restore a database, you should always test the application of a patch several times on a test system, particularly if the patch is a release update pack, product family release update pack, or pre-upgrade patch. After the test application is successful, apply the patch on the production system.

For more information, see: Changing Maintenance Mode, Oracle E-Business Suite Maintenance Utilities.