SQL2008如何压缩日志(log)文件?

在SQL2000/2005中可以快速压缩日志log文件,通过SQL,

方法一:

--BigData为数据库名
DUMP TRANSACTION BigData WITH NO_LOG
BACKUP LOG BigData WITH NO_LOG
DBCC SHRINKDATABASE(BigData )

执行以上语句可以快速压缩日志文件到1M。

但是以上语句中前两行在SQL 2008下无法执行 ,

第一行提示“Incorrect syntax near the keyword 'TRANSACTION'.”

第二行提示“One or more of the options (no_log) are not supported for this statement. Review the documentation for supported options. ”

第三行可以执行。但日志log文件没有任何变化。

原来SQL 2008 已经不再支持 DUMP TRANSACTIONBACKUP LOG WITH NO_LOG详情请看
  http://msdn.microsoft.com/zh-cn/library/ms187315%28SQL.90%29.aspx
  http://msdn.microsoft.com/zh-cn/library/ms186865.aspx 

sql2005说明中明确:包含 DUMP 语句是为了向后兼容。而 后续版本的 Microsoft SQL Server 将删除该功能。请避免在新的开发工作中使用该功能,并着手修改当前还在使用该功能的应用程序。 使用 BACKUP。

SQL2008说明:BACKUP LOG WITH NO_LOG 和 WITH TRUNCATE_ONLY 选项已废止。使用完整恢复模式或大容量日志恢复模式时,如果必须删除数据库中的日志备份链,请切换至简单恢复模式。有关详细信息,请参阅有关从完整恢复模式或大容量日志恢复模式切换的注意事项。

尝试方法二:  

----Logical Files :
--
CMS1.5_Data
--
CMS1.5_Log
DBCC SHRINKFILE (N'CMS1.5_Log' , 1)
GO

无效。

尝试方法三:  

代码
use DB_NAME
sp_dboption 
DB_NAME, "trunc. log on chkpt.", true
checkpoint
sp_dboption 
DB_NAME, "autoshrink", true

每一行指令请单独执行。其中的DB_NAME是指Database Name,在下完语法后的数小时至数十小时,该LOG档会逐渐释放空间,最后大约都会维持在数1024KB左右

有没有更快的方法呢?

尝试方法四:(请提前备份文件!!)

1. Detach数据库。
2.删除log文件。
3. 附加数据库,选移除log文件,此时SQL Server 会自动重新建立一个512K 的Log 文件。

附图:

邀月工作室
邀月工作室

邀月工作室

邀月工作室

方法五(没有试试,请提前备份文件!!):

 
1. 停止 SQL Server 的服务
 
2. 使用删除 Log文件
 
3. 重新启动SQL Server 服务,此时SQL Server 会自动重新建立一个1MB 的Log 文件。
方法六: (尘尘提供)

先设置恢复模式为“简单恢复”模式,再收缩:

USE BigData ;
GO
ALTER DATABASE BigData
SET RECOVERY SIMPLE;--设置简单恢复模式
GO
DBCC SHRINKFILE (BigData_Log, 1);
GO
ALTER DATABASE BigData
SET RECOVERY FULL;--恢复为原模式
GO 

 方法七: (尘尘提供)

USE BigData;
GO
BACKUP LOG DATABASENAME TO DISK='d:\test.bak'
-- Shrink the truncated log file to 1 MB.
DBCC SHRINKFILE (Bigdata_Log, 1);
GO


邀月注:本文版权由邀月和博客园共同所有,转载请注明出处。
助人等于自助!  3w@live.cn
posted @ 2009-12-13 15:12 邀月 阅读(3099) 评论(16) 编辑 收藏

 回复 引用 查看   
#1楼 2009-12-13 18:52 Vincent Yang      
方法2不是无效,是因为你少了一步,你先需要把备份模式换成simple mode然后才能shrink
 回复 引用 查看   
#2楼[楼主] 2010-01-21 09:31 邀月      
@Vincent Yang
最近看了《Microsoft Sql server 2008 Internal》,你说的是对的。

 回复 引用 查看   
#3楼 2010-01-21 09:37 Vincent Yang      
@邀月
不是我说的是对的,是因为msdn就是这么写的

 回复 引用 查看   
#4楼 2010-03-02 20:15 尘尘      
方法一在08里面已经不行,而且就算在这个也是一个非常危险的做法,所以是极端极端极端不推荐的
方法二在绝大多数情况下会没有作用
方法三接近正确了
至于方法四和方法五基本不存在不出问题的可能,除非你之前执行了checkpoint,而且没有任何其他人修改数据(最完美的就是在执行checkpoint之前设置为单用户模式),但是依然有很大的风险

正解:
一、完整备份一下数据库,如果之前有完整备份了,那么这里只需要备份一下日志即可
二、执行checkpoint
三、dbcc shrink,至于你shrink的是database或者是file都无所谓了
四、如果还不行的话,执行下面语句:
select log_reuse_wait_desc from sys.databases where name = 'databasename'
根据select出来的结果看是哪里出问题了,解决完问题之后,执行上面的checkpoint以及之后的步骤

日志文件不能压缩的话,要从日志的工作原理上面找原因,至于说日志的工作原理,不知道网上有没有,我这里有一些资料,不过我要问问有问题没,然后看看能发不能

以上是针对full模式的,simple模式的话就懒得提了,基本上shrink都可以成功

其实shrink成功与否最大最关键的问题在于:
一、在第一次shrink之前,要对数据库进行一次完整备份(或者说是仅仅对日志备份,这一点我忘了,你可以尝试一下)
二、在每一次shrink之前,备份一下日志

 回复 引用 查看   
#5楼[楼主] 2010-03-03 21:05 邀月      
引用尘尘:
日志文件不能压缩的话,要从日志的工作原理上面找原因

这是最大的正解!
我最近看了书的的日志部分,还没理清楚,你可以先把你的资料共享出来看看,稍后,我也会抽空把我的分享出来。

 回复 引用 查看   
#6楼 2010-03-03 21:29 尘尘      
@邀月
回头我问问,上面说的很详细,但是不敢拿出来。。。

 回复 引用 查看   
#7楼[楼主] 2010-03-03 21:41 邀月      

引用尘尘:
@邀月
回头我问问,上面说的很详细,但是不敢拿出来。。。

上面莫非有视频?哈哈

 回复 引用 查看   
#8楼 2010-03-03 22:26 尘尘      
@邀月
视频倒是没有,不过就算有了我也看不懂,呵呵
我英语太烂了,参加了一次toastmaster,有百分之八十没听懂
主要不知道那些资料哪里来的,等我确定来源并确定没问题再说吧

我记性不好,大概工作原理是这样的:
每次对数据的修改都会先记录到log文件里面,然后不知道什么时候(真的,除了你执行checkpoint)会写入data文件里面,对于simple来说,应该是等事务完成后就直接写入吧
写入到log文件里面的不是具体的语句,而是前后的数据变化,有一个语句可以查看日志文件的内容来着,我忘了。。。原谅我吧
日志文件是分成多个单元的(每次日志文件大小不够用了,就会多分配一些空间,这个新分配的就是一个单元,单元太多了,会影响性能,所以其实日志文件保持固定的大小是最理想的状态,因为这个时候单元数少)
日志是循环记录的,也就是说在截断点(应该是这么叫的吧)后开始写入,当写入到文件尾的时候,再从开头开始写,当再次到达截断点的时候,就会增加log文件大小了
截断点怎么产生呢?每次备份日志就会产生一个截断点,截断点之前的全部截断,但是并不释放空间(按理说这个时候应该就可以shrink了,为什么shrink不了呢?因为截断点还有一个限制的条件,就是在截断点之前的修改已经写入data文件,而截断点之后的修改都还没有写入data文件),这个时候就可以shrink了
如果备份日志之后并不shrink,则这个时候engine就会开始循环利用日志文件
所以说,如果有了一定的备份策略之后(这里主要是指日志的备份策略,也就是说备份时间),观察一段时间,确定日志文件的高峰值,然后比这个大一些,这样的话,避免了频繁的分配操作,提高了性能,而且不多次增大文件大小的话,单元数目会保持稳定,也可以提高性能

好了,大概情况就是这样的,至于说里面的细节,我都就不太清楚了,呵呵,将就着看看吧
如果看不懂的话,很抱歉,那应该是我的表达能力太差了

 回复 引用 查看   
#9楼 2010-03-03 22:30 尘尘      
@邀月
查看日志文件内容的是:
DBCC Log (<db_id>, <formart_id>)

 回复 引用 查看   
#10楼 2010-03-03 22:33 尘尘      
@邀月
log里面的修改内容写入data文件的时间间隔由recovery interval决定,通过sp_configure可以查看
不过要先执行:
sp_configure 'advanced',1
reconfigure with override

 回复 引用 查看   
#11楼 2010-03-03 22:37 尘尘      
@邀月
还有dbcc sqlperf也是一个很有用的命令

 回复 引用 查看   
#12楼 2010-03-03 22:42 尘尘      
@邀月
嘿嘿,把资料里面的内容搜索了一下,是这本书里面的内容,你可以去网上找找看一下,很有用哦
Microsoft SQL Server企业级平台管理实践

 回复 引用 查看   
#13楼[楼主] 2010-03-04 22:49 邀月      
@尘尘
感谢分享,我想我是看明白了,呵呵。有时间再仔细下这个问题。

 回复 引用 查看   
#14楼 2010-03-04 23:03 尘尘      
@邀月
哈哈,看来我的表达能力还没有差到一定程度啊

 回复 引用 查看   
#15楼 2011-03-16 08:29 正文      
恩,只用过2000和2005的
 回复 引用 查看   
#16楼 2011-11-04 17:00 Enix      
好文章,有对比,有尝试。。
发表评论

昵称: [登录] [注册]

主页:

邮箱:(仅博主可见)

评论内容:

  登录  注册

[使用Ctrl+Enter键快速提交评论]

0 1623004 9A/ROnmRZIU=