Azure DevOps Server数据库压缩问题：删除冗余数据后容量显示未更新的解决指引请求

这是个非常典型的场景——当你删除大量数据后，SQL Server并不会自动缩小数据库的物理文件大小，只是把释放出来的空间标记为空闲空间，所以数据库仍会显示原来的1.3TB容量。要让它显示实际占用的160GB，你需要手动收缩数据库文件，但得遵循正确的步骤，避免影响系统性能。

第一步：确认空闲空间情况 #

先运行以下查询，确认每个数据库文件的当前大小和空闲空间，确保确实有大量可回收的空间：

SELECT 
    name AS 文件名,
    size/128.0 AS 当前大小(MB),
    size/128.0 - CAST(FILEPROPERTY(name, 'SpaceUsed') AS INT)/128.0 AS 空闲空间(MB)
FROM sys.database_files;

这个查询会列出数据文件（.mdf/.ndf）和日志文件（.ldf）的详细信息，你能看到空闲空间的具体数值，为后续收缩操作提供依据。

第二步：分文件处理收缩操作 #

1. 处理事务日志文件 #

如果你的数据库使用的是完整恢复模式（Azure DevOps Server推荐的模式），先按以下步骤操作：

• 首先备份事务日志（保留日志完整性）：

  BACKUP LOG [你的AzureDevOps数据库名] TO DISK = 'D:\备份路径\你的数据库名_日志备份.bak';
  

• 然后收缩日志文件到最小合理大小：

  DBCC SHRINKFILE (N'你的数据库日志文件名', 0);
  

  这里的0表示让SQL Server自动收缩到最小可能的大小（仅保留必要的日志记录）。
• 最后恢复完整恢复模式（如果之前修改过）：

  ALTER DATABASE [你的AzureDevOps数据库名] SET RECOVERY FULL;
  

2. 处理数据文件 #

数据文件的收缩要更谨慎，因为频繁收缩会导致索引碎片化，影响查询性能。建议只在这种大量数据删除后执行一次：

• 方式一：收缩整个数据库（自动处理所有数据文件）

  DBCC SHRINKDATABASE ([你的AzureDevOps数据库名], 10);
  

  第二个参数10表示保留10%的空闲空间，你可以根据实际需求调整（比如设为5，或者0来尽量缩小，但不建议完全不留空闲空间）。
• 方式二：单独收缩指定数据文件（更精准）
  如果你想直接把数据文件缩小到170GB（给实际占用的160GB留10GB缓冲），可以执行：

  DBCC SHRINKFILE (N'你的数据库数据文件名', 174080);
  

  注意：170GB = 170 * 1024 = 174080 MB，替换成你的实际数据文件名即可。

第三步：收缩后的性能优化 #

收缩操作会产生大量索引碎片，必须进行优化：

• 如果索引碎片率超过30%，重建索引：

  EXEC sp_MSforeachtable 'ALTER INDEX ALL ON ? REBUILD;'
  

• 如果碎片率在10%-30%之间，重新组织索引：

  EXEC sp_MSforeachtable 'ALTER INDEX ALL ON ? REORGANIZE;'
  

同时，建议调整数据库文件的自动增长设置：改为固定大小增长（比如每次增长10GB），而不是百分比增长，这样能避免后续频繁小幅度增长导致的碎片化。

验证结果 #

再次运行第一步的空闲空间查询，你会看到数据库文件的物理大小已经缩小到接近实际占用的160GB，数据库显示的容量也会同步更新。

注意：收缩操作会消耗CPU和IO资源，请务必在非高峰时段执行，避免影响Azure DevOps Server的正常使用。

内容的提问来源于stack exchange，提问作者Gyanu Kumari