O log de transações

Aplica-se a:SQL Server

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

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

Advertência

Nunca exclua ou mova esse log a menos que compreenda completamente as ramificações de fazê-lo.

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

Dica

Os pontos de verificação criam pontos válidos conhecidos a partir dos quais começar a aplicar logs de transações 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 suportadas pelo log de transações

O log de transações suporta as seguintes operações:

  • Recuperação de transações individuais.
  • Recuperação de todas as transações incompletas quando o SQL Server é iniciado.
  • Avançar um banco de dados, arquivo, grupo de arquivos ou página restaurado até o ponto de falha.
  • Suporte à replicação transacional.
  • Suporte a soluções de alta disponibilidade e recuperação de desastres: grupos de disponibilidade Always On, 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 detetar 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 quando o SQL Server é iniciado

Se um servidor falhar, os bancos de dados podem ser deixados em um estado em que algumas modificações nunca foram gravadas do cache do buffer para os arquivos de dados, e pode haver algumas modificações de transações incompletas nos arquivos de dados. Quando uma instância do SQL Server é iniciada, ela executa uma recuperação de cada banco de dados. Todas as modificações registradas no log que podem não ter sido gravadas nos arquivos de dados são roladas para frente. Cada transação incompleta encontrada no log de transações é revertida para garantir que a integridade do banco de dados seja preservada. Para obter mais informações, consulte 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

Após uma perda de hardware ou falha de disco que afeta os arquivos de banco de dados, você pode restaurar o banco de dados até o ponto de falha. Primeiro, restaure o último backup completo do banco de dados e o último backup diferencial do banco de dados e, em seguida, restaure a sequência dos backups do log de transações até ao ponto de falha.

À medida que você restaura cada backup de log, 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 foram concluídas naquele momento. Para obter mais informações, consulte Visão geral de restauração e recuperação (SQL Server).

Suporte à replicação transacional

O Log Reader Agent monitora o log de transações de cada banco de dados configurado para 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.

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

As soluções de servidor em espera, grupos de disponibilidade Always On, espelhamento de banco de dados e envio de logs, dependem muito 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 reproduzida nas versões separadas do banco de dados em todas as réplicas secundárias. A réplica primária envia cada registro de log imediatamente para as réplicas secundárias, que aplicam os registros de log de entrada 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 os backups de log para 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 no 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 cada registro de log imediatamente para a instância do servidor espelho, que aplica os registros de log de entrada ao banco de dados espelho, rolando-o continuamente. Para obter mais informações, consulte Espelhamento de banco de dados (SQL Server).

Características do 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 código simples, rápido e robusto no Mecanismo de Banco de Dados do SQL Server. Para obter mais informações, consulte Arquitetura física do log de transações.

  • O formato de registos de log e de páginas não é obrigado a 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 falta de espaço no log de transações, ao mesmo tempo em que reduz a sobrecarga administrativa. Para mais informações, consulte ALTER DATABASE (Transact-SQL) opções de ficheiros e grupos de ficheiros.

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

Para obter informações sobre a arquitetura física e lógica do log de transações, consulte o guia de gerenciamento e arquitetura 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. Você deve truncar regularmente seu log de transações para evitar que ele preencha o espaço alocado. Vários fatores podem atrasar o truncamento do 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 do registo elimina ficheiros de registo virtual (VLFs) inativos do registo de transações lógico de uma base de dados do SQL Server, libertando espaço no registo lógico para ser reutilizado pelo registo de transações físico. Se um log de transações nunca for truncado, ele eventualmente preencherá todo o espaço em disco alocado para arquivos de log físicos.

Para evitar ficar sem espaço, a menos que o truncamento de log seja atrasado por algum motivo, o truncamento ocorre automaticamente após os seguintes eventos:

  • No modelo de recuperação simples, após um ponto de verificação.

  • No modelo de recuperação completa ou no modelo de recuperação em massa, se tiver ocorrido um ponto de verificação desde o backup anterior, o truncamento ocorrerá após um backup de log (a menos que seja um backup de log somente para 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 de registos 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 físico, você deve reduzir o arquivo de log. Para obter informações sobre como reduzir o tamanho do arquivo de log físico, consulte Gerenciar o tamanho do arquivo de log de transações. No entanto, tenha em conta os fatores que podem atrasar o truncamento do log. Se o espaço de armazenamento for necessário novamente após uma redução de log, o log de transações crescerá novamente e, ao fazer isso, introduzirá sobrecarga de desempenho durante as operações de crescimento de log.

Fatores que podem atrasar a truncação de log

Quando os registos do log permanecem ativos durante muito tempo, o truncamento do log de transações é adiado 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 atrasado por vários motivos. Para saber o que está a impedir a truncagem do registo, consulte as colunas log_reuse_wait e log_reuse_wait_desc da vista de catálogo sys.databases. A tabela a seguir descreve os valores dessas colunas.

Valor de log_reuse_wait log_reuse_wait_desc valor Descrição
0 NOTHING Atualmente, há um ou mais arquivos de log virtuais (VLFs) reutilizáveis.
1 CHECKPOINT Não ocorreu nenhum ponto de verificação desde a última truncagem do registo, ou o início do registo ainda não avançou para além de um ficheiro de registo virtual (VLF). (Todos os modelos de recuperação.)

Este cenário é uma razão habitual para atrasar a truncagem do registo. Para obter mais informações, consulte pontos de verificação de banco de dados (SQL Server).
2 LOG_BACKUP Um backup de log é necessário antes que o log de transações possa ser truncado. (Apenas modelos de recuperação completos ou de registo em massa.)

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

Se um backup de dados estiver impedindo o truncamento de log, cancelar a operação de backup pode resolver o problema imediato.
4 ACTIVE_TRANSACTION Uma transação está ativa (todos os modelos de recuperação):

Uma transação de longa duração pode existir no início do backup de log. Nesse caso, liberar espaço pode exigir outro backup de log. As transações de longa duração evitam o truncamento do log em todos os modelos de recuperação, incluindo o modelo de recuperação simples, no qual o log geralmente é truncado em cada checkpoint (ponto de verificação) automático.

Uma transação é adiada. Uma transação adiada é efetivamente uma transação ativa cuja anulação está bloqueada devido à indisponibilidade de um recurso. 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 de longa duração 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 classificação, arquivos de trabalho para hash, tabelas de trabalho de cursor e controle de versão de linha. Mesmo que a transação do usuário inclua apenas a leitura de dados (consultasSELECT), objetos internos podem ser criados e usados em transações do usuário. Em seguida, o log de transações tempdb pode ser preenchido.
5 DATABASE_MIRRORING O espelhamento do banco de dados é pausado ou, no modo de alto desempenho, o banco de dados espelho está 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 são entregues ao banco de dados de distribuição. (Somente modelo de recuperação completa.)

Para obter informações sobre replicação transacional, consulte 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 normalmente breve de truncagem atrasada de registos.
8 LOG_SCAN Está em curso uma verificação do registo. (Todos os modelos de recuperação.)

Esta é uma causa rotineira e normalmente breve de truncagem atrasada de registos.
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 a um banco de dados secundário correspondente. (Somente modelo de recuperação completa.)

Para obter mais informações, consulte O que é um grupo de disponibilidade Always On?.
10 - Apenas para uso interno.
11 - Apenas para uso interno.
12 - Apenas 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 do banco de dados poderá ser mais antiga do que o ponto de verificação o número de sequência de log (LSN). Neste caso, a página mais antiga pode adiar a truncagem do registo. (Todos os modelos de recuperação.)

Para obter informações sobre pontos de verificação indiretos, consulte pontos de verificação de banco de dados (SQL Server).
14 OTHER_TRANSIENT Esse valor não é usado no momento.
16 XTP_CHECKPOINT Um ponto de verificação OLTP In-Memory precisa ser executado. Para tabelas com otimização de memória, um ponto de verificação automático é tomado 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 e ponto de verificação para tabelas com otimização de memória.

Operações que podem ser minimamente registradas

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

Não há suporte para registro mínimo em log para tabelas com otimização de memória.

Sob o modelo de recuperação de completo, todas as operações em massa são totalmente registradas. No entanto, pode minimizar o registo em log de um conjunto de operações em massa mudando temporariamente o banco de dados para o modelo de recuperação com registo em massa para operações em massa. O registo mínimo é mais eficiente do que o registo completo e reduz a possibilidade de uma operação em grande escala preencher o espaço no registo de transações durante uma transação de grande volume. No entanto, se o banco de dados for danificado ou perdido quando o log mínimo estiver em vigor, não é possível recuperá-lo até ao momento da falha.

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

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

    Quando a replicação transacional está ativada, as operações BULK INSERT são integralmente registadas, mesmo no modelo de recuperação bulk-logged.

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

    Quando a replicação transacional está ativada, as operações SELECT INTO são integralmente registadas mesmo sob o modelo de recuperação bulk-logged.

  • Atualizações parciais de tipos de dados de valor elevado, utilizando a cláusula .WRITE na instrução UPDATE ao inserir ou anexar novos dados. O registo mínimo não é utilizado quando os valores existentes são atualizados. Para obter mais informações sobre tipos de dados de grande valor, consulte Tipos de dados.

  • instruções WRITETEXT e UPDATETEXT ao inserir ou acrescentar novos dados nas colunas de tipo de dados de texto, ntext, e imagem . O registo mínimo não é utilizado quando os valores existentes são atualizados.

    Advertência

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

  • Se a base de dados estiver definida para o modelo de recuperação simples ou bulk-logged, algumas operações DDL de índice são registadas de forma mínima, quer sejam executadas offline ou online. As operações de índice minimamente registradas são:

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

    • ALTER INDEX RECONSTRUÇÃO ou DBCC DBREINDEX Operação.

      As operações de criação de índice utilizam registo mínimo, mas podem sofrer atrasos quando existe uma cópia de segurança a decorrer em simultâneo. Este atraso é causado pelos requisitos de sincronização das páginas da memória intermédia com registo mínimo quando está a utilizar o modelo de recuperação simples ou bulk-logged.

      Advertência

      A instrução DBCC DBREINDEX está obsoleta. Evite usá-lo em novas aplicações.

    • DROP INDEX Nova reconstrução de heap (se aplicável). A desalocação da página de índice durante uma operação DROP INDEX é sempre totalmente registada.

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)
Fazer 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