首先说说,这个sql server的日志,就是*log.ldf结尾的日志文件,他的日志体系结构其实挺严谨,原意是---如果你不做日志备份,就不给你删日志,然后也有脚本给你回收日志空间,算是挺安全也方便实用了.

    看起来是挺合理的,但是碰到缺心眼的开发或使用者,日志一天天的胀大,而又忘记回收的话,那就悲催了,这个时候你就不可能备份了,然后就清空不了log.ldf日志,因为硬盘空间不够用啊,不能备份也就不能删日志,就成了个死循环了.

    我这边就遇到这种事,日志被撑到170G了,硬盘总共才200G空间,怎么搞好呢?

    最后经过百度和google两位幕后大师傅的指点,得到了下面的方法,仅供参考,因为也可能有些情况不太一致.

我们平常用的方法是直接收缩:

–SQL   Server收缩方法

最直接就是在sql server控制界面操作:

右键数据库→任务→收缩数据库→确定；

如果还是不理想,又或者试试这样:

1、右键数据库→属性→选项→故障还原模型→设为简单→确定；
2、右键数据库→任务→收缩数据库→确定；
3、右键数据库→属性→选项→故障还原模型→设为大容量日志记录→确定。

再不行,就要用下面的方法了:

首先我们看看日志当前的状态,

DBCC LOGINFO(test9572)

可以看到status=0的日志，代表已经备份到磁盘的日志文件；而status=2的日志还没有备份。当收缩日志文件时，收缩掉的空间其实就是 status=0的空间，如果日志物理文件无法减小，这里一定能看到非常多status=2的记录。

然后我们看看日志截断延迟原因,

SELECT [name] ,[database_id] ,[log_reuse_wait] ,[log_reuse_wait_desc] FROM [sys].[databases];

各种原因及解释如下：

log_reuse_wait_desc 值

NOTHING    当前有一个或多个可重复使用的虚拟日志文件。

CHECKPOINT    自上次日志截断之后，尚未出现检查点，或者日志头部尚未跨一个虚拟日志文件移动（所有恢复模式）。

这是日志截断延迟的常见原因。

LOG_BACKUP    需要日志备份，以将日志的头部前移（仅适用于完整恢复模式或大容量日志恢复模式）。

注意：日志备份不会妨碍截断。

完成日志备份后，日志的头部将前移，一些日志空间可能变为可重复使用。

ACTIVE_BACKUP_OR_RESTORE    数据备份或还原正在进行（所有恢复模式）。数据备份与活动事务的运行方式相同。数据备份在运行时，将阻止截断。

ACTIVE_TRANSACTION    事务处于活动状态（所有恢复模式）。一个长时间运行的事务可能存在于日志备份的开头。在这种情况下，可能需要进行另一个日志备份才能释放空间。

看完了状态,我的问题也是这个LOG_BACKUP,日志没备份导致,也就是开头说的死循环,因为硬盘空间不够用啊,不能备份也就不能删日志,就成了个死循环了

总有解决办法,办法的原理是在简单模式下进行，等清除动作完毕再调回到完全模式,下面来看:

首先,我们要确认日志的文件名,因为硬盘上的文件名不一定是数据字典里面的文件名,所以要确认下

USE test9572
GO
SELECT file_id,name FROM sys.database_files;
GO

然后就可以准备删了:

USE [test9572]
GO
ALTER DATABASE test9572 SET RECOVERY SIMPLE WITH NO_WAIT
GO
--简单模式
ALTER DATABASE test9572 SET RECOVERY SIMPLE 
GO
USE test9572
GO
DBCC SHRINKFILE (N'test9572_log' , 11, TRUNCATEONLY) 
GO
USE [test9572]
GO
ALTER DATABASE test9572 SET RECOVERY FULL WITH NO_WAIT
GO
--还原为完全模式
ALTER DATABASE test9572 SET RECOVERY FULL 
GO

删完可以看看硬盘空间,一切都变好了,