SQL Server如何截断(Truncate)和收缩(Shrink)事务日志
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了SQL Server如何截断(Truncate)和收缩(Shrink)事务日志,小编现在分享给大家,供广大互联网技能从业者学习和参考。文章包含1437字,纯文字阅读大概需要3分钟。
内容图文
原文:http://blog.csdn.net/tjvictor/article/details/5253931
?
当 SQL Server 截断事务日志时,它仅仅是在虚拟日志文件中做个标记,以便不再使用它,然后准备以重用形式来做备份 ( 假如运载在完整或是批量日志恢复模型 ) 。也就是说,在使用简单恢复模型时,事务日志包括如下的日志记录:
当 checkpoint 发生时,虚拟日志文件 1 、 2 不再被使用,因为事务 1 、 2 已经被提交了,而且日志记录也不再需要回滚了。然后 SQL Server 重用虚拟日志文件 1 、 2 ,如下图:
这就是我们所熟知的事务日志截断。基本上,事务日志的活动区间已经被截断了,但是事务日志的物理大小不会改变,除非数据库使用自动收缩的属性设置。在这种情况下,事务日志就会尽可能的在物理上进行周期性的收缩。
为了物理上减小事务日志的大小,收缩事务日志作为已知的方法,你在使用时可以选择下面选项中的一种:
-
执行 DBCC SHRINKDATABASE 命令
-
执行 DBCC SHRINKFILE 命令
-
设置数据库的事务日志自动收缩选项
需要注意的是,事务日志仅仅能收缩到虚拟日志文件的边界。下面是个例子。
我新建了一个数据库,它有 1MB 的事务日志空间, 5MB 的自动增长空间。运行 DBCC LOGINFO 显示如下:
这里有四个可变大小的虚拟日志文件。然后我输入一些数据,这会使事务日志 增长到 5MB :
在新的 5MB 事务日志区间里面新建了 4 个新的虚拟日志文件。每一个新建的虚拟日志文件都是 1310720bytes ,每 7 个虚拟日志文件正在使用时 ( 状态是 2) 。我现在备份事务日志,因此将会截断事务日志:
目前仅仅有一个虚拟日志文件在使用 ( 第 7 行,状态为 2). 假如我现在用下面的命令,试着把日志收缩到 2M :
DBCC SHRINKFILE (‘AdventureWorks_log‘, 2)
因为活动日志记录是虚拟日志文件 7 ,所以 SQL Server 仅仅删除虚拟日志文件 8 。这次事务日志从 7MB 收缩到 4.7MB. SQL Server 也在事务日志中新建了假的入口,为了移除 2MB 点之前的最近活动日志记录,以便于它包裹到虚拟日志文件 2 (注意状态为 2 的行)。
假如现在再次备份事务日志的话,事务日志会再次被截断,现在活动区间就是虚拟日志文件 2 了。
如果我现在再尝试一次收缩文件的话, SQL Server 则会成功的收缩到 2MB 左右,因为日志的活动区间已经接近 2MB 了。文件被收缩到最接近于日志登记时的大小。这时 DBCC LOGINFO 的输出如下:
事务日志文件大小为 2359296bytes( 虚拟日志文件大小总量要加上 8192 字节的头信息 )
所以如果你发现你不能收缩事务日志到一个指定的范围,运行 DBCC LOGINFO ,然后检查虚拟日志文件的范围,弄清楚每一个日志的大小,你能把文件收缩到什么范围。
? ?
本文翻译自 sqlbackuprestore ,更多精彩内容请浏览 http://www.sqlbackuprestore.com
原文:http://www.cnblogs.com/liyanwei/p/4451131.html
内容总结
以上是互联网集市为您收集整理的SQL Server如何截断(Truncate)和收缩(Shrink)事务日志全部内容,希望文章能够帮你解决SQL Server如何截断(Truncate)和收缩(Shrink)事务日志所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错,欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明:本文内容由互联网用户自发贡献,该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容, 请发送邮件至 gblab@vip.qq.com 举报,一经查实,本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。