Apakah korupsi indeks spasial yang tidak dapat diperbaiki dianggap normal?


23

Saya memiliki indeks spasial yang DBCC CHECKDBmelaporkan korupsi:

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

Indeks spasial, indeks XML atau tampilan terindeks 'sys.extended_index_xxx_384000' (objek ID xxx) tidak mengandung semua baris yang dihasilkan oleh definisi tampilan. Ini tidak selalu mewakili masalah integritas dengan data dalam database ini.

Indeks spasial, indeks XML atau tampilan terindeks 'sys.extended_index_xxx_384000' (objek ID xxx) berisi baris yang tidak diproduksi oleh definisi tampilan. Ini tidak selalu mewakili masalah integritas dengan data dalam database ini.

CHECKDB menemukan 0 kesalahan alokasi dan 2 kesalahan konsistensi dalam tabel 'sys.extended_index_xxx_384000' (objek ID xxx).

Tingkat perbaikan adalah repair_rebuild.

Menjatuhkan dan membuat ulang indeks tidak menghapus laporan korupsi ini. Tanpa EXTENDED_LOGICAL_CHECKStetapi dengan DATA_PURITYkesalahan tidak dilaporkan.

Juga, CHECKTABLEmembutuhkan 45 menit untuk tabel ini walaupun CI-nya berukuran 30 MB dan ada sekitar 30k baris. Semua data dalam tabel itu adalah geographydata titik .

Apakah perilaku ini diharapkan dalam keadaan apa pun? Dikatakan "Ini tidak selalu mewakili masalah integritas". Apa yang harus aku lakukan? CHECKDBgagal yang merupakan masalah.

Script ini mereproduksi masalah:

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

Ini adalah versi 12.0.4427.24 (SQL Server 2014 SP1 CU3).

Saya menulis tabel dengan skema dan data, DB baru, jalankan. Kesalahan yang sama. CHECKDB juga memiliki runtime 45 menit yang luar biasa ini. Saya menangkap rencana permintaan CHECKDB menggunakan SQL Profiler. Ini memiliki loop bergabung sesat tampaknya menyebabkan runtime yang berlebihan. Paket memiliki runtime kuadrat dalam jumlah baris tabel! Loop pemindaian bersarang ganda bergabung.

Rencana eksekusi DBCC

Menghapus semua indeks non-spasial tidak mengubah apa pun.

Jawaban:


25

Saya tidak bisa segera mereproduksi ini pada 2014 - 12.0.4213.0 tetapi melihatnya di SQL Server 2016 (CTP3.0) - 13.0.700.242.

Pada versi 2014 (tanpa kesalahan DBCC), rencana terlihat sebagai berikut.

masukkan deskripsi gambar di sini

Dan pada build 2016 ( dengan kesalahan DBCC dilaporkan) seperti ini.

masukkan deskripsi gambar di sini

Paket kedua memiliki satu baris yang keluar dari gabungan semi bergabung, paket nol pertama.

Predikat gabungan berbeda sehubungan dengan apa yang cocok dengan pk0kolom dalam indeks spasial.

masukkan deskripsi gambar di sini

Yang pertama memetakannya dengan benar ke tabel Primary Key, yang kedua memetakannya ke Idkolom yang dikembalikan dari TVF.

Menurut buku internal SQL Server 2012 ini adalah nilai biner (5) untuk jumlah sel Hilbert sehingga predikat ini tentu tidak benar (Jika Id baris tunggal di tabel dasar diatur ke 1052031049 alih-alih 20171 saya tidak ada lebih lama melihat kesalahan DBCC karena hal ini terjadi sesuai dengan nilai ini 0xa03eb4b849).


Pada 2014 - 12.0.4213.0 setelah membuat ulang tabel sebagai berikut saya bisa mereproduksi masalah.

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

(Catat perubahan dari IDmenjadi Id)

Instance 2014 saya diinstal dengan collation Case Sensitive. Jadi sepertinya ini telah mencegah kebingungan kolom sebelumnya.

Jadi saya kira solusi yang mungkin untuk mengubah nama kolom Citiesseperti CityIdmisalnya.

Hubungkan Item (laporan bug Microsoft)


4
Ini adalah bug yang fantastis :) Mungkin juga menjelaskan loop gila bergabung karena mereka mungkin hanya pilihan yang baik untuk kondisi bergabung kardinalitas mungkin lebih tinggi ini.
boot4life

7
@ boot4life IdKebingungan juga menyebabkan apa yang harus dicari sebagai pemindaian. Tangkapan yang bagus, Martin. Tampaknya hanya memengaruhi AUTO_GRIDopsi. Saya dapat mereproduksi bug pada 2014 SP1 CU4 dengan susunan case yang tidak sensitif. SQL Server membangun kueri pemeriksaan diperpanjang salah.
Paul White mengatakan GoFundMonica
Dengan menggunakan situs kami, Anda mengakui telah membaca dan memahami Kebijakan Cookie dan Kebijakan Privasi kami.
Licensed under cc by-sa 3.0 with attribution required.