[转]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 TRANSACTION和BACKUP 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

补充：

方法一在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之前，备份一下日志