Re: tough choices

"Mark A" <nobody_at_switchboard.net> wrote in message news:Za5Ac.101$ln4.34863_at_news.uswest.net...
> > Sy Borg wrote:
> >
> > >
> > > 2. DB2 can deliver better performance but only if the data that is
> > > accessed together is physically laid out together and the application
> > > has knowledge of the physical data layout (so it can connect to the
> > > right node in the cluster ). However, if, we separate the application
> > > logic from physical layout of the data the performance will be
> > > unpredictable.
> > >
> > > All this is just hypotheses - if anyone has some real world experience
> > > with these two offerings and can offer an objective opinion - we'd
> > > really appreciate it.
> >
> > 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.
> >
> > The main consideration I would think would be the overhead of federating
> > data for DB2. The more data the more difficult and time consuming and
> > the fact that losing nodes with RAC is an inconvience ... with DB2 you
> > have a lot more to worry about ... and mean time between failures goes
> > down, not up, as you add nodes.
> >
> > --
> > Daniel Morgan
>
> Where does he say that federated support will be used (or is needed) for
> DB2?

I got that from

"DB2 can deliver better performance but *only if* the data that is accessed together is physically laid out together and the application has knowledge of the physical data layout (so it can connect to the right node in the cluster )."

I may of course be wrong.

-- 
Niall Litchfield
Oracle DBA
http://www.niall.litchfield.dial.pipex.com