事务日志的截断与收缩

截断事务日志

自动截断操作：

　　1、备份事务日志

　　2、设置简单模式再设置回来

　　3、使用backup log with no_log或 backup log with truncate_only 

　　4、从未对数据库进行过完全（full）备份

概要总结：所谓的截断(truncated)只是将可恢复状态的VLF转换到可重用状态

   

    因此，VLF的状态是源自其上所含有的LSN的状态，可以分为两大类:活动VLF和不活动VLF

    而更加细分可以将VLF的状态分为以下四类:

1. 活动(Active) –在VLF 上存储的任意一条LSN是活动的时，则VLF则为活动状态，即使一个200M的VLF只包含了一条LSN，如上图的VLF3
2. 可恢复(Recoverable) – VLF是不活动的，VLF上不包含活动LSN,但还未被截断(truncated)
3. 可重用(Reusable) – VLF是不活动的，VLF上不包含活动LSN,已经被截断(truncated)，可以重用
4. 未使用(Unused) – VLF是不活动的,并且还未被使用过

概念：而所谓的截断(truncated)只是将可恢复状态的VLF转换到可重用状态。在简单恢复模式下，每一次CheckPoint，都会去检查是否有日志可以截断.如果有inactive的VLF时，CheckPoint都会将可截断部分进行截断，并将MinLSN向后推.

    在日志达到日志文件(ldf文件）末尾时，也就是上图的VLF8时，会重新循环到VLF1开始，以便让空间进行重复利用.所以日志虽然可以从物理顺序上是从VLF1到VLF8，但逻辑顺序可以是从VLF6开始到VLF2结束:

    

     因此可以看出，简单恢复模式下日志是不保存的（当事务结束后，相关的会被截断）。仅仅是用于保证事务回滚和崩溃恢复的用途.所以备份日志也就无从谈起，更不能利用日志来恢复数据库。

　　详细概念：如果从来没有从事务日志中删除日志记录，逻辑日志就会一直增长，直到填满容纳物理日志文件的磁盘上的所有可用空间。在某个即时点，必须删除恢复或还原数据库时不再需要的旧日志记录，以便为新日志记录腾出空间。删除这些日志记录以减小逻辑日志的大小的过程称为截断日志。
　　永远不能截断事务日志的活动部分。日志的活动部分是在任何时间恢复数据库所需的日志部分，因此必须有回滚所有未完成的事务所需的日志映像。这部分必须始终在数据库中，因为一旦服务器发生故障，在服务器重新启动时必须用它恢复数据库。日志活动部分起点处的记录由最小恢复日志序号 (MinLSN) 标识。
　　为数据库选择的恢复模式决定了在数据库内，必须在活动部分之前保留的事务日志量。虽然 MinLSN 之前的日志记录对恢复活动事务没有作用，但在使用日志备份将数据库还原到故障点时，必须用这些记录前滚修改。如果由于某种原因丢失了数据库，则可以通过还原上次的数据库备份，然后还原自该数据库备份后的每个日志备份来恢复数据。这意味着这些日志备份必须包含自数据库备份后所写入的每个日志记录。当维护事务日志备份序列时，日志记录直到写入日志备份时才能被截断。

删除数据或事务日志
　　删除数据或事务日志文件将从数据库删除该文件。仅当文件上不存在已有的数据或事务日志信息时才可能从数据库删除文件；文件必须完全为空后才能删除。若要将数据从一个数据文件迁移到同一文件组中的其它文件中，请使用 DBCC SHRINKFILE 语句，并指定 EMPTYFILE 子句。SQL Server 即不再允许将数据置于文件上，从而通过使用 ALTER DATABASE 语句或 SQL Server 企业管理器内的属性页，使之能够删除。
通过将事务日志数据从一个日志文件迁移到另一个以删除事务日志文件是不可能的。若要从事务日志文件清除非活动的事务，必须截断或备份该事务日志。一旦事务日志文件不再包含任何活动或不活动的事务，该日志文件就可以从数据库中删除。
添加或删除文件后，请立即创建数据库备份。在创建完整的数据库备份之前，不应该创建事务日志备份。

收缩数据库
SQL Server 2000 自动收缩有大量可用空间的数据库。该进程仅适用于那些 autoshrink 选项设置为 true 的数据库。服务器定期检查每个数据库中的空间使用情况。如果发现数据库中有大量闲置空间，而且它的 autoshrink 选项设置为 true，SQL Server 就缩小该数据库中的文件大小。也可以使用 SQL Server 企业管理器或 DBCC SHRINKDATABASE 和 DBCC SHRINKFILE 语句，手工收缩数据库中的文件。

文件始终从末端开始收缩。例如，如果有个 5 GB 的文件并将 DBCC SHRINKDB 语句中的 target_size 指定为 4GB，则 SQL Server 将从文件的最后一个 1 GB 开始释放尽可能多的空间。如果文件中被释放的部分包含使用过的页，则 SQL Server 首先将这些页重新定位到保留的部分。只能将数据库收缩到没有剩余的可用空间为止。例如，某个 5GB 的数据库有 4 GB 的数据并且 DBCC SHRINKDATABASE 语句的 target_size 被指定为 3 GB，则只释放 1 GB。

如果 DBCC SHRINKDATABASE 或 DBCC SHRINKFILE 语句无法收回日志文件中的所有空间，该语句将发出信息，指示必须执行什么操作以释放更多符合条件的空间。

收缩事务日志
在下列情况下，日志文件的物理大小将减少：

执行 DBCC SHRINKDATABASE 语句时。

执行引用日志文件的 DBCC SHRINKFILE 语句时。

自动收缩操作发生时。
　　日志收缩操作依赖于最初的日志截断操作。日志截断操作不减小物理日志文件的大小，但减小逻辑日志的大小，并将没有容纳逻辑日志任何部分的虚拟日志标记为不活动。日志收缩操作会删除足够多的不活动虚拟日志，将日志文件减小到要求的大小。

　　减小大小的单位是一个虚拟日志文件。例如，如果有个 600 MB 的日志文件被分成了 6 个 100 MB 的虚拟日志，则该日志文件的大小只能按 100 MB 递减。比如，文件可以减小到 500 MB 或 400 MB，但不能减小到 433 MB 或 525 MB。

　　不能释放容纳逻辑日志部分的虚拟日志。如果某个日志文件中的所有虚拟日志都容纳了逻辑日志部分，则不能收缩该文件，直到截断操作在物理日志的末端将一个或更多的虚拟日志标记为不活动。

　　当收缩任何文件时，必须从文件的末端开始释放空间。当收缩事务日志文件时，从文件的末端开始释放足够的虚拟日志以将日志减小到用户所要求的大小。用户指定的 target_size 四舍五入为下一个最大的虚拟日志边界大小。例如，如果用户为包含 6 个 100 MB 虚拟日志文件的 600 MB 文件指定 325 MB 的 target_size，则删除最后两个虚拟日志文件，因此新的文件大小为 400 MB。

　　在 SQL Server 2000 中，DBCC SHRINKDATABASE 或 DBCC SHRINKFILE 操作试图立即将物理日志文件收缩到所要求的大小（以四舍五入的值为准）：

　　如果虚拟日志中的逻辑日志部分没有超出 target_size 标记，则释放 target_size 标记之后的虚拟日志，并且成功完成 DBCC 语句，不出现任何信息。

　　如果虚拟日志中的逻辑日志部分超出 target_size 标记，则 SQL Server 2000 释放尽可能多的空间并发出一条信息。该信息告诉您需要执行什么操作以获得文件末端超出虚拟日志的逻辑日志部分。执行完该操作后，可以重新发出 DBCC 语句以释放剩余的空间。

文章参考自：

1.http://www.cnblogs.com/CareySon/archive/2012/02/17/2355200.html

2.https://zhidao.baidu.com/question/578389211.html