The Hunger Site

Wednesday, February 4, 2009

More attempts to release the oci.dll lock

As a follow-up to the oci.dll locking issue and the use of unlocker that I explained
in an earlier blog post, when I conducted a session on "Patching with Grid Control",
a DBA suggested there was a Windows fix avaiable for the oci.dll locking issue.

I found Metalink Note 232827.1 which suggested that the svchost process
has the oci.dll locked on the machine. The note asked to shutdown Windows
services such as the Com+ Event System, MSDTC, and IIS. After
those services are shutdown the machine has to be rebooted in order for the
svchost process to release the oci.dll. The note suggested that these services
lock the oci.dll even though the user may not be using them.

I followed these steps, but it didnt make a difference. The ocii.dll
stayed locked even after the listeners were stopped.

The DBA then suggested to set the following registry key in Windows:



I already had this registry key set. so this was not the solution. I had to
reply on the previous unlocker strategy (see the previous blog post).

A further bit of reading suggested that Windows keeps dlls in memory on
purpose for a certain period of time even after the dll is not is use. This is
for performance reasons.

I do wonder why Unix has no such issues and the performance is still ok
in unix without such "hold things in memory for some indefinite time"
tactics. We never have such locking issues on unix.

A side note on this issue: when I removed and reloaded the registry key
"AlwaysUnloadDLL=1" into the registry, from then on whenever I tried to
start the Grid Control Management service, it failed to load. I remembered
reading somewhere on the internet that this registry key may be causing
a Java load issue, so I deleted the "AlwaysUnloadDLL=1" key straight
away, and the Grid Control management service started loading fine.
Windows - you can love it, you can hate it.

No comments:


Opinions expressed in this blog are entirely the opinions of the writers of this blog, and do not reflect the position of Oracle corporation. No responsiblity will be taken for any resulting effects if any of the instructions or notes in the blog are followed. It is at the reader's own risk and liability.

Blog Archive