TL; DR: Mam nieusuwalne uszkodzenie w widoku indeksowanym. Oto szczegóły:
Bieganie
DBCC CHECKDB([DbName]) WITH EXTENDED_LOGICAL_CHECKS, DATA_PURITY, NO_INFOMSGS, ALL_ERRORMSGS
na jednej z moich baz danych powoduje następujący błąd:
Msg 8907, poziom 16, stan 1, wiersz 1 Indeks przestrzenny, indeks XML lub widok indeksowany „ViewName” (identyfikator obiektu 784109934) zawiera wiersze, które nie zostały utworzone przez definicję widoku. Nie musi to oznaczać problemu z integralnością danych w tej bazie danych. (...)
CHECKDB znalazł 0 błędów alokacji i 1 błędy spójności w tabeli „ViewName”.
repair_rebuild to minimalny poziom naprawy (...).
Rozumiem, że ten komunikat wskazuje, że zmaterializowane dane widoku indeksowanego „ViewName” nie są tożsame z tym, co generuje zapytanie bazowe. Jednak ręczna weryfikacja danych nie powoduje żadnych rozbieżności:
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
został użyty do wymuszenia użycia (tylko) indeksu na ViewName
. FORCESCAN
zastosowano, aby zapobiec indeksowanemu dopasowaniu widoku. Plan wykonania potwierdza, że oba środki działają.
Nie są zwracane żadne wiersze, co oznacza, że dwie tabele są identyczne. (Są tylko kolumny całkowite i guid, zestawienia nie wchodzą w grę).
Błąd nie może zostać naprawiony poprzez odtworzenie indeksu w widoku lub uruchomienie DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS
. Powtarzanie poprawek również nie pomogło. Dlaczego DBCC CHECKDB
zgłasza ten błąd? Jak się tego pozbyć?
(Nawet jeśli odbudowanie to naprawi, moje pytanie nadal będzie istnieć - dlaczego zgłaszany jest błąd, mimo że moje zapytania sprawdzania danych działają poprawnie?)
Aktualizacja: Błąd został naprawiony w niektórych wydaniach. Już nie mogę odtworzyć go w SQL Server 2014 SP2 CU 5. 2014 SP2 KB zawiera poprawkę bez artykule KB: Creating non-clustered index causes DBCC CheckDB With Extended_Logical_Checks to raise corruption error
. Dwa błędy związane z tym związane zostały zamknięte:
- 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]
Notacja nie działa w komentarzu znak nogami.Odpowiedzi:
Procesor zapytań może wygenerować niepoprawny plan wykonania dla (poprawnego) zapytania wygenerowanego przez DBCC, aby sprawdzić, czy indeks widoku generuje te same wiersze, co bazowe zapytanie widoku.
Plan wytwarzany przez procesor nieprawidłowo zapytania uchwyty
NULLs
doImageObjectID
kolumny. NiepoprawnieNULLs
powoduje, że zapytanie widoku odrzuca tę kolumnę, jeśli tak nie jest. Sądząc, żeNULLs
są wykluczone, jest w stanie dopasować przefiltrowany indeks nieklastrowany wUsers
tabeli, w której są filtrowaneImageObjectID IS NOT NULL
.Tworząc plan, który korzysta z tego filtrowanego indeksu, zapewnia, że nie zostaną napotkane wiersze z
NULL
inImageObjectID
. Te wiersze są zwracane (poprawnie) z indeksu widoku, więc wydaje się, że istnieje uszkodzenie, gdy nie ma.Definicja widoku to:
ON
Porównanie równość między klauzulaAdminUserID
iID
odrzucaNULLs
w tych kolumnach, ale nie zImageObjectID
kolumny.Część zapytania wygenerowanego przez DBCC to:
Jest to ogólny kod, który porównuje wartości w sposób
NULL
-aware. Z pewnością jest to szczegółowe, ale logika jest w porządku.Błąd w rozumowaniu procesora zapytań oznacza, że może zostać wygenerowany plan zapytań, który niepoprawnie używa przefiltrowanego indeksu, jak w przykładzie fragmentu planu poniżej:
Zapytanie DBCC ma inną ścieżkę kodu przez procesor zapytań niż zapytania użytkownika. Ta ścieżka do kodu zawiera błąd. Gdy generowany jest plan korzystający z filtrowanego indeksu, nie można go używać z
USE PLAN
wskazówką, aby wymusić kształt tego planu za pomocą tego samego tekstu zapytania przesłanego z połączenia z bazą danych użytkownika.Główna ścieżka kodu optymalizatora (dla zapytań użytkowników) nie zawiera tego błędu, więc jest specyficzna dla zapytań wewnętrznych, takich jak te generowane przez DBCC.
źródło
Dalsze dochodzenie pokazuje, że jest to błąd w DBCC CHECKDB. Błąd Microsoft Connect został otwarty: nieusuwalny błąd DBCC CHECKDB (który jest również fałszywie dodatni i poza tym dziwny) . Na szczęście udało mi się stworzyć repro, aby błąd można było znaleźć i naprawić.
Błąd można ukryć, grając ze schematem bazy danych. Usunięcie niepowiązanego przefiltrowanego indeksu lub usunięcie filtra ukrywa błąd. Aby uzyskać szczegółowe informacje, zobacz element Connect.
Element Connect zawiera również wewnętrzne zapytanie, którego DBCC CHECKDB używa do sprawdzania poprawności zawartości widoku. Nie zwraca żadnych wyników, co wskazuje, że jest to błąd.
Błąd został naprawiony w niektórych wydaniach. Nie mogę już go odtworzyć w SQL Server 2014 SP2 CU 5.
źródło