（从 StackOverflow 手动移动它，因为它确实属于这里。）
我们有一个生产 SQL Server Enterprise 数据库，其中包含几 TB 的数据。我们需要将数据拆分为多个文件。预生产环境中的测试进展顺利，但在收缩期间数据库的性能会下降。我们希望提前解决生产系统中文件收缩/拆分的潜在问题，因为我们有大客户使用 SLA，这限制了我们进行显着影响性能的更改的能力。
SQL Server 收缩/拆分功能是否能够限制在转换到多个文件期间收缩/拆分产生的开销？或者，我们是否有能够实现相同限制能力的路径。或者，是否可以采取一种在给定维护窗口期间逐渐拆分/缩小文件的方法？
我有一个文件组（不是主文件组），其中包含两个不同的 .ndf 文件，例如 a1.ndf 和 a2.ndf。
现在我想创建一个表，我希望我的表保存在 a2.ndf 文件而不是 a1 中。有没有办法做这样的事情？我正在使用 SQL Server。
谢谢。
我目前正在将数据库从 SQL Server 2008 (SP4) 迁移到 SQL Server 2017 (CU3)。一个显着的变化是所有文件组在迁移后都有两个数据文件。为完成此任务，我恢复了一个备份，添加了包含两个大小相同的文件以及相同的自动增长设置的新文件组，并使用以下语法传输数据：
CREATE UNIQUE CLUSTERED INDEX <PK of the table> ..... WITH (DROP_EXISTING = ON ,...) ON <new Filegroup>
不幸的是，我还必须移动一些 LOB，然后事情会变得有点复杂：
这种技术由 Kimberly Tripp在这里描述，可以追溯到 Brad Hoff。
感谢您的关注，现在回答我的问题：
通过重建这样的索引，文件组中需要多少可用空间？
我给你举个例子：
无法为数据库“abc”中的对象“xyz”分配空间。“xyz_pk”因为“def”文件组已满。通过删除不需要的文件、删除文件组中的对象、向文件组添加其他文件或为文件组中的现有文件设置自动增长来创建磁盘空间。
但是，每个文件的大小为 220 GB，每个文件中还有 50% 的可用空间。
这是建议的诊断查询
的输出文件大小加起来为 227,22 GB。
到目前为止，我不知道有任何其他补救措施DBCC SHRINKFILE可以消除可笑的大量可用空间。然而，这并不是我特别引以为豪的事情……它需要很长时间才能留下腐败等。
你能帮我理解为什么 SQL Server 分配了这么多可用空间，然后又愉快地按比例填充我的两个文件吗？
之后我会尝试准备一个演示……抱歉，我现在时间不够，也许你们中的一些专家已经知道这样做的原因。
在此先感谢您的帮助
马丁
我在 SQL Server 2017 CU3 上遇到了一些奇怪的错误消息。我正在迁移数据库并重新组织文件组。“重组”是指我使用存储过程在新文件组上为对象创建分区函数和分区方案，在分区时重建索引，然后删除分区。
最后我得到了一些空文件组。他们的文件被删除。文件组本身也被删除。这在大多数情况下都很有效。但是对于两个数据库，我删除了文件...留下一个文件组，但没有关联文件
ALTER DATABASE REMOVE FILEGROUP
引发错误 5042：
无法删除文件组“xyz”，因为它不为空。
我怎样才能摆脱那个空文件组......可能是什么问题？
我已经阅读了一些常见问题，但它们在我的系统中不存在：
检查：
SELECT * FROM sys.partition_schemes;
SELECT * FROM sys.partition_functions;
0 行...数据库中没有剩余分区对象
UPDATE STATISTICS对于数据库中的所有对象
没有效果
检查文件组上的索引：
SELECT * FROM sys.data_spaces ds
INNER JOIN sys.indexes i
ON ds.data_space_id = i.data_space_id
WHERE ds.name = 'xyz'
0 行
检查文件组中的对象：
SELECT
au.*,
ds.name AS [data_space_name],
ds.type AS [data_space_type],
p.rows,
o.name AS [object_name]
FROM sys.allocation_units au
INNER JOIN sys.data_spaces ds
ON au.data_space_id = ds.data_space_id
INNER JOIN sys.partitions p
ON au.container_id = p.partition_id
INNER JOIN sys.objects o
ON p.object_id = o.object_id
WHERE au.type_desc = 'LOB_DATA'
AND ds.name ='xyz'
0 行
在从文件组中删除文件之前，我还尝试了DBCC SHRINKFILE参数。EMPTYFILE这对我来说真的没有意义，但是我阅读了将其描述为修复的解决方案。反正没有效果。
我有一些希望阅读有关服务器故障的这个问题并尝试了以下方法：
然而，这没有任何效果。我仍然有一个没有关联文件的文件组，并且无法删除该文件组。我完全感到困惑，因为这发生在某些数据库中而不是其他数据库中（具有相同的结构）。当我DBCC CHECK FILEGROUP在这个空文件组上执行时，我收到一堆错误消息，如下所示：
无法处理对象“STORY_TRANSLATIONSCCC”（ID 120387498）、索引“Ref90159CCC”（ID 2）的行集 ID 72057594712162304，因为它位于未检查的文件组“CCC_APPLICATION_new”（ID 8）上。
“STORY_TRANSLATIONSCCC”的 DBCC 结果。对象“STORY_TRANSLATIONSCCC”的 0 页中有 0 行。
这是正常的还是它指向不寻常的事情？
这个问题可能是重复的，但是我在 dba.stackexchange 上的其他问题中找不到适合我的解决方法。请查看我已经尝试过的列表。这与无法删除未使用的文件组中描述的解决方案相同。
更多细节
也许它有助于理解我在错误发生之前做了什么。我正在计划迁移到新服务器。我目前正在测试实例上对此进行测试。数据库从 prod 服务器恢复，恢复模式切换为简单。我的目标是重组文件组并从每个文件组一个文件的模型转移到每个文件组两个文件的模型。为了实现这一点，我创建了新的空文件组，每个文件组有两个文件，然后将数据移过来。不幸的是，大多数对象都有 LOB 数据（XML 和二进制）......所以我也利用分区作为帮助来移动 lob 数据。最后，所有数据都驻留在新文件组中，旧文件组为空。然后我删除所有文件并删除相应的文件组。主文件组仍然存在，只是添加了另一个文件。我的问题。此过程工作正常，但在两个数据库中可以删除文件，但不能删除文件组。令人惊讶的是，这些数据库的结构应该与其他数据库的结构相同，在移动数据和删除旧文件组的过程中没有遇到任何问题。
因此，这是出现问题的两个数据库的文件组和文件的列表：
前
+-----------------+------------+
| Filegroup | Filename |
+-----------------+------------+
| CCC_APPLICATION | CCC_APP |
+-----------------+------------+
| CCC_ARCHIVE | CCC_ARCHIV |
+-----------------+------------+
| CCC_AXN | CCC_AXN |
+-----------------+------------+
| CCC_GDV | CCC_GDV |
+-----------------+------------+
| PRIMARY | CCC |
+-----------------+------------+
后
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| Filegroup name | Filegroup temporary name | Filename (logical) | Status |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| CCC_APPLICATION | - | CCC_APP | file removed, filegroup cannot be removed (error) |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| CCC_ARCHIVE | - | CCC_ARCHIV | file and filegroup removed |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| CCC_AXN | - | CCC_AXN | file and filegroup removed |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| CCC_GDV | - | CCC_GDV | file and filegroup removed |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| PRIMARY | - | CCC | file renamed to PRIMARY_1 |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| PRIMARY | - | PRIMARY_2 | new file added |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| CCC_APPLICATION | CCC_APPLICATION_new | CCC_APPLICATION_1 | new filegroup renamed at the end |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| CCC_APPLICATION | CCC_APPLICATION_new | CCC_APPLICATION_2 | new filegroup renamed at the end |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| CCC_ARCHIVE | CCC_ARCHIVE_new | CCC_ARCHIVE_1 | new filegroup renamed at the end |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| CCC_ARCHIVE | CCC_ARCHIVE_new | CCC_ARCHIVE_2 | new filegroup renamed at the end |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| CCC_AXN | CCC_AXN_new | CCC_AXN_1 | new filegroup renamed at the end |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| CCC_AXN | CCC_AXN_new | CCC_AXN_2 | new filegroup renamed at the end |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| CCC_GDV | CCC_GDV_new | CCC_GDV_1 | new filegroup renamed at the end |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
| CCC_GDV | CCC_GDV_new | CCC_GDV_2 | new filegroup renamed at the end |
+-----------------+--------------------------+--------------------+----------------------------------------------------+
我希望这会有所帮助。还有第二个数据库，其中文件组名称不同，但为简洁起见，我将其省略。
我用SELECT FILEPROPERTY('file_name', 'SpaceUsed')了，它返回NULL，这是什么意思？
我在正确的数据库中正确使用它。
我不能假设这NULL意味着空，因为：
我尝试创建一个新数据库（test2），然后查询SELECT FILEPROPERTY('test2', 'SpaceUsed'). 它已经具有价值。
在我的情况下，我有一个文件file_01.mdf并且file_02.ndf在 1 个文件组下，如果已经满了（没有启用自动增长），如果试图在其中添加数据file_01.mdf，它会给我错误吗？file_01.mdf
我很快就会迁移到 SQL Server 2017，因此我正在努力美化我们数据库中一些被忽视的方面。一方面是文件组：我的 DBA 前任创建了多个文件组，但是因为没有人真正被告知大多数对象只是转到默认文件组 (PRIMARY)。
现在我想强制创建表和索引的人实际命名他们的对象应该驻留的文件组。含义：没有“ON [Filegroup]”的 CREATE TABLE 或 CREATE INDEX 应该回滚并返回文件组丢失的错误。有什么办法可以做到这一点，您会建议继续采用这种方法吗？我刚刚发现基于策略的管理无法阻止在默认文件组上创建对象。
这样做的要点是，someboy 应该首先为对象选择文件组，而不是在默认文件组中创建它们，然后必须根据 DBA 的咆哮移动对象:-)。
我想到了两种技术......但是由于缺少知识而无法开始使用它们中的任何一种：
非常感谢您的帮助
马丁
有人可以引用我的真实世界场景，说明何时将多个文件组更改为只读是一个不错的选择以及何时使用它们？如果将其设置为只读有什么好处？
在具有多个文件组的数据库上，您是否必须备份整个数据库并备份该文件组的每个文件？您能否也给我一个何时使用文件组备份的示例？当您可以备份整个数据库时，我不明白为什么备份文件组会有所帮助。希望我能获得一个真实世界的体验，这个文件组备份将是理想的
我正在使用 AdventureWorks 数据库练习文件恢复，但没有得到我期望的恢复。我确信有一些非常简单的原因，但我还没有找到它。
这是我所做的
USERTABLES_01.HumanResources.Employee到新的 . HumanResources.Employee_01在USERTABLES_01文件组中。DELETE FROM HumanResources.Employee_01在没有 where 子句的情况下执行USERTABLES_01。RESTORE DATABASE [AdventureWorks2012] FILE N'AdventureWorks2012_UserTables_01'...一切恢复无怨无悔。但是我HumanResources.Employee_01的没有任何数据。
查看MS Example，也许我没有正确遵循它，但我很确定我做到了。
查看了类似的问题，但不确定这是我正在寻找的答案： Restore .mdf data file for a filegroup in SQL Server。