Le corruzioni dell'indice spaziale non risolvibili sono considerate normali?

Ho un indice spaziale per il quale DBCC CHECKDBriporta corruzioni:

DBCC CHECKDB(MyDB) 
WITH EXTENDED_LOGICAL_CHECKS, DATA_PURITY, NO_INFOMSGS, ALL_ERRORMSGS, TABLERESULTS

L'indice spaziale, l'indice XML o la vista indicizzata 'sys.extended_index_xxx_384000' (ID oggetto xxx) non contiene tutte le righe prodotte dalla definizione della vista. Ciò non rappresenta necessariamente un problema di integrità con i dati in questo database.

L'indice spaziale, l'indice XML o la vista indicizzata 'sys.extended_index_xxx_384000' (ID oggetto xxx) 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 2 errori di coerenza nella tabella 'sys.extended_index_xxx_384000' (ID oggetto xxx).

Il livello di riparazione è repair_rebuild.

Eliminare e ricreare l'indice non rimuove questi rapporti di corruzione. Senza EXTENDED_LOGICAL_CHECKSma con DATA_PURITYl'errore non viene segnalato.

Inoltre, CHECKTABLEquesta tabella richiede 45 minuti, sebbene il relativo elemento della configurazione abbia una dimensione di 30 MB e vi siano circa 30.000 righe. Tutti i dati in quella tabella sono geographydati puntuali .

Questo comportamento è previsto in qualche circostanza? Dice "Questo non rappresenta necessariamente un problema di integrità". Cosa dovrei fare? CHECKDBsta fallendo, il che è un problema.

Questo script riproduce il problema:

CREATE TABLE dbo.Cities(
    ID int  NOT NULL,
    Position geography NULL,
 CONSTRAINT PK_Cities PRIMARY KEY CLUSTERED 
(
    ID ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
)

GO
INSERT dbo.Cities (ID, Position) VALUES (20171, 0xE6100000010C4E2B85402E424A40A07312A518C72A40)
GO
CREATE SPATIAL INDEX IX_Cities_Position ON dbo.Cities
(
    Position
)USING  GEOGRAPHY_AUTO_GRID 
WITH (
CELLS_PER_OBJECT = 16, PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, SORT_IN_TEMPDB = OFF, DROP_EXISTING = OFF, ONLINE = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO

Questa è la versione 12.0.4427.24 (SQL Server 2014 SP1 CU3).

Ho scritto la tabella con schema e dati, eseguire DB fresco, eseguire. Stesso errore CHECKDB ha anche questo incredibile tempo di esecuzione di 45 minuti. Ho acquisito il piano di query CHECKDB utilizzando SQL Profiler. Ha un loop loop mal guidato che sembra causare un'eccessiva durata. Il piano ha un tempo di esecuzione quadratico nel numero di righe della tabella! Unisci loop di scansione nidificati.

La cancellazione di tutti gli indici non spaziali non cambia nulla.

Non sono riuscito a riprodurlo immediatamente nel 2014 - 12.0.4213.0 ma lo vedo su SQL Server 2016 (CTP3.0) - 13.0.700.242.

Sulla build 2014 (senza errori DBCC) il piano ha il seguente aspetto.

E sulla build 2016 ( con errori DBCC segnalati) in questo modo.

Il secondo piano ha una sola riga che esce dall'unione anti semi join, il primo piano zero righe.

I predicati di join sono diversi rispetto a ciò che corrisponde alla pk0colonna nell'indice spaziale.

Il primo lo mappa correttamente sulla chiave primaria della tabella, il secondo lo mappa sulla Idcolonna restituita dal TVF.

Secondo il libro interno di SQL Server 2012 questo è un valore binario (5) per il numero Hilbert della cella, quindi questo predicato è sicuramente errato (Se l'ID della singola riga nella tabella di base è impostato su 1052031049 anziché 20171 I no vedere più eventuali errori DBCC in quanto ciò corrisponde a questo valore di 0xa03eb4b849).

Nel 2014 - 12.0.4213.0 dopo aver ricreato la tabella come segue ho potuto riprodurre il problema.

CREATE TABLE dbo.Cities(
    Id int  NOT NULL,
    Position geography NULL,
 CONSTRAINT PK_Cities PRIMARY KEY CLUSTERED 
(
    Id ASC
)WITH (PAD_INDEX = OFF, STATISTICS_NORECOMPUTE = OFF, IGNORE_DUP_KEY = OFF, ALLOW_ROW_LOCKS = ON, ALLOW_PAGE_LOCKS = ON)
)

(Nota la modifica da IDa Id)

La mia istanza 2014 è installata con regole di confronto Case Sensitive. Quindi sembra che questo possa aver prevenuto la confusione della colonna in precedenza.

Quindi immagino che una potenziale soluzione alternativa potrebbe essere quella di rinominare la colonna Citiescome CityIdad esempio.

Connetti elemento (segnalazione bug Microsoft)