时间戳

首页 > 解决方案 > SQL Server :: FULL 备份未记录在 msdb.dbo.backupset 和日志文件异常大

sql-server - SQL Server :: FULL 备份未记录在 msdb.dbo.backupset 和日志文件异常大

问题描述

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

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

在此处输入图像描述

所以我发现这个指南说它可能是 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 0对我来说一切都很好，它看起来像is_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几乎无处不在：

在此处输入图像描述

标签： sql-serversql-server-2012backupsql-server-2019dbcc

解决方案

...解决方案是：

我们使用Always On availability groups并在故障转移环境（副本服务器）上进行了备份。

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

推荐阅读