Jangogo :
在SQL Server 2000/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 Server 2008 已经不再支持 DUMP TRANSACTION和BACKUP LOG WITH NO_LOG,
但是以上语句中前两行在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 Server 2008 已经不再支持 DUMP TRANSACTION和BACKUP LOG WITH NO_LOG,
SQL
Server 2005说明中明确:包含 DUMP 语句是为了向后兼容。而 后续版本的 Microsoft SQL Server
将删除该功能。请避免在新的开发工作中使用该功能,并着手修改当前还在使用该功能的应用程序。 使用 BACKUP。
SQL Server 2008说明:BACKUP LOG WITH NO_LOG 和 WITH TRUNCATE_ONLY 选项已废止。使用完整恢复模式或大容量日志恢复模式时,如果必须删除数据库中的日志备份链,请切换至简单恢复模式。有关详细信息,请参阅有关从完整恢复模式或大容量日志恢复模式切换的注意事项。
尝试方法二:
先把备份模式换成simple mode;
SQL Server 2008说明:BACKUP LOG WITH NO_LOG 和 WITH TRUNCATE_ONLY 选项已废止。使用完整恢复模式或大容量日志恢复模式时,如果必须删除数据库中的日志备份链,请切换至简单恢复模式。有关详细信息,请参阅有关从完整恢复模式或大容量日志恢复模式切换的注意事项。
尝试方法二:
先把备份模式换成simple mode;
- ----Logical Files :
- --CMS1.5_Data
- --CMS1.5_Log
- DBCC SHRINKFILE (N'CMS1.5_Log' , 1)
- GO
尝试方法三(Jangogo推荐):
- 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. Detach数据库。
2.删除log文件。
3. 附加数据库,选移除log文件,此时SQL Server 会自动重新建立一个512K 的Log 文件。
方法五(没有试过,请提前备份文件!!):
1. 停止 SQL Server 的服务
2. 使用删除 Log文件
3. 重新启动SQL Server 服务,此时SQL Server 会自动重新建立一个1MB 的Log 文件。(文/邀月)
备注:
一、完整备份一下数据库,如果之前有完整备份了,那么这里只需要备份一下日志即可
二、执行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之前,备份一下日志。
1. 停止 SQL Server 的服务
2. 使用删除 Log文件
3. 重新启动SQL Server 服务,此时SQL Server 会自动重新建立一个1MB 的Log 文件。(文/邀月)
备注:
一、完整备份一下数据库,如果之前有完整备份了,那么这里只需要备份一下日志即可
二、执行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之前,备份一下日志。
文档中心