关于sql server日志变得超大的删除解决办法

hhnf333

　　首先说说,这个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
　　删完可以看看硬盘空间,一切都变好了,