介绍 (Introduction)

There has always been some debate as to whether or not there are real benefits to be gained from accessing the information in the transaction log. This article will endeavor to answer that question by looking at the following:

关于访问事务日志中的信息是否会带来真正的好处，一直存在争议。 本文将通过查看以下内容来努力回答该问题：

• What is the SQL Server Transaction Log?什么是SQL Server事务日志？
• What information is stored in the transaction log?事务日志中存储什么信息？
• What can be gained by accessing the information in the transaction log?通过访问事务日志中的信息可以获得什么？
• How does the transaction log work?事务日志如何工作？
• What tools are available for reading the transaction log?哪些工具可用于读取事务日志？
• And ultimately, is this something we should be doing at all?最终，这是我们应该做的吗？

什么是SQL Server事务日志？ (What is the SQL Server Transaction Log?)

The main purpose of the SQL Server Transaction Log is to ensure that your database can be brought back to a consistent state in case of a system failure. In addition, it is used to perform other functions such as rollbacks when a rollback command is issued and supporting transactional replication and high availability solutions.

SQL Server事务日志的主要目的是确保在系统出现故障时可以将数据库恢复到一致状态。 此外，它还用于执行其他功能，例如在发出回滚命令时回滚，并支持事务复制和高可用性解决方案。

SQL Server logs information about each and every transaction made, into the transaction log before the changes are written to the database. The amount of information logged depends on the recovery model of your database. SQL Server offers 3 different recovery models: Full, Bulk Logged and Simple.

在将更改写入数据库之前，SQL Server将有关每个事务的信息记录到事务日志中。 记录的信息量取决于数据库的恢复模型。 SQL Server提供了3种不同的恢复模型：完整，批量记录和简单。

恢复模型 (Recovery Models)

FULL recovery model完整恢复模式

BULK_LOGGED recovery modelBULK_LOGGED恢复模型

SIMPLE recovery model简单的恢复模型

事务日志中记录了什么？ (What is logged in the transaction log?)

SQL Server logs every event in a database to a more or lesser extent.

SQL Server或多或少地将每个事件记录在数据库中。

• When a transaction begins or ends交易开始或结束时
• Every update , insert or delete每次更新，插入或删除
• Drop and creation of tables and indexes删除和创建表和索引
• Extent and page allocations and de-allocations范围和页面分配与取消分配
• Truncation of tables截断表
• All locks所有锁

Some operations may be minimally logged when the database is in simple or bulk logged recovery model, such as bcp, BULK INSERT, SELECT INTO and SELECT … INSERT command.

当数据库处于简单或批量记录的恢复模型时，某些操作的记录可能最少，例如bcp，BULK INSERT，SELECT INTO和SELECT…INSERT命令。

阅读事务日志可以得到什么？ (What can be gained from reading the Transaction Log?)

There are four main reasons why one might be interested in reading the transaction log.

为什么可能有兴趣阅读事务日志的主要原因有四个。

审计\取证 (Auditing \ Forensics)

SQL Server offers a myriad of methods which can be implemented as preventative measures to circumvent the need to use the SQL Server transaction log to audit a database. This includes SQL Server Auditing (SQL 2008 +), traces and extended events, change data capture to name but a few. Most of these with the exception of the default trace, requires implementation prior to any event occurring.

SQL Server提供了许多方法，这些方法可以作为预防措施来实现，从而避免了使用SQL Server事务日志来审核数据库的需求。 这包括SQL Server审核（SQL 2008 +），跟踪和扩展事件，将数据捕获更改为仅举几例。 除默认跟踪外，其中大多数都需要在任何事件发生之前实施。

The SQL Server transaction log however, is always present and as such can offer valuable information after an event occurred despite the fact that no special advanced configuration has been done.

但是，SQL Server事务日志始终存在，因此即使没有进行任何特殊的高级配置，事件发生后也可以提供有价值的信息。

In the absence of all preventative measures, being able to read the SQL Server Transaction log offers the ability to find out who performed a specific transaction after the fact, as well as the ability to obtain the values which have been modified with the option to roll them back.

在没有所有预防措施的情况下，能够读取SQL Server事务日志提供了在事发后找出谁执行了特定事务的能力，以及获得使用roll选项进行修改的值的能力。他们回来。

复苏 (Recovery)

Because every action is logged in the transaction log in such a way that a transaction may be either rolled forward or rolled back, the SQL Server transaction log may be used to recover lost data. Since only changes are logged and data in the log is not stored in a human readable format, getting this information out of the log is not easy, but the data is none the less available if you know where to look and how to read it. More about that later in this article in the section on interpreting the data in fn_dblog and fn_dump_dblog.

因为每个操作都以可以向前或向后回滚事务的方式记录在事务日志中，所以可以使用SQL Server事务日志来恢复丢失的数据。 由于仅记录更改，并且日志中的数据不是以人类可读的格式存储的，因此从日志中获取此信息并不容易，但是如果您知道在哪里查看和阅读方法，那么仍然可以获取数据。 在本文后面的有关解释fn_dblog和fn_dump_dblog中的数据的部分中，将对此进行更多介绍。

故障排除 (Troubleshooting)

In certain instances being able to see what exactly happened in a database for a specific period of time is necessary. Let’s say that your database size has grown inexplicably large during the course of the night. It would be impossible to say just by looking at the data what the reason behind this might be. However reading the transaction log will give you exact information about what occurred during the specific period which might have resulted in the rapid growth of your database.

在某些情况下，必须能够看到特定时间段内数据库中到底发生了什么。 假设您的数据库大小在夜间变得无法解释。 仅通过查看数据就无法说出其背后的原因是什么。 但是，阅读事务日志将为您提供有关在特定时期内发生的事情的确切信息，这可能导致数据库的快速增长。

识别还原点 (Identifying a restore point)

Last but not least, when it comes to having to restore a backup, knowing the exact point in time to which the database can be restored to get the lost or damaged data back is a huge advantage. Instead of restoring multiple backups until you find one which still has the relevant data intact, you can read the transaction log to determine when the event occurred and restore to the precise moment right before the event occurred.

最后但并非最不重要的一点是，在必须还原备份时，知道可以将数据库还原到正确的时间点以恢复丢失或损坏的数据是一个巨大的优势。 您可以读取事务日志以确定事件发生的时间，并还原到事件发生之前的确切时刻，而不是还原多个备份直到找到仍然完整的相关数据。

Microsoft应该提供日志读取器工具吗？ (Should Microsoft provide a log reader tool?)

There has been some debate as to whether or not Microsoft should provide a log reader tool. Both Kalen Delaney and Paul Randal agrees that there are useful applications of such a tool but that Microsoft should be focusing on more critical things and leave the log reading tools to third party vendor’s who have mastered the art of reading the log.

关于Microsoft是否应提供日志读取器工具一直存在争议。 Kalen Delaney和Paul Randal都同意这种工具的有用应用，但是Microsoft应该把重点放在更关键的事情上，而将日志读取工具留给掌握了读取日志技巧的第三方供应商使用。

SQL Server事务日志的剖析 (Anatomy of the SQL Server Transaction Log)

The SQL Server transaction log is a single file which usually has an .LDF file extension. Although possible to have multiple log files for a database, the transaction log is always written sequentially and multiple physical log files get treated as one continuous circular file.

SQL Server事务日志是一个文件，通常具有.LDF文件扩展名。 尽管可能有一个数据库的多个日志文件，但事务日志始终按顺序写入，并且多个物理日志文件被视为一个连续的循环文件。

SQL Server uses the transaction log to ensure that all transactions maintain their state even in case of a server or database failure. All transactions are written to the Transaction Log before it is written to the data files. This is known as write ahead logging.

SQL Server使用事务日志来确保所有事务即使在服务器或数据库出现故障的情况下也能保持其状态。 在将所有事务写入数据文件之前，都将其写入事务日志。 这称为预写日志记录 。

Every action performed on SQL Server is logged in the SQL Server transaction log, multiple entries may be created for a transaction as well as all locks that were taken during the operation. Each log entry has a unique number known as the LSN (log sequence number).

在SQL Server上执行的每个操作都记录在SQL Server事务日志中，可以为一个事务创建多个条目，以及在操作期间采取的所有锁定。 每个日志条目都有一个唯一的编号，称为LSN（日志序列号）。

Enough information is written to the log to allow for a transaction to be either re-done (rolled forward) or undone (rolled back). In some cases this means that the actual change gets logged, in other instances changes may be logged efficiently by just logging the pages which have been changed as in the case of a table truncation.

将足够的信息写入日志，以允许重新执行事务（前滚）或取消事务（后滚）。 在某些情况下，这意味着会记录实际的更改，而在其他情况下，只需记录已更改的页面（如表截断的情况），就可以有效地记录更改。

Logically the SQL Server Transaction log is divided into multiple sections known as virtual log files or VLFs. The logical transaction log gets truncated and expanded in units of VLFs. If a VLF no longer contains an active transaction, that VLF can be marked for re-use. If the log needs more space, space is allocated in increments of VLFs. The number and size of the VLFs is decided by the database engine and it will endeavor to assign as few VLFs as possible. Although the size and number of VLFs cannot be configured, it is affected by the initial size and the growth increment of the transaction log. If the log growth increment is set too low, it may result in an excessive amount of VLFs which can have an adverse effect on performance. In order to avoid this, it is important to size the log correctly and grow it in sufficiently large increments.

从逻辑上讲，SQL Server事务日志分为多个部分，称为虚拟日志文件或VLF。 逻辑事务日志将被截断并以VLF为单位进行扩展。 如果VLF不再包含活动事务，则可以将该VLF标记为可重复使用。 如果日志需要更多空间，则以VLF为增量分配空间。 VLF的数量和大小由数据库引擎决定，它将努力分配尽可能少的VLF。 尽管无法配置VLF的大小和数量，但是它受事务日志的初始大小和增长增量的影响。 如果将日志增长增量设置得太低，则可能导致过多的VLF，这可能会对性能产生不利影响。 为了避免这种情况，正确设置日志大小并以足够大的增量增长日志非常重要。

The following command can be executed to see how many virtual log files there are, how many has been used and what their sizes are. This will be used to determine what the correct size and increment should be.

可以执行以下命令来查看有多少个虚拟日志文件，已使用了多少个虚拟日志文件以及它们的大小。 这将用于确定正确的大小和增量。

DBCC LOGINFO

This procedure returns the following columns:

此过程返回以下列：

Column	Description
RecoveryUnitID
FileID	This is the identification number of the physical log file. It only applies if you have more than one physical log file.
FileSize	The size of the file in bytes
StartOffset	This is the offset of where the VLF starts in bytes. The output is sorted on this column.
FSeqNo	This is the order in which the VLF will be used. The largest number is the one which is currently being used.
Status	There are 2 possible values 0 and 2. 2 means that the VLF cannot be reused and 0 means that it is ready for re-use.
Parity	There are 2 possible values 64 and 128.
CreateLSN	This is the LSN when the VLF was created. If the createLSN is 0, it means it was created when the physical transaction log file was created.

柱	描述
RecoveryUnitID
文件ID	这是物理日志文件的标识号。 仅当您有多个物理日志文件时才适用。
文件大小	文件大小（以字节为单位）
StartOffset	这是VLF起始位置的偏移量（以字节为单位）。 输出在此列上排序。
FSeq否	这是使用VLF的顺序。 最大数量是当前正在使用的数量。
状态	有2个可能的值0和2。2表示VLF无法重用，0表示已准备好重用。
平价	有2个可能的值64和128。
创建LSN	创建VLF时的LSN。 如果createLSN为0，则表示它是在创建物理事务日志文件时创建的。

读取SQL Server事务日志 (Reading the SQL Server Transaction Log)

Even though Microsoft does not provide a tool, there are some undocumented functions which may be used to view the log. Because these procedures are undocumented, they are also not supported by Microsoft and as such comes with the warning of “Use at your own risk”. There has been some reports that fn_db_dumplog creates a hidden OS scheduler and some threads which apparently remains on the server until it is restarted. According to Paul Randal, Microsoft’s SQL Team is aware of this and will fix it sometime in the future.

即使Microsoft不提供工具，也可以使用一些未记录的功能来查看日志。 因为这些过程没有文档记录，所以Microsoft也不支持这些过程，因此带有“使用后果自负”的警告。 有报告称fn_db_dumplog创建了一个隐藏的OS调度程序，并且某些线程显然保留在服务器上，直到重新启动为止。 根据Paul Randal的说法，MicrosoftSQL团队已意识到这一点，并将在将来的某个时间对其进行修复。

fn_dblog（） (fn_dblog())

This table-valued function (which was DBCC Log prior to SQL Server 2005) allows you to view the entries in online transaction log. This procedure accepts 2 parameters, the start and the end LSN. To see all available entries NULL can be passed for both parameters, and all the entries in the active portion of the online log will be displayed.

此表值函数（SQL Server 2005之前是DBCC日志）使您可以查看联机事务日志中的条目。 该过程接受2个参数，开始和结束LSN。 要查看所有可用条目，可以为两个参数传递NULL，并且将显示在线日志活动部分中的所有条目。

SELECT * FROM fn_dblog(NULL,NULL)

fn_dump_dblog（） (fn_dump_dblog())

This function reads both the online log and log backups and accepts 68 parameters. All the parameters need to be specified in order to execute the statement.

该功能读取在线日志和日志备份，并接受68个参数。 需要指定所有参数才能执行该语句。

SELECT  * FROM fn_dump_dblog(NULL,NULL,'DISK',1
,'D:\Program Files\Microsoft SQL Server\MSSQL11.MSSQLSERVER\MSSQL\Backup\AdventureWorks2012.bak'
,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL,NULL
,NULL,NULL,NULL,NULL,   NULL,NULL,NULL,NULL,NULL,NULL
,NULL,NULL,NULL,NULL,   NULL,NULL,NULL,NULL,NULL,NULL
,NULL,NULL,NULL,NULL,   NULL,NULL,NULL,NULL,NULL,NULL
,NULL,NULL,NULL,NULL,   NULL,NULL,NULL,NULL,NULL,NULL
,NULL,NULL,NULL,NULL,   NULL,NULL,NULL,NULL,NULL,NULL
,NULL,NULL,NULL,NULL)

Parameter	Description
@start	The start LSN
@end	The end LSN
@devtype	This is the backup device type. The default value is DISK. Other valid values are NULL(DISK) | DISK | TAPE | VIRTUAL_DEVICE
@seqnum	This indicates which backup to read from a backup device if there is more than one backup in a backup file. The default value is 1.
@fname1	This parameter accepts the path to the backupfile.
@fname2 to @fname64	These parameters are used to specify additional backup files, if the media set has multiple media families.

P 上的 R A M E T E [R	d（E S）C R I P T I O 4 N
@ 式 T 一 室温	开始LSN
@ en d	结束LSN
@ dev的 吨 ÿpë	这是备份设备类型。 默认值为DISK。 其他有效值为NULL（DISK）| 磁盘 胶带 VIRTUAL_DEVICE
@ 小号 公式 U m 的	如果备份文件中有多个备份，则这指示从备份设备读取哪个备份。 预设值是1。
@f N A M E 1	此参数接受备份文件的路径。
@f N A M E 2 ŤØ @ F 2 N 一 M E 6 4	如果介质集具有多个介质系列，则这些参数用于指定其他备份文件。

解释fn_dblog和fn_dump_dblog中的数据 (Interpreting the data in fn_dblog and fn_dump_dblog)

Now that we have seen how we may be able to view the information in the SQL Server Transaction Log, let’s have a look at how it is presented and how we can make sense of it.

现在，我们已经了解了如何在SQL Server事务日志中查看信息，下面让我们看一下如何显示信息以及如何理解信息。

This is an incredibly complicated subject, details of which are really beyond the scope of this article, but in order to understand the value of using a log reader tool, it is necessary to have a basic idea of what it would take to interpret the data in the log without the help of a tool.

这是一个非常复杂的主题，其细节确实超出了本文的范围，但是为了理解使用日志读取器工具的价值，有必要对解释数据有一个基本的了解在没有工具帮助下的日志中。

The sequence of operations is indicated by the LSN (log sequence number) , but since multiple operations can happen simultaneously , all the entries linked to a specific transaction may not appear in sequence, so it is important to also look at the Transaction ID to know which log entries correspond to which transaction.

操作序列由LSN（日志序列号）指示，但是由于可以同时发生多个操作，因此链接到特定事务​​的所有条目可能不会按顺序出现，因此同样重要的是要查看事务ID以了解哪些日志条目对应于哪个事务。

Let’s insert one row in a simple table named [dbo.attribute] and see what happened in the log.

让我们在名为[dbo.attribute]的简单表中插入一行，然后查看日志中发生了什么。

INSERT INTO dbo.attribute VALUES ('Red')

In this query I am only looking at entries which has the same transaction ID as the INSERT.

在此查询中，我仅查看具有与INSERT相同的事务ID的条目。

SELECT[Transaction ID], [Current LSN], [Transaction Name], [Operation],  [Context],[AllocUnitName],[Begin Time],[End Time], [Transaction SID],[Num Elements] ,[RowLog Contents 0],[RowLog Contents 1],[RowLog Contents 2],[RowLog Contents 3]FROM fn_dblog (NULL, NULL)WHERE [Transaction ID] = (Select [Transaction ID] FROM fn_dblog (null,null) WHERE
[Transaction Name] = 'INSERT')GO

Notice that the first entry is an LOP_BEGIN_XACT operation. This indicates the start of any transaction and shows the start time. Similarly, the last entry is a LOP_COMMIT_XACT operation which displays the end time of the transaction.

请注意，第一个条目是LOP_BEGIN_XACT操作。 这指示任何事务的开始并显示开始时间。 同样，最后一个条目是LOP_COMMIT_XACT操作，它显示事务的结束时间。

The second row indicates that a lock operation was done (LOP_LOCK_XACT). If you want to see more information about the lock, you can check out the [Lock Information] column.

第二行表示已完成锁定操作（LOP_LOCK_XACT）。 如果您想查看有关锁的更多信息，可以查看[Lock Information]列。

The third row is where it starts to get really interesting. This is the entry in which we will be able to find the actual data which was inserted in the table. The data values are stored in the RowLog Contents columns. There are 6 RowLog Contents columns. To know which of these columns are relevant to the transaction at hand, we can check the [Num Elements] column.

第三行开始变得非常有趣。 这是我们可以在其中找到表中插入的实际数据的条目。 数据值存储在RowLog目录列中。 有6个“行日志内容”列。 要知道这些列中的哪列与手头交易相关，我们可以检查[Num Elements]列。

In this particular case there are 3 elements, which means we should only look at the values present in [RowLog Contents 0], [RowLog Contents 1] and [RowLog Contents 2]. As you can see, it’s not obvious by just looking at the data in these fields to know what was actually inserted. In order to know what the values were, we will actually have to deconstruct each entry.

在此特定情况下，有3个元素，这意味着我们只应查看[RowLog目录0]，[RowLog目录1]和[RowLog目录2]中的值。 如您所见，仅查看这些字段中的数据以了解实际插入的内容并不太明显。 为了知道这些值是什么，我们实际上必须解构每个条目。

The data in RowLog Contents 0 is:

RowLog目录0中的数据为：

0x300008000100000002000001001200526564

0x3000080001000000020002000001001200526564

Which can be broken down like this:

可以这样分解：

30	Status bit A
00	Status bit B

30	状态位A
00	状态位B

0800	Offset to find the number of columns in the row.
01000000	Data of fixed length col = 1
0200	Number of columns
00	Null bitmap
0100	Number of variable length columns
1200	Position where first variable length column ends, this is byte swapped which is 0x0012 which translates to 18.
526564	Data in variable length column = Red

0800	偏移量以查找行中的列数。
01000000	固定长度col的数据= 1
0200	列数
00	空位图
0100	可变长度列数
1200	第一个可变长列结束的位置，此字节交换为0x0012，转换为18。
526564	可变长度列中的数据=红色

The actual inserted value can be extracted from the log. Now let’s have a look at what happens when we update an entry. I’m going to change the value ‘Red’ to Rad.

可以从日志中提取实际插入的值。 现在让我们看看更新条目时会发生什么。 我将值“ Red”更改为Rad。

UPDATE dbo.attribute SET name_e = 'Rad' WHERE id = 1

Let’s have a look at what was logged now.

让我们看一下现在记录的内容。

SELECT[Transaction ID], [Current LSN], [Transaction Name], [Operation], [Context],[RowLog Contents 0],[RowLog Contents 1]FROM fn_dblog (NULL, NULL)WHERE [Transaction ID] = (Select [Transaction ID] FROM fn_dblog(null,null) WHERE
[Transaction Name] =   'UPDATE')GO

Notice the values in RowLog Contents 0 and RowLog Contents 1. If we convert this to varchar we will see that SQL Server only logged the actual change. RowLog Contents 0 holds the before value and RowLog Contents 1 holds the after value.

请注意RowLog目录0和RowLog目录1中的值。如果将其转换为varchar，我们将看到SQL Server仅记录了实际更改。 RowLog目录0保留前值，RowLog目录1保留后值。

SELECT   CAST(0x65 AS VARCHAR)
SELECT  CAST(0x61 AS VARCHAR)

In this case the only change was that the ‘e’ changed to ‘a’. In order to obtain the before value of a field which has been updated from the log, you would have to know what the inserted value was before it was changed as well as all subsequent changes. In order to do this a full log chain is required, and of course a lot of effort to decode all of it.

在这种情况下，唯一的变化是将“ e”更改为“ a”。 为了获得已从日志更新的字段的before值，您将必须知道插入的值在更改之前是什么以及所有后续更改。 为了做到这一点，需要完整的日志链，当然要花费很多精力才能对所有日志链进行解码。

使用日志阅读器工具的优点 (Advantages of using a log reader tool)

Due to the difficulty involved in reading the output of fn_dblog and fn_dump_dblog, having a tool which can do it for you is essential. Log reader tools do not have to be implemented in advance, since it solely depends on the availability of the SQL Server Transaction log. It can be installed after an unexpected event has occurred, providing the best possible chance of either tracking down the culprit or recovering the lost or damaged data.

由于读取fn_dblog和fn_dump_dblog的输出时会遇到困难，因此拥有一个可以为您完成此工作的工具至关重要。 日志读取器工具不必事先实现，因为它仅取决于SQL Server事务日志的可用性。 可以在发生意外事件后进行安装，以提供最大的机会来追查罪魁祸首或恢复丢失或损坏的数据。

结论 (Conclusion)

Reading the transaction log offers the ability to audit and investigate database activity after the fact. The format in which the SQL Server transaction log is written requires careful decoding of each item to understand which values have been affected. Microsoft does not provide any log reader tools aside from 2 functions which reads and displays but does not decode the log data.

读取事务日志后，便可以审计和调查数据库活动。 编写SQL Server事务日志的格式要求仔细解码每个项目，以了解哪些值受到了影响。 除2个功能之外，Microsoft不提供任何日志读取器工具，该工具可以读取和显示但不对日志数据进行解码。

When it comes to investigating an unexpected event after the fact, reading the transaction log is the only option. As long as databases are managed and operated by humans. There will always be a need to be able to read the SQL Server transaction log.

当事后调查意外事件时，读取事务日志是唯一的选择。 只要数据库是由人管理和操作的。 始终需要能够读取SQL Server事务日志。

翻译自: https://www.sqlshack.com/reading-sql-server-transaction-log/