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. --- [EMAIL PROTECTED] 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: [EMAIL PROTECTED] > > 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: [EMAIL PROTECTED] (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 [EMAIL PROTECTED] __________________________________________________ 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: [EMAIL PROTECTED] 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: [EMAIL PROTECTED] (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).
