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:
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
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
Version
11i_GL_D
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
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)
NLS Patches
3
4. Structure of a patch
•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.
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.
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
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:
1. adpatch ,admrgch
2. adctrl
3. adadmin
Installing a Patch
Now you will get a directory with patch no in this case directory name is
2145632
[applmgr@testserver Patches]$ls
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)
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.
Some SQL scripts perform row set processing. You can set the number of rows these
scripts process.
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
AutoPatch then validates the ORACLE usernames and passwords for Applications
products.
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 tells you what patches you are about to apply, what products they will
change, and asks you if you want to continue.
9
You should check the file
/d01/appl/110/admin/V1103/log/adpatch.log
For errors.
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]?
10
7. Post patch application steps
8. Patch History
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
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.
[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
PATCH_TOP
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
13
-merged_name=we are specifying name of patch which we get after
merging those three patches
Now we are running merge patch
Patch Troubleshooting
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
Now when you run adpatch it will start applying the original patch that failed.
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
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.
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.
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.
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.
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.
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
.
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