Sintomas
Considere o seguinte cenário:
-
Você está executando o Microsoft SQL Server 2014 ou o Microsoft SQL Server 2012 Service Pack 2 (SP2) em um servidor que hospeda a réplica secundária de um grupo de disponibilidade como parte de uma atualização sem interrupção.
-
Você aplicou uma das seguintes atualizações à instalação do SQL Server:
-
Atualização cumulativa 5 do SQL Server 2014
-
Atualização cumulativa 4 do SQL Server 2012 Service Pack 2
-
Atualização cumulativa 3 do SQL Server 2012 Service Pack 2
Importante O hotfix mencionado neste artigo substitui essas atualizações cumulativas. Não instale essas atualizações se ainda não tiver feito isso.
-
-
Para concluir a instalação da atualização cumulativa, reinicie essa réplica secundária.
-
Você faz failover do grupo de disponibilidade que está fazendo a transição da réplica secundária atualizada para a função principal.
Nesse cenário, você pode enfrentar um ou mais dos seguintes sintomas no servidor que está executando o SQL Server e que agora está hospedando a réplica primária do seu grupo de disponibilidade:
-
As réplicas secundárias são reportadas como "não está SINCRONIZAndo".
-
Ao consultar sys.dm_exec_requests, você observa o bloqueio intermitente de bloqueio entre sessões de usuários e uma sessão cujo comando é relatado como "DB_STARTUP". Você também pode observar o bloqueio entre os comandos Checkpoint e DB_STARTUP .
-
Deadlocks que envolvem a sessão que recuperou um de seus bancos de dados de disponibilidade são relatados no log de erros do SQL Server. Estes registros são semelhantes aos seguintes: <date/time> spid<xx> Recovery is writing a checkpoint in database <dbname/dbid>. This isan informational message only. No user action is required.<date/time> spid<xx> Recovery completed for database <dbname/dbid> in <x> second(s) (analysis<x> ms, redo <x> ms, undo <x> ms.) This is an informational message only. No user action is required.…<date/time> spid<xx> Error: 1205, Severity: 13, State: 28.<date/time> spid<xx> Transaction (Process ID <xx>) was deadlocked on lock resources with anotherprocess and has been chosen as the deadlock victim. Rerun the transaction.
-
Se o seu banco de dados de disponibilidade estiver habilitado para o Microsoft SQL Server Service Broker, as mensagens no seu banco de dados de disponibilidade podem não ser processadas com êxito. Se você iniciar a ferramenta de rastreamento do Profiler e, em seguida, capturar o evento "Broker: Message classificá", o seguinte evento será capturado:
9791, o Broker está desabilitado no banco de dados do remetente
Observação Isso não é um problema sistemático. Você pode ser capaz de aplicar essas atualizações cumulativas em uma configuração do AlwaysOn sem ter problemas. Se você já tiver aplicado essas atualizações cumulativas e não tiver notado esse problema, o seu sistema não será afetado e essas informações não se aplicam a você.
Causa
Esse problema ocorre porque algumas vezes ocorre uma condição de corrida entre os threads do sistema e as conexões do usuário. Isso impede que a lógica de correção da atualização cumulativa obtenha os bloqueios necessários para concluir o processo de atualização.
Resolução
Para solucionar esse problema, aplique o seguinte hotfix em c.o.d. (crítica sob demanda) :
3034679 CORRECry: os grupos de disponibilidade AlwaysOn podem ser reportados como não SINCRONIZAdosImportante Você deve aplicar este hotfix do COD em vez das seguintes atualizações cumulativas:
-
Atualização cumulativa 5 do SQL Server 2014
-
Atualização cumulativa 4 do SQL Server 2012 Service Pack 2
-
Atualização cumulativa 3 do SQL Server 2012 Service Pack 2
Observação Se você já tiver aplicado essas atualizações cumulativas, deverá usar a seguinte solução alternativa para resolver esse problema.
Solução alternativa
Como esse problema é causado pela disputa entre a sessão do usuário e a sessão de atualização nos bancos de dados de disponibilidade enquanto os bancos de dados migram para a função primária, você deve eliminar essa disputa para permitir que os bancos de dados se recuperem desse Estado. Para contornar esse problema, siga estas etapas:
-
Tente os métodos a seguir na ordem especificada.
Método 1: eliminar o acesso ao banco de dadosQuando os bancos de dados estiverem passando pelos sintomas mencionados na seção "sintomas", use uma ou ambas as etapas a seguir, conforme necessário, para eliminar a condição de bloqueio de bloqueio:
-
Query Sys.dm_exec_requests para localizar sessões em que o bloqueio de bloqueio ocorre nos bancos de dados de disponibilidade. Use a instrução Kill para encerrar essas sessões.
-
Desabilite ou interrompa o aplicativo que está acessando os bancos de dados de disponibilidade.
Se o método 1 não resolver o problema, vá para o método 2.
Método 2: reiniciar o servidor de host do SQL ServerQuando o acesso ao aplicativo e o acesso do usuário ainda estiverem desativados, reinicie a instância do SQL Server que hospeda os bancos de dados de disponibilidade afetados. Para fazer isto, siga as seguintes etapas:
-
Desabilitar o failover automático do grupo de disponibilidade.
-
Reinicie a instância afetada do SQL Server que hospeda a réplica primária.
-
Habilite o failover automático do grupo de disponibilidade.
-
-
Depois que os bancos de dados afetados forem recuperados completamente, restabeleça a conectividade do aplicativo e do usuário.
Status
A Microsoft confirmou que este é um problema nos produtos Microsoft listados na seção "Aplicável a".
Referências
Para obter mais informações sobre as atualizações cumulativas que serão afetadas por esse problema, confira os seguintes artigos da base de dados de conhecimento Microsoft:
