Re: an honest post about being an oracle ace
Date: Wed, 4 Feb 2009 10:13:14 +0000 (UTC)
Message-ID: <gmbpnq$qn6$3_at_solani.org>
On Mon, 02 Feb 2009 22:28:02 -0600, Michael Austin wrote:
> I know there are valid reasons to do RAC, but most that are postulated
> and presented to management these days are nonsense.
I beg to differ. While I do detest RAC being pushed like a snake oil that should solve all of the problems, from performance, high availability to replication and even pimples, RAC definitely has its value and can contribute a lot to an average IT department. For a DW or reporting database, RAC is a dream come true. It's easy to extend, it can be maintained piece by piece, it can employ massively parallel techniques and, in combination with partitioning, is the ultimate tool for processing large quantities of data.
For an OLTP database, RAC can be of immense value because it provides fault tolerance. It can also provide performance benefit, provided one organizes the application in such a way that there are very few concurrent accesses of the same data from different nodes. That would usually require rigorous testing, something that is expensive and time consuming.
The other strategy is to over-configure RAC nodes to make sure that the hardware alone can take the punishment 10 times over, but that will raise the cost of the configuration and make it less efficient in comparison with the proverbial "big iron". The "big iron" is much easier to manage and support than the Linux Lego elements approach, which means that one can also save on the DBA salary and employ a "DBA 2.0" instead of someone who knows how things are done and who tends to be rather expensive.
It is impossible to dismiss RAC as "snake oil". I am managing RAC configurations for years, I could even argue that I've specialized in RAC. I've been installing, tuning, expanding, patching and helping developers to write applications for RAC, for a decade now. I started with OPS and Oracle 7, worked on OPS 8i, RAC 9i, installed several 10g databases from scratch, added nodes to RAC database, installed RAC recommended patches and created standby DB for RAC. The only thing that I have never done is to create a RAC standby for RAC. I have even managed to install an 11g RAC for testing purposes. The installation process is much smoother than with 10g. I only tested the ASM version, I never tried with OCFS or GFS.
I know and like RAC, for the homegrown applications that the company can control. The only thing that I can dismiss as sheer madness is so called "stretch cluster", of the sort that Nuno described above. There is simply no way that a major RAC db can function across the Pacific. Across the Red Sea, maybe, with some splitters between the nodes, but not across the Pacific. RAC can be a good thing if you have a good DBA and some good developers.
There is one more thing: OEM is a rather expensive piece of junk. It's unresponsive, hard to maintain, install and use. It is a concoction of Java, Perl and Apache elements which wastes enormous resources and provides little benefit in comparison to Quest SpotLight or even Nagios.
It is configured and started using the infinitely annoying and overly complex emctl and emca utilities, without a GUI, configuration files are in XML format, error messages and logs are scattered across several directories and are not at all well documented. The "dbconsole" takes 1G to run, there is no self-explanatory .ini ASCII file and bugs with the runaway processes, munching away CPU resources are frequent. OEM can also be very unresponsive.
My advice to anyone venturing into the high end configurations would be to also consider a purchase of a good monitoring software like SpotLight. The development approach taken by OEM team is to give 50 cheap developers a typewriter and expect them to produce a good piece of software in the forseeable future. Well, maybe.
If someone doesn't understand my reference to typewriters, it was an adjustment from here: http://en.wikipedia.org/wiki/Infinite_monkey_theorem
-- http://mgogala.freehostia.comReceived on Wed Feb 04 2009 - 04:13:14 CST