适用于：
SQL Server
每个 SQL Server 数据库都有事务日志，用于记录所有事务以及每个事务所做的数据库修改。
事务日志是数据库的一个关键组件。 如果系统出现故障，则需要此日志才能使数据库恢复一致状态。
警告
永远不要删除或移动此日志，除非你完全了解执行此操作的后果。
有关事务日志的物理和逻辑体系结构的信息，请参阅 SQL Server 事务日志体系结构和管理指南。
提示
检查点创建已知良好的点，从中开始在数据库恢复期间应用事务日志。 有关详细信息，请参阅数据库检查点 (SQL Server)。
事务日志支持的操作
事务日志支持以下操作：
- 恢复个别的事务。
- SQL Server 启动时恢复所有未完成的事务。
- 将还原的数据库、文件、文件组或页前滚至故障点。
- 支持事务复制。
- 支持高可用性和灾难恢复解决方案：AlwaysOn 可用性组、数据库镜像和日志传送。
恢复个别的事务
如果应用程序发出 ROLLBACK 语句，或者数据库引擎检测到错误（例如失去与客户端的通信），使用日志记录回退未完成的事务所做的修改。
SQL Server 启动时恢复所有未完成的事务
当服务器发生故障时，数据库可能处于这样的状态：还没有将某些修改从缓存写入数据文件，在数据文件内有未完成的事务所做的修改。 启动 SQL Server 实例时，它将对每个数据库执行恢复操作。 前滚日志中记录的、可能尚未写入数据文件的每个修改。 在事务日志中找到的每个未完成的事务都将回滚，以确保数据库的完整性。 有关详细信息，请参阅还原和恢复概述（SQL Server）。
将还原的数据库、文件、文件组或页前滚至故障点
在硬件丢失或磁盘故障影响到数据库文件后，可以将数据库还原到故障点。 先还原上次完整数据库备份和上次差异数据库备份，然后将后续的事务日志备份序列还原到故障点。
还原每个日志备份时，数据库引擎将重新应用日志中记录的所有修改，前滚所有事务。 最后的日志备份还原后，数据库引擎将使用日志信息回退到该点上未完成的所有事务。 有关详细信息，请参阅还原和恢复概述（SQL Server）。
支持事务复制
日志读取器代理程序监视已为事务复制配置的每个数据库的事务日志，并将已设复制标记的事务从事务日志复制到分发数据库中。 有关详细信息，请参阅 事务复制的工作原理。
支持高可用性和灾难恢复解决方案
备用服务器解决方案、AlwaysOn 可用性组、数据库镜像和日志传送极大程度上依赖于事务日志。
在“Always On 可用性组应用场景”中，主要副本上数据库的每个更新在所有次要副本上数据库的独立副本中直接再现。 主要副本直接将每个日志记录发送到次要副本，这可将传入日志记录应用到可用性数据库，并将日志不断前滚。 有关详细信息，请参阅 Always On 故障转移群集实例 (SQL Server)。
在日志传送方案中，主服务器将主数据库的事务日志备份发送到一个或多个目标服务器。 每个辅助服务器将该日志备份还原为其本地的辅助数据库。 有关详细信息，请参阅关于日志传送 (SQL Server)。
在数据库镜像方案中，数据库（主体数据库）的每次更新都在独立的、完整的数据库（镜像数据库）副本中立即重新生成。 主体服务器实例立即将每个日志记录发送到镜像服务器实例，镜像服务器实例将传入的日志记录应用于镜像数据库，从而将其继续前滚。 有关详细信息，请参阅数据库镜像（SQL Server）。
事务日志特征
SQL Server 数据库引擎事务日志的特征：
事务日志是作为数据库中的单独的文件或一组文件实现的。 日志缓存独立于数据页的缓冲区缓存进行管理。 这种分离会导致 SQL Server 数据库引擎中的简单、快速且可靠的代码。 有关详细信息，请参阅 事务日志物理体系结构。
日志记录和页的格式不必遵守数据页的格式。
事务日志可以在几个文件上实现。 可以通过设置
FILEGROWTH日志的值，将文件配置为自动展开。 此配置减少了事务日志中空间不足的可能性，同时减少了管理开销。 有关详细信息，请参阅 ALTER DATABASE （Transact-SQL） 文件和文件组选项。重用日志文件中空间的机制速度快且对事务吞吐量影响最小。
有关事务日志的物理和逻辑体系结构的信息，请参阅 SQL Server 事务日志体系结构和管理指南。
事务日志截断
日志截断将释放日志文件的空间，以便由事务日志重新使用。 必须定期截断事务日志，防止占满分配的空间。 几个因素可能延迟日志截断，因此监视日志大小很重要。 可以尽量减少记录某些作，以减少它们对事务日志大小的影响。
日志截断从 SQL Server 数据库的逻辑事务日志中删除非活动 虚拟日志文件（VFS）， 释放逻辑日志中的空间供物理事务日志重复使用。 如果事务日志从不截断，它最终将填满分配给物理日志文件的所有磁盘空间。
为了避免空间不足，除非由于某些原因延迟日志截断，否则将在以下事件后自动进行截断：
简单恢复模式下，在检查点之后发生。
在完整恢复模式或大容量日志恢复模式下，如果自上一次备份后生成检查点，则在日志备份后进行截断（除非是仅复制日志备份）。
首次创建使用完整恢复模式的数据库时，事务日志会根据需要重复使用（类似于使用简单恢复模式的数据库），直到创建完整数据库备份为止。
有关详细信息，请参阅本文后面的 可延迟日志截断的因素 。
日志截断不会减小物理日志文件的大小。 若要减少物理日志文件的物理大小，则必须收缩日志文件。 有关收缩物理日志文件大小的信息，请参阅管理事务日志文件的大小。 但是，请记住 可能会延迟日志截断的因素。 如果在日志收缩后再次需要存储空间，事务日志将再次增长，并通过执行此作，在日志增长作期间引入性能开销。
可能延迟日志截断的因素
当日志记录长时间保持活动状态时，事务日志截断会延迟，事务日志可以填满，如本文前面所述。
重要
有关如何响应完整事务日志的信息，请参阅排查完整事务日志问题（SQL Server 错误 9002）。
日志截断可能会因各种原因而延迟。 若要了解阻止日志截断的内容，请查询 log_reuse_wait 目录视图的 log_reuse_wait_desc 和 列。 下表对这些列的值进行了说明。
| log_reuse_wait 值 | log_reuse_wait_desc 值 | 说明 |
|---|---|---|
0 |
NOTHING |
目前有一个或多个可重用的虚拟日志文件（VFS）。 |
1 |
CHECKPOINT |
自上次日志截断以来没有发生检查点，或者日志的头尚未移到 虚拟日志文件（VLF）之外。 （所有恢复模式。 此方案是延迟日志截断的例程原因。 有关详细信息，请参阅数据库检查点 (SQL Server)。 |
2 |
LOG_BACKUP |
在截断事务日志前，需要进行日志备份。 （仅限完整或大容量日志恢复模式。） 完成下一个日志备份后，一些日志空间可能变为可重复使用。 |
3 |
ACTIVE_BACKUP_OR_RESTORE |
数据备份或还原正在进行中。 （所有恢复模式。 如果数据备份阻止了日志截断，则取消备份操作可能有助于解决备份直接导致的此问题。 |
4 |
ACTIVE_TRANSACTION |
事务处于活动状态（所有恢复模式）： 一个长时间运行的事务可能存在于日志备份的开头。 在这种情况下，可能需要进行另一个日志备份才能释放空间。 长时间运行的事务将阻止所有恢复模式下的日志截断，包括简单恢复模式，在该模式下事务日志一般在每个自动检查点截断。 延迟事务。 “延迟的事务 ”是有效的活动事务，因为某些资源不可用，其回滚受阻。 有关延迟事务的原因以及如何将其移出延迟状态的信息，请参阅延迟事务（SQL Server）。 长期事务也可能会填满 tempdb 的事务日志。
tempdb 由用户事务隐式用于内部对象，例如用于排序的工作表、用于哈希的工作文件、游标工作表，以及行版本控制。 即使用户事务只包括读取数据（SELECT 查询），也可能在用户事务下创建和使用内部对象。 然后可以填充 tempdb 事务日志。 |
5 |
DATABASE_MIRRORING |
数据库镜像暂停，或者在高性能模式下，镜像数据库明显滞后于主体数据库。 （仅限完全恢复模式）。） 有关详细信息，请参阅数据库镜像（SQL Server）。 |
6 |
REPLICATION |
在事务复制过程中，与发布相关的事务仍未传递到分发数据库。 （仅限完全恢复模式）。） 有关事务复制的信息，请参阅 SQL Server 复制。 |
7 |
DATABASE_SNAPSHOT_CREATION |
正在创建数据库快照。 （所有恢复模式。 这是日志截断延迟的常见原因，通常也是主要原因。 |
8 |
LOG_SCAN |
发生日志扫描。 （所有恢复模式。 这是日志截断延迟的常见原因，通常也是主要原因。 |
9 |
AVAILABILITY_REPLICA |
可用性组的辅助副本正将此数据库的事务日志记录应用到相应的辅助数据库。 （仅限完全恢复模式）。） 有关详细信息，请参阅什么是 Always On 可用性组？。 |
10 |
- | 仅供内部使用。 |
11 |
- | 仅供内部使用。 |
12 |
- | 仅供内部使用。 |
13 |
OLDEST_PAGE |
如果将数据库配置为使用间接检查点，数据库中最早的页可能比检查点日志序列号 (LSN) 早。 在这种情况下，最早的页面可能会延迟日志截断。 （所有恢复模式。 有关间接检查点的信息，请参阅数据库检查点 (SQL Server)。 |
14 |
OTHER_TRANSIENT |
当前未使用此值。 |
16 |
XTP_CHECKPOINT |
需要执行内存中 OLTP 检查点。 对于内存优化表，当事务日志文件自上次检查点以来大于 1.5 GB 时，会自动执行检查点。 （包括基于磁盘的表和内存优化表。 有关详细信息，请参阅内存优化表的检查点作以及内存优化表的日志记录和检查点过程。 |
可以尽量减少日志量的操作
最小日志记录 只涉及记录恢复事务所需的信息，而无需支持时间点恢复。 本文介绍了在大容量日志 恢复模式下 以最小方式记录的作（以及简单恢复模式下的作，但备份正在运行时除外）。
内存优化表不支持最小日志记录。
在完整 恢复模式下，所有大容量操作都将被完整地记录下来。 但是，可以通过将数据库暂时切换到用于大容量操作的大容量日志恢复模式，最小化一组大容量操作的日志记录。 最小日志记录比完整日志记录更为有效，并在大容量事务期间，降低了大规模大容量操作填满可用的事务日志空间的可能性。 不过，如果在最小日志记录生效时数据库损坏或丢失，则无法将数据库恢复到故障点。
下列操作在完整恢复模式下执行完整日志记录，而在简单和大容量日志恢复模式下按最小方式记录日志：
批量导入操作（bcp、BULK INSERT 和 INSERT）。 有关在何时对批量导入表按最小方式进行记录的详细信息，请参阅在批量导入中按最小方式记录日志的前提条件。
启用事务复制后，
BULK INSERT即使在大容量日志恢复模式下，作也会完全记录。-
启用事务复制后，
SELECT INTO即使在大容量日志恢复模式下，作也会完全记录。 插入或追加新数据时，使用
.WRITE语句中的 子句部分更新到大型值数据类型。 在更新现有值时，不使用最小日志记录。 有关大型值数据类型的详细信息，请参阅数据类型。在“text”、“ntext”和“image”数据类型列中插入或追加新数据时的 WRITETEXT 和 UPDATETEXT 语句。 在更新现有值时，不使用最小日志记录。
警告
WRITETEXT弃用语句UPDATETEXT。 避免在新应用程序中使用它们。如果数据库设置为简单恢复模式或大容量日志恢复模式，则无论作是脱机运行还是联机，都记录了一些索引 DDL作。 记录最少的索引作包括：
CREATE INDEX 操作（包括索引视图）。
ALTER INDEX REBUILD 或
DBCC DBREINDEX操作。索引生成作使用最少的日志记录，但在同时运行备份时可能会延迟。 使用简单或大容量日志恢复模式时，这种延迟是由于最小记录缓冲池页的同步要求造成的。
警告
该
DBCC DBREINDEX语句已弃用。 避免在新应用程序中使用它。DROP INDEX 新堆重新生成（如果适用）。 作期间的
DROP INDEX索引页解除分配始终完全记录。
相关任务
| 任务 | 项目 |
|---|---|
| 管理事务日志 |
管理事务日志文件的大小 排查完整事务日志问题 （SQL Server 错误 9002） |
| 备份事务日志（仅限完整恢复模式） |
备份事务日志 数据库损坏时备份事务日志（SQL Server） |
| 还原事务日志（仅限完整恢复模式） | 还原事务日志备份 （SQL Server） |