Re: with all this talk about RAC...

Bill,

My company has made a business out of both building software around clustering technologies such as RAC, as well as offering professional services related to RAC. As such, we've spent a lot of time fixing failed RAC implementations, building a set of optimizations and best-practices around RAC, and helping organizations figure out when clustering is the right solution.

As other people have said, the pre-eminent reason for RAC that has proven to be the most dependable is the high-availability features. Active/active clustering is a huge advantage, not just in "mission-critical" systems, but in any organization that may not want to be under pressure to repair a failed system in any particular timeframe.

The other reason that holds true more often than one might think is the scalability advantages. Certainly, it would be absurd to expect to replace a 40-processor Sun server with 20 2-processor servers, but it is not unreasonable to replace an 8-processor sun server with 2 4-processor servers, or even 3-4 2-processor servers. As technologies such as InfiniBand and RDMA-over-Ethernet mature, it is going to be easier and easier to scale these clusters larger and larger.

The last advantage is the cost - the cost of the RAC licenses is often touted as eating up the hardware savings (plus the added complexity of administering RAC), but hard negotiation can bring that cost down to minimal levels. A second point is that the cost difference of the RAC licenses can often be absorbed through the processor savings you can get by moving from last-generation processors to current ones. The administration complexity is a valid concern, and one of the reason that there are a number of companies (mine included) that have software to reduce that complexity.

That's actually the reason we see so many failed RAC implementations - because clustering is fundamentally difficult, requires a much greater level of OS, storage, and hardware involvement than a normal database instance, and Oracle's documentation is sketchy and incomplete.

RAC is not a silver bullet - but what we've found is that more organizations than not could be using RAC to reduce cost and improve uptime. It's certainly a technology worth looking at.

One last tech note - I can not recommend RAC on Sun - not only is the hardware more expensive, removing a lot of the cost savings, but the additional software required can be expensive. Plus, there's a great deal more complexity - you need Oracle, Solaris, Sun cluster, and veritas, and you have to use raw devices (unless the sun clustered filesystem has been qualified - I haven't checked in a while). You end up with a very complex implementation, multiple vendors to deal with, and limitations on configuration. On Linux, you end up working with only the single vendor for the end-to-end cluster stack.

Thanks,
Matt

--
Matthew Zito
GridApp Systems
Email: mzito_at_gridapp.com
Cell: 646-220-3551
Phone: 212-358-8211 x 359
http://www.gridapp.com


On May 25, 2004, at 8:15 AM, bill thater wrote:



> i have a few serious questions.

>

> as the last part of a major upgrade of hardware/OS/software in our 

> production hosted environment, we're getting to upgrade the database 

> cluster.  now we have a couple ways to go here, linux cluster or sun 

> cluster, but i can sit here and make a good case both for and against 

> using RAC for our production databases.

>

> so what is the collective wisdom on the deciding factors to implement 

> RAC?

>


----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to:  oracle-l-request_at_freelists.org
put 'unsubscribe' in the subject line.
--
Archives are at http://www.freelists.org/archives/oracle-l/
FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------