> 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).
