目前，我的生产 SQL Server 2008 R2 服务器的数据库日志越来越失控：
上面提到的服务器有每日备份计划@1am 和每 15 分钟一次的 translog 备份。
数据库以完全恢复模式复制到订阅者。复制从上面的节点（发布者）推送。订阅服务器上的同一个数据库日志文件在磁盘上是 ~< 100 GB。
我做了什么来尝试修复：
上面没有任何工作，所以我尝试缩小使用 DBCC SHRINKFILE 也不起作用的日志文件。大小永远不会改变。
谁能告诉我有什么问题或者我作为 SQL Server DBA 需要做什么来解决上述问题？
您应该使用相同的表制作空白数据库，并将旧数据库数据从迁移脚本迁移到空白数据库。例如：INSERT INTO customers(cust_id, Name, Address) SELECT cust_id, Name, Address FROM olddb.customers
--这个脚本应该在新的空白数据库中运行
可能会阻止您缩小 translog 文件的可能因素：
查看您的 translog 文件大小的大小，很可能是由第二种可能性引起的。
您的复制分发代理运行非常频繁
SQL Server 日志阅读器代理将 translog 文件标记为正在使用并防止它们被收缩，这是 SQL Server 在备份 translog 文件后所做的。如果此过程频繁且足够长地发生，这可能会阻止您的 translog 文件在 translog 计划备份时收缩。
查看此MSDN 事务说明以及如何修改日志读取器代理。
MSDN 论坛中的一个线程描述了类似的问题，这里有一个 DBCC 查询，可以帮助您识别可能阻塞 translog 文件 ( DBCC OPENTRAN ) 的正在运行的事务。
您的数据库上正在发生长时间运行的事务
您可以使用 DBCC OPENTRAN 检查是否正在发生任何长时间运行的事务以及正在运行的进程，然后决定如何处理它。一旦长时间运行的事务完成，您应该能够缩小日志文件。
运行 sp_who2 后，我注意到日志上的一个长时间运行的事务正在不受控制地增长。我在那个 SPID 上使用了 kill 而不是我正在缩小日志文件。
您可以手动缩小日志文件 1.右键单击您的数据库 > 任务 > 缩小 > 文件 > 文件类型 = 日志而不是 ok