web-dev-qa-db-fra.com

Les corruptions d'indice spatial innombrable sont-elles considérées comme normales?

J'ai un index spatial pour lequel DBCC CHECKDB Rapports Corruption:

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.extendue_index_xxx_384000' (objet ID xxx) ne contient pas toutes les lignes que la définition de vue produit. Cela ne représente pas nécessairement une question 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.extendued_index_xxx_384000' (ID d'objet xxx) contient des lignes non produites par la définition de vue. Cela ne représente pas nécessairement une question d'intégrité avec les données de cette base de données.

CheckDB a trouvé 0 erreurs d'allocation et 2 erreurs de consistance dans le tableau 'Sys.extended_index_xxx_384000' (Objet ID XXX).

Le niveau de réparation est repair_rebuild.

La chute et la recréation de l'indice ne suppriment pas ces rapports de corruption. Sans EXTENDED_LOGICAL_CHECKS mais avec DATA_PURITY L'erreur n'est pas signalée.

En outre, CHECKTABLE prend 45 minutes pour cette table bien que son CI soit de 30 Mo de taille et il y a environ 30 000 rangées. Toutes les données de cette table sont le point geographyDATA.

Ce comportement est-il attendu en aucune circonstance? Il est dit "Cela ne représente pas nécessairement une question d'intégrité". Qu'est-ce que je suis supposé faire? CHECKDB échoue 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

Ceci est la version 12.0.4427.24 (SQL Server 2014 SP1 CU3).

J'ai scripté la table avec schéma et données, dB frais, exécution. Même erreur. CheckDB a également ce temps d'exécution incroyable de 45min. J'ai capturé le plan de requête à checkDB à l'aide du profileur SQL. Il a une boucle erronée rejoindre apparemment provoquant un runtime excessif. Le plan a un remontage quadratique dans le nombre de rangées de la table! Doublement de boucle de numérisation imbriquée.

DBCC execution plan

Effacement de tous les index non spatiaux ne change rien.

sql-serversql-server-2014spatialdbcc-checkdb
23
boot4life

Je ne pouvais pas immédiatement reproduire cela en 2014 - 12.0.4213.0, mais voyez-le sur SQL Server 2016 (CTP3.0) - 13.0.700.242.

Sur la construction de 2014 (sans erreurs DBCC), le plan ressemble comme suit.

enter image description here

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

enter image description here

Le deuxième plan a une seule ligne sortant de la fusion Anti Semi Join, la première planification zéro rangée.

Les prédicats de jointure sont différents par rapport à ce qui est assorti à la pk0 colonne dans l'index spatial.

enter image description here

Le premier mappe correctement à la touche primaire de la table, la deuxième carte à la colonne Id renvoyée du TVF.

Selon le livre SQL Server 2012, il s'agit d'une valeur binaire (5) pour le numéro Hilbert de la cellule de sorte que ce prédicat est certainement incorrect (si l'identifiant de la ligne unique dans la table de base est défini sur 1052031049 au lieu de 20171 Voir plus longtemps toutes les erreurs DBCC car cela se produise pour correspondre à cette valeur de 0xa03eb4b849).

En 2014 - 12.0.4213.0 après avoir ré-créé le tableau comme suit, je pouvais 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 une assiette sensible à la casse. Il semble donc que cela ait pu empêcher la confusion de la colonne auparavant.

Je suppose donc qu'une solution de contournement potentielle pourrait être de renommer la colonne de Cities comme CityId par exemple.

Connecter l'élément (rapport de bogue Microsoft)

25
Martin Smith