KB4338890 - CORREÇÃO: erro "Agendador não resultante" e SQL Server aparece sem resposta 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 tem o Microsoft SQL Server 2014, 2016 ou 2017 instalado.  Poderá deparar-se com um ou mais dos seguintes problemas:

  • A instância SQL Server aparece sem resposta e ocorre um erro "Scheduler não-yielding". Poderá ter de reiniciar o servidor para recuperar.
  • A reversão de uma transação pode demorar muito tempo a ser concluída. Na maioria dos casos, reiniciar a instância permitirá que a base de dados recupere muito mais rapidamente do que a reversão. Tenha em atenção que existem muitos motivos pelos quais uma reversão pode demorar muito tempo a ser concluída. Veja a secção "Mais Informações" abaixo para obter detalhes sobre as reversões de monitorização antes de tentar reiniciar.
  • Poderá ver esperas elevadas em spinlocks, como SOS_OBJECT_STORE.

Resolução

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

Atualização Cumulativa 9 para SQL Server 2017

Atualização Cumulativa 2 para SQL Server 2016 SP2

Acerca das atualizações cumulativas para SQL Server:

Cada nova atualização cumulativa para SQL Server contém todas as correções e todas as correções de segurança incluídas na atualização cumulativa anterior. Consulte as atualizações cumulativas mais recentes para 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 para SQL Server 2014

Informações do service pack para SQL Server

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

Service Pack 3 para SQL Server 2014

Acerca dos Service packs para SQL Server:

Os service packs são cumulativos. Cada novo service pack contém todas as correções que estão em service packs anteriores, juntamente com quaisquer correções novas. A nossa recomendação é aplicar o service pack mais recente e a atualização cumulativa mais recente para esse service pack. Não tem de instalar um service pack anterior antes de instalar o service pack mais recente. Utilize a Tabela 1 no artigo seguinte para encontrar mais informações sobre o service pack mais recente e a atualização cumulativa mais recente.

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

Mais Informações

Existem muitas razões pelas quais uma reversão pode demorar muito tempo, como uma transação de execução prolongada, um grande número de VLFs no ficheiro de registo de transações, E/S lenta, etc. Para verificar se o problema descrito neste artigo é a causa de uma reversão lenta, sugerimos que as seguintes técnicas sejam utilizadas para monitorizar o progresso da operação de reversão:

  • A partir de sys.dm_exec_requests, identifique o session_id cujo comando está definido como "KILLED/ROLLBACK" e certifique-se de que a sessão está a acumular tempo de E/S e CPU que indica o progresso. Se a E/S não estiver a ser alterada, poderá ser uma indicação de que está a deparar-se com o problema descrito neste artigo.
  • Consulte sys.dm_tran_database_transactions para identificar o estado atual da reversão com uma consulta como a seguinte:

Nota

  • SELECT 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)
  • FROM sys.dm_tran_database_transactions t
  • JOIN sys.dm_exec_requests s
       ON t.transaction_id=s.transaction_id
  • WHERE t.database_id=db_id('<Nome da Base de Dados') e s.session_id=<Session_id a executar a operação> de reversão

Nota:

Na consulta acima,

database_transaction_next_undo_lsn é o LSN do próximo registo a anular. database_transaction_begin_lsn é o LSN do registo de início da transação no registo de transações.

database_transaction_next_undo_lsn deve diminuir com cada instantâneo desta 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 num intervalo predeterminado e, em seguida, utilizar o delta dos LSNs processados em database_transaction_next_undo_lsn dentro desse intervalo e extrapolar o tempo necessário para estimar o tempo que a database_transaction_next_undo_lsn demorará a chegar ao database_transaction_begin_lsn.

Se a reversão estiver a progredir a um ritmo decente entre cada instantâneo, sugerimos que a reversão seja permitida sem reiniciar a instância SQL Server.

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

Estado

A Microsoft confirmou que se trata de um problema nos produtos Microsoft listados na secção "Aplica-se a".

Referências

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