I added one extra node to provide redundancy for a comparable number of CPUs - i.e. lose a node and still be at 16 CPUs against the Sun server. Sooo, if you go 16 vs. 16 it gets even more competitive. Also, I'm saying two servers @ 300k apiece - the reason I said two sun servers was for failover - and I only licensed one side of the cluster for Oracle - if you licensed both, obviously it gets even more expensive.
I also avoided comparing the speed of Intel vs. Sun CPUs because that's a long-running debate, and the speed difference can be hard to quantify. But, yes, absolutely - you could replace 16 Sun CPUs with a minimum of 12 Intel CPUs, and I would expect you could go down even further. Basically, I made the cost comparison as straightforward as possible - if you're willing to look at things like relative processor speed, aggregate I/O throughput, etc. - the numbers get even more compelling. When we go into a customer location, we tend to look at their specific support contracts, storage configuration, workloads, Oracle discount, additional software, administrative costs, etc. to create a real picture. And in just about every case where we're looking at a medium-size database environment (at least four-processor databases) we can show cost savings against single-system-image servers using RAC - again with some of our product-specific features we can save money on aggregate oracle licensing as well. There are definitely environments where RAC is not cost-effective - just like everything else, there's a sweet spot that you'll find - but those tend to be small environments (if you have a two-processor database, its unlikely two single-processor nodes will make sense). Thanks, Matt -- Matthew Zito GridApp Systems Email: [EMAIL PROTECTED] Cell: 646-220-3551 Phone: 212-358-8211 x 359 http://www.gridapp.com > -----Original Message----- > From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On > Behalf Of Mogens N�rgaard > Sent: Friday, December 05, 2003 9:44 PM > To: Multiple recipients of list ORACLE-L > Subject: Re: ETAGON... > > > Good stuff. Thanks. > > So what you're saying below is this: > > Before: 2 16-cpu Sun's: $600K for HW and OS plus 32 x $40K > for Oracle, > ie a total of $1.680K? Is that correct? > After: 5 4-cpu Intel boxes: $100K for HW and OS plus 20 x $60K for > Oracle, ie a total of 1.300K? > > What confuses me, I think, is the difference in number of CPU's > mentioned when only the additonal RAC price tag of $20K was mentioned. > > Is it possible to move from 32 Sparc CPU's to 20 Intel CPU's? > > Mogens > > Yechiel Adar wrote: > > >I concur about the software prices on big machines. We work with IBM > >mainframes and the last upgrade cost us a lot in SOFTWARE licenses, > >since we moved into a higher performance group. > > > >Yechiel Adar > >Mehish > >----- Original Message ----- > >To: "Multiple recipients of list ORACLE-L" <[EMAIL PROTECTED]> > >Sent: Thursday, December 04, 2003 7:49 PM > > > > > > > > > >>Well, I'm going to get involved here saying upfront that my > company is > >>a competitor of Etagon's, so I'm certainly biased, both > about us vs. > >>Etagon and RAC in general. > >> > >>However, the financial savings of RAC can be significant - > we do cost > >>analyses all the time of RAC for potential customers, and > its often as > >>simple as: > >> > >>2 mid-size sun servers (we'll say 16 processors) - $300,000 each = > >> > >> > >$600,000 > > > > > >>a cluster of 5 4-way servers = $100,000 > >>Cost of RAC per processor (list, even!) - $20,000 x 20 = $400,000 > >> > >>So, not taking into account the cost of clustering software for the > >>two > >> > >> > >big > > > > > >>sun boxes, the cost of downtime due to hardware failure, > sun platinum > >>support, discounted RAC licenses, forklift upgrades, and more > >>expensive backup and other software licenses for larger servers - > >>basically the simplest analysis you can do, RAC is still $100k > >>cheaper. > >> > >>If we do add in those other factors, RAC becomes even more > >>cost-effective. Where some of those cost savings get eaten > up, though > >>is in additional complexity and administration cost - which > is where > >>companies like mine > >> > >> > >and > > > > > >>Etagon find a market. RAC is hard, there's no question. > >> > >>The financial savings in RAC generally don't come from the license > >>costs > >> > >> > >(I > > > > > >>can show how you can save on license costs, but we're > straying into an > >>advertisement for our product at that point), they come > from improved > >>availability and reduced hardware costs. Big SMP servers are > >> > >> > >exponentially > > > > > >>more expensive than small ones, and the software that runs > on them is > >>correspondingly exponentially expensive. > >> > >>Thanks, > >>Matt > >> > >>-- > >>Matthew Zito > >>GridApp Systems > >>Email: [EMAIL PROTECTED] > >>Cell: 646-220-3551 > >>Phone: 212-358-8211 x 359 > >>http://www.gridapp.com > >> > >> > >> > >>>-----Original Message----- > >>>From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] > On Behalf > >>>Of Mogens N�rgaard > >>>Sent: Thursday, December 04, 2003 3:29 AM > >>>To: Multiple recipients of list ORACLE-L > >>>Subject: Re: ETAGON... > >>> > >>> > >>>Etagon invited me to come and visit them at their stand at > the UKOUG > >>>conference in Birmingham next week. Don't know if I'll > have time or > >>>not, but in general I'm still looking for hard evidence of > >>>financial savings > >>>using RAC, ie a real comparison where switching to RAC (on whatever > >>>platform) meant lower license costs in total. I've only seen > >>>calculations where the price of RAC was omitted or hugely > discounted. > >>>I'm even willing to ignore the increase in complexity that > >>>follows from > >>>clustering and RAC'ing... One thing, though, that I will not > >>>accept, is > >>>this notion of TCO. It seems that anybody can use that > thing to prove > >>>any point, so it becomes hard to compare :). > >>> > >>>If RAC is cheaper for you than non-RAC it must be because you save > >>>the $20K per CPU somewhere else. Or? > >>> > >>>Mogens > >>> > >>>Gunnar Berglund wrote: > >>> > >>> > >>> > >>>>Hi all, > >>>> > >>>>I would like to hear, if you have any experience > concering Etagon... > >>>> > >>>>Short review: > >>>> > >>>>Etagon is an Israeli company and their product is Data Center > >>>>Automation SW focussing initially on Oracle 9i RAC clustering SW. > >>>>Etagon claims that their SW can produce fundamental savings > >>>> > >>>> > >>>in 9i RAC > >>> > >>> > >>>>installation and lifecycle management. > >>>> > >>>>Please see their web site; www.etagon.com <http://www.etagon.com> > >>>> > >>>>I'd be interested to hear if you know Etagon already and > in any case > >>>>what is your take on their value proposition. Is 9i RAC > >>>> > >>>> > >>>installation & > >>> > >>> > >>>>maintenance a real pain point to you? And could Etagon SW > possibly > >>>>ease that pain? > >>>> > >>>> > >>>> > >>>-------------------------------------------------------------- > >>>---------- > >>> > >>> > >>>>Download Yahoo! Messenger > >>>> > >>>> > >>>> > >>><http://uk.rd.yahoo.com/mail/tagline_messenger/*http://downloa > >>> > >>> > >>d.yahoo.com/dl/intl/ymsgruk.exe> > >> > >> > >>>now for a chance to WIN > >>> > >>> > >>> > ><http://uk.rd.yahoo.com/mail/tagline_messenger/*http://messen > ger.promot > >ions. > > > > > >>yahoo.com/rwuk> > >> > >> > >>>Robbie Williams "Live At Knebworth DVD" > >>> > >>> > >>-- > >>Please see the official ORACLE-L FAQ: http://www.orafaq.net > >>-- > >>Author: =?ISO-8859-1?Q?Mogens_N=F8rgaard?= > >> INET: [EMAIL PROTECTED] > >> > >>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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] > >> > >>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: [EMAIL PROTECTED] (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: =?ISO-8859-1?Q?Mogens_N=F8rgaard?= > INET: [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] (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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
