今天按常用方法收缩一个测试用的数据库日志,发现没法收缩!
dbcc sqlperf(logspace)
USE [dbname]
GO
ALTER DATABASE [dbname] SET RECOVERY SIMPLE WITH NO_WAIT
GO
DBCC SHRINKFILE (N'dbname_log' , 0, TRUNCATEONLY)
GO
DBCC SHRINKDATABASE(N'dbname' )
GO
日志大小还是一样。
![](https://i-blog.csdnimg.cn/blog_migrate/e13afb7a5d9b476390a949a628cb51d2.jpeg)
![](https://i-blog.csdnimg.cn/blog_migrate/5f49383035b30e3a3e53bbf88ef92be6.png)
DBCC OPENTRAN 查看是否打开的事务。发现有打开的事务,执行检查点再收缩,还是不行!
DBCC OPENTRAN (dbname)
CHECKPOINT
参考:http://bbs.csdn.net/topics/350199751,将日志事务标志为已分发,再收缩,不行!
--日志中所有复制的事务将标记为已分发
EXEC sp_repldone @xactid = NULL,@xact_segno = NULL,@numtrans = 0,@time = 0,@reset = 1
现在查看虚拟日志文件,发现有很多,并且都处于活动状态
dbcc loginfo
最重要的语句竟然忘了,这可以查看日志空间的重复使用正在等待最后一个检查点的描述.。发现是REPLICATION
SELECT name,log_reuse_wait_desc FROM sys.databases where name='dbname'
这个数据库之前有作为事物同步过,但是都删除了。分发库也不存在了,现在竟然还有日志在等待?!
参考http://bbs.csdn.net/topics/390674731?page=1 ,执行删除所有复制对象。
--删除当前数据库中所有复制对象
EXEC sp_removedbreplication dbname
再看日志重用状态,正常了!看来有效!
在收缩数据库,查看已经收缩了!其他也恢复正常!
DBCC SHRINKFILE (N'dbname_log' , 0, TRUNCATEONLY)
GO
DBCC LOGINFO
GO
DBCC OPENTRAN (dbname)
GO
此收缩方法,适用于发布过数据库订阅同步的情况,一般正常情况下,都可以收缩日志。
转自:https://blog.csdn.net/kk185800961/article/details/41865073