我的数据库日志以前使用下面的SQL来清空,最近发现日志没法清空一直在增加,数据库是Sql Server 2005,怎么解决?--清空日志
DUMP TRANSACTION 库名 WITH NO_LOG
--截断事务日志
BACKUP LOG 数据库名 WITH NO_LOG
--收缩数据库
DBCC SHRINKDATABASE(数据库名)
----

解决方案 »

  1.   

    我试过直接执行上面的SQL结果日志还是没有被清空
      

  2.   

    首先
    --清空日志
    DUMP TRANSACTION 库名 WITH NO_LOG这个是2000及之前的写法,为了向后兼容,2005之后可以用--截断事务日志
    BACKUP LOG 数据库名 WITH NO_LOG这两个语句的效果是一致的。建议楼主:
    1. 仔细检查执行语句,越是奇怪的问题,往往错误越是低级。
    2. 楼主说清不掉,我觉得可以执行完语句以后,监视一下数据库日志变化
    因为
    --截断事务日志
    BACKUP LOG 数据库名 WITH NO_LOG这个如果执行失败的话,会有错误提示。如果没有,那应该是后面的收缩有问题。
    也就是说是shrinkdatabase执行有问题如果是这种情况的话,那实际上日志已经被清空了,只是没收缩而以。所以如果监视一段时间以后发现,数据库日志没有变化,那就可以肯定是这个问题了。
      

  3.   

    Some SQL Server administrators have noted that the transaction log seems unable to be truncated, even after the log has been backed up. This problem often results from a process opening a transaction and then forgetting about it. For this reason, from an application development standpoint, you should ensure that transactions are kept short. Another possible reason for an inability to truncate the log relates to a table being replicated using transactional replication when the replication log reader hasn't processed all the relevant log records yet. This situation is less common, however, because typically a latency of only a few seconds occurs while the log reader does its work. You can use DBCC OPENTRAN to look for the earliest open transaction or the oldest replicated transaction not yet processed and then take corrective measures (such as killing the offending process or running the sp_repldone stored procedure to allow the replicated transactions to be purged)
      

  4.   

    如何监视数据库日志变化?这个SQL以前一直都是正常的,执行完以后没任何错误提示只是显示一个列表。我试过在Management Studio里运行任务->收缩->数据库,文件。运行后日志大小还是没变化。
      

  5.   

    用Google翻译了一下不明白啥意思,难道要把数据库停了以后再清空日志?
      

  6.   

    1.DBCC OPENTRAN 看看是否有老的活动事务2.是否用了复制
      

  7.   

    其实,不让日志文件长太大的方法,最简单的就是创建三个小的日志文件.SQL在这三个日志文件中循环,一般每个几十兆就不再大了.
      

  8.   

    首先并不是以上的语句能确保截断或者收缩你的数据库日志
    你一定要了解 你的数据库日志能不能被截断(先不要谈收缩)并不一定是你的语句有问题,而是你的日志能否有被可标记为复用的段(截断),比如一个很长很长,或者永远不会结束的事务都会影响你截断事务
    用以下语句看一下 是否你的日志文件允许被截断,或者不允许被截断的原因,你只要找log_reuse_wait和log_reuse_wait_desc 两个字段就可以了
    select [name],log_reuse_wait,log_reuse_wait_desc from sys.databases
    可以的话贴上来看看
      

  9.   

    log_reuse_wait和log_reuse_wait_desc分别是6 REPLICATION,怎么解决?
      

  10.   

    运行DBCC OPENTRAN后显示,不明白什么意思。你讲的复制是指什么?我因为没用了。
    已复制的事务信息:
            最早的分布式 LSN     : (0:0:0)
            最早的非分布式 LSN : (1874429:25:1)
    DBCC 执行完毕。如果 DBCC 输出了错误信息,请与系统管理员联系。
      

  11.   

    have a tryEXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0,     @time = 0, @reset = 1
      

  12.   

    汗 sqlserver不是你管的吧...
    你运行17楼的那个语句
    EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0,     @time = 0, @reset = 1
    那个是标记所有的事务已被传送到distributor,运行之后
    再运行你1楼的截断事务的语句
      

  13.   

    我只用SQL而已,数据库的这类问题不懂了,我先试试。
      

  14.   

    试了这个SQL,不行,有错误提示EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0, @time = 0, @reset = 1消息 18757,级别 16,状态 1,过程 sp_repldone,第 1 行
    无法执行过程。该数据库没有发布。请在已为复制发布的数据库中执行该过程。
      

  15.   

    这样太麻烦了,我平时都是定时运行清空数据库的SQL
      

  16.   

    网上Google一下,自己找到了解决办法解决办法的原文:
    REPLICATION
    这是我遇到的情况,但我根本没有启用过REPLICATION,据查,这好像是SQLSERVER2008的一个BUG,解决方法是给标有“REPLICATION”的数据库任意一个表创建数据库事务复制(TRANSACTION REPLICATION),然后再删除,执行数据库与日志备份后,就可以收缩了。地址:http://dev.firnow.com/course/7_databases/sql/sqlServer/20100719/449726.html主要还是log_reuse_wait_desc REPLICATION的问题造成的,据说是个BUG。通过创建一个新的数据库事务复制然后再删除就正常了。
      

  17.   

    这个问题可能是由于 你此数据库是从其他地方复制过来的或者你离线后,移动过数据库再附加引起的,可以先执行sp_removedbreplication 然后再收缩