Re: BINARIES - San or Local Storage
- From: Walter Montalvo <montalvo2@xxxxxxxx>
- To: oracle-l@xxxxxxxxxxxxx
- Date: Thu, 26 Aug 2004 18:44:30 -0700
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
-----------------------------------------------------------------
Other related posts:
