La compresión de copia de seguridad provoca daños en la base de datos TDE de SQL 2017

13

En SQL Server 2017 (CU3), cada vez que habilito la compresión de respaldo en una de mis bases de datos TDE, el proceso de respaldo siempre corrompe una página específica en la base de datos. Si ejecuto la copia de seguridad sin compresión, no se corrompe. Estos son los pasos que he tomado para verificar y reproducir este problema:

  1. Ejecute DBCC CheckDB en la base de datos "TDE_DB1"; todo está bien, sin errores;
  2. Haga una copia de seguridad exitosa de la base de datos sin compresión; RESTORE VERIFYONLY dice que todo está bien;
  3. Restaurar con éxito la base de datos como "TDE_DB2"; todo está bien, DBCC CheckDB no muestra errores;
  4. Haga una copia de seguridad exitosa de la base de datos "TDE_DB1" CON compresión; RESTORE VERIFYONLY errores, diciendo "Se detectó daño al conjunto de copia de seguridad";
  5. Intenta restaurar la base de datos como "TDE_DB2"; errores, diciendo "RESTORE detectó un error en la página (1: 92454) en la base de datos"
  6. Repita los pasos 1-3; todo es bueno;
  7. DROP "TDE_DB1" y "TDE_DB2"; Restaurar "TDE_DB1" desde la copia de seguridad; todo es bueno;
  8. Repita los pasos 1-5; obtener los mismos resultados;

Para resumir: la base de datos y las copias de seguridad regulares parecen estar bien, ejecutando CHECKDB en la base de datos y VERIFYONLY en las copias de seguridad no informan ningún error. Copia de seguridad de la base de datos con compresión parece causar la corrupción.

A continuación se muestran los ejemplos de código con errores. (Nota: se requiere MAXTRANSFERSIZE para usar la compresión con una base de datos TDE )

-- Good, completes with no corruption;
BACKUP DATABASE [TDE_DB1] TO DISK = N'E:\MSSQL\Backup\TDE_DB1a.bak' WITH CHECKSUM;
RESTORE VERIFYONLY FROM DISK = N'E:\MSSQL\Backup\TDE_DB1a.bak' WITH CHECKSUM;

RESTORE DATABASE [TDE_DB2]
FROM DISK = 'E:\MSSQL\Backup\TDE_DB1a.bak'
WITH MOVE 'DataFileName' to 'E:\MSSQL\Data\TDE_DB2.mdf'
,MOVE 'LogFileName' to 'F:\MSSQL\Log\TDE_DB2_log.ldf';


-- Bad, I haz corruption;
BACKUP DATABASE [TDE_DB1] TO DISK = N'E:\MSSQL\Backup\TDE_DB1b.bak' WITH CHECKSUM, COMPRESSION, MAXTRANSFERSIZE = 131072;
RESTORE VERIFYONLY FROM DISK = N'E:\MSSQL\Backup\TDE_DB1b.bak' WITH CHECKSUM;
-- ERROR
--Msg 3189, Level 16, State 1, Line 1
--Damage to the backup set was detected.
--Msg 3013, Level 16, State 1, Line 1
--VERIFY DATABASE is terminating abnormally.

RESTORE DATABASE [TDE_DB2]
FROM DISK = 'E:\MSSQL\Backup\TDE_DB1b.bak'
WITH MOVE 'DataFileName' to 'E:\MSSQL\Data\TDE_DB2.mdf'
,MOVE 'LogFileName' to 'F:\MSSQL\Log\TDE_DB2_log.ldf';
-- ERROR
--Msg 3183, Level 16, State 1, Line 7
--RESTORE detected an error on page (1:92454) in database "TDE_DB2" as read from the backup set.
--Msg 3013, Level 16, State 1, Line 7
--RESTORE DATABASE is terminating abnormally.

Luego traté de verificar la página que informa que tiene el error (siempre es la misma página), pero DBCC PAGE informa que el ObjectId es 0. De acuerdo con este artículo de Paul Randal, eso significa que no se encontraron metadatos, y Una de las razones podría ser que la página en sí está corrupta y se usaron valores incorrectos para intentar buscar los metadatos. Su consejo es ejecutar CHECKDB, lo que no puedo hacer porque la copia de seguridad dañada no se restaurará.

Intenté las sugerencias de esta publicación SO (Agregar INIT y FORMAT al comando BACKUP) para restablecer los metadatos, pero eso no pareció cambiar nada, todavía tengo daños en la copia de seguridad comprimida.

Esto solo sucede con una de mis bases de datos TDE. Tengo otras 4 bases de datos TDE en este mismo servidor, y no tienen este problema. Eso me dice que puede haber un problema subyacente con esta base de datos específica. Me doy cuenta de que la solución fácil es simplemente no usar la compresión, pero creo que esto puede ser una advertencia temprana a un problema mayor que se avecina.

¿Alguien ha visto esto antes, o tiene alguna idea de por qué la compresión corrompería esa página? En este punto, estoy un poco perdido en cuanto a qué hacer a continuación. Pensé en restaurar la página desde una copia de seguridad anterior, pero no creo que eso importe porque la página en la base de datos normal parece estar bien.

ACTUALIZACIÓN 1: A continuación se muestran los resultados de DBCC PAGE, con la opción 0:

Ejecución DBCC completada. Si DBCC imprimió mensajes de error, comuníquese con el administrador del sistema.

PÁGINA: (1: 92454)

BUFFER:

BUF @ 0x000002187AE55640

bpage = 0x000002184865E000 bhash = 0x0000000000000000
bpageno = (1: 92454) bdbid = 8 breferences = 0 bcputicks = 563 bsampleCount = 1
bUse1 = 51429 bstat = 0x809 blog = 0x15a
bnext = 0x0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000

ENCABEZADO DE PÁGINA:

Página @ 0x000002184865E000

m_pageId = (1: 92.454) m_headerVersion = 111
m_type = 189 m_typeFlagBits = 0x2D m_level = 197
m_flagBits = 0x525e m_objId (AllocUnitId.idObj) = 788815194
m_indexId (AllocUnitId.idInd) = 515 de metadatos: AllocUnitId = 145011308798541824 metadatos: PartitionID = 0 metadatos: IndexId = -1 Metadata: ObjectId = 0 m_prevPage = (32842: 1881351155) m_nextPage = (13086: -560562340)
pminlen = 36067 m_slotCnt = 8149 m_freeCnt = 51871 m_freeData = 7295 m_reservedCnt = 4810 m_es = 4810 m_reservados: 4810 m_reservados = 4810 m_fresentados = 4810 m_reservados = 4810m 14755
m_xdesId = (12811: 1559482793) m_ghostRecCnt = 12339
m_tornBits = -1381699202 DB Frag ID = 1

Estado de asignación

GAM (1: 2) = SGAM ASIGNADO (1: 3) =
PFS NO ASIGNADO (1: 88968) = 0x0 0_PCT_FULL DIFF (1: 6) = NO CAMBIADO
ML (1: 7) = NO MIN_LOGGED

Si intento ejecutar DBCC PAGE con otras opciones, obtengo los siguientes errores:

PÁGINA DBCC con opción 1: Mensaje 0, Nivel 11, Estado 0, Línea 0 Se produjo un error grave en el comando actual. Los resultados, si los hay, deben descartarse.

PÁGINA DBCC con opción 3: Mensaje 2514, Nivel 16, Estado 5, Línea 3 Se ha producido un error de PÁGINA DBCC: Tipo de página no válida: no es posible el estilo de volcado 3.

ACTUALIZACIÓN 2: Estos son algunos de los resultados de la DMO sys.dm_db_database_page_allocations:

object_id = 75 index_id = 1 rowset_id = 281474981625856 allocation_unit_id = 281474981625856
allocation_unit_type = 1 allocation_unit_type_desc = IN_ROW_DATA extent_file_id = 1 extent_page_id = 92448
allocated_page_iam_file_id = 1 allocated_page_iam_page_id = 104
allocated_page_file_id = 1 allocated_page_page_id = 92454
is_allocated = 0 is_iam_page = 0 is_mixed_page_allocation = 0

Eric Cobb
fuente

Respuestas:

8

Parece que este problema es con bases de datos que han tenido operaciones SHRINK ejecutadas en ellas. En mi caso, estaba tomando una copia de una de nuestras bases de datos de producción en SQL Server 2014 (que ya está encriptada con TDE), ejecutando DBCC SHRINKFILE en los archivos de datos y de registro, luego hice una copia de seguridad y la restauré en mi nuevo SQL Servidor 2017. (El motivo de la reducción fue reducir el tamaño para que la transferencia de la copia de seguridad sea más rápida).

Como prueba, restauré una copia de la base de datos en la que no ejecuté DBCC SHRINKFILE, y no tenía problemas de corrupción al comprimir copias de seguridad.

Entonces, para resumir, los resultados de mis pruebas son los siguientes:

  • Las operaciones normales de copia de seguridad / restauración en esta base de datos TDE "encogida" funcionan correctamente en SQL 2017
  • La compresión de las copias de seguridad de la base de datos TDE "encogida" parece provocar daños en la tabla sys.sysmultiobjrefs
  • La compresión de las copias de seguridad de la base de datos TDE normal (sin ejecutar DBCC SHRINKFILE) funciona correctamente y no informa de daños

No sé si este es un error confirmado en SQL Server 2017, pero he enviado mis hallazgos a Microsoft para que lo revisen.

Entonces, la moraleja de esta historia es: ¡NO REDUZCA SUS BASES DE DATOS! ¡NUNCA! :)

Eric Cobb
fuente