RE: with all this talk about RAC...
- From: Pete Sharman <peter.sharman@xxxxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Wed, 26 May 2004 02:59:52 +1000
You know, I've kept out of a lot of this discuss= ion because people will
just say "He's from Oracle" and ignore me - w= hich should happen on a
regular basis anyway (the ignoring bit, not saying IR= 17;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 highligh= ted yet in this
discussion. Of the sites I’ve worked with that have= used RAC (and
since that was all I did for a long time, that’s a fair= ly large
number, at least 42), the ones that have run into problems have large= ly
been those who have gone into a RAC environment (or even OPS for that matte=
r) 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 unskilled 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 DBA come into ANY site that requires HA and= /or
the scalability that RAC offers is a recipe for disaster. Likewise, i= f
youdon’t have absolutely rock solid change control, you are just ask=
ing for trouble. One site I worked with 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
smal= l disk problem –lost one of their mirrored control files. Did
th= ey just copy the mirror back again? Nope –they brought in their
l=ast backup of the control file. Why, for crying out loud? Well, in =
thiscase, it was to prove their backup and recovery techniques needed a bit
of = work (tongue firmly in cheek). They’d never tested their
backup.&nbp; When they tried to recover the control file from back, a
completely unneces= sary action of course, they found their backups had
neverworked! L
The point I’m trying to make is simply this –HA, wheth= er RAC
ornot, from any database vendor, is a very unforgiving environment.&nb= sp;
It will point out any weaknesses in your operational procedures, staff, har=
dware and software configurations. Yes there are going to be technical
issu=es, 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-techn= ical issues that can arise simply because you’re not ready
to support HA.
Pete
"Controlling developers is like herding cats."
Kevin Loney, Oracle DBA Handbook
"Oh no, it's not. It's much harder th= an 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...
You wrote:
>>From my experience most of the RAC relat= ed issues comes with unskilled
DBAs managing the databases with their
>>experimental minds.
You cannot argue that the complexity of RAC can = add to the operational
challenges of supporting Oracle. Just thin= k about what might happen if
you have an unskilled DBA walking into a site th= at already has your RAC
installation and has never supported such? = Even an unimaginative,
non-experimentally minded DBA will have problems= with that one!
>>I have implemeted RAC in more than 20+ s= ites in various platforms and
different hardwares and no one (so-far) ha= s >>complained against RAC.
Needless to say for many of them the data/availa= bility is the oxygen for
their business
>>(Most of them are Telecom and banking customers).
Have you polled each and every one of them to as= sure that not one has
experienced an unplanned outage? 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 l= east one of them has had
to address an uptime issue we've disucssed on th= is list!
>>Now coming to the original question, I w= ould recommend Linux Clusters
against Sun clusters. You may also want to >&= gt;use the OCFS (it is stable
now on Linux) and have a shared oracle home. IMH= O RAC is stable and
proven.
Good that you mention the most currently stable environment. This
actually implies there are/were issues, as have = been discussed in prior
threads.
------------------------------------------------= ----------------
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:
