RE: Mutliplexing control/redo files

We had a similar experience. When the DB was built it was on an EMC symmetrix 
with mirrored drives, the DBA didn't multiplex because the disks were mirrored. 
Well, the EMC had a failure that affected both the primary and mirrored disk 
and that did in the database.

We multiplex redo and control files even if on the same disk, due to the human 
error factor. I remember a brand new young dba (I'm older now) that 
accidentally deleted a control file, fortunately there was another on the same 
disk, different directory. 



-----Original Message-----
From: oracle-l-bounce@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On 
Behalf Of Michael Brown
Sent: Tuesday, January 25, 2011 12:12 PM
To: mdinh@xxxxxxxxx
Cc: deshpande.subodh@xxxxxxxxx; RStorey@xxxxxxxxxxxxxxxxxx; oracle-l-freelists
Subject: Re: Mutliplexing control/redo files

It also provides protection against "Murphy" errors.  I had a client that did 
not multiplex their redo logs.  They learned their UPS was bad when they had a 
power outage.  Oracle was writing a redo log at the time and it corrupted the 
log so the database was unable to roll forward to a consistent state on startup.

--
Michael Brown
dba@xxxxxxxxxxxxxxxxx
http://blog.michael-brown.org




On Jan 25, 2011, at 1:53 PM, Michael Dinh wrote:

> Multiplexing provides an additional safety net for human errors.
> 
> I still do it and don't think it hurts. (feel free to correct me on the hurt)
> ________________________________________
> From: oracle-l-bounce@xxxxxxxxxxxxx [oracle-l-bounce@xxxxxxxxxxxxx] On Behalf 
> Of Subodh Deshpande [deshpande.subodh@xxxxxxxxx]
> Sent: Tuesday, January 25, 2011 4:10 AM
> To: RStorey@xxxxxxxxxxxxxxxxxx
> Cc: oracle-l-freelists
> Subject: Re: Mutliplexing control/redo files
> 
> multplexing (control files and redo) will help only when there are separate 
> hard disks.
> if its a same storage then multiplesing is not required instead I will prefer 
> regular backup, trace of control file etc.
> 
> thanks..subodh
> 
> On 6 October 2010 19:32, Storey, Robert (DCSO) 
> <RStorey@xxxxxxxxxxxxxxxxxx<mailto:RStorey@xxxxxxxxxxxxxxxxxx>> wrote:
> When I got into Oracle, the big thing was to have multiple physical disks so 
> that you could multpliex your control and redo files on several different 
> physical disks.  You would also put data files on separate disks/raids than 
> your idx files.  Oracle went so far as to outline which raid types were best 
> for which file types . I built a few systems on this principle and they all 
> worked fine
> 
> Then, in the last 5 or so years, Oracle comes out and says SAME is the way to 
> go.  So, I built my latest (3 yrs old) box using just that. 6 physical disks 
> setup as 3 mirrored pairs, and then stripped across. I created several 
> logical volumes within that pool and followed my same principle of separating 
> data and idx, and putting copies of each control/redo into different logical 
> volumes.  Sorry, I'm in a Windows environment.
> 
> But, as I am building my replacement box we are going to be moving to a SAN 
> environment.   So, this begs the question of multiplexing within a SAME or 
> SAN environment and does it still protect us in the way we envision?  It 
> would seem to me now that there is no need to create separate logical volumes 
> anymore.  Those tend to just be a helpful way of organizing the data into 
> easily remembered folders.
> 
> What should be my guiding principle for using the SANS.  If I just create one 
> large LUN, give it a volume designator (D:/) and store everything within that 
> volume, including multiple copies of control/redo,  is that not the same 
> thing as the S.A.M.E principle?  Even if I create multiple LUNS, give each 
> LUN a volume lable, and store my files accordingly, those luns are still just 
> chunks out of the same group of disks.
> 
> Does having a multiplex control file, with copies in separate folders any 
> different that having copies all in the same folder?
> 
> Just curious as to where to direct my hardware folks.
> 
> Thanks
> 
> 
> 
> --
> ==============================
> DO NOT FORGET TO SMILE TODAY
> ==============================
> --
> http://www.freelists.org/webpage/oracle-l
> 
> 

--
http://www.freelists.org/webpage/oracle-l


--
http://www.freelists.org/webpage/oracle-l

Other related posts: