Sintomas
Assuma que utiliza o grupo AlwaysOn Availability numa base de dados Microsoft SQL Server 2012 ou SQL Server 2014, e existe uma grande transação ativa aberta e requer um espaço adicional de registo. Quando o ficheiro de registo não pode crescer por uma das seguintes razões, a transação falha.
-
Falta de espaço adicional de arquivo
-
O ficheiro de log está configurado para não crescer
-
O ficheiro de registo atingiu o seu tamanho máximo configurado
Além disso, recebe a seguinte mensagem de erro:
Erro: 9002, Severidade: 17, Estado: 9.O registo de transações da base de dados "<nome da base de dados>" é completo devido a "LOG_BACKUP".
Depois de executar uma cópia de segurança de registo, recebe outra mensagem de erro 9002:
Erro: 9002, Severidade: 17, Estado: 9.O registo de transações da base de dados '<nome de base de dados>' é completo devido a "ATIVE_TRANSACTION".
Depois de outra cópia de segurança de registo, recebe então outra mensagem de erro 9002 seguida de uma mensagem de erro 5901:
Erro: 9002, Severidade: 17, Estado: 9.O registo de transações da base de dados '<nome da base de dados>' é completo devido a "AVAILABILITY_REPLICA".
Não foi possível escrever um registo de ponto de verificação na base de dados <nome da base de dados> porque o registo está fora do espaço. Contacte o administrador da base de dados para truncar o registo ou alocar mais espaço aos ficheiros de registo de bases de dados. Erro: 5901, Severidade: 16, Estado: 1.1 ou mais unidades de recuperação pertencentes à base de dados "<nome de base de dados>" não geraram um ponto de verificação. Isto é normalmente causado pela falta de recursos do sistema, como o disco ou a memória, ou em alguns casos devido à corrupção na base de dados. Examine as entradas anteriores no registo de erros para obter informações mais detalhadas sobre esta falha.
Quando o controlo de verificação subsequente ou as cópias de segurança de registo forem então tomadas durante a reversão da transação, poderá receber a seguinte mensagem de erro:
Msg 3052, Nível 16, Estado 1, Linha 4BACKUP LOG não foi capaz de registar atualizações para base de dados "<nome da base de dados>". As cópias de segurança subsequentes serão necessárias para adiantar o ponto de backup de '<LSN id 1>' para "<LSN id 2>" depois de o espaço de registo ser disponibilizado para os registar.
Quando recebe estas mensagens, já não pode submeter novas transações à base de dados, não podendo cultivar o ficheiro de registo ou adicionar outro ficheiro de registo.
Resolução
O problema foi corrigido pela primeira vez na seguinte atualização cumulativa do SQL Server:
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. Recomendamos que descarregue e instale as últimas atualizações cumulativas para o SQL Server:
Solução
Pode utilizar a seguinte solução para truncar os registos e retomar a atividade.
-
Verifique cada réplica secundária para verificar se a réplica secundária last_hardened_lsn (ver sys.dm_hadr_database_replica_states)corresponde à réplica primária last_hardened_lsn. Pode fazê-lo executando a seguinte consulta que está ligada à primeira instância de réplica
SELECT ags.name as AGGroupName, ar.replica_server_name as InstanceName, hars.role_desc, db_name(drs.database_id)as DBName, drs.last_hardened_lsn, drs.log_send_queue_size, drs.synchronization_state_desc as SyncState, ar.availability_mode_desc as SyncMode, CASE drs.is_local WHEN 1 THEN drs.database_id ELSE NULL END as database_id FROM sys.dm_hadr_database_replica_states drs LEFT JOIN sys.availability_replicas ar ON drs.replica_id = ar.replica_id LEFT JOIN sys.availability_groups ags ON ar.group_id = ags.group_id LEFT JOIN sys.dm_hadr_availability_replica_states hars ON ar.group_id = hars.group_id and ar.replica_id = hars.replica_id WHERE db_name(drs.database_id) = '<database name>'
-
Na réplica primária
-
Remova a base de dados do grupo de disponibilidade.
-
Voltar a adicionar a base de dados ao grupo de disponibilidade.
-
-
Em cada réplica secundária
-
Voltar a adicionar a base de dados ao grupo de disponibilidade.
-
Ao remover a base de dados do grupo de disponibilidade, truncará imediatamente os seus registos e libertará o espaço de registo. Se a last_hardened_lsn em cada réplica secundária for idêntica à réplica primária, e não forem tomadas cópias de segurança de registo durante o tempo de remoção da base de dados do Grupo Availability e de readição da base de dados em cada secundário, a réplica secundária será adicionada com sucesso sem quaisquer erros ou tendo de restaurar as cópias de segurança de registo no secundário. Se uma réplica secundária não estiver em funcionamento com a réplica primária e tiver de remover a base de dados do grupo de disponibilidade antes que o secundário possa recuperar, essa réplica secundária pode ter de ter cópias de segurança de registo restauradas para a recuperar antes de a adicionar novamente ao grupo de disponibilidade, ou deixar cair a base de dados na réplica secundária e re-seed-la com uma base de dados completa e de registo de transações.
Estado
A Microsoft confirmou que este problema ocorre nos produtos da Microsoft listados na secção "Aplica-se a".
