Google Groups no longer supports new Usenet posts or subscriptions. Historical content remains viewable.
Dismiss

RAC and scalability

0 views
Skip to first unread message

Andrea

unread,
Apr 7, 2008, 6:52:20 AM4/7/08
to
Hi all,
i've need some advise for resolve my doubt on RAC, because i have to
sizing RAC environment in my business.
Have been shows me two different solutions of RAC:

1) One node of Bl680c (until 4 CPU quad Core)

2) Two node of Bl480c (only 2 CPU quad Core)

The type of choice is a valuate for future scalability, first solution
support vertical scalability (2 to 4 CPU) instead of second solution
where scalability is only for horizontal (add a nodes).
First solution is correct sure but is more expensive and i would like
to know if his cost is justifiable, more cpu are effective benefit?

thanks for your info

bye
Andrew

Mark D Powell

unread,
Apr 7, 2008, 9:53:17 AM4/7/08
to

Andrew, I know nothing about the hardware you listed but if you want
useful responses you need to identify the type of application that you
will be running: OLTP, DSS, OLAP, etc ... and identify the current
user load. The Oracle version you will be using is also important.

For the solution to be RAC it must involve at least two nodes.

Also depending on the application design some applications just do not
scale well with RAC. To really run well under RAC the application
should have been designed with RAC in mind.

If two 2-cpu machines with 2G of memory will run the application
reasonably well a single 4-cpu machine with 4G would likely like run
it better.

HTH -- Mark D Powell --

Andrea

unread,
Apr 7, 2008, 10:50:17 AM4/7/08
to
On Apr 7, 3:53 pm, Mark D Powell <Mark.Pow...@eds.com> wrote:
>
> Andrew, I know nothing about the hardware you listed but if you want
> useful responses you need to identify the type of application that you
> will be running: OLTP, DSS, OLAP, etc ... and identify the current
> user load. The Oracle version you will be using is also important.
>
> For the solution to be RAC it must involve at least two nodes.
>
> Also depending on the application design some applications just do not
> scale well with RAC. To really run well under RAC the application
> should have been designed with RAC in mind.
>

unfortunately i can't collect informations on current user loads,
because this is a new project that merge several applications and
these apps doesn't current using.
The type of applications will mainly OLTP on 10g rel. of rdbms.
Sure 4 CPU is better then 2CPU, but what i want to know is if ScaleUp
is better then ScaleOut (horizontal scaling) in reference to cost of
the 2 servers describes up.

So if bl480c server with dual CPU have cost of 6.000$ and bl680c with
4 CPU is 12.500$ (double), in RAC environment it is better 2 nodes of
bl680c or 3-4 nodes of bl480c ?

thanks again
Andrew

ora...@msn.com

unread,
Apr 7, 2008, 11:02:03 AM4/7/08
to

Who could say with that limited bit of information? How much RAM is
installed in each configuration? How many concurrently connected
users do you expect? How fast is your network? What size do you
expect for the SGA?

With two nodes you have limited options for TAF (obviously) and should
one node die you're left with a single point of failure. With four
nodes you have a bit more 'wiggle room' before you end up with that
situation (three nodes must fail, and I expect that is a much rarer
occurrence).

This involves far more than simple monetary costs; additional
'expenses' for this are availability, scalability and performance, and
you might find that the four node configuration better suits your
expected user load and your anticipated SLA. But, no one can say
anything for certain until you provide more information.


David Fitzjarrell

DA Morgan

unread,
Apr 7, 2008, 1:07:09 PM4/7/08
to

You are approaching this in a way that may well lead to success or,
just as easily, lead to failure. This is not how one approaches RAC
design.

The number of CPUs for RAC should be roughly the same number of CPUs
for a standalone environment (assume scaling at ~80%). What matters
is how the application handles the sharing of blocks between nodes.
If there is a lot of sharing RAC is likely not going to scale well no
matter the hardware.

From Oracle's standpoint a 2 node cluster is a special case and you
should always try to go with a 3 node minimum.

So, unless you can answer questions about node affinity, my
recommendation would be to begin development on a single server,
identify CPU requirements, and then add a second server and see
how your application scales with cache fusion. To be successful
it must understand how RAC works and design services accordingly.
--
Daniel A. Morgan
Oracle Ace Director & Instructor
University of Washington
damo...@x.washington.edu (replace x with u to respond)
Puget Sound Oracle Users Group
www.psoug.org

sybr...@hccnet.nl

unread,
Apr 7, 2008, 3:17:41 PM4/7/08
to
On Mon, 07 Apr 2008 10:07:09 -0700, DA Morgan <damo...@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

DA Morgan

unread,
Apr 7, 2008, 9:57:33 PM4/7/08
to

You are correct about performance ... I was referring to the fact that
with a two node cluster, if you lose one node, you have a stand-alone
and RAC is no longer giving you the ability to failover or load balance.
If you go to three nodes you can lose one, whether due to failure or for
maintenance, and you still have a cluster.

hpuxrac

unread,
Apr 8, 2008, 10:50:44 AM4/8/08
to
On Apr 7, 6:52 am, Andrea <netsecur...@tiscali.it> wrote:

I would start by recommending that you read "You probably don't need
RAC" by Moans Nogood.

That pretty much gives you most of the critical things to think about.

RAC certainly has overhead that causes scalability problems for some
applications your mileage may vary. Generic testing of hardware that
doesn't really test out how well your applications scale out in RAC is
an exercise in wasting time.

An excellent point that Moans makes is that the very act of trying to
get high availability ( implementing RAC ) often causes lower
availability. Does this site and company have the critical mass of
experienced people necessary to support RAC? The questions that you
are asking make me think "not so much".

Try locating that paper by Moans and do your homework ... that is my
recommendation.

Mark D Powell

unread,
Apr 8, 2008, 11:30:12 AM4/8/08
to
On Apr 7, 3:17 pm, sybra...@hccnet.nl wrote:
> On Mon, 07 Apr 2008 10:07:09 -0700, DA Morgan <damor...@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.

DA Morgan

unread,
Apr 8, 2008, 11:45:41 AM4/8/08
to

Amazing how much easier it might be for the OP to find the paper you
refer to it you didn't spend so much time trying to act like you are
part of the "in" crowd.

The gentleman's name is Mogens Norgaard and this will actually help
the OP find the paper.
http://www.google.com/search?hl=en&q=%22Mogens+Norgaard%22+and+%22you+probably+don%27t+need%22&btnG=Google+Search

PS: Please go right ahead and complain about my signature block if it
it is cathartic.

hpuxrac

unread,
Apr 8, 2008, 1:19:49 PM4/8/08
to
On Apr 8, 11:45 am, DA Morgan <damor...@psoug.org> wrote:

snip

> Amazing how much easier it might be for the OP to find the paper you
> refer to it you didn't spend so much time trying to act like you are
> part of the "in" crowd.

Whatever. Doing some research and finding things tends to be good for
people.

You said "amazing how much easier" ... if you can't find it based on
what I said let me know.

>
> The gentleman's name is Mogens Norgaard and this will actually help

> the OP find the paper.http://www.google.com/search?hl=en&q=%22Mogens+Norgaard%22+and+%22you...
>

I am pretty sure that Moans is happy with that name. Why don't you
ask him?

DA Morgan

unread,
Apr 8, 2008, 6:21:52 PM4/8/08
to
hpuxrac wrote:
> On Apr 8, 11:45 am, DA Morgan <damor...@psoug.org> wrote:
>
> snip
>
>> Amazing how much easier it might be for the OP to find the paper you
>> refer to it you didn't spend so much time trying to act like you are
>> part of the "in" crowd.
>
> Whatever. Doing some research and finding things tends to be good for
> people.

I agree. But intentionally misleading them by misspelling what they are
looking for accomplishes what purpose?

If someone was asking for information about the RETURNING clause would
you tell them to look up the TURING clause?

iv...@hotmail.com

unread,
Apr 8, 2008, 9:23:00 PM4/8/08
to
On Apr 9, 1:45 am, DA Morgan <damor...@psoug.org> wrote:
> The gentleman's name is Mogens Norgaard and this will actually help
> the OP find the paper.http://www.google.com/search?hl=en&q=%22Mogens+Norgaard%22+and+%22you...

... and you can see him here: http://www.youtube.com/watch?v=CHzV4LZnvHc

:)

Igor

Frank van Bortel

unread,
Apr 9, 2008, 7:12:28 AM4/9/08
to
When I google on Moans Nogoods, I get numerous links
indicating "better known as Moans Nogood".

That, in turn, suggests the gentleman in question
is better know by his (self chosen) nickname than by
his original name.

--

Regards,
Frank van Bortel

Top-posting in UseNet newsgroups is one way to shut me up

hpuxrac

unread,
Apr 9, 2008, 10:02:05 AM4/9/08
to
On Apr 8, 6:21 pm, DA Morgan <damor...@psoug.org> wrote:

snip

> >> Amazing how much easier it might be for the OP to find the paper you
> >> refer to it you didn't spend so much time trying to act like you are
> >> part of the "in" crowd.
>
> > Whatever.  Doing some research and finding things tends to be good for
> > people.
>
> I agree. But intentionally misleading them by misspelling what they are
> looking for accomplishes what purpose?
>
> If someone was asking for information about the RETURNING clause would
> you tell them to look up the TURING clause?

You don't have a clue apparently. Not one. This really doesn't
surprise me.

Two things you could try if you actually had a clue.

1) Try doing a google search and use the words "moans nogood you
probably don't need" and see what the top hits are. Leave out the
double quotes as you don't have a clue apparently.

2) I wonder who posts things with the name "moans nogood".

Now maybe if you actually read what was posted in cdos and thought
about it a little before replying?

gazzag

unread,
Apr 9, 2008, 11:35:23 AM4/9/08
to
On 9 Apr, 15:02, hpuxrac <johnbhur...@sbcglobal.net> wrote:
>
> You don't have a clue apparently.  Not one.  This really doesn't
> surprise me.
>
> Two things you could try if you actually had a clue.
>
> 1) Try doing a google search and use the words "moans nogood you
> probably don't need" and see what the top hits are.  Leave out the
> double quotes as you don't have a clue apparently.
>
> 2) I wonder who posts things with the name "moans nogood".
>
> Now maybe if you actually read what was posted in cdos and thought
> about it a little before replying?

In this particular instance, it appears to me, that Daniel did read
the OP and replied appropriately. Either:

a. I have not read/understood the OP, or

b. You're looking for issues where there are none.

Just my tuppence.

-g

0 new messages