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.