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