MSSQL数据库瘦身及迁移求助：已缩表但备份仍占2.6TB

一、备份体积未缩减的核心原因 #

删除大表数据后，数据库物理文件（MDF/NDF）仅标记释放的空间为内部空闲可用，但物理文件的实际大小并未缩小，备份文件会包含整个已分配的物理空间，因此体积无变化。

二、实操解决方案 #

1. 处理事务日志文件（完整恢复模式下） #

• 若数据库为完整恢复模式，先执行一次日志备份，再临时切换为简单恢复模式：

  ALTER DATABASE YourDBName SET RECOVERY SIMPLE;
  

• 收缩日志文件至合理大小（示例预留10GB，可根据业务调整）：

  DBCC SHRINKFILE (YourDBLogFileName, 10240); -- 10240MB = 10GB
  

• 完成后恢复完整恢复模式（若业务需要）：

  ALTER DATABASE YourDBName SET RECOVERY FULL;
  

2. 高效迁移至新数据库（推荐，规避收缩碎片） #

既然计划在E盘新建数据库，直接迁移实际数据即可跳过原数据库的空闲空间：

• SQL Server导入导出向导：
  1. 连接源数据库与E盘新数据库
  2. 选择所有表和视图，执行数据复制，新数据库仅占用实际数据空间
• 批量生成迁移脚本（适配900张表的批量操作）：
  生成SELECT INTO迁移脚本：

  SELECT 'SELECT * INTO NewDB.dbo.' + name + ' FROM OldDB.dbo.' + name + ';'
  FROM OldDB.sys.tables;
  

  执行生成的脚本完成数据迁移后，手动创建视图、存储过程等对象。

3. 可选：收缩原数据库数据文件 #

若需临时缩小原数据库物理文件，可执行（注意：收缩会产生索引碎片，后续需重建）：

DBCC SHRINKDATABASE (YourDBName, 10); -- 预留10%空闲空间

4. 后续优化 #

• 对新数据库的大表重建索引，修复迁移或收缩产生的碎片：

  ALTER INDEX ALL ON YourTableName REBUILD;
  

• 建立自动清理历史数据的定时任务，避免数据库再次快速膨胀

三、多数据库磁盘规划 #

1. 先在临时3TB F盘完成所有数据库的迁移瘦身操作
2. 对瘦身完成的数据库执行备份（此时备份体积已缩减）
3. 将备份依次恢复至2TB E盘的永久空间，确保总占用不超过配额

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