There have been times when I would have paid extra for (1) a character-mode
installer and/or (2) a reliable and consistent way to create a listing of
EXACTLY what was installed (e.g. the long-defunct "instver").
I think I've installed Oracle with just about every mechanism they've had
since Oracle 5 came out - cpio from tape, custom platform-specific scripts,
a few dozen floppy disks (Xenix & DOS), orainst /c, orainst /m, and
runInstaller. The java-infested runInstaller is one of the worst pieces of
junk that Oracle has ever forced upon the user community. I've made it a
point to express this opinion to several rather senior people at Oracle. A
few - from the technical ranks - have even agreed (off the record of
course). For one thing, "making it easy to install Oracle" makes it far too
easy for the clueless to install it poorly!
Some of the comments like "Any machine that's need to run a production
database should be strong enough to run Java ok" miss the point entirely.
For one thing, not all Oracle installations are on production servers. More
importantly, the vast majority of Oracle installs are NOT done at the system
console. At my last two jobs, we used Exceed Hummingbird - which had quite
a few problems with runInstaller. At my current job, we use Reflection-X.
It seems a bit better - once you learn the quirks. (Hmmm... The first
screen is chopped off at the bottom so the buttons are invisible... Hit
return to go to next screen... Still invisible... Minimize... Click the
minimized icon on taskbar to restore... OK The buttons at the bottom are
visible now...). If you think that sounds like fun, try it over a dial-up
connection.
However, if you really want to experience ruinInstaller (pun intended) in
all its glory, try a cluster install sometime. I spent at least a couple of
man-weeks over the last five years fighting it, trying to diagnose problems,
trying to get it to work correctly - and have NEVER seen it actually work.
A typical cluster-based install with ruinInstaller usually goes something
like this:
loop until entirely sick of it
1) Perform cluster-based install, for which runInstaller reports successful
completion.
2) Go to any node other than where ruinInstaller was run to find that
a) not all the components were copied across
b) only parts (or nothing) got relinked
c) some components were installed, but cannot be recognized by local
ruinInstaller (hence can never be patched or upgraded)
d) all or some combination of the above and/or other major aggravations
3) Fumble around trying to find out why ( with little or no luck)
4) (optional) check Metalink - no help
5) (optional) Call support...
a) "We've never heard of a problem... "
b) Are you sure the server is plugged in? ..."
c) "Can you rcp/rsh between nodes?" (YES!)
d) "Are you sure?" (Well it did copy about half the required components
over... and I can rcp and rsh between nodes as the oracle user - outside
ruinstaller.)
e) ad nausem - perhaps apply some iffy hack that doesn't end up solving the
problem (e.g. "Try it again. When you reach the xxxxxxxx screen, open
another shell session, convert the zzzzzzzz.mk file to pig latin, put three
pennies in the Pepsi machine, go out to the parking lot, and perform a Hopi
rain dance. Then select <NEXT>. It should work now.")
6) Wipe all nodes completely clean and start over
end loop
Then... (optional)
Call somebody deep inside the mothership at Oracle and ask them about this
nightmare - and find out that it actually is a known, but largely
unadmitted, problem! Once someone on the OPS development team even supplied
a convoluted deep-geek hack to make it (almost, 99.2%-ish) work.
Finally...
Give up on the cluster install and just install the software individually on
each node. The problem here, on a complex install at least, is in trying to
determine exactly what options were selected everywhere so that you actually
have the same executables on every node. [Checking it with a file dump of
the "Installed Software" isn't very helpful since it seems to generate the
list in pseudo-random order as a hierarchical tree ("diff" doesn't work very
well).]
After the first dozen or so attempts (on several different platforms, with
several different versions of Oracle8 & 8i), I simply decided that I
wouldn't bother attempting another cluster install with ruinInstaller again.
Don Granaman
[OraSaurus and command line curmudgeon]
----- Original Message -----
To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]>
Sent: Tuesday, July 09, 2002 3:47 PM
What I wouldn't give for "./orainst /c" right now.
<RANT>
Where is the productivity and ease of use of the #$%^#@ OUI when it takes
hours and hours just to load up all the java crap! Piece of garbage is
enough to make me want to go back to 7.3.4 - and shoot the idiot who thought
up java...
</RANT>
Thankyou. I feel better about hating 9iAS now.
Scott Shafer
San Antonio, TX
210-581-6217
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author:
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Don Granaman
INET: [EMAIL PROTECTED]
Fat City Network Services -- (858) 538-5051 FAX: (858) 538-5051
San Diego, California -- Public Internet access / Mailing Lists
--------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: [EMAIL PROTECTED] (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
