Oracle EBS Patching 12.0 and 12.1

Patching Concepts

Throughout the course of the Oracle Applications life cycle, patches are applied for a number of reasons, including:

• Updating to a higher maintenance level
• Applying the latest product enhancements
• Adding a new feature or functionality
• Fixing an existing issue

Depending on the type of patch, it may update the file system, or the database, or both.

Patch Types

Patches are defined by type and by format. The patch type describes the purpose of the patch. For example, a patch may add product functionality, or it may fix an existing issue. There are several types of patches that you may be asked to apply to your Oracle Applications system. They are described in the following table

Patch Type	Description
Bug fix	Fixes an existing issue.
New feature	Adds new functionality.
Interoperability	Contains Oracle Applications files and database objects to make the current version of Oracle Applications compatible with a newer version of the database or a technology stack component. For example, to enable an Oracle 11g database to work with Oracle Applications Release 12.
Diagnostic	Released specifically to determine the source of an issue. A diagnostic patch does not contain fixes.
Translation	Contains Oracle Applications files that have been translated from English to another language. A translation patch may also run tasks to load or update data in the database.
Performance	Fixes a problem with, or improves the performance of, an upgrade from a previous major release, such as 11.5.9 to 12.
Documentation	Updates Oracle Applications Online Help. When applying a product minipack or a stand-alone patch that adds a new feature, review the Features Summary Matrices on OracleMetaLink for the associated documentation patch.

Patch Formats

Patch format describes the way the patch is packaged and applied. For example, a stand-alone patch focuses on a single, specific issue, while a minipack is a merged patch that consolidates all patches for a specific product for a specific period of time.

Patches are released in the following formats. If a patch format is described as cumulative, that patch contains a consolidation of updates from the inception of Release 12, up to, and including, the latest release level

Patches	Description
Stand-alone	A patch that fixes a specific issue or provides new functionality.
High-priority	A patch identified by Oracle as having an impact that is broad enough to merit application by all customers who have installed the affected product.
Rollup	An aggregation of patches that may be at a specific product or family release level.
Minipack	A consolidation of all patches for a product that upgrades the product to a new codelevel. The naming convention is R12.<product>.<codeline> such as R12.AD.A. Minipacks with a higher <codeline> supersede previous versions. They are cumulative.
Family pack	A consolidation of a set of minipacks and other patches for a product family. Family packs with a higher number supersede previous versions. They are cumulative.
Consolidated Update (CU)	An update containing generally recommended patches and additional targeted patches combined into a single patch. Applying a consolidated update brings a release to the latest recommended patch level. For example, R12 CU2.
Family consolidated upgrade patch	All upgrade-related, high-priority patches consolidated from all the products within a product family. Family consolidated upgrade patches are released as needed. The Oracle Applications Release Notes lists the most recent family consolidated upgrade patches.
Maintenance pack	A consolidation of all minipacks for all products. A maintenance pack updates a system to a new point release of Oracle Applications, such as from release 11.5.10 to 12. Maintenance packs with a higher number supersede previous versions. They are cumulative.

Patch File Structure

Patches generally consist of a top-level directory, several files in the top-level directory, and one or more subdirectories. The top-level directory is named <patchnum>, where <patchnum> is the number of the patch. The most important files in the top-level directory are: README.txt, README.html and the u<patchnum>.drv driver file. For most patches, applying the patch driver file is the only action required.

The README.txt or README.html file for each patch describes what the patch does, and how to generate customized installation instructions for applying the patch.

Patch Driver File

The unified driver contains the commands necessary to change files and database objects, and to generate new objects.

Unified Driver

The unified driver now contains copy, database, and generate portions in a single driver file. It is named u<patchnum>.drv. Run the unified driver on all APPL_TOPs and AutoPatch runs only the actions that are required for the current APPL_TOP.

Copy Portion of a Unified Driver

When the copy portion of a unified driver runs, AutoPatch performs the following actions:

• Extracts the appropriate files from the C library of each product.
• Compares the extracted object modules with their corresponding files in the patch directory. It also makes this type of comparison with files such as forms, reports, and SQL scripts.
• Backs up any product file with a more recent version in the patch directory to a subdirectory in the patch directory. For example, if <patch_dir> is the patch 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, it

backs up: <PROD>_TOP/<subdir(s)>/<old_file_name>

to

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

• Replaces the outdated files of each product with newer files from the patch directory.
• Loads the new object modules into the C libraries.
• Relinks the Oracle Applications products with the operating system, Oracle server, and other Oracle products libraries.
• Applies changed Java class files and regenerates JAR files as needed.
• Copies any specified HTML or media files to their respective destinations.
• Compiles out-of-date Java Server Page (JSP) files (if any JSP files are included in the patch).

Database Portion of a Unified Driver

When the database portion of a driver runs, AutoPatch performs these actions:

• Gets a list of current invalid objects in the APPS schema.
• Determines whether the action was performed in a previous patch.
• Runs SQL scripts and EXEC commands, which change Oracle Applications database objects. By default, AutoPatch runs scripts and commands in parallel.
• Compiles invalid objects in the database.
• Assembles a list of current invalid objects in the APPS schema.

Generate Portion of a Unified Driver

Apply the generate portion of a unified driver on all APPL_TOP directories containing one or more files being generated by the patch. If in doubt, apply it to all APPL_TOP directories on all nodes. When the generate portion of a driver runs, AutoPatch performs these actions:

• Generates Oracle Forms PL/SQL library files.
• Generates Oracle Forms menu files.
• Generates Oracle Forms executable files.
• Generates Oracle Reports PL/SQL library files.
• Generates Oracle Reports files.
• Generates message files.
• Generates Oracle Workflow resource files.

Patching Utilities

Patches are applied and tracked as needed by using one of the utilities designed specifically for that purpose. The following utilities are run from the command line.

AutoPatch

AutoPatch is the utility used to apply all patches to the Oracle Applications file system or database.

Use AutoPatch to apply patches to the Oracle Applications file system or database. It gathers necessary information about your system through a series of prompts. When you have completed the prompts, AutoPatch performs all the tasks required to apply the patch, including the following:

• Reads patch metadata to determine patch dependencies and requirements.
• Uploads patch information from a prior patch session to the database (if needed).
• Reads and validates the patch driver file and reads the product driver files.
• Compares version numbers of object modules from the product libraries and version numbers of the existing files against the patch files.
• Backs up all existing files that will be changed by the patch.
• Copies files.
• Archives files in libraries.
• Relinks executables.
• Generates forms, reports, message, graphics, and Java archive (JAR) files.
• Compiles JSP files and invalid database objects.
• Updates database objects.
• Runs AutoConfig to update configuration files, if any template files are introduced or updated by the patch.
• Saves patch information to the database.

AutoPatch takes no action if a patch contains no new updates to files or database objects in your system. If AutoPatch detects that there is a previously failed AutoPatch session, it will attempt to recover that session.

Preparing your System for Patching

Before you begin a patching session, there are some important tasks you need to complete.

Enable Maintenance Mode

Before you initiate an AutoPatch session, you must shut down the Workflow Business Events System and set up function security so that no Oracle Applications functions are available to users. This ensures optimal performance and reduces downtime when applying a patch. Maintenance mode provides a clear separation between normal runtime operation of Oracle Applications and system downtime for maintenance.

During a maintenance mode downtime, user login is restricted. Users are redirected to a system downtime URL, which informs them that the maintenance session is in progress. The Oracle Applications Manager (OAM) Maintenance Mode page allows you to schedule system downtime and send alert messages to notify users of the downtime schedule.

To enable or disable maintenance mode, use the Change Maintenance Mode menu in AD Administration.

Shut Down Services

If you are applying a patch that updates or relinks files, shut down the corresponding concurrent manager, Web server listeners, or forms server listeners. For example, if the files are on the node that contains the concurrent processing server, shut down the concurrent managers.

Log Files

In addition to the main log file (adpatch.log), AutoPatch also creates several other log files for specific purposes, for example, to record all the actions associated with parallel workers. The log files are written to $APPL_TOP/admin/<SID>/log (UNIX), where <SID> is the value of your ORACLE_SID or TWO_TASK variable, or in %APPL_TOP%\admin \<SID>\log (Windows), where <SID> is the value of ORACLE_SID or LOCAL. Review these files when the AutoPatch session is complete.

The log directory contains adpatch.log and adpatch.lgi, and may contain one or more additional files as described in the following table. If AutoPatch does not perform an action, it does not generate the log file associated with that type of action.

Log File	Description
adpatch.lgi	for AutoPatch informational messages (default name)
adrelink.log	for relinking
adlibin.log	for moving C object files into the C library of a product
adlibout.log	for moving C object files out of the C library of a product
adworkxxx.log	for database operations run in parallel
<language>_<filename>_ldt.log	for seed data loader files

Prompts

In addition to the standard prompts common to most AD utilities, AutoPatch also asks for information specific to the patching process. You must respond to all the prompts for each driver you run.

Main Log File Name

The main AutoPatch log file is named adpatch.log by default. We recommend you change the name to indicate the associated driver file, using a .log extension. For example, for the u1234567.drv driver, the log file should be u1234567.log.

SYSTEM and AOL User Passwords

AutoPatch prompts for the SYSTEM and AOL user passwords.

Patch Directory

AutoPatch asks you to specify the directory where the patch files have been unzipped. The default is the directory from which you started AutoPatch. If necessary, specify the full path name to the directory where you unzipped the patch files. The operating system user running AutoPatch must have write permissions to that directory.

Patch Driver File

AutoPatch prompts for the name of the patch driver file. By default, it does not check the integrity of the patch — whether the version of each file referenced in a driver file copy action matches the version present in the patch — as Oracle Applications patches are tested to ensure they contain the correct files before they are released.

Number of Parallel Workers

By default, AutoPatch runs database updates and file generation commands in parallel and prompts you for the number of workers. Tasks are assigned to workers, the workers run the tasks to completion, and AutoPatch assigns new tasks.

The default value for the number of workers is two times the number of CPUs on the node from which you run AutoPatch. Oracle recommends specifying 2 to 4 times the number of workers as CPUs.

After you specify the number of workers, AutoPatch displays messages like the following as it begins to update the Oracle Applications products:

Performing version checking for driver files...

Copying driver files into installation area...

Determining valid on-site files...

Screening out files not valid for this installation...

Extracting object modules from product libraries...

Performing version checking...

Determining what executables to link...

Determining what Oracle Forms files to generate...

Determining what Oracle Reports libraries to generate...

Determining what Oracle Reports files to generate...

Customized Files

AutoPatch reviews the AD_FILES table to determine if any customized files (Registered Flagged Files) will be replaced by the patch. If so, it displays a message listing the customized files it will replace.

NLS

If the patch you are applying has an NLS-related version, and if you are an NLS customer, AutoPatch prompts you about the NLS-related version of the patch before allowing you to continue.

  

Successful Completion Message

AutoPatch displays messages like the following when processing is complete. If you do not see a completion message, investigate the reason why. A job timing report has been generated for the current session.

You should check the file

/slot03/appmgr/prodappl/admin/PROD/out/adt323790.lst for details.

Purging timing information for prior sessions.

sqlplus -s APPS/***** @/slot03/appmgr/prodappl/ad/12.0.0/sql/adtpurge.sql 10 1000

Done purging timing information for prior sessions.

AutoPatch is complete.

AutoPatch may have written informational messages to the file

/slot03/appmgr/prodappl/admin/PROD/log/adpatch.lgi

Errors and warnings are listed in the log file

/slot03/appmgr/prodappl/admin/PROD/log/adpatch.log and in other log files in the same directory.

Backup Directory

When AutoPatch runs, a backup directory is created in the directory where you unzip the patch. The old version of each file updated by the patch is copied into the backup directory. When applying large patches (like minipacks, family packs, and maintenance packs), ensure there is enough disk space on the system where you unzip the patch, or the patching process might fail. Oracle recommends having at least twice the amount of disk space as the unzipped patch file.

Periodically, you can delete the files in the backup directory to free up space.

The AutoPatch Interface

Run AutoPatch from the command line. It relies on prompts for information, not input screens.

Running AutoPatch

Perform the following steps to start AutoPatch

.

Step 1 Set the environment

You must set the environment to apply the configuration parameters that define your system. This task is common to many AD utilities.

Step 2 Unzip the patch

Create a patch top directory, if it does not already exist. Download the patch into the patch top directory and unzip it.

Step 3 Review the information in the README file

In the directory where you unzipped the patch, you will find a README.txt file and a README.html file. Review either README file for information about the patch and for instructions on running the admsi.pl script.

Step 4 Run the admsi.pl script

Run the admsi.pl script to generate customized installation instructions for the patch. Follow the steps in the customized installation instructions to complete the patching process.

Applying a Patch Interactively

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

Patches may require prerequisite patches and manual steps. Run the admsi.pl script to generate customized installation instructions for the patch. These instructions contain all the required manual steps.

Steps

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. To set the environment:

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

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), located in the directory where you unzipped the patch. The README contains an abstract of the patch and instructions for running the admsi.pl script.

5.  Run the admsi.pl script to generate customized installation instructions for applying the patch. You will need to provide the location of your patch top directory and the applmgr password.

Run admsi.pl with the proper parameter values as follows -

cd $AD_TOP/bin

perl admsi.pl -patch_top=<patch-top-directory> -appspass=<apps-password>

For example,

perl admsi.pl -patch_top=/u01/apps/patches/3636980 -appspass=apps

The following general steps are contained in the customized installation instructions generated by the admsi.pl script. Additional steps are also detailed in the customized installation instructions depending on the patch, the state of your system, and the products you have installed.

Use the following steps, in addition to the steps detailed in the customized installation 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.

$ adstpall.sh

7.  Enable Maintenance Mode.

Use the Change Maintenance Mode menu of AD Administration to enable maintenance mode. Select option 1 to 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).

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

• APPL_TOP name 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, the 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.

When AutoPatch prompts for the driver name, specify the name of the driver.

11.  Review customizations.

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

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 is located in <APPL_TOP>/admin/<SID>/log. This is the file you named u<patchnum>.log in step 9. 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.

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

If AutoPatch has modified Oracle Applications 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.

14.  Disable Maintenance Mode.

Use the Change Maintenance Mode menu of AD Administration to disable maintenance mode. Select option 2 to disable maintenance mode.

15. Restart server processes.

After verifying that the patch was applied successfully, start all server processes and allow users to access the system.

$ adstrtal.sh

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.

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 RDBMS.

You can maintain the APPL_TOPs separately, or you can configure your system to share an APPL_TOP. 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. Any changes made to a shared file system are immediately available on all nodes.

Steps

Apply the unified driver as follows:

1. Complete Steps 1 – 9 in the previous section.
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
7. Start other services and restart Web server, if necessary

Please Subscribe my blog Qamar Zahoor, YouTube Channel YouTube, Join the Facebook group

Facebook Group and do follow on Twitter Twitter to get knowledge of Oracle EBS, Database, Ecommerce, Amazon, Ebay and Digital Marketing. Keep learning.