O log de transações

Aplica-se:SQL Server

Todo banco de dados do SQL Server tem um log de transações que registra todas as transações e as modificações feitas no banco de dados por cada transação.

O log de transações é um componente crítico do banco de dados. Se houver uma falha no sistema, você precisará desse log para trazer seu banco de dados de volta a um estado consistente.

Aviso

Nunca exclua ou mova esse log, a menos que você compreenda totalmente as implicações de fazer isso.

Para obter informações sobre a arquitetura física e lógica do log de transações, consulte o guia de arquitetura e gerenciamento do log de transações do SQL Server.

Dica

Os pontos de verificação criam pontos confiáveis a partir dos quais se começa a aplicar os logs de transação durante a recuperação do banco de dados. Para obter mais informações, consulte Pontos de verificação de banco de dados (SQL Server).

Operações com suporte pelo log de transações

O log de transações dá suporte às seguintes operações:

  • Recuperação de transações individuais.
  • Recuperação de todas as transações incompletas durante a inicialização do SQL Server.
  • Rolando um banco de dados restaurado, arquivo, grupo de arquivo ou página até ao ponto de falha.
  • Suporte à replicação transacional.
  • Dando suporte a soluções de alta disponibilidade e recuperação de desastre: grupos de disponibilidade AlwaysOn, espelhamento de banco de dados e envio de logs.

Recuperação de transações individuais

Se um aplicativo emitir uma instrução ROLLBACK ou se o Mecanismo de Banco de Dados detectar um erro como a perda de comunicação com um cliente, os registros de log serão usados para reverter as modificações feitas por uma transação incompleta.

Recuperação de todas as transações incompletas durante a inicialização do SQL Server

Se um servidor falhar, os bancos de dados poderão ser deixados em um estado em que algumas modificações nunca foram gravadas do cache de buffer para os arquivos de dados e poderá haver algumas modificações de transações incompletas nos arquivos de dados. Quando uma instância do SQL Server é iniciada, ele executa uma recuperação de cada banco de dados. Toda modificação registrada no log que possa não ter sido gravada nos arquivos de dados é reaplicada. Toda transação incompleta encontrada no log de transações é revertida para assegurar que a integridade do banco de dados seja preservada. Para obter mais informações, consulte a visão geral de restauração e recuperação (SQL Server).

Avançar um banco de dados, arquivo, grupo de arquivos ou página restaurado até o ponto de falha

Depois de uma perda de hardware ou falha de disco que afeta os arquivos de banco de dados, você pode restaurar o banco de dados ao ponto de falha. Você primeiro restaura o último backup completo do banco de dados e o último backup diferencial do banco de dados e, depois, restaura a sequência subsequente de backups do log de transações até o ponto da falha.

Ao restaurar cada backup do log de transações, o Mecanismo de Banco de Dados reaplica todas as modificações registradas no log para avançar todas as transações. Quando o último backup de log é restaurado, o Mecanismo de Banco de Dados usa as informações de log para reverter todas as transações que não estavam completas naquele ponto. Para obter mais informações, consulte a visão geral de restauração e recuperação (SQL Server).

Suporte à replicação transacional

O Agente Leitor de Log monitora o log de transações de cada banco de dados configurado para a replicação transacional e copia as transações marcadas para replicação do log de transações para o banco de dados de distribuição. Para obter mais informações, consulte Como funciona a replicação transacional.

Suporte a soluções de alta disponibilidade e recuperação de desastres

As soluções de servidor em espera, os grupos de disponibilidade Always On, o espelhamento de banco de dados e o transporte de logs dependem fortemente do log de transações.

Em um cenário de grupos de disponibilidade Always On, cada atualização de um banco de dados na réplica primária é imediatamente replicada nas cópias separadas do banco de dados em todas as réplicas secundárias. A réplica primária envia imediatamente cada registro de log para as réplicas secundárias, que aplicam os registros de log recebidos aos bancos de dados de disponibilidade, avançando continuamente o log. Para obter mais informações, consulte Instâncias de cluster de failover Always On (SQL Server).

Em um cenário de envio de logs, o servidor primário envia os backups de log de transações do banco de dados primário para um ou mais destinos. Cada servidor secundário restaura o backup de log a seu banco de dados secundário local. Para obter mais informações, consulte Sobre o envio de logs (SQL Server).

Em um cenário de espelhamento de banco de dados, cada atualização de um banco de dados, o banco de dados principal, é imediatamente reproduzida em uma cópia completa e separada do banco de dados, o banco de dados espelho. A instância do servidor principal envia imediatamente cada registro de log para a instância do servidor espelho, que aplica os registros de log recebidos ao banco de dados espelho, mantendo-o continuamente atualizado. Para obter mais informações, consulte Espelhamento de banco de dados (SQL Server).

Características de log de transações

Características do log de transações do Mecanismo de Banco de Dados do SQL Server:

  • O log de transações é implementado como um arquivo separado ou conjunto de arquivos no banco de dados. O cache de log é gerenciado separadamente do cache de buffer para páginas de dados. Essa separação resulta em um código simples, rápido e robusto no Mecanismo de Banco de Dados do SQL Server. Para obter mais informações, consulte a arquitetura física do log de transações.

  • O formato de registros de log e páginas não precisa seguir o formato das páginas de dados.

  • O log de transações pode ser implementado em vários arquivos. Você pode configurar os arquivos para expandir automaticamente definindo o FILEGROWTH valor para o log. Essa configuração reduz o potencial de ficar sem espaço no log de transações, ao mesmo tempo em que reduz a sobrecarga administrativa. Para obter mais informações, consulte ALTER DATABASE (Transact-SQL) opções de arquivo e grupo de arquivos.

  • O mecanismo para reutilizar o espaço dentro dos arquivos de log é rápido e tem efeito mínimo em taxa de transferência de transações.

Para obter informações sobre a arquitetura física e lógica do log de transações, consulte o guia de arquitetura e gerenciamento do log de transações do SQL Server.

Truncamento do log de transações

O truncamento de log libera espaço no arquivo de log para ser reutilizado pelo log de transações. É necessário truncar regularmente o log de transações para evitar que ele ocupe todo o espaço alocado. Vários fatores podem atrasar o truncamento de log, portanto, o monitoramento do tamanho do log é importante. Algumas operações podem ser minimamente registradas para reduzir seu efeito no tamanho do log de transações.

O truncamento de log exclui VLFs (arquivos de log virtuais) inativos do log de transações lógicas de um banco de dados do SQL Server, liberando espaço no log lógico para reutilização pelo log de transações físicas. Se um log de transações nunca for truncado, acabará ocupando todo o espaço em disco alocado para os arquivos de log físico.

Para evitar ficar sem espaço, a menos que o truncamento do log seja adiado por algum motivo, o truncamento ocorrerá automaticamente após os seguintes eventos:

  • No modelo de recuperação simples, depois de um ponto de verificação.

  • No modelo de recuperação completa ou no modelo de recuperação com registro em massa, se tiver ocorrido um ponto de verificação desde o backup de log anterior, o truncamento ocorrerá após um backup de log (a menos que seja um backup de log somente cópia).

  • Quando você cria pela primeira vez um banco de dados que usa o modelo de recuperação completa, o log de transações é reutilizado conforme necessário (semelhante a um banco de dados usando o modelo de recuperação simples), até o momento em que você cria um backup de banco de dados completo.

Para obter mais informações, consulte Fatores que podem atrasar o truncamento do log mais adiante neste artigo.

O truncamento de log não reduz o tamanho do arquivo de log físico. Para reduzir o tamanho físico de um arquivo de log, você deve reduzir esse arquivo de log. Para obter informações sobre como encolher o tamanho do arquivo de log físico, consulte Gerenciar o tamanho do arquivo de log de transações. No entanto, tenha em mente fatores que podem atrasar o truncamento de log. Se o espaço de armazenamento voltar a ser necessário após um encolhimento do log, o log de transações crescerá novamente e isso causará sobrecarga de desempenho durante as operações de crescimento do log.

Fatores que podem atrasar o truncamento do log

Quando os registros de log permanecem ativos por muito tempo, o truncamento do log de transações é retardado, e o log de transações pode ficar cheio, conforme descrito anteriormente neste artigo.

Importante

Para obter informações sobre como responder a um log de transações completo, consulte Solucionar problemas de um log de transações completo (erro 9002 do SQL Server).

O truncamento de log pode ser adiado por vários motivos. Para saber o que está impedindo o truncamento de log, consulte as colunas log_reuse_wait e log_reuse_wait_desc da exibição de catálogo sys.databases. A tabela a seguir descreve os valores dessas colunas.

Valor de log_reuse_wait Valor de log_reuse_wait_desc Descrição
0 NOTHING Atualmente, há um ou mais VLFs (arquivos de log virtual) reutilizáveis.
1 CHECKPOINT Nenhum ponto de verificação ocorreu desde o último truncamento de log ou o cabeçalho do log ainda não foi movido além de um VLF (arquivo de log virtual). (Todos os modelos de recuperação.)

Esse cenário é um motivo rotineiro para atrasar o truncamento do log. Para obter mais informações, consulte Pontos de verificação de banco de dados (SQL Server).
2 LOG_BACKUP Um backup do log é necessário antes que o log de transações possa ser truncado. (Somente modelos de recuperação completos ou de registro em massa.)

Quando o próximo backup de log for concluído, parte do espaço de log pode 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.)

Se um backup de dados estiver impedindo o truncamento do log, cancelar a operação de backup pode ajudar a resolver o problema imediato.
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, liberar espaço pode exigir outro backup de log. Transações de longa duração impedem o truncamento do log em todos os modelos de recuperação, incluindo o modelo de recuperação simples, no qual o log de transações geralmente é truncado em cada ponto de verificação automático.

Uma transação é adiada. 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 das transações adiadas e como movê-las para fora do estado adiado, consulte Transações adiadas (SQL Server).

Transações demoradas também podem preencher o log de transações do tempdb. tempdb é usado implicitamente por transações de usuário para objetos internos, como tabelas de trabalho para ordenação, arquivos de trabalho para hash, tabelas de trabalho de cursor e controle de versão de linhas. Mesmo que a transação do usuário inclua apenas leituras de dados (consultas SELECT), objetos internos podem ser criados e usados no âmbito de transações do usuário. Então, o tempdb log de transações pode ser preenchido.
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. (Somente modelo de recuperação completa.)

Para obter mais informações, consulte Espelhamento de banco de dados (SQL Server).
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. (Somente modelo de recuperação completa.)

Para obter informações sobre replicação transacional, consulte a replicação do SQL Server.
7 DATABASE_SNAPSHOT_CREATION Um instantâneo do banco de dados está sendo criado. (Todos os modelos de recuperação.)

Esta é uma causa rotineira e tipicamente breve de atraso no truncamento do log.
8 LOG_SCAN Uma verificação de logs está em andamento. (Todos os modelos de recuperação.)

Essa é uma causa rotineira e, em geral, breve de atraso no truncamento do log.
9 AVAILABILITY_REPLICA Uma réplica secundária de um grupo de disponibilidade está aplicando registros de log de transações desse banco de dados para um banco de dados secundário correspondente. (Somente modelo de recuperação completa.)

Para obter mais informações, confira O que é um grupo de disponibilidade Always On?.
10 - Somente para uso interno.
11 - Somente para uso interno.
12 - Somente para uso interno.
13 OLDEST_PAGE Se um banco de dados estiver configurado para usar pontos de verificação indiretos, a página mais antiga no banco de dados poderá ser mais antiga do que o LSN (número de sequência de log) do ponto de verificação. Nesse caso, a página mais antiga pode atrasar o truncamento do log. (Todos os modelos de recuperação.)

Para obter informações sobre pontos de verificação indiretos, confira Pontos de verificação do banco de dados (SQL Server).
14 OTHER_TRANSIENT Esse valor não é usado atualmente.
16 XTP_CHECKPOINT É necessário executar um ponto de verificação OLTP in-memory. Para tabelas com otimização de memória, um ponto de verificação automático é feito quando o arquivo de log de transações se torna maior que 1,5 GB desde o último ponto de verificação. (Inclui tabelas baseadas em disco e com otimização de memória.)

Para obter mais informações, consulte Operação de ponto de verificação para tabelas com otimização de memória e Processo de registro em log e de ponto de verificação para tabelas com otimização de memória.

Operações que podem ser minimamente registradas em log

O registro em log mínimo envolve registrar apenas as informações necessárias para recuperar a transação sem dar suporte à recuperação pontual. Este artigo identifica as operações que são minimamente registradas no modelo de recuperação bulk-logged (e também no modelo de recuperação simples, exceto quando um backup está em execução).

O registro mínimo em log não é compatível com tabelas otimizadas para memória.

No modelo de recuperaçãocompleta, todas as operações em massa são completamente registradas. No entanto, você pode minimizar o registro em log de um conjunto de operações em massa alternando temporariamente o banco de dados para o modelo de recuperação bulk-logged durante essas operações. O registro mínimo é mais eficiente do que o registro completo e reduz a possibilidade de uma operação em massa de grande escala preencher o espaço disponível do log de transações durante uma transação em massa. Porém, se o banco de dados for danificado ou perdido quando o log mínimo estiver em vigor, você não poderá recuperar o banco de dados até o momento da falha.

As operações a seguir, que são totalmente registradas no modelo de recuperação completa, são registradas minimamente no modelo de recuperação simples e bulk-logged:

  • Operações de importação em massa (bcp e BULK INSERTINSERT). Para obter mais informações sobre quando a importação em massa para uma tabela é minimamente registrada em log, consulte Pré-requisitos para o registro mínimo em log na importação em massa.

    Quando a replicação transacional é habilitada, as operações BULK INSERT são totalmente registradas em log, mesmo no modelo de recuperação de registro em massa.

  • Operações da cláusula SELECT - INTO.

    Quando a replicação transacional está ativada, as operações SELECT INTO são totalmente registradas em log mesmo no modelo de recuperação com log em massa.

  • Atualizações parciais em tipos de dados de valor longo, usando a cláusula .WRITE na instrução UPDATE ao inserir ou anexar novos dados. A criação mínima de log não é usada quando valores existentes são atualizados. Para obter mais informações sobre tipos de dados de valores grandes, confira Tipos de dados.

  • Instruções WRITETEXT e UPDATETEXT ao inserir ou anexar novos dados nas colunas do tipo de dados text, ntext e image. A criação mínima de log não é usada quando valores existentes são atualizados.

    Aviso

    As instruções WRITETEXT e UPDATETEXT estão obsoletas. Evite usá-los em novos aplicativos.

  • Se o banco de dados estiver configurado para o modelo de recuperação simples ou bulk-logged, algumas operações DDL de índice são registradas minimamente, independentemente de a operação ser executada offline ou online. As operações de índice minimamente registradas são:

    • CREATE INDEX operações (incluindo exibições indexadas).

    • ALTER INDEX REBUILD ou a operação DBCC DBREINDEX.

      As operações de compilação de índice usam log mínimo, mas podem ser adiadas quando há um backup em execução em paralelo. Esse atraso é causado pelos requisitos de sincronização das páginas do buffer pool com registro mínimo quando você usa o modelo de recuperação simples ou bulk-logged.

      Aviso

      A instrução DBCC DBREINDEX está obsoleta. Evite usá-lo em novos aplicativos.

    • DROP INDEX nova recompilação de heap (se aplicável). A desalocação da página de índice durante uma operação DROP INDEX é sempre registrada integralmente.

Tarefa Artigo
Gerenciar o log de transações Gerenciar o tamanho do arquivo de log de transações

Solucionar problemas de um log de transações completo (erro 9002 do SQL Server)
Backup do log de transações (somente modelo de recuperação completa) Fazer backup de um log de transações

Fazer backup do log de transações quando o banco de dados estiver danificado (SQL Server)
Restaurar o log de transações (somente modelo de recuperação completa) Restaurar um backup de log de transações (SQL Server)

Conteúdo relacionado

  • Last updated on