RE: with all this talk about RAC...

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 I&#82= 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_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...   

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