☰

SQL Server 日志文件不会缩小，因为非复制数据库上存在“日志正在等待复制”？

tag-icon • tag-icon sql sql-server database
SQL Server 日志文件不会缩小，因为非复制数据库上存在“日志正在等待复制”？

我有一个非关键任务数据库，我将其设置为在工作时间内每晚进行一次完整备份，每 30 分钟进行一次日志备份。数据库处于完全恢复状态，通常我没有理由截断/缩小日志，除非我进行一些繁重的维护。日志备份可以毫无问题地管理大小。但是我已经好几个星期没有去这个客户那里了，经过检查，我发现日志已经增长到 .mdf 文件大小的 10 倍左右。我查看了备份的运行情况，没有收到任何严重错误警报（SQL 邮件）。我尝试将数据库置于简单恢复状态并缩小日志，但这没有用。我继续尝试日志备份，结果如下：

日志未被截断，因为日志开头的记录正在等待复制或更改数据捕获。请确保日志读取器代理或捕获作业正在运行，或者使用 sp_repldone 将事务标记为分布式或捕获式。

重新启动SQL Server并重复同样的事情...

我说???这个数据库或数据库/服务器上没有设置复制???所以日志备份没有刷新.ldf。所以我做了几个小时的研究，我发现：

http://www.sqlmonster.com/Uwe/Forum.aspx/sql-server/5445/Log-file-is-not-truncated-inspite-of-regular-log-backup

http://www.eggheadcafe.com/software/aspnet/30708322/the-log-was-not-truncated-because-records-at-the-beginning-of-the-log-are-pending-replication.aspx

似乎是某种记录不全的错误？？

解决方案似乎是运行 exec sp_repldone，更准确地说

EXEC sp_repldone @xactid = NULL,
  @xact_segno = NULL, @numtrans = 0,
  @time= 0, @reset = 1

此过程可用于紧急情况，当存在待复制的事务时，允许截断事务日志。使用此过程可防止 Microsoft SQL Server 2000 复制数据库，直到数据库取消发布并重新发布为止。~ MSDN

当我这样做时，我得到以下结果

消息 18757，级别 16，状态 1，过程 sp_repldone，第 1 行无法执行过程。数据库未发布。在为复制而发布的数据库中执行该过程。

这是有道理的，因为数据库从未发布过进行复制。

我有几个问题：

A) 首先，这是怎么回事？是什么原因造成的？我想知道这是为什么？这真的是 bug 吗？还是备份的某些方面没有正常工作，导致数据库模仿复制状态？请有人在这方面给我一些启发。

B）其次...我真的必须发布/复制此数据库才能执行此 SP 来修复此问题吗???听起来很疯狂，或者是否有一些 T-SQL 可以将其置于已发布状态，执行该 proc 然后就可以开始了...

C) 第三，如果我确实必须发布此数据库才能执行 SP 以发布此不需要的错误复制/预期日志，以使我的 .ldf 文件和备份回到正轨。如何在没有它要求的在线主机的情况下发布数据库？？？我通常不做这种数据库管理，需要一些指导。

抱歉，如果这太冗长，但仅仅提出问题就有助于我澄清它......

预先感谢您的帮助

答案1

我有同样的问题

我做到了 SELECT name, log_reuse_wait_desc FROM sys.databases

它告诉我无法清空日志的原因是复制

我试过

sp_removedbreplication youdbname

并修复了这个问题

答案2

我们几乎遇到过同样的问题。 sys.databases 中甚至还没有安装复制 (SQL 2008)，我们的一个数据库突然毫无理由地被设置为正在复制。

我们不得不采取可怕的措施来恢复数据库，因为日志文件增长得太快了，而且（当然）正常的日志刷新过程不起作用。

过了一会儿，我才意识到复制设置是问题所在。那时，日志文件已满。令人震惊的是，即使我们能够恢复数据库，复制设置仍然设置。

这就是删除该设置的原因：

EXEC sp_repldone @xactid = NULL，@xact_segno = NULL，@numtrans = 0，@time= 0，@reset = 1

答案3

数据库是否启用了 CDC，CDC 和复制使用相同的技术。

1 运行选择 DATABASEPROPERTY('','ISPublished') -- 应该返回 0

  1. 检查数据库是否启用了 CDC。转到数据库并从 sys.dm_repl_traninfo 中选择 *——这应该是空的

3 DBCC loginfo --查找值为 2 的状态列

  1. DBCC OPENTRAN——检查是否存在一些长时间运行的事务。

  2. 即使所有这些都没有帮助，那么我们可能必须启用复制和 e

答案4

我遇到了完全相同的问题，我找到了一个更简单的解决方案：

  • 分离数据库
  • 删除日志文件
  • 使用指定 FOR ATTACH_REBUILD_LOG 的 CREATE DATABASE 语句重新附加它

（请注意，这是在 SQL 2k8 上）

相关内容