![缩小 SQL Server 数据文件,但不是一次性全部缩小?](https://linux22.com/image/795223/%E7%BC%A9%E5%B0%8F%20SQL%20Server%20%E6%95%B0%E6%8D%AE%E6%96%87%E4%BB%B6%EF%BC%8C%E4%BD%86%E4%B8%8D%E6%98%AF%E4%B8%80%E6%AC%A1%E6%80%A7%E5%85%A8%E9%83%A8%E7%BC%A9%E5%B0%8F%EF%BC%9F.png)
我有一个数据库文件,目前大小为 150GB,但只使用了 75GB - 这是因为我将所有索引(其余 75GB)移到了一个新的数据文件中。我想从这个数据文件中回收至少一部分空间,但当我尝试缩小文件时,它会无限期地“执行”,最终由于网络中断或其他我无法控制的原因(运行一天后)而被取消。即使使用“缩小到特定大小”功能并指定它只削减 10MB,它似乎也永远不会恢复 - 它只是处于静止状态,直到进程被中断。
还有其他方法可以让我重新获得这个空间吗,哪怕一次只恢复一点点?
编辑:有人发布了一个链接,解释了为什么我不应该缩小数据库。我明白,无论如何我都想缩小它。这台服务器上的磁盘空间非常宝贵,数据库很长时间内不会再次扩展到这个未使用的空间 - 正如我之前所说,我将索引从数据文件中迁移出来以释放这个空间,所以现在它被浪费了。
答案1
不,使用DBCC SHRINKFILE ('filename', target_size)
才是正确的方法。
如果您想以“块”的形式执行此操作,您可以逐步设置更小的目标大小,或者让它尽可能长时间运行直至被取消。
一些评论:
- 设定一个合理的目标大小,并留出一些允许的可用空间。也许 75GB 的数据总共需要 90GB?
- 在收缩过程中,检查活动监视器以查看 SPID 是否被阻止。如果文件末尾的页面上有一个打开的事务,则收缩将无法移动它,直到该事务提交或回滚。
- spid 是否确实取得了进展?(CPU 和 IO 数量正在发生变化)
- 收缩有时会花费很长时间,但它应该保存进度(意味着它每次移动 1 页,当它被取消时,所有完成的页面移动都已完成)
- 取消收缩后,尝试执行
DBCC SHRINKFILE ('filename', TRUNCATEONLY)
。它应该恢复文件末尾已释放的所有空间(参见我之前的观点) - 如果您感到绝望,请尝试在单用户模式下重新启动 SQL,这样您就知道当时没有其他任何操作正在对数据库进行操作(显然,这在生产服务器上是不可能的)
- 一旦能够完成收缩,请确保对数据库进行完整的重建索引,以消除收缩造成的碎片。这可能会回收您刚刚释放的一些空间。
- 如果你仍然无法让收缩起作用,请查看这个问题显然,有些情况下心理医生可能无法取得进展。
答案2
在我们的环境中,我们考虑了几种选择:
- 如果旧表可以面向外,则在全新文件组上创建新表并将数据库默认为该文件组。随着时间的推移,删除旧表,直到先前的文件组为空。然后将其删除。
- 如果旧表无法调出但包含可离线数小时的历史数据,请创建一个指向新文件组的新空表。交换表并开始批量将行从旧表复制到新表。但这可能会导致碎片。
- 发出带有 EMTPYFILE 选项的 DBCC SHRINKFILE,数据库会将所有对象移动到新文件。然后您可以删除旧文件。不过这可能需要很长时间。
- 将所有表的聚集索引(带有 DROP_EXISTING 的主键)重新创建到新文件组中。但这会锁定表。
祝你好运
答案3
如果您不想简单地回收空间(您明确拒绝这样做),而是坚持尝试缩小数据库,那么这将花费非常长的时间,并且您的事务日志扩展应该刚好覆盖您从数据库回收的任何空间。作为奖励,之后观察您的数据库性能是否下降。如果 Paul Randal 无法说服您(JL 对此进行了评论,但我会在此处重新发布:为什么不应该缩小数据文件收缩是一个糟糕的想法,我不确定是否有人能做到。如果幸运的话,收缩将在下一次修订中从 SQL Server 中删除(或至少进行更改,使其按照 Paul 的建议工作)。