11i PATCHES (adpatch)

OBJECTIVES

1. Introduction
2. What are patches? Why to apply patch? Who will decide to apply patch?
3. Types of patches
4. Structure of a patch
5. Pre Patch Steps
6. Patching Application in interactive Mode
7. Post patch application steps
8. Controlling/Managing Patch Session
9. Patch History
10.Applying Patches in non-interactively
11.Merging Of Patches
12.Patch Troubleshooting
13.How to reduce downtime while applying patches
14.Applying Patches to Multi-node system
15.Applying Unified drivers
16.Testing a Patch Before Applying it

1. Introduction:

• AutoPatch or Adpatch is a utility that is used to apply patches and

release updates.
• Before AutoPatch replaces a file with one from the patch, it
compares the version numbers to ensure that your file will be
replaced only with a newer one. Unless adpatch is run with
forcecopy on the command line:
adpatch options=forcecopy
• Before replacing any file, AutoPatch always makes a backup copy

2. What are patches? Why to apply patch? Who will decide to

apply patch?

• Patches are oracle delivery Mechanism

• Patches are the process of bug fixing and product Enhancements
• Patches are Apply To bring the Unstable oracle state to stable oracle
state

1
• The Implementation team & Oracle support services will decide to
apply patches

3. Types of patches

1. One of Patches
2. Mini Pack Patches
3. Family Pack Patches
4. Rollup Patches
5. Maintenance Pack Patches
6. IOP(interoperability Patch)
7. NLS Patches
8. Diagnostic Patches

One-of, individual or Standalone

These are terms used to describe an individual patch that is created to fix
one particular.
It is single Patch to resolve single bug

Mini Pack

‘Patch Set’ was the original term used in R10. In R11 the same type of
patch is now being called a ‘Mini Pack’. Both terms mean a large,
cumulative patch, for a particular product, that fixes most or all bugs that
have been fixed for that release and product. Mini Pack are consisting of
collection one of patches

Version

11i_AD_G

Module name (ad)

Version

11i_GL_D

Module name (gl)

If you want to get the additional utilities of 11.5.10 in 11.5.9 then you
have to apply a mini pack

2
Family Pack

‘Family Pack’ is a group of related Mini Packs products that are bundled
together, and possibly some additional individual fixes that have been
created after the Mini Packs. Some examples of product families are ERP,
CRM, Procurement, or Order Management, but there are many others.

Family pack of financial suite consist of (gl, ap, ar, ont, fa)

The same bulleted information for Mini Packs applies for Family Packs.
The only difference is the naming structure. Family Packs will be named
similar to:

 11i.OM_PF.G or 11i.FINAP_PF.A

 The ‘_PF’ in the name indicates it is a Family Pack and not

a Mini Pack.

Maintenance Pack

Maintenance Pack is the term that Oracle began using for R11, while
Release Update was used for R10.

A ‘Maintenance Pack’ is a collection of all Mini Packs that are bundled together onto a set
of CDs that can be ordered and easily installed by the customer

• with the full installation of this type of patch, the 3rd digit of
Applications Release will change. (Ex 11.5.3 to 11.5.5)

• As with Mini Packs, Maintenance Packs are cumulative. So if 11.5.5 is applied,

then the prior Maintenance Packs do not need to be applied.

NLS Patches

If your install has multiple languages, additional patches may need to be

installed for each language. The American patch needs to be applied first,
and then an NLS version of the same patch needs to be applied for each
language. When applying the NLS patch, be sure to set the NLS_LANG
variable to AMERICAN_AMERICA.<character set>, substituting the
appropriate character set for your language. For more information on
other variables and steps, consult the NLS Installation manual.

3
4. Structure of a patch

WHAT DOES A PATCH LOOK LIKE?

• A patch may consist of many files.
• When you receive a patch, you actually receive a compressed
archive (zip format) of several files. These include:
Patch driver files
• Every patch comes with one or more patch driver files.
• The patch driver file lists the files (and version numbers)
included in the patch.
• This file tells AutoPatch what steps need to be done to apply the
patch and . in what order to apply these steps
Three types of patch drivers, each with its own naming convention:
• c<bugno>.drv is the file, or copy driver, responsible for copying
files and linking executables. (This driver copies files from patch to
directories, relinks executables, and regenerates jar files.)

• d<bugno>.drv is the database driver, and runs SQL scripts and

programs
That updates the database. (Create packages, Create new error
messages,
Add a New table or View to database; Add a new column to a table)

• g<bugno>.drv is the generation driver, and generates forms,

reports, and
Message files.

•The names were chosen because the order in which they must be
applied is
Alphabetical: c (for copying), d (for database), and g (for
generation).

A readme file
• Every patch should come with a readme file, usually named
readme.txt.
• This file tells the user what bug it is fixing, what files are to be
changed, and special steps the user needs to perform (if
any).

"Replacement" files
• These files are listed in the file driver (c<bugno>.drv).
• These are files that replace the ones you have on your current
system or add files that are not on your current system.
• These are usually forms, reports, SQL scripts, or object modules.

4
 • They are organized by subdirectory within the patch directory
based on where they belong on your file system.

Scripts and executables

• These are SQL scripts and executables that need to be run to
apply that patch.
• These scripts often modify the database and are typically called by
the database driver.
• They are organized by subdirectory within the patch directory but
actually run from APPL_TOP, not from where the patch was
unloaded.

Patch files are grouped by directory based on their patch number.

Within each patch, files are grouped by product, then by their location in
the
<PROD>_TOP directory.

For example, suppose I have patch 123456, which replaces a report file
in PO and includes database update steps. I receive a compressed tar
archive, which expands to this:

123456
|
| | | |
|
po readme.txt c123456.drv d123456.drv
g123456.drv
|
| | |
reports forms patch
| | |
POXPOCPS.rdf US 110
| |________
POXPOMPO.fmb | |
Sql driver
| |
b123456.sql d123456.drv
A few notes about this example:
• The directory name for this patch is the same as the bug number
we are patching.

5
 • The readme.txt, c123456.drv, d123456.drv, and g123456.drv
are all at the top level of this patch.
• Note that within the patch, POXPOVPS.rdf is located in the po/reports
Directory. On the file system it is located in PO_TOP/reports directory.

From 11.5.9 onwards oracle has introduces U-driver (U12345.drv)

• It is unified driver which consist of c, d& g drivers
Order of applying Patch
• For single Node first apply ‘c’ then ‘d’ and finally ‘g’
• For Multi Node
 Firstly apply patch on DBtier in order ‘c’ then ‘d’ and finally
‘g’
 Secondly apply same patch on Application tier only ‘c’ and ‘g’

5.Pre Patch Steps

1. Log in as applmgr. Make sure this account is using a Bourne shell (or
Korn shell on some platforms). It may not work properly if you are using
other shells, such as a C shell.
2. Run the environment file for the Oracle Applications product group
you want to update.
This is normally <db_name>.env
• To run the environment file, make sure you are in a Bourne
or Korn Shell and type:
$ . $APPL_TOP/<db_name>.env
• Depending on your setup, you may have already run this file
when logged in

3. Take the backup of APPL_TOP, COMN_TOP &DATABASE

4. Shutdown all The Application Services, Instance should up and

running & Listener should be up and running

5. Ensure you have sufficient temporary disk space.

 You should have at least 50 MB in the temporary directories denoted by APPLTMP
and REPORTS25_TEMP.
 You should also have space in the operating system’s default
temporary directory (usually /tmp or /usr/tmp).
6. After Downloading Patch files from Metalink, Copy the patch files to
your own PATCH_TOP directory. That is the directory that holds the
patch files.

6
7. Unzipped the patch file, and then you will get directory with a patch
number in that directory you will find readme.txt. Read the readme.txt
file. It provides information you'll need to run AutoPatch. This information
may include:

• Software requirements, such as other patches you need to apply

first, or what Applications release you should have
• Disk space requirements, if the patch is particularly large
• Time requirements (a patch can take anywhere from 15 minutes
to several hours to run)
• Details Problems that are fix in this patch

Tools To Know Before Applying Patches

1. adpatch ,admrgch
2. adctrl
3. adadmin

6. Patching Application in interactive Mode:

Installing a Patch

Following are the basic steps to installing a patch on R11i.

[applmgr@testserver Applivs]$ cd /uo1/Patches

[applmgr@testserver Patches]$ ls p2145632_11i_LINUX.zip

[applmgr@testserver Patches]$ unzip p2145632_11i_LINUX.zip

Now you will get a directory with patch no in this case directory name is
2145632

[applmgr@testserver Patches]$ cd 214532

[applmgr@testserver Patches]$ls

po readme.txt c123456.drv d123456.drv

g123456.drv

These are the contents of patch dir you can see readme.txt .Now at this
stage read the readme file carefully and if there are any steps to execute
before starting the patch, they must be executed first. Such as applying a
prerequisite patch

7
[applmgr@testserver Patches]$ adpatch (return)

Autopatch confirms your APPL_TOP

Your default directory is ’/d01/appl/110’.
Is this the correct APPL_TOP [Yes]?

This is just confirming your APPL_TOP. Some customers may have multiple APPL_TOPs,
for different instances, and this helps prevent someone from accidentally applying a patch to
the wrong APPL_TOP.

Auto patch ask for your logfile name

AutoPatch records your AutoPatch session in a text file you specify. Enter
your AutoPatch log file name or press [Return] to accept the default file
name shown in brackets.
Filename [adpatch.log]:

Default name is adpatch.log

You can receive an email message if AutoPatch encounters a failure.

You can be notified by email if a failure occurs. Do you wish to activate

this feature [Yes]?
You chose to be notified by email when a failure occurs. Please enter the
email id(s) (separated by space) that notifications
should be sent to [applmgr] :

Some SQL scripts perform row set processing. You can set the number of rows these
scripts process.

Please enter the batchsize [1000]:

AutoPatch asks you to confirm the database and database home directory.

You are about to use or modify Oracle Applications product tables in your
ORACLE database ’apptest’ using ORACLE executables in
’/d01/oracle/prod/8.0.5’.
Is this the correct database [Yes]?

If these values are not correct, exit AutoPatch (by typing ‘ABORT’) and edit your
ORACLE_HOME and ORACLE_SID or TWO_TASK variables as needed.

8
AutoPatch asks for the SYSTEM password. It then determines the username for your
Application Object Library user

AutoPatch needs the password for your ’SYSTEM’ ORACLE schema in order to
Connecting to SYSTEM......Connected
determine your successfully.
installation configuration.
Enter the password for your’SYSTEM’ ORACLE schema: manager

Connecting to SYSTEM......Connected successfully.

AutoPatch then validates the ORACLE usernames and passwords for Applications
products.

The ORACLE username specified below for Application Object Library

uniquely identifies your existing product group: APPLSYS
Enter the ORACLE password of Application Object Library [APPS]: APPS

AutoPatch asks for the directory that holds the patch files.

Enter the directory where your Oracle Applications patch has been
unloaded
The default directory is [d01/app1/110/patches123456]:

AutoPatch asks for the name of your patch driver file.

Please enter the name of your AutoPatch driver file [patch.drv]:

• This is usually c<bugno>.drv, d<bugno>.drv, or g<bugno>.drv.

• AutoPatch tells you what patches you are about to apply, what products they will
change, and asks you if you want to continue.

At this point, AutoPatch takes over.

• AutoPatch displays messages to show its progress.

• And at the end a success message is displayed.

Log and Info File sync point:

Thu Apr 20 2000 10:29:13
Autopatch is exiting successfully.
AutoPatch is complete.
AutoPatch may have written informational messages to the file
/d01/appl/110/admin/V1103/log/adpatch.lgi

9
 You should check the file
/d01/appl/110/admin/V1103/log/adpatch.log
For errors.

Restarting a failed patch.

• Autopatch will ask several questions that have to be carefully answered.
APPL_TOP is set to /d01/appl/110
Backing up restart files, if any….Done.
Your previous AutoPatch session did not run to completion.
Do you wish to continue with your previous AutoPatch session
[Yes]?

1. If you want to continue, you answer with yes. Adpatch will ask you to confirm the
database and database home directory.
You are about to apply a patch to the installation of Oracle
Applications in your ORACLE database 'atlcol06_v1103'
using ORACLE executables in '/db02/webhome/v1103'.
Is this the correct database [Yes]?

• After this question, adpatch asks and confirms the same things as in a regular run.

2. If you don’t want to continue, you answer with No and the following question will come
up.
Enter No to continue with your previous AutoPatch session. [No]:

• If you answer this question with No, you will continue with the old adpatch session as
described above.
• If you answer this question with Yes, you will continue with the following question.
You can be notified by email if a failure occurs.
Do you wish to activate this feature [Yes]?

• After this question, adpatch asks and confirms the same

10
 7. Post patch application steps

There are a few post-AutoPatch steps to complete. After running

AutoPatch, you should check the log files for errors
• Log files are located in APPL_TOP/admin/<db_name>/log. .
• You should check your main log file (adpatch.log, by default) as well as other files
generated by AutoPatch (such as adrelink.log, admvcode.log, adwork*.log, and others).
• AutoPatch also produces an informational log file, adpatch.lgi. This contains messages on
actions that AutoPatch did not perform.

Search for words like "Error:", "Warning", "ORA-", "PLS-", "APP-",

"FRM-", and "REP-".
• Make all searches case insensitive
• Look for "Error:" (with the colon) and not "Error"

Re-run AutoPatch as necessary.

Clean up or read-protect log/, restart/, and out/ directories under the

admin base directory.
• Log, output, and restart files record passwords to your Oracle Applications products.
Restrict access to these files after you've confirmed the patch was successful.

Perform manual update steps

• Check your readme.txt file for any manual update steps you might need to perform at
this time.

I. Compile Invalid Objects

II. Take backup Immediately
III. Run the form or report that you have generated by applying patch
to see
Weather it is working fine or not
IV Remove obsolete file (Once you're sure the patch works, you can delete backup
copies of files (ones that end in O) to free up disk space.

8. Patch History

In prerelease 11.5.4 patch History going to be located in

APPL_TOP/admin/adptch.txt
Now it is going to store in database tables
I AD_APPLIED_PATCHES (this will give applied patch no’s)
II AD_PATCH_DRIVERS (this will give applied patch drivers)
III FND_PRODUCTS_INSTALLATIONS (this will give you patch set
or mini pack level &Family pack level)

11
A part from this oracle has given a shell script which will be available on
Metalink
(patchset.sh).this will give you information what are all patches you
have applied.
This will compare patch level that you have with available patches on
Metalink and give the comparison .you had to download this script from
Metalink

Login as applmgr
$ ./patchset.sh

9. Applying patches in non-interactively

If you want apply a patch non-interactive mode then you have to take
help of a file called adalldefaults.txt which is in
APPL_TOP/admin/adalldefaults.txt.

You have to copy this file to from APPL_TOP/admin/adalldefaults.txt

to
APPL_TOP/admin/<SID>/def.txt
This file is going to pass as argument when you run the adpatch

[applmgr@testserver Applivs]$cp $APPL_TOP/admin/adalldefaults.txt \

$APPL_TOP/admin/<SID>/def.txt

[applmgr@testserver Applivs]$adpatch
defaultsfile=$APPL_TOP/admin/<SID>/def.txt logfile==p1234.log
interactive=no patchtop=/u1o/patches/1234 adworkers=5

Now it will apply c, d & g all three driver and it will not going to ask
anything

You can make a shell script of above command line executable and
you can run that file

Ex:
[applmgr@testserver Applivs]$ vi patch.sh

adpatch defaultsfile=$APPL_TOP/admin/<SID>/def.txt
logfile==p1234.log interactive=no patchtop=/u1o/patches/1234
adworkers=5 driver=c1234.drv

:wq

12
 [applmgr@testserver Applivs]$ ./patch.sh

It will only apply c driver not d and g

10.How to merge the patch

Merging only compatible patches

Patches of different platform, different versions and different release
cannot be merged
Particularly NLS patches are going to be merged

PATCH_TOP

Source directory destination directory

12345 23456 34567

In source directory we have 3 patches now we are going to merge those

three patches and put them in destination directory

You should be at patch top level for merging patches for merging patches
Use admrgpch

There two types of drivers (1) split drivers (c, d &g) (2) unified driver (u)
We merge can’t these two drivers

Login as applmgr

[applmgr@testserver Applivs]$ cd /u01/Patches

[applmgr@testserver Applivs]$admrgpch –s source_dire_name -d dest_dir_name \
-merged_name= new_patch_name
-s = this option is used specify name of your source directory that
contains patches which are to be merged in the above case 12345,
23456& 34567
-d = this option is use to define the name of destination directory where
your patches is going to kept after merging

13
 -merged_name=we are specifying name of patch which we get after
merging those three patches
Now we are running merge patch

[applmgr@testserver Applivs]$ cd /u01/Patches/dest_dir_name

[applmgr@testserver dest_dir_name]$adpatch defaultsfile=$APPL_TOP/admin/SID/def.txt\
logfile=<logfile_name> Patchtop=/u01/Patches/ dest_dir_name interactive=no

Patch Troubleshooting

Basic patch troubleshooting

If’d’ driver has failed then the adctrl utility will specify which driver has
failed
If it tells that adworker02 has failed
Then go and refer adworker02.log for troubleshooting .they are located
in
$APPL_TOP/admin/<SID>/log.
Scenario 2
Suppose if your adpatch session has successfully completed running ‘c’
driver and it got hanged While running your‘d’ driver ,which requires
prerequisite patch to complete
Then you start one more session rename FND_INSTALL_PROCESS &
AD_DEFFERED_JOBS; drop the associated indexes of these tables and go
to
$APPL_TOP/admin/SID/ there you will find restart directory rename it.
Now apply
The pre-requisite or recommended patches rename back those two tables
and restart directory
Now if you start running the adpatch it will start applying the original patch
that has failed

Steps:
1. Login to sqlplus as users applsys
2. Make sure the FND_INSTALL_PROCESS exits:
3. create backup table of the FND_INSTALL_PROCESS tables:
Create table fnd_install_process_bak as select * from
fnd_install_process
4. Make sure table fnd_install_process_bak exits and has records :
Select count (*) from fnd_install_process_bak;
5. If your application is 11.5.8 then backup the AD_DEFFERED_JOBS table;
Create table ad_deffered_jobs_bak as select * from
ad_deffered_jobs
6. Make sure table ad_deffered_jobs_bak exits and has records
Select count (*) from ad_deffered_jobs_bak;

14
 7. Drop the tables ad_deffered_jobs & fnd_install_process and associated
indexes
Drop table ad_deffered_jobs
Drop table fnd_install_process
8. Login as applmgr user
9. go to $APPL_TOP/admin/<sid>
10. Rename restart directory
11. Now apply new Patch

After new Patch completes successfully

1. Login to sqlplus as applsys.

2. Recreate the fnd_install_process table:
Create table fnd_install_process as select * from
fnd_install_process_bak;
3. Login to sqlplus as apps and create a synonym or fnd_install_process:
Create synonym fnd_install_process for
applsys. fnd_install_process.
4. If you are running Applications Release 11.5.8, recreate the
AD_DEFERRED_JOBS table:
Create table ad_deffered_jobs as select * from
ad_deffered_jobs_bak;
5. Log in to UNIX as the applmgr user.
6. Change directories to the location where the restart files are stored:
cd $APPL_TOP/admin/<sid>
7. Rename the backed up restart directory:
mv restart_bak restart

Now when you run adpatch it will start applying the original patch that failed.

Backing out when a Patch fails

Suppose if ‘c’ driver has failed, in patch directory it will create a backup
directory which contains the files that ‘c’ driver is going to change

If ‘c’ has failed restore APPL_TOP, COMN_TOP which you have backed
before applying patch

If ‘d’ has failed restore APPL_TOP, COMN_TOP & DATABASE, which you
have backed before applying patch

How to reduce downtime while applying patches

Using a Staged Applications System

15
Action
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, it 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 as well to
further reduce risks.
■ You must have different Applications system names for the staged and
the production systems. AutoPatch will correct the historical information.

Complete the following tasks:

1. Update 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.
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.

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. If you need to
apply more than one patch, consider merging the patches to further
reduce downtime.
While you are completing this phase, do not apply any other patches to
the production system. If you do, you will have to recreate the staged
system.

Update the production database:

Once the patching is complete on the staged system, you are ready to
update the production system. You must be able to connect to the
production database from the staged system. If necessary, use the s_ifile
AutoConfig variable to create a tnsnames file in the staged system with
entries for the production system. See Using AutoConfig to Manage

16
System Configurations with Oracle Applications 11i (OracleMetaLink
document 165195.1).
Then, complete the following tasks:
1. Set the environment, shut down all services on the production system,
and enable maintenance mode.
2. Run AutoPatch.
Apply the database driver for the patch you wish to apply. For patches
with a unified driver, add the argument options=nocopyportion,
nogenerateportion to the AutoPatch start command (adpatch). Make
sure the database name in the AutoPatch prompt is correct.
If you applied multiple patches to the staged system, merge the database
drivers for each patch before applying it to the production system.

Update the production APPL_TOP:

The production APPL_TOP must be synchronized with the staged
APPL_TOP. To minimize downtime, you can complete this task while the
production database is being updated. You can use a simple copy or a
utility such as rdist.
Note these conditions:
■ If your system contains multiple APPL_TOPs, you must copy each one to
the production system.
■ If you share a single APPL_TOP, you need to synchronize only one
system.
■ 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. Do not copy the following files and directories
when you copy the APPL_
TOP:
$COMMON_TOP/util/apache
$COMMON_TOP/admin/scripts
$APPL_TOP/admin/<SID>
$FND_TOP/out
$FND_TOP/log
$COMMON_TOP/html/bin/appsweb.cfg
$COMMON_TOP/html/US/ICXINDEX.htm
$COMMON_TOP/html/_pages
$APPL_TOP/log/
$APPL_TOP/patches/
$COMMON_TOP/html/iby_debug.log
$COMMON_TOP/html/iby_error.log
If you use the rdist utility, you can use a distfile to exclude these files.

Create a complete production patch history:

17
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 if 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.

Complete these tasks:

1. Export applied patches information.

Run adphmigr.pl (located in AD_TOP/bin). Type adphmigr.pl -help to
see all valid options for running the utility. We recommend 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

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.

18
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 typing abort at the patch driver file prompt.

Note: The FNDLOAD method of transferring patch history is no longer recommended.

The adphmigr.pl method is more efficient and easier to use.

Applying patches to 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 APPL_TOP system, the APPL_TOP and the COMMON_TOP file
systems are installed on a shared disk resource mounted to each node in
the system. Any changes made to a shared APPL_TOP are immediately
available on all nodes.

Action
Complete the following steps. The example assumes a system with two
nodes, one with an administration server and a concurrent processing
server, and the other with a forms server and a Web server.
1. Log in as applmgr and set the environment.
2. Unzip the patch in a designated patch top directory.
3. Complete prerequisite or manual steps.
4. Shut down services.
5. Enable Maintenance Mode.
6. Start AutoPatch.
7. Respond to the AutoPatch prompts.
8. Apply the copy and database drivers to the APPL_TOP on node 1
(administration and concurrent processing).
9. Start the concurrent managers.
10 Apply the copy driver to the APPL_TOP on node 2 (forms and Web
servers).
11 Apply the generate driver to the APPL_TOP on node 1.
12 Apply the generate driver to the APPL_TOP on node 2.
13 Disable Maintenance Mode.
14. Start services and restart the Web server, if necessary.

Applying Unified drivers

Action
Perform the following steps:
1. Log in as applmgr and set the environment.
2. Unzip the patch in a designated patch top directory.

19
3. Complete prerequisite or manual steps.
4. Shut down services.
5. Enable Maintenance Mode.
6. Type the adpatch command as indicated in Step 6, adding the
following options on the command line: nocopyportion,
nogenerateportion. The command line syntax should look like this:
$ adpatch options=nocopyportion, nogenerateportion
7. At the prompt for the driver name, specify the unified (u) driver.
AutoPatch runs the driver, applying only the database portion of the
patch.
8. Respond to the AutoPatch prompts.
9. Review log files.
10. Review customizations.
11. Pre-allocate space for packages, functions, and sequences (optional).
12. Disable Maintenance Mode.
13. Restart server processes.
14. Delete or archive AutoPatch backup files
.

Testing a Patch before Applying It

Action
Complete the following steps:
1. Follow the steps in the 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 9 and 10 in the Applying a Patch interactively section.
You must also complete steps 12 and 13 if you shut down your servers
and enabled maintenance mode before you applied the patch.

20