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

Error 22050 – Failed to initialize sqlcmd library with error number -2147467259. [SQLSTATE 42000]

Olá,

Tivemos o seguinte erro em um job recém implantado aqui na empresa que utiliza a feature Database Mail. Abaixo a tela do job em questão:

E22050_1

Messagem:

Executed as user: DOMINIO\SVC-CONTAETC. Failed to initialize sqlcmd library with error number -2147467259. [SQLSTATE 42000] (Error 22050).  The step failed.

Procurando maiores informações sobre esse erro nos mais decentes mecanismos de busca (não é o bing), localizei várias ocorrências dessa mesma mensagem onde a única coisa em comum era o uso do Database Mail, mas as causas do problema quase sempre eram diferentes. Pensando nisso, a melhor estratégia era identificar o erro raíz que estava gerando a “falha na inicialização na biblioteca do SQLCMD”.

Troubleshooting 

  • Profiler configurado, filtrando a conta do Agent e com o evento “User Error Message”. Pode ser Extended Events também. Não importa o meio de tracing, importante é conseguir resolver o problema.
  • Executar novamente o job problemático. Eu executei no mesmo ambiente porque já conheço o ambiente e o que o job faz, mas recomendo que faça isso em ambiente de não-produção.
  • Consultar o trace. Simples assim.

Básico, mas suficiente. Olha o erro raíz aí:

E22050_2

Erro:

Invalid object name ‘dbo.ResultQuery’.

Antes de falar sobre o erro, é interessante falar sobre o job em questão: ele prepara um resultset bem simples utilizando a tabela  dbo.ResultQuery, só que a lógica inteira do job acontece no banco BDABC e a query utilizada no Database Mail não especificava qual era a base, logo, o objeto era procurado na MASTER (onde ele realmente não existe). Abaixo o trecho de código com a referência inválida.

A forma de consertar isso foi trivial: colocar o nome da base antes do dbo e pronto. Job funcionando e sem erro 22050.

Logo podemos concluir que o que realmente importa neste caso, é o erro raíz, não a mensagem logada no SQL Agent. Lembra um pouco as “palas” que acontecem no DTC onde aparece que a transação foi abortada e no final das contas foi um erro totalmente away (tabela inválida, coluna inválida, pk duplicada, etc).


TL;DR: O erro  22050 não responde o motivo do erro. Analise o código, de preferência com Trace, Extended Events ou algo que possa te ajudar a localizar o erro original.


 

Até o próximo post 🙂