主页 / user-44096

Eric Cobb's questions

Martin Hope
Eric Cobb
Asked: 2018-01-11 07:32:07 +0800 CST
  • 13

在 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
Martin Hope
Eric Cobb
Asked: 2017-04-20 06:46:09 +0800 CST
  • 7

我有一张不断更新的表格，没有人能弄清楚更新的来源。我怀疑它们来自实体框架，但我想通过扩展事件捕获更新和相关信息来证明这个理论。

我在 SQL 2014 Enterprise 上，并尝试使用 exec_prepared_sql 和 sql_statement_starting 事件来捕获该信息。这是我到目前为止所拥有的：

CREATE EVENT SESSION [Query Trace] ON SERVER 
ADD EVENT sqlserver.exec_prepared_sql(
    ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_id,sqlserver.database_name,sqlserver.plan_handle,sqlserver.session_id,sqlserver.sql_text,sqlserver.username)
    WHERE ([sqlserver].[like_i_sql_unicode_string]([sqlserver].[sql_text],N'%UPDATE %') AND [sqlserver].[like_i_sql_unicode_string]([sqlserver].[sql_text],N'%TableA%') AND [sqlserver].[database_id]=(123))),
ADD EVENT sqlserver.sql_statement_starting(
    ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_id,sqlserver.database_name,sqlserver.plan_handle,sqlserver.session_id,sqlserver.sql_text,sqlserver.username)
    WHERE ([sqlserver].[like_i_sql_unicode_string]([sqlserver].[sql_text],N'%UPDATE %') AND [sqlserver].[like_i_sql_unicode_string]([sqlserver].[sql_text],N'%TableA%') AND [sqlserver].[database_id]=(123)))
ADD TARGET package0.event_file(SET filename=N'E:\ExtendedEvent\Query-Trace.xel')
WITH (MAX_MEMORY=4096 KB,EVENT_RETENTION_MODE=ALLOW_SINGLE_EVENT_LOSS,MAX_DISPATCH_LATENCY=30 SECONDS,MAX_EVENT_SIZE=0 KB,MEMORY_PARTITION_MODE=NONE,TRACK_CAUSALITY=ON,STARTUP_STATE=OFF)
GO

这似乎运作良好，我已经对其进行了测试，并且能够捕获常规 UPDATE 语句和使用 sp_executesql 调用的语句。但是，我仍然缺少一些东西。表中的数据仍在修改中，并且此扩展事件未捕获执行此操作的 UPDATE。

所以，我的问题是：

1) 为了捕获可能来自实体框架的更新，我还需要在扩展事件中观看其他内容吗？

2）我应该使用其他东西来代替扩展事件吗？

谢谢！

sql-server sql-server-2014