Re: tough choices

Sy Borg wrote:

> Hello:
> We are designing two multi-user client server applications that
> performs large number of transactions on database servers. On an
> average Application A has a 50% mix of select and update/insert/delete
> statements and application B has 80-20 mix of select and
> update/insert/delete statements. Being able to scale the databases as
> needed so the performance is unaffected, is one of our critical
> requirements. We've been investigating Oracle 10g RAC and DB2 ESE as
> alternatives and in both cases unfortunately, we get a lot more
> marketing spin than real answers. I've looked through some of the
> newsgroup postings on oracle and ibm's websites and most of the
> discussions seem to be about high availability(and technology
> evangelism). The information we've gathered so far seems to point to:
>
> 1. The critical factor (and possibly the bottleneck) for Oracle's RAC
> performance is the network and the storage access speed- if the
> network does not have ample unused bandwidth or the rate at which
> storage can be accessed by various nodes has reached the point of
> diminishing returns - we won't get any additional performance by
> simply increasing the number of nodes. Also, the application that
> performs more writes will hugely increase the network traffic because
> of synchronization requirements.
>
> 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
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)