Re: Oracle RAC cost justification?

There is not argument about scalability that I know.

Probably there are some applications that will even
scale better on RAC somehow (never think that deep,
because never need it to) as per some Oracle sales
"demo" :)

From my experience with working on huge Sun and HP
platforms (108, 64, 24, ... CPU boxes usually in the
cluster because of the customers policy) for "unknown"
customers they can scale very well up even up to that
number of CPU's dependant what is your application
doing of course.

Oracle, itself when hitting the same table may be very
unscalable, even doing just lookups (SELECT) on the
same table from N processes (N<number of CPU's) is not
fully scalable. 
We all know why, do not we?

I tested myself in HP labs, certain parts of our
application, on the 64-CPU machines and got almost the
perfect scalability with 90% user time and 10% system
time and 0% I/O.

We tested one big customer end solution, of course
just piece using bulk insert into the same partitioned
table (up to a billion records per day, as per real
production need) having again almost perfect
scalability. The instance had 130G SGA.

Some things will scale, some will not.
I do not agree that 108 CPU Sun or 64 CPU HP or
whatever machine is not going to scale just because of
the number of CPU's. That was maybe true many years
ago, I am relatively new in a big HW arena (3 years).
It is usually not scaling when you hit some other
bottlenecks then the OS and HW, like Oracle critical
latches, network, application spin locks, to not
mention more obvious stupid things in your app or
Oracle because of "nice" design.

I am not going to spend too much words describing the
difference in performances while using RAC with two
machines with the same number of CPU's as that one big
beast.
Just I never got the figures even near these while
using RAC with even small number of CPU's in the
situations where you load balance the work over two
nodes. Of course I am talking about pushing specific
Oracle operations to the limit, like inserts.

This does not mean that RAC will not scale while
having nicely partitioned application touching
different tables and indexes on the different nodes.

The big argument for RAC I know is when you have the
system on the HW that cannot be expand. We had the
situation where there is no bigger machine on the
particular OS market, so to do pure horizontal scaling
you can add the node with the RAC or invent somehow
horizontal application solution working with many
partitioned databases.
We all buy machines for the next 3 years usage.
Correct?

RAC is probably very meaningful in Linux and Windows
environments as already mentioned where you are
limited on specific number of CPU's (It was 8, but
probably this expands as IBM, HP and others are in the
Linux game for some time).

The ugly thing about this is that your application or
third party apps were never designed to work properly
in the RAC environment, or even when designed (I tried
a few times) could not get the results as one machine.

Regards,
Zoran


--- Tim Gorman <tim@xxxxxxxxx> wrote:

> But I don't think that there is any
> argument that either SMP or
> NUMA scales much more effectively than RAC/OPS, is
> there?




                
__________________________________ 
Discover Yahoo! 
Have fun online with music videos, cool games, IM and more. Check it out! 
http://discover.yahoo.com/online.html
--
http://www.freelists.org/webpage/oracle-l

Other related posts: