RE: BINARIES - San or Local Storage
- From: "Loughmiller, Greg" <greg.loughmiller@xxxxxxxxxxxx>
- To: "'oracle-l@xxxxxxxxxxxxx'" <oracle-l@xxxxxxxxxxxxx>
- Date: Fri, 27 Aug 2004 06:59:11 -0500
I have read this thread, and haven't seen any one mention hardware
clustering and your file systems..
We typically run every database in a HW clustering config (SUN cluster,
Veritas VCS,etc). We found that placing the binaries on the SAN allowed us
to "fail over" a little more effectively. Just one way of doing it.... Works
better with our overall strategy. When the hardware goes "south", the
resource groups have the Oracle binaries defined as a component, the file
systems for the binaries/data files fail over to the member node of the
cluster.
Another "standard" has been to use the internal drives for OS required items
(TMP, SWAP, /opt, /home , etc). All products/applications get to live on the
SAN. Now there are exceptions as vendors like to force the use of specific
file systems(why?) like /etc or /var/opt.
greg
-----Original Message-----
From: Walter Montalvo [mailto:montalvo2@xxxxxxxx]
Sent: Thursday, August 26, 2004 9:45 PM
To: oracle-l@xxxxxxxxxxxxx
Subject: Re: BINARIES - San or Local Storage
Kathy,
If the local disk are NOT mirrored (either RAID-5 or RAID-1), I put them on
the SAN.
That way I dont worry about a disk failure wiping out my binaries and
config files.
HOWEVER, if the local disks are not mirrored it might mean that the root
disk is not mirrored, which make me more nervous.
Having RAC and all the redundancy from the SAN means little if your UNIX
kernel root disk is not mirrored!
If your local disk ARE mirrored, as they should be for a High Availability
system, then I have no problem putting the binaries on the local MIRRORED
disks.
Yes, SAN *sequential* read performance is higher that local disks, but
really, most of the time the reads occur when starting up the
instance. After that there is hardly any activity on the disks.
Periodically there are writes to the alert log and trace files, but they
are very low volume and hardly constitute a bottleneck for the system. All
your datafiles, including archive logs and redo logs, should be on the SAN.
Do you want to share/fail over your binaries with another host? Most
likely no, so less of a reason to put them on the SAN.
Walter
At 02:10 PM 8/26/2004, you wrote:
>We are in the process of moving to 10G and getting a new SAN EMC Clarion
>Storage Array. We also MAY be going to RAC. These are Solaris Boxes
>
>The question is I have read conflicing things about whether to put the
>binaries on the local internal disks or the SAN arrays.
>
>I have always put the binaries on the local internal disk. What do you do
>and why?
>
>Is the local reads for the binaries that much quicker?
>
>
>Thanks,
>
>Kathy
>Oracle Database Monkey
>
>
>
>
>This transmission contains information solely for intended recipient and
may
>be privileged, confidential and/or otherwise protect from disclosure. If
>you are not the intended recipient, please contact the sender and delete
all
>copies of this transmission. This message and/or the materials contained
>herein are not an offer to sell, or a solicitation of an offer to buy, any
>securities or other instruments. The information has been obtained or
>derived from sources believed by us to be reliable, but we do not represent
>that it is accurate or complete. Any opinions or estimates contained in
>this information constitute our judgment as of this date and are subject to
>change without notice. Any information you share with us will be used in
>the operation of our business, and we do not request and do not want any
>material, nonpublic information. Absent an express prior written agreement,
>we are not agreeing to treat any information confidentially and will use
any
>and all information and reserve the right to publish or disclose any
>information you share with us.
>
>
>----------------------------------------------------------------
>Please see the official ORACLE-L FAQ: http://www.orafaq.com
>----------------------------------------------------------------
>To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
>put 'unsubscribe' in the subject line.
>--
>Archives are at //www.freelists.org/archives/oracle-l/
>FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
>-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
----------------------------------------------------------------
Please see the official ORACLE-L FAQ: http://www.orafaq.com
----------------------------------------------------------------
To unsubscribe send email to: oracle-l-request@xxxxxxxxxxxxx
put 'unsubscribe' in the subject line.
--
Archives are at //www.freelists.org/archives/oracle-l/
FAQ is at //www.freelists.org/help/fom-serve/cache/1.html
-----------------------------------------------------------------
Other related posts: