Re: Is RAC DOA?

Tom,

Great points - please see below.

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 Aug 16, 2004, at 11:38 AM, Mercadante, Thomas F wrote:



> Matt,

>

> You said:

>

> "RAC is hard to set up, get working in a stable fashion, and manage

> long-term"

>

> And

>

> "The problem is, like you said, it can be expensive for those

> organizations unable or unwilling to fight the good fight against

> oracle.  Also, a certain number of DBAs (this list, by the way, is much

> more atypical than what I see out in the field) are averse to

> technologies like Linux, Intel, and active/active clustering for a

> variety of (generally not very good) reasons."

>

>

> So, why would I suggest RAC to any organization?  It's expensive, hard 

> to

> manage, a tough fight with Oracle to get it working correct, and on 

> top of

> all that, hardware, again, is making a comeback it providing 99.999 

> uptime

> in one hardware platform.  So tell me again, why I need RAC?


Well, I think there's a couple of different moving parts in the stuff I 
said.  The first is regarding the difficulty getting RAC working.  The 
problem, from what we've seen, is not RAC alone, but the nature of 
these clusters in totality.  For many organizations, they have Sun or 
IBM or HP UNIX servers and are looking at rolling out RAC on 
Linux/Intel servers.  That means that not only do they have to pick up 
RAC, but they have to pick up Linux and Intel hardware as well.  That's 
a fair amount of new technologies to introduce all at once.  In 
addition, there are several organizations I've seen where RAC was 
crammed down the DBA or system admins' throats as a pilot project where 
those involved had no intention of seeing it succeed.

But there's two different pieces to "getting RAC working".  One is 
getting a RAC cluster up, seeing shared storage, etc - sort of the base 
functionality.  That can be done by anyone with a certain amount of 
patience and skill.  The other piece is "getting RAC working well", 
which is much more difficult.  That can come only with experience - 
just like being good at Veritas clustering can only come with 
experience, or being a good DBA can only come with experience.

So, when looking at deploying RAC, a big question I'd ask is - are my 
people ready to take this task on?

Once its deployed, the management overhead comes much more from the 
system side than the database.  Where once you had 1 server, you now 
have three to five or more, which means more patching, more OS faults, 
etc.  In addition, the associated infrastructure - network management, 
storage management, etc. create additional costs.

Hardware isn't really improving, though, is the problem.  The hardware 
redundancy that exists is around things like transient error correction 
- single bit ECC, SMART for hdds, etc.  When there's an OS failure, or 
a CPU trap, or a network card interrupt problem, your box is down.  
That's why people buy two boxes and pay for Veritas, etc.

A really great metric to use about whether a database is a good RAC 
candidate is - "Is this database important enough to our business that 
we buy 2x hardware and pay for an active/passive clustering solution, 
and is it large enough that it requires more than 4 processors to 
operate?"    In configurations like those, RAC can generally be cheaper 
than the existing solution without too much difficulty.

The last piece that I want to add on this subject is that the 
management costs can be significantly reduced through the use of 
secondary/third-party tools.  Now, a huge huge chunk of full disclosure 
here - my company makes a RAC/clustering and virtualization management 
software platform.  The whole point of our product is to make running 
RAC databases actually easier and better than running them on single 
servers.  We're not the only people doing it either - there's a variety 
of companies, including Oracle, shilling tools to ease the management 
gap between single-instance to RAC clusters.

That's a generalized trend in technology - technology Y is introduced 
to improve availability||speed||scalability of platform X, but the 
trade-off is complexity.  Then, startups and other companies step in 
with management tools and enhancements to reduce the complexity, 
increasing the overall hard dollar cost of technology Y but reducing 
the complexity such that it becomes as simple as the status quo and at 
least equally cost-effective as technology Y alone.  Eventually 
technology Y is the norm.

RAC is not a hammer for every nail.  But it is a technology that is in 
active development, growing in use, and reflects the overall trend in 
computing today - clusters of inexpensive, commodity servers, with the 
additional complexity being offset by management tools.  There's a lot 
of marketing, engineering, and VC dollars being invested in it, and to 
be honest, everything we've heard from Oracle is the push towards RAC, 
not away from it.

Thanks,
Matt

----------------------------------------------------------------
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
-----------------------------------------------------------------