RE: ETAGON...

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: mzito_at_gridapp.com
Cell: 646-220-3551
Phone: 212-358-8211 x 359
http://www.gridapp.com



> -----Original Message-----

> From: ml-errors_at_fatcity.com [mailto:ml-errors_at_fatcity.com] 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" <ORACLE-L_at_fatcity.com>

> >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: mzito_at_gridapp.com

> >>Cell: 646-220-3551

> >>Phone: 212-358-8211 x 359

> >>http://www.gridapp.com

> >>

> >>    

> >>

> >>>-----Original Message-----

> >>>From: ml-errors_at_fatcity.com [mailto:ml-errors_at_fatcity.com] 

> 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: mln_at_miracleas.dk

> >>

> >>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: =?ISO-8859-1?Q?Mogens_N=F8rgaard?=

>   INET: mln_at_miracleas.dk

> 

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