了解SQL Server事务日志备份和完整备份的日志序列号

This article explores the SQL Server Transaction log backups and log sequence number (LSN) in combination with the Full backups.

本文探讨了SQL Server事务日志备份和日志序列号（LSN）与完整备份的组合。

SQL Server备份简介 (SQL Server Backup Introduction)

The database backups are crucial for database recovery and disaster planning. It is the primary duty of a DBA to define the backup policy for each database based on the criticality, Recovery time object (RTO) and Recovery Point Objective (RPO). The database backups are useful even if you implemented the disaster recovery solutions like HADR SQL Server Always On. To meet these requirements, we schedule native or third-party backup tools to take database backups. We have the following database backups in SQL Server.

数据库备份对于数据库恢复和灾难计划至关重要。 DBA的主要职责是根据重要性，恢复时间对象（RTO）和恢复点目标（RPO）为每个数据库定义备份策略。 即使您实施了灾难恢复解决方案（例如HADR SQL Server Always On），数据库备份也很有用。 为了满足这些要求，我们安排本机或第三方备份工具进行数据库备份。 我们在SQL Server中具有以下数据库备份。

• Full backup: It is a complete database backup and allows to restore database till the time backup was completed. It is the most straightforward form of database backup 完全备份：这是完整的数据库备份，可以还原数据库直到备份完成。 这是最简单的数据库备份形式
• Differential backup: It contains changes from the last full backup. These are cumulative backups 差异备份：它包含自上次完整备份以来的更改。 这些是累积备份
• Log backup: It takes SQL Server transaction log backup and contains data from the last log backup or first full database backup 日志备份：需要执行SQL Server事务日志备份，并包含上次日志备份或首次完整数据库备份中的数据

We are not going to talk in detail about these backup types. You can refer to the article Understanding SQL Server Backup Types to gather details about them.

我们不会详细讨论这些备份类型。 您可以参考文章了解SQL Server备份类型以收集有关它们的详细信息。

DBA combines these database backups to have a backup policy of a database. Usually, for large databases, we take a weekly full backup and the combination of differential and log backups in between. These database backups build a log chain, and it is very critical to maintain the log chain for database backups. We should also be aware of the actions that can break the log sequence. If the LSN chain is broken, it is difficult to restore the database, and in case of any disaster, if we cannot restore the database, it might create a problematic scenario for the DBA.

DBA组合了这些数据库备份以具有数据库的备份策略。 通常，对于大型数据库，我们每周进行一次完整备份，并在两者之间进行差异备份和日志备份的组合。 这些数据库备份会建立一个日志链，因此维护数据库备份的日志链非常关键。 我们还应该意识到可能破坏日志序列的操作。 如果LSN链断开，则很难还原数据库，如果发生任何灾难，如果我们无法还原数据库，则可能会给DBA带来问题。

Suppose we have the following backup policy for a critical database.

假设我们对关键数据库具有以下备份策略。

• Weekly Full backup
  每周完整备份
• Daily differential backup
  每日差异备份
• Hourly SQL Server transaction log backup
  每小时SQL Server事务日志备份

In the above scenario, let’s say someone took a Full database backup after the SQL Server Transaction Log backup.

在上述情况下，假设某人在SQL Server事务日志备份之后进行了完整数据库备份。

问题 (Questions)

Now let me ask a few questions here:

现在让我在这里问几个问题：

• Will the full backup break the LSN chain?
  完整备份会中断LSN链吗？
• The transaction log backup after the full backup contains data from the full backup or not?
  完全备份后的事务日志备份是否包含来自完全备份的数据？
• If the database size is huge and full backup takes 4-5 hours to complete, what happens to hourly log backup?
  如果数据库很大，并且完全备份需要4到5个小时才能完成，那么每小时日志备份会怎样？
• Would log backup work while the full backup is in progress?
  正在进行完整备份时，日志备份会工作吗？

If you know the answers to these questions, you can skip this article. I am sure most of the DBA would be confused and fail to answer these questions.

如果您知道这些问题的答案，则可以跳过本文。 我确信大多数DBA都会感到困惑，并且无法回答这些问题。

SQL Server备份和LSN概述 (Overview of SQL Server backups and LSN)

Let’s prepare the environment to explore answers to these questions.

让我们准备一个环境来探索这些问题的答案。

示例1：完整数据库备份和LSN (Example 1: Full Database backup and LSN )

Create a sample database and take a full database backup using the following query. This query takes the full backup, performs CHECKSUM and verify backup once finished.

创建一个示例数据库，并使用以下查询进行完整的数据库备份。 此查询将执行完整备份，执行CHECKSUM并在完成后验证备份。

BACKUP DATABASE [SampleDB] TO  DISK = N'E:\DBbackup\SampleDB.bak' WITH NOFORMAT, INIT,  NAME = N'SampleDB-Full Database Backup', SKIP, NOREWIND, NOUNLOAD, COMPRESSION,  STATS = 10, CHECKSUM
GO
declare @backupSetId as int
select @backupSetId = position from msdb..backupset where database_name=N'SampleDB' and backup_set_id=(select max(backup_set_id) from msdb..backupset where database_name=N'SampleDB' )
if @backupSetId is null begin raiserror(N'Verify failed. Backup information for database ''SampleDB'' not found.', 16, 1) end
RESTORE VERIFYONLY FROM  DISK = N'E:\DBbackup\SampleDB.bak' WITH  FILE = @backupSetId,  NOUNLOAD,  NOREWIND
GO

Once backup is finished, execute the following query in database context for which we want to extract the details. It checks backup history for full, differential and SQL Server transaction log backups. It also gives the log sequence details for each backup types.

备份完成后，在我们要提取其详细信息的数据库上下文中执行以下查询。 它检查完整，差异和SQL Server事务日志备份的备份历史记录。 它还提供了每种备份类型的日志序列详细信息。

SELECT 
s.database_name,
CAST(CAST(s.backup_size / 1000000 AS INT) AS VARCHAR(14)) + ' ' + 'MB' AS bkSize,
CAST(DATEDIFF(second, s.backup_start_date,
s.backup_finish_date) AS VARCHAR(4)) + ' ' + 'Seconds' TimeTaken,
s.backup_start_date,
CAST(s.first_lsn AS VARCHAR(50)) AS first_lsn,
CAST(s.last_lsn AS VARCHAR(50)) AS last_lsn,
CAST(s.database_backup_lsn AS VARCHAR(50)) AS database_backup_lsn,
CAST(s.checkpoint_lsn AS VARCHAR(50)) AS checkpoint_lsn,
CASE s.[type] WHEN 'D' THEN 'Full'
WHEN 'I' THEN 'Differential'
WHEN 'L' THEN 'Transaction Log'
END AS BackupType,
s.recovery_model
FROM msdb.dbo.backupset s
INNER JOIN msdb.dbo.backupmediafamily m ON s.media_set_id = m.media_set_id
WHERE s.database_name = DB_NAME() 
ORDER BY backup_start_date DESC, backup_finish_date
GO

In the output, we can look at the following values.

在输出中，我们可以查看以下值。

• First_lsn: It shows the log sequence number of the oldest log record First_lsn：显示最早的日志记录的日志序列号
• Last_LSN: it shows the Last log sequence number in the backup set Last_LSN：它显示备份集中的最后一个日志序列号
• Checkpoint_LSN: it is the log sequence number of the last checkpoint Checkpoint_LSN：它是最后一个检查点的日志序列号
• Database_LSN: it shows the LSN of the last full database backup. In this case, we are taking a first full backup. Therefore, it shows the zero value Database_LSN：它显示上次完整数据库备份的LSN。 在这种情况下，我们将进行第一次完整备份。 因此，它显示零值

示例2：事务日志备份和LSN (Example 2: Transaction log backup and LSN)

Now open two new query windows.

现在打开两个新的查询窗口。

Query Window 1: Execute the following query to take SQL Server Transaction Log backup at every 1-minute interval.

查询窗口1：执行以下查询以每1分钟间隔进行一次SQL Server事务日志备份。

BACKUP LOG [SampleDB] TO  DISK = N'E:\DBbackup\SampleDB.trn' WITH NOFORMAT, INIT, 
SKIP, NOREWIND, NOUNLOAD, COMPRESSION,  STATS = 10
GO
WAITFOR DELAY '00:01:00.000'
BACKUP LOG [SampleDB] TO  DISK = N'E:\DBbackup\SampleDB1.trn' WITH NOFORMAT, INIT, 
SKIP, NOREWIND, NOUNLOAD, COMPRESSION,  STATS = 10
GO
WAITFOR DELAY '00:01:00.000'
BACKUP LOG [SampleDB] TO  DISK = N'E:\DBbackup\SampleDB2.trn' WITH NOFORMAT, INIT, 
SKIP, NOREWIND, NOUNLOAD, COMPRESSION,  STATS = 10
GO
WAITFOR DELAY '00:01:00.000'
BACKUP LOG [SampleDB] TO  DISK = N'E:\DBbackup\SampleDB3.trn' WITH NOFORMAT, INIT, 
SKIP, NOREWIND, NOUNLOAD, COMPRESSION,  STATS = 10
GO
WAITFOR DELAY '00:01:00.000'
BACKUP LOG [SampleDB] TO  DISK = N'E:\DBbackup\SampleDB4.trn' WITH NOFORMAT, INIT, 
SKIP, NOREWIND, NOUNLOAD, COMPRESSION,  STATS = 10
GO
WAITFOR DELAY '00:01:00.000'
BACKUP LOG [SampleDB] TO  DISK = N'E:\DBbackup\SampleDB5.trn' WITH NOFORMAT, INIT, 
SKIP, NOREWIND, NOUNLOAD, COMPRESSION,  STATS = 10
GO
WAITFOR DELAY '00:01:00.000'
BACKUP LOG [SampleDB] TO  DISK = N'E:\DBbackup\SampleDB6.trn' WITH NOFORMAT, INIT, 
SKIP, NOREWIND, NOUNLOAD, COMPRESSION,  STATS = 10
GO
WAITFOR DELAY '00:01:00.000'
BACKUP LOG [SampleDB] TO  DISK = N'E:\DBbackup\SampleDB7.trn' WITH NOFORMAT, INIT, 
SKIP, NOREWIND, NOUNLOAD, COMPRESSION,  STATS = 10
GO
WAITFOR DELAY '00:01:00.000'
BACKUP LOG [SampleDB] TO  DISK = N'E:\DBbackup\SampleDB8.trn' WITH NOFORMAT, INIT, 
SKIP, NOREWIND, NOUNLOAD, COMPRESSION,  STATS = 10
GO

Query Window 2: Execute the following query to generate transaction log activity every 30 seconds.

查询窗口2：执行以下查询以每30秒生成一次事务日志活动。

INSERT INTO ExamResult
VALUES
('Lily', 
 'Maths', 
 65
);
Go 100
WAITFOR DELAY '00:00:30.000'
 
INSERT INTO ExamResult
VALUES
('Lily', 
 'Maths', 
 65
);
Go 100
WAITFOR DELAY '00:00:30.000'
 
INSERT INTO ExamResult
VALUES
('Lily', 
 'Maths', 
 65
);
Go 100
WAITFOR DELAY '00:00:30.000'
 
INSERT INTO ExamResult
VALUES
('Lily', 
 'Maths', 
 65
);
Go 100
WAITFOR DELAY '00:00:30.000'
 
INSERT INTO ExamResult
VALUES
('Lily', 
 'Maths', 
 65
);
Go 100
WAITFOR DELAY '00:00:30.000'
 
INSERT INTO ExamResult
VALUES
('Lily', 
 'Maths', 
 65
);
Go 100

Once both the query gets completed, rerun the query to check the log backup history.

两个查询都完成后，请重新运行查询以检查日志备份历史记录。

In this screenshot, you can note the following things.

在此屏幕截图中，您可以注意以下几点。

• Database_backup_LSN for all log backup points to last full backup first_lsn
  所有日志备份点的Database_backup_LSN至上一次完整备份first_lsn
• For the first log backup, Last_lsn value corresponds to last_lsn of the full backup
  对于第一个日志备份，Last_lsn值对应于完整备份的last_lsn
• For all subsequent log backup, first_lsn is the last_lsn value of previous SQL Server Transaction Log backup
  对于所有后续日志备份，first_lsn是先前SQL Server事务日志备份的last_lsn值

示例3：多个完整备份和后续日志备份 (Example 3: Multiple full backups and subsequent log backup)

Let’s take two full backup and subsequent SQL Server transaction log backups.

让我们进行两个完整备份和后续SQL Server事务日志备份。

BACKUP DATABASE [SampleDB] TO  DISK = N'E:\DBbackup\SampleDB1.bak' WITH NOFORMAT, INIT,  NAME = N'SampleDB-Full Database Backup', 
SKIP, NOREWIND, NOUNLOAD, COMPRESSION,  STATS = 10, CHECKSUM
GO
BACKUP DATABASE [SampleDB] TO  DISK = N'E:\DBbackup\SampleDB2.bak' WITH NOFORMAT, INIT,  NAME = N'SampleDB-Full Database Backup', 
SKIP, NOREWIND, NOUNLOAD, COMPRESSION,  STATS = 10, CHECKSUM
GO
 
WAITFOR DELAY '00:01:00.000'
BACKUP LOG [SampleDB] TO  DISK = N'E:\DBbackup\SampleDB9.trn' WITH NOFORMAT, INIT, 
SKIP, NOREWIND, NOUNLOAD, COMPRESSION,  STATS = 10
GO
WAITFOR DELAY '00:01:00.000'
BACKUP LOG [SampleDB] TO  DISK = N'E:\DBbackup\SampleDB10.trn' WITH NOFORMAT, INIT, 
SKIP, NOREWIND, NOUNLOAD, COMPRESSION,  STATS = 10
GO

Let’s view the database backup LSN information. In the following screenshot, we can note the following things.

让我们查看数据库备份LSN信息。 在以下屏幕截图中，我们可以注意以下几点。

• For the first full backup after the log backups, checkpoint_lsn and first_lsn values are same, and database_backup_lsn still point to first_lsn of the initial full backup
  对于日志备份之后的第一个完整备份，checkpoint_lsn和first_lsn值相同，而database_backup_lsn仍指向初始完整备份的first_lsn
• For the next full backup also, checkpoint_lsn and first_lsn values are the same but the database_backup_lsn value changes to first_lsn of the previous full backup
  对于下一次完整备份，checkpoint_lsn和first_lsn值相同，但是database_backup_lsn值更改为上一次完整备份的first_lsn
• Log backup after the full backup has the first_LSN value equals to last_lsn of the last log backup. It shows that log backup does not break the LSN chain and it continues to maintain the chain since the last log backup
  完整备份后的日志备份的first_LSN值等于上次日志备份的last_lsn。 它显示日志备份不会中断LSN链，并且自从上次日志备份以来它继续维护该链。

示例4：在完整备份处于运行状态时进行SQL Server事务日志备份 (Example 4: Take SQL Server transaction log backup while a full backup is in running state)

In the next step, let’s start log backup while the full backup is in running state. Open two new query window in SSMS.

在下一步中，让我们在完整备份处于运行状态时开始日志备份。 在SSMS中打开两个新的查询窗口。

Execute the following query to take full database backup in the first window.

执行以下查询以在第一个窗口中进行完整的数据库备份。

BACKUP DATABASE [SampleDB] TO  DISK = N'E:\DBbackup\SampleDBfull23.bak' WITH NOFORMAT, INIT,  NAME = N'SampleDB-Full Database Backup', 
SKIP, NOREWIND, NOUNLOAD, COMPRESSION,  STATS = 10, CHECKSUM

In the second query window, execute the query to take transaction log backup.

在第二个查询窗口中，执行查询以进行事务日志备份。

BACKUP LOG [SampleDB] TO  DISK = N'E:\DBbackup\SampleDB23.trn' WITH NOFORMAT, INIT, 
SKIP, NOREWIND, NOUNLOAD, COMPRESSION,  STATS = 10
GO

Once both the backups are finished, view the database backup history again.

两个备份完成后，再次查看数据库备份历史记录。

Observe the following things from the query output.

从查询输出中观察以下内容。

• Full database backup started at 2019-07-16 13:26:20.000 and log backup started at 2019-07-16 13:26:21.000
  完整数据库备份始于2019-07-16 13：26：20.000，日志备份始于2019-07-16 13：26：21.000
• Log backup started before full database backup finished at 2019-07-16 13:26:28.000
  在完整数据库备份于2019-07-16 13：26：28.000之前开始日志备份
• Both full and log backup show the similar database_backup_lsn because transaction log backup started before completion of the full backup, it references to old full backup
  完全备份和日志备份都显示类似的database_backup_lsn，因为事务日志备份在完全备份之前开始，它引用了旧的完全备份
• The log backup LSN still matches with the last_LSN of previous transaction log backup. It shows that SQL Server transaction log backup maintains the log chain even if it is running while the full backup is in progress. Log truncation cannot occur during the full backup even if you are running the transaction log backup. It will occur with the first log backup after the full backup
  日志备份LSN仍与先前事务日志备份的last_LSN匹配。 它显示SQL Server事务日志备份将维护日志链，即使该日志链在完全备份进行时仍在运行。 即使您正在运行事务日志备份，在完整备份期间也不会发生日志截断。 完全备份后，它将在第一次日志备份时发生

最初提出的问题的答案 (Answers to initially asked questions)

Let’s go back to questions asked initially and find out the answers.

让我们回到最初提出的问题，找出答案。

• Will the full backup break the LSN chain?

  完整备份会中断LSN链吗？

  No, Full backup does not break the log sequence chain.

  不，完全备份不会中断日志序列链。

• The transaction log backup after the full backup contains data from the full backup or not?

  完全备份后的事务日志备份是否包含来自完全备份的数据？

  The transaction log backup takes data from the last LSN of previous log backup. It maintains the log chain; however, we can restore the full backup followed by the transaction log backup. SQL Server prepares a restoration plan as per the LSN during restore planning.

  事务日志备份从先前日志备份的最后一个LSN中获取数据。 它维护日志链； 但是，我们可以还原完整备份，然后再还原事务日志备份。 在还原计划期间，SQL Server根据LSN准备还原计划。

• If the database size is enormous and full backup takes 4-5 hours to complete, what happens to hourly log backup?

  如果数据库很大，并且完全备份需要4-5个小时才能完成，那么每小时日志备份会怎样？

  Nothing, Log backup can continue to run as usual. The only difference is that it cannot truncate the transaction log due to in-progress full backup. Once we execute log backup after full backup completion, it truncates the log as well.

  日志备份可以照常继续运行。 唯一的区别是由于正在进行完全备份，它无法截断事务日志。 在完全备份完成后执行日志备份后，它也会同时截断日志。

• Would SQL Server transaction log backup work while the full backup is in progress?

  在进行完全备份时，SQL Server事务日志备份是否可以工作？

  As per the previous question, transaction log backup execution can work as usual. You will not face any failure in the transaction log backup job due to full backup progress.

  按照前面的问题，事务日志备份执行可以照常进行。 由于完整的备份进度，您不会在事务日志备份作业中遇到任何失败。

日志序列不匹配的常见原因 (Log sequence mismatch common reason)

We can have many reasons that can break the log chain for database backup. If a particular database backup is corrupted or missing, it might impact the log chain and would make it difficult to restore the database.

我们有很多原因可能会破坏数据库备份的日志链。 如果特定的数据库备份已损坏或丢失，则可能会影响日志链，并使恢复数据库变得困难。

Let’s explore the reasons that can break the log sequence.

让我们探讨破坏日志序列的原因。

• Sometimes DBA changes the recovery model to simple to execute bulk transactions that can lead to higher log growth. If we switch the recovery model from Full to Simple, it breaks the log sequence. Switching back the recovery model to FULL requires to set up a log chain again using the full backup and the subsequent SQL Server transaction log backups
  有时，DBA将恢复模型更改为易于执行批量事务的简单操作，这可以导致更高的日志增长。 如果将恢复模式从“完全”切换为“简单”，则会中断日志序列。 将恢复模型切换回FULL，需要使用完整备份和后续SQL Server事务日志备份再次设置日志链
• Switching recovery model from bulk-logged to simple also breaks the log sequence
  将恢复模式从大容量日志记录切换为简单日志记录也会破坏日志序列
• Suppose we take differential backup daily. The base for the differential backup is the last full backup. We should not take on-demand full backup in this case because it breaks the chain for the differential backup. Take full backup with the Copy_Only option in this case
  假设我们每天进行差异备份。 差异备份的基础是最后的完整备份。 在这种情况下，我们不应该进行按需完整备份，因为这会断开差异备份的链。 在这种情况下，使用Copy_Only选项进行完全备份
• If we revert to a database snapshot, it also breaks the log sequence
  如果我们恢复到数据库快照，它也会破坏日志序列

结论 (Conclusion)

In this article, we explored the concept of a SQL Server transaction log backup with LSN and how SQL Server maintains the chain with multiple scenarios. DBA should be aware of these scenarios to avoid any mistake that can break the log sequence. You should also perform the database restoration drills on a timely basis to test the recovery of databases from the backups.

在本文中，我们探讨了使用LSN进行SQL Server事务日志备份的概念，以及SQL Server如何在多种情况下维护链。 DBA应该注意这些情况，以避免可能破坏日志序列的任何错误。 您还应该及时执行数据库还原演练，以测试从备份中恢复数据库的情况。

翻译自: https://www.sqlshack.com/understanding-log-sequence-numbers-for-sql-server-transaction-log-backups-and-full-backups/