Oracle Apps Patching Steps

Before explaining oracle apps patching steps lets first discuss online patching. Online patching uses the latest feature of the Oracle database 11gR2 which is called “Edition-Based Redefinition” and also uses multiple file systems on the application side.

During online patching, business application users continue using the Oracle application and simultaneously a patch or a sequence of patches can be applied to another edition of the same database and application.

Another edition here means another exact copy of database and application. And once the patching is complete the users are switched over to a patched file system/database in cutover phase by just bouncing middle tier services.

File System

An R12.2.0 is installed with three file Systems.

1.FS1 – Production file system that is used by application users when the system is being patched.

2.FS2 – Exact copy of production used by the patching tool. This copy is patched by the patching tool.

It gets synchronized with FS1 by the patching tool before it gets updated by a patch. When patching is complete, the patching tool swaps the FS1 and FS2 file systems. FS2 file system becomes FS1 and FS1 is switched to FS2. This way, FS2 is again ready to be used for any future patching tasks.

3.FS-NE – This is a non-edition file system which stores data that is stored in a file system like data import/export files, report out and log files.

Phases of ADOP (online patching)

ADPATCH utility is no longer used in R12.2.0 and is being replaced by ADOP – AD Online Patching. There are five phases or life cycles of ADOP which are:

a) PREPARE
b) APPLY
c) FINALIZE
d) CUTOVER
e) CLEANUP

 

 

 

Oracle Apps Patching Steps Explanation :

 

 

1. In Oracle Apps R 12.2 onwards all patching operations are online ( EBS system remains available to users during patching) unlike previous versions where system is unavailable during patching (Maintenance Mode)

2. Online Patching uses Edition Based Redefinition (EBR) at Database Layer and Multiple File System at the Application Tier level

3. Edition Based Re-Definition provides two copies of the Database object (schema) pre and post patch.

a) Run Edition of database objects: used by online users and is not changed by patching

b) Patch Edition of database objects: used by patching tool and do not affect the running application

Note: There is third edition (zero or more editions) called Old Edition – Patch Edition when prompted to Production i.e. new Run Edition, previous Run Edition is marked as Old Edition. Full Cleanup Operation (part of ADOP) removes Old Edition (More on Cleanup Operation later)

4. In Oracle Applications 12.2 there are two file system

a) FS1: Production File System used by users

b) FS2: Copy of production File System used by patching tools (adop: More on adop later)

Note: FS1 and FS2 can switch role i.e. FS2 will become production File system and FS1 will become File System for Patching at Cutover Phase of online patching (ADOP).More on various phases in AD Online Patching (adop) later.

Note: Third files system fs_ne stores data on file system like a log, out, data import/export files

5. Patches are applied to copy of production environment (copy of the code and NOT data) whereas users access the original production environment (Patching applied is to file system and Patch Edition of database objects and not applicable to transactions tables/data in database)

6. Actual downtime during patching (ADOP) is to switch users from pre-patched copy to patched copy.

7. Online Patching Tool ADOP (AD Online Patching) now replaces adpatch in 12.2

8. Phases on ADOP (replacement of ADPATCH) are

Prepare -> Apply -> Finalize -> Cutover -> Cleanup (more on these phases later)

9. Patching can be aborted any time before Cutover Phase

Online Patching (ADOP) in Oracle EBS R12.2

Online patching is supported by the capability of storing multiple application editions in the database, and the provision of a dual application tier file system. At any given point in time, one of these file systems is designated as run (part of the running system) and the other as a patch (either being patched or awaiting the start of the next patching cycle).

Main Oracle Apps Patching Steps are:

For applying a patch in R12.2 you need to use adop and run through all below phases in the sequence mentioned below.

1.  Firstly,adop phase=prepare
2.  Secondly, adop phase=apply patches=, workers=
3.  adop phase=finalize workers= (called automatically)
4.  Then adop phase=cutover workers=
5.  adop phase=cleanup (called automatically)
   OR
   Running all phases in single command:
   adop phase=prepare,apply,finalize,cutover,cleanup patches=,

DESCRIPTION OF EACH PHASE

1) PREPARE PHASE DETAILS

Used to start a new online patching cycle

How to execute:

A) Set the environment by executing (sourcing) the run file system environment file: $ source /EBSapps.env run B) Verify environment You can confirm that the environment is properly set by examining the relevant environment variables:
$ echo $FILE_EDITION run
$ echo $TWO_TASK dbSID

C) Download Patches

Download patches to be applied and place then in the $PATCH_TOP directory of your system. This directory is pre-created by the install in the non-editioned file system (fs_ne) and should not be changed.

Important: On a multi-node system with non-shared file systems, you must copy the patch files to each separate $PATCH_TOP directory, so that the patch files are available from the same location on all nodes. D) Unzip the patch

$ unzip .zip

E) Run Prepare Command

Prepare the system for patching by running the following command to start a new patching cycle:

$ adop phase=prepare

What it will do:

• Checks whether to perform a cleanup, which will be needed if the user failed to invoke cleanup after the cutover phase of a previous online patching cycle.
• Checks the integrity of the database data dictionary. If any corruption is found, adop exits with an error.
• Checks system configuration on each application tier node. A number of critical settings are validated to ensure that each application tier node is correctly registered, configured, and ready for patching.
• Checks for the existence of the “Online Patching In Progress” (ADZDPATCH) concurrent program.
• This program prevents certain predefined concurrent programs from being started, and as such needs to be active while a patching cycle is in progress (that is, while a database patch edition exists). If the ADZDPATCH program has not yet been requested to run, a request is submitted. Note: ADZDPATCH is canceled later on when the cutover phase is complete.
• Checks to see if the patch service has been created. adop requires that a special database service exists for the purpose of connecting to the patch edition. This service is created automatically, but its continued existence is validated on each prepare.

It can be checked by the database parameter SERVICE_NAME

SQL> show parameter service_name

Here dba is the SID of our database and ebs_patch is additional service_name which is required by online patching tool.

If you look at tnsnames.ora file in the Application tier $TNS_ADMIN directory you will find below kind of entry:
_patch= (DESCRIPTION= (ADDRESS=(PROTOCOL=tcp)(HOST=)(PORT=)) (CO NNECT_DATA= (SERVICE_NAME=ebs_patch) (INSTANCE_NAME=) ) )
During the patching phase, adop will use this tns entry to connect to the database.

• Invokes the TXK script

$AD_TOP/patch/115/bin/txkADOPPreparePhaseSynchronize.pl to synchronize the patches which have been applied to the run APPL_TOP, but not the patch APPL_TOP.

• Checks the database for the existence of a patch edition, and creates one if it does not find one.

2) APPLY PHASE DETAILS

In the apply phase, adop applies the specified patches to the system. Patches are applied to the patch edition of the database and file system.
How to execute:

Example:

$ adop phase=apply patches=1234,7891 workers=8
Where 1234 and 7891 are the patch numbers
What it will do:

If a post-installation patch step mentions any tasks that need to be performed explicitly, where they are run from depends on the type of patching:

• In a normal online patching cycle, the steps should be executed from the patch file system after the apply phase.

• If the patch is being applied in hotpatch mode or downtime mode, the steps should be executed from the run file system after the apply phase.

3) FINALIZE PHASE DETAILS

The finalize phase will be executed while the application is still online. It is used to perform any remaining processing that is needed to ensure the system is ready for the fastest possible cutover.

Used to perform the final patching operations that can

How to execute:
$ adop phase=finalize

What it will do:

• Pre-compute DDL that needs to be run at cutover.
• Compile all invalid objects.
• Validate that the system is ready for cutover. If finalize_mode=full, compute statistics for key data dictionary tables for improved performance.

VERY IMPORTANT 1: Up to this phase, you can run a special phase called abort, which will undo the changes made so far in the patching cycle. After cutover is complete, however, you cannot do this.

VERY IMPORTANT 2: In an online patching cycle, the requisite JAR files are initially stored in the $APPL_TOP/admin//out directory, and then uploaded into the database during the cutover phase. Therefore, the out directory must not be deleted at least until cutover (next phase) is complete.

4) CUTOVER PHASE DETAILS

Used to perform the transition to the patched environment. Shuts down application tier services, makes the patch edition the new run edition, and then restarts application tier services. This is the only phase the involves a brief downtime.

Important: No users should remain on the system during cutover, as there will be a short downtime period while the application tier services are restarted. Also, any third-party processes connected to the old run edition of the database should be shut down, or they will be terminated automatically.

How to execute:
$ adop phase=cutover

What it will do:

• Shut down an internal concurrent manager. The adop utility signals the internal concurrent manager to shut down but will wait for any existing concurrent requests to finish before it proceeds with cutover actions.
Note: Cutover will take longer if it has to wait for long-running concurrent processes to complete. In such a case, you can expect to see an informational message of the form: [STATEMENT] [END 2013/10/28 23:47:16] Waiting for ICM to go down if you do not want to wait for in-progress concurrent requests to finish normally, you can terminate the internal concurrent manager by executing the adcmctl.sh abort command from a different shell.

• Shut down application tier services: All application tier services are brought down. During this period, the system is unavailable to users.

• Cutover database:

Promote patch database edition to become the new run database edition, using adzdpmgr.pl script.

• Cutover file system: Promote patch file system to become the new run file system, switching the $FILE_EDITION values in the patch and run environments. The current patch APPL_TOP becomes the new run APPL_TOP, and the current run APPL_TOP becomes the new patch APPL_TOP. Terminate old database sessions: Terminate any database connections to the old run edition of the database.

• Start application tier services: Application tier services are restarted, on the new run edition. The system is now available again to users

• ADZDPATCH concurrent program is canceled when the cutover phase is complete.

5) CLEANUP PHASE DETAILS

Important: If you fail to run the cleanup phase explicitly, it will be run automatically on the next prepare cycle, but this will cause a delay in starting your next online patching cycle.

This adop phase is used to remove obsolete code and data from old editions.

How to execute:

$ adop phase=cleanup

What it will do:

• Various actions are performed during the cleanup, including dropping (removing) obsolete: Crossedition triggers, Seed data, Editioned code objects (covered objects), Indexes, Columns, Editions. Using parameter cleanup_mode:

a) cleanup_mode=quick – Performs minimum cleanup, including removal of obsolete cross-edition triggers and seed data.
Use quick cleanup when you need to start the next patching cycle as soon as possible. For example, if you want to start a new patching cycle right away, but have not yet run cleanup from the previous patching cycle, you can use quick cleanup mode to complete the essential cleanup tasks as fast as possible.

b) cleanup_mode=standard – Does the same as quick mode, and also drops (removes) obsolete editioned code objects (covered objects).
This is the default mode, so does not need to be specified.

c) cleanup_mode=full – Performs maximum cleanup, which drops all obsolete code and data from earlier editions
Use full cleanup when you want to recover the maximum amount of space in the database. If you have run a large number of patching cycles or applied a very large patch such as a roll-up, significant space may be consumed by obsolete table columns and recovered by running a full cleanup. A full cleanup should only be performed when there is no immediate need to start a new patching cycle.

THERE ARE TWO SPECIAL PHASES:

A) ABORT PHASE DETAILS
Abort PHASE is a conditional phrase. This phase cannot be specified with any other phase.
If for some reason either the prepare or apply phase failed or gave problems, you can abort the patching cycle at either of these points by running a special phase with the Command. The actions taken will be discarded (rollbacked).

IMPORTANT: This abort command is only available up to (but not including) the cutover phase. After cutover, the system is running on the new edition, and abort is no longer possible for that patching cycle. How to execute:
The command to perform this operation is:

$ adop phase=abort

What it will do:

• Firstly, confirms that there is an in-progress online patching cycle, so the abort call is therefore valid.
• Secondly, checks for the existence of a patch edition and drops one if it exists.
• Cancels the ADZDPATCH concurrent program, if it is running.
• Deletes the rows inserted for the pending session ID from the ad_adop_sessions and ad_adop_session_patches tables.

VERY IMPORTANT:

After running abort, a full cleanup must be performed. The cleanup command is: adop phase=cleanup cleanup_mode=full). This will remove any columns that were added by the patch but are no longer needed because of the abort. If they are not removed, they may cause problems in a later patching cycle.

Alternatively, you can run a combined command to abort the patching cycle and perform a full cleanup:

$ adop phase=abort,cleanup cleanup_mode=full

If any attempt was made to apply patches to the patch edition, after abort you must run the fs_clone phase (adop phase=fs_clone) to recreate the patch file system.

B) FS_CLONE PHASE DETAILS

The fs_clone phase is a command (not related to adcfgclone.pl) that is used to synchronize the patch file system with the run file system. The fs_clone phase should only be run when mentioned as part of a specifically documented procedure.

How to execute:

The fs_clone phase is run using the following command:

$ adop phase=fs_clone

What it will do:

This phase is useful if the APPL_TOPs have become very unsynchronized (meaning that there would be a large number of delta patches to apply). It is a heavyweight process, taking a backup of the entire current patch APPL_TOP and then cloning the run APPL_TOP to create a new patch APPL_TOP. As this method requires more time and disk space, it should only be used when the state of the patch file system is unknown. This command must be invoked from the run file system before the next prepare phase is run.

Note: The patch file system requires at least 25 GB of free disk space to be available for adop operations, including fs_clone. If there is insufficient free space, the adop operation will fail.

If an fs_clone operation fails, you can rerun it with the option force=yes to restart it from the beginning (with the same session ID), or force=no to restart it from the point where it failed.

IMPORTANT POINTS REGARDING ONLINE PATCHING:

1. adop utility is put under $APPL_TOP_NE/ad/bin. It is a wrapper script which calls internally the perl script $AD_TOP/bin/adzdoptl.pl which does actual work of applying the patch.

2. adop will automatically set its environment as required, but it is the user’s responsibility to set the environment correctly for any other commands that may be run. Set the run edition environment whenever executing commands that you intend to affect the run edition.
For example:

$ . /EBSapps.env run $ adstrtal.sh

Set the patch edition environment whenever you intend to execute commands that affect the patch edition. For example:
$ . /EBSapps.env patch $ sqlplus apps/apps @my_custom_patch_script.sql

3. All the phases need to be completed and you can’t skip any of these. For example, if you try to skip the prepare phase, you may get an error message like “Apply phase can only be run while in a patching cycle, i.e. after the prepare phase.”

4. After an online patching cycle is started, you should not perform any configuration changes in the run edition file system. Any that are made will not be propagated and will, therefore, be lost after cutover is complete.

5. You should not attempt to clone an Oracle E-Business Suite system while an online patching cycle is in progress.

6. The prepare, apply, and fs_clone phases all require at least 10GB of free disk space. All other phases require 1GB of free space. A warning message will be displayed if less than the needed amount is available.

7. The directories where you extracted the patches applied in a given patching cycle must be retained, in the same location and with the same contents, until the next prepare phase completes. This is also a requirement for patches applied in a hotpatch session.

8. Maintenance Mode is not needed for online patching, and so Maintenance Mode is not available in Oracle E-Business Suite Release 12.2.

ADOP ON MULTI-NODE

In a multi-node environment, one application tier node will be designated as the primary node. This is the node where the Admin Server is located, and will usually also be the node that runs Oracle HTTP Server. All other application tier nodes are designated as secondary nodes.

adop commands are invoked by a user on the primary node. Internally, adop uses Secure Shell (ssh) to automatically execute required patching actions on all secondary nodes. You must set up passwordless ssh connectivity from the primary node to all secondary nodes.

If a node unexpectedly becomes inaccessible via ssh, it will be abandoned by adop, and the appropriate further actions are taken. Consider a scenario where the adop phase=prepare command is run in a system with ten application tier nodes. The command is successful on nine nodes but fails on the tenth. In such a case, adop will identify the services enabled on nodes 1-9. If they are sufficient for Oracle E-Business Suite to continue to run normally, adop will mark node 10 as abandoned and then proceed with its patching actions. If they are not sufficient, adop will proceed no further.

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 the 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 mini pack 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 code level. The naming convention is R12.<product>.<codeline> such as R12.AD.A. Mini packs 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 of 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 of 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 a 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:

• Firstly, generates Oracle Forms PL/SQL library files.
• Secondly, generates Oracle Forms menu files.
• Then generates Oracle Forms executable files.
• After that generates Oracle Reports PL/SQL library files.
• Generates Oracle Reports files.
• Generates message files.
• At last, 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:

Tasks

• 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 the installation area…

Determining valid on-site files…

Screening out files not valid for this installation…

Extracting object modules from product libraries…

Performing version checking…

Determine what executables to link…

Determining what Oracle Forms files to generate…

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

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.

• 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

• Firstly, create a patch top directory, if it does not already exist. So download the patch into a staging directory and unzip the patch into the patch top directory. Then do not use the patch subdirectory under the <PROD>_TOP directories as your patch top directory.
• Secondly, change directory to the patch top directory where you unzipped the patch.
• So, 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.
• At last 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

So the following general steps are contained in the customized installation instructions generated by the admsi.pl script. Therefore 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.

• 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

• Enable Maintenance Mode.

Use the Change Maintenance Mode menu of AD Administration to enable maintenance mode. Select option 1 to enable maintenance mode.

• Start AutoPatch.

Use the adpatch command to start AutoPatch from the patch top directory (the directory where you downloaded the patch files).

• Respond to the AutoPatch prompts:
  • Firstly, APPL_TOP name where you want to apply the patch.
  • Secondly, Log file name: Select a name for the log file, for example, u<patchnum>.log.
  • So, Email where you want to receive notifications.
  • So, Batch size, the default is 1000.
  • Then Database name.
  • Therefore, Patch top directory where you unzipped the patch.
  • So driver file name: Provide the name of the driver file located in the patch top directory, for example, u<patchnum>.drv.

• Apply the driver.

1.  

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

• Review customizations.

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

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

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

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

• Disable Maintenance Mode.

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

• Restart server processes.

After verification of patch, installation start all server processes and allow users to access the system.

$ adstrtal.sh

• 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

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

So 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. Firstly, complete Steps 1 – 9 in the previous section.
2. Then apply the unified driver on the node where the administration server is located.
3. After that apply the unified driver on the node where the concurrent processing server is located.
4. Then start the concurrent managers.
5. So apply the unified driver on the remaining nodes in the application tier.
6. Then disable Maintenance Mode. Use the Change Maintenance Mode menu of AD Administration to disable
7. At last, start other services and restart the Web server, if necessary

So please do not forget to share knowledge, share this on your social network. Hope you subscribe for email newsletter as well, thanks.

Any questions? or Suggestion leaves a comment below.