O backup detecta corrupção, mas o CHECKDB não

Eu tenho um banco de dados onde, quando executo o comando backup

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

Eu recebo a mensagem de erro

A mensagem 3043, nível 16, estado 1, linha 8
BACKUP 'MyDatabase' detectou um erro na página (1: 745345) no arquivo 'F: \ Data \ MyDatabase_1.ndf'.
A mensagem 3013, nível 16, estado 1, linha 8
BACKUP DATABASE está sendo finalizada de maneira anormal.

Eu executei um CHECKDB completo, mas ele volta limpo. Percebi que a opção Verificação de página havia sido definida como NENHUM (não é o que eu fiz), então mudei para CHECKSUM e reconstruí todos os índices no banco de dados para que ele escreva em todas as páginas e gere somas de verificação. Depois disso, o backup ainda falha e o checkdb ainda mostra limpo (portanto, nenhuma alteração).

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

do log SQL:

DBCC CHECKDB (MyDatabase) WITH all_errormsgs, no_infomsgs, data_purity executado por xxx, encontrou 0 erros e reparou 0 erros. Tempo decorrido: 0 horas 21 minutos 46 segundos. A captura instantânea do banco de dados interno possui o ponto de divisão LSN = 000ab776: 0000112f: 0001 e o primeiro LSN = 000ab776: 0000112d: 0001.

Corri o DBCC PAGE, mas ele erros (nem parece estar retornando a página correta em primeiro lugar). POSSO executá-lo com a opção de impressão 2 e ele retorna, mas sinceramente não sei o que estou procurando lá.

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

PÁGINA: (3: 513793)

AMORTECEDOR:


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          

CABEÇALHO DA PÁGINA:


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
Metadados: AllocUnitId = 633462595911680 Metadados: PartitionId = 0
Metadados: IndexId = -1 Metadados: 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 de frag do banco de dados = 1

Status de alocação

GAM (1: 511232) = SGAM ALOCADO (1: 511233) = NÃO ALOCADO     
PFS (1: 744096) = 0x40 ALOCADO 0_PCT_FULL DIFF (1: 511238) = NÃO MUDADO
ML (1: 511239) = NÃO MIN_LOGGED      

Msg 2514, Nível 16, Estado 8, Linha 20
Ocorreu um erro de DBCC PAGE: Metadados de página inválidos - o estilo de despejo 3 não é possível.

Alguma idéia do que eu poderia tentar a seguir? A versão do servidor é

select @@version

Microsoft SQL Server 2014 (SP2-CU11) (KB4077063) - 12.0.5579.0 (X64) 
    21 de fevereiro de 2018 12:19:47 
    Direitos autorais (c) Microsoft Corporation
    Developer Edition (64 bits) no Windows NT 6.3 (Build 9600:) (Hypervisor)

O nível de compatibilidade do banco de dados é 100 (SQL 2008).

Esta resposta foi retirada de uma edição do boletim informativo do SQLskills.com escrito por Paul Randal, sobre "um banco de dados que falharia em um backup com erros de soma de verificação de página, mas passava por um DBCC CHECKDB".

O único momento em que isso pode acontecer é quando uma extensão é mista (onde as 8 páginas na extensão podem ser alocadas para potencialmente 8 unidades de alocações diferentes - veja aqui ) e algumas páginas são marcadas erroneamente como alocadas na página relevante do PFS.

Quando isso acontece, DBCC CHECKDBnão tentará ler essas páginas, pois deriva quais páginas serão lidas nas páginas IAM de uma unidade de alocação (a primeira lista as páginas alocadas de uma extensão mista). Este caso é uma lacuna na DBCC CHECKDBlógica de detecção de corrupção.

Como DBCC CHECKDBnão foi possível detectar a corrupção, não foi possível fazer os reparos necessários para corrigi-los. Então DBCC WRITEPAGE, usando , resolvi as alterações necessárias no status de alocação para as páginas alocadas erroneamente, diretamente na página do PFS, e funcionou!

Este foi um caso extremamente raro - é muito mais comum que uma DBCC CHECKDB falha, mas um backup seja bem-sucedido.

Na minha opinião, a resolução de Paul está muito além de exportar e importar os dados como você fez, então acho que você fez a coisa certa.