RE: with all this talk about RAC...
- From: Pete Sharman <peter.sharman@xxxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Wed, 26 May 2004 04:48:07 +1000
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] =
On Behalf Of Michael Fontana
Sent: Wednesday, 26 May 2004 2:13 AM
To: oracle-l@xxxxxxxxxxxxx
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@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:
