RE: RedHat 6 RAC Specific Questions & Concerns

From: Herring, David <>
Date: Sat, 14 Sep 2013 15:23:59 -0500
Message-ID: <>

I know I'm REALLY late to the game on this, but it's been a relatively painful past experience for me, similar to what others have shared. We have various DR systems that are kept in sync using SRDF. After a few tries under 11gR2 we realized we needed documentation explaining 2 different scenarios when bringing up the DR db - SRDF replicated OCR/Voting disks and when those disks were skipped in replication. As a result I put together a 14-page document explaining in detail the entire process. Because you all have been so nice in sharing links on this I'll have to make sure to compare my notes.

Jeremy, I totally feel your pain about a restore under pressure. We had a 6-node RAC that I was trying to bring up and due to the emergency and importance of this db, I had to share my entire desktop with a large group of people on an emergency call, which started around 10pm and finished sometime after 8am the next day. I believe 1 or more 3-letter acronym folks joining the call to throw their weight around at Oracle to get the help we needed, when we needed it. For me that made things worse because it seemed like the entire client's company pushed Oracle to help me, then Oracle pulled in big-wigs and it was all back to me again. And everyone was watching everything I was typing.

Dave Herring

-----Original Message-----
From: [] On Behalf Of Jeremy Schneider Sent: Monday, August 19, 2013 11:38 AM
To: Andy Klock
Cc: oracle-l; Andrew Kerber
Subject: Re: RedHat 6 RAC Specific Questions & Concerns

Andy -- have a look at note 1294915.1 -- it's for windows but it has a few points where it tells you to run different commands on vs -- and these notes still apply to linux. Remember that the official 11g documentation on oracle's website only applies to -- not or later!! The recovery issue was not purely a syntax change - there was more to it.  It had a lot to do with figuring out what commands had to be executed in what order.

For example: having the ASM spfile inside ASM complicated things a little.  That file probably wasn't anywhere in our backups so we had to get the contents from the alert log... plus there are no asm diskgroups when we started your recovery so we had to temporarily use disk-based pfile/spfile to bootstrap ASM up... and also remember that you don't get to startup ASM directly but have to use special bootstrap-enabled CRS commands to start ASM so you really can't pass a pfile/spfile directly to it. it's not that hard to figure out but it wasn't fun when i occasionally got steps out of order during a high-pressure downtime situation.

I couldn't find a doc or metalink note with all the steps I needed to essentially do a bare metal recovery of on linux. I had to patch stuff together with a combination of related notes (like this one) and a little deduction. Andrew - we're in the thick of some big migrations right now but when I have a chance I'll try to write some of this up in a blog post or something. I did keep pretty detailed notes and session logs for the whole recovery... just need the time to write it up.



On Mon, Aug 19, 2013 at 11:20 AM, Andy Klock <> wrote:

> Was the recovery issue purely a syntax change, or was there more to it
> than that? Do you mine posting the pre and post syntax changes?
> Thanks Jermemy!
> Andy
> On Mon, Aug 19, 2013 at 11:58 AM, Jeremy Schneider <
>> wrote:
> ...
> Frankly ASM is the "simplest" thing to setup... I would just contend
> that
>> block devices are a worthwhile tradeoff b/c while it's a little more
>> complicated to setup initially it's a lot simpler to recover.
>> -J
-- --
Received on Sat Sep 14 2013 - 22:23:59 CEST

Original text of this message