Чи вважаються нормальними пошкодження просторового індексу нормальними?

У мене є просторовий індекс, для якого DBCC CHECKDBповідомляється про корупцію:

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

Просторовий індекс, індекс XML або індексований вигляд 'sys.extended_index_xxx_384000' (ідентифікатор об’єкта xxx) не містить усіх рядків, які створює визначення подання. Це не обов'язково означає проблему цілісності даних у цій базі даних.

Просторовий індекс, індекс XML або індексований вигляд 'sys.extended_index_xxx_384000' (ідентифікатор об'єкта xxx) містить рядки, які не були створені визначенням представлення. Це не обов'язково означає проблему цілісності даних у цій базі даних.

CHECKDB знайшов 0 помилок розподілу та 2 помилки узгодженості у таблиці 'sys.extended_index_xxx_384000' (ідентифікатор об'єкта xxx).

Рівень ремонту є repair_rebuild.

Скасування та відтворення індексу не видаляє ці повідомлення про корупцію. Без, EXTENDED_LOGICAL_CHECKSале з DATA_PURITYпомилкою не повідомляється.

Крім того, CHECKTABLEдля цієї таблиці потрібно 45 хвилин, хоча її CI має розмір 30 Мб, а рядки - близько 30 к. Усі дані в цій таблиці є точковими geographyданими.

Чи очікується така поведінка за будь-яких обставин? У ній написано: "Це не обов'язково означає проблему цілісності". Що я повинен робити? CHECKDBне вдається, що є проблемою.

Цей сценарій відтворює проблему:

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

Це версія 12.0.4427.24 (SQL Server 2014 SP1 CU3).

Я написав таблицю зі схемою та даними, свіжий БД, виконую. Така ж помилка. CHECKDB також має цей неймовірний час виконання в 45 хвилин. Я захопив план запитів CHECKDB за допомогою SQL Profiler. Він має помилкове з'єднання циклу, очевидно, спричиняючи надмірне виконання. План має квадратичне виконання в кількості рядків таблиці! Приєднується подвійно вкладений контур сканування.

Очищення всіх непросторових індексів нічого не змінює.

Я не міг одразу відтворити це у 2014 році - 12.0.4213.0, але бачу це на SQL Server 2016 (CTP3.0) - 13.0.700.242.

У збірці 2014 року (без помилок DBCC) план виглядає наступним чином.

І на збірку 2016 року ( з повідомленнями про помилки DBCC), як це.

Другий план має один рядок, що виходить із об'єднання антиполовинних об'єднань, перший план - нульових рядків.

Предикати об’єднання відрізняються залежно від того, що відповідає pk0стовпцю в просторовому індексі.

Перший правильно відображає його в таблиці Первинний ключ, Другий відображає його в Idстовпчик, повернутий з TVF.

Відповідно до книги внутрішніх служб SQL Server 2012, це бінарне (5) значення для номера Гільберта комірки, тому цей предикат, безумовно, є неправильним (Якщо ідентифікатор одного ряду в базовій таблиці встановлений на 1052031049 замість 20171, я ні більше не бачите помилок DBCC, оскільки це відповідає цьому значенню 0xa03eb4b849).

У 2014 - 12.0.4213.0 після перетворення таблиці наступним чином я міг відтворити проблему.

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

(Зверніть увагу на зміну з IDна Id)

Мій екземпляр 2014 року встановлений із порівнянням регістру. Так виглядає, ніби це, можливо, попереджало плутанину стовпців раніше.

Тож я думаю, що можливим рішенням може бути перейменування стовпця Cities, CityIdнаприклад.

Підключити елемент (звіт про помилку Microsoft)