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.

Para obter informações sobre a arquitetura e os componentes internos do log de transações, consulte o guia de gerenciamento e arquitetura de log de transações do 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 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 da 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, o que resulta em código simples, rápido e robusto no Mecanismo de Banco de Dados do SQL Server. Para obter mais informações, consulte Transaction Log Physical Architecture.

• 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. Os arquivos podem ser definidos para expandir automaticamente definindo o valor FILEGROWTH para o log. Isso reduz o potencial de ficar sem espaço no log de transações e, ao mesmo tempo, reduz a sobrecarga administrativa. Para obter mais informações, consulte ALTER DATABASE (Transact-SQL) Opções de Ficheiro e Grupo 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 e os componentes internos do log de transações do SQL Server, consulte o guia de arquitetura e gerenciamento de log de transações .

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 impacto no tamanho do log de transações.

O truncamento de log elimina arquivos de log virtuais inativos do log de transações lógicas de uma base 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, 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 um banco de dados pela primeira vez usando 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 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 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 mente Fatores que podem atrasar o truncamento de 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 de log permanecem ativos por um longo tempo, o truncamento do log de transações é atrasado e o ficheiro de log pode encher, como já mencionámos anteriormente neste artigo.

O truncamento de log pode ser atrasado 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 do sys.databases exibição de catálogo. A tabela a seguir descreve os valores dessas colunas.

Operações que podem ser minimamente registradas

Registro em log mínimo envolve registrar apenas as informações necessárias para recuperar a transação sem oferecer suporte à recuperação no tempo desejado. Este artigo identifica as operações que são minimamente registradas no modelo de recuperação de bulk-logged (bem como no modelo de recuperação simples, exceto quando um backup está em execução).

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 a granel (bcp, BULK INSERTe 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 totalmente registadas, mesmo sob o modelo de recuperação de registo em massa.

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

  Quando a replicação transacional está habilitada, as operações SELECT INTO são completamente registadas, mesmo sob o modelo de recuperação em massa.

• Atualizações parciais para tipos de dados de grande valor, usando 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 log mínimo não é usado quando os valores existentes são atualizados.

  Advertência

  As declarações WRITETEXT e UPDATETEXT são preteridas; evite usá-las em novas aplicações.

• Se o banco de dados estiver configurado no modelo de recuperação simples ou com registro em massa, algumas operações DDL de índice são registradas com registro mínimo, quer a operação seja executada offline quer online. As operações de índice minimamente registradas são as seguintes:

  • CRIAR ÍNDICE operações (incluindo exibições indexadas).

  • Operação de ALTER INDEX REBUILD ou DBCC DBREINDEX.

    As operações de compilação de índice usam registro mínimo, mas podem ser atrasadas quando há um backup em execução simultânea. Esse atraso é causado pelos requisitos de sincronização das páginas do pool de buffer minimamente registadas ao utilizar o modelo de recuperação simples ou com registo em bloco.

    Advertência

    A instrução DBCC DBREINDEX é desaconselhada; evite usá-la 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 de DROP INDEX é sempre totalmente registrada.

Tarefas relacionadas

Conteúdo relacionado

• Guia de arquitetura e gerenciamento de log de transações do SQL Server
• Controlar a durabilidade da transação
• Pré-requisitos para registro mínimo de importação em massa
• Backup e restauração de bancos de dados do SQL Server
• Visão geral da restauração e recuperação (SQL Server)
• Pontos de verificação de banco de dados (SQL Server)
• exibir ou alterar as propriedades de um banco de dados
• Modelos de recuperação (SQL Server)
• Backups de log de transações (SQL Server)
• sys.dm_db_log_info (Transact-SQL)
• sys.dm_db_log_space_usage (Transact-SQL)