TL; DR: Eu tenho uma corrupção não corrigível em uma exibição indexada. Aqui estão os detalhes:
Corrida
DBCC CHECKDB([DbName]) WITH EXTENDED_LOGICAL_CHECKS, DATA_PURITY, NO_INFOMSGS, ALL_ERRORMSGS
em um dos meus bancos de dados produz o seguinte erro:
Msg 8907, Nível 16, Estado 1, Linha 1 O índice espacial, o índice XML ou a exibição indexada 'ViewName' (ID do objeto 784109934) contém linhas que não foram produzidas pela definição da exibição. Isso não representa necessariamente um problema de integridade com os dados desse banco de dados. (...)
O CHECKDB encontrou 0 erros de alocação e 1 erros de consistência na tabela 'ViewName'.
repair_rebuild é o nível mínimo de reparo (...).
Entendo que esta mensagem indica que os dados materializados da exibição indexada 'ViewName' não são idênticos ao que a consulta subjacente produz. No entanto, verificar manualmente os dados não gera discrepâncias:
SELECT * FROM ViewName WITH (NOEXPAND)
EXCEPT
SELECT ...
from T1 WITH (FORCESCAN)
join T2 on ...
SELECT ...
from T1 WITH (FORCESCAN)
join T2 on ...
EXCEPT
SELECT * FROM ViewName WITH (NOEXPAND)
NOEXPAND
foi usado para forçar o uso do (somente) índice ViewName
.FORCESCAN
foi usado para impedir que a correspondência de exibição indexada aconteça. O plano de execução confirma que ambas as medidas estão funcionando.
Nenhuma linha está sendo retornada aqui, o que significa que as duas tabelas são idênticas. (Existem apenas colunas de número inteiro e guia, os agrupamentos não entram em jogo).
O erro não pode ser corrigido recriando o índice na exibição ou executando DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS
. Repetir as correções também não ajudou. Por que DBCC CHECKDB
relatar esse erro? Como se livrar dele?
(Mesmo que a reconstrução o corrigisse, minha pergunta ainda permaneceria - por que um erro é relatado, embora minhas consultas de verificação de dados sejam executadas com êxito?)
Atualização: O bug foi corrigido em algumas versões. Já não posso reproduzi-lo no SQL Server 2014 SP2 CU 5. A KB 2014 SP2 contém uma correção sem artigo KB: Creating non-clustered index causes DBCC CheckDB With Extended_Logical_Checks to raise corruption error
. Os dois erros de conexão sobre isso foram fechados:
- https://connect.microsoft.com/SQLServer/feedback/details/847233/creating-non-clustered-index-causes-dbcc-checkdb-with-extended-logical-checks-to-raise-corruption-error
- https://connect.microsoft.com/SQLServer/feedback/details/795478/unfixable-dbcc-checkdb-error-that-is-also-a-false-positive-and-otherwise-strange
If the indexed view does not contain an aggregate over values of type float or real and you receive errors 8907 or 8708, drop the index on the view and re-create it. Do not use ALTER INDEX REBUILD to try to remove the differences between the stored and the computed view, because ALTER INDEX REBUILD does not recalculate the view before rebuilding the index. Then run DBCC CHECKTABLE on the View to verify no differences remain.
[1]
notação não funciona na marcação de comentário.Respostas:
O processador de consultas pode produzir um plano de execução inválido para a consulta (correta) gerada pelo DBCC para verificar se o índice de visualização produz as mesmas linhas que a consulta de visualização subjacente.
O plano produzido pelo processador de consultas manipula incorretamente
NULLs
para oImageObjectID
coluna. Razão incorreta para que a consulta de exibição rejeiteNULLs
essa coluna, quando não. Pensando queNULLs
são excluídos, ele pode corresponder ao índice não clusterizado filtrado naUsers
tabela que filtra noImageObjectID IS NOT NULL
.Ao produzir um plano que usa esse índice filtrado, garante que as linhas com
NULL
inImageObjectID
não sejam encontradas. Essas linhas são retornadas (corretamente) a partir do índice de exibição; portanto, parece que há uma corrupção quando não há.A definição da visualização é:
A
ON
comparação de cláusulas de igualdade entreAdminUserID
eID
rejeitaNULLs
nessas colunas, mas não a partir daImageObjectID
coluna.Parte da consulta gerada pelo DBCC é:
Este é um código genérico que compara valores em um
NULL
consciente. Certamente é detalhado, mas a lógica é boa.O erro no raciocínio do processador de consultas significa que um plano de consulta que usa incorretamente o índice filtrado pode ser produzido, como no exemplo de fragmento do plano abaixo:
A consulta DBCC usa um caminho de código diferente através do processador de consultas das consultas do usuário. Este caminho de código contém o erro. Quando um plano usando o índice filtrado é gerado, ele não pode ser usado com a
USE PLAN
dica para forçar a forma do plano com o mesmo texto de consulta enviado a partir de uma conexão com o banco de dados do usuário.O caminho principal do código do otimizador (para consultas do usuário) não contém esse bug, portanto é específico para consultas internas como as geradas pelo DBCC.
fonte
Investigações adicionais mostram que este é um erro no DBCC CHECKDB. Um erro do Microsoft Connect foi aberto: Erro não corrigível do DBCC CHECKDB (que também é um falso positivo e, de outra forma, estranho) . Felizmente, consegui produzir uma reprodução para que o bug pudesse ser encontrado e corrigido.
O bug pode ser oculto, jogando com o esquema do banco de dados. A exclusão de um índice filtrado não relacionado ou a remoção do filtro oculta o erro. Para detalhes, consulte o item de conexão.
O item de conexão também contém a consulta interna que DBCC CHECKDB usa para validar o conteúdo da exibição. Ele não retorna resultados, mostrando que isso é um bug.
O bug foi corrigido em algumas versões. Não consigo mais reproduzi-lo no SQL Server 2014 SP2 CU 5.
fonte