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.

Do you already have a hardware/os platform picked out, because the underlying technology in a high-transaction rate application is just as important as the database engine you choose. Since "high-transaction" rate is quite subjective, can you quantify that point a bit more.

With RAC, (and depending on your platform) physical access to the data from ALL nodes in the cluster - concurrently - would be IMHO imperative.   There are "cluster" technologies out there that do not allow concurrent access to all file systems from multiple nodes and you need to research them carefully.

But if you want to use the "original" RAC, use Oracle Rdb (not to be confused with RDBMS - formerly DEC Rdb) on an OpenVMS cluster. A cluster that can be ~256 nodes and using SAN storage, multiple-PB of storage. And the application can run concurrently on all nodes in the cluster. BTW, A large number of stock exchanges rely on OpenVMS and Rdb on the trading floor... draw your own conclusions.

Michael Austin. Received on Wed Jun 16 2004 - 10:22:12 CDT