如何解决SQL Server中DMS访问LSN失败的故障？

1. 日志备份保留周期短于DMS长轮询周期：SQL Server的事务日志会按备份策略定期备份并截断，若日志备份的保留时长小于DMS设置的6小时长轮询周期，夜间数据库闲置期间，DMS未及时读取的LSN对应的日志备份会被提前清理，导致任务后续无法找到该LSN的日志数据。
2. 对DMS长轮询逻辑的误解：长轮询是DMS在无变更时等待新数据的最长时长，并非实时持续读取日志。等待期间DMS不会主动跟踪日志备份变化，仅在轮询周期结束后才检查日志，若这段时间内目标日志备份已被删除，就会触发LSN访问失败的错误。
3. AlwaysOn环境的日志管理特殊性：多可用区AlwaysOn部署下，日志备份由可用性组统一管理，若备份策略未考虑DMS的读取需求，备份文件可能被过早清理；同时若DMS未正确配置为从主副本读取日志，也会导致无法访问有效的日志备份集。

• 调整日志备份保留策略：将SQL Server事务日志备份的保留时长设置为大于等于DMS长轮询周期+1-2小时的缓冲时间，确保DMS需要的日志备份在读取前不会被删除。例如长轮询6小时，保留时长设为8小时以上。
• 优化DMS轮询周期：若夜间数据库长期闲置，可将长轮询周期缩短至1-2小时（仍符合AWS建议的>1小时要求），让DMS更频繁地检查并读取日志，及时标记已处理的LSN，避免日志备份被清理后无法回溯。
• 配置DMS日志读取参数：针对SQL Server AlwaysOn环境，确保DMS任务的UseLogBackup参数设为true，并指定从可用性组主副本读取日志，保证DMS能正确识别和访问完整的日志备份链。
• 确保日志备份链完整：检查SQL Server的事务日志备份计划，避免出现备份中断导致的日志链断裂——日志链断裂会使DMS无法跨备份集读取后续LSN，需及时修复备份链并重新初始化DMS任务。
• 设置错误重试机制：在DMS任务配置中启用RetryableErrorWaitTime参数，设置合理的重试间隔（如300秒），让任务在遇到LSN不可用错误时自动重试，同时通过CloudWatch监控日志备份相关告警，提前发现问题。

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