Sintomas
Assuma que utiliza a funcionalidade AlwaysOn Availability Groups no Microsoft SQL Server 2012. Quando altera o acesso à ligação da réplica secundária de "legível" para "ilegível", ocorre uma corrupção em páginas que utilizam a compressão da página na réplicadada.As bases de dados de disponibilidade que experimentam este problema na réplica secundária não podem recuperar devido a um erro durante a fase de redo de sincronização. A réplica secundária não sincronizará com a réplica primária, e relata um estado de sincronização de "SUSPEND_FROM_REDO". Além disso, recebe as seguintes mensagens de erro no registo de erro do SQL Server que acolhe a réplica secundária:
<Data> <Hora> espiado<ID> Erro: 17066, Gravidade: 16, Estado: 1.<Data> <Hora> espiado> <0 ID> afirmação do servidor SQL: Arquivo: <página.cpp>, linha=3898 Falhado = 'Afirmação!'. Este erro pode estar relacionado com o tempo. Se o erro persistir após a repetição da declaração, utilize o DBCC CHECKDB para verificar se existe integridade estrutural na base de dados, ou reiniciar o servidor para garantir que as estruturas de dados na memória não são corrompidas.<Data> <Tempo> espiado<ID> Erro: 3624, Severidade: 20, Estado: 1.<Data> <Tempo>>> <0 verificação > de afirmação do sistema falhou. Verifique o registo de erros do SQL Server para obter mais detalhes. Normalmente, uma falha de afirmação é causada por um bug de software ou corrupção de dados. Para verificar se existe corrupção na base de dados, considere executar o DBCC CHECKDB. Se concordar em enviar despejos para a Microsoft durante a configuração, será enviada uma mini lixeira para a Microsoft. Uma atualização pode estar disponível da Microsoft no mais recente Pack de Serviços ou num QFE de Suporte Técnico. <Data> <Hora> espiado<ID> AlwaysOn Availability Groups o movimento de dados para base de dados '<DataBase Name>' foi suspenso pelo seguinte motivo: "system" (Source ID 2; Cadeia de origem: 'SUSPEND_FROM_REDO'). Para retomar o movimento de dados na base de dados, terá de retomar a base de dados manualmente. Para obter informações sobre como retomar uma base de dados de disponibilidade, consulte SQL Server Books Online.<Date> <Time> espiado<ID> Error: 3313, Severidade: 21, Estado: 2.<Data> <Tempo> espiado> <0 > Durante a reformulação de uma operação registada na base de dados '<DataBase Name>', ocorreu um erro no registo de registo de identificação (1786:4978584:74). Normalmente, a falha específica é previamente registada como um erro no serviço De Registo de Eventos do Windows. Restaurar a base de dados a partir de uma cópia de segurança completa, ou reparar o ponto <de> <de data> <> espiado<> opção ALTER DB param: RESUME<Data> <Hora> espiado> <0 ID> Grupos de Disponibilidade AlwaysOn Para Sempre Grupos de Base de Dados '<Data Base>' foi retomado. Esta é apenas uma mensagem informativa. Nenhuma ação do utilizador é necessária.<Data> <Tempo> espiada<ID> as transações não qualificadas estão a ser retransmissíveis na base de dados <DataBase Name> para uma alteração do estado dos Grupos de Disponibilidade AlwaysOn. Conclusão de reversão estimada: 100%. Esta é apenas uma mensagem informativa. Nenhuma ação do utilizador é necessária.<Data> <Hora> spid<ID> AlwaysOn Availability Groups com base de dados primária terminada para base de dados secundária '<DataBase Name>' na réplica de disponibilidade com Replica ID: {bbdedecb-f26b-47e9-9e7d-7c22f99bed23}. Esta é apenas uma mensagem informativa. Nenhuma ação do utilizador é necessária.<Data> <Hora> espiada<ID> Base de dados '<Data Base Nome>'.<Data> <Time> espiado> <2 ID> A recuperação da base de dados '<DataBase Name>' (13) está 0% completa (restam cerca de 781 segundos). Fase 1 de 3. Esta é apenas uma mensagem informativa. Não é necessária qualquer ação do utilizador.......
Resolução
O problema foi corrigido pela primeira vez na seguinte atualização cumulativa do SQL Server.
Atualização Cumulativa 6 para SQL Server 2012 SP2 Atualização Cumulativa 16 para SQL Server 2012 SP1
Cada nova atualização cumulativa do SQL Server contém todos os hotfixes e todas as correções de segurança que foram incluídas com a atualização cumulativa anterior. Confira as últimas atualizações cumulativas do SQL Server:
Mais Informações
A emissão anterior pode ocorrer quando o acesso de leitura for alterado para a réplica secundária. Pode definir as bases de dados de acesso à leitura da disponibilidade na réplica secundária utilizando os seguintes dois métodos:
-
Desajuste o acesso de leitura utilizando o comando ALTER AVAILABILITY GROUP:
ALTER AVAILABILITY GROUP [AGName]MODIFY REPLICA ON N'<SRV>' WITH (SECONDARY_ROLE(ALLOW_CONNECTIONS = NO))
-
Defina o acesso de leitura alterando as definições no Object Explorer do SQL Server Management Studio (SSMS):
-
Ligue ao servidor e, em seguida, abra a pasta Disponibilidade AlwaysOn.
-
Abra a pasta Grupos de Disponibilidade.
-
Clique com o botão direito no grupo de disponibilidade e selecione Propriedades.
-
Altere a propriedade Secundária legível para a réplica secundária para Nº, e, em seguida, clique em Ok.
-
Estado
A Microsoft confirmou que este problema ocorre nos produtos da Microsoft listados na secção "Aplica-se a".
