Oracle FAQ | Your Portal to the Oracle Knowledge Grid |
![]() |
![]() |
Home -> Community -> Mailing Lists -> Oracle-L -> RE: Oracle RAC cost justification?
Mark,
You are correct. Everybody dances around the issue but fails to ask the clear-eyed question about the actual cost/benefit of using RAC. So far, I have not seen a clear-case for using it - since there are so many other ways to accomplish the business mission of the problem. The $ cost of RAC is so high that it bumps up against actual hardware costs. And then add in the complexity factor of managing the software (want to talk about rolling Oracle upgrades in a RAC environment?) that the number of actual cases where RAC makes sense diminishes greatly.
Tom
PS: What message number am I? Do I win? LOL!
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Mark W. Farnham
Sent: Friday, June 03, 2005 10:13 AM
To: adar76_at_inter.net.il
Cc: oracle-l_at_freelists.org
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
business
situation.
For some businesses (in fact probably yours, since you have an
identified
time of requiring
high availibility) there is little or no inconvenience to outages for
preventive maintenance
and upgrades. (Call this polar case A for reference.)
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 sysadmin/dba team would not preempt in
configuration.
Now again, this is really a question for a measurement and/or
simulation,
but based on
what I've seen:
In Case A you're far more likely to fail due to the complexities of RAC
than
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 repaired on the fly, RAC wins because
eventually
you need an
outage for preventive maintenance or an upgrade.
Now a tiny percentage of you out there may have a compute size problem
where
the largest
available horsepower (including descaling due to memory bus and all
other
hardware
contentions) in a single box is not enough. For that case RAC wins, but
will
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
compute
problem is
currently modest but has a substantial chance to change upward at an
unpredictable rate.
Then you can add nodes to RAC. Now the more nodes you have the more
problems
you introduce.
But that is a strawman to the growth arguement, because no one says the
nodes you add have
to be the same size as your original nodes.
And remember, until we get to 47, we don't have enough messages in a thread!
Regards,
mwf
-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Yechiel Adar
Sent: Friday, June 03, 2005 6:22 AM
Cc: oracle-l_at_freelists.org
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 morning about 3-4 people in each branch needs to go over the checks
that were issued against the accounts they manage.
Then they OK or reject the checks.
If the server goes down during that period all hell breaks loose.
So we are going with RAC and TAF, since most of the work is reading data
from the database.
Oh, the database is on a SAN, with real time copy to DR site, over fiber.
Adar Yechiel
Rechovot, Israel
Larry Elkins wrote:
>And though it strays a bit at times, but not very far, I've found this
>thread very interesting, even if it is 28 emails so far (more now I
>suppose). I am very interested in what people are seeing in the real
world
>regarding RAC, and why they chose it, why they like/regret it, and
>alternatives that have been considered. So yeah, I don't know diddly
about
>RAC ;-) That's why I find this thread interesting, it is very
educational
>;-) I can read all the docs and white papers until I'm blue in the face
but
>real world takes on it are nice to hear.
>
>Regards,
>
>Larry G. Elkins
>elkinsl_at_flash.net
>214.954.1781
>
>
>
>
>
-- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-l -- http://www.freelists.org/webpage/oracle-lReceived on Fri Jun 03 2005 - 10:32:45 CDT
![]() |
![]() |