我需要将数据库拆分为文件组吗？现在是 30GB

Question

我现在正在将我公司的数据库服务器从 Windows 2000/Sql Server 2000 更改为 Windows 2003 R2/Sql Server 2005。它拥有 30 个数据库，每个数据库的大小约为 7gb，但其中一个是 30gb。现在我想知道我是否应该利用这个机会在这个数据库上使用文件组。但是我以前没用过，不知道数据库的内容那么好。但它是一个经济系统，所以我认为在过去 8 年的生产中，它包含大量历史“只读”信息。

谁能给我一些关于我是否应该拆分它的提示和技巧？我现在有 2 个单独的磁盘，一个用于日志文件，另一个用于数据库。

如果有人能给我一些意见，我将不胜感激:)

Answer 1

您想将数据库拆分为多个文件组，还是将多个文件添加到现有的主文件组？

在第一种情况下，您需要将对象（表、索引）移动到新添加的文件组中，否则它将保持为空。这样做需要您对所述对象的使用模式有很好的理解，以便您可以确定哪些对象去哪里。之后的优势是您将能够根据访问方式将文件组分配到单独的 IO 路径（单独的磁盘/LUN）。另一个优点是您可以更精细地管理备份/恢复，允许您进行零碎恢复并允许您进行单个文件组备份。我会说在数据库中分配文件组是一个设计时的决定，现在对你来说有点晚了。

第二种情况，您只需将更多文件添加到 PRIMARY 文件组，以便将 IO 分布到多个磁盘。除非你确实做有IO问题，你有多个IO路径（即单独的磁盘/阵列/ LUN的放置文件到），所以在添加多个文件为零的优势。您可能会遇到建议将数据库拆分为 N 个相同大小的文件的建议，其中 N 是 CPU 内核数，但该建议已过时，因为 SQL 2005/2008 处理 SGAM/GAM 分配争用比 SQL 2000 好得多，并且不再需要拆分。

从你对问题和环境的描述来看，坦率地说，我认为没有理由进行任何拆分：你不会制定任何花哨的恢复计划来允许零碎恢复（而且只有 30Gb，这是相当小的），并且无论如何，您只有一个磁盘，因此多个文件没有任何好处。