ADPatch - Rush-up

This post is about basics of Applications patches and its options.


ADPATCH Options
You can execute adpatch by logging in as the applications OS user and sourcing the appropriate environment file.
#su - applmgr
$cd SAMAPPL
$. ./APPSORA.env
$adpatch

By default adpatch does not take any clause, but there are some clauses that you could use with adpatch.
Running a patch in test modeYou can use the apply clause with adpatch to specify weather to run the patch in TEST mode or not,
when you run the patch in test mode it does not do any changes but runs generates a log file with all the actions it would have performed.

$adpatch apply=ny
The default is apply=y
Pre-install Mode You can also run a patch in pre install mode, this would be done normally during an upgrade or consolidated update. When a patch is applied in a preinstall mode the all the AD utilities are updated before the upgrade or update .

$adpatch preinstall=y
The default is preinstall=n
Other Options with adpatch
You can use the options clause to specify some of the other options available with adpatch.
AutoconfigYou can use the options=noautoconfig
top specify autopatch that you do not wish to run autoconfig as a part of the patch application. This can be useful when applying a large number of patches when they are not merged.

By default autoconfig is run as a part of adpatch.
$adpatch options=noautoconfig

Checkfile
The chekfile option of adpatch tells adpatch to check for already executed exec, SQL, and exectier commands.
You can use
options=nocheckfile
skips this check, however this can cause performance overheds so should be used only when specified.
$adpatch options=nocheckfile

Compile DatabaseBy default autopatch compiles the invalid objects after the patch application, in case you wish not to do so you can specify

options=nocompiledb
along with autopatch.$adpatch options=nocompiledb

Compile JSPBy default auto patch compiles the java server pages (jsp) after the patch application, in case you wish not to do so you can specify
options=nocompilejsp
along with autopatch.

$adpatch options=nocompilejsp

Copy PortionIf you wish adpatch not to execute the commands present in the copy driver portion of the patch you can use the

options=nocopyportion
.$adpatch options=nocopyportion

Database Portion
If you wish adpatch not to execute the commands present in the database driver portion of the patch you can use the

options=nodatabaseportion.
$adpatch options=nodatabaseportion

Generate Portion
If you wish adpatch not to execute the commands present in the generate driver portion of the patch you can use the

options=nogenerateportion
$adpatch options=nogenerateportion

Maintenance Mode
If you wish to apply a patch regardless of the system being in maintenance mode you can use options=hotpatch.
$adpatch options=hotpatch

Integrity Check
If you wish to check the integrity of the patch you can use the options=integrity. Since metalink patches are pre checked for their integrity it is generally not required to do an explicit check and the default value is nointegrity.
$adpatch options=integrity

Maintain MRC
You can use the
maintainmrc option to specify weather you wish adpatch to execute the Maintain MRC schema as a part of the patch application or not. By default maintain MRC is done for standard patches and is disabled for translation and documentation patches.
$adpatch options=nomaintainmrc

Pre requisite Patch Check
If you wish adpatch not to check for pre requisite patches before application of the main patch you can use

options=noprereq.

By default pre requsite checking is enabled.
$adpatch options=noprereq

Validate Schemas
If you wish adpatch to explicitly validate all the registered schema by making a connection you can use
options=validate.
By default this validation is not performed.
$adpatch options=validate

Java Classes
If you wish adpatch not to copy new java classes from the patch you can use
options=nojcopy.

By default java classes are copied.

$adpatch options=nojcopy


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

Relinking
If you wish adpatch not do perform relinking you can use
options=nolink.
$adpatch options=nolink

Generate Forms
If you wish adpatch not to generate the forms files you can specify
options=nogenform.
$adpatch options=nogenform

Generate Reports
If you wish adpatch not to generate the report files you can specify
options=nogenrep.
$adpatch options=nogenrep

You could specify multiple options at the command line using the , delimiter.$adpatch options=hotpatch,nojcopy


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.
ConsistencyThere 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 ApplicationSchedule 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 PatchIn 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 PossibleIn case your business can afford it you should opt for automating the patch application and management process using third party

Below are categories under which Oracle Application patches are divided.

Standalone or Individual Patches - These kind of patches are delivered to fix a one off bug or introduce a new feature in any of the oracle applications products. Mostly these patches would be independent and unrelated though they might require certain pre requisite patches to be applied.
Mini Packs - These are a consolidation of various standalone patches for a particular product in oracle applications like AD,GL etc. The naming convention for mini packs would be in the form of 11i.. such as 11i.AD.I.Mini packs are cumulative in nature that is AD.I would include all the bug fixes that were included in AD.H and so on. Prior to release 11 the mini packs were referred as patch sets.

Family Packs - A family pack is a consolidation of all the mini packs and various stand alone patches for a particular oracle applications product family. The functional grouping of application products forms a product family like financials HRMS etc. The naming convention of these family packs are in the form of 11i. like 11i.HR_PF.K.As in the case of mini packs the family packs are also cumulative in nature.
Consolidated Updates - Since the time between releases of oracle applications is significant, a number of patches mini packs and family packs would have been introduced. A consolidated update as the name implies is a consolidation of the recommended patches that have been released up till the date of the release of the consolidated update. A consolidated update brings the entire oracle applications system to the latest recommended patch level. The consolidated updates are in the form of CU like CU2.Consolidated updates are also cumulative.

Technology Stack Updates - Recently oracle has started to introduce a new type of patch know as the technology stack update, these include consolidation of patches and mini packs for the underlying technology stack. As a result they do not include any functional patches. An example of technology stack update is 11i.ATG_PF.H.Technology stack updates are cumulative.
Maintenance Packs - A maintenance pack is a consolidation of all the mini packs for all products and all the family packs for the entire oracle applications. Maintenance packs upgrade the system from on release to a higher release for example when you apply the 11.5.10.2 maintenance pack to a 11.5.9 system you upgrade your entire oracle applications to a higher version.

Critical Patch updates (CPU) - Every quarter oracle releases critical patch update that addresses the security vulnerabilities and alerts that have been identified. The critical patch updates were introduced in 2005 prior to which security alert were used address the security fixes for oracle products.

Translation Patches - In a multilingual environment the patches are first applied in the base language. After that a translation patch is required to be applied for each of the additional language installed. The translation patches would be in the form of _ like 3460000_FRC implies the Canadian French translation patch for 3460000 (consolidated update 2).

Recommended Patch List (RPL) - A recommend patch list is a list of patches for a particular oracle applications product. The RPL is not a patch but just a list of recommendations. In fact the consolidated updates are built up on the RPL based on the cut off dates for inclusion .