Sintomas
Suponha que você use o grupo de disponibilidade AlwaysOn em um banco de dados do Microsoft SQL Server 2012 ou do SQL Server 2014, e uma grande transação ativa aberta existe e requer espaço de log adicional. Quando o arquivo de log não pode crescer por um dos seguintes motivos, a transação falha.
-
Falta de espaço adicional no arquivo
-
O arquivo de log está configurado para não aumentar
-
O arquivo de log atingiu seu tamanho máximo configurado
Além disso, a seguinte mensagem de erro é exibida:
Erro: 9002, severidade: 17, estado: 9. o log de transação do banco de dados ' nome do banco de dados ' <banco de dados '> ' está cheio devido a ' LOG_BACKUP '.
Depois de executar um backup de log, você recebe outra mensagem de erro do 9002:
Erro: 9002, severidade: 17, estado: 9. o log de transação do banco de dados ' nome do banco de dados ' <banco de dados '> ' está cheio devido a ' ACTIVE_TRANSACTION '.
Depois de outro backup de log, você recebe outra mensagem de erro do 9002 seguida de uma mensagem de erro do 5901:
Erro: 9002, severidade: 17, estado: 9. o log de transação do banco de dados ' nome do banco de dados ' <banco de dados '> ' está cheio devido a ' AVAILABILITY_REPLICA '.
Não foi possível gravar um registro de ponto de verificação no banco de dados <o nome do banco de dados> porque o log está sem espaço. Entre em contato com o administrador do banco de dados para truncar o log ou atribuir mais espaço aos arquivos de log do banco de dados. Erro: 5901, severidade: 16, estado: 1. uma ou mais unidades de recuperação pertencentes ao banco de dados ' <nome do banco de dados> ' falhou ao gerar um ponto de verificação. Isso geralmente é causado por falta de recursos do sistema, como disco ou memória, ou em alguns casos devido à corrupção do banco de dados. Examine as entradas anteriores no log de erros para obter informações mais detalhadas sobre essa falha.
Quando o ponto de verificação ou backups de log subsequentes são feitos durante a reversão da transação, você pode receber a seguinte mensagem de erro:
MSG 3052, nível 16, estado 1, linha 4BACKUP LOG não pôde registrar atualizações para o banco de dados ' <nome do banco de dados> '. Os backups de log subsequentes serão necessários para avançar o ponto de backup de ' <LSN ID 1> ' para ' <lsn ID 2> ' após o espaço do log ser disponibilizado para o registro em log.
Quando você receber essas mensagens, não será mais possível enviar nenhuma nova transação para o banco de dados e não poderá aumentar o arquivo de log ou adicionar outro arquivo de log.
Resolução
O problema foi corrigido primeiro 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 incluídas na atualização cumulativa anterior. Recomendamos que você baixe e instale as atualizações cumulativas mais recentes do SQL Server:
Solução alternativa
Você pode usar a seguinte solução alternativa para truncar os logs e atividades de retomada.
-
Verifique cada réplica secundária para verificar se a réplica secundária last_hardened_lsn (consulte Sys.dm_hadr_database_replica_states) corresponde à réplica primária last_hardened_lsn. Você pode fazer isso executando a seguinte consulta que está conectada à instância de réplica primária
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 o banco de dados do grupo de disponibilidade.
-
Adicione novamente o banco de dados ao grupo de disponibilidade.
-
-
Em cada réplica secundária
-
Adicione novamente o banco de dados ao grupo de disponibilidade.
-
Ao remover o banco de dados do grupo de disponibilidade, ele truncará imediatamente seus logs e liberará espaço de log. Se a last_hardened_lsn em cada réplica secundária for idêntica à réplica primária e não houver backups de log durante a hora de remover o banco de dados do grupo de disponibilidade e adicionar novamente o banco de dados em cada secundário, a réplica secundária será readicionada com êxito sem erros ou com a necessidade de restaurar os backups de log no secundário. Se uma réplica secundária não for atual com a réplica primária e você tiver que remover o banco de dados do grupo de disponibilidade antes que o secundário possa ficar em dia, essa réplica secundária pode ter que fazer backups de log restaurados para que ele seja recriado com um backup completo e de banco de dados de log de transações.
Status
A Microsoft confirmou que este é um problema nos produtos Microsoft listados na seção "Aplicável a".
