Les corruptions d'index spatial non réparables sont-elles considérées comme normales?

J'ai un index spatial pour lequel DBCC CHECKDBsignale 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_CHECKSmais avec DATA_PURITYl'erreur n'est pas signalée.

En outre, cela CHECKTABLEprend 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 geographydonné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.

Je n'ai pas pu le reproduire immédiatement sur 2014 - 12.0.4213.0 mais le vois sur SQL Server 2016 (CTP3.0) - 13.0.700.242.

Sur la version 2014 (sans erreur DBCC), le plan se présente comme suit.

Et sur la version 2016 ( avec des erreurs DBCC signalées) comme ceci.

Le deuxième plan a une seule ligne sortant de la fusion anti semi jointure, le premier plan zéro lignes.

Les prédicats de jointure sont différents en ce qui concerne ce qui correspond à la pk0colonne dans l'index spatial.

Le premier le mappe correctement à la clé primaire de la table, le second le mappe à la Idcolonne renvoyée par le TVF.

Selon le livre interne de SQL Server 2012, il s'agit d'une valeur binaire (5) pour le nombre Hilbert de la cellule, donc ce prédicat est certainement incorrect (si l'ID de la seule ligne de la table de base est défini sur 1052031049 au lieu de 20171, je ne voir plus d'erreurs DBCC car cela correspond à cette valeur de 0xa03eb4b849).

Sur 2014 - 12.0.4213.0 après avoir recréé la table comme suit, j'ai pu reproduire 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)
)

(Notez le changement de IDà Id)

Mon instance 2014 est installée avec le classement sensible à la casse. Il semble donc que cela ait pu éviter la confusion des colonnes auparavant.

Je suppose donc qu'une solution de contournement pourrait être de renommer la colonne Citiescomme CityIdpar exemple.

Élément de connexion (rapport de bogue Microsoft)