主页 / dba / 问题 / 124655
Accepted
boot4life
Asked: 2015-12-28 10:30:57 +0800 CST

无法修复的空间索引损坏是否被认为是正常的？

  • 772

我有一个报告损坏的空间索引：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 行。该表中的所有数据都是点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)。

我用模式和数据、新数据库、执行编写了表。同样的错误。CHECKDB 也有令人难以置信的 45 分钟运行时间。我使用 SQL Profiler 捕获了 CHECKDB 查询计划。它有一个误入歧途的循环连接，显然会导致运行时间过长。该计划在表的行数中具有二次运行时间！双重嵌套扫描循环连接。

DBCC执行计划

清除所有非空间索引不会改变任何东西。

sql-server sql-server-2014

1 个回答

  1. Best Answer

    我无法在 2014 - 12.0.4213.0 上立即重现它，但确实在 SQL Server 2016 (CTP3.0) - 13.0.700.242 上看到了它。

    在 2014 年版本（没有 DBCC 错误）中，计划如下所示。

    在此处输入图像描述

    在 2016 年版本中（报告了DBCC 错误）是这样的。

    在此处输入图像描述

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

    pk0连接谓词在与空间索引中的列匹配方面有所不同。

    在此处输入图像描述

    第一个正确地将其映射到表主键，第二个将其映射到Id从 TVF 返回的列。

    根据 SQL Server 2012 内部手册，这是单元格希尔伯特数的二进制 (5) 值，因此此谓词肯定不正确（如果基表中单行的 ID 设置为 1052031049 而不是 20171，我不不再看到任何 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 错误报告）

    • 26

相关问题