Oracle EBS Patching
A Patch which fixes a
bug (or) enhance/add a particular feature in existing program.
Patch is a program to fix a
particular problem or enhance/add a particular feature in existing
program/product/software.
Why patches require in oracle Ebs?
Patches may be required to resolve problem with application code, to fix
production issues, to install new feature to upgrade components of the
technology stack.
Patches is of two types
1) (Opatch) to apply database patches
2) (Adpatch) to apply application patches.
MODES IN PATCHING:
We can apply adpatch in four modes.They are
1)Interactive
2)Non - Interactive
3)Pre-install mode
4)Test mode
1) Interactive :-
Providing all the inputs at the time of applying a patch.
2) Non - Interactive :-
Providing the inputs for adpatch in a file is said to be Non-interactive
mode.
It is a text file.
Location of the defaults file is $APPL_TOP/admin/<SID>
While working with defaults file for the first time we need to provide all the
inputs. From next time onwards we have to provide only limited information like
Patch location, driver file, patch log file and number of works.
Example:
$adpatch defaultsfile=/u01/erpapp/appl/admin/ebsofdb/adpatchdef.txt
From next time onwards no need to provide all the inputs,its enough to provide
below inputs.
1)Logfile
2)Patch directory location
3)Driver file
4)Workers
Advantage: Reduce patch timing.
3) Pre-install mode :-
In this mode, Only copy
portion is applied.('C' Driver is applied)
Database portion and generate portion will not be executed.('D' and 'G' Driver
will not be executed). Default it is set to no adpatch preinstall=n
This would be done normally during an upgrade or consolidated update. When a
patch is applied in a preinstall mode then all the AD utilities are updated
before the upgrade or update. If you wish to apply a patch in preinstall mode then use below syntax.
$adpatch preinstall=y
4) Test mode :-
By using this mode, We can see the effects of applying this patch will have on
your system before applying the patch.
The default is adpatch apply=y.
If you want to apply a patch in test mode follow below syntax.
Syntax: adpatch apply=no
in this mode just file comparision will be done between PATCH_TOP and APPL_TOP
and that will be reported in .lgi file.
It is located under $APPL_TOP/adminn/<SID>/log/adpatch.lgi
Advantage: Will get to know what patch is doing before applying the patch on
our system.
Adpatch options:
To change the default behavior of patching ,we can use below options.
Non default
nocopyportion
nodatabaseportion
nogenerateportion
nocompiledb
nocompilejsp
novalidate
nomaintainancemrc
noautoconfig
hotpatch
default
copyportion
databaseportion
generateportion
compiledb
compilejsp
validate
maintainancemrc
autoconfig
nohotpatch
Checkfile :-
The checkfile option of adpatch tells adpathc to check for already executed
exec, SQL, and exectier commands. this can cause performance overheds so should
be used only when specified.
$adpatch options=nocheckfile
Compiledb :-
Purpose: To compile
invalid objects in the database after running actions in the database driver.
Default: compiledb (use ‘nocompiledb’ to skip)
Compilejsp :-
Purpose: To compile out-of-date JSP files, if the patch has copy actions for at
least one JSP file.
Default: compilejsp (use’nocompilejsp’ to skip)
Copyportion :-
Purpose: To run commands found in a copy driver. This will copy the higher
version files from patch to product top.
Default: copyportion (Use ‘nocopyportion’ to skip. Use it only when mentioned
in readme of patch)
databaseportion :-
Purpose: To run commands found in a database driver. This portion includes
applying the files (like sql, pls etc) to database.
Default: databaseportion (use ‘nodatabaseportion’ to skip. Use it only when
mentioned in readme of patch).
generateportion :-
Purpose: To run commands found in a generate driver. This portion will generate
new executable files from the copied code of patch. For example if will
generate new forms files (fmx) from new .fmb files.
Default: generateportion (use ‘nogenerateporation’ to skip).
$adpatch options=nogenform
$adpatch options=nogenrep
integrity :-
Purpose: To perform patch integrity checking. Tells adpatch whether to perform
patch integrity checking, which verifies that the version of each file
referenced in a copy action matches the version present in the patch.
Default: nointegrity (By default the integrity is not checked)
$adpatch options=integrity
maintainmrc :-
Purpose: To maintain the
MRC schema after running actions found in the database driver.
Default: maintainmrc (use ‘nomaintainmrc’ to skip)
autoconfig :-
Purpose: Tells adpatch to run Autoconfig after patch installation.
Default: autoconfig (use ‘noautoconfig’ to skip)
parallel :-
Purpose: To run actions that update the database or actions (like SQL) that
generate files in parallel (like genform).
prereq :-
Purpose: Tells adpatch whether to perform prerequisite patch checking prior to
running patch driver files that contain actions normally found in the copy
driver.
Default: prereq (use ‘noprereq’ to skip)
$adpatch options=noprereq
validate :-
Purpose: To connect to all registered Oracle Applications schemas at the start
of the patch. Adpatch validates the passwords for each schema.
Default: novalidate (use ‘validate’ to validate schema passwords)
Default: parallel (use ‘noparallel’ to skip)
Java Classes :-
If you wish adpatch not to copy new java classes from the patch .By default
java classes are copied.
$adpatch options=nojcopy
Relinking :-
If you wish adpatch not do perform relinking you can use options=nolink.
Force Copy :-
By default adpatch copies the files without check the version of the existing
files already present on the system.If you do not wish the newer version
of the file to be replaced by the older version contained in the patch use
options=noforcecopy.
$adpatch options=noforcecopy.
You could specify multiple options at the command line using the , delimiter.
$adpatch options=nocompiledb,nocompilejsp,nojcopy
Following flags can be
passed to adpatch
1) hidepw
Purpose: This argument is used to hide the passwords in log files
Default: nohidepw
2) trace
Purpose: Tells the adpatch utility whether to log all database operations to a
trace file
Default: notrace
3) logging
Purpose: Tells the adpatch utility whether to create indexes using the logging
or nologging mode.
What two tables adpatch creates when you apply or run adpatch session ?
FND_INSTALL_PROCESSES
AD_DEFERRED_JOBS
Naming convention of
patch
1)<p><number>_11i_<platform>
<number>=7 digits
example: p1234567_r12_LINUX.Zip
2)P1234567_11i_GENERIC.Zip
Note: Generic indicates on all platform we can apply this patch.
Types of patch in oracle applications
One of patch
A patch that doesn't depends upon another patch. One of patches fixes one or
more bugs for a single product. One of patches may or may not have the pre
requisites.
These patches are small in size. They often called as standalone patches.
Mini Pack:
A mini pack is one which will upgrade any product patch set level to next level
.
or
Collection of one -off patches and enhancement related to particular module.
All bug fixes related to one product which will change the patchset level of
specific product.
Minipack version is denoted by alphabetic characters.
patch+patch=Minipack
<11i>_<product>_<minipack level>
Example: 11i.FND.H
11I.GL.I
11i.GL.H.1
Rollup patches
A rollup patch is one which will deliver bug fixes identified after the release
of any major application versions like 11.5.8/11.5.9.
Family pack
A Family pack is one
which will upgrade the patch set level of all the products in that family to
particular patchsetlevel.
(OR)
Collection of minipack patches for a particular family group of application
modules.
Some of the families in oracle Apps are:
FIN == GL,AR,AP,FA
ATG == AD,FNDAU,WF
Family pack patches will change entire product family.
product Minipack+product
Minipack= Family pack.
Naming convention of family pack patch:
=========================
<Family name>_PF.<CODE LEVEL>
Example:HR_PF.J
GL_PF.K
Maintenance pack patch
Group of family pack is called Maintenance pack patch.
A maintenance pack will upgrade applications from one version to another like
11.5.8 to 11.5.9
Consolidated patches.
Consolidated patches
will come into pictures after upgrades from one version of applications to
another, all post upgrade patches will a consolidated and given as consolidated
patch.
PATCH ARCHTECTURE
================
Suppose this is the patch number 1234567.
Example:P<1234567>_R12_LINUX.zip
A patch contains three things.
1)Directory with the patch number like here in this case 1234567.inside you
will find below files.
2)README.txt or README.html
3)Driver files
c<patch number>.drv
d<patch number>.drv
g<patch number>.drv
u<patch number>.drv it is ther in updated versions.
What happens when we unzip a patch?
===========================
unzip P<1234567>_R12_LINUX.zip
When we unzip a patch it create a base directory with the patch number like
1234567.
it contains all patch related files .in this directory there is a file
README.txt or README.html
which contains instruction how to apply a patch and also it contain patch
number,product,release
and platform.if patch is too long it contain document id which helps us to
apply a patch.
it also contain driver files.
c<patch number>.drv
====================
Copies the files that are there in patch to the APPL_TOP
Extracts the appropriate files from each product c library.
Re-links the oracle application product.
Compares the files in the patch with those in the APPL_TOP,if the files in the
patch are a higher
version, then adpatch copies the files from patch to APPL_TOP
d<patch number>.drv
===================
The database driver contains all commands to change the database objects. In
multi node installation d driver runs
from the admin server. The database driver applies all script copied by the
copy driver to the database.
==> Make a list of all invalid objects in the database.
==>Run sql scripts,which make changes to the database.(Packages,procedures
and etc).
==>Compile all the invalid objects that are there in the database.
g<patch number>.drv
==================
Regenerate all forms,reports and PL/SQL libraries that have been effected by
the patch.
u<patch number>.drv
===================
It is combination of all three drivers c,d and g.The action of each driver is
performed by u driver.
Q) Who will created the patches?
Patches are created by Oracle whenever there are enhancement in its application
or there are any problem with the exists ones.
Q) After Patches are
Applied Successfully, it will update the patch history in AD_SNAPSHOTS.
what is a snapshot?
There are two types of snapshosts, APPL_TOP and global. APPL_TOP snapshots
contain version of files and patches applied within that APPL_TOP. A global
snapshot contains the same information but for the entire environment, ie. all
APPL_TOPS.
The global view snapshot is used when you use Patch Wizard to determine whether
or not a patch has been applied. APPL_TOP snapshots are using by autopatch (adpatch)
to determine if all prerequisite patches have been applied. Each time you apply
a patch AutoPatch updates the current view snapshot. I believe it may even
create a new current view snapshot and just replace the existing one.
Additionally there are two types of snapshots, current view and named. A named
snapshot is just a copy of the current view snapshot at a given point in time.
Patch wizard and AutoPatch use current view snapshots.
To access snapshot information launch adadmin, select option 2 - Maintain
Applications Files menu, select 5 - Maintain snapshot information and you will
see the menu below:
Maintain Snapshot Information
-------------------------------------------
1. List snapshots
2. Update current view snapshot
3. Create named snapshot
4. Export snapshot to file
5. Import snapshot from file
6. Delete named snapshot(s)
7. Return to Maintain Applications Files menu
Back to the problem of adpatch seeming to hang while instantiating a
current-view snapshot. Since this is a cloned environment, a snapshot doesn't
exist yet for the APPL_TOP. So before AutoPatch can check if prerequistite
patches have been applied, it must create a snapshot. This process can take 1-2
hours depending on how fast your servers are. You can avoid this by running
"Update current view snapshot" via adadmin after you clone.
I should add, that in my experience I've only encountered this problem a few
times. Most of the patches I apply to a cloned environment are quick one-offs
with no pre-reqs. Large patching efforts such as family packs or patches with
pre-reqs may experience this problem. I haven't tried, but if your crunched for
time you may be able to bypass adpatch updating the current view snapshot by
specifying "adpatch options=noprereq" to skip the prerequisite check.
Patching Best Practices
As an Oracle
Applications DBA we tend to spend a considerable amount of time applying
patches. A newbie Applications DBA recently asked me the duties of an Applications
DBA besides patching .At that moment i refrained myself just to a smile. But
the question does highlight the significance of patching in an AppsDba's
routine.
Patching, though not a
very complicated process, inefficient or inappropriate patching can seriously
jeopardize the functioning of your
system. Most of the patching for oracle applications is done using adpatch
tools and there are many more which have other methods of application like
through a shell script. However in my current post i will talking only about
the adpatch patches. The 'best practices' mentioned here are the ones which I
have felt to be of use and have made my patching life a bit less complicated.
Patching Methodology
Having a proper patching
process and methodology is always helpful. The ideal one for me is the PATCH
-> TEST -> DEVELOPMENT ->
PRODUCTION one. Under this the patch is first applied to a patch instance then
it is propagated to the test environment where the testing is done after which
it is applied on the development instance where the development team tests the
patch against there customizations if any. Upon passing these stages the patch
is finally applied to the production system. If you cannot afford these many
instances at minimum you must ensure the patch is tested on TEST environment
before you actually go
ahead and apply the
patch to your production.
Consistency
There should be
consistency in the patch application process. That is you should use the same
steps to apply the patch in your
production environment that you used in your TEST/PATCH environment for
example if you applied a pre requisite patch A as part
of your main patch
application, you must ensure the same pre requisite patch is also applied on
the production environment and not a superseded
version of patch A.
Needless to mention
there must be also consistency among the all the different environments. That
is your PATCH/TEST/DEVELOPMENT and PRODUCTION environments should have the same
setups configuration and patchset levels.
Schedule Patch
Application
Schedule the patch
application as far as possible. There are multiple benefits you realize out of
scheduling. The most important one being
that the downtimes will be scheduled and will have help the business to be prepared
for them and not be taking them by
surprise. Also if your patching downtimes are scheduled you can plan to have
the downtime following your backup schedule thereby eliminating the need for
having a separate backups for each patch application. However there will be
high priority patches that will have applied outside this schedule.
A Patch in Time
It is always advisable
to be at the latest patch set level at most of the times. I have always felt
that it is one of your duties as an Apps
DBA to take the fear of patching out of the business's mind. My experience sys
that being on the latest Consolidated
Update or the latest Roll up patch helps in avoiding most of the pre requisite
in case of applying any one off patch which might be required. Also you should
apply the Critical Patch Updates that are released by oracle every quarter.
The Readme
Before applying a patch
make sure you have gone through the readme file of the patch. This file might
contain some special or additional steps that you might have to follow as a
part of the patch application. Also it will tell you if there are any pre
requisite patches that are require. Downloading and having the pre requisites
ready saves you a lot of time.
Pre requisite Patch
In case you are required
to apply a pre requisite patch before you can apply the main patch. it is
better to apply the pre requisite patch only and not the superseded version of
the pre requisite patch. In case you choose to apply the super seeded version
of the of the pre requisite patch you must doubly make sure that the superseded
patch qualifies as a pre requisite patch for the main patch.
Patch Impact Analysis
A patch impact analysis
should be carried out as far as possible before going ahead with the actual
pat6ch application. The simplest way of doing it would be to apply the path
with apply=no option along with adpatch. You can then go through the actions
the patch would have done either from the logfile or view it through the Oracle
Applications manager.
NLS Environment
In case you are patching
an NLS environment. Check if you have a translation patch also available for
the main patch. if one is available make sure to download and keep it ready.
You must install the US language patch first and immediately follow it by
applying the translation patch.
Merge Patches
In cases where you are
doing a bulk patch application like during a production setup the patch
application time is reduced greatly by
merging the patches using AD Merge Patch. However per requisite patches should
not be merged. Also in an NLS environment its is not advisable to merge
multiple language translation patches.
The Logfile
I most patching
scenarios the patch log file is either over written by accepting the default
logfile name adpatch.log or in other cases these are not maintained properly. I
have found myself digging up patch logfiles for a variety of reasons, though
you have a lot of this information available to you via Oracle Applications
Manager's Patch Reports.
Maintenance Mode
With the latest AD.I
patch set there is a pre requisite to put the system on maintenance mode before
applying a patch. I have come across DBA's by passing this option by using
options=hotpatch for reducing the patching related downtime. There is a reason
for having the maintenance mode feature out there, it offers certain
performance benefits and reduces the chances of any conflicts. There are other
ways to reduce the patching related down times, which i will touch upon briefly
next.
Reduce Your Patch
Downtime
As discussed earlier merging
your patches is one of the ways to reduce your patching related downtimes.
There are also certain options you could use with adpatch which could reduce
your downtime significantly. You must however understand each of there options
clearly before using them with adpatch. For e.g. choosing not to compile
invalid objects might reduce your patching downtime but you must be sure of the
invalid objects or you must manually run the compilation script once you are
through with all your patch application.
You can also implement
the concept of a Shared Application Tier File System and a Staged APPL_TOP to
further bring down your patching downtime and effort.
Automate If Possible
In case your business
can afford it you should opt for automating the patch application and
management process using third party tools. My favorite ones have been
Ringmaster APM and Kintana. You might have to still wait a little bit more to
have all these features inbuilt through your oracle applications manager.
Difference between a multi-node and a shared
environment & how is patching impacted
In a multi-node
(distributed) system, servers are installed on more than one node. The core technology directories (admin, ad,
au, and fnd) and all product directories are installed under the APPL_TOP on
all nodes, except for any node that contains only a database. You can patch the APPL_TOPs separately, or
you can set up a shared environment that will enable you to perform patching
and other maintenance procedures only once. This type of system shares not only
the APPL_TOP and COMMON_TOP file systems, but the Applications node technology
stack as well. All Applications nodes are installed on a single, shared disk
resource that is mounted under the same name from each Applications node machine.
Any Applications node can be used to provide standard services, such as serving
forms or Web pages, concurrent processing, or applying patches. Maintenance
procedures are performed on a single Applications node.
If you have not
configured your system as a shared environment, you apply the unified driver to
all APPL_TOPs. AutoPatch sorts out which driver actions it must perform on each
APPL_TOP. You apply the driver first to the node where the administration
server is located. Then, you apply it to the node where the concurrent
processing server is located. Start the concurrent managers, and apply the
driver to the remaining nodes in any order.
How is the maintenance of Oracle Applications
simpler in Release 12? Are patches easier to apply?
In
Release 12, Oracle keeps major new features and bug fixes separate. Significant
improvements to maintaining Applications in Release 12 include:
- Major new functionality is
reserved for point releases
- A new maintenance branch will
be created for each point release
- New feature introduction into
maintenance branches is limited and requires executive approval
- Codelevels make checking for
prerequisites easier
- Patch Application Assistant
(PAA) enhances tracking of manual steps during patch application
What are codelines? Codelevels?
In
Release 12, Oracle Applications patches are grouped into codelines. A codeline begins
with a point release that delivers a unique set of features, such as Release
12.0, and progresses to include all the patches required to maintain that point
release. The initial Release 12.0 point release introduces codeline A. Any
future point releases introduce new codelines, each identified by a new
letter. For example, Release 12.1 would introduce codeline B and Release
12.2 would introduce codeline C.
Patches associated with codelines not only implement a set of product features
for that point release, but also provide fixes to that set of features.
We describe this unique set of product features for a point release as a codeleveland
assign it a unique number. Codelevels also identify patches for individual
products. For example, codelevel R12.AD.A.1 is the first set of fixes to
codelevel R12.AD.A, R12.AD.A.2 is the second set, and so on. Codelevels are
cumulative - each one contains the initial set of features plus all the fixes
created to date for that product or product family.
All codelevels created after the initial point release are aggregated into
cumulative release update packs (RUPs). RUP1 is equivalent to R12.0.1, RUP2 is
equivalent to R12.0.2, and so on. In addition, they may also provide
feature enhancements, which provide new functionality that has a limited impact
on your system.
A new point release contains new features that will substantially impact your
system and may change its operation. It starts a new codeline (for
example, codeline B). At that point, you can choose to upgrade to the new
codeline and adopt the new features, or stay on your existing codeline, where
bug fixes and enhancements will continue to be provided for your existing
features.
How has patch prereq checking improved in Release 12 compared to
Release 11i?
In
Release 11i, patches could require other individual patches as prerequisites.
This process was flexible, but it was difficult to determine if a new patch
included all the functionality of an older patch.
In Release 12, patches can only require a codelevel as a prerequisite and
sometimes based on the technical reasons may require other individual patches
as prerequisite. That means if a patch requires R12.GL.A.3 as a prerequisite,
it is clear that R12.GL.A.4 satisfies the prerequisite and R12.GL.A.2 does not.
What is a recommended patch?
Recommended
patches include high-priority patches or patches that update your system to a
new codelevel. Use the Patch Wizard utility in Oracle Applications Manager
(OAM) to determine which recommended patches you have not yet applied and what
the effect of applying an individual patch will be on your system.
What is a patch driver file?
AutoPatch
uses a driver file to direct the installation of a patch. This unified driver
is named u<patchnumber>.drv. It contains all the driver actions (copy,
database, and generate) that the patch requires, and it performs these actions
in the stated order. Typically, you run the driver on all APPL_TOPs and
AutoPatch determines which actions are required for the current APPL_TOP and
runs only those actions.
The driver actions are as follows:
- Copy: Contains commands to change Oracle Applications
files. The commands include directives to copy and update files,
libraries, and/or Java, and commands for generating JAR files and/or C
executables. In a multi-node system, the copy portion runs on all
application tier APPL_TOPs.
- Database: Contains commands to change Oracle Applications
database objects, such as PL/SQL and table definitions, or to update or
migrate data. In a multi-node system, the database portion runs only on
the application tier APPL_TOP that implements the administration server.
- Generate: Contains commands to generate forms, reports,
messages, and/or graphics files. In a multi-node system, the generate
portion runs on all application tier APPL_TOPs, unless the APPL_TOP only
implements the administration server.
What is the AutoPatch checkfile feature?
The
checkfile feature reduces patch application downtime by checking to see if a
given database action has been performed previously for the associated file
contained in the patch. If an action has been performed using the current (or
higher) version of a file, AutoPatch omits the action from the current patch
application.
What are the Oracle Applications patch types?
Applications
patches are organized by aggregation level.
Individual Bug Fix: A patch that fixes an existing issue.
Individual bug fixes are released only when there is an immediate need for a
fix or enhancement that cannot wait until a release update pack (RUP) is
available. Although individual bug fixes are intended to be as small as
possible, they usually include any dependent files that have changed since the
base release in order to form a complete patch that can be applied by any
customer. The actual number of files changed will depend on the current code
level on the system to which the patch is being applied.
Product Family Release Update Pack (Product Family RUP): An
aggregation of patches on a given codeline created for all products in a
specific product family for a specific point release.
Release Update Pack (RUP): An aggregation of product family RUPs on a
given codeline created across Oracle E-Business Suite after the initial
release. RUPs are cumulative and include all one-off bug fixes previously
released to customers as well as legislative updates and less critical fixes.
New functionality is also allowed in RUPs with executive approval.
Pre-upgrade patch: All upgrade-related, high priority
patches consolidated from all the products within a product family.
Pre-upgrade patches are released as needed. The Oracle Applications Release Notes lists the most recent pre-upgrade patches.
Consolidated Upgrade Patch: All upgrade-related patches consolidated
from all the products within a product family. These patches are released as
needed and are only available for upgrading a Release 12 system from one point
release to another. Release 11.5.10. The Oracle Applications Release
Notes Note 405293.1 lists the most recent patches.
Documentation Patch: Updates online help.
What are AutoPatch restart files?
Restart
files store information about completed processing in the event of a patch or
system failure. They allow AutoPatch and AD Administration to continue
processing at the point where they stopped. Do not modify or delete restart
files unless specifically told to do so by Oracle Support Services.
The restart files reside in $APPL_TOP/admin/<SID>/restart (UNIX) or in
%APPL_TOP%\admin\<SID>\restart (Windows).
What is the difference between a multi-node and a shared environment and how is
patching impacted?
In
a multi-node (distributed) system, servers are installed on more than one
node. The core technology directories (admin, ad, au, and fnd) and all
product directories are installed under the APPL_TOP on all nodes, except for
any node that contains only a database. You can patch the APPL_TOPs
separately, or you can set up a shared environment that will enable you to
perform patching and other maintenance procedures only once. This type of
system shares not only the APPL_TOP and COMMON_TOP file systems, but the
Applications node technology stack as well. All Applications nodes are
installed on a single, shared disk resource that is mounted under the same name
from each Applications node machine. Any Applications node can be used to
provide standard services, such as serving forms or Web pages, concurrent
processing, or applying patches. Maintenance procedures are performed on a
single Applications node.
If you have not configured your system as a shared environment, you apply the
unified driver to all APPL_TOPs. AutoPatch sorts out which driver actions it
must perform on each APPL_TOP. You apply the driver first to the node where the
administration server is located. Then, you apply it to the node where the
concurrent processing server is located. Start the concurrent managers, and
apply the driver to the remaining nodes in any order.
Can I apply multiple
patches in one operation?
Before
you run AutoPatch, use AD Merge Patch to merge multiple patches into a single,
integrated patch so that the required patching tasks and processes are
performed only once. In general, you can safely merge any Oracle Applications
patch with another Oracle Applications patch. Patches should be merged with
their listed prerequisite patches to make the application of the patch easier.
However, patches that affect the Applications DBA (AD) product may change the
AutoPatch utility itself. So, they can be merged only with other AD patches and
must be applied separately, before you apply any non-AD patches.
Note: AD Merge Patch cannot merge patches of different releases,
different parallel modes, or different platforms. However, it can merge patches
for a specific platform with a generic patch, or patches with different source
character sets. The utility notifies you if you try to merge incompatible
patches.
How do I apply multiple
translation patches?
If
an Oracle Applications system contains multiple languages other than American English
(US), and you are applying multiple patches for each language, the recommended
method is to merge all US patches into a single patch and all patches for every
non-US language into a single patch. Then, apply the merged US patch followed
by the merged language patch.
You can also merge US patches with the additional language patches or merge
each language in separate language-specific patches. Depending on your downtime
window and your system topology, it may be necessary to keep the US and non-US
patches separate.
Can I run multiple AutoPatch sessions at the same time?
You
cannot run multiple sessions simultaneously (concurrently). However, patches
can be merged and applied in a single patching session.
Do patches need to be applied in a particular order? What is a prerequisite
patch?
AD
patches are the only patches that must be applied in a specific order. This is
necessary because you may need to patch the patching utility itself so that it
works properly when you use it to apply subsequent patches. It is not necessary
to apply non-AD patches in a particular order, even though a readme may state a
specific order is required.
A prerequisite patch fulfills a dependency for another patch. In Release
12, only codelevels can be prereq patches. Strictly speaking, they are co-requisites and
can be applied in any order before using the system. We recommend that you
merge a patch with its required prerequisites, with the exception of
prerequisite patches for the AD product.
Do I have to perform all the manual steps associated with a patch?
Oracle
Patch Application Assistant (PAA) helps you track and perform manual steps
during patching. For patches that have manual steps, the patch readme file
contains the generic instructions for all systems. PAA generates a
customized set of instructions specific to your installation and displays the
relevant manual steps. For merged patches, PAA automatically merges the
contents of the individual patch readme files. After successfully completing
each step, you can record that step as completed for future reference.
Can I automate the patching process?
Non-interactive
patching allows you to save time by automating the patching process and
avoiding some of the prompts. You can store the responses to the patching
prompts in a defaults file. Then, when you run AutoPatch, you specify the
name of the defaults file, the location of the patch top directory, the name of
the driver file and other parameters in the command line.
How can I track my customizations? What
happens to my customizations during patching?
You
should apply patches first on a test system. Then, review the changes in the
test system and identify the best way to re-integrate customizations affected
by the patch.
You need to register flagged files through Register Flagged Files tool in
Oracle Applications Manager (OAM). Before applying AutoPatch, you need to run
Patch Impact Analysis from OAM to know the list of customizations that would be
overridden with the patch application. The Register Flagged Files tool replaces
the applcust.txt file that was used in 11i and is described in Oracle Applications
Patching Procedures.
Note: Registering customized files does not prevent the object or the patch
from being applied. It only makes them available to OAM for review. See
Customization Standards in Oracle Applications Developer's Guide for more details.
ASSESSING THE EFFECTS
OF PATCHING
Can I determine ahead of time how a patch will affect my system?
You
can analyze the actions a patch will take by reviewing patch log files without
applying a patch to production or you can access a Patch Impact Analysis report
through the Patch Wizard in Oracle Applications Manager (OAM) to see how a
patch will affect the files on your system.
If you want to review log files, you can apply a patch on a test system. Alternatively,
you can apply the patch in production using the AutoPatch test mode. Applying a
patch in test mode requires that you use the AutoPatch optionapply=no.
The resulting log file shows all the actions that AutoPatch will take.
To determine how a patch will affect the files on your system, you can request
a Patch Impact Analysis report for a specific patch through the Patch Wizard in
OAM. The Patch Impact Analysis feature of Patch Wizard provides links to
details about a patch including the following information:
- The total number of files in
the patch
- The number and type of files
the patch will install
- The products that will have
updated files
- The files that will be
introduced by the patch
- The files on the target system
that will be changed by the patch
How do I know what patches have been applied to my system?
The
best way to review patching history is to use the Applied Patches utility
provided by Oracle Applications Manager (OAM). From the Applied Patches
interface, you can perform a simple search by querying on the patch number, the
number of days or date range during which patches were applied and/or the patch
language. An advanced search provides additional search criteria.
The search results display useful information including patch name,
description, a list of merged patches, location of applied patch, language,
files changed or copied, bug fixes in each driver file, whether patch
application was successful and timing information.
How do I know what files have been updated by a patch?
One
of the features of the Applied Patches utility in Oracle Applications
Manager (OAM) is the File History option. Using this feature, you can search
for files that have been updated by a patch. You can view file history
information such as the APPL_TOP and directory where the file resides, the
product that owns the file, the file name and version, the date on which the
file was changed, the patch details report and the action summary report for
updates to the file.
How can I find out how much time a patch took to apply? How can I monitor the
progress of a patch?
The
Timing Reports utility in Oracle Applications Manager (OAM) allows you to
monitor a job that is running or view statistics of completed AutoPatch and AD
Administration sessions. You can view information such as task name, task
status, time taken to complete the task, start time and end time, and log
files.
If I am applying a patch and it fails, should I simply re-run it from the
beginning after fixing the issue?
If
a patch driver fails, fix the issue and restart AutoPatch. AutoPatch will allow
you to continue where the patch left off. Re-running the patch from the
beginning may result in it being applied incorrectly.
Can I restart a failed patch non-interactively?
Use
the restart argument to continue the old session from where it failed.
Use the same command line options that you used initially to start the
non-interactive session, but add restart=yes.
If AutoPatch fails during the copy portion of the unified driver, what should I
do?
In
many cases, the issue can be resolved and the patching process can be restarted
at the point of failure. If there is no feasible method of resolving the
issue, review the log files and the copy portion of the unified driver to
determine the files copied by the patch and the update actions performed.
Depending on the number of files that were copied prior to the failure, you
must decide the best method for restoring the files. Based on the actions
recorded in the log file, you must decide which files, if any, need to be
relinked, restored, and generated.
If a worker fails during the database portion of the unified driver, what
should I do?
Attempt
to correct the problem and restart the failed job.
To restart a failed job, run AD Controller and choose Option 2 to tell the
worker to restart a failed job. Enter the worker number when prompted.
What should I do if a
worker process is hanging?
When
running AutoPatch, there may be situations when a worker process appears to
hang or stop processing. If this occurs, you may need to terminate the
process manually. If you do, you must also restart the process
manually. A process that appears to be hanging could be a valid
long-running job. Be careful when terminating processes.
Can I restore my system after the database portion of the patch fails?
There is no general method of backing out changes that a patch
makes to the Oracle Application database. To avoid the need to restore a database, you should always
test the application of the patch several times on a test system, particularly
if the patch is a release update pack (RUP) or pre-upgrade patch. Do not
apply the patch in production until the patch has successfully applied in a
test system.
What happens in pre-install mode ?
It
updates the adutilities
Unified
APPL_TOP in Oracle Apps R12
Unified APPL_TOP is different from separate APPL_TOP
in Oracle Applications 11i. Unified APPL_TOP make more sense if you are using
multi node Oracle Applications R12.
In Oracle Applications 11i , in multi node
installation each APPL_TOP have its different name and files in each APPL_TOP
will depend on type of Node (i.e. Forms Node will have fmx or forms related
files where as APPL_TOP belonging to CM only node will have rdf or files
required to run CM node)
Starting from R12, it will use Unified APPL_TOP
which means all files required for all middle tier services are included in all
nodes of Multi Node installation (irrespective of services running on that
node)
What
are few changes because of Unified APPL_TOP ?
— During Cloning of multi node Oracle Application
install, only one copy (any one appl_top) of Application Node files need to
copied to target instance.
— During Cloning of Multi Node to Single Node you
don’t have to merge APPL_TOP’s in R12 as required in 11i .
—Services start/stop If you are using adstrtall.sh
to start services on a node then it will start services which were configured
to start during install on that node (You can still start a specific service even
though it was not suppose to configure/start by calling startup script of that
specific services).
To explain this better, lets assume you installed
multi node R12 instance with Node 1 as Forms & Web Server where as Node 2
was installed with Concurrent Manager. Now on Node1 when you use adstrtall.sh
script to start services as expected it will start Forms and Web services but
unlike 11i, You can still start Concurrent Manager on Node1 by running
adcmctl.sh
—FND_NODES From R12 all nodes will have Y against
all services (For multi-node) in FND_NODES table.