RE: Mutliplexing control/redo files

From: Stephens, Chris <Chris.Stephens_at_adm.com>
Date: Fri, 8 Oct 2010 10:03:29 -0500
Message-ID: <D95BD5AFADBB0F4E9BB6C53F14D3A05004FBF0D8E5_at_JRCEXC1V1.research.na.admworld.com>

Not that is really matters but at least for my environment there is no guarantee that a mount point will always and forever be used exclusively for oracle data. I follow a similar standard but name the mount points generically followed by $ORACLE_SID

i.e. /u01/PRODDB1

       /u01/PRODDB2
      /u02/PRODDB1

Not a huge deal but I'm not getting much done at work today and felt like putting in my 2 cents.

Chris

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Joel.Patterson_at_crowley.com Sent: Friday, October 08, 2010 8:53 AM
To: rodd.holman_at_gmail.com; oracle-l_at_freelists.org Subject: RE: Mutliplexing control/redo files

I've been wondering about this but don't really get specifics.

I finally decided 'right'. Put 'em together so I went like this

/orasoft mount point for all software
/oradata/SID1/allDB1files
/oradata/SID2/allDB2files
/oradata/SID3/allDB3files

...
etc.

As for organizational clarity... beauty is in the eye of the beholder. As for deleting your files... oh if that can happen, it can happen on any configuration.

Just havn't got past this. As for putting another mount point on admin or $ORACLE_BASE/'diag' for large tracing... it seems that if oracle cannot write to the alert log, then the db stops anyway so I havn't been able to absorb that concept completely yet.

Joel Patterson
Database Administrator
904 727-2546

---

From: oracle-l-bounce_at_freelists.org [mailto:oracle-l-bounce_at_freelists.org] On Behalf Of Rodd Holman Sent: Wednesday, October 06, 2010 11:30 AM To: oracle-l_at_freelists.org
Subject: Re: Mutliplexing control/redo files

I am also going through a re-architect process for my large db. We are looking at Solaris/ZFS for file systems. Solaris is using the zpool method which effectively creates the same disk ambiguity to oracle that a SAN, NAS, or SAME would. Like Andrew, I use separate folders for organization clarity. I am setting up my layout as follows:

/u01/oradata/SID/system (all the base db tablespaces, undo, and temp that get installed when you do the base install (controlfile goes here))
/u01/oradata/SID/dbf (users01.dbf and any other application tablespaces)
/u01/oradata/SID/redo (obvious)
/u01/oradata/SID/archive (also obvious)
/var/opt/oracle (oratab file, oraInv.loc file, and multiplexed control file.) This is a separate mirrored pair from the zpool. A similar Windows construct would be to put a directory under C: and store a controlfile there as well.

This doesn't provide and real protection or additional security, it just organizes the db files so that anyone coming into the system (We have consultants and other DBA's that are not as familiar with this db as I) can quickly figure out what is where.

The real mount volume (zfs mount point) is at the /u01/oradata/SID level

In a Windows environment I would substitute D: (or what ever drive you mount at) for the /u01 and go from there.

--Rodd Holman

On 10/06/2010 09:35 AM, Andrew Kerber wrote: I like to use different folders because it helps to protect against user error. Other than that, there is no difference. On Wed, Oct 6, 2010 at 9:02 AM, Storey, Robert (DCSO) <RStorey_at_dcso.nashville.org<mailto:RStorey_at_dcso.nashville.org>> wrote:

Does having a multiplex control file, with copies in separate folders any different that having copies all in the same folder? Thanks

--
Andrew W. Kerber


CONFIDENTIALITY NOTICE:
This message is intended for the use of the individual or entity to which it is addressed and may contain information that is privileged, confidential and exempt from disclosure under applicable law. If the reader of this message is not the intended recipient or the employee or agent responsible for delivering this message to the intended recipient, you are hereby notified that any dissemination, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by email reply.



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

Received on Fri Oct 08 2010 - 10:03:29 CDT