SQL Server最佳做法build议为数据和日志文件分开的驱动器。 如果两个逻辑驱动器位于相同的EVA上，你真的会增加速度吗？
啊 – 只是我的专业领域！
SQL的“最佳实践”假设您使用单独的物理磁盘作为数据，并且logging是，但是在具有本地连接的物理磁盘的服务器中，或者通过传统的SAN方法（其中LUN只是单个SAN磁盘的一部分）。 EVA与这个非常不同。
根据哪种型号，您有任何给定的LUN将分布在8个物理磁盘中的最less一个，如果是P6xxx，则可以是12个或更多。 所以如果你的日志分布在8个或8个以上的磁盘上，并且你的数据分布在另外8个或更多的磁盘上，你显然会看到比只有两个磁盘上的数据更好的性能。 鉴于这是性能最低的configuration，您可能会看到更好的性能，因为更广泛的传播，我认为你会同意，这个“最佳做法”与地狱与EVA。
基本上只是把它们从最大的磁盘组中划分出来（你真的希望单个DG中的磁盘的types/速度都是相同的），让EVA担心其余部分。 我在多个EVA / P6xxx / 3Par盒子上运行了许多MSSQL集群，现在真的没有必要像以前那样用旧的SANarrays来回溯到2000年代。
可能，是的…每个块设备排队是一个独特的区域，即使在进入相同的物理磁盘组时也可能受益于分离。
完全同意Chopper3。 数据库文件/日志理论上的磁盘分离性能，你为古老的JBOD做了很久了。
一个大的磁盘组（大量的主轴）的EVA是你所需要的。
另外，如果你实际上在硬件层面上观察SQL Server或者Oracle，在DB文件上的磁盘I / O数量可以通过大量的RAM来抵消。 日志，是的，他们仍然按顺序写; 只要确保您的日志滚动阈值设置为符合您的事务处理速度。
我们在VMware上运行一些中等大小（300GB）的Oracle实例，运行在EVA上。 这增加了另一层抽象; 即：
O / S卷（NTFS） – > VMware VMDK文件 – > VMware数据存储（VMFS文件系统） – >与其关联的vRAID级别的EVA虚拟磁盘（LUN） – > EVA磁盘组 – >物理FC / AL驱动器
因此，如果您要求计算机科学家定位包含您的数据库块的磁盘块，为了应用一些优化build议，他或她只会耸耸肩。
通常，在具有特定卷的特定存储的旧存储上，他们build议将日志和数据保留在不同的子集上。 现在，大多数存储都安装了跨越大型磁盘组跨越所有IO的池。 在一个大池中，没有必要避免在同一个磁盘上有任何数据库的日志和数据，但是由于ewwhite在他的回答（队列争用）中提到的原因，我仍然build议把它们保留在不同的卷上。