问题标签 [filegroup]

我即将构建一个新的 SQL Server，并计划广泛使用文件组。我预计这台服务器上的 5 个不同数据库会出现大幅增长，并且会大量读取/写入。我计划在每个数据库上创建 2 个额外的文件组（一个用于用户数据，一个用于索引），每个数据库总共创建 3 个文件组。我计划在不同的驱动器/主轴之间拆分文件组。此服务器是 EMC SAN 上的虚拟服务器 (VMWare)。我是 SAN 架构的新手，我不是 SAN 管理员。我在“Microsoft SQL Server 2012 Unleashed”一书中读到了关于文件组和 SAN 的简短说明，即文件组在使用 SAN 时可能无关紧要。不幸的是，没有比这更多的细节了，我在这个话题上也没有找到太多其他的东西。

使用 SAN 进行存储时是否需要使用文件组？

如果不是，那为什么不呢？如果是这样，那为什么？

我可以就这个主题向我的 SAN 管理员提问什么问题？

我正在创建一个带有文件组和文件的数据库：

这个脚本完成了它的工作，但我想使用文件的相对路径，因为它将在不同的机器上执行。该文件（实际上是文件夹）必须位于数据库文件附近。如何实现？

我有一个包含两个文件组的数据库，第二个文件组（默认）用于数据库表。

出于某种原因，当我检查文件组大小时，主文件组仍用于存储所有数据，而辅助文件组似乎与其初始大小相同。

我通过查看表属性文件组字段仔细检查了这些表是否在辅助文件组中。

为什么这个数据库仍然使用主文件组？

附加信息。我运行了@Vishal Gajjar 的引用脚本，该脚本确定一个表（最大的表）并未完全使用辅助文件组，因为它仍在使用“文本文件组”的主文件组。

我正在考虑在大约 600GB 的现有数据库上实现文件组。我遇到的最大障碍实际上是在生产中设置它。我需要数据库仍然可用，但移动一些表需要相当长的时间。在开发过程中，将近 5 天的时间将所有索引迁移到新家，然后缩小数据库。

那么在需要保持数据库活动的大型数据库上实现文件组的最佳方法是什么？

我试图从数据库的其余部分中分离出一个只读的、大量使用的审计表。将它放在一个文件组和单独的文件中似乎是最好的解决方案。

但是我无法弄清楚如何在实体框架中进行设置，我是否需要手动删除并创建表并将约束定位到文件组？

目前我正在使用迁移来创建数据库和表：

相关：如何将表移动到 SQL Server 2008 中的特定文件组

我们经历了一次 sql 注入攻击，它破坏了我们的主数据库。

主数据库有两个分区表到文件组中。

损坏的数据库进入了可疑模式，我们无法使用。

我能够恢复部分数据库的备份（没有文件组，因为我们没有备份这些文件。我知道坏事）。

我现在能够以可疑模式删除数据库，因此我们只剩下恢复的数据库和链接到损坏数据库的文件组。

现在我正试图弄清楚如何使这些文件组重新联机。

我已经尝试删除它们，以便我可以重新添加它们，但我无法删除它们，因为我得到了

有什么解决办法吗？我发现他们谈论从备份恢复的帖子，但我们没有其中一个文件组。

我们丢失了这些数据吗？我们如何删除文件组？备份现在因此停止工作。

更新

如果我运行这个

数据库抱怨离线的所有文件组都说“RECOVERY_PENDING”

我有一个包含两个文件组的数据库：

现在我有第一个文件组的备份：Primary.bak。并使用以下脚本恢复：

它成功恢复。但是我在ArchiveFileGroup中的另一个表出现以下错误，而我想从中进行选择：

查询处理器无法为表或视图“客户”生成计划，因为该表位于不在线的文件组中

我的错误是什么？

希望你能帮助我，我正在尝试添加一个具有相应文件组名称的文件，这是我的代码：

当我执行代码时，我收到以下错误：Msg 102, Level 15, State 1, Line 5 Incorrect syntax near '('

我的代码有问题吗？提前致谢

在许多 SQL Server 文章中提到，最佳实践是在物理磁盘上使用多个文件组以避免磁盘争用和磁盘主轴问题。所以我的查询是：

1：拥有多个文件组的相同理论是否适用于虚拟机？
2：我是否仍应将我的临时数据库创建到不同的磁盘，我是否还应该创建多个临时数据库文件以避免在我的生产环境的虚拟机设置中对同一临时数据库文件进行大型读/写操作

您的建议和推理将有助于确定最佳实践。谢谢。

我有大约 300 个表，它们位于不同的分区中，现在这些表不再用于存储如此庞大的数据。现在，我不时遇到空间问题，其中一些但有价值的空间被为这些表创建的 150 个文件组占用，所以我想将表的文件组更改为任何一个而不是 150 FG，并通过删除这些文件组来释放空间.

仅供参考：这些表现在不包含任何数据，但定义了许多约束和索引。

您能否建议我，如何有效地完成它？