SQL Server 2014，标准版（在 vmware 下运行，fwiw）。添加 Dell MD3420 DAS 盒。
在旧学校，您会为 MDF、LDF、TEMPDB、BACKUP 设置离散的轴组。
例如
- MDF：数量 6：300GB-15K，RAID 10 // 900GB 存储
- LDF: Qty 4: 150GB-15K, RAID 10 // 数据占用空间更小，主轴增加 IOPS
- TEMPDB：数量 4：150GB-15K，RAID 10 // 数据占用空间更小，主轴增加 IOPS
- 备份：数量 2：2TB，RAID 1
用例：该系统有5个数据库，并且是OLTP。
现在，我被告知：只需设置数量 10：600GB-15K 驱动器，并将 MDF、LDF、TEMPDB 和 BACKUP 全部放在那里。较大的主轴集的整体性能更高，足以弥补备份期间同时写入 LDF 和 BACKUP 的限制。
- a) 这种新方法是正确的方法吗？
- b) LDF应该是相对于MDF是离散的……感觉好笑！
- c）我真的觉得备份应该是他们自己的主轴集（出于很多原因）
获胜者是？SQL 传统？还是戴尔存储架构师？
这首先是数据库恢复问题，其次是性能问题。
数据库恢复：
通过将 LDF 和 MDF 文件保存在同一个物理阵列中，您将失去执行“日志尾部”备份的任何机会。这意味着您的数据已从以下任一位置消失：
从失败的阵列中取出并复制的最后一个事务日志。
其他地方的镜像对/可用性组/复制数据库
所以第一个问题是“你能丢失多少数据”。如果您不能丢失超过备份日志的频率，那么将其放在该阵列上将无法满足您的数据丢失目标。
表现：
其余的实际上取决于您的使用模式。好像您没有活动的机器，我们可以从中获取基线，如果我错了请告诉我。假设我们不这样做，我们应该明白 DiskIO 是至关重要的，尤其是当可能没有足够的 RAM 或在高事务环境中时。你认为它会非常具有交易性吗？如果是这样，请为事务日志驱动器提供大量磁盘。那个版本的 Dell SAN 可以让你短行程你的磁盘，这应该会给你一个很好的性能提升，因为事务日志驱动器通常去多磁盘不是为了空间，而是为了写入性能。
将 TempDB 放在它自己的磁盘上很有用，但如果您对为什么要这样做没有任何真正清晰的想法，那么您真的应该对此进行测试，或者只是将它放在同一个阵列中并进行测试。 TempDB可能有奇怪的模式，因此您可能会获得各种性能结果和增长。不过，许多人只是将其与数据放在同一磁盘上。在这种情况下由您决定。
有时可能值得通过应用程序模式和支持它们的数据库来隔离磁盘。我不确定你是否有那个选项。如果不这样做，您的布局看起来不错，但如果不进行测试就无法判断。就我个人而言，我会先尽可能多地进行测试，看看我们期望增长多少，然后看看向主数据阵列添加更多 IOPS 或将它们分开是否更有意义。
你能做任何类型的基准测试吗？
最终答案：
正如阿里和此处的其他发帖人指出的那样，真正的问题是：详细的用例是什么？
说“OLTP”并不能回答问题。真正的问题要详细得多。例如“TEMPDB 是否一直受到锤击（这样你就想将该 IO 与 MDF IO 隔离开来）”
在我们的例子中，更大跨度（更多轴）的好处明显大于 TEMPDB 负载，因此这是第 1 步：
下一点是备份。如前所述，备份必须在差异跨度上。
现在困难的是：LDF。按照这本书的说法，LDF 应该比 MDF 在差异磁盘系统上。这是旧的、已建立的 SQL Server 协议。
但这意味着降低整体磁盘系统性能。
这是一个微妙的话题。它开始促使你问“什么是失败场景？什么是恢复场景？”
一些答案：
更远：
如果我们只是每隔几分钟进行一次日志备份（除了每天的完整备份之外），LDF 丢失并不严重
结论：LDF 和 MDF 可以坐在同一个跨度上。
赢家：跟随戴尔存储架构师：在这种情况下，更大的轴组的性能增益超过了其他问题。