SQL Server 2008 事务日志物理文件尺寸无法减小的解决办法（含日志收缩(shr...

本文主要是介绍SQL Server 2008 事务日志物理文件尺寸无法减小的解决办法（含日志收缩(shr...，希望对大家解决编程问题提供一定的参考价值，需要的开发者们随着小编来一起学习吧！

我的一个数据库，数据文件10+G ，事务日志达20+G，而且使用常规的截断、收缩方法均无法减小日志物理文件的尺寸，经过一番寻找，终于找到了解决方法。

查看日志信息

在查询分析器中执行如下代码来查看日志信息：

DBCC LOGINFO('数据库名称')注意：

日志备份不会妨碍截断。

完成日志备份后，日志的头部将前移，一些日志空间可能变为可重复使用。

ACTIVE_BACKUP_OR_RESTORE

数据备份或还原正在进行（所有恢复模式）。

数据备份与活动事务的运行方式相同。数据备份在运行时，将阻止截断。有关详细信息，请参阅本主题后面的“数据备份操作与还原操作”部分。

ACTIVE_BACKUP_OR_RESTORE

数据备份或还原正在进行（所有恢复模式）。

数据备份与活动事务的运行方式相同。数据备份在运行时，将阻止截断。有关详细信息，请参阅本主题后面的“数据备份操作与还原操作”部分。

DATABASE_MIRRORING

数据库镜像暂停，或者在高性能模式下，镜像数据库明显滞后于主体数据库（仅限于完整恢复模式）。

有关详细信息，请参阅本主题后面的“数据库镜像与事务日志”部分。

REPLICATION

在事务复制过程中，与发布相关的事务仍未传递到分发数据库（仅限于完整恢复模式）。

有关详细信息，请参阅本主题后面的“事务复制与事务日志”部分。

DATABASE_SNAPSHOT_CREATION

正在创建数据库快照（所有恢复模式）。

这是日志截断延迟的常见原因，通常也是主要原因。

DATABASE_SNAPSHOT_CREATION

正在创建数据库快照（所有恢复模式）。

这是日志截断延迟的常见原因，通常也是主要原因。

针对延迟日志截断原因的部分解决方案

LOG_BACKUP
备份日志后再执行收缩即可

REPLICATION
这是我遇到的情况，但我根本没有启用过REPLICATION，据查，这好像是SQLSERVER2008的一个BUG，解决方法是给标有“REPLICATION”的数据库任意一个表创建数据库事务复制（TRANSACTION REPLICATION），然后再删除，执行数据库与日志备份后，就可以收缩了。

小技巧

一般收缩日志的代码中都要求指定日志的文件名称，下面的代码则可以自动获取日志文件名称

1 USE[数据库名称]
2 DECLARE@LogFileLogicalName sysname
3 SELECT@LogFileLogicalName=NameFROM sys.database_filesWHERE Type=1
4 PRINT@LogFileLogicalName
5 DBCC SHRINKFILE (@LogFileLogicalName,1);