Tempo aproximado para leitura: 00:05:58 min
Dúvida
Como resolver o consumo demasiado de espaço em disco para o arquivo de log ou dados .ldf e .mdf?
Ambiente
Framework - Framework (Linha RM) - Banco de Dados - Todas as versões
Solução
O Shrink é um recurso que nos permite reduzir o tamanho dos arquivos do banco de dados. Está operação pode ser feita em conjunto, banco de dados inteiro, ou em um arquivo específico, dados ou log.
Primeiramente verifique se a empresa possui a rotina de efetuar backup de log e se possui auditoria de usuário ligada. Efetue um backup da base de dados e do log antes de efetuar o processo.
O log do SQL Server poderá crescer mais ou menos a depender do recovery model escolhido.
O recovery model simple, irá logar as transações realizadas, porém ao escolher este nível de recuperação o SQL Server entende que sua tolerância para perda de dados não envolve recuperação point in time ou backups full e diferencial são suficientes. Desta forma, ao atingir um certo volume o SQL Server automaticamente realiza um checkpoint em background e confirma as transações pendentes no log para o arquivo de dados. Caso seu recovery esteja como simple e seu log esteja crescendo rapidamente e não retornando a um tamanho gerenciável existem algumas ações a serem realizadas.
- Checkpoints manuais
- Shrink file
Caso ainda assim, tenha dificuldade em reduzir o log, pode existir alguma configuração na instância relacionada a replicações realizadas no passado ou alguma outra configuração voltada a este cenário impactando o processo de checkpoint.
Caso esteja utilizando o recovery full, o responsável mais comum por realizar o processo de checkpoint sem a intervenção do DBA é o processo de backup do log de transação. Ao se realizar o backup, o processo de checkpoint é realizado de forma automática no momento deste backup, mantendo os arquivos de log em produção em tamanhos gerenciáveis. Para isso, é necessário escolher a periodicidade do backup de log conforme o seu negócio.
Caso o seu recovery model seja full e o processo de backup de log não esteja sendo realizado, este pode ser o problema relacionado ao crescimento dos arquivos.
Caso não seja o DBA da empresa, sugiro que alinhe estas informações com o mesmo para tomada de decisão.
USE [Nome da Base]
GO
DBCC SHRINKFILE (N'Nome do Log' , 0, TRUNCATEONLY)
GO
O processo de shrink em arquivos de dados pode ocasionar problemas como fragmentação de índices locks dentre outros cenários indesejáveis. Sendo assim, recomendamos alinhar a estratégia com o DBA responsável.
Para garantir o crescimentos dos arquivos de Dados e arquivos de Log mdf e ldf, recomendamos as seguintes parametrizações para os arquivos correspondentes:
- RECOVERY MODEL: simple
- AUTO GROWTH: unrestricted growth by 10%
- MAXIMUM FILE SIZE: Unlimited
Importante
Estas recomendações são apenas um direcionamento básico para uma boa operação do servidor de banco de dados e não deve ser considerado como único padrão de avaliação, monitoração, e configuração do banco de dados que deve ser realizado por o DBA responsável.
6. LIMPEZA DAS TABELAS DE LOG DE EXECUÇÃO DE PROCESSOS
A TOTVS recomenda que não seja feita nenhuma intervenção direta no banco de dados, por isso temos mecanismos afim de facilitar os processos de limpeza das tabelas de log de execução de processos:
Limpeza Tabelas Log Execução Processos
Erro:
The transaction log for database 'CorporeRM_TESTE' is full. To find out why space in the log cannot be reused, see the log_reus>
Caso o erro acima ocorra, segue abaixo alguns comandos que podem ajudar e analisar o erro:
DBCC SQLPERF(LOGSPACE)
Fornece logs de transações e estatísticas de uso de espaço para todos os bancos de dados. Também pode ser utilizado para repor as estatísticas de espera e travamento.
LOGSPACE: Retorna o tamanho atual do log de transações e a porcentagem de espaço de log usada para cada banco de dados. Você pode usar essas informações para monitorar a quantidade de espaço utilizado em um log de transações.Leia DBCC SQLPERF
DBCC SHRINKDATABASE ('nome_dabase'):
Reduz o tamanho dos dados e arquivos de log do banco de dados especificado.
As ilustrações seguintes mostram um log de transações antes e depois do truncamento. A primeira ilustração mostra um log de transações que nunca foi truncado. Atualmente, quatro arquivos de log virtuais estão em uso pelo log lógico. O log virtual inicia à frente do primeiro arquivo de log virtual e termina em log 4 virtual. O registro de MinLSN está em log 3 virtual. O log 1 virtual e o log 2 virtual contêm apenas registros de log inativos. Estes registros podem ser truncados. O log 5 virtual ainda está sem uso e não é parte do log lógico atual.
A segunda ilustração mostra como o log aparece depois de ser truncado. Log 1 virtual e log 2 virtual foram liberados para reutilização. O log lógico agora inicia no começo do log 3 virtual. O log 5 virtual ainda está sem uso e não é parte do log lógico atual.
Saiba mais
Guia de arquitetura e gerenciamento do log de transações do SQL Server
Truncamento de log de transações
0 Comentários