The windows registry HKey_Local_Machine\ORACLE\Key_OraDb11g_home1 key has a Value field named SQLPATH

When you run a file from insied sqlplus using @ or “start”, sqlplus will search any folders listed in sqlpath for the file.

Also on starting sqlplus, it will check folders listed in sqlplus for any file named “login.sql”. If it finds a file, then this gets run before a prompt is presented. Also if any “connect /” is done in sqlplus, then a login.sql is again run.

Problem:

If my pc does a sqlplus/nolog then I do not want my login.sql to do anything (because there is no connection)

Likewise once someone is connected, if they do a “connect sys/password as sysdba”, I do not want my login.sql to do anything (namely because this blocks OEM from starting/shutting down my database)

Otherwise for any non-sys/non-system connect, I do want a login.sql to be run.

Solution:

In sqlplus there are some predefined variables.

You can see these by typing “define”. The following is what you get after a sqlplus/nolog

I decided to try Virtual PC on Win 7, mostly because my laptop has the hardware virtualization. Also vmware website was not taking registrations last weekend. Also wanted to see if the lack of linux support would cause any issues.

I left the Virtual hard disk with its Total Disk size set to 130GB and dynamic type. My budget is 20GB. OEL 5 does not seem to grab the full size, but supports the dynamic nature of the Virtual hard disk file.

5. Changed the vm settings to point the DVD drive to the OEL 5 dvd iso file.

From some scattered references on Metalink, it seems that Oracle does interact with WMI on windows.

For my second attempt, I could have turned off the “Windows Management Instrumentation” service. As I was testing on my own machine, I decided to kill the wmiprvse process which had the Dlls open.

The second attempt again using OEM failed as the nmo.exe process was locked and this again caused the “CheckActiveFilesAndExecutables” failure.

This time I tried an old win3.1 trick. I renamed nmo.exe to nmo.exe_dis. So nmo.exe could be replaced.

The third attempt using OEM failed. OEM did not get as far as checking for pre-requisites. It seems that OEM needed the nmo.exe executable file.
nmo.exe seems to be Oracle Network Manager Objects. This is part of the Oracle networking stack

I read a post on otn which said that Oracle had not guaranteed that OEM could install all patch sets. Some CPU (Critical Patch Update) would need to be installed via opatch. Unfortunately I did not save the url.

Attempt four used opatch. I shutdown the oracle related services. The attempt failed again for “CheckActiveFilesAndExecutables”. This time, onmly the dlls were listed (not nmo.exe).

So attempt five using opatch involved killing the wmiprvse.exe which was locking the DLLs and it did work. The CPU (Critical Patch Update) was installed.

The Readme for the Jan2010 CPU descibes installing using opatch. I did not see any reference to using OEM. I decided to try OEM just as an exercise. I am impressed with the way OEM shutdown the dtabase and services during my attempts. My Learnings:

1. OEM cannot install all CPUs (Critical Patch Update). Sometimes opatch needs to be invoked at the command-line to get around nmo.exe being active.
2. WMI impacts by loadings some of the oracle dlls. I have not seen any instructions about how to avoid this. Shutting down the “Windows Management Instrumentation” service for the duration of the install would probably work.

Note all of the above was tested on my test installation. If it was my employer’s database, the a lot more care would be applied.