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

庋藏天下 2015-10-26

展开全文

数据库的事务日志已满。若要查明无法重用日志中的空间的原因，请参阅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 此值当前未使用。

本文来自：.Net学习网 http://www./ac/ID983
======================================================

清除日志啦
USE [master]
GO
ALTER DATABASE [exam] SET RECOVERY SIMPLE WITH NO_WAIT
GO
ALTER DATABASE [exam] SET RECOVERY SIMPLE --简单模式
GO
USE [exam]
GO
DBCC SHRINKFILE (N' 日志文件名' , 1, TRUNCATEONLY) --日志文件名要完整路径
GO
USE [master]
GO
ALTER DATABASE [exam] SET RECOVERY FULL WITH NO_WAIT
GO
ALTER DATABASE [exam] SET RECOVERY FULL --还原为完全模式
GO

=======================================================

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

(2012-03-12 14:03:40)

http://blog.sina.com.cn/s/blog_5b68649a01013edq.html

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

先在MSSQL查询分析器里执行一下下面的命令,如果无法解决问题再继续往下看.

backup log dbname with no_log --dbname要清除事物日志的数据库名
go

dbcc shrinkdatabase(dbname)
go

以下是从微软网站复制过来的文章,有耐心的朋友仔细看看,应该可以解决问题!

本主题讨论对已满事务日志可以采取的几种应对措施，并就以后如何避免出现已满事务日志给出建议。如果事务日志已满，则 SQL Server 数据库引擎会发出 9002 错误。当数据库在线或恢复时，日志可能会满。如果数据库在线时日志已满，则数据库保持在线状态，但是只能进行读取而不能更新。如果恢复过程中日志已满，则数据库引擎将数据库标记为 RESOURCE PENDING。不管哪种情况，都需要用户执行操作才能使日志空间可用。

数据库 <wbr>'dbname' <wbr>的事务日志已满。若要查明无法重用日志中的空间的原因，请参阅 <wbr>sys.databases <wbr>中的 <wbr>lo

应对已满事务日志

正确响应已满事务日志在某种程度上取决于导致日志已满的情况。若要在给定情况下查找阻止日志截断的原因，请使用 sys.database 目录视图的 log_reuse_wait 列和 log_reuse_wait_desc 列。有关详细信息，请参阅 sys.databases (Transact-SQL)。有关延迟日志截断的因素的说明，请参阅导致日志截断延迟的因素。

重要提示：
如果数据库在恢复过程中出现 9002 错误，则在解决此问题后，可使用 ALTER DATABASE database_name SET ONLINE 恢复数据库。

响应已满事务日志的备选方法包括：

备份日志。
释放磁盘空间以便日志可以自动增长。
将日志文件移到具有足够空间的磁盘驱动器。
增加日志文件的大小。
在其他磁盘上添加日志文件。
完成或取消长时间运行的事务。

下列部分介绍了这些备选方法。请选择最适用于您情况的响应。

注意：
强行截断日志会破坏日志链，并在下次完整备份数据库之前使数据库处于容易受到攻击的状态。因此，未来版本的 SQL Server 将从 BACKUP 语句中删除 TRUNCATE_ONLY 选项。应避免使用此选项进行新的开发工作，并计划修改当前使用它的应用程序。