Резервне копіювання виявляє корупцію, але CHECKDB цього не робить

У мене є база даних, де я запускаю команду резервного копіювання

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

Я отримую повідомлення про помилку

Msg 3043, рівень 16, стан 1, рядок 8
РЕКЛАМА "MyDatabase" виявила помилку на сторінці (1: 745345) у файлі "F: \ Data \ MyDatabase_1.ndf".
Повідомлення 3013, Рівень 16, Стан 1, Рядок 8
БЕЗПЕКА БАКУПАЦІЇ закінчується аномально.

Я побіг повний CHECKDB, але він повертається чистим. Я помітив, що для параметра «Перевірка сторінки» було встановлено значення «НІКОЛЬНЕ» (не я займаюсь), тому змінив його на «CHECKSUM» і відновив усі індекси в БД, щоб він міг записувати на всі сторінки та створювати контрольні суми. Після цього резервна копія все-таки виходить з ладу, і checkdb все ще відображається чистим (тому ніяких змін).

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

з журналу SQL:

DBCC CHECKDB (база даних MyData) З all_errormsgs, no_infomsgs, data_purance, виконаними 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)

БУФЕР:


BUF @ 0x00000003811F8280

bpage = 0x00000000F2D70000 bhash = 0x0000000000000000 bpageno = (1: 745345)
bdbid = 5 бреферів = 0 bcputicks = 0
bsampleCount = 0 bUse1 = 44283 bstat = 0x809
blog = 0x5adb215a bnext = 0x0000000000000000          

СТОРІНКА КОРИСТУВАЧА:


Сторінка @ 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 Ідентифікатор фрагмента БД = 1

Статус розподілу

GAM (1: 511232) = ALLOCATED SGAM (1: 511233) = НЕ РОЗДІЛЕНО     
PFS (1: 744096) = 0x40 ALLOCATED 0_PCT_FULL DIFF (1: 511238) = НЕ ЗМІНЕНО
ML (1: 511239) = NOT MIN_LOGGED      

Msg 2514, Рівень 16, Стан 8, Рядок 20
Сталася помилка PAGE DBCC: Неправильні метадані сторінки - стиль демпінгу 3 не можливий.

Будь-які ідеї, що я можу спробувати далі? Версія сервера є

select @@version

Microsoft SQL Server 2014 (SP2-CU11) (KB4077063) - 12.0.5579.0 (X64) 
    21 лютого 2018 12:19:47 
    Авторські права (c) Корпорація Microsoft
    Версія для розробників (64-розрядна) для Windows NT 6.3 (Build 9600:) (Hypervisor)

Рівень сумісності БД становить 100 (SQL 2008).

Ця відповідь взята з випуску інформаційного бюлетеня SQLskills.com, написаного Полом Рандалом, про "базу даних, яка не змогла б створити резервну копію з помилками контрольної суми сторінки, але передала DBCC CHECKDB".

Єдиний раз, коли це може статися, це коли міра є змішаною мірою (де 8 сторінок в обсязі можна розподілити на потенційно 8 різних одиниць розподілу - див. Тут ), а деякі сторінки помилково позначені як виділені відповідною сторінкою PFS.

Коли це станеться, DBCC CHECKDBвони не намагатимуться прочитати ці сторінки, оскільки це отримує, які сторінки читати із сторінок IAM одиниці розподілу (перша з яких перераховує сторінки, виділені зі змішаною мірою). Цей випадок є прогалиною в DBCC CHECKDBлогіці виявлення корупції.

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

Це був надзвичайно рідкісний випадок - набагато частіше зустрічається DBCC CHECKDB помилка, але резервне копіювання буде успішним.

На мою думку, резолюція Павла набагато вище експорту та імпорту даних, як ви, тому я думаю, ви зробили правильно.