The latest and greatest version of the Oracle database, 11g Release 2, was made available recently and as the resident technical person at ZDNet.com.au, it fell to me to take it for a spin. Little did I realise the hell that I had just walked into.
I will admit that two of the following mistakes are my fault entirely and could easily be fixed, but the third and final one is enough to drive anyone mad.
Mistake #1: choosing an "Enterprise Linux" as a test platform
The Asus server that was about to cause endless stress (see next mistake) came with a copy of Windows 2008 R2 on it. That's a bit of a problem since Oracle 11g Release 2 is only currently available for Linux
No biggie, I'll just put Ubuntu server on there and we can live happily ever after. Wrong! The database's operating system requirements demand Asianux, SUSE Enterprise, Red Hat Enterprise, or Oracle Enterprise Linux and an X server. The headless Ubuntu server would not be any good in this trial.
Since I was testing an Oracle database, I figured that I'd take Oracle Enterprise Linux (OEL) 5.0 for a spin as well. Bad move. The catch with OEL is that you need a paid key to get updates from the online repositories, so you are stuck with the packages on the install DVD as a test. If any of the packages are buggy, you are stuck with them.
On the plus side, OEL had far less forms and registration loops than the other Oracle database-supported distributions, and clearly marked a single DVD download. I didn't want to download 8GB of Red Hat or SUSE only to find out that the second DVD is optional or more likely useless.
But in the interest of remaining on a supported OS, OEL was the best of a bad litter. I'm sure that CentOS or Fedora would work, but that doesn't get much love in the Oracle forums, as I saw people were told to get a supported OS as their first order of business.
Mistake #2: combining Linux and AHCI RAID
Since I am not a sysadmin everyday, I forgot about the whacky world of motherboard bus controllers and the varying degree of Linux support. Suffice to say that for the foreseeable future, I will not make this mistake again.
Installing Linux is not an activity I recommend with the Asus RS700-E6. Despite AHCI, RAID or legacy IDE modes being available, none were sufficient to install the OS and have it boot correctly without a significant amount of GRUB manipulation.
Legacy IDE mode was initially a non-event as it was dog slow, until an "enhanced" option was noticed in the BIOS and returned the drives to 21st century speeds.
But my favourite solution to this horrid situation was to use the Lenovo server with a proper hardware RAID card inside that worked with no dramas (hardware-wise at least).
Mistake #3: attempting to install Oracle
To the people that install, configure and maintain Oracle databases day in and day out: "More power to you!" I understand why it is that you are so well paid because if I had an option at this point, I would always have someone install, configure and create the database environment the way I wanted. I'd make the money back in the 10 years I would have lost from my life and save on dental fees I would have needed to replace my ground-away teeth.
The process for installing Oracle is arcane and should be better for a company that claims to be the leader in databases. Why do I have to go to the trouble of creating users, groups and environment variables by hand when other database and enterprise applications have been doing this for years? The answer escapes me; I'm hoping that there is a very good reason for this.
Over the course of wrestling with various instances of the Oracle install process I've had many things fail — so at least there is variety amongst the copious levels of frustration on offer — Java runtime crashes, kernel parameter errors due to not reading the instructions closely enough, and services failing during the configuration stage.
At least the database software itself always gets installed properly; it's the configuration of the listeners and the database itself that gives me grief. The configuration can be done manually, but wading through the documentation and
ecma errors is a nightmare; not to mention that invoking
netca causes the Java VM to crash hard.
It just shouldn't happen though. I'm not a 24/7 Oracle person, I'm a techie attempting to try the software out. If I was tasked with evaluating Oracle to run our next project on, I'd have to report back: "I'm sure it must be great when it is up and running, but once it is, pray to your deity of choice that it doesn't fall over or we'll have to get that expensive Oracle professional back."
So far it has taken days and I am yet to have a 100 per cent faultless installation experience, and I know that I could have MySQL, PostgreSQL or MS SQL up and running in hours by comparison.
For the time being, I am done with these vain attempts to get Oracle up and working. Perhaps I'll return to it when Windows' build appears — I can't say I'm looking forward to the next time our paths cross though.