sql server 2005日志文件过大问题解决后分析--针对发布订阅产生的日志问题

机房在四月份改造中对数据库的软硬件进行了升级，具体情况是：原先旧有的数据库是采用主备两台1u的单机，在windows 2000的系统下分别安装好sql server 2000后，在主数据库上做一天一次的完整备份和每隔两小时的差异备份，在完整备份的同时进行发布；备数据库则对主数据库的完整备份进行订阅。改造后的配置则是使用了带两个节点sdb01和sdb02的群集，并使用sdb03进行原先的备数据库的订阅工作。由于sdb01和sdb02两台机器上使用了windows 2003的系统，考虑到使用群集的情况，选用sql server 2005的兼容性会更好。于是就需要将sql2000上的数据库迁移到sql2005，根据网上的方法在sql2000上进行了数据库备份，然后在sql2005上新建一个同名数据库，并使用还原数据库的方法覆盖该数据库，接着对还原后的数据库用户进行必要的修改，一切看似迁移成功。

但随着时间迁移，发现日志文件逐渐变大，三四个月后竟然达到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的订阅是正常的。