请看下面的两个精彩解答:
解答1:
If your SAN has performance and availability algorithms built into the management software then yes, it is a good idea for both performance and availibility to put them on the SAN. As I understand it, SANs manage the pools and dynamically allocate storage as needed for either performance or disk failures (it senses that the disk is about to fail due to low performance metrics and physically moves files to other disks in the pool).
It is best practice to put log files and data files on seperate "physical" disks for 2 reasons:
In an ideal situation, the log files and data files would reside on disks found on seperate controllers as this is the best performance and HA gain along with the disk speed and RAID choice.
解答2:
One thing to consider is that the log files are sequential writes where as the data files are non sequential. That is one of the reasons for separate LUNs. Log files write faster if they are on their own LUN because the spindles don't have to skip around, just write sequential. If you add in a data file then the spindles have to skip around and you lose some performance. I'm hoping I got the right terminology there as I'm not all that familiar with SANs themselves. The idea behind it should be however.
Frequently vendor recommendations are wrong when it comes to SQL Server. Just because SQL Server has different needs than most applications that use a SAN.
参考资料
=======================
SQL Server - Separating data, log, and TempDB files on a SAN
Any benefit to separate LUNs for log/DB when using SAN pooled storage?