Produto:

Banco de Dados

Versões:

Todas

Ocorrência:

SHRINK - Reduzir tamanho dos arquivos do banco de dados

Ambiente:

SQL Server

Passo a passo:

O Shrink é um recurso que nos permite reduzir o tamanho dos arquivos do banco de dados. Esta 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.


1. Selecione a opção de propriedades da base:
 

 
2. Clique na opção Options:
 


Clique na opção Options e selecione o Recovery model como Simple

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 automáticamente 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 rápidamente e não retornando a um tamnaho 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 períodicidade 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.

 

3. Siga os procedimentos abaixo:
 

Clique com o botão direito sobre a base > Tasks > Shrink > Files
 
4. Siga os procedimentos abaixo:
 

Marque a opção File Type: Log e clique em ok
 
O procedimento acima também pode ser executado através do script abaixo:
 
USE Nome_Base
GO
ALTER DATABASE Nome_Base SET RECOVERY SIMPLE
GO
DBCC SHRINKFILE (Nome_Log, 5)
GO
ALTER DATABASE Nome_Base SET RECOVERY FULL
GO

 
5. Para verificação quanto a limitação de memória do log, deve-se verificar os parâmetros abaixo:
 

Clique com o botão direito sobre a instância da base > Properties
 

Acesse a opção Memory – Verifique se o Maximum Server memory não está estourado. Deve ser estudado se o tamanho informado está correto ou se deve ser limitado maior espaço.
Utilize o parâmetro max_server_memory para garantir que o sistema operacional não experimente uma pressão de memória prejudicial. Reserve de 2 GB a 4 GB para o sistema operacional em si.


# Fica a dica referente ao erro abaixo:

The transaction log for database 'CorporeRM_TESTE' is full. To find out why space in the log cannot be reused, see the log_reus>

Segue abaixo alguns comando 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.

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.


Log de transação com quatro logs virtuais


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.


Arquivo de log dividido em quatro arquivos de log virtuais


https://technet.microsoft.com/pt-br/library/ms189085.aspx



Outra forma de reduzir o volume da base de dados é a limpeza das tabelas de log de execução de processos, estes objetos podem conter um alto volume de dados.

Para facilitar o processo de limpeza das tabelas de log de execução de processos:


Limpeza Das Tabelas De Log De Execução De Processos
http://tdn.totvs.com/x/GAaZDg



Observações:

Para mais informações:


   COMUNIDADE  R@Tecnologia

 Canais de Atendimento:

Abertura de Chamados Através do Portal Totvs www.suporte.totvs.com.br

Telefônico: 4003-0015 Escolhendo as opções 2 – (Software), 2 – (Suporte Técnico), 3 – (RM), 8 – (Tecnologia), 2 – (Banco de Dados)