Msg 9002 The transaction log for database '' is full

本文涉及的产品
日志服务 SLS,月写入数据量 50GB 1个月
简介:

今天有个朋友说他的数据库报错,错误信息如下:

 

Msg 9002, Level 17, State 2, Line 4
The transaction log for database '' is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc column in sys.databases

 

这个错误是很常见的,日志文件满了,但是导致日志满的原因会有很多,怎么查呢?其实这个错误已经给了我们很大的提示,查询sys.databases中的log_reuse_wait_desc列.查询sys.databases:

 

SELECT log_reuse_wait_descFROMsys.databasesWHERE[name]='database';

得到的值为:LOG_BACKUP,说明需要运行日志备份解决这个问题。所以对数据库进行一个日志备份:

 

BACKUPLOG DatabaseAtoDISK='D:\MSSQL\databaseAckup.trn';

备份完成后问题解决,之后再查log_reuse_wait_desc得到值为:NOTHING(当前有一个或多个可重复使用的虚拟日志文件。)

 

 

下面我列出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

当前未使用此值。

 

另外一个常见的引起日志满的因素是Longrunningtransaction,我们在查询sys.databases后可以看到ACTIVE_TRANSACTION,然后根据DBCC OPENTRAN找出没有CommitSPID进行处理。

 

下面是运行DBCC OPENTRAN的结果集:

 

Transaction information for database 'master'.

Oldest active transaction:

SPID (server process ID) : 52

UID (user ID) : -1

Name : user_transaction

LSN : (518:1576:1)

Start time : Jun 1 2004 3:30:07:197PM

SID : 0x010500000000000515000000a065cf7e784b9b5fe77c87709e611500

DBCC execution completed. If DBCC printed error messages, contact your system administrator.


本文转自 lzf328 51CTO博客,原文链接:


http://blog.51cto.com/lzf328/1002162

相关实践学习
通过日志服务实现云资源OSS的安全审计
本实验介绍如何通过日志服务实现云资源OSS的安全审计。
相关文章
|
7月前
|
SQL 缓存
【YashanDB知识库】YashanDB run.log中有slow log queue is full信息
【YashanDB知识库】YashanDB run.log中有slow log queue is full信息
|
7月前
|
数据库
【YashanDB数据库】YAS-02079 archive log mode must be enabled when database is in replication mode
YAS-02079 archive log mode must be enabled when database is in replication mode
【Unity3D 问题总结】Unity报错提示:Asset database transaction committed twice
也找不到代码哪里出错了,新建查空场景运行也会报错,真是离了个大谱! 然后打开UnityHub发现原来是许可证过期了!!
【Unity3D 问题总结】Unity报错提示:Asset database transaction committed twice
|
SQL 人工智能 JSON
深度解析Delta Transaction Log
深度解析Delta Transaction Log
深度解析Delta Transaction Log
|
SQL 存储 数据库
处理令人心烦的数据库事务日志 (SQL Server Transaction Log Files)
经常, 我们会被过快增长的数据库事务日志Transaction Log而困扰, 如果我们没有正确及时的处理, 可能会造成数据库交易无法进行, 服务器磁盘空间占光等问题. 在SQL Server的使用过程中, 我经常帮助用户和数据库的维护人员处理日志Transaction Log太大后造成的系统瘫痪的问题. 其实这个问题很容易避免. 今天我给大家分享下, 是什么造成了日志增长过大的问题. 和如何避免这种问题再次发生. 该文章的语句适用于SQL Server 2015 及其以后的版本 每一个数据库至少有两个文件: 一个是数据文件(Data file), 一个是事务日志文件(Transaction
976 0