Grupos de Disponibilidade AlwaysOn podem ser relatados como não SINCRONIZAR depois de aplicar a CU5 de 2014 do SQL Server, SQL Server 2012 SP2 CU4 ou CU3 de SP2 de 2012 do SQL Server

IMPORTANTE: Este artigo foi traduzido por um sistema de tradução automática (também designado por Machine translation ou MT), não tendo sido portanto revisto ou traduzido por humanos. A Microsoft tem artigos traduzidos por aplicações (MT) e artigos traduzidos por tradutores profissionais. O objectivo é simples: oferecer em Português a totalidade dos artigos existentes na base de dados do suporte. Sabemos no entanto que a tradução automática não é sempre perfeita. Esta pode conter erros de vocabulário, sintaxe ou gramática… erros semelhantes aos que um estrangeiro realiza ao falar em Português. A Microsoft não é responsável por incoerências, erros ou estragos realizados na sequência da utilização dos artigos MT por parte dos nossos clientes. A Microsoft realiza actualizações frequentes ao software de tradução automática (MT). Obrigado.

3033492
Sintomas

Considere o seguinte cenário:
  • Está a executar o Microsoft SQL Server 2014 ou Microsoft SQL Server 2012 Service Pack 2 (SP2) num servidor que aloje réplicas secundária de um grupo de disponibilidade como parte de uma actualização gradual.
  • Aplicou uma das seguintes actualizações para instalação do SQL Server:
    • Actualização cumulativa do SQL Server 2014 5
    • Actualização cumulativa do SQL Server 2012 Service Pack 2 4
    • Actualização cumulativa do SQL Server 2012 Service Pack 2 3
    Importante A correcção mencionada neste artigo substitui estas actualizações cumulativas. Não instale estas actualizações se ainda não tenha este.
  • Para concluir a instalação da actualização cumulativa, reinicie esta réplica secundária.
  • A activação pós-falha do grupo de disponibilidade que está a transitar réplicas secundárias actualizada para o papel principal.
Neste cenário, poderá detectar um ou mais dos seguintes sintomas no servidor que executa o SQL Server e que agora está a alojar a réplica principal do seu grupo de disponibilidade:
  • As réplicas secundárias são reportadas como "Não SINCRONIZAR".
  • Quando efectua uma consulta sys.dm_exec_requests, nota intermitente bloquear bloqueio entre sessões de utilizadores e de uma sessão cujo comando é comunicado como "DB_STARTUP". Também poderá verificar o bloqueio entre os comandos de ponto de verificação e DB_STARTUP .
  • Bloqueios fatais que envolvam a sessão que recuperar uma das bases de dados de disponibilidade são reportados no registo de erros do SQL Server. Estes registos semelhante ao seguinte:

    <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 a base de dados de disponibilidade é activado para Microsoft SQL Server Service Broker, mensagens na sua base de dados de disponibilidade podem não ser processadas com êxito. Se iniciar a ferramenta de rastreio do Profiler e, em seguida, pode captura o evento "Mediador: mensagem classificar", o seguinte evento é capturado:

    9791, o facilitador de está desactivado na base de dados do remetente
Nota Não é um problema sistemático. Poderá aplicar estas actualizações cumulativas de uma configuração de AlwaysOn sem este problema. Se já tiver aplicado estas actualizações cumulativas e não notar este problema, o sistema não é afectado e estas informações não se aplica ao utilizador.
Causa
Este problema ocorre porque uma condição de corrida, por vezes, ocorre entre os threads de sistema e as ligações do utilizador. Isto impede que a aplicação de patch lógica da actualização cumulativa de obter os bloqueios que são necessários para concluir o processo de actualização.
Resolução
Para resolver este problema, aplique o seguinte crítica a pedido (CQO) correcção:

3034679 CORRECÇÃO: Grupos de Disponibilidade AlwaysOn podem ser relatados como não SINCRONIZAR

Importante Tem de aplicar esta correcção de COD em vez das actualizações cumulativas seguintes:
  • Actualização cumulativa do SQL Server 2014 5
  • Actualização cumulativa do SQL Server 2012 Service Pack 2 4
  • Actualização cumulativa do SQL Server 2012 Service Pack 2 3


Nota Se já tiver aplicado estas actualizações cumulativas, tem de utilizar os seguintes trabalhos em redor para resolver este problema.
Como contornar
Uma vez que este problema é causado por contenção entre na sessão de utilizador e a sessão de actualização contra as bases de dados de disponibilidade durante a transição de bases de dados para o papel principal, tem de eliminar este contenção para activar as bases de dados recuperar deste Estado.

Para contornar este problema, siga estes passos:
  1. Tente os seguintes métodos pela ordem especificada.
    Método 1: Eliminar o acesso da base de dados
    Quando as bases de dados detectar os sintomas mencionados na secção "Sintomas", utilize um ou ambos dos seguintes passos conforme necessário para eliminar a condição de bloqueio de bloqueio:
    • Consulta sys.dm_exec_requests Para localizar sessões nas qual bloqueio bloquear ocorre nas bases de dados de disponibilidade. Utilizar o KILL declaração para terminar estas sessões.
    • Desactivar ou parar a aplicação que está a aceder as bases de dados de disponibilidade.

    Se o método 1 não resolver o problema, avance para o método 2.


    Método 2: Reiniciar o servidor de anfitrião do SQL Server
    Quando o acesso a aplicações e de acesso do utilizador ainda estiverem desactivados, reinicie a instância do SQL Server que está a hospedar as bases de dados de disponibilidade afectado. Para tal, siga estes passos:
    1. Desactive a activação pós-falha automática do grupo de disponibilidade.
    2. Reinicie a instância do SQL Server que está a alojar a réplica principal afectada.
    3. Active a activação pós-falha automática do grupo de disponibilidade.
  2. Depois de bases de dados afectadas recuperar completamente, restabelecer a aplicação e ligação do utilizador.
Ponto Da Situação
A Microsoft confirmou que este é um problema nos produtos da Microsoft listados na secção "Aplica-se a".

Referências
Para mais informações sobre as actualizações cumulativas que são afectados por este problema, consulte os seguintes artigos na Microsoft Knowledge Base:

Aviso: Este artigo foi traduzido automaticamente

Propriedades

ID do Artigo: 3033492 - Última Revisão: 11/14/2015 05:55:00 - Revisão: 5.0

  • Microsoft SQL Server 2014 Enterprise
  • Microsoft SQL Server 2014 Developer
  • Microsoft SQL Server 2014 Enterprise Core
  • Microsoft SQL Server 2012 Service Pack 2
  • Microsoft SQL Server 2012 Enterprise
  • Microsoft SQL Server 2012 Developer
  • Microsoft SQL Server 2012 Enterprise Core
  • kbsurveytest kbexpertiseadvanced kbmt KB3033492 KbMtpt
Esta informação foi útil?