我有一个目前150GB的数据库文件,但只使用了75GB – 这是因为我将所有索引(另一个75GB)移动到一个新的数据文件.我想从这个数据文件中回收至少部分空间,但是当我试图缩小文件时,它会无限期地“执行”,最终因为网络中断或其他不受我控制而被取消(之后)运行的一天).即使使用“缩小到特定大小”功能并指定它只是修剪10MB也似乎永远不会返回 – 它只是在进程被中断之前一直存在.
还有另一种方法可以让我回收这个空间,即使是一次一点点吗？
编辑：有人发布了一个链接,解释了为什么我不应该缩小我的数据库.我理解,无论如何我想缩小它.磁盘空间在这个服务器上是非常宝贵的,并且数据库将不会再次扩展到这个未使用的空间很长一段时间 – 如前所述,我将索引迁出数据文件以释放这个空间,所以现在浪费了.
解决方法
不,使用DBCC SHRINKFILE(‘filename’,target_size)是正确的方法.
如果你想在“块”中进行,你可以设置逐渐变小的目标大小,或者只是让它在被取消之前尽可能长时间运行.
一些评论：
>放置合理的目标尺寸,允许一定的允许空间.对于75GB的数据,可能总共90GB？
>收缩正在运行时,请检查活动监视器以查看是否阻止了SPID.如果文件最末端的页面上存在打开的事务,则在该事务提交或回滚之前,shrink将无法移动它.
> spid实际上是在取得进展吗？ (cpu和IO号正在变化)
>收缩有时可能需要非常长的时间,但它应该保存其进度(意味着它一次移动1页,当它被取消时,所有已完成的页面移动已经完成)
>取消缩小后,尝试执行DBCC SHRINKFILE(‘filename’,TruncATEONLY).它应该恢复文件末尾已经释放的所有空间(参见我之前的观点)
>如果您感到绝望,请尝试在单用户模式下重新启动sql,因此您知道当时没有其他任何方法可以对数据库进行操作(显然,这在prod服务器上可能是不可能的)
>一旦能够完成收缩,请确保对数据库执行完全重新索引,以消除收缩所产生的碎片.这可能会回收你刚刚释放的一些空间.
>如果仍然无法使缩减工作,请查看this SO question上的一些讨论.显然有些情况下缩小可能无法进行.
