行为异常DBCC Shrinkfile

我正在尝试对其中95％的数据已被存档和删除的数据库运行1GB的dbcc收缩文件。我用的是235GB的文件，其中9GB是数据/索引。我想缩小到50GB。我知道收缩数据库文件是不好的，它会导致碎片等。作为数据清除/收缩的一部分，我们还有一个重建idnex脚本。

当我在自己的工作站（四核，12GB RAM，2个SATA驱动器）上对数据库运行dbcc收缩文件脚本时，收缩过程大约需要8-10分钟。

当在数据库发布后数据清除的相同副本上运行相同的代码时，在我们的测试环境（80多个核，128GB RAM，SSD SAN）中，需要70分钟。请注意，运行收缩文件时，此服务器上几乎没有活动。它已运行4次，结果相同。

然后，我采取了另一种方法，将剩余的9GB移动到另一个文件组和物理文件。在空的230GB文件上运行dbcc收缩文件以将其缩减到50GB，在我自己的工作站上花费的时间不到1分钟。

使用相同的方法，在测试环境上，又需要70分钟以上的时间。

在测试环境运行70分钟的过程中，按照布伦特·奥扎尔（Brent Ozar）的脚本操作前后，我已经对waitstats进行了快照，并且返回的waittypes值得关注。下面的前3行：

秒采样时间采样持续时间（以秒为单位）wait_type等待时间（秒）等待次数平均每次等待的毫秒数
2013-05-28 11：24：22.893 3600 WRITELOG 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事件日志显示没有异常。在这一点上，我要抓挠，为什么与独立工作站相比，忍者硬件要花这么长时间。

数据文件上的收缩文件是单线程操作，重用了较小的内存缓冲区。

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

但是，本地PC具有本地I / O延迟（本地磁盘，即不必多次访问SAN）的好处。