Esta manhã, foi recebido o seguinte alerta por e-mail:
DATA/HORA: 28/02/2018 09:26:42
DESCRIÇÃO: A tentativa de buscar a página lógica (1:3948712) no banco de dados 9 falhou. Pertence à unidade de alocação 72057594045857792 e não a 72059184917512192.
COMENTÁRIO: (Nenhum)
JOB RUN: SQL Sentry 2.0 Alert Trap
Olhando no log de eventos da réplica secundária, há três ocorrências da mesma mensagem:
Fonte spid138
Mensagem Tentativa de buscar página lógica (1:3948712) no banco de dados 9 falhou. Pertence à unidade de alocação 72057594045857792 e não a 72059184917512192.
Executando o seguinte na réplica secundária (grupo de disponibilidade síncrono de 2 nós):
DBCC TRACEON(3604)
dbcc page (9, 1,3948712,3)
go
DBCC TRACEOff(3604)
Trecho dos resultados de qualquer réplica:
Page @0x00000070DAB8C000
m_pageId = (1:3948712) m_headerVersion = 1
m_type = 3 m_typeFlagBits = 0x0 m_level = 0
m_flagBits = 0x8200 m_objId (AllocUnitId.idObj) = 129 m_indexId
(AllocUnitId.idInd) = 256 Metadata: AllocUnitId = 72057594046382080
Metadata: PartitionId = 72057594040811520
Metadata: IndexId = 1 Metadata: ObjectId = 197575742
m_prevPage = 0:0) m_nextPage = (0:0) pminlen = 0
m_slotCnt = 2 m_freeCnt = 1634 m_freeData = 6568
m_reservedCnt = 0 m_lsn = (46041:1506360:18)
m_xactReserved = 0 m_xdesId = (0:0)
m_ghostRecCnt = 0 m_tornBits = -99702035 DB Frag ID = 1
Executando o seguinte na réplica primária:
select OBJECT_NAME (197575742)
plan_persist_plan
Perguntas
- Estou certo em dizer que tenho uma corrupção de índice clusterizado da
plan_persist_plan
tabela que faz parte do Query Store? É a melhor/única correção para executar o seguinte:
ALTER DATABASE MyDatabase SET QUERY_STORE CLEAR;
Se o nº 2 for a melhor correção, existe alguma boa maneira de preservar os dados no Query Store que seriam excluídos?
- Esse tipo de corrupção indica um problema com o subsistema de E/S?
Outras informações
- Eu tenho o QueryStore ativado obviamente, ele tem uma capacidade de 350 MB, está no modo Read-Write atualmente, intervalo de liberação de 15 minutos, coleta de estatísticas por hora, modo de captura TODOS, limpeza baseada em tamanho automático, limite de consulta obsoleto de 5 dias.
- DB id 9 é um banco de dados de usuários críticos para os negócios
- Os detalhes do erro são Erro: 605, Gravidade: 21, Estado: 3.
Verifiquei o log de eventos do sistema Windows conforme as orientações . Isso gerou apenas eventos "informativos", sem erros.
DBCC CHECKTABLE ('sys.plan_persist_plan');
resultados:
DBCC results for 'sys.plan_persist_plan'. There are 12562 rows in 240 pages for object "sys.plan_persist_plan". DBCC execution completed. If DBCC printed error messages, contact your system administrator.
Não consigo estabelecer o comando correto para reconstruir o índice, o seguinte não funciona:
ALTER INDEX PK_plan_persist_plan_cidx ON sys.plan_persist_plan REBUILD;
Conforme observado no meu comentário acima, tive um problema de corrupção semelhante com uma tabela interna do repositório de consultas.
Como você mesmo sugeriu, eu costumava
ALTER DATABASE MyDatabase SET QUERY_STORE CLEAR;
tentar corrigir o problema e isso funcionou bem. No SQL Server 2017, a Microsoft adicionou um procedimento de reparo que pode ser tentado antes de limpar os dados:sp_query_store_consistency_check
( source )Se você deseja preservar os dados, provavelmente o único método é copiar as tabelas - não consigo encontrar ninguém que tenha criado um script para isso.
Normalmente, com corrupção, eu também ficaria preocupado com meus discos, mas neste caso estou um pouco desconfiado de que o problema esteja no próprio armazenamento de consultas.
Respondendo a sua pergunta nº 3
Consulte Como posso exportar dados do Repositório de Consultas? não é difícil na maioria dos casos exportar os dados QS. Não posso dizer se seu erro afetará a exportação.
Você pode encontrar alguns dados ausentes ao exportar. Consulte Por que os detalhes do Query Store estão ausentes?
Corrigi o erro alterando o nível de compatibilidade do meu banco de dados de 110 para 130 (SQL Server 2016).
A versão de compilação da minha instância é 13.0.5062.0, mas os bancos de dados foram migrados de uma versão mais antiga e nunca mudaram o nível de compatibilidade.