O log de transações (SQL Server)

Todo banco de dados do SQL Server tem um log de transações que registra todas as transações e modificações feitas no banco de dados a cada transação. O log de transação deve ser truncado regularmente para impedir o preenchimento. No entanto, alguns fatores podem atrasar o truncamento de log e, portanto, o monitoramento do tamanho do log é importante. Algumas operações podem ser registradas em log minimamente para reduzir o impacto no tamanho do log de transações.

O log de transações é um componente crítico do banco de dados e, se houver uma falha do sistema, será necessário que o log de transações retorne seu banco de dados a um estado consistente. O log de transações nunca deve ser excluído ou movido a menos que você compreenda plenamente as consequências disso.

Observação
Pontos bons conhecidos com base nos quais começar a aplicar logs de transação durante a recuperação de banco de dados são criados por pontos de verificação. Para obter mais informações, consulte Pontos de verificação de banco de dados (SQL Server).

Neste tópico:

• Benefícios: operações com suporte pelo log de transações

• Truncamento do log de transações

• Fatores que podem atrasar o truncamento de log

• Operações que podem ser minimamente registradas em log

• Tarefas relacionadas

Benefícios: 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 quando SQL Server é iniciado.

• Rolando um banco de dados restaurado, arquivo, grupo de arquivo ou página até ao ponto de falha.

• Dando 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 log.

[Início]

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. O truncamento de log é essencial para impedir o preenchimento do log. O truncamento de log exclui 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 foi truncado, eventualmente, ele preencherá todo o espaço em disco alocado para seus arquivos de log físicos.

Para evitar esse problema, a menos que o truncamento de log esteja sendo atrasado por alguma razão, o truncamento ocorrerá automaticamente depois dos seguintes eventos:

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

• No modelo de recuperação completa ou bulk-logged, se um ponto de verificação ocorreu desde o backup anterior, o truncamento ocorrerá depois de um backup de log (a menos que esse seja um backup de log de cópia somente).

Para obter mais informações, consulte Fatores que podem atrasar o truncamento de log, posteriormente neste tópico.

Observação
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ê precisa reduzir o 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.

[Início]

Fatores que podem atrasar o truncamento de log

Quando os registros de log permanecem ativos por muito tempo, o truncamento do log de transações é atrasado esse log poderá ocupar todo o espaço.

Importante
Para obter informações sobre como responder a um log de transações completo, consulte Solução de problemas em um log de transação completa (SQL Server Erro 9002).

O truncamento de log pode ser atrasado por uma variedade de fatores. E possível descobrir se, de fato, há algo impedindo o truncamento de log consultando as colunas log_reuse_wait e log_reuse_wait_desc da exibição do catálogo sys.databases. A tabela a seguir descreve os valores dessas colunas.

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 de banco de dados (SQL Server).
2	LOG_BACKUP	Um backup de log é necessário antes do truncamento do log de transações. (Modelos de recuperação completa e bulk-logged somente) Quando o backup de log seguinte é concluído, 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). Se um backup de dados estiver evitando o truncamento de log, a operação de backup pode ajudar a solucionar o problema imediatamente.
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. Observação Transações demoradas impedem o truncamento de 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 de transações adiadas e como fazer com que elas saiam do estado adiado, consulte Transações adiadas (SQL Server).
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 (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. (Apenas modelo de recuperação completa) Para obter mais informações sobre a replicação transacional, consulte Replicação do SQL Server.
7	DATABASE_SNAPSHOT_CREATION	Um instantâneo de 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	Um exame de log está ocorrendo. (Todos os modelos de recuperação) Esse é um motivo rotineiro e, normalmente breve, de truncamento de log atrasado.
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. (Modelo de recuperação completa) Para obter mais informações, consulte Visão geral de grupos de disponibilidade AlwaysOn (SQL Server).
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 do ponto de verificação. Nesse caso, a página mais antiga pode atrasar o truncamento de log. (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 atualmente.

[Início]

Operações que podem ser minimamente registradas em log

O registro mínimo em log envolve o registro somente das informações que são necessárias para recuperar a transação sem oferecer suporte à recuperação pontual. Este tópico identifica as operações com registro mínimo em log no modelo de recuperação bulk-logged (como também no modelo de recuperação simples, exceto quando há um backup em execução).

Observação

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

As operações a seguir, completamente registradas sob o modelo de recuperação completa, têm log mínimo no modelo de recuperação simples e bulk-logged:

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

  Observação
  Quando a replicação transacional está habilitada, as operações BULK INSERT são completamente registradas mesmo no modelo de recuperação bulk-logged.

• Operações SELECT INTO.

  Observação
  Quando a replicação transacional está habilitada, as operações SELECT INTO são completamente registradas mesmo no modelo de recuperação bulk-logged.

• Atualizações parciais em tipos de dados de valor grande, usando a cláusula .WRITE na instrução UPDATE ao inserir ou anexar novos dados. Observe que o log mínimo não é usado quando valores existentes estão sendo atualizados. Para obter mais informações sobre tipos de dados de valor grandes, consulte Tipos de dados (Transact-SQL).

• Instruções WRITETEXT e UPDATETEXT ao inserir ou anexar novos dados em colunas de tipos de dados text, ntext e image. Observe que o log mínimo não é usado quando valores existentes estão sendo atualizados.

  Observação
  As instruções WRITETEXT e UPDATETEXT são preteridas, portanto você evite usá-las em novos aplicativos.

• Se o banco de dados for definido como o modelo de recuperação simples ou bulk-logged, algumas operações INDEX DDL terão log mínimo, independentemente de ela ser executada offline ou online. Os operações de índice de log mínimo são:

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

  • Operações ALTER INDEX REBUILD ou DBCC DBREINDEX.

    Observação
    A instrução DBCC DBREINDEX é preterida, portanto evite usá-la em novos aplicativos.

  • Recriação de novo heap DROP INDEX (se aplicável).

    Observação
    A desalocação de páginas de índice durante uma operação DROP INDEX sempre é totalmente registrada em log.

[Início]

Tarefas relacionadas

Managing the transaction log

• Gerenciar o tamanho do arquivo de log de transações

• Solução de problemas em um log de transação completa (SQL Server Erro 9002)

Fazendo backup do log de transações (modelo de recuperação completa)

• Fazer backup de um log de transações (SQL Server)

Restaurando o log de transações (modelo de recuperação completa)

• Restaurar um backup de log de transações (SQL Server)

[Início]

Consulte também

Conceitos

Pré-requisitos para log mínimo em importação em massa

Fazer backup e restaurar bancos de dados do 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)