每个 SQL Server 数据库都有一个事务日志,用于记录所有事务以及每个事务所做的数据库修改。 事务日志必须定期截断,以防止它被填满。 但是,某些因素可能会延迟日志截断,因此监视日志大小非常重要。 某些操作可以最小化日志记录,以减少它们对事务日志大小的影响。
事务日志是数据库的关键组件,如果系统发生故障,则可能需要事务日志才能使数据库恢复一致状态。 除非完全了解执行此作的后果,否则不应删除或移动事务日志。
注释
检查点创建已知的良好点,这些点是从中开始在数据库恢复期间应用事务日志的地方。 有关详细信息,请参阅数据库检查点 (SQL Server)。
在本主题中:
优点:事务日志支持的操作
事务日志支持以下操作:
恢复单个事务。
启动 SQL Server 时恢复所有不完整的事务。
将还原的数据库、文件、文件组或页面向前滚动到故障点。
支持事务复制。
支持高可用性和灾难恢复解决方案:AlwaysOn 可用性组、数据库镜像和日志传送。
事务日志截断
日志截断操作释放日志文件中的空间,以供事务日志再次使用。 日志截断对于防止日志填充至关重要。 日志截断从 SQL Server 数据库的逻辑事务日志中删除非活动虚拟日志文件,从而释放逻辑日志中的空间供物理事务日志重复使用。 如果事务日志从未被截断,它最终会填满所有分配给其物理日志文件的磁盘空间。
为了避免此问题,除非出于某种原因延迟日志截断,否则截断会在以下事件后自动发生:
在简单恢复模型下,在检查点之后。
在完整恢复模式或大容量日志记录恢复模式下,如果自上一次备份以来发生了检查点,则在日志备份后会进行截断(除非它是仅复制日志备份)。
有关详细信息,请参阅本主题后面的 “延迟日志截断的因素”。
注释
日志截断不会减小物理日志文件的大小。 若要减小物理日志文件的物理大小,需要收缩日志文件。 有关收缩物理日志文件大小的信息,请参阅 “管理事务日志文件的大小”。
可能会延迟日志截断的因素
当日志记录长时间保持活动状态时,事务日志截断会被延迟,这可能会导致事务日志填满。
重要
有关如何响应完整事务日志的信息,请参阅 对完整事务日志(SQL Server 错误 9002)进行故障排除。
日志截断可能会因各种因素而延迟。 可以通过查询 sys.databases 目录视图中的 log_reuse_wait 和 log_reuse_wait_desc 列,来发现是否有任何内容阻止日志截断。 下表描述了这些列的值。
log_reuse_wait 值 | log_reuse_wait_desc描述值 | DESCRIPTION |
---|---|---|
0 | 无 | 目前有一个或多个可重用的虚拟日志文件。 |
1 | 检查站 | 自上次日志截断以来没有发生检查点,或者日志的头尚未移出虚拟日志文件。 (所有恢复模式) 这是日志截断延迟的常见原因。 有关详细信息,请参阅数据库检查点 (SQL Server)。 |
2 | 日志备份 | 在事务日志可以截断之前,需要进行日志备份。 (仅完整恢复模式或大容量日志恢复模式) 完成下一个日志备份后,某些日志空间可能会可重用。 |
3 | 活动备份或恢复 | 数据备份或还原正在进行(所有恢复模式)。 如果数据备份阻止日志截断,取消备份操作可能有助于立即解决问题。 |
4 | ACTIVE_TRANSACTION | 当前事务处于活动状态(适用于所有恢复模式)。 日志备份开始时可能存在长时间运行的事务。 在这种情况下,要释放空间可能需要进行额外的日志备份。 请注意,长时间运行的事务会阻止所有恢复模式下的日志截断,包括简单的恢复模式,在该模式下,事务日志通常会在每个自动检查点上截断。 交易被延后。 延迟事务实际上是由于某些不可用资源而阻止其回滚的活动事务。 有关延迟事务的原因以及如何将其移出延迟状态的信息,请参阅延迟事务(SQL Server)。 长时间运行的事务也可能填满 tempdb 的事务日志。 Tempdb 由用户事务隐式使用,用于存储内部对象,如用于排序的工作表、用于哈希的工作文件、游标工作表和行版本控制。 即使用户事务仅包括读取数据(SELECT 查询),也可以创建内部对象并在用户事务下使用。 然后可以填充 tempdb 事务日志。 |
5 | 数据库镜像 | 数据库镜像暂停或处于高性能模式,镜像数据库明显落后于主体数据库。 (仅限完整恢复模式) 有关详细信息,请参阅数据库镜像(SQL Server)。 |
6 | 复制 | 在事务复制期间,与发布相关的事务仍不传递给分发数据库。 (仅限完整恢复模式) 有关事务复制的信息,请参阅 SQL Server 复制。 |
7 | 数据库快照创建 | 正在创建数据库快照。 (所有恢复模式) 这是一个惯常情况,通常较为简短,是导致日志截断延迟的原因。 |
8 | LOG_SCAN | 正在进行日志扫描。 (所有恢复模式) 这是一种常见且通常较为简短的导致日志截断延迟的情况。 |
9 | 可用性副本 | 可用性组的次要副本将此数据库的事务日志记录应用于相应的辅助数据库。 (完整恢复模式) 有关详细信息,请参阅 AlwaysOn 可用性组概述(SQL Server)。 |
10 | - | 仅供内部使用 |
11 | - | 仅供内部使用 |
12 | - | 仅供内部使用 |
13 | OLDEST_PAGE | 如果数据库配置为使用间接检查点,则数据库中最早的页面可能早于检查点 LSN。 在这种情况下,最旧的页面可能会延迟日志截断。 (所有恢复模式) 有关间接检查点的信息,请参阅数据库检查点(SQL Server)。 |
14 | 其他临时 | 此值当前未使用。 |
16 | XTP_CHECKPOINT | 当数据库包含内存优化文件组时,事务日志可能不会截断,直到自动 In-Memory OLTP 检查点被触发(这在每 512 MB 的日志增长时会发生)。 注意:若要在 512 MB 大小之前截断事务日志,请针对相关数据库手动触发 Checkpoint 命令。 |
可以最小化日志记录的操作
最小日志记录 只记录恢复事务处理所需的必要信息,但不支持时间点恢复。 本主题列出在大容量日志恢复模式(以及简单恢复模式,但备份运行时除外)下,仅进行最小记录的操作。
注释
内存优化表不支持最小日志记录。
注释
在完整恢复模式下,所有批量操作都会被完全记录。 但是,可以通过暂时将数据库切换到大量日志恢复模式来最大程度地减少一组批量操作的日志记录。 最小日志记录比完整日志记录更有效,并减少了在大规模批量事务期间填充可用事务日志空间的可能性。 但是,如果数据库在最小日志记录生效时损坏或丢失,则无法将数据库恢复到故障点。
在完整恢复模式下完全记录的以下操作,在简单恢复模式和大容量日志恢复模式下以最小日志记录:
大容量导入操作(bcp、BULK INSERT 和 INSERT... SELECT)。 有关批量导入到表中的最小记录的详细信息,请参阅 批量导入中最小日志记录的先决条件。
注释
启用事务复制后,即使在大容量日志恢复模式下,BULK INSERT 操作也会被完全记录。
SELECT INTO 操作。
注释
启用事务复制后,SELECT INTO操作会被完整记录,即使在大容量日志恢复模式下也是如此。
使用 UPDATE 语句中的 .WRITE 子句对大型值数据类型进行部分更新,以插入或追加新数据。 请注意,更新现有值时不使用最小日志记录。 有关大型值数据类型的详细信息,请参阅数据类型(Transact-SQL)。
当将新数据插入或追加到
text
、ntext
和image
数据类型列时,请使用WRITETEXT和UPDATETEXT语句。 请注意,更新现有值时不使用最小日志记录。注释
WRITETEXT 和 UPDATETEXT 语句已弃用,因此应避免在新应用程序中使用这些语句。
如果数据库设置为简单恢复模式或大容量日志恢复模式,则一些索引 DDL 操作在脱机或联机执行时会进行最小日志记录。 最小记录的索引操作如下所示。
CREATE INDEX 操作(包括创建索引视图)。
ALTER INDEX REBUILD 或 DBCC DBREINDEX 操作。
注释
DBCC DBREINDEX 语句已弃用,因此应避免在新应用程序中使用它。
DROP INDEX 新堆重新生成(如果适用)。
注释
DROP INDEX操作期间的索引页解除分配始终有完整日志记录。
相关任务
Managing the transaction log
备份事务日志(完整恢复模式)
还原事务日志(完整恢复模式)
另请参阅
控制事务持续性
批量导入中最低限度日志记录的先决条件
SQL Server 数据库的备份和还原
数据库检查点 (SQL Server)
查看或更改数据库的属性
恢复模式 (SQL Server)