日志文件不断增长

原文:日志文件不断增长

 

先了解SQLServer需要保存的日志记录:

 

1、  所有没有经过“检查点”的日志记录:

 

       SQLServer定时执行(Checkpoint),保证“脏页”被写入硬盘。没做Checkpoint的,可能是只在内存中修改,数据文件还没同步。SQLServer要在硬盘的日志文件中有记录,一边异常重启后重新修改。

 

2、  所有没有提交的事务所产生的日志及其后续的日志记录:

 

      所有日志都有严格顺序,不能有跳跃。

 

3、  要做备份的日志记录:

 

       如果恢复模式不是简单模式,那么SQLServer会认为用户是要去备份日志记录的。所有没备份的记录都会保留。

 

4、  有其他需要读取日志的数据库功能:

 

      如事务型复制(Transactional Replication)和镜像。

       除以上的类型之外,其他类型会在Checkpoint时做截断把占用的空间标志为可重用。如果重用空间足够,是不会报告日志空间已满。Checkpoint的频率由服务器的“Recovery Interval”决定,默认为一分钟左右。

 

通常日志不断增长的原因有:

 

1、  数据库恢复模式不是简单,但是没有做日志备份:

 

       在这种模式下,做完整备份和差异备份是不会截断日志的。

 

2、  数据库上有一个很长时间都没有提交的事务:

 

       SQLServer不会干预前端程序的连接遗留事务在SQLServer中的行为。只要不退出,事务会一直存在,直到(此处原为知道,谢谢kalagooooo的细心发现,现以改正过来)前端主动提交或者回滚。此时做日志备份也没用了。

 

3、  数据库上有一个很大的事务在运行:

 

       如建立、重建索引。或者insert/delete大量数据。或者是服务器端游标没有把数据及时取走。

 

4、 数据库复制或镜像出了异常

 

        要避免上述现象,来防止日志不断增长。对于不会做日志备份的数据库,设为简单模式即可。如果是完整模式,一定要定期做日志备份。如果镜像或复制除了问题,要及时处理,如果没有处理,那么要暂时拆除复制或镜像。程序设计时,也要避免事务时间过长、过多。

 

 

对于日志增长处理:

 

步骤1:检查日志现在使用情况和数据库状态:

       检查日志使用百分比、恢复模式和日志重用等待状态。从2005以后,sys.databases加入了log_reuse_wait(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


事务处于活动状态(所有模式)


5


DATABASE_MIRRORING


数据库镜像滞后(完整模式)


6


REPLICATION


在事务复制中,与发布相关的事务仍未传递到分发数据库(仅限于完整模式)


7


DATABASE_SNAPSHOT_CREATEION


正在创建数据库快照(所有模式)


8


LOG_SCAN


正在进行日志扫描(所有模式)


9


OTHER_TRANSIENT


此值当前未使用

 

使用以下脚本检查:

 

DBCC SQLPERF(LOGSPACE)
GO
SELECT name,recovery_model_desc,log_reuse_wait,log_reuse_wait_desc
FROM sys.databases
GO

 

如果Log Space Used(%)很高,就要马上定位为什么不能被清除。如果状态为:LOG_BACKUP,就意味(此处原为以为,感谢kalagooooo的细心发现,现以改正过来)着SQLServer,意味着SQLServer等待着日志备份。要检查是否需要做日志备份。

 

步骤2:检查最久的活动事务:

         如果大部分日志都在使用中且重用状态为:ACTIVE_TRANSACTION,那么要看看最久的事务是谁申请的:

 

DBCC OPENTRAN
GO
SELECT  *
FROM    sys.dm_exec_sessions AS t2 ,
        sys.dm_exec_connections AS t1
        CROSS APPLY sys.dm_exec_sql_text(t1.most_recent_sql_handle) AS st
WHERE   t1.session_id = t2.session_id
        AND t1.session_id > 50

 

执行后返回:

 

 

找出最久的事务之后,先要检查是否有问题,如果有问题,那么最好从应用层面把事务提交或回滚。如果实在不行,那就使用KILL SPID来杀掉进程。

 

时间: 2024-11-02 17:15:49

日志文件不断增长的相关文章

你还可以再诡异点吗——SQL日志文件不断增长

前言   今天算是遇到了一个罕见的案例. SQL日志文件不断增长的各种实例不用多说,园子里有很多牛人有过介绍,如果我再阐述这些陈谷子芝麻,想必已会被无数次吐槽. 但这次我碰到的问题确实比较诡异,其解决方式也是我第一次使用. 下文将为各位看管详细介绍我的解决思路.   现象   一客户反馈数据库的日志文件不断增长,已分配的磁盘空间快使用完,尝试过事务日志截断(事务日志备份)的操作,但没有任何效果.   分析   遇到这个问题,我最直接的感受:肯定有大的事务一直在执行,导致日志备份无法截断事务日志的

Oracle监听日志文件过大如何处理

Oracle监听器日志文件(通常叫做listener.log)是一个纯文本文件,它的大小是一直不断增长的,在一个生产Oracle服务器上,DBA会每日查看该文件,如检查监听器是否有异常停止,是否有恶意攻击连接等,当这个文件特别大的时候,打开和浏览文件内容时可能比较慢.这时可能会想到将当前的日志文件备份一下,然后重新创建一个新的日志文件,但Oracle的监听器在运行时是不允许对其日志文件做删除,重命名操作,于是只有停止监听器.重命名后,再启动监听器,启动时会自动创建一个新的监听器日志文件,但这样客

AIX 日志清理 监听日志清理--过大的Oracle监听日志文件处理

AIX 日志清理 监听日志清理--过大的Oracle监听日志文件处理 Oracle监听器日志文件(通常叫做listener.log)是一个纯文本文件,它的大小是一直不断增长的,在一个生产Oracle服务器上,DBA会每日查看该文件,如检查监听器是否有异常停止,是否有恶意攻击连接等,当这个文件特别大的时候,打开和浏览文件内容时可能比较慢.这时可能会想到将当前的日志文件备份一下,然后重新创建一个新的日志文件,但Oracle的监听器在运行时是不允许对其日志文件做删除,重命名操作,于是只有停止监听器.重

MS SQL 需要定期清理日志文件

前言碎语     关于对SQL SERVER 日志文件管理方面了解不多的话,可以参考我的这篇博客文章"MS SQL 日志记录管理", 不过这篇文章只是介绍对SQL SERVER日志记录的深入认知了解,并没有提出如何管理日志文件的方案,如果你有兴趣的话,倒不妨可以钻研一下如何管理.提取日志记录信息,这是数据库 精细化管理的一个方面,如果手头管理的服务器过多,事情过多,你很难做到精细化管理!很多事情都忙不过来,需要时间去做!   问题现象     这几天有台数据库服务器一天会收到8封左右的

小心MOSS日志文件膨胀

最近为了项目的需要,在我本已不堪重负的本本上装了个AD和MOSS.MOSS装的是2007 SP1,然后打上了好几百兆的补丁,用了一下还勉强可以使用,就只有把本本作为MOSS的开发环境了. 我30G的C盘,在装MOSS之前大概还有3个G左右,由于用的是Windows2008,装下来操作系统就占用了10G,我其他软件是能装D盘的就装D盘了,但是不知道为什么还是很快把30G的C盘快用完了.这下装了MOSS以后也就还有1个多G的空间了,将就用吧.但是用了两天后系统就报警C盘空间只剩下几十兆了! 太恐怖了

应用商店-(iOS)有个日志文件,希望能帮忙分析一下,说是在程序加载的时候,应用程序崩溃了。

问题描述 (iOS)有个日志文件,希望能帮忙分析一下,说是在程序加载的时候,应用程序崩溃了. 10C http://a103.phobos.apple.com/us/r30/Purple7/v4/38/1e/87/381e875f-bdf2-b8ed-33b6-b56cb1a6165b/temp..rgbcntpc.crash?downloadKey3=1449655120_daec0230692a58a1ba3f2a4c2d24b499 http://a1363.phobos.apple.co

关于数据库日志文件清空的问题

问题描述 关于数据库日志文件清空的问题 如何实现清空数据库日志文件的使用空间?不通过压缩数据库日志文件. 也就是在执行 dbcc sqlperf(logspace) 命令之后,出现的结果集中,有Database,Logsize,LogSpaceUsed(%),Status这四列数据. 怎么能实现,在不压缩LogSize的情况下,是LogSpaceUsed(%)的值变大. 对于SQL Server 2008的 USE [master] GO ALTER DATABASE DNName SET RE

教你如何缩小SQL SERVER日志文件

前几天也碰到日志文件过大的问题,数据库实际大小为600M, 日志文件实际大小为33M, 但日志文件占用空间为2.8G!!! 试了多种方式,SHIRNK DATABASE, TRUNCATE LOG FILE, 都没办法将文件缩小.无论如何,这应该算SQL SERVER的一个BUG吧. 后来找到下面的代码,就可以将日志文件缩小到自己想要的大小了.把代码COPY到查询分析器里,,然后修改其中的3个参数(数据库名,日志文件名,和目标日志文件的大小),运行即可(我已经用过多次了) ----- SET N

如何修改MySQL日志文件位置?

MySQL日志文件相信大家都有很多的了解,MySQL日志文件一般在:/var/log/mysqld.log,下面就教您修改MySQL日志文件位置的方法,供您参考. 今天需要改MySQL日志文件的位置,发现在/etc/my.cnf中怎么也改不了. 后来发现MySQL日志位是指定的: [root@localhost etc]# ps auxgrep mysqld   root     11830 0.5 0.0   4524 1204 pts/0    S    03:03   0:00 /bin/