DBCC CHECKDB corruzione irreversibile: la vista indicizzata contiene righe che non sono state prodotte dalla definizione della vista

TL; DR: ho una corruzione non riparabile in una vista indicizzata. Ecco i dettagli:

In esecuzione

DBCC CHECKDB([DbName]) WITH EXTENDED_LOGICAL_CHECKS, DATA_PURITY, NO_INFOMSGS, ALL_ERRORMSGS

su uno dei miei database produce il seguente errore:

Messaggio 8907, livello 16, stato 1, riga 1 L'indice spaziale, l'indice XML o la vista indicizzata 'ViewName' (ID oggetto 784109934) contiene righe che non sono state prodotte dalla definizione della vista. Ciò non rappresenta necessariamente un problema di integrità con i dati in questo database. (...)

CHECKDB ha trovato 0 errori di allocazione e 1 errori di coerenza nella tabella 'ViewName'.

repair_rebuild è il livello di riparazione minimo (...).

Comprendo che questo messaggio indica che i dati materializzati della vista indicizzata 'ViewName' non sono identici a ciò che produce la query sottostante. Tuttavia, la verifica manuale dei dati non presenta alcuna discrepanza:

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è stato usato per forzare l'uso del (solo) indice su ViewName. FORCESCANè stato utilizzato per impedire la corrispondenza della vista indicizzata. Il piano di esecuzione conferma che entrambe le misure funzionano.

Qui non vengono restituite righe, il che significa che le due tabelle sono identiche. (Esistono solo colonne di numeri interi e guid, le regole di confronto non entrano in gioco).

L'errore non può essere corretto ricreando l'indice sulla vista o eseguendolo DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS. Anche ripetere le correzioni non ha aiutato. Perché DBCC CHECKDBsegnala questo errore? Come sbarazzarsene?

(Anche se la ricostruzione avesse risolto il problema, la mia domanda sarebbe ancora valida: perché viene segnalato un errore anche se le mie query di controllo dei dati vengono eseguite correttamente?)

Aggiornamento: il bug è stato corretto in alcune versioni. Non riesco più a riprodurre in SQL Server 2014 SP2 CU 5. Il 2014 SP2 KB contiene una correzione senza articolo KB: Creating non-clustered index causes DBCC CheckDB With Extended_Logical_Checks to raise corruption error. I due bug di connessione su questo sono stati chiusi:

• 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

Il Query Processor può produrre un piano di esecuzione non valido per la query (corretta) generata da DBCC per verificare che l'indice di visualizzazione produca le stesse righe della query di visualizzazione sottostante.

Il piano prodotto dall'elaboratore di query gestisce erroneamente NULLsla ImageObjectIDcolonna. Motiva erroneamente che la query di visualizzazione rifiuta NULLsper questa colonna, quando non lo fa. Pensando che NULLssono esclusi, è in grado di abbinare l'indice non cluster filtrato sulla Userstabella su cui filtra ImageObjectID IS NOT NULL.

Producendo un piano che utilizza questo indice filtrato, garantisce che le righe con NULLin ImageObjectIDnon vengano rilevate. Queste righe vengono restituite (correttamente) dall'indice della vista, quindi sembra che ci sia un danneggiamento quando non lo è.

La definizione della vista è:

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

Il ONconfronto di uguaglianza della clausola tra AdminUserIDe IDrifiuta NULLsin quelle colonne, ma non dalla ImageObjectIDcolonna.

Parte della query generata da DBCC è:

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);

Questo è un codice generico che confronta i valori in NULLmodo consapevole. È certamente prolisso, ma la logica va bene.

Il bug nel ragionamento del Query Processor significa che può essere prodotto un piano di query che utilizza erroneamente l'indice filtrato, come nel frammento del piano di esempio riportato di seguito:

La query DBCC utilizza un percorso di codice diverso attraverso il Query Processor dalle query dell'utente. Questo percorso del codice contiene il bug. Quando viene generato un piano che utilizza l'indice filtrato, non può essere utilizzato con il USE PLANsuggerimento per forzare quella forma del piano con lo stesso testo di query inviato da una connessione al database utente.

Il percorso del codice dell'ottimizzatore principale (per le query degli utenti) non contiene questo errore, quindi è specifico per le query interne come quelle generate da DBCC.

Ulteriori indagini dimostrano che si tratta di un bug in DBCC CHECKDB. È stato aperto un bug di Microsoft Connect: errore irreversibile DBCC CHECKDB (che è anche un falso positivo e altrimenti strano) . Fortunatamente, sono stato in grado di produrre una riproduzione in modo che il bug potesse essere trovato e corretto.

Il bug può essere nascosto giocando con lo schema del database. L'eliminazione di un indice filtrato non correlato o la rimozione del filtro nasconde il bug. Per i dettagli, vedere l'elemento di connessione.

L'elemento connect contiene anche la query interna che DBCC CHECKDB utilizza per convalidare il contenuto della vista. Non restituisce risultati, a dimostrazione che si tratta di un bug.

Il bug è stato corretto in alcune versioni. Non riesco più a riprodurlo in SQL Server 2014 SP2 CU 5.