完整備份和日誌備份中的日誌序列號
我的完整備份每天凌晨 02:00 開始。大約需要3個小時。
我還每 15 分鐘（在 15、30、45 和 00 小時）進行一次 T-Log 備份。
當我“僅恢復 header”時，我可以驗證 T-log 備份的 LSN 序列。
但是，完整備份的最後一個 LSN 與備份開始後立即進行的 T-log 備份之間似乎存在差距（即 02:15）
下面是從 02:00 開始的完整備份的 restore headeronly 輸出
第一個LSN：76583000073086500011 最後一個
LSN：76595000084143900001
…這是從 02.15 開始的日誌備份的 restore headeronly 輸出
第一個LSN：76570000086250400001 最後一個
LSN：76571000009693900001
完整備份的最後一個LSN和日誌備份的第一個LSN不應該一樣嗎？
我比較了在 05:15 和 05:00（完全備份完成時）備份的日誌的 LSN，但再次沒有序列。
我還檢查了完整備份和 CreateLSN 的 RESTORE FILELISTONLY，日誌文件的 DropLSN 為 0。我可能在這裡遺漏了什麼？謝謝你。
完整數據庫備份的 LastLSN + 1 將落在其後續事務日誌備份的 FirstLSN 和 LastLSN 之間。（http://www.mssqltips.com/sqlservertip/3209/understanding-sql-server-log-sequence-numbers-for-backups/）
事務日誌包含許多並行事務的事務詳細資訊，這些事務 (a) 已完成或 (b) 仍在處理中。
事務日誌備份旨在使用將數據庫恢復到包括最後完成的事務的時間點所需的所有數據來強化日誌文件。這也包括所有仍在處理中的事務，即使它們在送出或回滾之前沒有已知狀態。
因此，日誌備份的FirstLSN需要包含最早的未完成事務，以便能夠覆蓋所有送出或回滾事務的情況。
**注意：**這也解釋了為什麼長時間執行的打開事務可能會使數據庫日誌文件過度增長。日誌文件必須繼續將所有包含事務的 LSN 維護到最舊的仍然打開的事務。