Oracle EBS Patching
A Patch which fixes a bug (or) enhance/add a particular feature in existing program.
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 :-
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 :-
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.
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
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.
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
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.
(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
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.
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.
================
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.
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.
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
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.
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.
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.
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.
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).
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.
You cannot run multiple sessions simultaneously (concurrently). However, patches can be merged and applied in a single patching session.
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.
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.
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:
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
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.
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.
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.
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.
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.
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.
No comments:
Post a Comment