Software Deployment Question

Multiple Oracle Clients

07/08/2008 19109 views
Hi folks - I've been given 2 Oracle client packages (9 &10) to troubleshoot..[:'(].
The installs are MSI captures and someone elses work entirely..leading to even more [:'(][:'(].

From previous posts I see that if you require multiple Oracle clients simultaneously, then NO package should create the ORACLE_HOME environment variable.
If it is set it will force the installed Oracle apps to use the directory specified in this variable as the definitive oracle home.
But our 10g MSI does set this variable to point to its own installation dir.
Should I remove this ORACLE HOME env. var?


Also - 9i creates an ORACLE_HOMES registry key under HKLM\SOFTWARE\ORACLE.. this location is common to all other Oracle client installs.
So is this pretty much the same as the env. variable? i.e. doesn't this key also try and force other installs to use this specific Oracle home too?
Or is this a necessary registry setting i.e. do you need one oracle as the default home always?

If the registry key remains as it is (pointing to the 9i install directory) - how do other Oracle applications find their desired Oracle client? By using the PATH env. variable? or by using the oracle.key file contents?

I've packaged multiple Oracles before myself..kept no notes of course so am scratching my head once more.. aagh

Any help is much appreciated.

0 Comments   [ + ] Show comments


Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

All Answers

I've had success doing multiple vendor installs using Oracle's installer - not a repackage.

More experience packagers have gotten around the multple Oracle_Home problem using scripting. Look in the archive in this forum for some clues. I haven't had the chance to try it out yet.

What problem are you having? I've found the best way to check if Oracle works AT ALL is to do a tnsping directly from the command prompt of the version you want to test, and ping a known good Oracle instance.
Answered 07/08/2008 by: aogilmor
9th Degree Black Belt

if you go down repackaging path you need to do this.

change all registry entries from


You need to lookup the LastHomes and HomeCounter values during install, increment by one and set that value to ORACLEID and ORACLE_HOMECOUNTER

the oracle.key file is independant to each installation and needs to contain the matching Oracle_Home counter for that specific installation. I did this with a CA like this from memory

SetOracke.Key, 1058, SystemFolder, echo > HKLM\Software\Oracle_Homes\Oracle[ORACLEID]

If you do a search for OracleMSIFix.vbs and OracleRegfix.vbs you should be able to find to vbs scripts I wrote to automate the whole process with Windows Installer automation object.
Answered 07/08/2008 by: jmcfadyen
5th Degree Black Belt

Hi Owen\John - thank you both for your responses.

If it were a fresh start I would definitely introduce a managed\dynamic process for the assignment of Oracle homes.
John - scripting is a great idea. Before I posted I did a search here and read the other posts you've contributed to. It's something I will def. look to adopting in the future.

The approach that was adopted on a previous site was to designate each Oracle its own unique home - a list of the homes was centrally managed - if a new Oracle install became available for packaging we just appended to the list of homes taking the next available increment. You don't need to look at the ORACLEID or ORACLE_HOMECOUNTER with this approach either.
So no conflicts between Oracle homes.

Unfortunately - in this instance the Oracle packaging is managed by a different packaging team - it looks like they have correctly assigned the homes in the registry so that is not the issue.
I think they have made the mistake of including the environment variable "ORACLE_HOME"

So if I could reiterate the original question - does the ORACLE_HOME env var force all oracles to use a certain directory as its home thus breaking other versions?
Also, are the registry keys under HKLM\SOFTWARE\ORACLE detrimental if we want multiple Oracles to coexist?
e.g. 2 of the keys are ORACLE_HOME, ORACLE_HOME_NAME - are they required at this level as defaults or can they be removed?

I'd ideally like to fix all the Oracle packages that are available for install but I'm not privvy to interfering the approach originally adopted by 'more enlightened' people.. I just need to fix the above installs for our site. Hence the mention of the specific keys and env. var.

Once again thanks for your responses thus far.
Answered 07/09/2008 by: sh79
Senior Yellow Belt

to be entirely honest I dont recall having an issue with this env variable. I haven't packaged much in over a year now, nor do i have access to old source etc as I have moved projects many times since my oracle days.

Sorry I can't check that up for you.
Answered 07/09/2008 by: jmcfadyen
5th Degree Black Belt

Just thought I'd post one last time on this..maybe someone will find it useful.

I've dug up a document that described the process used on one of my previous contracts.
It does look like the ORACLE_HOME environment variable forces existing Oracle installations to use its value as the definitive HOME.

Example, lets say an Oracle 9i application is launched. It sees the ORACLE_HOME registry key that appears under HKLM\SOFTWARE\ORACLE\HOME[oracle9_dir].. it uses this path contained in this key to find the necessary Oracle 9i files.

Now introduce an env var called ORACLE_HOME - even though the application knows it has a HOME as described in the above registy key it is still strong-armed into seeking out files in the location as designated by this env variable.

The ORACLE_HOME env var could be considered a reserved word in Oracle - if it says look in this location, then thats what all the Oracle applications will do - it would seem that it has precedence over the registry.

One last thing - most of the registry keys created in HKLM\SOFTWARE\ORACLE can be deleted from the Oracle captures\snapshots as they also appear under each Oracle home.
I've asked an Oracle DBA to confirm this but unfortunately he couldn't.. all I know is that in the past when I did package Oracle applications for coexistence this is what I did and never had any problems.. and guess what.. that doc I found describing the Oracle packaging process - well I wrote it.. if only I had found it sooner [8|]

Thanks guys for you help.
Answered 07/10/2008 by: sh79
Senior Yellow Belt


The registries under HKLM\software\oracle should not be deleted.
Rather you should make the app work such a way that it detect the Home and increment it
with the help of system search and Custom action and also replacing for e.g
OracleHome0 with OracleHome[Homeindex] as mentioned above wherever necessary also the Homepath location need to be set using SET Property CustomAction say HOMEPATH=C:\oracle\ora92 and replace it with the property defined.

Answered 08/19/2008 by: shweta_kar
Blue Belt

Thanks for the response shweta-kar ..but i think you might have misinterpreted my question & final suggestion.
You are focusing on the assignment of an OracleHome.. but this is not being queried.
I understand the necessity of having separate oracle homes and can appreciate the many different methods of designating a home for new oracle applications.

Neither am I talking about deleting all the registry information under HKLM\software\oracle but rather just deleting the registry 'names' and 'data' under this key.
i.e. leave all the sub-keys as they are, but delete the registry names and data on the RHS of the key HKLM\software\oracle. You will see that most of these keys are common to every individual Oracle installation.
Since they are common to different Oracles it is obvious there will be a clash. The last Oracle application that gets installed will overwrite these keys with its own values - this has nothing to do with the correct assignment of the Oracle homes. That is a separate matter entirely.

Anyway, as I've pointed out, I've deleted these keys numerous times and have not had a functional issue with Oracle to date.
Answered 08/19/2008 by: sh79
Senior Yellow Belt

This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ