| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
 |
 | |||
| Oracle FAQ | Your Portal to the Oracle Knowledge Grid | |
|
| |||
Home -> Community -> Mailing Lists -> Oracle-L -> Re: Virtual RAC on Solaris E15k
Mark,
If the E15K rarely ever goes down, then why is redundancy within the E15K being discussed at all? Circular argument, does not compute, does not compute, brain imploding...arrrggghhhhh...<pfffttt!>...
I suggest that you first take the discussion away from this specific situation, and decide on why RAC would be utilized at all in the first place, whether it is on two different partitions of the same E15K, or multiple independent nodes of a cluster, or a clustered HAL 9000 ("I'm sorry, Dave -- that will cost you $60,000 per processor, Dave" "Arrggghhhh...<pfffttt!>")...
What precisely are they trying to accomplish with RAC? Not the elevator speech; in detail?
High-availability through redundancy? In what way are clustered databases redundant? There is one database on shared storage, so there is no redundancy (due to RAC) at that level. Thus, if someone drops or truncates a table in production, RAC is not going to help at all. RAC does not provide data redundancy. Database replication mechanisms like Data Guard, Adv Rep, and Streams provide database redundancy.
RAC is multiple instances on the same database, so RAC provides redundancy of services. Lose one database instance (a.k.a. Service), and another instance or service is available to carry the load. So, what causes a loss of an instance or service?
Management has already ruled out the possibility of unplanned failures on the E15K, right? What!!!! They say we have to protect against unplanned failures anyway? Arrrrggghhhhhh! Brain imploding...<pffftt!>...
Of course! Bugs and operator error. Software and softer-ware. Those things will cause unplanned outages.
Yes, reducing operator error by improving security and procedures is a better resolution rather than making the services redundant. I mean, if I applied that logic to real life, my wife and I would have tried to have two sets of twins instead of just two "singleton" kids, just in case we drop one of them from a balcony or lose one at the shopping mall. Judging from the gaunt exhausted appearance of some of the parents of twins I've seen, I think I'd rather work to reduce the lethality of my actions toward my offspring, rather than take the "redundancy" route. Same thing with computers.
Bugs? Let's see, is the prevalence of serious bugs greater or lesser for RAC as compared to non-RAC? Anyone? Anyone? Bueller? Anyone?
OK. RAC doesn't seem to do a whole lot to deal with unplanned outages; at least the pluses and minuses seem to even out. So, let's instead focus on "planned outages", such as upgrades or patches. RAC might be able to help here. Very much so, since these outages are likely the primary cause of downtime. Certain upgrades/patches to the E15K hardware might benefit from the technique of "rolling upgrade". Ditto for certain portions of the Solaris operating system. However, Oracle Support states specifically that rolling upgrades are verboten for RAC, so that's a non-starter. If you're upgrading or patching your application software and the upgrade/patch doesn't touch the database, then it is possible that rolling upgrades could be employed for that too. If, however, your application software upgrade or patch touches the database, then forget about doing a rolling upgrade there, too.
In summary, your management's proposed configuration cannot protect against a mishap within the database (i.e. dropped table, bad update of data, etc), because database redundancy is not what RAC does.
Since they do not believe that the E15K can fail (except "rarely", whatever that means, which evidently feels like "never" to them), protecting against unplanned instance failure is not a concern. Well, hardware failure is not a concern, but buggy software and airhead DBAs probably are. Enough said about that.
So, the sole benefit of using RAC in this manner is facilitating certain types of rolling upgrades. Which is, in fact, a very good use of RAC.
Of course, management is planning to have a completely separate test E15K for testing all these rolling upgrade scenarios, right? What!!!! They are going to perform these rolling upgrades for the first time in the production environment? Arrrrgggghhhhh! Brain imploding...<pfffttt!>...
Hope this helps...
-Tim
on 6/11/04 1:37 PM, Mark Moynahan at Mark.Moynahan_at_apollogrp.edu wrote:
> 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_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html
> -----------------------------------------------------------------
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------Received on Sat Jun 12 2004 - 02:32:27 CDT
 |
 |