SQL 2008 日志管理解决方法

2013-11-23

SQL 2008 日志管理在SQL SERVER 2000/2005中，收缩数据库日志文件的sql语句如下：DUMP TRAN DBName WITH NO_

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,   --要收缩的数据文件逻辑名称  
                10 --收缩之后为10MB
                ) 
我用下列语句执行后日志文件从300M压缩到了19M。
BACKUP LOG NAVTEQ_TMC to disk='C:\1.bak'
DBCC SHRINKFILE (NAVTEQ_log,10)
通过backup 截断日志的作用是什么？我不截断它不也是可以压缩日志吗？
如果是full模式，只有先通过截断日志，才有可能压缩。其实就是标记了一下，这些日志没用了，可以被覆盖了。

如果你是simple，那就不用截断日志了，直接压缩。
谢谢yupeigu的耐心回答，刚才我测试了下发现我在full模式下没有截断日志也可以直接压缩啊。这是什么情况？
对，这个是一个特例，在把数据库的恢复模式改为full模式后，仍然你可以压缩，截断日志。

只有在full模式之后，并且做了一个完整备份，且做一个日志备份后，sql server才认为，日志对于你是重要的，那么这种情况下，通过备份日志，才能截断日志。
你把我搞糊涂了，什么是full模式之后？简单模式吗？不是说在full模式下必须先备份截断日志才能被压缩吗？可是我没备份截断过日志，也没备份过DB也可以直接压缩啊。

呵呵，这个是有点搞的，sql server默认在full模式下，不需要备份日志，也可以截断日志的。

所以“可是我没备份截断过日志，也没备份过DB也可以直接压缩啊。”你的这个才成立。

而在full模式下，如果已经做了完整备份，且有第一次备份了日志，你这个“可是我没备份截断过日志，也没备份过DB也可以直接压缩啊。”就不行了。

热点排行

SQL Server

SQL 2008 日志管理解决方法