将日志文件和数据文件分开以将磁盘从操作系统中分离出来的标准做法（tempdb，备份和交换文件也一样）当您的驱动器都是基于SAN的，并且您的LUN不是刻有特定的磁盘或RAID组时 – 它们只是SAN上x个驱动器的一部分，而LUN只是空间分配
日志和数据驱动器具有不同的数据访问模式，这些数据访问模式在共享驱动器时彼此相冲突（至less在理论上）。
日志写入
日志访问由大量的小型顺序写入组成。 数据库日志有点简单，它们是环形缓冲区，其中包含将数据项写入磁盘上特定位置的指令列表。 访问模式由大量的小型顺序写入组成，必须保证完成，因此写入到磁盘。
理想情况下，日志应该安静（即不与其他任何东西共享）RAID-1或RAID-10卷。 从逻辑上讲，您可以将进程视为主DBMS写出日志条目和一个或多个使用日志的日志读取器线程，并将更改写入数据磁盘（实际上，该进程已经过优化，以便写入数据如有可能，立即出去）。 如果日志磁盘上存在其他stream量，那么磁头将被其他访问移动，并且顺序日志写入变为随机日志写入。 这些速度要慢得多，所以繁忙的日志磁盘可能会造成一个热点，成为整个系统的瓶颈。
数据写入
（已更新）日志写入必须提交到磁盘（称为稳定介质），以使事务有效且有资格提交。 可以从逻辑上将其视为正在写入的日志条目，然后将其用作通过asynchronous过程将数据页写入磁盘的指令。 在实践中，磁盘页面写入事实上是在日志条目被准备和缓冲的，但是不需要立即写入事务来提交。 通过Lazy Writer进程（感谢Paul Randal指出这一点），磁盘缓冲区被写出到稳定的介质（磁盘）中， 这篇Technet文章更详细地讨论了这个问题。
这是一种严重的随机访问模式，因此将相同的物理磁盘与日志共享可能会在系统性能上造成人为的瓶颈。 日志条目必须写入事务提交，所以随机寻求减慢这个过程（随机I / O比顺序的日志I / O慢）会将日志从一个顺序转变为一个随机访问设备。 这在繁忙的系统上造成严重的性能瓶颈，应该避免。 与日志卷共享临时区域时也是如此。
caching的作用
SAN控制器往往具有较大的RAMcaching，可以在一定程度上吸收随机访问stream量。 但是，为了保证事务完整性，需要保证从DBMS的磁盘写入完成。 当控制器设置为使用写回caching时，脏块将被caching，并且I / O调用会向主机报告已完成。
这可以消除很多争用问题，因为caching可以吸收很多I / O，否则这些I / O会出现在物理磁盘上。 它还可以优化RAID-5的奇偶校验读取和写入，从而减lessRAID-5卷对性能的影响。
这些都是推动“让SAN处理它”思想的特点，但是这种观点有一些局限性：
写回caching仍然具有可能会丢失数据的故障模式，并且控制器已经连接到DBMS，并说块已经写到了实际上没有的地方。 因此，您可能不希望为事务性应用程序使用回写式caching，特别是在执行关键任务或财务数据时，数据完整性问题会对业务造成严重后果。
SQL Server（特别是）在一个标志（称为FUA或强制更新访问）强制物理写入磁盘之前，在调用返回的模式下使用I / O。 微软有一个authentication程序 ，许多SAN供应商生产硬件来expression这些语义（ 这里总结的要求）。 在这种情况下，没有任何caching可以优化磁盘写入，这意味着如果日志stream量位于繁忙的共享卷上，则stream量将会发生颠簸。
如果应用程序生成大量磁盘通信量，则其工作集可能会超出caching，这也会导致写入争用问题。
如果SAN与其他应用程序共享（特别是在同一磁盘卷上），来自其他应用程序的stream量可能会产生日志瓶颈。
某些应用程序（如数据仓库）会产生较大的瞬态负载峰值，使其在SAN上非常不友善。
即使在一个大的SAN上，单独的日志卷仍然是推荐的做法。 你可能会放弃在一个轻微使用的应用程序的布局上的麻烦。 在真正的大型应用程序上，您甚至可以从多个SAN控制器中获益。 Oracle发布了一系列数据仓库布局案例研究，其中一些较大的configuration涉及多个控制器。
把责任放在它所属的地方
对于大容量或性能可能成为问题的事情，请让SAN团队负责应用程序的性能。 如果他们将忽略你的configurationbuild议，那么确保pipe理层意识到这一点，系统性能的责任就在适当的地方。 特别是，为I / O等待或页面locking等待或可接受的应用程序I / O SLA等关键数据库性能统计信息build立可接受的准则。
请注意，分散在多个团队中的绩效的责任创造了一个激励，指责并将压力传递给另一个团队。 这是一个众所周知的pipe理反模式，也是一个解决问题的公式，可以拖延数月甚至数年。 理想情况下，应该有一个有权限指定应用程序，数据库和SANconfiguration更改的架构师。
另外，在负载下testing系统。 如果你能安排它，二手服务器和直连arrays可以很便宜地在Ebay上购买。 如果您使用一个或两个磁盘arrays来设置这样一个盒子，则可以使用物理磁盘configuration进行修剪并测量对性能的影响。
举个例子，我在一个大的SAN上运行一个应用程序（一个IBM Shark）和一个带有直接连接U320arrays的双插槽的盒子进行了比较。 在这种情况下，在易趣上购买的价值3000英镑的硬件的性能超过了高达100万英镑的高端存储区域networking（SAN）的两倍 – 在CPU和内存configuration大致相当的主机上。
从这个特殊的事件来看，可能会有这样的说法，说这样的事情是保持SANpipe理员诚实的一个很好的方法。
我假设Equallogic标签和请求的内容意味着您在Equallogic SAN中做了很多工作。 以下是关于Equallogic的具体说明，不适用于其他SANtypes。
使用Equallogicarrays时，用于卷的特定磁盘不能像EMC Clariionarrays那样精确地指定，因此方法必须有所不同。
Equallogic架构是非常自动化和dynamic的。 其基本构build块是arrays单元，而不是RAIDarrays，如同在其他SAN中看到的那样。 每个arrays完全configuration为RAID 5,6,10或50，尽pipe这并不意味着每个arrays只有一个RAID组，但您永远无法在该级别上决定或与之交互。 您将数组放入存储池，然后您的池就属于一个存储组。 存储组具有群集\虚拟IP地址，您可以将该群集用作该组中所有卷的iSCSI发现目标–EQL组pipe理软件和主机MPIO堆栈处理实际路由到最合适的端口所需的IP级别redirect当请求数据块的时候，单个数组是可以控制的，
存储卷是从每个池中的总可用空间中分配的。 池中的所有卷都分布在该池中的所有arrays（最多可达4个独立arrays），以便在networking接口总数（每个Eqlarrays2-4个，取决于型号）和IO尽可能多的控制器。 Equallogicpipe理软件随着时间的推移监视卷\数组的性能，并dynamic地优化块间数据块的分布。 一般情况下，除非您知道自己在做什么，否则应该将所有arrays放在一个池中，让它做到这一点，只要记住确保您configuration了RAID 10，高速磁盘（SAS 10k \ 15k），RAID 50或5，以确保优化过程实际select真正的高性能驱动器。 实际上可能需要几天（7+）才能达到最佳状态，但总的来说，它应该以相当快的速度达到平衡的分配，因为它会立即将数量分配到尽可能多的数组（尽pipe数量可以达到4个）最初创build。
粗略估计，根据驱动器types和RAIDtypes的不同，每个PSarrays的2500-5000 IOP之间将会有一定的距离。 如果您提供了足够的IOP总量，那么即使您将所有卷简单包装到单个池中，自动化pipe理过程也应该会为您提供良好的性能。
但是，如果你想保证你的日志，数据库，临时存储，操作系统驱动器等实际上相互隔离，你可以做一些事情。 首先，您可以为卷定义一个RAID首选项，以确保特定卷始终只存储在该RAIDtypes的arrays上（如果它们存在于该卷所属的池中）。 其次，您可以定义分层存储池，这些存储池只包含能够为特定层提供各种性能等级的arrays，然后将您的卷分配到适当的池中。 这种方法带来的健康警告是，您通常需要大量的arrays才能实现更好的整体性能 – 这对您来说可能不那么重要，而不是保证关键性能的performance，尽pipe如此它仍然是最好的select。 戴尔针对Oracle数据库的参考架构使用一个带有2个用于数据，投票磁盘和OCR的RAID 10arrays的池，以及一个具有用于闪存恢复区的单个RAID 5arrays的独立池。
在Equallogic的所有时间点上，您应该问问自己，如果您就强制分区做出的决定是否能够为可用的networking接口，磁盘主轴和控制器提供更好的集群性能。 如果你不能回答，那么select最小数量的泳池，让它处理的细节，或让Equallogic专家做一个真正的devise。 如果你只有一个数组，那么在分离体积方面你就没有办法做。
我们将数据库存储在单个SAN盒子上，但是具有单独的数据，日志和备份LUN，每个LUN都在不同的磁盘组上，按照速度进行分层 – 具有RAID 10 15Krpm LUN的日志，RAID 1 10 / 15krpm LUN上的数据以及备份到RAID 5个7.2krpm的LUN。 我们还通过同一SAN上的不同控制器提供日志和数据。
好问题！
首先看看布伦特·奥扎尔（Brent Ozar）关于这个问题的“钢铁笼BlogMatch”的辩论。
在我们公司，对于大多数服务器来说，我们把数据和日志放在同一个SAN驱动器上，留给SAN团队来确保一切正常。
我开始认为这不是最好的策略，特别是对于更高容量的服务器。 根本的问题是，我实在无法validationSAN团队是否真的在为我们需要的空间集合足够的驱动器。 我们不会对从我们这边或者其他任何地方的SAN驱动器运行IO基准testing，我们只是假设他们正在“做他们的工作”（调整性能和空间），这可能有点天真。
我的另一个想法是，数据与日志需要的访问types是不同的。 我会尽力find我最近阅读的文章，这篇文章谈论的是如何以不同的方式优化两种不同的驱动器types（我认为需要针对顺序写入进行优化，另一种需要对随机读取进行优化， 。）
总之，是的，您可以为SQL Server数据文件，日志文件和TempDB数据和日志文件创build单独的卷。
由于您使用Equallogic标记了您的问题，请阅读免费的戴尔参考体系结构指南：在devise解决scheme之前，先用Dell™EqualLogic™PS5000系列存储arrays （需要注册） 部署Microsoft®SQLServer® 。 通常你会发现关于特定configuration的指导可能与通用build议有很大的不同 。
我会同意BradC（+1）的performance。 一般来说，一个好的SAN将会拥有比您预期的更多的原始I / O。
把你的BACKUP从你的系统中分离出来还是一个好主意（很明显，我知道，但是如果我每次看到这个都有£1的话）
另外，build议保持tempdb远离日志文件。 当你开始需要Logs，Data和Temp的“不同的桶”（技术术语）时，SAN人员的帐篷会倾斜你的眼睛，但是如果你告诉他们这样，你可以衡量IO去往每个区域的不同数据量，让他们向您展示他们的幻想performance图！
只需双倍/双重检查SAN人员是否适合您。 如果你想RAID 10然后坚持（我做过），即使他们一直说他们的RAID 5没有性能损失。
（对于“基于文件”的操作，RAID 5是没问题的，对于密集写入，只要填满写入缓冲区就可以了！
请注意这里所有术语的混合。
一般而言，非常基本：
你可以在同一个数组上有多个卷，当你在这个线程中讨论的高级优化时，应该记住这点。
关键是其他几个人提到的（不要忘记它），在不同的驱动器主轴上分离数据/日志/备份，而不仅仅是单独的卷。
编辑：上面的Helvick给了你一个关于Equallogic SAN的重要答案！