Tham nhũng không thể trộn DBCC CHECKDB: Chế độ xem được lập chỉ mục chứa các hàng không được tạo bởi định nghĩa chế độ xem

TL; DR: Tôi đã có một tham nhũng không thể sửa chữa trong một cái nhìn được lập chỉ mục. Đây là những thông tin chi tiết:

Đang chạy

DBCC CHECKDB([DbName]) WITH EXTENDED_LOGICAL_CHECKS, DATA_PURITY, NO_INFOMSGS, ALL_ERRORMSGS

trên một trong những cơ sở dữ liệu của tôi tạo ra lỗi sau:

Msg 8907, Cấp 16, Trạng thái 1, Dòng 1 Chỉ mục không gian, chỉ mục XML hoặc chế độ xem được lập chỉ mục 'ViewName' (ID đối tượng 784109934) 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à 1 lỗi nhất quán trong bảng 'ViewName'.

Repair_Vbuild là mức sửa chữa tối thiểu (...).

Tôi hiểu rằng thông báo này chỉ ra rằng dữ liệu được cụ thể hóa của chế độ xem được lập chỉ mục 'ViewName' không giống với những gì truy vấn cơ bản tạo ra. Tuy nhiên, việc xác minh dữ liệu theo cách thủ công không tạo ra bất kỳ sự khác biệt nào:

SELECT * FROM ViewName WITH (NOEXPAND)
EXCEPT
SELECT ...
from T1 WITH (FORCESCAN)
join T2 on ...

SELECT ...
from T1 WITH (FORCESCAN)
join T2 on ...
EXCEPT
SELECT * FROM ViewName WITH (NOEXPAND)

NOEXPANDđã được sử dụng để buộc sử dụng chỉ số (chỉ) trên ViewName. FORCESCANđã được sử dụng để ngăn chặn việc xem chỉ mục phù hợp xảy ra. Kế hoạch thực hiện xác nhận cả hai biện pháp để làm việc.

Không có hàng nào được trả về ở đây, có nghĩa là hai bảng giống hệt nhau. (Chỉ có các cột số nguyên và hướng dẫn, các bộ sưu tập không đi vào hoạt động).

Các lỗi không thể được cố định bằng cách tái tạo chỉ mục trên quan điểm hoặc bằng cách chạy DBCC CHECKDB REPAIR_ALLOW_DATA_LOSS. Lặp đi lặp lại các bản sửa lỗi cũng không giúp được gì. Tại sao DBCC CHECKDBbáo cáo lỗi này? Làm thế nào để thoát khỏi nó?

(Ngay cả khi xây dựng lại cố định, câu hỏi của tôi vẫn đứng vững - tại sao một lỗi được báo cáo mặc dù các truy vấn kiểm tra dữ liệu của tôi chạy thành công?)

Cập nhật: Lỗi đã được sửa trong một số bản phát hành. Tôi không còn có thể sao chép nó trong SQL Server 2014 SP2 CU 5. 2014 SP2 KB chứa bản sửa lỗi mà không có bài viết KB : Creating non-clustered index causes DBCC CheckDB With Extended_Logical_Checks to raise corruption error. Hai lỗi kết nối về điều này đã bị đóng:

• https://connect.microsoft.com/QueryServer/feedback/details/847233/creating-non-clustered-index-causes-dbcc-checkdb-with-extends-logical-checks-to-raise-corruption-error
• https://connect.microsoft.com/QueryServer/feedback/details/795478/unfixable-dbcc-checkdb-error-that-is-also-a-false-poseitive-and-therwise-strange

Bộ xử lý truy vấn có thể tạo ra một kế hoạch thực hiện không hợp lệ cho truy vấn (chính xác) do DBCC tạo ra để kiểm tra xem chỉ mục xem có tạo ra các hàng giống như truy vấn của chế độ xem bên dưới không.

Kế hoạch được tạo bởi bộ xử lý truy vấn xử lý không chính xác NULLscho ImageObjectIDcột. Nó không chính xác lý do mà truy vấn xem từ chối NULLscho cột này, khi nó không. Nghĩ rằng NULLsbị loại trừ, nó có thể khớp với chỉ mục không được lọc trên Usersbảng mà bộ lọc trên ImageObjectID IS NOT NULL.

Bằng cách tạo ra một gói sử dụng chỉ mục được lọc này, nó đảm bảo rằng các hàng có NULLin ImageObjectIDkhông gặp phải. Các hàng này được trả về (chính xác) từ chỉ mục xem, vì vậy nó xuất hiện có tham nhũng khi không có.

Định nghĩa xem là:

SELECT
    dbo.Universities.ID AS Universities_ID, 
    dbo.Users.ImageObjectID AS Users_ImageObjectID
FROM dbo.Universities
JOIN dbo.Users
    ON dbo.Universities.AdminUserID = dbo.Users.ID

Các ONso sánh bình đẳng khoản giữa AdminUserIDvà IDRejects NULLstrong các cột, nhưng không phải từ ImageObjectIDcột.

Một phần của truy vấn được tạo DBCC là:

SELECT [Universities_ID], [Users_ImageObjectID], 0 as 'SOURCE'
FROM [dbo].[mv_Universities_Users_ID] tOuter WITH (NOEXPAND) 
WHERE NOT EXISTS
( 
    SELECT 1 
    FROM   [dbo].[mv_Universities_Users_ID] tInner
    WHERE 
    (
        (
            (
                [tInner].[Universities_ID] = [tOuter].[Universities_ID]
            ) 
            OR 
            (
                [tInner].[Universities_ID] IS NULL
                AND [tOuter].[Universities_ID] IS NULL
            )
        )
        AND
        (
            (
                [tInner].[Users_ImageObjectID] = [tOuter].[Users_ImageObjectID]
            ) 
            OR 
            (
                [tInner].[Users_ImageObjectID] IS NULL 
                AND [tOuter].[Users_ImageObjectID] IS NULL
            )
        )
    )
)
OPTION (EXPAND VIEWS);

Đây là mã chung để so sánh các giá trị theo NULLkiểu nhận biết. Nó chắc chắn dài dòng, nhưng logic là tốt.

Lỗi trong lý luận của bộ xử lý truy vấn có nghĩa là một kế hoạch truy vấn sử dụng không đúng chỉ mục được lọc có thể được tạo ra, như trong đoạn kế hoạch ví dụ dưới đây:

Truy vấn DBCC có một đường dẫn mã khác thông qua bộ xử lý truy vấn từ các truy vấn của người dùng. Đường dẫn mã này chứa lỗi. Khi một kế hoạch sử dụng chỉ mục được lọc được tạo, nó không thể được sử dụng với USE PLANgợi ý để buộc hình dạng kế hoạch đó có cùng văn bản truy vấn được gửi từ kết nối cơ sở dữ liệu người dùng.

Đường dẫn mã trình tối ưu hóa chính (đối với các truy vấn của người dùng) không chứa lỗi này, do đó, nó đặc trưng cho các truy vấn nội bộ giống như các truy vấn được tạo bởi DBCC.

Điều tra sâu hơn cho thấy đây là một lỗi trong DBCC CHECKDB. Một lỗi Microsoft Connect đã được mở: Lỗi DBCC CHECKDB không thể sửa được (đó cũng là một lỗi dương tính và khác lạ) . May mắn thay, tôi đã có thể tạo ra một repro để lỗi có thể được tìm thấy và sửa chữa.

Lỗi có thể được ẩn bằng cách chơi với lược đồ cơ sở dữ liệu. Xóa một chỉ mục được lọc không liên quan hoặc xóa bộ lọc, sẽ che giấu lỗi. Để biết chi tiết xin vui lòng xem các mục kết nối.

Mục kết nối cũng chứa truy vấn nội bộ mà DBCC CHECKDB sử dụng để xác thực nội dung xem. Nó trả về không có kết quả, cho thấy đây là một lỗi.

Các lỗi đã được sửa trong một số bản phát hành. Tôi không còn có thể sao chép nó trong SQL Server 2014 SP2 CU 5.