恢复模式为简单;
KILL 此数据库的所有活动进程;
然后 数据库 backup log [db] with no_log; 后,仍然无法截取日志;
后来重启SQL 服务,并确认没有其它进程访问此数据库.然后日志仍然很大>10G以上.
等待片刻,再backup log [db] with no_log; 收缩,仍然无法截取日志,日志的可用空间仍然很小.奇怪了后来解决办法是将日志文件删除了,重建的.迷惑:
理论上不是说,简单恢复模式会将已结束的事务日志抛弃,重启SQL 服务的时候会将未完成的活动事务回滚.难道就无法回滚事务?
KILL 此数据库的所有活动进程;
然后 数据库 backup log [db] with no_log; 后,仍然无法截取日志;
后来重启SQL 服务,并确认没有其它进程访问此数据库.然后日志仍然很大>10G以上.
等待片刻,再backup log [db] with no_log; 收缩,仍然无法截取日志,日志的可用空间仍然很小.奇怪了后来解决办法是将日志文件删除了,重建的.迷惑:
理论上不是说,简单恢复模式会将已结束的事务日志抛弃,重启SQL 服务的时候会将未完成的活动事务回滚.难道就无法回滚事务?
重启服务会回滚未完成的事务只是理论上来说是这样的,但你不能截断日志的原因很多,比如数据库用于事务复制而日志传送尚未完成
以后碰到这样的问题,先别急 用下面的语句看看,会告诉你不能截断原因USE [master]
SELECT [name] ,[database_id] ,[log_reuse_wait] ,[log_reuse_wait_desc] FROM [sys].[databases]
影响截断日志的因素很多,比如镜像复制,正在创建快照,checkpoint尚未出现等
当初的时候是眼睁睁的看着那个日志在增大,查看进程是一存储过程在跑,KILL掉该进程.日志无法回滚.由于此系统为微软自己的SCOM系统,存储过程超复杂,当时就没怎么看.