最可能的答案是您需要运行日志备份或者有一个打开的事务。
这里还有一点可以帮助你...
在您的服务器上运行此脚本:
-- last FULL backup
;with FULLBUs
as (
select d.name, max(b.backup_finish_date) as 'Last FULL Backup'
from sys.databases d
join msdb.dbo.backupset b
on d.name = b.database_name
where b.type = 'D'
group by d.name
),
-- last LOG backup for FULL and BULK_LOGGED databases
LOGBUs
as (
select d.name, max(b.backup_finish_date) as 'Last LOG Backup'
from sys.databases d
join msdb.dbo.backupset b
on d.name = b.database_name
where d.recovery_model_desc <> 'SIMPLE'
and b.type = 'L'
group by d.name
)
-- general overview of databases, recovery model, and what is filling the log, last FULL, last LOG
select d.name, d.state_desc, d.recovery_model_desc, d.log_reuse_wait_desc, f.[Last FULL Backup], l.[Last LOG Backup]
from sys.databases d
left outer join FULLBUs f
on d.name = f.name
left outer join LOGBUs l
on d.name = l.name
where d.name not in ('model', 'TempDB')
order by d.name
此查询将为您提供数据库的粗略概述、它们使用的恢复模式、日志已满的原因以及上次 FULL 和 LOG 备份的运行时间。
查看标记为 log_reuse_wait_description 的列。很可能它说 BACKUP。下一个最可能的原因是TRANSACTION。
如果是BACKUP,这里有一些信息:
基本上,对于您的 SIMPLE 数据库,每天运行一次完整备份。对于 FULL 数据库,每天运行一次 FULL 备份,每小时运行一次 LOG 备份。调整 LOG 数据库的频率,以匹配您在保住工作的同时丢失数据的能力。
管理备份的最简单方法是使用Ola Hallengren's maintenance scripts。访问他的网站并尝试使用它们。
如果您看到 TRANSACTION 是原因,请尝试运行:
dbcc opentran
并追踪拥有未结交易的人。