Log Shipping主库日志备份作业异常：失败/卡顿排查求助

针对你遇到的System.IO.FileLoadException: 0x80070020（文件被占用）和作业时长不稳定的问题，咱们一步步来定位根因：

1. 锁定“文件被占用”的源头 #

这个错误核心是日志备份文件（或临时生成的备份文件）被其他进程锁定，你可以这么操作：

• 作业失败的瞬间，立刻用微软官方的「Process Explorer」工具搜索对应的日志备份文件路径，查看哪个进程在占用它。常见嫌疑对象：
  • 杀毒/安全工具：很多杀毒软件会实时扫描新生成的备份文件，刚好卡在LS备份写入的节点上导致锁定，可临时把备份目录加入杀毒排除列表测试。
  • 第三方备份工具：如果有其他备份系统（比如Veeam、Commvault）同时备份该库日志，会和LS作业抢文件锁，检查是否有重叠的备份计划。
  • 镜像相关进程：极端情况下，镜像的log send进程可能和LS备份进程在日志文件头部产生竞争，可同步观察镜像的同步状态是否有延迟。

2. 检查作业与维护任务的重叠 #

虽然你的数据库事务不频繁，但周期性维护作业（比如索引重建、统计信息更新）会瞬间产生大量日志，直接拉长LS备份时长甚至超时：

• 拉取SQL Server代理的所有作业时间线，对比LS日志备份作业的执行时间，看是否和其他维护作业重叠。
• 如果发现重叠，调整维护作业的时间窗口，或者临时把LS备份周期从15分钟调长到30分钟，避开维护高峰。

3. 排查存储层面的IO瓶颈 #

1.8TB的数据库，日志备份的IO性能直接决定作业时长：

• 检查备份目标磁盘健康：查看Windows系统日志里的磁盘读写错误/警告，用diskmgmt.msc确认磁盘状态正常。
• 监控SQL Server等待事件：作业运行时执行如下查询，查看是否存在IO类等待：

  SELECT wait_type, wait_time_ms, session_id 
  FROM sys.dm_exec_requests 
  WHERE command LIKE '%BACKUP%'
  

  如果出现BACKUPTHREAD、PAGEIOLATCH_WRITE这类等待，说明磁盘IO跟不上，可考虑把备份目录换到SSD磁盘，或开启LS备份的压缩选项（减少IO传输量）。

4. 验证Log Shipping与镜像的兼容性 #

主库同时参与镜像和Log Shipping，需确保两者配置无冲突：

• 确认LS日志备份未使用WITH COPY_ONLY选项：COPY_ONLY备份不会截断日志，会导致日志文件无限增长，同时打破LS备份链。查看LS作业的备份命令，应为标准格式（示例）：

  BACKUP LOG [你的数据库名] TO DISK = '备份文件路径' WITH NOFORMAT, NOINIT, NAME = 'LS日志备份', SKIP, REWIND, NOUNLOAD, COMPRESSION
  

• 检查镜像同步状态：如果镜像处于异步模式或存在较大延迟，主库日志无法及时截断，会导致备份文件越来越大、备份时间变长。执行如下查询查看状态：

  SELECT database_id, mirroring_state_desc, mirroring_log_sequence_number 
  FROM sys.database_mirroring
  

5. 检查作业配置与权限 #

• 查看LS日志备份作业的重试设置：如果作业第一次失败后立刻重试，可能因为文件仍被占用导致二次失败，可调整重试间隔或增加重试次数。
• 确认作业运行账户权限：账户需要对备份目录有读写权限，同时拥有SQL Server的BACKUP DATABASE权限，权限不足也可能导致备份异常。

6. 深挖日志细节 #

• 查看SQL Server错误日志：在作业失败的时间点附近，寻找更详细的备份失败细节（比如日志文件损坏、磁盘空间不足等）。
• 查看Windows应用日志：系统会记录文件访问被拒绝的相关事件（比如Event ID 4656），可帮助定位具体的占用进程。

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