The Transaction Log (SQL Server) (Português)

• 10/23/2019
• 11 minutes to read
• • M
  • D
  • f
  • M
  • s
  • +8

Applies to: SQL Server (all supported versions)

Every SQL Server database has a transaction log that records all transactions and the database modifications made by each transaction.,

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

para mais informações sobre a arquitectura do diário de operações e os dados internos, consulte a arquitectura e o Guia de gestão do Diário de operações do servidor SQL.

operações suportadas pelo Diário de operações

O Diário de operações suporta as seguintes operações:

• recuperação Individual de operações.recuperação de todas as operações incompletas quando o servidor SQL é iniciado.
• rodando uma base de dados restaurada, arquivo, filegroup, ou página para a frente até o ponto de falha.suporte à replicação transacional.suporte a alta disponibilidade e soluções de recuperação de desastres: sempre em grupos de disponibilidade, espelhamento de banco de dados e envio de logs.,

recuperação individual da transacção

Se uma aplicação emitir uma declaração ROLLBACK, ou se o motor da Base de dados detectar um erro como a perda de comunicação com um cliente, os registos de registo são usados para fazer recuar as modificações feitas por uma transacçã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 onde algumas modificações nunca foram escritas a partir do cache de buffer para os arquivos de dados, e pode haver algumas modificações a partir de transações incompletas nos arquivos de dados. Quando uma instância do servidor SQL é iniciada, ele executa uma recuperação de cada banco de dados. Cada modificação registrada no log que pode não ter sido escrita nos arquivos de dados é rolada para a frente., Todas as transações incompletas encontradas no diário de transações são então revertidas para se certificar de que a integridade do banco de dados é preservada. Para mais informações, consulte a visão geral de recuperação e recuperação (servidor SQL).

ao gravar uma base de dados, ficheiro, filegroup ou página anterior restaurada até ao ponto de falha

após uma perda de hardware ou falha do disco que afecte os ficheiros da base de dados, poderá repor a base de dados até ao ponto de falha., Você primeiro restaurar o último backup de banco de dados completo e o último backup de banco de dados diferencial, e, em seguida, restaurar a sequência subseqüente dos backups de log de transação para o ponto de falha.

à medida que você restaurar cada backup de log, o motor de banco de dados reaparece todas as modificações registradas no log para avançar todas as transações. Quando o último backup de log é restaurado, o motor de banco de dados, em seguida, usa a informação de log para rolar de volta todas as transações que não estavam completas naquele ponto. Para mais informações, consulte a visão geral de recuperação e recuperação (servidor SQL).,

suporte à replicação transacional

o agente Leitor de Registos monitoriza o diário de operações de cada base de dados configurada para replicação transacional e copia as transacções marcadas para replicação a partir do diário de operações para a base de dados de distribuição. Para mais informações, veja como funciona a replicação transacional.

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

as soluções de standby-server, sempre em grupos de disponibilidade, mirror de banco de dados e log shipping, dependem fortemente do diário de operações.,

em um cenário de grupos de disponibilidade, cada atualização de uma base de dados, a réplica primária, é imediatamente reproduzida em cópias separadas e completas da base de dados, as réplicas secundárias. A réplica primária envia Cada registro de log imediatamente para as réplicas secundárias, que aplica os registros de log recebidos para bases de dados de grupos de disponibilidade, continuamente rodando-o para a frente. Para mais informações, veja sempre em instâncias de Cluster de Failover

em um cenário de envio de log, o servidor primário envia o log de transação ativo do banco de dados primário para um ou mais destinos., Cada servidor secundário repõe o log na sua base de dados secundária local. Para mais informações, consulte Sobre Log Shipping.

em um cenário de espelhamento de banco de dados, cada atualização para uma base de dados, a base de dados principal, é imediatamente reproduzida em uma cópia separada e completa da base de dados, a base de dados espelho. A instância principal do servidor envia Cada registro de log imediatamente para a instância do servidor espelho, que aplica os registros de log de entrada para o banco de dados mirror, continuamente rodando-o para a frente. Para mais informações, consulte a base de dados Mirroring.,

log de Transações características

Características do SQL Server Mecanismo de Banco de dados de log de transação:

• 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 dentro do motor de banco de Dados SQL Server. Para mais informações, consulte a arquitectura física do Diário de operações.

• o formato dos registos de registo e das páginas não é obrigado a seguir o formato das páginas de dados.,

• O Diário de operações pode ser implementado em vários ficheiros. Os arquivos podem ser definidos para expandir automaticamente, definindo o valor FILEGROWTH para o log. Isto reduz o potencial de ficar sem espaço no diário de operações, ao mesmo tempo que reduz a sobrecarga administrativa. Para mais informações, veja ALTER DATABASE (Transact-SQL) e opções de Filegroup.

• o mecanismo para reutilizar o espaço dentro dos ficheiros de registo é rápido e tem um efeito mínimo na transferência.,

para informações sobre a arquitectura do diário de operações e os dados internos, consulte a arquitectura e o Guia de gestão do Diário de operações do servidor SQL.

truncação do diário de operações

a truncação do Diário liberta espaço no ficheiro de registo para reutilização pelo Diário de operações. Você deve truncar regularmente seu log de transação para evitar que ele preencha o espaço atribuído. Vários fatores podem atrasar a truncação do log, então monitorar o tamanho do log importa. Algumas operações podem ser registradas de forma mínima para reduzir seu impacto no tamanho do diário de operações.,

a truncação do registo apaga os ficheiros de Registo Virtual inactivos (VLFs) do registo lógico de transacções de uma base de dados do servidor de SQL, libertando espaço no registo lógico para reutilização pelo registo físico de transacções. Se um diário de transações nunca é truncado, ele acabará por preencher todo o espaço em disco atribuído aos arquivos de log físico.

para evitar ficar sem espaço, a menos que a truncação logarítmica seja atrasada por alguma razão, a truncação ocorre automaticamente após os seguintes eventos:

• sob o modelo de recuperação simples, após um checkpoint.,
• sob o modelo de recuperação completa ou modelo de recuperação registrada a granel, se um checkpoint ocorreu desde o backup anterior, truncação ocorre após um backup de log (a menos que seja um backup apenas de cópia).

para mais informações, veja fatores que podem atrasar a truncação do log, mais tarde neste tópico.

Fatores que pode atrasar o truncamento de log

Quando os registros de log permanecem ativos por um longo tempo, truncamento de log de transações está atrasado, e o log de transação pode encher-se, como já foi mencionado anteriormente neste tópico.,

na verdade, a truncação logarítmica pode ser retardada por uma variedade de razões. Saiba o que, se alguma coisa, está impedindo a sua truncação de log, questionando as colunas log_reuse_ wait_desc do sistema.vista de catálogo de bases de dados. A tabela seguinte descreve os valores destas colunas.,

replicação

log_reuse_wait valor	log_reuse_wait_desc valor	Descrição
0	NADA	Atualmente, existem um ou mais reutilizáveis arquivos de log virtuais (Vlf).
1	CHECKPOINT	não ocorreu nenhum checkpoint desde a última truncação de log, ou o chefe do log ainda não se moveu para além de um arquivo de log virtual (VLF). (Todos os modelos de recuperação) esta é uma razão de rotina para atrasar a truncação do log., Para mais informações, consulte os pontos de verificação da Base de dados (Servidor SQL).
2	LOG_PACKUP	é necessária uma cópia de segurança de log antes de O Diário de operações poder ser truncado. (Full or bulk-loged recovery models only) When the next log backup is completed, some log space might become reusable.
3	ACTIVE_BACKUP_OR_RESTORE	está em curso uma cópia de segurança de dados ou uma recuperação (todos os modelos de recuperação).se um backup de dados está impedindo a truncação de log, cancelar a operação de backup pode ajudar o problema imediato.,
4	ACTIVE_TTT>	uma transacção está activa (todos os modelos de recuperação): Pode existir uma transacção a longo prazo no início do backup log. Neste caso, libertar o espaço pode requerer outra cópia de segurança. Note-se que as operações de longa duração impedem a truncação de log sob todos os modelos de recuperação, incluindo o modelo de recuperação simples, ao abrigo do qual o diário de operações é geralmente truncado em cada ponto de controlo automático. Uma transação é diferida., Uma transação diferida é efetivamente uma transação ativa cuja rollback é bloqueado por causa de algum recurso indisponível. Para informações sobre as causas das transações diferidas e como movê-las para fora do estado diferido, consulte as transações diferidas (servidor SQL).as transacções a longo prazo poderão também preencher o registo de transacções do tempdb. O Tempdb é usado implicitamente por transações de usuários para objetos internos, como tabelas de trabalho para ordenação, arquivos de trabalho para hashing, tabelas de trabalho de cursor e versionamento de linhas., Mesmo que a transação do usuário inclua apenas a leitura de dados (SELECT consultas), objetos internos podem ser criados e usados nas transações do Usuário. Então o diário de transações do tempdb pode ser preenchido.
5	DATABASE_MIRRORING	Database mirroring is paused, or under high-performance mode, the mirror database is significantly behind the principal database. (Full recovery model only) For more information, see Database Mirroring (SQL Server).,
6	durante as replicações transacionais, as operações relevantes para as publicações ainda não foram transmitidas à base de dados de distribuição. (Full recovery model only) For information about transactional replication, see SQL Server Replication.
7	DATABASE_SNAPSHOT_CREATION	está a ser criada uma fotografia de base de dados. (Todos os modelos de recuperação) esta é uma rotina, e tipicamente breve, causa de atraso na truncação logarítmica.
8	LOG_SCAN	está ocorrendo uma varredura de log., (Todos os modelos de recuperação) esta é uma rotina, e tipicamente breve, causa de atraso na truncação logarítmica.uma réplica secundária de um grupo de disponibilidade está a aplicar os registos do diário de operações desta base de dados a uma base de dados secundária correspondente. (Full recovery model) Para mais informações, veja a visão geral de sempre sobre grupos de disponibilidade (SQL Server).,
10	–	apenas Para uso interno
11	–	apenas Para uso interno
12	–	Somente para uso interno
13	OLDEST_PAGE	Se um banco de dados é configurado para usar pontos de verificação indiretos, a mais antiga página sobre o banco de dados pode ser mais antigo do que o ponto de verificação de número de seqüência de log (LSN). Neste caso,a Página mais antiga pode atrasar a truncação do log. (All recovery models) For information about indirect checkpoints, see Database Checkpoints (SQL Server).,este valor não é actualmente utilizado.
16	XTP_CHECKPOINT	um ponto de verificação OLTP em memória precisa ser realizado.Para tabelas otimizadas pela memória, um ponto de controle automático é tomado quando o arquivo de registro de transação se torna maior que 1.,5 GB desde o último ponto de verificação (inclui baseado em disco e de memória otimizada tabelas) Para mais informações, consulte Operação de ponto de verificação de Memória Otimizada e Tabelas (https://blogs.msdn.microsoft.com/sqlcat/2016/05/20/logging-and-checkpoint-process-for-memory-optimized-tables-2/)

Operações que podem ser minimamente registrada

Mínimo de log envolve apenas o registo da informação que é necessária para recuperar a transação, sem ponto de apoio-em-tempo de recuperação., Este tópico identifica as operações que são minimamente registradas sob o modelo de recuperação de massa registrada (bem como sob o modelo de recuperação simples, exceto quando um backup está em execução).

as seguintes operações, que estão completamente registadas no modelo de recuperação completa, estão minimamente registadas no modelo de recuperação simples e a granel:

• operações de importação a granel (bcp, BULK INSERT e INSERT… SELECCIONAR)., Para mais informações sobre quando a importação de volumes em uma tabela é mínima, veja pré-requisitos para o registro mínimo na importação de volumes.

Quando a replicação transacional está ativada, BULK INSERT as operações são totalmente registradas mesmo sob o modelo de recuperação registrada.

• seleccione nas operações.

Quando a replicação transacional está ativada, SELECT INTO as operações são totalmente registradas mesmo sob o modelo de recuperação registrada.,

• actualizações parciais a tipos de dados de grande valor, utilizando a cláusula .WRITE na declaração de actualização ao inserir ou adicionar novos dados. Note que o registro mínimo não é usado quando os valores existentes são atualizados. Para mais informações sobre tipos de dados de grande valor, consulte Tipos de dados (Transact-SQL).

• writetext and UPDATETEXT statements when inserting or appending new data into the text, ntext, and image data type columns. Note que o registro mínimo não é usado quando os valores existentes são atualizados.,

  Warning

  The WRITETEXT and UPDATETEXT as declarações são depreciadas; evite usá-las em novas aplicações.

• Se a base de dados estiver configurada para o modelo de recuperação simples ou com entrada em massa, algumas operações de DDL de índice são registradas de forma mínima, quer a operação seja executada offline ou online. As operações de indexação com registo mínimo são as seguintes:

  • criar operações de indexação (incluindo vistas indexadas).

  • ALTER INDEX REBUILD ou DBCC dbreindex operations.,

    Warning

    The DBCC DBREINDEX statement is depreciated; Do not use it in new applications.

    Nota

    As operações de compilação de índices utilizam o registo mínimo, mas podem ser atrasadas quando há uma cópia de segurança em execução simultânea. Este atraso é causado pelos requisitos de sincronização de páginas de buffer pool minimamente registradas quando se usa o modelo de recuperação simples ou em massa registrada.

  • DROP INDEX New heap rebuild (se aplicável). A desallocação da página de índice durante uma operação DROP INDEX é sempre totalmente logada.,n o Banco de dados Está Danificado (SQL Server)

  Restauração do Log de Transação (Modelo de Recuperação Completa)

  • Restaurar um Backup de Log de Transação (SQL Server)

  Veja também:

  o SQL Server Log de Transações de Arquitetura e Gerenciamento de Guia
  Controle de Transação Durabilidade
  pré-Requisitos para o Mínimo de Log de Importação em Massa
  Backup e Restauração de Bancos de dados SQL Server
  Restaurar e Visão geral da Recuperação (SQL Server)
  pontos de verificação de Banco de dados (SQL Server)
  Visualizar ou Alterar as Propriedades de um Banco de dados
  Modelos de Recuperação (SQL Server)
  Backups de Log de Transação (SQL Server)
  sys.,dm_db_log_info (Transact-SQL)
  sys. dm_db_log_space_usage (Transact-SQL)