我有一个很大的只读数据库，里面有大约30个表。DB的总大小约为13TB，最大的表约为4.5TB。(大约有10个大小为1TB+的表，然后是几个较小的表。)目前，DB被拆分为8个数据文件，全部位于PRIMARY文件组中。
我已经在一些大表上应用了PAGE级别的数据压缩，这将DB的大小减少到了10TB左右，但是，我真的想回收磁盘上的一些空间。(这个数据集是只读的，它永远不会增长。)
我意识到缩小文件会导致大量碎片，这可以通过重建所有索引来解决，但重建索引可能会导致文件再次增长。。。啊！
这引出了我关于如何在压缩后回收磁盘空间的问题：
- 我唯一的解决方案是将所有表/数据复制到具有较小文件的新文件组中，删除原始表，然后清空/删除或收缩原始文件吗
- 有人知道有什么脚本或工具可以帮助我决定所需的最佳文件大小吗
- 最好的做法是
- 使用聚集索引+PAGE压缩在新文件组上创建新表
- 将原始表插入/选择到新表中(使用TF610和tablock)
- 删除原始表
- 在新文件组上创建非聚集索引
这似乎是一项需要很长时间的大任务，因为我基本上必须重新创建我的整个数据库。。。再一次我缺少一个更简单的解决方案吗？
本白皮书涵盖了所有内容：数据压缩：策略、容量规划和最佳实践
在数据压缩完成之后，所保存的空间被释放到相应的数据文件。但是，空间不会释放给文件系统，因为文件大小不会作为数据压缩的一部分自动减少。
有几个选项可以通过减小文件大小来释放文件系统的空间：
DBCC SHRINKFILE(或)DBCC SHRINKDATABASE:
在DBCC shrink文件之后，碎片将增加。请使用ALTER INDEX … REORGANIZE，而不是重新生成
还要注意，DBCC SHRINKFILE是单线程的，可能需要很长时间才能完成
如果要压缩文件组中的所有表：
-创建一个新的文件组
-压缩时将表和索引移动到新的文件组
压缩旧文件组中的所有表和索引并将其移动到新文件组后，可以删除旧文件组及其文件以释放文件系统的空间
请注意此方法中的一个警告。如果表在同一文件组中具有LOB_DATA分配单元，则此方法不会将LOB_DATA移动到新文件组(在其他文件组中重新创建聚集索引时，仅移动IN_ROW_DATA和ROW_OVERFLOW_DATA分配单元)。因此，旧文件组不会完全为空，因此无法删除。
还有一个选项：
如果要压缩文件组中的所有表，则还有另一个解决方案。在新文件组中创建一个空表，对其进行压缩，然后使用INSERT…SELECT将数据复制到新表中。