First and foremost, before you jump into this, make
sure that your mission-critical applications are "certified" supported
on RAC, and which version of RAC -- after all, a "RAC cluster" is ipso
facto one version. That could be
illuminating and show-stopping. RAC is good technology, but it is a niche solution, not a general-purpose solution. It is not high-availability -- look toward Data Guard for viable database high-availability. It is a database scalability solution, plain and simple. If you cannot scale by moving to a larger server, then RAC is a viable alternative. Once the justification of RAC as a high-availability solution is removed (as it should be), then the decision of how to scale becomes a matter of which platform you are using. If you are on Solaris or HP-UX or AIX, chances are good you can scale quite high within a single server, without using RAC. If you are on Windows or Linux, chances are good you might have to use RAC. Crude generalizations, yes - but I'm being terse. Cost enters into it, as many IT departments do not want to buy/lease "big iron", but the Oracle licensing for RAC generally more than offsets, not to mention the hidden costs of training (formal or OJT). I'm an OPS/RAC DBA since 1994, and the common trajectory for OPS/RAC implementations made for the wrong reasons (i.e. H/A not scalability, general-purpose not special-purpose, etc) often resembles Napoleon's retreat from Moscow. Still, it's great technology, can be a lot of fun, and looks great on the resume. Tim Gorman consultant -> Evergreen Database Technologies, Inc. postal => P.O. Box 630791, Highlands Ranch CO 80163-0791 website => http://www.EvDBT.com/ email => Tim@xxxxxxxxx mobile => +1-303-885-4526 fax => +1-303-484-3608 Lost Data? => http://www.ora600.be/ for info about DUDE... Guillermo Alan Bort wrote: Just make sure you don't end up having to manage 50 pointless RACs... ;)-- //www.freelists.org/webpage/oracle-l |