Werden unfixierbare Räumliche Indexverfälschungen als normal angesehen?

Ich habe einen räumlichen Index, für den DBCC CHECKDBFehler gemeldet werden:

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

Der räumliche Index, der XML-Index oder die indizierte Sicht 'sys.extended_index_xxx_384000' (Objekt-ID xxx) enthält nicht alle Zeilen, die die Sichtdefinition erzeugt. Dies ist nicht unbedingt ein Integritätsproblem mit den Daten in dieser Datenbank.

Der räumliche Index, der XML-Index oder die indizierte Sicht 'sys.extended_index_xxx_384000' (Objekt-ID xxx) enthält Zeilen, die nicht von der Sichtdefinition erstellt wurden. Dies ist nicht unbedingt ein Integritätsproblem mit den Daten in dieser Datenbank.

CHECKDB hat in der Tabelle 'sys.extended_index_xxx_384000' (Objekt-ID xxx) 0 Zuordnungsfehler und 2 Konsistenzfehler gefunden.

Reparaturstand ist repair_rebuild.

Durch das Löschen und Neuerstellen des Index werden diese Korruptionsberichte nicht entfernt. Ohne EXTENDED_LOGICAL_CHECKSaber mit DATA_PURITYdem Fehler wird nicht berichtet.

Außerdem CHECKTABLEdauert 45 Minuten für diese Tabelle , obwohl seine CI 30 MB groß ist und es gibt etwa 30k Reihen. Alle Daten in dieser Tabelle sind geographyPunktdaten.

Wird dieses Verhalten unter keinen Umständen erwartet? Es heißt "Dies ist nicht unbedingt ein Integritätsproblem". Was soll ich machen? CHECKDBscheitert was ein problem ist.

Dieses Skript reproduziert das Problem:

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

Dies ist Version 12.0.4427.24 (SQL Server 2014 SP1 CU3).

Ich habe die Tabelle mit Schema und Daten skriptiert, frische DB, ausgeführt. Gleicher Fehler. CHECKDB hat auch diese unglaubliche Laufzeit von 45 Minuten. Ich habe den CHECKDB-Abfrageplan mit SQL Profiler erfasst. Es gibt einen fehlgeleiteten Loop-Join, der anscheinend zu einer übermäßigen Laufzeit führt. Der Plan hat eine quadratische Laufzeit in der Anzahl der Zeilen der Tabelle! Doppelt verschachtelte Scan-Loop-Verknüpfungen.

Das Löschen aller nicht räumlichen Indizes ändert nichts.

Ich konnte dies nicht sofort auf 2014 - 12.0.4213.0 reproduzieren, sehe es aber auf SQL Server 2016 (CTP3.0) - 13.0.700.242.

Beim Build 2014 (ohne DBCC-Fehler) sieht der Plan folgendermaßen aus.

Und beim Build 2016 ( mit gemeldeten DBCC-Fehlern) so.

Der zweite Plan enthält eine einzelne Zeile aus dem Merge-Anti-Semi-Join, die erste Zeile enthält keine Zeilen.

Die Join-Prädikate unterscheiden sich in Bezug auf die Übereinstimmung mit der pk0Spalte im räumlichen Index.

Der erste ordnet es korrekt dem Primärschlüssel der Tabelle zu. Der zweite ordnet es der Idvom TVF zurückgegebenen Spalte zu.

Laut dem SQL Server 2012-Interna-Buch ist dies ein binärer (5) Wert für die Hilbert-Nummer der Zelle, sodass dieses Prädikat mit Sicherheit falsch ist Es werden keine DBCC-Fehler mehr angezeigt, da dies dem Wert von 0xa03eb4b849) entspricht.

Am 2014 - 12.0.4213.0 nach dem erneuten Erstellen der Tabelle wie folgt konnte ich das Problem reproduzieren.

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)
)

(Beachten Sie die Änderung von IDnach Id)

Meine 2014-Instanz wird mit case sensitive Kollatierung installiert. Es sieht also so aus, als hätte dies die Spaltenverwirrung zuvor verhindert.

Ein möglicher Workaround könnte also darin bestehen, die Spalte Citieswie CityIdzum Beispiel in umzubenennen .

Connect Item (Microsoft-Fehlerbericht)