Thursday, May 12, 2011

Oracle Patch Notes

[The header link is for the Oracle Support Document for 11.2.0.2 Patch 5; login to Oracle support is required].
I'm updating my development box with the latest quarterly critical patch update (CPU) from oracle. Actually, I'm going one step beyond that; Patch 4 is the CPU revision (from early April), but by the time I checked for the download, Patch 5 was available.
I'm installing this on a Windows Vista64 box; this information applies specifically to this combination (although it looks like this is a common windows/oracle issue).
The patch instructions are pretty standard: shutdown all oracle services, shut down the MS Distributed Transaction Coordinator service, and apply the patch.
This didn't work for me; there were two problems that I ended up having to resolve.
1. The installation log is documented as follows:
Inspect the opatch.log file generated in %ORACLE_HOME%\cfgtoollogs\opatch for any errors.
My first error messages indicated that the installer couldn't create the log file in C:\Program Files\Oracle\Inventory\logs. That ended up to be pretty easy to resolve -- my domain account didn't have permission to write to Program Files (and probably shouldn't have such permissions in general), so I had to grant "write" privileges to the \logs directory explicitly. This is one of those cases where "setup.exe" can do things that individual logins can't. Since OPATCH isn't named "setup.exe", you don't get the inherited ability to write to that directory.
However, access to the \logs directory wasn't sufficient. Opatch needed to do something to \Inventory\install.platform as well, so I needed to update permissions on that directory as well.
Lesson: The account used to run opatch must have write access to C:\Program Files\Oracle\Inventory and Inventory\logs.
(2) After resolving the permissions issue, opatch failed with a different error -- error code 74 -- with a long list of ora .dlls that were listed as "still active".
I had shutdown all services properly.
I had shutdown the Distributed Transaction Coordinator service.
So, maybe something got hung up, let's restart the machine.
No change -- same error, same files locked.
The error code 74 is common enough to get some Google hits, but the standard response is to "restart the database", or, failing that, "use this fine freeware application to review your open files and determine which service is to blame". ProcessExplorer (from msdn technet) to the rescue...
A process named “wmiprvse.exe” had the dlls open. That is the Windows Management Instrumentation service. Stop that service and you get:

Return Code = 0

The local system has been patched and can be restarted.

OPatch succeeded.

Don't forget to run catcpu.sql after the patch updated is complete!