Re: RAC and scalability

On Apr 7, 3:17 pm, sybra..._at_hccnet.nl wrote:
> On Mon, 07 Apr 2008 10:07:09 -0700, DA Morgan <damor..._at_psoug.org>
> wrote:
>
> > From Oracle's standpoint a 2 node cluster is a special case and you
> >should always try to go with a 3 node minimum.
>
> Can you corroborate this?
> From my end it looks like a 3 node cluster will make things worse, as
> you will have 3 caches in sync (and no, this particular app was not
> designed for RAC, it was ported from sqlserver)
>
> --
> Sybrand Bakker
> Senior Oracle DBA

Where did Andrew say this was ported from SQL Server?

One of the problems I see with high multi-node RAC on cheap hardware is that the more machines the more likely cache fusion overhead issues will come up.

When you run three or four node RAC you can easily run into the problem where if a sinlge machine dies the load is high enough that the remaining machines do not run it well, performance wise. Now you need another machine, just in case, and while the hardware may be cheap the software license just went up.

Sizing a machine to a not yet running in production database is more luck than science for most shops. Even when you have real numbers to work with sizing a new machine is not always straight forward. Trying to figure out RAC in advance ??

My advice since so much is unknown is buy an expandable machine where you can add more cpu and memory. Get one of these delivered as soon as practical. Get Oracle installed and a database built and start work on the application. Time test it.

Using the performance test numbers for IO rate, memory usage, and performance (clock time) determine how many more machines you need.

Try to have the sales contract written to allow the decision on which specific model of machines to buy put off till later. Get a price based on a minimum number of X or Y with a set amount for additional units.

HTH -- Mark D Powell -- Received on Tue Apr 08 2008 - 10:30:12 CDT