Ich habe einen räumlichen Index, für den DBCC CHECKDB
Fehler 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_CHECKS
aber mit DATA_PURITY
dem Fehler wird nicht berichtet.
Außerdem CHECKTABLE
dauert 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 geography
Punktdaten.
Wird dieses Verhalten unter keinen Umständen erwartet? Es heißt "Dies ist nicht unbedingt ein Integritätsproblem". Was soll ich machen? CHECKDB
scheitert 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.
quelle
Id
Verwirrung führt auch dazu, dass ein Suchvorgang ein Scan sein soll. Großartiger Fang, Martin. Es scheint nur dieAUTO_GRID
Option zu beeinflussen . Ich kann den Fehler in 2014 SP1 CU4 mit einer Sortierung ohne Berücksichtigung der Groß- / Kleinschreibung reproduzieren. SQL Server erstellt die erweiterte Überprüfungsabfrage falsch.