我正在尝试针对 95% 的数据已存档和删除的数据库以 1GB 的块运行 dbcc 收缩文件。我有一个 235GB 的文件，其中 9GB 是数据/索引。我想把它缩小到 50GB。我知道收缩数据库文件是不好的，它会导致碎片等。作为数据清除/收缩的一部分，我们还有一个重建 idnex 脚本。
当我在自己的工作站（四核、12GB RAM、2 个 SATA 驱动器）上针对数据库运行 dbcc 收缩文件脚本时，收缩需要大约 8-10 分钟。
在数据清除后针对数据库的相同副本运行相同的代码时，在我们的测试环境中（80 多个内核、128GB RAM、SSD SAN），需要 70 分钟。请注意，在运行收缩文件时，此服务器上几乎没有活动。它已运行 4 次，结果相同。
然后我采用了不同的方法，将剩余的 9GB 移动到不同的文件组和物理文件。在我自己的工作站上对空的 230GB 文件运行 dbcc shrinkfile 以将其缩小到 50GB 需要 < 1 分钟。
使用相同的方法，在测试环境中，再次需要 70 分钟以上。
在测试环境的 70 分钟运行期间，我根据 Brent Ozar 的脚本拍摄了前后的 waitstats 快照，并且返回的 waittypes 没有显示任何值得关注的内容。下面的前 3 行：
第二采样时间 采样持续时间（以秒为单位） wait_type 等待时间（秒） 每次等待平均等待毫秒数 2013-05-28 11:24:22.893 3600 写日志 160.8 143066 1.1 2013-05-28 11:24:22.893 3600 CXPACKET 20.9 13915 1.5 2013-05-28 11:24:22.893 …