背景与问题概述
在企业级数据库架构中，SQL Server Always On Availability Group (AG) 已成为高可用和灾难恢复的主流选择。然而，许多IT管理员容易忽视一个关键的数据保护层面：日志传送（Log Shipping）。虽然AG提供了实时的数据冗余，但日志传送作为一种异步的、基于文件的备份机制，对于防止逻辑错误（如误删除表、恶意删除数据）以及满足特定合规性要求至关重要。
近日，某中型制造企业反馈其核心ERP系统的数据库日志传送监控报警，显示备份作业连续失败。经过现场排查，发现主副本（Primary Replica）上的历史备份任务停滞，导致备用站点无法应用最新的交易日志，数据延迟高达数小时。本文将复盘此次故障的排查过程，并总结通用的解决方案。
故障现象与初步定位
管理员登录到SQL Server Management Studio (SSMS)，检查Always On可用性组的监控状态，发现AG本身运行正常，主副本与辅助副本之间的同步延迟极小（毫秒级）。然而，在“日志传送”管理界面中，所有辅助副本均显示“未接收到最近备份”。进一步查看主副本上的作业历史记录，发现名为“LS Backup [DBName]”的作业在过去24小时内多次失败，错误代码指向“由于系统资源不足，无法完成请求的服务”或“无法访问共享路径”。
深度排查与根因分析
针对上述现象，我们从以下四个维度进行了详细排查：
1. 主副本负载与备份窗口冲突
现象：备份失败时间通常集中在业务高峰期的下午2点至4点。主服务器的CPU和磁盘I/O使用率在备份期间飙升至90%以上。
分析：SQL Server的全量备份和差异备份本身是I/O密集型操作。如果日志传送的备份作业（Backup Job）与日常维护计划中的全量/差异备份重叠，或者主副本正在执行大规模的数据导入任务，会导致备份进程被挂起或超时。此外，如果未配置备份压缩，生成的日志文件体积巨大，进一步加剧了存储和I/O压力。
2. 网络连通性与共享文件夹权限
现象：尝试在主服务器上手动将生成的`.trn`文件复制到共享文件夹时，偶尔出现访问拒绝或超时。
分析：日志传送依赖于Windows身份验证或SQL Server代理账户对目标共享文件夹的写权限。如果网络中存在防火墙策略变动，或者AD域账号密码过期，会导致SQL Server代理账户无法验证共享目录权限。另外，如果主副本与日志副本位于不同子网，且网络带宽受限，大体积日志文件的传输可能会因TCP超时而导致作业失败。
3. 存储空间耗尽
现象：检查主服务器和共享文件夹所在磁盘，发现可用空间接近零。
分析：日志文件是持续增长的。如果清理旧备份的作业（Cleanup Job）未能按时执行，或者磁盘配额设置过低，会导致新备份无法写入。特别是在使用备份压缩功能失效或磁盘文件系统损坏的情况下，空间清理可能滞后于生成速度。
4. Always On角色切换的影响
现象：故障前一周曾发生过一次手动故障转移（Failover）测试。
分析：当发生角色切换时，新的主副本需要重新配置日志传送会话。如果管理员未正确更新共享路径权限或未重新初始化日志传送元数据，新主副本上的备份作业可能沿用旧的配置或陷入不一致状态。
解决方案与实施步骤
基于上述分析，我们采取了以下措施成功恢复了日志传送功能：
步骤一：优化备份策略与资源隔离
- 启用备份压缩：在日志传送设置中，勾选“压缩备份”。这能显著减少生成的日志文件大小，降低I/O负担和网络传输时间。建议在SSMS的“日志传送配置向导”->“备份设置”中修改，或通过T-SQL脚本调整。
EXEC sp_change_log_shipping_primary_database @database = N'DBName', @backup_compression = 1; - 错峰调度：调整全量/差异备份作业的时间窗口，避开业务高峰期和日志备份的高峰时段。确保日志传送备份作业拥有更高的优先级或独立的资源池。
步骤二：排查并修复权限与网络问题
- 验证账户权限：确保SQL Server代理服务运行的账户（通常是Domain Admin或具有特定权限的域账户）对目标共享文件夹拥有“完全控制”权限。同时，检查该账户在本地安全策略中的“作为服务登录”权利。
- 网络连通性测试：从主服务器使用`Test-Path`或`dir \\Share\Folder`命令测试共享路径的访问。如有必要，联系网络团队检查防火墙规则，确保TCP端口445（SMB）畅通，并适当增加网络超时设置。
步骤三：清理空间与重置会话
- 清理旧备份：手动删除共享文件夹中过期的日志文件（建议保留至少7天的日志以备不时之需）。检查并修复“日志传送清理作业”，确保其按计划运行。
- 重新配置日志传送：如果配置混乱，最稳妥的方法是删除当前的日志传送配置，然后重新运行“添加日志传送”向导。在向导过程中，仔细核对共享路径、账户凭据和备份频率。对于Always On环境，务必确认是否需要在每个辅助副本上单独配置日志传送，或者利用AG的内置机制结合日志传送进行双重保护。
最佳实践建议
为了防止此类问题再次发生，建议企业IT团队遵循以下规范：
- 监控前置：不要仅依赖作业失败后的报警。在监控系统中设置阈值，当日志备份间隔超过一定时间（如30分钟）或备份文件大小异常时即触发预警。
- 定期演练：每季度进行一次日志恢复演练，验证备用站点的日志文件是否可用，以及是否能成功还原到指定时间点。
- 文档化配置：记录所有的共享路径、账户权限和调度时间表。在发生AD域迁移或服务器IP变更时，第一时间更新相关配置。
结语
日志传送作为SQL Server数据保护体系中的重要一环，常被High Availability需求所掩盖。然而，在面对人为错误或勒索病毒攻击时，它往往是最后的防线。通过细致的排查和规范的运维管理，可以确保这一机制始终处于健康状态，为企业数据资产提供坚实的保护。