SQL Server日志文件是巨大的
目前，我生产的Server 2008 R2服务器的数据库日志正在失控：
- 数据文件:磁盘上的D:\Data...\MyDB.mdf = 278859 MB
- 日志文件:磁盘上的L:\Logs...\MyDB_1.ldf = 394542 MB
上面提到的服务器计划每天备份一次@1am & translog备份，每15分钟一次。
数据库以完全恢复模式复制到订阅服务器。复制是从上面的节点(publisher)中推送的。订阅服务器上相同的db日志文件是磁盘上的~< 100 GB。
我做了些什么来修复：
- 运行db的完整备份(耗时1小时:47米)
- 运行translog备份作业，每15分钟运行一次。(1M:20)
- 运行另一个数据库的完整备份。
上面没有工作，所以我尝试收缩日志文件，而日志文件使用都不起作用。尺寸永远不会变。
谁能告诉我，作为Server，有什么问题或者我需要做些什么来解决上面的问题？
回答 4
Stack Overflow用户
发布于 2016-02-10 22:18:23
可能会阻止您缩小translog文件：
- 数据库上正在发生长时间运行的事务。
- 您的复制分发代理运行非常频繁。
看看translog文件大小，很可能是第二种可能性造成的。
您的复制分发代理运行非常频繁的
Server日志读取器代理将translog文件标记为已使用，并防止其收缩，这是Server备份translog文件后所做的工作。如果此过程发生频繁且时间足够长，则可能会防止translog文件在translog计划备份时收缩。
看看这个MSDN事务性解释，以及如何修改日志读取器代理。
还有一个描述类似问题的MSDN论坛中的线程，这里有DBCC查询，它帮助您识别可能阻塞translog文件(DBCC OPENTRAN)的正在运行的事务。
长时间运行的事务正在数据库上发生
您可以使用DBCC检查是否正在发生任何长时间运行的事务，以及正在运行什么进程，然后决定如何处理它。一旦长时间运行的事务完成，您就应该能够收缩日志文件。
Stack Overflow用户
发布于 2016-02-11 20:30:03
在运行sp_who2之后，我注意到日志上有一个长时间运行的事务正在失控地增长。我在SPID上使用了杀死，而不是继续缩小日志文件。
Stack Overflow用户
发布于 2016-05-29 11:38:28
您应该使用相同的表创建空白数据库，并将旧的数据库数据从迁移脚本迁移到空白数据库。如:插入客户( cust_id，姓名，地址)选择cust_id，名称，地址从olddb.customers
-这个脚本应该在新的空白数据库中运行
https://stackoverflow.com/questions/35327005
复制相似问题
腾讯云开发者
