Changes in Default AutoPatch Prerequisite Checking Behavior

Earlier versions of AutoPatch (adpatch) would automatically check whether the prerequisites for the current patch were installed properly.  An important change to the AutoPatch defaults was made in the Applications DBA Minipack 11i.AD.I.2 release:  automatic checks for prerequisite patches are now disabled by default. 

When you run AutoPatch AD.I.2 and higher, sharp-eyed DBAs may notice the following warning:
  Attention: AutoPatch no longer checks for unapplied pre-requisite 
patches. You must use OAM Patch Wizard for this feature.
Alternatively, you can review the README for pre-requisite
information.

As of AD.I.2 and higher, if you want prerequisites to be checked, you now must explicitly pass the parameter options=prereq to AutoPatch in addition to any other parameters that you may already be passing.  For example:
  $ adpatch options=prereq

This was a somewhat controversial decision within Development.  Proponents for disabling prerequisite checks correctly note that certain patches won't apply even when their prerequisites have been applied as part of other combined patchsets. 

The downside of this new default behavior is that you may end up applying a patch without knowing that the prerequisites are missing.  This is a particularly tricky problem to debug when dealing with technology stack patches.

So, our standing recommendations are to check a patch's README carefully, or just add the options=prereq parameter manually when running AutoPatch.


Comments:

I remember over a year ago when I pushed a TAR/SR on this very issue - it seems that the INV group refused to follow this procedure of making sure they're patches checked pre-reqs.

I ended up getting a call from someone (sorry, it's been too long) who explained the situation and said that the issue was being taken care of and I could expect changes soon that would get all product groups in sync on this issue...

So what did support do? Rather then fix the issue, they gave up. Now for every patch I apply, I have to go check all the pre-reqs and ensure we have them - vs. this being done by default. I mean really, you've always (via options=noprereq) had the ability to make adpatch skip this - why would you disable this by default? To help the beginnger DBAs? Aren't those the same people who need this info the most?

Posted by jay Weinshenker on April 23, 2006 at 06:29 AM PDT #

Jay, I agree with you. My opinion (stressing that it's mine, not Oracle's, and is an opinion, not a statement of fact) is that the decision about changing the default decision was not well-considered.

There have been a number of efforts to assess the consequences in the field. For example, I've personally asked Support Managers for our global Applications Technology Stack support teams to let me know whether this new behavior is triggering an increase in Service Request (SR) volumes. To date, the answer appears to be, "Nope - no appreciable impact."

So, if this new default is creating more problems than it solves, we don't have SR metrics that show that. So, here's your chance to let us know about it -- feel free to post more comments if you really hate this new default.

There's no guarantee that your comments will result in a switch back to the older setting, but I can guarantee that nothing will happen if you don't speak up.

Regards,
Steven

Posted by Steven Chan on April 23, 2006 at 03:16 PM PDT #

Hi,

I have done a lot of patching in our setup. We run 5 Production installations for our client (a syndicate of 5 local government agencies), plus test, dev, uat, support etc. Looking at out patch history, we have applied almost 500 patches on top of 11.5.9 for each of the environments.

Patching in Apps 11i has always been hit and miss, and my view on the "prereq" feature is that I could never trust it. I found on far too many occasions that adpatch would check for a pre-req using a specific patch, and if didn't find it then it would fall over - even if I had applied the patch that supersceded the original pre-req. My guess is that when a patch is supersceded, it really should be loading metadata that shows the prior patch has been effectively applied. I don't believe all development teams are doing this, hence the problem with using the "prereq" option.

On the subject of patching - one nasty habit I have seen a few times is when a patch is released on Metalink, then someone realises the patch has been built incorrectly, so they rebuild it and rerelease it with the same patch number. More than a few times I have downloaded a patch, had problems with it that baffle Oracle support, only to find out that Development has changed the contents of the patch without telling anyone! I think this is unforgivable, and while people make mistakes, the correct procedure to follow would be to immediately withdraw the old patch and then build a new patch to superscede it.

Patching became such a nightmare for us that we went and bought a Change Management Tool to do it for us (Quest StatACM). This has eased the burden a bit, but we still have to do a lot of manual checking when downloading patches.

Paul

Posted by Paul Murgatroyd on April 24, 2006 at 02:45 AM PDT #

Steven,

I have found Paul’s comments very close to my thoughts.
Just few additional comments:
- I think it is absolutely brilliant to have a tool which would tell you that you haven’t applied prerequisite. And it is an awful decision to have this functionality disables by default (especially having in enabled in first versions).
- But in the other hand I think there is no a reliable prerequisite analyzing tool available today. Instead of operating with patch numbers this type of tool have to work on the files level in the same manner as an adpatch utility analyzing if particular file delivered by a patch it training to apply have newer version then in the environment or not. I understand that it sounds to complicated to generate for each patch a long list with all files (and versions) that this patch is depend on, and after that let adpatch to check if there are appropriate versions of the files in place for a particular environment, but it seems that there is no other way hoe t o implement reliable prerequisite analysing tool.
- I have tried multiple times OAM Patch Wizard functionality to analyse prerequisite and most of the cases it fail to give correct results. I thing it is to new product for using it in production (relay on it if you wish).

PS It is absolutely fantastic that you have provided the way how to discuss this kind of issues with the responsible persons within Oracle (as was mentioned before Oracle Support Services have wrong goals [resolution time, efficiently etc], to provide efficient feed back to Development teams like yours).

Yury

Posted by Yury Velikanov on May 07, 2006 at 12:06 PM PDT #

Hi

We also had a problem or checking patch prerequisites manually and it took a lot of time because we apply around 25 patches a week on all our EBS enviroments.
Now we found a Patchdepend tool (www.patchdepends.com) that check Patch prerequisites very fast.

lee

Posted by lee on September 30, 2010 at 06:46 AM PDT #

Post a Comment:
  • HTML Syntax: NOT allowed
About

Search

Categories
Archives
« April 2014
SunMonTueWedThuFriSat
  
1
4
5
6
7
8
9
10
11
12
13
14
18
19
20
21
22
23
24
25
26
27
28
29
30
   
       
Today