J'ai un index spatial pour lequel DBCC CHECKDB
signale des corruptions:
DBCC CHECKDB(MyDB)
WITH EXTENDED_LOGICAL_CHECKS, DATA_PURITY, NO_INFOMSGS, ALL_ERRORMSGS, TABLERESULTS
L'index spatial, l'index XML ou la vue indexée 'sys.extended_index_xxx_384000' (ID d'objet xxx) ne contient pas toutes les lignes produites par la définition de la vue. Cela ne représente pas nécessairement un problème d'intégrité avec les données de cette base de données.
L'index spatial, l'index XML ou la vue indexée 'sys.extended_index_xxx_384000' (ID d'objet xxx) contient des lignes qui n'ont pas été produites par la définition de la vue. Cela ne représente pas nécessairement un problème d'intégrité avec les données de cette base de données.
CHECKDB a trouvé 0 erreur d'allocation et 2 erreurs de cohérence dans la table 'sys.extended_index_xxx_384000' (ID d'objet xxx).
Le niveau de réparation est repair_rebuild
.
La suppression et la recréation de l'index ne supprime pas ces rapports de corruption. Sans EXTENDED_LOGICAL_CHECKS
mais avec DATA_PURITY
l'erreur n'est pas signalée.
En outre, cela CHECKTABLE
prend 45 minutes pour cette table bien que son CI soit de 30 Mo et qu'il y ait environ 30 000 lignes. Toutes les données de ce tableau sont des geography
données ponctuelles .
Ce comportement est-il attendu en toutes circonstances? Il dit "cela ne représente pas nécessairement un problème d'intégrité". Qu'est-ce que je suis supposé faire? CHECKDB
échoue, ce qui est un problème.
Ce script reproduit le problème:
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
Il s'agit de la version 12.0.4427.24 (SQL Server 2014 SP1 CU3).
J'ai scripté la table avec le schéma et les données, nouvelle base de données, exécutée. Même erreur. CHECKDB a également cet incroyable temps d'exécution de 45 minutes. J'ai capturé le plan de requête CHECKDB à l'aide de SQL Profiler. Il y a une jointure de boucle erronée provoquant apparemment un temps d'exécution excessif. Le plan a une exécution quadratique dans le nombre de lignes de la table! Jointure de boucle de balayage double imbriquée.
La suppression de tous les index non spatiaux ne change rien.