我只剩下 2GB,所以我需要删除这个历史表。这个表现在是空的,但是数据库磁盘空间没有释放。数据库文件为320GB。
如果您引用卷上的实际数据库文件消耗,则SQL Server 不会自动处理。仅仅因为您从数据库中删除了数据并不意味着数据库文件将缩小以仅适合现有数据。
如果您必须回收卷上的空间,您要寻找的是使用DBCC SHRINKFILE. 根据该文档,值得注意的是一些最佳实践:
DBCC SHRINKFILE
最佳实践 当您计划收缩文件时,请考虑以下信息: 在创建大量未使用空间的操作(如截断表或删除表操作)之后,收缩操作最有效。 大多数数据库都需要一些可用空间来进行日常日常操作。如果您反复收缩数据库并注意到数据库大小再次增长,这表明常规操作需要收缩的空间。在这些情况下,反复收缩数据库是一种浪费的操作。 收缩操作不会保留数据库中索引的碎片状态,并且通常会在一定程度上增加碎片。这是不重复收缩数据库的另一个原因。 按顺序而不是同时收缩同一数据库中的多个文件。系统表的争用可能会因阻塞而导致延迟。
最佳实践
当您计划收缩文件时,请考虑以下信息:
另外值得注意的是:
DBCC SHRINKFILE可以在流程中的任何时候停止操作,并保留任何已完成的工作。
执行此操作时肯定需要考虑一些事项,我建议您查看Paul Randal 的博客文章,了解执行此操作时会发生什么。
第一步肯定是验证您实际能够替换多少空间和可用空间,以及文件上的已用空间:
use AdventureWorks2012; go ;with db_file_cte as ( select name, type_desc, physical_name, size_mb = convert(decimal(11, 2), size * 8.0 / 1024), space_used_mb = convert(decimal(11, 2), fileproperty(name, 'spaceused') * 8.0 / 1024) from sys.database_files ) select name, type_desc, physical_name, size_mb, space_used_mb, space_used_percent = case size_mb when 0 then 0 else convert(decimal(5, 2), space_used_mb / size_mb * 100) end from db_file_cte;