当存在空间索引时，我们遇到了 DBCC CHECKDB 在 Sql Server 2008R2 上因访问冲突（空指针引用）而崩溃的问题。使用 DBCC CHECKDB WITH EXTENDED_LOGICAL_CHECKS 可重复此问题，但在某些情况下仅使用 DBCC CHECKDB 也会发生此问题。
这发生在 Windows 2008 R2 下的 Sql Server 2008 R2 sp1 标准版（和开发人员版）和 Windows 7（全部 64 位）下。
这是一个简单的 T-SQL 脚本，用于演示此问题。如果您在 SSMS 中运行它，您将看到输出和 SQL 连接被终止。
使用主控
去
如果存在（从 sys.databases 中选择 *，其中 name = 'DbccCrashExample'）删除数据库 DbccCrashExample
去
创建数据库 DbccCrashExample
去
使用 DbccCrashExample
去
创建表 dbo.GeometryTable
（
GeometryTableID int 非空，
特征几何非空，
约束 PK_GeometryTable 主键聚集 (GeometryTableID)
）
去
插入 dbo.GeometryTable(GeometryTableID，Feature)
选择 1，几何::STGeomFromText('POINT(0 0)'，4326)
去
在 dbo.GeometryTable(Feature) 上创建空间索引 SPATIAL_GeometryTable_Feature，其中 (BOUNDING_BOX=(0, -2, 1, 2))
-- 作品
--DBCC 检查数据库
-- 失败
DBCC CHECKDB 带有 EXTENDED_LOGICAL_CHECKS
奇怪的是，DBCC 似乎已经完成并且没有错误，但是随后发生了严重错误：
CHECKDB 在数据库“DbccCrashExample”中发现 0 个分配错误和 0 个一致性错误。 消息 0，级别 11，状态 0，行 0 当前命令发生严重错误。结果（如果有）应被丢弃。 消息 0，级别 20，状态 0，行 0 当前命令发生严重错误。结果（如果有）应被丢弃。
在 Sql Server 错误日志中，我们得到了如下堆栈转储：
SqlDumpExceptionHandler：进程 59 生成了致命异常 c0000005 EXCEPTION_ACCESS_VIOLATION。SQL Server 正在终止此进程。 ***************************************************************************************** * * 开始堆栈转储： * 11/20/11 13:23:34 spid 59 * * * 异常地址 = 0000000000E84A8D 模块（sqlservr+0000000000274A8D） * 异常代码 = c0000005 EXCEPTION_ACCESS_VIOLATION * 读取地址 00000000000000000 时发生访问冲突 * 输入缓冲区 408 字节 - * 在 dbo.Geo 上创建空间索引 SPATIAL_GeometryTable_Feature * metryTable(Feature) 与 (BOUNDING_BOX=(0, -2, 1, 2)) -- 有效 --DBCC * CHECKDB — DBCC CHECKDB WITH EXTENDED_LOGICAL_CHECKS 失败 *
我们已经就此问题向 Microsoft 提交了付费支持案例。我在此发布此问题是为了与其他人分享此问题。我将发布我们从 Microsoft 收到的有关此问题的反馈。
答案1
更新：
该修复已在 Sql Server 2008 r2 sp1 cu4 中发布。
SQL Server 2008 R2 Service Pack 1 的累积更新包 4
有关此问题的更多详细信息请参见此处：
修复：在 SQL Server 2008 或 SQL Server 2008 R2 中对包含具有空间索引的表的数据库运行 DBCC CHECKDB 命令时发生访问冲突
历史：
我们向 Microsoft 提交了有关此问题的支持案例。显然这是一个已知问题，已在其他版本的 Sql Server（2008 SP2 CU7、2008 SP3 CU3、2008R2 RTM CU11、2008R2 SP1 CU4）中修复，并将在 Sql Server 2008R2 SP1 CU4（sp1 累积更新 4）中修复。
因此，目前的解决方案是，在 2011 年 12 月中旬累积更新发布之前，不要运行“WITH EXTENDED_LOGICAL_CHECKS”或完全跳过“DBCC CHECKDB”。
问题描述 ----------------------------- DBCC CHECKDB WITH EXTENDED_LOGICAL_CHECKS 失败并出现以下错误，并生成访问冲突转储 CHECKDB 在数据库“AriesTempForEtlOnly”中发现 0 个分配错误和 0 个一致性错误。 消息 0，级别 11，状态 0，行 0 当前命令发生严重错误。结果（如果有）应被丢弃。 消息 0，级别 20，状态 0，行 0 当前命令发生严重错误。结果（如果有）应被丢弃 DBCC CHECKDB 运行良好，当您删除空间索引时它似乎工作正常。 分析 -------------------- -- 触发访问冲突的指令 sqlservr！CScaOp_Identifier::装饰+0x63： 00000000`00954a8d 488b01 mov rax，qword ptr [rcx] ds：00000000`00000000=???????????????? -- 命中 AV 的线程的堆栈 Child-SP ReAddr 调用站点 00000000`0e3d8dd0 00000000`01a40289 sqlservr！CScaOp_Identifier::Decorate+0x63 00000000`0e3d8e20 00000000`01a4007a sqlservr！CScaOp_Identifier::XRelBindSelf+0x16d 00000000`0e3d8eb0 00000000`01a3ccd9 sqlservr！CScaOpArg::XRelBind+0x62 00000000`0e3d8ee0 00000000`01a3cda2 sqlservr！XRelBindProjectList+0x8d 00000000`0e3d8f20 00000000`01a3d781 sqlservr！CRelOp_Project::XRelBind+0x56 00000000`0e3d8f90 00000000`01a3f877 sqlservr！CRelOp_Union::XRelBind+0xa5 00000000`0e3d8ff0 00000000`01a3f990 sqlservr！CRelOp_Query::XRelBind+0x27 00000000`0e3d9020 00000000`00d48d4b sqlservr！CRelOp_Query::XRelBindQuery+0xb4 00000000`0e3d91f0 00000000`008b37a5 sqlservr！CProchdr::FNormQuery+0x3a 00000000`0e3d9230 00000000`00876644 sqlservr！CProchdr::FNormalizeStep+0x13ae 00000000`0e3d9700 00000000`00877259 sqlservr！CSQLSource::FCompile+0xc99 00000000`0e3dbd20 00000000`008770fc sqlservr！CSQLSource::FCompWrapper+0xc1 00000000`0e3dbdf0 00000000`0074ac63 sqlservr！CSQLSource::Transform+0x4de 00000000`0e3dbeb0 00000000`00bce5c9 sqlservr！CSQLSource::Execute+0x449 00000000`0e3dbfe0 00000000`02418255 sqlservr！CSQLSource::SeExecute+0x17c 00000000`0e3dc0a0 00000000`028abc55 sqlservr！ExecXrel+0x1f1 00000000`0e3dc570 00000000`028ab7d5 sqlservr！CheckRowsetDiff::ExecuteXREL+0x195 00000000`0e3dc5f0 00000000`028ad41a sqlservr！CheckRowsetDiff::Execute+0x55 00000000`0e3dc630 00000000`028845eb sqlservr！RowsetDiffExecutor::Execute+0x386 00000000`0e3dd300 00000000`02882661 sqlservr！UtilDbccCheckDatabase+0x1a37 00000000`0e3de670 00000000`028bd0b0 sqlservr！DbccCheckDB+0x2bd 00000000`0e3de6d0 00000000`01bd50a2 sqlservr！DbccCommand::Execute+0xc8 00000000`0e3de7a0 00000000`00749a86 sqlservr！CStmtDbcc::XretExecute+0x8ce 00000000`0e3deb20 00000000`0074b4af sqlservr！CMsqlExecContext::ExecuteStmts+0x375 00000000`0e3dec30 00000000`0074ad6c sqlservr！CMsqlExecContext::FExecute+0x97e 00000000`0e3dedb0 00000000`0076cfa6 sqlservr！CSQLSource::Execute+0x7b5 00000000`0e3deee0 00000000`007965e2 sqlservr！process_request+0x64b 00000000`0e3df540 00000000`006eb450 sqlservr！process_commands+0x4e5 00000000`0e3df750 00000000`006eb116 sqlservr！SOS_Task::Param::Execute+0x12a 00000000`0e3df860 00000000`006eaf5b sqlservr！SOS_Scheduler::RunTask+0x96 00000000`0e3df8c0 00000000`008244fa sqlservr！SOS_Scheduler::ProcessTasks+0x128 00000000`0e3df930 00000000`008247dd sqlservr！SchedulerManager::WorkerEntryPoint+0x2d2 00000000`0e3dfa10 00000000`00c6c0cd sqlservr！SystemThread::RunWorker+0xcc 00000000`0e3dfa50 00000000`008253d2 sqlservr！SystemThreadDispatcher::ProcessWorker+0x2db 00000000`0e3dfb00 00000000`733037d7 sqlservr！SchedulerManager::ThreadEntryPoint+0x173 00000000`0e3dfba0 00000000`73303894 msvcr80!_callthreadstartex+0x17 00000000`0e3dfbd0 00000000`76cc652d msvcr80!_threadstartex+0x84 00000000`0e3dfc00 00000000`773bc521 kernel32！BaseThreadInitThunk + 0xd 00000000`0e3dfc30 00000000`00000000 ntdll！RtlUserThreadStart + 0x1d
- 已向 Kilimanjaro RTM CU11 至 Kilimanjaro SP1CU4 的端口提交了修补程序请求
- 针对空间索引运行 CheckTable 时，CScaOp_Identifier::Decorate 中发生异常访问冲突。
- 问题发生在函数 CScaOp_Identifier::Decorate 中的一行代码中。
- 在这里，我们尝试取消引用结构 pLR（LookupResult），但它被设置为 NULL。
- 以下版本中已修复此问题：2008 SP2 CU7、2008 SP3 CU3、2008R2 RTM CU11、2008R2 SP1 CU4
- 已向 Kilimanjaro RTM CU11 至 Kilimanjaro SP1CU4 的端口提交了修补程序请求