KB4338890 - CORRECÇÃO: erro "Agendador sem rendimento" e SQL Server parece não responder no SQL Server 2014, 2016 e 2017

Aplica-se a
SQL Server 2016 Developer - duplicate (do not use) SQL Server 2016 Enterprise - duplicate (do not use) SQL Server 2016 Enterprise Core - duplicate (do not use) SQL Server 2016 Standard - duplicate (do not use) SQL Server 2017 Developer on Windows SQL Server 2017 Enterprise Core on Windows SQL Server 2017 Enterprise on Windows SQL Server 2017 Standard on Windows SQL Server 2014 Developer - duplicate (do not use) SQL Server 2014 Enterprise - duplicate (do not use) SQL Server 2014 Enterprise Core - duplicate (do not use) SQL Server 2014 Standard - duplicate (do not use)

Sintomas

Suponha que você tenha o Microsoft SQL Server 2014, 2016 ou 2017 instalado.  Você pode enfrentar um ou mais dos seguintes problemas:

  • A instância do SQL Server parece não responder e ocorre um erro de "Agendador sem rendimento". Talvez seja necessário reiniciar o servidor para se recuperar.
  • A reversão de uma transação pode levar muito tempo para ser concluída. Na maioria dos casos, reiniciar a instância permitirá que o banco de dados se recupere muito mais rapidamente do que a reversão. Observe que há muitos motivos pelos quais uma reversão pode levar muito tempo para ser concluída. Consulte a seção "Mais informações" abaixo para obter detalhes sobre o monitoramento de reversões antes de tentar reiniciar.
  • Você pode ver esperas altas em spinlocks como SOS_OBJECT_STORE.

Resolução

Esse problema é corrigido nas seguintes atualizações cumulativas para o SQL Server:

Atualização cumulativa 9 para o SQL Server 2017

Atualização cumulativa 2 para o SQL Server 2016 SP2

Sobre atualizações cumulativas para o SQL Server:

Cada nova atualização cumulativa do SQL Server contém todos os hotfixes e todas as correções de segurança incluídas na atualização cumulativa anterior. Confira as atualizações cumulativas mais recentes para o SQL Server:

Atualização cumulativa mais recente do SQL Server 2017

Atualização cumulativa mais recente do SQL Server 2016

Atualização cumulativa mais recente do SQL Server 2014

Informações do service pack do SQL Server

Esta atualização é corrigida no seguinte service pack para o SQL Server:

Service Pack 3 para SQL Server 2014

Sobre os service packs do SQL Server:

Os service packs são cumulativos. Cada novo service pack contém todas as correções dos service packs anteriores, juntamente com as novas correções. Nossa recomendação é aplicar o service pack mais recente e a atualização cumulativa mais recente para esse service pack. Não é necessário instalar um service pack anterior antes de instalar o service pack mais recente. Use a Tabela 1 do artigo a seguir para encontrar mais informações sobre o service pack mais recente e a atualização cumulativa mais recente.

Como determinar a versão, a edição e o nível de atualização do SQL Server e seus componentes

Mais informações

Há muitos motivos pelos quais uma reversão pode levar muito tempo, como uma transação de execução longa, um grande número de VLFs no arquivo de log de transações, E/S lenta etc. Para verificar se o problema descrito neste artigo é a causa raiz de uma reversão lenta, sugerimos que as seguintes técnicas sejam usadas para monitorar o progresso da operação de reversão:

  • No sys.dm_exec_requests, identifique o session_id cujo comando está definido como "KILLED/ROLLBACK" e verifique se a sessão está acumulando tempo de E/S e CPU, indicando o progresso. Se a E/S não estiver sendo alterada, pode ser uma indicação de que você está enfrentando o problema descrito neste artigo.
  • Consultar sys.dm_tran_database_transactions para identificar o estado atual da reversão usando uma consulta como a seguinte:

Observação

  • SELECT getdate() as CurrentTime, database_transaction_next_undo_lsn,database_transaction_begin_lsn,t.transaction_id,database_transaction_begin_time,database_transaction_log_record_count,db_name(t.database_id)
  • DE sys.dm_tran_database_transactions t
  • INGRESSAR sys.dm_exec_requests s
       ON t.transaction_id=s.transaction_id
  • WHERE t.database_id=db_id('<Database Name') and s.session_id=<Session_id realizando a operação> de reversão

Observação:

Na consulta acima,

database_transaction_next_undo_lsn é o LSN do próximo registro a ser desfeito. database_transaction_begin_lsn é o LSN do registro inicial da transação no log de transações.

database_transaction_next_undo_lsn deve diminuir a cada snapshot dessa consulta. A reversão será concluída com êxito quando o database_transaction_next_undo_lsn atingir database_transaction_begin_lsn.

O objetivo aqui é tirar alguns instantâneos da consulta anterior dentro de um intervalo predeterminado e, em seguida, usar o delta dos LSNs processados no database_transaction_next_undo_lsn dentro desse intervalo e extrapolar o tempo necessário para estimar o tempo que levará para o database_transaction_next_undo_lsn atingir o database_transaction_begin_lsn.

Se a reversão estiver progredindo a uma taxa decente entre cada snapshot, sugerimos que a reversão possa ser concluída sozinha sem reiniciar a instância do SQL Server.

Consulte os seguintes artigos para obter mais informações sobre a recuperação de longa execução:

Status

A Microsoft confirmou que este é um problema nos produtos da Microsoft listados na seção "Aplica-se a".

Referências

Saiba mais sobre a terminologia que a Microsoft usa para descrever atualizações de software.