> > > > 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
That does not sound like he needs Federated support to me. I think he
(original poster) was asking a question and not answering one. But I am not
sure what he was talking about.
Received on Thu Jun 17 2004 - 20:36:41 CDT
