主页 / dba / 问题 / 195078
Accepted
Eric Cobb
Asked: 2018-01-11 07:32:07 +0800 CST

备份压缩导致 SQL 2017 TDE 数据库损坏

  • 772

在 SQL Server 2017 (CU3) 上，每当我在我的一个 TDE 数据库上启用备份压缩时，备份过程总是会损坏数据库中的特定页面。如果我在没有压缩的情况下运行备份，它不会损坏。以下是我为验证和重现此问题而采取的步骤：

  1. 在数据库“TDE_DB1”上运行 DBCC CheckDB；一切都很好，没有错误；
  2. 不压缩成功备份数据库；RESTORE VERIFYONLY 表示一切正常；
  3. 成功将数据库恢复为“TDE_DB2”；一切都很好，DBCC CheckDB 显示没有错误；
  4. 使用压缩成功备份“TDE_DB1”数据库；RESTORE VERIFYONLY 错误，提示“检测到备份集损坏”；
  5. 尝试将数据库恢复为“TDE_DB2”；错误，说“RESTORE 在数据库中的页面 (1:92454) 上检测到错误”
  6. 重复步骤1-3；一切都很好;
  7. 删除“TDE_DB1”和“TDE_DB2”；从备份中恢复“TDE_DB1”；一切都很好;
  8. 重复步骤1-5；得到相同的结果；

总结一下：数据库和常规备份看起来很好，在数据库上运行 CHECKDB 并在备份上运行 VERIFYONLY 不会报告任何错误。使用压缩备份数据库似乎会导致损坏。

以下是有错误的代码示例。（注意：在 TDE 数据库中使用压缩需要 MAXTRANSFERSIZE）

-- Good, completes with no corruption;
BACKUP DATABASE [TDE_DB1] TO DISK = N'E:\MSSQL\Backup\TDE_DB1a.bak' WITH CHECKSUM;
RESTORE VERIFYONLY FROM DISK = N'E:\MSSQL\Backup\TDE_DB1a.bak' WITH CHECKSUM;

RESTORE DATABASE [TDE_DB2]
FROM DISK = 'E:\MSSQL\Backup\TDE_DB1a.bak'
WITH MOVE 'DataFileName' to 'E:\MSSQL\Data\TDE_DB2.mdf'
,MOVE 'LogFileName' to 'F:\MSSQL\Log\TDE_DB2_log.ldf';


-- Bad, I haz corruption;
BACKUP DATABASE [TDE_DB1] TO DISK = N'E:\MSSQL\Backup\TDE_DB1b.bak' WITH CHECKSUM, COMPRESSION, MAXTRANSFERSIZE = 131072;
RESTORE VERIFYONLY FROM DISK = N'E:\MSSQL\Backup\TDE_DB1b.bak' WITH CHECKSUM;
-- ERROR
--Msg 3189, Level 16, State 1, Line 1
--Damage to the backup set was detected.
--Msg 3013, Level 16, State 1, Line 1
--VERIFY DATABASE is terminating abnormally.

RESTORE DATABASE [TDE_DB2]
FROM DISK = 'E:\MSSQL\Backup\TDE_DB1b.bak'
WITH MOVE 'DataFileName' to 'E:\MSSQL\Data\TDE_DB2.mdf'
,MOVE 'LogFileName' to 'F:\MSSQL\Log\TDE_DB2_log.ldf';
-- ERROR
--Msg 3183, Level 16, State 1, Line 7
--RESTORE detected an error on page (1:92454) in database "TDE_DB2" as read from the backup set.
--Msg 3013, Level 16, State 1, Line 7
--RESTORE DATABASE is terminating abnormally.

然后我尝试检查报告为有错误的页面（它始终是同一页面。），但 DBCC PAGE 报告 ObjectId 为 0。 根据 Paul Randal 的这篇文章，这意味着没有找到元数据，并且原因之一可能是页面本身已损坏，并且使用了不正确的值来尝试查找元数据。他的建议是运行 CHECKDB，但我不能这样做，因为损坏的备份无法恢复。

我尝试了这个 SO Post（将 INIT 和 FORMAT 添加到 BACKUP 命令）中的建议来重置元数据，但这似乎没有改变任何东西，我仍然在压缩备份上损坏。

这只发生在我的一个 TDE 数据库中。我在同一台服务器上还有 4 个其他 TDE 数据库，它们没有这个问题。这告诉我这个特定数据库可能存在潜在问题。我意识到简单的解决方案就是不使用压缩，但我觉得这实际上可能是对即将出现的更大问题的早期警告。

有没有人以前见过这个，或者知道为什么压缩会损坏该页面？在这一点上，我有点不知道下一步该怎么做。我考虑过从较早的备份中恢复页面，但我认为这无关紧要，因为常规数据库中的页面看起来很好。

更新 1： 以下是 DBCC PAGE 的结果，选项为 0：

DBCC 执行完成。如果 DBCC 打印出错误消息，请联系您的系统管理员。

页：（1:92454）

缓冲：

BUF @0x000002187AE55640

bpage = 0x000002184865e000 bhash = 0x000000000000000000
bpageno =（1：92454）bdbid = 8 breferences = 0 bcputicks = 0 bcputicks = 563 bsamplecount = 1 buse1 = 1
buse1 = 51429 bstat = 51429 bstat = 0x809blet000000000000
00000000000000000000000000000000000000000000个

页眉：

页面@0x000002184865E000

m_pageId = (1:92454) m_headerVersion = 111
m_type = 189 m_typeFlagBits = 0x2d m_level = 197
m_flagBits = 0x525e m_objId (AllocUnitId.idObj) = 788815194
m_indexId (AllocUnitId.idInd) = 515 Metadata: AllocUnitId = 145011308798541824 Metadata: PartitionId = 0 Metadata: IndexId = -1 Metadata: ObjectId = 0 m_prevPage = (32842:1881351155) m_nextPage = (13086:-560562340)
pminlen = 36067 m_slotCnt = 8149 m_freeCnt = 51871 m_freeData = 7295 m_reservedCnt = 4810 m_lsn = (742012401:720884976:30191) m_xactReserved = 14755
m_xdesId = (12811:1559482793) m_ghostRecCnt = 12339
m_tornBits = -1381699202 数据库片段 ID = 1

分配状态

GAM (1:2) = 已分配 SGAM (1:3) =
未分配 PFS (1:88968) = 0x0 0_PCT_FULL DIFF (1:6) = 未更改
ML (1:7) = NOT MIN_LOGGED

如果我尝试使用其他选项运行 DBCC PAGE，我会收到以下错误：

带有选项 1 的 DBCC PAGE：消息 0，级别 11，状态 0，第 0 行当前命令发生严重错误。结果，如果有的话，应该被丢弃。

带选项 3 的 DBCC PAGE：消息 2514，级别 16，状态 5，第 3 行 发生 DBCC PAGE 错误：页面类型无效 - 转储样式 3 不可能。

更新 2： 以下是 sys.dm_db_database_page_allocations DMO 的一些结果：

object_id = 75 index_id = 1 rowset_id = 281474981625856 allocation_unit_id = 281474981625856
allocation_unit_type = 1 allocation_unit_type_desc = IN_ROW_DATA extent_file_id = 1 extent_page_id = 92448
allocated_pa​​ge_iam_file_id = 1 allocated_pa​​ge_iam_page_id = 104
allocated_pa​​ge_file_id = 1 allocated_pa​​ge_page_id = 92454
is_allocated = 0 is_iam_page = 0 is_mixed_pa​​ge_allocation = 0

sql-server corruption

1 个回答

  1. Best Answer

    看起来这个问题与运行了 SHRINK 操作的数据库有关。在我的例子中，我在 SQL Server 2014 上复制了我们的一个生产数据库（已经用 TDE 加密），在数据和日志文件上运行 DBCC SHRINKFILE，然后备份并在我的新 SQL 上恢复它2017服务器。（缩小的原因是为了减小尺寸，以便更快地传输备份。）

    作为测试，我恢复了一份没有运行 DBCC SHRINKFILE 的数据库副本，并且在压缩备份时它没有损坏问题。

    所以，总结一下，我的测试结果如下：

    • 这个“缩小的”TDE 数据库的正常备份/恢复操作在 SQL 2017 中正常工作
    • 压缩“缩小的”TDE 数据库的备份似乎会导致 sys.sysmultiobjrefs 表损坏
    • 压缩常规 TDE 数据库的备份（没有运行 DBCC SHRINKFILE）工作正常并且不报告损坏

    我不知道这是否是 SQL Server 2017 中已确认的错误，但我已将我的发现发送给 Microsoft 以供他们查看。

    所以，这个故事的寓意是：不要收缩你的数据库！曾经！:)

    • 8

相关问题