求教邹健：SQL事务复制，订阅服务器的日志日益增大，并且无法收缩

Question

我数据库是SQL2000 做复制 类型：事务复制，然后订阅服务器的日志居然增加到70G了，我想清空日志，并收缩，做了以下操作：
1.DUMP   TRANSACTION   数据库名   WITH   NO_LOG  
2.BACKUP LOG 数据库名  WITH NO_LOG 
但是报错，错误信息：
The log was not truncated because records at the beginning of the log are pending replication. Ensure the Log Reader Agent is running or use sp_repldone to  transactions as distributed.这个如何解决？并且把日志缩写到10G以下，我希望不要把订阅服务器停掉，单纯SQL语句操作，谢谢。

Answer 1

如果不要日志,清除它,参考如下:清除日志： 
DECLARE @LogicalFileName sysname,
        @MaxMinutes INT,
        @NewSize INT
USE     szwzcheck             -- 要操作的数据库名
SELECT  @LogicalFileName = 'szwzcheck_Log',  -- 日志文件名
@MaxMinutes = 10,               -- Limit on time allowed to wrap log.
        @NewSize = 20                  -- 你想设定的日志文件的大小(M)
-- Setup / initialize
DECLARE @OriginalSize int
SELECT @OriginalSize = size 
  FROM sysfiles
  WHERE name = @LogicalFileName
SELECT 'Original Size of ' + db_name() + ' LOG is ' + 
        CONVERT(VARCHAR(30),@OriginalSize) + ' 8K pages or ' + 
        CONVERT(VARCHAR(30),(@OriginalSize*8/1024)) + 'MB'
  FROM sysfiles
  WHERE name = @LogicalFileName
CREATE TABLE DummyTrans
  (DummyColumn char (8000) not null)
DECLARE @Counter   INT,
        @StartTime DATETIME,
        @TruncLog  VARCHAR(255)
SELECT  @StartTime = GETDATE(),
        @TruncLog = 'BACKUP LOG ' + db_name() + ' WITH TRUNCATE_ONLY'
DBCC SHRINKFILE (@LogicalFileName, @NewSize)
EXEC (@TruncLog)
-- Wrap the log if necessary.
WHILE     @MaxMinutes > DATEDIFF (mi, @StartTime, GETDATE()) -- time 
      AND @OriginalSize = (SELECT size FROM sysfiles WHERE name = 
@LogicalFileName)  
      AND (@OriginalSize * 8 /1024) > @NewSize  
  BEGIN -- Outer loop.
    SELECT @Counter = 0
    WHILE  ((@Counter < @OriginalSize / 16) AND (@Counter < 50000))
      BEGIN -- update
        INSERT DummyTrans VALUES ('Fill Log')  
        DELETE DummyTrans
        SELECT @Counter = @Counter + 1
      END   
    EXEC (@TruncLog)  
  END   
SELECT 'Final Size of ' + db_name() + ' LOG is ' +
        CONVERT(VARCHAR(30),size) + ' 8K pages or ' + 
        CONVERT(VARCHAR(30),(size*8/1024)) + 'MB'
  FROM sysfiles 
  WHERE name = @LogicalFileName
DROP TABLE DummyTrans
SET NOCOUNT OFF
 
把szwzcheck换成你数据库的名字即可，在查询分析器里面运行。 
有全角的空格(为了显示好看),你自己把他换一下. 
收缩日志：企业管理器--所有任务--收缩数据库--文件--选日志文件收缩

Answer 2

清除不了?DBCC CHECKDB
检查指定数据库中的所有对象的分配和结构完整性。

Answer 3

--1.清空日志
DUMP  TRANSACTION  库名  WITH  NO_LOG    --2.截断事务日志：
BACKUP LOG 库名 WITH NO_LOG--收缩数据库
DBCC SHRINKDATABASE(库名)--收缩指定数据文件,1是文件号,可以通过这个语句查询到:select * from sysfiles
DBCC SHRINKFILE(1)
--sql2000的方法：backup log 数据库名 with NO_LOG
backup log 数据库名 with TRUNCATE_ONLY
DBCC SHRINKDATABASE(数据库名) --SQL2005的方法：BACKUP LOG  数据库名  to  "d:\bf.bak"
backup log 数据库名 with NO_LOG
DBCC SHRINKFILE (数据库名_log,收缩大小 ) WITH NO_INFOMSGS
阶段日志的语句会报错，但是不影响收缩效果，我也没搞懂是什么回事，你先试试看

Answer 4

订阅服务器一般是做只读用，如果可能的话，设置成简单恢复模式.
如果是full模，有可能出现无法截断日志，可以尝试备份日志再收缩
DECLARE @I INT SET @I=1
WHILE @I<3
BEGIN
    BACKUP LOG [库名] TO  DISK = N'c:\log.bak'  
    DBCC SHRINKDATABASE('库名')
    --DBCC SHRINKFILE(日志文件)
    SET @I=@I+1
END

Answer 5

已经简单模型了你还怎么backup log ????

Answer 6

现在关键是 订阅数据库的LOG文件非常之大，我收缩没用啊

Answer 7

你到底是simple模式还是FULL模式啊？
如果是full模式，才能截断并收缩啊

Answer 8

SIMPLE 模式，那么怎么收缩呢？现在有70多G了，我现在只能把日志文件大小钉死

Answer 9

SIMPLE只能改成FULL才能截断日志再收缩.
你原来就是SIMPLE？

Answer 10

日志文件初始是7G，是从另外个DB拷贝过来的，做订阅服务器的，增长是10%，默认的

Answer 11

1.这里有个疑问：如果确定是单纯的订阅数据库，且又是simple恢复模式。
  那么基本上不可能出现楼主说的问题。这样的问题可能发生在发布数据库
  或是分发数据库上。
2.simple模式的数据库在执行checkpoint时会自动截断事务日志。但是一些因素会
  导致截断事务日志的延迟如：事务复制或长时间运行的事务。收缩simple模式数
  据库的事务日志非常简单：
  
  use dbname
  GO
  checkpoint
  GO
  dbcc shrinkfile(log_file_id)
  GO
  
  这样就行了。
2.存在一种可能，检查你的复制拓扑，订阅数据库是否又重新发布了？
  
  --SQL2K
  SELECT DATABASEPROPERTYEX('订阅数据库','IsPublished')
  GO
  --SQL2K5
  SELECT is_published FROM sys.databases
  WHERE database_id = DB_ID('订阅数据库')
  
4.最早的活动事务，最早的分布式和非分布式复制事务
  
  DBCC opentran(订阅数据库)
  GO
  
5.如果确实如此：订阅数据库又重新发布或是问题是在发布数据库或是分发数据库
  就按照错误信息中的方法来处理：
 Ensure the Log Reader Agent is running or use sp_repldone to  transactions as distributed. 

Answer 12

5.如果确实如此：订阅数据库又重新发布或是问题是在发布数据库或是分发数据库 
  就按照错误信息中的方法来处理： 
Ensure the Log Reader Agent is running or use sp_repldone to  transactions as distributed. 
=================================================================================================
我用SP_REPLDONE这个我不太敢做，因为这个要在发布服务器上做的，万一失败，就惨了，所以我问下SP_REPLDONE具体怎么做。

Answer 13

SQL Server 2005不装sp也有这个问题，打上sp后可以解决这个问题。不知道2000如何解决，呵呵，等高手吧。

Answer 14

汗一个先！
楼主把你需要把问题再重新描述一下，否则没办法帮你解决的。
如果只是不知道SP_REPLDONE的用法，可以看帮助讲的很清楚了。

Answer 15

现在有个订阅服务器,数据库日志达到70G，然后收缩没用，用了很多方法都不行。
数据库版本：SQL2000 标准版 英文
数据库模型：简单现在想用SQL语句来把日志文件收缩到10G以下，谢谢啦！！！

Answer 16

如果只是A数据库发布 B数据库订阅，B的恢复模式是simple。
你在操作B数据库的事务日志，是不会碰到你说的那个错误的！

Answer 17

1.问题可能就出在你这个订阅数据库是怎么来的了？
2.是否这个订阅数据库是从一个发布数据库拷贝过来的？？？
3.检查一下数据库里是否存在syspublications这个表？
4.当前订阅数据库可以同步成功嘛？

Answer 18

Google了一下，基本可以确定楼主遇到的问题就是我说的情况：
你的订阅数据库是从一个事务复制的发布数据库拷贝过来的。大致的方法如下：
USE 数据库名
GO
EXEC sp_dboption '数据库名','published','true'
EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0,     @time = 0, @reset = 1
EXEC sp_removedbreplication '数据库名'
BACKUP LOG 数据库名 WITH no_log
DBCC shrinkfile(....)
GO

Answer 19

你的情况跟我的有点类似，我后来是这样搞定的：
1、先将复制设置成已分发
当 xactid 为 NULL，xact_seqno 为 NULL，并且 reset 为 1 时，日志中的所有复制事务都标记为已分发。当事务日志中存在不再有效的复制事务并且想截断该日志时，此过程很有用，例如：  
EXEC sp_repldone @xactid = NULL, @xact_segno = NULL, @numtrans = 0,     @time = 0, @reset = 1
 2、再开始收缩declare @strDbName varchar(32),@sql varchar(200) set @strDbName = 'RedBoy' --需要处理的数据库名 set @sql = 'dump transaction ['+@strDbName+'] with no_log'+char(10)+char(13)set @sql = @sql +     'backup log ['+@strDbName+'] with no_log'+char(10)+char(13)set @sql = @sql +    'DBCC SHRINKDATABASE(['+@strDbName+'])'exec(@sql)

Answer 20

今天无意间搜到了这个，同样的问题我最近遇到过一次。
我想出现这个问题的原因可能有：
1 订阅数据库是从一个事务复制的发布数据库拷贝过来
2 订阅数据库曾经出过故障，如置疑，采用rebuild log and dbcc checkdb修复过.我遇到的情况是第2种.
解决的方法：
1.将该库设置为分发库，简单为该库做一个发布项
2.停止该发布项使用的logreader job.
3.exec sp_repldone null,null,0,0,1 
4.dbcc shrinkfile这样就可以解决了。