當存在空間索引時，我們在 Sql Server 2008R2 上遇到了 DBCC CHECKDB 因存取衝突（空指標引用）而崩潰的問題。使用 DBCC CHECKDB WITH EXTENDED_LOGICAL_CHECKS 可以重複問題，但在某些情況下僅使用 DBCC CHECKDB 也會發生這種情況。
我們在 Windows 2008 R2 和 Windows 7（都是 64 位元）下的 Sql Server 2008 R2 sp1 標準（和開發人員版本）上發生了這種情況。
以下是一個示範此問題的簡單 T-SQL 腳本。如果您在 SSMS 中運行它，您將看到輸出並且 sql 連線被終止。
使用大師
去
如果存在(select * from sys.databases where name = 'DbccCrashExample') 刪除資料庫DbccCrashExample
去
建立資料庫 DbccCrashExample
去
使用 DbccCrashExample
去
建立表 dbo.GeometryTable
（
GeometryTableID int NOT NULL,
特徵幾何形狀不為空，
CONSTRAINT PK_GeometryTable 主鍵聚集（GeometryTableID）
）
去
插入 dbo.GeometryTable(GeometryTableID, Feature)
選擇 1，幾何::STGeomFromText('POINT(0 0)', 4326)
去
使用 (BOUNDING_BOX=(0, -2, 1, 2)) 在 dbo.GeometryTable(Feature) 上建立空間索引 SPATIAL_GeometryTable_Feature
——作品
--DBCC檢查資料庫
-- 失敗
帶有 EXTENDED_LOGICAL_CHECKS 的 DBCC CHECKDB
一件奇怪的事情是，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 * 讀取位址 0000000000000000 時發生存取衝突 * 輸入緩衝區 408 位元組 - * 在 dbo.Geo 上建立空間索引 SPATIAL_GeometryTable_Feature * metricTable(Feature) with (BOUNDING_BOX=(0, -2, 1, 2)) -- 有效 --DBCC * CHECKDB -- DBCC CHECKDB 與 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）中修復。
因此，目前的解決方案是不要執行“WITH EXTENDED_LOGICAL_CHECKS”或完全跳過“DBCC CHECKDB”，直到 2011 年 12 月中旬累積更新發佈為止。
問題描述 ---------------------------- 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 的執行緒堆疊 子 SP RetAddr 呼叫站點 00000000`0e3d8dd0 00000000`01a40289 sqlservr!CScaOp_Identifier::裝飾+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::轉換+0x4de 00000000`0e3dbeb0 00000000`00bce5c9 sqlservr!CSQLSource::執行+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::執行+0x55 00000000`0e3dc630 00000000`028845eb sqlservr!RowsetDiffExecutor::執行+0x386 00000000`0e3dd300 00000000`02882661 sqlservr!UtilDbccCheckDatabase+0x1a37 00000000`0e3de670 00000000`028bd0b0 sqlservr!DbccCheckDB+0x2bd 00000000`0e3de6d0 00000000`01bd50a2 sqlservr!DbccCommand::執行+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::執行+0x7b5 00000000`0e3deee0 00000000`007965e2 sqlservr!process_request+0x64b 00000000`0e3df540 00000000`006eb450 sqlservr!process_commands+0x4e5 00000000`0e3df750 00000000`006eb116 sqlservr!SOS_Task::參數::執行+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 的修補程序請求