目前，我的生产SQL Server 2008 R2服务器的数据库日志正在失控：
- 数据文件： D：\Data...\MyDB.mdf = 磁盘上的 278859 MB
- 日志文件：L：\Logs...\MyDB_1.ldf = 磁盘上的 394542 MB
上面提到的服务器每15分钟安排@1am和Translog备份的每日备份。
数据库以完整恢复模式复制到订阅服务器。从上面的节点(发布者(推送重新分配。订阅服务器上的同一数据库日志文件在磁盘上为 ~<100 GB。
我做了什么来尝试修复：
- 运行数据库的完整备份(需要 1 小时 47 秒(
- 运行每 15 分钟运行一次的 translog 备份作业(耗时 1 分 20 秒(
- 运行数据库的另一个完整备份
上面的一切都不起作用，所以我然后尝试使用 DBCC 收缩文件收缩日志文件，这也不起作用。大小永远不会改变。
谁能告诉我出了什么问题，或者作为SQL Server DBA我需要做什么来解决上述问题？
您收缩 translog 文件的情况：
- 数据库上正在发生长时间运行的事务
- 复制分发代理运行非常频繁
查看您的 translog 文件大小的大小，很可能是由第二种可能性引起的。
复制分发代理运行非常频繁
SQL Server日志读取器代理将 translog 文件标记为正在使用并防止它们被收缩，这是 SQL Server 在备份 translog 文件后执行的操作。如果此过程发生的频率和时间足够长，这可能会阻止您的 translog 文件在计划的备份中收缩。
查看此 MSDN 事务说明以及如何修改日志读取器代理。
MSDN 论坛中描述类似问题的线程，这里有 DBCC 查询，可帮助您识别可能阻止 translog 文件 (DBCC OPENTRAN( 的正在运行的事务。
数据库上正在发生长时间运行的事务
您可以使用DBCC OPENTRAN检查任何长时间运行的事务是否正在发生，以及正在运行的进程，然后决定如何处理它。一旦长时间运行的事务完成，您应该能够收缩日志文件。
运行sp_who2后，我注意到日志上有一个长时间运行的事务，该事务无法控制地增长。我在那个 SPID 上使用了 kill，而不是继续缩小日志文件。
您应该使用相同的表创建空白数据库，并将旧数据库数据从迁移脚本迁移到空白数据库。例如：插入客户(cust_id、姓名、地址(选择cust_id、姓名、地址来自 老数据库客户
--此脚本应在新的空白数据库中运行
您可以手动收缩日志文件1.右键单击数据库>任务>收缩>文件>文件类型=日志 比还行