Início / dba / Perguntas / 335432
Accepted
rois
Asked: 2024-02-02 00:20:00 +0800 CST

DBCC CHECKDB COM EXTENDED_LOGICAL_CHECKS falha quando executado na réplica secundária

  • 772

Crie o banco de dados mais simples possível:

CREATE DATABASE DatabaseCheck

Adicione este banco de dados a um Grupo de Disponibilidade, onde o secundário não é legível

Na execução primária:

DBCC CHECKDB ('DatabaseCheck') WITH EXTENDED_LOGICAL_CHECKS

É bem-sucedido:

CHECKDB encontrou 0 erros de alocação e 0 erros de consistência no banco de dados 'DatabaseCheck'. Execução do DBCC concluída. Se o DBCC imprimir mensagens de erro, entre em contato com o administrador do sistema.

Execute o mesmo comando DBCC no secundário. Ele falha mesmo que nenhum erro tenha sido encontrado:

CHECKDB encontrou 0 erros de alocação e 0 erros de consistência no banco de dados 'DatabaseCheck'. Msg 0, Nível 11, Estado 0, Linha 1 Ocorreu um erro grave no comando atual. Os resultados, se existirem, deveriam ser descartados.

  • Remover COM EXTENDED_LOGICAL_CHECKSfaz com que o erro desapareça
  • Tornar a réplica secundária legível faz com que o erro desapareça
  • Fazer um failover e verificar o novo primário faz com que o erro desapareça. Verificar o novo secundário mostra o erro novamente.

Alguma ideia do que se trata? A verificação da documentação DBCC CHECKDB não diz nada sobre EXTENDED_LOGICAL_CHECKS não ser compatível com réplica secundária não legível. Parece um bug no próprio comando para mim.

Uma coisa que notei na saída do comando é que ele verifica estatísticas como aqui:

Integridade verificada das estatísticas 'sys.sysrscols.clst'. Integridade verificada das estatísticas 'sys.sysrowsets.clust'. Integridade verificada das estatísticas 'sys.sysrowsets._WA_Sys_00000002_00000005'. Integridade verificada das estatísticas 'sys.sysrowsets._WA_Sys_00000003_00000005'. Integridade verificada das estatísticas 'sys.sysrowsets._WA_Sys_00000006_00000005'. Integridade verificada das estatísticas 'sys.sysrowsets._WA_Sys_00000004_00000005'. Integridade verificada das estatísticas 'sys.sysrowsets._WA_Sys_00000005_00000005'. Integridade verificada das estatísticas 'sys.sysrowsets._WA_Sys_00000008_00000005'.

Eles estão ausentes quando executados no secundário

Reproduzido em:

Microsoft SQL Server 2019 (RTM-CU23) (KB5030333) - 15.0.4335.1 (X64) 21 de setembro de 2023 17:28:44 Copyright (C) 2019 Microsoft Corporation Developer Edition (64 bits) no Windows Server 2019 Standard 10.0 (Build 17763 :)

Editar:

A única mensagem no log de erros é esta:

DBCC CHECKDB (DatabaseCheck) executado por Domain\user encontrou 0 erros e reparou 0 erros. Tempo decorrido: 0 horas 0 minutos 0 segundos. O instantâneo do banco de dados interno tem ponto de divisão LSN = 00000034:000001b1:0001 e primeiro LSN = 00000034:000001af:0002.

Não há dumps recentes em sys.dm_server_memory_dumps

sql-server-2019

1 respostas

  1. Best Answer

    Recebi um ticket para a Microsoft porque estávamos enfrentando esse "problema" em nosso ambiente de produção. Espero que isso esclareça para alguém, porque a documentação não era tão óbvia sobre isso em primeiro lugar.

    Resposta curta: Verificações lógicas estendidas requerem acesso de leitura ao banco de dados.

    Resposta longa do ticket:

    Emitir:

    O cliente está tentando executar “DBCC CHECKDB WITH EXTENDED_LOGICAL_CHECKS” em uma réplica secundária não legível e está falhando com: Erro: 976 Estado 14. Consulte a fig.1. Isso pode ser reproduzido no SQL 2019 e 2022 (CU mais recente). Se a réplica secundária estiver marcada como legível, esse processo será bem-sucedido sem erros.

     

    Resolução:

    Posso confirmar que esse comportamento é intencional. De acordo com nossa documentação ao usar “EXTENDED_LOGICAL_CHECKS” (…as verificações lógicas são realizadas em uma visualização indexada, índices XML e índices espaciais…).

      DBCC CHECKDB (Transact-SQL) - SQL Server

     

     

    Esse comportamento ocorre por design porque para executar as verificações de consistência precisamos de acesso de leitura ao banco de dados.

    (ou seja, citação do mesmo artigo….{ }Essas verificações de consistência lógica cruzam a tabela de índice interno do objeto de índice com a tabela do usuário à qual ele está referenciando. Para encontrar linhas remotas, uma consulta interna é construída para realizar uma interseção completa de as tabelas internas e de usuário…){ }

     

    Também revisei os dumps da pilha e encontrei o erro 976, que também confirma que estamos tentando ler os dados.

    Definição:

    976 - 14
The target database, '%.*ls', is participating in an availability group and is currently not accessible for queries. 
Either data movement is suspended or the availability replica is not enabled for read access. 
To allow read-only access to this and other databases in the availability group, 
enable read access to one or more secondary availability replicas in the group.
For more information, see the ALTER AVAILABILITY GROUP statement in SQL Server Books Online.

     

    • 2

relate perguntas