SQL Server 截断日志示例

这篇文章主要为大家详细介绍了SQL Server 截断日志示例，具有一定的参考价值，可以用来参考一下。

SQL Server 在完成事务日志备份时将自动截断事务日志中的不活动部分。这些不活动的部分包含已完成的事务，因此在恢复过程中不再使用。相反，事务日志的活动部分包含仍在运行但尚未完成的事务。SQL Server 将重新使用事务日志中这些截断的非活动空间，而不是任由事务日志继续增大并占用更多的空间。

虽然可以手工截断事务日志，但强烈建议最好不要这样做，因为这将断开日志备份链。在创建完整数据库备份前，将无法为数据库提供媒体故障保护。只有在非常特殊的环境中才使用手工日志截断，而且尽可能快地创建完整数据库备份。

事务日志非活动部分的终点（因此就是截断点）是下列事件的最早点：

最近的检查点。

最早的活动事务的起点，即尚未提交或回滚的事务。

这代表在恢复过程中，SQL Server 必须回滚事务的最早点。

最早事务的起点，这些事务包括已发布但尚未复制更改的复制对象。

这代表 SQL Server 仍必须复制的最早点。

这个好象类似 oracle 的rman 备份中,备份完archivelog 后,archivelog 是不再需要的,rman 可以自动删除备份的log ,而sqlserver 系统会截断部分日志.

oracle 的日志是循环使用online redolog 并生成archivelog 文件,而sqlserver 的日志构架如下描述

事务日志物理构架

数据库内的事务日志映射在一个或多个物理文件上。日志文件在概念上是一串连续的日志记录。在物理上，日志记录序列必须有效地存储在实现事务日志的物理文件集内。

Microsoft® SQL Server™ 2000 在内部将每个物理日志文件分成许多虚拟日志文件。虚拟日志文件没有固定大小，且物理日志文件所包含的虚拟日志文件数不固定。在创建或扩展日志文件时，SQL Server 动态地选择虚拟日志文件的大小。SQL Server 尝试维护少量的虚拟文件。在日志文件扩展名后，根据现有日志的大小和新文件增量的大小确定虚拟文件的大小。虚拟日志文件的大小或数量不能由管理员配置或设置，而是由 SQL Server 代码动态确定。

只有当虚拟日志文件的 size 和 growth_increment 值较小时，它们才会影响系统的性能。如果这些日志文件经过多次按小增量值增长后变得很大，它们将有大量的虚拟日志文件，从而降低恢复的速度。建议使用接近最终所需大小的 size 值来定义日志文件，并将日志文件的 growth_increment 值设得相对大一些。

事务日志是回绕的日志文件。例如，假设有一个数据库，它包含一个分成四个虚拟日志文件的物理日志文件。当创建数据库时，逻辑日志文件从物理日志文件的始端开始。在逻辑日志的末端添加新的日志记录，逻辑日志就向物理日志末端增长。截断操作发生时，删除最小恢复日志序号（MinLSN）之前的虚拟日志内的记录。本示例数据库内的日志外观与下图所示相似。

这个循环不断重复，只要逻辑日志的末端不到达逻辑日志的始端。如果经常截断旧的日志记录，使得总能为下一个检查点创建的所有新日志记录保留足够的空间，那么日志永远不会填满。然而，如果逻辑日志的末端真的到达了逻辑日志的始端，将发生下列两件事之一：

如果对日志启用了自动增长且磁盘上有可用空间，文件就按 growth_increment 指定的数量扩展，新的日志记录则添加到扩展中。

如果没有启用自动增长，或者保存日志文件的磁盘上的可用空间比 growth_increment 指定的数量少，则生成 1105 错误。

如果逻辑日志包含多个物理日志文件，则逻辑日志将沿着所有的物理日志文件移动，然后回绕到第一个物理日志文件的始端。

截断事务日志

如果从来没有从事务日志中删除日志记录，逻辑日志就会一直增长，直到填满容纳物理日志文件的磁盘上的所有可用空间。在某个即时点，必须删除恢复或还原数据库时不再需要的旧日志记录，以便为新日志记录腾出空间。删除这些日志记录以减小逻辑日志的大小的过程称为截断日志。

永远不能截断事务日志的活动部分。日志的活动部分是在任何时间恢复数据库所需的日志部分，因此必须有回滚所有未完成的事务所需的日志映像。这部分必须始终在数据库中，因为一旦服务器发生故障，在服务器重新启动时必须用它恢复数据库。日志活动部分起点处的记录由最小恢复日志序号 (MinLSN) 标识。

为数据库选择的恢复模式决定了在数据库内，必须在活动部分之前保留的事务日志量。虽然 MinLSN 之前的日志记录对恢复活动事务没有作用，但在使用日志备份将数据库还原到故障点时，必须用这些记录前滚修改。如果由于某种原因丢失了数据库，则可以通过还原上次的数据库备份，然后还原自该数据库备份后的每个日志备份来恢复数据。这意味着这些日志备份必须包含自数据库备份后所写入的每个日志记录。当维护事务日志备份序列时，日志记录直到写入日志备份时才能被截断。

MinLSN 之前的日志记录只用于维护事务日志备份序列。

在简单恢复模式中，不维护事务日志序列。MinLSN 之前的所有日志记录可以随时被截断，但在处理 BACKUP 语句时除外。NO_LOG 和 TRUNCATE_ONLY 是只对使用简单恢复模式的数据库有效的 BACKUP LOG 选项。

说明tempdb 数据库始终使用简单恢复模式，不能切换到其它恢复模式。日志截断始终发生在 tempdb 中的检查点上。

在完全恢复模式和有日志记录的大容量恢复模式中，维护事务日志备份序列。MinLSN 之前的逻辑日志部分直到复制到某个日志备份时才能被截断。

日志截断在下列情况下发生：

执行完 BACKUP LOG 语句时。

在每次处理检查点时（如果数据库使用的是简单恢复模式）。这包括 CHECKPOINT 语句所产生的显式检查点和系统生成的隐式检查点。例外情况是如果检查点发生在 BACKUP 语句仍活动时，则不截断日志。有关自动检查点间隔的更多信息，请参见检查点和日志的活动部分。

事务日志在内部分成若干称为虚拟日志文件的部分。虚拟日志文件是截断的单元。当截断事务日志时，删除包含 MinLSN 的虚拟日志文件头之前的所有日志记录。有关虚拟日志文件的更多信息，请参见事务日志物理构架。

因此，按下面任一方式控制事务日志的大小：

在维护日志备份序列时，调度 BACKUP LOG 语句按间隔发生，以使事务日志不致增长到超过预期的大小。

当不维护日志备份序列时，指定简单恢复模式。

注：关于SQL Server 截断日志示例的内容就先介绍到这里，更多相关文章的可以留意