web-dev-qa-db-ja.com

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

空間インデックスがあり、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があると、エラーは報告されません。

また、このテーブルのCHECKTABLEは45分かかりますが、CIのサイズは30 MBであり、約30k行あります。そのテーブルのすべてのデータはポイントgeographydataです。

この動作はどのような状況でも予想されますか？それは「これは必ずしも完全性の問題を表すものではない」と述べています。私はどうしたらいいですか？ 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プロファイラを使用してCHECKDBクエリプランをキャプチャしました。見当違いのループ結合があり、明らかに過度のランタイムを引き起こしています。計画には、テーブルの行数に2次ランタイムがあります！二重にネストされたスキャンループ結合。

DBCC execution plan

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

sql-serversql-server-2014spatialdbcc-checkdb
23
boot4life

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

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

enter image description here

そして、このような2016ビルド（withDBCCエラーが報告された）では、.

enter image description here

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

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

enter image description here

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

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

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バグレポート）

25
Martin Smith