【问题标题】:SQL Server :: FULL backup not recorded in msdb.dbo.backupset and log file unusually largeSQL Server :: FULL 备份未记录在 msdb.dbo.backupset 和日志文件异常大
【发布时间】:2020-09-23 11:04:58
【问题描述】:

我有一台运行 SQL Server 2019 的服务器,但数据库仍在 Compatibility level 110 上(这意味着基本上是 SQL Server 2012)。

我们每晚都会进行一次完整备份,我确实每天都看到文件备份在正确的文件夹中。但是,如果我运行 this query 并添加 backup_finish_date desc 以检查上次完整备份的时间,我会看到日期是几个月前:

所以我发现 this guide 说它可能是 SQL Server 中的一个错误并要求运行此检查:

USE msdb
GO
SELECT server_name, database_name, backup_start_date, is_snapshot, database_backup_lsn
FROM backupset

"...在结果中,请注意 database_backup_lsn 列和 is_snapshot 列。表示实际数据库备份操作的条目具有以下特征: database_backup_lsn 列的值不为 0。 is_snapshot 列的值为 0。”

对我来说一切都很好,看起来像 database_backup_lsn column is not 0is_snapshot column is 0

然后指南说运行这个查询来验证备份的完整性:

WITH backupInfo AS( SELECT database_name AS [DatabaseName], 
name AS [BackupName], is_damaged AS [BackupStatus],
backup_start_date AS [backupDate],
ROW_NUMBER() OVER(PARTITION BY database_name 
ORDER BY backup_start_date DESC) AS BackupIDForDB 
FROM msdb..backupset) SELECT DatabaseName 
FROM backupinfo WHERE BackupIDForDB = 1 and BackupStatus=1 

结果什么都没有!

指南说:“...如果此查询返回任何结果,则表示您在报告日期之后没有良好的数据库备份。”

所以现在我害怕我们的备份被搞砸了。我们使用CHECKSUM 进行备份,但我们已经很久没有运行DBCC CHECKDB,所以我们可能(成功并使用CHECKSUM)对损坏的数据库进行备份。让我们跑吧:

DBCC CHECKDB('msdb') WITH NO_INFOMSGS, ALL_ERRORMSGS

结果什么都没有,所以看起来一切都很好。

同时日志文件 (155GB) 的大小与 514GB 的数据文件大小相比显得异常大

编辑:

我每晚都进行完整备份,每小时进行一次日志备份

编辑 2:

Brent Ozar 建议运行 SELECT name, log_reuse_wait_desc FROM sys.databases;,结果我几乎到处都有 NOTHING

【问题讨论】:

  • 关于日志,您多久执行一次事务日志备份?您提到您每天进行一次完整备份,但事务日志备份上没有任何内容。
  • 谢谢@Larnu,我每天进行一次完整备份,每小时进行一次日志备份

标签: sql-server sql-server-2012 backup sql-server-2019 dbcc


【解决方案1】:

...解决方案是:

我们使用Always On availability groups,并且备份是在故障转移环境(副本服务器)上进行的。

我在网上看到很多与我类似的问题,但他们并没有真正的答案。我相信我不是唯一一个面临这个问题的人

【讨论】:

    猜你喜欢
    • 2010-10-23
    • 1970-01-01
    • 2020-10-28
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2012-10-06
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多