CORREÇÃO: erro de "não respondendo no Agendador" e SQL Server parece não responder no SQL Server de 2014, 2016 e 2017

Aplica-se a: SQL Server 2016 DeveloperSQL Server 2016 EnterpriseSQL Server 2016 Enterprise Core

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 "não respondendo no Agendador". Você terá que reiniciar o servidor para recuperar.
  • Reversão de uma transação pode levar muito tempo para ser concluída. Na maioria dos casos a reiniciar a instância permitirá que o banco de dados recuperar muito mais rapidamente que a reversão. Observe que há vários motivos para que uma reversão pode levar muito tempo para ser concluído, consulte a seção "Mais informações" abaixo para obter detalhes sobre como monitorar reversões antes de tentar reiniciar.
  • Você pode ver altas esperas em spinlocks como SOS_OBJECT_STORE.

Resolução


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

       Atualização cumulativa 9 para o SQL Server 2017

       Atualização cumulativa 2 para SQL Server 2016 SP2

Informações do service pack para SQL Server

Esta atualização foi corrigida no service pack seguinte do SQL Server:

Service Pack 3 para o SQL Server de 2014

Informações adicionais


Há várias razões por que uma reversão pode levar muito tempo, como uma transação de longa duração, um grande número de VLFs no arquivo de log de transação, lenta e/s etc.  Para verificar se o problema descrito neste artigo é a causa de uma reversão lenta, sugerimos que as técnicas a seguir seja usado para monitorar o progresso da operação de reversão:

  • De sys.dm_exec_requests, identifica o session_id cujo comando é definida como "KILLED/REVERTER" e certifique-se de que a sessão é acumular tempo de CPU e de i / indicando o progresso. Se a e/s não seja alterado, ele pode ser uma indicação de que você está encontrando o problema descrito neste artigo.
  • Consulta sys.dm_tran_database_transactions para identificar o estado atual da reversão usando uma consulta semelhante ao seguinte:
​ ​

Selecione getdate() como 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 t, sys.dm_tran_database_transactions

ENTRAR em sys.dm_exec_requests s   EM t.transaction_id=s.transaction_id

ONDE t.database_id=db_id ('<Nome do banco de dados') e s.session_id= <Session_id para executar a operação de reversão >

Observação:

Na consulta acima,

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

database_transaction_next_undo_lsn deve diminuir com cada instantâneo desta consulta. Reversão será concluído com êxito quando o database_transaction_next_undo_lsn atinge database_transaction_begin_lsn.

O objetivo aqui é obter alguns instantâneos da consulta anterior dentro de um intervalo predeterminado e usar o delta dos LSNs processados em database_transaction_next_undo_lsn dentro desse intervalo e extrapolar o tempo necessário para estimar o tempo necessário para a database_transaction_next_undo_lsn alcançar a database_transaction_begin_lsn.

Se a reversão estiver em andamento em uma taxa razoável entre cada snapshot, sugerimos que a reversão poderá concluir por conta própria, sem reiniciar a instância do SQL Server.

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

Status


A Microsoft confirmou que este é um problema nos produtos Microsoft listados na seção "Aplicável a".

Referências


Saiba mais sobre a terminologia usada pela Microsoft para descrever as atualizações de software.