October 7, 2009 at 11:58 am
I have inherited a SQL Server 2005 that had been built and maintained by Windows admins who are not proper DBAs (myself included!). We are hosting 19 small databases for different applications (Trend Micro products, VMWare virtual center, sharepoint, etc), the largest one being a 17GB database. I have about 25GB of user mdfs and about 17GB of user ldfs.
For DAS, I have (2) 67GB drives for OS mirroring, and (4) 136GB drives for storage on a RAID controller - 2 drives on each channel.
I also have SAN storage available on an EMC CX-3. Right now the server is configured with user and system databases and logs stored all over the place with no organization or separation, on the OS drives, storage drives, and SAN drives.
I would like to rebuild the server per best practice and I am wondering where to store program files, system databases, user databases, transaction logs, and tempdb to reflect best performance and reliability. Our SAN administrator has all the drives in our enclosures configured for RAID 5 and is unwilling to set up a RAID 10 or RAID 1. I am able to configure the DAS drives in either RAID 10 or RAID 1.
Any suggestions would be appreciated! Let me know if any more info is needed about my environment.
Thanks!
October 7, 2009 at 1:26 pm
create a lun for temp DB ,make sure you create on file per core and set the size of each of them to the same at startup, 2005+ uses temp a lot temp DB
one LUN for transaction log
one LUN for DB
one LUN for SQL -- although you could run it off server...I generally create a lun for it
you can always add an exra lun later and split the DB if need
your is simple link that might help a bit
October 7, 2009 at 2:49 pm
Thanks for the reply. I originally thought about doing that, but I cannot guarantee that the LUNS are not going to be shared. I also heard that DAS can be faster in some cases (especially when the LUNs are RAID 5 and shared) so where can that come into play?
thanks!
October 7, 2009 at 3:08 pm
well a couple of things, the SAN has lots of cache...and SQL uses that by using read ahead, this helps a bunch, the engine will go out an start grabing pages that is thinks it will need even before the I/O is asked for. Second thing is when using a SAN you can get away with much more fragmentation and page splits then via the server
Linchi Shea -- had about 5 articles on fragmentation on a SAN, surprising when you rebuild an index on SAN you see very very little improvement...due to the cache and read ahead issue.
so I would say go with the SAN. also keep in mine that your SAN has a lot more spindles then your Server this will help.
on ? you said the San ADMIN will not change over to 10 from 5 is there something being used on the LUN's now. Maybe he has empty luns at the moment?
anyhow read Luchi blogs and after such I am guess you will go with the SAN ...I have also included an counter argument to read.....good luck
http://sqlblog.com/search/SearchResults.aspx?q=fragmentation
http://kendalvandyke.blogspot.com/2009/02/disk-performance-hands-on-part-5-raid.html
October 7, 2009 at 3:21 pm
Unfortunately, he (and management) do not believe we need RAID 10. They don't think we would gain much for the disk cost because we are a small to midlevel organization (3000 users). We also have an Oracle ebusiness suite infrastructure running on the same SAN serving a couple of thousand users - they think that its performance on RAID 5 is acceptable, so in their mind there is no reason to change for a "little SQL box" such as this one.
I will go ahead and plan for LUN usage for all components, but probably keep the program files on the DAS.
Viewing 5 posts - 1 through 4 (of 4 total)
You must be logged in to reply to this topic. Login to reply