即使在同一个LUN上，多个数据/日志文件也是一件好事吗？

Question

我已经读过，每个CPU / CPU Core都有一个文件是个好主意，这样SQL就可以更有效地将数据传输到磁盘和从磁盘传输数据。好吧，我可以看到它们在不同的主轴上的好处，但如果我的数据文件（.mdf和.ndf）只有一个主轴（在Raid 10中有4个驱动器），我仍然可以从分割数据文件中受益（从.mdf文件到.mdf和几个.ndf文件）？日志文件也是如此，虽然我认为没有任何好处，因为数据必须连续写入，并且你受到主轴顺序写入速度的限制......

仅供参考，这与SQL Server 2005/2008 ...

有关

感谢。

Answer 1

对多个tempdb数据文件的建议绝对不是关于IOPS。它是关于tempdb中的分配页面（GAM，SGAM，PFS）的争用。 SQL 2005+在这些页面上不需要那么大的负载，但仍然会发生争用。并非所有系统都需要1个文件到1个核心映射。大多数系统在1个文件到2个或4个核心的情况下表现良好。文件太多会增加管理文件的开销。一个好的建议是从1：4或1：2开始，如果争用继续，则增加。不要超过1：1。

对于其他数据库，不建议这样做。

是的，只有1个日志文件......总是。

Answer 2

8 Steps to better Transaction Log throughput：

  

仅创建一个事务日志文件。   即使你可以创建多个   事务日志文件，您只需要   一个...... SQL Server没有“条纹”   跨多个事务日志文件。   相反，SQL Server使用   事务日志文件按顺序。

Misconceptions around TF 1118：

  

为什么不需要跟踪标志   很多在2005年和2008年？在SQL Server中   2005年，我的团队更改了分配   系统为tempdb减少了   争用的可能性。有   现在是临时表的缓存。当一个新的   临时表是在冷系统上创建的   （刚刚启动后）它使用相同的   SQL 2000的机制。当它是   虽然掉了，而不是全部   页面被完全解除分配，   一个IAM页面和一个数据页面   左分配，临时表是   放入一个特殊的缓存。随后   临时表创作将在   缓存，看看他们是否可以抓住一个   预先创建的临时表'关闭   架'。如果是这样，这将避免访问   完全分配位图。该   临时表缓存并不大（我想   这是32桌），但这仍然可以   导致锁存器中的大下降   tempdb中的争用。

所以两个问题的答案都是肯定的。日志条带化从来都不是问题，每个ND-NDF基本上是一个神话，需要很长时间才能消亡。多个文件IMHO只有在您可以条带化IO（单独的LUN）时才有意义。多个文件组虽然有意义，但不是出于IO原因，出于管理目的：piecemeal restores和归档只读文件组。

Answer 3

仍然很好。这不是关于IOPS - 它是关于SQL Server阻塞某个操作的文件。主要是当文件扩展名分配给表/索引时。如果你做了很多插入/更新，多个文件基本上意味着另一个线程将阻止另一个文件，而不是等待第一个文件。

因此，这不是关于IOPS加载，而是关于阻塞行为。