Oracle FAQ Your Portal to the Oracle Knowledge Grid
HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US
 

Home -> Community -> Mailing Lists -> Oracle-L -> RE: BINARIES - San or Local Storage

RE: BINARIES - San or Local Storage

From: David Kurtz <info_at_go-faster.co.uk>
Date: Thu, 26 Aug 2004 23:21:09 +0100
Message-ID: <CKEAJBMGFEOCDBFILPJDOEKJEJAA.info@go-faster.co.uk>


How much time are you going to spend accessing Oracle binaries from disk compared to accessing Oracle data files? I would suggest not much. So this is not the main event.

I'll probably get flammed for the following heresy, but you don't spend much time updating Oracle binaries so the RAID level of the disk they are on doesn't really matter. The RAID-5 penalty is for writing.

So, as far as performance is concerned it isn't going to make much difference where you put the binaries (within reason). I think that the administrative considerations are going to be the determining factor here.

regards



David Kurtz

-----Original Message-----
From: oracle-l-bounce_at_freelists.org
[mailto:oracle-l-bounce_at_freelists.org]On Behalf Of Gogala, Mladen Sent: 26 August 2004 22:52
To: 'oracle-l_at_freelists.org'
Subject: RE: BINARIES - San or Local Storage

Binaries on the local disk aren't faster then binaries on Symmetrix, as long as Symmetrix isn't configured as RAID-5, please pardon my French. If Symmetrix is configured as RAID-1+0, then it equals or exceeds internal disks in speed and clearly surpasses them in reliability. Problem is that you are not supposed to waste those internal disks either, so you should put there something that can be easily re-created. Oracle executables are (hopefully) not changing on the daily basis. If they are, then you have problem with gremlins who mastered software engineering, which is an especially nasty variety. Internal disks are usually connected to the rest of the system by 320 UW SCSI III with 320 MBit sec transfer rate while Symmetrix is usually connected by something called FC/AL (Fiber Channel/Arbitrated Loop). Fiber Channel in its latest incarnation surpasses 1GBit/sec, which means that FC controller is significantly faster then SCSI. Disks are usually produced by 3rd party vendor in both cases, so it doesn't really matter. You get 10milisec average access time, which usually turns into 30 milisec per I/O request, which is excruciatingly slow. Now enters the best EMC cash cow: cache memory. It helps significantly reduce average disk access time, but it is not free. As a matter of fact, it is very expensive. Now is the time to stop the story, because we came to the point where I should discuss things like buffer cache efficiency and implementation, priority paging (implemented only by Solaris, of all unixes) and things from the Adrian Cockroft's "Ferrari" book, which definitely outside the scope of this list.

--
Mladen Gogala
A & E TV Network
Ext. 1216



> -----Original Message-----
> From: Duret, Kathy [mailto:kduret_at_starkinvestments.com]
> Sent: Thursday, August 26, 2004 5:10 PM
> To: Oracle L (E-mail)
> Subject: BINARIES - San or Local Storage
>
>
> 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_at_freelists.org
> put 'unsubscribe' in the subject line.
> --
> Archives are at http://www.freelists.org/archives/oracle-l/
> FAQ is at http://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_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://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_at_freelists.org put 'unsubscribe' in the subject line. -- Archives are at http://www.freelists.org/archives/oracle-l/ FAQ is at http://www.freelists.org/help/fom-serve/cache/1.html -----------------------------------------------------------------
Received on Thu Aug 26 2004 - 17:17:59 CDT

Original text of this message

HOME | ASK QUESTION | ADD INFO | SEARCH | E-MAIL US