日期:2014-05-17  浏览次数:20563 次

SQL 2008 日志管理

在SQL SERVER 2000/2005中,收缩数据库日志文件的sql语句如下:
DUMP TRAN DBName WITH NO_LOG
BACKUP   LOG   DBName WITH   NO_LOG  
DBCC SHRINKFILE(DBName_Log)

然而在SQL 2008中已经弃用了此功能,在网上找了一翻之后可通过以下语句来收缩日志:

USE [master]
GO
ALTER DATABASE DBName SET RECOVERY SIMPLE WITH NO_WAIT
GO
ALTER DATABASE DBName  SET RECOVERY SIMPLE
GO
USE DBName 
GO
DBCC SHRINKFILE (N'LogFileName' , 0,TRUNCATEONLY)
GO
USE [master]
GO
ALTER DATABASE DBName  SET RECOVERY FULL WITH NO_WAIT
GO
ALTER DATABASE DBName  SET RECOVERY FULL
GO

而且也说明了执行此语句的优缺点:

说明:优点:此清除日志所运行消耗的时间短。缺点:不过此动作最好不要经常使用,因为它的运行会带来系统碎片。普通状态下LOG和DIFF的备份即可截断日志。此语句使用的恰当环境:当系统的日志文件异常增大或者备份LOG时间太长可能影响生产的情况下使用。


对于此说明有几个不明白的地方在这问下高手们:
1. 运行此命令会带来系统碎片,这个碎片指的是什么? 
2. 普通状态下LOG和DIFF的备份即可截断日志,什么叫普通状态下? 备份日志就可截断日志,截断日志后是不是会清空不活跃的日志?如果清空则 什么叫“不活跃的日志”? 
3. 我所使用的数据库数据每天生成几百万条之后,基本都是用于查询。然而我想在每隔一两天就压缩情况下日志,这样是否会影响数据库的性能和完整性。
 


在网上查了很多资料都是copy的,都是这句话,没有一个详细介绍的。所以在这希望能得到满意的答案。
日志 数据库 压缩 SQL log

------解决方案--------------------
引用:
Quote: 引用:

首先,不建议你通过把数据库的恢复模式变化为simple,然后采用收缩日志文件的方法,来压缩日志。

1.你收缩日志,相当于是在物理的角度,这个碎片,应该是指日志不连续了,因为你使用物理的方法,来搬运日志,把日志从A搬到B,空出来的空间,就被压缩掉了

2.这个就是一般情况,就是你的数据库时在full恢复模式下,通过备份日志,就可以,自动截断日志。

这个截断日志,应该不是说清空日志,只是做了个标记,表示这部分日志能循环使用了。

3.建议不要这么做,如果你的数据库正常还好,要是出了问题,你就会丢失数据的


那截断日志 日志是否被压缩过,日志文件是否会变小?比例大概是多少?比如100G的日志备份之后大概是多少个G?
压缩才减少日志的大小,截断仅“标识可重用”,没有比例可言,dbcc sqlperf(logspace)可以看到你的日志用了百分之多少
------解决方案--------------------
引用:
Quote: 引用:

Quote: 引用:

Quote: 引用:

Quote: 引用:




Quote: 引用:

Quote: 引用:

Quote: 引用:

首先,不建议你通过把数据库的恢复模式变化为simple,然后采用收缩日志文件的方法,来压缩日志。

1.你收缩日志,相当于是在物理的角度,这个碎片,应该是指日志不连续了,因为你使用物理的方法,来搬运日志,把日志从A搬到B,空出来的空间,就被压缩掉了

2.这个就是一般情况,就是你的数据库时在full恢复模式下,通过备份日志,就可以,自动截断日志。

这个截断日志,应该不是说清空日志,只是做了个标记,表示这部分日志能循环使用了。

3.建议不要这么做,如果你的数据库正常还好,要是出了问题,你就会丢失数据的


那截断日志 日志是否被压缩过,日志文件是否会变小?比例大概是多少?比如100G的日志备份之后大概是多少个G?


日志文件,应该是被收缩了,能收缩多少,这个不确定,能收缩多少,但是你可以指定你要的目标大小:



DBCC SHRINKFILE(xx,   --要收缩的数据文件逻辑名称