KB3095156 - CORREÇÃO: Erro 9002 e erro 3052 ao tentar adicionar ou fazer backup do arquivo de log no SQL Server 2012 ou SQL Server 2014

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 que exista uma grande transação ativa aberta que exija 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 crescer
• O arquivo de log atingiu o tamanho máximo configurado

Além disso, a seguinte mensagem de erro é exibida:

Depois de executar um backup de log, você recebe outra mensagem de erro 9002:

Após outro backup de log, você receberá outra mensagem de erro 9002 seguida por uma mensagem de erro 5901:

      

Quando os backups subsequentes de ponto de verificação ou log forem feitos durante a reversão da transação, você poderá receber a seguinte mensagem de erro:

Ao receber essas mensagens, você não poderá mais enviar novas transações 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 pela primeira vez na seguinte atualização cumulativa do SQL Server:

• Atualização cumulativa 3 para o SQL Server 2014 SP1
• Atualização cumulativa 10 para o SQL Server 2014
• Atualização cumulativa 8 para o SQL Server 2012 SP2

Recomendação: instalar a atualização cumulativa mais recente para o 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 para o SQL Server:

• Atualização cumulativa mais recente do SQL Server 2014 SP1
• Atualização cumulativa mais recente do SQL Server 2014
• Atualização cumulativa mais recente do SQL Server 2012 SP2

      

Solução alternativa

Você pode usar a solução alternativa a seguir para truncar os logs e retomar a atividade.

1. Verifique cada réplica secundário para verificar se o réplica last_hardened_lsn secundário (consulte sys.dm_hadr_database_replica_states) corresponde ao réplica last_hardened_lsn primário. Você pode fazer isso executando a seguinte consulta 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>'
   

2. Na réplica primária

   • Remova o banco de dados do grupo de disponibilidade.
   • Adicione novamente o banco de dados ao grupo de disponibilidade.

3. 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 o last_hardened_lsn em cada réplica secundário for idêntico ao réplica primário e nenhum backup de log for feito durante o tempo de remoção do banco de dados do Grupo de Disponibilidade e adição novamente do banco de dados em cada secundário, o réplica secundário será adicionado novamente com êxito sem erros ou sem ter que restaurar backups de log no secundário.

Se uma réplica secundária não estiver atualizada com a réplica primária e você precisar remover o banco de dados do grupo de disponibilidade antes que o secundário possa alcançá-lo, essa réplica secundária talvez precise ter backups de log restaurados para atualizá-la antes de adicioná-la novamente ao grupo de disponibilidade ou descartar o banco de dados na réplica secundária e propague novamente com um backup completo do banco de dados de log de transações.

Status

A Microsoft confirmou que este é um problema nos produtos da Microsoft listados na seção "Aplica-se a".