Qual a melhor forma de manter os tamanhos dos arquivos de log SQL

Sou um novo DBA e estou gerenciando uma instância do SQL Server 2012 que possui uma quantidade razoável de atividades. Estou executando no modo de recuperação completa porque precisamos de recuperação pontual.

No momento, estou fazendo um backup completo dos bancos de dados e logs todos os dias às 5h. Alguns dos arquivos de log aumentaram até 300 GB e, mesmo depois de fazer um backup, eles não diminuem de tamanho. Posso fazer com que eles reduzam de tamanho executando algo semelhante a:

BACKUP LOG db1 TO DISK = '\\server\share\db1_log1.trn';
DBCC ShrinkFile([db1_log], 0);

BACKUP LOG db1 TO DISK = '\\server\share\db1_log2.trn';
DBCC ShrinkFile([db1_log], 0);

BACKUP LOG db1 TO DISK = '\\server\share\db1_log3.trn';
DBCC ShrinkFile([db1_log], 0);

Quando verifico os LSNs dos arquivos de backup, vejo algo como:

RESTORE headeronly FROM DISK = N'\\server\share\db1_log1.trn'
FirstLSN:  15781000014686200001
SecondLSN: 15802000000665000001

RESTORE headeronly FROM DISK = N'\\server\share\db1_log2.trn'
FirstLSN:  15802000000665000001
SecondLSN: 15805000000004100001

RESTORE headeronly FROM DISK = N'\\server\share\db1_log3.trn'
FirstLSN:  15805000000004100001
SecondLSN: 15808000000004200001

Não acredito que estou quebrando minha cadeia de logs diminuindo os arquivos de log. Lendo isso, acredito que estou prejudicando meu desempenho, porque esses arquivos de log encolhidos precisam crescer novamente.

Questões:

1. Por que o arquivo de log não diminui após meus backups? É porque existem transações não confirmadas?
2. No começo, eu pensava que deveria reduzir os arquivos de log após cada backup das 05:00. Depois de ler como isso é ruim para o desempenho, agora acredito que preciso fazer backups regulares de log a cada duas horas durante o dia. Isso está correto?
3. Meu backup completo normal do banco de dados / logs acontece todos os dias às 05:00 e, às vezes, leva 3 horas. Se eu agendar os backups de log a cada hora, o que acontecerá quando o backup de log colidir com o backup das 5:00 da manhã?

1. Por que o arquivo de log não diminui após meus backups? É porque existem transações não confirmadas?

O arquivo de log NTFS real não "encolhe" em um backup do log de transações, mas os VLFs (Arquivos de Log Virtuais) no log de transações são marcados para reutilização (porque agora eles são salvos em backup e persistidos na mídia), permitindo a o log de transações costuma ocorrer. Se você não estiver fazendo backup do log de transações ou com uma frequência insuficiente, não haverá VLFs disponíveis e isso fará com que o log de transações aumente (desde que o crescimento automático esteja definido) para acomodar entradas adicionais do log de transações.

2.No começo, eu pensava que deveria reduzir os arquivos de log após cada backup das 5:00 da manhã. Depois de ler como isso é ruim para o desempenho, agora acredito que preciso fazer backups regulares de log a cada duas horas durante o dia. Isso está correto?

A redução rotineira e agendada de arquivos não é uma boa ideia. Somente quando você precisar recuperar o espaço necessário, deverá considerar a DBCC SHINKFILE. Além disso, ao aumentar continuamente o log de transações, você pode impedir outras coisas, como a recuperação do banco de dados. Com muitas VLFs no log de transações (um problema comum quando o log de transações é aumentado apenas por um pequeno incremento de armazenamento), a quantidade de tempo para recuperar o banco de dados pode ser maior que o desejado.

3.O backup completo normal do banco de dados / logs acontece todos os dias às 05:00 e, às vezes, leva 3 horas. Se eu agendar os backups de log a cada hora, o que acontecerá quando o backup de log colidir com o backup das 5:00 da manhã?

Nada vai acontecer, isso é uma operação completamente legal. Veja este gráfico abaixo do MSDN . Onde há um ponto preto, essas duas operações não podem ocorrer ao mesmo tempo. Como você pode ver, um backup do banco de dados e um log de transações são permitidos simultaneamente.

A dica aqui é que você deve fazer backup do seu log de transações com mais frequência. O crescimento do arquivo NTFS não é o único problema que você pode encontrar ao não fazer backup do seu log de transações com mais frequência. Se houver uma falha no armazenamento e seu log de transações for perdido, você poderá restaurar apenas no momento em que seu último backup do log de transações. Se o log de transações for perdido, você não poderá fazer backup do final do log e restaurar no momento exato da falha. No seu caso, você pode perder 24 horas em dados. Mas se você fizer backup dos logs de transações a cada, digamos, 30 minutos, sua perda máxima de dados será de 30 minutos. Nesse caso, se seu log de transações for desativado e você tiver seu backup completo e sua cadeia de logs intacta, poderá restaurar para esse último backup de log.

Documentação do TechNet sobre Truncamento do log de transações

O principal problema com o qual você está lidando é que você está fazendo backup dos seus logs uma vez por dia. O comportamento do mecanismo é que os registros de log (espaço usado) em um arquivo de log serão removidos somente após um backup bem-sucedido. Esse espaço é recuperado quando ocorre um ponto de verificação, mas se o seu banco de dados estiver na recuperação Full / Bulk Logged, os registros de log serão removidos apenas se tiverem sido feitos backup com êxito.

Os backups de log devem ser usados ​​em conjunto com os backups completos e devem ser executados em um intervalo regular entre os backups completos. Esse intervalo pode ser qualquer período, embora eu normalmente execute backups de log a cada 15 minutos. Seu intervalo depende do seu RPO (Objetivo do ponto de recuperação) e da quantidade de dados que você pode perder no caso de uma recuperação.

Se você estiver executando backups regulares de log, não precisará reduzir os arquivos regularmente, pois gerenciará o espaço no arquivo de log antes que ele seja forçado a crescer.

Eu tenho o mesmo problema que você antes. Meu arquivo de log sempre aumenta. Em vez disso, uso o backup completo do banco de dados todas as noites. Então aqui está a minha solução:

1. faça backup do seu arquivo de log atual.

2. Defina seu banco de dados para recuperação simples

   • Porque no Full Recovery -> o arquivo de log não exclui a transação confirmada, apenas reorganiza seus dados -> o arquivo Shink não afeta muito -> e vice-versa para o Simple Recovery.

3. Altere seu arquivo de log para 1 MB ou menos (você decide)

4. Defina seu banco de dados novamente para recuperação completa.

Espero que seja ajuda

Phong Tran