sql-server – 不可修复的空间索引损坏是否正常？

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

The spatial index,XML index or indexed view ‘sys.extended_index_xxx_384000’ (object ID xxx) does not contain all rows that the view definition produces. This does not necessarily represent an integrity issue with the data in this database.

The spatial index,XML index or indexed view ‘sys.extended_index_xxx_384000’ (object ID xxx) contains rows that were not produced by the view definition. This does not necessarily represent an integrity issue with the data in this database.

CHECKDB found 0 allocation errors and 2 consistency errors in table ‘sys.extended_index_xxx_384000’ (object ID xxx).

修复级别是repair_rebuild.

删除并重新创建索引不会删除这些损坏报告.如果没有EXTENDED_LOGICAL_CHECKS但使用DATA_PURITY,则不会报告错误.

此外,CHECKTABLE需要45分钟才能使用此表,尽管它的CI大小为30 MB,大约有30,000行.该表中的所有数据都是点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,SORT_IN_TEMPDB = OFF,DROP_EXISTING = OFF,ONLINE = OFF,ALLOW_PAGE_LOCKS = ON) ON [PRIMARY]
GO

这是版本12.0.4427.24(SQL Server 2014 SP1 CU3).

我用表格和数据编写了表格,新的DB,执行.同样的错误. CHECKDB也具有45分钟的令人难以置信的运行时间.我使用SQL事件探查器捕获了CHECKDB查询计划.它有一个错误的循环连接,显然会导致运行时间过长.该计划在表的行数中具有二次运行时！双嵌套扫描循环连接.

清除所有非空间索引不会改变任何内容.

解决方法

在2014年版本中(没有DBCC错误),该计划如下所示.

并在2016年版本(报告DBCC错误)这样.

第二个计划有一行来自合并反半连接,第一个计划零行.

连接谓词与空间索引中与pk0列匹配的内容不同.

第一个正确地将它映射到表主键,第二个映射到从TVF返回的Id列.

根据SQL Server 2012内部书籍,这是单元格的希尔伯特数的二进制(5)值,因此该谓词肯定是不正确的(如果基表中单行的Id设置为1052031049而不是20171我没有更长时间看到任何DBCC错误,因为这恰好对应于此值0xa03eb4b849).

在2014年 – 12.0.4213.0重新创建表后,我可以重现问题.

CREATE TABLE dbo.Cities(
    Id int  NOT NULL,CONSTRAINT PK_Cities PRIMARY KEY CLUSTERED 
(
    Id ASC
)WITH (PAD_INDEX = OFF,ALLOW_PAGE_LOCKS = ON)
)

(注意从ID到Id的变化)

我的2014实例安装了Case Sensitive整理.所以看起来好像这可能阻止了之前的列混淆.

所以我想一个潜在的解决方法可能是将CITY中的列重命名为CityId.

Connect Item(微软错误报告)

（编辑：李大同）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!