数据库事务日志文件-log4j 日志 文件

今天系统突然报如下错误：

数据库的事务日志已满。要找出日志中的空间不能被重用的原因，请参阅 sys.databases 中的 log_reuse_wait_desc 列

检查服务器后发现数据库日志所在的磁盘空间已满。 从磁盘中删除一些文件后，系统恢复正常。 又上网查了一下错误。 如果想从日志文件本身来解决，可以使用以下两种方法解决：

一、清除日志：

步骤： 1. 备份日志文件。 2. 压缩日志文件。

1、备份日志文件，可以使用如下sql命令：

DUMPTRANSACTION 数据库名称 WITHNO_LOG

2、打开企业管理器，右击数据库->属性->选项->故障恢复-模型-选择-简单模型。 （也可以直接在查询分析器中执行：

alterdatabase 数据库名称 setrecoverysimple

3.右击要压缩的数据库-->All Tasks-->Shrink Database-->Shrink File-->选择Log File-->在Shrink Mode中选择Shrink to XXM，这里会给出一个shrink to allow最小M数，直接输入这个合适的数，确认即可。

二、删除Log文件：

这种方式有一定的风险，因为SQL Server的日志文件并不是实时写入数据库的主文件，如果处理不当，会造成数据丢失。

步骤：分离数据库企业管理器-->服务器-->数据库-->右击-->分离数据库。

然后删除LOG文件，再附加数据库：

附加数据库企业管理器 --> 服务器 --> 数据库 --> 右键单击​​ --> 附加数据库。

这个方法生成了一个新的LOG，大小只有500K多。

如果不希望日志文件无限增长以至于过大，可以给日志文件设置一个最大值，如下：

Enterprise Manager --> Server --> 右击Database --> Properties --> Transaction Log --> Limit file growth to xM（x是你允许的最大数据文件大小）

使用SQL语句设置如下：

alterdatabase库名modifyfile(name=逻辑文件名,maxsize=20)

附上sys.databases表中log_reuse_wait_desc列的值的含义：

log_reuse_wait 值

log_reuse_wait_desc 值

阐明

没有什么

当前有一个或多个可以重复使用的虚拟日志文件。

1个

检查点

自上次日志截断以来数据库事务日志文件，未出现检查点，或者日志头未跨虚拟日志文件移动（所有恢复模式）。

这是日志截断延迟的常见原因。 有关详细信息，请参阅检查点和日志的活动部分。

2个

日志备份

需要日志备份以向前移动日志标头（仅限完整或批量日志恢复模型）。

注意：日志备份不会阻止截断。

日志备份完成后，日志标头会提前，并且一些日志空间可能可供重用。

3个

ACTIVE_BACKUP_OR_RESTORE

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

数据备份与活动事务一样工作； 当数据备份运行时，截断被阻止。 有关详细信息，请参阅本主题后面的“数据备份和还原操作”部分。

4个

ACTIVE_TRANSACTION 交易

事务处于活动状态（所有恢复模式）。

· 在日志备份开始时，可​​能有长时间运行的事务。 在这种情况下，释放空间可能需要额外的日志备份。 有关详细信息，请参阅本主题后面的“长时间运行的活动事务”部分。

· 事务将被延迟（仅适用于 SQL Server 2005 企业版及更高版本）。 “延迟事务”实际上是一个活动事务数据库事务日志文件，由于某些资源不可用而导致回滚被阻塞。 有关导致事务延迟的原因以及如何使它们脱离延迟状态的信息，请参阅延迟事务。

5个

数据库镜像

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

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

6个

复制

在事务复制期间，与发布相关的事务仍未传递到分发数据库（仅限完整恢复模型）。

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

7

DATABASE_SNAPSHOT_CREATION

创建数据库快照（所有恢复模型）。

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

8个

日志扫描

正在进行日志扫描（所有恢复模式）。

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

9

OTHER_TRANSIENT

该值当前未使用。