Re: steps to follow to develop applications with target db on RAC

From: hpuxrac <johnbhurley_at_sbcglobal.net>
Date: Mon, 7 Jan 2008 13:20:51 -0800 (PST)
Message-ID: <8c751a8e-4f0b-4702-a6e4-9f7ad1bcc2b9@e10g2000prf.googlegroups.com>


On Jan 7, 3:25 pm, sybra..._at_hccnet.nl wrote:
> On Mon, 7 Jan 2008 20:31:17 +0100, "KCS" <K..._at_hotmail.it> wrote:
> >Developers asked us a simple checklist to follow to build good applications
> >where the target database is a 10g RAC (2 or 3 nodes).
> >I remember a pair of links on this forum about this argument, but we do not
> >succeed in finding them.
>
> >Would it be possible for you to give us some information, about developing
> >application for ?
>
> >Thanx
>
> >Mastino (KCS Srl)
>
> RAC is ill-suited for non-OLTP applications (according to the 10g RAC
> course).
> RAC is also very sensitive to unscalable applications. If the
> application is unscalable in a single instance situation, results in a
> RAC configuration will be even worse. (Again according to the
> aforementioned course).
> The best you can do is build a scalable app for a single instance.
>
> The one thing you might take into account, is splitting up your
> application in several services (modules). You can decide to run a
> service on 1 node or multiple nodes, have it fail-over, or have it
> crash etc.
>

I am going to have to agree with Mr. Bakker for once.

The better your organization and developers are at designing and implementing highly scalable single instance applications the better odds that they "might" tolerate some of the consequences of RAC.

Yeah there are a few glitches and gotcha's with sequences and in some cases index design in RAC. As Mr. Bakker said OLTP and small amounts of data access are crucial. The more often that multiple instances go after larger amounts of the same data concurrently ... the more impact. Received on Mon Jan 07 2008 - 15:20:51 CST

Original text of this message