Some observations based on experience.
Allocating storage based on the controllers helps if
the database is large enough. e.g. 1 controller
manages 100G of physical disk. Use that as a mount
point. This does improve io somewhat if you can have
mount points in 100G multiples (or whatever your
controller manages).
On board caching can be a problem. Oracle writes to
disk but the data actually gets cached rather than
physically written to disk. If a database crashes
before the actual write to disk occurs you lose the
data. Write through caching helps this but offer no
guarantees.
We found that approximately 60% of our io was actually
from the cache rather than disk. The cache lru was
holding the data blocks. This made the reads much
faster.
- tim_at_sagelogix.com wrote:
> > The Sys. Admin. team wants to consolidate storage
> (and
> > probably get a new toy too) on all of our servers,
> so they
> > are evaluating a SAN (LSI Logic E4600). The DBA
> team is
> > doing some research to determine the pros and cons
> of
> > doing this, and I'd like to hear any of your
> experiences
> > (good and bad) using SAN with Oracle.
> >
> > My understanding is that all of our database
> servers would
> > remain intact, but the attached disk storage would
> move
> > into the SAN. So, we still have the Production,
> Test, and
> > App. servers with their processors and memory,
> Oracle
> > homes, etc. The SAN will hold database files from
> > Production, Test, Apps., staging, ODS,data
> warehouse, etc.
> >
> > Their arguments:
> > -the SAN is very scalable (500 GB - 40 TB)
> > -easy to manage disks in one central location
> > -fancy statistics collection on all SAN disks
> > -much higher throughput on the fiber SAN
> connections than
> > with locally attached disk arrays
> > -capable of using mixed RAID levels (0, 1, 1+0, 5,
> etc.)
> > -can partition sets of disks in the SAN for
> specific
> > server access -Snapshot backup capability is very
> fast in
> > the SAN (much faster than traditional Oracle
> backups)
> >
> > DBA arguments:
> > -How will this affect database performance?
> > -What are the drawbacks, if any, with the
> pre-fetch of
> > data performed by the SAN (i.e., SAN cache)
> > -How tunable is the SAN
> > -Fast, small disks are better for performance and
> less
> > wasted space than the typical huge disks in a SAN
> (it's
> > possible to use smaller disks in the SAN) -Prove
> it!
> >
> >
> > After reading the "Sane SAN" article and a case
> study
> > about Volvo implementing a SAN, I believe it's
> possible to
> > have a great Oracle/SAN implementation if it's
> setup
> > correctly and tuned. Other resources that you can
> Google
> > are "Using SVA SnapShot with Oracle", "Performance
> > Benchmark LSI Logic E4600 (STK D178)", "SAN
> Storage for
> > Open Systems Environments", and of course check
> the
> > OraFaq.
> >
> > Thanks for sharing,
> >
> > David Wagoner
> > Oracle DBA
>
> Sounds like you're going through an excellent
> evaluation
> process. I would suggest to keep in mind Anjo's
> advice to
> also regard I/O in terms of units of throughput
> (i.e. read
> or write rates) instead of Gbytes or Tbytes (i.e.
> static
> capacity). Helps clarify the discussions...
>
> The other thing is the idea of co-mingling
> production and
> dev/test. Of course it is possible and quite
> feasible, but
> if you look at things from the perspective of units
> of
> throughput, you might find a huge disparity or
> conflict.
> Perhaps the most telling indicator might be
> reviewing
> whether or not your LANs for production and dev/test
> are
> isolated from one another -- many of the rationales
> for
> doing so (or not doing so) might be similar to the
> considerations for your SAN.
>
> Good luck!
> --
> Please see the official ORACLE-L FAQ:
> http://www.orafaq.com
> --
> Author:
> INET: tim_at_sagelogix.com
>
> Fat City Network Services -- 858-538-5051
> http://www.fatcity.com
> San Diego, California -- Mailing list and web
> hosting services
>
> To REMOVE yourself from this mailing list, send an
> E-Mail message
> to: ListGuru_at_fatcity.com (note EXACT spelling of
> 'ListGuru') and in
> the message BODY, include a line containing: UNSUB
> ORACLE-L
> (or the name of mailing list you want to be removed
> from). You may
> also send the HELP command for other information
> (like subscribing).
Pete Barnett
Lead Database Administrator
The Regence Group
pnbarne_at_regence.com
Do you Yahoo!?
Yahoo! Web Hosting - Let the expert host your site
http://webhosting.yahoo.com
--
Please see the official ORACLE-L FAQ: http://www.orafaq.com
--
Author: Peter Barnett
INET: regdba_at_yahoo.com
Fat City Network Services -- 858-538-5051 http://www.fatcity.com
San Diego, California -- Mailing list and web hosting services
---------------------------------------------------------------------
To REMOVE yourself from this mailing list, send an E-Mail message
to: ListGuru_at_fatcity.com (note EXACT spelling of 'ListGuru') and in
the message BODY, include a line containing: UNSUB ORACLE-L
(or the name of mailing list you want to be removed from). You may
also send the HELP command for other information (like subscribing).
Received on Mon Nov 18 2002 - 11:58:27 CST
