Oracle EBS Patching

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.

TROUBLESHOOTING

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.