| 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: with all this talk about RAC...
Once more with feeling, and without HTML. :(
You know, I've kept out of a lot of this discussion because people will jus= t say "He's from Oracle" and ignore me - which should happen on a regular b= asis anyway (the ignoring bit, not saying I'm from Oracle). ;)
But I think there's one point which is THE most important point to me with = RAC that hasn't been sufficiently highlighted yet in this discussion. Of t= he sites I've worked with that have used RAC (and since that was all I did = for a long time, that's a fairly large number, at least 42), the ones that = have run into problems have largely been those who have gone into a RAC env= ironment (or even OPS for that matter) without having the necessary project=management best practices in place.
Let me explain what I mean by project management best practices. A perfect= example is given in Michael's reply. "What might happen if you have an un= skilled DBA walking into a site that already has your RAC installation and = has never supported such?" Whether it's RAC or not, having an unskilled DB= A come into ANY site that requires HA and/or the scalability that RAC offer= s is a recipe for disaster. Likewise, if you don't have absolutely rock so= lid change control, you are just asking for trouble. One site I worked wit= h had NOTHING outside of their production environment, so guess where they = tested new application versions or kernel patches? And for a third example,= there was one site that had a small disk problem - lost one of their mirro= red control files. Did they just copy the mirror back again? Nope - they = brought in their last backup of the control file. Why, for crying out loud= ? Well, in this case, it was to prove their backup and recovery techniques= needed a bit of work (tongue firmly in cheek). They'd never tested their = backup. When they tried to recover the control file from back, a completel= y unnecessary action of course, they found their backups had never worked! =:(
The point I'm trying to make is simply this - HA, whether RAC or not, from = any database vendor, is a very unforgiving environment. It will point out = any weaknesses in your operational procedures, staff, hardware and software= configurations. Yes there are going to be technical issues, just as there= is with any hardware and software. To me, though, that particular problem= is far less likely to cause you grief than the non-technical issues that c=an arise simply because you're not ready to support HA.
Pete
=A0
"Controlling developers is like herding cats."
Kevin Loney, Oracle DBA Handbook
=A0
"Oh no, it's not.=A0 It's much harder than that!"
Bruce Pihlamae, long-term Oracle DBA
-----Original Message-----
From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] =
On Behalf Of Michael Fontana
Sent: Wednesday, 26 May 2004 2:13 AM
To: oracle-l_at_freelists.org
Subject: RE: with all this talk about RAC...
=A0
You wrote:=A0 =
=A0
>>From my experience most of the RAC related issues comes with unskilled
DBAs managing the databases with their =
>>experimental minds. =
=A0
You cannot argue that the complexity of RAC can add to the operational
challenges of supporting Oracle.=A0 Just think about what might happen if
you have an unskilled DBA walking into a site that already has your RAC
installation and has never supported such?=A0 Even an unimaginative,
non-experimentally minded DBA will have problems with that one!=A0 =
=A0
>>I have implemeted RAC in more than 20+ sites in various platforms and
different hardwares=A0 and no one (so-far) has >>complained against RAC.
Needless to say for many of them the data/availability is the oxygen for
their business =
>>(Most of them are Telecom and banking customers).
=A0
Have you polled each and every one of them to assure that not one has
experienced an unplanned outage?=A0 With all the reports on this list, and
my experience with just starting up Oracle 7 OPS after a reboot taking
*** HOURS ***, I think we can safely assume at least one of them has had
to address an uptime issue we've disucssed on this list!
=A0
>>Now coming to the original question, I would recommend Linux Clusters
against Sun clusters. You may also want to >>use the OCFS (it is stable
now on Linux) and have a shared oracle home. IMHO RAC is stable and
proven.
=A0
Good that you mention the most currently stable environment.=A0 This
actually implies there are/were issues, as have been discussed in prior
threads.=A0 =
=A0
-- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://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_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 -----------------------------------------------------------------Received on Tue May 25 2004 - 13:45:42 CDT
 |
 |