In part one of this series we looked at the plan of attack that we took when bringing an unpatched Oracle applications 11.5.10 infrastructure to the current critical patch level. At the end of this we had a control spreadsheet (template here) with 18 technology patches and 66 applications patches to consider. That's a lot of patching. Those of you who are used to applications patching will know that that isn't necessarily the end of the matter. Oracle Applications patches often have dependencies on other patches. There is therefore some more work to be done in determining whether any more patches are required.

The easiest way of doing this in 11.5.10 is to use the Applications Patch Wizard. This is what I did as a first cut. However the Patch Wizard isn't, well entirely reliable, there's a list of some of the issues with the Patch Wizard in 11.5.10 right here. In particular the patch wizard might

• not notice that you've already applied a pre-requisite.
• not notice that you haven't applied a pre-requisite.
• recommend an inappropriate patch - we'll come back to this later

Both of these considerations mean that you should also review the individual readmes of the patches you will be applying. This is particularly important for applications patches in any case because often the readme will contain other instructions that you should also note - for example you might be directed to clear the _pages cache.

The patch wizard will take a comma separated list of patches, download them and analyze against your current build level. Be aware though that there is a limit to how long this patch string can be, and exceeding it will result in the analysis failing. We learned this the hard way. I therefore split the analysis into 5 separate lists (the bottom 5 in the screen shot below.)

You'll see if you look carefully enough that not all the patches were recommended for application, what you can't see because the patch list column is so wide is that there are further detail buttons over on the far right of the screen. Clicking on one of these presents you with an analysis that looks like this

This page should show you the necessary prerequistes - for example Patch 5013805 in the above has a prerequisite  - in this case by the way the 'prerequisite' tag is a bit misleading since this patch fixes an internal server error introduced by CPU October 05.Having completed this task and reveiwed all the relevant readmes - this took over a day, there are only so many readmes you can read without losing the wll to live - we had downloaded (the patch wizard does this for you another good reason to use it) and identified all required patches. At this point we decided that it was well worth considering merging all the apps patches so that we would only have one large patch to apply to the system. Merging doesn't always work well, but for CPU patching - where a relatively small number of focussed vulnerabilities are being patched we thought it likely that a merged patch would work and save considerable time. Merging is done by use of the admrgpch utility as follows.

• create a source directory with the unmerged patches - we could use the patch stage directory used by the patch wizard here
• create a target directory for the merged patch.
• issue the command admrgpch -s source_directory -d dest_directory
• review the log file.

When this had been done successfully we finally had all the necessary patches on disk, ready to apply.

Next time we'll look at the actual application process, some timings and some issues that we need to bear in mind.

I'm not normally one for blog series. Call it a short attention span, call it an old style approach to blogging, call it what you will but I tend to write about whatever is currently on my mind. Never the less what is on my mind at the moment is the application of Oracle's released Critical Patches to an E-Business suite infrastructure with none applied. I'll be presenting on this subject at theUKOUG in December so if you want to tell me just how badly we did it then catch me there. This topic is rather too long for a traditional blog post, and whilst I do intend to write this up as a longer article - to go with the presentation - I thought I'd try a short series working through the steps.

This post will cover the procedure used by the author for applying the critical patch updates (CPU) released from Jan 2005 up to April 2007.  This series is based on an Applications system with ATG Rollup 5 (metalink registration required) already applied. Whilst the general approach in this paper is likely to be widely useful, individual software levels will mean that precise details of patches required will vary from site to site. This is another way of saying - don't take my list of patches as gospel.

The broad approach I took was as follows. - This will serve as a useful road map for the series by the way. 

1. Obtain a List of all patches issued as CPU.
2. Determine any prereqs required.
3. Obtain patches
4. Review all readmes
5. Upgrade databases to current patch level where appropriate
6. Apply CPU updates to tech stack (OID/IAS, DB, 806_HOME. IAS_HOME)
7. Merge the Apps patches for quicker application

 When I reviewed the various CPU documents on Oracle.com websites (metalink and the main oracle.com CPU site) I realized that the list was way too long! Our architecture looks a bit like the diagram below (where the black boxes are the databases - blame the conversion from visio to png for that.

Consequently I decided that a control spreadsheet was needed that could be updated as the process went on. At the start it looked like this. That's a lot of work to get through. Over the next few parts we'll work through how it went and what we learned along the way.