截断事务日志所要注意的问题
2011-01-05 17:49
169 查看
截断事务日志所要注意的问题
数据库使用的时间一长,日志也随之成长,当日志占用了较多的磁盘空间时,为节省宝贵的磁盘空间,往往要清除一下日志,笔者也见过很多网上流传的截断日志的方法,总的来说那些流传的方法是有效并可行的,但它忽略了一些要点,容易让新手犯下大错!首先,我们先谈谈 Backup Log ... With 所使用的几个参数:
WITH NO_TRUNCATE
WITH TRUNCATE_ONLY
WITH NO_LOG
1.WITH NO_TRUNCATE 用来备份日志,使用该选项后,MSSQL 会将当前数据库中所有活动进程写入到日志中,因此, NO_TRUNCATE 可以保证数据恢复到最后的更新状态下。 NO_TRUNCATE 通常使用在数据库系统损坏后的日志备份中。
2.WITH TRUNCATE_ONLY 不是用来备份日志,而是用来显式截断日志的,使用该选项后,MSSQL 会将当前数据库事务日志 中的非活动部分(已提交完成的事务)截断,这时被截断的非活动事务所占用的物理空间会被最新的活动日志所替代, 这意味着,日志一旦被截断,将不会用来作恢复使用。
3.WITH NO_LOG 同 WITH TRUNCATE_ONLY 相似,也是用来显式截断日志的,与 WITH TRUNCATE_ONLY 不同的是NO_LOG 选项截断日志的操作是不会记录在日志中的。
讲了这一些,我们就会有两点发现:
1.显式截断日志 WITH TRUNCATE_ONLY 与 WITH NO_LOG 有一定的冒险,原因就是“日志一旦被截断,将不会用来作恢复使用”。为了解除威胁,在使用显式截断日志前,最好备份一下日志,并在截断日志后,做一次完全备份,重新塑造新的日志备份逻辑链,用来防止日志备份中的脱节现象。
2.尽量使用 WITH TRUNCATE_ONLY ,NO_LOG 仅当事务日志完全填满时才使用,当日志完全填满时,不能使用WITH TRUNCATE_ONLY来截断事务日志。这样是因为 MSSQL 将记录此次截断情况,而此时事务日志中却没有剩余空间,因此只能使用 NO_LOG 。
总结:不要轻易使用显式截断日志的方法,经常作日志备份,实质上在日志备份后,也会截断日志的。
若要使用显式截断日志,一定要做好备份,尤其是截断后的那次完全备份!
摘自:http://blog.csdn.net/suntt/archive/2006/02/26/610374.aspx
相关文章推荐
- SQL Server如何截断(Truncate)和收缩(Shrink)事务日志
- 为什么完整备份不能截断事务日志
- python logging模块在多进程多日志文件写入时要注意的问题
- 考勤系统问题记录一:事务日志太大
- 问题:SQL Server 2000数据库的事务日志文件过大,如何将其缩小?
- 关于SQL Server事务日志的问题汇总
- SQL SERVER 2008 事务日志截断
- 关于SQL Server事务日志的问题汇总
- 数据库“TSupervise” 的事务日志已满问题的解决之法
- 关于SQL Server事务日志的问题汇总
- 在Python中使用全局日志时需要注意的问题
- 程序中有事务的时候需要注意的一个问题
- SQL Server如何截断(Truncate)和收缩(Shrink)事务日志
- SQL Server 2008 事务日志截断(truncate)与收缩(shrink)
- 事务、异常-T-SQL 编码时应该注意的10个问题-by小雨
- 解决 “数据库 'tempdb' 的日志已满。请备份该数据库的事务日志以释放一些日志空间” 的问题
- 事务处理必须重新运行问题---运维日志2
- SQL 2008 截断事务日志不能用了??
- SQL事务日志问题
- 【转】对于SQL SERVER 事务日志已满问题整理