Mutliplexing control/redo files

From: Storey, Robert \(DCSO\) <"Storey,>
Date: Wed, 6 Oct 2010 09:02:32 -0500
Message-ID: <6727A8A8C9EAF343B21C48BF04DB6453295E96_at_dcsosvms01.dcso.org>



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

--
http://www.freelists.org/webpage/oracle-l
Received on Wed Oct 06 2010 - 09:02:32 CDT

Original text of this message