DBCC CHECKDB nieusuwalne uszkodzenie: Widok indeksowany zawiera wiersze, które nie zostały utworzone przez definicję widoku

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)

NOEXPANDzostał użyty do wymuszenia użycia (tylko) indeksu na ViewName. FORCESCANzastosowano, 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 CHECKDBzgł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

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 NULLsdo ImageObjectIDkolumny. Niepoprawnie NULLspowoduje, że zapytanie widoku odrzuca tę kolumnę, jeśli tak nie jest. Sądząc, że NULLssą wykluczone, jest w stanie dopasować przefiltrowany indeks nieklastrowany w Userstabeli, w której są filtrowane ImageObjectID IS NOT NULL.

Tworząc plan, który korzysta z tego filtrowanego indeksu, zapewnia, że nie zostaną napotkane wiersze z NULLin ImageObjectID. Te wiersze są zwracane (poprawnie) z indeksu widoku, więc wydaje się, że istnieje uszkodzenie, gdy nie ma.

Definicja widoku to:

SELECT
    dbo.Universities.ID AS Universities_ID, 
    dbo.Users.ImageObjectID AS Users_ImageObjectID
FROM dbo.Universities
JOIN dbo.Users
    ON dbo.Universities.AdminUserID = dbo.Users.ID

ONPorównanie równość między klauzula AdminUserIDi IDodrzuca NULLsw tych kolumnach, ale nie z ImageObjectIDkolumny.

Część zapytania wygenerowanego przez DBCC to:

SELECT [Universities_ID], [Users_ImageObjectID], 0 as 'SOURCE'
FROM [dbo].[mv_Universities_Users_ID] tOuter WITH (NOEXPAND) 
WHERE NOT EXISTS
( 
    SELECT 1 
    FROM   [dbo].[mv_Universities_Users_ID] tInner
    WHERE 
    (
        (
            (
                [tInner].[Universities_ID] = [tOuter].[Universities_ID]
            ) 
            OR 
            (
                [tInner].[Universities_ID] IS NULL
                AND [tOuter].[Universities_ID] IS NULL
            )
        )
        AND
        (
            (
                [tInner].[Users_ImageObjectID] = [tOuter].[Users_ImageObjectID]
            ) 
            OR 
            (
                [tInner].[Users_ImageObjectID] IS NULL 
                AND [tOuter].[Users_ImageObjectID] IS NULL
            )
        )
    )
)
OPTION (EXPAND VIEWS);

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ć zUSE 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.

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.