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.

Clique aqui para ver a versão em Inglês deste artigo: 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
Comentários