假设SQL Server的工作负载只是一个普通的OLTP数据库，并且总共有20个可用的磁盘，哪种configuration会更有意义？
单个RAID 1 + 0，包含全部20个磁盘。 该物理卷将同时包含数据文件和事务日志文件，但是将从该RAID创build两个逻辑驱动器：一个用于数据文件，一个用于日志文件。
要么…
两个RAID 1 + 0，每个包含10个磁盘。 一个物理卷将包含数据文件，另一个包含日志文件。
这个问题的原因是由于我（SQL Developer）和同事（DBA）之间的分歧。
对于我所做的每一个configuration或者其他人都可以看到的configuration，数据文件和事务日志文件在物理层面被分开，并被放置在单独的RAID上。
但是，我的同事的观点是，通过将所有磁盘放入单个RAID 1 + 0中，服务器完成的任何IO都可能在所有20个磁盘之间共享，而不是我build议的configuration中只有10个磁盘。
从概念上讲，他的论点对我来说是有意义的。 另外，我从微软那里得到了一些似乎支持他的立场的信息。
http://technet.microsoft.com/en-us/library/cc966414.aspx
在“3. RAID10configuration”一节中，显示了将所有20个磁盘分配给单个RAID 1 + 0的configuration，其中指出：
在这种情况下，I / O并行可以被所有分区充分利用。 因此，I / O工作负载的分配在20个物理主轴之间，而不是4个分区级别。
但是…我见过的每一个其他configuration都build议将数据和日志文件分离到独立的RAID上。 在“服务器故障”中find的所有内容都表示相同。
我知道一个日志文件会被写入很重要，这些数据文件将是读写的组合，但是这是否要求这些文件被放置到单独的RAID而不是单个RAID？
DBA的观点确实是有道理的，但是这里是一个难题：如果我正确地阅读了这篇文章，MS正在谈论DB分区和表级别的性能，而不是磁盘/文件系统分区级别。 我相信DBA会赢得辩论，如果你正在谈论什么types的数组创build的数据文件只。 既然你正在谈论为数据AND日志文件创build什么types的数组，我相信你的观点是最有意义的，从磁盘/文件系统的性能angular度来看。 数据库文件总是随机访问，日志文件总是按顺序访问。 您不应该在同一个物理或逻辑驱动器上混合使用这两种types的I / O。 另外，在同一个物理磁盘（或磁盘arrays）上创build多个逻辑分区不会为您购买任何数据库和日志将争用相同的物理资源。
我的重新推荐是这样的：
为数据库文件创build一个物理arrays（RAID10），并为日志文件创build一个单独的物理arrays（RAID10）。
这要取决于你在系统上的工作量。 如果你的工作负载很高，你想把它们分开，因为数据文件将是一个非常随机的工作量，而事务日志是一个非常连续的工作量。 如果您不希望日志的IO速度变慢，或者受到数据文件的负载影响，那么通常情况下，性能会得到改善。
恨恨，但DBA是..数据库pipe理员。
在构build复杂的查询时，它们比服务器pipe理员聪明得多，但是硬件/服务器pipe理员在分配适当的资源方面是相当聪明的（假设他有一头白发或四）。 🙂
我的简短回答：关于主轴，主要是关于主轴，以及在过去几年中，您select的文件系统以及文件系统可以吸收多less内存。
（a）不同的物理控制器之间分离dbdata / logs / transactionals（b）使用tweak文件系统params（具体而言，这是一个很大的选项，将你的db写入/读取/提交的参数与（c）“select我的毒药”。
非关键的数据，日志，回滚数据等可以或多或less的在实际的数据文件（取决于数据库的风格）上进行“脆弱的”文件系统（memfs，fast-io-fs w / o journal / preflight / precommit caching）很好地散布在一个构造良好的zpool便宜的东西。
上一张海报是绝对正确的，因为转录日志是顺序的，可以/应该继续写快速写入的卷，而不是读取（并且可以说不一定是“稳定”），如大条。 响应者（“这里是蹭”）也是正确的：如果数据不在内存或磁盘caching中，并且没有严重（发音为“长，单调，乏味且容易猜测错误” ）分析，你绝对应该尽量避免混合磁盘与function不同的数据库。 （例如高传输读取和低传输大数据写入 – 完全FUBAR的任何caching策略）。
我的“ISO 8层”的build议是这样的：接近数据库pipe理员，并说，嘿，我不会告诉你你错了，作为回报，你不会告诉我如何构build我的系统:)他们非常经常会发表一些样板build议，从长远来看，这些build议很less是最佳的。 不是因为他们不知道自己在做什么 – 而是因为他们把信任放在$ vendor推销的中间文件中，“devise为惹恼最less的客户/导致更less帮助电话“。
如果你想直接告诉我，感觉自由; 但请记住 – 没有全局的理想configuration。 行数，预期的扫描，键/索引的基数和效率，查询/秒，每个间隔的全表扫描等等，都在其中起作用。 这是一场艰苦的比赛。
提醒我WARGAMES ..
你想玩游戏吗？
是。 让我们玩全球热核战争吧。
..
如何一个好的数据库架构游戏？
[全球热核战争战略本来就容易..]
🙂
简单的答案是，它将取决于你的读/写比率。 给定OLTP，你可能有一个很好的混合，并保持转录日志分开的数据库将允许事务到DB数组“追逐”日志数组而不是一个数组之间弹跳。
事务日志通常只写入并顺序写入。 如果您将日志保留在自己的一组磁盘上，那么这些磁盘根本就不会有任何search（除了更新文件系统元数据时），只需逐步向前一个扇区即可。
如果您将日志和数据混合在同一个RAID集上（即使它们位于不同的逻辑单元上），您将失去顺序写入事务日志的性能提升。
我猜如果你将在每个事务中写入less量的数据，你将通过将日志保存在自己的数组中来赢得性能。 如果数据太多，以至于数据写入磁盘的时间与查找时间相比较大，那么最好有一个大的数组。