Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
Home -> Community -> Usenet -> c.d.o.server -> Re: tough choices
"Sy Borg" <borgforward_at_yahoo.ca> wrote in message
news:b275fb29.0406161916.1e32d18_at_posting.google.com...
> 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.
PMFJI No, they're not saying that. But it would be foolish to pretend you keep on bolting on extra boxes ad infinitum and the thing just keeps on scaling linearly. There comes a point where you do have to consider that multiple nodes and multiple instances are all sharing the one disk storage array, and are all sending messages across the one internconnect/networking infrastructure... and hence, contention issues will eventually arise. At *that* point, new interconnects and new storage solutions may need to be considered.
The marketing guys are probably over-selling scalability. That's what marketing guys are paid for. But they're not just making it all up either. As ever, it's 'take every grain of truth with a pinch of salt'.
Regards
HJR
Received on Wed Jun 16 2004 - 23:25:09 CDT