SQL Server文件和文件组

Question

我想不出为什么我们需要在文件组中包含多个文件的任何原因。我想到这种方式的原因是我们可以从T-SQL（最终用户）级别控制文件组，但不能从T-SQL（最终用户）级别控制文件组的各个文件。是否还需要文件的任何评论或想法？

提前谢谢， 乔治

Answer 1

每个文件组包含多个文件仅在以下原因下有用：

1. 出于性能原因，在多个磁盘上分配磁盘I / O负载。即，在无法使用其他磁盘重新配置RAID配置的情况下，或者没有RAID。
2. 如果您有VLDB并且由于后勤原因不希望处理非常大的单个文件。

有一个'都市传奇'，SQL Server每个文件只使用一个线程，因此文件数应该与CPU的数量相匹配。然而，这是假的discussed by Microsoft here。

历史上，还有另一个原因。信不信由你在SQL Server 4.2到7的时代sql server有时安装在FAT32文件系统上，该系统有4 GB的文件限制。将文件链接在一起（我们现在称之为文件组）的方法是一种解决文件系统限制的方法，并允许基于FAT的安装大于4gig的DB。

Answer 2

旧线程，我知道，但这里对我来说是有意义的：回到当天最大文件大小的Windows文件系统FAT32是2GB。如果你的数据库文件变大了，你就搞砸了（发生在我身上的MS Access-Database一次）。因此，他们允许定义最大文件大小（如：2GB），您可以添加更多文件。如果您的数据库增长并且超出了最大大小，则下一个文件被填满，直到该文件已满，等等。所有这些文件都可以作为一个文件组进行寻址。您可以通过选择文件组来定义表数据位置，但是您没有看到该文件组中的tabledata最终会在哪个文件中。所有你知道的是，你的表数据最终可以在文件组中的任何文件中。 通过这种“拆分”您的文件系统永远不会看到大于最大文件大小的文件（此处：2GB），尽管您的数据库中的表可能要大很多倍。 今天设置多个文件对于将大型数据文件“切碎”成小块以进行基于文件的备份非常有用（请询问网络管理员他们想要什么，因为在备份期间将大型（如1TB）文件写入分区需要很长时间，即使在快速RAID。所有其他写操作都需要等待很长时间。等待时间越短，高优先级操作就越快执行。 如果您关心同一个表的并行访问，请考虑http://msdn.microsoft.com/en-us/library/ms188730%28v=sql.105%29.aspx中的水平分区。这允许将表的数据分布在不同的硬盘上，例如“1月份在磁盘R上的所有销售额：”，“2月份在磁盘S上的所有销售额：”，而不创建单独的表。在分区表的过程中您可以定义哪个部分将转到哪个文件组。

Answer 3

我可以提供一个很长的解释，但MSDN做得很好here。可能您特别不需要在文件组中包含多个文件，但并非所有人都这样。