RE: Mutliplexing control/redo files
- From: "Stephens, Chris" <Chris.Stephens@xxxxxxx>
- To: "Joel.Patterson@xxxxxxxxxxx" <Joel.Patterson@xxxxxxxxxxx>, "rodd.holman@xxxxxxxxx" <rodd.holman@xxxxxxxxx>, "oracle-l@xxxxxxxxxxxxx" <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 8 Oct 2010 10:03:29 -0500
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Joel.Patterson@xxxxxxxxxxx
Sent: Friday, October 08, 2010 8:53 AM
To: rodd.holman@xxxxxxxxx; oracle-l@xxxxxxxxxxxxx
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@xxxxxxxxxxxxx [mailto:oracle-l-bounce@xxxxxxxxxxxxx] On
Behalf Of Rodd Holman
Sent: Wednesday, October 06, 2010 11:30 AM
To: oracle-l@xxxxxxxxxxxxx
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@xxxxxxxxxxxxxxxxxx<mailto:RStorey@xxxxxxxxxxxxxxxxxx>> 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.
Other related posts:
