Msg 9002 The transaction log for database '' is full

简介:

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

 

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

相关实践学习
日志服务之使用Nginx模式采集日志
本文介绍如何通过日志服务控制台创建Nginx模式的Logtail配置快速采集Nginx日志并进行多维度分析。
相关文章
|
数据库
Exception: The transaction log for database is full. To find out why space in the log cannot be reused, see the log_reuse_wait_desc.错误解决
升级数据库到最后一步,X,遇错。 还好,是定位数据库错误,以前怕LOG日志变大,作了限制。 取消即可。 顺便列几条要用的命令:   New-SPWebApplication -Name "Helios80" -ApplicationPool "helios80AppPool" -Aut...
1278 0
|
23天前
|
Java
使用Java代码打印log日志
使用Java代码打印log日志
77 1
|
24天前
|
Linux Shell
Linux手动清理Linux脚本日志定时清理日志和log文件执行表达式
Linux手动清理Linux脚本日志定时清理日志和log文件执行表达式
78 1
|
28天前
|
SQL 关系型数据库 MySQL
MySQL数据库,可以使用二进制日志(binary log)进行时间点恢复
对于MySQL数据库,可以使用二进制日志(binary log)进行时间点恢复。二进制日志是MySQL中记录所有数据库更改操作的日志文件。要进行时间点恢复,您需要执行以下步骤: 1. 确保MySQL配置文件中启用了二进制日志功能。在配置文件(通常是my.cnf或my.ini)中找到以下行,并确保没有被注释掉: Copy code log_bin = /path/to/binary/log/file 2. 在需要进行恢复的时间点之前创建一个数据库备份。这将作为恢复的基准。 3. 找到您要恢复到的时间点的二进制日志文件和位置。可以通过执行以下命令来查看当前的二进制日志文件和位
|
1月前
|
监控 Shell Linux
【Shell 命令集合 系统管理 】Linux 自动轮转(log rotation)日志文件 logrotate命令 使用指南
【Shell 命令集合 系统管理 】Linux 自动轮转(log rotation)日志文件 logrotate命令 使用指南
51 0
|
1月前
|
存储 数据库
ALTER MATERIALIZED VIEW LOG :语句来更改现有物化视图日志的存储特征或类型。
`ALTER MATERIALIZED VIEW LOG` 语句用于修改已有的物化视图日志的存储属性或类型。配合示例中的动画图像(由于格式限制无法显示),该语句帮助优化数据库的性能和管理。
44 0
|
3天前
|
Java
log4j异常日志过滤规则配置
log4j异常日志过滤规则配置
13 0
|
15天前
|
运维 安全 Ubuntu
`/var/log/syslog` 和 `/var/log/messages` 日志详解
`/var/log/syslog` 和 `/var/log/messages` 是Linux系统的日志文件,分别在Debian和Red Hat系发行版中记录系统事件和错误。它们包含时间戳、日志级别、PID及消息内容,由`rsyslog`等守护进程管理。常用命令如`tail`和`grep`用于查看和搜索日志。日志级别从低到高包括`debug`到`emerg`,表示不同严重程度的信息。注意保护日志文件的安全,防止未授权访问,并定期使用`logrotate`进行文件轮转以管理磁盘空间。
21 1

热门文章

最新文章