奇怪的行为 DBCC Shrinkfile

Question

我正在尝试针对 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 3600 PAGELATCH_EX 11.1 443038 0.0

Windows 事件日志没有显示任何异常。在这一点上，我正在挠头，为什么与我的独立工作站相比，忍者硬件需要这么长时间。

Answer 1

数据文件上的 Shrinkfile 是单线程操作，重复使用小内存缓冲区。

因此，Ninja 硬件在额外内存和 80 个核心方面并没有优势。

然而，您的本地 PC 具有本地 I/O 延迟的优势（本地磁盘，即不必多次访问 SAN）。