¿Se consideran normales las corrupciones de índice espacial no fijables?

Tengo un índice espacial para el cual DBCC CHECKDBinforma sobre corrupciones:

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

El índice espacial, el índice XML o la vista indizada 'sys.extended_index_xxx_384000' (ID de objeto xxx) no contiene todas las filas que produce la definición de vista. Esto no representa necesariamente un problema de integridad con los datos de esta base de datos.

El índice espacial, el índice XML o la vista indizada 'sys.extended_index_xxx_384000' (ID de objeto xxx) contiene filas que no fueron producidas por la definición de la vista. Esto no representa necesariamente un problema de integridad con los datos de esta base de datos.

CHECKDB encontró 0 errores de asignación y 2 errores de coherencia en la tabla 'sys.extended_index_xxx_384000' (ID de objeto xxx).

Nivel de reparación es repair_rebuild.

Descartar y volver a crear el índice no elimina estos informes de corrupción. Sin EXTENDED_LOGICAL_CHECKSpero con DATA_PURITYel error no se informa.

Además, CHECKTABLEtoma 45 minutos para esta tabla, aunque su CI tiene un tamaño de 30 MB y hay aproximadamente 30k filas. Todos los datos en esa tabla son geographydatos de puntos .

¿Se espera este comportamiento bajo ninguna circunstancia? Dice "Esto no representa necesariamente un problema de integridad". ¿Que se supone que haga? CHECKDBestá fallando, lo cual es un problema.

Este script reproduce el 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

Esta es la versión 12.0.4427.24 (SQL Server 2014 SP1 CU3).

Guioné la tabla con esquema y datos, DB nueva, ejecutar. Mismo error. CHECKDB también tiene este increíble tiempo de ejecución de 45 minutos. Capturé el plan de consulta CHECKDB usando SQL Profiler. Tiene una unión de bucle equivocada que aparentemente causa un tiempo de ejecución excesivo. ¡El plan tiene tiempo de ejecución cuadrático en el número de filas de la tabla! Uniones de bucle de escaneo doblemente anidadas.

Borrar todos los índices no espaciales no cambia nada.

No pude reproducir esto inmediatamente en 2014 - 12.0.4213.0 pero lo veo en SQL Server 2016 (CTP3.0) - 13.0.700.242.

En la compilación 2014 (sin errores de DBCC), el plan tiene el siguiente aspecto.

Y en la compilación 2016 ( con errores DBCC informados) como este.

El segundo plan tiene una sola fila que sale de la combinación anti semiunión, el primer plan cero filas.

Los predicados de unión son diferentes con respecto a lo que coincide con la pk0columna en el índice espacial.

El primero lo asigna correctamente a la tabla Clave primaria, el segundo lo asigna a la Idcolumna devuelta por el TVF.

De acuerdo con el libro interno de SQL Server 2012, este es un valor binario (5) para el número de Hilbert de la celda, por lo que este predicado es ciertamente incorrecto (si el Id. De la fila única en la tabla base se establece en 1052031049 en lugar de 20171 I no Ya no veo ningún error DBCC ya que esto corresponde a este valor de 0xa03eb4b849).

En 2014 - 12.0.4213.0 después de volver a crear la tabla de la siguiente manera, pude reproducir el 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)
)

(Tenga en cuenta el cambio de IDa Id)

Mi instancia de 2014 está instalada con la intercalación de mayúsculas y minúsculas. Por lo tanto, parece que esto pudo haber evitado la confusión de la columna antes.

Entonces, supongo que una posible solución podría ser cambiar el nombre de la columna Citiescomo, CityIdpor ejemplo.

Conectar elemento (informe de error de Microsoft)