将事务日志放置在单​​独的卷[固态]上？

事务日志通常隔离在单独的卷上。据我了解，这种做法的基本原理是事务日志的数据是按顺序写入的-硬盘驱动器可以按顺序执行写入操作，而随机执行则要快得多。这是由于驱动器内部的小针在写入顺序数据块时必须移动短得多的距离，这与随机写入相反。

（很抱歉，您的幼稚的解释。只是想使我所读的内容有意义。）

考虑到这一点……在我看来，固态驱动器几乎没有针头，盘片和东西在内部移动。如果我的数据库和事务日志都位于八个固态驱动器的单个RAID 5上，那么将事务日志移到其自己的单独卷上真的有任何好处吗？如果假定的效率提升是基于顺序写入的前提，即减小了针移动和盘旋转的距离，而固态驱动器没有这些移动部分，那么通过隔离日志我可以获得什么？

简短的答案，使用单个阵列，通过8个SSD驱动器从数据中分离日志不会带来任何性能提升。有关SSD的更详细（且有趣的）注释，请参阅SSD上的SQL：热门和疯狂之爱。请特别注意有关SSD相关故障的注意事项。

将日志与SSD上的数据分开，与其说是性能问题，不如说是RPO（恢复点目标）。这种想法是，您可以通过将日志与数据分开来减少RPO，以便在数据阵列出现故障的情况下，您的日志阵列应该/可以保持可访问性。如果RPO至关重要，则谨慎地考虑在两个阵列中的每个阵列中使用不同的驱动器品牌/型号，以减轻相关的故障问题。

有关总线带宽的评论无关紧要。如果您需要转移那么多IO，则有更大的问题要担心。

有一个小组同意，在HDD上进行分离将是有益的，他们仍然声称对于SSD驱动器不再需要这样做。

因此，对于他们，我想问：“如果没有争用问题，那么为什么要使用RAID 10？不再需要剥离！因此只需镜像就足够了，当然也不需要8个驱动器，是数据库的2倍大小就足够了！”。

但是实际情况是，如果某些东西需要RAID 10，那就是日志文件！

这不仅是因为顺序问题还是随机问题（请参阅下面的资源），而且一旦您了解了SSD驱动器的工作原理，它实际上就至关重要。

长话短说（有关详细说明，请参见 http://arstechnica.com/information-technology/2012/06/inside-the-ssd-revolution-how-solid-state-disks-really-work/），一个SSD驱动器在读取和写入零方面非常有效，但是要写入一个则效率不高，因为它必须擦除整个部分才能写入一个！

尽管这对于常规写入而言不是问题，因为它们无论如何都在内存中缓冲并在页面边界中被写出，但对于日志文件而言却是一个主要问题，因为日志文件会绕过所有缓存，而SQL Server会阻塞直到日志将写入光盘！，这意味着每次写入都可能会擦除整个部分。

因此，为了对其进行优化，我建议为日志文件分配每个额外的磁盘（数据库大小的两倍，无需剥离！），这样便可以在较短的时间内处理尽可能多的磁盘。

老年答案

答案是肯定的，原因有三点。1）随机与顺序-显而易见，SSD可以极大提高随机写入的性能，但仍然存在随机与顺序的问题，如以下白皮书和链接所示：

• http://research.microsoft.com/pubs/63596/USENIX-08-SSD.pdf
• http://static.usenix.org/event/fast12/tech/full_papers/Min.pdf
• /programming/2100584/difference-between-sequential-write-and-random-write
• http://www.neowin.net/forum/topic/992800-why-sequential-vs-random-io-speeds-differ-for-ssd/

2）可靠性-所有SSD驱动器同时发生故障的可能性很大，在这种情况下RAID无法提供保护，但是由于仅用于顺序驱动的SSD驱动器具有不同的使用寿命，因此这可能是您的救星

3）写争用-将日志放在其自己的主轴上的原因不仅是因为随机vs顺序，而且还因为写争用，正如我们可以从以下事实中看到的那样，建议将tempdb放在单独的卷上，这表明这里的问题也与写争用有关。

这对日志文件应有更大的作用，因为对日志的写入会阻止事务被视为已提交，直到将其写入磁盘表面为止。

实际上，对于日志，您可以将常规HDD驱动器用作Dell的白皮书，网址为http://www.dell.com/downloads/global/products/pvaul/en/ssd_vs_hdd_price_and_performance_study.pdf

编辑

Microsoft建议将tempdb放在其自己的阵列上以旋转光盘，请参阅

• MSDN- http://technet.microsoft.com/library/Cc966545（“最佳做法和建议”部分）
• MSDN- http://msdn.microsoft.com/zh-CN/library/ms175527( SQL.105) .aspx
• Sunil Agarwal（SQL Server存储引擎团队成员）-http://blogs.msdn.com/b/sqlserverstorageengine/archive/2009/01/04/managing-tempdb-in-sql-server-tempdb-configuration.aspx
• 保罗·兰德尔（通过链接到上面的链接作为一个有用的链接） - http://www.sqlskills.com/BLOGS/PAUL/category/tempdb.aspx
• StackOverflow- https: //stackoverflow.com/questions/360088/sql-server-tempdb-optimization-tips-for-a-new-server
• ServerFault- https: //serverfault.com/questions/19866/recommended-disk-partition-setup-for-a-sql-server
• “ Microsoft Sql Server管理和管理（SAMS）”（第33页）

以及其他许多方面，这是Sql Server中普遍接受的概念，但是没有人表达了拆分数组的问题。

此外，SQL Server团队创建了文件组和分区分区的概念，其唯一目的是能够将它们移动到单独的阵列上。

实际上，位于http://msdn.microsoft.com/zh-cn/library/ms187087(v=sql.105）的MSDN 建议，通过在其自己的数组上分离非聚簇索引，可能会带来性能优势（尽管这不应作为每种情况的一般建议，仅针对特定的工作负载，请参阅http://weblogs.sqlteam.com/dang/archive/2008/08/01/Are-you-a-DBA -Monkey.aspx）。

因此，说在旋转磁盘上分离的原因不仅是顺序读取还是随机读取的问题，而且还涉及一般写入争用，这同样适用于SSD，这只是逻辑上的扩展。

尽管可能有些人不同意该建议，并认为放置tempdb及其自身的卷没有好处（例如Jack Douglas），您甚至可能声称分离日志文件没有好处（例如Mark Storey） -Smith），而是声称拆分数组要糟糕得多，但仍然不要忘记这是一种新方法，与Microsoft和社区建议的公认方法背道而驰，到目前为止，没有人提供任何指向任何对象的链接。基准测试以支持它。

因此，我对所有拒绝投票的人所说的是，我认为对某篇文章进行投票是不道德的，只是因为它与您的观点不同，尤其是在以下情况下：1）您的观点与公认的理论背道而驰2）并且与供应商（Microsoft）相抵触）自己的文档3）并且您还没有提供任何证明只是一种意见。

但是在这种情况下，这甚至更荒谬，因为我的帖子不过是对该理论的逻辑扩展，因此，认为该帖子为卧床建议的人当然需要回到所有建议该理论的职位并对其进行否决。

假设有人认为RAI​​D是老派理论，并否决所有推荐它的文章，这有什么意义？