标签: filegroups

Microsoft Technet 文章建议将辅助文件组创建为默认文件组（请参阅下面的参考）。辅助文件组应该有多个文件，比如四个，每个文件都放在不同的磁盘上。作为同事的补充经验法则，文件数应等于 CPU 内核数。

我的理解是，这种设置非常适合机械旋转磁盘驱动器，因为旋转磁盘驱动器比固态驱动器慢得多，因此可以通过从多个磁头流式传输数据来提高性能。这种理解是否正确？

如果是，那么我的问题是基于成本的优化器是否考虑了较新的固态驱动器？当切换到新的固态驱动器时，旋转硬盘驱动器的性能瓶颈似乎消失了。我们的 IT 运营小组告诉我，虽然我目前被分配了一个虚拟驱动器，但数据实际上存储在 ISCSI SAN 上，它有多个固态驱动器。

这个问题旨在回答对于这种规模的大型数据库来说，最佳设置是什么：

1. 我应该有一个只有一个文件的默认辅助文件组吗？
2. 我是否应该有一个默认的辅助文件组，其中包含的文件数等于 CPU 上的内核数？
3. 使用固态驱动器时对数据库表进行分区是否可以提高性能？

我正在处理的当前项目需要一个可扩展的数据库，该数据库的大小将达到几 TB，用于存储大量日志数据。一周的样本大约有 1.5 亿条记录，我们需要存储 3 年的滚动日志。所以，我现在正在寻找长时间运行的查询来查找数据。我已经将索引调整到几乎所有工作都归因于非聚集索引搜索的程度；优化器不建议添加缺失的索引。

笔记

Microsoft SQL Server 上的许可目前由 CPU 内核决定。因此，在这个问题上投入更多内核是很敏感的，尤其是在这不会提高性能的情况下。

此外，我目前正在 SQL Server 2014 上进行开发，但将迁移到 SQL Server 2017 进行开发和生产。

更新 1

该项目将每晚加载日志，我预计很少（可能没有）更新或删除，因为日志根本不会改变 - 所以它们不会被重新加载。出于分析目的，将读取其他所有内容。

系统表的 PRIMARY 文件组，其中 SECONDARY 默认文件组用于其他所有内容。这样做的原因由本问题底部引用的链接解释。

将为表分区创建单独的文件组。数据库中还有其他足够小的表，它们将驻留在 SECONDARY 文件组中 - 我只对两个表进行分区，其中一个超过 1 亿条记录（按 IDENTITY 行号分区），另一个将进入数十亿条记录（按时间划分[每月]）。

我计划在 3 年内按月进行分区。因此，将有 36 个分区。我将为每年创建文件组，然后将 12 个文件放入相应的年度文件组中。分区策略是为了减少读取时间，因为会有大量数据扫描用于分析目的。年度文件组策略严格来说是为了便于 DBA 维护，他们可以通过删除单个文件组来删除一年的数据。

参考：

SQL Server 最佳实践设置默认文件组

在我的情况下，我有一个文件file_01.mdf并且file_02.ndf在 1 个文件组下，如果file_01.mdf已经满了（没有启用自动增长），file_01.mdf如果尝试在其中添加数据，它会出错吗？

我的数据库中有三个文件组：

默认为三级。现在我想在 PRIMARY 上创建表，它显示以下错误

关键字“primary”附近的语法不正确。

create table tb1
(
    id int identity primary key nonclustered,
    somecolumn nvarchar(15)
)
on PRIMARY;

当我将默认文件组选项更改为 PRIMARY 时，它可以在 PRIMARY 上创建表。当我的语法没有错误时，为什么会显示此错误？

谢谢你的时间。

我有一个简单恢复模型的数据库，并定期进行完整、差异备份。

该数据库还有每个月的文件组。每个文件组只有一个 NDF 文件。

像这样：

FileGroup: PRIMARY
File: Primary.mdf

FileGroup: FG201801
File: 201801.ndf

FileGroup: FG201802
File: 201802.ndf

FileGroup: FG201803
File: 201803.ndf

etc

我的目标有两个：

1. 能够按分区级别进行备份。正如我所读到的，只有当我将文件组标记为只读时才可能。所以我已经分离了部分备份BAK文件。 https://learn.microsoft.com/en-us/sql/relational-databases/backup-restore/partial-backups-sql-server

2. 第二个目标是（我的问题在这里），能够仅恢复一个文件组，而无需恢复主文件组或触及任何其他文件组。

有可能吗？

据了解，如果我只想恢复 FG201802 ，而 PRIMARY 和其他文件保持不变，那么首先我必须恢复包含 PRIMARY 文件组的完整备份，然后我可以恢复 FG201802 的部分备份。如何在不恢复 PRIMARY 的情况下恢复 FG201802？

有人可以向我指出一个可以演示这一点的在线资源吗？网上的所有文章（我发现）总是开始恢复主完整备份，然后一一应用其余的部分备份。

我只想恢复部分备份，怎么办？

谢谢你！

多年来，一直有一个长时间运行的 SQL 代理作业需要近两个小时才能完成。大约两周前，出于一个小小的突发奇想，决定改变相关数据库的增长率。此后，这项工作在不到 30 分钟的时间内就完成了。改变日志的增长率会强制生成新的执行计划。我只是好奇 SQL Server 内部发生了什么，这会导致更快的运行时间。

谢谢