今天早上，公司打来电话，说TFS（Team Foundation Server）微软源代码管理软件签入不了，报错：TF30042 数据库已满。
经过差不多半个小时的处理，基本上好了，再次总结一下：
根据提示，我先检查磁盘空间，发现都有几十G（公司的TFS数据库比较大，光压缩备份就有20G以上），足够用来备份。
检查完硬盘空间后，接着检查数据库空间，发现日志文件的确满了，按照常规思路，做了一次日志备份。正常来说，这已经能清空日志了。但是发现还是不行。为此也头疼了一下。看看恢复模式，是完整的，然后我就换成大容量日志，其实这一步我觉得有点多余，因为作为源代码管理，频繁签出签入是很正常，但是几乎没有大容量插入的，所以换这个模式作用不大，只是作为“试探性”的动作而已。
后来看到网上的提示说检查一下SQLServer的错误日志，再次说明一下，很多DBA书籍上对问题检查都是这样的顺序：1、检查windows错误日志；2、检查SQLServer的错误日志然后再去做对应的处理。我由于经验不足，直接跳过了，反倒是问题处理延缓了。在检查了错误日志后，的确发现一些有用信息：
根据【消息】，我去数据库用以下代码查询：
SELECT name, log_reuse_wait_desc FROM sys.databases where log_reuse_wait_desc = ‘Replication‘
发现只有一条记录，就是我的TFS数据库：Tfs_HKITCollection。然后到MSDN上查。发现Replication这个状态是因为还原了某些发布的数据库或者没有正确移除而导致的，而我的服务器上没有任何复制数据库，但在我接手之前我就不清楚了。还是先解决问题
执行：
sp_removedbreplication ‘指定数据库‘
根据联机丛书对这个存储过程的解释：
只有当其他删除复制对象的方法都失败后，才应当使用此过程。
执行完后，在查询上面的语句：
SELECT name, log_reuse_wait_desc FROM sys.databases where name=‘Tfs_HKITCollection‘
发现log_reuse_wait_desc这一列已经变回log backup，证明处理成功，然后我再做一次日志备份。数据库TFS就可以访问了。
到此为止，问题算是处理完毕。另外，如果有必要，可以收缩一下数据库。
补充一些相关知识：
--检查当前数据库是否可以用于复制，1 = TRUE，0 = FALSE，可以更改DB_NAME()来检查其他数据库。2008之前不知道可否使用。
SELECT DATABASEPROPERTYEX ( DB_NAME() , ‘IsPublished‘ )
至于复制，超过本文范围，本文主要记录处理心得，希望有同样情况的人能得到解决，也作为自己的一个记录。