如何调整SQL Server数据库大小，迁移至Azure VM时降低冗余存储成本

迁移前原实例操作 #

• 先确认各文件实际空间占用，执行以下查询获取数据文件、日志文件的总大小、已用空间、空闲空间：

SELECT 
    name AS FileLogicName,
    size/128.0 AS TotalSizeMB,
    FILEPROPERTY(name, 'SpaceUsed')/128.0 AS UsedSpaceMB,
    (size - FILEPROPERTY(name, 'SpaceUsed'))/128.0 AS FreeSpaceMB,
    type_desc AS FileType
FROM sys.database_files;

• 清理冗余数据：删除无用的历史表、临时表、测试数据，清理过期的系统日志、备份历史，再对高碎片索引进行重建，进一步压缩实际占用空间：

-- 重建指定表所有索引，可根据业务场景调整填充因子
ALTER INDEX ALL ON [TargetTableName] REBUILD WITH (FILLFACTOR = 80);

• 收缩数据库文件：禁止直接执行SHRINKDATABASE，单独收缩指定文件可减少碎片产生
  1. 收缩数据文件：根据第一步查询到的已用空间，预留10%~20%的缓冲空间用于后续正常写入，示例如下：

  -- 示例：已用空间600GB，预留10%即660GB=675840MB，替换为实际的文件逻辑名和目标大小
  DBCC SHRINKFILE (N'DataFileLogicName' , 675840);
  

  2. 收缩日志文件：如果是完整恢复模式，先执行一次事务日志备份再收缩，也可临时切换到简单恢复模式再操作：

  -- 临时切换简单恢复模式（不需要事务日志点对点还原时使用）
  ALTER DATABASE [DBName] SET RECOVERY SIMPLE;
  GO
  -- 收缩日志文件，建议预留足够峰值事务需求的空间，示例预留8GB=8192MB
  DBCC SHRINKFILE (N'LogFileLogicName' , 8192);
  GO
  -- 按需切回完整恢复模式，切回后需执行一次完整备份
  ALTER DATABASE [DBName] SET RECOVERY FULL;
  GO
  

注意：收缩文件属于高IO操作，必须在业务低峰期执行，执行过程中避免大规模数据写入，操作完成后需重新检查索引碎片，碎片过高时再次重建索引。

备份与恢复操作 #

• 原实例执行压缩备份，减小备份文件体积，提升传输和恢复效率：

BACKUP DATABASE [DBName] 
TO DISK = N'C:\Backup\DBName.bak' 
WITH COMPRESSION, STATS = 10;

• 将备份文件传输到Azure VM后执行恢复，恢复完成后再次执行第一步的空间查询语句，确认数据库总大小符合预期，没有多余未分配空间，最后验证数据完整性和业务可用性即可。

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