首先说说,这个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删完可以看看硬盘空间,一切都变好了,
另外有需要云服务器可以了解下创新互联cdcxhl.cn,海内外云服务器15元起步,三天无理由+7*72小时售后在线,公司持有idc许可证,提供“云服务器、裸金属服务器、高防服务器、香港服务器、美国服务器、虚拟主机、免备案服务器”等云主机租用服务以及企业上云的综合解决方案,具有“安全稳定、简单易用、服务可用性高、性价比高”等特点与优势,专为企业上云打造定制,能够满足用户丰富、多元化的应用场景需求。