Printable View
What's the best method for multiple installs (some are the same version) on the same server as far as the oraInventory directory is concerned?
There's got to be a better way than copying the /etc/oraInst.loc every time we install to a different $ORACLE_HOME.
One slip, and oraInventory will be corrupted.
Point the ORACLE_BASE and ORACLE_HOME to the location of ORACLE_HOME. This will create a new oraInventory under each ORACLE_HOME directory. Also you would have to remame the oraInst.loc file such that you will keep the oracle inventory loc for each installs.
I personally prefer to maintain the inventory under each home, such that messing up with one inventory will not mess the other installs. When you do any patch installs, you would have to reset the ORACLE_BASE to ORACLE_HOME. This will also help me to keep the jdk versions individual to each installs.
Sam
That is our current methodology and it resulted in a corrupted oraInventory when the oraInst.loc file was pointing to the wrong place during an upgrade of one $OH's.
It'll work if everyone is real careful, but isn't there a BETTER way?
Why not you write a shell script and execute it before every install/upgrade with the apporpriate value. Else write one with an interactive mode that would allow the user to choose between.
sam
/etc/oraInst.loc? What version of Oracle are you using that puts a file in the /etc directory? I've only seen /var/opt/oracle, created by running /tmp/orainstRoot.sh if /var/opt/oracle doesn't already exist.Quote:
There's got to be a better way than copying the /etc/oraInst.loc every time we install to a different $ORACLE_HOME.
Once the oraInst.loc file is created, OUI looks for the location specified in it, then reads the oraInventory stuff. You can have multiple Oracle products installed in their respective ORACLE_HOMEs, with all of that information stored in the original oraInventory directory if you let Oracle do what it wants to do.
The only time I've had to dummy up the oraInst.loc file is when getting abused by the iAS/iDS installation process, and that was going off the reservation for other reasons (needed to do that so iDS would install using the JRE directory created with the iDS install, and not using the JRE directory from a previous Oracle product install).
The path is not the same on all UNIX flavours. In HP it goes into /etc/oraInst.loc.Quote:
Originally posted by stecal
/etc/oraInst.loc? What version of Oracle are you using that puts a file in the /etc directory? I've only seen /var/opt/oracle, created by running /tmp/orainstRoot.sh if /var/opt/oracle doesn't already exist.
As KenEwald pointed, its not a practive a general oracle rep would recomend. I personally have been through some problem, which forced me to do an install from scrach. Its not as simple as you may think once the inventory gets corrupted. The practice what KenEwald had been following was a recomendation made to me from Oracle Inventory development folks long time back. This would keep the things clean, installations smooth. The only pain the one that KenEdwald had pointed out, possibility of messing it.
-Sam
You mean someone is still using HP-UX for UNIX? Where? Who? How often? When did you know about this, and what have you done about it? Our little HP box sits in a dark room, collecting dust, weeping gently, hoping for the day when it will be needed again.
HP-UX is still really popular in the telecoms industry - which is s ahame cos I cant stan dit. Any OS that can't automount a CD has some serious problems
BTW, stecal,
HP servers are the first certified configuration for the 9i RAC ;)
-Sam
HP and Oracle? Yeah, that's Oracle sleeping around with whomever will give them good press.
Nope in HP its in /var/opt/oracle/oraInst.locQuote:
Originally posted by sambavan
The path is not the same on all UNIX flavours. In HP it goes into /etc/oraInst.loc.
-Sam
In IBM its on /etc/oraInst.loc
we have both RS6000 SP and HP 9000 Series server over here.
We're migrating from HP to Linux. The Linux install puts oraInst.loc in /etc
By the way, the 9.2.0.2 --> 9.2.0.3 patch is really screwed up. Support finally suggested we reinstall base 9.2.0.1, upgrade the installer (2.2.0.12 --> 2.2.0.18), then upgrade to 9.2.0.3. That finally worked.
It was already mentioned on the 9.2.0.3 docs, that you have to upgrade your installer before applying the patch. Looks like you missed reading the README :)
Sam
I'm sorry, you're mistaken, I didn't miss the patch's README or the installer upgrade.
The 9.2.0.2 --> 9.2.0.3 upgrade file (a cpio file) for Linux extracted with errors. A couple other folks posted the same error on metalink forums.
The workaround was to leapfrog the 9.2.0.2 --> 9.2.0.3 upgrade.
Here is the extract from Metalink Patchset download site:Quote:
Originally posted by KenEwald
I'm sorry, you're mistaken, I didn't miss the patch's README or the installer upgrade.
The 9.2.0.2 --> 9.2.0.3 upgrade file (a cpio file) for Linux extracted with errors. A couple other folks posted the same error on metalink forums.
The workaround was to leapfrog the 9.2.0.2 --> 9.2.0.3 upgrade.
Code:
README for 2761332
Oracle 9i Release 2 Database Server Patch Set 2
with Cluster Manager Patch for Linux-32
Patch Set Notes
Patch Set version 9.2.0.3.0
This note accompanies the 9.2.0.3.0 patch set for the Oracle Database Server. It includes patches for the RDBMS , PL/SQL, Precompilers, Networking, Oracle Text (formerly interMedia Text), JDBC, JavaVM, XML Developers Kit, Oracle 9i Globalization, Oracle Core, Ultrasearch, Spatial, SQL*Plus, SQLJ, JPublisher, Intermedia, OLAP ,Oracle Internet Directory, Oracle XDK and Oracle Intelligent Agent products.
This is not a complete software distribution and you must install it over an existing 9i Release 2 Oracle Server installation.
Users applying this patch set must use at least the Oracle Universal Installer 2.2.0.18.0 to insure their Oracle Home can
be patched in the future. The OUI 2.2.0.18.0 is available for download from Oracle Metalink where it can be accessed with
the bug number 2878462 and choosing the Linux32 platform. This is further mentioned in the "Installing the Patch Set" section.
Post Release Issues
Issues that are discovered after release of this patch set are documented on the Oracle Metalink website. Customers should check here for the latest status prior to installing this patch set in a production environment.
To see the latest Status and Alerts for this patch set, please read Doc.Id: 189908.1 available through Metalink.To find this document on Metalink, after logging in, simply type 189908.1 in the search field and click on the 'Search' Button .
Customers unable to utilize this Web site should contact Oracle Support.
:)
Sam
Technically, if anyone is going out to do this, it is patch number 2878462, not bug number. If you do a search based on Bugs, nothing is returned. I just went through a little clown show with OSS about them correcting this readme.Quote:
README for 2761332
The OUI 2.2.0.18.0 is available for download from Oracle Metalink where it can be accessed with the bug number 2878462 and choosing the Linux32 platform.
At least you don't need to reboot it when adding a volume like Solaris. I mean, that's something even Windows can handle without rebooting. :rolleyes:Quote:
Originally posted by stecal
You mean someone is still using HP-UX for UNIX? Where? Who? How often? When did you know about this, and what have you done about it? Our little HP box sits in a dark room, collecting dust, weeping gently, hoping for the day when it will be needed again.
Thanks for making your point Sam. I read the note and didn't skip the installer upgrade.
So far, we've been really impressed with the performance, flexibility and low cost of Linux on Dell.
We're beginning to test our databases on Linux. So far, I'm not convinced that it's solid enough to put into production. That's probably just us getting comfortable with Linux though.
Have a nice day