log_reuse_wait_desc为REPLICATION,日志暴大,无法收缩

数据库日志文件从几MB激增至350GB,检查发现log_reuse_wait_desc为REPLICATION。通过DBCC loginfo()查看所有VLF处于active状态。排查后发现并非复制引起,而是CDC开启且CDC Capture Job异常。手动启动Job并等待,最终成功备份日志并收缩。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

早上检查数据发现,有一台数据的硬盘空间只剩下几MB。习惯性检查日志文件,发现日志文件居然暴增到了350多GB

首先备份日志,再收缩-------无变化。(实际上日志备份每1小时1挡,正常在跑.)

---------------------------------------------------------------------------

检查日志空间占用及不能截断原因:

DBCC SQLPERF(LOGSPACE)  
GO  
SELECT name,recovery_model_desc,log_reuse_wait,log_reuse_wait_desc  
FROM sys.databases GO 

可以看到log_reuse_wait_des

log_reuse_wait replication是指在SQL Server数据库中,事务日志未能重用的原因之一是正在进行数据库复制操作。 数据库复制是一种将数据从一个数据库复制到另一个数据库的技术。在数据库复制期间,源数据库中的事务日志将被传输到目标数据库,并在目标数据库中重放,以确保数据的一致性。这意味着源数据库的事务日志无法被重用,直到它们在目标数据库中成功应用。 当我们在数据库中启用复制时,我们可能会在sys.databases视图的log_reuse_wait列中看到replication值。这表示事务日志无法重用,因为复制操作正在进行中。 要解决log_reuse_wait replication问题,我们需要确保复制操作正常运行并成功应用事务日志到目标数据库。如果复制操作中断或失败,我们可能需要调查并解决故障,以便事务日志可以重用。 一些常见的排查复制故障的方法包括: 1. 检查数据库复制代理账户的权限和连接配置是否正确。 2. 检查复制代理账户是否具有足够的权限来执行复制操作。 3. 检查目标数据库是否正常运行且可连接。 4. 检查源数据库和目标数据库之间的网络连接是否正常。 5. 检查复制拓扑配置是否正确,并确保所有复制相关的作业和代理是否正常运行。 通过解决复制故障并确保复制操作正常运行,我们可以解决log_reuse_wait replication问题,并使事务日志能够在数据库中正常重用。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值