RE: Virtual RAC on Solaris E15k
- From: "Mark W. Farnham" <mwf@xxxxxxxx>
- To: <oracle-l@xxxxxxxxxxxxx>
- Date: Sun, 13 Jun 2004 23:33:29 -0400
At most, this provides coverage for component failures that fail to bring
down the whole machine. For example, a CPU board could flake out and just
bring down one virtual machine. I don't have MTBF data for e15Ks so that you
could do a case analysis to compute the expected "saving the day" that might
be achieved with this configuration. A wild guess would be almost never.
Second, I don't believe there is a reliable collection of data comparing
rates of single instance Oracle database crashes entirely due to software
with similar crashes for the more complex RAC environment. A wild guess
would be they are pretty close, but that RAC fails enough oftener than
single instance that it covers the spread on single virtual machine
failures.
So for redundancy, I think Cary gave you a spot on short answer.
Now there are some odd ball situations where multiple instances on a single
piece of hardware makes sense, but that has to do with load. For example, if
you have two or more highly divergent user pools that are accessing a
datawarehouse type database, they might profit from being able to have
multiple SGAs that are prewarmed with data correlated the user pools.
Now if your management wants to charter a project to collect the data
required to prove that this is a bad idea, please keep us in mind. I believe
we could do that for a little less than the cost of a second e15k.
mwf
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx
[mailto:oracle-l-bounce@xxxxxxxxxxxxx]On Behalf Of Cary Millsap
Sent: Saturday, June 12, 2004 6:42 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: RE: Virtual RAC on Solaris E15k
Good grief. This is a formula for all of the pain with absolutely none of
the benefit!
Cary Millsap
Hotsos Enterprises, Ltd.
http://www.hotsos.com
* Nullius in verba *
Upcoming events:
- Performance Diagnosis 101: 6/22 Pittsburgh, 7/20 Cleveland, 8/10 Boston
- SQL Optimization 101: 5/24 San Diego, 6/14 Chicago, 6/28 Denver
- Hotsos Symposium 2005: March 6-10 Dallas
- Visit www.hotsos.com for schedule details...
-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx]
On Behalf Of Mark Moynahan
Sent: Friday, June 11, 2004 2:38 PM
To: 'oracle-l@xxxxxxxxxxxxx'
Subject: Virtual RAC on Solaris E15k
Management has come to our team and asked about putting a 9i RAC on a single
e15K. We completed their request by building a two node cluster on a single
e15k. The problem is that management thinks this will buy them redundancy.
When management was asked 'How would RAC on e15k provide redundancy if the
e15k goes down?' their rebuttal was 'The e15k rarely ever goes down and
there needs to be db redundancy in relation to the e15k hardware.' This
doesn't make sense to me. Why bother with virtual RAC when there is still a
single point of failure? The added complexity of RAC doesn't provide any
real benefits. Can anyone argue in favor of putting virtual RAC on an e15k?
Wouldn't a logical standby be a better option?
Thanks,
Mark
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts:
