Esta semana, nosso banco de dados em um servidor SQL2014 SP2 CU11 começou a gerar erros fatais (gravidade 20), na instrução de código FETCH, que pode ser reduzido para:
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 e DBCC CHECKDB não encontraram nenhum problema, uma reinicialização do servidor não ajudou (e como ocorreu em várias versões do mesmo banco de dados ao mesmo tempo, era muito improvável que isso fosse um problema de estrutura de banco de dados).
Em um servidor de desenvolvimento com SQL2014 SP2 e apenas CU6, as mesmas instruções são executadas sem problemas (em um SQL2017 Server também funciona).
A mesa
- tem cerca de 4 milhões de linhas
- é particionado por uma coluna inteira
- tem um PK clusterizado em duas colunas (a coluna de partição mais um bigint)
- tem 25 índices (eu acho, eu deveria limpar um pouco :-))
Primeira solução: Quando alterei a declaração CURSOR para
(ou pelo menos adicionou a palavra-chave STATIC), ele funciona bem.
Solução final: A tabela tinha uma coluna de geometria e uma de geografia, que foram descartadas neste fim de semana (juntamente com os dois índices espaciais correspondentes).
Como essa foi a única alteração nessa tabela, decidi reconstruir o índice de chave primária clusterizada, o que resolveu esse problema.
Parece que o SP2 CU11 no SQL2014 tem um pequeno bug neste caso especial, então talvez alguém com um problema semelhante ache esta solução útil ...