Howard J. Rogers wrote:
> "Daniel Morgan" <damorgan_at_x.washington.edu> wrote in message
> news:1079372613.798437_at_yasure...
>
>>Niall Litchfield wrote:
>>
>>>I see a lot of this sort of remark from advocates of RAC (or indeed many
>>>other new technologies). The selling point of RAC is that it gives near
>>>linear scalability and reliability no matter what your application -
>
> that is
>
>>>how it is sold.
>>
>>I know. Oracle's marketing is doing Oracle no service by
>>mischaracterizing RAC ... and for that matter GRID. They are creating
>>misunderstandings that only hurt the product's acceptance and the
>>very sales they think they are enhancing.
>>
>> If the reality is (and I honestly think that it is) that
>>
>>>your average off the shelf business software solution (think
>>>SAP,Peoplesoft,SIEBEL etc) will actually suffer under RAC, then the
>
> reality
>
>>>is that buying RAC would be a poor idea.
>>
>>That depends on more things than just the software developer's name. And
>>it depends on why RAC is being purchased because there are three
>>entirely different reasons for buying it.
>>
>>1. High availability
>>2. Scalability
>>3. Failover
>
>
> Now this is where it gets interesting, because my list of RAC benefits would
> read:
>
> 1. High availability
> 2. Scale Up (do more work in the same time)
> 3. Speed Up (do the same work in less time)
>
> I count failover (by which I presume you mean Transparent Application
> Failover?) as merely a component of High Availability (and given it only
> works for select statements in 9i, it was another feature that was
> over-sold).
>
> Now, if you accept that list, then a number of questions arise, principle
> amongst which is: is there any other product or configuration which can give
> you 90%+ of those benefits without the additional complexity and hassles
> which RAC can bring to the party?
>
> And, until 9i Release 2, I would have argued that there wasn't really.
> Standby database could give you most of the High Availability you might
> want. And with multiple standby databases, you could have opened one of them
> read-only and done your reporting there, thus freeing up your primary site
> for OLTP-type work, and thus achieving some form of scale-up.
>
> But with the logical standby of 9i Release 2, I'd argue that you can pretty
> much achieve most of those three points with goold old Data Guard. Having
> the standby database fully openable makes a hell of a difference to the
> equation.
>
> And whereas the big boys will certainly have a genuine need for the full
> package that RAC can give, I think the majority of sites can get by with the
> not-quite-as-sexy and not-quite-as-functional but still-pretty-much-adequate
> capabilities of DG.
>
> In a world where, if my memory of the last set of figures I saw was correct,
> 25% of Oracle sites still use version 7, and another 35% still use 8i, then
> I think it safe to assert that most people don't need RAC. Which is where
> (if memory again serves) this entire discussion started.
>
> Regards
> HJR
Different countries different priorities perhaps. Here TAF is a bigger
issue. But the biggest reason for RAC is to save money. The argument
is quite simple.
- Check the cost of a 16 CPU box to handle an application's anticipated
load.
- Check the cost of 8 x 2CPU boxes plus the cost of RAC to handle an
application's anticipated load.
- Explain to your CFO why you just spent a boat load of capital on the
big box when it won't be required until the application scales up to its
anticipated workload two years in the future when the 16CPU box will
already be obsolete.
- Explain to the people at the unemployment office why you need a job.
And yes it is beginning to happen that way over here.
--
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 Mon Mar 15 2004 - 16:03:17 CST
