我继承了一个系统，其中以前的 DBA 将 7 个数据文件添加到 PRIMARY 文件组（初始大小为 8MB），并将 AUTOGROW 选项保留为 8MB。我现在拥有的是一组八个文件，每个文件大小约为 3 - 4GB，在两年内缓慢增长。我想以最快的方式删除文件碎片。
以下是我想出的选项：
- 将 PRIMARY 文件组中的第一个文件扩展 ~28GB（7 个文件 x 4GB）
- 将数据从每个连续文件中移出并将它们标记为删除
- 删除其他 7 个文件
- 分离数据库
- 将分离的数据库文件复制到服务器上的不同驱动器
- 将分离的数据库文件复制回原始驱动器
- 重新附加数据库
或者
- 创建一个 32GB 大小的新数据库 (8 x 4GB)
- 使用 SSIS 将所有对象、表、用户和权限转移到新数据库
- 删除旧数据库
- 重命名新数据库
操作系统级别的“磁盘碎片整理”仍然不是一个选项吗？
我不知道哪个选项是最好的，或者它是否会起作用。
此外，该数据库正在被镜像和复制，因此需要重建它的工作量最少。
谢谢你的帮助。
老实说，除非您没有几 Gig 的 RAM，否则 32 Gig 的数据库物理碎片应该不是什么大问题。
以下关于服务器故障的问题有一些有用的答案，这可能有助于 https://serverfault.com/questions/31011/sql-database-physical-file-fragmentation
现在，在空间增加了这么多之后，物理文件肯定是碎片化的，并且会从文件级别的一些碎片整理中受益。
我不知道您的情况，但任何服务器都应该足够快以提供单个 32 GB 数据文件。只有当所有这些文件都在不同的物理磁盘上时，我才会看到好处，否则我认为不需要这样的麻烦。
不过，在这种情况下，我会使用解决方案 1，但我会创建比当前大小更大的文件，其空间至少应该足够明年使用，并且具有更大的自动增长大小。
我不认为操作系统级别的碎片整理可用于实时数据库文件。我一直认为您需要将其分离才能对文件进行碎片整理，但似乎来自 Serverfault 答案的人能够在数据库在线时对数据库文件进行碎片整理。
您的两个选项都应该能够工作，通过使用单个碎片整理文件使您的数据库更快，但是，对于解决方案 2，我认为不需要具有相同数量的文件，您可以使用单个文件创建数据库数据文件并使用 SSIS/bcp 移动新数据库表中的所有内容。
我之前会测试，但我认为第一个解决方案会更快。