SQL Server Performance Forum – Threads Archive
data files across LUN’sHi There I know for parttioning or just general filegroup administration etc, it is best practice to split your data files on seperate disks, same goes for splitting the clustered and nonclustered indexes on different disks for parrallel reads. What i want to know is this true for LUN’s assigned to the DB Server when working wth a SAN. In other words does Sql Server not know/care that the "disks" are not true local disks ? ANd that there are no real disk controllers? Will Sql Server still take advantage of parrallel IO, even though the LUN’s may be craved from the same raid set, and be assigned to the same storage processor etc on the SAN? Are parrallel reads possible purely from an OS perspective ? If Sql Server thinks they are seperate physical disks it will do parralle IO ? Thanx
Good question. It all depends on how the LUNs are made up. If your SAN administrator can’t tell you on which physical disks the files are going to come, you have no way of knowing whether it will actually speed things up. Except off course for fragmentation: several files on the same LUN can become fragmented, so that is still a reason to use seperate disks (LUNs) for log file and data file.
Personally, I’d still separate the data file from the log file, each on their own LUN. Without knowlegde of the physical disks of which the LUNs are made up, I see no use in splitting the data into separate data files.
not not let the SAN rep setup disks like this, LUNs sharing disk drives
this strategy is so the SAN vendor can justify the ridiculous cost of a SAN create LUNs out of entire sets of disks, unless the intent is to split a set of disks into LUNs for primary file group, 2nd, etc & backup
logs must get their own dedicated disks