Encolhendo um log de transações do SQL Server

No momento, estou tendo que lidar com um log de transações do SQL Server que ficou fora de controle. Isenção de responsabilidade: eu não sou dba e essa não é minha área de especialização, portanto, tenha paciência comigo.

Atualmente, tenho um arquivo de log de transações de 115 GB para um banco de dados de 500 MB que (obviamente) foi mal gerenciado por algum tempo para que ele chegue nesse estado.

A principal prioridade é recuperar o espaço no disco ocupado por esse arquivo antes de acabarmos! Disseram-me que aumentar o tamanho da unidade não é uma opção, mesmo que temporariamente, e com base no crescimento passado, precisamos agir em breve.

Pelo que entendi, a melhor abordagem é manter o banco de dados no modo de recuperação completa, mas faça backups regulares do arquivo de log, monitore isso por um período de tempo e ajuste o tamanho inicial e o incremento conforme necessário. Tudo certo.

Como fazemos backups regulares de banco de dados completos à meia-noite, seria seguro colocar temporariamente o banco de dados no modo de recuperação simples (após a execução de um desses backups), reduzir o arquivo de log para recuperar (praticamente todo) o espaço e em seguida, coloque-o novamente no Full Recovery com a estratégia de backup mencionada acima?

Meu pensamento é que, se algo acontecesse nesse período, poderíamos simplesmente restaurar o backup completo sem usar os logs.

ATUALIZAR

Alguns detalhes extras em resposta a algumas das respostas e comentários:

• Queremos manter a capacidade de fazer uma restauração pontual, para que o banco de dados permaneça no modo de recuperação total.

• O motivo pelo qual o arquivo t-log cresceu tanto é que nunca foi feito backup . Verificado como log_reuse_wait_desc retorna 'LOG_BACKUP'.

O log de transações para esse banco de dados contém todas as transações desde o último backup do log de transações ou a última vez que ele foi alternado do modo de recuperação simples. Execute o seguinte para obter a resposta definitiva sobre por que o SQL Server não pode truncar o log e subseqüentemente por que o log está crescendo.

SELECT  d.Name
        ,d.log_reuse_wait_desc
FROM    sys.databases d
ORDER BY
        d.name

Se você deseja recuperação pontual, deixe o banco de dados no modelo de recuperação completa e faça backups freqüentes de log. Cada backup de log conterá todas as transações desde o último backup de log. O processo de backup do log também é responsável por limpar o log e marcar o espaço para reutilização, ou seja, a próxima transação feita no banco de dados será gravada no início do log truncado de maneira circular. Esse backup e reutilização do log é o que impede o crescimento do arquivo de log.

Se você não está interessado em recuperação pontual e deseja simplificar a administração do banco de dados. Em seguida, defina o banco de dados para o modelo de recuperação simples e não faça backups de t-log. O SQL Server truncará automaticamente o log de transações após a confirmação de cada transação. Significando que uma vez que a transação tenha sido confirmada no log, o registro será substituído pela próxima transação etc.

De qualquer forma, depois de tomar uma dessas duas decisões, você poderá reduzir o arquivo de log para um tamanho mais razoável. Observe idealmente que você deseja torná-lo grande o suficiente para que não cresça, mas não tão grande que seja necessário reduzi-lo novamente. Observe também que você não pode reduzir a parte ativa do log.

Faça o download e implante a solução de administração de banco de dados https://ola.hallengren.com/ para cobrir backups, fragmentação de índice, estatísticas e CHECKDB.

Você também pode encontrar o relatório 'uso do disco' retornado clicando com o botão direito do mouse no DB em Explorador de Objetos> Relatórios> Relatórios padrão> 'uso do disco' útil para retornar o espaço livre no t-log.

Também recomendo que você pesquise no Google por que é tão importante manter a cadeia de logs intacta do ponto de vista de DR e como a mudança de completa para simples quebra a cadeia, deixando você exposto à perda de dados.

Como fazemos backups regulares de banco de dados completos à meia-noite, seria seguro colocar temporariamente o banco de dados no modo de recuperação simples (após a execução de um desses backups), reduzir o arquivo de log para recuperar (praticamente todo) o espaço e em seguida, coloque-o novamente no Full Recovery com a estratégia de backup mencionada acima?

Sim, seria seguro, desde que você interfira em nenhuma transação ao fazer isso, como uma carga noturna. Em geral, se um banco de dados estiver no modo de recuperação completa, você deseja backups regulares do T-Log. Isso reduzirá o problema que você está enfrentando. Escrevo "em geral" porque, em alguns casos, vi pessoas definirem um banco de dados como completo, sem saber por que o fizeram. Vamos supor que não seja esse o caso.

Você pode considerar por que o log tem esse tamanho em relação ao tamanho do banco de dados. Um banco de dados de 500 MB com um log de 116 GB parece muito desproporcional para um evento único. Eu sugeriria monitorar o que está acontecendo no banco de dados para ver como ele chegou a esse tamanho em primeiro lugar.