DBCC CHECKDBの修復不可能な破損：インデックス付きビューには、ビュー定義によって生成されなかった行が含まれています

TL; DR：インデックス付きビューに修正不可能な破損があります。詳細は次のとおりです。

ランニング

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

私のデータベースのいずれかで次のエラーが生成されます：

メッセージ8907、レベル16、状態1、行1空間インデックス、XMLインデックス、またはインデックス付きビュー 'ViewName'（オブジェクトID 784109934）には、ビュー定義によって生成されなかった行が含まれています。これは、必ずしもこのデータベース内のデータの整合性の問題を表しているわけではありません。（...）

CHECKDBは、テーブル 'ViewName'で0個の割り当てエラーと1個の一貫性エラーを検出しました。

repair_rebuildは最小修復レベル（...）です。

このメッセージは、インデックス付きビュー「ViewName」の具体化されたデータが、基になるクエリが生成するものと同一ではないことを示していることを理解しています。ただし、データを手動で検証しても矛盾は発生しません。

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で（のみ）インデックスの使用を強制するために使用されましたViewName。FORCESCANインデックス付きビューの一致を防ぐために使用されました。実行計画により、両方の対策が機能していることが確認されます。

ここには行が返されません。つまり、2つのテーブルは同一です。（整数列とGUID列のみがあり、照合は機能しません）。

ビューでインデックスを再作成するか、を実行してもエラーを修正できませんDBCC CHECKDB REPAIR_ALLOW_DATA_LOSS。修正を繰り返しても解決しませんでした。なぜDBCC CHECKDBこのエラーを報告するのですか？それを取り除く方法は？

（再構築によって修正されたとしても、私の疑問は解決されません。データチェッククエリは正常に実行されますが、エラーが報告されるのはなぜですか？）

更新：バグはいくつかのリリースで修正されました。SQL Server 2014 SP2 CU 5では再現できなくなりました。2014SP2 KBには、KB記事なしの修正が含まれていますCreating non-clustered index causes DBCC CheckDB With Extended_Logical_Checks to raise corruption error。これに関する2つの接続バグがクローズされました。

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

クエリプロセッサは、DBCCによって生成された（正しい）クエリに対して無効な実行プランを生成し、ビューインデックスが基になるビュークエリと同じ行を生成することを確認できます。

クエリプロセッサによって生成されたプランNULLsは、ImageObjectID列を誤って処理します。誤って、ビュークエリNULLsがこの列を拒否するのは、そうでない場合です。NULLs除外されていると考えると、フィルタリングするUsersテーブルのフィルタリングされた非クラスター化インデックスと一致することができますImageObjectID IS NOT NULL。

このフィルター選択されたインデックスを使用するプランを作成することにより、NULLin を含む行が検出さImageObjectIDれないようにします。これらの行はビューインデックスから（正しく）返されるため、存在しない場合は破損しているように見えます。

ビューの定義は次のとおりです。

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

これらの列のON句の等価比較AdminUserIDおよびID拒否NULLsは、列からではなく、拒否しImageObjectIDます。

DBCCが生成したクエリの一部は次のとおりです。

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

これは、値をNULL意識した方法で比較する汎用コードです。確かに冗長ですが、ロジックは問題ありません。

クエリプロセッサの推論のバグは、以下のプランフラグメントの例のように、フィルタリングされたインデックスを誤って使用するクエリプランが生成される可能性があることを意味します。

DBCCクエリは、クエリプロセッサを介したユーザークエリとは異なるコードパスを取ります。このコードパスにはバグが含まれています。フィルター選択されたインデックスを使用するプランが生成USE PLANされるとき、ユーザーデータベース接続から送信された同じクエリテキストでそのプランの形状を強制するヒントと一緒に使用できません。

メインオプティマイザーコードパス（ユーザークエリ用）にはこのバグが含まれていないため、DBCCによって生成されるような内部クエリに固有です。

さらに調査した結果、これはDBCC CHECKDBのバグであることがわかりました。Microsoft Connectのバグが公開されました。不可能なDBCC CHECKDBエラー（これも誤検知であり、奇妙なエラーです）。幸いなことに、バグを見つけて修正できるように再現することができました。

このバグは、データベーススキーマを操作することで隠すことができます。無関係のフィルター選択されたインデックスを削除するか、フィルターを削除すると、バグが隠されます。詳細については、接続項目を参照してください。

接続項目には、DBCC CHECKDBがビューの内容を検証するために使用する内部クエリも含まれています。結果が返されず、これがバグであることを示しています。

このバグはいくつかのリリースで修正されています。SQL Server 2014 SP2 CU 5では再現できなくなりました。