DBCC CHECKDB em cópias da MASTER – Um caso interessante

Ilustrando um DB generico a lot

Olá,

Executei o CHECKDB em uma base chamada MASTER_SHADOW, que é uma cópia da master de um servidor de produção.

Erros pipocam na tela conforme ilustrado abaixo (resumido com as partes relevantes, pois os erros abaixo se repetem para diferentes classes):

Msg 8992, Level 16, State 1, Line 1
Check Catalog Msg 3851, State 1: An invalid row (class=12,depid=0,depsubid=0) was found in the system table sys.syssingleobjrefs (class=12).
Msg 8992, Level 16, State 1, Line 1
Check Catalog Msg 3851, State 1: An invalid row (class=13,depid=1,depsubid=0) was found in the system table sys.syssingleobjrefs (class=13).
(…)
(…)
CHECKDB found 0 allocation errors and 61 consistency errors not associated with any single object.
DBCC results for ‘sys.sysrscols’.

Msg 8906, Level 16, State 1, Line 1
Page (1:10) in database ID 7 is allocated in the SGAM (1:3) and PFS (1:1), but was not allocated in any IAM. PFS flags ‘MIXED_EXT ALLOCATED 0_PCT_FULL’.

CHECKDB found 1 allocation errors and 61 consistency errors in database ‘master_shadow’.
DBCC execution completed. If DBCC printed error messages, contact your system administrator.


O que era:

Assim que analisei o resultado, executei o CHECKDB na master em produção, a mãe desse “backup”. Nenhum erro, tudo no grau.

Suspeitei que fosse particularidade de alguma página da master que perdia referência ao virar uma base de usuário.

Fiz aquela pesquisa básica e cheguei no seguinte artigo do Paul Randal que elucidou o motivo do erro: Is my master Database really corrupt?

Em suma, realmente era particularidade da master, especificamente a página #10 da master que possui metadados “especiais”, que não pode existir em nenhuma outra base de usuário, o que era o caso dessa cópia da MASTER. Pelas mensagens de erro, nota-se que todos os erros de consistência apontavam para a mesma página (#10), então estava lendo sobre o assunto certo pro problema certo.


Finalizando

Conclusões do artigo original já supracitados no artigo do sqlmag: É interessante manter a MASTER na sua rotina de checagem de backup/restore mas tire as cópias de testes de integridade pra evitar diversos falso-positivos.

Conclusão: MASTER na rotina de RESTORE? Sim. Na rotina de CHECKDB? Só direto em produção.
Já restaurei master em várias oportunidades. Mas nunca havia executado CHECKDB até então. Topando com esse erro pela primeira vez. Vivendo e aprendendo.
[]’s

Leave a Comment

Your email address will not be published. Required fields are marked *