It appears that blogging about Oracle (something I've been doing since March 2004)  will get you a press pass to open world this year. Now the whole disclosure/expenses thing has been debated at length elsewhere, and we know where Oracle are on this. Now a free pass to open world might be interesting to me, but when I check the flight and hotel is almost exactly gbp 2000 - for my American readers that means this offer would amount to a personal commitment of a little over 4000 dollars. It's safe to say I won't be going at that price. I know Jake and others considered that perhaps travel expenses would influence the coverage - perhaps for next year this little example will suggest why in fact it influences the lack of coverage.
 

A new blog to watch, and you can catch up with it from Day 1. Those highly talented, successful and enviable chaps over at Miracle have started a training program with a difference. They've taken on a guy with pretty much no prior Oracle experience and aim to put him through a rigorous practical internship. I've been privileged enough to see a few of the things likely to be thrown this guy's way. 90 days in Hell is a pretty good title for the experience I feel. Jan is to be commended for daring both the program and to share the experience with the world. Right now Jan is starting withTom Kyte's latest book which is the introductory material for this course. You can probably judge just by this fact that the aim is to get someone out in 3 months time who will stand comparison with people who've worked for a few years in the industry.
I can think of only one other internship program like it, Joel Spolsky'sinternship program over at Fog Creek Software. There the focus was on software development, but a similar approach of teach people stuff by doing and learning from some of the best in the business while you are at it.

I turn 40 today, and as a nice birthday present 64bit 11g turns up  on OTN. If you told me when I was 20 that I'd be celebrating 40 with a software download and taking my 5 year old to a school disco, well I'd never have believed that I could turn into such a sad old man so quickly..

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.