This is a short script with notices about the employment of the 11gR2 patch set 2 (aka 184.108.40.206) oracle fat client on windows x64. That is, saying fat client, I’m talking about the classic client side software collection, featuring oci.dll at most as well as other .net and java and the like things.
I’m definitely not talking about the instant client stuff invented with oracle releases 10g or so.
I already have a running 220.127.116.11 oracle fat client around, such that I’m discussing an update here but quite a lot of information will also be interesting iff you’re planning a fresh installation of the 18.104.22.168 oracle fat client.
Finally, the deployment platform in question is windows 7 x64, which takes importance when examining the different patching strategies that oracle does meanwhile run for *ux (PSU/CSU) and win (none such) plattforms. Let’s get started.
The problem of oracle dll files being still active (and locked against modification) inspite of a clear shutdown of all oracle services on windows has been around for lightyears it seems.
What changes, though, is the net of dependencies that has to be checked prior to an upgrade or patch execution to find the processes that actually keep hooking up the dll’s in question. I was hit again lately, when trying to apply the server 22.214.171.124 Patch 18 (the APR2013 bundle patch) on win x64. The infamous error message on executing opatch apply read:
Oracle Interim Patch-Installationsprogramm Version 126.96.36.199.3
Oracle Home : e:\oracle\product\11.2.0\dbhome_2
Central Inventory : C:\Program Files\Oracle\Inventory
Verifying environment and performing prerequisite checks...
Prerequisite check "CheckActiveFilesAndExecutables" failed. The details are:
Following files are active :
Recommended actions: OPatch needs to modify files which are being used by some processes.
OPatch failed with error code = 41
this is not a raw technical discussion of how to install oracle patch sets or how to circumvent known patch set bugs. this is a run down presentation of my most annoying experience of installing oracle software lately. an expression of anger about intransparent documentation structures and versioning, permanent manual intervention, enormous effort in time and cost and, finally, inefficiency. but let’s see what happened.
i recently installed the so called Release 10.1.0.5 Patch 28 for Microsoft Windows (32-Bit) on a lab- and a couple of production-machines. so far, everyone knows that installing oracle patches is not an easy job. you need to figure out what patch to install actually and download the patch for a dedicated database and operating system software version. mostly, the actual patch, to be applied properly, requires other patches to be applied a priori and a posteriori. in the case of the mentioned patch, which is a bundle of interim patches, even the patch installer OPatch had to be patched in advance. but that’s not the whole story. wrapped within the newer OPatch oracle automatically distributes OCM, the oracle configuration manager.
to sum it up i had to take regard of the following patches, in that order:
p6880880_101000_WINNT – installs a newer OPatchand hooks in OCM
p5746866_10105_GENERIC – fixes timezone files
p7367493_10105_WINNT – my actual intend
applying this series of patches may be executed in two ways, depending on whether you already know about the hidden OCM-introduction.