Re: Is RAC DOA?
- From: Matthew Zito <mzito@xxxxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Mon, 16 Aug 2004 12:58:08 -0400
Tom,
Great points - please see below.
Thanks,
Matt
--
Matthew Zito
GridApp Systems
Email: mzito@xxxxxxxxxxx
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@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
