事务日志占满磁盘，数据库恢复中能否移动.ldf文件并重启恢复？

你现在的数据库正处于恢复阶段1（前滚未提交事务），这个过程完全依赖当前的事务日志文件（.ldf）重放所有未完成的操作，中途移动或修改LDF文件会直接中断恢复流程，让数据库进入可疑或损坏状态，后续修复成本极高。

给你分阶段的可行解决方案：

第一步：先腾空间让恢复进程完成 #

当前最紧急的是让恢复跑完，别中断。你已经新增了磁盘，可以这么操作：

• 把服务器上非关键的文件（比如旧的数据库备份、临时日志文件、系统缓存文件等）临时转移到新增磁盘，给当前存放LDF的磁盘腾出至少几GB的余量（恢复过程中可能还会少量写入日志）
• 如果是Windows服务器，也可以尝试用磁盘管理工具扩展当前磁盘的容量（前提是磁盘有未分配空间）；Linux的话可以用逻辑卷扩展（lvextend + resize2fs之类的命令）

等恢复完成（三个阶段都结束，数据库回到可用状态），再处理LDF文件的移动。

第二步：恢复完成后安全移动LDF文件 #

等数据库恢复完成并可用后，按以下步骤移动日志文件：

1. 先查询当前数据库的日志文件名称和路径：

   SELECT name, physical_name 
   FROM sys.master_files 
   WHERE database_id = DB_ID('ABCD');
   

   记下日志文件的name（比如ABCD_Log）和当前physical_name路径。

2. 将数据库设置为脱机：

   ALTER DATABASE ABCD SET OFFLINE;
   

   这一步会断开所有数据库连接，确保文件不被占用。

3. 手动将LDF文件从原路径复制到新增磁盘的目标位置（比如D:\SQLLogs\ABCD.ldf）。

4. 修改SQL Server系统目录中的文件路径：

   ALTER DATABASE ABCD 
   MODIFY FILE (NAME = 'ABCD_Log', FILENAME = 'D:\SQLLogs\ABCD.ldf');
   

   注意把NAME换成你第一步查到的日志文件名，FILENAME换成新的路径。

5. 将数据库重新设为联机：

   ALTER DATABASE ABCD SET ONLINE;
   

6. 验证文件路径是否更新成功：再次执行第一步的查询语句，确认physical_name已经变成新路径。

后续预防措施 #

• 立即检查并修复你的备份计划，尤其是日志备份——在完整恢复模式下，只有定期做日志备份才能截断事务日志，避免LDF无限制膨胀。
• 下次执行大量DELETE操作时，建议分批执行（比如每次删10000条，加事务和等待），同时配合日志备份，减少日志的累积。

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