Sintomas
Suponha que você tenha o Microsoft SQL Server 2014, o 2016 ou o 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 a recuperação.
-
A reversão de uma transação pode levar muito tempo para ser concluída. Na maioria dos casos, a reinicialização da 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 a reversão pode levar muito tempo para ser concluída, confira a seção "mais informações" abaixo para obter detalhes sobre o monitoramento de reversões antes de tentar reiniciar.
-
Você pode ver grandes esperas de spinlocks como SOS_OBJECT_STORE.
Resolução
Este problema foi corrigido nas seguintes atualizações cumulativas do 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 do SQL Server:
Atualização cumulativa mais recente do SQL Server 2017
Informações do Service Pack para SQL Server
Esta atualização foi corrigida no seguinte Service Pack para SQL Server:
Service packs são cumulativos. Cada novo Service Pack contém todas as correções que estão em Service Packs anteriores, juntamente com qualquer nova correção. Nossa recomendação é aplicar o Service Pack mais recente e a atualização cumulativa mais recente para esse Service Pack. Você não precisa instalar um Service Pack anterior antes de instalar o Service Pack mais recente. Use a tabela 1 no artigo a seguir 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 seus componentes
Informações adicionais
Há muitos motivos pelos quais 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çõ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:
-
Em Sys.dm_exec_requests, identifique a session_id cujo comando está definido como "eliminado/reversão" e certifique-se de que a sessão esteja acumulando tanto o tempo de e/s para a CPU indicando o progresso. Se a e/s não for alterada, talvez seja uma indicação de que você está encontrando o problema descrito neste artigo.
-
Query Sys.dm_tran_database_transactions para identificar o estado atual da reversão usando uma consulta como a 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)
DA sys.dm_tran_database_transactions t
INGRESSAr em sys.dm_exec_requests s EM t.transaction_id = s.transaction_id
EM que t.database_id = db_id (' nome do banco de dados<') e s.session_id =<session_id de executar 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ção.
database_transaction_next_undo_lsn deve estar decrescente com cada instantâneo desta consulta. A reversão será concluída com êxito quando o database_transaction_next_undo_lsn alcançar database_transaction_begin_lsn.
O objetivo aqui é levar alguns instantâneos da consulta anterior dentro de um intervalo predeterminado e, em seguida, usar o Delta do LSNs processado em database_transaction_next_undo_lsn dentro desse intervalo e extrapolar o tempo usado para estimar o tempo que levará para que o database_transaction_next_undo_lsn atinja o database_transaction_begin_lsn.
Se a reversão estiver progredindo a uma taxa de custo incompleto entre cada instantâneo, sugerimos que a reversão seja permitida para ser concluída sem reiniciar a instância do SQL Server.
Confira os artigos a seguir para obter mais informações sobre a recuperação de longa execução:
-
Noções básicas sobre o desempenho de recuperação no SQL Server
-
SQL Server (2000, 2005, 2008): a recuperação/Rollback leva mais tempo do que o esperado
-
Como uma estrutura de arquivo de log pode afetar o tempo de recuperação do banco de dados
-
Acompanhar o progresso da recuperação do banco de dados usando informações do DMV
Status
A Microsoft confirmou que este é um problema nos produtos Microsoft listados na seção "Aplicável a".
Referências
Saiba mais sobre a terminologiaque a Microsoft usa para descrever atualizações de software.
