SQL SERVER事务日志已满详解

1 . SQLServer日志满，先备份数据。
2 . 检查日志文件大小，超过1 GB就警告。
3 . 增量日志满，执行备份后截断。
4 . 完整模式，备份数据后自动截断。
5 . 大量插入，手动截断日志。
6 . 简单模式，直接备份，空间自动释放。
7 . VLF过多，压缩日志文件。
8 . 磁盘空间不足，先清理。
9 . 修改日志增长策略，按需设置。
1 0. 每月检查日志使用，调整策略。

你自己掂量。

用友软件提示：数据库**日志已满.请备份该数据库的事务日志以释放一些日志空间. 请问该怎么解决?

上周，我那个朋友公司用友软件提示“数据库日志已满”，他急得团团转。
他说，事务日志满了，数据库就卡住了。
我教他先备份日志，然后用工具删除。
他说操作有点复杂，但我告诉他，这是最直接的方法。
他还说，如果日志文件太大，可能得调整大小。
我让他先试试这些，如果不行，再找专业人士。
他说，他会记着的。
算了，希望他这次能搞定。

数据库日志已满，如何处理？

哎哟喂，跟你唠唠数据库日志满了的处理，我这可是踩过坑的。

前年，我在北京一个项目上，半夜被电话吵醒，监控报警数据库日志满了。
那阵子正赶上一个重要客户的数据导入，真要命。

当时咋整的？先赶紧查日志，发现是某个导入脚本卡死在那儿了，没提交事务。
我这人急，想立马解决问题，就试了 dumptransaction 数据库名 with no_log。
想着把没提交的事务咔嚓了，日志立马清了。
结果？导入的数据全没了，客户那边炸锅了。
还好我事先有个备份，赶紧从备份恢复，但折腾了好久。

后来我学聪明了。
再遇到类似情况，先不急着瞎操作。
先看看日志文件有多大，哪个事务没提交占地方了。
如果非得紧急处理，会先尝试 backup log 数据库名 with truncate_only。
这个命令是截断日志，把未提交的事务也丢了，但至少能把日志清出来，让数据库继续运行。
记得那次是备份到另一个盘，没直接删，万一有错能恢复点啥。

实在不行，就得考虑收缩。
用 dbcc shrinkfile 可以缩日志文件。
不过这玩意儿也挺坑的，收缩完了可能磁盘碎片了，下次日志又长起来。
我有个同事，缩完日志，结果第二天日志又占满盘了，又得跑一趟。
所以收缩日志也得看情况，不是万能药。

最彻底的办法，还是分离数据库，删掉旧的日志文件，再重新附加。
我去年在上海处理过一个老数据库，日志文件跟没头苍蝇似的疯长，硬是这么干的。
分离数据库，把那些7 年前的日志文件全删了，然后重新附加，搞了个新的小日志文件。
这次日志增长就慢多了。
具体操作是 sp_detach_db 分离，然后 sp_attach_single_file_db 重新附加。
不过这操作风险大，数据库挂了就得这么整。

预防措施最重要。
平时就得注意，设置自动收缩也得看情况。
有个项目，我让他们开了自动收缩，结果收缩收缩把数据库文件也缩没了，数据丢了。
所以自动收缩得谨慎开。
限制日志增长是个好办法，alter database 数据库名 modify file 限制下最大大小，日志长到哪儿就停那儿。
我管一个系统，就设置了日志最大5 00G，反正他们数据量就那么大，从来没超过。

总之一句话，数据库日志满了是真头疼。
平时得多注意预防，真急了也别瞎操作，先搞清楚状况，权衡利弊，该备份的备份，该丢的事务就得狠心。
别像我前年那样，一急乱操作，惹出一堆麻烦。