修正不可能な空間インデックスの破損は正常と見なされますか？

破損を報告する空間インデックスがありDBCC CHECKDBます：

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

空間インデックス、XMLインデックス、またはインデックス付きビュー 'sys.extended_index_xxx_384000'（オブジェクトID xxx）には、ビュー定義が生成するすべての行が含まれていません。これは、必ずしもこのデータベース内のデータの整合性の問題を表しているわけではありません。

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

CHECKDBは、テーブル 'sys.extended_index_xxx_384000'（オブジェクトID xxx）で0の割り当てエラーと2つの一貫性エラーを検出しました。

修理レベルはrepair_rebuildです。

インデックスを削除して再作成しても、これらの破損レポートは削除されません。なしでEXTENDED_LOGICAL_CHECKSはなくてDATA_PURITYエラーが報告されていません。

また、CHECKTABLECIのサイズは30 MBで、約3万行ありますが、このテーブルには45分かかります。そのテーブルのすべてのデータはポイントgeographyデータです。

この動作はどのような状況でも予想されますか？「これは必ずしも整合性の問題を表しているわけではありません」と書かれています。私はどうしたらいいですか？CHECKDB失敗しています。これは問題です。

このスクリプトは問題を再現します：

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

これは、バージョン12.0.4427.24（SQL Server 2014 SP1 CU3）です。

スキーマとデータ、新しいDB、実行を使用してテーブルのスクリプトを作成しました。同じエラー。CHECKDBには、この45分の信じられないほどのランタイムもあります。SQL Profilerを使用してCHECKDBクエリプランをキャプチャしました。ループ結合が誤っているため、明らかに過剰な実行時間が発生します。プランには、テーブルの行数に2次ランタイムがあります！二重にネストされたスキャンループ結合。

すべての非空間インデックスをクリアしても、何も変わりません。

これを2014-12.0.4213.0ですぐに再現できませんでしたが、SQL Server 2016（CTP3.0）-13.0.700.242で確認できます。

2014ビルド（DBCCエラーなし）では、計画は次のようになります。

そして、（2016ビルド上で、このような報告DBCCエラー）。

2番目のプランには、マージアンチセミジョインから1つの行があり、最初のプランには行がありません。

結合述部はpk0、空間インデックスの列に一致するものに関して異なります。

最初のものはテーブルの主キーに正しくマッピングし、2番目のIdものはTVFから返された列にマッピングします。

SQL Server 2012の内部の本によると、これはセルのヒルベルト数のbinary（5）値であるため、この述語は間違いなく間違いです（ベーステーブルの単一行のIDが20171ではなく1052031049に設定されている場合Iいいえこれはたまたまこの値に対応するため、DBCCエラーが表示されなくなります0xa03eb4b849。

2014-12.0.4213.0では、次のようにテーブルを再作成した後、問題を再現できました。

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

（からIDへの変更に注意してくださいId）

2014年のインスタンスは、大文字と小文字を区別した照合でインストールされます。そのため、以前は列の混乱を防いでいたようです。

私が推測するように、潜在的な問題を回避するには、列の名前を変更するかもしれないCitiesとして、CityId例えば。

接続アイテム（Microsoftバグレポート）