有关事务日志截断和收缩

概述

在实际环境中，我们经常会遇到事务日志满，无法进行操作，这样我们需要手动进行对日志文件的截断和收缩。由于长时间运行的事务或暂停的数据库镜像会话都

可导致事务日志填满，这个时候日志中的事务仍处理活动状态，经常有人在右击数据库--&gttask--&gtshrink--&gtfiles，选择数据库文件或日期志文件都不产生效果。如果数据库使用的是简单恢复模式，事务日志将被自动截断。

 

首先，我们可以通过目录视图sys.databases中log_reuse_wait和log_reuse_wait_desc列可显示事务日志的活动情况：

 

SELECT name,log_reuse_wait,log_reuse_wait_desc FROM sys.databases

 

当log_reuse_wait_desc为ACTIVE_TRANSACTION时，表示事务日志处于活动状态，这时通过普通的收缩日期志文件不会有效。

 

 

日志截断

日志截断可释放日志文件中的空间，以供事务日志重新使用。由于日志的活动部分不能通过收缩来截断或删除，因此，当日志记录长时间保持活动状态时，截断将被延迟。

 

日志截断（在简单恢复模式下自动执行）对于防止日志变满至关重要。截断过程通过将不包含任何逻辑日志部分的虚拟日志文件标记为不活动来减小逻辑日志文件的大小。

 

日志截断并不减小物理日志文件的大小。 减小日志文件的物理大小需要收缩文件。

 

在清除事务日志，SQLSERVER 2000与SQLSERVER 2005基本上可以用一样的命令，但是在SQLSERVER 2005有些新的变化。

 

SQLSERVER 2000

DUMP TRANSACTION { database_name | @database_name_var }

  WITH { NO_LOG | TRUNCATE_ONLY }

[;]

 

 

SQLSERVER 2005则可以用BACKUP命令完成

Backing Up the Transaction Log (full and bulk-logged recovery models)

BACKUP LOG { database_name | @database_name_var }

  TO [ ,...n ]

  [ ] [ next-mirror-to ]

  [ WITH { | } [ ,...n ] ]

[;]

 

Truncating the Transaction Log (breaks the log chain)

BACKUP LOG { database_name | @database_name_var }

  WITH { NO_LOG | TRUNCATE_ONLY }

[;]

 

注：SQL SERVER 2008 已取消BACKUP TRANSACTION、BACKUP LOG { WITH NO_LOG | TRUNCATE_ONLY } 功能

在SQL SERVER 2008中，如果数据库使用的是简单恢复模式，事务日志将被自动截断。如果必须从数据库删除日志备份链，请切换到简单恢复模式。

 

收缩日志文件

DBCC SHRINKFILE (N'filename_log' , 0, TRUNCATEONLY);

 

例：

在日志的活动部分不能通过收缩来截断或删除时，将通过截断后再收缩(SQL SERVER 2005)

1. BACKUP LOG database_name WITH TRUNCATE_ONLY

 

2.  DBCC SHRINKFILE (N'filename_log' , 0, TRUNCATEONLY);

 

即可完成！

 

在完成事务日志截断和收缩后，之后的差异备份和日期志备份将无效，所以要求做一次完全备份！

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/9932141/viewspace-631056/，如需转载，请注明出处，否则将追究法律责任。

转载于:http://blog.itpub.net/9932141/viewspace-631056/