日志文件不断增长

来源:互联网 发布:扫描ip地址软件 编辑:程序博客网 时间:2024/04/29 23:26

 

先了解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)来反映不能截断日志的原因 --感谢http://blog.csdn.net/yenange 的提醒,对原文“阶段”修改回“截断”

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)GOSELECT name,recovery_model_desc,log_reuse_wait,log_reuse_wait_descFROM sys.databasesGO


 

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

 

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

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

 

DBCC OPENTRANGOSELECT  *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 stWHERE   t1.session_id = t2.session_id        AND t1.session_id > 50


 

执行后返回:

 

 

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

 

原创粉丝点击