Please start any new threads on our new
site at https://forums.sqlteam.com. We've got lots of great SQL Server
experts to answer whatever question you can come up with.
| Author |
Topic |
|
smino
Starting Member
2 Posts |
 Posted - 2009-09-09 : 10:05:41
|
| First off I am not a SQL admin, but a san admin. I am trying to understand SQL performance, to better help the sql admin here.His current setup:C drive Scsi OS and SQL program installFusions IO drive (testing) 80GB for all databases.What I believe should be done is to have both the OS and DB on the fusion IO, to prevent the SCSI C drive as being a bottle neck. Can this be the case? Assuming the Databases only are on the fusions IO drive (very fast 130000IOPS/1.1GB/s Read and write) what does SQL hit on the C drive?Is there anything like a cache DB that might be on the Cdrive, other than the OS cache? Is there anything that is referenced often on the C drive, such as the sql program itself that would benefit greatly from being on the fusion io drive? Comments?His databases are roughly 50GB-60GB, and the amount of data coming in every hour is huge.Sylvain Mino |
|
|
tkizer
Almighty SQL Goddess
38200 Posts |
Posted - 2009-09-09 : 13:08:59
|
| It is not recommended to put SQL Server on the OS partition. When you install SQL Server, even if you specify all files to go to a different drive such as the E drive, it still must put some files on the OS drive (typically C).You should see very little activity on the C drive if SQL Server is properly placed on a different drive. PerfMon should show pratically nothing happening on the C drive. Most/all activity will come from the location of the MDF and LDF files.I do not know what a fusion drive is. We put all of our databases on the SAN.Tara KizerMicrosoft MVP for Windows Server System - SQL Serverhttp://weblogs.sqlteam.com/tarad/Subscribe to my blog"Let's begin with the premise that everything you've done up until this point is wrong." |
 |
|
|
Sitka
Aged Yak Warrior
571 Posts |
Posted - 2009-09-11 : 08:36:30
|
| How big are the solid state drives?Reading recent history when solid state drives were small, the usage seems to have been locating the tempdb to them, but the operations to the data are going to determine the effectiveness of that.Say for instance every hour this dba is running a ETL (extract transform load) package that makes use of large #temp staging tables, then you could see how SSD would help a lot. However that result of that ETL operation may end in high transactional log activity (which could also benefit from SSD). Ask the dba how big his transactional log size is (average and max) between tlog backups. It is frustrating trying to strategize (shoehorn) db storage onto disks that are too small. I'm jealous of your sql admin to have you helping him, and the solid states."it's definitely useless and maybe harmful". |
|
|
|
|
|
|
|
|
Understanding performance on SQL