我正在将公司的数据库服务器从 Windows 2000/Sql Server 2000 更改为 Windows 2003 R2/Sql Server 2005。它包含 30 个数据库，每个数据库的大小约为 7gb，但其中一个数据库的大小为 30gb。现在我想知道我是否应该利用这个机会在这个数据库上使用文件组。但我以前从未使用过它，而且我不太了解数据库的内容。但这是一个经济系统，所以我认为在过去 8 年的生产中，它保存了大量历史“只读”信息。
有人能给我一些提示和建议，告诉我是否应该拆分它吗？我现在有 2 个独立的磁盘，一个用于日志文件，一个用于数据库。
如果有人能给我一些意见我将非常感激:)
答案1
您想将数据库拆分为多个文件组，或者将多个文件添加到现有的主文件组吗？
在第一种情况下，您需要将对象（表、索引）移动到新添加的文件组中，否则它将保持为空。这样做需要您非常了解所述对象的使用模式，以便确定哪些对象放在哪里。之后的优势是，您将能够根据访问方式将文件组分配到单独的 IO 路径（单独的磁盘/LUN）。另一个优势是，您可以更精细地管理备份/恢复，允许您进行零碎恢复并允许您进行单个文件组备份。我认为在数据库中分配文件组是一种设计时间决定对你来说现在有点晚了。
第二种情况，你只需向 PRIMARY 文件组添加更多文件，以便将 IO 分散到多个磁盘上。除非你真的做有 IO 问题，并且您有多个 IO 路径（即，将文件放置在单独的磁盘/阵列/lun 上），那么添加多个文件没有任何好处。您可能会遇到建议将数据库拆分为 N 个大小相等的文件的建议，其中 N 是 CPU 核心数，但该建议已经过时，因为 SQL 2005/2008 处理 SGAM/GAM 分配争用比 SQL 2000 好得多，不再需要拆分。
根据您对问题和环境的描述，我坦率地认为没有理由进行任何拆分：您不会制定任何花哨的恢复计划以允许逐块恢复（而且它只有 30Gb，相当小），而且您只有一个磁盘，因此多个文件没有任何优势。
答案2
我认为，如果将数据库拆分为文件组，则不会获得太多性能提升，因为您只有两个专用磁盘，而您已经需要一个磁盘来存储您的事务日志。
我不会分割它。
答案3
以下是有关文件组的信息。只有将它们放在单独的驱动器上，它们才能真正提高性能。文件组的另一个用途是隔离只读表并能够仅备份活动文件组。