恢复模式为简单;
KILL 此数据库的所有活动进程;
然后 数据库 backup log [db] with no_log; 后,仍然无法截取日志;
后来重启SQL 服务,并确认没有其它进程访问此数据库.然后日志仍然很大>10G以上.
等待片刻,再backup log [db] with no_log; 收缩,仍然无法截取日志,日志的可用空间仍然很小.奇怪了后来解决办法是将日志文件删除了,重建的.迷惑:
理论上不是说,简单恢复模式会将已结束的事务日志抛弃,重启SQL 服务的时候会将未完成的活动事务回滚.难道就无法回滚事务?

解决方案 »

  1.   

    简单恢复模式并不是说将已结束的事务日志抛弃 而是将部分的虚拟日志片段标记为可复用
    重启服务会回滚未完成的事务只是理论上来说是这样的,但你不能截断日志的原因很多,比如数据库用于事务复制而日志传送尚未完成
    以后碰到这样的问题,先别急 用下面的语句看看,会告诉你不能截断原因USE [master]
    SELECT [name] ,[database_id] ,[log_reuse_wait] ,[log_reuse_wait_desc] FROM [sys].[databases]
      

  2.   

    恩 简单模式下不能用事务复制 我只不过打个比方
    影响截断日志的因素很多,比如镜像复制,正在创建快照,checkpoint尚未出现等
      

  3.   

    除了checkpoint 有点着边外,其它都不着边,悲剧了.
    当初的时候是眼睁睁的看着那个日志在增大,查看进程是一存储过程在跑,KILL掉该进程.日志无法回滚.由于此系统为微软自己的SCOM系统,存储过程超复杂,当时就没怎么看.