SQLSERVER的日志链是事务日志备份之间形成的连续序列，它是实现数据库时间点恢复的基础，所有的事务日志备份必须首尾相连才能构成完整的恢复路径。
什么是SQLSERVER日志链
SQLSERVER的事务日志会为每个事务分配唯一的日志序列号（LSN），每个日志备份都会记录一段连续的LSN范围。当第一个事务日志备份的起始LSN对应数据库的初始状态，后续每个日志备份的起始LSN恰好等于前一个日志备份的结束LSN时，这些备份就形成了连续的日志链。
日志链的核心作用是保证事务日志的连续性，只有完整的日志链才能让数据库恢复到链中任意一个时间点，不会出现数据断层。
LSN在日志链中的核心作用
LSN是日志链的连接标识，每个事务日志记录都包含LSN，日志备份的头部会记录本次备份的起始LSN和结束LSN。我们可以通过系统视图查询日志备份的LSN信息：
-- 查询所有日志备份的LSN信息
SELECT
backup_set_id,
backup_start_date,
first_lsn, -- 备份的起始LSN
last_lsn, -- 备份的结束LSN
checkpoint_lsn
FROM msdb.dbo.backupset
WHERE type = 'L' -- L代表事务日志备份
ORDER BY backup_start_date ASC
正常情况下，后一个日志备份的first_lsn会等于前一个日志备份的last_lsn，这样两个备份就形成了连续的衔接，多个这样的备份串联起来就是完整的日志链。
日志链断裂的常见场景
日志链一旦断裂，断裂点之后的事务日志备份将无法用于恢复，常见的断裂原因有以下几种：
- 执行了一次完整的数据库备份，并且没有同时备份事务日志，导致新的日志链起点生成，旧的日志链断裂
- 手动删除了中间某个事务日志备份文件，导致LSN序列无法连续衔接
- 数据库从简单恢复模式切换到完整恢复模式后，没有先执行一次完整备份就直接做日志备份，初始LSN不连续
- 事务日志文件本身损坏，导致部分日志记录丢失，无法生成连续的备份
如何维护完整的日志链
为了保证日志链始终完整，需要遵循以下操作规范：
1. 固定备份顺序
备份顺序必须是：完整备份 → 事务日志备份1 → 事务日志备份2 → ...，不能跳过完整备份直接做日志备份，也不能在两次日志备份之间插入新的完整备份而不衔接日志。
2. 不要随意删除日志备份文件
除非已经确认对应的日志备份不再需要用于任何恢复场景，否则不要删除中间的日志备份文件，避免破坏LSN连续性。
3. 恢复模式切换后先打基础备份
当数据库从简单恢复模式切换到完整恢复模式时，必须先执行一次完整备份，再开始执行事务日志备份，确保初始LSN正确。
4. 定期检查日志链连续性
可以通过脚本定期检查现有日志备份的LSN是否连续，及时发现断裂问题：
-- 检查日志备份LSN是否连续
WITH LogBackupInfo AS (
SELECT
backup_set_id,
first_lsn,
last_lsn,
LEAD(first_lsn) OVER (ORDER BY first_lsn ASC) AS next_first_lsn
FROM msdb.dbo.backupset
WHERE type = 'L'
)
SELECT
backup_set_id,
first_lsn,
last_lsn,
CASE
WHEN next_first_lsn = last_lsn THEN '连续'
ELSE '断裂'
END AS chain_status
FROM LogBackupInfo
日志链断裂后的修复方法
如果日志链已经断裂，唯一的修复方式是重新执行一次完整数据库备份，从新的完整备份开始重新构建日志链，断裂点之前的所有日志备份将无法再用于后续恢复。
执行完整备份的脚本如下：
-- 执行完整备份重新开始日志链 BACKUP DATABASE TestDB TO DISK = 'D:BackupTestDB_Full.bak' WITH INIT, NAME = 'TestDB完整备份_重建日志链'
之后再进行的事务日志备份就会基于这次新的完整备份形成新的连续日志链。
注意：日志链只和事务日志备份的连续性有关，完整备份和差异备份不会直接影响日志链的连续性，但差异备份的恢复需要依赖对应的完整备份和完整的日志链。