http://technet.microsoft.com/zh-CN/library/ms190925
每个 SQL Server 数据库都具有事务日志,用于记录所有事务以及每个事务对数据库所做的修改。 必须定期截断事务日志以避免它被填满。 但是,一些因素可能延迟日志截断,因此监视日志大小很重要。 某些操作可以最小日志量进行记录以减少其对事务日志大小的影响。
事务日志是数据库的重要组件,如果系统出现故障,则可能需要使用事务日志将数据库恢复到一致状态。 删除或移动事务日志以前,必须完全了解此操作带来的后果。
![]() |
---|
检查点创建一些正常点,在数据库恢复期间从这些正常点开始应用事务日志。 有关详细信息,请参阅数据库检查点 (SQL Server)。 |
本主题内容:
日志截断释放日志文件的空间,以便由事务日志重新使用。 日志截断主要用于阻止日志填充。 日志截断从 SQL Server 数据库的逻辑事务日志中删除不活动的虚拟日志文件,释放逻辑日志中的空间以便物理事务日志重用这些空间。 如果事务日志从不截断,它最终将填满分配给物理日志文件的所有磁盘空间。
为了避免这个问题,除非由于某些原因延迟日志截断,将在以下事件后自动进行截断:
-
简单恢复模式下,在检查点之后发生。
-
在完整恢复模式或大容量日志恢复模式下,如果自上一次备份后生成检查点,则在日志备份后进行截断(除非是仅复制日志备份)。
有关详细信息,请参阅本主题后面的可能延迟日志截断的因素。
![]() |
---|
日志截断并不减小物理日志文件的大小。 若要减少物理日志文件的物理大小,需要收缩日志文件。 有关收缩物理日志文件大小的信息,请参阅管理事务日志文件的大小。 |
在日志记录长时间处于活动状态时,事务日志截断将延迟,事务日志可能填满。
![]() |
---|
有关如何响应已满事务日志的信息,请参阅解决事务日志已满的问题(SQL Server 错误 9002)。 |
日志截断会由于多种因素发生延迟。 您可以查询 sys.databases 目录视图的 log_reuse_wait 和 log_reuse_wait_desc 列来发现是什么(如果有)阻止了日志的截断。 下表对这些列的值进行了说明。
log_reuse_wait 值 |
log_reuse_wait_desc 值 |
说明 | ||
---|---|---|---|---|
0 |
NOTHING |
当前有一个或多个可重复使用的虚拟日志文件。 |
||
1 |
CHECKPOINT |
自上次日志截断之后,尚未生成检查点,或者日志头尚未跨一个虚拟日志文件移动。 (所有恢复模式) 这是日志截断延迟的常见原因。 有关详细信息,请参阅数据库检查点 (SQL Server)。 |
||
2 |
LOG_BACKUP |
在截断事务日志前,需要进行日志备份。 (仅限完整恢复模式或大容量日志恢复模式) 完成下一个日志备份后,一些日志空间可能变为可重复使用。 |
||
3 |
ACTIVE_BACKUP_OR_RESTORE |
数据备份或还原正在进行(所有恢复模式)。 如果数据备份阻止了日志截断,则取消备份操作可能有助于解决备份直接导致的此问题。 |
||
4 |
ACTIVE_TRANSACTION |
事务处于活动状态(所有恢复模式)。
|
||
5 |
DATABASE_MIRRORING |
数据库镜像暂停,或者在高性能模式下,镜像数据库明显滞后于主体数据库。 (仅限完整恢复模式) 有关详细信息,请参阅数据库镜像 (SQL Server)。 |
||
6 |
REPLICATION |
在事务复制过程中,与发布相关的事务仍未传递到分发数据库。 (仅限完整恢复模式) 有关事务复制的信息,请参阅 SQL Server 复制。 |
||
7 |
DATABASE_SNAPSHOT_CREATION |
正在创建数据库快照。 (所有恢复模式) 这是日志截断延迟的常见原因,通常也是主要原因。 |
||
8 |
LOG_SCAN |
发生日志扫描。 (所有恢复模式) 这是日志截断延迟的常见原因,通常也是主要原因。 |
||
9 |
AVAILABILITY_REPLICA |
可用性组的辅助副本正将此数据库的事务日志记录应用到相应的辅助数据库。 (完整恢复模式) 有关详细信息,请参阅 AlwaysOn 可用性组概述 (SQL Server)。 |
||
10 |
— |
仅供内部使用 |
||
11 |
— |
仅供内部使用 |
||
12 |
— |
仅供内部使用 |
||
13 |
OLDEST_PAGE |
如果将数据库配置为使用间接检查点,数据库中最早的页可能比检查点 LSN 早。 在这种情况下,最早的页可以延迟日志截断。 (所有恢复模式) 有关间接检查点的信息,请参阅数据库检查点 (SQL Server)。 |
||
14 |
OTHER_TRANSIENT |
当前未使用此值。 |
“最小日志记录”是指只记录在不支持时间点恢复的情况下恢复事务所需的信息。 本主题介绍在大容量日志恢复模式下(以及简单恢复模式下)按最小方式记录、但在运行备份时例外的操作。
![]() |
---|
在完整恢复模式下,所有大容量操作都将被完整地记录下来。 但是,可以通过将数据库暂时切换到用于大容量操作的大容量日志恢复模式,最小化一组大容量操作的日志记录。 最小日志记录比完整日志记录更为有效,并在大容量事务期间,降低了大规模大容量操作填满可用的事务日志空间的可能性。 不过,如果在最小日志记录生效时数据库损坏或丢失,则无法将数据库恢复到故障点。 |
下列操作在完整恢复模式下执行完整日志记录,而在简单和大容量日志恢复模式下按最小方式记录:
-
大容量导入操作(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 操作期间将始终完整记录索引页的释放操作。
-