Re: tough choices

From: Daniel Morgan <damorgan_at_x.washington.edu>
Date: Wed, 16 Jun 2004 20:30:31 -0700
Message-ID: <1087443050.928894@yasure>

Comments in-line.

Sy Borg wrote:

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

>>The "bottleneck" you have identified is only a problem if you don't
>>obtain the proper hardware. The number of transactions, and volume,
>>going through an HBA to a storage device is not related to RAC versus
>>federated data. Buy the right hardware and there is no issue.

>
>
> Thank you Daniel. Please pardon my ignorance - my background is
> software development. I have one further question - does this mean
> that we need to recommend an upfront investment in a super fast
> network and storage hardware to our customers? In other words, when
> the oracle guys make the scalability claim for their database
> clusters, are they saying that - sure you can scale your system up and
> add many more processor nodes - but make sure you spend the big bucks
> on the network and storage right now because if you don't and add more
> nodes in the future - your network and storage hardware might not be
> able to handle the volume.

My comment is generic and has nothing to do with Oracle or any other specific product. Every system has a breaking point based on whatever resource is going to be most challenged. It might be CPU. It might be the bus. It might be the storage array. Without benchmarking and load testing your system you are just making expensive guesses and they could be wrong.

What you need to do is:

1. Write specs
2. Choose your development environment
3. Size your hardware with help from the vendor
4. Write a good contract with the vendor putting the sizing burden

    of all aspects of the hardware on them

So in answer to your question ... scaling on any database system requires that your hardware, all of it, support the scaling. And scaling RAC is not significantly different from scaling SMP. More CPUs, more RAM, more bytes moved, more storage, more HBAs, etc.

No database can violate the rule.

-- 
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 Wed Jun 16 2004 - 22:30:31 CDT