No SQL Server 2017 (CU3), sempre que habilito a compactação de backup em um dos meus bancos de dados TDE, o processo de backup sempre corrompe uma página específica no banco de dados. Se eu executar o backup sem compactação, ele não será corrompido. Aqui estão as etapas que tomei para verificar e reproduzir esse problema:
- Execute o DBCC CheckDB no banco de dados "TDE_DB1"; tudo é bom, sem erros;
- Backup bem-sucedido do banco de dados sem compactação; RESTORE VERIFYONLY diz que está tudo bem;
- Restaure o banco de dados com sucesso como "TDE_DB2"; tudo está bem, DBCC CheckDB não mostra erros;
- Backup bem-sucedido do banco de dados "TDE_DB1" COM compactação; Erros RESTORE VERIFYONLY, dizendo "Dano no conjunto de backup foi detectado";
- Tente restaurar o banco de dados como "TDE_DB2"; erros, dizendo "RESTORE detectou um erro na página (1:92454) no banco de dados"
- Repita os passos 1-3; tudo está bem;
- SOLTE "TDE_DB1" e "TDE_DB2"; Restaurar "TDE_DB1" do backup; tudo está bem;
- Repita os passos 1-5; obter os mesmos resultados;
Para resumir: O banco de dados e os backups regulares parecem bons, executar CHECKDB no banco de dados e VERIFYONLY nos backups não relata nenhum erro. Fazer backup do banco de dados com compactação parece causar a corrupção.
Abaixo estão os exemplos de código com erros. (Observação: MAXTRANSFERSIZE é necessário para usar a compactação com um banco de dados 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.
Em seguida, tentei verificar a página que é relatada como tendo o erro (é sempre a mesma página.), mas DBCC PAGE informa que o ObjectId é 0. De acordo com este artigo de Paul Randal , isso significa que não houve metadados encontrados e uma das razões pode ser que a própria página está corrompida e valores incorretos foram usados para tentar procurar os metadados. Seu conselho é executar CHECKDB, o que não posso fazer porque o backup corrompido não será restaurado.
Eu tentei as sugestões deste SO Post (Adicionando INIT e FORMAT ao comando BACKUP) para redefinir os metadados, mas isso não pareceu mudar nada, ainda recebo corrupção no backup compactado.
Isso só acontece com um dos meus bancos de dados TDE. Tenho 4 outros bancos de dados TDE neste mesmo servidor, e eles não apresentam esse problema. Isso me diz que pode haver um problema subjacente com esse banco de dados específico. Percebo que a solução mais fácil é simplesmente não usar a compactação, mas sinto que isso pode realmente ser um aviso antecipado para um problema maior que está por vir.
Alguém já viu isso antes, ou tem alguma ideia de por que a compactação corromperia essa página? Neste ponto, estou meio sem saber o que fazer a seguir. Considerei restaurar a página de um backup anterior, mas acho que isso não importaria, pois a página no banco de dados regular parece boa.
ATUALIZAÇÃO 1: Abaixo estão os resultados da PÁGINA DBCC, com a opção 0:
Execução DBCC concluída. Se o DBCC imprimir mensagens de erro, entre em contato com o administrador do sistema.
PÁGINA: (1:92454)
AMORTECEDOR:
BUF @0x000002187AE55640
BPAGE = 0x000002184865E000 BHASH = 0x0000000000000000
BPAGENO = (1: 92454) Bdbid = 8 Breferences = 0 Bcputicks = 563 BsampleCount = 1 BUSE1 = 51429 BSTAT
= 0x809 BlogCABEÇALHO DA PÁGINA:
Página @0x000002184865E000
m_pageId = (1:92454) 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 Metadata: AllocUnitId = 145011308798541824 Metadata: PartitionId = 0 Metadata: 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_lsn = (742012401:720884976:30191) m_xactReserved = 14755
m_xdesId = (12811:1559482793) m_ghostRecCnt = 12339
m_tornBits = -1381699202 DB Frag ID = 1Status de alocação
GAM (1:2) = ALLOCATED SGAM (1:3) = NÃO ALLOCATED
PFS (1:88968) = 0x0 0_PCT_FULL DIFF (1:6) = NÃO ALTERADO
ML (1:7) = NÃO MIN_LOGGED
Se eu tentar executar DBCC PAGE com outras opções, recebo os erros abaixo:
DBCC PAGE com opção 1: Msg 0, Level 11, State 0, Line 0 Ocorreu um erro grave no comando atual. Os resultados, se existirem, deveriam ser descartados.
DBCC PAGE com opção 3: Msg 2514, Level 16, State 5, Line 3 Ocorreu um erro DBCC PAGE: Tipo de página inválido - estilo de despejo 3 não é possível.
ATUALIZAÇÃO 2: Aqui estão alguns dos resultados do 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