Düzeltilemez uzaysal endeks bozulmaları normal kabul edilir mi?

Bir var mekansal indeksi olan DBCC CHECKDByolsuzlukların raporlar:

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

Uzamsal dizin, XML dizini veya dizine alınmış görünüm 'sys.extended_index_xxx_384000' (nesne kimliği xxx), görünüm tanımının ürettiği tüm satırları içermiyor. Bu mutlaka bu veritabanındaki verilerle bir bütünlük sorunu teşkil etmez.

Uzamsal dizin, XML dizini veya dizine alınmış görünüm 'sys.extended_index_xxx_384000' (nesne kimliği xxx), görünüm tanımı tarafından üretilmeyen satırlar içerir. Bu mutlaka bu veritabanındaki verilerle bir bütünlük sorunu teşkil etmez.

CHECKDB 'sys.extended_index_xxx_384000' tablosunda 0 ayırma hatası ve 2 tutarlılık hatası buldu (nesne kimliği xxx).

Tamir seviyesi repair_rebuild.

Dizini bırakmak ve yeniden oluşturmak, bu bozulma raporlarını kaldırmaz. Olmadan EXTENDED_LOGICAL_CHECKSancak DATA_PURITYhata bildirilmez.

Ayrıca, CHECKTABLECI'si 30 MB boyutunda ve yaklaşık 30k satır olmasına rağmen, bu tablo için 45 dakika sürer. Bu tablodaki tüm veriler nokta geographyverileridir.

Bu davranış hiçbir koşulda bekleniyor mu? "Bu mutlaka bir bütünlük sorununu temsil etmez" diyor. Ne yapmam gerekiyor? CHECKDBbir sorun olan başarısız.

Bu komut dosyası sorunu yeniden üretir:

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

Bu sürüm 12.0.4427.24'tür (SQL Server 2014 SP1 CU3).

Tabloyu şema ve verilerle yazdım, taze DB, çalıştır. Aynı hatayı. CHECKDB ayrıca bu inanılmaz 45 dakikalık çalışma süresine sahiptir. SQL Profiler kullanarak CHECKDB sorgu planı ele geçirdi. Görünüşe göre aşırı çalışma süresine neden olan yanlış yönlendirilmiş bir halka birleşimi vardır. Plan, tablonun satır sayısında ikinci dereceden çalışma zamanına sahip! İki kat yuvalanmış tarama döngüsü birleşiyor.

Mekansal olmayan tüm dizinleri temizlemek hiçbir şeyi değiştirmez.

Bunu 2014 - 12.0.4213.0 tarihinde hemen çoğaltamazdım ama SQL Server 2016 (CTP3.0) - 13.0.700.242'de görebiliyorum.

2014 yapısında (DBCC hatası olmadan) plan aşağıdaki gibi görünüyor.

Ve 2016 yapı üzerinde ( birlikte böyle DBCC hataları rapor).

İkinci plan birleştirme karşıtı yarı birleşmeden çıkan tek bir sıraya sahip, ilk plan sıfır sıra.

Birleştirme tahminleri pk0, uzamsal dizindeki sütuna uygun olanlarla ilgili olarak farklıdır .

Birincisi doğru şekilde Birincil Tabloya eşler, İkincisi IdTVF'den döndürülen sütuna eşler .

SQL Server 2012 internals kitabına göre bu, hücrenin Hilbert numarası için bir ikili (5) değerdir, bu nedenle bu öngörü kesinlikle yanlıştır (Temel tablodaki tek satırın kimliği 20171 yerine 1052031049 olarak ayarlanırsa, hayır bu değere karşılık geldiği için DBCC hatalarını daha uzun süre görün 0xa03eb4b849.

2014 - 12.0.4213.0 tarihinde aşağıdaki tabloyu yeniden oluşturduktan sonra sorunu tekrar oluşturabilirim.

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

(Değiştiğine dikkat edin IDiçin Id)

2014 örneğim, Büyük Harf Duyarlı harmanlama ile yüklenir. Böylece, bu daha önce kolon karmaşasını önlemiş olabilir gibi görünüyor.

Sanırım Yani potansiyel bir çözüm sütunu yeniden adlandırmak için olabilir Citiesolarak CityIdörneğin.

Bağlama Öğesi (Microsoft hata raporu)