| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Q. To RAC or go vertical
When you do TCO analysis do add in the costs of administration? The learning
curve?
The maintenance? The value of reliability and familiar support structures?
WHat kind of proof do you have about the claim of RAC's reliability compared
to a single mutliple processor system?
What about when a node does fail and suddenly the users and batch processing is left with 1/2 or a 1/4 of the procsessing power gone? How long is it going to take to get the system back to 100%? Lots of admins can be confident in gettting a huge hp or sun box up in less than 12 hours. Is 6 hours of downtime worse than three days of processing at 50% capacity?
What about the value of KNOWING a solution works not just speculating on how much money it MIGHT save.
The IT industry has fallen because of lots of "sell them the sizzle, get em' the bacon later" marketing hype like the info floating around about RAC and grid. Software and hardware vendors have been jumping from one "great idea" to another. The result is a lot of products that end up in the bone yard and another round of layoffs.
What is happening is hardware and software vendors are feeding the markets desire to have a low cost system with unlimited power and scalability. I am sorry to say you STILL can't have both. I know what vendors are thinking, they think this will be holy grail of IT that will bring us back to the fat days of pre y2k.
"Get the grid going it so complex that they will have to use our consulting services too...once wer'e in the door we'll be there for years." IT directors made the mistake of trusting vendors once. They aren't going to do again.
Frankly I am all for reducing complexity and increasing reliability. Right now there is proven technology that may cost a bit more but in the long is going to be the right decision.
"The above notes and my company aside, I would be shocked if I ever implemented a large single-image Oracle instance ever again. "
Yeah right when monkeys fly out my butt.
Brad O.
-----Original Message-----
Sent: Tuesday, August 05, 2003 11:39 AM
To: Multiple recipients of list ORACLE-L
The point of RAC is both fault tolerance AND scalability. More specifically, the ability to recover from a multi-node failure as well as use commodity hardware and scale on demand are the major motivating factors. Besides that, the cost difference between a mid-size SSI server and a RAC cluster is simply stunning.
We've done the TCO analysis over and over again, and there's simply no fiscal justification in today's world to put a mid-size database instance on anything _besides_ RAC. If you look at the hardware cost difference alone between an 8-way sun box and two 4-way linux boxes, its more than a 10-fold cost difference. That's before you take into account you often need a volume manager, a cluster server, and a whole second node to cluster it with to achieve the same level of reliability you get with a RAC cluster.
As always, full disclosure says I should say that I have a vested interest in the success of RAC, but I'm not even including our product in the cost comparison. Just vanilla RAC-on-linux vs. big-UNIX is a pretty compelling story in and of itself.
Now, I said there's no _fiscal_ justification. RAC is obviously not a hammer for every nail. There are both applications and workloads that either require special tuning or are just not optimal for message-passing clusters. Also, there are scalability limitations due to interconnect latency in terms of the number of nodes you can have in a cluster - this is something we're working on addressing here.
RAC's other big problem is that Oracle's RAC documentation is....artistic...by which I mean misleading, difficult to understand, and sometimes just wrong. This keeps organizations off of RAC or convinces them to hire consultants, and the vast majority of RAC consultants out there are even worse than the vast majority of Oracle/Sun consultancy practices - cookie cutter solutions and ill-informed consultants.
The above notes and my company aside, I would be shocked if I ever implemented a large single-image Oracle instance ever again.
*clambers off soapbox*
Thanks,
Matt
-- Matthew Zito GridApp Systems Email: mzito_at_gridapp.com Cell: 646-220-3551 Phone: 212-358-8211 x 359 http://www.gridapp.comReceived on Tue Aug 05 2003 - 14:34:30 CDT
> -----Original Message-----
> From: ml-errors_at_fatcity.com [mailto:ml-errors_at_fatcity.com] On
> Behalf Of Stephen Lee
> Sent: Tuesday, August 05, 2003 10:54 AM
> To: Multiple recipients of list ORACLE-L
> Subject: RE: Q. To RAC or go vertical
>
>
>
> I think the point of RAC is fault tolerance, not scalability.
> If it's performance you want then you want a bigger box, not
> more boxes. 8 CPUs is not big. You sure don't need the
> expensive hardware if all you want to run is 8 CPUs. It
> would be better to go with a smaller frame and use the money
> you save to get more CPUs and additional I/O capacity. For
> example, instead of E12K with 8 CPUs, get 4810 with 12 CPUs
> -- unless you have definite plans to push the E12K out to its
> limits in the future. Don't forget to consider the backup
> requirements of a 5 - 10 TByte database. Another
> consideration, I think, is that those big, fancy boxes
> require additional sys admin skills.
>
> -----Original Message-----
> Hi All
>
> I would like to ask for your thoughts on whether to RAC or
> just go vertical (more cpu)
>
> Background
>
> Txn - OLTP like txn during day but batch extracts at night and
> very big batch extract periodically
> Data Volume - 5-10 TByte
> Data volatility - 99 % of data is very much like a ware house
> (unchanged)
> other 1% is read/update/delete/insert
>
> Options
> 1. Say a very large server like a HP Superdome or SUN E12000
> with 8 CPUs
> Server already exist so cost is in obtaining
> additional CPU/Blades
> ie Traditional Server using plain old vanilla Oracle EE
> - can still increase head room.
> - batch programs can utilise all 8 CPUs
> - storage system need not cater for clustering
>
> 2, Same large server like a HP Superdome or SUN E12000 but
> partitioned
> into two. Each with 4 CPU.
> Oracle RDBMS + RAC option
> - storage server need to cater for cluster config
> - max performance for batch is with 4 CPUs only
>
>
> Which would you prefer and why. I am not convinced with the
> RAC option. Now if I was going with cheaper Intel servers
> like Dell servers with 4 CPUS each, and purchase say 4 nodes
> of 4 cpus each, that would be a different story. In this
> case I have the equipment and ability to grow vertically.
>
> ta
> tony
> --
> Please see the official ORACLE-L FAQ: http://www.orafaq.net
> --
> Author: Stephen Lee
> INET: Stephen.Lee_at_DTAG.Com
>
> Fat City Network Services -- 858-538-5051 http://www.fatcity.com
> San Diego, California -- Mailing list and web hosting services
> ---------------------------------------------------------------------
> To REMOVE yourself from this mailing list, send an E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru')
> and in the message BODY, include a line containing: UNSUB
> ORACLE-L (or the name of mailing list you want to be removed
> from). You may also send the HELP command for other
> information (like subscribing).
>
-- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Matthew Zito INET: mzito_at_gridapp.com Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing). -- Please see the official ORACLE-L FAQ: http://www.orafaq.net -- Author: Odland, Brad INET: Brad.Odland_at_qtiworld.com Fat City Network Services -- 858-538-5051 http://www.fatcity.com San Diego, California -- Mailing list and web hosting services --------------------------------------------------------------------- To REMOVE yourself from this mailing list, send an E-Mail message to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in the message BODY, include a line containing: UNSUB ORACLE-L (or the name of mailing list you want to be removed from). You may also send the HELP command for other information (like subscribing).
 |
 |