错误"数据库的事务日志已满。若要查明无法重用日志中的空间的原因"的解决方法

今天系统突然报出如下错误:

数据库的事务日志已满。若要查明无法重用日志中的空间的原因,请参阅sys.databases中的log_reuse_wait_desc列

到服务器上查看后发现,是因为数据库日志所在的磁盘空间满了,移出该盘部分文件后,系统就恢复正常了。又在网上查了一下该错误,如果要从日志文件本身来解决,可用以下两种方法解决:
一,清空日志:
步骤:1,备份日志文件。2,压缩日志文件。
1,备份日志文件,可使用如下sql命令:
DUMP TRANSACTION 数据库名 WITH NO_LOG

2,打开企业管理器,在数据库上点右键->属性->选项->故障恢复-模型-选择-简单模型。(也可以直接在查询分析器里执行:
alter database 数据库名 set recovery simple

3.右键点击要压缩的数据库-->所有任务-->收缩数据库-->收缩文件-->选择日志文件-->在收缩方式里选择收缩至XXM,这里会给出一个允许收缩到的最小M数,直接输入这个一个合适的数,确定就可以了。

二,删除Log文件:
这种方法有一定的风险性,因为SQL SERVER的日志文件不是即时写入数据库主文件的,如处理不当,会造成数据的损失。
步骤:分离数据库 企业管理器-->服务器-->数据库-->右键-->分离数据库。
然后删除LOG文件,再附加数据库:
附加数据库 企业管理器-->服务器-->数据库-->右键-->附加数据库。
此法生成新的LOG,大小只有500多K。

若不想日志文件无限制的增长以至于太大,可以为日志文件设置一个最大值,方法如下:
企业管理器-->服务器-->右键数据库-->属性-->事务日志-->将文件增长限制为xM(x是你允许的最大数据文件大小) 

使用SQL语句设置如下:
alter database 库名 modify file(name=逻辑文件名,maxsize=20)

附带上sys.databases表中的log_reuse_wait_desc列的各值的意思:

log_reuse_wait值 log_reuse_wait_desc值 说明
0 NOTHING 当前有一个或多个可重用的虚拟日志文件。
1 CHECKPOINT 自上次日志截断之后,尚未出现检查点,或者日志头部尚未跨一个虚拟日志文件移动(所有恢复模式)。 
这是日志截断延迟的常见原因。 有关详细信息,请参阅检查点和日志的活动部分。
2 LOG_BACKUP 要求日志备份将日志标头前移(仅适用于完整恢复模式或大容量日志恢复模式)。

注意:日志备份不会阻止截断。
日志备份完成后,日志标头将前移,并且一些日志空间可能会变为可重新使用。
3 ACTIVE_BACKUP_OR_RESTORE 数据备份或还原正在进行(所有恢复模式)。 
数据备份与活动事务的工作原理相同;数据备份运行时,将阻止截断。 有关详细信息,请参阅本主题后面的“数据备份操作与还原操作”部分。
4 ACTIVE_TRANSACTION 事务处于活动状态(所有恢复模式)。 

·在日志备份开始时,可能存在长时间运行的事务。 在这种情况下,释放空间可能需要进行其他日志备份。 有关详细信息,请参阅本主题后面的“长时间运行的活动事务”部分。 
·事务将延迟(仅适用于 SQL Server 2005 Enterprise Edition 及更高版本)。 “延迟的事务”实际上是其回滚由于某些资源不可用而受阻的活动事务。 有关导致事务延迟的原因以及如何使它们摆脱被延迟状态的信息,请参阅延迟的事务.

5 DATABASE_MIRRORING 数据库镜像暂停,或者在高性能模式下,镜像数据库明显滞后于主体数据库(仅限于完整恢复模式)。 
有关详细信息,请参阅本主题后面的“数据库镜像与事务日志”部分。
6 REPLICATION 在事务复制过程中,与发布相关的事务仍未传递到分发数据库(仅限于完整恢复模式)。 
有关详细信息,请参阅本主题后面的“事务复制与事务日志”部分。
7 DATABASE_SNAPSHOT_CREATION 正在创建数据库快照(所有恢复模式)。 
这是日志截断延迟的常见原因,通常也是主要原因。
8 LOG_SCAN 正在进行日志扫描(所有恢复模式)。 
这是日志截断延迟的常见原因,通常也是主要原因。
9 OTHER_TRANSIENT 此值当前未使用。

你可能感兴趣的:(SQL,Server)