Re: MS SQL Server Evaluation

From: Daniel Morgan <damorgan_at_x.washington.edu>
Date: Fri, 12 Mar 2004 14:53:59 -0800
Message-ID: <1079132044.292409@yasure>

Comments in-line.

Howard J. Rogers wrote:

> "Daniel Morgan" <damorgan_at_x.washington.edu> wrote in message
> news:1079112892.570278_at_yasure...
>

>>Howard J. Rogers wrote:
>>
>>I think you are wrong on several counts.

>
>
> That of course is everyone's privilege!!
>

>>The main reason I see for
>>RAC is build-out rather than build-up. It can save a boatload of
>>money building a 16CPU machine with 8 x 2CPU Intel machines rather
>>than talking to HP, Sun, or IBM about a 16CPU box. And with that
>>boatload of money both Larry and his customers can buy their boats.

>
>
> That of course rather presupposes that the 8x2 solution works as well as the
> 16 cpu solution. I'll lay odds up front that it wouldn't. Cache Fusion
> sounds great in the marketing material but it's just a lot of old
> inter-process messaging under the hood, all of which takes time and effort
> on the part of Oracle. You've still got the issue of forced disk writes. And
> the interconnect had better be up to the job.

Unless you got a very poorly written application ... the number of blocks that need to move between nodes should be minimal. But from my experience benchmarking RAC ... you get about 88% of the performance for 25-40% of the cost. And that's after paying Larry his due.

> And by the time you've paid the consultant to set GC_FILES_TO_LOCKS
> properly, you could probably have purchased the 16 cpu box twice over with
> enough left over for a small yacht.

Or for very few dollars you could take a class and learn to do it yourself. There is absolutely no need to pay the consultant unless you have more cash than incentive.

>>Failover will become a larger part of the equation when Oracle makes
>>good its promise in a later release of 10g to make Oracle Forms, etc.
>>failover which means we will finally be able to have failover with
>>Oracle's own apps.

>
> You believe these promises!?

I have reasons to. And I'll leave it at that.

>>And grid? If you have 10g what is the extra cost for grid?

>
> Performance and productivity, which will go down the tubes the minute the
> DBA starts experimenting with it in those environments that have no use for
> it.

When you have actual benchmarks that back this up let me know. That is not my experience and I have it installed.

> But as I think Niall put it in another thread: there was a time when 8.0 did
> all that we could ask of it, and we were happy. There will always be some
> that need the new features, but I don't believe business needs have changed
> *so* much since 8.0 that there will be a sudden rush for grid technology now
> that it's available from SME's.
>
> Regards
> HJR
Business needs have changed dramatically. You'd never run Amazon.com on 8.0. Nor build some of the apps I've worked on for telecoms. Lets be honest here Howard ... anything can be built in assembly language. It just takes more time and costs more money. Therefore we use C and C++. Just about anything can be built in C or C++ but it takes more time and costs more money therefore we buy database software from vendors like Oracle. Just about anything could be done with Oracle version 6 but it takes more time and costs more money therefore we use the latest tools.

And unless we don't know how to use them effectively they save time and money. The problem is the "unless" and I think you just like bashing Oracle for the pure sake of bashing Oracle. If you compare them against some standard of perfection they should burn the place to the ground and go home. But if you compare them against IBM, Sybase, and Microsoft I'd think you'd be pretty happy with the company Larry's built.

-- 
Daniel Morgan
http://www.outreach.washington.edu/ext/certificates/oad/oad_crs.asp
http://www.outreach.washington.edu/ext/certificates/aoa/aoa_crs.asp
damorgan_at_x.washington.edu
(replace 'x' with a 'u' to reply)

Received on Fri Mar 12 2004 - 16:53:59 CST