Artigo
04/01/2012

Fatores que podem atrasar o truncamento de log

O truncamento de log libera espaço no arquivo de log para ser reutilizado pelo log de transações. Como a parte ativa do log não pode ser truncada nem removida por redução, o truncamento pode ser atrasado quando os registros de log permanecerem ativos por muito tempo.

Observação
Para obter informações sobre o funcionamento do truncamento de log, consulte Truncamento de log de transações.

Os registros de log podem permanecer ativos em várias condições, descritas neste tópico. E possível descobrir se, de fato, há algo impedindo o truncamento de log usando as colunas log_reuse_wait e log_reuse_wait_desc da exibição do catálogo sys.databases.

Observação
Alguns desses fatores, como uma transação de longa execução ou uma sessão de espelhamento de banco de dados pausada, podem preencher o log de transações. Para obter informações sobre como responder a um log de transações completo, consulte Solucionando problemas em um log de transação completa (Erro 9002).

A tabela a seguir descreve brevemente os valores das colunas log_reuse_wait e log_reuse_wait_desc da exibição do catálogo sys.database.

Valor log_reuse_wait	Valor log_reuse_wait_desc	Descrição
0	NOTHING	Atualmente há um ou mais arquivos de log virtuais reutilizáveis.
1	CHECKPOINT	Não aconteceu nenhum ponto de verificação desde o último truncamento de log, ou o início do log ainda não foi movido para fora de um arquivo de log virtual (todos os modelos de recuperação). Essa é uma razão rotineira para atrasar o truncamento de log. Para obter mais informações, consulte Pontos de verificação e a parte ativa do log.
2	LOG_BACKUP	É necessário um backup de log para avançar para o início do log (apenas modelos de recuperação completa ou com log de operações em massa). Observação Os backups de log não evitam o truncamento. Quando o backup de log é concluído, o cabeçalho do log é movido para frente e parte do espaço do log poder se tornar reutilizável.
3	ACTIVE_BACKUP_OR_RESTORE	Um backup de dados ou uma restauração está em andamento (todos os modelos de recuperação). Um backup de dados funciona como uma transação ativa e, quando está em execução, o backup evita o truncamento. Para obter mais informações, consulte "Operações de backup de dados e operações de restauração", mais adiante neste tópico.
4	ACTIVE_TRANSACTION	Uma transação está ativa (todos os modelos de recuperação). É possível haver uma transação de longa execução no início do backup de log. Nesse caso, a liberação de espaço pode exigir outro backup de log. Para obter mais informações, consulte "Transações ativas de longa execução", mais adiante neste tópico. Uma transação é adiada (apenas o SQL Server 2005 Enterprise Edition e versões posteriores). Uma transação adiada é efetivamente uma transação ativa cuja reversão é bloqueada por causa de algum recurso indisponível. Para obter informações sobre as causas de transações adiadas e como fazer com que elas saiam do estado adiado, consulte Transações adiadas.
5	DATABASE_MIRRORING	O espelhamento de banco de dados está pausado, ou em um modo de alto desempenho, o banco de dados espelho fica significativamente atrás do banco de dados principal (apenas modelo de recuperação completa). Para obter mais informações, consulte "Espelhamento de banco de dados e log de transações", mais adiante neste tópico.
6	REPLICATION	Durante as replicações transacionais, as transações relevantes para as publicações ainda não foram entregues no banco de dados de distribuição (apenas modelo de recuperação completa). Para obter mais informações, consulte "Replicação transacional e log de transações", mais adiante neste tópico.
7	DATABASE_SNAPSHOT_CREATION	Um instantâneo do banco de dados está sendo criado (todos os modelos de recuperação). Esse é um motivo rotineiro e, normalmente breve, de truncamento de log atrasado.
8	LOG_SCAN	Está acontecendo uma verificação do log (todos os modelos de recuperação). Esse é um motivo rotineiro e, normalmente breve, de truncamento de log atrasado.
9	OTHER_TRANSIENT	Esse valor não é usado atualmente.

Operações de backup de dados e operações de restauração

O truncamento de log não pode acontecer durante nenhuma operação de backup nem restauração. No SQL Server 2005 e versões posteriores, podem acontecer backups de log durante um backup de dados. No entanto, não acontece o truncamento de log durante os backups de log, pois todos os logs de transações devem continuar disponíveis para a operação de backup de dados. Se um backup de dados estiver evitando o truncamento de log, o cancelamento do backup pode ajudar a solucionar o problema imediatamente.

Para obter mais informações sobre truncamento de log, consulte Truncamento de log de transações.

Transações ativas de longa execução

Uma transação ativa requer que o log permaneça ativo desde o registro de log que contém o início da transação. Por exemplo, se o início e o término de uma transação forem controlados pelo usuário, uma causa típica de uma transação de longa execução será um usuário iniciar uma transação e sair enquanto a transação espera por uma resposta dele. Nesses casos, embora a transação em espera gere um log muito pequeno, a transação retém o truncamento de log e faz com que o log aumente bastante.

Observação
Para obter informações sobre como evitar transações de longa execução, consulte Codificando transações eficientes.

Espelhamento de banco de dados e log de transações

O espelhamento de banco de dados requer que cada registro permaneça ativo até que a instância do servidor principal receba uma notificação da instância do servidor espelho de que o registro foi gravado no disco no servidor espelho. Se a instância do servidor espelho ficar atrás da instância do servidor principal, a quantidade de espaço de log ativo aumentará adequadamente. Nesse caso, talvez você precise interromper o espelhamento de banco de dados, fazer um backup de log que trunca o log, aplicar o backup de log no banco de dados espelho (usando WITH NORECOVERY) e reiniciar o espelhamento.

Importante
Além disso, antes de começar o espelhamento, se algum backup de log adicional for feito depois do backup de log exigido, você também deverá aplicar manualmente cada backup de log adicional (sempre usando WITH NORECOVERY). Depois de aplicar o último backup de log, você poderá iniciar o espelhamento.

Para obter mais informações, consulte Removendo o espelhamento de banco de dados e Configurando espelhamento de banco de dados.

Replicação transacional e log de transações

A replicação de mesclagem e a replicação de instantâneo não afetam o tamanho do log de transações, mas uma replicação transacional sim. Se um banco de dados incluir uma ou mais publicações transacionais, o log não será truncado até que todas as transações relevantes para as publicações sejam enviadas ao banco de dados de distribuição. Se o log de transações estiver aumentando demais, e o Log Reader Agent estiver em execução com agendamento definido, considere encurtar o intervalo entre as execuções ou definir a execução em modo contínuo. Se ele estiver definido para executar em modo contínuo (o padrão), assegure que ele esteja em execução. Para obter mais informações sobre como verificar o status do Log Reader Agent, consulte Como exibir informações e executar tarefas para os agentes associados com uma publicação (Replication Monitor).

Além disso, se você tiver definido a opção 'sync with backup' no banco de dados de publicação ou no banco de dados de distribuição, o log de transações não será truncado até ser feito o backup de todas as transações. Se o log de transações estiver crescendo demais, e você tiver essa opção definida, considere encurtar o intervalo entre backups de log de transações. Para obter mais informações sobre como fazer o backup e restaurar bancos de dados envolvidos em replicação transacional, consulte Estratégias para fazer backup e restaurar o instantâneo e a replicação transacional.

Para gerenciar a replicação