Tengo un índice espacial para el cual DBCC CHECKDB
informa 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_CHECKS
pero con DATA_PURITY
el error no se informa.
Además, CHECKTABLE
toma 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 geography
datos de puntos .
¿Se espera este comportamiento bajo ninguna circunstancia? Dice "Esto no representa necesariamente un problema de integridad". ¿Que se supone que haga? CHECKDB
está 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.