Backups de log de transações (SQL Server)

  • Artigo

Aplica-se a:SQL Server

Este artigo só é relevante para bancos de dados SQL Server que usam modelos de recuperação completa ou bulk-logged. Este artigo descreve o backup de log de transações de um banco de dados SQL Server.

Você deve ter pelo menos criado um backup completo antes de criar qualquer backup de log. Depois disso, o backup do log de transações pode ser feito a qualquer momento, exceto durante outro backup de log.

Recomendamos que você faça backups de log com frequência para minimizar exposição à perda de trabalho e para truncar o log de transações.

Em geral, um administrador de banco de dados cria um backup completo de banco de dados ocasionalmente, como semanalmente, e, como opção, cria uma série de backups de banco de dados diferencial em um intervalo mais curto, como diariamente. Independentemente dos backups de banco de dados, o administrador de banco de dados faz backup do log de transações em intervalos frequentes. Para determinado tipo de backup, o intervalo ideal entre backups depende de fatores como importância dos dados, tamanho do banco de dados e carga de trabalho do servidor. Veja mais informações sobre a implementação de uma boa estratégia, em Recomendações neste artigo.

Como funciona uma sequência de backups de log

A sequência de backups de log de transações log chain é independente dos backups de dados. Por exemplo, suponha a sequência de eventos a seguir.

Hora Evento
8:00 Backup do banco de dados.
Meio-dia Backup de log de transações.
16:00 Backup de log de transações.
18h Backup do banco de dados.
20h Backup de log de transações.

O backup do log de transações criado às 20h contém registros de log de transações das 16h às 20h, abrangendo o horário em que o backup completo do banco de dados foi criado às 18h. A sequência de backups de logs de transações é contínua, do backup completo de banco de dados inicial criado às 8h até p último backup de log de transações feito às 20h. Para obter informações sobre como aplicar esses backups de log, veja o exemplo Aplicar backups de log de transações (SQL Server).

Recomendações

Se um log de transações estiver danificado, o trabalho executado desde o backup válido mais recente será perdido. Portanto, recomendamos enfaticamente que você coloque seus arquivos de log em um armazenamento tolerante a falhas.

Se um banco de dados estiver danificado ou se você estiver prestes a restaurar o banco de dados, recomendamos que crie um backup da parte final do log para permitir a restauração do banco de dados até o momento atual.

Cuidado

Problema conhecido: em bancos de dados com tabelas otimizadas para memória, executar um backup de log de transações sem recuperação e, posteriormente, executar uma restauração de log de transações com recuperação pode resultar em um processo de restauração de banco de dados sem resposta. Esse problema também pode afetar a funcionalidade de envio de logs. Para contorná-lo, a instância do SQL Server pode ser reiniciada antes de iniciar o processo de restauração.

Por padrão, toda operação de backup bem-sucedida acrescenta uma entrada ao log de erros do SQL Server e ao log de eventos do sistema. Se você fizer backup do log com muita frequência, essas mensagens de êxito serão acumuladas muito rapidamente, resultando em logs de erros imensos que podem dificultar a localização de outras mensagens. Nesses casos, você pode suprimir essas entradas de log usando o sinalizador de rastreamento 3226, se nenhum dos seus scripts depender dessas entradas. Para obter mais informações, confira Sinalizadores de rastreamento (Transact-SQL).

Faça backups de log com frequência suficiente para dar suporte a seus requisitos empresariais, especificamente, a tolerância à perda de trabalho, que pode ser causada por um armazenamento de logs danificado.

  • A frequência apropriada para fazer backups de log depende de tolerância à exposição à perda de trabalho, equilibrada por quantos backups de log é possível armazenar, administrar e, potencialmente, restaurar. Pense no objetivo de tempo de recuperação (RTO) e no objetivo de ponto de recuperação (RPO) necessários ao implementar sua estratégia de recuperação e, especificamente, na cadência do backup de logs.

  • Fazer um backup de log a cada 15 a 30 minutos deve ser o bastante. Se o seu negócio requer que você reduza ao mínimo a exposição à perda de trabalho, considere fazer backups de log com mais frequência. Backups de log mais frequentes têm a vantagem adicional de aumentar a frequência de truncamentos de log, resultando em arquivos de log menores.

Importante

Para limitar o número de backups de log que você precisa restaurar, é essencial fazer backup dos dados com frequência. Por exemplo, convém programar um backup de banco de dados completo por semana e backups de diferenciais de banco de dados diariamente.
Mais uma vez, pense no RTO e RPO necessários ao implementar sua estratégia de recuperação e, especificamente, na cadência de backup completo e diferencial de banco de dados.

Conteúdo relacionado