Oracle installation
Yesterday, I had the displeasure of installing Oracle 9i (9.2.0.whatever) on one servers in the collection of soon-to-be demo machines. Some comments about this:
1. There’s the years-outstanding issue of needing an X server to install the damn thing. In Oracle 7 days, and possibly 8.0, back before this whole silly “i” thing got rolling, Oracle was a pleasure to install: just use a text log in and go through the install in text mode. The DBA class I took years ago mentioned the GUI installer, but we used text mode for everything (instilling or reinforcing in me a long-held bias against GUI tools for DBA work). It was neat: you don’t need fancy graphics if all you’re doing is selecting a bunch of check boxes. Curses-based displays might be necessary, and was for orainst, but, hey, that’s no big deal. But for the past few years, since the dreaded “i”, we’ve had to run GUI install tools. Not just any GUI install tools, but Java-based GUI install tools, ones that would barf all over the multi-windowed Exceed X server I had running: I’m forced to kill all my X clients to set up single-window Exceed, or find a Sun box and put a head on it just to install the software. Big, slow, piggish, with little added functionality. I’m told there’s a way to script the install procedure so that a GUI isn’t always needed, but the GUI is needed the first time through to do the script, and we don’t do enough Oracle installs to make that worthwhile.
2. 500MB of /tmp free space on Solaris just to install?! Oh my god. Well, not the copying of the software from CD to $ORACLE_HOME, but the relinking that’s done to prepare Oracle binaries is what burns up all that space. This is insane. 500MB of free /tmp on a Solaris box implies at least 800MB of swap + RAM, say, a gig to be safe, since our box with 756MB swap + RAM got blown out. I remember installing an Oracle 7 on my rickety old Sparc5, with maybe 64MB of RAM and a tiny 2G hard drive, with Solaris already installed and probably only a 192MB of swap. We hadn’t run into this problem before, since we were installing Oracle on Enterprise boxes, which did have a gig or two of RAM to throw around on them, but this install was on an old Ultra 10. In this sense, Oracle doesn’t want to be bothered with installations for developers’ personal use, to, say, prototype before moving on to the enterprise boxes. Or they figure they’re all running Windows for dev work, and probably Oracle Personal edition (or whatever the 9i version of things is called) installs OK on PCs.
3. The new thinking about the init.ora parameters file confuses me. But this is less Oracle’s stupidity than my falling behind the times in the DBA world. A few months ago, my old boss asked if I could consult on an Oracle installation he was dealing with at his new job up in Westchester. I declined: the work sounded more difficult that I could reasonably claim to be able to do, since my skills were very rusty, and there would be some forensic work involved (they were firing the current DBA, and they weren’t sure what he’d done to the databases). I can set up instances of Oracle, network them in a basic way so that JDBC clients can get to them, and make sure they don’t fill up, etc. It’s basic work, but it’s all that’s required right now. We’re not running databases that have to be up 24/7/365-or-else. We’re not even running databases that have to be particularly large or fast, just good enough for developers to work on, and then take their work over to the clients installations, where real, fulltime DBAs can set up their systems optimally.