Oracle FAQ Your Portal to the Oracle Knowledge Grid

Home -> Community -> Mailing Lists -> Oracle-L -> RE: Oracle RAC cost justification?

RE: Oracle RAC cost justification?

From: Wiegand, Jeff <>
Date: Fri, 3 Jun 2005 13:48:33 -0500
Message-ID: <>

We're a totally online University with growth in the 35% to 40% range yearly. We currently have about 12,000 students running on a third party learning system, with Weblogic the middle tier, clustered. The majority of our students hit the system at the same time each day, and the same days of the week, so we have a high level of concurrency with highest volumes Sunday evenings. So we need to scale to support Sunday evenings, no matter what happens the rest of the week.=20

This is our business, so we have to be up at all times. Our growth is significant. We are implementing a system that can scale up and/or out.

We were sold RAC on Windows two years ago - I was hired AFTER. Horrible. We are moving to Solaris, with RAC. We have Campus licensing, so we do not incur a RAC cost; we pay to run EVERYTHING on Oracle and can have 5,0000 RAC nodes if we want. We have off-site DR, with RAC, using Data Guard. We considered using Veritas volume manager or whatever it is to map across two CX3XX SANs, so the SANs would not be a SPOF. We still might with the next budget.

For myself, I want to relax, knowing that if something happens to a server, there are others up and life goes on. Our production is hosted, and guess what? They've unplugged the wrong server before?! Human error is alive and well, and I'm guilty too. Also, we don't have to spend 8 years figuring out scalability needs 3 and 5 years down the road. And what happens after the vendor upgrades the app? All the previous load testing is out the window. RAC it is.=20

Thank god for RAC in a Windows environment, because we've had a half dozen failures with Windows, and I'd say 90% of the students do not experience the outage. We are 75/25 read/write. So on to Solaris ...

-----Original Message-----
[] On Behalf Of David Sent: Friday, June 03, 2005 9:36 AM
Subject: RE: Oracle RAC cost justification?

When ya get right down to it I don't care about complexities and inconveniences. I get paid well for those headaches. What I care more about is that the Interconnect and the architecture has severe =3D limitations.
Measurements and analysis must be done on a case by case truly.

I contend that folks that are using RAC in Active/Passive mode go do so =3D
as well without RAC and not lse a thing.=3D20

RAC has mertis where it works an all or some nodes are shared actively. David

-----Original Message-----
From: =3D
On Behalf Of Mark W. Farnham
Sent: Friday, June 03, 2005 7:13 AM
Subject: RE: Oracle RAC cost justification?

It seems everyone keeps dodging the question of measurement.

Is the sum of "inconvenience" to the business process of a robustly configured SMP greater or less than the sum of "inconvenience" to the business process of a robustly configured RAC system?

First, you have to define what is "inconvenient" in your particular =3D business

For some businesses (in fact probably yours, since you have an =3D identified
time of requiring high availibility) there is little or no inconvenience =3D
outages for preventive maintenance and upgrades. (Call this polar case A =3D

For other businesses any outage at any time is a problem. (Case B).

Second, what do I mean by "robustly configured?" That means no stupidly configured single points of failure, and only considering failure points that a reasonably smart and experienced compulsive obsessive =3D sysadmin/dba
team would not preempt in configuration.

Now again, this is really a question for a measurement and/or =3D simulation,
but based on what I've seen:

In Case A you're far more likely to fail due to the complexities of RAC =3D
due to a hardware failure.

In Case B unless your overall required uptime for the system is significantly less than the MTBF (mean time between failures) for the aggregate of the failure rate due to all components that cannot be =3D repaired
on the fly, RAC wins because eventually you need an outage for =3D preventive
maintenance or an upgrade.

Now a tiny percentage of you out there may have a compute size problem = =3D
the largest available horsepower (including descaling due to memory bus =3D
all other hardware
contentions) in a single box is not enough. For that case RAC wins, but =3D
probably be more expensive and failure prone (but by a declining amount asymptotically to a non-zero but possibly insignificant value above the failure of a single box) than a single box if one big enough existed.

The other case where RAC has an advantage is when the size of the =3D compute
problem is currently modest but has a substantial chance to change =3D upward at
an unpredictable rate.

Then you can add nodes to RAC. Now the more nodes you have the more =3D problems
you introduce. But that is a strawman to the growth arguement, because = =3D
one says the nodes you add have to be the same size as your original =3D nodes.

And remember, until we get to 47, we don't have enough messages in a =3D thread!



-----Original Message-----
From: =3D
[]On Behalf Of Yechiel Adar
Sent: Friday, June 03, 2005 6:22 AM
Subject: Re: Oracle RAC cost justification?

We are going with RAC now due to business needs. We are a medium bank, ~100 branches, and we are going to implement an imaging system for checks. All the checks are sent to the information center, and are scanned and the images are put in Oracle db. Each =3D morning
about 3-4 people in each branch needs to go over the checks that were = =3D
against the accounts they manage. Then they OK or reject the checks. If =3D
server goes down during that period all hell breaks loose. So we are =3D going
with RAC and TAF, since most of the work is reading data from the =3D database.

Oh, the database is on a SAN, with real time copy to DR site, over =3D fiber.

Adar Yechiel
Rechovot, Israel

Larry Elkins wrote:

>And though it strays a bit at times, but not very far, I've found
>thread very interesting, even if it is 28 emails so far (more now =
>suppose). I am very interested in what people are seeing in the =
>world regarding RAC, and why they chose it, why they like/regret =
>and alternatives that have been considered. So yeah, I don't know=3D20
>diddly about RAC ;-) That's why I find this thread interesting, it
>very educational
>;-) I can read all the docs and white papers until I'm blue in the face
>real world takes on it are nice to hear.
>Larry G. Elkins



Received on Fri Jun 03 2005 - 14:53:37 CDT

Original text of this message