La copia de seguridad detecta daños, pero CHECKDB no

Tengo una base de datos donde cuando ejecuto el comando de copia de seguridad

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

Me sale el mensaje de error

Msg 3043, Nivel 16, Estado 1, Línea 8
BACKUP 'MyDatabase' detectó un error en la página (1: 745345) en el archivo 'F: \ Data \ MyDatabase_1.ndf'.
Msg 3013, Nivel 16, Estado 1, Línea 8 La
BASE DE DATOS DE RESPALDO está finalizando de manera anormal.

Ejecuté un CHECKDB completo pero vuelve limpio. Me di cuenta de que la opción de verificación de página se había establecido en NINGUNO (no es mi tarea), así que la cambié a CHECKSUM y reconstruí todos los índices en la base de datos para que escribiera en todas las páginas y generara sumas de verificación. Después de esto, la copia de seguridad sigue fallando y el checkdb todavía se muestra limpio (por lo que no hay cambios).

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

del registro de SQL:

DBCC CHECKDB (MyDatabase) WITH all_errormsgs, no_infomsgs, data_purity ejecutado por xxx encontró 0 errores y reparó 0 errores. Tiempo transcurrido: 0 horas 21 minutos 46 segundos. La instantánea de la base de datos interna tiene un punto de división LSN = 000ab776: 0000112f: 0001 y el primer LSN = 000ab776: 0000112d: 0001.

Ejecuté DBCC PAGE pero tiene errores (ni siquiera parece devolver la página correcta en primer lugar). PUEDO ejecutarlo con la opción de impresión 2 y regresa, pero sinceramente, no sé qué estoy buscando allí.

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

PÁGINA: (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          

ENCABEZADO DE PÁGINA:


Página @ 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
Metadatos: AllocUnitId = 633462595911680 Metadatos: PartitionId = 0
Metadatos: IndexId = -1 Metadatos: 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

Estado de asignación

GAM (1: 511232) = SGAM ASIGNADO (1: 511233) = NO ASIGNADO     
PFS (1: 744096) = 0x40 ASIGNADO 0_PCT_FULL DIFF (1: 511238) = NO CAMBIADO
ML (1: 511239) = NO MIN_LOGGED      

Msg 2514, Nivel 16, Estado 8, Línea 20
Se ha producido un error de PÁGINA DBCC: Metadatos de página no válidos - no es posible el estilo de volcado 3.

¿Alguna idea de lo que podría probar a continuación? La versión del servidor es

select @@version

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

El nivel de compatibilidad de la base de datos es 100 (SQL 2008).

Esta respuesta está tomada de un número del boletín SQLskills.com escrito por Paul Randal, sobre "una base de datos que fallará una copia de seguridad con errores de suma de comprobación de página, pero pasó un DBCC CHECKDB".

El único momento en que esto puede suceder es cuando una extensión es una extensión mixta (donde las 8 páginas en la extensión se pueden asignar a potencialmente 8 unidades de asignaciones diferentes, ver aquí ) y algunas páginas se marcan erróneamente como asignadas por la página PFS relevante.

Cuando eso suceda, DBCC CHECKDBno intentará leer esas páginas, ya que deriva qué páginas leer de las páginas IAM de una unidad de asignación (la primera de las cuales enumera las páginas asignadas de forma mixta). Este caso es un vacío en DBCC CHECKDBla lógica de detección de corrupción.

[Porque] DBCC CHECKDBno pudo detectar la corrupción, no le fue posible hacer las reparaciones necesarias para repararlos. Entonces DBCC WRITEPAGE, usando , resolví los cambios necesarios en el estado de asignación para las páginas asignadas erróneamente, directamente en la página PFS, ¡y funcionó!

Este fue un caso extremadamente raro: es mucho más común que una DBCC CHECKDB falla pero una copia de seguridad tenga éxito.

En mi opinión, la resolución de Paul va mucho más allá de exportar e importar los datos como lo hizo usted, por lo que creo que hizo lo correcto.