嚴重性 20 - 提取後 LOCAL CURSOR 中的致命錯誤

本週，我們在 SQL2014 SP2 CU11 伺服器上的數據庫開始在程式碼的 FETCH 語句中拋出致命錯誤（嚴重性 20），可以簡化為：

DECLARE @dummy int
DECLARE CurName CURSOR LOCAL FOR
       SELECT TOP (1) t.id FROM dbo.t_table AS t;
OPEN CurName;

WHILE 1 = 1
BEGIN
   FETCH NEXT FROM CurName INTO @dummy;
   IF @@fetch_status <> 0 BREAK;
   PRINT @dummy
END;

DBCC CHECKTABLE 和 DBCC CHECKDB 沒有發現任何問題，伺服器重新啟動沒有幫助（並且由於它同時發生在同一數據庫的多個版本上，因此不太可能是數據庫結構問題）。

在帶有 SQL2014 SP2 且只有 CU6 的開發伺服器上，相同的語句執行沒有問題（在 SQL2017 伺服器上它也可以工作）。

桌子

• 大約有 4 mio 行
• 由整數列分區
• 在兩列上有一個聚集的 PK（分區列加上一個 bigint）
• 有 25 個索引（我想，我應該清理一下 :-)）

第一個解決方案： 當我將 CURSOR 聲明更改為

DECLARE CurName CURSOR LOCAL FORWARD_ONLY STATIC READ_ONLY FOR ...

（或至少添加了 STATIC 關鍵字），它執行良好。

最終解決方案： 該表有一個幾何和一個地理列，這週末被刪除了（連同兩個相應的空間索引）。

由於這是對該表的唯一更改，因此我決定重建聚集主鍵索引，從而解決了這個問題。

看來，SQL2014 中的 SP2 CU11 在這種特殊情況下有一個小錯誤，所以也許有類似問題的人會發現這個解決方案很有用……

引用自：https://dba.stackexchange.com/questions/207602