Резервное копирование обнаруживает повреждение, но CHECKDB не делает

У меня есть база данных, где при запуске команды резервного копирования

BACKUP DATABASE [MyDatabase] TO     
DISK =  'G:\Backup\MyDatabase_01_01_2018.bak'   
WITH    NOFORMAT, NOSKIP, COMPRESSION, INIT, BUFFERCOUNT = 100

Я получаю сообщение об ошибке

Сообщение 3043, уровень 16, состояние 1, строка 8
BACKUP «MyDatabase» обнаружил ошибку на странице (1: 745345) в файле «F: \ Data \ MyDatabase_1.ndf».
Сообщение 3013, уровень 16, состояние 1, строка 8
BACKUP DATABASE завершается ненормально.

Я запустил полный CHECKDB, но он возвращается чистым. Я заметил, что для параметра Page Verify было задано значение NONE (не мое), поэтому я изменил его на CHECKSUM и перестроил все индексы в БД, чтобы заставить его записывать все страницы и генерировать контрольные суммы. После этого резервное копирование все еще не удается, и checkdb по-прежнему показывает чистый (так что никаких изменений).

DBCC CHECKDB('MyDatabase') WITH NO_INFOMSGS, ALL_ERRORMSGS,
DATA_PURITY, EXTENDED_LOGICAL_CHECKS;

из журнала SQL:

DBCC CHECKDB (MyDatabase) WITH all_errormsgs, no_infomsgs, data_purity, выполненная xxx, обнаружил 0 ошибок и исправил 0 ошибок. Прошедшее время: 0 часов 21 минута 46 секунд. Снимок внутренней базы данных имеет точку разделения LSN = 000ab776: 0000112f: 0001 и первый номер LSN = 000ab776: 0000112d: 0001.

Я запустил DBCC PAGE, но он выдает ошибки (даже, кажется, не возвращает нужную страницу в первую очередь). Я могу запустить его с опцией печати 2, и он возвращается, но, честно говоря, я не знаю, что я там ищу.

DBCC PAGE ('MyDatabase',1,745345,3)

СТРАНИЦА: (3: 513793)

BUFFER:


BUF @ 0x00000003811F8280

bpage = 0x00000000F2D70000 bhash = 0x0000000000000000 bpageno = (1: 745345)
bdbid = 5 записей = 0 bcputicks = 0
bsampleCount = 0 bUse1 = 44283 bstat = 0x809
blog = 0x5adb215a bnext = 0x0000000000000000          

ЗАГОЛОВОК СТРАНИЦЫ:


Page @ 0x00000000F2D70000

m_pageId = (3: 513793) m_headerVersion = 1 m_type = 2
m_typeFlagBits = 0x4 m_level = 0 m_flagBits = 0x0
m_objId (AllocUnitId.idObj) = 1075937538 m_indexId (AllocUnitId.idInd) = 2
Метаданные: AllocUnitId = 633462595911680 Метаданные: PartitionId = 0
Метаданные: IndexId = -1 Метаданные: ObjectId = 0 m_prevPage = (3: 513795)
m_nextPage = (3: 513820) pminlen = 17 m_slotCnt = 426
m_freeCnt = 2 m_freeData = 7338 m_reservedCnt = 0
m_lsn = (608841: 643611: 411) m_xactReserved = 0 m_xdesId = (0: 0)
m_ghostRecCnt = 0 m_tornBits = 0 ID фрагмента БД = 1

Статус распределения

GAM (1: 511232) = ВЫДЕЛЕННЫЙ SGAM (1: 511233) = НЕ ВЫДЕЛЕННЫЙ     
PFS (1: 744096) = 0x40 ALLOCATED 0_PCT_FULL DIFF (1: 511238) = НЕ ИЗМЕНЕНО
ML (1: 511239) = НЕ MIN_LOGGED      

Сообщение 2514, уровень 16, состояние 8, строка 20
Произошла ошибка DBCC PAGE: неверные метаданные страницы - стиль дампа 3 невозможен.

Есть идеи, что я мог бы попробовать дальше? Версия сервера

select @@version

Microsoft SQL Server 2014 (SP2-CU11) (KB4077063) - 12.0.5579.0 (X64) 
    21 февраля 2018 12:19:47 
    Авторское право (c) Microsoft Corporation
    Developer Edition (64-разрядная версия) в Windows NT 6.3 (сборка 9600:) (гипервизор)

Уровень совместимости БД - 100 (SQL 2008).

Этот ответ взят из выпуска информационного бюллетеня SQLskills.com, написанного Полом Рэндалом, о «базе данных, которая не может выполнить резервное копирование с ошибками контрольной суммы страницы, но прошла через DBCC CHECKDB».

Единственный случай, когда это может произойти, - это когда экстент является смешанным экстентом (где 8 страниц в экстенте могут быть выделены потенциально 8 различным единицам выделения - см. Здесь ), а некоторые страницы ошибочно помечены как выделенные соответствующей страницей PFS.

Когда это произойдет, DBCC CHECKDBне будет пытаться прочитать эти страницы, так как он определяет, какие страницы следует прочитать со страниц IAM блока распределения (первая из которых перечисляет страницы, выделенные из смешанного экстента). Этот случай - пробел в DBCC CHECKDBлогике обнаружения коррупции.

[Потому что] DBCC CHECKDBне смог обнаружить коррупцию, он не смог сделать ремонт, необходимый для их устранения. Итак, используя DBCC WRITEPAGE, я разработал изменения, необходимые в статусе выделения для ошибочно распределенных страниц, прямо на странице PFS, и это сработало!

Это был чрезвычайно редкий случай - гораздо чаще случается DBCC CHECKDB сбой, но резервное копирование будет успешным.

На мой взгляд, разрешение Пола намного превышает экспорт и импорт данных, как вы, поэтому я думаю, что вы поступили правильно.