Encolhendo um log de transações do SQL Server

8

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'.

Kraig Walker
fonte
Você verificou alguma transação aberta ou algum tipo de tarefa ad-hoc ou agendada que teria causado o crescimento do log de transações? Identificar o motivo pode ajudá-lo a planejar o crescimento adequadamente.
KASQLDBA 25/01
Assim que você alternar para o modo Simples, não será mais possível recuperar o log de transações além desse ponto, até o próximo backup completo. Mesmo se você voltar ao modo de recuperação completa, o backup / restauração / recuperação do log de transações não começará a funcionar novamente até que você faça outro backup completo. Portanto, certifique-se de fazer um backup completo imediatamente depois de voltar para a recuperação completa.
precisa saber é o seguinte
O motivo usual para arquivos de log fora de controle como este é 1) falha em fazer backups completos regulares, 2) falha em fazer backups regulares de log de transações ou 3) alguma configuração nos backups completos ou em log (como somente cópia) ) que está impedindo que as marcas de backup normais sejam definidas.
usar o seguinte código
@RBarryYoung Verificamos que é porque nenhum backup de t-log foi realizado. Você recomenda fazer o que sugeri originalmente, mas fazer um backup completo manualmente logo após retornar o banco de dados à recuperação total para evitar os problemas mencionados? É imperativo recuperar um pouco do espaço em disco o mais rápido possível.
Kraig Walker
AFAIK, não há nenhum ponto em estar no modo de recuperação completa se você não estiver fazendo backups de log. Se você não planeja fazer backups de log, deixe-o no modo simples. Seus backups completos ainda poderão ser restaurados de qualquer maneira, você acabou de ganhar; não poderá fazer uma recuperação / rollforward, mas você não poderá fazer isso de qualquer maneira sem os backups de log.
usar o seguinte código

Respostas:

4

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.

Pixelated
fonte
3

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.

user541852587
fonte
Pelo que entendi, isso já dura seis meses ou mais, agora com zero de manutenção, daí o tamanho. Farei o que você sugere e fique de olho no crescimento do arquivo assim que resolver o problema imediato.
Kraig Walker
Para ser sincero, quero votar nesta resposta.
jyao
11
Na verdade, NÃO é seguro alternar da recuperação COMPLETA para a simples e começar a diminuir. Pela descrição do Kraig Walker, acho que esse banco de dados não possui nenhum backup t-log por algum tempo. Portanto, a primeira coisa a fazer é verificar o modo de recuperação de banco de dados e qual é o último backup do tlog feito (se NÃO for o modo de recuperação simples). Se houver um backup do tlog, verifique por que o backup do tlog não limpa o log marcando [log_reuse_wait_desc] na exibição sys.databases Minha experiência é que, se a maioria do arquivo de log estiver vazia, você poderá reduzir diretamente.
jyao
@jyao Seu palpite é certo, não há backups de log e é por isso que o arquivo é tão grande.
Kraig Walker