Là tham nhũng chỉ số không gian không thể trộn được coi là bình thường?


23

Tôi có một chỉ mục không gian để DBCC CHECKDBbáo cáo tham nhũng:

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

Chỉ mục không gian, chỉ mục XML hoặc chế độ xem được lập chỉ mục 'sys.extends_index_xxx_384000' (ID đối tượng xxx) không chứa tất cả các hàng mà định nghĩa chế độ xem tạo ra. Điều này không nhất thiết thể hiện vấn đề toàn vẹn với dữ liệu trong cơ sở dữ liệu này.

Chỉ mục không gian, chỉ mục XML hoặc chế độ xem được lập chỉ mục 'sys.extends_index_xxx_384000' (ID đối tượng xxx) chứa các hàng không được tạo bởi định nghĩa chế độ xem. Điều này không nhất thiết thể hiện vấn đề toàn vẹn với dữ liệu trong cơ sở dữ liệu này.

CHECKDB đã tìm thấy 0 lỗi phân bổ và 2 lỗi nhất quán trong bảng 'sys.extends_index_xxx_384000' (ID đối tượng xxx).

Cấp sửa chữa là repair_rebuild.

Bỏ và tạo lại chỉ mục không loại bỏ các báo cáo tham nhũng. Không có EXTENDED_LOGICAL_CHECKSnhưng với DATA_PURITYlỗi không được báo cáo.

Ngoài ra, CHECKTABLEmất 45 phút cho bảng này mặc dù CI của nó có kích thước 30 MB và có khoảng 30k hàng. Tất cả dữ liệu trong bảng đó là geographydữ liệu điểm .

Là hành vi này dự kiến ​​trong bất kỳ trường hợp? Nó nói "Điều này không nhất thiết phải đại diện cho một vấn đề toàn vẹn". Tôi phải làm gì bây giờ? CHECKDBthất bại đó là một vấn đề.

Kịch bản này tái tạo vấn đề:

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

Đây là phiên bản 12.0.4427.24 (SQL Server 2014 SP1 CU3).

Tôi viết kịch bản với lược đồ và dữ liệu, DB mới, thực thi. Cùng một lỗi. CHECKDB cũng có thời gian chạy đáng kinh ngạc là 45 phút. Tôi đã nắm bắt kế hoạch truy vấn CHECKDB bằng SQL Profiler. Nó có một vòng lặp sai lầm tham gia rõ ràng gây ra thời gian chạy quá mức. Kế hoạch có thời gian chạy bậc hai trong số lượng hàng của bảng! Vòng lặp quét lồng nhau tham gia.

Kế hoạch thực hiện DBCC

Xóa tất cả các chỉ mục phi không gian không thay đổi bất cứ điều gì.

Câu trả lời:


25

Tôi không thể sao chép ngay lập tức vào năm 2014 - 12.0.4213.0 nhưng tôi thấy nó trên SQL Server 2016 (CTP3.0) - 13.0.700.242.

Trên bản dựng 2014 (không có lỗi DBCC), kế hoạch sẽ như sau.

nhập mô tả hình ảnh ở đây

Và trên bản dựng năm 2016 ( lỗi DBCC được báo cáo) như thế này.

nhập mô tả hình ảnh ở đây

Kế hoạch thứ hai có một hàng duy nhất được đưa ra khỏi hợp nhất chống bán tham gia, kế hoạch đầu tiên không có hàng nào.

Các vị từ nối là khác nhau đối với những gì được khớp với pk0cột trong chỉ mục không gian.

nhập mô tả hình ảnh ở đây

Cái đầu tiên ánh xạ chính xác nó vào bảng Khóa chính, Cái thứ hai ánh xạ nó tới Idcột được trả về từ TVF.

Theo sách nội bộ của SQL Server 2012, đây là giá trị nhị phân (5) cho số Hilbert của ô nên vị từ này chắc chắn không chính xác (Nếu Id của hàng đơn trong bảng cơ sở được đặt thành 1052031049 thay vì 20171 tôi không còn thấy bất kỳ lỗi DBCC nào vì điều này xảy ra tương ứng với giá trị này của 0xa03eb4b849).


Vào năm 2014 - 12.0.4213.0 sau khi tạo lại bảng như sau tôi có thể tái tạo vấn đề.

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

(Lưu ý thay đổi từ IDsang Id)

Phiên bản 2014 của tôi được cài đặt với đối chiếu Case Sensitive. Vì vậy, có vẻ như điều này có thể đã ngăn chặn sự nhầm lẫn cột trước đây.

Vì vậy, tôi đoán một cách giải quyết tiềm năng có thể là đổi tên cột Citiesthành CityIdví dụ.

Kết nối mục (báo cáo lỗi của Microsoft)


4
Đây là một lỗi tuyệt vời :) Cũng có thể giải thích các vòng lặp điên rồ tham gia bởi vì chúng có thể đơn giản là một lựa chọn tốt cho điều kiện tham gia cardinality có thể cao hơn này.
boot4life

7
@ boot4life Sự Idnhầm lẫn cũng gây ra những gì nên tìm cách quét. Bắt tuyệt vời, Martin. Nó chỉ xuất hiện để ảnh hưởng đến các AUTO_GRIDtùy chọn. Tôi có thể sao chép lỗi trên 2014 SP1 CU4 với trường hợp đối chiếu không nhạy. SQL Server xây dựng truy vấn kiểm tra mở rộng không chính xác.
Paul White nói GoFundMonica
Khi sử dụng trang web của chúng tôi, bạn xác nhận rằng bạn đã đọc và hiểu Chính sách cookieChính sách bảo mật của chúng tôi.
Licensed under cc by-sa 3.0 with attribution required.