但随着时间迁移，发现日志文件逐渐变大，三四个月后竟然达到10g之巨。期间有尝试过处理，方法如下：
1.清空日志
DUMP TRANSACTION 库名 WITH NO_LOG
2.截断事务日志：
BACKUP LOG 数据库名 WITH NO_LOG
3.收缩数据库文件（如果不压缩,数据库的文件不会减小）
同时也注意到将数据库的恢复模式从“完整”改为“简单”。但是操作后的日志非但没有减小，反而略有增大。也考虑到是否要使用分离数据库的方法将日志文件删除后，再附加数据库。但这只是治标不治本的方法，且对系统的运行存在影响。
这时看到一篇文章介绍，用DBCC UPDATEUSAGE命令修复数据库的行记录数，修复了一些错误，但是还是无法收缩。根据该文章的提示，使用了这样一个函数：DBCC OPENTRAN(Db_Name)，显示类似下面的信息：
已复制的事务信息:
最早的分布式 LSN : (0:0:0)
最早的非分布式 LSN : (1051867:2025:1)
DBCC 执行完毕。如果 DBCC 输出了错误信息，请与系统管理员联系。
而在其它正常的数据库上运行这个命令，则没有前面三行东西。接着使用了exec sp_removedbreplication ‘Db_Name’,奇迹出现了，该数据库日志文件立马减少到了1兆多。
为什么会出现这样的情况呢？sp_removedbreplication的msdn解释是：该存储过程在发布服务器的发布数据库中或在订阅服务器的订阅数据库中执行。 该过程将从执行它的数据库中删除所有复制对象，但它不会从其他数据库（例如，分发数据库）中删除对象。非常的拗口，难于理解。下面这句话相信同样不好理解：如果将数据库附加到的服务器不是该数据库从中分离的服务器，并且启用了分离的数据库以进行复制，则应该运行 sp_removedbreplication 从数据库删除复制。
换言之，通常如果你设置过数据库复制或发布，而后来设置失败并没有启用，可能会导致这个问题，你看不到跟复制有关的内容，但是在数据库里却存在这样的东西，于是日志被它堵住了，这成了一个永远无法完成的命令，所以后续的日志都无法截断。执行了这个命令以后，强制清除了复制内容。
因此我们的日志文件变得过大且无法正常截断问题的根源可能在于：从sql2000升级到sql2005的过程中存在兼容性问题或者sql2005存在bug，因为在升级过后群集的数据库发布与sdb03的订阅是正常的。
