Il backup rileva la corruzione, ma CHECKDB no

Ho un database in cui quando eseguo il comando di backup

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

Ricevo il messaggio di errore

Messaggio 3043, livello 16, stato 1, riga 8
BACKUP "MyDatabase" ha rilevato un errore nella pagina (1: 745345) nel file "F: \ Data \ MyDatabase_1.ndf".
Messaggio 3013, livello 16, stato 1, riga 8
BACKUP DATABASE si sta chiudendo in modo anomalo.

Ho eseguito un CHECKDB completo ma torna pulito. Ho notato che l'opzione Verifica pagina era stata impostata su NESSUNO (non il mio compito), quindi l'ho cambiata in CHECKSUM e ricostruito tutti gli indici nel DB per farlo scrivere su tutte le pagine e generare checksum. Dopodiché il backup non riesce ancora e il checkdb mostra ancora pulito (quindi nessuna modifica).

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

dal registro SQL:

DBCC CHECKDB (MyDatabase) WITH all_errormsgs, no_infomsgs, data_purity eseguito da xxx ha trovato 0 errori e riparati 0 errori. Tempo trascorso: 0 ore 21 minuti 46 secondi. L'istantanea del database interno ha il punto di splittaggio LSN = 000ab776: 0000112f: 0001 e il primo LSN = 000ab776: 0000112d: 0001.

Ho eseguito DBCC PAGE ma si tratta di errori (non sembra nemmeno che stia restituendo la pagina giusta in primo luogo). POSSO eseguirlo con l'opzione di stampa 2 e ritorna ma onestamente non so cosa sto cercando lì.

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

PAGINA: (3: 513793)

BUFFER:


BUF @ 0x00000003811F8280

bpage = 0x00000000F2D70000 bhash = 0x0000000000000000 bpageno = (1: 745345)
bdbid = 5 breferences = 0 bcputicks = 0
bsampleCount = 0 bUse1 = 44283 bstat = 0x809
blog = 0x5adb215a bnext = 0x0000000000000000          

INTESTAZIONE DI PAGINA:


Pagina @ 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
Metadati: AllocUnitId = 633462595911680 Metadati: PartitionId = 0
Metadati: IndexId = -1 Metadata: 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 DB Frag ID = 1

Stato di allocazione

GAM (1: 511232) = SGAM ASSEGNATO (1: 511233) = NON ASSEGNATO     
PFS (1: 744096) = 0x40 ASSEGNATO 0_PCT_FULL DIFF (1: 511238) = NON MODIFICATO
ML (1: 511239) = NON MIN_LOGGED      

Messaggio 2514, livello 16, stato 8, riga 20
Si è verificato un errore PAGINA DBCC: metadati di pagina non validi - stile di dump 3 non possibile.

Qualche idea su cosa potrei provare dopo? La versione del server è

select @@version

Microsoft SQL Server 2014 (SP2-CU11) (KB4077063) - 12.0.5579.0 (X64) 
    21 febbraio 2018 12:19:47 
    Copyright (c) Microsoft Corporation
    Developer Edition (64 bit) su Windows NT 6.3 (Build 9600:) (Hypervisor)

Il livello di compatibilità del DB è 100 (SQL 2008).

Questa risposta è tratta da un numero della newsletter di SQLskills.com scritta da Paul Randal, su "un database che fallirebbe un backup con errori di checksum della pagina, ma che ha passato un DBCC CHECKDB".

L'unica volta che ciò può accadere è quando un'estensione è un'estensione mista (in cui le 8 pagine nell'estensione possono essere allocate a potenzialmente 8 diverse unità di allocazione - vedere qui ) e alcune pagine sono erroneamente contrassegnate come allocate dalla relativa pagina PFS.

Quando ciò accade, DBCC CHECKDBnon tenterà di leggere quelle pagine, poiché deriva quali pagine leggere dalle pagine IAM di un'unità di allocazione (la prima delle quali elenca le pagine allocate da una dimensione mista). Questo caso rappresenta una lacuna nella DBCC CHECKDBlogica di rilevamento della corruzione.

[Poiché] DBCC CHECKDBnon è stato in grado di rilevare la corruzione, non è stato possibile effettuare le riparazioni necessarie per risolverli. Quindi DBCC WRITEPAGE, usando , ho elaborato le modifiche necessarie nello stato di allocazione per le pagine allocate erroneamente, direttamente nella pagina PFS, e ha funzionato!

Si è trattato di un caso estremamente raro: è molto più comune che un DBCC CHECKDB errore abbia esito negativo ma un backup abbia esito positivo.

Secondo me, la risoluzione di Paul va ben oltre l'esportazione e l'importazione dei dati come hai fatto tu, quindi penso che tu abbia fatto la cosa giusta.