Eri*_*obb 13 sql-server corruption transparent-data-encryption sql-server-2017
在 SQL Server 2017 (CU3) 上，每当我在我的一个 TDE 数据库上启用备份压缩时，备份过程总是会损坏数据库中的特定页面。如果我在不压缩的情况下运行备份，它不会被损坏。以下是我为验证和重现此问题而采取的步骤：
总结一下：数据库和常规备份看起来不错，在数据库上运行 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 = 0x0000000000000000
bpageno =（1：92454）bdbid = 8 breferences = 0 bcputicks = 563 bsampleCount = 1
bUse1 = 51429 BSTAT = 0x809博客= 0x15a
bnext编辑= 0x0000000000000000 bDirtyContext = 0x0000000000000000 bstat2 =为0x0页眉：
页@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元数据：AllocUnitId = 145011308798541824元数据：的partitionid = 0元数据： IndexID为= -1元数据：的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 DB Frag 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，则会出现以下错误：
DBCC PAGE with option 1: Msg 0, Level 11, State 0, Line 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_page_iam_file_id = 1 allocated_page_iam_page_id = 104
allocated_page_file_id = 1 allocated_page_page_id = 92454
is_allocated = 0 is_iam_page = 0 is_mixed_page_allocation = 0
看起来这个问题与运行了 SHRINK 操作的数据库有关。就我而言，我在 SQL Server 2014（已经用 TDE 加密）上复制了我们的一个生产数据库，在数据和日志文件上运行 DBCC SHRINKFILE，然后进行备份并在我的新 SQL 上恢复它2017 服务器。（收缩的原因是为了减小大小以使传输备份更快。）
作为测试，我恢复了一个我没有在其上运行 DBCC SHRINKFILE 的数据库副本，并且在压缩备份时它没有损坏问题。
所以，总而言之，我的测试结果如下：
我不知道这是否是 SQL Server 2017 中已确认的错误，但我已将我的发现发送给 Microsoft，供他们查看。
所以，这个故事的寓意是：不要缩小你的数据库！曾经！:)