Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: with all this talk about RAC...

RE: with all this talk about RAC...

From: Pete Sharman <peter.sharman_at_oracle.com>
Date: Wed, 26 May 2004 04:48:07 +1000
Message-Id: <200405251848.i4PIm9m7025163@rgmgw3.us.oracle.com>


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



Please see the official ORACLE-L FAQ: http://www.orafaq.com

To unsubscribe send email to:=A0 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
-----------------------------------------------------------------


----------------------------------------------------------------
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

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US