了解SQL Server中的日志记录和恢复 (Understanding Logging and Recovery in SQL Server)

“Understanding Logging and Recovery in SQL Server”, Paul S. Randal在Paul S. Randal has given a complete overview of the transaction log. In four sections he explains: what is logging, what is recovery, how the transaction log works, and which recovery models are available. This article can be used as a starting point in understanding fundamentals of the transaction log and the logging process “了解SQL Server中的日志和恢复”中 ，对事务日志进行了完整的概述。 他在四个部分中说明了什么：日志记录，什么是恢复，事务日志如何工作以及可用的恢复模型。 本文可以作为了解事务日志和日志记录过程基础的起点

Logging in SQL Server is necessary to describe what’s changed in the storage structure of the database. Each database must have a transaction log to function properly. Virtual log files (VFLs) are smaller parts of the transaction log used for simpler internal management:

必须登录SQL Server才能描述数据库的存储结构中发生的更改。 每个数据库必须具有事务日志才能正常运行。 虚拟日志文件（VFL）是事务日志的较小部分，用于简化内部管理：

Choosing the right recovery model is important for future managing of the transaction log. There are three different recovery models, each with its own characteristics, advantages, and disadvantages. Here are some key points by Paul S. Randal regarding the transaction log:

选择正确的恢复模型对于将来管理事务日志很重要。 有三种不同的恢复模型，每种都有其自身的特点，优点和缺点。 这是Paul S. Randal关于事务日志的一些关键点：

• Do not create multiple log files, as it will lead to performance loss不要创建多个日志文件，因为这会导致性能下降
• Be aware of the recovery model your database is using and the effect it has on the transaction log—especially around whether it can automatically truncate or not when a checkpoint occurs请注意数据库正在使用的恢复模型及其对事务日志的影响，尤其是在发生检查点时是否可以自动截断数据库
• Be aware of the potential for transaction log growth, the factors that can lead to it, and how to get it back under control注意事务日志增长的潜力，可能导致其增长的因素，以及如何使其恢复受控状态
• Know where to look for help when troubleshooting a full transaction log [1]排查完整事务日志时，知道在哪里寻求帮助[1]

极客城市：探索事务日志结构 (Geek City: Exploring the Transaction Log Structure)

Exploring and reading the transaction log can be difficult due to the way information is recorded and the majority is in the hexadecimal format. SQL Server has, officially undocumented, the DBCC LOGINFO command which can be used to explore and read the transaction log. In “Geek City: Exploring the Transaction Log Structure”, Kalen Delaney points out the DBCC LOGINFO commands and importance of VLFs (Virtual Log Files). Using the DBCC LOGINFO command the result would be one row per Virtual log file and specific columns including: FileId, FileSize, StartOffset, FSecNo, Status, Parity, and CreateLSN. There is an example of T-SQL code which can be used to explore the transaction log with the DBCC LOGINFO command

由于记录信息的方式非常困难，因此很难浏览和读取事务日志，并且大多数信息采用十六进制格式。 SQL Server具有官方未记录的DBCC LOGINFO命令，该命令可用于浏览和读取事务日志。 在“极客城市：探索事务日志结构”中 ， Kalen Delaney指出了DBCC LOGINFO命令和VLF（虚拟日志文件）的重要性。 使用DBCC LOGINFO命令，结果将是每个虚拟日志文件一行，并且特定列包括：FileId，FileSize，StartOffset，FSecNo，Status，Parity和CreateLSN。 有一个T-SQL代码示例，可用于通过DBCC LOGINFO命令浏览事务日志

事务日志已满–事务日志大于数据文件–字段＃001中的注释 (Transaction Log Full – Transaction Log Larger than Data File – Notes from the Field #001)

As every active SQL Server database is constantly performing some kind of operation, its transaction log is always getting bigger. Tim Radney points out the most common error a database administrators can make: having a database in full recovery mode without regular transaction log backups. If that is the case, the transaction log will eventually fill up the whole data storage space. In “Transaction Log Full – Transaction Log Larger than Data File – Notes from the Field #001”, Tim suggests using the DBCC SHRINKFILE function and switching the database into the simple recovery mode

由于每个活动SQL Server数据库都在不断执行某种操作，因此它的事务日志总是越来越大。 蒂姆·拉德尼（Tim Radney）指出了数据库管理员可能犯的最常见错误：使数据库处于完全恢复模式，而没有常规的事务日志备份。 如果真是这样，事务日志最终将填满整个数据存储空间。 在“事务日志已满-事务日志大于数据文件-字段＃001的注释”中 ，Tim建议使用DBCC SHRINKFILE函数并将数据库切换为简单恢复模式

多个日志文件以及它们为什么不好 (Multiple log files and why they’re bad)

In “Multiple log files and why they’re bad”, Paul S. Randal presents the statistical data collected from 1,300 SQL Server instances regarding the number of transaction logs per database. If there are multiple transaction logs present that implies that the first one is large and it’s run out of space (more than 2TB). Paul points out the importance of proper transaction log file size management and suggests usage of Log Growths counter the Databases performance object

在“多个日志文件及其坏处”中 ， Paul S. Randal展示了从1300个SQL Server实例收集的有关每个数据库的事务日志数量的统计数据。 如果存在多个事务日志，则表明第一个事务日志很大且空间不足（超过2TB）。 Paul指出了适当的事务日志文件大小管理的重要性，并建议使用Log Growths来抵消Databases性能对象

事务日志的麻烦 (The Trouble with Transaction Log)

Based on experience, Thomas Larock claims that majority of transaction logs are in the bad shape. The default settings when creating a database in SQL Server is the model template, with characteristic to auto-grow by 10 percent to a maximum of 2 terabytes. The number of Virtual log files (VFLs) is depending on the initial or extended size of the transaction log:

根据经验， 托马斯·拉洛克 （ Thomas Larock）声称大多数交易日志的状况都不好。 在SQL Server中创建数据库时的默认设置是模型模板，其特征是自动增长10％，最大增长2 TB。 虚拟日志文件（VFL）的数量取决于事务日志的初始大小或扩展大小：

Credit and copyright: Thomas Larock and Kimberly Tripp

版权和版权：Thomas Larock和Kimberly Tripp

In the article, “The Trouble with Transaction Log”, there is code that will show the maximum number of Virtual log files (VLFs) for a log file that is set to grow by defaults. Also, there is a recommendation that Virtual log file should be 512MB as a starting point

在“事务日志的问题”一文中 ，有代码将显示默认情况下会增长的日志文件的最大虚拟日志文件（VLF）数量。 另外，建议虚拟日志文件应以512MB为起点

未公开记录的功能– fn_dblog (Undocumented function – fn_dblog)

Like the DBCC LOGINFO command, the fn_dblog function is undocumented officially too. In “Undocumented function – fn_dblog”, Muhammad Imran explains syntax and gives an example of code to execute. There is a useful script which converts a hexadecimal Log sequence number (LSN) to an integer Log sequence number which can only then be used as a parameter in the fn_dblog function

像DBCC LOGINFO命令一样，fn_dblog函数也未正式记录。 Muhammad Imran在“未公开的函数– fn_dblog”中解释了语法，并提供了要执行的代码示例。 有一个有用的脚本可以将十六进制的Log序列号（LSN）转换为整数Log序列号，然后才可以将其用作fn_dblog函数中的参数

交易日志神话 (Transaction log myths)

In “Transaction log myths”, Vedran Kesegić talks about popular transaction log myths. Transaction log truncation will not make a transaction log smaller, transaction log records are not written to the data storage immediately, transaction log shrinking is not a good practice, a transaction log will grow if its database is in the simple recovery model etc.

VedranKesegić在“交易日志神话”中谈到了流行的交易日志神话。 事务日志截断不会使事务日志变小，事务日志记录不会立即写入数据存储中，事务日志收缩不是一个好习惯，如果其数据库处于简单恢复模型中，则事务日志会增长。

sp_BlitzTM结果：事务日志太大？ (sp_BlitzTM Result: Transaction Log Too Large?)

sp_BlitzTM is a stored procedure by Brent Ozar Unlimited which determinates the “health” of SQL Server. It’s stored in the temporary TempDB database. After running the stored procedure it shows whether the transaction log is larger than the data itself which indicate that transaction log backups are not being performed or not being performed often enough. In “sp_Blitz Result: Transaction Log Too Large?”, there is a guide and recommendation how to deal with the problem

sp_BlitzTM是Brent Ozar Unlimited的存储过程，它确定SQL Server的“运行状况”。 它存储在临时TempDB数据库中。 运行存储过程后，它会显示事务日志是否大于数据本身，这表明事务日志备份没有执行或没有足够频繁地执行。 在“ sp_Blitz结果：事务日志太大？”中 ，有一个指南和建议如何处理该问题

关于SQL Server中的事务日志及其截断 (About transaction log and its truncation in SQL Server)

In “About transaction log and its truncation in SQL Server”, Mika Wendelius explains how the transaction log file content is categorized into three different categories:

Mika Wendelius在“关于SQL Server中的事务日志及其截断”中 ，介绍了如何将事务日志文件的内容分为三类：

• Used portion – this contains log records that are written to the transaction log but can be removed已用部分–包含已写入事务日志但可以删除的日志记录
• Active portion – this is the part of the transaction log which is defined by the oldest active transaction. This information cannot be removed while the transaction is still active活动部分–这是事务日志中由最早的活动事务定义的部分。 事务仍处于活动状态时，无法删除此信息
• Unused portion – this is empty space [2]未使用的部分–这是空白[2]

In the second part, Mika provides step by step instruction for resolving the situation when a transaction log is full

在第二部分中，Mika提供了逐步说明，以解决事务日志已满时的情况

使用事务日志还原SQL Server数据库 (Restore your SQL Server database using transaction logs)

In “Restore your SQL Server database using transaction logs”, Tim Chapman gives a scenario for recovering a SQL Server database using a transaction log. He points out how important the backup plan is and why all the backups should be tested more than once

在“使用事务日志还原SQL Server数据库”中 ， Tim Chapman给出了一种使用事务日志还原SQL Server数据库的方案。 他指出了备份计划的重要性，以及为什么所有备份都应进行多次测试

翻译自: https://www.sqlshack.com/top-10-articles-sql-server-transaction-log/